ベンダー側の要件定義メンバーがいなくなると失敗する

失敗プロジェクトの共通点

「要件定義のメンバーがいなくなったんですか？」
「なぜそれを知っているんですか！？」

プロジェクトが頓挫して、弊社に相談に来られると、いつも同じやりとりになります。デジャヴです。

A社では、受け入れテストで大量のバグが発生し、「ベンダーチェンジした方がいいですか？」と相談を受けました。

B社では、システムの動きがまったく業務を無視しており、「もう一度、要件定義からやり直した方がいいですか？」と相談を受けました。

C社では、相次ぐ仕様変更でベンダーから多額の追加費用を求められ、「どうベンダーと戦えばいいですか？」と相談を受けました。

この3社に共通するのは、「ベンダー側の要件定義メンバーがいなくなった」ということ。

私自身も、何度か苦い経験があります。

なぜ、ベンダー側の主力メンバーがいなくなると、プロジェクトはうまくいかなくなるのでしょうか？

そもそも、なぜ主力メンバーがいなくなるのでしょうか？

じゃあ、どう対策をとればいいのでしょうか？

それぞれ考えていきましょう。

なぜ、うまくいかなくなるのか？

システム開発において、どの工程が一番重要でしょうか？

言うまでもなく「要件定義」です。

ユーザー側もベンダー側も、最も気合いを入れて取り組みます。そのベンダー側のメンバーがいなくなると、次のような問題を引き起こします。

① 設計・開発工程のヌケモレ

要件定義を進めていると「詳細は今後詰めていきましょう」と先送りするケースは多々あります。要件定義書に書くには細かすぎるので、詳細設計書や運用設計書に書いていくということ。
しかし、このやり取りをしたメンバーがいなくなると、この部分がすっぽりと抜け落ちてしまいます。ユーザーが「あのとき約束しましたよね？」と伝えても、要件定義書に書かれていないため「追加要望です」と返されます。その瞬間、あの優しかったユーザーが豹変します。横で聞いていた私がトラウマを抱えるほどの修羅場になります。
 

② 解釈を誤る

要件定義書に書いていても、ベンダー側の新しいメンバーは解釈を誤ります。ユーザーから直接話を聞いていないからです。新しいメンバーは、開発要員です。業務要件よりもシステム仕様の理解を優先するため「なぜそうなっているのか？」を深く考えません。認識がズレたまま、書かれてあることだけを実装していきます。
そして、常識で考えたらわかるようなバグが見つかっても「仕様変更です」と返してきます。これが繰り返されると、ユーザーが全員、ダークサイドに落ちていきます。こうして修羅の国が誕生します。
 

③ 信頼関係の喪失

ユーザーは、業務を理解してくれるメンバーに信頼を寄せます。そのため、要件定義のメンバーには大きな信頼を寄せていました。ところが、突然の交代。これは非常に不信感を持ちます。新しいメンバーはシステムに詳しくても、業務を理解していません。話すたびにユーザーは失望していきます。
ベンダーが「素人質問」をしだすと、ユーザーは全員、遠い目になります。誰もまともに回答せず、違うことを考え始めます。そう、「ベンダーチェンジ」を⋯。
 

これらの問題は、受入テストでバグが多発したときに顕在化します。ユーザーの溜まっていた不満が一気に爆発し、対立が表面化します。

「このベンダーはクビだ！」「訴えてやる！」と泥沼化していきます。

いえ、泥沼化しました。。。（遠い目）

なぜ、いなくなったのか？

そもそも、ベンダーの主力メンバーがなぜ、いなくなったのでしょうか？

私もベンダーで10年間働いていたので、内側からも様々なパターンを見てきました。その中から代表的な4つを挙げます。

① 主力メンバーの力量不足

