スクラムチームを超生産的にするためのパタン・ランゲージ
こんにちは。天野です。
スクラムの生みの親であるジェフ・サザーランド博士らが2014年に出した論文 ”Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams” の存在を知り、読んでみました。
この論文の中で、ハイパープロダクティブ（超生産的）チームを体系的に生み出すためのパタン・ランゲージとして、9つのパタンが紹介されています。これがとても興味深く学びがあったので、ざっと紹介しつつ所感を書いてみたいと思います。
パタン・ランゲージとは
パタンとは、建築家のクリストファー・アレグザンダーが考案した概念です。ひとつのパタンは、特定のコンテキストで発生する問題に対して、繰り返し適用可能な解決策を表します。
あるパタンが別のパタンの前提条件になるなど、複数のパタンがお互いに影響を与えることで、文法が形成され、一連の並びはパタン・ランゲージと呼ばれます。
Scrum PLoPでは、スクラムの実践者によるパタン記述が継続的に行われています。公開されたパタンはオンラインで読むこともできるほか、書籍としても出版されています。
The Patterns
ハイパープロダクティブチームを体系的に生み出すため9つのパタンはこちらになります。
1. Stable Teams
2. Yesterday's Weather
3. Swarming: One Piece Continuous Flow
4. Interrupt Pattern: Illigitimus Non Interruptus
5. Daily Clean Code
6. Emergency Procedure
7. Scrumming the Scrum
8. Happiness Metric
9. Teams that Finish Early Accelerate Faster
最初の2つのパタンは、チームがスプリントを成功させるための準備をするものだそうです。パタン3〜6は、一般的な問題に対処するためのものになります。パタン7・8は、パタン9を副次的に導くものだそうです。
1〜8のパタンを適用することで、チームはパタン9に到達し、結果としてハイパープロダクティブチームが生まれる、という流れになります。
それでは、各パタンを順番に見ていきます。
チームが準備を整えるためのパタン
1. Stable Teams (安定したチーム)
ざっくり要約（詳細は上記リンク先を参照してください）
プロジェクトマネジメントでは、問題を解決するために「リソースマネジメント」がよく行われる。人を多く移動させると、さまざまなコストが発生する：
- 作業内容を把握するための管理業務
- チームのメンバー統合と業務の学習が必要になることによる効率低下
- ブルックスの法則にさらされる（遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせる）
それゆえ：チームを安定させ、チーム間での人の入れ替わりを避ける。安定したチームは自分のキャパシティを把握する傾向があり、ビジネスにある程度の予測可能性を持たせることができる。チームメンバーを可能な限り一つのチームに専念させる。
安定したチームのメンバーは、お互いを知ることができる。メンバーは、互いの仕事のスタイルを体験し、一緒にできる仕事の量を学習する。安定したチームは、親しみやすさと相互の期待に応える一貫性を増し、信頼の共同体を発展させるようになる。
おなじみの話だと思いますが、本当に重要だと改めて実感します。第一のパタンとして挙げられるほど、すべての土台になるのが安定したチームです。最近の自分の活動を振り返ってみても、安定したチームで活動するための環境を整えることがすべてだと感じます。
2. Yesterday's Weather (昨日の天気)
ざっくり要約（詳細は上記リンク先を参照してください）
自尊心のある個人やチームは、自分に対してどんどん高い目標を設定するのが人間の性である。チームが過度に野心的になるのも人間の性で、結果、自分自身や利害関係者を失望させないために近道をしたり、期待したものを提供できなかったりする。
自ら設定したパフォーマンスへの挑戦は、特に短期的には成果を上げることができる。しかし、このような高いレベルは、長期的には維持できず、パフォーマンスは元のレベルに戻ってしまうのが一般的である。
それゆえ：ほとんどの場合、前回のスプリントで完了した見積もりポイントは、次のスプリントでチームが完了する見積もりポイント数を高い信頼性で予測することができる。
チームは、次の開発期間と条件に適した作業を選択することで、ステークホルダーの期待を管理することができる。ベロシティは平均値と標準偏差を持つ統計量なので、チームの約半分は「昨日の天気」に足りず、約半分がそれを上回ると予想する必要がある。目標は、ベロシティのばらつきを減らすようにプロセスを改善することである。
昨日の天気を活用することで、高い目標と持続可能なペース、ステークホルダーの期待値調整、継続的なプロセス改善などを作り出すことができます。正直なところ、このパタンは「はいはい、ベロシティのことでしょ？」とあまり重要に考えていなかったのですが、こうして見ると確かに多くの要素の土台になるコアプラクティスだと思いました。
チームがスプリントを終わらせるためのパタン
3. Swarming: One Piece Continuous Flow (スウォーミング)
ざっくり要約（詳細は上記リンク先を参照してください）
一度に多くのことに取り組むと、個人の効率、チームのベロシティ、企業の健全性が極端に低下することがある。もし全員が個々に自分の仕事に取り組んでいたら、お互いに助け合うことも、長期的にお互いから学ぶこともない。
それゆえ：プロダクトバックログの1つの項目にチームの最大限の努力を集中させ、できるだけ早く完了させる。この項目を担当する人は、チームのキャプテンである。全員が可能な限りキャプテンを助けなければならず、誰もキャプテンを邪魔してはならない。キャプテンがDoneになったらすぐに、次のバックログ項目に責任を持つ人がキャプテンになる。
このパタンは、チームの力を結集してビジネス価値を提供するために、ベロシティを最大化することを目的としている。チームのアイデンティティを個人ではなくチーム全体に集中させることで、スウォーミングを促進させることができる。このパタンを導入することで、チームは一個流しのフローに移行する。トヨタは、これが生産能力を最適化することを実証した。
スウォーミングのパタンです。リンク元には、コンテキストスイッチによる悪影響や、トヨタ生産方式の話などが詳しく紹介されています。PBIごとにキャプテンを決めるというのは、面白いと共になるほどと思いました。キャプテンはPOではなく、モブプロにおけるドライバに近い概念だと思いますが、PBIごとに決めることで、場当たり的でない作業計画を立てたり、リーダーシップを発揮して素早く仕事を完了させられる効果があると思いました。
4. Interrupt Pattern: Illigitimus Non Interruptus (割り込みバッファ)
割り込みのパタンです。元のパタン名が Illegitimi non carborundum という擬似ラテン語のフレーズから来ているようで、 "Don't let the bastards grind you down (野郎どもに負けるな！)" と英訳されるそうです。
ざっくり要約（詳細は上記リンク先を参照してください）
スクラムチームは多くの利害関係者にサービスを提供しており、スプリント中に優先順位が変わったり、現場で問題が発生したりして、スクラムチームの作業が中断されることがよくある。営業やマーケティングの要求と経営陣の干渉が重なると、チームの慢性的な機能不全を引き起こす。
それゆえ：割り込みのための時間を明示的に割り当て、割り当てた時間内に収まる以上の作業を許可しない。もし作業が割り当てを超えたら、スプリントを中断する。
生産を阻害しないよう組織を自己組織化させるために、3つのシンプルなルールを設定する：
1. チームは過去のデータにもとづき、予期しないアイテムのためにバッファを作る
2. すべての瑣末でない要求はトリアージのためにPOを通す。いくつかの重要なアイテムは、POが割り込みバッファに追加する。
3. バッファがオーバーフローしたら、チームは自動的に中断し、スプリントを再計画しなければならない。POはマネジメントに日程がずれることを通知する。
さらに良いことに、バッファが満杯にならなくなると、チームは早期に終了し、バックログから前倒ししたり、阻害要因を取り除く作業ができるようにな。さらに、もしチームが「昨日の天気」を使ってバッファのサイズを決め、バッファがほとんど一杯にならなければ、バッファのサイズは継続的に小さくなり、割り込みの問題は解消される。
割り込み処理のための時間を確保しておき、それ以上の時間を使わないようにするというパタンです。やること自体には特に不思議な点はありませんでしたが、バッファがどう変化するかの記述がとても興味深かったです。常に一定量をバッファとして確保するのではなく、バッファが使われなくなったら早期終了＋改善により加速することと、さらに「昨日の天気」にもとづいてバッファサイズが縮小することが書かれています。このパタンによって、チームは割り込みに計画的に対処しつつ、プロセスを継続的に改善することが可能になるんですね。
5. Good Housekeeping (グッド・ハウスキーピング)
もとのパタン名は "Daily Clean Code" ですが、現在は Good Housekeeping というタイトルで公開されています。
ざっくり要約（詳細は上記リンク先を参照してください）
作業環境がごちゃごちゃしていると、どこから何を始めたらいいのか、時間とエネルギーをロスしてしまう。後片付けを先延ばしにすると、後片付け作業が蓄積され、進捗が滞る。このような混乱は、ベロシティや品質を製品急激に低下させる。
それゆえ：完全にクリーンなプロダクトおよび作業環境を常に維持するか、または、毎日の終わりに清掃する。
作業環境がきれいだと、何をすればよいかが一目瞭然になり、タスクの流れがスムーズになる。製品は毎日Doneの状態でなければならない。グッド・ハウスキーピングとは、自分だけでなく、他の人の汚れもきれいにすることである。このアプローチは、アジャイルチームの原則である技術的な卓越性への継続的な注意の重要な部分を占めている。
これはボーイスカウト・ルールと同じものですね。製品と作業環境をきれいに維持することが難しい場合は、製品、設計、または作業環境に深刻な問題があることを示している可能性があります。基本的なパタンですが、常にクリーンな状態を保つには技術的な成熟が欠かせないので、後半のこの位置に来ているのかなという印象を持ちました。
6. Emergency Procedure (緊急時対応手順)
ざっくり要約（詳細は上記リンク先を参照してください）
スプリントの途中で、突発的な要求や予期せぬ変更により問題が発生する。問題を迅速に特定し、迅速に対応することは、アジリティの精神の基本である。
スプリント機能不全の原因は数え切れないほどあるが、このパタンは主に一般的な問題の上位3つに焦点を当てている：
・緊急の要求
・技術的な問題
・重要な人材や能力の喪失
チームは、うまくいっていないときは、プロダクトオーナーに相談しなければならない。それだけでなく、スプリントゴール達成に影響する大きな問題に迅速に対処する方法について、プロダクトオーナーと合意しておく必要がある。
それゆえ：バーンダウンが下がらないときは、パイロットが日常的に使うテクニックを試す。悪いことが起きたら、その問題に対して特別に設計された緊急手順を実行する。
スクラムの緊急時対応手順：（必要な分だけ実施する）
1. チームの仕事のやり方を変える。何か違うことをする。
2. 助けを求める。通常、バックログを他の誰かに譲ることによって。
3. スコープを縮小する。
4. スプリントを中止し、再計画する。
5. 緊急事態がリリース日にどのように影響するかを経営陣に報告する。
このパタンは、非常に規律正しいチームが使用することを想定している。もしチームがこれを頻繁に使用し、価値、品質、納品率が向上しない場合、そのチームは環境やスクラムの使い方に何か根本的な問題がないかどうか考えるべきかも知れない。
このパタンは、非常に規律正しいチームで使用することが想定されている点が新鮮でした。改善を積み上げ、十分に加速しているハイパフォーマンスチームは、ある程度のリスクを背負ったエクストリームスポーツとしてスプリントに着手します。そのようなチームが、緊急の要求や技術的な問題に対処するためのパタンなんですね。
確かに、経験値の低いチームでこのパタンを実施すると、スプリントの途中でスコープを見直したり再計画することで、甘やかすような対応になってしまいます。経験値の低いチームには、最後までやり切って失敗してもらい、レトロスペクティブで振り返った方が健全な成長を期待できそうです。
超生産的な状態を達成するためのパタン
7番目以降のパタンは、これまでのパタンの利点を活かし、チームがハイパープロダクティブ（超生産的）な状態を達成するためのパタンになります。
7. Scrumming the Scrum (スクラムをスクラムする)
ざっくり要約（詳細は上記リンク先を参照してください）
スクラムチームのうち、パフォーマンスと価値創造能力の根本的な新しいレベルへのパラダイムシフトを実現するのは、ごく少数に過ぎない。これは、ほとんどのチームが障害を特定し、取り除くことができないからである。
困難な障害は、時に極めて集中的な努力を必要とする。多くの障害に一度に取り組むと、成果は少なく、チームの士気を低下させる。
それゆえ：スプリントレトロスペクティブで最も重要な障害を1つ特定し、次のスプリントが終了する前に除去する。最優先の障害を取り除くには、それをタスクとしてスプリントバックログに入れ、受け入れテストを実施する。そして、スプリントレビューで評価する。
最優先の障害に集中することで、最優先の障害への集中を失うことなく、他の優先順位の高い障害も取り除くためにチームが自己組織化するという副次的な効果が得られる。
このパタンは、継続的に効率を高め、持続的に高い作業能力を確保するもので、ベロシティで測定することができる。
レトロスペクティブで設定したアクションを、次のスプリントバックログに入れるのは自分もやっていたので、「これ、Scrumming the Scrumって言うのか！」と目から鱗でした。
自分の認識と違った点は、このパタンは障害を除去することでスループットを高めることにフォーカスしている点です。そして、受け入れ条件とベロシティにによって効果を測定しています。
8. Happiness Metric (幸福指標)
ざっくり要約（詳細は上記リンク先を参照してください）
レトロスペクティブなどの活動では、一般的に多くの改善案が出る。ベロシティ向上に役立つとされるアイデアの長いリストを思いつくのは自然なことである。選択された改善は、実際には速度をまったく向上させないかも知れないし、もし向上させたとしても、最も重要な改善ではない可能性がある。
私たちは一般的に、人は自分の仕事をうまくこなすことで大きな満足感を得られると考えている。しかし、それ以上に重要なことは、人々はしばしば、どんなことが自分をより効果的にするのか、どんなことが自分の邪魔をしているのかを理解することができるということである。
それゆえ：チームの合意によって選択された、一度に一つの小さな改善で、改善プロセスを推進する。チームに質問を投げかけ、テーブルの上にある選択肢のうちどれが最もチームの情熱や参加意識を引き出せるかを考えさせ、その答えを使って、チームを最も活気づけるカイゼンを選択する。チームは、次のスプリントでその項目に取り組むことを（自分自身に）コミットする。
多数決や誰かの決定ではなく、合意形成に導くことが重要である。ここで重要なのは、チームがコントロールできていると感じることであり、その感覚を損なうものは、このパタンを機能させる核心に触れるものである。結局のところ、これはチームの自律性を引き出し、増幅することである。
Happiness Metricは名前は知っていましたが、改めてリンク先のパタンのページを読むと、めちゃくちゃ長いことに驚きました。長い理由も書かれており、幸福を指標にすることが何を意味していて、どのように機能するかについて、広く誤解されているのだそうです。
単に幸福度を点数で評価して、点数が上がるようにすればパフォーマンスが上がるということではありません。個人の幸福だけに着目して改善に取り組んだ結果、ベロシティが低下した事例が紹介されているように、パフォーマンスと幸福度には相関関係はありますが、因果関係ではないのです。
そこで、個人を超えた何らかの目的との結びつきが必要です。チームのメンバーは何らかの価値観を共有し、外向けの最も価値があることに向けて、焦点を合わせる必要があるのです。
チームが自分たちの運命をみずからの手に委ね、強い自律性を発揮し、共通の目的に向けて情熱を持って取り組む状態が、このパタンで実現したい「幸福な状態」なのだと理解しました。
また、Scrumming the Scrumで改善案の優先順位づけをするためにHappiness Metricを使う、という実装例も紹介されており、なるほどと思いました。
9. Teams that Finish Early Accelerate Faster (早く終わらせるチームは早く加速する)
ざっくり要約（詳細は上記リンク先を参照してください）
スプリントに仕事を詰め込みすぎると、チームはプレッシャーを感じ、終わらせることができず、不幸になる。ノコギリの刃を研ぐ時間を取れず改善も進まない。
それゆえ：スプリントに入れる作業量を前回のスプリントよりも小さくし、より控え目なスプリントゴールを目指す。スプリントゴール（成果）の野心度は、作業のボリューム、コスト、期間に比例しない場合があることに注意する。
スプリントの早期完了時には次のスプリントのアイテムに着手することで、将来のベロシティを高めることができる。
レトロスペクティブでカイゼンを特定し、最優先で次のスプリントバックログに入れることで、加速の確率を高める。
早く終わらせることによってチームは、自分たちが何をしているのかをより明確に考えることができ、障害物を取り除き、次のスプリントのバックログを前倒しし、勝利への姿勢を身につけ、ベロシティを高めることができる。
スプリントの仕事を早く完成させることができると、チームの自己効用感が高まり、心の余裕が生まれ、障害物の除去や改善も進み、加速に繋がるということですね。短期的に見るとやるべき仕事を減らしているだけなのに、長期的には加速するというのは、何とも面白いなと思いました。
本論文で紹介されているのはパタン・ランゲージなので、ただ最後のパタンに従い仕事減らせば加速するというわけではありません。このパタンが成立する文脈を構築するために、他のパタンが必要になります。
所感
ハイパープロダクティブチームを体系的に生み出すため9つのパタンを紹介しました。
個人的な感覚ですが、5番目のグッド・ハウスキーピングくらいまでできればかなり練度の高いチームと言えそうです。パタンを積み上げる過程で、どのような文脈が形成されるのかは、正直実践してみないと分かりません。
現在自分が支援しているチームでは、できる限りこれらのパタンを実装しようと試しています。実験の結果はまたどこかで紹介してみたいと思います。どんな結果になるのか楽しみです。
最後まで読んでいただきありがとうございました。本記事は定期購読マガジン「スクラムマスターの頭の中」で執筆した記事を再編したものになります。毎週更新しているので、よければ購読よろしくお願いします。それでは！
ありがとうございます。書籍代に使ったり、僕の周りの人が少し幸せになる使い道を考えたいと思います。