発注者側のプロジェクトマネジャーの大切な仕事の1つに、何かを依頼した相手に対してきちんとフィードバックすることが挙げられる。特に悪い知らせのフィードバックこそなるべく早いタイミングで丁寧に行ったほうがよい。

 例えば、システム調達時に提案コンペを行った際に、コンペで勝ち残れなかったベンダーに対してはできるだけ早く「落選」を伝えるべきである。落選を通知するのは、誰でもあまり気が進まない仕事であろう。だから、しばしば落選の連絡を延ばし延ばしにしてしまいがちだ。

 しかし、落選したベンダーにとっては早い通知のほうがありがたい。仮に1週間、落選通知が遅れたとしよう。提案チームは結果が出るまで解散できず、メンバーがほかの仕事に移ることが難しいため、その1週間はただ待つだけになる。さらに受注に備えて仮押さえしているSEやプログラマーもリリースできない。もしほかの案件からリソースを回してほしいという依頼があっても、落選と決まるまでは動けないのである。

 もし落選したベンダーから「落選の理由を聞かせてほしい」という申し出があったならば、時間を取って面談して説明すべきである。それが商談における基本的なビジネスマナーであろう。ベンダーとしては「なぜ負けたのか」という理由を聞いて次の機会や別顧客の提案に生かしたいのである。コンペの敗者に対する提案活動への労いとして、フィードバックは丁寧に行ってもらいたい。もし落選通知をぞんざいにすれば、ベンダーは二度とその発注者と付き合いたいと思わなくなるかもしれない。

 ベンダーだけでなくエンドユーザーに対するフィードバックも重要である。マネジャーはエンドユーザーから「業務要求」を聞いて、それをRFP(提案依頼書)に記載してベンダーに提示する。それは要件定義の段階でもまれて、要求から要件へと変わる。要件として確定する段階で、エンドユーザーの最初の要求のいくつかは却下されたり、内容が大きく変化したりするだろう。却下や変化の理由について、要求を出したエンドユーザーにきちんとフィードバックを行うことを忘れてはならない。

 あるエンドユーザーはこう話す。「新システムに対する意見や要求を言ってくれとヒアリングを受けた。ところが、その後どうなったか全く話がなかった。そして、ある日突然テストしてくれと頼まれたのでやってみたら、自分が挙げた要求が全く採用されておらず頭にきた。それ以来システム開発のヒアリングは乗り気がしないので、多忙を理由に断ることが多い」。

 さらに聞いてみると「頭にきた理由は要求が採用されなかったからではない。却下なら却下でいいから、なぜ知らせてくれなかったのか。予算の都合や優先順位など開発側にも都合があることは分かっている。でも、なんのフィードバックもなく、テストしたら判明ではいくらなんでもひどい」と続いた。こうした声は少なくない。

 「バッドニューズこそ早く」はシステム構築の世界でも同じである。嫌な仕事こそ逆に気合を入れて立ち向かい、さっさと片付けようではないか。

永井 昭弘(ながい あきひろ)
イントリーグ代表取締役社長兼CEO
日本IBMの金融担当SEを経て、ベンチャー系ITコンサルのイントリーグに参画、96年社長に就任。多数のIT案件のコーディネーションおよびコンサルティング、RFP作成支援などを手掛ける。著書に「RFP&提案書完全マニュアル」「事例で学ぶRFP作成術 実践マニュアル」(共に日経BP社)がある。