オフショア開発失敗事例１　進捗報告が上がってこない

プロジェクトの状況

2008年の前半、私はあるオフショア開発プロジェクトを立て直すためにベトナムのホーチミンに隔週で出張していました。
そのプロジェクトは約250画面のWebシステムで、オフショア側は70人の要員が参画していました。このプロジェクトでは、機能ごとにスケジュールを分けて、機能単位で納品してもらっていました。そのため、毎週納品があったのですが、遅延が頻繁に発生していました。何よりも拙かったのが、進捗に関する報告がオフショアからきちんと上がってこなかったことです。
それで業を煮やした幹部が、私に「プロジェクトを立て直してこい」と命令されて半常駐することになったのです。

最初、私は甘く考えていました。
70人いても共用Excelファイルに進捗報告を記入してもらえば、未記入者だけをせいぜい10人くらいフォローすれば済みます。最初は未記入者が多くても、2〜3日で記入率は改善するはずです。
後は、遅れている開発者をフォローして日本側に報告すればその日の仕事は終わりです。
午前中で十分片付くのではないかと思っていました。

到着初日の状況

ホーチミンに着いた私は、オフショア側のＰＭに対して「今朝時点の進捗を出してください」と依頼しました。
毎朝進捗をまとめて、午後までに日本に送るのがルールだったので急に無理なお願いをしたわけではありません。
するとＰＭは「午後まで時間をください」と答えました。
いつも遅れるのでこれも想定内です。私は午後まで待つことにしました。

午後になっても報告はありません。午後２時になって状況を聞きにＰＭのところに行きました。
私　「進捗報告書はできましたか？」
ＰＭ「まだです。もう少し待ってください。」
私　「できた分だけでもくれませんか？」
ＰＭ「全体的に見直しをしているので渡せません。」

結局、翌日の朝になっても進捗報告書はできませんでした。

とりあえず原因判明

翌日、ＰＭに事情を聴くことにしました。
進捗報告書を作るのに時間が掛かっている理由ですが、いくら聞いても「ちゃんとやっている。時間が掛かるのはしょうがない」の一点張りです。

いくら話してもらちがあかないので、何をやっているのかこの目で見るためにＰＭに張り付くことにしました。
ＰＭと担当者の会話を翻訳してもらうため、通訳も一緒です。

最初は私が張り付いていることを嫌がっているようでしたが、段々気にしなくなってきました。
そのＰＭは、とにかく担当者のところへ行って何かを話しています。ほとんど自分の机には戻りません。
何を話しているのか通訳に翻訳を頼むと「仕事とは関係ない話です」と言って翻訳してくれません。しばらく経って頼んでも同じ答えです。「10分も同じ相手と話していて全然仕事の話をしないわけないでしょ」と少し怒っていうと通訳は困った顔をしてうつむいてしまいました。
しょうがないので「仕事に関係ないなら早く済ませてくれ」と伝えてもらいました。

この調子で４、５人回ったところで気づきました。このＰＭは進捗を一人ひとりヒアリングしているのです。しかも世間話をしながらなので一人10分以上掛かっています。これでは１日で進捗報告が終わるはずがありません。
私　「進捗を一人ひとりヒアリングしているのですか？」
ＰＭ「そうです。」
私　「なぜ、担当者にExcelファイルを更新させないのですか？」
ＰＭ「担当者が大変だからです。」
私　「数字を４、５個入力するだけですよ。その数字をあなたに教えるために数えるから同じではないですか？」
ＰＭ「そんなことはありません。」

どこまでも話が噛み合わず、進捗管理を私が直接行うことにしました。

自分で管理を始めてみたものの

その日のうちに進捗報告書を共用サーバに格納し、全員を集めて入力方法を説明しました。
そして帰る前にその日の進捗を必ず入力するよう指示しました。

そして翌朝、どのくらいの入力してくれているか確認すると３割弱しか入っていません。６割は入るかなと思っていたのでがっかりしましたが、気を取り直して未入力者に直ぐに入力するよう指示しました。

もちろん、それで全員が入力してくれるはずがありません。
午後になっても入力していない担当者は一人ひとり聞いて回りました。また、状況を報告するのは遅れを回復することよりも大切だと訴えました。
実当時の私の会社では遅れていることよりも状況を把握していないことの方が怒られました。遅れていることを数値できっちり把握し、予定通りに対策が進んでいればあまり怒られませんでした。

結局、１週間で８割強の人が入力してくれるようになりました。10人位はヒアリングしなければなりませんでしたが、最後まで改善することができませんでした。

進捗管理でもうひとつ困ったのが、誤入力の多さでした。
作成済チェックリスト件数より消化件数の方が多かったり、開始日付の方が完了日付よりも後だったりと誰でも分かる間違えが沢山あります。チェックして正しい値を聞いて回るのに結構時間が掛かっていました。
これは、誤入力があるとセルを赤くするようにExcelファイルを修正することで解決しました。

対策が軌道にのるまで２週間近く掛かってしまい、日本からフォローが来るたびに胃がキリキリ痛くなる毎日を送っていました。

その後、進捗報告は毎日送れるようになりましたが、進捗の遅れは解決したわけではなかったので、結局半年近くホーチミンに通うことになってしまいました。

この経験から得た教訓

離れた場所にいると報告が上がってこないというのが一番困ります。
報告が上がってくれば、問題があってもその対策の是非などを議論することができますが、報告が上がってこなければ何もできません。このようにＰＭに言ってもどうにもならないときは、幹部を動かさなければなりません。
それには、直ぐ動いてくれる幹部と普段から信頼関係を築いておくことが大切です。

発注側としての反省は、進捗報告書や不良一覧表などの管理資料の様式と記載要領を渡しただけで、どう運用しようとしているのか確認しなかった点です。むしろ各種管理資料は、運用方法まで提示して、プロジェクトメンバーへの説明会開催までサポートすべきでした。この後のプロジェクトでは運用に関する手順書をまとめ、事前に渡すようにしました。
また、誤入力をチェックする仕組みは、最初からExcelファイルに入れるようにしました。