第2回オフショア開発における私の失敗例(1)

2008.05.14

周翼

　2003年にJUDE（チェンジビジョンの設計支援ツール）開発部に配属されてから，すでに5年が過ぎました。その間，自らJUDEの設計・実装・テストに従事すると同時に，福井のJUDE開発チーム（以下，福井チームと呼びます）と上海のJUDE開発チーム（以下，上海チーム）の間の橋渡し役も勤めてきました。IT業界では，このような役割をブリッジSEと呼びますが，JUDE開発部ではコミュニケータ（communicator）と呼んでいます。

　JUDEコミュニケータとしては，(1)福井チームが決定したストーリー（JUDE開発チームが採用しているXP方法論の手法で，シンプルなテキストや画像によって記述される機能要求）やタスク，開発方針などを上海チームに伝達する，(2)上海チームの質問と意見を福井チームに伝える，(3)それらの質問や意見に関する福井チームの回答を上海チームに説明する，(4)上海チームの進捗（しんちょく）を把握・管理する──などの責務があります。

　JUDE開発チームに参加する前に，私はプログラマとしてオフショア開発に参加したことがあります。しかし，コミュニケータは経験したことがなかったので，最初の数年間はとまどいと試行錯誤の連続でした。自分の開発に集中しすぎて上海チームへの回答を怠ったり，上海チームの進捗を明確に福井チームに伝えられなかったりして，両チームに迷惑をかけたことも多々あります。

　振り返れば，コミュニケータになった当初，もっとも知りたかったのは，他のブリッジSEの経験と教訓でした。そこで今回（と次回），私は，自分の失敗例とその改善としての実践を公開し，オフショア開発に従事している同業者やオフショア開発を検討している方々の参考になればと考えました。さらに，これらの改善に対する皆さんの意見・批判・アドバイスをお待ちしています。

失敗例1－オフショア管理と開発とのアンバランス

　私は，大学でソフトウエア専攻に在籍していた際，動作するソースコードを書くスキルで，高い点数を得た体験がありました。大学を卒業して，日本の開発を下請けするソフトウエア会社でプログラマとして勤めているうちに，ITの開発者は，動作するソースコードをどれだけ書くかによって評価されると誤認し始めました。

　もともと私はコーディングが好きで，周囲に邪魔されずに，コーディングに集中できる時間を楽しんでいました。そして，評価基準に対する誤認とコーディングへの執着を持ったまま，私はコミュニケータとしてJUDE開発部の一員になりました。

　1999年にJUDEの梅版を公開してから2003年にJUDE開発部に私が配属されるまで，JUDE開発部の先輩たちは，XPというアジャイル方法論を実践しながら，様々な新機能をJUDEに追加しました。私にとっては，Golfフレームワーク（弊社が開発したMVC型の汎用GUIフレームワーク）の勉強やJUDEの各機能の分析，XPによる各プラクティスの実践など，すべてが楽しい毎日でした。一日も早く，自分が開発した機能がJUDEに取り込まれるように，そして先輩たちに評価されるように，私は大量にコーディングすることを決意しました。

　JUDE開発では一週間を1回の開発イテレーションとし，月曜日の朝に行われるイテレーション会議で一週間の個人タスクを決めます。個人の開発経験が考慮され，タスクが振られることもありますが，原則として開発者は，ToDoリスト（未開発のタスクリスト）から好きなタスクを選択できます（上海チームにもいくつかのタスクを出して，優先度の高いタスク以外は，自分のやりたいタスクを選択してもらっています）。

　その当時私は，以下のようなルールを自分に課して，タスクを選択しました。その結果を出すことで，自分が評価されるだろうと思っていました。

ともかくたくさんコーディングする
まだかかわったことがない機能に，積極的にチャレンジする
毎日7時間で週に5日間はコーディングする
多少の残業を加えて毎日2時間ぐらいを上海チームの管理を行う

◆シーン1：上海チームの進捗管理

　イテレーション会議後に，私はコーディングしたい気持ちを抑えながら，まず上海チームのリーダーに以下のようにタスクを伝えました。

