第4章 プロダクトユニット制を機能させる最小セット
組織図の変更を、実際に回る運用へ変えるための話
前回は、組織図を変えてもチームが機能しない理由は、配置換えそのものではなく、責任境界と判断レーンが設計されていないことにある、という話を書きました。
今回は、その次です。
実際に、プロダクトユニット制を回し始めるには何が必要なのか。
ユニット制を本当に機能させるには、最低限どんな資料・ルール・会議が必要なのか。
この話になると、組織はだいたい2つの失敗に分かれます。
1つは、気合いを入れすぎて制度を重くしすぎること。
もう1つは、逆に「とりあえずやってみよう」で何も定義せず、現場に丸投げしてしまうことです。
前者は、資料ばかり増えて現場が動けなくなります。
後者は、結局すべてが空気と個人依存に戻ります。
だから必要なのは、完璧な制度ではありません。
最小限だが、実際に判断を揃えられるセットです。
最初は次の4点だけで始めましょう。
- ユニット定義
- 判断レーン
- 横断インターフェース
- レビュー運用
この4つがあるだけで、ユニット制は「名前だけの制度」から「動く運用」に変わり始めます。
今回は、その最小セットを具体化します。
制度を重くしすぎても、何も定義しなくても失敗する
まず最初に、このテーマでよく起きる2つの失敗を整理します。
失敗1: 制度を重くしすぎる
ユニット制を成功させようとして、最初から全部作り込んでしまう。
- 役割定義書が何十ページもある
- 会議体が増える
- 承認フローが複雑になる
- 例外ルールが細かすぎる
- 結局、読む人がほとんどいない
この状態では、「整っている」ように見えても、現場はむしろ動きにくくなります。
特に、変化の速いプロダクト組織では、制度の精密さより、運用可能性の方がずっと重要です。
失敗2: 何も定義せずに丸投げする
逆に、「現場に任せる」「自律的にやってほしい」と言いながら、
- ユニットの責任範囲が曖昧
- どこまで決めてよいか曖昧
- 他ユニットとの接続面が曖昧
- 例外時の扱いが曖昧
という状態で始めてしまう。
これは自律ではありません。
単に、曖昧さを現場に押しつけているだけです。
本当に必要なのは、その中間です。
回る最小セットだけ先に作る。その上で、運用しながら足りないところを足していく。
これが、最初の設計の基本になります。
最小セットの全体像 - 最初は4点あれば十分始められる
最小セットとして置くのは、次の4点です。
1. ユニット定義シート
そのユニットは何を達成し、何には責任を持たないかを定義する。
2. 判断レーン
どんな判断を、誰が、どこまで、どのレーンで決めるかを整理する。
3. インターフェースシート
他ユニットとの依存関係や同期の仕方を定義する。
4. 定例レビュー設計
日々の判断やズレを更新する会議の最小構成を決める。
重要なのは、この4つがそれぞれ別物ではないことです。
- ユニット定義が責任境界を作る
- 判断レーン が判断の流れを作る
- インターフェースシートが横断接続を作る
- レビュー運用がそれらを更新する
つまり、構造を定義し、運用で回し、レビューで直すための最小ループです。
たとえば、オンボーディング改善を進める1つの判断でも、この4点は連動します。
- ユニット定義シートで「このユニットはオンボーディング完了率に主責任を持つ」と決める
- 判断レーンで「画面内で閉じる改善はユニット内、共通基盤変更は横断レビュー」と決める
- インターフェースシートで「デザインシステム変更や共通イベント定義変更は設計段階で共有する」と決める
- レビュー運用で「今週その判断をユニット内に閉じるのか、上位レーンに上げるのか」を更新する
重要なのは、4つの資料を別々に作ることではありません。
1つの判断が、この4点を通って迷わず前に進める状態を作ることです。
ここまであれば、少なくとも「誰が何をどこまで決めるのか不明」という状態はかなり減らせます。
ユニット定義シート - まず「何を持つか」と「何を持たないか」を書く
ユニット制を始めるときに、最初に必要なのはユニット定義シートです。
ここで大事なのは、「何をやるチームか」だけでなく、何をやらないチームかまで明文化することです。
たとえば、最低限このくらいの項目を用意しましょう。
ユニット定義シートの見出し例
- ユニット名
- ミッション
- 成果責任
- 非責任領域
- 主KPI
- 共有KPI
- 主な依存先 / 依存元
- 今期の重点テーマ
- 現時点のリスク / 論点
ここで特に重要なのは、次の3つです。
ミッション
このユニットは何を達成するために存在するのか。
「担当領域」ではなく、「どんな結果を出す責任を持つか」で書くのがポイントです。
成果責任
どの指標、どの体験、どの領域に責任を持つのか。
たとえば売上なのか、継続率なのか、オンボーディング完了率なのか。
“なんとなく全部”にしないことが大事です。
非責任領域
これがかなり効きます。
ユニットが関心を持つことと、責任を持つことは違います。
見てはいるが主責任ではないもの、連携はするが保持しないものを明示しておくと、後で境界が膨らみにくくなります。
ユニット定義シートは、完璧である必要はありません。
まずは1〜2ページでよいので、そのユニットの責任境界を他者に説明できる状態を作ることが大事です。
判断レーン - どんな判断を、どこまでローカルに閉じるかを決める
次に必要なのが、判断レーンです。
ユニット制にしたのに遅くなる組織は、大抵ここがありません。
つまり、「この種類の判断は、どこで完結してよいのか」が見えていない。
判断レーン とは、簡単に言うと、判断の種類ごとのレーン分けです。
たとえば、こんな分け方で十分です。
判断レーン の例
- レーン 1: ユニット内で完結してよい判断
- レーン 2: 他ユニットとの合意が必要な判断
- レーン 3: プロダクト横断レビューが必要な判断
- レーン 4: VPoP / 経営接続が必要な判断
- レーン EX: 緊急例外ルート
このレーン分けがあると、会議のたびに
「これって誰に持っていく話ですか？」
から始めなくて済みます。
何を判断レーンに書くか
最低限、次の項目があれば十分です。
- 判断カテゴリ
- 具体例
- どこで完結するか
- 誰が最終判断者か
- どの条件で上位レーンに上げるか
たとえば、
- UI文言修正や軽微な改善はユニット内で完結
- 共通コンポーネント変更は横断レビュー必須
- KPI定義変更はVPoP接続が必要
- 障害時の緊急変更は例外レーンで処理
のように置けばかなり運用しやすくなります。
大事なのは、判断レーンは権限表ではなく、判断の交通整理表だということです。
つまり、「偉い人一覧」ではなく、「どの話をどのルートで流すか」を定義するものです。
インターフェースシート - 横断依存を“仲良くやる”で済ませない
ユニット制で最も詰まりやすいのは、ユニットの中ではなく、ユニットの間です。
ここを放置すると、毎回ゼロから調整が始まります。
だから、横断依存は早めに資料化しておく必要があります。
そのための最小資料が、インターフェースシートです。
インターフェースシートの見出し例
- 接続先ユニット
- 接続が必要な論点
- どの段階で同期するか
- 共有フォーマット
- 相手側の裁量範囲
- 詰まったときのエスカレーション先
たとえば、
- 共通基盤の変更は設計段階で共有する
- KPIの定義変更は月次レビュー前に共有する
- UI一貫性に影響する変更はデザイン側レビューを通す
- 仕様確定後の大きな差し込みは例外レーンに乗せる
のように、接続条件を明文化する。
インターフェースシートのポイントは「仲良く連携しましょう」を書く資料ではないことです。
そうではなく、
- 何が同期対象か
- いつ同期するか
- 何を渡せば相手が動けるか
- どこから先は相手の裁量か
を決める資料です。
横断依存の難しさは、人間関係ではなく、接続面の未定義から生じることが多い。
だから、ここを軽くてもいいので決めておく価値があります。
定例レビュー設計 - 会議を増やすのではなく、更新点を整理する
ここまでで構造はある程度見えてきます。
でも、それだけでは足りません。
実際に運用してズレが出たときに更新できる場が必要です。
それがレビュー運用です。
ただし、ここで大事なのは、会議を増やすことではありません。
既存の会議を、判断更新の場として整理することです。
最初は次の3つで十分です。
1. 週次ユニットレビュー
目的は、ユニット内で完結する判断と、外に出すべき論点を切り分けることです。
毎回見るのはこの程度でよいです。
- 今週変わったこと
- 今ユニット内で決めるべきこと
- 上位レーンに上げるべきこと
- 詰まり / リスク
2. 隔週横断論点レビュー
目的は、ユニット間の依存や衝突を早めに処理することです。
見るべきなのは、
- 接続面で詰まっている論点
- 依存関係の優先順位
- 合意が必要な仕様 / KPI / 基盤変更
- 例外処理案件
3. 月次戦略接続レビュー
目的は、ユニットの活動が戦略とずれていないかを確認することです。
見るべきなのは、
- 重点テーマの進み方
- 前提の変化
- 継続 / 保留 / 中止の判断
- 翻訳層の修正が必要な点
重要なのは、これらを全部新設する必要はないことです。
すでに会議があるなら、目的と見出しを変えるだけでかなり改善できます。
会議体の問題は、数が多いことより、何の判断をする会議なのか曖昧なことにあります。
だから、増やすより整理する方が効きます。
具体例 - 「機能追加はユニット内、横断基盤変更はレビュー必要」と決まっているだけで速くなる
ここで単純な例を示します。
あるユニットが、オンボーディング改善のために新しい機能追加をしたい。
この変更がユニット内の画面とロジックだけで完結するなら、レーン 1 で処理できる。
ユニット内で議論し、責任者が判断し、進めればよい。
一方、その変更が、
- 共通基盤に手を入れる
- 横断KPIに影響する
- 他ユニットの運用フローに影響する
なら、レーン 2 か レーン 3 に上げる必要がある。
これが明文化されているだけで、かなり速くなります。
なぜなら、毎回「これって勝手に進めていいんだっけ？」と相談する時間が減るからです。
しかも、後から「それは先に言ってほしかった」と揉めることも減る。
つまり、判断レーン の価値は、管理を増やすことではなく、迷いと手戻りを減らすことにあります。
緊急例外判断のルールも、最初から軽く置いておく
もう一つ効くのが、緊急例外ルートです。
多くの組織では、通常時のルールは考えていても、例外時のルールがありません。
その結果、緊急時になると一気に空気の世界に戻ります。
たとえば、
- 障害時
- 大型案件の急な差し込み
- 法務 / セキュリティ論点の急浮上
- 経営判断による優先順位変更
こういうときに、最低限でも
- 誰が暫定判断をしてよいか
- いつまで有効か
- 事後にどこへ戻すか
- 何を記録するか
が決まっていると、例外が例外のまま処理できます。
逆にこれがないと、例外対応が常態化し、気が付くと通常ルールが死んでいます。
だから、緊急例外ルートは後回しにしない方がよいです。
最初から軽く置いておくと、運用が安定します。
導入時の注意 - 最初から完璧にしない
ここまで読むと、「やはりいろいろ作る必要があるな」と感じるかもしれません。
でも、ここで大事なのは、最初から完成度を上げすぎないことです。
1. 最初から完璧にしない
最初の版は粗くてよいです。
重要なのは、現場で使われることです。
読まれない完璧な制度より、使われる7割の制度の方が強い。
2. まず1ユニットで試す
最初から全組織展開しない方がよいです。
責任境界や横断依存が特に見えやすいユニットを1つ選び、まずそこで回してみる。
その方が学びが速いです。
3. 例外が多い場所から整える
詰まりやすい場所から先に整える方が効果が出やすいです。
- 他ユニット依存が強い領域
- 例外差し込みが多い領域
- 優先順位衝突が起きやすい領域
こういう場所は、制度の必要性が見えやすいので、導入も進みやすいです。
4. 運用で直す前提を持つ
最初に決めたものを絶対視しない。
週次・隔週・月次のレビューで、レーンや接続面を少しずつ調整する。
最小セットの価値は、変更可能性にあります。
この記事から持ち帰れること
もし、自分の組織でユニット制を始めようとしている、あるいは始めたのにうまく回っていないなら、まず次の4点だけを揃えてみてください。
- ユニット定義シート
- 判断レーン
- インターフェースシート
- レビュー運用
最初から大制度は要りません。
でも、この4つがないと、ユニット制は「気合いで回す仕組み」になりやすいです。
逆に、この4つがあるだけで、
- 何を持つか
- どこまで決めるか
- どこで接続するか
- どう更新するか
が見え始めます。
プロダクトユニット制を機能させる最小セットとは、要するに、責任・判断・接続・更新を運用できる状態を作ることです。
これももう少し実務的に言うと、
「このテーマは誰が持つのか」
「どこまでユニット内で決めてよいのか」
「どこで他者と接続するのか」
「次回どこで見直すのか」
が、毎回ゼロから相談されなくなる状態を作る、ということです。
まとめ
ユニット制を本当に回すには、最低限どんな資料・ルール・会議が必要か。
答えは、そこまで多くありません。
最初から大きな制度は不要です。
必要なのは、
- ユニット定義
- 判断レーン
- 横断インターフェース
- レビュー運用
の4点です。
この4つがあると、ユニット制は単なる組織図変更ではなく、運用可能な意思決定構造になります。
そして重要なのは、これを最初から完璧にしないことです。
まず最小セットで始める。
1ユニットで試す。
例外の多い場所から整える。
運用しながら更新する。
これが、ユニット制を本当に機能させる現実的なやり方だと思います。
次回は、
「ロードマップは『機能一覧』ではなく『判断の記録』である」
というテーマで、組織構造が整ったあとに、日々のテーマ判断をどう揃えるかを書きます。
Discussion