オフショア開発におけるアジャイルソフトウェアプロセス

継続的インテグレーションで統合の頭痛を回避する

複数サイトのチーム間で作業を統合する際の問題について、いくつかの話を聞いたことがあります。インターフェースの定義に細心の注意を払っても、統合の問題は依然として厄介な頭をもたげます。これは、インターフェースのセマンティクスを適切に指定することが非常に難しいためであることがよくあります。したがって、すべてのシグネチャが正しくても、実装が実際に何をするかについての前提につまずく可能性があります。

Thoughtworksで最初に定着したXPの実践は継続的インテグレーションであり、私たちはそれに非常に慣れているため、オフショア開発でもそれを使用することにしました。そのため、当初から、すべての人が単一のコードベースを使用し、CruiseControlをビルドとテストの両方を実行するように設定しました。これにより、場所がどこであろうと、すべての人がメインラインに近い状態が保たれます。

誰もがこの仕組みに非常に満足しています。その主な利点は、統合で他のグループを悩ませる問題が私たちには発生しないということです。継続的な統合とテストプロセスは、多くの統合問題を非常に迅速に洗い出し、その結果、見つけにくくなる前に修正できます。

CruiseControlのWebページでは、すべてのサイトで海外の状況を確認できます。朝一番に、CruiseControlのWebページをチェックして、他のサイトで行われた変更を確認できます。これにより、世界の反対側で何が起こっているかを簡単に把握できます。

これには、開発者がビルドを壊さないように努力し、壊れた場合はすぐに修正するという、優れたビルド規律が必要です。メインラインに変更をコミットした場合、変更が正常にビルドされたことを示すCruiseControlからのメールメッセージを受信するまで、帰宅すべきではないという一般的な慣習です。リモートオフィスが同じビルドで実行されている場合、深夜のビルドの失敗ははるかに深刻です。

世界規模の継続的インテグレーションは非常に人気がありますが、いくつかの問題にも直面しました。通信パイプは、私たちが望むほど広くも信頼性も高くないため、リモートサイトからのソース制御操作はぎこちなくなる可能性があります。一般的に、ビルドサーバーはほとんどの開発者と同じサイトに保持しますが、リモートサイトではメインラインからの最新の更新を取得するのに非常に時間がかかることがあります。通信回線が長ければ長いほど、グリッチから回線がしばらくダウンするなど、あらゆる問題が発生しやすくなります。リポジトリを24時間アクセス可能にすると、バックアップのためにダウンさせるのが面倒になります。これらの問題はすべて、クラスタ化されたコードリポジトリによって軽減されますが、まだそのようなものを試していません。

ソースコード制御システムの中には、特に設定が適切でない場合、チェックアウトに時間がかかり、苦痛を伴うものがあることがわかりました。チェックアウト時間を短縮する方法を見つけることに時間を費やす価値があり、リモート作業をうまく処理できないソースコード制御システムに固執している場合は、実際にソースコード制御システムを変更することも価値があります。

（興味深いことに、これらの通信問題は特にインドのようなリモートサイトでの問題であると人々は考えていますが、私たちは西洋のインフラでも問題が頻繁に発生することを発見しました。継続的インテグレーションには、多くの場合、人々が慣れているよりも優れた接続性が必要です。）

ただし、最良の接続性であっても、オンショアファイアウォール内にロックされているサービスをシステムが必要とする場合は、問題が発生する可能性があります。システムを開発環境で効果的にテストできるように、これらのサービスに対して優れたテストダブルを構築する必要があります。

各サイトから他のサイトへアンバサダーを派遣する

上で述べたように、アジャイル手法は、対面での人間同士のやりとりの重要性を強調しています。全員が同じ場所にいなくても、一部の人々を移動させることは明らかに大きな助けになります。当初から、コミュニケーションを円滑にするために、常に米国チームの誰かがインドにいるようにすることにしました。そのようなアンバサダーは、米国を拠点とする人々をすでに知っているため、彼の人脈を活用して、誰もがコミュニケーションを取るのに役立ちます。

