「ITパートナーに任せれば解決する」は、もはや成立しない
itpjstudy
大規模ITプロジェクトでは、これまで「ITパートナーに任せる」という考え方が広く採用されてきました。
もちろん、外部の専門家を活用すること自体は合理的です。問題は、「何を外部に任せるのか」が曖昧なまま、課題の定義から解決策の検討、システム導入までを一社に委ねてしまうことです。
現在は、ITパートナー側のビジネスモデルそのものが変化しています。
「ITパートナーに任せれば解決する」が成立しなくなった
かつてのITパートナーは「課題解決型SI」だった
かつてのITパートナーには、ユーザ企業の業務を理解し、業務上の課題を一緒に考え、ITを使って解決する役割が期待されていました。
ユーザ企業側が必ずしもITに詳しくなくても、
「この業務がうまく回っていない」
「この情報をもっと有効に活用したい」
「この業務を効率化したい」
といった相談をすれば、ITパートナーが業務とITの両面から解決策を提案する。
このモデルでは、ITパートナーは単なる「システム開発会社」ではなく、ユーザ企業にとっての「外部の課題解決人材」でした。
現在のITパートナーは「オファリング型SI」へ変化している
現在のITパートナーは、特定の業務・製品・クラウド・サービス・方法論などを組み合わせた「オファリング」を持ち、それを標準化して提供する傾向が強くなっています。
これはITパートナー側にとって合理的な変化です。
オファリングを標準化すれば、
- 必要なスキルセットを定義できる
- 必要な人材を計画的に確保できる
- 教育・育成を標準化できる
- 提案・見積を効率化できる
- プロジェクトの収益性を管理しやすくなる
といったメリットがあります。
つまり、「オファリング型SI」は決して悪いものではありません。むしろ、人材不足の環境では非常に合理的なビジネスモデルです。
問題は、ユーザ企業が求めているものと、ITパートナーが提供しやすいものが一致しない場合があることです。
人材不足がこの変化を加速させている
課題解決型SIには、高度な人材が必要です。
業務を理解し、ITを理解し、顧客と対話し、正解が決まっていない問題に対して解決策を考える。
このような人材は、単なる技術スキルを持つ人材よりも希少です。
一方で、オファリング型SIでは、必要なスキルをある程度定義できます。
したがって、人材不足になればなるほど、ITパートナー側には「個別対応型」よりも「標準化・オファリング化」するインセンティブが働きます。
優秀な課題解決人材は重要顧客・重要案件に集中する
さらに、課題解決能力の高い人材は有限です。
ITパートナーから見れば、限られた優秀な人材を、
- 戦略的な顧客
- 大規模案件
- 高収益案件
- 長期的な関係を構築したい顧客
に集中させることは当然の経営判断です。
その結果、すべての顧客が同じレベルの課題解決人材を利用できるわけではありません。
ここに、ユーザ企業側が認識しておくべき重要な現実があります。
「大手ITパートナーだから、どの案件でも高度な課題解決人材が出てくる」とは限らない。
重要なのは会社名ではなく、実際に自社のプロジェクトに誰が参画するのかです。
ユーザ企業側にも「能力の空洞化」が起きている
ここまでを見ると、「ITパートナーの能力が低下したことが問題だ」と考えてしまいがちです。
しかし、実際にはユーザ企業側にも大きな変化があります。
ITアウトソーシングによってユーザ企業のIT人材が減少した
ユーザ企業は、ITコストの最適化や専門人材の活用を目的として、システム開発・運用などをITパートナーにアウトソーシングしてきました。
これは短期的には合理的な選択です。
しかし、長期的には、
「自社でITをどう活用するかを考える人材」
や、
「ITパートナーをどう使いこなすかを考える人材」
が減少する可能性があります。
特に問題となるのは、システムを「作る能力」ではなく、「何を作るべきかを判断する能力」まで外部化してしまうことです。
大規模プロジェクトの長期サイクルが過去の成功体験を残している
大規模な基幹システムは、一度導入すると10年、20年にわたって利用されることがあります。
そのため、IT業界やユーザ企業の人材が入れ替わっても、プロジェクトの考え方や調達モデルは引き継がれます。
過去に、
「このITパートナーに任せれば、こちらが細かく指示しなくてもやってくれた」
という成功体験があれば、次の世代でも同じ期待を持ちやすくなります。
しかし、10年、20年の間には、ITパートナーのビジネスモデルも、人材構成も、技術も大きく変わっています。
「昔のITパートナー像」と「現在のITパートナー」の間にギャップがある
ここで、双方の期待値にギャップが生まれます。
| ユーザ企業側の期待 | ITパートナー側の実態 |
| 業務課題を理解してほしい | RFP・要求事項に基づいて提案する |
| 最適な解決策を考えてほしい | 自社オファリングを組み合わせて提案する |
| 想定外の問題にも対応してほしい | 標準サービスの範囲内で対応する |
| 必要なら柔軟に人材を追加してほしい | スキル・契約・採算に基づき人材を配置する |
| プロジェクトを成功させてほしい | 契約したスコープを確実に実行する |
どちらが正しい、という話ではありません。
ビジネスモデルが変化しているにもかかわらず、期待値だけが過去のまま残っていることが問題なのです。
ユーザ企業とITパートナーの双方で課題解決能力が不足する
結果として、難しい状況が生まれます。
| 以前 | 現在 | |
| ユーザ企業 | 業務知識＋IT・プロジェクト能力 | 業務知識はあるがIT・PM能力が薄い |
| ITパートナー | IT知識＋業務課題解決能力 | IT実行能力はあるが課題解決人材が希少 |
| 両者の関係 | 一緒に課題を解く | 契約・役割分担に基づいて実行する |
つまり、かつて両者の間に存在していた「課題を定義し、解決する能力」そのものが空洞化しているのです。
RFPと相見積だけでは、最適なITパートナーを選べない
ユーザ企業は通常、RFPを作成し、複数のITパートナーから提案を受け、価格や提案内容を比較します。
これは調達プロセスとしては合理的です。しかし、現在の環境では、ここにも限界があります。
RFPは「解決すべき問題」が定義されていることを前提としている
RFPは、「何を実現したいのか」がある程度明確であることを前提としています。
しかし、本当に難しいプロジェクトでは、
- 何が本当の課題なのか
- 何を変えるべきなのか
- システムで解決すべきなのか
- 業務プロセスを変えるべきなのか
- 標準化すべきなのか
- 個別対応を残すべきなのか
といったこと自体を考えなければなりません。
つまり、
「何を作るか」より前に「何を解決するか」を決める必要がある。
ということです。
ITパートナーは自社オファリングを前提に提案しやすい
ITパートナーには、自社で販売したいオファリングと、そのオファリングを実行できる人材が存在します。
そのため、意識的であれ無意識的であれ、RFPを自社のオファリングに当てはめて解釈する傾向が生まれます。
これは、ITパートナーが悪意を持っているという話ではありません。
自社が持っている能力を使って提案するのが、ITパートナーにとって自然だからです。
相見積で比較しているのは「課題解決能力」とは限らない
相見積をすれば、複数社を比較できます。
しかし、比較できるのは基本的に「各社が提示した提案」です。
未知の問題に遭遇したとき、
「この人たちは、前提そのものを疑って解決策を考えられるだろうか？」
という能力までは、提案書だけでは判断しにくいものです。
「正しいものを作ったが、正しい問題を解いていない」というリスク
大規模ITプロジェクトで最も怖いのは、プロジェクトが「失敗」することだけではありません。
むしろ、
計画通りに進み、予定通りにシステムが完成したにもかかわらず、事業上の課題が解決されない。
というケースです。
これは「プロジェクト管理」の問題ではなく、課題設定の問題です。
プロジェクトの失敗は、実行フェーズより前に始まっている
プロジェクトの問題は、実行段階で突然発生するわけではありません。
提案、契約、体制設計の段階ですでに、その後のプロジェクトの成否が決まっている場合があります。
提案段階で生まれる「オファリングと課題のミスマッチ」
ユーザ企業が本当に必要としている解決策と、ITパートナーが提供しやすいオファリングが一致するとは限りません。このミスマッチを見抜けないまま契約すると、実行フェーズで問題になります。
実行段階で顕在化するスコープと能力のギャップ
プロジェクト開始後に、
「この要件は標準機能では対応できない」
「この業務については想定していなかった」
「この領域の専門人材がいない」
といった問題が発生することがあります。
提案時の「できます」と、実行時の「この体制ではできません」の間にギャップが生まれるのです。
「契約範囲外」が増えることで、プロジェクトが硬直化する
本来なら、
「どうすればこの問題を解決できるか？」
を議論すべきところが、
「それは契約範囲外です」
「追加費用になります」
「標準サービスには含まれません」
という議論に変わっていきます。
もちろん契約管理は重要です。
しかし、契約管理がプロジェクトの目的達成より前面に出てしまうと、プロジェクトは硬直化します。
想定外の課題に対応できる人材がいない
大規模プロジェクトでは、計画時点ですべての問題を予測することはできません。
だからこそ必要なのが、想定外の問題に対して、自ら考えて対応できる人材です。
プロジェクトマネジメントにおいて、この能力は極めて重要です。
ユーザ企業は「ITパートナー選び」から「課題解決能力の構成」へ発想を変える
では、ユーザ企業はどうすればよいのでしょうか。
重要なのは、「優秀なITパートナーを探す」という発想だけでは不十分だと認識することです。
これからは、
「このプロジェクトに必要な能力を、誰が、どのように担うのか」
を先に考える必要があります。
まず自社に必要な課題解決能力を定義する
プロジェクトに必要な能力を分解して考えます。
例えば、
- 業務課題の定義
- 業務改革・業務設計
- IT構想・アーキテクチャ設計
- プロジェクトマネジメント
- ベンダーマネジメント
- システム導入
- データ移行
- 利用定着・チェンジマネジメント
などです。
「どの会社に頼むか」より先に、「何の能力が必要か」を定義することが重要です。
何を自社に残し、何を外部化するかを決める
すべてを自社で内製する必要はありません。
一方で、課題の定義や重要な意思決定まで外部に委ねてしまうと、ユーザ企業としての主体性が失われます。
したがって、
自社に残す能力
と
外部から調達する能力
を明確に分ける必要があります。
一社にすべてを任せる「丸投げ型」から脱却する
一社にすべてを任せるモデルは、管理が容易というメリットがあります。
しかし、その会社のオファリングや人材構成が、プロジェクトの選択肢そのものになってしまうリスクがあります。
「一社に任せること」が問題なのではありません。
一社に任せることと、プロジェクト全体をその会社に依存することは別物です。
ITパートナーを「能力の供給者」として捉える
ITパートナーを「すべてを解決してくれる会社」と捉えるのではなく、
「必要な能力を提供してくれる会社」
と捉え直します。
この視点に立つと、複数のパートナーを組み合わせることにも合理性が生まれます。
ユーザ企業が課題解決能力を獲得する二つの方法
ユーザ企業が必要な能力を構築する方法は、大きく二つあります。
① 自社で能力を獲得する
② 外部の専門会社を組み合わせる
どちらか一方だけではなく、両者を組み合わせることも可能です。
方法① 外部登用によって自社の能力を強化する
一つ目は、外部から優秀な人材を登用し、ユーザ企業自身が課題解決能力を持つ方法です。
これは「すべてを内製する」という意味ではありません。
プロジェクトの中核となる、
- 課題設定
- 意思決定
- 全体構想
- PM
- ベンダーコントロール
などを自社に持つという考え方です。
自社に残すべき人材・能力とは何か
特に重要なのは、「外部に任せる仕事を定義できる能力」です。
外部に任せるためには、
「何を任せるのか」
「何を成果とするのか」
「その提案は本当に適切なのか」
「問題が起きたとき、どこまでが相手の責任なのか」
を判断できなければなりません。
これは、アウトソーシングすればするほど重要になる能力です。
方法② 複数の専門会社を組み合わせる
二つ目は、一社にすべてを任せるのではなく、専門性の異なる会社を組み合わせる方法です。
例えば、
| 役割 | 主なミッション |
| ユーザ企業 | 事業目的・意思決定・最終責任 |
| 業務専門コンサル | 業務課題・業務改革・業務設計 |
| PM/PMO専門会社 | 全体統括・進捗・課題・リスク・ベンダー管理 |
| システム導入会社 | システム設計・開発・導入・移行 |
という分担が考えられます。
業務専門コンサル、PM/PMO、システム導入会社の役割分担
このモデルのポイントは、「会社を分けること」そのものではありません。
それぞれの会社に異なる役割を持たせることで、一社のオファリングにプロジェクト全体が引っ張られることを防ぐことにあります。
例えば、業務専門コンサルが「何を変えるべきか」を考え、システム導入会社が「どう実装するか」を考える。
その間をPM/PMOが統合する。
このように役割を分けることで、専門性を活かしながら全体最適を目指すことができます。
「一社に任せない」ことによるメリットと難しさ
一方、複数会社を組み合わせると、新しい難しさも生まれます。
- 会社間の責任分界
- 情報共有
- 意思決定
- 課題の押し付け合い
- スケジュール調整
- 全体最適と個社最適の衝突
などです。
したがって、マルチベンダー化すれば自動的に成功するわけではありません。
むしろ、複数の専門会社を統合する「全体マネジメント能力」がより重要になります。
これまでの大規模ITプロジェクトでは、「優秀なITパートナーを選び、その会社に任せる」という考え方が一定の合理性を持っていました。
しかし、ITパートナーのオファリング化と人材不足、そしてユーザ企業側のIT人材の空洞化が進んだ現在、このモデルだけではプロジェクトを成功させることが難しくなっています。
重要なのは、ITパートナーに任せることそのものを否定することではありません。
むしろ、
「任せるためには、任せる側に能力が必要である」
ということです。
ユーザ企業は、自社にどのような課題解決能力を残すべきなのかを考えなければなりません。そのうえで、外部登用によって自社の能力を強化するのか、業務専門コンサル、PM/PMO、システム導入会社などを組み合わせるのかを選択する必要があります。
これからのプロジェクトマネジメントで重要になるのは、単にWBSを作り、進捗や課題を管理することだけではありません。
プロジェクトの目的を実現するために、必要な課題解決能力を誰が担うのかを設計すること。
そして、その能力をユーザ企業と複数の外部パートナーの組み合わせによって構成し、全体として機能させることです。
言い換えれば、これからのユーザ企業に求められるのは、「ITパートナーを選ぶ能力」から「課題解決エコシステムを設計する能力」への転換なのではないでしょうか。
大規模ITプロジェクトの成否を分けるのは、どのITパートナーを選んだかだけではありません。
「誰に何を任せ、誰が何を考え、誰が最後まで課題解決に責任を持つのか」。
その全体像をプロジェクト開始前に設計できることこそが、これからのユーザ企業におけるプロジェクトマネジメントの重要な役割になっていくと考えます。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
