ログラスでアジャイルコーチをしております、おーのA（@ohnoeight）です。 ログラスの経営管理プロダクトチームでは、事業の成長を見据え、FAST（Fluid Adaptive Scaling Technology）を導入しています。2024年10月の入社以来、ログラスのFASTにおけるふりかえりを探索してきた過程を記事にします。
FASTについて
本記事ではFASTについての説明は省略します。FAST Guideをご覧ください。
ログラスがFASTにチャレンジすることになった経緯については以下の資料をご参照ください。
記事に記載の言葉の説明（一部のみ記載）
- Value Cycle: FASTにおける活動サイクル。ログラスでは2〜3日ごと、週2回の同期のためのFASTミーティングを実施
- コレクティブ（Collective）: プロダクト全体を開発する人々。ログラスでは経営管理プロダクトを担う全員を指す
- チーム：コレクティブから流動的に作られる個別のチーム。通常、各メンバーは自身が選んだチームで活動。ログラスではスロットとも呼ぶ
ふりかえりの実施方法の変遷
前提
スクラムでは、スクラムガイドで検査・適応という三本柱の2つに加え、スプリントレトロスペクティブというイベントを用意し、チームの改善方法を定義しています。スクラムをベースとしたスケーリングフレームワークも同様です。
一方でFAST Guideではふりかえりの方法は定義されていません。ログラスではFASTにおけるふりかえりの方法を探索してきました。
本記事では、半年間の私の考えていたこととチャレンジについて整理します。
FAST導入初期
FAST Guideには以下のように記載があります。
"On a short cadence, the Collective meets to share learning and progress to gain a shared understanding of product state and current conditions."
"短い周期でコレクティブはミーティングを開催し、学びと進捗を共有し、プロダクトの状態と現在の状況について共通の理解を得ます。"
ログラスでは、これに則り、「週2回のValue Cycle後の同期時に各チームから共有」を実施していました。また、2週間に1回（後に週1回）のふりかえりをOpen Space Technologyで実施し、コレクティブの前進のための材料集めやカイゼンを行っていました。
この頃の課題意識
各チームの「課題」は、チーム内のメンバーが自分たちで解決できていました。一方で、コレクティブ全体に影響するカイゼン提案は少なかったです。
全体の開発プロセスのうち、メンバーがどこにカイゼン提案の声を上げて良いかわからないのではないか、という仮説を立てました。FASTという新しいフレームワークに取り組む中で、フレームワーク固有のものと外のものが明確でないことで、カイゼンできる領域が曖昧になっていると考えました。
ログラスでは過去、小規模チームでスクラム開発を行っていました。スクラムの型を守るだけでなく、守破離の考えで型を破ることも行っていたはずです（スクラム時代、私は在籍していませんでした）。フレームワーク自体を変化させることも、チームの成長につながります。
FASTではふりかえりの方法が定義されていません。スクラムのレトロスペクティブのような基本となる型を定義することで、メンバーが守破離のプロセスを歩み出せるのではないかと考え、基本的な考え方の提示に取り組みました。
FASTの検査・適応の基本的な考え方の定義
SECIモデルからの考えの整理
SECIモデルに基づき、以下のように整理しました：
-
内面化プロセス：バリューサイクル
- チームとコレクティブの学びを、新たなバリューサイクルで活用し、個人で定着・深化
-
共同化プロセス：バリューサイクル
- 個人でチームで定着・深化
-
表出化プロセス：バリューサイクルのふりかえり・FASTミーティング
- バリューサイクルの学びをチームの学びや課題へと昇華
- チームの学びをコレクティブ全体に共有・蓄積
-
連結化プロセス：週次のFASTふりかえり
- 共有された学びから、新たな知識創造・課題発見・挑戦を促進
この抽象度の高い考え方を基に、チームが実際のアクティビティを設計することを意図しました。
以下は参考として作成したアクティビティの一例
基本的な考え方を定義した結果
ふりかえり特別会を実施し、いくつかの課題が表出化し、アクションも定義できました。特にふりかえりの目的が不明確という指摘から、目的の明確化など新たな活動につながりました。
その後は定期的に基本概念に立ち戻った議論ができ、共通言語として価値が出てきています。
この頃の課題意識
これらの活動を経てもなお、コレクティブ全体へのカイゼン提案は頻繁には起きませんでした。特定のメンバーからの発信でカイゼンは行われましたが、コレクティブ全員が全体に対してカイゼンを行える状況ではありませんでした。
この頃まで私は、ふりかえりをスクラムのスプリントレトロスペクティブ相当と考えていました。しかしFASTはスケーリングアジャイルの手法であり、FASTのふりかえりはLeSSのオーバーオールレトロスペクティブに近いものです。
小規模チームで可能だったことが、規模が大きくなると難しくなるのは、どのスケーリングフレームワークでも同様です。ログラスの課題は、FASTに特有のものではなく、スケーリングフレームワーク共通の課題です。ただしFASTには、コレクティブ全体の課題に向き合うためのフレームワークのサポートがないため、独自の探索が必要です。
チーム規模が大きくなると、プロダクト全体や開発プロセスへの責任が分散され、発言のハードルも上がります。また、各チームの課題解決に集中することで、全体の課題を見つけにくくなる認知負荷の問題もあります。
今後の取り組み
人数が多い場合の参加形態（必須・任意・指名制）には、それぞれ一長一短があり、明確な正解はありません。
フレームワークで定められた方法を実施する場合は説明が容易です。ただ、決められた形に則ることは、チームの本質的な課題を考える機会を奪っていると感じます。一方FASTでは、実施方法を自分たちで考える必要があり、その過程でチームが本質的な「Why」を考える機会となっています。難しさはありますが、このように活動を自分たちで考えることに本気で取り組むことで、チームの本質的な課題を考える機会となり、チームの成長につながります。
今後もアジャイルコーチとして、フレームワークの未定義部分の整備を模索し、メンバーが本質的な検査・適応を容易に実施できる環境を目指します。
将来的にはFASTの探索をログラスが行ったことで他社も取り組むことができたと言ってもらえるように走って行きたいと思います。
終わりに
ログラスでは、仲間を募集しています。 カジュアル面談も募集しておりますので、ご興味のある方はぜひご応募ください。
その他の職種はこちら
参考文献
Discussion