基幹システムプロジェクトの成功要因を「3つ」に絞ってみた（中編：ベンダー選定編）

前回の続きです

前回のコラムでは、基幹システムプロジェクトで絶対に外せないポイントを「3つ」に絞りました。

① トップダウン
② ベンダー選定
③ 情シスPMO

前編では「①トップダウン」を整理しました。経営トップとプロジェクトが定期的につながる「仕組み」の話です。

（前回リンク： ① トップダウン編）

今回は「②ベンダー選定」です。

まずは、ある会社での事例から見ていきましょう。

社長が同席した、異例の初回相談

「タイムマシンがあるなら、あの時に戻ってやり直したい」

社長のこの一言が忘れられません。

炎上プロジェクトのご相談をいただくことがあります。時期は、たいてい決まっています。

「受け入れテスト」です。

そのご相談の初回に、社長が同席されていました。

これは、珍しいことです。

通常、ご相談をいただくのは情シスメンバーやプロジェクトメンバーです。部長が同席されることはあっても、社長が出てこられるケースは、めったにありません。

しかし、話を聞いていくうちに、その理由がわかってきました。

その基幹システムプロジェクトは、受け入れテスト期間が終了したことになっていました。ベンダーからは、検収書と請求書が送られてきています。

受け入れテストの予定期間は3ヶ月。しかし、すでに6ヶ月が経過していました。

「もうこれ以上は延長できません。お支払いください」

ベンダーの営業担当が、そう迫ってきます。

情シスは怒り心頭です。バグが多発しているからです。ユーザー部門も「全く使い物にならない」と門前払い。

そこで情シスは、「検収NG」として請求を突き返しました。

すると、ベンダー営業は意外にもあっさりと引き下がったそうです。

「わかりました。たしかに今の状況ではリリースできませんね。仕様変更が多すぎるからです。仕様変更には、しっかり対応させていただきます」

そして後日、仕様変更分の見積書を持参してきました。しかも、かなりの高額です。

それを聞いた社長が、キレました。

「払わない」

ベンダーにそう宣言したそうです。

すると今度は、ベンダーの幹部が出てきました。そして、強気に言い返されてしまったといいます。

「どうしたものか。裁判は面倒だ」

社長がそうおっしゃった瞬間、私はようやく腑に落ちました。

会社を揺るがす一大事件に発展しています。だから、社長が同席されていたのです。

これまで、多くの費用と時間と労力を費やしてきました。今さら白紙に戻す決断もできません。

その日は、ベンダーへの愚痴のオンパレード。

負の感情が爆発し、場が妙な盛り上がり方をしていきます。プロジェクトの状況を詳しく聞くどころではありません。

オンラインでのご相談だったこともあり、その日はいったん終了。後日あらためて訪問し、詳しくヒアリングさせていただくことになりました。

さて、この会社は、なぜここまでの事態に陥ってしまったのでしょうか？

目も当てられない障害管理表

後日、訪問してヒアリングを行いました。

障害管理表を見せていただくと、受け入れテストは初日からバグの嵐でした。

起票件数は、800件をゆうに超えています。

しかも、直近の1週間だけで20件も起票されており、収束する気配すらありません。

グラフにすれば、きれいな右肩上がりになるでしょう。このままなら1000件を超えるのは時間の問題だ、とのことでした。

情シスメンバーが振り返るには、「パッケージがイケていない」そうです。

カスタマイズが多く、そこで品質が大きく損なわれていました。

ベンダーに他社事例を聞いても、答えてくれません。担当者も業務理解が不足しており、説明がなかなか伝わりません。

ベンダー側のプロジェクトマネージャーは、技術者肌の方でした。業務要件を説明するユーザーからは「話が通じない」と嫌われています。

さらに、メンバーがコロコロ入れ替わります。

ユーザーに詰められたメンバーはいつの間にか姿を消し、新たなメンバーが補充される。そのたびに業務知識もシステム知識もリセットされ、立ち上がりに時間を要します。

悪循環です。

その結果、要件定義を行ったメンバーは全員いなくなってしまいました。業務を知るベンダーメンバーは、皆無という有様です。

デグレーションも多発します。1つ修正すれば、別のところに新たなバグが生まれる。ベンダーでありながら、そもそもの技術力と力量が不足しているのです。

