勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

アフターコロナ時代を想定して分散アジャイル開発について調べてみた(Agile Software Development with Distributed Teams)

ウィズコロナなのかアフターコロナなのかはよくわからないけど、今回の新型コロナ感染拡大の事態を踏まえて分散アジャイルについての勘所について整理しようと思って、いろいろな調べてみた。世の中にはTips集と精神論ばかりが溢れている気がする。知りたいのは戦術だ。先人たちの知見から学ぶことはあるのだろうか?

Agile Software Development with Distributed Teams: Staying Agile in a Global World

以前に「A Practical Guide to Distributed Scrum」という本を読んでいる(DAD本で紹介されていた)。
agnozingdays.hatenablog.com

この本は基本的に「複数のグローバルなサイトに分散されたチームでのスクラム」について書かれていたと記憶している(若干自信はない)。今回読みたいのはそうではなくて、チームのメンバーが自宅などそれぞれのワークスペースにいて、サイトに集合しないタイプの分散である(あとで触れるがこれは「分散されたチーム」という)。

というわけで今回は「Agile Software Development with Distributed Teams: Staying Agile in a Global World」を取り上げてみた。

著者のJutta Ecksteinさんは独立したアジャイルコーチで、一時期はAgile Allianceのボードメンバーだったこともあるようだ。なお、2013年の本であり、DevOps以前のコンテキストで書かれている点には留意する必要があるだろう。

Distributed Team(分散チーム)とDispersed Teams(分散されたチーム)

本書ではひとくくりにされがちな分散を二つに区分して取り扱っている。

  • Distributed Team(分散チーム)とは、複数のサイトに配置された複数のチームのことを指す。Dispersed Teams(分散されたチーム)は多くの場所で働く人々で構成された一つのユニットを指す。大規模なプロジェクトではこの混合となる。
  • Dispersed Teams(分散されたチーム)では、チームが小さくてもチームメンバー間の効果的なコミュニケーションを確保するために、高度な調整作業が必要になる。

なお本書ではどちらの場合も取り扱っているのだけれども、本記事では自分が興味を持っているDispersed Teams(分散されたチーム)の場合の考慮点のみに触れる。

Building TeamsとEstablishing Communication and Trust

アジャイル開発であれば当然でもあるが、鍵となるのは信頼の確立である。アジャイル宣言では以下のように解説されている。

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
アジャイル宣言の背後にある原則

というわけで、本書では以下の戦略の説明がある。

  • 最初の1-2か月間はメンバーが一緒に作業をする形として「チームを鍛える」
  • 信頼と関係性を構築した上で分散する
  • 確立した信頼関係はゆっくりと低下し8-12週程度で閾値を下回る。よって隔月や四半期ごとに集結して信頼関係を回復する必要がある

これは、非常によくわかる。現在リモートワークでうまくやっているチームがまわっているのは、おそらく以前にしっかりとした信頼関係が構築できているからなのだろう。これから新たにチームを組成した場合にはこの問題に直面すると思う。

新規チームを構築するのに、さすがに1-2ヶ月オンサイトで作業というのは厳しいだろう。とはいえ最初は数日の合宿、1週間くらいのリモートワークの練習、再度のオンサイトミーティングによる振り返り、といったサイクルでチーム構築を開始すれば良さそうな印象がある。その後は定期的にオンサイトの振り返りを実施するのがよいのではないだろうか。

Keeping Sites in Touch

本書ではオンサイトのアジャイル開発には存在しないいくつかの役割の追加やマネジメントに関するテクニックも紹介されている。

  • コミュケーションファシリテーターの配置
    • コミュニケーションに関する問題を発見、解決する責任を持つ役割を設置する
  • (文化の異なるグローバルに分散されたチームの場合)アンバサダーの配置
    • 文化の違いなどを緩和して、信頼関係を向上させる役割を設置する
  • MBWA(Management by walking around)の積極的実施
  • ソーシャルコネクションを強化するための施策の実施
    • プロジェクトに特別なイベントをつくる(リリースを一緒に祝う)
    • Wikiなどでの写真の積極的共有(自己紹介、旅行記など仕事に直接関係ないものを含む)

この点は強く共感。スクラムであればプロダクトオーナーやスクラムマスターといった役割があるけれども、分散されたチームではおそらく何らかのプラスアルファは必要なのだろう。エンジニアリングマネージャーがやるのか、チームメンバーを任命するのかなどの振れ幅はありそうだが、工夫は必ず必要だと思う。

というわけで、いろいろとヒントがあって面白かった。

なお本書はKindle版はAmazonでも購入できるが、契約していればlearning.oreilly.comでも閲覧することが可能である。