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

by Kyosuke Awata

Slide 1

Slide 1 text

https://speakerdeck.com/wooootack/fast -taught-me-large-scale-agile-hardships-a nd-fun に移⾏しました

Slide 2

Slide 2 text

FASTと向き合うことで⾒えた⼤規模アジャイルの難しさと楽しさ Scrum Fest Kanazawa 2025 2025年6⽉14⽇株式会社ログラス粟⽥恭介 2

Slide 3

Slide 3 text

今⽇はこんな話をします 3

Slide 4

Slide 4 text

今⽇はこんな話をします ● FASTについての説明 ● FASTをやっていくなかで発⽣した課題の共有 ● 発⽣した課題の裏に潜んでいた本質的な課題の共有 ● この違いを認識することの意味 ● この違いに気付くことができた理由 ● この気付きが私にもたらした変化 ● （おまけ）FASTの好きなところを語る ● まとめ⾃分の経験と考察をもとにした事例話です 4

Slide 5

Slide 5 text

今⽇はこんな話をします ● FASTについての知識だけでなく現場のリアル ● 表⾯的な課題と本質的な課題を区別することの価値 ● ⼤きく複雑な課題と向き合う際の⼼構え持ち帰ってもらえそうなこと 5

Slide 6

Slide 6 text

FASTの概要 6

Slide 7

Slide 7 text

FASTの概要 - FASTとは ● ⾃⼰組織化とスケーリングの技術 ○ ⼈々が仕事を中⼼に⾃⼰組織化し、スケールしていくための⽅法 ● デリバリーとディスカバリーの両⽅に対応 ○ 従来の多くの⼿法がデリバリーに偏っていたが、FASTはディスカバリー活動にも対応 ● 変化に強い組織を⽬指した仕組み ○ 変化の速い時代において、⾼い適応⼒とレジリエンスを備え、継続的なイノベーションを促進する ● 超軽量で最⼩限の構造のみが存在する ○ 適応と創発を推進するために、あえて超軽量で最⼩限の構造 FAST - Fluid Adaptive Scaling Technology とは 7 引⽤：（http://fastagile.io）

Slide 8

Slide 8 text

FASTの概要 - チームとコレクティブ ● “コレクティブ” で、共通の⽬的を達成する ○ 共通の⽬的のために集まった、⾃律的で権限を持つ⾃⼰組織化された集団 ● “チーム” は “コレクティブ” の中で、流動的に作られる ○ チームは固定されず、作業に応じて流動的に形成される ○ 知識やスキルの共有、必要な場所への⼈員配置の柔軟性などが促進される ● “チーム” 同⼠は、サイロ構造ではなくネットワーク構造 ○ チームが固定されたサイロになるのではなく、ネットワーク状につながる構造を作り出す ○ 静的なチーミングやサイロが引き起こす課題（限られた知識リソース、知識共有の困難さ、柔軟性の⽋如、依存関係など）を解決するチームとコレクティブ 8 引⽤：（http://fastagile.io）

Slide 9

Slide 9 text

FASTの概要 - バリューサイクルバリューサイクル 9 コレクティブ⽴ち上げ FAST Meeting FAST Meeting FAST Meeting ここ ● FASTにおける「連続的な作業サイクル」のこと ○ FAST Meetingによって区切られる ● スクラムのスプリントと違ってタイムボックスではない ○ 期間も可変に設定できる ● バリューサイクルをどのように過ごすかは基本的に⾃由 ○ 集合知と各⾃の判断を組み合わせ、⾃⼰管理的に解決する ○ 必要に応じて、⼀時的に別のチームに移って共同で作業することも可能ここ永遠に繰り返す引⽤：（http://fastagile.io）

Slide 10

Slide 10 text

FASTの概要 - FAST Meeting FAST Meeting 10 第1部バリューサイクルの完了第2部バリューサイクルの開始第3部マーケットプレイス前回のバリューサイクルで達成したことや学んだことをコレクティブ全体で共有し全員が共通の理解を持つ PdMからコレクティブにメッセージを伝え次のバリューサイクルを開始する次に何に取り組むべきかのマーケットプレイスボードを作成しメンバーが個々に貢献したい作業を選びチームを形成する引⽤：（http://fastagile.io）

