システム開発失敗の要因と成功への処方箋 - Strategy

特集◎経営課題としての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