システム開発プロジェクトの本当の失敗は①現状維持②開発遅延や障害。両方の原因と対策を解説

といった、疑問に答えます。本記事の内容で、
・システム開発の失敗の定義
・気を付けるべき観点
を理解できます。

本記事は以下の流れで解説していきます。

記事前半は、上図の流れでプロジェクト全体の失敗と打ち手の話をします。記事後半では、システム構築において多い要件定義の失敗に関して掘り下げ、原因と対策を解説していきます。

本記事は、以下の社内SE基礎講座の「要件FIX」の記事です。

IT初心者・社内SE向け｜システム開発の【基礎講座】関連記事一覧

システム開発、失敗の定義

システム開発における本当の失敗は、プロジェクトを開始し障害や遅延が発生してしまう事だけではありません。むしろ、ビジネス視点でシステム開発プロジェクトの失敗は、プロジェクトが開始されない、若しくは、プロジェクトをやり切ったとしてビジネスに役にも立たない事が本当の意味でシステム開発の失敗です。

プロジェクトが開始もされない場合は、現状維持で問題ないと思うかもしれません。しかし、実際には競業他社が切磋琢磨し日々改善していくビジネス概況の中で、現状維持は気づかずに自社のビジネスが衰退している状況です。したがって、システム開発プロジェクトにおける本当の失敗は、以下の２つです。

失敗事例

システム開発の失敗では、②にフォーカスしがちですが、②よりも①の問題の方がビジネスにとっては深刻です。これは、失敗の成功の反対は失敗と洗脳されてしまっている事にそもそもの原因があるかもしれません。成功の反対は何もしない、チャレンジしないことである点の理解が必要です。

①システム開発プロジェクトをチャレンジ・開始もせず現状維持

まず初めに①チャレンジしない事によるビジネスへの影響を説明します。

１．デジタル化の遅れ

事例：小売業者のデジタル化遅れ ある小売業者が、オンラインストアの導入を先延ばしにしました。その結果、競合他社がオンライン市場で成功を収める中、この業者はデジタルシフトに乗り遅れ、大きな市場シェアを失いました。ここでの失敗は、システム開発プロジェクトにチャレンジしなかったことです。

2. 革新の遅れによる競争力の低下

事例：伝統的な銀行業界
多くの伝統的な銀行が、フィンテック企業に対抗するためのデジタルトランスフォーメーションに慎重すぎた結果、革新が遅れました。フィンテック企業は迅速に市場に出て、便利なオンラインサービスを提供し、多くの顧客を獲得しました。競争力を失った銀行は、顧客流出と収益減少に苦しんでいます。

3. 顧客ニーズへの対応不足

事例：旅行代理店のオンライン対応遅れ
ある旅行代理店は、オンライン予約システムの導入に消極的でした。その結果、消費者はより便利なオンライン予約を提供する他のサービスに移行し、この代理店は多くの顧客を失いました。顧客ニーズに応えないことでビジネスチャンスを逃すことが、真の失敗です。

4. イノベーションの機会損失

事例：製造業の自動化導入遅れ
製造業において、自動化技術の導入を見送った企業があります。この結果、生産効率が低く、コスト競争力で劣る状態が続きました。自動化技術にチャレンジしなかったことが、イノベーションの機会を逃し、競争力を低下させました。

5. 業務効率の改善遅れ

事例：物流企業のIT導入遅れ
ある物流企業が、在庫管理システムの導入を後回しにしました。その結果、在庫管理の効率が悪く、顧客への納品遅延やコスト増加が発生しました。ここでも、システム開発プロジェクトに取り組まなかったことが、業務効率の改善を遅らせる原因となりました。

②システム開発プロジェクトの遅延や障害の失敗

次にシステム開発を遅延や障害発生した場合にはどのような影響があるのか解説します。

1. 売上損失

事例：アマゾンのシステムダウン 2013年、アマゾンは約40分間のシステムダウンを経験しました。その結果、約500万ドルの売上損失が生じました。これは、システムの停止が直ちに収益に影響を及ぼす典型例です。

2. 顧客信頼の損失

事例：ターゲットのデータ漏洩 2013年末、アメリカの大手小売業者ターゲットは、大規模なデータ漏洩事件に見舞われました。4000万人以上のクレジットカード情報が流出し、顧客の信頼が大きく揺らぎました。この結果、顧客の離反や売上の減少、そして巨額の賠償金が発生しました。

3. 法的および規制上の問題

事例：ブリティッシュ・エアウェイズのGDPR違反 2018年、ブリティッシュ・エアウェイズはシステムのセキュリティ不備により、50万件以上の顧客データが漏洩しました。この結果、EUのGDPR（一般データ保護規則）に基づき、1億8300万ポンド（約240億円）の罰金が科されました。これは、システムの失敗が法的制裁につながる典型例です。

4. 業務効率の低下

