stakeholders-org-design

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

目次

1. ワークフロー
2. ステークホルダーのマッピング
3. チーム間インターフェース契約
4. ケイパビリティ成熟度
5. 一般的なパターン
6. ガードレール
7. クイックリファレンス

ワークフロー

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

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 契約

明記する内容：エンドポイント、データ形式／スキーマ、認証、レート制限、バージョン管理／後方互換性 例：サービス：User Auth API | 所有者：Identity Team | エンドポイント：/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 回	月 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 ドメイン
• 複雑：関連するドメインを 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 枚のピザ、ダンバー数）、認知負荷の限界、インターフェースの所有者を明確化、マトリックス組織の弊害を回避