私たちはこれをいくつかのレベルに拡大しました。技術レベルと要件レベルの両方でコミュニケーションをとるために、米国の開発者と米国の分析者をインドに派遣することが役立つことがわかりました。また、インドから米国チームに誰かを派遣することも価値があります。航空運賃は、コミュニケーションが改善されるため、すぐに元が取れます。

オフショアチームにビジネス指向のアンバサダーがいることの利点の1つは、オフショアチームにビジネスコンテキストを提供するのに役立つことです。要件リストだけに基づいてソフトウェアを構築すると、多くのビジネスコンテキストを見逃してしまいます。開発者は、なぜそれが重要なのかを伝えられずに、何をすべきかを指示されます。「なぜ」は、適切に「何を」行う上で大きな違いを生むことがよくあります。

アンバサダーの仕事の重要な部分は、ゴシップを伝えることです。どのプロジェクトでも、多くの非公式なコミュニケーションがあります。その多くは重要ではありませんが、一部は重要であり、問題はどれがどれであるかを判断できないことです。したがって、アンバサダーの仕事の一部は、より正式なコミュニケーションチャネルには重要ではないと思われる多くの情報を伝えることです。

アンバサダーが海外で過ごす期間が長すぎると、母国との連絡が途絶えてしまうため、通常、アンバサダーは数か月ごと（場合によっては数週間ごと）に交代します。これにより、アンバサダーが長期間離れたくないため、アンバサダーにとってより簡単になります。また、より多くの人がアンバサダーとして時間を過ごすことで、リモートチームを知ることができます。アンバサダーを選択する際には、個々のニーズと好みに注意を払うことが非常に重要です。何千マイルも離れた場所で数か月過ごしたくない人もいるため、彼らはアンバサダーになるべきではありません。

プロジェクトマネージャーは、アンバサダーとして一定の時間を費やすことが重要であることもわかりました。プロジェクトマネージャーの仕事の多くは、紛争を解決し、問題が深刻化する前に洗い出すことです。電話回線の両側で仕事をした経験は、彼らがそれを効果的に行うために非常に重要です。

アンバサダーは、信頼関係を構築し、遠隔地間で連携を強化する上で重要な役割を果たします。そのため、プロジェクトの早い段階でアンバサダーを派遣することが不可欠です。アンバサダーが配置されないままプロジェクトがしばらく進行すると、コミュニケーションのミスや不快な感情が生じ、それらを修復するのに多くの労力がかかります。アンバサダーはこのようなリスクを軽減しますが、問題が定着し始める前に早期に配置する必要があります。

訪問による接触で信頼を築く

アンバサダーは、数ヶ月間「別の」場所に滞在する、半恒久的な人たちです。これは非常に重要ですが、それだけでは十分ではありません。より多くの人々が関わるさらなる接触も必要です。これらの訪問は、遠隔地とのコミュニケーションを効果的に行うために必要な関係を構築し、維持するのに役立ちます。

接触訪問には2種類あると考えられます。シード訪問はプロジェクトの初期段階で行われ、関係を構築することを目的としています。一方、維持訪問は関係を維持するのに役立ちます。

シード訪問はプロジェクトの初期に計画する必要があり、かなりの期間（最低2週間）が必要となります。シード訪問の重要な点は、人々がお互いに協力して作業することに慣れることなので、共同タスクを中心にアレンジする必要があります。

• 初期リリース計画を作成するために、オンショアの顧客とプロジェクトマネージャーをオフショアサイトに派遣します。
• オフショアのアナリストをオンショアに招待し、初期の要件収集セッションに参加してもらいます。
• オンショアの開発者の一部をオフショアチームに派遣し、オフショアチームが既存のコードベースで初めてイテレーション作業を行うのを支援します。
• オフショアチームをオンショアの場所に訪問させます。特に、クライアントサイトである場合は重要です。