Slide 11

Slide 11 text

FASTの概要 - チームとコレクティブ最初はコレクティブだけがある 11 コレクティブ

Slide 12

Slide 12 text

FASTの概要 - チームとコレクティブチームは流動的に作られる（チームに所属しないのもあり） 12 コレクティブ作業Aチーム作業Bチーム作業Cチーム

Slide 13

Slide 13 text

FASTの概要 - チームとコレクティブ相互に連携しているネットワーク構造を⽬指す 13 作業Aチーム作業Bチームコレクティブ作業Cチーム

Slide 14

Slide 14 text

FASTの概要 - プルベースなフローシステム ● プルベースなフローシステムであることを意識する ○ 柔軟性、適応性、⾃⼰組織化といったFASTのメリットを享受するための根幹となる思想 ○ 作業が連続的に流れ、必要な作業を必要な⼈が⾃ら引き込むことで進んでいく ● プルベースとは ○ 作業が上から “プッシュ” されるのではなくチームやメンバーが⾃ら “プル” する ○ これらはマーケットプレイスの場において⾃⼰組織化されて現れる ○ 作業が提⽰されメンバーが⾃ら参加することで作業がコレクティブに “プル” されていく ● フローシステムとは ○ バリューサイクルの期間は可変であり、タイムボックスではない ○ タイムボックスに縛られず、状況に応じてサイクルが柔軟に進められる ○ 準備ができたものから着⼿し、完了まで淀みなく連続的に流れていくことを促進するプルベースなフローシステム 14 引⽤：（http://fastagile.io）

Slide 15

Slide 15 text

発⽣した課題 15

Slide 16

Slide 16 text

マーケットプレイスでの混乱

Slide 17

Slide 17 text

発⽣した課題 - マーケットプレイスでの混乱優先度の議論が紛糾した 17 17 チーム① チーム② チーム③ チーム④ チーム⑤ チーム⑥ 優先度⾼いです優先度⾼いです優先度⾼いです優先度⾼いです優先度⾼いです優先度⾼いです ● 全員が⾃らの意思で、ビジネス的に優先度が⾼いと思うタスクに着⼿することが求められる ○ 優先順位の評価基準が相対評価ではなく絶対評価になってしまっていた ○ FAST以前のスクラムチーム並列期は機能領域に閉じていたため、チームを超えた⽐較は急にできない ● そもそものプロダクトマネジメントが難易度が⾼い ○ プロダクトも⼤きくなってきた＋経営管理ドメイン特有のやることの多さもあるかも ○ テクニカルな⾯も含めてのマネジメントが必要になってきた（負債解消、共通基盤構築など）

Slide 18

Slide 18 text

発⽣した課題 - マーケットプレイスでの混乱不⼗分なケイパビリティのチームで⾛り出すことに 18 18 ● ほとんどのチームが⼈不⾜という状態になってしまった ○ どれかを捨てるという意思決定ができなかった ● 複数チームに所属になってしまう⼈も（⼀部）出てきた ○ 複数チームのボトルネックに誰かがなってしまうリスクも潜んでいた ○ 最も注⼒すべきものを個⼈⽬線でも選択できていないという状態⼈不⾜ですが着⼿します⼈不⾜ですが着⼿します⼈不⾜ですが着⼿します⼈不⾜ですが着⼿します⼈不⾜ですが着⼿します⼈不⾜ですが着⼿しますチーム① チーム② チーム③ チーム④ チーム⑤ チーム⑥

Slide 19

Slide 19 text

コレクティブよりチームが優先された

Slide 20

Slide 20 text

発⽣した課題 - コレクティブよりチームが優先された ● ちらほらと対⽴の⽕種が⽣まれ始めていた ○ コレクティブのふりかえりに出ずにチームの活動に時間を取りたい（コレクティブ vs チーム） ○ 他のチームからうちのチームに⼈を移動できませんか（チーム vs チーム） ● マーケットプレイスでも即戦⼒な⼈材を求めるチームが多かった ○ 新メンバーやジュニアなメンバーの育成がおろそかに ○ 新メンバーもどこに⼊ったら良いのか迷ってしまう状態に⾃分たちのチームの⽬標達成が第⼀という状態になってしまった 20 チーム① チーム② チーム③ スケジュールが遅れてるので即戦⼒メンバーがほしいうちも新⼈を受け⼊れる余裕は... ⼀旦⽌めて他に移動？ちょっと厳しいかも... どこに⼊ろう...