事例：航空会社の予約システムの不具合 ある航空会社で、予約システムの不具合が発生し、多くのフライトの遅延やキャンセルが相次ぎました。この結果、乗客からのクレームが殺到し、顧客サービス部門が対応に追われました。また、フライトの運行スケジュールが乱れたことで、業務全体の効率が低下しました。

5. 競争力の低下

事例：大手銀行のシステムアップグレード失敗 ある大手銀行が、競合他社に対抗するために新しいシステムを導入しようとしましたが、移行プロセスで多くの問題が発生しました。この結果、顧客が新しいシステムに不満を抱き、競合他社に流れてしまいました。このように、システムの失敗は市場での競争力を低下させることがあります。

システム開発のプロジェクトを失敗させない対策

システム開発における失敗には、プロジェクトの遅延や技術的な障害と、そもそもプロジェクトにチャレンジしないことの両方があります。これらの失敗を防ぐための対策を以下の２つの観点で整理して紹介します。

1. システム開発の遅延や障害の対策

1.1 プロジェクト管理の徹底

• 計画の明確化: プロジェクト開始前に詳細な計画を立て、スケジュールと予算を明確にします。
• 進捗管理ツールの利用: タスク管理ツールやプロジェクト管理ソフトウェアを利用して進捗を可視化し、問題が発生した場合には迅速に対応できるように準備が必要です。

1.2 リスク管理

• リスク評価と対策: プロジェクト開始時にリスクを評価し、事前に対策を講じておくことでリスクを低減できます。
• 定期的なレビュー: プロジェクトの進行中に定期的なレビューを行い、リスクが発生していないかを確認することで打ち手を事前に対策可能です。

1.3 コミュニケーションの強化

• 定期的なミーティング: チーム全体での定期的なミーティングを行い、情報共有と問題解決を図る。
• 透明性の確保: チームメンバー間での透明なコミュニケーションを促進し、問題が早期に報告される環境を整える。

1.4 テストと品質管理

• 継続的なテスト: 開発の各フェーズでテストを行い、問題が早期に発見されるように対策します。
• 品質管理プロセス: 厳格な品質管理プロセスを導入し、システムの品質を維持します。

2. システム開発にチャレンジしないことの対策

2.1 戦略的なビジョンの策定

• 市場分析とビジョン設定: 市場の動向を分析し、将来のビジネス目標を明確にする。これに基づいて必要なシステム開発を計画します。
• 経営陣のリーダーシップ: 経営陣がシステム開発の重要性を理解し、積極的に推進するリーダーシップを発揮しチャレンジを促します。

2.2 組織文化の改革

• イノベーションの奨励: 社内でのイノベーションを奨励し、新しい技術やプロジェクトに挑戦する文化を育成することでイノベーションを加速します。
• 失敗を許容する文化: チャレンジすることの重要性を認識し、失敗を恐れずに新しいプロジェクトに取り組む姿勢を持つ文化を形成します。

2.3 リソースの確保

• 予算と人材の確保: システム開発に必要な予算と人材を適切に確保し、プロジェクトが実現可能な状態を整えます。
• 教育とトレーニング: 社員に対して最新の技術やプロジェクト管理に関する教育・トレーニングを提供し人事育成を実施します。

2.4 パートナーシップと外部支援の活用

• 外部パートナーとの連携: 必要に応じて外部の専門家や企業と提携し、プロジェクトの成功を支援を活用します。
• 外部資源の活用: 内部リソースだけでなく、外部のリソースや技術を活用してシステム開発を推進を支援してもらいます

補足：システム開発遅延の原因の５０％は要件定義から

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

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

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

設計遅延

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

設計書レビューは要件確認や要件追加の場ではないんだけどな..,

— にんにん⚙⚙ (@maaramaramara) April 28, 2020

テスト遅延

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

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

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

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

稼働後トラブル

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

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

システム開発失敗事例にみる要件定義の漏れ

２つのシステム開発の失敗事例を参考に要件定義の重要性を具体的に見ていきます。

取り上げる事例は、

スルガ銀行⇔IBMのパッケージソフトの導入の失敗事例

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

出所：日経電子版

内容としては、以下です。

スルガ銀の旧システムのリバースエンジニアリング［注2］を含めた3回の要件定義を経ても、要件を確定できなかった。今回の裁判でスルガ銀側から意見書を提出したAITコンサルティングの有賀貞一代表取締役は、「そもそも海外製パッケージであるCorebankは、邦銀の業務とかい離がありすぎた」と指摘する。Corebankの選定そのものに失敗の要因が潜んでいたという見方だ。

今回のケースはパッケージ導入ですが、この場合でも要件の漏れ・認識齟齬・合意が不足し、それが原因で訴訟にまで発展しているケースとなります。

アクセンチュア⇔テルモの物流管理システムの失敗事例

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

出所：日経コンピューター