理由が何であれ、訪問の主な目的はタスクを実行することではなく、協力関係を構築することであることを忘れないでください。よくある間違いは、訪問中にあまりにも多くのタスクを詰め込みすぎて、重要な人間関係のコミュニケーションのための時間がほとんどないことです。そのため、作業ペースを緩やかに保ち、ホストが訪問者を案内し、非公式な交流を始めることができるような非公式な時間をスケジュールすることを恐れないでください。夕食や観光は、訪問者がホストと行う最も有益な活動となることがよくあります。

できるだけ早くシード訪問を行うことが重要です。きちんとした個人的な関係がなければ、コミュニケーションのミスや信頼の欠如が原因で問題が発生する可能性があります。これらの問題を修復するには多くのエネルギーが必要となり、プロジェクトに永続的な損害を与える可能性もあります。したがって、これらの問題を未然に防ぐために、早めにシード訪問を行う必要があります。

複数サイトに最初から開発者がいる場合は、シード訪問の特別なバリエーションが重要になります。この場合、開発者、または少なくともシニア開発者を一緒に集めて、最初の数回のイテレーションを構築することが重要です。重要なアーキテクチャ上の決定は、これらのイテレーションで行われるため、この期間中は近接していることが重要です。これがなければ、異なるチームが異なる決定をしたり、あるチームが別のチームが理解できない決定を下したりして、分裂してしまう可能性があります。

シード訪問が完了したら、接触を維持するために、より頻度の少ない維持訪問を利用する必要があります。維持訪問は短くても構いませんが、頻繁に行う必要があります。2ヶ月ごとに1週間の訪問が最低限です。繰り返しますが、必要なタスクに焦点を当てる必要があり、そのための良いタスクの1つは振り返りです。チーム間のコミュニケーションに問題があると感じた場合、または重大な問題が発生した場合は、より長く、頻繁な訪問をすることを恐れないでください。システム設計に大幅な変更が発生した場合、より長い接触訪問を行うことが特に役立つことがわかりました。

贈り物、特に文化を広めるのに役立つ贈り物は、常に持参する価値があります。特に、遠隔地の特産品であるスナック菓子やスイーツの贈り物を歓迎しています。

文化の変化を過小評価しない

アジャイル手法を組織に導入する最も難しい部分の1つは、それが引き起こす文化的な変化です。実際、これが組織がアジャイル手法の採用に問題を抱える主な理由であることがわかりました。多くの企業は、上級者が意思決定を行い、下位レベルの人がそれを実行するという前提の指揮統制モデルで運営されています。アジャイル手法を機能させるには、実行者によるより多くの自主性と意思決定が必要です。

これは欧米企業では大きな問題ですが、アジアの文化は上司への服従を強化するため、アジアでは問題が増幅されます。（インドの大手契約会社が実施したトレーニングコースでは、経営を「統制の科学」と定義していました。）このような環境では、人々は質問をしたり、問題について話し合ったり、実現不可能な納期について警告したり、上司からの指示と思われるものに対する代替案を提案したりすることを躊躇することがよくあります。

欧米のチームは、この傾向に注意する必要があり、東洋のチームが受動的に同意していると感じた場合は、反論する必要があります。礼儀正しい受け入れは、重要な問題が議論されていない兆候であることが多いことに注意してください。さらに、欧米のチームは、権威的に聞こえないように注意する必要があります。権威的な態度は、この種の状況を強化するからです。

このことに関する悪いニュースは、チームをより積極的にすることは困難な戦いであり、必然的に多くの時間がかかるということです。問題が見つかったとしても、問題が提起されると決して想定することはできません。人々が分散型統制スタイルの管理に慣れるには、想像以上に時間がかかります。