Slide 21

Slide 21 text

発⽣した課題 - コレクティブよりチームが優先された ● 形式上の⽬標は存在していたが、全員で共通認識を持ててはいなかった ○ コレクティブの⽬標は影を潜め、チームごとに⽴てた⽬標を追いかける状態 ○ コレクティブの⽬標とチームの⽬標が接続できているかどうかの確認はおざなり ● 「それぞれのチームは順調！コレクティブとしては順調？」という状況に陥った ○ チーム単位では、スクラムのプラクティスを導⼊するなどチームビルディングも活発になってきた ○ コレクティブ単位での全体最適のような活動はあまり活発にはならなかったコレクティブとして掲げた⽬標が形骸化してしまった 21 こっから！チームの⽬標に向けてどうですか？ヤバい！順調！なのかな...？コレクティブの⽬標に向けてどうですか？順調...？どうだろ...？解像度：⾼解像度：低

Slide 22

Slide 22 text

本質的な課題を探す 22

Slide 23

Slide 23 text

マーケットプレイスでの混乱は FASTのせいか？

Slide 24

Slide 24 text

本質的な課題を探す- マーケットプレイスでの混乱はFASTのせいか？ ● 全員がビジネス的に価値があることを判断できる状態はそう容易に作れるものではない ○ ビジネスへの理解、プロダクトへの理解など多くの要素が必要 ● 特定の⼈にプロダクトオーナーをやってもらうとしたら解決するのか？ ○ おそらく意思決定はしやすくなるし、議論も紛糾はしない ○ ただしプロダクトオーナーがボトルネックとなるリスクは残り続けてしまう ● 優先順位付けに対するアプローチの違いと⾔えそう ○ 例えばスクラムは、プロダクトオーナーに最終決定を委ねる “知の巨⼈”（に近い） ○ 逆にFASTは、全員で最適解を探す “集合知” ○ 難易度は⾼いが「1⼈の⼈間が考えるより遥かに⾼い知性を発揮する」という可能性も秘めている「優先度の議論が紛糾する」はFASTの課題と⾔えるか？ 24

Slide 25

Slide 25 text

本質的な課題を探す- マーケットプレイスでの混乱はFASTのせいか？ ● そもそも⼗分なケイパビリティってなんだろう ○ 誰かが答えを知っているのか？ ○ 元々のスクラムチーム時代は⼗分だったと⾔えるのだろうか？ ● チームに必要なケイパビリティは、常に変化し続ける ○ 特定スキルを持ったメンバーがいれば常に⼤丈夫という話ではない ○ あらかじめ必要なケイパビリティを定義して、その通りにチームを作ろうとしてもうまくいかない ● 素早くリソースアロケーションできることが解決策なのかも ○ 「あ、うちのチームいまケイパビリティ⾜りてないかも？」ってなったときに⽴ち⽌まる ○ ⾃分のチームの優先度が本当に⾼いのなら、他から移動してきてもらう ○ 逆に⾃分たちのチームの優先度が低いのなら、解散するべきなのかもしれない「不⼗分なケイパビリティのチームで⾛り出す」はどうだろうか？ 25

Slide 26

Slide 26 text

本質的な課題を探す- マーケットプレイスでの混乱はFASTのせいか？ ● これらの議論を通じて全員が認識を揃える “プロセス” が本当の価値なのではないか ○ マーケットプレイスボードは⾔っても数⽇間のチーム分けに過ぎない ○ うまくできなかったとしても作るまでに⾏った議論は無駄にはならない ● 集合知を⽤いて継続的にマーケットプレイスボードも改善を進めていく ○ 回数を重ねるごとに良くなっていくはずはじめから完成されたマーケットプレイスボードを作ろうとしない 26 コレクティブは、提案された活動アイテムとチーム構成を、依存関係や限られた専⾨性といった感覚的な基準を基に調整することがあります。最終評価によってFaSTミーティングは終了し、メンバーは散会して、⾃⾝が選んだチームでの活動を開始します。ー FaSTガイド引⽤：（https://drive.google.com/ﬁle/d/1jkKpvhWcF1N0-7B-9tCkRNXZnphHrHxP/view）

