自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ / dev-productivity-con-2025

by Yoshiki Iida

Slide 1

Slide 1 text

⾃律的なスケーリング⼿法FASTにおける VPoEとしてのアカウンタビリティ #開発⽣産性con_ﬁndy 2025.07.03 株式会社ログラス事業執⾏役員 VPoE 飯⽥意⼰

Slide 2

Slide 2 text

⾃⼰紹介 2015年に株式会社クラウドワークスに入社。エンジニア、スクラムマスター、プロダクトオーナーを経て、2019年から執行役員として開発部門の統括を行う。 2020年に株式会社ログラスにソフトウェアエンジニアとして入社。プロダクト開発に携わったのち、1人目のエンジニアリングマネージャーとして組織設計、マネジメント体制の構築、エンジニア採用、採用広報・ブランディングの推進を行う。 2024年11月から事業執行役員VPoEに就任。 X: @ysk_118 株式会社ログラス事業執行役員 VPoE 飯田意己 Yoshiki Iida

Slide 3

Slide 3 text

● ログラスのミッション ● これまでのログラス ● FASTへの挑戦 ● 1年間の学び ● 開発⽣産性にどう向き合うかアジェンダ

Slide 4

Slide 4 text

ログラスのミッション

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

経営企画は「企業価値の向上」をミッションに、企業経営にまつわるあらゆる業務を担っている

Slide 8

Slide 8 text

今後の展望

Slide 9

Slide 9 text

今後の展望

Slide 10

Slide 10 text

昨年のおさらい

Slide 11

Slide 11 text

昨年の伊藤（当時VPoE/現CTO）の登壇 https://www.youtube.com/watch?v=CYPRRxHq84E より

Slide 12

Slide 12 text

昨年の伊藤（当時VPoE/現CTO）の登壇

Slide 13

Slide 13 text

昨年の伊藤（当時VPoE/現CTO）の登壇

Slide 14

Slide 14 text

昨年の伊藤（当時VPoE/現CTO）の登壇

Slide 15

Slide 15 text

昨年の伊藤（当時VPoE/現CTO）の登壇

Slide 16

Slide 16 text

昨年の伊藤（当時VPoE/現CTO）の登壇

Slide 17

Slide 17 text

昨年の伊藤（当時VPoE/現CTO）の登壇

Slide 18

Slide 18 text

昨年の伊藤（当時VPoE/現CTO）の登壇

Slide 19

Slide 19 text

昨年の伊藤（当時VPoE/現CTO）の登壇

Slide 20

Slide 20 text

アジャイルフレームワーク FASTへの挑戦

Slide 21

Slide 21 text

● ドメインの複雑さ × 横断的体験の整合性 → 経営管理領域の難しさ🔥 ● パフォーマンス課題への継続的な対処 → 扱うデータ量の増加🔥 ● 認知負荷とチーム間連携のトレードオフ → 機能領域別チームでの個別最適(サイロ)化🔥 （機能Aの拡張に機能Bも変更が必要な場合のチーム間連携コスト）前提となるプロダクト組織が向き合う課題

Slide 22

Slide 22 text

解決したい課題 ● デリバリー、ディスカバリー双⽅に組織全体で向き合えるようにする ○ 機能領域を跨いでプロダクト全体の価値を捉えられるようにする ● 機能領域別チームの枠をとっぱらい、組織全体の機動性を⾼める ○ プロダクト全体で最も優先順位の⾼い課題に機動性⾼くチーム組成する → 上記課題の解消のため、FASTというアジャイルフレームワークを導⼊機能領域に閉じた最適化からプロダクト全体での最適化に向かえるように

Slide 23

Slide 23 text

● Quinton Quartelが提唱したスケーリングフレームワーク ● OSTから着想を得ている ● 提案されたアイテムに開発者が集まりチームを結成 ○ 流動的なチーム構成 ○ 「何を開発するか」は “コレクティブ” の集合知で決まる ● 個々の開発者の⾃律性が強く要求される ○ ルールが⾮常に少なく⾃由度が⾼い FASTについて簡単に説明「動的なチーミングと自律 MAXで組織をスケールさせるアジャイルフレームワーク FASTとは？」 https://prd-blog.loglass.co.jp/entry/2024/09/12/181043 より

