逆コンウェイ戦略とPlatform as a Productで進めるチームトポロジー段階的移行ガイド

Last updated at 2026-03-28Posted at 2026-03-28

逆コンウェイ戦略とPlatform as a Productで進めるチームトポロジー段階的移行ガイド

この記事でわかること

逆コンウェイ戦略（Inverse Conway Maneuver）の原則と、望ましいアーキテクチャからチーム構造を逆算する設計手法
CNCF Platform Engineering成熟度モデル（2026年版データ）に基づく組織の現在地評価と移行ロードマップの作り方
Platform as a Productの実践手法：専任PPM（プラットフォームプロダクトマネージャー）によるプロダクトライフサイクル管理
9つのプラットフォームエンジニアリング・アンチパターンを回避しながら段階的に移行する方法
AI/MLワークロード統合を見据えたIDPの拡張設計パターン

対象読者

想定読者: DevOps・CI/CDの基礎知識があるMLエンジニア・ソフトウェアエンジニア
必要な前提知識:
- ソフトウェア開発チームでの協業経験（スクラム・カンバンの基礎概念）
- CI/CDパイプラインの基本的な理解（GitHub Actions等を使ったことがある程度）
- 「チームトポロジー」の4つのチームタイプ（Stream-aligned・Platform・Enabling・Complicated-subsystem）の概要レベルの理解
- 「認知負荷」はMLの文脈ではなく、開発者が把握すべき技術的複雑性を指します

関連記事: IDPツール選定については「Backstage・Port・Humanitecで比較するIDP設計と成熟度モデル実践ガイド」、Backstage+Crossplane+ArgoCDの実装については「Backstage+Crossplane+ArgoCDで構築するPlatform Engineeringの設計と導入」も参照してください。

結論・成果

DORA 2025レポートによると、90%の組織がIDP（内部開発者プラットフォーム）を導入し、76%が専任プラットフォームチームを設置しています（Announcing the 2025 DORA Report）。一方で、CNCF・platformengineering.orgの2026年版データでは、29.6%の組織が成功指標を一切計測しておらず、成熟した運用に到達したのは13.1%に留まっています（Platform Engineering Maturity in 2026）。

この「導入済みだが成熟していない」ギャップを埋めるカギが、逆コンウェイ戦略に基づく段階的移行とPlatform as a Productのプロダクトマネジメント手法です。本記事では、成熟度モデルの各レベルに沿った具体的な移行パターンと、先行企業の失敗事例を交えて解説します。

逆コンウェイ戦略で「望ましいアーキテクチャ」からチーム構造を設計する

コンウェイの法則を理解する

コンウェイの法則（Conway's Law）とは、「組織のコミュニケーション構造がそのままシステム設計に反映される」という経験則です。1967年にMelvin Conwayが提唱し、その後の研究で繰り返し確認されています（Conway's Law - Martin Fowler）。

MLエンジニアの方には、MLパイプラインの設計に例えるとわかりやすいかもしれません。データチーム・モデルチーム・サービングチームが完全に分離された組織では、データ前処理→学習→推論の各段階にチーム間の受け渡しが発生し、パイプライン全体のフローが遅くなります。これがコンウェイの法則の典型的な表れです。

逆コンウェイ戦略（Inverse Conway Maneuver）は、この法則を逆手に取る手法です。「望ましいソフトウェアアーキテクチャを先に決め、それを実現するようにチーム構造を変える」というアプローチです（How Can the Inverse Conway Manoeuvre Help Drive Organisational Change?）。

