stakeholders-org-design

ステークホルダーと組織設計

目次

1. 目的
2. 使用する場面
3. 概要
4. ワークフロー
5. ステークホルダーのマッピング
6. チーム間インターフェース契約
7. 能力成熟度
8. 一般的なパターン
9. ガードレール
10. クイックリファレンス

目的

ステークホルダーと組織設計では、影響力ネットワークをマッピングし、システムアーキテクチャに沿った効果的なチーム構造（コンウェイの法則）を設計し、明確なチームインターフェースと責任を定義し、組織の能力成熟度を評価して改善の指針とするためのフレームワークを提供します。

使用する場面

次のような場合に、このスキルを呼び出します。

• 組織チームを設計または再編成する（職能別 → プロダクト別、モノリス → マイクロサービスのチーム、プラットフォームチーム）
• 変革施策のステークホルダーをマッピングする（権力・関心マトリクス、影響力ネットワーク、推進者／阻害者）
• チームのインターフェースと契約を定義する（API、SLA、引き継ぎプロトコル、意思決定権）
• 能力成熟度を評価する（DevOps／DORA、セキュリティ／CMMC、アジャイル、データ、デザインの成熟度モデル）
• コンウェイの法則を適用する（チーム構造を目指すシステムアーキテクチャに合わせる）
• ガバナンスフレームワークを確立する（RACI、意思決定権、エスカレーション経路）
• 部門横断のコラボレーションモデルを計画する（プロダクトトライアド、組み込み型と集中型）
• チームトポロジーを設計する（ストリームアラインド、プラットフォーム、イネーブリング、複雑なサブシステム）

このスキルを呼び出すきっかけとなるユーザーの表現：

• 「チームをどのように編成すべきですか？」
• 「［施策］のステークホルダーをマッピングしてください」
• 「チームのインターフェースを定義してください」
• 「［能力］の成熟度を評価してください」
• 「コンウェイの法則」
• 「チームトポロジー」
• 「RACIマトリクス」

概要

次の要素を組み合わせたフレームワークです。

1. ステークホルダーのマッピング：権力・関心マトリクス、影響力ネットワーク、意思決定権のためのRACI
2. 組織設計：アーキテクチャと戦略に沿ったチーム構造
3. チーム間インターフェース契約：API、SLA、引き継ぎプロトコル、コミュニケーションパターン
4. 能力成熟度：標準モデル（DORA、CMMC、CMM、カスタム評価基準）を使った評価

簡単な例（プラットフォームチームの設計）：

ステークホルダーマップ：

• 高い権力、高い関心：エンジニアリング担当VP（スポンサー）、プロダクトチーム（顧客）
• 高い権力、低い関心：CTO（指標を示して満足してもらう）
• 低い権力、高い関心：個々のエンジニア（情報を共有する）

チーム構造：

• プラットフォームチーム（8人）：開発者体験、インフラストラクチャ、可観測性
• インターフェース：セルフサービスAPI、ドキュメント、オフィスアワー
• SLA：稼働率99.9％、機能提供まで2週間未満、重大なバグの修正まで4時間未満

能力成熟度（DORAメトリクス）：

• デプロイ頻度：毎日 → 毎週（目標：毎日）
• リードタイム：1週間 → 2日（目標：1日未満）
• MTTR：4時間 → 1時間（目標：1時間未満）
• 変更失敗率：15％ → 5％（目標：5％未満）

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Org Design Progress:
- [ ] Step 1: Map stakeholders and influence
- [ ] Step 2: Define team structure and boundaries
- [ ] Step 3: Specify team interfaces and contracts
- [ ] Step 4: Assess capability maturity
- [ ] Step 5: Create transition plan with governance

ステップ 1：ステークホルダーと影響力を把握する

すべてのステークホルダーを特定し、関心度と権限に基づいて分類して、影響力のネットワークをマッピングします。権限・関心度マトリックスとRACIフレームワークについては、ステークホルダーのマッピングを参照してください。

ステップ 2：チーム構成と境界を定義する

アーキテクチャと戦略に沿ったチームを設計します。単純な再編の場合 → resources/template.mdを使用します。コンウェイの法則を踏まえた複雑な組織設計の場合 → resources/methodology.mdを確認します。

ステップ 3：チーム間のインターフェースと契約を明確にする

チーム間のAPI、SLA、引き継ぎプロトコル、意思決定権を定義します。契約のパターンについては、チーム間インターフェース契約を参照してください。

ステップ 4：能力の成熟度を評価する

成熟度モデル（DORA、CMMC、カスタムモデル）を使用して現状を評価します。評価フレームワークについては、能力成熟度を参照してください。