そして、最大の火種が「仕様変更」でした。

ベンダーは仕様変更だと主張しています。しかし、ユーザーは納得できません。要件定義できちんと伝えているからです。

ところが、その証拠となるドキュメントが存在しません。存在していても、内容が粗すぎて肝心の記載がありません。

「システムの動きがおかしい」「伝えた仕様と違う」と指摘しても、

「ドキュメントに書かれていないことは仕様変更になります」

と無表情で突き返されます。

最後は「言った言わない」の応酬です。

そもそも当時の要件定義メンバーは全員入れ替わっており、経緯を知る人間がベンダー側に一人もいません。議事録にも、詳細は書かれていませんでした。

ドキュメントの記載漏れなのに、なぜ我々が責められるのか。

ユーザーは、まったく納得できない様子でした。

答え合わせは、たった2つの質問で終わった

一連の状況確認が終わった後、私はこうお願いしました。

「RFPを見せていただけますか？」

すると、一瞬、間が空きました。

その後、情シスメンバーが後ろめたそうに、こう答えます。

「実は、しっかり作っていなくて…」
「でも、きちんと相見積もりをとって、3社の中から決めているので…」

なるほど。

私は、続けて質問しました。

「では、RFIはありますか？」

「え？ それは何ですか？」

ここで、答え合わせが終わりました。

やはり「ベンダー選定ミス」なのです。

きちんとベンダーを選びきれていない。何となく選んでしまっただけなのです。

念のため、整理しておきます。

RFPとは「Request for Proposal」、提案依頼書のことです。自社の要求事項をまとめ、ベンダーに提案を依頼する文書です。

RFIとは「Request for Information」、情報提供依頼書のことです。ベンダーやパッケージの基本情報を質問リストとして送り、回答をもらうものです。

この2つが、ベンダー選定の両輪となります。

RFPを作っていないということは、自社要求が整理できていないということ。

すると、ベンダーやパッケージを選ぶ基準が曖昧になります。基準が曖昧なら、自社に適合しないベンダーが平然と残ります。

そして最後は、金額の安さで決めることになります。

その結果が、「安かろう悪かろう」です。

一方、RFIを作っていないということは、市場調査が不十分だということ。

3社と相見積もりをとったといいます。しかし、そもそもその3社は正しかったのでしょうか。

ベンダーの数は、星の数ほどあります。無数にある中から、その3社をどうやって選んだのでしょうか。

その3社以外に、もっと自社に合ったベンダーがあったかもしれません。むしろ、その可能性の方が高いのです。

もし、正しいベンダーを選べていたら

想像してみてください。

もし、自社にふさわしいベンダーが選ばれていたら、どうなっていたでしょうか。

自社にフィットしたパッケージであれば、カスタマイズは抑えられます。

同じ業界での導入実績が豊富であれば、業務知識も豊富です。他社事例も教えてくれます。その業界に明るいので、業務改革の相談にも乗ってくれるでしょう。

そもそもカスタマイズが減れば、バグ自体が発生しません。品質問題が激減します。

仕様変更の問題もなくなり、追加費用や延伸といった問題も起きません。

実績十分なプロジェクトマネージャーが担当すれば、リスクも大幅に減らせます。

つまり、適切なベンダーとパッケージを選ぶことで、予算・品質・スケジュールが守られるということです。

裏を返せば、こうなります。

不適切なベンダーを選んでしまうと、予算・品質・スケジュールの問題は、もはや回避できないのです。

「1億円以内に収めますから」

もう1つ、事例を挙げます。

ある企業から「要件定義終了後」のタイミングでご相談をいただきました。

パッケージベンダーとFIT&GAPを行い、ベンダーからカスタマイズ開発の見積もりを取得した直後です。

ベンダーの営業担当は、笑顔でこう言ったそうです。

「大丈夫ですよ。1億円以内に収めますから」

ユーザー側は、耳を疑いました。

「え？ 桁を間違えていませんか？ 1000万円以内の間違いでは？」

金額のギャップが大きすぎて、唖然としたそうです。

べらぼうに高すぎる。予算を遥かにオーバーしている。とてもではないが、払えません。

ベンダーが余計なカスタマイズを入れて、ぼったくろうとしているのではないか。

しかし、ベンダーはもう今さら変えられません。