# 逆コンウェイ戦略の設計プロセス
inverse_conway_process:
  step_1_define_architecture:
    description: "望ましいシステムアーキテクチャを定義"
    example: "マイクロサービス + IDP + セルフサービスインフラ"
    # MLパイプラインでいう理想的なDAG構造を先に設計するイメージ

  step_2_derive_team_structure:
    description: "アーキテクチャからチーム境界を逆算"
    teams:
      - stream_aligned: "ビジネスドメインごとに1チーム"
      - platform: "共通インフラをプロダクトとして提供"
      - enabling: "新技術の導入を支援"
      - complicated_subsystem: "専門知識が必要な領域を担当"

  step_3_define_interactions:
    description: "チーム間のインタラクションモードを設計"
    modes:
      - x_as_a_service: "Platformチーム → Stream-alignedチーム"
      - facilitating: "Enablingチーム → Stream-alignedチーム"
      - collaboration: "期間限定の密な協業（新機能立ち上げ時など）"

  step_4_evolve_gradually:
    description: "一度に全部変えず、段階的に移行"
    anti_pattern: "ビッグバン式の組織再編は失敗率が高い"

Team Topologies第2版の新しい視点

Team Topologiesの第2版（2025年9月刊行）では、いくつかの重要な概念が更新されています（Team Topologies 2nd Edition - IT Revolution）。

第1版からの主な進化ポイントは以下の通りです。

観点	第1版（2019年）	第2版（2025年）
組織の捉え方	効率的な機械	繁栄するエコシステム
適用範囲	ソフトウェアチーム	全社変革・マルチ企業ポートフォリオ
プラットフォームチーム	単一チーム	プラットフォームグルーピング（フラクタル構造）
認知負荷	考慮事項の一つ	設計原則の中核
事例	初期採用者中心	世界各国10の新規事例

特に注目すべきはプラットフォームグルーピングの概念です。大規模組織では、単一の「プラットフォームチーム」ではなく、プラットフォーム自体がStream-aligned Team・Enabling Team・Complicated-subsystem Teamを内包するフラクタル構造を持つという考え方です。

注意点:

プラットフォームグルーピングは50人以上のプラットフォーム組織に適した設計です。10人前後の小規模チームでは、過度な分割が認知負荷を逆に増大させるリスクがあります。組織規模に応じた適切な粒度の判断が必要です。

組織診断：あなたのチームはどのフェーズか

逆コンウェイ戦略を適用する前に、まず現在の組織状態を診断する必要があります。以下のチェックリストで現在地を確認してみましょう。

# team_topology_assessment.py
# チームトポロジー移行フェーズ診断ツール
# Python 3.11+, 外部依存なし

from dataclasses import dataclass
from enum import Enum


class MaturityPhase(Enum):
    """CNCF成熟度モデルに基づくフェーズ分類"""
    PROVISIONAL = "Provisional"      # 暫定的・受動的
    OPERATIONAL = "Operational"      # 運用レベル
    SCALABLE = "Scalable"            # スケーラブル
    OPTIMIZING = "Optimizing"        # 最適化

    # MLエンジニア向け補足:
    # Jupyter Notebookで実験 → MLflow導入 → Kubeflow本番運用 → 自動最適化
    # という成熟度の進化に似たイメージ


@dataclass
class AssessmentQuestion:
    question: str
    dimension: str  # Investment, Adoption, Interfaces, Operations, Measurement
    scores: dict[str, int]


QUESTIONS = [
    AssessmentQuestion(
        question="プラットフォームチームに専任予算はあるか？",
        dimension="Investment",
        scores={
            "ボランティア・兼務のみ": 1,
            "専任チームあるが受動的（チケット対応中心）": 2,
            "専任チームでプロダクトロードマップあり": 3,
            "クロスファンクショナルなエコシステム": 4,
        },
    ),
    AssessmentQuestion(
        question="開発者はプラットフォームをどう使っているか？",
        dimension="Adoption",
        scores={
            "使っていない・知らない": 1,
            "マネジメントの指示で使用": 2,
            "プラットフォームの価値を感じて自発的に使用": 3,
            "開発者自身がプラットフォームに貢献": 4,
        },
    ),
    AssessmentQuestion(
        question="プラットフォームの成功を何で測定しているか？",
        dimension="Measurement",
        scores={
            "測定していない": 1,
            "ポータルログイン数などの活動指標": 2,
            "DORA指標・開発者満足度": 3,
            "ビジネス成果（Time-to-Market・コスト削減率）": 4,
        },
    ),
]