Slide 24

Slide 24 text

スケーリングフレームワークの例 ● Scrum@Scale ● LeSS ● SAFe ● Nexus ● FAST 国内で事例のあるフレームワークも選択できたが、これまでのスクラムでも⾃律性を⼤事にしてきた組織⽂化があり、少ないルールで柔軟性の⾼いFASTがスタートアップにおける機動性に対してもFitすると考え、チャレンジを決定した。 FASTについて簡単に説明

Slide 25

Slide 25 text

FASTの価値、原則、柱価値原則柱 ● 自律性 ● 目的の共有 ● 熟達 ● 協働 ● 自己組織化 ● 自己管理 ● ナチュラルリーダーシップ ● 正しいことをせよ ● T字型であれ ● チームプレイヤーであれ ● 経験を分かち合い、学び合え ● 複雑適応系 ● オープンスペーステクノロジー ● Y理論によるガバナンス ● リーンスタートアップ ● 流動的なチーミング ● ダンパー数 ● ネットワーク型組織 FAST Guide(Japanese) から作成 https://drive.google.com/file/d/1jkKpvhWcF1N0-7B-9tCkRNXZnphHrHxP/view

Slide 26

Slide 26 text

FASTについて簡単に説明チームA データ取込チームB マスタ設定データ変換チームC データ分析‧出⼒スクラム時代の構造 1つのコードベース 3つの機能領域 3つのチームスロットA スロットB スロットC スロットD FASTでの構造 1つのコードベース 1つのコレクティブ流動的なチーミングの枠（社内用語：スロット）バックログA バックログB バックログC Big Picture アイテムD アイテムC アイテムA アイテムB コレクティブ

Slide 27

Slide 27 text

どうFASTを導⼊したか？ https://speakerdeck.com/yoshikiiida/rsgt2025 RSGT2025の資料を参照現場の自律性を引き出すことと、組織全体の意思決定をリードすることのバランスの難しさについて解説しています。

Slide 28

Slide 28 text

1年間の学び

Slide 29

Slide 29 text

● 流動性の解釈の深まり(内部‧外部) ● 品質への向き合い⽅ ● ⾃律性の解釈の深まり ● サイロとの継続的な戦い ● 守破離の捉え⽅ 1年での学び

Slide 30

Slide 30 text

● 流動性の解釈の深まり(内部‧外部) ● 品質への向き合い⽅ ● ⾃律性の解釈の深まり ● サイロとの継続的な戦い ● 守破離の捉え⽅ 1年での学び

Slide 31

Slide 31 text

● 初期のころは各スロットの⼈の出⼊りも多かった ● ⾃律的に動くというマインドが⽣まれたのはよかったが、コミュニケーションコストが上がるという指摘もあった ● 考案者⾃⾝も時間経過とともに移動は落ち着いていくと⾔っている学び：流動性を特徴として持っているが、流動しなくてはいけないということではない流動性の解釈の深まり（内部）

Slide 32

Slide 32 text

● 新規事業と既存事業の流動性 ● FASTだから外部とも⾃由に出⼊りできるわけではない学び：スクラムとの対⽐で流動性が特徴ではあるが、内部での出⼒を⾼めるためにはコレクティブとしての安定性は重要流動性の解釈の深まり（外部）経営管理新規事業A 新規事業B

Slide 33

Slide 33 text

● 流動性の解釈の深まり(内部‧外部) ● 品質への向き合い⽅ ● ⾃律性の解釈の深まり ● サイロとの継続的な戦い ● 守破離の捉え⽅ 1年での学び

Slide 34

Slide 34 text

「チームの枠を流動的にする」 ↓ 「スクラムよりも⼩さいチーム単位を構成」品質への向き合い⽅

Slide 35

Slide 35 text

● ⼀⾒並列数を上げられると錯覚するが、実際には戦⼒分散してしまっている ● 結果として品質課題につながるシーンもあった学び：スクラムでは固定的なチームの枠があるため、その中でのメンバーの出⼊りによるチームが有している知識‧スキルの増減はわかりやすい FASTにおいても各スロットで⼗分なメンバーが揃っているかは重要な視点品質への向き合い⽅

