システム要件定義のよくある失敗を知っておいて未然に防ぎたい！
といった、疑問に答えます。
この記事では、システム開発で最も重要な要件定義。その要件定義でよく発生する失敗事例からとどのように失敗を回避できるのか？を紹介します。
本記事で解説する内容を理解することで、システム開発推進中にきおつけるべき勘所がわかります。後は、実戦でその勘所を上手く推進する現場力を身に着けることができればプロジェクトを成功に導く確率をぐっと上げることができます。
結論です。
失敗も成功もポイントは人とのコミニケーション・コンセンサスの取り方です。これにつきます。事例を交えながら、どんなコミニケーションの欠落があったか、どう防ぐことができるか解説します。
✔記事の信ぴょう性
SE＋社内SE歴15年以上。現在も一部上場企業で社内SE管理職。大規模システム開発及び、グローバル（15か国以上）へシステム導入・展開を推進。SE講師として100名弱の部下・生徒の育成に貢献。
システム開発の命運を握る要件定義。驚きのインパクト
IRA（情報処理推進機構）の調査結果によると、システム開発遅延のなんと50％の要件定義の問題と公表しています。以下の図を参照ください。
システム開発の上流工程のである要件定義の問題は、後続の開発工程に影響を及ぼします。
例えば、以下の様なトラブルを誘発します。
設計遅延
テスト遅延
稼働後トラブル
設計遅延
要件定義～基本設計で語られるべき詳細が詰められておらず、結局、設計時に業務や情報システム部門と要件・機能の確認が発生し、設計遅延が起こります。
設計書レビューは要件確認や要件追加の場ではないんだけどな..,
— にんにん⚙⚙ (@maaramaramara) April 28, 2020
テスト遅延
テスト遅延も一見、要件定義の不備と関係なく聞こえます。しかし、実際には大いに関係があります。
リリース直前のテストは一番プロジェクトの遅延のしわ寄せがそもそも来ます。
大抵の場合、リリース納期が変わりません。（業界の構造の密接に関係、関連記事【システムエンジニアてきつい!?新３K!?は誤解｜３つのポイントで解説】。記事、中ほどでしわ寄せが下流に来る構造解説しています）。
つまり、上流工程の遅延リカバリはテストを短くするなどして調整が横行します。全体計画・リスク管理が甘かったこと等言えますが、要件定義フェーズでの計画・段取りの甘さに起因します。
稼働後トラブル
システム開発において、システムが上手くいかないことで障害が発生するよりも多いのが考慮漏れです。
業務とのフローの詰めが甘く、要件が上手く出せなかったせいでイレギュラーが発生した際にシステムが上手くハンドリングできず稼働後のトラブルをまねきます。
システム開発失敗事例にみる要件定義の漏れ
２つのシステム開発の失敗事例を参考に要件定義の重要性を具体的に見ていきます。
取り上げる事例は、
スルガ銀行⇔IBMのパッケージソフトの導入の失敗事例
アクセンチュア⇔テルモの物流管理システムの失敗事例
スルガ銀行⇔IBMのパッケージソフトの導入の失敗事例
勘定系システムの開発失敗を巡りスルガ銀行が日本IBMを訴えた裁判で、東京地方裁判所は3月29日に約74億円の賠償を日本IBMに命じる判決を下した。
出所：日経電子版
内容としては、以下です。
スルガ銀の旧システムのリバースエンジニアリング［注2］を含めた3回の要件定義を経ても、要件を確定できなかった。今回の裁判でスルガ銀側から意見書を提出したAITコンサルティングの有賀貞一代表取締役は、「そもそも海外製パッケージであるCorebankは、邦銀の業務とかい離がありすぎた」と指摘する。Corebankの選定そのものに失敗の要因が潜んでいたという見方だ。
今回のケースはパッケージ導入ですが、この場合でも要件の漏れ・認識齟齬・合意が不足し、それが原因で訴訟にまで発展しているケースとなります。
アクセンチュア⇔テルモの物流管理システムの失敗事例
医療機器大手のテルモが物流管理システムの刷新に失敗。構築プロジェクトは中止に追い込まれた。テルモは開発委託先のアクセンチュアを相手取り、38億円の損害賠償を求めて提訴した。
出所：日経コンピューター
記事によると、単体テストまでは順調にすすみ、テストで横ぐし機能・連動する機能の設計漏れがあったとの指摘でした。
非常によく見かける構図です。ほとんどの場合、この原因は要件定義でクロスファンクショナルな機能のディスカッション検討が不十分でプロセス間の要件の漏れが原因です。
システム要件定義を失敗せず推進する5つの勘所
時として、要件定義の漏れは訴訟にまで至るいリスクがあります。要件定義を上手く進める勘所を以下で解説します。
ポイントは５つです。
どれも重要ですが一番重要な事は、責任者ときちんと合意することです。要件定義のクロージングの時点で紙で書かれた文章で責任者と合意することで、プロジェクトをピン止めし前に進めることができます。
・要件定義フェーズは、要件定義FIXだけが仕事ではない事を理解しよう
・とにかく紙に書く
・時間を切る
・要件定義は『早く 』 でも『簡単 』 でもなく『正しくやる 』 が重要
・要件定義は必ず責任者と書面で合意する
１つづつ解説します。
要件定義フェーズは、要件定義FIXだけが仕事ではない事を理解しよう
要件定義フェーズでは、システム化要件定義以外でも、プロジェクト全体の段取りをすることが非常に重要です。
要件定義フェーズの決める事として（要件だけではなく）以下も念頭に入れましょう。
・開発の成果物、体制概要
・運用の方針
・移行の方針
このような後工程の考慮がどこまで出来るかで、後工程での考慮漏れを著しく減らすことが出来ます。
後工程をしっかり考えるからこそ、不透明な部分があれば、その箇所だけでも切り出し実証検証（PoC )を行う等様々なリスク管理が可能になります。
POCをご存じない方は以下の記事もあわせておすすめです。
PoC= Proof of Conceptの意味は？それと、PoC死って何？
要件定義フェーズでは、『要件を定義する 』 だけではない
— CATO@ITエンジニア ライフハック (@it_compass_guru) May 11, 2020
後工程の段取りをするフェーズと捉えるだけで、
決めるべきことに違いが生まれる
この決めるべき事・観点を蓄積するのが重要
要件はとにかく紙に書く！
要件定義の失敗は、話していない＝議論していないではありません。書いて記録に残していないのがほとんどです。
書いていない事は、ないと同じ！。とにかく紙に書き記録を残しましょう。
あわせてお勧め
「資料の体裁を整えろ！」と注意されないようにするコツ
時間を切って要件定義を進める
文章化の次にすべきことは、時間をきる事です。
何をいつまでに決めなければいけないか？を明確にしましょう。時間をきることにより切迫感が生まれ、それにより行動に移り易くなります。
要件定義は無駄に長くすることが重要ではなく、質を高めることが重要です。時間を決めるのはそのまず初めにやるべきことです。
とはいっても、時間を切るためには
・必要なタスクを洗い出す
・段取りを決める
・マイルストーンに入らない予定を調整する
といった様々な行動があって初めて時間を切ることができます。
要件定義は『早く 』 でも『簡単 』 でもなく『正しくやる 』 が重要
要件定義の目的は、後工程の障害を減らすために努力をします。
上記でご説明したような、勘所を考慮しながら出来るだけ失敗しないように準備を進めます。
つまり、要件定義フェーズで、要件が十分でなければプロジェクトを遅らせるべきですし、必要な人がまきこめていない場合は、調整が必要です。
このフェーズでの課題をないがしろにしないで、プロジェクトの序盤でもあるこの時期に表だし・消込をするのが重要です。
課題の先送りは絶対にNGです。
要件定義は必ず責任者と書面で合意する
要件定義の最も重要な事は、責任者としっかりと合意することです。
仮に要件が不十分・仕様が間違っている等々様々な問題があったとしても、合意があればほとんどの場合、建設的な問題の解決に向かうことができます。
完璧なシステムはないので、合意した仕様でどう業務設計・業務変更するか？と言った議論に向かうことができます。
責任者との合意が無ければシステム開発者サイドの一方的な不手際として扱われることになります。
驚愕！システム開発の遅延理由50％は要件定義の失敗。回避策はこれまとめ
システム開発の失敗のほとんどが、『要件定義フェーズ 』 で発生します。上流の工程を如何にうまく実現するかで失敗の確率を減らすことが出来ます。
要件定義で失敗しない為に、
・要件定義フェーズは、要件定義FIXだけが仕事ではない事を理解しよう
・とにかく紙に書く
・時間を切る
・要件定義は『早く 』 でも『簡単 』 でもなく『正しくやる 』 が重要
・要件定義は必ず責任者と書面で合意する
を頭に入れ、要件定義を推進する必要があります。
システムに完璧は存在しません。あくまでも人間の業務を支援するツールです。ですので、きちんと合意することにより、システムとユーザーが歩み寄りシステムを活用しつつ業務改善につなげることができます。
社内SEとしては、システムに詳しいことも重要ですが、こういった誰とどのようにコミニケーションしコンセンサス・合意をとるかといったヒューマンスキルも非常に重要になります。
あわせておすすめ