このままでは、進むも地獄、引くも地獄。途方に暮れていました。

同席された部長は、こうおっしゃいました。

「ウチの情シスは優しすぎて、ベンダーに強く言い返せない。だから、しっかりと『ベンダー調整』ができる人材に入ってもらいたい」

このように要件定義後に止まってしまう事例。実はこれもよくあるケースです。

しかし、これはベンダー調整の問題ではありません。

やはり「ベンダー選定ミス」なのです。

「なぜ、そんなに高いベンダーを選んだのですか？」

そうお聞きすると、こう返ってきました。

「無名のベンダーだと不安なので、有名なベンダーを選びました」

選定時には「カスタマイズ費用は要件定義後にお見積りします」と説明されており、ここまで費用が膨らむとは想定していなかったそうです。

そして案の定、この会社もRFPもRFIも作っていませんでした。相見積もりで、3社から決めたとのこと。

実は、このベンダーは悪くない

誤解のないよう、順番に整理します。

RFPがないということは、自社要求が明確でないということです。それでは、ベンダー側もカスタマイズ費用を見積もることは不可能です。

要件定義後にしか見積もりが出てこないのは、当然のことなのです。これ自体は、ベンダーは悪くありません。

問題は、そこじゃない。

「なぜ、このベンダーを選んだのか」です。

このベンダーは、高いことで有名なベンダーなのです。

費用レンジの高いベンダーを選んだのですから、高い見積もりが出てくるのは当たり前です。

そもそも「大企業向けに価格設定しているベンダー」を中小企業が選んでしまうと、不幸が生まれます。

金銭感覚のギャップが、大きすぎるからです。

大企業向けのベンダーは、高品質でマネジメントもしっかりしている分、エンジニア単価も非常に高い。ちょっとしたカスタマイズを行うだけで、びっくりする見積もりが出てきます。

もちろん、立派なパッケージにも理由があります。

機能が洗練され、画面も見やすく、便利な機能も豊富。それが、高い理由でもあります。

しかし、中小企業にそこまでの機能は不要です。使いこなせず、持て余します。

その結果、未使用の機能が無数に存在し、それも含めた費用を払い続けることになります。

Too Muchなのです。

中小企業には、それに合ったパッケージがたくさん存在します。必要最低限の機能をもつパッケージとベンダーを選べば、費用は大幅に抑えられます。

また、RFIを作っていないということは、そのようなパッケージ調査が十分に行われていないということ。

無数にある選択肢が、最初から無かったことになってしまっているのです。

その結果、大量の広告費でCMを流し続けている、ネームバリューのあるパッケージが選ばれました。

最初の一手を、間違えているのです。

その後のベンダー調整で、どうにかなるレベルを超えています。

ベンダー選定を誤ると、その後どう頑張ろうが、取り返しはつきません。

なぜ、ベンダー選定ミスは繰り返されるのか

では、なぜ多くの企業で「ベンダー選定ミス」が生じるのでしょうか。

直接的な理由は、ハッキリしています。「ベンダー選定プロセス」が不十分だからです。

RFIとRFPを駆使して、きちんと選びきれていない。何となく選んで、失敗している。

しかし、問題の本質は別にあると私は考えています。

 

ベンダー選定を「軽視」しているからです。

 

「ベンダーはどこを選んでも大差ない」

心のどこかで、そう思っているのです。それよりも「要件定義以降をしっかり行うこと」の方が重要だと考えています。

要件定義、設計、システム開発、テスト、ユーザー教育。この一連の流れをやり切ること。ここが一番大事だ。

「ITプロジェクトは、ベンダーを決めてからが本番だ」

そう信じているのです。

ただし、表向きは違います。誰もが口を揃えて「ベンダー選定も大事」と言います。

だから、問題が見えなくなります。

しかし、軽視している人々は、必ず行動に現れます。

経営層は「早くベンダーを決めろ」と急かします。1ヶ月、遅くとも2ヶ月あればベンダーは決められるだろう、と言います。

そのプレッシャーを浴びた情シスは、ベンダー選定を急ぎます。

すると、時間をかけてRFPで要求整理をしている暇はありません。それなりに有名なベンダーに声をかければ大丈夫だろう、ぐらいに考えてしまいます。