しかし、良いニュースもあります。人々が意思決定の自由と責任を認識すると、本当にそれを楽しんでいるように見えます。インドのチームの何人かは、他の会社の友人が、自分たちがどれほどの自主権を与えられているかを信じられないと話してくれました。この自主性は、人々がより生産的になり、より大きな責任を担うことができるようになるという、大きなモチベーターです。オフショアチームのメンバーは、オンショアチームを待つのではなく、意思決定を行うための信頼と理解を得るため、多くの遅延につながります。私にとって最も興味深いことの1つは、この文化的な影響がアジアと西洋の両方で、長期的にどのような影響をもたらすかを発見することです。

シード訪問は、ここで重要な役割を果たします。人々は、良好な個人的な関係があれば、問題を提起する可能性がはるかに高くなります。

これらの文化的な問題について話すことさえ、問題を引き起こす可能性があります。この記事の草稿を見た一部の（欧米の）業界アナリストは、このセクションは人を軽視しており、不快であると言いました。バンガロールにいる当社の開発者の1人は、私が非常に穏やかすぎると言いました。別の人は、それは問題だが、多くの欧米企業よりも悪いかどうか疑問だとコメントしました。しかし、アジアには指揮統制を強化する文化的要因があり、これが変化しつつあるという点で、ある程度の合意が得られているようです。

（これはThoughtworksにとって特に深刻な問題です。私たちは米国でも顕著な反権威的な姿勢を持っています。私たちは当初から、インドでも同じ文化を維持することにしました。私たちは確かに成功しているように見えます。）

共通情報をWikiにまとめる

共通の情報を保持するためのさまざまな方法を試してきましたが、今のところ最も気に入っているのはwikiです。wikiは、使い方が簡単で、どのブラウザでも作業でき、設定が簡単なため、うまく機能します。

共通の情報（ストーリーカード、設計ガイドライン、ビルド手順、進捗状況に関するメモなど、チームが参照するために書き留めておく必要のあるものは何でも）をそこに入れることができます。多くのwikiが備えている変更通知機能を利用して、ページの変更がメールまたはRSSフィードを通じて通知されるようにすることが非常に便利であることがわかりました。

wikiは性質上、構造化されておらず、この構造の欠如は利点の一部です。チームは通常、プロジェクトの成長とともにwiki上の独自の構造を構築できます。これは、過度に成長しないように、誰かが庭師として行動する必要があることを意味します。

テストスクリプトを使い要件を理解する

距離が離れるほど、要件を伝達するための儀式をより多く取り入れる必要があります。私たちは、単一サイト開発で使用する多くの手法に固執しながら、それを実現することができました。

ますます、より成熟したXPチームが、要件を伝達する方法として受け入れテストを使用していることに気づきました。このようなチームは、要件を明確にし、開発チームが目指すべき具体的な目標を与えるために、イテレーションの開始前にテストスクリプトを作成します。うまく機能したスタイルの1つは、米国を拠点とする顧客が機能（XP用語でストーリー）を具体化するために短い物語（2、3ページ）を作成することです。次に、インドを拠点とするアナリスト/テスターが、このストーリーのテストスクリプトを作成します。これは、自動テストと手動テストのどちらでも実行できますが、私たちは自動テストを非常に推奨しています。スクリプトが開発されるにつれて、米国とインドのアナリストは、メールとIM、およびテストスクリプトを確認するための定期的な（週に2〜3回）電話会議を通じて調整を行います。

これにより、インドのアナリストと米国の顧客の両方が要件を実際に理解するのに非常に役立ったことがわかりました。テストを書き出すことで、インドのアナリストは必要なものを本当に理解し、質問が浮上したら米国の顧客に質問する必要が生じます。開発者は、テストスクリプトを掘り下げるよりもインドのアナリストに質問する方が簡単であると感じるため、インドのアナリスト/テスターがいることは依然として重要です。検索エンジンは優れていますが、人間の方が対応しやすいことがよくあります。

この手法で最も大きな問題は、クライアントのスタッフをそれを行うように関与させることです。その結果、ほとんどのプロジェクトではそれを行うことができませんでしたが、行った場合には、このアプローチが価値のあるものであることがわかりました。

定期的なビルドで機能に関するフィードバックを得る