Slide 36

Slide 36 text

Ken Schwaberの2007年の書籍企業のプロダクトの中⼼にある共通のデータ、処理、機能ような領域はコアと呼ばれ、新機能の開発に伴いコアの変更が必要となる場合、その変更の難易度は⾼く、コア開発者がいなければ新規機能の開発はできない、という⽰唆が書かれている。コア開発者の制約 Ken Schwaber(2007). Enterprise and Scrum, The (Developer Best Practices) (English Edition), Microsoft Press https://www.microsoftpressstore.com/store/enterprise-and-scrum-9780735690936 より

Slide 37

Slide 37 text

● 流動性の解釈の深まり(内部‧外部) ● 品質への向き合い⽅ ● ⾃律性の解釈の深まり ● サイロとの継続的な戦い ● 守破離の捉え⽅ 1年での学び

Slide 38

Slide 38 text

過度に⾃律性を守らなければいけない？という空気感⾃律性の解釈の深まり自律性が大事だから上段の方針レベルまでにとどめて詳細は任せたほうがいい？入社して間もないけど自律的に動かなければいけない？影響範囲が大きいけど自律的に意思決定できないといけない？

Slide 39

Slide 39 text

● 「FASTでやっているから⾃律的に動かないといけない」 ○ → スクラムでも⾃律性は求められる ○ → コレクティブという⼤きな枠での⾃律性はより難易度が⾼い ● FASTによって難易度が上がったという混乱‧⼾惑いはあった学び：どんなやり⽅にせよ、Whole Productで今どこに向かうべきなのか、何を最優先で⽚付けなければいけないのか？を考えなければいけない。⾃律性を合議と捉えると歪んでしまう。誰かが意思決定をしなくてはいけないが、 Product Owner(相当の⼈)がスタンスを取る=⾃律性を損なう、ではない。⾃律性の解釈の深まり

Slide 40

Slide 40 text

● 流動性の解釈の深まり(内部‧外部) ● 品質への向き合い⽅ ● ⾃律性の解釈の深まり ● サイロとの継続的な戦い ● 守破離の捉え⽅ 1年での学び

Slide 41

Slide 41 text

● 機能領域に分かれた複数のチームがそれぞれ独⾃のチームのカルチャーを持っていた ● チーム間でのコラボレーションの際にチームの⽂化の違いがコミュニケーションコストという形で顕在化したスクラム時代のサイロチームA データ取込チームB マスタ設定データ変換チームC データ分析・出力 1つのコードベース、 3つの機能領域、3つのチーム

Slide 42

Slide 42 text

● 初期は流動性⾼く⼈の動きが発⽣していた ● だんだんと落ち着いていき、それぞれのスロットで新たなやり⽅、⽂化が形成されはじめた学び：やり⽅に問わず、環境次第でサイロの⼒学は働いてしまう。チーム間での協働の視点を常に持ちながら個々の仕事を進める視点が必要。 FASTによってサイロは崩されたが‧‧ スロットA スロットB スロットC スロットA スロットB スロットC

Slide 43

Slide 43 text

● 流動性の解釈の深まり(内部‧外部) ● 品質への向き合い⽅ ● ⾃律性の解釈の深まり ● サイロとの継続的な戦い ● 守破離の捉え⽅ 1年での学び

Slide 44

Slide 44 text

FASTの「守り」とは何か FASTの守破離価値原則柱 ● 自律性 ● 目的の共有 ● 熟達 ● 協働 ● 自己組織化 ● 自己管理 ● ナチュラルリーダーシップ ● 正しいことをせよ ● T字型であれ ● チームプレイヤーであれ ● 経験を分かち合い、学び合え ● 複雑適応系 ● オープンスペーステクノロジー ● Y理論によるガバナンス ● リーンスタートアップ ● 流動的なチーミング ● ダンパー数 ● ネットワーク型組織

Slide 45

Slide 45 text

Slide 46

Slide 46 text