「こんにちは，今週のタスクを説明します。○○○と△△△と□□□があります。まずWikiにこれらのタスクを反映してください。○○○の優先順位が高いので，今週中に必ず完了してください。残りのタスクをみんなに選択してもらってください。Wikiには見積もった開発コストも書いてください。各ストーリーについて質問があれば，聞いてください」（JUDE開発では，分散共同開発の見える化を実現するために，図1のようにWikiで進捗とストーリーを管理しています）。

図1●Wikiで進捗とストーリーを管理
[画像のクリックで拡大表示]

　すぐには質問がなかったので，私は即座に自分のコーディングを始めました。その後何度か上海チームから質問がありましたが，説明した後，「大丈夫ですか？わかりましたか？」と尋ねて，「大丈夫」という回答をもらったら，また自分のコーディングに復帰するという状態でした。質問が少なかったので，上海チームはきっと順調に開発を進めているものだと思っていました。帰宅する前に，Wikiに書かれたコスト見積もりを見て，「今週ですべてのタスクは完了する。大丈夫」と判断しました。

　上海チームから全く質問や連絡がない日もありました。その場合，帰宅する前に先方に進捗状況を確認しました。「候補タスクのすべては完成できませんが，優先順位の高い○○○は大丈夫です」と上海チームのリーダーが回答したので，「了解です。優先順位の高い○○○を確保できれば問題ありません」と私は念を押しました。

　JUDEチームは毎朝，進捗の報告会を行います。その席で私は「上海チームは順調です。今週中に優先順位の高いタスクを完了できます。私のコーディングも順調です」と，自信満々に上海チームと自分の進捗を報告しました。

　一つの開発イテレーションの最終日となる金曜日に，上海チームが開発したタスクの動作確認とソースコード・レビューを行いました。

　上海チームが実装した機能は，ストーリーに書いてある通りに動かせば，問題はなかったのですが，影響がありそうな関連機能との結合テストで大量の不具合が見つかりました。さらに，ソースコード・レビューでは，クラス間の依存関係を考慮していない実装が発覚しました。これらの不具合の修正やソースコードのリファクタリングに，さらに一週間を要することが判明し，上海チームの進捗は一週間遅れることになりました。

◆シーン2：自分のタスク管理

　上海チームは責任を持って開発すると同時に，ストーリーの説明を細かく求め，異議があれば，ストーリーの見直しを要求できます。上海チームの積極性を保つために，福井チームには「正しい意見は積極的に採用し，採用できなければ，必ず納得してもらえるまで説明する」という方針があります。

　コミュニケータにとって，そのような意見と説明が応酬する議論は大変な一日を意味します。まず福井チームは，改めて設計会議を開きます。私は，上海チームの意見をその場で説明し，双方の設計の比較を行います。

　福井チームに採用されなければ，その理由をしっかり理解し，上海チームに説明しなければなりません。上海チームには中国名門大学の出身者が多く，自分の設計と提案に自信と誇りを持っています。そのプライドを傷つけることなく，モチベーションを保たせるために，私は，潜在的な不具合などを例に挙げながら，できるだけ論理的でていねいな説明を心がけています。

　複雑なストーリーの場合，ストーリーの解説と意見交換で数日を費やすことも珍しくありません。このようなコミュニケーションを何度か重ねるうちに，自分のタスクが徹夜しても終わらなくなる状況になりました。そうして私の進捗が遅れました。

■教訓

　プロジェクトにおいて，コーディングは非常に重要な段階ですが，そのほかにも上流から下流まで様々な段階があります。プロジェクトを成功させるためには，すべての段階を意識しなければなりません。

　さらに，オフショア開発の場合，海外チームの開発品質や進捗は，プロジェクトの成功に直結します。コミュニケータは，「中国チームのタスクはコミュニケータのタスクであり，中国チームの成功はコミュニケータの成功でもある」という意識を持たなければなりません。

■現在の実践

　現在，私は以下のルールで自分のタスクを選択するようにしました。そして「上海チームに対する評価は，自分に対する評価」という意識改革を行いました。