モデリングツール「JUDE」の中国オフショア開発において私たちは，XP(Extreme Programming)というアジャイル(Agile)の開発方法論を採用しました。この開発プロジェクトにおけるコミュニケーターの四つの役割および それらの役割を果たすための実践を紹介します。
中国オフショア開発の地理的な制約によって，「開発者の全員を1つの部屋に集めての開発」などの「XPプラクティス（プロジェクトに従 事するメンバーの実践）」を実現しにくかったものの，日中双方が様々な改善と実践を行った結果，JUDEは26万ユーザー(全世界)に採用されるモデリン グツールにまで成長し，「ソフトウェア・プロダクト・オブ・ザ・イヤー2006」を獲得できました（Google Map で作成した「JUDEユーザー分布マップ」)。
幸運なことに，私はJUDE開発に参加でき，日中開発チーム間の「コミュニケーター（JUDEチームでは，ブリッジSEのことをコミュニケーターと呼 ぶ）」を務めてきました。試行錯誤を繰り返しつつ，日中双方の開発者の助けとアドバイスをもとに，中国オフショア開発をスムーズに遂行するための様々な改 善を行ってきました。
これらの改善はまだまだ不十分ではありますが，中国オフショアが盛んに行われている現在，1つの事例および経験談として，JUDEオフショア開発におけるコミュニケーターの四つの役割およびそれらの役割を果たすための実践を紹介します。
コミュニケーターの四つの価値
その1：日中間の見える化
中国オフショア開発の場合，日本の開発チームと中国の開発チームは長期にわたって地理的に分散して開発を進めるため，各面においてお互いに「見え ない」状況が続き，様々なリスクを招きます。そのため私は，日中双方が相手開発チームの状況が正確に見えているかどうかといった観点から，コミュニケー ターとしての自分の役割を評価し，改善しています。
お互いのタスク
私はコミュニケーターを始めて間もなく，「中国側は何をやっていますか？」「日本側は何をやっていますか？」と日中双方の開発者からしばしば質問されました。相手のタスクがわからなければ，以下のようなリスクに遭遇する可能性があります。
リスク1：中国側がほとんどタスクを持っていないのに，日本側がタスクを出さないと，蓄積している不具合の修正や機能の改善を行う機会を逃してしまいます。結果的に，ユーザーに提供できる価値が減り，製品の評価が下がります。
リスク2：中国側のタスクが多すぎるのに，日本側が中国側にさらにタスクを追加するようだと，連日の残業で中国側の開発効率が落ち，中国開発者の転職につながります。
リスク3：中国側の開発者から日本側の開発者のタスクが見えないため，「日本側はほとんど仕事をしていないのに，私たちだけが忙しくなっている」と中国人開発者が勘違いし，モチベーションが低下します。
相手の認識
「日本側の望みどおりに開発していますか？無駄な開発をしていませんか？」「中国側は要求どおりに開発を行っていますか？仕様と全く異な るものを作っていませんよね！」「中国側は，優先順位の高い機能を先に開発してくれていますか？」---。複雑な機能仕様を開発する場合，よく日中双方の 開発者からそんな不安な声が聞こえてきます。
仕様に対する相手の認識と優先順位に対する認識がわからないと，以下のようなリスクに遭遇する可能性があります。
リスク1：中国オフショア開発においては，日本語と英語の読解力が日中双方の開発者の仕様理解の度合いを左右します。読解ミスで中国側の 開発者の認識がずれたまま開発を進めると，とんでもない成果物を作成し，無駄な手戻り作業が生じてしまいます。認識ズレが度重なると，中国オフショア開発 は中断されかねません。
リスク2：中国側の仕様に対する認識ズレが日本側から見えないと，早期の修正を中国側の開発者に要求できません。無駄な開発コストを防ぐ機会を失ってしまいます。
リスク3：日本側が考えているタスクの優先順位を中国側が認識できないと，優先順位の高いタスクを後回しにしてしまいます。結果的に，日本側に最大の開発価値をもたらすことができません。
リスク4：中国側の開発者に開発タスクを出しすぎではないかと日本側が心配し，オフショアのタスク量を減らした場合に，中国側の開発者は自分の開発能力が日本側に疑われて評価が落ちているのではないか，と誤解し，開発に集中できなくなります。
お互いの進ちょく
「日本側の機能仕様はいつ完成できますか？手元にタスクがないのですが，何をすればいいのですか」「中国側はどこまでやりましたか？いつ終わる予定ですか？」---。相手の進ちょくがわからなければ，以下のような問題点に遭遇する可能性があります。
リスク1：難しい問題に直面しているため，中国側の開発チームの開発が進まない場合に，日本側は解決につながる知識とサンプルを持っているにもかかわらず，中国側に提供できません。
リスク2：日本側が機能仕様をすでに作成したのに，中国側がその進ちょくを察知できないと，実装設計の開始が遅れてしまいます。
リスク3：中国側の実装とテストが終わりかけているのに，日本側が次に中国側に出せるタスクを準備できていないようだと，中国側がひまになり，オフショア開発のコストを無駄にしてしまいます。
精神状態
「最近，開発が忙しくなっていますが，中国側のモチベーションは大丈夫ですか？」---。中国開発者の顔が見えないため，日本側は中国開発者の健康状態とモチベーションを心配するようになります。
中国開発者の離職率の高さが話題になっています。ひとつの理由としては，タスクが多すぎて，仕事に疲れたりストレスがたまったりすることも考えられます。その精神状態が見えれば，タスク量を調整し，中国開発者に対する心のケアを行い，転職を防ぐことにつながるでしょう！
以上の各面における見える化を実現できるかどうかが，コミュニケーターとしての価値を決めると私は考えています。
その2：日中間のコミュニケーション
JUDEチームは，「ブリッジSE」の代わりに私の役割を「コミュニケーター(communicator)」と呼んでいます。その理由は，日本側の要求 を中国側の開発者に伝達し，その要求の開発を管理することを期待しているだけではなく，より一層の日中間のコミュニケーションを活性化させることも期待し ているからだと，私は考えています。
中国オフシュア開発は一種の国際文化交流で，人間と人間のコミュニケーションです。コミュニケーションを活性化させるために，私は以下の二点を重視しています。
コミュニケーションに対する勇気を持ってもらう
連載5回目の「中国開発者が考える評価の基準（/article/COLUMN/20080709/310467/ へリンク）」に「周囲の人にできることができなかったら，見下される恐れがある」という中国人技術者の考え方について紹介しました。
開発現場において，私は中国人技術者の問題解決能力と積極性を意識しつつ，「チームワークの大事さ」と「ほうれんそう」（報告，連絡，相 談）のメリットを中国側の開発者に説明しており，「困った時に，みんなの助けがありますよ」という考えを常に中国側の開発者に意識してもらっています。
日中双方のコミュニケーションを促進する手法
日中双方の開発者に異なる国の開発者とコミュニケーションを行う勇気を持たせても，コミュニケーションの失敗が繰り返されると，勇気がな くなってしまいます。そこで私は，日中双方の開発者のアドバイスとアイデアを取入れて，日中双方のコミュニケーションにおける言語依存度を最小限に抑える 方法を実践しました。
その3：日中間の信頼
中国開発者が離職する原因について様々な議論が行われていますがその際，中国開発者の日本側に対する信頼感が無視されがちです。
技術力における信頼
「一緒に仕事をしている日本人開発者の設計能力は大丈夫でしょうか？コミュニケーターからもらった指示は日本側の指示どおりでしょうか？ せっかく設計と指示どおりに実装したのに，やり直せと言われたら困ります。いくら努力しても，結局，常に実装し直さないといけません。そのような相手と一 緒に仕事をしても，自分の才能が発揮できません」---。そのように考えて新たな職場を探す中国人の開発者が大勢います。
キャリアにおける信頼
中国には，「士為知己者死」（男は自分を認めてくれるもののために命を投げ出す）ということわざがあります。会社が経営危機に陥っても， 会社に信頼され，自分の才能が会社に認められているとわかれば，最後まで会社のために全力を尽くす中国人の開発者を数多く見てきました。
その4：積極性と忍耐
積極性と忍耐がないと，どんなことにも成功しません。コミュニケーターという役割を果たすには，積極性と忍耐が特に重要です。積極性と忍耐に欠けているコミュニケーターは，日本チームと中国チームを分断する悪役となるだけです。
コミュニケーターとしての私は，日本側の要求を一方的に中国側に押し付けるわけにはいけません。日本側の設計に対して，中国側の開発者も 自分の考え方と質問があります。彼らの積極性と開発のモチベーションを保ち，コミュニケーションという価値を実現するために，設計に関する日中間の議論お よび質問応答が日常茶飯事になっています。(1)一方の質問・要求・回答を理解し，論理的にもう一方の開発者に伝える，(2)一方の設計をもう一方の開発 者に納得させる，それらの仲介において忍耐力が要求されます。
さらに，前述のすべての価値を実現するために，いくら大変な議論の仲介になりうると予想できても，積極的にその議論を促進しなければなりません。
時には私は，コミュニケーターを務めると同時に，機能の開発も担当します。中国側とのコミュニケーションで機能の開発が間に合わない場合 には，積極的にまわりに助けを求め，開発の一部を分担してもらうようにしています。逆に優先順位の高い開発タスクに追われる場合には，中国側がコミットし た実装を周りの日本側の開発者にチェックしてもらうように努めています。
コミュニケーターの実践
朝会で中国側のタスクと進ちょくの報告
JUDE開発はXP方法論を実践しているため，毎日の9時40分に朝会を行います。その朝会のルールは以下の通りです。
- 朝会は15分以内に終わらせる。長い議論は朝会の後に行う。
- チーム全員が順番に司会者となる。司会者は，開会の挨拶，議論時間のコントロール，閉会の挨拶，を行う。
- 朝会は立ったまま行う。
- 昨日のタスクと今日のタスク，問題点，連絡事項を全員に説明する。
私は，朝会で自分のタスクだけではなく，中国側開発チーム全員のタスク状況を説明するようにしています。場合によって，中国側の開発者 のモチベーションも併せて報告します。例えば，タスクが特定の中国開発者に集中しすぎる場合，その中国開発者に対する心のケアを促します。
朝会によって，私は，(1)中国側タスクの見える化，(2)中国側タスク進ちょくの見える化，(3)中国側精神状態の見える化，を実現できると考えています。
Wikiによる様々な日中間の共有
開発チームが地理的に分散する中国オフシュア開発の場合，自分の考えを素早く相手に理解してもらうために，日中双方がともに修正できるWebページが力 になります。JUDE開発では，Wikiで日中間のタスクやモチベーションなどの共有を実践しています(最近，一部の開発においては，TRAQと自社製品 のTRICHORDも使いはじめています)。
タスクにおける進ちょく状況と優先順位の共有
JUDE開発では，週単位にリリース計画の中から開発タスクを選択し，1つの開発イテレーションにしています。開発イテレーションごとに 新たなWikiページを作成し，各タスクの概要とストーリーへのリンク，タスクの優先順位，タスクの進ちょく状況，タスクの担当者を表形式で表していま す。
Wikiでは，各タスクの進ちょく状況をToDo/Doing/Doneで表現し，タスクにおける予想の開発日数(Estimate) と経過した開発日数(Past)，残りの開発日数(Need)を明記しています。さらに各イテレーションのWikiページに日本側の開発者のタスクおよび その進ちょくも書かれています。
これらによって，(1)中国側における日本側のタスクの見える化，(2)日中双方のタスクの見える化，を実現しています。
タスクボードによる中国側の進ちょくの見える化
Wikiページとともに，私は紙のタスク看板も愛用しています。その理由としては，主に以下の四つが挙げられます。
- 紙のタスク看板が大きくてオフィスのどこからでも見えるので，地理的に離れている中国側開発チームの存在を日本側の開発者に感じさせることができる。
- 日本側の開発者がWebブラウザを開かずにいつでも気軽に中国側の状況を目にすることができる。
- 中国側のタスクについて議論をしたい時に，即座に日本側の開発者とタスク看板の前でミーティングができる。さらに，参加者の誰でも，看板にあるタスクがはっきり見える。
- 付箋でタスクを表現するので，議論しながらタスクを簡単に書き直したり，中止にしたいタスクを即座に看板から外したりできる。タスク状況を素早く 更新できるので，速やかに会議を進められる（ミーティング後に私は最新の看板状態をWikiに反映し，中国側との共有を実現します）。
さらに，タスク看板でのタスク管理において，私は以下の実践をしています。
実践1：異なる色の付箋を使用しています。色によって，タスクの優先順位またはタスクの性質(不具合か改善か新規機能か)がわかりやすいようにするためです。
実践2：タスクの細分化を行います。例えば，“クラス図上でのクラス作成”というタスクを中国側に担当してもらうとします。その場合には，中国側にそのタ スクを伝える前に，ToDo欄に“クラス図上でのクラス作成”という付箋を1枚しか貼りません。伝達完了後に，そのタスクの進ちょくを表せる一連のサブタ スクに分割します。そのため，ToDo欄にある“クラス図上でのクラス作成”の付箋が消え，代わりに“テストケース書き”，“モデル作成”，“図上表示の 実装”などサブタスクを表現する付箋が出現します。開始しているサブタスクはDoing欄に移します。
実践3：縦軸で“ToDo”“Doing”“Done”のタスク状態を表現し，横軸で開発者のタスク欄を表現します。それによって，特定の開発者の進ちょくとタスク量がわかるようになります。
実践4：“Done”となったタスクをチェックする人のタスク欄に貼りなおします。
タスクボードの実践で，私は，(1)中国側タスクの見える化，(2)中国側タスク進ちょくの見える化，(3)タスク優先度に対する中国側 認識の見える化，(4)気軽に中国側のタスクを議論するミーティングができるようにするコミュニケーターとしての役割，を実現したいと考えています。
リリース目標の共有
目前のタスクにとどまらず，長期的なリリース目標も中国側の開発者に理解してもらうために，毎回リリース計画の結果をWikiで公開しています。
日本側の感謝の言葉
リリース後，日本側の開発チームは中国側の開発チームに感謝の言葉をWikiで送るようにしています。それによって，中国側の開発者に仕事の達成感を感じてもらい，日本側に信頼されていることを認識してもらい，互いの信頼関係を深めます。
ニコニコカレンダー
アジャイル宣言の第一条として，「プロセスやツールよりも，人と人同士の交流を重視する」ということが書かれています。開発の主役は人間 です。仕事の効率は人間の健康状態やモチベーションに大きく左右されます。そのため，中国開発者のモチベーションの見える化が非常に重要です。
私は，Wikiでニコニコカレンダーのページを開設し，中国開発者に毎日のモチベーションを正直に書いてもらっています。やる気が出ない場合に必ずその理由を明記してもらい，タスク調整のために活かします。
ストーリーの書き方
図，実例
ストーリー（機能要求）をメッセンジャの音声チャットで中国側に伝えた後に，中国側にそのストーリーをWikiに反映してもらっています。さらにストーリーの書き方として，文章を並べるのではなく，図と実例を多用するように要求しています。
文章をどんなに詳細に書いたとしても，あいまいさを克服することはできません。中国側の理解を示してもらうためには，具体例が不可欠です。
ストーリーのテストケース
中国側に説明したストーリーをWikiに反映してもらうと同時に，そのストーリーのテストケースも作成してもらうようにしています。テストケースの書き 方として，事前条件と結果を具体的な数字で表すように中国側の開発者に要求します。さらに，JUnitで自動テストを書けるなら，できるだけ自動テストを 作成してもらいますが，GUI関連で自動テストが書きにくい場合に，Excelでテストケースを書いてもらっています。
どんなに図や実例を用いて中国側に説明をしても，中国側の開発者の認識ズレを見えるようにできません。なぜかというと，誰でも自分の認識を正しいと考えており，ズレを意識できないからです。
テストケースなら，機能要求に対する認識ズレがあれば，事前条件に対して日本側が望んでいる結果が得られないはずです。テストケースに よって，中国側の開発者に自分の思考過程(機能要求に対する認識)を示してもらい，機能要求に対する認識の見える化を図り，再議論のきっかけを作り出しま す。
デモ会による中国側の認識と進ちょくの見える化
デモ会とは，開発途中の機能を実際に動かして，日本側の開発チームとサポートチームにその動作を見せる会です。その場で私は皆の改善要求とアドバ イスをいただき，優先順位に応じて中国チームに改善してもらいます。デモ会によって早期に仕様の認識ズレを発見し，中国側の進ちょくの見える化と認識の見 える化を果します。
中国側が担当している開発タスクの大きさによって，デモ会の頻度を決めています。デモ会を頻繁に行いすぎると，日本側にとって進ちょく が見えにくくなります。逆に，2回のデモ会の間に時間を置きすぎると，発見した認識ズレや不具合の修正が難しくなり手戻りによる開発コストが増加します。
デモ会で私は，(1)中国側タスクの見える化，(2)中国側タスク進ちょくの見える化，(3)中国側のタスクに対する認識の見える化，(4)日本側のタスクに対する認識の見える化，を実現できると考えています。
ソースレビュー会
デモ会とAccept(実装した機能をほかの開発者にテストしてもらう仕組み)で実装した機能に対する認識のズレや様々な不具合を早期に発見できます が，関連機能へのディグレードはなかなか発見できません。そのようなディグレードを防ぐために，日本側のJUDEチームはソースレビュー会を行っていま す。
ソースレビュー会の準備として，私は中国チームがコミットしたソースコードを事前に理解しておかなければなりません。そして，レビュー 会のときに，私はまずレビュー参加者にソースコードの概要を説明します。ベテラン開発者もレビューに参加するので，ほかの機能に影響を与えたり性能を悪く したりする実装をすぐに発見でき，指摘してくれます。
レビュー会の後に，私は指摘を整理し，中国の開発者に修正してもらいます。レビュー会を通して，(1)中国側タスク進ちょくの見える化，2)中国側のタスクに対する認識の見える化，(3)日本側の機能要求認識の見える化，を実現できます。
週の途中のタスク調整
日本側は毎週の月曜日にイテレーション・ミーティングを開き，日本側と中国側の1週間のタスク(1つの開発イテレーション)を決定します。
ただし，タスクをいったん開始すると，様々なことが見えるようになります。例えば，予想より遥かに簡単で1日2日でも完成できるケースも ありますし，逆に予想より技術的に遥かに難しくてなかなか開発が進まないケースもあります。そこで私は，週の途中に必ず各タスクの進ちょくをチェックしま す。
早めにタスクが終わる場合，新しいタスクを追加し，逆に，なかなか開発が進まない場合，日本側の開発者と技術調査をし，中国側の開発者 をサポートします。中国側の開発者にとっては，難しいタスクを担当した場合にもまわりのサポートを得られるし，状況によってタスク調整もできるというメ リットがあるので，開発の状況を積極的に日本側に示すようになっています。
途中のタスク調整によって，(1)中国側タスク進ちょくの見える化，(2)日本側のタスク優先度認識の見える化，(3)日中双方のコミュニケーションに対する勇気，を実現できます。
喜びの共有
中国チームにモチベーションを保たせるために，私は特に注意しているのは，成功の喜びを日中双方に共有させることです。
例えば，JUDEが「ソフトウェア・プロダクト・オブ・ザ・イヤー2006」を受賞したとき，私はこの喜ばしいニュースを中国側の開発 チームに伝え，中国側の開発者に対する日本側の感謝のメールを送りました。「ほかの開発プロジェクトと比べて，JUDE開発に参加できて幸いです。受賞を 誇りに思っています。もっと世界中の開発者にJUDEを使っていただけるように，日本側の開発者とがんばっていきたいです。」という言葉を中国側の開発者 からもらいました。
日本側のJUDE開発チームは毎週，ユーザーからの感想と要望を整理し，開発計画に活かすようにしています。整理したそれらのユーザー の声を中国側の開発チームにもメールし，中国側と共有しています。「世界中のユーザーに自分が開発した機能を使っていただいていることを実感し，開発者と してのやりがいを感じています」という言葉を中国側の開発者からもらいました。
中国側の開発者に子供が生まれたときには，日本側の開発チームにこのニュースを伝え，その開発者の仕事量を軽減しました。さらに，日本 側からはお祝いとして，子供服がその開発者に送られました。こうした喜びの共有によって，日中間のコミュニケーションを促進し，信頼を深めることができま す。
アイカンパニー意識
アイカンパニーというのは自分(アイ)を1つの会社（カンパニー）と考え，上司や同僚を自分の顧客とし，自分のスキルを商品とします。そして顧客(上司や同僚)に自分の商品(スキル)を売り込むために，様々な努力と実践をします。
私は，常に自分を日本に常駐する中国受託開発会社の社長と仮定し，中国側の開発者を自分の社員と仮定しています。日本の開発チームからも らった機能要求を中国の開発チームに正確に伝えたか，中国側からの質問を正しく回答できたか，品質の高い実装を日本の開発チームに納品できたか，などの成 果でその受託開発会社の運営に成功しているかどうかを判断します。
その会社の売上を拡大するために，様々な実践方法を実行し，会社運営が危うくなった場合(中国側が日本側の要求を正しく実装できなかっ たような状況)，日本側のお客さん(自分の日本人開発仲間)とコミュニケーションし，売上を挽回します(中国側に実装し直してもらいます)。開発の結果と 自分の仮想利益に直結するために，どんな辛いコミュニケーションにしても仲介できるようにしています。
アイカンパニー意識によって，コミュニケーターに必要とする積極と忍耐を得られます。
0 件のコメント:
コメントを投稿