前回に引き続き，今回も私の失敗例と改善策を紹介します。オフショア開発に携わる同業者の方々の参考になれば幸いです。

失敗例3−進捗が見えなかったことによる失敗

　福井のJUDE開発部には，福井チームと上海チームのタスク看板（図1）があります。ToDo，Doing，Doneの三つの進捗状態に分けて，タスクを付箋に書いて貼り付けるのです。

図1●JUDE開発部にあるタスク看板 [画像のクリックで拡大表示]

　月曜日の朝に行われるイテレーション・ミーティングで，前の週のタスク進捗を確認し，今週のタスクを決定します。そして，毎日の朝会（図2）の前にタスクの進捗状況に応じて看板を更新し，朝会で自分の進捗を報告します。私は，看板にリストされている自分のタスクを更新すると同時に，Wiki（上海チームの進捗を管理している）の情報をもとに看板にある上海チームのタスクも更新します。

図2●朝会では，看板の前で，タスクの進捗報告や更新などを行う [画像のクリックで拡大表示]

◆失敗シーン

　月曜日に，ある複雑なタスクを上海チームに開発してもらうことになりました。このタスクによって，ある要素を図上に作成したり，削除したり，色を変えたりできるようになります。さらにこの要素の各属性を編集するGUIも必要です。

　私は，このタスクをWikiの進捗テーブルに以下のように書きました。“Estimate”は，このタスクを完了させるための見積もり日数で，“Need”は実際に必要とする開発日数を表します。まだ開発を始めていないので，経過日数を意味する“Passed”は0で，この先に5日間の開発が必要とします。Wikiに書き込んだ後，JUDE開発部のタスク看板のToDo欄に“要素の作成”の付箋を貼りました。

　そして，上海のリーダーに以下のように伝えて，タスク看板の“要素の作成”の付箋をDoing欄に移しました。

「ある要素をメンバーに作成してほしいのです。今週中に完成できると思います。毎日必ずWikiの進捗テーブルを更新して進捗を反映するよう，開発担当に伝えてください」

　その後，毎日帰宅前にWikiを見て，開発の必要日数が順調に減っているのを確認し，一安心していました。念のために，開発担当に「Wikiを見る限り，かなり順調なようですが，質問など本当にありませんか？」と聞きました。「はい，大丈夫です」と担当メンバーは答えました。

　翌日の朝会で「上海チームの開発は順調です。計画通りに今週中にこのタスクは終われると思います。金曜日の午後に，皆さんに動作を確認していただきたいので，デモを行います」と福井チームに報告しました。

　金曜日の朝がやってきました。Wikiの進捗テーブルは以下の状態になりました。

　午後のデモのため，とりあえずその要素を動かして，現状を見てみようと私は思いました。驚くことに，最も重要とされた要素の属性編集GUIはほぼ未完成で，図上での動作でも，要素の作成と色設定はできても，削除ができないといった状態でした。

「いまの状態なら，今日中に完成できないのではないですか？ なぜ，残り日数が0.5と言えるのですか？」と，上海の担当メンバーに尋ねました。

「まず，その要素を図上に表示できさえすれば，と思いました。したがって，簡単に実現できる要素の作成と色設定の実装を優先し，削除やGUIなどの難しい部分は後回しにすることにしました。図上に表示できていますから，順調と言えますよね！ 削除とGUIと残りの不具合を，今日中にすべて完成させたいと思います」
「残りの機能を実現するには，0.5じゃ無理ですよね！」 「確かに難しいです。でも，頑張ってみないとわからないでしょう？」

■教訓

• タスク全体の進捗状況は見えにくい（残タスク量のパーセンテージや，残り必要日数だけでは，実際の進捗具合はわかりにくいものです）
• タスク優先順位に対する認識が，中国人開発者と日本開発者との間に差がある（日本側の優先順位を明確にする必要があります）
• 残作業量は「当初の見積もり（Estimate）−過ぎた時間（Passed）」ではない（本当に残っている作業を完成させるのに必要な時間を記入すべきです）

■現在の実践

1. タスクを二日間で終われるサブタスクに分解しています。上記の要素作成を例とするならば，「図上における要素の作成」「図上における要素の削除」「図上における要素の色設定」「要素を編集するGUI」といった具合に分解します。
2. 各サブタスクに優先順位を付けて，上海チームの開発順序を管理します。「要素の属性を編集するGUI」「図上における要素の作成」「図上における要素の削除」は，必ず当イテレーションで上海チームに実現してほしいものですから，“S”レベルにします。実装の品質に注力するのであれば，「図上における要素の色設定」は次のイテレーションに実現してもらっても構わないので“C”にします。
3. 細かめに動作確認を行います。サブタスクは二日間で完成できるので，二日に一度完成したサブタスクを動かして動作を確認しています。週末の最終テストまでに少なくとも二度は上海チームに修正してもらう機会があるため，仕様の認識ズレと実装ミスを早いうちに発見できます。

　以上の実践ルールをもとに，現在では，Wikiの進捗テーブルを以下のように書いています。