オフショア開発失敗事例２　指摘した不良が修正されない

並行して発生していた問題

実は「オフショア開発失敗事例１　進捗が報告されない」で書いたこととは別の問題が並行して起きていました。
それは日本側の受入テストで指摘した不良が一向に修正されないというものでした。
日本側で作成した不良一覧に、オフショア側で修正担当者と修正予定日を入れてくるのですが、予定日になっても一向に修正されてきません。一部の不良に関してなら分かるのですが、７割位の不良がその状態でした。
そのため、受入テストの要員が待機で無駄に時間を使うという事態が生じていました。

オフショア先の会社でＰＭに進捗資料の提出を依頼した後、不良の修正状況を直接担当者に聞いて回りました。
私　　「この不良はどうなっていますか？」
担当者「これは私の担当ではありません。」
私　　「え、でも不良一覧にはあなたの名前が載っていますよ。」
担当者「この不良一覧は知っていますが、私の名前が載っているのは初めて見ました。」

たまたま、この不良だけ連絡がうまくいかなかったのだろうと思い、次の担当者に聞くと、まったく同じ回答が帰ってきました。つぎの担当者も同じです。たまに指示を受けている担当者がいるのですが、７〜８割は不良の担当を知らない状態でした。

さすがに怒ってＰＭに説明を求めると
ＰＭ　「今はみんな忙しいので、仕事の進み具合をみながら割当てるつもりでした。」
私　　「では不良一覧には嘘を書いたんですか？」
ＰＭ　「嘘ではありません。その通りに進めていく予定ですから」
私　　「でも、予定日が過ぎても修正が終わっていませんよね。」
ＰＭ　「しょうがありません。忙しいですから。」

これはダメだと思いましたが、ここで怒っても何も解決しません。
とりあえず担当者に直接指示を出すことの了解をもらって自分で何とかすることにしました。（プライドが傷ついたのかＰＭは最初抵抗していましたが、問題の緊急性を説明して何とか納得してもらいました。）

対策は簡単で、不良一覧の担当者を決めて、担当者と修正予定日を決めたら、更新した不良一覧を日本側に送るだけです。後は、新たに発生した不良で同じことをするのと、修正状況をフォローしていくだけです。

対策したのに再び遅れが・・・

しばらくは順調でした。しかし５日目から再び遅れが出始めました。しかも徐々に拡大しています。
個々に事情を聞いて原因が何となく分かってきました。

そのプロジェクトでは、リリースを細かく分け、機能単位にリリースしてもらっていました。
担当者は、ある機能のリリースを終えると次の機能の開発に入りますが、同時にリリース済みの機能に不良があるとその修正も行わなければなりません。
不良修正の予定日を決めるときに、開発と並行して作業を行っていることを考慮していないため、無理なスケジュールを組んでしまっているようなのです。正確に言うと、一応考えてはいるようですが、開発がうまくいくことを前提としていました。
実際には、簡単なプログラムの開発でも不良が出たり、環境の問題でつまずいたりというのは当たり前に起きるので何も起きないというのはありえません。しかし彼らは、とても楽観的です。

本質的には人が足りないという問題なので、オフショア会社の幹部に人の追加割り当てをお願いしましたが、時間が掛かりそうですし、増員してから戦力になるまでも時間が掛かります。
そこで、重要度、緊急度の高い不良に絞って優先して対策し、残りは再度日本側と修正スケジュールを調整しましたが、日本側に大変な迷惑を掛けてしまいました。

この経験から得た教訓

日本人と比べてベトナム人の技術者は、先のことに対して楽観的に考える傾向があります。
この件以外にも仕事を頼むと大概出来ると答えるのですが、当日になると出来ていないということが多々あります。
進捗の予測精度が悪いチームや担当者に当たったときは、抱えている作業をよく聞いて判断する必要があると思いました。