def assess_maturity(answers: list[int]) -> MaturityPhase:
    """回答スコアから成熟度フェーズを判定"""
    avg = sum(answers) / len(answers)
    if avg < 1.5:
        return MaturityPhase.PROVISIONAL
    elif avg < 2.5:
        return MaturityPhase.OPERATIONAL
    elif avg < 3.5:
        return MaturityPhase.SCALABLE
    else:
        return MaturityPhase.OPTIMIZING


# 使用例
if __name__ == "__main__":
    # 各質問への回答スコア（1-4）
    sample_answers = [2, 2, 1]  # 典型的な「導入済みだが成熟していない」組織
    phase = assess_maturity(sample_answers)
    print(f"診断結果: {phase.value}")
    # => 診断結果: Provisional
    print(f"推奨アクション: まず成功指標の測定を開始してください")

CNCF成熟度モデルに沿った段階的移行パターンを設計する

成熟度モデルの4レベル×5次元を理解する

CNCF Platform Engineering成熟度モデルは、プラットフォームの成熟度を4レベル×5次元で評価するフレームワークです（CNCF Platform Engineering Maturity Model）。

platformengineering.orgが518名を対象に実施した2026年版の調査データを見ると、各次元の分布には大きなばらつきがあります。

次元	Level 1	Level 2	Level 3	Level 4	注目ポイント
Investment	13.1%	45.5%	28.3%	13.1%	半数近くが「予算あるが受動的」
Adoption	17.0%	36.6%	28.2%	18.3%	強制的な導入が最多
Measurement	29.6%	24.2%	32.1%	14.1%	約3割が未計測

（出典: Platform Engineering Maturity in 2026: What the data tells us）

注目すべきはMeasurement次元の遅れです。Investment・Adoptionが進んでいてもMeasurementが追いついていない組織が多く、「プラットフォームを作ったが効果を証明できない」状況に陥っています。

Level 1→2：受動的チームから能動的チームへ

Level 1（Provisional）からLevel 2（Operational）への移行は、多くの組織にとって最初のハードルです。この段階でよくあるのが、Jellyfish社が指摘する**「リブランディング・アンチパターン」**です（9 Platform Engineering Anti-Patterns That Kill Adoption）。

既存のインフラチームや運用チームの名前を「プラットフォームチーム」に変えただけでは、チケット駆動の受動的な運用モデルは変わりません。

Level 1→2の移行で実行すべき3つのアクション:

最も頻度の高いチケットをセルフサービス化する: 開発者から最も多いリクエスト（環境構築、権限付与など）を特定し、それを自動化する
プラットフォームの「ユーザー」を定義する: Stream-aligned Teamを「顧客」として認識し、ニーズをヒアリングする
1つの指標を計測し始める: 「環境構築にかかる時間」など、開発者の待ち時間を定量化する

# level1_to_2_migration.yaml
# Level 1→2 移行チェックリスト
migration_checklist:
  prerequisite:
    - "チケットログから上位5つの頻出リクエストを抽出"
    - "開発者3名以上にヒアリング（15分×3回）"

  actions:
    - name: "セルフサービス環境構築"
      description: "最頻出リクエストをGitHub Actions/Backstageテンプレート化"
      success_metric: "環境構築リードタイム: 数日 → 30分以内"
      # MLエンジニア向け: JupyterHub Spawnerで
      # GPUインスタンスをワンクリック起動するイメージ

    - name: "開発者ヒアリング定例化"
      description: "月1回、30分のフィードバックセッション"
      success_metric: "開発者NPS（Net Promoter Score）の計測開始"

    - name: "ダッシュボード構築"
      description: "プラットフォーム利用状況の可視化"
      success_metric: "DORA 4指標のうち最低1つを継続計測"

  anti_patterns_to_avoid:
    - "名前だけ変えて運用モデルを変えない（リブランディング）"
    - "開発者の声を聞かずに機能を作る（孤立開発）"
    - "全社一斉導入を強制する（マンデート型採用）"