● FASTの「守」が完全にできているとは⾔えない ○ スクラムよりもルールは少ないが、価値や原則など考え⽅に関する要素が多く、学習し⾃然に馴染むまでは時間がかかる ● 対して、スクラムの原則である「透明性、検査、適応」については多くのメンバーが馴染んでいる ○ スクラムがよく定着しているとも⾔えるし、アンラーニングできていないとも⾔える ○ 無理にアンラーニングしていくことが現状の我々にとっての最適解なのか？ FASTの守破離

Slide 47

Slide 47 text

● FASTの「破」に⼊っているところもすでにある ○ マーケットプレイスにてその場その場の状況を⾒て流動的にチーミングを⾏うことが前提だが、ある程度未来を⾒通すためにスロットの配置の予測を⽴てる取り組みをしている ○ 流動性とは逆⾏するので少なくとも「守」ではない ● FASTをベースにしつつもログラスなりの現時点の最善を模索している FASTの守破離安定的なチーム組成：スクラム流動的なチーム組成： FAST

Slide 48

Slide 48 text

開発⽣産性にどう向き合うか

Slide 49

Slide 49 text

● 前提として、⼤規模なモノリスがベースとなっており、全体の開発⽣産性を精緻に計測することはスクラムでもFASTでも難しい ● やっていること ○ Findy Team+による可視化 ○ リリースノート集計の可視化 ○ 品質ダッシュボード ○ コードベースの増加量推移 ○ 内部品質の可視化開発⽣産性との向き合い⽅

Slide 50

Slide 50 text

コード量とリリースごとのコード変更量の推移開発⽣産性との向き合い⽅プロダクトコードは線形的に増加しながら、一人当たりのコード変更量のペースは維持。コードベースが大きくなっても変更容易性については維持ができている。

Slide 51

Slide 51 text

● ⼀⽅で新機能リリースや改善のリリースノートの数⾃体はダウントレンドがあった ○ ひとつひとつの開発規模が⼤きくなりリードタイムは増加している ○ ソースコードやデータ量の純増による⾮機能的な開発の⽐率も上がっている ● その上でフレームワーク移⾏によるダウンタイムは存在する複合的な要因が絡み合うため何かの単⼀指標で⽣産性を説明することはしていない開発⽣産性との向き合い⽅

Slide 52

Slide 52 text

AI活⽤については間違いなく今後のゲームチェンジャーであり、全⽅位的に⾼い実⾏強度で取り組んでいる。各種メトリクスはあくまでメトリクスとして扱いつつ、変数となるレバーを定め、施策実⾏をセットでモニタリング → 課題認識に対して何をアクションしているのかを⽰すことが重要開発⽣産性との向き合い⽅引用元）「Claude Code Week」既存事業で 1週間AI縛りで開発したことで見えたゲームチェンジと開発フローの再構築の必要性 https://zenn.dev/loglass/articles/b286b1e8f0947b

Slide 53

Slide 53 text

FASTとの関連性はどうか？

Slide 54

Slide 54 text

● 流動性の解釈の深まり(内部‧外部) → 仕事量の⽣産性、期待付加価値の⽣産性 ● 品質への向き合い⽅ → 仕事量の⽣産性 ● ⾃律性の解釈の深まり → 期待付加価値の⽣産性 ● サイロとの継続的な戦い → 期待付加価値の⽣産性 ● 守破離の捉え⽅ → 仕事量の⽣産性 FASTの学びに対しての⽣産性の観点からのふりかえり

Slide 55

Slide 55 text

仕事量の⽣産性 ● 流動的なチーミングは課題優先順位に対して適切なチーミングができれば、フロー効率を⾼められる ○ ⼀⽅で適切な判断にならない場合、戦⼒分散するリスクもある ● 開発が⻑期化するものについては配置をあらかじめプランニングすることでフロー効率を⾼められる FASTの学びに対しての⽣産性の観点からのふりかえり期待付加価値の⽣産性 ● 流動的なチーミングによって機能領域を跨いだメンバーが集まることで、横断的な価値を考慮できる体制構築ができる ● 機能領域別のチームの枠をなくすことで、プロダクトマネジメントの意思決定は全体俯瞰の意識が強化された

Slide 56

Slide 56 text