人々がアジャイル手法での要件収集を検討する場合、フィードバックループの重要性を見落としがちです。多くの場合、要件プロセスは、アナリストが要件を提供し、開発者がそれを実装しに行くものとして見られています。後日、開発者が要求されたものを実装したかどうかを確認する人がいます。アジャイルプロジェクトでは、顧客と開発者の間の緊密な近接性により、顧客は進捗状況をより頻繁に監視できるため、誤解をより迅速に特定できます。さらに、部分的に開発されたシステムも顧客を教育できます。なぜなら、要求されたものと必要なものの間には違いがあり、通常、いくつかの動作するソフトウェアが存在するまでそれは明らかにならないからです。

定期的な統合ビルドにより、米国の顧客は昨夜の作業を取り下げて試すことができます。これは、同じ場所にいるほど直接的ではありませんが、顧客は誤解を迅速に修正できるだけでなく、要件に対する自身の理解を洗練させることもできます。

これを機能させるには、環境の問題を解決して、海の両側で環境を適切に複製することが重要です。オンショアの人がビルドを取り下げて問題を発見し、環境構成の問題のためにオフショアの人が問題を複製できないほど悪いことはありません。環境が早期に解決されるようにし、環境の問題が発生した場合に解決する人がいることを確認してください。

たとえ部分的な機能しかなくても、定期的に作成物を確認するようにしましょう。作業の早い段階で誰かが確認することで、コミュニケーションのずれを早期に発見できます。多くの場合、人々は完成するまで他人に見せたがりませんが、このような状況では、待つ価値はありません。

スクラムは、開発チームがイテレーションの終わりに顧客にデモを行うことを長らく提唱してきました。私たちはこのプラクティスをかなり広く採用しており、ショーケースと呼んでいます。リモートチームの場合、リモートショーケースを好んで実施します。オフショアの開発者が、リモートデスクトップソフトウェアを使ってソフトウェアの新機能を披露します。リモートチームにこれをさせることは、オフショアとオンショアの間、開発者と顧客の間の繋がりを構築するあらゆる機会を活用するもう一つの例です。

定期的な短いステータスミーティングを実施する

アジャイル手法は、チーム全体で定期的に短いステータスミーティング（スクラムにおけるスクラム、XPにおけるスタンドアップミーティング）を行うことを推奨しています。これをリモートグループに持ち込むことは、他のチームと連携するために重要です。時差は、特に米国とインドの間で誰にとっても都合の悪い時間になるため、最大の課題となることがよくあります。初期のプロジェクトでは、週2回のスタンドアップがうまく機能し、十分な連携を提供することがわかりました。

最近のプロジェクトでは、Wikiの利用を増やしており、これによりクロスショアでのスタンドアップの必要性が減りました。現在では、ショア内のチームでスタンドアップを行いますが、異なるショア間では行いません。ただし、毎日クロスショアミーティングを行いますが、これはチーム全体ではなく、クロスショアコラボレーションに焦点を当てたメンバーのみが参加します。ただし、小規模なチームでは、クロスショアでのスタンドアップを行います。

会議通話を始める際に、現地のニュースについて雑談する習慣は良いことだとわかりました。最近のちょっとした現地の話題、つまり政治、スポーツ、天気などは、お互いの日常的な生活環境を理解するのに役立ちます。（これは、私たちオタク以外の人にとっては当たり前のことでしょう。人々がタスク指向になりすぎると、私たちが生きているより広い状況を見失いがちになります。）

時差の問題がある場合、通話の時間を選択する際に、両者が譲歩し合うことが重要です。クライアントの中には、業務時間中にしか通話しないというところがあり、インドの人々は非常に都合の悪い時間に来なければなりませんでした。一方だけにすべての負担を強いることは、円滑なコラボレーションには役立ちません。

