エンジニアが「このお客さん、ダメだ」と心の中で思う瞬間とその対策

「しょうがねぇ、やってやるか！」のマインドがもたらすもの

たとえば、ベンダーの技術力に問題があるなら、発注者は、そのことによって納期遅延やコストオーバーが起き得ることを、あらかじめ社内に伝えて了承を得ておく必要があります。

技術の検討やメンバー教育に時間を取られるベンダーに変わって、テストケースのデータ作成やプロジェクト管理作業の一部を変わってあげる、などの直接的な協力が必要になるときもあります。

最初から、過剰な協力姿勢を示す必要はありません。
ベンダーに正式なクレームを入れでもいいでしょう。
「なんとしてでも間に合わせろ！」と、ベンダーに強く出ても構いません。
場合によっては、「ペナルティ」として費用を減額することだってアリです。

しかし、それはそれとして、システム開発プロジェクトが1つのチームであり、会社を幸せにする「本当に役に立つシステム」を作ることが目的である以上、「このままではプロジェクトが危険に陥る」と感じた時には、お互いにできることはなんだってやる必要があります。

野球で言えば、勝利のために監督が選手を怒鳴りつけたり、場合によっては野手がマウンドに立つようなことと同じです。

もちろん、お互いにすべてを開示しきれないリスクだってあります。発注者内の人事異動などは、その最たるものかもしれません。でも、具体的な氏名を明かさなければ、「毎年4月は異動の時期だから、主要メンバーが抜けることも想定して対策を考えておきましょう」という程度のことは言えるはずです。

そうした「リスクの共有」をせずに、「何かあっても、そっちの責任でしょ？」という態度をとる発注者とは、決してプロジェクトがうまくいかないことを、経験豊富なベンダーはよく知っています。

相手がそういう発注者だと知った途端、ベンダーは、表面には出さずとも、後ろ向きになります。急な要件追加や発注者側の責任でスケジュールが遅れるようなことがあったときにも何も協力してくれず、ただ追加費用と納期延長を求め、最悪の場合、途中で逃げ出してしまうこともあるわけです。

システム開発プロジェクトは、与えられた役割をまっとうするのではなく、お互いに迷惑を掛け合いながら成功するものです。そのためには、双方の抱えるリスクを、できる限りオープンにする必要があるのです。

『システムを「外注」するときに読む本』の第5章では、ベンダー選びをアタリ・ハズレの「バクチ」だと考えていた発注者のプロジェクトが一度危機に陥り、そこから、どんなベンダーなのか事前に把握しきれなかったとしても発注者サイドがリスクを管理できるようになるためのスキルと考え方を詳しく紹介しています。

ご自分の会社やプロジェクトにあてはめていただきながら、ぜひ、ご一読くだされば幸いです。