● コードベースの状態、リリース頻度、変更量、障害発⽣率、新機能数、リードタイム、、など、基本的なメトリクスをモニタリングしながら、全体としての開発プロセスのアップデートを進めてきた ● 仕事量の⽣産性の改善は⽐較的わかりやすいアクションに紐付けられるが、期待付加価値の⽣産性の改善は⾮常に難易度が⾼い🔥 ○ 現状は体制としてこれに向かう取り組みが前に進んだところだが道半ばの状態 ○ お客様の意思決定がより良くなったか？課題発⾒がしやすくなったか？業務効率化できたか？、、、など、付加価値の観点は複数存在し、恒常的なモニタリングまでは⾄っていない開発⽣産性との向き合い⽅

Slide 57

Slide 57 text

FAST導⼊によって得られたこと ● 現状課題はまだ多く残っており、練度を上げ切れてはいない状況 ● ⼀⽅、ルールの少なさゆえに混乱もあったが、結果として現場のアジャイルに向き合う本質的な試⾏錯誤を促進できた側⾯も⽣まれた ○ 改めて全体観を持ちながらプロダクト開発をしていく重要性 ○ それに向き合う組織としてのマインドセット開発⽣産性との向き合い⽅メンバーの発信も増やすことができた。 https://speakerdeck.com/wooootack/fast-taug ht-me-large-scale-agile-hardships-and-fun

Slide 58

Slide 58 text

⽣産性とは何か⽣産性 = 単位○○あたりの⽣産量、価値これを計測することで得られるものは過去から現在のやり⽅に関する情報のみ。また、ここから出せるアクションはあくまで短期的なアクションに過ぎない。つまり、⽣産性を改善するというアクションだけでは、⻑期的な価値を⾒落とすリスクがある。 VPoEとしてのアカウンタビリティ t 現在ちょっと先の未来の改善を積み重ねることはできる長期の理想状態に至れるか？は別の話

Slide 59

Slide 59 text

FASTの評価短期的には組織の動き⽅を⼤きく変えたので⽣産性は下がっている。しかし、スクラムの中でなんとなく回ってしまっていた状況を⾒つめ直す機会にもなった。プロダクト全体の価値を捉えることの難しさを体感した。チームを超えてコラボレーションすることの⼤事さを体感した。⾃分たちで改善していくことの重要性を体感した。いろいろな組織としての学習が進んだ。この価値は⽣産性だけでは測ることができない。 VPoEとしてのアカウンタビリティ

Slide 60

Slide 60 text

⻑期⽬線のスタンスを取ること⽣産性で測れるような短期の合理性も重要である。しかし、⻑期視点の、短期では合理的ではないように⾒える取り組みも重要である。例えば、⽂化やアイデンティティといった、より抽象的な開発組織としての強みを作るための活動をどう維持できるか？など。⻑期視点のスタンスを持ち、取り組みを維持する説明を継続することがVPoEの責務 VPoEとしてのアカウンタビリティ

Slide 61

Slide 61 text

⾃律的なスケーリング⼿法FASTにおける VPoEとしてのアカウンタビリティとスタンス #開発⽣産性con_ﬁndy 2025.07.03 株式会社ログラス事業執⾏役員 VPoE 飯⽥意⼰ @ysk_118

Slide 62

Slide 62 text

まとめ

Slide 63

Slide 63 text

● 機能領域のフィーチャーチームからWhole Productに向き合うためのスケーリングを FASTというフレームワークを⽤いて取り組んできた ● スケーリングの過程において、 ○ 流動性や⾃律性の解釈が進んだこと ○ 品質をあげるためのチーム構成の要素 ○ サイロの⼒学 ○ FASTの守破離という学びがあった ● 仕事量の⽣産性および、期待付加価値の⽣産性それぞれの解像度は上がったが、取り組みや運⽤の熟達度はまだ道半ば ○ AI時代の新しいスタンダードへのチャレンジが次の1年の取り組み ● ⻑期的な価値となる学びもあり、ここへの投資はVPoEのスタンスが重要であるまとめ

Slide 64

Slide 64 text

FASTに取り組んできた1年を現場⽬線で振り返り、リアルな苦悩や試⾏錯誤を発信するイベントを実施します。 7⽉24⽇（⽊）19:00-@ログラスオフィス/オンラインお知らせ

Slide 65

Slide 65 text

No content