Slide 27

Slide 27 text

コレクティブよりチームが優先されたのは FASTのせいか？

Slide 28

Slide 28 text

本質的な課題を探す - コレクティブよりチームが優先されたのはFASTのせいか？ ● コレクティブ = スクラムチーム、チーム = (個⼈ or ペア or トリオ) とマッピングできる ○ スクラムで⾔えば、活動の中⼼が個⼈のタスクを終わらせることになっていたり、開発者間の連携がない状態で並列にタスクを進めていたら危険信号かも ○ 「スプリントゴールに向けて全員で協⼒する」であれば活動の中⼼はチームになっているはず ● 私たちのチームでお試しでFASTをやっていた時は問題なく回っていた ○ ペアやトリオを柔軟に組み替えながらチームとして成果を出していく動きをできていた ○ スウォーミングができていたことが背景にあるのではないか（アジャイルコーチ談） ● （参考）スウォーミングとは ○ 最も重要な課題を迅速に完了して価値提供を加速するために、チーム全員がその課題に集中し協⼒して解決にあたることスクラムでもチームによってはこの課題は発⽣する 28

Slide 29

Slide 29 text

本質的な課題を探す - コレクティブよりチームが優先されたのはFASTのせいか？ ● 以前のスクラムチーム時代にも、並列にいろんなタスクを進めるチームがあった ○ ゴールもそれぞれの⽬標をそれぞれが達成するような形になってしまう ● 本来の向き合うべき活動単位ではなく⽇々の近い活動単位にフォーカスしてしまう ○ ⾃分が今やっている仕事の⽬標達成が第⼀に来てしまう ● 我々が⽬指すのはチームの⽬標達成ではなくコレクティブの⽬標達成 ○ だからFASTを導⼊して強制的にそういう⼒学が働きやすくしたとも⾔えそう FASTの課題ではなく、FASTによって顕在化した組織に潜む課題だった 29 コレクティブは⾃律的で、⼗分な権限を持ち、⾃⼰組織化していて、⾃⼰管理できる⼈達によるグループで、共通の⽬的のもとに集まり、プロダクトのディスカバリーとビジネスゴールの達成ができる能⼒を持ち合わせています。ー FaSTガイド引⽤：（https://drive.google.com/ﬁle/d/1jkKpvhWcF1N0-7B-9tCkRNXZnphHrHxP/view）

Slide 30

Slide 30 text

これらの課題を区別することの意味 30

Slide 31

Slide 31 text

これらの課題を区別することの意味 ● この判断を⾒誤ると解決したつもりがより悪化するというリスクがある ○ 例えば「FASTが良くない」となってしまったら、全て “回避” すべき課題に⾒えてしまう ○ 先⼊観を持ってしまうと「これもFASTの課題だから回避すればいいよね」となってしまう ○ 「FASTをやめる」という回避はできるが解決できていない意思決定を下しかねない “回避” すべき課題なのか “解決” すべき課題なのかが明確になる 31 課題を発⾒する課題を回避する課題を解決する危険なルート原因を特定する

Slide 32

Slide 32 text

これらの課題を区別することの意味 ● ⼤切なのは、変化を受け⼊れた上で理想状態とのギャップに向き合うこと ○ 「スクラム時代は〜だった」のように過去との⽐較にはあまり価値がない ○ ⽬指している理想状態に対するギャップを認識して、どうやって登っていくかを考えられる過去ではなく未来に⽬を向けることができる 32 スクラム時代理想状態現状向き合うべきはこのギャップと登り⽅過去未来パワーここを戻そうとしても価値は低い

Slide 33

Slide 33 text

私がこの気づきを得られた理由 33

Slide 34

Slide 34 text

ターニングポイントは RSGT2025

Slide 35

Slide 35 text

