■ 1. 概要・目的
- 本資料はNick Tune著「Architecture Modernization」の組織論に関する章を中心に解説した講演資料
- モダナイゼーションを技術ではなく組織の視点で説明し明日からの行動に繋げることを目的とする
- 対象読者はモダナイゼーションに迫られたビジネスリーダーと会話をするエンジニア・モダナイゼーションに知見をつけたいエンジニア・エンジニアとの折衝を行うビジネス職
■ 2. モダナイゼーションと「組織」の問題（第1・2章）
- モダナイゼーションの障壁は技術の問題ではなく組織の問題である
- マイクロサービスに移行したのにデプロイは遅くなった
- 技術的負債の返済を始めたが半年で元の優先度に戻った
- 新アーキテクチャを設計したがチーム間の調整コストが爆発した
- モダナイゼーションが必要な理由は変化が必ず起きて競争優位性を保てなくなるため
- 業界の変化（新規参入・新製品・既存市場）
- 自社組織と外部技術の変化（メンバー離脱・技術シフト）
- 国内・世界情勢の変化（法律・関税・調達コスト増加）
- モダナイゼーションの定義は技術の刷新だけではなく技術・組織・文化の変革である
- 目指すのは「持続可能な高速フロー」
- アイデアから本番環境への迅速かつ安全なデリバリー
- 複数年にわたって維持できる能力
- コンウェイの法則によりソフトウェアの高速なフローを実現するには組織構造が密接に関係する
- システムを設計する組織はその組織のコミュニケーション構造をコピーした設計を生み出す（Melvyn Conway 1968）
- コンウェイの法則の力を無視してアーキテクチャを考え出そうとするとミスマッチが生じ多くの摩擦と問題が生じる（Martin Fowler）
- コンウェイの法則が裏目に出た事例（旅行会社）
- マーケティングIT部門とIT部門（プラットフォーム）が断絶していた
- プラットフォームAPIの信頼性が低くてもマーケティングIT側が責任を押し付けられた
- 技術的回避策（プラットフォームのデータ同期機能の構築）を選んだ結果として同期維持に認知負荷の大部分が消費された
- 教訓：ソフトウェアアーキテクチャが組織のコミュニケーション機能不全を反映してしまった
- 組織の準備確認として5つの問いを経営層に投げかける必要がある
- ビジネスリーダーは新機能開発の速度を落とす覚悟があるか
- レガシーシステムの変更が複雑で時間がかかることを理解しているか
- 予期せぬ事態が発生し大幅な遅延やコスト増加が生じた場合どう反応するか
- 予算の仕組み・作業の優先順位付けを変えチームに権限委譲する準備があるか
- 学習とスキルアップに十分な時間と資金を投資する意思があるか
- 経営層との合意形成には技術用語をビジネス言語に翻訳することが必要
- 技術的負債 → 機会損失コスト（競合は2週間で出せるものが自社は3ヶ月）
- リファクタリング → 市場投入速度の改善（新機能の開発に本来の3倍の時間がかかっている）
- アーキテクチャ刷新 → 事業継続性のリスク低減（現行システムを理解する人が2名のみ）
- 合意形成の実践アプローチは3つのステップで構成される
- ステップ1：現状を可視化する（DORAメトリクスによるデリバリー速度の定量化・障害対応コストの集計・技術的負債による機会損失の列挙）
- ステップ2：小さく始めて信頼を得る（いきなり全面刷新を提案せず3〜6ヶ月で成果が見えるパイロットを提案・成果をビジネス指標で報告）
- ステップ3：継続的にコミットメントを維持する（定期的な進捗報告をビジネス言語で行い・割り込みによる影響を可視化し数字で示す）
■ 3. モダナイゼーションに必要な組織の姿（第11・13章）
- チームトポロジー（Matthew Skelton & Manuel Pais 2019年）はソシオテクニカルなアプローチ
- 組織とソフトウェアの設計を同時に最適化する体系的なアプローチ
- 目的はチームの自律性と高速なフローの実現
- 4つのチームタイプと3つのインタラクションモードで構成される
- ソシオテクニカルとは社会システム（人間・組織）と技術システムを別々のものではなく相互依存し合う一つのシステムとして捉える概念
- 5つの基本原則
- 持続可能な高速フロー：速度と品質はトレードオフではない
- 小規模で長期的なチーム：5〜9人の安定したグループ
- チームファーストの考え方：人は「リソース」ではない
- You build it you run it：開発から運用まで一貫した責任
- 認知負荷の最小化：チームが扱える範囲に責任を制限
- 原則の実践（フローとチーム）
- 持続可能な高速フロー：高パフォーマンスチームは1日に複数回デプロイしダウンタイムも少なく回復も迅速（DORAの4つのキーメトリクスで自組織の現在地を測定可能）
- 小規模で長期的なチーム・チームファースト：5〜9人で信頼を維持しすべての作業は個人ではなくチームに向けられ目標設定と評価もチーム単位でチームはなるべく解散をしない
- 原則の実践（責任と認知負荷）
- You build it you run it：運用性を考慮した機能開発が自然に行われ他チームとのデプロイ調整が不要になりフローが大幅に高速化（7digitalの実例では各チームが毎朝ダッシュボードで確認し運用しないチームでは見たことがない良い品質が達成できている）
- 認知負荷の最小化：認知負荷には課題内在性（軽減困難）・課題外在性（削減すべき）・学習関連（増やしたい）の3種類があり高い兆候は過度のコンテキストスイッチとデリバリーペースの低下であり対処法はサブドメインが大きすぎる場合に複数の小さなサブドメインに分割すること
- 4つのチームタイプ
- ストリームアラインドチーム：バリューストリームに端から端まで責任を持つ（組織の大多数）
- プラットフォームチーム：ストリームアラインドチームの認知負荷を軽減する共有機能を提供
- コンプリケイテッドサブシステムチーム：高度な専門知識を要する複雑なサブシステムを担当
- イネーブリングチーム：新しい技術やプラクティスの習得を支援（終了条件あり）
- 内部開発者プラットフォーム（IDP）のポイント
- プラットフォームチームの役割はストリームアラインドチームの認知負荷を軽減すること
- セルフサービスで利用でき開発者体験（DX）が優れていることが重要
- 「薄いプラットフォーム」から始めチームの実際のニーズに基づいて段階的に成長させる
- 既存のクラウド（Google Cloud・AWS・Azureなど）を組織構造に合わせてカスタマイズして利用する
- 3つのインタラクションモード
- コラボレーション：2チームが密接に協力して共通目標を達成（認知負荷：高い）
- X-as-a-Service：明確に定義されたサービスを提供しinterfaceに従い利用（認知負荷：低い）
- ファシリテーティング：一方が他方のスキルアップや目標達成を支援（認知負荷：中程度）
- ポイント：コラボレーションは有用だが認知負荷コストが高くメリットが正当化できなければXaaSに切り替えるべき（チームの疎結合）
- チームトポロジーの設計は一度設計して終わりではなく継続的な見極めが必要
- 進化が必要なサイン：過度のコラボレーション（ドメイン境界が最適でない）・過度のコンテキストスイッチ（認知負荷が高すぎる）・デリバリーのペースが遅くなっている・過度なデリバリー調整（境界と変化が整合していない）
- 数年ごとの大規模な組織再編ではなく絶えず見極めて進化できる組織を構築すべきである
■ 4. モダナイゼーションを推進する組織（第15章）
- AMET（アーキテクチャモダナイゼーションイネーブリングチーム）の定義
- モダナイゼーションの慣性の力に立ち向かう一時的なチーム
- ワークショップ開催・コーチング・優先度の維持を通じてモダナイゼーションを推進
- 最終的にAMET自体が不要になる状態を目指す（一時的な足場）
- AMETではないもの：全モダナイゼーション作業を担う「モダナイゼーションチーム」・すべてのアーキテクチャを設計する「中央集権的アーキテクトチーム」
- AMETが解決する6つの課題
- 着手できない・分析麻痺 → モダナイゼーションを始動させる
- 他業務との競合で進捗が遅れる → 高い勢いを維持する
- 設計の知識・経験不足 → よりよい設計を支援する
- 従来手法への後戻り → 持続可能な変化を促進する
- 関係者がモダナイゼーションの価値を理解できない → ビジョンを周知し続ける
- ある分野の学びが他で活かされない → 学びを共有・展開する
- AMETの活動プロセス（3〜6ヶ月で始動し役割を終えたら外す）
- ヒアリングとマッピングのツアーで問題とモダナイゼーションの機会を発見
- キックスターターワークショップ（数日間対面）でビジョンの認識を合わせる
- 3〜6ヶ月以内で成果を出す具体的な行動計画を策定
- AMETの関与度は時間とともに低下し最終的に組織自身がモダナイゼーションを主導する
- 意思決定と方向性を主導
- ファシリテートから見学に後退
- 1対1コーチングでリーダーの能力を確認
- リーダー自身が主導・AMET解散
- 意思決定の分散にはアーキテクチャアドバイスプロセスを適用する
- 誰でもアーキテクチャに関する決定を下せるが影響を受ける人々と専門家に事前に相談することが条件
- ADR（Architecture Decision Records）で議論と決定を記録する
- 原則と社内版テクノロジーレーダーを意思決定の指針にする
- 週1回1時間のアーキテクチャ相談フォーラムを開催する
■ 5. モダナイゼーションを根付かせる組織（第17章）
- モダナイゼーションの成否は学習にかかっている
- モダナイゼーションが野心的であるほど学習への投資がより必要
- 継続的に「進化」を続ける必要がある
- 多くの新スキルの習得には数ヶ月を要する
- 計画・予算の段階で学習コストを考慮しないと将来の問題になる
- 学習の始め方は種をまき育てること
- 読書会のような小さな種から始める
- 同僚から尊敬されているインフルエンサーに権限を与え「トレーナー養成」方式でスキルを伝播
- 小さな成功体験を積み重ねる
- 主な学習手法
- コミュニティ・オブ・プラクティス（CoP）：共通の関心を持つ人々の定期的な集まり
- バイトサイズアーキテクチャセッション：月2回・45〜60分でチーム間の知識を広め集団的理解を深める
- メンタリングプログラム：明示的なプログラムとして確立し人事評価と同等に扱う
- モブ/ペアプログラミング：実践を通じた最も効果的な学習
- 社内テックカンファレンス：年1〜2回の知識伝播と一体感の創出
- 事例：PayFit（フランス/HRテックユニコーン/約1000人）
- エンジニアリングディレクターがDDD読書会を開始（隔週）しスタッフエンジニアと数名のマネージャから他のメンバーを巻き込んだ
- 2年かけて成長し経営陣を通し全社的な「単一の給与計算ドメインに対して」ドメインディスカバリーとモダナイゼーションを実施
- 「給与期間」を「6人が7つの異なる意味で使う」状態を解消
- 事例：Infor（CloudSuite）（アメリカ/Eコマース/約20人）
- アーキテクチャ変更の前にまず技術的卓越性の構築に注力
- Samman Methodで学習文化を育成しボトムアップでコアドメインを特定
- 逆コンウェイ操作（理想のアーキテクチャに基づきチームを組成）を段階的に適用
- Samman Method（Emily Bacheによる）
- ラーニングアワー（Learning Hours）：日々の業務から意図的に切り離された短時間（通常1時間程度）の集中学習セッションでコードカタなどを使い安全な環境で新しい技術や概念を練習する
- アンサンブルワーキング（Ensemble Working）：ラーニングアワーで学んだ技術を実際のプロダクションコードに適用していく実践プロセスでチーム全員（3〜6人程度）が一つの画面を共有し協力してコードを書くモブプログラミング形式
- 学習を組織のDNAに組み込む実践ポイント
- 学習活動は通常の勤務時間内に組み込み他の業務と同等に扱う
- メンバーのメンタリングを追加業務ではなく人事評価で同等の重要度として扱う
- 経営陣や上位層が学習を奨励していると感じさせる環境をつくる
- 7digitalの事例：月に2日間の学習時間・毎週数時間の議論タイム（CTOが強く奨励）によりすべてのチームが毎日プロダクションにデプロイし入社初日にデプロイしバグは昼食前に解決
- 学習文化のアンチパターン（優秀な人材の流出につながる）
- CTOがカンファレンス参加費を半額しか出さない
- チーフアーキテクトがカンファレンスを公然とバカにする
- メンタリングを追加業務として課しつつ同じ作業量を期待する
- 変革を技術的なものだけと考え合意形成なしに進める
- 逆コンウェイ操作を現在のシステム制約を無視して適用しようとする
■ 6. AI Agent時代の組織を考える
- 2025年以降Coding AI Agentが急速に発展
- Claude Code・GitHub Copilot・Gemini CLI Agent mode・Devin・Cursor Agentなど
- コード生成だけでなく調査・設計・テスト・リファクタリングまで一貫して実行
- 「エンジニア1人あたりの生産性」の前提が変わりつつある
- AI Agentでも変わらないもの：モダナイゼーションの本質的な難しさはコードではなくコンテキストにある
- ドメイン知識のヒアリング：「給与期間」を6人が7つの意味で使う問題はAIでは解決できない
- 組織間のコミュニケーション：部門の断絶・責任の押し付け合いは人間の課題
- ビジネスコンテキストの理解と意思決定：何をモダナイズすべきか・優先順位は何か
- AI Agentで加速できること
- 現状の可視化：レガシーコードの構造分析・依存関係の整理・ドキュメント生成
- PoCの高速作成：新アーキテクチャの検証用プロトタイプを数時間で構築
- 移行の自動化：コードの機械的なリファクタリング・テストの自動生成
- 学習の加速：コードベースの説明・ペアプログラミングの相手としての活用
- ポイント：AI Agentは「手を動かす速度」を上げるが「正しい方向」を決めるのは組織であり効率の良い「作業環境」を作るのも組織
- AI Agentを入れただけでは変わらないことが調査で示されている
- チームレベルでは改善あり（タスク完了数+21%・マージされたPR数+98%・1日あたりのPR処理数+47%）
- 組織レベルでは改善なし（全社スループート有意な相関なし・DORA指標改善なし・品質KPI改善なし）
- PRレビュー時間+91%・バグ発生率+9%という下流のボトルネックが価値を吸収（Faros AI 2025・10,000名以上の開発者テレメトリ分析）
- AI Agentを武器にするための組織の条件
- AI Agentの効果は組織の成熟度に比例する
- ドメイン知識が属人的 → Agentに正しい指示が出せず的外れな成果物が量産される
- チーム間にコミュニケーション不全 → Agentが生成したコードが他チームの前提と矛盾する
- 学習文化がない → Agentの使い方がチーム間で共有されず効果にばらつき
- ドメイン知識が共有されている → Agentに的確な指示を出せ高品質な成果物が得られる
- チームの自律性が高い → Agentを活用した素早い意思決定と実装が可能になる
- 本書の組織論を実践することがAI Agent時代の競争優位に繋がる
- AI Agent導入を経営層に伝える際のビジネスインパクト
- AI Agentを導入したい → モダナイゼーションの投資対効果を数倍に高められる
- 開発者の生産性が上がる → 新機能の市場投入を現在の半分の期間で実現できる
- 注意：Agentの導入にもコストがかかる（ライセンス・ガバナンス整備・学習時間）のでパート1で述べた合意形成のアプローチが必要
■ 7. まとめ：明日からできること
- 持続可能な高速フロー（ゴール）を実現する全体構造
- 土台：リーダーシップのコミットメント
- 必要な組織の姿（チームトポロジー）：5つの原則・4つのチームタイプ・3つのインタラクション
- 推進する組織（AMET）：始動・勢いの維持・段階的縮小
- 根付かせる組織（学習文化）：種をまく・CoP/メンタリング・DNAに組み込む
- 個人・複数人として明日からできること
- 読書会を始める（1冊・2人から）
- バイトサイズアーキテクチャセッションを試す（月2回・45分）
- 自チームの認知負荷を振り返る
- チームとして明日からできること
- DORAメトリクスで現在地を測定する
- チームの自律性レベルを確認する（ロードマップの決定権はあるか）
- You build it you run itを始める（小さく・1つのサービスから）
- 組織として明日からできること
- リーダー層に5つの問いを投げかける
- AMET的な役割を検討する
- 学習を通常業務と同等に扱う制度を設計する