記事によると、単体テストまでは順調にすすみ、テストで横ぐし機能・連動する機能の設計漏れがあったとの指摘でした。

非常によく見かける構図です。ほとんどの場合、この原因は要件定義でクロスファンクショナルな機能のディスカッション検討が不十分でプロセス間の要件の漏れが原因です。

システム要件定義失敗の原因と対策

時として、要件定義の漏れは訴訟にまで至るいリスクがあります。要件定義を上手く進める勘所を以下で解説します。

要件定義の失敗原因

1. コミュニケーション不足

• 説明不足: ユーザーやステークホルダーのニーズや期待が明確に伝わっていない。
• フィードバックの欠如: 要件を確認するプロセスが不足しており、誤解が生じる。

2. 不十分な調査

• 現状分析不足: 現行の業務プロセスやシステムの理解が浅い。
• ユーザー調査不足: 実際のユーザーの声やニーズが正確に反映されていない。

3. 要件の曖昧さ

• 不明確な要件: 要件が曖昧で具体性に欠けるため、開発チームが正しく理解できない。
• 変更管理の不備: 要件が頻繁に変更されるが、それが適切に管理されていない。

4. 現実的でない要件

• 技術的制約の無視: 現実的な技術的制約を無視した要件が設定される。
• 予算やスケジュールの無視: 予算やスケジュールに見合わない過大な要件が設定される。

要件定義の対策

1. コミュニケーションの強化

• 定期的なミーティング: ユーザー、ステークホルダー、開発チームが定期的に集まり、要件についてディスカッションする場を設ける。
• フィードバックサイクル: 要件定義の各ステージでユーザーからのフィードバックを収集し、修正・改善を行う。

2. 十分な調査

• 現状分析: 現行システムや業務プロセスを詳細に分析し、現状の課題やニーズを明確にする。
• ユーザーインタビュー: 実際のユーザーやステークホルダーに対してインタビューを行い、具体的なニーズを把握する。

3. 要件の明確化

• SMART要件: 要件を具体的（Specific）、測定可能（Measurable）、達成可能（Achievable）、現実的（Realistic）、期限付き（Time-bound）に設定する。
• プロトタイピング: 初期段階でプロトタイプを作成し、ユーザーと共に要件を確認・修正する。

4. 現実的な要件設定

• 技術的評価: 要件定義の段階で技術的な実現可能性を評価し、技術的制約を考慮した要件設定を行う。
• 予算とスケジュールの調整: 予算やスケジュールに見合った要件を設定し、必要に応じて要件の優先順位をつける。

要件定義を上手く進める為のアドバイス

ポイントは５つです。
どれも重要ですが一番重要な事は、責任者ときちんと合意することです。要件定義のクロージングの時点で紙で書かれた文章で責任者と合意することで、プロジェクトをピン止めし前に進めることができます。

１つづつ解説します。

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

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

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

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

後工程をしっかり考えるからこそ、不透明な部分があれば、その箇所だけでも切り出し実証検証（PoC )を行う等様々なリスク管理が可能になります。


POCをご存じない方は以下の記事もあわせておすすめです。
PoC= Proof of Conceptの意味は？それと、PoC死って何？

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

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

この決めるべき事・観点を蓄積するのが重要

— CATO@ITエンジニア　ライフハック (@it_compass_guru) May 11, 2020

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

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

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

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

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

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

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

要件定義は無駄に長くすることが重要ではなく、質を高めることが重要です。時間を決めるのはそのまず初めにやるべきことです。

とはいっても、時間を切るためには
・必要なタスクを洗い出す
・段取りを決める
・マイルストーンに入らない予定を調整する
といった様々な行動があって初めて時間を切ることができます。

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

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

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

つまり、要件定義フェーズで、要件が十分でなければプロジェクトを遅らせるべきですし、必要な人がまきこめていない場合は、調整が必要です。

このフェーズでの課題をないがしろにしないで、プロジェクトの序盤でもあるこの時期に表だし・消込をするのが重要です。

課題の先送りは絶対にNGです。

要件定義は必ず責任者と書面で合意する

要件定義の最も重要な事は、責任者としっかりと合意することです。

仮に要件が不十分・仕様が間違っている等々様々な問題があったとしても、合意があればほとんどの場合、建設的な問題の解決に向かうことができます。

完璧なシステムはないので、合意した仕様でどう業務設計・業務変更するか？と言った議論に向かうことができます。

責任者との合意が無ければシステム開発者サイドの一方的な不手際として扱われることになります。

システム開発プロジェクトの本当の失敗は①現状維持②開発遅延や障害。両方の原因と対策を解説まとめ

システム開発の失敗に関して、開発の課題とチャレンジしない課題に分類し解説しました。最後にこれまで解説した内容のまとめです。

システム開発の失敗の定義

システム開発プロジェクトをチャレンジ・開始もせず現状維持

システム開発プロジェクトの遅延や障害の失敗