全員がプロダクトへ向き合う組織を持続成長させるために——組織づくりのフライホイールと4象限 / The Flywheel Model and Four Quadrants for Organizational Design

2026.09.05 Product Engineering Conference 2026

Transcript

1. 全員がプロダクトへ向き合う組織を 持続成長させるために 組織づくりのフライホイールと4象限 2026.09.05 / Product Engineering Conference 2026
2. 自己紹介 とりい 2023.04〜 EM @ Grooves ➔ 趣味 ◆ アニメを⾒ること、油絵を描くこと ➔ 推し書籍 エンジニアリング組織論への招待 ◆ アジャイルリーダーシップ ◆ チーム‧ジャーニー ◆ LeanとDevOpsの科学 ◆ 急成⻑を導くマネージャーの型 ◆ 良い戦略、悪い戦略 ◆ ラディカル‧プロダクト‧シンキング ◆ これまでの経験 組織づくり、ScM、採⽤、⽬標＆評価、 CRE、全社業務改善、全社AI推進 など https://aviary-gallery.vercel.app/
3. アジェンダ 01 背景と前提 ⾃分とプロダクトエンジニアリングの関係、現場で起きていたこと 02 組織づくりのフライホイール 組織を持続成⻑させるために 03 2軸4象限での施策分類 2つの軸と4つの象限、各象限の代表施策 04 フライホイール×4象限 3つの段階と、その⽴体化 05 診断と活用例 組織づくりを診断するステップと、⾃⾝の失敗を踏まえた活⽤例 06 まとめ
4. なぜ組織の話をするのか より多くの価値をユーザーへ届け、より遠くにあるビジョンを実現するためには 何かしらのプロダクトと組織が不可欠 プロダクトを介したユーザーへの提供価値、その質とサイクル向上のため プロダクト開発メンバーもユーザーと事業ドメインへの理解を深めたほうが良い！ そう信じて、全員がプロダクトと事業へ向き合う組織づくりを続けています 自分とプロダクトエンジニアリングの関係 「歴史のあるプロダクトと組織」 ユーザーへの提供価値を 最⼤化していくためにどうしよう プロダクトエンジニアリングの コミュニティで個⼈や組織の実践例を キャッチアップ 2024.03〜 2026.09 「プロダクトエンジニア」との出会い 現在 2027〜 2023.04 2025.02〜 Grooves⼊社 コミュニティとの出会い プロダクトエンジニアリングを軸に ⾃分たちの組織づくりも再構成 AIの浸透で開発のボトルネックも変化 プロダクトエンジニアリングへの追い⾵
5. 私たちの現場で起きていたこと Crowd Agent（10年超のBtoBプラットフォーム） 40 ビジネス 名前後 対 10 数名 開発（Eng‧PdM‧PD） 求⼈企業と⼈材紹介会社、顧客が2⽅向にいる複雑なドメイン 分業が健全に機能していたからこそ、開発が顧客から 遠くなる CSが顧客の声を拾える。各チームが⾃組織の数値を追える体制。 PdM、デザイナー、エンジニアのロール分けも機能していた。 「プロダクトエンジニア」という⾔葉との出会いで、⽬指すべき⽅向 性が決まった
6. 組織づくりでよく言われていること 一人の熱量だけで施策は継続しない 組織づくりに唯一の正解はない 何かを始めるために熱量は必要だが、熱量だけでは継 個別の事例はそこに⾄るまでの背景が重要。 続しない。 組織規模‧プロダクトフェーズ‧⽂化など全く同じ状 周囲のメンバーも動いていけるかどうか。 況はない。⾃分たちの取り組みは⾃分たちで正解にし ていくほかない。 今⽇のゴール 個別事例の紹介で終わらず、⾃組織の現在地を診断し、次の⽅針を考えられる状態を⽬指します
7. 組織を持続成長させるためのフライホイール 今⽇の結論につながる話の⼀つ 組織づくりの施策は独⽴しておらず、 個⼈から仲間、仕組み、制度へと広げていく ことで、組織の持続成⻑へとつながる 委ねる 施策を広げていく順序であり、段階的に 進めていくために「解像度」と「信頼」が 重要になる
8. 施策を振り返るための2軸と4象限 施策の属性や偏りを分析するために活⽤ トップダウン 【アラインメント】 【制度の整備】 マインド 仕組み 【啓蒙活動】 【協働の仕組み化】 ボトムアップ
9. マッピングしてみると トップダウン 【アラインメント】 04 ⽬指す組織像のNotion公開 【制度の整備】 07 取り組みの称賛 08 効果の定性‧定量共有 10 VoC閲覧権限の整理 14 分析Skills‧MCPの全社利⽤ 11 「価値に向き合う」を話し続ける マインド 13 仕様に答えるDevinを全社展開 18 トレンドを上‧横へ共有 15 評価制度‧⽬標設定の⾒直し 16 ⾮エンジニアの環境構築⽀援 21 キャリアの先を⽰す 20 求⼈呼称を統⼀ 22 委員会制の導⼊ 仕組み 23 聴く‧観察を続ける 01 コミュニティ感想の社内共有 03 発表内容の記事化 05 顧客理解資料の集約ページ 02 コミュニティでLT発表 06 リードエンジニア挙⼿‧推薦制 17 職能拡張系コミュニティ参加 19 システム思考の紹介 12 職能横断で話せる場を定期開催 ドッグフーディング デュアルトラックアジャイル 【啓蒙活動】 【協働の仕組み化】 ボトムアップ
10. 【啓蒙活動】社外コミュニティへの参加と社内共有 WHY ・身近なところから共感・推進してくれる仲間を探す アラインメント 制度の整備 ・プロダクトエンジニアリングへの自身の解像度を高める WHAT ・コミュニティへの参加や発表 ・他社事例のキャッチアップ ・行動や所感を社内へ共有 HOW Slack雑談チャンネル・全社向け日報・1on1など複数のチャネル 啓蒙活動 協働の仕組み化 でまずは自分からN=1で盛り上がる🔥
11. 【啓蒙活動】社外コミュニティへの参加と社内共有 WHY ・身近なところから共感・推進してくれる仲間を探す アラインメント 制度の整備 ・プロダクトエンジニアリングへの自身の解像度を高める WHAT ・コミュニティへの参加や発表 ・他社事例のキャッチアップ ・行動や所感を社内へ共有 HOW Slack雑談チャンネル・全社向け日報・1on1など複数のチャネル 啓蒙活動 協働の仕組み化 でまずは自分から盛り上がる🔥 Slackでの共有
12. 【アラインメント】目指す組織像の公開と、上・横への共有 WHY ・ありたい姿を定め、各自が自走する方向性を迷わせない アラインメント 制度の整備 ・隣接組織やメンバーにも活動を広く知ってもらう WHAT ・目指したい組織の形を資料化、定量・定性効果の発信 ・他Mgr・上長・経営などにも共有し続ける HOW ・日々の業務から参照しやすい場所にリンクや画像を設置 ・1on1などでも触れて、情報に触れる機会を増やす 啓蒙活動 協働の仕組み化 啓蒙活動と近いが、より⾃組織に置き換えた整理や発信が必要
13. 【アラインメント】目指す組織像の公開と、上・横への共有 WHY Notionでの資料整理 1on1での共有 ・ありたい姿を定め、各自が自走する方向性を迷わせない アラインメント 制度の整備 ・隣接組織やメンバーにも活動を広く知ってもらう WHAT ・目指したい組織の形を資料化、定量・定性効果の発信 ・他Mgr・上長・経営などにも共有し続ける https://tech.grooves.com/entry/2025/05/19/141223 HOW ・日々の業務から参照しやすい場所にリンクや画像を設置 ・1on1などでも触れて、情報に触れる機会を増やす 啓蒙活動 協働の仕組み化 啓蒙活動と近いが、より⾃組織に置き換えた整理や発信が必要
14. 【協働の仕組み化】リードエンジニア制 WHY ・属人的な取り組みから再現性を抽出する アラインメント 制度の整備 ・挑戦のハードルを下げ、巻き込める人数を増やし、オーナー シップ醸成につなげる WHAT ・職能に閉じないコミュニケーション機会の型化 ・プロジェクトのリードエンジニアを、挙手制・推薦制に 啓蒙活動 協働の仕組み化 HOW 検証フェーズから、PM・プロダクトデザイナーと密に連携して いく
15. 【協働の仕組み化】リードエンジニア制 WHY ・属人的な取り組みから再現性を抽出する アラインメント 制度の整備 ・挑戦のハードルを下げ、巻き込める人数を増やし、オーナー シップ醸成につなげる WHAT ・職能に閉じないコミュニケーション機会の型化 改善施策を検討したり ・プロジェクトのリードエンジニアを、挙手制・推薦制に ドッグフーディングを実施したり 啓蒙活動 協働の仕組み化 HOW ディスカバリーフェーズから、PM・プロダクトデザイナーと密 に連携していく
16. 【制度の整備】評価と採用 WHY 個人や組織のプロダクトエンジニアリングに報い、長期的に持 アラインメント 制度の整備 続成長させるため WHAT ・職能に囚われない評価制度・目標設定への見直し ・採用要件や選考基準の見直し HOW ・目標、1on1、振り返り、評価と各メンバーと伴走する ・採用段階からプロダクトエンジニアリングの目線を合わせる 啓蒙活動 協働の仕組み化 協働の仕組み化は現場主体、制度整備は中⻑期⽬線で枠組みとしてMgr主体
17. 【制度の整備】評価と採用 WHY 個人や組織のプロダクトエンジニアリングに報い、長期的に持 アラインメント 制度の整備 続成長させるため WHAT ・職能に囚われない評価制度・目標設定への見直し ・採用要件や選考基準の見直し HOW ・目標、1on1、振り返り、評価と各メンバーと伴走する ・採用段階からプロダクトエンジニアリングの目線を合わる 啓蒙活動 協働の仕組み化 協働の仕組み化は現場主体、制度整備は中⻑期⽬線で枠組みとして広め ※採⽤要件や選考基準も⾒直し 共通認識を取っています https://speakerdeck.com/hiro_torii/evaluating-product-engineers-from-a-managers-perspective
18. 4象限図とフライホイールを合わせて考えてみると × 委ねる 組織づくりの具体的な進め方や振り返り観点が見えてくる ここから3つの段階に分けて⾒ていきます
19. ①まずは個々の力で動かす 仲間を増やしながら取り組みを継続し、 解像度を高める ⼩⼈数での仕組み化にも徐々にトライ いきなり制度化は難しい。⾃分の解像度も、周囲の 理解も⾜りない アラインメント‧啓蒙‧協働を⼩さく繰り返す（⽰ す、巻き込む、試して学ぶ） まだまだ各々の熱量に依存した状態 次の段階へ 小さな仕組み化を進め、 定量・定性で成果が見え始めたら②へ
20. ②仕組み化から範囲を広げる 仕組み化からさらに活動範囲を広げる 仕組み化による実績や影響を周知し、協働メンバ ーを拡⼤。新たな取り組みにつなげる 範囲を広げるために把握すること（観察する・聴く） 定量 リリース数、DORA、会話量、フロー時間 定性 チームアンケート、1on1 ⾃分の場合は「SPACE」に相当する指標を定義し、 定期的に更新 チームアンケートの設計と収集例; https://zenn.dev/grooves/articles/0c7adbd143e183 次の段階へ 自分たちの組織で範囲を広げる方法が見え 推進や運用を担える人が増えたら③へ
21. ③制度化への道のり 中長期的な枠組みとして制度を用意する 制度化が機能すると、組織の⾃⾛化と委譲も進み、 次の啓蒙‧アラインメント‧仕組み化が始まる 制度化の先 ⾃分たちの⾔葉でプロダクトエンジニアリング を説明できる 推進や運⽤を担う⼈が増えている 委ねる 私たちで⾔うと、2024年には組織がPdEとは？という状態 2026年には開発‧採⽤‧新規メンバーの共通⾔語へと浸透
22. 4象限図xフライホイールにおける「高さ」の概念 フライホイールを回す中で 仕組み化範囲を広げたり制度化が進んだり… 各象限を平⾯的には移動できない ただの平面図ではなくz軸に相当する「積み重ね」が存在する？
23. 解像度と信頼 z軸に相当するもので、⽇々の活動を通して積み上げていくもの 解像度 信頼 01 変革テーマへの理解 02 組織内での関係性 試したこと、わかったこと、どう変えたいか、 メンバー同⼠が価値観や得意不得意を知っている Why, What, Howを含め⾃分たちの⾔葉で語れる 懸念や反対意⾒も率直に話せる 推進や運⽤をお互いに任せられる テーマごとに深める 次のテーマにも持ち越せる 01 × 02 → 事業フェーズや組織の歴史を踏まえた、⾃分たちに実現可能な進め⽅ができる →取り組みを続けながら周囲をよく観察すること‧話を聴くことが重要（プロダクト開発と似ている） 関係性が⼗分に構築された組織では、テーマの理解を深めることへ集中できる
24. 組織づくりの状況を診断するステップ 01 これまでの施策を4象限で振り返ってみる 02 フライホイールのどこかで止まっているか考えてみる 極端な偏りがあった場合、その背景を考えてみる 個々が頑張る段階か、範囲を広げていく段階か、 次の周回を狙う段階か 03 自身やチームの到達度を計る テーマへの理解、組織内の関係性 推進や運⽤を委譲できるメンバーの有無 04 次の方針を考える 何を試すか、誰と進めるか、どうやって振り返るか 委ねる
25. 付録
26. 自身の振り返り 事象 図では「アラインメン ト」に比重を置きすぎ ていた 「エンジニアの活動領域をもっ と広げたい」 資料を作成したり事例も共有し ていた N=1の取り組みなどは生まれた が、現場での仕組み化は進まな い 施策 診断 → ループでは「②巻 き込む」が不足 エンジニア以外、巻き込めて いなかった PdM・デザイナー・POとも会 話し、目指したい開発や体制 を聴く → チームの共通言語・共通理解 を増やす機会として、協働 ワークやコミュニケーション の機会から増やす 観察することと聴くことは前提として、4象限とフライホイールを組み合わせたことで、 「仕組み化」施策を継続せず「巻き込む」ための施策を重視することができた
27. まとめ 個人の熱量から組織の当たり前へ 個々の⼒→仕組み化→範囲拡⼤→制度化 ⽇々の活動からテーマの理解と組織内の関係性を深める 唯一の正解がないからこそ現在地を診断する 4象限とフライホイールの概念を活⽤し、現在の段階とこれか ら取りうる施策の⽅針を検討する そこから何を試し、誰と進め、どうやって振り返るか 決める 委ねる
28. アジャイルソフトウェアの12の原則より "The best architectures, requirements, and designs emerge from self-organizing teams.” “最良のアーキテクチャ‧要求‧設計は、⾃⼰組織的なチー ムから⽣み出されます。”
29. プロダクト開発と並⾏し、 プロダクトと向き合える組織も育てていきましょう！ ありがとうございました！！