ステップ 5：ガバナンスを伴う移行計画を作成する

移行経路、意思決定権、レビュー頻度を定義します。resources/evaluators/rubric_stakeholders_org_design.jsonを使用して自己チェックします。最低基準：平均スコア ≥ 3.5。

ステークホルダーのマッピング

権限・関心度マトリックス

象限	エンゲージメント	例
権限が高く、関心度も高い	密接に管理する（頻繁にコミュニケーションを取る）	エグゼクティブスポンサー、プロダクトオーナー
権限が高く、関心度が低い	満足度を維持する（状況を報告する）	技術プロジェクトのCFO、法務
権限が低く、関心度が高い	情報を提供する（フィードバックを求める）	個人貢献者、アーリーアダプター
権限が低く、関心度も低い	監視する（関与を最小限にする）	周辺チーム

RACIマトリックス

• R - Responsible（実行責任者）：作業を実行する（複数人でも可）— 例：エンジニアリングチームが機能を構築する
• A - Accountable（説明責任者）：成果に責任を持つ（意思決定ごとに必ず1人）— 例：プロダクトマネージャーが機能の成功に責任を持つ
• C - Consulted（協議先）：意思決定の前に意見を提供する（双方向）— 例：認証設計についてセキュリティチームに相談する
• I - Informed（報告先）：意思決定の後に通知を受ける（一方向）— 例：サポートチームにリリースを知らせる

影響力ネットワークのマッピング

特定する対象：推進者（支持者）、阻害者（抵抗者）、橋渡し役（つなぎ役）、ゲートキーパー（アクセスを管理する人） マッピングする内容：誰が誰に影響を与えているか。公式・非公式の権力、信頼関係、コミュニケーションパターン

チーム間インターフェース契約

API契約

明確にする項目：エンドポイント、データ形式／スキーマ、認証、レート制限、バージョン管理／後方互換性 例：サービス：ユーザー認証API | オーナー：アイデンティティチーム | エンドポイント：/auth/login、/auth/token | SLA：稼働率99.95%、p95で<100ms

SLA（サービスレベル契約）

定義する項目：可用性（99.9%、99.99%）、パフォーマンス（p50／p95／p99のレイテンシ）、サポート応答時間（重大：1時間、高：4時間、中：1日）、容量（リクエスト数／秒、ストレージ）

引き継ぎプロトコル

デザイン → エンジニアリング：仕様、プロトタイプ、デザインレビューの承認 | エンジニアリング → QA：機能の完成、テスト計画、ステージング | エンジニアリング → サポート：ドキュメント、運用手順書、トレーニング | リサーチ → プロダクト：調査結果、推奨事項、プロトタイプ

意思決定権（DACI）

D - Driver（推進役）（調整する）、A - Approver（承認者）（必ず1人）、C - Contributors（貢献者）（意見を提供する）、I - Informed（報告先）（通知を受ける） 例：アーキテクチャ（テックリードが承認し、アーキテクトが貢献する） | 採用（採用マネージャーが承認し、面接担当者が貢献する） | ロードマップ（PMが承認し、エンジニアリング／デザイン／営業が貢献する）

能力成熟度

DORAメトリクス（DevOpsの成熟度）

メトリクス	エリート	高	中	低
デプロイ頻度	1日に複数回	週次〜日次	月次〜週次	月次未満
リードタイム	1時間未満	1日未満	1週間〜1か月	1か月超
MTTR	1時間未満	1日未満	1日〜1週間	1週間超
変更失敗率	0〜15%	16〜30%	31〜45%	45%超

一般的な成熟度レベル（CMM）

レベル 1 初期：予測不能、事後対応型 | レベル 2 反復可能：基本的な PM | レベル 3 定義済み：文書化、標準化 | レベル 4 測定：データに基づく | レベル 5 最適化：継続的な改善

カスタム能力評価

テンプレート：能力名 | 現在のレベル（根拠を添えて 1～5） | 目標レベル | ギャップ | アクション項目

よくあるパターン

パターン 1：機能別チーム → プロダクトチーム（Spotify モデル）

• 導入前：フロントエンドチーム、バックエンドチーム、QA チーム、DevOps チーム
• 導入後：プロダクトスクワッド 1（フルスタック）、プロダクトスクワッド 2（フルスタック）
• インターフェース：スクワッドは機能をエンドツーエンドで担当し、共有プラットフォームチームがインフラストラクチャを担当します
• メリット：提供の迅速化、引き継ぎの削減、明確なオーナーシップ

パターン 2：プラットフォームチームの切り出し