Level 2→3：プロダクトマインドセットの導入

Level 2からLevel 3への移行で最も重要なのが、Platform as a Productのマインドセットです。CNCF成熟度データによると、この段階で専任PPM（プラットフォームプロダクトマネージャー）を導入している組織はわずか21.6%です。38%はエンジニアが兼務でプロダクト思考を実践しようとしていますが、25.4%はプロダクトマインドセット自体が欠如しています。

platformengineering.orgの2026年予測では、「プロジェクトマネージャーをそのままプラットフォームPMに転換するのは失敗パターン」と指摘されています。プラットフォームの「プロダクト」は社外顧客向け製品とは異なり、開発者の認知負荷を削減するという特殊な価値提供が求められるためです（10 Platform Engineering Predictions for 2026）。

よくある間違い: 最初は「社外向けプロダクトマネジメントの手法をそのまま適用すればよい」と考えがちですが、実際にはプラットフォームのユーザー（開発者）は自らが技術者であるため、一般的なユーザーリサーチとは異なるアプローチが必要です。具体的には、開発者の日常ワークフローに直接組み込む形でのフィードバック収集が有効です。

Level 3→4：ビジネス価値とAI統合

Level 4（Optimizing）に到達している組織は全体の13.1%に過ぎません。この段階では、プラットフォームの成功をDORA指標だけでなくビジネス成果で測定することが求められます。

platformengineering.orgの2026年予測によると、「Platform Teamはビジネスバリューエンジニアリングに転換する」とされ、成功指標は「収益への貢献」「回避できたコスト」「利益貢献度」で測定されるようになります。

また、DORA 2025レポートの重要な知見として、プラットフォーム品質が高い場合にのみAI採用効果が発揮されることが明らかになっています。プラットフォーム品質が低い組織では、AIツールを導入しても効果が限定的だったと報告されています。

Platform as a Productの実践手法を導入する

プロダクトライフサイクルで運営する

Platform as a Productとは、社内プラットフォームを「社外向けプロダクトと同等の規律で運営する」アプローチです。O'Reilly刊『プラットフォームエンジニアリング』（Camille Fournier, Ian Nowland著、2025年日本語版刊行）では、プラットフォームチーム内のプロダクトマネージャーの役割が体系的に解説されています（O'Reilly Japan プラットフォームエンジニアリング）。

LegalOn Technologiesの事例では、認証基盤を独立したプロダクトとして位置づけ、開発チームを「顧客」として扱うことで、ゲートキーパー（遅延の原因）からイネーブラー（価値の源泉）への転換に成功しています（Platform as a Product - LegalOn Technologies）。

Platform as a Productの5つのフェーズ:

開発者リサーチの具体的手法

プラットフォームの「顧客」である開発者のニーズを把握するには、社外顧客向けのリサーチとは異なるアプローチが必要です。

# platform_user_research.py
# プラットフォーム開発者リサーチ計画テンプレート
# Python 3.11+, 外部依存なし

from dataclasses import dataclass, field
from enum import Enum


class ResearchMethod(Enum):
    """開発者リサーチの手法"""
    SHADOWING = "シャドーイング"        # 開発者の横で作業を観察
    DIARY_STUDY = "日記調査"           # 1週間の作業ログを記録してもらう
    FRICTION_LOG = "フリクションログ"   # 困った瞬間をリアルタイムで報告
    NPS_SURVEY = "NPSサーベイ"         # 四半期ごとの満足度調査
    OFFICE_HOURS = "オフィスアワー"     # 週1回の自由相談枠