その結果、選定プロセスから慎重さが消え、大胆になっていきます。本来のプロセスが、大幅に省略されてしまうのです。

情シスにとっても、その方が「進捗感」を出しやすいのです。

とりあえず有名なベンダーに声をかけ、社内関係者も呼んでプレゼンを開催する。3社ぐらいから見積もりをもらい、比較表にまとめる。

これで「それなりの選定プロセス」に見せられます。経営層のプレッシャーも、ひとまず回避できます。

ベンダーを決めた後は、ベンダーに頑張ってもらえばいい。我々も要件定義で頑張る。

だから、3社程度に声をかけて、相見積もりという「事務手続き」をさっさと終わらせよう。

そうして、時間をかけず、あっさりとベンダーが決まってしまうのです。

ここで、前編の補足をしておきます。

前編では、経営トップの関与、すなわちトップダウンこそが、プロジェクト成功の1つ目の条件だと述べました。

しかし、トップダウンとは「介入すること」であって、「急かすこと」ではありません。

ベンダー選定を急がせる指示は、トップダウンではなく、単なる圧力です。

ここを混同すると、1つ目の条件が、2つ目の条件を破壊してしまいます。

要件定義は、ベンダー選定より大事か

たしかに要件定義は大事です。設計もテストも大事です。そこに異論はありません。

しかし、「ベンダー選定よりも大事か」と問われれば、私は明確に「No」と答えます。

ユーザーがいくら要件定義やテストを頑張ろうが、ベンダーが力量不足であれば、まったく意味がないからです。

不適合なパッケージを修正しても、カスタマイズが膨大になるだけです。

いくら開発工数を削っても、単価が高すぎれば予算オーバーします。

いくら業務説明を丁寧に行っても、実績と経験が不足していれば、話は通じません。
 

勝負は、ベンダー選定の時点で決まっているのです。
 

逆に、力量も実績もあり、信頼できるベンダーさえ選んでいれば、ユーザー側が多少至らなくても、きちんとやってくれます。

しっかりしたベンダーは、最初の提案や計画から、すでにしっかりしています。

最初に立派な船に乗るか、泥舟に乗るか。

乗った後は、どれだけ必死に漕ごうが、結果はさほど変わりません。

正直に申し上げれば、ベンダー選定は面倒です。非常に労力がかかります。候補のベンダーを増やせば増やすほど、時間を奪われます。

その面倒な手間を省いて、楽をして決めている側面も、否定できないのではないでしょうか。

ベンダー選定ミスを防ぐ「6つのポイント」

では、どうすればよいのでしょうか。

ベンダー選定ミスをしないためのポイントを、6つに整理します。

① 十分な選定期間を確保する

一番大きな原因が、これです。選定スケジュールを、短く見積もりすぎています。

「ベンダーを選ぶだけだから、1〜2ヶ月もあれば余裕だろう」

ここが、すべての元凶です。

結論から言えば、基幹システムであれば4〜6ヶ月は見たほうがいいと考えます。

こう申し上げると、多くの方から「え？ さすがに時間をかけすぎでは？」という反応が返ってきます。

しかし、その感覚のまま進んだ先が、先に挙げた2つの事例なのです。

障害管理表が800件を超えた会社も、1億円の見積もりを突きつけられた会社も、特別に怠慢だったわけではありません。

「ベンダーを選ぶだけなのだから、そんなに時間はかからないだろう」

ただ、そう思っただけです。

その感覚が、RFPを省かせ、RFIという発想そのものを消し去りました。そして数年後、社長が「タイムマシンがあれば」とつぶやく事態を招いています。

1〜2ヶ月と4〜6ヶ月では、大違いです。

重要な自社の業務に、腰を据えて向き合うのか。余裕なく追い立てられるように、ベンダーへ声をかけるのか。

ここで、この先の数年にわたるプロジェクトの運命が決まります。

大規模プロジェクトこそ、「じっくり選定し、すばやく実行する」が唯一の正解です。

逆は、最悪です。

「すばやく選定し、じっくり実行する」。これは、地獄への一本道です。

すばやく選定した（つもりの）ベンダーとは、その後の数年間を、ゆっくりとしか実行できないプロジェクトにしてしまいます。仕様変更で揉め、追加費用で揉め、稼働時期が延びていく。