この知識不足や配慮不足は、他の分野にも見られます。あるプロジェクトでは、インドの祝日であるディワリの期間中に大規模なリリースを予定してしまいました。これはアメリカのチームに感謝祭中に働いてもらうようなものです。幸いにも、日付を変更するよう説得することができました。それほど深刻なケースでなくても、祝日は共有されることはまれなので、一方のチームが祝日モードになっている間、もう一方のチームが通常どおりの勤務週になっていることがよくあることを覚えておいてください。

短いイテレーションを使用する

一般的に、アジャイル手法では、他の多くの反復型アプローチよりも短いイテレーションを使用します。Thoughtworksでは、ほぼすべてのプロジェクトで1週間または2週間のイテレーションを使用しています。経験豊富なインドの開発者の中には、2〜3ヶ月のイテレーションを使用している場所で働いたことがある人もいますが、短いイテレーションの方がはるかに優れていると報告しています。

数年前、分散型プロジェクトでは、短いイテレーションを使用することが困難だったため、2週間のイテレーションを好む傾向がありましたが、これは変化しました。現在では、分散型プロジェクトで1週間のイテレーションを快適に実行する方法を習得しました。

リモートサイトに合わせて調整されたイテレーション計画ミーティングを使用する

ほとんどのプロジェクトで、チーム全体が参加する各イテレーションの開始時の計画会議が、次の作業を全員で調整するのに非常に役立つことがわかりました。ほとんどのプロジェクトが、それぞれの状況に合わせてイテレーション計画会議（IPM）を独自に変化させていることに気づきました。（このような自己適応は、アジャイルプロセスにおける重要な要素です。）

リモートチームは、特に不都合な時差の問題がある場合、独自の制約を加えます。しかし、不都合な会議時間の苦痛にもかかわらず、IPMは非常に有用であることがわかりました。

IPMの前に、米国の顧客は、スケジュールされた各機能（ストーリー）のナラティブを送信します。私たちは、IPMの前にこれをテストスクリプトに変換したいと考えています。この期間中の質問は、メールで処理されます。IPMの直前に、開発チームは機能をより細かい粒度のタスクに分解します。これらのタスク分解は、フィードバックのために米国と共有されます。

このすべての事前作業により、電話会議は短縮され、現在はタスク分解から生じる問題に集中しています。電話会議は通常、30分から2時間程度です。このようなリモート会議は特に大変なので、実際の電話会議は短く保つことが重要です。

コードベースを移動する際、バグ修正から始めるのが良い

私たちのプロジェクトの2つでは、大規模な（数十万行のコード）コードベースを取り、そのコードベースの大幅な開発をバンガロールの研究所に移すことになりました。これらのプロジェクトの両方で、インドのチームは新しい機能を追加する前に、いくつかのイテレーションでバグ修正から始めました。

バグ修正から始めることで、インドのチームは、バグ修正は変更よりも多くのコードリーディングを伴うため、コードベースに関する実質的な作業を行う前に、コードベースに慣れることができました。これはうまく機能しましたが、より経験豊富な人はバグ修正のみを行うことを不名誉だと考えるかもしれないという懸念があります。一部の人はこれを問題と認識するかもしれませんが、バグ修正や非常に局所的な機能変更に取り組むことは、大規模な新しいコードベースに慣れるための最良の方法の1つだと私は信じています。

バグ修正のコミュニケーションの性質も、オフショアでの作業をより簡単にする可能性があります。オンショアチームは、バグの詳細をマッピングするのに1日を費やし、それをオフショアチームに伝え、オンショアの夜間に作業することができます。オンショアチームは、翌日に修正を確認することができます。コミュニケーションが困難なため、これはオンサイトチームにバグを修正させるよりも効率的ではないことを強調する必要がありますが、オフショアチームと連携するためのより複雑でない方法になる可能性があります。

チームを活動ごとではなく機能ごとに分ける

オンショア/オフショアの境界に関する従来の考え方の多くは、人々が行う活動に基づいています。したがって、分析と設計はオンショアで行い、構築はオフショアで行い、受け入れテストはオンショアで行います。これは明らかにウォーターフォールモデルにうまく適合します。

