（新URLに移行しました）FASTと向き合うことで見えた、大規模アジャイルの難しさと楽しさ

最新版はこちら（https://speakerdeck.com/wooootack/fast-taught-me-large-scale-agile-hardships-and-fun）

Transcript

1. https://speakerdeck.com/wooootack/fast -taught-me-large-scale-agile-hardships-a nd-fun に移⾏しました
2. FASTと向き合うことで⾒えた ⼤規模アジャイルの難しさと楽しさ Scrum Fest Kanazawa 2025 2025年6⽉14⽇ 株式会社ログラス 粟⽥ 恭介 2
3. 今⽇はこんな話をします 3
4. 今⽇はこんな話をします • FASTについての説明 • FASTをやっていくなかで発⽣した課題の共有 • 発⽣した課題の裏に潜んでいた本質的な課題の共有 • この違いを認識することの意味 • この違いに気付くことができた理由 • この気付きが私にもたらした変化 • （おまけ）FASTの好きなところを語る • まとめ ⾃分の経験と考察をもとにした事例話です 4
5. 今⽇はこんな話をします • FASTについての知識だけでなく現場のリアル • 表⾯的な課題と本質的な課題を区別することの価値 • ⼤きく複雑な課題と向き合う際の⼼構え 持ち帰ってもらえそうなこと 5
6. FASTの概要 6
7. FASTの概要 - FASTとは • ⾃⼰組織化とスケーリングの技術 ◦ ⼈々が仕事を中⼼に⾃⼰組織化し、スケールしていくための⽅法 • デリバリーとディスカバリーの両⽅に対応 ◦ 従来の多くの⼿法がデリバリーに偏っていたが、FASTはディスカバリー活動にも対応 • 変化に強い組織を⽬指した仕組み ◦ 変化の速い時代において、⾼い適応⼒とレジリエンスを備え、継続的なイノベーションを促進する • 超軽量で最⼩限の構造のみが存在する ◦ 適応と創発を推進するために、あえて超軽量で最⼩限の構造 FAST - Fluid Adaptive Scaling Technology とは 7 引⽤：（http://fastagile.io）
8. FASTの概要 - チームとコレクティブ • “コレクティブ” で、共通の⽬的を達成する ◦ 共通の⽬的のために集まった、⾃律的で権限を持つ⾃⼰組織化された集団 • “チーム” は “コレクティブ” の中で、流動的に作られる ◦ チームは固定されず、作業に応じて流動的に形成される ◦ 知識やスキルの共有、必要な場所への⼈員配置の柔軟性などが促進される • “チーム” 同⼠は、サイロ構造ではなくネットワーク構造 ◦ チームが固定されたサイロになるのではなく、ネットワーク状につながる構造を作り出す ◦ 静的なチーミングやサイロが引き起こす課題（限られた知識リソース、知識共有の困難さ、柔軟性の ⽋如、依存関係など）を解決する チームとコレクティブ 8 引⽤：（http://fastagile.io）
9. FASTの概要 - バリューサイクル バリューサイクル 9 コレクティブ ⽴ち上げ FAST Meeting FAST Meeting FAST Meeting ここ • FASTにおける「連続的な作業サイクル」のこと ◦ FAST Meetingによって区切られる • スクラムのスプリントと違ってタイムボックスではない ◦ 期間も可変に設定できる • バリューサイクルをどのように過ごすかは基本的に⾃由 ◦ 集合知と各⾃の判断を組み合わせ、⾃⼰管理的に解決する ◦ 必要に応じて、⼀時的に別のチームに移って共同で作業することも可能 ここ 永遠に 繰り返す 引⽤：（http://fastagile.io）
10. FASTの概要 - FAST Meeting FAST Meeting 10 第1部 バリューサイクルの完了 第2部 バリューサイクルの開始 第3部 マーケットプレイス 前回のバリューサイクルで達成したことや学んだことを コレクティブ全体で共有し全員が共通の理解を持つ PdMからコレクティブにメッセージを伝え 次のバリューサイクルを開始する 次に何に取り組むべきかのマーケットプレイスボードを作成し メンバーが個々に貢献したい作業を選びチームを形成する 引⽤：（http://fastagile.io）
11. FASTの概要 - チームとコレクティブ 最初はコレクティブだけがある 11 コレクティブ
12. FASTの概要 - チームとコレクティブ チームは流動的に作られる（チームに所属しないのもあり） 12 コレクティブ 作業Aチーム 作業Bチーム 作業Cチーム
13. FASTの概要 - チームとコレクティブ 相互に連携しているネットワーク構造を⽬指す 13 作業Aチーム 作業Bチーム コレクティブ 作業Cチーム
14. FASTの概要 - プルベースなフローシステム • プルベースなフローシステムであることを意識する ◦ 柔軟性、適応性、⾃⼰組織化といったFASTのメリットを享受するための根幹となる思想 ◦ 作業が連続的に流れ、必要な作業を必要な⼈が⾃ら引き込むことで進んでいく • プルベースとは ◦ 作業が上から “プッシュ” されるのではなくチームやメンバーが⾃ら “プル” する ◦ これらはマーケットプレイスの場において⾃⼰組織化されて現れる ◦ 作業が提⽰されメンバーが⾃ら参加することで作業がコレクティブに “プル” されていく • フローシステムとは ◦ バリューサイクルの期間は可変であり、タイムボックスではない ◦ タイムボックスに縛られず、状況に応じてサイクルが柔軟に進められる ◦ 準備ができたものから着⼿し、完了まで淀みなく連続的に流れていくことを促進する プルベースなフローシステム 14 引⽤：（http://fastagile.io）
15. 発⽣した課題 15
16. マーケットプレイスでの混乱
17. 発⽣した課題 - マーケットプレイスでの混乱 優先度の議論が紛糾した 17 17 チーム① チーム② チーム③ チーム④ チーム⑤ チーム⑥ 優先度 ⾼いです 優先度 ⾼いです 優先度 ⾼いです 優先度 ⾼いです 優先度 ⾼いです 優先度 ⾼いです • 全員が⾃らの意思で、ビジネス的に優先度が⾼いと思うタスクに着⼿することが求められる ◦ 優先順位の評価基準が相対評価ではなく絶対評価になってしまっていた ◦ FAST以前のスクラムチーム並列期は機能領域に閉じていたため、チームを超えた⽐較は急にできない • そもそものプロダクトマネジメントが難易度が⾼い ◦ プロダクトも⼤きくなってきた＋経営管理ドメイン特有のやることの多さもあるかも ◦ テクニカルな⾯も含めてのマネジメントが必要になってきた（負債解消、共通基盤構築など）
18. 発⽣した課題 - マーケットプレイスでの混乱 不⼗分なケイパビリティのチームで⾛り出すことに 18 18 • ほとんどのチームが⼈不⾜という状態になってしまった ◦ どれかを捨てるという意思決定ができなかった • 複数チームに所属になってしまう⼈も（⼀部）出てきた ◦ 複数チームのボトルネックに誰かがなってしまうリスクも潜んでいた ◦ 最も注⼒すべきものを個⼈⽬線でも選択できていないという状態 ⼈不⾜ですが 着⼿します ⼈不⾜ですが 着⼿します ⼈不⾜ですが 着⼿します ⼈不⾜ですが 着⼿します ⼈不⾜ですが 着⼿します ⼈不⾜ですが 着⼿します チーム① チーム② チーム③ チーム④ チーム⑤ チーム⑥
19. コレクティブよりチームが優先された
20. 発⽣した課題 - コレクティブよりチームが優先された • ちらほらと対⽴の⽕種が⽣まれ始めていた ◦ コレクティブのふりかえりに出ずにチームの活動に時間を取りたい（コレクティブ vs チーム） ◦ 他のチームからうちのチームに⼈を移動できませんか（チーム vs チーム） • マーケットプレイスでも即戦⼒な⼈材を求めるチームが多かった ◦ 新メンバーやジュニアなメンバーの育成がおろそかに ◦ 新メンバーもどこに⼊ったら良いのか迷ってしまう状態に ⾃分たちのチームの⽬標達成が第⼀という状態になってしまった 20 チーム① チーム② チーム③ スケジュールが遅れてるので 即戦⼒メンバーがほしい うちも新⼈を 受け⼊れる余裕は... ⼀旦⽌めて他に移動？ ちょっと厳しいかも... どこに⼊ろう...
21. 発⽣した課題 - コレクティブよりチームが優先された • 形式上の⽬標は存在していたが、全員で共通認識を持ててはいなかった ◦ コレクティブの⽬標は影を潜め、チームごとに⽴てた⽬標を追いかける状態 ◦ コレクティブの⽬標とチームの⽬標が接続できているかどうかの確認はおざなり • 「それぞれのチームは順調！コレクティブとしては順調？」という状況に陥った ◦ チーム単位では、スクラムのプラクティスを導⼊するなどチームビルディングも活発になってきた ◦ コレクティブ単位での全体最適のような活動はあまり活発にはならなかった コレクティブとして掲げた⽬標が形骸化してしまった 21 こっから！ チームの ⽬標に向けて どうですか？ ヤバい！ 順調！ なのかな...？ コレクティブの ⽬標に向けて どうですか？ 順調...？ どうだろ...？ 解像度：⾼ 解像度：低
22. 本質的な課題を探す 22
23. マーケットプレイスでの混乱は FASTのせいか？
24. 本質的な課題を探す- マーケットプレイスでの混乱はFASTのせいか？ • 全員がビジネス的に価値があることを判断できる状態はそう容易に作れるものではない ◦ ビジネスへの理解、プロダクトへの理解など多くの要素が必要 • 特定の⼈にプロダクトオーナーをやってもらうとしたら解決するのか？ ◦ おそらく意思決定はしやすくなるし、議論も紛糾はしない ◦ ただしプロダクトオーナーがボトルネックとなるリスクは残り続けてしまう • 優先順位付けに対するアプローチの違いと⾔えそう ◦ 例えばスクラムは、プロダクトオーナーに最終決定を委ねる “知の巨⼈”（に近い） ◦ 逆にFASTは、全員で最適解を探す “集合知” ◦ 難易度は⾼いが「1⼈の⼈間が考えるより遥かに⾼い知性を発揮する」という可能性も秘めている 「優先度の議論が紛糾する」はFASTの課題と⾔えるか？ 24
25. 本質的な課題を探す- マーケットプレイスでの混乱はFASTのせいか？ • そもそも⼗分なケイパビリティってなんだろう ◦ 誰かが答えを知っているのか？ ◦ 元々のスクラムチーム時代は⼗分だったと⾔えるのだろうか？ • チームに必要なケイパビリティは、常に変化し続ける ◦ 特定スキルを持ったメンバーがいれば常に⼤丈夫という話ではない ◦ あらかじめ必要なケイパビリティを定義して、その通りにチームを作ろうとしてもうまくいかない • 素早くリソースアロケーションできることが解決策なのかも ◦ 「あ、うちのチームいまケイパビリティ⾜りてないかも？」ってなったときに⽴ち⽌まる ◦ ⾃分のチームの優先度が本当に⾼いのなら、他から移動してきてもらう ◦ 逆に⾃分たちのチームの優先度が低いのなら、解散するべきなのかもしれない 「不⼗分なケイパビリティのチームで⾛り出す」はどうだろうか？ 25
26. 本質的な課題を探す- マーケットプレイスでの混乱はFASTのせいか？ • これらの議論を通じて全員が認識を揃える “プロセス” が本当の価値なのではないか ◦ マーケットプレイスボードは⾔っても数⽇間のチーム分けに過ぎない ◦ うまくできなかったとしても作るまでに⾏った議論は無駄にはならない • 集合知を⽤いて継続的にマーケットプレイスボードも改善を進めていく ◦ 回数を重ねるごとに良くなっていくはず はじめから完成されたマーケットプレイスボードを作ろうとしない 26 コレクティブは、提案された活動アイテムとチーム構成を、依存関係や限られた専⾨性といった感覚的 な基準を基に調整することがあります。最終評価によってFaSTミーティングは終了し、メンバーは散 会して、⾃⾝が選んだチームでの活動を開始します。 ー FaSTガイド 引⽤：（https://drive.google.com/file/d/1jkKpvhWcF1N0-7B-9tCkRNXZnphHrHxP/view）
27. コレクティブよりチームが優先されたのは FASTのせいか？
28. 本質的な課題を探す - コレクティブよりチームが優先されたのはFASTのせいか？ • コレクティブ = スクラムチーム、チーム = (個⼈ or ペア or トリオ) とマッピングできる ◦ スクラムで⾔えば、活動の中⼼が個⼈のタスクを終わらせることになっていたり、開発者間の連携が ない状態で並列にタスクを進めていたら危険信号かも ◦ 「スプリントゴールに向けて全員で協⼒する」であれば活動の中⼼はチームになっているはず • 私たちのチームでお試しでFASTをやっていた時は問題なく回っていた ◦ ペアやトリオを柔軟に組み替えながらチームとして成果を出していく動きをできていた ◦ スウォーミングができていたことが背景にあるのではないか（アジャイルコーチ談） • （参考）スウォーミングとは ◦ 最も重要な課題を迅速に完了して価値提供を加速するために、チーム全員がその課題に集中し協⼒し て解決にあたること スクラムでもチームによってはこの課題は発⽣する 28
29. 本質的な課題を探す - コレクティブよりチームが優先されたのはFASTのせいか？ • 以前のスクラムチーム時代にも、並列にいろんなタスクを進めるチームがあった ◦ ゴールもそれぞれの⽬標をそれぞれが達成するような形になってしまう • 本来の向き合うべき活動単位ではなく⽇々の近い活動単位にフォーカスしてしまう ◦ ⾃分が今やっている仕事の⽬標達成が第⼀に来てしまう • 我々が⽬指すのはチームの⽬標達成ではなくコレクティブの⽬標達成 ◦ だからFASTを導⼊して強制的にそういう⼒学が働きやすくしたとも⾔えそう FASTの課題ではなく、FASTによって顕在化した組織に潜む課題だった 29 コレクティブは⾃律的で、⼗分な権限を持ち、⾃⼰組織化していて、⾃⼰管理できる⼈達によるグルー プで、共通の⽬的のもとに集まり、プロダクトのディスカバリーとビジネスゴールの達成ができる能⼒ を持ち合わせています。 ー FaSTガイド 引⽤：（https://drive.google.com/file/d/1jkKpvhWcF1N0-7B-9tCkRNXZnphHrHxP/view）
30. これらの課題を区別することの意味 30
31. これらの課題を区別することの意味 • この判断を⾒誤ると解決したつもりがより悪化するというリスクがある ◦ 例えば「FASTが良くない」となってしまったら、全て “回避” すべき課題に⾒えてしまう ◦ 先⼊観を持ってしまうと「これもFASTの課題だから回避すればいいよね」となってしまう ◦ 「FASTをやめる」という回避はできるが解決できていない意思決定を下しかねない “回避” すべき課題なのか “解決” すべき課題なのかが明確になる 31 課題を発⾒する 課題を回避する 課題を解決する 危険なルート 原因を特定する
32. これらの課題を区別することの意味 • ⼤切なのは、変化を受け⼊れた上で理想状態とのギャップに向き合うこと ◦ 「スクラム時代は〜だった」のように過去との⽐較にはあまり価値がない ◦ ⽬指している理想状態に対するギャップを認識して、どうやって登っていくかを考えられる 過去ではなく未来に⽬を向けることができる 32 スクラム時代 理想状態 現状 向き合うべきは このギャップと登り⽅ 過去 未来 パワー ここを戻そうと しても価値は低い
33. 私がこの気づきを得られた理由 33
34. ターニングポイントは RSGT2025
35. 私がこの気づきを得られた理由 - ターニングポイントはRSGT2025 森 雄哉さんの発表を聞いて、あまりの学びの多さに衝撃を受けました 35 引⽤：（https://speakerdeck.com/moriyuya/continuous-management-of-trade-offs-rsgt2025）
36. 私がこの気づきを得られた理由 - ターニングポイントはRSGT2025 • ⾃分たちは、複雑な問題を安易に分割せずに⽴ち向かおうとしている ◦ 分割して簡単にするのではなく、本当に必要な課題解決と向き合わなければいけない ◦ 対⽴関係も⽣まれつつあるが、それを協⼒関係に変えていかなきゃいけない • マーケットプレイスでのバランス調整は、良い解決策ではない ◦ リソース配分の調整がうまくいって安⼼していた過去の⾃分をふりかえって反省 • FASTもあえて軽量なフレームワークとしていてコントロールしようとはしていない ◦ コントロールしようとするのではなく相⼿に寄り添う ◦ コントロールできない前提で、どうやって1つにまとまっていくのか これらを咀嚼できた時、FASTに対する向き合い⽅や考え⽅が変わった 36
37. 今まで以上に多種多様な声を集めた
38. 私がこの気づきを得られた理由 - 今まで以上に多種多様な声を集めた • 多種多様なメンバーの声を聞いた ◦ あまり話したことがない⼈や別職種、レイヤーの違う⼈などと1on1をして課題感をヒアリング ◦ 新しい世界の情報を集めてこれを使ってトレードオフを解決するためのヒントを探す • 「しっかり話せば分かる」が⾒つかるように ◦ お互いに悪意はなく、善意で遠慮していただけ ◦ 集合知の⼒で解決できることもある ⾃分の⾒ている世界が狭かったことを痛感した 38 引⽤：（https://speakerdeck.com/moriyuya/continuous-management-of-trade-offs-rsgt2025?slide=255）
39. 学習する組織を⽬指し続けた
40. 私がこの気づきを得られた理由 - 学習する組織を⽬指し続けた • 実⾏する組織よりも学習する組織を⽬指し続けた ◦ 元々のスクラムチーム時代から学習する組織の強さは実感していた ◦ FASTになってからも、疑問が⽣まれたらすぐに雑談ベースで議論していた • 学習できる環境を使い倒した ◦ アジャイルコーチ、EM、VPoEなどの有識者といつでも組織について議論することができた ◦ コレクティブを対象としたふりかえりは必ず参加し、積極的に改善を推進した • “分かる” から “できる” に向けてチャレンジを続けた 変化に強くなるためには、学習する組織である必要がある 40 変化と競争の激しいグローバル経済の中で成功するには、組織は学習する⼒も持たなければならない。 およそどんな専⾨分野であれ⽬標は絶えず動いている。その分野の進歩に遅れずついていくには⼈々は ⽣涯にわたって学習しなければならず、成功は新たなスキルを習得して斬新な可能性を思い描ける⼈た ちが⼿にすることになるのだ。 ー チームが機能するとはどういうことか 引⽤：（https://eijipress.co.jp/products/2182）
41. この気づきが私にもたらした変化 41
42. チーム視点とコレクティブ視点の共存
43. この気づきが私にもたらした変化 - チーム視点とコレクティブ視点の共存 • チームでは取り扱えない機能開発が必要になってきた ◦ AチームとBチームが協⼒しないと価値が出せない • 元々、スクラムチーム時代は課題を感じてなかったのでFASTにも消極的だった ◦ チーム単位で⾒たら順調だったし⼤きな変化を求める理由もなかった • 他チームとの連携においても、⾒えない壁のようなものは感じつつもスルーしていた ◦ 壁はあるけど、それでもなんとかなっていたから 以前は取り扱える領域が限られていたし、チームで活動するという視点が強かった 43 優先度が⾼いチーム横断の機能開発があり 〇〇さんのリソースを借りれませんか？ ⼀時的なチームを作ることになる想定です う〜ん、いまは出せないですね 我々の⽬標やチームを育てていく必要も ありますし、チームを分解するってことで すか？
44. この気づきが私にもたらした変化 - チーム視点とコレクティブ視点の共存 • チームもコレクティブも良くなる解決策を探るべきである ◦ チーム視点で⾃分たちのチームへの影響を考慮するだけでは不⼗分 ◦ コレクティブのメンバー視点で他のチームへの影響も考慮しなければならない ◦ そしてコレクティブ代表視点になり、コレクティブへの影響も考慮しなければならない チームもコレクティブも良くなる解決策を探るべきと考えるように 44 ⽊（チーム）も⾒て 森（コレクティブ）も⾒る
45. カオスを楽しめるようになった
46. この気づきが私にもたらした変化 - カオスを楽しめるようになった • そもそも安定させようとすること⾃体が誤りだったと気づいた ◦ 激しい⼈員の増加や新規事業への移動などが避けられない組織状況である ◦ FASTの柱の1つに “Complex Adaptive Systems”（複雑適応系）がある • スクラムのアンラーニングが必要だった（異論は認める） ◦ スクラムのプラクティスや価値観はチームの安定化に傾いてしまう可能性もある 安定しない組織を前提に、それをどう乗りこなしていくのかを考えるように 46 引⽤：（https://drive.google.com/file/d/1sB8n-Ev-CmoY0WHozsagsQiTKA0fiGQM/view）
47. この気づきが私にもたらした変化 - カオスを楽しめるようになった • カオスと複雑さの瀬⼾際が最もイノベーションが起こりやすい ◦ 過度にルールがありすぎるわけでもなく、完全に無秩序でもない状態 • 安易にプラクティスを導⼊するのではなく、根気強く原則や価値を説き続ける（XPの⾔葉を拝借） ◦ プラクティスをやることがルールのようになると逆にこれらの妨げになる ◦ 放置しておいてもうまくいくように、原則や価値を語り続け、⽂化として定着させていく • 全体を考慮した上で個別に最適化していく動きを加速させていく ◦ その上で認識ズレてるなってなったら揃えれば良い ◦ 少しずつ1つの⽣命体のように意思を持つようになっていければ良い 意図的に複雑かつ不安定にすることで、創造的かつ適応的な振る舞いを助⻑する 47 Need more innovation? FAST sits at the cusp of chaos and complexity - where innovation is most likely to happen. ー FAST - What is FAST Good For? Who Should Look at FAST? 引⽤：（https://www.fastagile.io/）
48. 複雑な課題と正⾯から 向き合うことを恐れなくなった
49. この気づきが私にもたらした変化 - 複雑な課題と正⾯から向き合うことを恐れなくなった • 「チームは⼩さいほうが良い」と思っていた ◦ スクラムガイド※1 やチームトポロジー※2 にもそのような記載があり、これ⾃体も間違いではない ◦ より⼤きな課題を解決しようとした際に逆効果になることもあるのかもと感じた • 分割は容易にできるが統合は容易ではない ◦ ⼀度サイロ化してしまったチームを1つにまとめるのは難易度が⾼い ◦ サイロ化させることが本当に最適かどうかの⾒極めはした⽅が良い • あえてチームを分割しないことで何が起こるのか ◦ レバレッジをかけてより⼤きな課題解決ができる（かもしれない） ◦ 広範囲に影響を及ぼせる環境になったからこそ、⼤胆な意思決定ができるように あえてチームを分割しないという選択肢を知ることができた 49 1：https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf 2：https://pub.jmam.co.jp/book/b593881.html
50. この気づきが私にもたらした変化 - 複雑な課題と正⾯から向き合うことを恐れなくなった • これまでは雰囲気でタスクを分割していた ◦ スクラムガイドなどを参考にしながら、なるべく⼩さくすることが多かった ◦ あえて⼤きい状態で残すという判断はあまりしたことがない • 新たに得られたタスクを分割する際の考え⽅ ◦ “そのタスクをどうやって解決していきたいか” という願いも込める ◦ タスクが完了された後の結果だけでなく、そのプロセスも意識する タスクの分割において新たな考え⽅を得られた 50 開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメン トを作 成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテ ムを 1⽇以内の ⼩さな作業アイテムに分解することによって⾏われる。 ー スクラムガイド（2020） 引⽤：（https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf）
51. この気づきが私にもたらした変化 - 複雑な課題と正⾯から向き合うことを恐れなくなった • ⼤きく複雑な課題を本質的に解決することは容易なことではない ◦ 解きやすい課題から解いていくというように結論を急いではいけない ◦ 解きやすくするために無理な分割をしてはいけない • 実⾏ではなく学習、変化することを恐れない ◦ どれだけ頑張っても学習しなければ解けない壁にぶつかった ◦ “実験して、学習して、変化する” という原点に⽴ち戻ることができた • ただスタートアップという環境でこういう考えを維持することは根気が必要（個⼈差あり） ◦ 意思決定や作業速度が遅いという印象を持たれるリスクもある ◦ 説明責任を果たし必要性を訴え続けていくということは避けては通れない 短期的な成果に囚われすぎないようになった 51
52. （おまけ）FASTの特に好きなところ 52
53. FASTの特に好きなところ 性善説で成り⽴っている（意訳）ところ 53 引⽤：（https://drive.google.com/file/d/1sB8n-Ev-CmoY0WHozsagsQiTKA0fiGQM/view）
54. まとめ 54
55. FASTと真剣に向き合うことで
56. 裏に潜む⼤きく複雑な課題を発⾒でき
57. ⾃然と本質的な課題解決に⽬が向くように
58. その経験は私を⼤きく成⻑させてくれました
59. これからも本質的な課題を解決し続けたい
60. ⼤きく複雑な課題だって怖くないぞ