リモートでのアジャイル開発のコミュニケーション

　こんにちは！フィックスターズのグループ会社、株式会社スリークの浅原です。新型コロナウィルスの影響で今月からリモートワークを始められた方も多くいらっしゃるかと思いますが、ソフトウェアの開発にはコミュニケーションがつきものです。特に最近採用例の多いアジャイル開発ではコミュニケーションが重視される為、リモート環境で上手にアジャイル開発を回すのは簡単ではありません。
　今回は分散ロケーションでのアジャイル(スクラム)開発を4年以上おこなってきた私の経験から、分散環境でのコミュニケーションにおける要点をまとめました。経験豊富なスクラムマスターであれば当たり前のこともあるかもしれませんが、少しでも皆さんの参考になればと思います。

　スリーク社では、ソフトウェア開発プロジェクトの生産性向上の為のサービス Sleeek（スリーク）を開発しています。Sleeekは、ソフトウェア開発の現場で利用される各種サービス(JIRA, GitHub, GitLab, Slack, など)から情報を取得し、時にはメンバーとインタラクティブにコミュニケーションをとりながら、開発進捗やボトルネックなどをわかりやすく表示し、何をすればプロジェクトがスムーズに進むのかをアドバイスしてくれる開発支援サービスです。このサービスの開発自体が

• カリフォルニア: プロダクトオーナー、UI / UXデザイナー、BizDev
• 東京: コア開発
• ベトナム: 現行バージョンのQA、次世代機能の調査

の3か所にまたがった分散スクラムチームで行われています。また、私の前職であるFixstars Solutions (フィックスターズのUS子会社) でも、

• 北カリフォルニア: 顧客担当Project Manager
• 南カリフォルニア: 本社
• ボストン: ライフサイエンス関連開発チーム
• ビクトリア(カナダ): 組み込み開発エンジニアチーム

の分散環境で運営されていました。

　さて、まず最初にお話ししておきたいのは、私はなにも分散チームやリモートワークの伝道師ではないということです。ここで、私の愛読書であるINSPIREDから一節を紹介させて下さい。

他のすべての条件が同じであれば、一箇所にまとまったチームは、分散したチームよりもはるかに優れている。それは否定のしようがない。

マーティ・ケーガン, INSPIRED

　私は10年以上プロジェクトマネージャを経験してきましたが、これは本当にそのとおりだと思っています。 リモートチームには、単一ロケーションチームと比較して様々なオーバーヘッドが存在します。 また、メンバーが一か所に集まることでイノベーションが起こる可能性が増えます。休憩時間にコーヒーを飲みながらする雑談から何かが起こるかもしれません。テクノロジーカンパニーとして有名なAppleが、シリコンバレーに大きなキャンパスを作り、多くの従業員をそこに集めることにこだわっているのには、このようなメリットがあるからでしょう。

　以上のように私は単一ロケーションチームの持つ大きな価値を理解していますし、実感してきました。しかし、現実にはさまざまな理由からひとつのオフィスでチームメンバー全員が働くのは徐々に難しくなってきています。要はPros/Cons の問題です。私は、少なくとも”現時点の” スリーク社にとっては、単一ロケーションチームであるよりも、分散チームであるほうがメリットが “やや”大きいと考え、現在のチーム構成をとっています。私が考える分散チームの長所は次のとおりです。

• 24時間体制でプロジェクトに取り組むことができる
• 比較的競争の少ない地域で優秀な人材を見つけることができる
• サンフランシスコのような無慈悲に高いオフィス賃料を支払う必要はない

もちろん、分散チームの短所は単一ロケーションチームの価値の逆です。オーバーヘッドが多く、イノベーションの可能性が少ないといえるでしょう。さらに、スクラムを含むアジャイル開発は基本的に単一ロケーションチーム向けであることも考慮する必要があります。有名な「アジャイルソフトウェアの原則」を参照下さい。アジャイル開発は多くのコミュニケーションプロセスによって構成されているので、分散ロケーションでの実施には工夫が必要です。

　実際に分散ロケーションでのアジャイル開発を行っているなかで「さまざまな場所にいるメンバー全員が、プロジェクトのステータスを同じように把握すること」の大切さを何度も感じました。 以下では、私たちが実際におこなった分散したチームメンバー間のコミュニケーションを改善する方法をご紹介します。

1.同期通信

　最初のトピックは、電子メール、電話、テキストチャットなどの同期通信を改善する方法です。
　分散メンバーが同じタイムゾーンにいるなら、これはそう難しいことではありません。隣にいる人に話しかけるのと比較して、アクションが一つ (Slackアイコンをクリックするとか、電話を取る) 余計にかかるだけです。
　この余計なワンステップすらなくすために、あるプロジェクトチームは「仮想窓」を使用して、2つの異なる場所をビデオ会議ソフトウェアで常時接続しているそうです。我々も数時間ですが、東京とオレンジカウンティをつなぐ “窓” を導入しています。