私がこの気づきを得られた理由 - ターニングポイントはRSGT2025 森雄哉さんの発表を聞いて、あまりの学びの多さに衝撃を受けました 35 引⽤：（https://speakerdeck.com/moriyuya/continuous-management-of-trade-oﬀs-rsgt2025）

Slide 36

Slide 36 text

私がこの気づきを得られた理由 - ターニングポイントはRSGT2025 ● ⾃分たちは、複雑な問題を安易に分割せずに⽴ち向かおうとしている ○ 分割して簡単にするのではなく、本当に必要な課題解決と向き合わなければいけない ○ 対⽴関係も⽣まれつつあるが、それを協⼒関係に変えていかなきゃいけない ● マーケットプレイスでのバランス調整は、良い解決策ではない ○ リソース配分の調整がうまくいって安⼼していた過去の⾃分をふりかえって反省 ● FASTもあえて軽量なフレームワークとしていてコントロールしようとはしていない ○ コントロールしようとするのではなく相⼿に寄り添う ○ コントロールできない前提で、どうやって1つにまとまっていくのかこれらを咀嚼できた時、FASTに対する向き合い⽅や考え⽅が変わった 36

Slide 37

Slide 37 text

今まで以上に多種多様な声を集めた

Slide 38

Slide 38 text

私がこの気づきを得られた理由 - 今まで以上に多種多様な声を集めた ● 多種多様なメンバーの声を聞いた ○ あまり話したことがない⼈や別職種、レイヤーの違う⼈などと1on1をして課題感をヒアリング ○ 新しい世界の情報を集めてこれを使ってトレードオフを解決するためのヒントを探す ● 「しっかり話せば分かる」が⾒つかるように ○ お互いに悪意はなく、善意で遠慮していただけ ○ 集合知の⼒で解決できることもある⾃分の⾒ている世界が狭かったことを痛感した 38 引⽤：（https://speakerdeck.com/moriyuya/continuous-management-of-trade-oﬀs-rsgt2025?slide=255）

Slide 39

Slide 39 text

学習する組織を⽬指し続けた

Slide 40

Slide 40 text

私がこの気づきを得られた理由 - 学習する組織を⽬指し続けた ● 実⾏する組織よりも学習する組織を⽬指し続けた ○ 元々のスクラムチーム時代から学習する組織の強さは実感していた ○ FASTになってからも、疑問が⽣まれたらすぐに雑談ベースで議論していた ● 学習できる環境を使い倒した ○ アジャイルコーチ、EM、VPoEなどの有識者といつでも組織について議論することができた ○ コレクティブを対象としたふりかえりは必ず参加し、積極的に改善を推進した ● “分かる” から “できる” に向けてチャレンジを続けた変化に強くなるためには、学習する組織である必要がある 40 変化と競争の激しいグローバル経済の中で成功するには、組織は学習する⼒も持たなければならない。およそどんな専⾨分野であれ⽬標は絶えず動いている。その分野の進歩に遅れずついていくには⼈々は⽣涯にわたって学習しなければならず、成功は新たなスキルを習得して斬新な可能性を思い描ける⼈たちが⼿にすることになるのだ。ーチームが機能するとはどういうことか引⽤：（https://eijipress.co.jp/products/2182）

Slide 41

Slide 41 text

この気づきが私にもたらした変化 41

Slide 42

Slide 42 text

チーム視点とコレクティブ視点の共存

Slide 43

Slide 43 text

この気づきが私にもたらした変化 - チーム視点とコレクティブ視点の共存 ● チームでは取り扱えない機能開発が必要になってきた ○ AチームとBチームが協⼒しないと価値が出せない ● 元々、スクラムチーム時代は課題を感じてなかったのでFASTにも消極的だった ○ チーム単位で⾒たら順調だったし⼤きな変化を求める理由もなかった ● 他チームとの連携においても、⾒えない壁のようなものは感じつつもスルーしていた ○ 壁はあるけど、それでもなんとかなっていたから以前は取り扱える領域が限られていたし、チームで活動するという視点が強かった 43 優先度が⾼いチーム横断の機能開発があり〇〇さんのリソースを借りれませんか？⼀時的なチームを作ることになる想定ですう〜ん、いまは出せないですね我々の⽬標やチームを育てていく必要もありますし、チームを分解するってことですか？