@dataclass
class ResearchPlan:
    """四半期ごとのリサーチ計画"""
    quarter: str
    methods: list[ResearchMethod]
    target_teams: list[str]
    key_questions: list[str] = field(default_factory=list)
    success_criteria: str = ""


# 実践例: Q1リサーチ計画
q1_plan = ResearchPlan(
    quarter="2026-Q1",
    methods=[
        ResearchMethod.FRICTION_LOG,    # 最も投資対効果が高い
        ResearchMethod.OFFICE_HOURS,    # 低コストで継続可能
    ],
    target_teams=["推薦チーム", "検索チーム", "決済チーム"],
    key_questions=[
        "環境構築で最も時間がかかるステップは？",
        "デプロイ時に不安を感じる瞬間はどこか？",
        "現在のCIパイプラインで改善してほしい点は？",
        # MLチーム特有の質問:
        "GPUリソースの確保にどれくらい待たされるか？",
        "実験環境と本番環境の差異で困ったことは？",
    ],
    success_criteria="フリクションポイント上位5件の特定と優先順位付け",
)


def prioritize_friction_points(
    friction_logs: list[dict],
) -> list[dict]:
    """フリクションログから優先度を計算

    Args:
        friction_logs: [{"issue": str, "frequency": int,
                         "severity": int, "team": str}]
    Returns:
        優先度スコアでソートされたリスト
    """
    for log in friction_logs:
        # 優先度 = 頻度 × 深刻度
        # 深刻度: 1=軽微, 2=業務影響あり, 3=ブロッカー
        log["priority_score"] = log["frequency"] * log["severity"]
    return sorted(friction_logs, key=lambda x: x["priority_score"], reverse=True)


# 使用例
if __name__ == "__main__":
    sample_logs = [
        {"issue": "GPU確保に半日待ち", "frequency": 20, "severity": 3, "team": "ML"},
        {"issue": "環境変数の設定漏れ", "frequency": 50, "severity": 1, "team": "全体"},
        {"issue": "ステージング環境がない", "frequency": 10, "severity": 3, "team": "決済"},
        {"issue": "CIが遅い（30分以上）", "frequency": 40, "severity": 2, "team": "全体"},
    ]
    prioritized = prioritize_friction_points(sample_logs)
    for item in prioritized:
        print(f"[{item['priority_score']:3d}] {item['issue']} ({item['team']})")
    # => [ 80] CIが遅い（30分以上） (全体)
    # => [ 60] GPU確保に半日待ち (ML)
    # => [ 50] 環境変数の設定漏れ (全体)
    # => [ 30] ステージング環境がない (決済)

日本企業の実践事例：enechainの組織再編

エネルギー取引プラットフォームを提供するenechainでは、チームトポロジーの原則に基づいてSREデスクの再編を実施しました（チームトポロジーの観点で見直すプラットフォーム開発組織 - enechain Tech Blog）。

課題: SREデスクに全インフラリクエストが集中し、プロダクトチームがセルフサービスで対応できない状況。戦略的な取り組みが後回しになり、目の前の要求対応に追われていた。

実施した再編:

再編前	再編後	Team Topologiesの分類	インタラクションモード
SREデスク（全部担当）	SREデスク	Enabling Team	Facilitating（信頼性プラクティスを教育）
	Platform Engineeringデスク	Platform Team	X-as-a-Service（セルフサービス基盤を提供）
	Securityデスク	Complicated-subsystem Team	X-as-a-Service（セキュリティ機能を提供）

成果: CTOが1ヶ月以内に確認した変化として、明確なオーナーシップの確立、2〜3年スパンのロードマップの策定開始、人員増に頼らない問題解決アプローチの定着が報告されています。

制約条件: この事例はエンジニア数十名規模の組織のものです。数百名以上の組織では、さらに多層的なプラットフォームグルーピング（前述）が必要になる可能性があります。また、再編は一度で完了するものではなく、3〜6ヶ月ごとにインタラクションモードの見直しが推奨されます。