最もオーソドックスですが「最初から負け戦」となる致命的なパターン。最初は、人当たりがよくて、何でも聞いてくれるので、好印象です。安心して、いろいろ細かく説明します。ところが、何度も同じ質問をしてきたり、ドキュメントが間違いだらけだったり、徐々にボロが出てきます。ユーザーからの指摘が増え、対応できなくなり、最後は逃げ出します。人当たりが良かったのは、単に自信がなかったからです。
実はベンダー上層部は予想していました。「やっぱりダメだったか」と裏で交代タイミングを探っています。社内は人材不足のため、窓際族も出動させていたのです。
 

② プロパーがパートナーを切った

ベンダーの主力メンバーがプロパー（正社員）でないことは珍しくありません。特に大手ベンダーは獲得する案件の数に対して、社員の数が圧倒的に不足しています。そのため、営業と責任者以外、すべてパートナー（協力会社）メンバーというのは普通にあります。
しかし、パートナーには「アタリ・ハズレ」があります。優秀なパートナーだったら良いですが、まったく戦力にならないパートナーも大勢います。もし「ハズレ」を引いた場合、要件定義終了（契約終了）のタイミングでメンバーチェンジとなります。
一方で「アタリ」を引いても、ものすごく優秀なパートナーは扱いにくい側面があります。もともとの提案書の欠陥を指摘して「このスケジュールは無理」「この見積もりは甘すぎる」と正論を吐きまくり、ベンダー内部は揉めます。ユーザーに寄り添いすぎるパートナーが、ベンダーの敵とみなされ、要件定義後にクビを切られます。ちなみに、この正論は数ヶ月後に現実のものとなり、ベンダー上層部はしっぺ返しをくらうのですが。
つまり、主力メンバーがパートナーの場合、うまくいかなくなった途端に「トカゲの尻尾切り」が発動します。
 

③ ベンダー管理者の見通しの甘さ

「要件定義書はきちんと作った。後は詳細化すればいい」と現場を知らないベンダー管理者が壮大な勘違いをするパターン。扱いにくく高単価なパートナーを切って、安くて従順なパートナーに切り替えると、もう見事なまでにコケます。
そもそも、ベンダー管理者が力量不足だと、開発メンバーから信頼されていません。話が通じず、進捗プレッシャーだけかけてくるので、誰も報告なんかしません。そのため、ベンダー管理者は、状況をまったく把握できません。徐々に進捗報告が、実態からかけ離れて楽観的になっていくのです。
要件定義メンバーがいなくなったのは、「泥舟」から逃げ出したからです。ベンダー管理者が力量不足だと、メンバー離脱が相次ぎます。
 

④ メンタル不調による離脱

ユーザーからのプレッシャーに耐えきれず、心が病んで、フェードアウトするパターン。実は一番多いかもしれません。表面的には、そのメンバーのメンタルが弱かったり、実力不足だったりと言われます。
しかし、大抵はユーザー側にも問題があります。発注側の立場で横柄な態度をとったり、余計なプレッシャーをかけたり、レビューで重箱の隅をつついたり、人格を否定するような暴言をはいたり、「モンスターユーザー」が原因となっていることがあります。その人を前にすると萎縮し、発言できなくなり、さらにユーザーが調子に乗る。その成れの果てです。これが発生した場合は、ユーザー側は深刻な問題として受け止めなければなりません。
真っ先にある人の顔が浮かぶアナタ、その直感は正しいです。

どう対策すればいいのか？

ベンダー主力の離脱を直接防ぐことはできませんが、間接的に防いだり、影響を最小化したりすることはできます。

① ベンダー選定をしっかりやる

そもそもですが、そのベンダーを選んで契約したのは、ユーザー自身です。そこで「選定ミス」をしているから、離脱を招いているともいえます。
RFI/RFPでしっかりとベンダーを絞り、最後はプレゼンの面談で確認すること。ベンダーの実績を評価することで、プロジェクト管理の甘いベンダーは弾くことができます。
また、提案時のベンダー体制図も評価すること。プロジェクトマネージャーやプロジェクトリーダーの経歴を確認することで、力量不足やミスマッチを見抜けます。
ポイントは、このメンバーがプロパーなのかパートナーなのかを確認すること。パートナーの場合は、離脱するリスクが高くなるため、このタッグで成功させたプロジェクトがどれだけあるかを確認しましょう。
 