これとは対照的に、オフショアチームができるだけ多くのアクティビティを処理するようにすると、状況が改善されることがわかりました。したがって、要件がオンショアから来ているという制限はありますが、可能な限り多くの分析と設計を行うことを望んでいます。オンショアとオフショアの開発チームで作業を分割する場合、アクティビティではなく機能に基づいて分割します。システムを大きなモジュールに分割し、オフショアチームにこれらのモジュールの一部に取り組んでもらいます。ただし、これを行うほとんどのグループとは異なり、これらのモジュール間のインターフェースを設計してフリーズすることに大きな労力を費やしません。継続的な統合と弱いコード所有権により、モジュールインターフェースは開発が進むにつれて進化できます。

この重要な要素の1つは、オフショアチームのアナリスト部分を成長させることです。開発者に近い人がビジネスを理解すればするほど、開発チームは効率的に開発できます。質問に答えるために一晩待つ必要がないため、開発者はすぐに答えを得ることができ、進捗の妨げを取り除くことができます。これらすべては、オフショアアナリストのビジネス知識を成長させることに焦点を当てる必要があることを意味します。これには時間がかかりますが、ローカルの知識はオンショアのビジネス知識にとって不可欠な要素です。

これの当然の帰結として、チームを水平方向に（1つのチームがプレゼンテーションを行い、別のチームがデータベースを行う）分割しないことです。一般的に、私は機能的なスタッフ組織を好みます。リモートチームは、チームをレイヤーで分割することの問題を悪化させます。

ここで覚えておくべき最も重要なことは、コンウェイの法則の支配的な力です。システムの構造は、それを構築したチームの構造を反映します。つまり、分散チームを、可能な限り疎結合であるモジュールで分割することが重要です。

ドキュメントの必要性が増すことを予測する

アジャイル手法は、ドキュメント作成の努力の大部分が無駄になるという観察から、ドキュメント作成を軽視します。ただし、対面でのコミュニケーションが減るため、ドキュメントはオフショア開発においてより重要になります。この作業は、チーム全体が同じ場所にいる場合には必要ないため、ある意味無駄です。しかし、オフショアモデルを考えると、これらを行う必要があります。したがって、これらはオフショアで物事を実行するための代償の一部です。それは、人々がそれらを書く時間、ドキュメントから多くのことを理解することがより困難になるために追加される時間、そして人々がそれらを使用するときに感じる不満の代償です。

ドキュメントだけでなく、より積極的なコラボレーションツール（Wiki、課題追跡ツールなど）もより多く必要になります。全体として、構造をあまり課さないツールを優先する方が良いようです。そうすれば、チームは自分たちの働き方に合わせてツールをより適切に適合させることができます（Wikiが非常にうまく機能する理由の1つです）。

私は常に、ドキュメントをバージョン管理システムにチェックインして、人々が最新の資料を簡単に取得できるようにするようにチームにアドバイスしています。これは、リモートワークを行っている場合は特に重要です。

ドキュメントであれ他のものであれ、他の人のテンプレートは自分には合わず、最初から適切なスキームを思いつくことはできないことを覚えておいてください。ドキュメントの形式と、それがどの程度うまく機能しているかについて、十分にコミュニケーションを取るようにしてください。チームにとって何が最もうまく機能するかを学ぶにつれて、ドキュメントの構造を進化させることを期待してください。

アジャイルプロジェクトにおけるドキュメント作成を成功させるには、2つの重要な点があります。1つ目は、「必要最低限」のドキュメントを見極めることです。これは判断が難しく、プロジェクトによって異なります。幸いなことに、アジャイル開発の反復的な性質により、適切なレベルになるまで試行錯誤することができます。アジャイルドキュメント作成を成功させる2つ目の重要な点は、ドキュメントに執着したり、最新の状態に保つという非現実的な期待を抱かないことです。ドキュメントは特定の目的を果たすために作成される必要があり、その目的を果たした後、ドキュメントを更新し続けるよりも重要なことがあるでしょう。直感に反するように思えるかもしれませんが、次にドキュメントが必要になったときに、新たにドキュメントを作成する方が良い場合があります。プロジェクトの一部を文書化する必要が生じるたびに最初からやり直すことで、ドキュメントを効率的に保つための素晴らしい動機付けになるという副次的なメリットもあります！

