私が体験した要件定義における５つの失敗事例と事前に防ぐ方法

「システム開発をこれから依頼しようとしているが、開発の要件定義で失敗が多いと聞いて不安」
「過去の失敗事例を知って今後の対策を練りたい」
こんなことに悩んでいませんか

たしかに、わたし自身も今まで多くのシステム開発案件に関わる中で、多くの失敗を経験してきたし、同僚が失敗した事例も見てきた。その多くは要件定義がうまくできていなかったためのものが多い。

しかし、安心して欲しい。システム開発をそこまで恐れる必要はない。要件定義の失敗事例を理解して対策を事前に講じれば失敗の確率は大幅に下げることができる。

この記事では、そんな不安要素を取り除くために要件定義の失敗事例を個人的な経験も踏まえて網羅的に紹介する。また、各失敗事例がどういった原因で発生していて、どうビジネスに影響を与えるのか、またどういった対策がありえるのかについても触れていく。

これを読んでくれたあなたが、ここで紹介する要件定義の失敗事例から事前に手を打つべき勘所を把握して、納得のいく開発プロジェクトの遂行ができると幸いである。

1 失敗事例１：要件とビジネス的な要求がずれている

一番よくある失敗として、要件とビジネス的な要求がずれていることが挙げられる。ビジネスで達成したかったこととシステムで実現できることにズレがあるパターンだ。

続く章でその内容、原因、対策について詳細にみていく。

1-1 内容：想定と違うものができてしまう

たとえば、筆者が以前関わっていた案件でこんなことがあった。その案件では、工場などを持っている企業向けに二酸化炭素の排出量などの環境情報を集計するシステムを開発していた。

発注側は「工場などの拠点別にデータを入力してもらい、最終的に企業単位で数値を合算でき、そのデータの経年での推移が管理できる」という機能を想定していた。

しかし、開発者はデータの入力が拠点別に行われるという事実を把握していなかった。そのため「一人の人が各種データを入力し、企業単位でそのデータの経年での推移が管理できる」というシステムを作ってしまった。

つまり、ワークフローが正確に伝わっていなかったため、実際の運用に耐えないシステムが出来上がってしまったのだ。

1-2 原因：要求がエンジニアに伝わっていない

要求がエンジニアに正確に伝わっていないと、要件定義に失敗する可能性が格段に高まる。

そもそもシステム開発の流れは、発注者が受注者であるエンジニア（開発会社）に対してビジネス的に実現したい要求を伝える。その要求を元に、エンジニアが要件定義を行いシステム開発の大枠を決める。

そのため要求が明確に共有されていない場合、おのずと要件もビジネスの目的から外れる可能性が出てくる。

1-3 対策：エンジニアが理解しやすいように要求を共有する

要件とビジネス的な要求にずれを生じさせないようにするためには、エンジニアに対して正確に要求を共有することが必要だ。

そのためには、以下の点に留意して作るシステムや機能の詳細を箇条書きで伝えることが有効だ。

・システムや機能の目的（なぜそれを作るのか？

　例）複数拠点の工場のデータを一括で経年で把握したいから

・誰が何をするのかというワークフロー

　例）複数拠点の工場の担当者がデータを入力する。本社の管理部門の担当者がデータを一括で経年で把握できる。

自由な文章で要求を共有すると次のような問題が起こり得る。

・エンジニアが欲しい情報の記載が漏れる

・情報を盛り込みすぎてエンジニアが必要な情報を取捨選択するのが難しくなり、伝えたい内容を理解してもらえない

逆に箇条書きでポイントを絞って共有することで、必要な情報の漏れがなくなり、情報を受け取った側の理解が容易になる。

2 失敗事例２：要件が頻繁に変わってしまう

要件が頻繁に変わってしまうパターンも失敗事例としてありがちだ。開発に着手している途中で方針が変更になり、手戻りなどが発生してしまうパターンだ。

続く章でその内容、原因、対策について詳細にみていく。