② 要件定義の終了判定をしっかりやる

ベンダーは要件定義書が不十分であっても、とにかく先に進めたがります。要員計画が狂うと赤字になるからです。「設計書で詳細化するので大丈夫です」と甘い言葉を囁きます。ユーザーもスケジュールを遅らせたくないので、次の契約書にサインしてしまいます。
でも、これはユーザーが悪いです。きちんと要件定義の「終了判定」をすること。その上で次に進まないと、後で揉めるだけです。この後、ベンダーの主力メンバーが交代したら、その暗黙知は闇に葬られます。
そのため、先送りにしたものは全て「申し送り事項」として、一覧化しましょう。そこで、漏れなく書かれてあることをレビューし、ようやく先に進むのです。
なお、要件定義の終了に「待った」をかけた場合、ベンダーには決まり文句があります。「要件定義は準委任契約なので成果物じゃない。もし延長するなら追加費用です」と。でも、ここは戦ってください。「そもそも要件を明確にできていないから契約不履行だ」と切り出し、交渉していきます。ユーザーが戦うべきタイミングは、受け入れテストではありません。この要件定義終了判定です。ここで戦わずに仲良く先送りにするから、みんなで仲良くタイタニック号に乗り込んでしまうのです。
本対策は、主力メンバーの離脱は防げませんが、離脱した時に影響を最小化できます。
 

③ 交代要員は事前に面談を申し入れる

ベンダー責任者は、神妙な面持ちでメンバー交代を相談しにきます。その時に「候補者と面談させてほしい」と伝えてください。本来は、ベンダーの体制に口を出す権利はありません。しかし、この時はベンダー側にも後ろめたい気持ちがあるため、断りにくい状況です。そこに「もう交代は避けたい、プロジェクトを成功させるため」とダメを押すことで、面談をセッティングしてくれる確率は高くなります。
面談時は、そのメンバーのプロフィールを確認します。同じような業界、システムの経験があるか、火消しで途中交代で立て直した経験があるか、このプロジェクトをどう立て直すのかを、質問していきます。もしここで不安を感じたら、正直に伝えます。「もうこの人は変えられない」と言われたら、さらに体制を強化する工夫を求めていきます。
 

④ ベンダーと信頼関係をつくる

プロジェクトには期限があります。多少辛くても、期限があるから頑張れます。その期限まで我慢できずに離脱してしまうのは、「人間関係」にも問題があるからです。もし、身内に「モンスターユーザー」がいるなら、プロジェクトから外しましょう。ベンダーに不当なストレスを与えないようにすることは重要です。
逆に「あのユーザーのために頑張りたい」と思ってもらえたら、過酷な状況であっても最後まで付き合ってくれるものです。
当たり前のことだと思われるかもしれませんが、失敗プロジェクトは例外なく、人間関係が崩壊しています。
対策は「ベンダーを好きになること」です。好きになれば、ネガティブ面ではなく、ポジティブ面に目が向きます。怒れるユーザーに「気持ちはわかりますが、彼らも頑張っていますし、良いところは褒めてあげましょうよ」と言うのは相当な勇気がいります。でも、プロジェクト成功後の打ち上げで「あの時は助かった、ありがとう！」と言ってもらえます。HEROになりませんか？

ベンダー離脱はユーザーの責任

ベンダー側のメンバー離脱は、ベンダーの責任です。

ですが、ベンダーの責任だけで片付けてしまっては、失敗から学べませんし、次も同じことを繰り返してしまいます。

離脱には、ユーザーにも非があります。

ユーザーがきちんとベンダーを選び、きちんと自社体制を組み、きちんと信頼関係を構築していれば、離脱は防げたはずです。

ぜひ、信頼したベンダーの方々とプロジェクトを最後まで乗り切り、一緒に達成感を味わってください！打ち上げのビールは美味すぎます。終電なのに、目覚めたら知らない駅に来てしまいます。

貴社のプロジェクトでは、ベンダー主力メンバーの離脱を防げていますか？