システム開発の遅延理由50％は要件定義の失敗：事例と回避策

システム要件定義のよくある失敗を知っておいて未然に防ぎたい！

といった、疑問に答えます。

この記事では、システム開発で最も重要な要件定義。その要件定義でよく発生する失敗事例とどのように回避できるのか？を紹介します。この記事を読むことで、具体的に要件定義で取るべきアクションが明確になります。

✔記事の信ぴょう性

米にてシステムエンジニア→現、某一部上場企業の情報システム部門、社内SE管理職として活躍中。システムエンジニア・社内SEとしての15年以上の体験・学びを通して有益なアドバイスが出来ます。

✔目次

システム開発の命運を握る要件定義驚きのインパクト
システム要件定義を失敗せず推進する４つの観点
システム開発の遅延理由50％は要件定義の失敗：事例と回避策まとめ

システム開発の命運を握る要件定義驚きのインパクト

IRA（情報処理推進機構）の調査結果によると、システム開発遅延のなんと50％の要件定義の問題と公表しています。以下の図を参照ください。

システム開発の上流工程のである要件定義の問題は、後続の開発工程に影響を及ぼします。

例えば、以下の様なトラブルを誘発します。

設計遅延
テスト遅延
稼働後トラブル

設計遅延

要件定義～基本設計で語られるべき詳細が詰められておらず、結局、設計時に業務や情報システム部門と要件・機能の確認が発生し、設計遅延が起こります。

設計書レビューは要件確認や要件追加の場ではないんだけどな..,
— にんにん⚙⚙ (@maaramaramara) April 28, 2020

テスト遅延

テスト遅延も一見、要件定義の不備と関係なく聞こえます。しかし、実際には大いに関係があります。

リリース直前のテストは一番プロジェクトの遅延のしわ寄せがそもそも来ます。

大抵の場合、リリース納期が変わりません。（業界の構造の密接に関係、関連記事【システムエンジニアてきつい!?新３K!?は誤解｜３つのポイントで解説】。記事中ほどでしわ寄せが下流に来る構造解説）。

つまり、上流工程の遅延リカバリはテストを短くするなどして調整が横行します。全体計画・リスク管理が甘かったこと等言えますが、要件定義フェーズでの計画・段取りの甘さに起因します。

稼働後トラブル

システム開発において、システムが上手くいかないことで障害が発生するよりも多いのが考慮漏れです。

業務とのフローの詰めが甘く、要件が上手く出せなかったせいでイレギュラーが発生した際にシステムが上手くハンドリングできず稼働後のトラブルをまねきます。

失敗事例の訴訟の例

勘定系システムの開発失敗を巡りスルガ銀行が日本IBMを訴えた裁判で、東京地方裁判所は3月29日に約74億円の賠償を日本IBMに命じる判決を下した。
出所：日経電子版

医療機器大手のテルモが物流管理システムの刷新に失敗。構築プロジェクトは中止に追い込まれた。テルモは開発委託先のアクセンチュアを相手取り、38億円の損害賠償を求めて提訴した。
出所：日経コンピューター

システム要件定義を失敗せず推進する４つの観点

・要件定義フェーズは、要件定義FIXだけが仕事ではない事を理解しよう
・とにかく紙に書く
・時間を切る
・要件定義は『早く』でも『簡単』でもなく『正しくやる』が重要

の４つを意識して要件定義を進める事が重要になります。１つづつ解説します。

要件定義フェーズは、要件定義FIXだけが仕事ではない事を理解しよう【最重要】

要件定義フェーズでは、システム化要件定義以外でも、プロジェクト全体の段取りをすることが非常に重要です。

要件定義フェーズの決める事として（要件だけではなく）以下も念頭に入れましょう。

・開発の成果物、体制概要
・運用の方針
・移行の方針

このような後工程の考慮がどこまで出来るかで、後工程での考慮漏れを著しく減らすことが出来ます。

後工程をしっかり考えるからこそ、不透明な部分があれば、その箇所だけでも切り出し実証検証（PoC )を行う等様々なリスク管理が可能になります。PoC= Proof of Conceptの意味は？それと、PoC死って何？も合わせてお勧めです。

要件定義フェーズでは、『要件を定義する』だけではない

後工程の段取りをするフェーズと捉えるだけで、
決めるべきことに違いが生まれる

この決めるべき事・観点を蓄積するのが重要
— CATO@ITエンジニア　ライフハック (@se_guru_k) May 11, 2020

要件はとにかく紙に書く！

要件定義の失敗は、話していない＝議論していないではありません。書いて記録に残していないのがほとんどです。

書いていない事は、ないと同じ！。とにかく紙に書き記録を残しましょう。

以前「」の記事でも書きましたが、引用すると

✅合わせてお勧め
「資料の体裁を整えろ！」と注意されないようにするコツ

時間を切って要件定義を進める

文章化の次にすべきことは、時間をきる事です。

何をいつまでに決めなければいけないか？を明確にしましょう。時間をきることにより切迫感が生まれ、それにより行動に移り易くなります。

ワタミグループ創業者の渡邉/美樹の【夢に日付を! 【新版】夢をかなえる手帳術】で日付を切る重要性を更に学ぶことが出来ます。

要件定義は『早く』でも『簡単』でもなく『正しくやる』が重要

要件定義の目的は、後工程の障害を減らすために努力をします。

上記でご説明したような、勘所を考慮しながら出来るだけ失敗しないように準備を進めます。

しかし、システム開発は、【バグ・障害なく、遅延なく、作る】のが最終目的ではありません。システム開発の目的は、役に立つ仕組みを構築し使う事です。

システム要件定義で、一番重要な事は、この『役に立つ仕組みを作る為に正しく進める事です』

例：業務要件が肥大化しなかなか作る要件が絞られないケース

この場合の間違った考え方。
【要件は実現可能な範囲で早くから絞っておく】になります。

あるべき考え方。
【業務・事業が達成したいゴールの為に、必ず必要な機能は何か？違う手段（開発以外で）で実現できないのか？を考え】ビジネスの実現性を追求します。

結果、必要な機能が見つかったとしても使われない仕組みを作ることは回避できます。

経験上、大抵の膨れ上がった要望は、本来は業務ゴール達成には必要がないが、いつのまにかあれもこれも言ってしまっているケースが9割くらい感覚的にあります。

アドバイスとしては、社内SEとして『その機能でどれくらい効果あるのか？』を自分にも業務ユーザーにもやさしく投げかけが重要です。

難しく思われがちな
システム要件の整理が意外な方法で簡単に

コツは、自宅の冷蔵庫・テレビを選ぶ感覚にあてがって考えてみる事

本当にその大きさいる？
その機能使わないよね！？
そのオプションでこの値段いる？

こんな感じの冷静な判断が必要
この感覚大事#社内SE #要件定義
— CATO@ITエンジニア　ライフハック (@se_guru_k) May 11, 2020