by Bas Vodde
この記事では、避けるべき手法と試してみる価値のある代替案を取り上げる。自分たちのチームが今どこに立っているのかを把握し、取り入れる価値のある協働の手法を見つける助けにしてほしい。
チームはどのように協力してプロダクトを作るのだろうか。自律的なチームでは、どう働くかはチーム自身が決める。とはいえ、すべてをゼロから考え出さなければならないわけではない。チームは他のチームがこれまでに得た経験から学べるし、学ぶべきである。私は、いくつかの共通した手法が現れるのを見てきた。この記事ではそれらを取り上げ、3つのカテゴリーに分類する。
より協働的な手法を勧めてはいるが、「協働のための協働」ではない。協働的な手法を好むのには理由がある。
ここからは、避けるべき手法と試すべき手法をいくつか見ていく。自分たちのチームの現状を評価し、実験してみる協働のやり方を選ぶ材料にしてほしい。
これらの手法は、知識のサイロ化、過度な専門特化、そして高いWIPを招くことが多い。一見すると生産的に感じられるが、それは個人のタスクだけを測った場合の話であって、システム全体のパフォーマンスで見ればそうではない。残念なことに、こうした手法は非常によく見られるため、これが普通で問題ないのだと思い込まれてしまっている。
スプリントの最初に、チームメンバーは自分が個人で取り組むアイテムを選ぶ。スプリント中は、それぞれがかなり独立して自分のアイテムに取り組む。
スプリント中のWIPは非常に高い。チームワークと学習は非常に少ない。
選んだアイテムを、ウォーターフォールのように逐次的に進める。多くの場合、UXデザイン → 実装 → テストという順序をたどる。チームの中には、これらの活動に対応する役割が明確に残っている。スプリント内で作業量に偏りが出るため、たいていUXの作業は実際のスプリントが始まる前（前のスプリント中）に行われ、テストの作業は次のスプリントで行われることになる。
これでは本当のチームも、本当のスプリントも存在しない状態である。
スプリント中のWIPは非常に高い。チームワークと学習は少ない。アイテムのリードタイムはたいてい3スプリントになる。
チームには専門特化したメンバーがいて、自分の専門分野から出ようとしない。よくある例はフロントエンド開発、バックエンド開発、DevOpsである。チームは各アイテムをタスクに分割し、各メンバーは自分の専門のタスクだけを取る。アイテムがまだ終わっていなくても、残っているタスクが自分の専門でなければ、その人は自分の専門が必要な次のアイテムに移ってしまう。
スプリント中のWIPは高い。チームワークは専門と専門の引き継ぎのときにしか起きないので、学習は少ない。
チームは、完成までに何スプリントもかかる大きなフィーチャーに取り組む。フィーチャーをスプリントに収まる縦切りに分割するのではなく、タスクに分割して何スプリントも先まで計画してしまう。実質的にスプリントを無視して、大きなプロジェクトのようにそのフィーチャーに取り組む。毎スプリント、形式上は次のタスクを取るだけである。スプリントは報告のための儀式でしかなくなる。
WIPは高い。スプリントの終わりにプロダクトが本当に出荷可能な状態にはならないため、リードタイムは長い。ユーザーからの早期フィードバックの機会もない。たいていは、大きなフィーチャーの自分の担当部分に一人で取り組むことになる。
チームのスコープが狭い。プロダクトの定義が小さいチーム、マイクロサービスがチームに対応付けられている場合、あるいは「フロントエンドチーム」のような場合である。バックログのアイテムには他チームの作業も必要になるため、チームはしばしばブロックされる。ブロックされると、他チームが自分たちの分の作業を終えるまで、別のアイテムに移ってしまう。
チームのスコープは組織的に決められていることが多く、これを変えるにはチーム構造の変更が必要になる（後述の「協働的な文脈」を参照）。チーム構造の変更が実施されていない場合、他チームのコンポーネントのコードを自分たちで変更することで、依存を少し軽くするチームもある。その場合、依存は「他チームが変更してくれるのを待つ」から「他チームがレビューして承認してくれるのを待つ」に変わる。
WIPが高く、アイテムは出荷可能な状態でないことが多い。
これらのチーム内手法は、メンバー間で仕事と文脈が共有された状態を作り、それがさらに協働を生む。これらの手法は、(1) WIPを減らして柔軟性を高め、(2) 知識の共有と学習を増やして知識のサイロ化を減らし、オンボーディングを速める。
同じタスク・同じ文脈に複数人が関わることが多いため、一見すると生産的でないように感じられるかもしれない。しかし、文脈が共有され知識が行き渡ることが、全体としてより良いパフォーマンスにつながる。
協働的なチームは、これらの手法からどれか1つを選ぶというより、好み、都合、すでに持っている知識、アイテムの複雑さなどに応じて、1つのスプリントの中で組み合わせて使うのが普通である。
スプリント計画2で、チーム全員がすべてのアイテムの設計と実装を詳しく議論する。これにより、各メンバーがそれぞれのアイテムについて何をすべきかを深く理解した状態（共通のイメージ）になる。そして、粒度の細かいタスク（たいてい数時間で終わる程度）を作り、それを作業の分担、見える化、同期に使う。チームはアイテムを1つずつ進めることにし、各メンバーは同じ1つ（あるいは少数）のアイテムのタスクを取る。チームは絶えず話し合い、作業を同期させる。これは継続的インテグレーションやトランクベース開発と特に相性がよい。チームが絶えず互いの作業を共有し合う必要があるからである（後述の「協働的な文脈」を参照）。
全員が個々に作業していても、チームの協働の度合いは高い。
WIPは低い。複数のタスクが同時に進んでいても、それらはすべて同じアイテムに属している。
デイリースクラムは、チームが責任を共有して自分たちの作業をマネジメントする場である。スプリント計画2で粒度の細かいタスクを作り、チームが緊密に働いている場合、1日に何度もデイリースクラムを行うことは珍しくない。デイリースクラムは手早い同期ポイントになる。ここまでに何をやったかを全員が共有し、アイテムに何が残っているかをチームで確認し、アイテムを終わらせてWIPを低く保つために誰が何を取るかを決める。
タスクの粒度の細かくして働くとスプリント中にメンバー間の調整がかなり多くなる。その結果、チームが2つのサブチームに分かれてそれぞれのアイテムに取り組むようになることがあるが、これはWIPを増やし協働を減らしてしまう。より良い代替案は、チームがペアプロを始めることである。チームは引き続き入念にスプリント計画2を行って粒度の細かいタスク（今度は少し大きめになるのが普通）を作り、各ペアが同じアイテムのタスクを取っていく。
WIPは低い。チームの協働と学習は、全員が一人で作業する場合よりも高くなる傾向がある。
チーム全員が1台のメインのコンピュータの前に集まり、同じタスクに同時に取り組む。1人（またはペア）がドライバーとなり、他の人は方向性を示し、考え、議論し、意見を出す。 ドライバー以外もコンピュータは使うが、主に着手中のアイテムに関する調べものに使う。 進行中のアイテムは常に1つである。 モブプロをするチームは、スプリント計画2を短くしたり省いたりすることが多い、なぜならそれぞれのアイテムに着手する直前に都度実施する事が多いからである。
開発とはほとんどがタイピングだと考えている人には、モブプロはばかげたことに思えるかもしれない。しかし開発の核心は学習と問題解決であり、これらは頭数が多いほうがうまくいく活動である。
WIPは常にアイテム1つだけ。チーム全員が同じタスク、同じ文脈だけに取り組むので、協働の度合いは極めて高い。
やり方はモブプログラミングに似ているが、全員が同時に同じ文脈に取り組むわけではない点が異なる。
チームは1台のメインのコンピュータの前に集まり、1人（またはペア）が取り組んでいるアイテムのドライバーになる。この人（ペア）が、そのアイテムの進捗の全体像を把握する。 他のメンバーは、同じアイテムのタスクに個人（またはペア）で取り組む。 メインのコンピュータにはアイテムの進捗の全体像が映し出され、細かなサイドタスクは同じ部屋にいる個人（またはペア）が進める。
WIPはたいていアイテム1つだけのままである。チームの協働の度合いは高いが、モブプログラミングよりは作業がやや並列化される。
チームとして緊密に働いていると、割り込みが入るたびにチーム全体が文脈を切り替えることになる。そのため、こうした働き方をしているチームは、急な依頼、緊急の不具合、他の人やチームへの説明といった割り込みに対応する担当を1人選ぶ（1人を犠牲にする）ことが多い。スプリントごとに、犠牲になる人を交代する。
これらの手法は、チームとチーム間で仕事と文脈共有の頻度を増やし、個々のチームに知識のボトルネックができるのを避けることをねらいとする。 チームのスコープ、知識、協働が広がれば、個々のチームの専門性に縛られることなく、本当にビジネス価値の順に働けるようになる。
複数チームで働くときは、複数チームでのスプリント計画の前にチームが自分たちのやることを決めてしまわないようにする。チームが「事前選択」をしてしまうと、複数チームでのスプリント計画は協働の場ではなく、自分のチームが欲しいアイテムを確保する場になってしまう。 どのチームがどのアイテムをやるかを完全に開いたままにしておくと、どのチームがどのアイテムを取るのが一番よいか、どう助け合えるかというチーム横断の議論が生まれる。 これがうまく機能するには、チームは優先順位の順にアイテムを取る必要があり、その優先順位は（現在のチームのスキルや都合ではなく）重要度によって決められている必要がある。
事前選択をしないからといって、チームがどのアイテムに着手したいという希望を持てないわけではない。希望は持ってよい。ただし、協働が前提とならなければならない。
この手法は、チームが自分たちの領域に閉じこもるのを避け、複数チームでの協働を増やす。プロダクト全体思考を生み出すのである。
依存関係の最大化とは、スプリント計画において、密接に関連するアイテムをあえて別々のチームが選ぶことである。 これは、似たアイテムを1つのチームがまとめて取り、独立して進められるようにするという一般的なふるまいの逆である。 依存関係を最大化するとき、チームは密接に関連するアイテムを複数のチームに分散させることで、チーム横断で協働する機会（学習のため、楽しさのため、知識のボトルネックを減らすため）を探すことになる。
同じ作業の文脈を共有すると、チーム横断の協働は大きく増える。ほとんど1つのチームのようになる。
作業があまりに強く関連しているために、チームが本当に1つのチームとして働くことを決め、1スプリントの間だけ2つのチームを1つの大きなチームに統合することがある。これには、非常に大きなチームになることに伴う難しさもついてくる。 一時マージをする場合は、チーム横断での知識共有を最大化するために、チームをまたいだペアプロもあわせて行うのが普通である。
チームがプロダクト全体にまたがって働くときは、プロダクトの設計とアーキテクチャについて共通の見方を持ち、どのチームがシステムのどこを触るのかを知っておくと役に立つ。 それをねらうのが、複数チームでのスプリント計画2である。 全チームが一緒にスプリント計画2を始め、現在のアーキテクチャと、今回のスプリントでどのチームがどこを触るのかを議論する。このアーキテクチャの共有議論の後、各チームは同じ場所でそれぞれのスプリント計画2を行う。こうすることで、チーム間で素早く同期を取る機会が生まれる。
スプリント計画1でアイテムを選ぶとき、あるチームが他チームの人の知識を必要とすることはよくある。それを得る最も簡単な方法の1つが、その人（時にはチーム全員）が相手チームのスプリント計画2に参加することである。 そこで一緒に、知識を必要としているアイテムを見ていく。その後、訪問した人たちは自分たちのスプリント計画2に戻る。
トラベリングとは、あるチームのメンバーが、少なくとも1スプリントの間、他のチームに（コンサルタントとしてではなく）通常のメンバーとしてフルタイムで加わり、その後元のチームに戻ることである。トラベリングによって、意図した知識共有も偶然の知識共有もチーム間で起こり、チーム横断のより緊密な協働につながる。
大きな学習を必要とする新しいロードマップ項目に着手するとき、あるいは（外部との）コミュニケーションが多く発生するときには、その責任を1つのチームが複数スプリントにわたって明示的に引き受けることがある。このチームがリーディングチームとなる。 リーディングチームは、そのアイテムの進捗、他チームへの学習の展開、（外部との）調整について全体像を把握しておく。
この手法は諸刃の剣であり、他の解決策を優先すべきである。 リーディングチームは、過度な専門特化を招いたり、他のチームが「自分たちのアイテムではない」と感じて力を奪われたように思ったりすることが今なおある。必ずそうなるわけではないが、こうした力学には注意が必要である。
協働的な手法は協働的な文脈の中でこそ成功する。周囲の文脈が協働を支えていなければ、同じ手法でも失敗する。 何が協働的な文脈を作るのかというテーマは、それだけで1本の記事、あるいは1冊の本、あるいはシリーズものの本になるだろう。 ただし、私が特に影響が大きいと感じている点がいくつかあるので、この記事で触れておきたい。 それらは技術的手法、チーム構造、マネジメントのふるまいに関わるものである。
継続的インテグレーション（トランクベース開発）、テスト駆動開発、継続的なリファクタリングといったアジャイルなエンジニアリング手法の導入は、チーム内でより緊密に協働するために不可欠である。 これらの技術的手法とチームの協働のパターンは互いに強化し合う。 どちらもエクストリームプログラミングという同じ発祥を持つことを考えれば、驚くことではない。 技術的手法とチームの力学の関係についての考察は、 技術的手法とスクラムについての講演で見ることができる。
特にチーム横断の協働の手法は、チームをまたいだコードの共同所有を通じた文脈の共有を前提としている。 多くの組織はアーキテクチャに合わせてチームを配置し、結果としてチームがコードの一部分を所有することになる。 これはコンポーネントチームと呼ばれる。 協働的なチーム横断の手法の節では、複数のコンポーネントにまたがってコードの所有を共有するエンドツーエンドチーム、あるいはフィーチャーチームが採用されていることを前提とした。これにより、チーム間で文脈がより共有され、協働と学習が増える。 このテーマの基礎的な事については チーム間の依存関係を最大化するにて詳しく説明している。
チームは、顧客との約束や期限を守るよう強いプレッシャーを受けることが多い。 現実のプロダクト開発の多くには本物の期限や約束が存在するが、チームにプレッシャーをかけたところで、それを守れる可能性が上がるわけではない。 プレッシャーをかけると短期的な効率に目が向き、システム全体の効率よりも個人主義的な働き方に傾いてしまう。 適切な優先順位付けによってチームへの期限のプレッシャーを取り除くことが、協働と学習の環境を作る。 プレッシャーによってスコープを最大化しようとするこの力学は、「契約ゲーム」と呼ばれることがある。
この記事では、協働とそこから生まれる相互学習を促すもの・妨げるものについて、チーム内とチーム横断のさまざまな手法を見てきた。そこで気づいたことは次のとおりである。
これらの手法は、それぞれをきちんと説明し、効果的な使い方を示すのに記事1本分が必要である。 それはこの記事の範囲を超える。 その代わりに、チームにはこれらの違いを理解し、より協働的なやり方へと切り替えていくことを勧めたい。そうすることで、学習と成長が増え、組織の柔軟性が高まり、仕事はもっと楽しくなる。
RSS feed