読後に得られるもの（3行）
- なぜプロダクト開発組織をマトリクス型に変えたのか（背景と狙い）
- “板挟み”を前提に、役割と意思決定をどう設計したか（実務の要点）
- デメリットを踏まえつつ、変化に強い組織をどう運用するか（これから）
Schoo Advent Calendar 2025最終日担当、Schoo CTO加藤です。
今日は「プロダクト開発組織をマトリクス型に切り替えた話」を、社外の方にも伝わる粒度でまとめます。
TL;DR
- 目的は「組織図を綺麗にする」ことではなく、プロダクトが進化するスピードを上げること
- コンフリクトが起きやすいので、衝突を前提に役割・責任・意思決定を先に設計した
- 結果として、メンバーの will が前に出やすくなり、自走が増えた（体感）
- デメリットを理解して対策を立て、今後も変わり続ける前提で運用している
本記事は社外向けのため、社内の固有名詞や評価制度の詳細などは伏せています（ニュアンス重視で）。
変更の背景整理
Schooのプロダクト開発現場には、強みがあります。
体験を磨き込むデザイナー、価値の筋道を立てるプロダクトマネージャー、専門性の高いエンジニア。みんな真剣で、誠実で、プロダクトに責任を持っている。
ただ、ある時期から「もったいない」が積もってきました。
- スクラムの意思決定に関わる人が増えがち
- 「誰が最後に決めるか」が場面によって揺れる
- 合意形成が丁寧なぶん、前進のテンポが重くなることがある
これは誰かの努力不足ではなく、真面目に関わろうとするほど構造の摩擦が出る、という種類の問題でした。
プロダクト開発は時に “ちゃんと決める” より “ちゃんと進める” が先に必要になります。検証が遅れるほど学びも遅れ、学びが遅れるほど次の一手も遅れる。
この「もったいない」を減らし、未来に向けて前に進む速度を上げるために、線を引き直しました。
マトリクス組織の概要
マトリクス型の発想はシンプルです。
- プロダクト（領域）単位のチームに重心を置く（価値に責任を持つ単位を揃える）
- 一方で、専門性の育成・標準化・採用などは職能ラインでも支える
- つまり プロダクト軸 × 職能軸 の二軸で見る
やったこと一覧
以下が、今回の変更で「実際にやったこと」を整理したものです。
| 観点 | やったこと | 狙い |
|---|---|---|
| 目的 | 組織図の整理ではなく、前進速度の向上を最上位に置く | 何を優先するかをブレさせない |
| 意思決定 | チームに権限を持たせる | 意思決定速度を上げる |
| 検証速度 | 小さく出して改善を前提にする | 実験の回転数を上げる |
| 配置 | 3職種が同じ方向を見やすい単位に寄せる | 優先順位のズレを減らす |
| コンフリクト対策 | 衝突を前提に、責任・権限・期待値を言語化 | 現場とマネージャーの迷いを減らす |
| 導線 | 相談と決裁を混ぜない、エスカレーション導線を設計 | 詰まったら前に進める |
| 運用 | 課題を見つけて直す「改善ループ」を回す | 変化に強い組織にする |
| スタンス | デメリットはゼロにしない。理解して引き受ける | リターンを取りにいく |
意思決定を再設計
組織変更で効くのは、人数配置より 日々の判断がどう行われるか です。
今回、特に重視したのはこの3つでした。
ここで、前日の Day24 でEMの山田が書いた記事がとても良い補助線になります。
「優先度を明確にして同時並行を減らす」「チームで認識を揃える」「できたものから早く出して脳内メモリをクリアにする」という話は、意思決定を速くする設計と地続きです。
権限をもたせる
遅さの正体は「決裁を取りに行く」ことに時間がかかることでした。
だから、裁量を持たせ日々の決定をチームにて実施していく、情報共有は、関係者が同じ粒度で状況を把握できる形に寄せ、意思決定の前提情報をオープンにし、判断の透明性を上げました。
アップデート前提で出す
新機能は完璧な形で出すと遅くなります。検証を速く回すための体制を用意し、検証の回転数を上げるために、開発の“型”と役割分担を変えました。
※前提として、セキュリティと信頼性の基準は維持した上で、検証速度を上げています。
ディレクションを同じ方向へ
デザイナー・PdM・エンジニアが同じ目的に向かうように、チーム単位に目標を再設定しました。チーム側に重心を置くことで、同じゴールに対する会話が増えるようにしました。
課題を先回り
マトリクス組織の難所は、縦（プロダクト）と横（職能）の 衝突と板挟み です。
ここは「起きたら頑張る」だと、現場もマネージャーも消耗します。
なので今回は、コンフリクトを前提に 事前に丁寧に設計しました。
- 各ポジションの 責任範囲／意思決定権限／期待値 を言語化
- 迷いやすい論点は、人ではなく ルール に寄せる
- 相談・エスカレーションの導線（最後に誰が決めるか）を決める
（補足）「線を引く」例
- 優先順位が衝突したときの原則（どこで調整し、どこで決めるか）
- 「相談したい」と「決めてほしい」を混同しない会話の型
- 評価・育成の責任と、日々の成果の責任を混ぜない工夫
※詳細は会社ごとに違うので、ここでは雰囲気だけに留めます。
実験量を増やす
狙っているのは、次の4つです。
- プロダクトグロースを力強く推進する
- 新規プロトタイプを爆速にする
- 検証の回転数を上げる
- 意思決定を速くする
特に大事にしたいのは「実験の量」。
打席が増えれば学びが増える。学びが増えれば、次の判断の精度が上がる。
小さく出して、早く気づいて、磨いていく。
その循環が “自然に回る” 組織を作りたいです。
変化は通過点
強調しておきたいのですが、今回のマトリクス化は 到達点ではなく通過点です。
組織は一度作って終わりではなく、プロダクト・市場・事業フェーズに合わせて形を変え続けるもの。
むしろ 運用しながら直し続けること が、組織の筋肉になります。
willが強くなる
制度の話というより、空気の変化として嬉しかったのがここです。
- 職能の枠を越えて「目的」から話すことが増えた
- 「これ、やったほうがいいよね」がチームから自然に出てくる
- 許可待ちではなく、前に進める選択肢を自分たちで持てる
will は命令で増えない。
でも、will が立ち上がりやすい構造にはできる。今回それを実感しました。
デメリットを受け入れる
マトリクス化には次のようなデメリットがあります。
- 二軸になる分、調整コストが発生しやすい
- 役割が曖昧だと、意思決定が逆に遅くなる
- マネジメントが増えると、現場が “調整疲れ” しやすい
そこで私たちは「デメリットのない組織」を模索するのではなく、 デメリットを理解した上で、それ以上のリターンを取りにいく選択をしました。
そして、この形が将来のフェーズに合わなくなったら、変えていきます。理想形を固持するより、変化に強い状態であり続けることのほうが大事だと思っています。
最後にまとめ
プロダクト開発の速度は、ツールやプロセスだけで決まりません。
日々の小さな選択が、文化になって速度になります。
- いま決めるべきことは何か
- どこまでをチームで決めるのか
- 完璧を待つより、学びを先に取りにいけないか
Schooは「学び」の会社です。
だからこそ、僕ら自身が いちばん学びが回るつくり方 を選び続けたいと思っています。
今回のマトリクス化は到達点ではなく通過点です。
組織は一度作って終わりではなく、プロダクトの学びや事業フェーズに合わせて 変化し続けるもの だと考えています。
マトリクスは万能ではありません。調整コストも増えます。
それでも今は、学びを速く回し、プロダクトを前に進める ための選択として、この形が最適だと思っています。
来年は、小さく出して、早く学んで、磨いたものが次々“定番”になっていく。
そんな一年にしていきます。
読んでいただき、ありがとうございました。
Schooでは一緒に働く仲間を募集しています！