要件定義って何のためにするんだろう？
むかし私もこういった素朴な疑問を上司に聞いたことがあって、その時は「何を作るか明確にするため」と言われて、なるほどと納得した気がしていた。
そうだとすると、お客さんから「こんな画面がほしい」と言われたら要件定義は不要ということなのだろうか？確かに、実際に小さいプロジェクトでは要件定義が行われないこともある。
要件定義をするプロジェクト、しないプロジェクトの違いはどこにあるのか？
そもそも、要件定義は何のためにするのか？
今回はこういった素朴な疑問について述べていく。
目次
要件定義の目的
自分の経験をベースにつらつらと書くことは簡単だが、それだと根拠の弱い主張になってしまう。そう思っていろんな本を読みながら考えを整理してみた。
その結果、要件定義をする理由は『プロジェクトの5W2Hを明確にして失敗を防ぐため』だという結論に至った。
まず、データから紹介していこうと思う。
半数のプロジェクトが失敗する
日経コンピュータの調査で、システム開発プロジェクトの半分は失敗という調査結果が出た。
2003年から考えると2018年では失敗する確率は減少したようだが、それでも半数は失敗しているという。
失敗原因トップは「要件定義の不備」
次にプロジェクトの失敗の原因である。
日経コンピュータは、プロジェクトの失敗原因を「納期・コスト・満足度」の観点で調査した。
出典：日経コンピュータ、2018年3月1日号 p.30
出典：日経コンピュータ、2018年3月1日号 p.32
出典：日経コンピュータ、2018年3月1日号 p.34
仕様変更の発生や、追加開発作業の発生など、原因の上位には『要件定義の不備』が並ぶ。また、満足度の観点でも原因のトップは『要件定義が不十分』となっている。
このように、失敗するプロジェクトの多くは要件定義に問題があったと考えられるのである。
失敗原因トップが要件定義である理由
では、なぜ要件定義の不備がプロジェクト失敗につながりやすいのか？
それは、要件定義の不備はプロジェクトの終盤で発覚しやすく、大きな手戻りになってしまうからだ。
出典：IPA『経営者が参画する要求品質の確保』,p.26
要件定義工程の中で不備が見つかれば資料の修正だけで済む話が、プロジェクトの終盤で発覚すると設計書修正・ロジック修正・再テストという大きな手戻りになるため、納期遅延やコストオーバーにつながってしまうのである。
要件定義ですべきことは5W2Hを整理すること
要件定義の不備がプロジェクトの失敗につながることは分かった。
では、要件定義の不備を無くすには何をすればいいのか？
要件定義の不備を無くすのは非常に難しい課題だが、経済産業省が管理する情報処理推進機構（以下、IPA）で整備されている「共通フレーム」では、要件定義の作業について、下記のように述べている。
要件定義プロセスは、定義された環境において、利用者及び他の利害関係者が必要とするサービスを提供できるシステムに対する要件を定義することを目的とする。
この文章を分解して考えてみると、
どこに提供するのか？（where）
・利用者及び他の利害関係者が必要とするサービス
誰が必要とするのか？（who)
なぜ必要とするのか？(why)
何を必要とするのか？（what)
いつ必要とするのか？(when)
・サービスを提供できるシステムに対する要件
どうやってサービスを提供するのか？(how)
このように要件定義では5W1Hを明確にすべきだと理解できる。
同様にIPAでは、費用（how-much）を含めた5W2Hを明確にすることを推奨している。
システム開発では、「何を作るか」という点ばかりが注目されがちだが、これは手段（How）であって目的ではない。システム開発の背景には、解決したい課題（What）があって、その課題を解決することで成し遂げたいこと（Why）があるのだ。
これを踏まえて、要件定義で整理すべき5W2Hについて述べていく。
Why：目的
システム開発のあるあるとして、「○○システムを作る」という手段（How）が目的になってしまうことがある。
システム開発の費用は億を超えることも珍しくないため、『作ったは良いが使えない』という状況は企業にとって大きな損失だろう。こういったリスクを減らすためにシステムが必要な背景（目的）は明確にしておく必要があるのだ。
What：解決すべき課題
目的（Why）と手段（how）の間には『課題（What）』が存在する。
例えば、売上アップという目的（Why）があるとすると、そのための課題（What）は何なのかを考える。
一般的な売上施策としては
・新規顧客の獲得
・既存顧客の単価UP（購入頻度や購入数等）
・商品単価のUP
などが挙げられる。
こういった課題を現状を分析しながら洗い出していく。
なお、整理した課題については、要件定義書における「業務要件」としてアウトプットする。
How：課題をどう解決するか
設定した課題をどう解決するのか、つまり”手段”の検討だ。ここにきてようやくシステム開発という手段が出てくる。
複数の対策が挙げられる課題もあるため、そういう場合はより手軽で効果の高い対策を評価する。
システム対策をする場合は、
・プラットフォーム（ネットワーク、ハードウェア、OS、ミドルウェア等）の検討
・必要な機能（機能要件）の整理
・求められる性能等（非機能要件）の把握
などについて、細かく整理・検討をしていく。
検討したシステム対策の内容については、要件定義書における「機能要件」「非機能要件」としてアウトプットする。
Where：どこを対象にするのか
課題を解決するうえで対象となる組織、業務、システムなどの範囲を設定する。
例えば、システム対策のうえで業務を一部変更する場合は、全国の各拠点の業務を同時に変えると混乱が大きくなるため、一部の拠点だけの業務を試験的に変更することがある。
他にも、ハンコ廃止のために電子決裁ワークフローシステムを構築する場合でも、全ての申請書に適用すると混乱が大きくなるために、対象の申請書を限定したりする。
このように混乱（影響）を抑えるため、あるいはコストを抑えるために対象を絞ることなるのだ。
なお、ここで整理した内容は、要件定義書における「業務要件」や機能要件に反映される。
Who：課題対策に誰の協力が必要か
課題を解決するうえで誰の協力が必要かを設定する。
業務を変えるのが一部門だけならいいが、関係部門が増えるごとにヒアリングや調整の難易度が上がるため、プロジェクトを先導する部門（窓口部門）を決めることが多い。
これらの整理した結果は、プロジェクト体制図としてアウトプットされる。
When：課題対策をいつまでに行うか
いわゆる納期。
改定された法律への対策だったり、ハードウェアの保守期限切れへの対応だったり、外部環境によって納期が設定されることもあるが、それ以外は体制上できる範囲での”なる早”で納期が設定されることが多い。
How much：課題対策にいくらかかるのか
システム開発費用。
要件定義は最終的にはシステム開発費用の見積りをする。むしろ、見積もりをするために様々な機能要件や非機能要件を整理すると言ってもいいぐらいだ。
さいごに
要件定義の目的について説明してきたが、最後にポイントをまとめる。
（補足）
・プロジェクトの半数は失敗をしており、その原因の上位は要件定義の不備である。
・要件定義の不備はプロジェクト終盤で発覚することが多く、納期遅延やコストオーバーに繋がる可能性が高い。
・5W2Hを明確にすることで要件定義の不備を減らせる
逆に言うと、5W2Hが明確になっている場合は要件定義は完了しているとして問題ない。私の経験上も要件定義工程が無い（完了している判断してマイルストーン上に出さない）小さいプロジェクトは多い。
以上、参考になれば幸いだ。
要件定義工程の関連記事はこちら。
参考文献
日経ビジネス『プロジェクト失敗の理由、15年前から変わらず』
IPA『高品質のための超上流工程における企業の課題・取組み事例集』
コメントを残す