「システム開発は専門家であるベンダに任せれば安心」と考えていませんか？
どれほど優秀なベンダに任せても、それだけでシステム導入が成功するとは限りません。導入目的の明確化や業務要件の決定、社内調整や意思決定など、発注側にしか果たせない重要な役割が存在するからです。
任せきりにすることで生じるリスクとは何か。そして、プロジェクトを成功に導くために発注側企業が備えるべき「プロジェクト管理力」とはどのようなものか。ベンダと確かな信頼関係を築き、一つのチームとして成果を出すためのポイントを解説します。

１．はじめに

「システムのことは分からないので、ベンダに任せています。」

システム導入プロジェクトに携わっていると、このような言葉を聞くことがあります。
確かに、システム開発の専門家はベンダです。設計、開発、テストなどを計画どおり進めるためには、ベンダ側のPM（Project Manager：プロジェクトマネージャ）の能力が非常に重要です。
しかし、優秀なベンダと優秀なPMに任せれば、システム導入は成功するのでしょうか。

私はそうは考えていません。
システム導入プロジェクトには、ベンダだけでは決められないことが数多くあります。

• 「会社として何を実現したいのか。」
• 「現在の業務をどう変えるのか。」
• 「A案とB案のどちらを選択するのか。」
• 「追加費用を負担してでも、この機能を実装するのか。」

こうした判断ができるのは、発注側企業です。

つまり、ベンダ側のプロジェクト管理力だけでなく、発注側にもプロジェクトを管理し、必要な意思決定を行う力が必要なのです。

２．ベンダと発注側では役割が違う

まず理解しておきたいのは、ベンダと発注側ではプロジェクトにおける役割が異なることです。
ベンダには、システムの専門家として、

• 実現方法を検討する
• 開発計画を立てる
• 品質を管理する
• 課題やリスクを報告する
• 専門的な選択肢を提示する

といった役割があります。

一方、発注側には、

• システム導入の目的を明確にする
• 業務要件を決める
• 社内の意見をまとめる
• 提示された選択肢を評価する
• 必要な意思決定をする

という役割があります。

ベンダがどれほど優秀でも、
「御社として、A案とB案のどちらにしますか。」
という問いに対する答えまで決めることはできません。
自社の業務をどうするかを決める責任は、発注側にあります。

図.連携で実現するシステム統合の成功

３．「専門家だから正しい」と考えない

発注側でよくあるのが、
「ベンダがそう言っているから大丈夫だろう。」
という考え方です。
もちろん、専門的な技術についてはベンダの知識を尊重する必要があります。
しかし、分からないことをそのままにしてはいけません。
例えばベンダから、
「標準機能では対応できないので追加開発が必要です。」
と言われたとします。

ここで、
「専門家が言うのだから仕方がない。」
と判断するのではなく、

• 「なぜ標準機能ではできないのですか。」
• 「業務を変えれば標準機能で対応できませんか。」
• 「追加開発した場合、費用や将来の保守にどのような影響がありますか。」

と確認することが重要です。

これはベンダを疑うという意味ではありません。
発注側が内容を理解した上で判断するための確認です。
分からない専門用語があれば聞けばよいのです。
システムの専門家でなくても、「なぜですか」と聞くことはできます。

４．希望があるなら最初に伝える

発注側にも、もう重要な一つ重要な責任があります。
それは、自社の希望や制約条件を早い段階で伝えることです。

プロジェクトが進んでから、
「実は、この帳票も必要です。」
「経営層から、この機能を追加してほしいと言われました。」
「この業務だけは今のやり方を変えられません。」

と言われることがあります。

発注側からすると、

「少し変更するだけ。」

と思うかもしれません。
しかし、設計が終わった後で要求を追加すれば、設計変更、プログラム修正、テストのやり直しなどが発生します。
場合によっては、他の機能やスケジュールにも影響します。
要件定義段階なら容易に対応できた要求が、開発後半では大きなコストになることもあります。
もちろん、プロジェクト途中で新しい要求が発生することはあります。
問題なのは、最初から分かっていた希望を伝えず、後から出すことです。

発注側は、
「まだ決まっていないから伝えない。」
ではなく、
「現時点では未決定だが、このような希望がある。」
という情報も早めに共有することが重要です。