-- [サイモンズ]

複数のコミュニケーションモードを早期に機能させる

さまざまなコミュニケーションツールは、さまざまな種類の問題に適しています。最低限、Wiki、インスタントメッセージング、および良好な電話回線を用意してください。

インスタントメッセージングは、簡単な質問と回答に適していますが、IMの特に優れた点は、相手がデスクにいるときにわかることです。IMのステータスを最新の状態に保つ習慣を身につける必要はありますが、その情報は常に役立ちます。特に重複時間が短い場合に、重複時間帯にコミュニケーションが急増していることがわかります。

最近、多くの企業がインスタントメッセージングを気が散るものと捉えてブロックしています。これにより、他のプロジェクトの人々にThoughtWorkerが質問することができなくなるため、常に私たちの妨げになります。特にオフショアプロジェクトでは、非公式な1対1の連絡手段がなくなるため、悪影響があります。

簡単なメッセージのやり取り以上の場合は、電話に切り替えるのが最善です。電話を簡単にかけられるようにしてください。電話料金を気にすることでためらわれるべきではありません。電話をかけることで、誤解による無駄なコストを削減できる場合があります。

ビデオプレゼンテーションには多くの価値があることがわかりました。プロジェクトの背景に関する短い講義を録画して、リモートチームに送信できます。これらはドキュメントよりも準備が簡単で、（長すぎなければ）理解しやすく、そして何よりも、動画の方がドキュメントよりも相手の全体像を把握しやすいので、個人的なつながりを深めるのに役立ちます。詳細にはそれほど適していませんが、全体像を把握するのにはより適しています。

電子メールはしばしば両刃の剣となります。特に、個人間の電子メールを避けて、ブロードキャストニュースグループまたはメーリングリストを使用することを推奨しています。必要な人に情報が届かない、または情報を見つけることができないということがあまりにも簡単に起こります。ニュースグループにメッセージやリクエストを投稿することで、誰もがメッセージを見ることができ、検索も簡単です。興味のないスレッドはスキップするのが簡単であることに人々は気づくでしょう。

1対1ではなくマルチキャストでのコミュニケーションは、リアルタイムツールを使用しても実現できます。いくつかのチームがCampfireの使用によって良い効果があったと報告しています。（IRCも同様に使用できますが、まだ言及されていません。）

おそらく最も解決が難しいのは、プロジェクトの全体像、つまりビジョンをどのように伝達するかということです。ほとんどのコミュニケーション、およびコミュニケーションに関する議論は、日々の詳細に集中しています。これらを適切に行うことは重要ですが、日々のことに焦点を当てていると、誰も全体的なビジョンに注意を払わないという危険性があります。

多くの人々は大きなビジョンに対する認識に基づいて習慣的な小さな意思決定を行うため、これは悪影響を及ぼす可能性があります。これらの小さな意思決定が積み重なるため、全体像が伝わらないと、問題が表面化する可能性があります。

この問題は、プロジェクトのビジネスコンテキストを伝達する上で特に重要です。多くの場合、リモートコミュニケーションは、今週構築する必要があるものといった戦術的な詳細に焦点を当てすぎています。しかし、多くの技術的な意思決定にはより広い戦略的なコンテキストが必要であるため、リモートチームがプロジェクト、およびビジネスが目指す方向性について、より広い全体像を把握することが重要です。

このようなコミュニケーションは、オンサイトプロジェクトでは、特にビジネスとテクノロジーの間に多くの組織的な障壁がある場合には、しばしば欠落しています。リモート開発チームは、分散開発がほとんどのコミュニケーションの困難を悪化させるのと同様に、この問題を悪化させます。