• きっかけ：複数のプロダクトチームがインフラストラクチャ関連の作業を重複して行っている
• 設計：セルフサービスツールを提供するプラットフォームチームを設置します
• インターフェース：プラットフォームチームの API とドキュメント、オフィスアワー、SLA
• 人員配置：エンジニアリング部門の 10～15％（プロダクトエンジニア 7～10 人につきプラットフォームエンジニア 1 人）

パターン 3：専門家の組み込みと中央集約

• 組み込み：プロダクトチーム内にセキュリティ／QA／データエンジニアを配置（緊密な連携）
• 中央集約：専門家を独立したチームに配置（一貫性、専門性の深化）
• ハイブリッド：CoE（標準を設定）＋組み込み（実装）
• 選択要因：チームの規模、成熟度、ドメインの複雑さ

パターン 4：コンウェイの法則との整合

• 原則：システム設計はコミュニケーション構造を反映します
• 適用：望ましいアーキテクチャに合わせてチームを設計します
• 例：マイクロサービス → サービスごとの小規模で自律的なチーム
• アンチパターン：モノリシックなチーム構造 → モノリシックなアーキテクチャが残り続ける

パターン 5：Team Topologies（4 つの基本タイプ）

• ストリームアラインド：変更の流れに沿ったプロダクトチーム
• プラットフォーム：ストリームアラインドチームを支援する内部プロダクト
• イネーブリング：ストリームアラインドチームの能力を高める（一時的）
• 複雑なサブシステム：複雑な領域（ML、セキュリティ）を担当する専門家

ガードレール

コンウェイの法則は避けられません：

• チームはコミュニケーション構造を反映したシステムを生み出します
• 望ましいアーキテクチャに合わせて意図的にチームを設計します
• チームの再編成 ＝ システム境界の再編成

チーム規模の上限：

• 2 枚のピザで足りるチーム：5～9 人（Amazon）
• ダンバー数：緊密に協働する関係は 5～15 人
• 小さすぎる場合（3 人未満）：脆弱で、スキルの多様性が不足します
• 大きすぎる場合（12 人超）：コミュニケーションの負担が増え、サブグループが形成されます

チームごとの認知負荷：

• 各チームが担当できるドメイン／システムの数には限りがあります
• 単純：1 チームにつき 1 ドメイン
• 複雑：関連するドメインを 2～3 個
• 非常に複雑：チームにつき複雑なドメインは最大 1 つ

インターフェースのオーナーシップを明確にする：

• すべてのインターフェースに明確なオーナーを 1 人設定します
• オーナーシップの共有 ＝ オーナー不在
• オーナー、SLA、連絡先、エスカレーションを文書化します

マトリックス地獄を避ける：

• 二重のレポートラインを最小限に抑えます（責任の所在が曖昧になります）
• マトリックスが必要な場合：主担当と副担当のマネージャーを明確にします
• 意思決定権を明示的に定義します（RACI／DACI）

ステークホルダーの疲弊：

• すべてのステークホルダーを同じように管理しないでください
• 権限／関心が高い場合＝頻繁に関与します
• 権限／関心が低い場合＝最低限の最新情報を伝えます
• 権限／関心の変化に応じて調整します

成熟度評価の現実性：

• 目標だけで評価しないでください
• 根拠に基づいて評価します（指標、成果物、観察）
• よくある落とし穴：現状を過大評価する
• 入手可能な場合は外部ベンチマークを使用します

クイックリファレンス

リソース：

• クイック組織設計：resources/template.md
• コンウェイの法則とチームトポロジー：resources/methodology.md
• 品質評価基準：resources/evaluators/rubric_stakeholders_org_design.json

5 ステップのプロセス：ステークホルダーを把握 → チームを定義 → インターフェースを指定 → 成熟度を評価 → 移行計画を策定

ステークホルダーのマッピング：パワー・関心度マトリックス（高／低 × 高／低）、RACI（実行責任者／説明責任者／協議対象者／報告対象者）、影響力ネットワーク

チームインターフェース：API 契約、SLA（可用性／パフォーマンス／サポート）、引き継ぎプロトコル、意思決定権（DACI／RAPID）

成熟度モデル：DORA（デプロイ頻度、リードタイム、MTTR、変更失敗率）、汎用 CMM（5 段階）、カスタム評価

チームの種類：ストリームアラインド（プロダクト）、プラットフォーム（内部プロダクト）、イネーブリング（能力構築）、複雑なサブシステム（専門家）

ガードレール：コンウェイの法則、チームの規模（2 枚のピザ、ダンバー数）、認知負荷の限界、インターフェースの所有者を明確化、マトリックス組織の弊害を回避