こんにちは！
複数の億規模プロジェクトでPLやってるやまさんです！
要件定義って、どうやって進めればいいか分からないんだよね…
要件定義はやることが一番ふわっとしますよね^^;
ただ、要件定義工程はシステム開発において最重要工程です。
要件定義のデキでプロジェクト全体が成功するか、成功しないが半分以上決まると言っていいでしょう。
この記事では要件定義工程で行う上でのポイントを紹介していきたいと思います！
ぜひ読んでみてくださいね！
今回はウォーターフォール型の開発手法をベースに紹介していきたいと思います。
まだまだ主流の開発手法でウォーターフォールを標準開発手法として使用しているIT企業も多いので、ぜひご覧になってみてください！
Contents
システム開発全体と要件定義の位置づけ
システム開発全体の流れは上の図のようになっています。
V字モデルの概念ですね。
この図は１度は見たことがあるのではないでしょうか。
システム開発全体で要件定義は開発フェーズの先頭にいます。
最初ということもあり、要件定義工程ではシステム開発で
- 何をやるべきなのか
- 実際に何をやっていくのか
これらをお客さんと決めていく工程なんですよね。
つまり、要件定義工程で検討事項に漏れがあると、お客さんの目に触れるまで二度と検討されないなんてこともあります。
よく考えれば、当たり前なんですが、考えるべきこととして議題に上がってなければ誰も考えないですよね^^;
人間、目に見える間違ったもの指摘するよりも、足りないものを検討する方が難しいです。
なので、要件定義工程はプロジェクトにおいて超重要な工程いえるでしょう。
システム開発で要件定義工程はプロジェクト炎上原因の第１位の超重要工程
この記事の冒頭で少しふれましたが、要件定義工程はシステム開発プロジェクトで最重要工程だと、ボクは考えます。
というか、システム開発プロジェクトが成功するか、成功しないかは要件定義のデキに大きく左右されると言ってもいいぐらいでしょう。
webで検索してみても、こんな記述が出てきます
プロジェクトが失敗する理由は要件定義の不備に集約できる。
日経ビジネス:https://business.nikkei.com/atcl/opinion/15/100753/030700005/
↑は日経ビジネスというビジネス雑誌の「プロジェクト失敗の理由」というテーマの記事から引用しました。
実際の調査は日経コンピュータという雑誌がやってるみたいですね。
ということで、日経コンピュータを調べてみると…
これらの記述からも要件定義工程はプロジェクトが炎上するか、炎上しないかが決まる超重要工程といえそうです。
要件定義が原因でプロジェクトが炎上する超単純な理由
では、要件定義工程のデキがなぜプロジェクト炎上につながるのでしょうか。
結論は要件定義の不備を確認できるのはプロジェクトの最終段階、お客さんがシステムを確認する段階だからです。
つまり、プロジェクトの一番最後の工程なんですよね。
なので、要件定義が原因でプロジェクトが炎上する理由は超単純で
- 不備を見つけても直すための時間が極端に短い
これなんですよね^^;
しかも、要件定義が原因の問題ってたいてい…
こういうのできないの？
この機能、想像してたのと違う。
こんな感じなんですよね^^;
こういった要件定義を原因とする不備って、外部設計からすべてやり直しなんてことはめちゃあります。
最初からやり直しレベルのことをエンジニアはプロジェクトの終盤に言われるわけです^^;
なので、要件定義が不十分だとプロジェクトが炎上する理由は
いまさらそんなことを言う？
これにつきます^^;
システム開発の要件定義工程を成功させるには？ 5W2Hで情報を整理
ここからこの記事の本題です（笑）
プロジェクトの成否を握る要件定義工程のポイントを紹介していますね。
要件定義書など表現の仕方（成果物）の形はいろいろあると思います。
ですが、要件定義工程で決めおかないといけないことは
”5W2H”
これで整理するのがオススメです。
詳しく説明していきますね！
WHY なぜやるのか
システム開発のプロジェクトには必ず目的（なぜやるのか）があります。
- 毎日行っている定例的な作業を効率化したい
- ミスが多い特定の作業を減らしたい
- 新規顧客を獲得して売上を上げたい
- etc…
内容はプロジェクトごとに変わりますが、システムを導入することで解決したい問題や達成したい目標が必ずあるはず。
お客さんの問題を解決したり、目標を達成することがプロジェクトの目的になります。
要件定義工程ではこの”プロジェクトの目的”を把握する必要があるんですよね。
プロジェクト炎上の原因はほぼこの”目的（WHY）”の把握が甘いのが原因です^^;
”目的（WHY）”の把握が甘いと、なせプロジェクトが炎上するの？
そこの解説の前に”何を（WHAT）”を説明していきますね。
WHAT 何をするか
目的（WHY）が把握できたら、その目的を達成するために何を（WHAT）したらいいか考えます。
つまり、”課題設定”ですね^^
ここでのポイントは「何ができたら、目的を達成できるのか」そういった視点で考えることですよ^^
目的が達成できた状態を具体的に考えていくイメージです。
”目的（WHY）”をしっかり考えておくと、”何を（WHAT）”を考えやすいんですよね。
例えば、プロジェクトの目的が”売上を上げたい”の場合だと…
- 新規顧客の獲得
- 既存顧客のリピート率UP
- 1回あたりの購入金額合計のUP（客単価UPと言われるやつ）
- etc
といった感じで、いろいろありますよね^^;
ちょっと方向性がたくさんありすぎるのではないでしょうか。
「売上を上げたい」というのを目的（WHY）に設定するのはマズそうです。
では「売上を上げたい」という”目的（WHY）”を「1回あたりの購入金額合計のUP（客単価UP）して売上を上げたい」をしてみると、どうでしょうか。
これの”何を（WHAT）”を考えてみると…
- 購入予定の商品といっしょに買うと便利なものをおすすめする
- 価格の高い類似の別商品を紹介する
- 以前、お客さんが購入した消耗品商品を補給するような商品を紹介する
ここまで具体化できれば、具体的に何をやればいいかイメージができてくるんじゃないでしょうか^^
実際のプロジェクトではこんな感じでどんどん”何を（WHAT）”を出して細かくしていきます。
でも、やることたくさんになると、コストもスケジュールもどんどん大きくなっていかない？
その通りです^^;
全てをやっていたら後で説明するコスト（HOW MUCH）や期間（WHEN）を守れません。
なので、実際のプロジェクトではお客さんと話合いながらどの課題に対してアプローチしていくか決めていく必要があります。
なお、ここで、「”目的（WHY）”の把握が甘いと、なせプロジェクトが炎上するのか」の質問について回答しておきますね^^
その答えは「”何を（WHAT）”の不足するから」です。
”何を（WHAT）”の不足すると、具体的にどうなるかと言うと…
プロジェクトの終盤、お客さんの確認で仕様追加や仕様変更が発生します。
そして、たいてい期間も人員も不足しプロジェクトが炎上するんですよね^^;
”何を（WHAT）”を考えたとき、やることのイメージがしづらい場合は”目的（WHY[）”に立ち返って検討するのがオススメです。
HOW どうやるのか
目的（WHY）と何を（WHAT）の検討を終えたら、次にどうやって実現するか（HOW）を考えていきます。
- どういうシステム構成にするのか
- 何か既存のアプリを流用するのか
- クラウドを使うのか
- etc
ここでやっとシステム的な視点が出てきます。
やってしまいがちな失敗例としてはシステム的な視点から”何を（WHAT）”を考えてしまうパターン。
エンジニアはシステムを作る職業なのでハマりやりすいので、注意しておくのがオススメです^^
WHERE どこを対象とするのか
お客さんの業務フロー上のどこをシステム化するのか、そういったシステム化の対象範囲（WHERE）を決めていきます。
先ほど例で示した「1回あたりの購入金額合計のUP」の例でいろんな何を（WHAT）がでてきましたね。
検討を進めていくと、いろんな課題（WHAT）が出てきますが、「今回のプロジェクトではこの課題への対策は優先度が低いので対象外にしましょう」などといった形でお客さんと決めていきます。
WHO 誰がやるか
どうやるのか（HOW）、どこを対象とするのか（WHERE）が決めたら、次はだれが（WHO）やるのかを決めていきます。
自分たち（自社）がやるのか、外注するか、お客さんがやるのかなどなど…
実際のプロジェクトではステークホルダー整理や体制図作成などという形で表れてくることが多いですよ^^
WHEN いつまでにやるのか
WHENは分かりやすいですね^^
プロジェクトは終わりを決める必要がるので、いつまでに（WHEN）何をやるのかというのを整理していきます。
お客さんとシステムのリリース時期を決めるだけでなく、プロジェクト全体の大まかなスケジュールを決めていきましょう。
外部設計工程はいつまでにやるのか、結合テストはいつから始めるかなど、大まかなスケジュールを決めていきます。
お客さんが特に気にするのはお客さんの受け入れテストのタイミングとリリースタイミングですね。
ただ、エンジニア側としてはコーディングはいつまでにやるのか、単体テストはいつまでにやるのかなどを最低限この段階で決めていきます。
HOW MUCH いくらかかるのか
いくら必要なのか（HOW MUCH）も分かりやすいですね。
当たり前ですが、システム開発プロジェクトはタダではありません^^;
- ハードウェアを購入するならいくならのか
- 原価（工数）はいくらか
- お客さんへの提示額はいくらか
↑のようなことを決めていきます。
当たり前ですが、ここはプロジェクトの収益にダイレクトに影響するのでとても重要になりますよ！
今回は機能要件をメインに紹介しています。ですが、プロジェクトで見落としがち要件の１つに非機能要件というものがあります。
処理スピードなどの性能やセキュリティに関する要件などのことですね。
非機能要件は要件定義工程でお客さんへのヒアリングを行っていてもほぼ話題に上がらないのが特徴です。一方で、非機能要件はスペックなどコストにダイレクトにはねてくるものもあるんですよね^^;
なので、非機能要件もしっかりとした検討する必要があります。
システム開発の要件定義で一番注意が必要なのは「WHY：目的の把握」
要件定義は5W2Hで情報を整理するのがいいのは分かったけど、注意すべきポイントとかあったりする？
もちろんありますよー（笑）
ボクはエンジニアを10年以上やってますが、経験上、要件定義で不備が発生しやすいポイントは”「WHY：目的」の把握不足”なんですよね。
「WHY：目的」の把握不足が原因で「WHAT：何を」の漏れが出てくるんです^^;
「WHY：目的」の把握不足が原因の漏れはプロジェクト終盤での”仕様追加、仕様変更”という形であらわれてきます。
実のところ、お客さん自身も何がやりたいか分かってないことが多いんですよ。
え？発注してきたのお客さんなのに？
そうなんですよね^^;
「システム導入すれば全部解決するんでしょうー？」のように思ってるお客さんは結構多いです…
当然ですが、ITシステムは魔法ではありません。
パッケージにするにしても、スクラッチにするにしても、何ができればいいのか、システム導入の目的を考えてシステムを作らないと望んだ効果は出てきません。
システムの導入目的を把握が甘かったりすると、システムで実装するべき機能が漏れます。
要件定義ではシステムに必要な機能を決めていくのが主な作業。
導入目的をちゃんと把握していないと本当は実装すべき機能を見落としてしまう場合があるんですよね。
こういった見落とされた機能は設計書や要件定義書などに記載されていない場合が大半です。
なので、システムで実装されていなくてもバグとは言い切れないんですが、実際の開発では
「これもよろしく」
「この機能がないと話にならないね」
など、お客さんからは”あって当然でしょ”というスタンスで、納品確認時に申告が上がってきます。
お客さんとしてもシステム開発にかかったお金のムダにするわけにはいかないのでかなり強めに言ってくることが多いんですよね…
PMも赤字を避けるためにいろいろ調整を頑張るんですが、結局、断り切れずに徹夜して対応。
こんな流れで炎上しているのはよく見かけるんですよね。
↑のような炎上パターンにハマらないためにも、5W2Hで情報をしっかり整理して検討漏れを防止していくのがオススメです。
システム開発後半で発生しがちなプロジェクト炎上パターンに”システムを作ることが目的になっている”というものがあります。
いろいろなトラブルの結果、時間がなくなり当初の仕様を捻じ曲げる。要はシステムの都合で機能の内容を変更しちゃうってことですね。
信じられないかもしれませんが、本当にあるのでご注意を…^^;
まとめ：システム開発は要件定義工程のデキでプロジェクト成否が決まる。
この記事で次のようなことを紹介しました。
- 要件定義は開発工程全体の最重要工程
- でも、要件定義工程はシステム開発で難易度が高く炎上原因の第１位
- 要件定義の不備はプロジェクト後半で問題となって炎上する
- 要件定義工程を成功させるには5W2Hにそって情報を整理するのがオススメ
- 実際のプロジェクトでは”WHY：システム開発の目的”の不備が発生することが多いので注意
いかがでしたでしょうか。
この記事では「お客さんのシステム導入目的を把握する」ことの重要性にも触れましたね^^
この記事をここまで読んでいただけたのでお気づきかと思いますが、エンジニアにはシステム導入目的を把握してお客さんのビジネス上の問題を解決していくことが求められます。
ですが、正直なところ、これができるエンジニアはとても少ない^^;
逆に言うと、お客さんのシステム導入目的を把握できるエンジニアは希少性が高いことになります。
実はこの希少性は年収という形でも表れてきているんですよね。
エンジニアの”希少性と年収”についてはこちらの記事で紹介してみたので、ぜひ読んでみてください！
それでは！
最後に（おまけ）
ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;
プログラミングなど、ITに関するスキルが壊滅的だったのです。
ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。
こう言うと、なかなかの怪しさですよね（苦笑）
ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。
ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^
プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。
めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。
そのためか、昔は
- エンジニアになったはいいものの、IT技術に関して興味を持てない…
- 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
- IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
- 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…
このような悩みを抱えていました。
おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。
ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…
というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。
このブログの中でも人気の記事なので、気になった方は一度見てみてください^^
最後まで読んでいただきありがとうございました！！
仕事で要件定義工程を任されたんだけど、結局何やればいいか分からなくて…