2-1 内容

例えば、以前とあるアンケートシステムの開発プロジェクトにおいて似たような事例が起きた。そのシステムは、企業が顧客に対して任意のアンケート調査を実施するためのものだった。それを実現するために、自社で質問を作り、顧客に送信し、顧客の回答を自社の担当者が管理画面上で確認できるという機能があった。

そのプロジェクトの中で、アンケートの質問を検索する機能を作ることになっていた。検索する方法としては、以下の２つが想定されていた。

1 タグ検索：自社で作成する質問に担当者が任意のタグをつけて、そのタグで検索する

2 フリーワード検索：質問文のテキストから検索対象のワードと一致する質問を検索する

しかし、開発が進行していくうちにフリーワード検索の対象について議論が起き前提が覆った。その結果、検索対象が質問文だけではなく、回答データに対しても行いたいという要求に変わった。そして、要求の変更に伴って要件定義もし直すことになった。

2-2 原因：スコープが大きすぎる

この手の失敗の原因としては、開発する機能の単位が大きすぎることが挙げられる。本来であればいくつかの開発案件として分けるべきなのに、一つの大きな案件の塊として扱ってしまっているということだ。

システム開発は「要件定義→設計→開発」という流れで進んでいく。つまり、要件を実現するためにどう作るかを設計し、その設計に基づいて実際にプログラムを書いていくという流れだ。

そのため要件が変わると、その変更の程度によって設計も変えなければならない場合がある。

実際先ほどの例では、データの保存方法についても変更が発生した。その結果、設計レベルで大幅な手戻りが発生した。

2-3 対策：一つあたりの開発スコープを適切なサイズに切る。

要件が頻繁に変わってしまうことを防ぐためには、一つの開発案件あたりのスコープを適切なサイズに分割することが必要だ。そのため発注者側が本当にその案件は分割できないのかを考えることが必要だ。また念を押して、受注者に対して分割ができないか、分割するならどうやるかなどを相談しながら提案をもらいつつ進めるのが良い。

先ほどの例で言えば、同じ検索機能でもタグ検索とフリーワード検索は別々に考えることができる。そのため２つの異なる案件として開発を進めていれば手戻りは小さく、タグ検索のリリース時期についてはフリーワード検索の要件変更の影響を受けなくて済んだはずだ。

3 失敗事例３：要件定義の段階で対応が必要な項目についての認識が漏れてしまっている

要件定義の段階で対応が必要な項目についての認識が漏れてしまっているパターンも失敗事例としてよくある。

続く章でその内容、原因、対策について詳細にみていく。

3-1 内容

例えば、以前の案件でこんなことがあった。その案件では、企業向けのシステムを開発していた。そのシステムは３つの料金プランがあり、料金プランによって使える機能が異なっていた。

しかし、システムのリリース後に管理者側でプランを追加したり、名称変更をしたりする機能がないことが問題になった。

その結果、企業向けの料金プランを追加、変更する機能は、当初発注側が想定していた時期よりも遅れて追加されることになった。

3-2 原因：エンジニアの考慮漏れ

この失敗事例の原因は、エンジニアの考慮漏れであることがほとんどだ。よく起こりがちなのが、ユーザが使う画面はしっかり考慮しているのに、管理者側が使う画面について考慮が漏れてしまうパターンだ。

3-3 対策：CRUDマトリクスを作ることを依頼する

こういった失敗を防ぐために、CRUDマトリクスを作成してもらうことは効果的だ。CRUDマトリクスを作成することで、以下の２点がシステム開発で実現できることを担保できる。

・必要なデータがある

・各データに対する処理が過不足なく作られる

CRUDマトリクスとは、以下のようなものだ。縦軸に必要なデータを並べ、横軸に画面一覧を並べている。それぞれの交差するマスで何ができるかを示している。（Create,Read,Update,Delete）

これを受注者に作ってもらうことで、必要なデータとそれぞれに対してどんな処理をどこの画面で行えるのかが一目でわかるようになる。そのため発注者・受注者双方が協力して認識の漏れをなくす一助になる。

