分散ロケーションにいるスクラムチームのコミュニケーション
タイトルのテーマで Sleeek Blog で記事を書いたのですが(まだ公開はされていません)、スクラム初心者向けに文章を大幅に書き直してしまったので、こちらでオリジナルの文章をポストしておきたいと思います。ついでに日本語に訳しておきます。Google 翻訳ベースですので、多少読みにくくてすみません。。。
Sleeekは、リモートチームをより良く機能させるためのツールであると考えています。実際、Sleeekの開発チームは分散しています。プロダクトオーナー、UI / UXデザイナー、BizDevチームは、カリフォルニア州オレンジカウンティにいます。エンジニアチームは東京オフィスにいて、一部はホームオフィスで働いていますし、ベトナムのチームとも協業しています。しかし、最初に断っておきますが、私は、分散チームやリモートワークの伝道師ではありません。 ここで、 INSPIREDの文章を引用 させてください (私はこの本の大ファンです)。
"他のすべての条件が同じであれば、一箇所にまとまったチームは、分散したチームよりもはるかに優れている。それは否定のしようがない。" マーティ・ケーガン, INSPIRED
10年以上のプロジェクトマネジャー経験から、私はこの意見に完全に同意できます。リモートチームには、単一ロケーションチームと比較して様々なオーバーヘッドが存在します。また、単一のロケーションに集まることでイノベーションが起こる可能性が増えます。コーヒールームでのカジュアルな会話の間に何かが起こるかもしれません。シリコンバレーの技術大手であるAppleが、1つの大きなキャンパスにすべての従業員を集めることにこだわっている理由を考えてみてください。
ここまでの文章が記事のタイトルと一致しないことわわかっています。本題にいきましょう。私は単一ロケーションチームの持つ大きな価値を理解していますが、現実には1つのオフィスでチームメンバー全員が働くのは難しくなってきています。少なくとも私のチームにとっては、単一ロケーションチームであるよりも、分散チームのメリットの方が "やや" 大きいと考え、今のチーム構成をとりました。とはいえ、すべての物事には長所と短所があります。分散チームの長所は次のとおりです。
- 24時間体制でプロジェクトに取り組むことができます
- 競争の少ない市場で強力な人材を見つけることができます
- サンフランシスコの残酷なオフィス賃料を支払う必要はありません
もちろん、短所は単一ロケーションチームの価値の逆です。オーバーヘッドが多く、イノベーションの可能性が少ないといえるでしょう。また、チームがスクラム開発を採用している場合、スクラムは基本的に単一ロケーションチーム向けであることも考慮する必要があります。あなたがスクラム開発の経験がある場合、スクラムは多くのコミュニケーションプロセスによって構成されていることを知っているでしょう。この記事では、分散したチームメンバー間のコミュニケーションを改善する方法に焦点を当て、いくつかのアイデアを提案します。さまざまな場所にいる全員が、プロジェクトのステータスを同じように把握することが重要です。
ちなみに以下でコミュニケーション手法を 同期/非同期 でカテゴリ分けするのは、サイボウズさんのこちらの記事からヒントを得ました。
1. 同期通信
最初のトピックは、電子メール、電話、テキストチャットなどの同期通信を改善する方法です。分散メンバーが同じタイムゾーンにいるなら、これはそう難しいことではありません。隣にいる人に話しかけるのと比較して、アクションが一つ (Slackアイコンをクリックするとか、電話を取る) 余計にかかるだけです。この余計なワンステップをなくすために、あるプロジェクトチームは「仮想窓」を使用して、2つの異なる場所をビデオ会議ソフトウェアで常時接続しているそうです。我々Sleeek も東京とアーバイン市をつなぐ "窓" の導入を検討しています。
チームメンバーの一部が異なるタイムゾーンにいる場合、状況は少し難しくなります。重要なのは、ローカルチームとリモートチームの両方が同時にそれぞれのオフィスにいる「オーバーラップ時間」です。同期通信を増やすために、オーバーラップ時間をできるだけ長くすることをお勧めします。例えば、あなたがカリフォルニアにいて、リモートチームはアジアにいるのであれば、あなたの作業開始時間を少し遅くし、リモートチームに少し早く始業するように要求する必要があります。
すべてのスクラムイベント(デイリースタンドアップ、スプリントレビュー、スプリント・レトロスペクティブ、スプリントプランニングなど) を、オーバーラップ時間の適切な時間にアレンジしてみましょう。デイリースタンドアップは朝のルーチンである必要はありません。会議時間は、一部のメンバーに苦痛を与えるべきではありません。各メンバーのステータスを定期的に共有することは、「朝の会議」に固執するよりもずっと重要です。また、リモートチーム特有のメリットとして、進行中のタスクを引き継いでもらって、始業したばかりのチームが他のチームが中断したところから再開できます。
私は毎日のデイリー・スタンドアップが本当に好きで、やる気を引き出してくれると思っています。ただし、分散チームの場合、デイリー・スタンドアップのコストは、単一ロケーションチームよりも少し高くなります。チームメンバーの参加へのモチベーションが落ち、他人の報告を聞くことに集中できていないように思われる場合は、会議の数を減らしましょう。デイリー・スタンドアップは、文字通り「毎日」である必要はありません。 GeekBotなど、Slackでテキストベースの毎日のスタンドアップを行うためのツールがいくつかあります。 Sleeek の機能の1つである日報の自動生成 も、優れた代替オプションです。そのようなツールをデイリー・スタンドアップの代わりに週に数回試すことをお勧めします。
2. 非同期通信
分散チームにとって、非同期通信は同期通信よりもはるかに重要かもしれません。非同期通信の例は、Wikiページ、Issueのdescription/コメント、プルリクエストのdescription/コメント、および共有ドライブ内のその他のドキュメントです。これらのドキュメントは、異なるタイムゾーンの各メンバー間の意識ギャップを埋める役目を果たします。 プロジェクトチームを管理し、全員が同じ状況を把握できるようにするために、ドキュメントが重要であることは誰も疑いません。チームWikiページに、チームのビジョン、ミッション、およびポリシーをまとめておくことは良いアイデアです。すべてのチームメンバーは、重要な情報にいつでもアクセス可能であるべきです。新人にとって、このようなWikiページを読むことは、チームに定着するための最良の出発点であるはずです。 1つの場所の参加者のみで行われる会議では、議事録を残し、決議事項を他のロケーションのメンバーと共有しましょう。
また、プロジェクトマネージャーとして、ソースコードの品質とコメントの品質の両方に注意を払う必要があります。ソースコードの品質については、コードレビューが重要です。別の場所にいるエンジニアが書いたコードをレビュー(およびその逆) することは、技術的な詳細を共有するのに役立ちます。次に、コメントの品質は、開発ツールへの各入力をいかに正確にするかにかかわっています。開発ツールへの各入力とは、例えば、課題管理ツール（JIRA、Trello、ZenHubなど）のイシューの説明/コメント、またソースコード管理ツール（GitHub、Bitbucket、GitLabなど）のコミットコメント/レビューコメント等です。 イシュー作成やコミットコメントのフォーマットに関するチームポリシーを作成しておくと役立ちます。Sleeek でも、Sider によるソースコードの品質向上だけでなく、自然言語であるコメント自体の品質を向上するための機能を提供できないか検討しています。
3. 対面コミュニケーション
Slack、Jira、GitHub、Zoomなど、様々な通信プラットフォームによって世界は縮小されました。しかし、リアルの対面コミュニケーションはオンラインよりもはるかに生産的であることは容易に想像できます。 米国とアジアなどを頻繁に往復するのは金銭的にも体力的にも簡単なことではありませんが、特にプロダクトマネージャにとってはそのコストに見合う価値があります(と思って、頑張ってやっています)。