9つのアンチパターンを回避して移行を成功させる

戦略・実行・文化の3カテゴリで整理する

Jellyfish社の調査で特定された9つのアンチパターンは、戦略的・実行的・文化的の3カテゴリに分類できます（9 Platform Engineering Anti-Patterns That Kill Adoption）。

各アンチパターンの詳細と回避策を見ていきましょう。

戦略的アンチパターンと回避策

1. リブランディング・アンチパターン

既存のインフラチームの名前を「Platform Team」に変更しただけで、チケット駆動の受動的な運用モデルを変えないケースです。

回避策: サービスマインドセットからプロダクトマインドセットへの転換を行います。成功指標を「チケット解決時間」から「開発者のセルフサービス率」「環境構築リードタイム」に変更することが有効です。

2. 孤立開発（Field of Dreams）アンチパターン

「作れば使ってもらえる」という前提で、開発者のヒアリングなしに数ヶ月〜数年かけてIDPを構築し、リリース後に誰も使わないケースです。

回避策: 開発者を顧客として扱い、ユーザーリサーチ→MVP→フィードバック→改善のサイクルを回します。最初のMVPは「1つの高摩擦問題」を解決する最小限のものにします。

3. マグパイ（カラス）症候群

Service MeshやeBPF、AIオーケストレーターなど、最新技術を追いかけることがプラットフォームの目的になってしまうケースです。

回避策: 地味だが実際の苦痛を解決する自動化を優先します。「開発者が最も時間を無駄にしている作業は何か」から逆算してロードマップを組みます。

実行的アンチパターンと回避策

4. UI先行アンチパターン

美しい開発者ポータルを構築したが、裏側の自動化エンジンがなく、ポータルからリクエストを送ってもチケットが発行されるだけのケースです。

回避策: API・Golden Path・自動化エンジンを先に構築します。UIは後から追加する「Thinnest Viable Platform」アプローチが有効です。

5. 過剰設計アンチパターン

あらゆるユースケースに対応しようとして、プラットフォーム自体が複雑なブラックボックスになるケースです。80%のケースをカバーする「舗装道路」（Paved Road）を提供しつつ、残り20%には「脱出口」（Escape Hatch）を用意します。

6. Day2軽視アンチパターン

プラットフォームを「プロジェクト」として構築し、完成後にチームを解散させるケースです。ドキュメントが腐り、バグが蓄積し、プラットフォームが足かせになります。

回避策: プラットフォームは永続的なプロダクトチームで運営します。継続的な予算とロードマップが必要です。

文化的アンチパターンと回避策

7. スキル集中トラップ

シニアエンジニアをプラットフォームチームに集中させ、プロダクトチームが判断力を失うケースです。

回避策: ナレッジシェアリングのローテーションを導入し、Enablingチームがプロダクトチームの技術力向上を支援します。

8. 強制採用アンチパターン

プラットフォームの使用を全社義務化すると、開発者は不満を声に出さなくなり、重要なフィードバックが得られなくなります。

回避策: 採用は任意にします。プラットフォームが「最も簡単で速い選択肢」であれば、自然に採用率は上がります。低い採用率はプロダクトの問題として捉えます。

9. 間違った指標の追跡

ポータルのログイン数やテンプレート利用回数といった虚栄の指標（Vanity Metrics）を追跡し、ビジネス成果との接続がないケースです。

回避策: 以下の指標をDORA推奨のH.E.A.R.T.フレームワークで構造化します。