4 失敗事例４：工数の見積もりが甘すぎる

工数の見積もりが甘すぎるのも失敗事例としてありがちだ。

続く章でその内容、原因、対策について詳細にみていく。

4-1 内容

例えば、筆者が以前関わったプロジェクトで開発側の責任者が工数の算出をかなりざっくりと行ったことがあった。その工数の算出に使える時間が少なかったこともあり、算出された工数に特に根拠はなく、なおかつかなりハイスキルな人目線での予想工数だった。そのため、3ヶ月と見積られた開発プロジェクトだったが、プロジェクトの初期の段階で遅延が出始め、最終的には1ヶ月以上遅延した。

4-2 原因：工数出しの根拠が弱い

この手の失敗の原因としては、工数の算出方法の根拠が弱いことが挙げられる。

本来であれば、タスクを分解し、分解したそれぞれのタスクに対して予想工数を算出していく。しかし、タスクの分解が甘く、ざっくりしたタスクに対してざっくりと予想工数を割り振っていくと次のどちらかが起きる。大幅な工数遅延。もしくは、開発者が異常な工数的余裕をもつことで生産性がガクッと下がる。

実際これは、開発経験がすくない若手のエンジニアにはよくある現象だ。というのも、業務知識が薄いため、案件を完成させるために必要な工程を想像することが難しいからだ。

その結果、ざっくりとした作業工程に対して、工数を見積もるため大幅な遅延が発生したりする。

4-3 対策：工数出しの根拠を提示してもらう

ざっくりしすぎた工数見積もりを防ぐためには、工数の根拠をできる限り提示してもらうようにすることが望ましい。

ただし前提として、完璧な予想工数というものはない。ソフトウェア開発は予測不能な出来事が多く発生する。それは、他の機能をどう作るのかによって実現方法が異なって来たり、使えると思っていた技術が使えなかったりといったことだ。

そのため、工数出しの根拠を出してもらうことは以下の点を狙ってのことだ。

・根拠を提出するとなれば、より精緻に算出するインセンティブが受注側に生まれる点

・工数に根拠があれば、一つずれた時に見直しがしやすい

　例）一つの画面を作るのに1日かかると見積もっていたとする。しかし、開発してみたら3日かかるとなったら「残りの開発が必要な画面数 x 3日」すれば軌道修正がしやすい。

5 失敗事例５：最初から不確実性が高いものの要件を固めてしまう

不確実性の高いものも含めて全ての要件を一気に固めようとしてしまうというのもよくある失敗パターンだ。

続く章でその内容、原因、対策について詳細にみていく。

5-1 内容

例えば、筆者の経験からもこんなことがあった。当時は企業向けの報告書作成ツールを開発していた。あらかじめシステムが決めたワークフローがあり、ユーザはそれ通りに作業を進めていくことで報告書ができるという機能を持っていた。

しかしそのワークフローが「A->B->C」という順番なのか「A->B」と「A->C」は同時並行で進められるのかという実際のユーザの業務フローが見えていない状態で、前者の機能を作ってしまった。しかし、後にユーザテストをした結果、実際は「A->B」と「A->C」は同時並行で進められるというフローにするべきだということがわかり、改修を余儀なくされた。

この失敗の結果として、使われない機能を開発するために開発工数を費やしてしまった。この例で言えば、以下の２つの点で開発工数を節約できた可能性がある。（もちろん作ってみて試すというのが完全に悪いと否定するわけではない）

・最初の「A->B->C」というワークフローに則って行なった開発工数

・「A->B」と「A->C」は同時並行で進められるというフローにするための修正工数

特に、2つ目に関してはシステムの動きを変更するだけではなく、保存されてしまっているデータの修正も含むため改修のコストは大きい。実際、この例で挙げた案件での改修でも、データ修正にかかった工数はシステムの動きを変更するために使った工数よりも大きかった。