はじめに
ログラスさんで取り組もうとしているFaST agileを下記の資料で知り、調べてみました。
FAST概要
"Fluid Scaling Technology (for Agile)"を標榜した、自己組織化を重視した軽量なフレームワークです。
日本語ガイドも公開されています。
FASTガイドより引用した概要図 (Per Beiningによる)
※ 以下「スクラムでいうXX」といった表現を避け、FASTガイドの文言をできるだけそのまま受け取ってみます
用語
コレクティブ
活動に必要な人全員を合わせてコレクティブにします。
コレクティブは自律的で、十分な権限を持ち、自己組織化していて、自己管理できる人達によるグループで、共通の目的のもとに集まり、プロダクトのディスカバリーとビジネスゴールの達成ができる能力を持ち合わせています。
ある目的のために集まった開発活動に必要な人全体を指して「コレクティブ」と呼びます。ある目的の粒度はフィーチャーやプロジェクトといった単位ではなく、プロダクトビジョンなど大きな粒度のような気がします。
コレクティブにはエンジニアだけでなくプロダクトマネージャーやデザイナーも含めるのでしょう。ステークホルダーも含めてコレクティブと呼ぶのかは分かりません。
コレクティブの参加者には「自己管理」が求められ、コレクティブは「自己組織化」してプロダクトのディスカバリーとビジネスゴールの達成のために「十分な権限」も持ちます。
ガイドには詳細の記載がありませんが、コレクティブに集まった面々は「セットアップ」と呼ばれる活動を行い、「目的・ミッション(ビッグピクチャー)」および「活動に対する理解と進捗」を可視化するワークショップを行うそうです。
バリューサイクル
以下の3ステップがバリューサイクルを構成します。3ステップを継続的に繰り返します。
1) 自己組織化する: ミーティングをファシリテートし、人々が自己組織化して活動を行うためのチームを形成できるようにします。
2) 活動する:各チームは、自身が集った活動アイテムのために計画し、協働します。
3) 同期する:短い周期でコレクティブはミーティングを開催し、学びを共有し進捗して、プロダクトの状態と現在の状況について共通の理解を得ます。
開発の区切りを「バリューサイクル」と呼びます。固定期間ではなく、ガイドでは「コレクティブが2日間のバリューサイクルを実施した後に3日間のバリューサイクルを実施することもあり得ます」と書かれています。
メンバーは自己組織化して何の活動をするか、どんな担当割(ガイドではチームと表記)で行うかを計画し、協働します。
バリューサイクルの終わりにはミーティング(FaSTミーティング)を開催し、活動の進捗や学びを共有し、プロダクトの状態・状況についての理解を揃えます。
ロール
メンバー：コレクティブに所属する全員がメンバーです。
プロダクトマネージャー：戦略、プロダクトディスカバリー、そして顧客とビジネスに価値を届けること、のそれぞれの仕組みがどうなっているかを理解しているメンバーです。
チームスチュワード：バリューサイクル内で、チームに奉仕すると有志で申し出たメンバーです。
フィーチャースチュワード(オプション)：あるフィーチャーのコンセプトから完成に至るまでの全てを理解することを有志で申し出たメンバーです。フィーチャースチュワードは開発の進捗について議論をする能力を持ちます。
コレクティブには4つのロールがあります。1コレクティブ=1プロダクト という制限はなく、コレクティブには複数のプロダクトマネージャーが所属できます。
チームのお世話係となる「チームスチュワード」と機能開発のお目付け役となる「フィーチャースチュワード」は自己組織化により立候補したメンバーが持ち回りで担当します。
ツール
コレクティブアグリーメント:常に更新されるドキュメントで、コレクティブがどのように協調するかを記述したものです。少なくとも、どのように意思決定がなされ、どのように対立が解消されるかについて記述してあるべきです。
マーケットプレイスボード:現在のバリューサイクルでどの活動アイテムが選ばれ、そのアイテムのために集まったチームに誰がいるかを可視化するためのものです。
コレクティブ内の意思決定・コミュニケーション方針など行動指針を「コレクティブアグリーメント」としてまとめます。
またバリューサイクル内の活動計画・進捗状況は「マーケットプレイスボード」で可視化を行います。
バリューサイクル内の開発の流れ
タスクをメンバーに分配するのではなく、タスクの周りにメンバーが集まる仕組みをベースとしている。
1. プロダクトマネージャーの指針表明
プロダクトマネージャーが、みんなを鼓舞するメッセージと共にバリューサイクルを開始します。
そのメッセージは、理想的にはビッグピクチャーを改めて共有する形をとります。
場合によって、プロダクトマネージャーは前のFaSTミーティング以降にプロダクトにどのような変化があったか、例えば新たな観点の登場や緊急度の変化など、を強調することもあります。
プロダクトマネージャーの話から始まる。
ビッグピクチャー(=目的・ミッション)をその時点の情報に基づいて見直し、再重要だと考えている課題や解決したいことをコレクティブのメンバーに対して説明します。
2. 自己組織化し、活動の周りにチームを形成
オープンスペーステクノロジーにインスパイアされた進め方で、コレクティブは新たなバリューサイクルのために、活動のマーケットプレイスを作成します。
チームスチュワードは立候補して自ら立ち上がり、1人ずつ短い「ピッチ」を行い、活動に奉仕する意思表明をします。 そして、チームスチュワードがその活動に対応するプレースホルダをマーケットプレイスボードに置きます。
すべてのチームスチュワードがピッチを終えると活動のマーケットプレイスができあがります。 メンバーはそれぞれ、どうすれば最大の貢献ができるかを考え、マーケットプレイスボードにある活動アイテムの隣に自分の名前を置きます。
こうして、各自の選択によってチームが構成されます。
プロダクトマネージャーの話を踏まえ、「こういう活動が必要ではないか」と考えたチームスチュワードが立候補し、どのような貢献をするか説明した上で、マーケットプレイスボードに活動を記載する。
その後メンバー各自がどう貢献するかを考え、マーケットプレイスボードの活動の側に自分の名前を記載する。
これにより誰が何の活動に貢献するのかが見えるかされ、バリューサイクル内の担当割(チーム)が形成される
このあとチームごとに活動をタスク分解し計画を行う。計画を詳細化することで複数チーム間の依存関係やリソースの過不足などが見つかるが、FaSTでは自己組織化によって解決する。チーム間で依存性をどう解消するかを話したり、メンバーはどの時点でもチームを移動して貢献することが推奨されている。
価値・原則・柱
ガイドからの抜粋です。
ざっと眺めてみるだけでもどんな考え方をベースにしているフレームワークなのか伝わるかと。
考えたこと
読んでいてどうしてもスクラムやカンバンといった既存手法との差異が気になってきます。
自分はスクラムで起きるであろう下記の課題の解決を狙っているのかなと感じました。
- 固定化された開発リズム→バリューサイクルの期間は変えても良い
- 固定化されるスクラムマスター→チームスチュワードは立候補
- スプリントが進んでも深まらないプロダクトへの理解→バリューサイクルの最初にプロダクトオーナーが最新状況を都度説明
- 複数チームのスケーリング調整→チームスチュワードのピッチにメンバーが自発的に集まる仕組み
- チームで成果を出すため、個人の強みや専門性を抑えてしまう→ピッチにメンバーが集まる仕組み & いつでも移動可というルール
とはいえ、良い取り組みはスクラムを使っていようが導入可能なものにも見えます。
できそう?
↑角谷さんのツイートが"まさにコレ！"でした。
「プロダクトのために集まるメンバー全員が高い自律性を持ち発揮し続けることを前提としたフレームワーク」なので、前提条件を成立させることがまず非現実的なのではと思いました。FaSTのやり方がまずいのか、自律ができてないのか、他に何か問題があるのか切り分けることにずっと苦労しそうです。
下記のどちらかに早晩収束しそう
- 自己組織化を最大限に引き出せ、はちゃめちゃな所まで辿り着ける
- そんなことは人類には早すぎるので、はちゃめちゃな状態に早晩なる
ログラスさんが取り組むようですが、「FaSTが良いと公言し実際に推進する人がいるなら、人間の光の部分を強く信じている人」なのではと思いました。
私はやっていいよと言われても色々悩んで実行に移せないと思います。
参考文献
