情報システム部門・IT部門が強くなるためのプラットフォーム

攻めの情シス研究所

情シスにノウハウを。
情シスが会社を強くします。

プロジェクト途中でのベンダーチェンジは有効なのか?

2022

8/02

プロジェクト途中でのベンダーチェンジは有効なのか?

プロジェクトがうまくいかない責任はベンダーに向かう

「ベンダーには一銭も払わない!それどころか訴えてやる!」

プロジェクトがうまくいかなくなると、ユーザーから物騒なセリフが飛び交います。

ここまで直接的な言葉までいかなくても、ベンダーがやり玉にあがる光景はさほど珍しくもないのではないでしょうか?

なぜなら、プロジェクトは難しいからです。

簡単なプロジェクトなんて、存在しません。

簡単なら一部署のタスクとしてやればいいだけです。

プロジェクトは必ずピンチが訪れます。その前提で、どう踏ん張るかがターニングポイントとなります。

はたして、プロジェクトがうまくいかないときに、途中でベンダーを切り替える「ベンダーチェンジ」は有効なのでしょうか?

ベンダーチェンジの影響

まず、プロジェクトの途中でベンダーの契約を打ち切るとどうなるのでしょうか。

今までプロジェクトに投下した「お金」と「時間」をドブに捨てることになります。

その途中までの成果物はありますが、引き継げるかどうかは微妙です。うまくいかなかったものなので、全面的に見直し対象となりそうです。

ユーザー部門では、また要件定義や基本設計からやり直しとなる「苦行」を強いられます。

プロジェクト全体としては、もう失敗が許されないプレッシャーが強くなります。

切羽詰まっているので、ベンダーの選定プロセスも呑気にやり直す場合ではありません。そのため、冷静さを欠き、引き継いでくれるベンダーを一本釣りしようとします。

失敗しないために多少お金をかけても…と従来の2倍、3倍と費やすことも仕方ないと考えだします。足元を見られてベンダーに吹っ掛けられても「次は失敗できないから」といくらでも払おうとしてしまいます。

金銭感覚がマヒしてしまい、もはや正しい判断はできません。

外から見たら明らかに「異常」な精神状態だとわかりますが、当事者は冷静ではいられません。もう心の中では、ベンダーと修復できない関係にまで発展しています。今さら引き返して、一緒に前を向くというイメージも持てません。

当事者は「背水の陣」で新しいベンダーに希望を見いだすしかない状況です。

プロジェクトがうまくいかない場合のテコ入れ策

では、このようにプロジェクトがうまく行っていないときに、どのような手が打てるのでしょうか?何かを変えていく必要はありますが、大きく2つ挙げてみます。

① ベンダーPMチェンジ

ベンダーチェンジしてしまうと、プロジェクト全体の「座組」が変わってしまいます。提案内容も契約も要件定義も、何もかもがリセットされてしまいます。

そのリセットを防ぎ、「チェンジコスト」を極力おさえる方法が、この「ベンダーPMチェンジ」です。

ベンダーの力量不足は「プロジェクトマネージャー(PM)」の力量不足によるところが大きい。このPMを変えるだけで、ベンダー全体の動きが大きく変わることも珍しくありません。

ベンダーの上層部に働きかけ、PM交代を調整していきます。

新しいPMを入れるでもよいですが、それよりも確実な方法があります。

既存メンバーで、ユーザーから評判の良いメンバーを上に引き上げるのです。ユーザーから評判が良いということは、今後もうまくコミュニケーションをとっていけます。プロジェクトの成功要因は何といってもコミュニケーションです。

たとえ、それがベンダーの協力会社メンバーであっても(正社員ではないからPMにはなれないと言われても)、調整します。実際に私は、何度も協力会社メンバーをPMに引き上げて、プロジェクトを最後まで完走しています。

② ユーザーチェンジ

そもそも、プロジェクトがうまくいっていないのはベンダーのせいなのでしょうか?

もしユーザー側に原因がある場合は、当然ながらベンダーをチェンジしても解決しません。それどころかチェンジするだけ時間とお金がかかり、さらに2回目のプロジェクトもうまくいかないでしょう。不幸を重ね塗りするだけです。

ユーザーが要求を出し、ベンダーがシステムで具現化する。

この普遍的な流れにおいて、上流は常にユーザー側にあります。要求の出し方がうまくなければ、システムもうまくいきません。要求の品質が悪ければ、システムの品質も悪くなります。

つまり、どんなにベンダーがすばらしくても、ユーザーがダメであれば、プロジェクトはうまくいきません。ベンダーチェンジしても失敗を繰り返すだけです。

困ったことに、ユーザーが力量不足のときほど、ベンダーのせいにしたがります。

「自分たちが正しい」という盲目的な前提があるため、原因が自分たちにあるとはみじんも考えません。ただ、うまくいかない原因を説明しないといけないため、ベンダーが「スケープゴート」となります。

私はコンサルタントとして客観的な立場でプロジェクトを支援していますが、もちろんベンダーが悪いこともあります。しかし、それ以上にユーザーが悪いことの方が多いと感じます。

「ユーザーチェンジ」は、ユーザー側のプロジェクトオーナーに相談し、判断してもらうことになります。実際にユーザーチェンジによって、プロジェクトが「V字回復」するケースは多くあります。

いろいろユーザー側の人間模様が絡むので、簡単ではありません。しかし、特定の社員に配慮しすぎて、社運がかかったプロジェクトを沈没させるわけにもいきません。大局的な判断が求められます。

ベンダーを信じるということ

今後、プロジェクトが困難な状況に陥ったとき、「ベンダーチェンジ」は確かに選択肢ではあるでしょう。しかし、それは冷静な判断ができないだけかもしれません。

基本的に、ベンダーチェンジは「Lose-Lose」です。誰も得しません。

振り出しに戻るのではなく、お金と時間を投入した分、大幅なマイナスからのスタートになります。そこをふまえて考えないといけません。

プロジェクトの状況を客観視し、「ベンダーPMチェンジ」や「ユーザーチェンジ」も選択肢に含めた上で、総合的に判断していく必要があります。

特に身内の問題は、ベンダーのせいにしても同じことを繰り返すだけです。そもそも、ベンダー選定は全社合意です。関係者全員で決めたことです。

それを簡単に覆せるほど、軽い決定だったのでしょうか?

基本的には、ベンダーを一度決めたらそのベンダーと心中してやり抜く覚悟が必要です。ベンダーとは、同じ目的を持つ同志であり、ワンチームです。この枠組みの中で、まずはあらゆる対策を打っていくべきではないでしょうか。

ベンダーを信じると報われます。これは私の経験則です。

貴社のIT部門・情報システム部門は、プロジェクトがうまくいかない時に、何が原因かを正しく把握していますでしょうか?そして、適切な対策を打っていますでしょうか?

関連コラム

御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか

情シスコンサルタント
田村 昇平

情シス(IT部門、情報システム部門)を支援するコンサルタント。

支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。

多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。

また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。

「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。

著書の詳細は、こちらをご覧ください。