選定で楽をしてしまうと、後から取り戻せません。しかし、実行する速さは、入念に選定した分だけ後からついてきます。
 

② RFP作成（自社要求の整理）

自社の業務を整理し、それらをRFP（要求事項）としてまとめます。

事前のドキュメント状況や現行システム状況にもよりますが、ここだけで2〜3ヶ月かかります。

ここを省略したと聞くと、私はいつもこう思ってしまいます。

「御社の業務はそんなに薄っぺらいのですか？」

基幹システムは、本体業務の仕組み化です。その本体業務の現状がどうなっているのか。どんな課題を抱えているのか。将来、どうしていきたいのか。

考えることは山ほどあるはずです。

それなのに、自社の整理ができないまま、安易にベンダーに声をかけてしまう。ベンダー営業のペースに乗せられてしまう。自社の本体業務を軽視しているのは、自分たちではないでしょうか。

RFPの質を上げることで、ベンダーの提案の質が上がります。自社が本当に望む提案を、受けられるようになるのです。
 

③ RFI作成（市場調査）

では、RFPさえしっかり作ればよいのでしょうか。

そんなことはありません。

仮に3社にRFPを出すとして、その3社が自社に合わないベンダーだったらどうでしょうか。

もちろん失敗します。どんなに完璧なRFPを作ってもうまくいきません。

無数のベンダーの中から、その3社を選んだ根拠が不明確なら、それは単なる博打にすぎないのです。

それを防ぐための技術が、RFIです。

ベンダーおよびパッケージの基本情報を「質問リスト」として送り、回答をもらう。その基本情報を比較して、RFPを送るべき3社〜5社に絞り込むのです。

見るべきポイントは明確です。パッケージ機能、実績、概算費用、会社の基本情報です。そこから致命的な不足やギャップがあれば「脚切り」していきます。

たとえば、必須機能がなければ、論外です。同じ業界への導入実績がなければ、ノウハウは期待できません。基本料金の段階で、予算を大幅に超過していれば、選択肢にはなりえません。会社の財務状況が赤字だったり、従業員数が少なければ、実行リスクが極めて高くなります。

まずは、広く浅く候補ベンダーを20社以上リストアップする。その中からRFIを送る先を10社前後に絞る。そしてRFIの回答からRFPを送る先を3社〜5社に絞り込む。この慎重なプロセスが、その後のプロジェクトのリスクを大幅に減らしていくのです。
 

④ 提案・プレゼン評価

ベンダー評価は、見積金額だけではありません。

機能、実績、体制、スケジュール、進め方など、多くの要素を評価し、総合的に決めていく必要があります。

また、提案書だけでは評価できないものがあります。

それが「動く画面デモ」と「プロジェクトマネージャー」です。

特に、プロジェクトマネージャーは重要です。

自社と同業のプロジェクト経験、同じ企業規模、同じシステムの経験があるかないか。これが、プロジェクトに大きく影響します。

同じような経験がなければ、今回のプロジェクトでは「初心者」です。業務理解が十分にできず、トラブルが生じた際にも、解決の引き出しがありません。

プロジェクト経験は、絶対に軽視してはいけません。

経験こそが、先の見通しを立て、トラブルを事前に回避し、発生した際にも早急なリカバリを行う、すべての源になるからです。

それらを確認するのが、対面でのベンダープレゼンの場です。

プロジェクトマネージャー予定のメンバーに、過去の経歴を詳しく質問していきます。

そこで、経歴を盛っているのか、本当に修羅場をくぐってきたのか、信頼できるか、自社に合いそうか。五感を通して伝わってきます。
 

⑤ 契約締結

ベンダー選定プロセスは、選んで終わりではありません。

契約が無事に締結できるまでは、あくまで「内定」です。

他のベンダーすべてに断りを入れてしまった後で、厳しい契約条件を突きつけてくる場合もあります。

契約不適合期間が短すぎる。損害賠償金額の上限が低すぎる。検収条件が緩すぎる。

自社に不利な契約とならないよう、調整しなければなりません。

そこを超えて、初めてベンダーが確定します。
 

⑥ プロジェクト計画

ベンダー選定の最後の山場は、実は契約締結ではありません。

その後のプロジェクトの「キックオフ」を正しく迎えるまでは、終わったとは言えないのです。