# platform_metrics.yaml
# プラットフォーム指標の構造化（H.E.A.R.T.フレームワーク）
metrics:
  happiness:
    description: "開発者満足度"
    measurements:
      - "四半期NPS（目標: +30以上）"
      - "CSAT（5段階、目標: 4.0以上）"
    # MLエンジニア向け: モデルの精度指標に相当

  engagement:
    description: "プラットフォーム利用頻度"
    measurements:
      - "週次アクティブユーザー率（目標: 80%以上）"
      - "セルフサービス完了率（目標: 70%以上）"

  adoption:
    description: "新チームの取り込み"
    measurements:
      - "新チームオンボーディング時間（目標: 1日以内）"
      - "Golden Path採用率（目標: 60%以上）"

  retention:
    description: "継続利用"
    measurements:
      - "月次離脱率（目標: 5%未満）"
      - "Escape Hatch利用率（高すぎるとPFの改善余地あり）"

  task_success:
    description: "タスク達成"
    measurements:
      - "環境構築リードタイム（目標: 30分以内）"
      - "デプロイ頻度（DORA指標）"
      - "変更失敗率（DORA指標、目標: 15%未満）"

AI/MLチームをチームトポロジーに統合する

DORA 2025の知見：プラットフォーム品質とAI効果の相関

DORA 2025レポートでは、プラットフォーム品質が高い組織でのみAI採用が組織パフォーマンスを向上させるという重要な発見が報告されています（DORA Capabilities: Platform Engineering）。プラットフォーム品質が低い場合、AIツールを導入しても効果は限定的でした。

platformengineering.orgの2026年版調査でも、94%がAI統合を重要視し、86%が「プラットフォームエンジニアリングがAI価値実現に不可欠」と回答しています。しかし同時に、59%がAI導入に必要なスキルギャップに直面しているという課題も明らかになっています。

AI/MLワークロード対応IDPの参照アーキテクチャ

2026年の予測として、DevOpsとMLOpsが統合パイプラインに収斂する動きが指摘されています。アプリケーション開発者・MLエンジニア・データサイエンティストが単一のデリバリーパイプラインを共有する世界です（10 Platform Engineering Predictions for 2026）。

MLチームのチームトポロジー配置パターン

MLチームのチームトポロジー上の配置は、組織規模と成熟度によって異なります。

パターン	MLチームの分類	適する組織	メリット	リスク
A: Stream-aligned	ML機能を含むStream-aligned Team	小規模、ML機能が1〜2個	ビジネス価値に直結	MLの専門性が分散
B: Complicated-subsystem	ML専門チーム	中規模、ML基盤が複雑	専門性の集約	ビジネス理解が薄れる
C: Platform内包	Platform TeamのML基盤担当	大規模、MLPlatformが成熟	スケーラブル	ML固有のニーズへの感度低下

パターンBの実装例:

# ml_team_topology.yaml
# MLチームのチームトポロジー配置例（パターンB）
team_structure:
  stream_aligned_teams:
    - name: "推薦チーム"
      responsibility: "ユーザー推薦機能のE2E"
      interaction_with_ml:
        mode: "X-as-a-Service"
        what: "学習済みモデルAPIを利用"
    - name: "検索チーム"
      responsibility: "検索ランキングのE2E"
      interaction_with_ml:
        mode: "Collaboration"
        what: "新モデル立ち上げ時は期間限定で密に協業"
        duration: "2-4スプリント"

  complicated_subsystem_team:
    - name: "MLプラットフォームチーム"
      responsibility: "モデル学習・推論・モニタリング基盤"
      provides:
        - "学習パイプラインのテンプレート"
        - "モデルサービング基盤（推論API）"
        - "実験追跡ダッシュボード（MLflow/W&B）"
        - "GPUリソース管理（Kueueによるキューイング）"
      interaction_mode: "X-as-a-Service（基本）"

  enabling_team:
    - name: "ML品質チーム"
      responsibility: "MLOps・データ品質のベストプラクティス普及"
      interaction_mode: "Facilitating"
      activities:
        - "データ品質チェック手法の教育"
        - "モデルモニタリングの導入支援"
        - "A/Bテスト設計のレビュー"