　チームメンバーの一部が異なるタイムゾーンにいる場合、コミュニケーションの難易度は少し上がります。重要になるのは、ローカルチームとリモートチームの両方が同時にそれぞれのオフィスにいる「オーバーラップ時間」です。同期通信を増やすために、オーバーラップ時間をできるだけ長くすることをお勧めします。例えば、あなたがカリフォルニアにいて、リモートチームはアジアにいるのであれば、あなたの作業開始時間を少し遅くし、リモートチームに少し早く始業してもらいましょう。

　すべてのスクラム・セレモニー(デイリー・スタンドアップ、スプリントレビュー、スプリント・レトロスペクティブ、スプリントプランニングなど) を、オーバーラップ時間の間にアレンジしてみましょう。デイリー・スタンドアップは必ず朝に行うべし！　なんていうことはありません。アジアのメンバーに合わせる為に、アメリカのメンバーが夜中の打ち合わせに参加しないといけないなど、一部のメンバーに無理を強いるのは避けましょう。それによって、デイリーが徐々に行われなくなってしまう方が問題です。各メンバーのステータスを定期的に共有することは、デイリーを「朝」に行うことにこだわるよりもずっと重要です。

　私はスクラム・セレモニーの中で、デイリー・スタンドアップが本当に好きで、様々な良い効果があると思っています。しかし、分散チームの場合、デイリー・スタンドアップのコストは、単一ロケーションチームよりも高くなります。チームメンバーのデイリー参加へのモチベーションが落ち、他人の報告を聞くことに集中できていないように思われる場合は、回数を減らしましょう。デイリー・スタンドアップは、文字通りの「デイリー」である必要はありません。GeekBotなど、口頭の打ち合わせの代わりに、Slackでテキストベースのデイリースタンドアップを行うためのツールがいくつかあります。 Sleeek の機能の1つである日報の自動生成 も、優れた代替オプションです。そのようなツールをデイリー・スタンドアップの代わりに週に数回試してみてはいかがでしょうか。

2. 非同期通信

　分散チームにとって、非同期通信は同期通信よりもはるかに重要です。非同期通信の例は、チームのWikiページ、タスクの説明/コメント、プルリクエストの説明/コメント、および共有ドライブ内のその他のドキュメントです。
　これらのドキュメントは、異なるタイムゾーンの各メンバー間の意識ギャップを埋める役目を果たします。プロジェクトチームを管理し、全員が同じ状況を把握できるようにするために、ドキュメントが重要であることは誰しも理解しているところでしょう。チームWikiページに、チームのビジョン、ミッション、およびポリシーをまとめておくことは良いアイデアです。すべてのチームメンバーが、そのような重要な情報にいつでもアクセスできるようにしておきましょう。特に新しいメンバーにとっては、このようなWikiページを最初に読むことで、チームのやり方を学ぶことができ、チームに馴染むのが速くなります。
　1つの場所の参加者のみで行われる会議では、必ず議事録を残し、決議事項を他のロケーションのメンバーと共有することも大切です。GitLab 社の例では、すべての打ち合わせで動画と議事録を残し、必要な人がいつでもアクセスできるようにしているそうです。

　また、プロジェクトマネージャは、ソースコードの品質とコメントの品質の両方に注意を払う必要があります。ソースコードの品質については、コードレビューが重要です。別の場所にいるエンジニアが書いたコードをレビュー(およびその逆) することは、技術的な詳細を共有するのに役立ちます。コードレビューの重要性には疑問の余地は無いと思いますが、それでも私がインタビューしている中では、「なかなかレビューの時間を捻出できない」、「時間に追われて適当なレビューになってしまっている」という声を多く聞きます。 弊社が提供しているコードレビュー支援サービス「Sider」 は、コーディングスタイルやベスト・バットプラクティスをプルリクエスト毎に自動でチェックしてくれます。ソースコードの可読性や保守性を高めるために、Sider のようなツールを導入するのも一つの手です。

　コメントの品質は、開発ツールへの各入力をいかに正確にするかにかかっています。開発ツールへの各入力とは、例えば、タスク管理ツール（JIRA、Trello、ZenHubなど）のタスクの説明/コメント、またソースコード管理ツール（GitHub、Bitbucket、GitLabなど）のコミットコメント/レビューコメント等です。タスク作成やコミットコメントのフォーマットに関するチームポリシーを作成しておくと役立ちます。

　我々も今後、自然言語であるコメント自体の品質を向上するための何らかの機能を提供できないか、内部で検討しています。

3. 対面コミュニケーション

　Slack、Jira、GitHub、Zoomなど、様々なコミュニケーションプラットフォームによって世界はとても近くなりました。しかし、リアルの対面コミュニケーションはオンラインよりもはるかに生産的です。 アメリカとアジアを頻繁に往復するのは金銭的にも体力的にも簡単なことではありませんが、特にプロダクトマネージャにとってはそのコストに見合う価値があります(と信じて、私も頑張って出張しています。同じ立場の方、頑張りましょう！)。

　コミュニケーションはメンバーとの理解度合いやサポートしてくれるツールによって今後も変化していくものです。スリーク社もより良い方法を探して常にチャレンジしています。この記事に対するコメントや、こちらの問い合わせフォームからでも結構です。是非、みなさんのやり方も教えて下さい！

*　コミュニケーション手法を 同期/非同期 でカテゴリ分けするのは、サイボウズさんのこちらの記事からヒントを得ました。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。