ここが非常に重要なのですが、キックオフで用いる「プロジェクト計画書」は、自社で作るのではなく、ベンダーに作らせます。

なぜでしょうか。

ベンダープレゼン時の説明は、口約束に過ぎないからです。

その時に好印象だった営業の方は、姿すら見当たりません。

プロジェクト後半になって「提案の時にやると言ったじゃないか」と訴えても、「要件定義書に書かれていないことはできません」と断られます。

「提案書に書いてあるじゃないか」と反論しても、「その時とは前提が異なります。あくまでも提案時点での話です」と逃げられます。

では、どうするか。

ベンダーが作った提案書の内容を、プロジェクト計画書に盛り込んでもらうのです。

そのプロジェクト計画書をもとに、自社とベンダーの関係者が一堂に会し、読み合わせを行う。

それが、あるべき「キックオフ」の姿です。

プロジェクト計画書に書いてあれば、逃げられません。プロジェクトのバイブルだからです。

要件定義書に盛り込むことを正式に要求できますし、仮に漏れていたとしても、計画書の記載を拠り所に対応を要求できます。

このキックオフまでしっかり行われれば、ひとまず安心です。

後は、自社が少しミスをしようが、経験と実力のあるベンダーが助けてくれます。プロジェクト計画に従い、自動的に正しい方向へ進んでいきます。

上流が濁れば、下流はもっと濁る

要件定義 → 設計 → 製造 → テスト。

フェーズが進むにつれ、関わる人が増え、対応コストが指数関数的に増えていきます。

テストで製造ミスが発覚した場合は、製造 → テストをやり直しです。

設計ミスなら、設計 → 製造 → テストをやり直しです。

要件定義漏れなら、要件定義 → 設計 → 製造 → テストをやり直しです。

つまり、上流に遡れば遡るほど、修正コストは膨大になります。

では、これが「ベンダー選定ミス」だったら、どうなるのでしょうか。

もはや、考えたくもありません。要件定義以降のミスとは、比べ物にならないほど致命的です。

ベンダーは、一度決めてしまったら、なかなか変えられません。変えるにしても、お互いに相当のダメージを負います。

そのため、仮にベンダー選定ミスだと気づいても、誰も口に出しません。だから、表に出てこないのです。

どのみち、その時点で失敗プロジェクトです。

上流が濁れば、下流はもっと濁ります。

上流の失敗は、下流では取り返せません。取り返すためのコストとスケジュールが10倍、20倍となり、プロジェクトが破綻するからです。

その大元が、ベンダー選定です。

ここが不十分であれば、その後のプロジェクトは自作自演にすぎません。悪化した後にどう頑張っても、時すでに遅しです。

極論すれば、ベンダー選定は1ヶ月遅れてもいいのです。それは、その後の6ヶ月以上の遅れを未然に防いでいます。

RFPの作成に3ヶ月かかってもいいのです。それは、その後のプロジェクトの頓挫を、先回りして防いでいます。

もし経営層が「早く決めろ」と圧力をかけてきても、選定プロセスは省略してはいけないのです。

その後のプロジェクト炎上で、生きた心地のしない対応に追われるぐらいなら、最初の選定段階でちょっと苦労して、十分なスケジュールを確保するほうが100倍マシだと思うのは、私だけでしょうか。

プロジェクト成功の、2つ目の条件

プロジェクト成功の2つ目の条件は、「ベンダー選定」です。

ベンダーは無数に存在します。その中から、自社に最高にふさわしい1社を選び抜くこと。

会社の心臓部にあたる基幹システムをギャンブルにしてはいけません。

そのためには、4つです。

・しっかりと選定期間を確保すること
・RFIやRFPのプロセスを省略しないこと
・プレゼンでプロジェクトマネージャーをよく見ること
・契約締結まで油断せず、正しくキックオフを迎えること

正しいベンダーを選べば、プロジェクトは大きく成功へ近づきます。

冒頭の社長がおっしゃった「タイムマシンがあるなら戻りたい」という一言。

戻りたい先は、受け入れテストでも、要件定義でもありません。

ベンダーを決めた、あの日です。

今回はここまで。次回は、最後の「③情シスPMO」を整理していきます。

貴社の基幹システム刷新は、ベンダー選定をやり切ったと、胸を張って言えますでしょうか？