ハマりポイント: MLチームを完全にPlatform Teamの内部に組み込む（パターンC）と、ML固有のニーズ（実験の反復速度、データ品質、モデル精度のトレードオフ）がプラットフォームのロードマップ上で後回しにされるリスクがあります。Complicated-subsystem Teamとして独立性を保ちつつ、Platform TeamとはX-as-a-Service（GPU/TPUリソース提供）の関係を構築するのが推奨パターンです。

よくある問題と解決方法

問題	原因	解決方法
プラットフォーム導入後も開発速度が上がらない	認知負荷の高い部分が自動化されていない	フリクションログで実際のボトルネックを特定し、上位3件を優先解決
プラットフォームチームがチケット対応に追われる	Level 1→2移行が不完全、セルフサービス化が不足	上位5件のチケットをテンプレート化・自動化し、チケット数の推移を計測
開発者がプラットフォームを使わない	孤立開発・強制採用アンチパターン	開発者ヒアリングを実施し、1つの高摩擦問題を解決するMVPを提供
経営層にプラットフォームの価値を説明できない	Measurement次元がLevel 1（未計測）	Time-to-Market・環境構築時間の削減率をビジネス成果として定量化
MLチームがプラットフォームの恩恵を受けていない	汎用プラットフォームがGPU/実験管理に非対応	ML固有のGolden Path（GPU確保→学習→デプロイ）を追加提供

まとめと次のステップ

まとめ:

逆コンウェイ戦略は「望ましいアーキテクチャからチーム構造を逆算する」手法。Team Topologies第2版（2025年9月刊行）で認知負荷が設計原則の中核に位置づけられた
CNCF成熟度モデルの4レベル×5次元で現在地を評価し、段階的に移行する。DORA 2025によると90%の組織がIDP導入済みだが、13.1%しかLevel 4（最適化）に到達していない
Platform as a Productのマインドセットが移行の成否を分ける。専任PPMの導入は21.6%に留まっており、プロダクト思考の欠如がLevel 3→4のボトルネックになっている
9つのアンチパターン（戦略的3・実行的3・文化的3）を理解し、特に「リブランディング」「孤立開発」「間違った指標」の3つが最も頻度が高い
AI/MLワークロード対応がプラットフォームの新たな責務として浮上。プラットフォーム品質が高い場合にのみAI採用効果が発揮される（DORA 2025）

次にやるべきこと:

組織診断を実施する: 本記事のアセスメントツール（team_topology_assessment.py）で現在のフェーズを特定する
フリクションログを1週間収集する: 開発者の日常的な苦痛ポイントを定量化し、最初のMVPのスコープを決定する
1つの指標を計測し始める: 環境構築リードタイムやデプロイ頻度など、最もインパクトのある指標を1つ選んで継続計測する

参考

CNCF Platform Engineering Maturity Model - CNCF公式の成熟度モデル
Platform Engineering Maturity in 2026: What the data tells us - 2026年版成熟度データ分析
9 Platform Engineering Anti-Patterns That Kill Adoption - Jellyfish社の9アンチパターン
10 Platform Engineering Predictions for 2026 - 2026年の10予測
Announcing the 2025 DORA Report - DORA 2025レポート
DORA Capabilities: Platform Engineering - DORA公式プラットフォームエンジニアリング解説
Team Topologies 2nd Edition - IT Revolution - Team Topologies第2版
Conway's Law - Martin Fowler - コンウェイの法則の解説
How Can the Inverse Conway Manoeuvre Help Drive Organisational Change? - CTO Craft - 逆コンウェイ戦略の組織変革への応用
O'Reilly Japan プラットフォームエンジニアリング - Camille Fournier, Ian Nowland著
Platform as a Product - LegalOn Technologies Engineering Blog - LegalOnの実践事例
チームトポロジーの観点で見直すプラットフォーム開発組織 - enechain Tech Blog - enechainの組織再編事例

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up