特集◎経営課題としてのIT システム開発失敗の要因と成功への処方箋著者：松本渉 1 ．システム開発はなぜ失敗するのか ? が、ユーザーのニーズに応えきれず、結局使用されないシステムとなってしまったシステム開発の失敗事例が後を絶たない。実際弊社のクラ − C 社は業務の効率化を目指し、ERP を導入。しかしシスイアントから見聞きするシステム開発案件を想起しても、所テム構築途中及び構築後に様々な業務の非効率が判定の予算内で、当初の期限内に、本来の目的（業務効率向上、明。再度業務改革を行おうとしたが、当該システムに縛コントロール強化、コスト削減など）を十分に果たすシステムられ、十分な成果が挙げられなかった開発を実現した事例はむしろまれといってよい。具体的には以下のような失敗事例がある。 − D 社は 17 億の資金を投じて新システムを構築。しかし、業務の理解が不十分なままベンダーが DB の設計を行ったため、極度に複雑な DB 構造となり処理速度に • 予算超過 − A 社は開発予算を10 億としてシステム開発を発注。しか著しい問題が発生。結果として使用されないシステムとなったし製造工程でベンダー側が当初予定の 3 倍に及ぶ大幅な増員を行い、コスト拡大を要求された。同時期に重要 • 開発遅延な要件に関するベンダーとの理解の齟齬が判明し仕様 − E 社は開発期間を14 ヶ月と設定して業務システムの構築の変更・拡大を行ったこともあり、上記大幅増員に関するを開始。しかしベンダーの成果物に対する社内のレベンダー側の落ち度を特定できず、コスト交渉に失敗。ビュー、及び関係部門間の意見調整が大幅に遅れ、8 ヶ月結局 7億の予算オーバーとなってしまったの遅延につながった − F 社は大手 ITベンダーにシステム開発を発注したが、製 • 成果の未達 − B 社は社内ユーザーの声を集めてシステム構築を企画しクボックス化。表面上は順調な進捗を報告されていたたが、盛り込むべき要件があれもこれもと増幅し予算内が、試験工程直前にプロジェクト・マネジャー（PM）からでの開発が困難と判明。その後要件の絞込みのための大幅な遅延を突如告知された。ベンダーに依頼し PM を社内調整に難航し、所定の開発期間を大幅に超過。最終変更したがその後も同様の問題が発生。結局半年の開発的にはシステム部門主導で大幅な要件絞込みを行った遅延となったこの文書は旧ブーズ・アンド・カンパニーが PwCネットワークのメンバー、Strategy& になった 2014 年 3 月 31 日以前に発行されたものです。詳細は www.strategyand.pwc.com. でご確認ください。造後工程でベンダーの下請け業者の作業内容がブラッ Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 17 松本渉（まつもとわたる）（[email protected]）ブーズ・アンド・カンパニー東京オフィスのシニア・アソシエイト。小売、消費財等の各種産業において、海外戦略、ブランド戦略、業務改革、プロジェクトマネジメントサポート（システム開発含む）等多様な案件をリードしている。図表1 ：システム開発失敗の直接的要因（落とし穴）例要件定義設計 − システム開発目的と要件の乖離 − 優先順位が不明確なことによる要件の拡大 − 論理的に不明確で開発不能な設計文書の作成製造・試験 − 技術的に不可能な要件の発覚 − ベンダーの下請け業者などの進捗のブラックボックス化 − 重要な要件の定義漏れ − 成果物のバージョン管理の不徹底（『先祖がえり』の発生：古いバージョンをベースに作業が進む） − 他のプロジェクトとの要件の調整漏れ − ベンダー側の人員大幅増による PMのコントロール機能低下 − テスト計画の抜け漏れ − 論理的に不明確で開発不能な要件の設定 − ベンダー成果物に対するレビュー工数不足 − ベンダー成果物に対するレビュー工数不足 − 顧客企業とベンダー間の要件に関する意識齟齬 − ベンダーからのコスト増大依頼への交渉材料不足 − 経営陣及び関係部署による最終確認の段階での仕様変更依頼 − ベンダー側の人員大幅増によるPMのコントロール機能低下大企業のシステム開発担当者にとってこれらは周知の失敗要因。問題はもっと根深いところにあるのではないか？出所：ブーズ・アンド・カンパニー分析これらはいずれも社内ユーザーの声を集め、十分な予算をいるのである。問題はもっと根深いところにありそうである。確保し、大手といわれるベンダーを使用しながら失敗した事図表 2 は典型的なシステム開発の失敗要因を因果関係で例である。満を持して取り組んだはずのシステム開発がなぜ紡いだものである。各工程の随所に見られる失敗の直接的要失敗に終わってしまうのであろうか？因（落とし穴）は、実は、システム開発以前または川上工程での、ごく少数の要因に根源があることがわかる。システムベン 2 ．3 つの根本的失敗要因ダー側の要因が一つ、顧客企業側の問題が二つである。実際、前述のいずれの失敗事例においても、これらの根本的要因のシステム開発を失敗に導く落とし穴ともいうべき直接的要一つまたは複数があてはまり、結局それが後工程でのトラブ因は各工程の随所に存在する（図表1参照）。これらは既に多ルにつながり、システム開発を失敗に至らしめたのである。くの書籍でも指摘されていることであり、大企業のシステム開発担当者であれば周知の事実であろう。従って多くの企業 ①システムベンダーの「モラルハザード」のシステム開発責任者はこれらの落とし穴に陥らぬよう入念システム開発失敗の根本的な原因の一つは、システム開発な注意を払ってシステム開発に当たっているはずである。しという事業そのものの特性に起因して生じるシステムベンかしながら、気がついてみるとこれらの落とし穴にはまってダーの「モラルハザード」である。 18 Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 特集◎経営課題としてのIT 図表 2 ：システム開発失敗の根源的要因とそれがもたらすインパクト（典型例）根源的要因インパクトベンダーによる非現実的な安値/ 非現実的な短期開発提案ベンダーのモラルハザード経営陣・関係部署との開発目的のすりあわせ不足経営/ITの橋渡し機能の欠如/不足不適切な RFP作成/ベンダー選定社内体制（レビュー要員等）の未整備ベンダーによる開発不可能な要件の取り込みベンダーによる不当なコスト拡大要求要件の肥大化企業側のコスト交渉における混乱（交渉材料の整理が困難）要件に関するベンダーとの意識齟齬ベンダー成果物に対するレビュー不足予算超過成果の未達仕様の大幅変更要件定義漏れプロジェクトマネジメント機能の欠如/不足ベンダー成果物に対するレビュー遅延開発遅延出所：ブーズ・アンド・カンパニー分析システム開発事業の特性の第一は「情報の非対称性」であ「モラルハザード」に陥りがちである。例えば、交渉力の比較る。システム開発は専門的な知識や技術を活用して行われる的低い初期段階やコンペ段階では、非現実的な短納期や低ため、顧客企業側とベンダー側の情報レベルにどうしてもコストを提案し受注を獲得しておき、交渉力が高まる開発後ギャップが生じやすい（ベンダーが顧客企業よりも圧倒的に多工程で何らかの理由を付けてコスト拡大請求をする、というくの情報を抱えることになる）。しかも、そのギャップは開発インセンティブが働きがちなのである。多くの場合、後工程でが進めば進むほど拡大する。はシステム開発過程がブラックボックス化（「情報の非対称第二の特性は「代替不可能性」である。システム開発は顧客性」）しており、真のコスト拡大要因がベンダーの当初の甘い企業の個別の業務に関わる複雑な要求に応えた「特殊仕様」見積もりによるものなのか、企業側の落ち度によるものなのとなることが多い（特に日本企業においてこの傾向が顕著でか容易に判別しづらくなってしまっている。「今更他のベンある）。このため、開発途中でベンダーの切り替えができないダーにスイッチできない」という「代替不可能性」も顧客企業「代替不可能性」が生じてしまう。側を更に不利な立場に追いやる。当然、コスト交渉はベン上記二つの特性すなわち「情報の非対称性」と「代替不可能ダー側に有利に運びやすい。性」ゆえに、後工程でベンダーは顧客企業に対して圧倒的な交更にこの時点で企業側からの仕様変更依頼や企業側に渉力を持つに至ってしまう。このため、ベンダー側は一種の起因する要件漏れの発覚などが生じることも多く、複数の Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 19 コスト拡大要因が渾然一体となると、コスト交渉はベンダー例えば、ある重要な要件漏れが発覚した場合に、直ちに、当該側に圧倒的に有利となってしまう。多くのシステム開発が当初要件を放棄して開発を続けた場合と当該要件の追加を行っ予算を超過しがちなのは、このような要因によることが多い。た場合とで、コスト面はもちろん、本来のシステム開発の目的実際上記 A 社の事例は、まさにそのような失敗の典型事例にどのようなインパクトが出るのか、経営陣に分かる言葉でである。製造工程段階でのベンダー側の大幅増員は、そもそ説明しなければならない。システム開発責任者は、経営面でもベンダー側が生産性を甘く見積もっていたことに起因するのスキルが不足し経営陣に十分にそのインパクトを伝えきれ部分が大きかったが、既にシステム開発を進めてしまった顧客ず、問題を先送りにしてしまうことが多い。このような問題は企業側の立場の弱さを突かれ、ベンダー側の莫大なコスト拡後工程になればなるほど深刻度を増し、その結末は莫大な大要求に応じる結果となってしまったのである。出戻りコストとして跳ね返ってくるか、結局本来の目的を達成前述の F 社の事例もこのような事例の一つといえる。下請けできずに使用されないシステムとなってしまうケースが多い業者活用はしばしばトラブルの原因となることが多く、よほどのである。注意をしてかからないと開発のブラックボックス化を招いて前述の B 社の事例は、まさにそのような失敗事例の一つでしまう。ひとたびブラックボックス化が起きると、ベンダーのある。システム開発目的に関する経営陣との十分なすり合わコスト拡大要求に対する交渉材料がなくなってしまい、不利なせがなされなかったために、社内ユーザーとの意見調整に右交渉を強いられることになるのである。往左往し、結局システム部門主導で「システムありき」の開発を行ってしまった。これが「作っても使われないシステム」に ②経営 / 業務とITの橋渡しを行う機能の欠如または不足繋がってしまったのである。システム開発失敗のもう一つの重要な根本要因は、顧客企前述の C 社の失敗事例も同様の根源的要因に根ざしてい業において経営とITの橋渡しを行う機能が欠如している、またる。企画段階において経営の視点が欠如していたため、業務は不十分であることにある。専門性が高く、かつ経営へのイン効率向上という目的に照らしてシステムだけではなしえないパクトも大きいシステム開発においては、この機能が極めてこと（業務そのものを見直すべきところ）の見極めができず、重要であり、その欠如または不足は命取りとなりかねない。業務そのものの再構築という重要なステップが抜け落ちて例えば、システム開発の企画段階では、経営者がシステムしまった。また開発段階でそれが発覚しても経営とのコミュに期待する真の目的をきちんと汲み取り社内の関係部門とニケーションが不足し軌道修正に至らなかった。この結果、の意識あわせを行った上で、それらの経営上・業務上の要件「非効率な業務を強力にサポートするシステム」の完成というを ITの要件に落とし込み、社内のシステム部門やベンダーに皮肉な成果に至ってしまったのである。伝えることが極めて重要である。これが不十分になると、結局 D 社の事例も同様の要因が根源にある。専門性の高い DB 具体的な「もの」が出てくる試験工程に至って始めて経営陣や設計において、どのような業務知識が設計に必要かを見極社内関係部門から根本的な問題を指摘され、大幅な出戻りめ、ベンダーに過不足なくそれを伝えるには相当の IT・業務のを生じてしまうことになりかねない。双方の知識が必要である。D 社にはそのような人材が不足しまた、開発開始後の諸工程では、ベンダーの提案やシステムていたため、実際の業務とはかけ離れた使用不可能な DB 設上の問題点、リスクについて経営へのインパクトを早期に察知計に至ってしまったのである。して分かりやすく経営陣に伝えることが極めて重要である。 20 Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 特集◎経営課題としてのIT 図表 3 ： PMOのミッションの例企画要件定義 − システム開発の目的に関する経営陣、システム開発責任者、社内関係部署とのすり合わせ − 定義された要件と本来の開発目的との照合による、要件漏れや不要な要件の抽出 − 開発プロジェクトに必要なスキル、人員規模の見積もりと人員確保に向けた関係部署との調整 − 定義された要件の技術的実現性についてのベンダーの計画の検証 − システム開発の目的に沿ったベンダー選定基準の作成およびベンダー選定案の提示 − 現実的かつ合理的な開発規模、プロジェクト予算、スケジュールの設定、およびベンダーとすり合わせ設計・製造・試験 − レビュー工数の見積もりに基づくスケジュールの詳細化/アップデート − 問題が生じた場合のインパクトの見積もりと経営陣への報告 − 生じた根本原因の究明と打開策の提案 − レビュー工数の見積もりに基づくスケジュールの詳細化/アップデート − ベンダーからコスト拡大要請が生じた場合のコスト交渉 − 要件定義前後のベンダーのコスト見積もり差異について妥当性の検証 − 定義された要件の骨子を一般的用語に「翻訳」し経営陣および関係部署に伝達出所：ブーズ・アンド・カンパニー分析 ③プロジェクトマネジメント機能の欠如または不足品質リスクやレビュー遅延による開発遅延を防止する必要がシステム開発失敗のもう一つの重要な根本要因となりうるある。これらの能力を備えた人材が十分に配置される例は少のは、顧客企業側のプロジェクトマネジメント機能の欠如まなく、重要な失敗要因の一つとなっているのである。たは不足である。失敗している企業の例を見ると、プロジェク前述の E 社の事例では、これらのプロジェクトマネジメントトマネジメントは「ベンダーの仕事」と捉え、全てをベンダースキルを備えた人材がいないことが失敗の根源的要因と任せとしてしまっているケースが多い。しかしながら、当該機なった。同スキルの不足により、自社のプロジェクトメンバー能はベンダー、顧客企業双方に必要であり、両者のすりあわのレビュー工数を見誤り、結果として自社のレビュー遅延がせを通じてこそ、プロジェクトを期限内で完遂することがで開発遅延に繋がってしまったのである。きるのである。例えば、企画段階では、顧客企業側も開発規模や難易度を 3．成功への処方箋−三つの要件を備えたPMO の設置合理的に見積もった上で、社内のどのようなスキルの人材をどの程度プロジェクトに配置するかを決定し、必要なリソーシステム開発を成功に導くには、上記三つの根本的な失敗スを確保することがきわめて重要になる。多くの企業ではこ要因に対処することが不可欠である。具体的には、以下の三つれが行われない、もしくは不十分であるため、ベンダーの成の要件を備えた組織 / 機能（ PMO＝プロジェクトマネジメント果物に対するレビューに十分な工数が取れなくなり、ベンオフィス）をシステム開発プロジェクトの企画・立ち上げ段階ダーのモラルハザードを助長して開発リスクが増大するだけから組み込み、ベンダーとの交渉、ベンダーモニタリング、社でなく、開発遅延にもつながるケースが見られる。内関係部署の調整、経営陣とのコミュニケーション等々の任また、開発開始後の諸工程では、ベンダーのスケジュールの務に当たらせることが必要である（ PMO の具体的な任務は図現実性・合理性を客観的に吟味し、遅延リスクを事前に除去し表3 参照）。三つの要件はいずれも必須要件であり、いずれかたり、実際にリスクが顕在化した場合に問題の真因をいち早一つを欠いても成功は望めない。く掴んで損失を最小限に食い止めることが重要である。更に、自社のプロジェクトメンバーのレビュー工数などを合理的に PMO が備えるべき要件 1：ベンダーからの独立性・中立性見積もりスケジュールに組み込むことで、レビュー漏れによるシステムベンダーのモラルハザードを防止するには、特定 Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 21 のベンダーと利害関係・依存関係を持たず独立的・中立的なとは異なるベンダーを選択する結果となったケースが多い）。視点から開発ベンダーを選定し、ベンダーの開発進捗をモニまたベンダー側に必要な情報を整理して提供しないまま提タリングする機能が不可欠である。しばしば「 PMO は発注先案書を書かせ評価するケースも多く、そもそも客観的な評価のベンダーが設置しているので我々は必要ない」というコメが困難となっているケースも見受けられる。このような場合、ントが聞かれるが、発注先ベンダーの PMO だけでは中立性・従来の取引経験から情報量に優る既存ベンダーが過大評価独立性の観点で明らかに不十分であり、ベンダーのモラルハされるのはいうまでもない。ザードは防止できない。顧客企業は自らベンダーから独立しまた開発段階でも、「信頼ベース」でベンダーの客観的進捗た PMO を組成する必要があるのである。管理を怠り、開発がブラックボックス化してしまうケースが例えば、入札時点では幅広く候補ベンダーを洗い出し、特みられる。定の候補ベンダーの論理に流されることなく、各ベンダーの社内の人材を PMO に活用するのであれば、システム部門コスト・開発期間の見積もり根拠の客観性・合理性を公平に以外の人材の活用も視野に入れるなど、中立性を担保するた吟味する必要がある。入札時点ではベンダーと顧客企業側にめの工夫が必要となるのである。は情報ギャップが生じておらず（または顧客企業の方が情報優位である）、かつ「代替可能性」も顧客企業側に確保されて PMO が備えるべき要件 2：経営とITの両方の知見いるため、ここでしっかりとした見積もりの前提条件を双方 PMO が経営 / 業務とITの橋渡しを行うためには、経営とITので合意してしまうことがその後のベンダー側のモラルハザー両方の知見を備え、経営者や社内関係部署とシステム部門、ドを防止するのに極めて有効である。ベンダーのそれぞれに的確にコミュニケーションを行えるまた開発過程では、進捗度合いの判定をベンダー任せにせ人材の配属が不可欠である。ず、ベンダーと顧客企業側双方が理解しうる客観的な指標をシステム開発を成功に導く強力な PMO 機能を担保するた用いて開発の進捗をモニタリングし、情報ギャップを最小限めに、もっともハードルが高いのがこの要件である。社内はに抑えることがモラルハザードの防止につながる。おろか、社外においても、そのような人材、組織は決して多くなお、ここで更に注意しなければならないのは、社内のシスはないからである。テム部門の人材だけでは必ずしも中立性を担保できない場合例えば、前述の「ベンダーからの中立性」という要件を満たがあるということである。システム部門では、従来から付き合すためには、開発発注先以外のシステムベンダーを起用し、いのあるベンダーを過大評価し、かつ依存しがちだからだ。他のベンダーを中立的に選択させ、その進捗をモニタリングすなわち、ベンダー選定の段階において、ベンダーのコスさせれば事足りるかもしれない。しかしながらシステムベント・開発期間の見積もりの客観性・合理性よりも従来の付きダーの多くは、「経営とITの両方に知見のある人材」が不足合いやコミュニケーションのし易さなどに偏った評価を行い、し、経営者とのコミュニケーションが不十分となることが多ベンダー選択を誤ることが多い（ブーズ・アンド・カンパニーい。特に経営者がシステムに期待する真の目的を ITの専門的がサポートしたシステム開発案件では、システム開発の目的な要件に落とし込む能力や、システム上生じた問題点やリスを十分に整理しベンダーに必要な要件をインプットした上クを経営へのインパクトに翻訳して分かりやすく伝える能力で、コスト・開発期間の見積もり根拠の詳細を入手してそのが不足しているために結局本来の開発目的から外れたシス客観性・合理性を徹底的に吟味したところ、従来のベンダーテム開発に至ってしまうケースが見られる。 22 Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 特集◎経営課題としてのIT 結局、社外からそのような希少な人材を探し出して採用するか、社内において中長期的な視野を持ってそのような人材を育成するしかあるまい。しかし、それまでの間システム開発その根本原因を究明する能力（「『なぜ』を 5 回繰り返せる」知的タフネス） − 生じた問題に対する対処方法について考えられるオプを凍結させるわけにはいかないし、そもそも社内の誰もが持ションを網羅的に洗い出し、それぞれのインパクトを、ち合わせていない能力を育成するのは難しい。定量・定性の両面から客観的に評価し最善の解決策をこのような場合には、特定の開発ベンダーと利害関係がな導き出す能力く、経営とITの知見に長けた外部コンサルタントを活用し、一旦 PMO 機能を担わせ、徐々に社内に知識移転を図ることも有効な手段と考えられる。 • コミュニケーション能力 − 社内の合意形成に向け最大限の効果を得るために、適切なタイミングで、適切な人物にアプローチし、適切な PMOが備えるべき要件 3：高いプロジェクトマネジメント能力方法（説得 / 交渉 / 報告 / 指示）で情報を伝達できる能力プロジェクトを期限内で完遂するためには非常に高いレベ − ベンダーと利害が一致する論点と対立する論点を峻別ルのプロジェクトマネジメント能力が必要である。特に注意し、それぞれに適した交渉方法とテクニックを使い分すべきなのは、ここで必要な能力は、一般にシステム開発にける能力おいて挙げられる狭義のプロジェクトマネジメント力（スケジュール設計/ 管理力、調整力など）よりも広い範囲をカバーこれらの能力も「経営とITの両方の知見」ほどではないが、する能力であるという点である。それはあらゆるタイプの難易容易に見出したり育成したりしうる能力ではなく、ロールモ度の高いプロジェクト（システム開発以外のプロジェクトをデルとなりうる人材を核にして実践を通じて中長期的に知識含む）を推進していくために共通して必要となる広範囲かつ移転を図ることが必要である。このような観点から、一時的高度なマネジメント力であり、例えば以下のようなスキルがに社外の人材や組織を活用して PMO に当たらせつつ、徐々あげられる。に知識移転を図っていくことも有効であろう。 • 論理力 − システム開発において本来達成すべき経営目的（業務効率化、コスト削減、コントロール強化、等々）から、ベンダー選定のクライテリア、業務 / システム要件などを論理的に過不足なくブレイクダウンし、プライオリティ付けできる能力 − 各工程において達成すべき成果物から、必要なタスク、人材、工数を論理的に過不足なく抽出する能力 • 問題解決力 − 生じた問題の表層部の「火消し」に奔走するのではなく、 Booz & Company M a n a g e m e n t J o u r n a l Vo l . 1 3 2010 Spring 23