FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation

Loglass Tech Talk vol.6「FAST実践のリアル〜壁にぶつかり、悩み、試し続けた1年間〜」
https://loglass-tech.connpass.com/event/357161/

Transcript

1. FAST導⼊1年間のふりかえり 〜現実を直視し、さらなる進化を求めて〜 Loglass TECH TALK vol.6 - FAST実践のリアル 〜壁にぶつかり、悩み、試し続けた1年間〜 2025年7⽉24⽇ 株式会社ログラス 粟⽥ 恭介 1
2. ⾃⼰紹介 2 2019年に、石油精製工場のプラントエンジニアからソフトウェアエンジニアに転生 しました。その後はエクセルスクショ職人の時期などかくかくしかじかありまして、 2023年10月からログラスでエンジニアとして働いています。 現在は経営管理Loglassの開発に取り組みながら「最強の開発組織を作る」という 野望を密かに抱えています。 FASTは導入初期から取り組んでいて、社内でもそれなりに詳しい方の人間だと思 います。 愛車はスバルのBRZ（ZC6）で、推しは元AKB48の柏木由紀です。 株式会社ログラス エンジニア 粟田 恭介 Kyosuke Awata
3. ログラスについて 3
6. 経営企画は「企業価値の向上」をミッションに、企業経営にまつわるあらゆる業務を担っている
7. 今後の展望
8. 今後の展望
9. 今⽇はこんな話をします 9
10. 今⽇はこんな話をします • FASTの簡単なおさらい • FASTに対する評価 • さらなる進化に向けて • まとめ アジェンダ 10
11. 今⽇はこんな話はしません 11
12. 今⽇はこんな話はしません • FASTの詳しい説明 • なぜFASTに取り組んでいるのか • 具体的なやってみての学び系 既に発表済みの内容などは少なめにしています 12
13. FASTの簡単なおさらい 13
14. FASTの簡単なおさらい - FASTとは • ⾃⼰組織化とスケーリングの技術 ◦ ⼈々が仕事を中⼼に⾃⼰組織化し、スケールしていくための⽅法 • デリバリーとディスカバリーの両⽅に対応 ◦ 従来の多くの⼿法がデリバリーに偏っていたが、FASTはディスカバリー活動にも対応 • 変化に強い組織を⽬指した仕組み ◦ 変化の速い時代において、⾼い適応⼒とレジリエンスを備え、継続的なイノベーションを促進する • 超軽量で最⼩限の構造のみが存在する ◦ 適応と創発を推進するために、あえて超軽量で最⼩限の構造 FAST - Fluid Adaptive Scaling Technology とは 14 引⽤：（http://fastagile.io）
15. FASTの簡単なおさらい - チームとコレクティブ • “コレクティブ” で、共通の⽬的を達成する ◦ 共通の⽬的のために集まった、⾃律的で権限を持つ⾃⼰組織化された集団 • “チーム” は “コレクティブ” の中で、流動的に作られる ◦ チームは固定されず、作業に応じて流動的に形成される ◦ 知識やスキルの共有、必要な場所への⼈員配置の柔軟性などが促進される • “チーム” 同⼠は、サイロ構造ではなくネットワーク構造 ◦ チームが固定されたサイロになるのではなく、ネットワーク状につながる構造を作り出す ◦ 静的なチーミングやサイロが引き起こす課題（限られた知識リソース、知識共有の困難さ、柔軟性の ⽋如、依存関係など）を解決する チームとコレクティブ 15 引⽤：（http://fastagile.io）
16. FASTの簡単なおさらい - バリューサイクル バリューサイクル 16 コレクティブ ⽴ち上げ FAST Meeting FAST Meeting FAST Meeting ここ • FASTにおける「連続的な作業サイクル」のこと ◦ FAST Meetingによって区切られる • スクラムのスプリントと違ってタイムボックスではない ◦ 期間も可変に設定できる • バリューサイクルをどのように過ごすかは基本的に⾃由 ◦ 集合知と各⾃の判断を組み合わせ、⾃⼰管理的に解決する ◦ 必要に応じて、⼀時的に別のチームに移って共同で作業することも可能 ここ 永遠に 繰り返す 引⽤：（http://fastagile.io）
17. FASTの簡単なおさらい - FAST Meeting FAST Meeting 17 第1部 バリューサイクルの完了 第2部 バリューサイクルの開始 第3部 マーケットプレイス 前回のバリューサイクルで達成したことや学んだことを コレクティブ全体で共有し全員が共通の理解を持つ PdMからコレクティブにメッセージを伝え 次のバリューサイクルを開始する 次に何に取り組むべきかのマーケットプレイスボードを作成し メンバーが個々に貢献したい作業を選びチームを形成する 引⽤：（http://fastagile.io）
18. FASTの簡単なおさらい - チームとコレクティブ 最初はコレクティブだけがある 18 コレクティブ
19. FASTの簡単なおさらい - チームとコレクティブ チームは流動的に作られる（チームに所属しないのもあり） 19 コレクティブ 作業Aチーム 作業Bチーム 作業Cチーム
20. FASTの簡単なおさらい - チームとコレクティブ 相互に連携しているネットワーク構造を⽬指す 20 作業Aチーム 作業Bチーム コレクティブ 作業Cチーム
21. FASTに対する評価 21
22. 社内でアンケートを取りました
23. FASTに対する評価 - 社内でアンケートを取りました • 社内のプロダクト開発に関わる総勢50名が対象 • 職種やFAST歴もさまざまで幅広い意⾒を集めました 回答いただいた⽅々 23 CRE
24. FASTに対する評価 - 社内でアンケートを取りました 詳細な質問内容 24 • 以下3項⽬の「理解度、⾔語化度、納得度」 ◦ スケーリングと向き合う必要性について ◦ フレームワークとしてFASTを選択した理由について ◦ 具体的なFASTへの取り組み⽅について • FAST導⼊によって得たもの、失ったもの ◦ 個⼈、チーム、組織を問わず
25. スケーリングと向き合う必要性について
26. FASTに対する評価 - スケーリングと向き合う必要性について 課題感は明確に存在していたし、現場のメンバーに意欲もあった 26 https://speakerdeck.com/yoshikiiida/rsgt2025 • 解像度の差はあれど確実に課題は存在していた ◦ 課題を肌で感じているメンバーも複数存在していた • 課題ドリブンではなかったかもしれないが意欲もあった ◦ 実際に勉強会にはかなりの⼈数が参加した
27. FASTに対する評価 - スケーリングと向き合う必要性について • ある程度は理解を得られている：ただ、理解の⽅向性や内容まで揃っているかは懸念がある • ⾔語化度、納得度はのびしろあり：社内でもそこまで議論が活発なイメージはなく限定的 全体の回答 27 回答者数（⼈数）
28. FASTに対する評価 - スケーリングと向き合う必要性について • FAST歴の⻑さと納得度は⽐例しない：理解度と⾔語化度が⾼いが納得度だけが相対的に低い • ビジネスサイドへのアプローチは課題：適切に情報共有やアラインメントが取れているかは要確認 FAST歴、職種別 28 ※ 「まったくそう思わない＝1点〜とてもそう思う＝5点」として平均点を算出
29. FASTを選択したことについて
30. FASTに対する評価 - FASTを選択したことについて FASTをやりたいという声が最も多かった 30 https://speakerdeck.com/yoshikiiida/rsgt2025 • 勉強会では最もFASTに票が集まった ◦ 勉強会に参加していなかったメンバーからも反対の声は少なかった • 変化を進んで受け⼊れるマインドがあった ◦ 「Update Normal」というTech Valueが⽀えになった
31. FASTに対する評価 - FASTを選択したことについて • 全体的にスコアは低め：スケーリングの必要性に⽐べても下がっている • 特に⾔語化度が低い：理解度、納得度は平均レベルに留まっており、教育不⾜の懸念がある • 組織全体には浸透していない：なぜFASTなのかがうまく伝えられていない、課題設定は適切か 全体の回答 31 回答者数（⼈数）
32. FASTに対する評価 - FASTを選択したことについて FAST歴、職種別 32 • (同じ)FAST歴の⻑さと納得度は⽐例しない：理解度と⾔語化度が⾼いが納得度だけが相対的に低い • (同じ)ビジネスサイドへのアプローチは課題：適切に情報共有やアラインメントが取れているかは要確認 • QAは全体的にスコアが上昇している：元々の動きと近しいなどといった要因がありそう ※ 「まったくそう思わない＝1点〜とてもそう思う＝5点」として平均点を算出
33. 具体的なFASTへの取り組み⽅について
34. FASTに対する評価 - 具体的なFASTへの取り組み⽅について ひたすら模索する⽇々が続いたが少しずつ光明がさし始めた 34 https://speakerdeck.com/wooootack/fast-taught-me-large-scale-agile-hardships-and-fun • 実際にチャレンジしてからは課題発⾒と改善の連続 ◦ 壁を超えたと思ったらまた壁が⾒つかる • 少しずつログラス流のFASTの形が⾒えてきた ◦ それでもまだ課題はたくさん残っている
35. FASTに対する評価 - 具体的なFASTへの取り組み⽅について 全体の回答 35 • 選択理由よりやや上昇：それでも低い。具体的な活動を正しく発信できていない懸念がある • どちらでもない怖さ：無関⼼の領域に⼊りつつあるのかも？という危機感は常に持っておきたい 回答者数（⼈数）
36. FASTに対する評価 - 具体的なFASTへの取り組み⽅について FAST歴、職種別 36 • 歴とともに着実に伸びている：実際に体感し深く学ぶことの価値はあると確信 • すべてがMAXになる⼈々がいる：歴が⻑い⼈がしっかり理解し現場を推進しているといえる • (同じ)ビジネスサイドへのアプローチは課題：適切に情報共有やアラインメントが取れているかは要確認 ※ 「まったくそう思わない＝1点〜とてもそう思う＝5点」として平均点を算出
37. FASTによって得られたもの
38. FASTに対する評価 - FASTによって得られたもの • 流動的なチーミング ◦ 以前のスクラムチームをまたいだ⼈の流動性 ◦ イシューに応じてメンバーをアサインできるようになった ◦ チームの⼈数の増減が⾃由にできる • メンバーの成⻑ ◦ 個⼈の主体性が発揮されやすくなった ◦ スクラム以上に常に⾃律的に考えることを強いられる ◦ 各⾃が⾃分を向き合い続けた結果ときどき突出して成⻑する⼈が現れる印象 ◦ これはFASTじゃないと得られない化学反応なのではないか • 視座の向上 ◦ チームのスケーリングについて考える機会が増えたと ◦ ボトムアップの組織を維持し続ける⼤事な⼟壌になっている ◦ 「プロダクトとしてどうするか？」という意識での思考は個々に増えてきたと個⼈的に感じている 強靭な組織の⼟壌は出来つつあるが、プロダクトの価値貢献にはまだ届かず？ 38
39. FASTによって失ったもの
40. FASTに対する評価 - FASTによって失ったもの • 意思決定者、責任者 ◦ 責任の所在が曖昧になった気がするとの声 ◦ プロダクトのオーナー誰、意思決定誰がするの問題 • 特定の領域に特化した⼈材、チーム ◦ 認知負荷の低さ ◦ 技術的な領域のリード（その領域に詳しい⼈物） • ピープルマネジメント的な観点 ◦ メンバーの得意不得意、成果を発揮するにはどうすれば良いか ◦ タスクアサインによる期待の掛け⽅ • 運⽤系タスク ◦ 暗黙知や個々⼈の関係性が深まらないため、⽣産性向上への動きが鈍いように⾒える ◦ 新規開発の⽐率が⼤きくなっている 意図的に捨てたもの、そうじゃないものが混在している 40
41. さらなる進化に向けて 41
42. さらなる進化に向けて - 抱えている課題と、⽬指す姿を再定義したい • 時間の経過とともに、熱量や納得感などは薄れていくことが予想できる ◦ 新規事業チームへの移動や新⼊社員の増加などにより、⽐率が薄まっている ◦ ⼊社したときから FAST の⼈も⼀定数存在していて、過去のペインを知らない ◦ 急拡⼤する組織の中で、FASTに取り組まなければいけない状態 • 当時描いていた課題や⽬指す姿との乖離が⽣まれつつある（と思う） ◦ 「経営管理コレクティブでOrgTopologiesのB2を⽬指す」本当にいまも同じだろうか？ ◦ FASTへの解像度が上がったことで違う世界が⾒えつつある ◦ 最新状態へ更新したうえで、改めて周知しモメンタムを取り戻したい • FASTによる悪影響と元々そうだったものがより区別しにくい状況に ◦ FAST導⼊後もずっと社員は増え続けているしプロダクトは成⻑し続けている ◦ ⼤量の変数からFASTによる影響とそうではないものを的確に⾒抜くことは難しい ◦ ただし、⼤事なのは犯⼈探しではなく、原因の特定とそれを解決すること 抱えている課題と、⽬指す姿を再定義したい 42
43. さらなる進化に向けて - 理解度、⾔語化度、納得度の向上に取り組みたい • FASTをやっているメンバーに限定しても、同じ温度感でスケーリングと向き合えていない ◦ 職種による差、歴による違いなどで温度差が存在してしまっているのは事実 ◦ FASTの思想を「体現できているか」ではなく「体現しようとしているか」が重要 ◦ 抽象度が⾼いので実践から学ぶのが最も近道になる • ビジネスサイド（と区切りたくないが）に正しく情報を伝える必要がある ◦ 実際に課題と直⾯してないし、開発側の⽇々の動き⽅がイメージできないと理解も難しい ◦ ⼀緒にプロダクトを作っていく重要なステークホルダーで、敵ではない ◦ 協業のためにも相互理解を深め、信頼を築いていきたい • 理解度、⾔語化度、納得度が低い原因を⾃分たちの中に⾒つけたい ◦ ⼈を変える前にまず⾃分が変わほうが早い ◦ FASTをやっているメンバーが、理解度、⾔語化度、納得度を上げていくことは必須 ◦ そして、⾃分たちが使っている⾔葉ではなく、相⼿に伝わる⾔葉で話す 理解度、⾔語化度、納得度の向上に取り組みたい 43
44. さらなる進化に向けて - プロダクトを主語にした議論をもっと活発にしたい • FASTは「プロダクトの成功」のために取り組んでいる ◦ プロダクトの価値最⼤化のために取り⼊れたことを改めて周知 ◦ ⾔葉だけでなく実際にプロダクトに価値を出していかねばならない ◦ プロダクトに対して「FASTだからできた/できること」の探求 • その感覚をまだ⼗分に届けられていない ◦ アンケート結果もプロダクトへの⾔及は少ない（聞き⽅の問題もあるとして） ◦ プロダクトへの価値提供まで接続して考えられる⼈がまだ少ない ◦ ここは明確な伸びしろだなと感じている • 組織の話とかプロセスの話で終わってしまうと、職種や部署の間に壁が⾒え始める ◦ そのためにも主語は「プロダクト」に変えていきたい ◦ 事業貢献の意欲が⾼い⼈が集まっていると思っているので、できるはず ◦ 良いプロダクトを作るのに、職種は関係ない プロダクトを主語にした議論をもっと活発にしたい 44
45. さらなる進化に向けて - ログラスにとってのスケーリングとは？を考え続けたい • FASTをこのまま続けることが唯⼀の正解だとは思っていない ◦ 「とりあえず以前の状態に戻す」といった、易きに流れる選択肢は取りたくない ◦ FASTは特に薄いフレームワークなので、他のさまざまな思想を取り⼊れやすいはず ◦ 実際にそういったMIXさせてみようといった動きもあり、効果が出始めている • 適切な分解ポイントは常に探り続けたい ◦ 課題を分解して解いた結果、元の課題が解決できないは危険 ◦ 元の課題が解決できる分解ならやれば良い ◦ スケーリングと同じくらい適切な分割は難しいが、それに価値はあるはず • わたしたちにとって最適な「スケーリング」とは？ ◦ ⼩規模なチームであれば、変数が少なく再現性のある事例を引っ張ってこれるかもしれない ◦ スケーリングが必要な規模であれば、独⾃の仕組みが必ず必要になるはず ◦ 適応するだけではなく、⽣成するといったマインドチェンジが必要になってくるのではないか ログラスにとってのスケーリングとは？を考え続けたい 45
46. より詳しく知りたい⽅は 46
47. より詳しく知りたい⽅は - 我々がFAST挑戦に踏み切った理由を語る 47 我々がFAST挑戦に踏み切った理由を語る https://speakerdeck.com/itohiro73/dev-productivity-con-2024
48. より詳しく知りたい⽅は - FASTの導⼊のより詳細な経緯と、マネージャー視点ならではの苦悩を語る 48 FASTの導⼊のより詳細な経緯と、マネージャー視点ならではの苦悩を語る https://speakerdeck.com/yoshikiiida/rsgt2025
49. より詳しく知りたい⽅は - FASTを通じて得た学びを、⼤規模アジャイルの楽しさや難しさと共に語る 49 FASTを通じて得た学びを、⼤規模アジャイルの楽しさや難しさと共に語る https://speakerdeck.com/wooootack/fast-taught-me-large-scale-agile-hardships-and-fun
50. より詳しく知りたい⽅は - VPoE視点でのふりかえりと、説明責任をどう負うのかを語る 50 VPoE視点でのふりかえりと、説明責任をどう負うのかを語る https://speakerdeck.com/yoshikiiida/dev-productivity-con-2025
51. より詳しく知りたい⽅は - その他、FAST関連の記事をまとめたページも 51 その他、FAST関連の記事をまとめたページも https://prd-blog.loglass.co.jp/entry/fast