Slide 44

Slide 44 text

この気づきが私にもたらした変化 - チーム視点とコレクティブ視点の共存 ● チームもコレクティブも良くなる解決策を探るべきである ○ チーム視点で⾃分たちのチームへの影響を考慮するだけでは不⼗分 ○ コレクティブのメンバー視点で他のチームへの影響も考慮しなければならない ○ そしてコレクティブ代表視点になり、コレクティブへの影響も考慮しなければならないチームもコレクティブも良くなる解決策を探るべきと考えるように 44 ⽊（チーム）も⾒て森（コレクティブ）も⾒る

Slide 45

Slide 45 text

カオスを楽しめるようになった

Slide 46

Slide 46 text

この気づきが私にもたらした変化 - カオスを楽しめるようになった ● そもそも安定させようとすること⾃体が誤りだったと気づいた ○ 激しい⼈員の増加や新規事業への移動などが避けられない組織状況である ○ FASTの柱の1つに “Complex Adaptive Systems”（複雑適応系）がある ● スクラムのアンラーニングが必要だった（異論は認める） ○ スクラムのプラクティスや価値観はチームの安定化に傾いてしまう可能性もある安定しない組織を前提に、それをどう乗りこなしていくのかを考えるように 46 引⽤：（https://drive.google.com/ﬁle/d/1sB8n-Ev-CmoY0WHozsagsQiTKA0ﬁGQM/view）

Slide 47

Slide 47 text

この気づきが私にもたらした変化 - カオスを楽しめるようになった ● カオスと複雑さの瀬⼾際が最もイノベーションが起こりやすい ○ 過度にルールがありすぎるわけでもなく、完全に無秩序でもない状態 ● 安易にプラクティスを導⼊するのではなく、根気強く原則や価値を説き続ける（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/）

Slide 48

Slide 48 text

複雑な課題と正⾯から向き合うことを恐れなくなった

Slide 49

Slide 49 text

この気づきが私にもたらした変化 - 複雑な課題と正⾯から向き合うことを恐れなくなった ● 「チームは⼩さいほうが良い」と思っていた ○ スクラムガイド※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

Slide 50

Slide 50 text

この気づきが私にもたらした変化 - 複雑な課題と正⾯から向き合うことを恐れなくなった ● これまでは雰囲気でタスクを分割していた ○ スクラムガイドなどを参考にしながら、なるべく⼩さくすることが多かった ○ あえて⼤きい状態で残すという判断はあまりしたことがない ● 新たに得られたタスクを分割する際の考え⽅ ○ “そのタスクをどうやって解決していきたいか” という願いも込める ○ タスクが完了された後の結果だけでなく、そのプロセスも意識するタスクの分割において新たな考え⽅を得られた 50 開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテムを 1⽇以内の⼩さな作業アイテムに分解することによって⾏われる。ースクラムガイド（2020）引⽤：（https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf）

Slide 51

Slide 51 text

この気づきが私にもたらした変化 - 複雑な課題と正⾯から向き合うことを恐れなくなった ● ⼤きく複雑な課題を本質的に解決することは容易なことではない ○ 解きやすい課題から解いていくというように結論を急いではいけない ○ 解きやすくするために無理な分割をしてはいけない ● 実⾏ではなく学習、変化することを恐れない ○ どれだけ頑張っても学習しなければ解けない壁にぶつかった ○ “実験して、学習して、変化する” という原点に⽴ち戻ることができた ● ただスタートアップという環境でこういう考えを維持することは根気が必要（個⼈差あり） ○ 意思決定や作業速度が遅いという印象を持たれるリスクもある ○ 説明責任を果たし必要性を訴え続けていくということは避けては通れない短期的な成果に囚われすぎないようになった 51

Slide 52

Slide 52 text

（おまけ）FASTの特に好きなところ 52

Slide 53

Slide 53 text

FASTの特に好きなところ性善説で成り⽴っている（意訳）ところ 53 引⽤：（https://drive.google.com/ﬁle/d/1sB8n-Ev-CmoY0WHozsagsQiTKA0ﬁGQM/view）