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

Transcript

1. ⾃律的なスケーリング⼿法FASTにおける VPoEとしてのアカウンタビリティ #開発⽣産性con_findy 2025.07.03 株式会社ログラス 事業執⾏役員 VPoE 飯⽥意⼰
2. ⾃⼰紹介 2015年に株式会社クラウドワークスに入社。エンジニア、スクラムマスター、プロ ダクトオーナーを経て、2019年から執行役員として開発部門の統括を行う。 2020年に株式会社ログラスにソフトウェアエンジニアとして入社。プロダクト開 発に携わったのち、1人目のエンジニアリングマネージャーとして組織設計、マネ ジメント体制の構築、エンジニア採用、採用広報・ブランディングの推進を行う。 2024年11月から事業執行役員VPoEに就任。 X: @ysk_118 株式会社ログラス 事業執行役員 VPoE 飯田 意己 Yoshiki Iida
3. • ログラスのミッション • これまでのログラス • FASTへの挑戦 • 1年間の学び • 開発⽣産性にどう向き合うか アジェンダ
4. ログラスのミッション
7. 経営企画は「企業価値の向上」をミッションに、企業経営にまつわるあらゆる業務を担っている
8. 今後の展望
9. 今後の展望
10. 昨年のおさらい
11. 昨年の伊藤（当時VPoE/現CTO）の登壇 https://www.youtube.com/watch?v=CYPRRxHq84E より
12. 昨年の伊藤（当時VPoE/現CTO）の登壇
13. 昨年の伊藤（当時VPoE/現CTO）の登壇
14. 昨年の伊藤（当時VPoE/現CTO）の登壇
15. 昨年の伊藤（当時VPoE/現CTO）の登壇
16. 昨年の伊藤（当時VPoE/現CTO）の登壇
17. 昨年の伊藤（当時VPoE/現CTO）の登壇
18. 昨年の伊藤（当時VPoE/現CTO）の登壇
19. 昨年の伊藤（当時VPoE/現CTO）の登壇
20. アジャイルフレームワーク FASTへの挑戦
21. • ドメインの複雑さ × 横断的体験の整合性 → 経営管理領域の難しさ🔥 • パフォーマンス課題への継続的な対処 → 扱うデータ量の増加🔥 • 認知負荷とチーム間連携のトレードオフ → 機能領域別チームでの個別最適(サイロ)化🔥   （機能Aの拡張に機能Bも変更が必要な場合のチーム間連携コスト） 前提となるプロダクト組織が向き合う課題
22. 解決したい課題 • デリバリー、ディスカバリー双⽅に組織全体で向き合えるようにする ◦ 機能領域を跨いでプロダクト全体の価値を捉えられるようにする • 機能領域別チームの枠をとっぱらい、組織全体の機動性を⾼める ◦ プロダクト全体で最も優先順位の⾼い課題に機動性⾼くチーム組成する → 上記課題の解消のため、FASTというアジャイルフレームワークを導⼊ 機能領域に閉じた最適化からプロダクト全体での最適化に向かえるように
23. • Quinton Quartelが提唱したスケーリング フレームワーク • OSTから着想を得ている • 提案されたアイテムに開発者が集まり チームを結成 ◦ 流動的なチーム構成 ◦ 「何を開発するか」は “コレクティブ” の集合知で決まる • 個々の開発者の⾃律性が強く要求される ◦ ルールが⾮常に少なく⾃由度が⾼い FASTについて簡単に説明 「動的なチーミングと自律 MAXで組織をスケールさせるアジャイルフレームワーク FASTとは？」 https://prd-blog.loglass.co.jp/entry/2024/09/12/181043 より
24. スケーリングフレームワークの例 • Scrum@Scale • LeSS • SAFe • Nexus • FAST 国内で事例のあるフレームワークも選択できたが、これまでのスクラムでも⾃律性 を⼤事にしてきた組織⽂化があり、少ないルールで柔軟性の⾼いFASTがスタート アップにおける機動性に対してもFitすると考え、チャレンジを決定した。 FASTについて簡単に説明
25. FASTの価値、原則、柱 価値 原則 柱 • 自律性 • 目的の共有 • 熟達 • 協働 • 自己組織化 • 自己管理 • ナチュラルリーダーシッ プ • 正しいことをせよ • T字型であれ • チームプレイヤーであれ • 経験を分かち合い、学び 合え • 複雑適応系 • オープンスペーステクノ ロジー • Y理論によるガバナンス • リーンスタートアップ • 流動的なチーミング • ダンパー数 • ネットワーク型組織 FAST Guide(Japanese) から作成 https://drive.google.com/file/d/1jkKpvhWcF1N0-7B-9tCkRNXZnphHrHxP/view
26. FASTについて簡単に説明 チームA データ取込 チームB マスタ設定 データ変換 チームC データ 分析‧出⼒ スクラム時代の構造 1つのコードベース 3つの機能領域 3つのチーム スロットA スロットB スロットC スロットD FASTでの構造 1つのコードベース 1つのコレクティブ 流動的なチーミングの枠（社内用語：スロット） バックログA バックログB バックログC Big Picture アイテムD アイテムC アイテムA アイテムB コレクティブ
27. どうFASTを導⼊したか？ https://speakerdeck.com/yoshikiiida/rsgt2025 RSGT2025の資料を参照 現場の自律性を引き出すこ とと、組織全体の意思決定 をリードすることのバランス の難しさについて解説してい ます。
28. 1年間の学び
29. • 流動性の解釈の深まり(内部‧外部) • 品質への向き合い⽅ • ⾃律性の解釈の深まり • サイロとの継続的な戦い • 守破離の捉え⽅ 1年での学び
30. • 流動性の解釈の深まり(内部‧外部) • 品質への向き合い⽅ • ⾃律性の解釈の深まり • サイロとの継続的な戦い • 守破離の捉え⽅ 1年での学び
31. • 初期のころは各スロットの⼈の出⼊りも多かった • ⾃律的に動くというマインドが⽣まれたのはよかったが、コミュニケーション コストが上がるという指摘もあった • 考案者⾃⾝も時間経過とともに移動は落ち着いていくと⾔っている 学び： 流動性を特徴として持っているが、 流動しなくてはいけないということではない 流動性の解釈の深まり（内部）
32. • 新規事業と既存事業の流動性 • FASTだから外部とも⾃由に出⼊りできるわけではない 学び： スクラムとの対⽐で流動性が特徴ではあるが、 内部での出⼒を⾼めるためにはコレクティブとしての安定性は重要 流動性の解釈の深まり（外部） 経営管理 新規事業A 新規事業B
33. • 流動性の解釈の深まり(内部‧外部) • 品質への向き合い⽅ • ⾃律性の解釈の深まり • サイロとの継続的な戦い • 守破離の捉え⽅ 1年での学び
34. 「チームの枠を流動的にする」 ↓ 「スクラムよりも⼩さいチーム単位を構成」 品質への向き合い⽅
35. • ⼀⾒並列数を上げられると錯覚するが、実際には戦⼒分散してしまっている • 結果として品質課題につながるシーンもあった 学び： スクラムでは固定的なチームの枠があるため、その中でのメンバーの出⼊りによる チームが有している知識‧スキルの増減はわかりやすい FASTにおいても各スロットで⼗分なメンバーが揃っているかは重要な視点 品質への向き合い⽅
36. 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 より
37. • 流動性の解釈の深まり(内部‧外部) • 品質への向き合い⽅ • ⾃律性の解釈の深まり • サイロとの継続的な戦い • 守破離の捉え⽅ 1年での学び
38. 過度に⾃律性を守らなければいけない？という空気感 ⾃律性の解釈の深まり 自律性が大事だから上 段の方針レベルまでに とどめて詳細は任せた ほうがいい？ 入社して間もないけど 自律的に動かなけれ ばいけない？ 影響範囲が大きいけど 自律的に意思決定でき ないといけない？
39. • 「FASTでやっているから⾃律的に動かないといけない」 ◦ → スクラムでも⾃律性は求められる ◦ → コレクティブという⼤きな枠での⾃律性はより難易度が⾼い • FASTによって難易度が上がったという混乱‧⼾惑いはあった 学び： どんなやり⽅にせよ、Whole Productで今どこに向かうべきなのか、何を最優先で⽚付けなければいけない のか？を考えなければいけない。 ⾃律性を合議と捉えると歪んでしまう。 誰かが意思決定をしなくてはいけないが、 Product Owner(相当の⼈)がスタンスを取る=⾃律性を損なう、ではない。 ⾃律性の解釈の深まり
40. • 流動性の解釈の深まり(内部‧外部) • 品質への向き合い⽅ • ⾃律性の解釈の深まり • サイロとの継続的な戦い • 守破離の捉え⽅ 1年での学び
41. • 機能領域に分かれた複数のチームが それぞれ独⾃のチームのカルチャー を持っていた • チーム間でのコラボレーションの際 にチームの⽂化の違いがコミュニ ケーションコストという形で顕在化 した スクラム時代のサイロ チームA データ取込 チームB マスタ設定 データ変換 チームC データ 分析・出力 1つのコードベース、 3つの機能領域、3つのチーム
42. • 初期は流動性⾼く⼈の動きが発⽣していた • だんだんと落ち着いていき、それぞれのス ロットで新たなやり⽅、⽂化が形成されはじ めた 学び： やり⽅に問わず、環境次第でサイロの⼒学は働 いてしまう。チーム間での協働の視点を常に持 ちながら個々の仕事を進める視点が必要。 FASTによってサイロは崩されたが‧‧ スロットA スロットB スロットC スロットA スロットB スロットC
43. • 流動性の解釈の深まり(内部‧外部) • 品質への向き合い⽅ • ⾃律性の解釈の深まり • サイロとの継続的な戦い • 守破離の捉え⽅ 1年での学び
44. FASTの「守り」とは何か FASTの守破離 価値 原則 柱 • 自律性 • 目的の共有 • 熟達 • 協働 • 自己組織化 • 自己管理 • ナチュラルリーダーシッ プ • 正しいことをせよ • T字型であれ • チームプレイヤーであれ • 経験を分かち合い、学び 合え • 複雑適応系 • オープンスペーステクノ ロジー • Y理論によるガバナンス • リーンスタートアップ • 流動的なチーミング • ダンパー数 • ネットワーク型組織
45. FASTの「守り」とは何か FASTの守破離 価値 原則 柱 • 自律性 • 目的の共有 • 熟達 • 協働 • 自己組織化 • 自己管理 • ナチュラルリーダーシッ プ • 正しいことをせよ • T字型であれ • チームプレイヤーであれ • 経験を分かち合い、学 び合え • 複雑適応系 • オープンスペーステクノ ロジー • Y理論によるガバナンス • リーンスタートアップ • 流動的なチーミング • ダンパー数 • ネットワーク型組織 太字にした箇所は普段の活動でも意識できてそう
46. • FASTの「守」が完全にできているとは⾔えない ◦ スクラムよりもルールは少ないが、価値や原則など考え⽅に関する要素が 多く、学習し⾃然に馴染むまでは時間がかかる • 対して、スクラムの原則である「透明性、検査、適応」については 多くのメン バーが馴染んでいる ◦ スクラムがよく定着しているとも⾔えるし、アンラーニングできていない とも⾔える ◦ 無理にアンラーニングしていくことが現状の我々にとっての最適解なの か？ FASTの守破離
47. • FASTの「破」に⼊っているところもすでにある ◦ マーケットプレイスにてその場その場の状況を⾒て流動的にチーミングを ⾏うことが前提だが、ある程度未来を⾒通すためにスロットの配置の予測 を⽴てる取り組みをしている ◦ 流動性とは逆⾏するので少なくとも「守」ではない • FASTをベースにしつつもログラスなりの現時点の最善を模索している FASTの守破離 安定的なチーム組成：スクラム 流動的なチーム組成： FAST
48. 開発⽣産性にどう向き合うか
49. • 前提として、⼤規模なモノリスがベースとなっており、 全体の開発⽣産性を精緻に計測することはスクラムでもFASTでも難しい • やっていること ◦ Findy Team+による可視化 ◦ リリースノート集計の可視化 ◦ 品質ダッシュボード ◦ コードベースの増加量推移 ◦ 内部品質の可視化 開発⽣産性との向き合い⽅
50. コード量とリリースごとのコード変更量の推移 開発⽣産性との向き合い⽅ プロダクトコードは線形的に増加しながら、 一人当たりのコード変更量のペースは維持。 コードベースが大きくなっても変更容易性に ついては維持ができている。
51. • ⼀⽅で新機能リリースや改善のリリースノートの数⾃体はダウントレンドが あった ◦ ひとつひとつの開発規模が⼤きくなりリードタイムは増加している ◦ ソースコードやデータ量の純増による⾮機能的な開発の⽐率も上がっている • その上でフレームワーク移⾏によるダウンタイムは存在する 複合的な要因が絡み合うため何かの単⼀指標で⽣産性を説明することはしていない 開発⽣産性との向き合い⽅
52. AI活⽤については間違いなく今後のゲームチェン ジャーであり、全⽅位的に⾼い実⾏強度で取り組ん でいる。 各種メトリクスはあくまでメトリクスとして扱いつ つ、変数となるレバーを定め、施策実⾏をセットで モニタリング → 課題認識に対して何をアクションしているのかを ⽰すことが重要 開発⽣産性との向き合い⽅ 引用元） 「Claude Code Week」既存事業で 1週間AI縛りで開発したことで見えた ゲームチェンジと開発フローの再構築の必要性 https://zenn.dev/loglass/articles/b286b1e8f0947b
53. FASTとの関連性はどうか？
54. • 流動性の解釈の深まり(内部‧外部) → 仕事量の⽣産性、期待付加価値の⽣産性 • 品質への向き合い⽅ → 仕事量の⽣産性 • ⾃律性の解釈の深まり → 期待付加価値の⽣産性 • サイロとの継続的な戦い → 期待付加価値の⽣産性 • 守破離の捉え⽅ → 仕事量の⽣産性 FASTの学びに対しての⽣産性の観点からのふりかえり
55. 仕事量の⽣産性 • 流動的なチーミングは課題優先順位に対 して適切なチーミングができれば、フ ロー効率を⾼められる ◦ ⼀⽅で適切な判断にならない場合、 戦⼒分散するリスクもある • 開発が⻑期化するものについては配置を あらかじめプランニングすることでフ ロー効率を⾼められる FASTの学びに対しての⽣産性の観点からのふりかえり 期待付加価値の⽣産性 • 流動的なチーミングによって機能領域を 跨いだメンバーが集まることで、横断的 な価値を考慮できる体制構築ができる • 機能領域別のチームの枠をなくすこと で、プロダクトマネジメントの意思決定 は全体俯瞰の意識が強化された
56. • コードベースの状態、リリース頻度、変更量、障害発⽣率、新機能数、リード タイム、、など、基本的なメトリクスをモニタリングしながら、全体としての 開発プロセスのアップデートを進めてきた • 仕事量の⽣産性の改善は⽐較的わかりやすいアクションに紐付けられるが、 期待付加価値の⽣産性の改善は⾮常に難易度が⾼い🔥 ◦ 現状は体制としてこれに向かう取り組みが前に進んだところだが道半ばの状態 ◦ お客様の意思決定がより良くなったか？課題発⾒がしやすくなったか？ 業務効率化できたか？、、、など、付加価値の観点は複数存在し、恒常的なモニタ リングまでは⾄っていない 開発⽣産性との向き合い⽅
57. FAST導⼊によって得られたこと • 現状課題はまだ多く残っており、練度を上げ切れてはいない状況 • ⼀⽅、ルールの少なさゆえに混乱もあったが、結果として現場のアジャイルに向き合う 本質的な試⾏錯誤を促進できた側⾯も⽣まれた ◦ 改めて全体観を持ちながらプロダクト開発をしていく重要性 ◦ それに向き合う組織としてのマインドセット 開発⽣産性との向き合い⽅ メンバーの発信も増やすことができた。 https://speakerdeck.com/wooootack/fast-taug ht-me-large-scale-agile-hardships-and-fun
58. ⽣産性とは何か ⽣産性 = 単位◦◦あたりの⽣産量、価値 これを計測することで得られるものは過去から現在のやり⽅に関する情報のみ。 また、ここから出せるアクションはあくまで短期的なアクションに過ぎない。 つまり、⽣産性を改善するというアクションだけでは、⻑期的な価値を⾒落とすリスクがある。 VPoEとしてのアカウンタビリティ t 現在 ちょっと先の未来の改善を積み重ねることはできる 長期の理想状態に至れるか？は別の話
59. FASTの評価 短期的には組織の動き⽅を⼤きく変えたので⽣産性は下がっている。しかし、スクラムの中 でなんとなく回ってしまっていた状況を⾒つめ直す機会にもなった。 プロダクト全体の価値を捉えることの難しさを体感した。チームを超えてコラボレーションす ることの⼤事さを体感した。⾃分たちで改善していくことの重要性を体感した。いろいろな 組織としての学習が進んだ。 この価値は⽣産性だけでは測ることができない。 VPoEとしてのアカウンタビリティ
60. ⻑期⽬線のスタンスを取ること ⽣産性で測れるような短期の合理性も重要である。 しかし、⻑期視点の、短期では合理的ではないように⾒える取り組みも重要である。 例えば、⽂化やアイデンティティといった、より抽象的な開発組織としての強みを作るための 活動をどう維持できるか？など。 ⻑期視点のスタンスを持ち、取り組みを維持する説明を継続することがVPoEの責務 VPoEとしてのアカウンタビリティ
61. ⾃律的なスケーリング⼿法FASTにおける VPoEとしてのアカウンタビリティとスタンス #開発⽣産性con_findy 2025.07.03 株式会社ログラス 事業執⾏役員 VPoE 飯⽥意⼰ @ysk_118
62. まとめ
63. • 機能領域のフィーチャーチームからWhole Productに向き合うためのスケーリングを FASTというフレームワークを⽤いて取り組んできた • スケーリングの過程において、 ◦ 流動性や⾃律性の解釈が進んだこと ◦ 品質をあげるためのチーム構成の要素 ◦ サイロの⼒学 ◦ FASTの守破離 という学びがあった • 仕事量の⽣産性および、期待付加価値の⽣産性それぞれの解像度は上がったが、取り組 みや運⽤の熟達度はまだ道半ば ◦ AI時代の新しいスタンダードへのチャレンジが次の1年の取り組み • ⻑期的な価値となる学びもあり、ここへの投資はVPoEのスタンスが重要である まとめ
64. FASTに取り組んできた1年を現場⽬線で振り返り、リアルな苦悩や試⾏錯誤を 発信するイベントを実施します。 7⽉24⽇（⽊）19:00-@ログラスオフィス/オンライン お知らせ