13. 文化的変革#

会議の招待メールが木曜日に届いた。件名は「ネットワークチーム体制の更新」だった。ジョルディはネットワークエンジニアとして15年のキャリアを積んでいた。CCIEを取得し、3度の買収、2度のNOC統合、そして社内のケーススタディとなるほど深刻なBGPルーティングインシデントを生き抜いてきた。彼はこれが人員に関する連絡だと思っていた。

違った。

マネージャーが説明したのは、ネットワークチームがプラットフォームエンジニアリング部門の下に再編されるということだった。チーム名は「ネットワーク自動化プラットフォーム」に変わる。仕事の内容も変わる。手動プロビジョニングは減り、プロビジョニングを担う自動化システムを構築・運用することが中心になる。新しい職務記述書はすでに書かれていた。タイトルは「ネットワークプラットフォームエンジニア」だった。

その夜、ジョルディは家に帰って職名を検索した。結果のほとんどはクラウドの求人やコンテナオーケストレーションインフラを指していた。1時間読んで、内容の半分くらいは理解できた。Pythonスクリプトを書いたことはなかった。Gitが実際に何なのか知らなかった。興奮すべきか恐怖を感じるべきか、判断がつかなかった。

その年の終わりには、ジョルディは2つの自動化ワークフローを本番環境にリリースし、ルーターを一度も設定したことのないソフトウェアエンジニアが書いた数百行のコードをレビューし、チーム初のアーキテクチャ決定記録を書いていた。彼はソフトウェア開発者ではなかった。彼は分類が難しく、もっと価値のある何かになっていた。ネットワークと、それを運用するシステムの両方を理解するエンジニアだ。

この章はその変革について書かれている。ジョルディ個人の変革だけでなく、組織全体の変革についてだ。第1章から第12章で扱った技術は、それ自体では動かない。ネットワークエンジニアリングが伝統的に育ててきたものとは異なるスキル、役割、協働の仕方を持つ人々が必要だ。技術を正しく実装することは難しい。組織の変革を正しく進めることはさらに難しく、自動化の取り組みが失敗するのも、多くの場合そこにある。

13.1 アイデンティティの危機#

文化的変革で最も難しいのは、Gitを覚えることではない。長年の深いCommand Line Interface (CLI)習熟によって築き上げたアイデンティティを手放すことだ。

ネットワークエンジニアリングは、習得が難しく偽れない専門性を中心に職業文化を形成してきた。障害時のBGP収束の挙動を理解すること。深夜2時にスパニングツリーのトポロジー変更をデバッグすること（そしてスパニングツリーは今でも現役だ）。アプリケーションチームがチケットを起票し終わる前に、パケットキャプチャを読み取ってわずかなMTUの不一致を特定すること。これらは年月をかけて培った高度なスキルであり、強いプロフェッショナルとしてのアイデンティティを生み出してきた。

自動化はその専門性の表面を揺るがす。よく設計された自動化プラットフォームがVLANプロビジョニング、設定ハードニング、ゼロタッチデバイスオンボーディングを処理するようになると、それらのタスクを手作業のCLIで長年習熟したエンジニアは、矛盾のように感じる選択を迫られる。自動化を使って自分が得意なことを置き換えるか、自分を定義するスキルを守るために自動化に抵抗するかだ。

これが**クラフツマンのジレンマ (Craftsman’s Dilemma)**だ。ある技術に深く習熟しているほど、その技術を隠す抽象化は道具ではなく脅威に感じられる。ベンダー固有のCLIの細部をすべて知っているネットワークエンジニアが抽象化レイヤーに抵抗するのは非合理ではない。完全に合理的な判断だ。専門性を馴染みのないものと交換するよう求められているのだから。

このジレンマを解く視点の転換がある。自動化は深いネットワーク知識を置き換えない。それを必要とするのだ。違いは、その知識がどこでどのように活かされるかだ。BGP収束を深く理解するエンジニアは、自動化された世界でも劣らない価値を持つ。信頼性の高いBGP閉ループ自動化を設計できる唯一の人物だからだ。スキルは実行から設計へ、コマンドの入力からどのコマンドをどの条件で実行すべきかを定義することへと移る。

「ネットワークを設定する」から「ネットワークを設定するシステムを構築する」へのこの転換こそ、この章の核心にある文化的変革だ。スキルのギャップではない。認識のギャップだ。

flowchart LR
    classDef legacy fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef emerging fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    A["**ネットワークエンジニア** - 設定を実行する - 深いデバイス専門知識"]
    B["**ネットワークプラットフォームエンジニア** - 自動化システムを設計する - コードに埋め込まれた専門知識"]

    A -->|"認識の転換"| B

    class A legacy
    class B emerging

この移行を成功させるエンジニアは、ソフトウェア開発者になろうと決意した人ではない。特定のベンダーのエッジケースで自動化が失敗し続ける理由を知りたいと思い、症状の裏にあるシステムを理解するまでその問いに向き合い続けた人だ。設定する方法だけでなく、インテントからデバイスへ設定がどのように伝わるか、障害がどう伝播するか、システムがどう回復するかを知りたいという好奇心こそが、この移行を可能にするマインドセットだ。それはまた、自動化以前の優れたネットワークエンジニアを際立たせていたマインドセットでもある。レシピを適用するだけでなく、プロトコルを理解したいと思う人たちのものだ。

その好奇心の報酬は、個人が手作業で到達できる規模を超えた影響力だ。800台のスイッチを対象に正しく動作する単一の自動化ワークフローは、チームが1週間の手動変更ウィンドウで完了できる以上の仕事を数分でこなす。そのワークフローを構築したエンジニアはそれに置き換えられていない。その人の専門知識が、眠っている間も動き、定型作業を確実にこなし、判断を要する問題のためにエンジニアリングの余力を生み出すシステムに埋め込まれたのだ。手作業のCLI習熟がどれだけ積み上がっても生み出せない、より強力な立場だ。

第1章では、自動化の障壁として変化への恐れと誤ったスキルが挙げられていた。これらの障壁は、マネージャーがチームを再編したからといって消えるわけではない。役割の定義、スキルの育成、そして深いネットワーク専門知識が新しいモデルでより価値があることを組織が示す方法として、意図的な取り組みが必要だ。

アイデンティティの危機は、まさにそこから始まることが多い。エンジニアがまだ定義できない新しい肩書き、組織もまだどうサポートすればいいか模索中の役割として。

13.2 自動化された世界における新しい役割#

自動化変革を開始するチームが尋ねる最も非生産的な質問は「どの仕事がなくなるのか?」だ。より有用な問いは「どの役割が生まれ、何を必要とするのか?」だ。

ほとんどの役割は消えるのではなく、進化する。変わるのは価値が集まる場所だ。1日8時間手動の変更チケットを処理していたオペレーターがなくなるわけではない。チケット処理の8時間がなくなり、そこで解放されたキャパシティは、チームが積極的に移行を形作らなければ、より高い価値のある仕事へと向かうか、組織的な摩擦へと向かうかのどちらかだ。

移行を成功させたチームで一貫して現れる役割を以下に示す。

• ネットワークプラットフォームエンジニア: この役割は、自動化プラットフォームをエンジニアリング成果物として所有する。プラットフォームにはSource of Truth (SoT)のスキーマ設計、実行パイプラインの設定、自動化変更を検証・デプロイするCI/CDワークフロー、ネットワークオブザーバビリティプラットフォーム、自動化ブロック間のインターフェース契約が含まれる。ネットワークプラットフォームエンジニアは、コンテナクラスターを運用したり内部開発者ツールを管理するソフトウェアプラットフォームエンジニアの対応役だ。他のエンジニアがネットワークを運用するために使うシステムを構築・維持する。この役割は第4章から第8章のアーキテクチャ作業と第10章のプラットフォームエンジニアリングパターンに直結する。

• ネットワーク信頼性エンジニア (NRE): 大規模ソフトウェアサービスのために開発されたSREモデルは、ネットワーク自動化に意味のある変更を加えて適用できる。NREの役割はSREの原則をネットワーク運用に適応させたものだ。自動化パイプラインのサービスレベル目標の定義、自動化障害のインシデント対応プロセスの構築、機能開発速度と運用安定性のバランスを保つエラーバジェットの管理。閉ループ自動化が深夜3時に誤動作したとき、NREはその障害モードのランブックをあらかじめ設計しておくことを職務とする人物だ。

• ネットワークアーキテクト: この役割はデバイスから離れ、インテントに近づく。ネットワークアーキテクトはネットワークがどうあるべきかを定義する。Source of Truthのインテントモデル、自動化が強制する設計パターン、トポロジーとアドレッシングを規律するポリシーだ。デバイスのCLIで過ごす時間は減り、スキーマ設計、クロスチームのアーキテクチャレビュー、設計上の判断が自動化をどう制約・実現するかの評価に多くの時間を割く。第4章はこの役割が主に所有するインテントレイヤーを記述している。

• ネットワークデータエンジニア: 閉ループ自動化、自己修復ネットワーク、自律運用（第15章から第17章で扱う）は高品質な運用データに依存している。ネットワークデータエンジニアはObservabilityシステムに供給するデータパイプラインを構築・管理し、テレメトリを実用的なものにするスキーマを定義し、自動化の意思決定の根拠となるデータの品質を所有する。この役割は第6章のオブザーバビリティブロックと第5部の閉ループパターンをつなぐ。

• ネットワーク自動化開発者: この役割は自動化コードそのものを書く。プラットフォームが依存するインテグレーションロジック、ワークフローオーケストレーション、検証フレームワーク、ツールだ。ネットワーク自動化開発者は、ネットワークチームに組み込まれて十分なネットワーク知識を得たソフトウェアエンジニアかもしれないし、十分なソフトウェア開発能力を身につけたネットワークエンジニアかもしれない。どちらの道でも機能する。ネットワークプラットフォームエンジニアとの重要な違いはスコープだ。自動化開発者は特定の自動化機能を提供し、プラットフォームエンジニアはその機能が動くシステムを所有する。

従来のオペレーター役割は縮小するが消えない。なくなるのは反復的な実行だ。手動プロビジョニング、チケットごとのCLIセッション、人間がスクリプトランナーとして機能するワークフロー。根本的な判断力（何かがおかしいと気づく、自動化が見逃したものをキャッチする、曖昧なインシデントで判断を下す）は価値を持ち続け、定型実行ではなく品質保証とエスカレーション所有へと移動する。

以下の図は昇進表ではない。価値がどこへ移るかの地図だ。反復的な実行から、設計、信頼性、データ、プラットフォーム所有へ。多くのエンジニアは一本の矢印に従わない。自分がすでに好奇心を持っているものに合う矢印を選ぶ。

flowchart LR
    classDef legacy fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef emerging fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    subgraph Legacy["従来の役割プロファイル"]
        direction TB
        L1[**ネットワークオペレーター** - 手動プロビジョニング - デバイスCLI習熟]
        L2[**ネットワークエンジニア** - 設計とトラブルシューティング - ベンダー専門知識]
    end
    subgraph Emerging["新たな役割プロファイル"]
        direction TB
        E1[**ネットワークプラットフォームエンジニア** - 自動化プラットフォーム - CI/CDとSoT所有]
        E2[**ネットワーク信頼性エンジニア** - SLOとインシデント対応 - エラーバジェット]
        E3[**ネットワークアーキテクト** - インテントモデル - 設計ガバナンス]
        E4[**ネットワークデータエンジニア** - テレメトリパイプライン - オブザーバビリティ品質]
        E5[**ネットワーク自動化開発者** - ワークフローとインテグレーションコード - 検証フレームワーク]
    end
    L1 -->|進化| E1
    L1 -->|進化| E5
    L2 -->|進化| E2
    L2 -->|進化| E3
    L2 -->|進化| E4
    class L1,L2 legacy
    class E1,E2,E3,E4,E5 emerging

13.3 スキル変革の道筋#

この変革を試みるすべての組織に2つの失敗パターンが現れる。1つ目は、すべてのネットワークエンジニアがソフトウェア開発者になることを期待すること。2つ目は、ネットワークチームに組み込まれたソフトウェアエンジニアが深いプロトコル知識を身につけずにネットワーク自動化を所有することを期待することだ。どちらも同じ理由で失敗する。一方の領域のスキルが意志によって移転するという前提だ。

13.3.1 T字型エンジニア#

IDEOのティム・ブラウンが提唱し、プラットフォームやDevOps組織で広く採用されているT字型エンジニアの概念が、成功する作業モデルに名前をつけた。1つの領域での深い垂直的専門性と、もう一方の広い水平的リテラシー。対称性ではない。完全な第二の専門化でもない。生産的な非対称性だ。

ネットワークプラットフォームエンジニアへの道を歩むネットワークエンジニアには、コーディング言語（例：Python）やDSL（例：YAML）を読んでデバッグして修正できる、Version Control System (VCS)のワークフローを理解できる、CI/CDパイプラインの失敗を論理的に考えられる、スキーマ設計の意思決定に参加できるだけのソフトウェア開発リテラシーが必要だ。データ構造をゼロから設計したりアルゴリズムの複雑さを最適化する必要はない。ソフトウェアエンジニアリングでのセカンドキャリアではなく、ソフトウェアの実践における運用リテラシーが必要だ。

ネットワーク自動化に移行するソフトウェアエンジニアには、BGP収束がなぜその時間かかるのか、スパニングツリーのトポロジー変更がどう伝播するか、分散ルーティングテーブルの文脈で「最終的に一貫性がある」とはどういう意味か、そしてラボでは正しく動く自動化が本番環境でベンダーの実装の違いによって失敗しうる理由を理解できるだけのネットワーク深度が必要だ。CCIEは必要ない。ネットワークエンジニアと意味のある会話ができ、自分の仮定が間違っているときに気づけるだけの基礎が必要だ。

T字型は、ドメイン間にうまく定義されたインターフェースを生み出すためのものだ。各人が相手の言語を十分に理解し、すべての会話に翻訳者を必要とせずに明確にコミュニケーションし、共同でデバッグし、共有の意思決定ができるようにする。

T字型は固定された目標ではない。役割とともに進化する。重要なのは各人の深さの軸と広さの軸を特定し、両方を尊重した学習パスを構築することだ。

ジョルディが最初の自動化プルリクエストを提出したとき、レビューしたソフトウェアエンジニアは11個のコメントを残した。変数名、エラー処理の欠如、ハッピーパスしかカバーしていないテスト。最初の反応は防御的になることだった。15年間、ネットワークを正しく設定してきたのだから。次の反応はブラウザのタブを閉じることだった。3番目の反応は、使ったことのないデバイスのインターフェースエラーであるかのように、コメントをゆっくりもう一度読み直すことだった。3回目のプルリクエストでは、説明ではなく質問をコメントに書くようになっていた。レビュアーは協力者になった。新しいドメインでエキスパートから初心者へ、そして再びエキスパートへという移行は快適ではない。しかしそれが移行の形だ。

13.3.2 基礎知識をめぐる議論#

自動化変革を進めるすべてのチームで、同じ問いが浮かぶ。深いプロトコル知識は今も重要か? CCIEの取得（またはそれに相当するもの）は今も価値があるか? そうだ、ただし異なる形で。

基礎知識は自動化された世界でも重要性は変わらない。適用の仕方が変わるのだ。BGP収束の挙動を理解しないエンジニアは、信頼性の高い閉ループBGP自動化を設計できない。スパニングツリーを理解しないエンジニアは、本番環境のトポロジー障害モードを忠実に再現するシミュレーション環境を構築できない。自動化レイヤーはネットワークの上に成り立っている。その正確さは、ネットワークがどう振る舞うかのモデルの品質に依存し、そのモデルは構築した人々が基盤となるプロトコルをどれだけ理解しているかによる。

変わるのは学習パスだ。従来の認定試験のルート（理論を学び、試験に合格し、本番で応用する）は間違いではないが、唯一の信頼できる道ではなくなった。課題優先のパスも少なくとも同等に効果的になった。実際の運用問題から始め、それを解く自動化を構築し、その問題が要求する特定のプロトコル挙動や設計原則を学ぶ。資格は既存の知識を検証するものだ。実践の後に取得する方が価値が高い。

CCIEは深さの強いシグナルであり続ける。自動化された世界では、自動化が依存する種類の深さを示すシグナルだ。ただし単独では運用の現在性は示さない。デバイスを手動で設定できる知識は必要条件だが、もはや十分条件ではない。

自動化特有の資格が従来のネットワーキングトラックと並んで生まれ、T字型の水平軸を検証している。バージョン管理の衛生管理、API設計、CI/CDパイプラインの基礎だ。これらはプロトコル深度の補完として有用であり、代替ではない。

13.3.3 AIがスキル要件に与える影響#

Artificial Intelligence (AI)コーディングアシスタントは、ネットワーク自動化におけるソフトウェア開発の入口を大きく変えた。Pythonクラスを暗記できないエンジニアでも、定型的な自動化タスクに対してプロンプトで動くコードを生成できるようになった。デバイス出力のパース、設定テンプレートの生成、基本的なインテグレーションスクリプトの作成などだ。これは始める際のハードルを下げる。正しく行うためのハードルを下げるわけではない。

AIアシスタントが代替できないもの。自動化を実行すべきでないときを判断する能力、予期せぬ形で現れる自動化障害を診断する能力、特定の自動化ワークフローを第4章から第12章にわたるプラットフォーム設計全体に結びつけるアーキテクチャの論理。AIアシスタントは書いたテストに合格するコードを生成する。書き忘れたテストは教えてくれない。

ここで重要なパターンが**監督される同僚 (Supervised Colleague)**だ。AI生成の自動化コードを、有能だが経験の浅いエンジニアのコードと同様に扱う。レビューし、テストし、デバッグできるくらい理解し、所有する。自動化が本番パイプラインに入った瞬間から、すべての行を入力したかどうかにかかわらず、それはあなたのものだ。

AIツールの状況は、いかなる書籍も追いつけないペースで進化している。ここで説明した具体的な能力は、読んでいる時点ではすでに古くなっているかもしれない。根本にあるパターン、AIが生成したコードは他の貢献と同じレビューと所有権移転が必要だということ、AI支援はエンジニアリングの判断を置き換えないということ、はどのツールが存在するかにかかわらず変わらない。

実際に必要なコーディング知識の量。他人が書いたコードを読んで理解できる、一般的な障害モードをデバッグできる、既存の自動化を新しい要件に合わせて修正できる、コードレビューで情報に基づいた判断ができる程度。コードの運用リテラシーであり、プロのソフトウェア開発者レベルではない。「CLIツールが使える」より高い基準だ。「分散システムをゼロから設計できる」より低い基準だ。

13.3.4 スキル開発のパス#

移行を行うチームで、2つの具体的な開発パスが現れる。

• プラットフォームや自動化の役割へ移行するネットワークエンジニアの場合: 実践的な開始順序は、書く前に読んでデバッグすることに焦点を当てたPythonの基礎、VCSのワークフローと衛生管理、障害を診断するのに十分なCI/CDパイプラインの理解、YAMLとJavaScript Object Notation (JSON)のスキーマ設計だ。新しいコードを生成する前に、既存のコードを読んでデバッグすることに重点を置くべきだ。最初の意味ある節目は「スクリプトを書いた」ではない。「他人の自動化障害をデバッグし、なぜそれが起きたかを理解した」だ。移行して6ヶ月後、ジョルディはまさにそれに直面した。自分が書いたわけではない本番ワークフローの40行にわたるPythonのトレースバックだ。最初の反応はチームのソフトウェアエンジニアに転送することだった。代わりに、ルーティングテーブルを読んでいたときのように、先頭から1行ずつ読み始めた。障害を引き起こしたネットワーク固有の前提は23行目にあった。BGPセッション状態に関するハードコードされた期待で、BGPを手動で設定したことがある人には完全に理にかなっていて、テストが必要なものとして誰の頭にも浮かばなかったものだ。彼は自分でそれを修正した。トレースバックはノイズではなくなっていた。それは地図になっていた。

• ネットワーク自動化に移行するソフトウェアエンジニアの場合: 実践的な開始順序は、IPの基礎、障害モードを論理的に考えるのに十分なだけ深く学んだ1つのルーティングプロトコル、ネットワークエンジニアが変更に慎重になる運用上の信頼モデル（ウェブアプリケーションのバグとは異なり、1つの誤ったコマンドで本番ネットワークを停止させる可能性がある）、そして本番インシデント中にネットワークエンジニアのそばでシャドウ経験を積むことだ。最初の意味ある節目は「ネットワーク理論を理解した」ではない。「ネットワークエンジニアが何を恐れていて、なぜそうなのかを知っている」だ。

flowchart LR
    classDef net fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef sw fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef shared fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b

    subgraph Network["ネットワークエンジニアリング"]
        N1["プロトコル専門知識 - デバイス挙動 - 障害診断"]
    end
    subgraph Overlap["共有ゾーン"]
        O1["自動化設計 - SoTスキーマ - シミュレーション精度 - 変更信頼モデル"]
    end
    subgraph Software["ソフトウェアエンジニアリング"]
        S1["コード構造 - テスト規律 - CI/CDパイプライン"]
    end

    Network --- Overlap --- Software

    class N1 net
    class O1 shared
    class S1 sw

**ローテーションモデル (Rotation Model)**はこのプロセスを加速するパターンだ。両グループをお互いのそばで実践しながら学ぶ状況に置く、構造化されたクロスチームローテーション。ネットワークエンジニアがソフトウェアチームに2週間組み込まれ、ソフトウェアエンジニアがネットワークチームのオンコールに2週間入る。形式的な意味でのクロストレーニングではなく、協働を持続可能にする共通の語彙と相互尊重を築くためだ。

移行して2年後、ジョルディはマネージャーが開発実験として提案した計画的なローテーションの一環として、3ヶ月間クラウドインフラチームに組み込まれた。懐疑的に受け入れた。クラウドチームはデバイスやプロトコルについて考えなかった。アプリケーションがネットワークに対して期待することを考えていた。その前提は書き留められておらず、しばしば間違っていた。戻ってきてからジョルディが構築した自動化は、チームがそれまでに作ったもので初めて、デバイスレイヤーから上ではなくアプリケーションレイヤーから下へとネットワークインテントをモデル化したものだった。それはまた、これまでにリリースした中で最も信頼性の高い自動化でもあった。ジョルディもマネージャーも、それを予期していなかった。ローテーションはジョルディをクラウドエンジニアリングでクロストレーニングしたのではなかった。すでに深く理解していたことに対して新しい視点を与え、そのフレームの転換こそがアーキテクチャ的思考の実際の姿だ。

戻ってから3ヶ月後、ジョルディはチームのために、アプリケーションチームがネットワークの前提をどのようにモデル化するかについて観察したことを共有する非公式セッションを開いた。6人のエンジニアが参加した。そのうち2人は、彼が共有したことに基づいて、次の自動化ワークフローの設計を変えた。ローテーションはジョルディを変えただけでなく、彼を通じて、他のエンジニアが問題をどう考えるかを変えた。一人の学びは、意図的に共有されると、倍増する。

エンジニアリングマネージャーとチームリードへ: このセクションで説明したスキル変革は、ドキュメントと善意だけでは起きない。時間の確保（学習は、フルの運用負荷の隙間だけでは起きられない）、心理的安全性（エンジニアはリスクの低い環境でミスを犯す必要があり、ラボへのアクセスと意図的な非本番実験時間が必要だ）、そして深いネットワーク知識が新しいモデルでも価値があり障害ではないという、リーダーシップからの目に見えるスポンサーシップが必要だ。

この変革に失敗するチームは、ほぼ例外なくツールやプランが不足しているチームではない。エンジニアが新しいスキルを習得することは「本当の仕事」を終えた後でやるべきことだと感じているチームだ。

13.3.5 実践的なツールキット#

以下のツールシーケンスは、移行を始めるネットワークエンジニアへの優先順位に従った順だ。各ステージの目標は、次へ進む前に習熟することではない。役立てるくらいの流暢さと、何かがおかしいときに気づける程度だ。

flowchart BT
    classDef foundation fill:#4a7fa5,stroke:#2d5f80,color:#fff
    classDef automation fill:#3a8a5a,stroke:#2d6b45,color:#fff
    classDef platform fill:#7a5a8a,stroke:#5d4570,color:#fff

    F["**基礎レイヤー** - Git · Python · YAML"]
    A["**自動化レイヤー** - Ansible · Jinja2 · Netmiko/NAPALM · Nornir"]
    P["**プラットフォームレイヤー** - SoT · テスト · Docker · Kubernetes · CI/CD"]

    F --> A --> P

    class F foundation
    class A automation
    class P platform

基礎レイヤー（ここから始める）:

• Git: 交渉の余地のない出発点。コミット、ブランチ、プルリクエスト、マージコンフリクトの解消。自動化プラットフォームのすべてはバージョン管理の衛生管理に依存する。自動化ツールよりも先に学ぶ。
• Python: 新しいコードを書く前に、既存のコードを読んでデバッグすることに集中する。最初の節目は、ゼロからクラスを書くことではなく、トレースバックを読んで何を伝えているか理解することだ。
• YAML: ほとんどのネットワーク自動化ツールの設定言語。Ansible、NetBox、ほとんどのCI/CDパイプラインを使うには、構造、インデント、データ型の理解が必要だ。

Pythonは今日のネットワーク自動化で支配的な言語だが、唯一の選択肢ではない。パフォーマンスが重要なツールやプラットフォームコンポーネントにはGoが増えており、スクリプティングの概念は言語をまたいで移転する。Pythonの基礎を学ぶ投資は、プログラミングリテラシーへの投資であり、Pythonへの忠誠ではない。どの言語をプラットフォームが使うかにかかわらず、メンタルモデルは引き継がれる。

自動化レイヤー:

• Ansible: ネットワーク環境で最も広く展開されている実行ツール。プレイブック、インベントリ、ロール、変数の優先順位。プロビジョニングと設定自動化のユースケースの大半をカバーする。
• Jinja2: Ansibleとほとんどの設定生成ワークフローで使われるテンプレートエンジン。テンプレートが変数データに対してどのようにレンダリングされるかを理解することは、スケールでの設定管理に不可欠だ。
• NetmikoまたはNAPALM: NetmikoはレガシーデバイスのSSH/CLI自動化を扱う。NAPALMは構造化APIをサポートするデバイスに対してマルチベンダーの抽象化レイヤーを提供する。既存のネットワーク自動化コードベースのほとんどで、どちらか一方または両方が登場する。
• Nornir: 大規模なデバイスインベントリ全体での接続管理、タスク実行、並列処理を担うPythonネイティブの自動化フレームワーク。AnsibleがPythonを抽象化するのに対し、NornirはPythonを露出させるため、完全なプログラム制御が求められる複雑なワークフローにより適している。

このリストは使うための推奨ではなく、学ぶための推奨だ。これらのツールの多くはスケールで顕在化する限界を持ち、よく設計されたプラットフォームはそれらをよりクリーンなインターフェースの後ろに抽象化する。それらの仕組み、障害モードとエッジケースを含めて理解することこそが、いつ使うか、いつ置き換えるか、本番で誤動作したときに何を注視するかについて情報に基づいた判断を可能にする。

プラットフォームレイヤー:

• Source of Truth: 最も一般的なSource of Truth実装。スキーマ設計、APIインタラクション、自動化がSoTに読み書きする方法を理解することで、実行ツールを第4章のアーキテクチャモデルに接続する。
• テスト: 自動化コードのテストを書くこと。最初の意味ある使い方は、新しいテストを書くことではなく、既存のテストが何をカバーしていて何を見逃しているかを理解することだ。
• Dockerの基礎: ローカル開発環境を実行し、コンテナイメージとは何かを理解し、Composeファイルを読める程度。コンテナオーケストレーションではなく、環境セットアップで詰まらないための最低限だ。
• Kubernetesの基礎: 自動化プラットフォームのコンポーネント（オーケストレーター、APIゲートウェイ、オブザーバビリティスタック）はますますKubernetes上のコンテナ化ワークロードとして動く。クラスターを運用する必要はないが、デプロイメントマニフェストを読み、Podの再起動を理解し、実行中のコンテナからログを調べる方法は、プラットフォームの問題をデバッグする際に定期的に必要になる。
• CI/CDパイプライン: パイプライン定義を読んで理解し、パイプラインの失敗を診断し、パイプラインのどこで失敗が起きたかを知る。パイプラインをゼロから書くのは後でいい。

ツールよりも順序が重要だ。Gitをよく知りPythonをデバッグできるエンジニアは、すべてのツールをインストールしたが何も深く理解していないエンジニアよりも、ネットワーク自動化チームで役に立つ。深さは使用から生まれ、インストールからではない。

AIコーディングアシスタントはこのツールキットを不要にしない。自分がプロンプトで生み出したコードを読めないエンジニアは、それが本番で失敗したときにデバッグできず、同僚がそれを提出したときにレビューできず、自動化が何をしたかを利害関係者に説明できない。上記の基礎こそが、AIアシスタントを不要にするのではなく、安全に使えるようにするものだ。

13.4 採用の促進#

チームに自動化を始めさせることは、チームが自動化を組織的な能力として構築・維持させることとは別の問題だ。両方に注意が必要で、必要とするものも異なる。このセクションは前者を扱う。チームを立ち上げ、ほとんどの自動化プログラムが自律的なスケールに達する前に停滞させる予測可能な障壁を乗り越えるにはどうすればいいか。

**採用はしご (Adoption Ladder)**パターンは3つのステージに名前をつける。パイロット、スケール、持続。各段には異なる成功基準がある。

1. パイロットは、自動化が少なくとも1つのユースケースで十分に信頼できるほど機能することを証明することだ。成功基準はカバレッジでもコード量でもない。信頼だ。チームは手動プロセスではなく実際にこの自動化を使っているか? 「ほとんどはそうだが、重要な変更には手動でも行う」という答えなら、パイロットは成功していない。

2. スケールは、より多くのユースケースとより多くのエンジニアへ自動化を広げることだ。成功基準はセルフサービスだ。自動化を構築しなかったエンジニアが、元の作者に聞かずにそれを使えるか? 構築者しか操作できないプラットフォームはスケールしていない。手動の依存がデバイスのCLIから自動化ツールに移っただけだ。

3. 持続は、元の作者がいなくなっても生き続ける自動化だ。成功基準はオンボーディングだ。新しいエンジニアが、元のチームの説明なしに既存の自動化を理解し、修正し、拡張できるか? 答えがノーなら、自動化はより良いツールを持つキーパーソン依存だ。

13.4.1 変化への抵抗パターン#

十分な一貫性で現れる3つの抵抗パターンに名前をつけることができる。

1. **凍り付いた専門家 (Frozen Expert)**パターン: 最も経験が豊富で、手動の作業方法に深く根差した専門知識を持つエンジニアが、自動化への最も声高な批評者になる。これは不合理ではない。彼らのステータス、キャリアの軌跡、プロフェッショナルとしてのアイデンティティは、他のどのジュニアエンジニアよりもその変化によって脅かされている。機能する対応は、そのエンジニアを自動化の観客ではなく著者にすることだ。最初の自動化ワークフローを設計した凍り付いた専門家はその成功に投資する。完成したプラットフォームを手渡されて使うよう言われた凍り付いた専門家は、その欠点を見つけることに意欲を持つ。

2. **見えないROI (Invisible ROI)**パターン: うまく機能する自動化はチケットも目に見える活動も生み出さない。失敗だけが見える。VLANプロビジョニングを自動化したチームは、自動化が価値を提供しているシグナルなしに何ヶ月も過ごすことができる。シグナルは提出されることのなかった何百ものチケットだからだ。これに対処するには意図的な計測が必要だ。前後のプロビジョニング時間の追跡、回避されたインシデントの数、Mean Time To Resolution (MTTR)の改善の測定、そしてそれらの数字を、通常は自動化が失敗したときしか見ない利害関係者に見えるようにすること。

3. **ブラックボックス (Black Box)**パターン: アクセスが制限されているためではなく、理解できないものを信頼しないために、構築したエンジニアしか使わない自動化。自動化は正しい結果を生み出すが、何をしているのか、なぜそうするのかについての洞察を提供しない。他のエンジニアは、手動プロセスの方が遅くても少なくとも読み取れるため、自動化を迂回する。対応は、自動化自体に透明性を組み込むことだ。監査ログ、ステップごとの実行トレース、明確なエラーメッセージ、そして何かが起きる前に何が起きるかを示すDry Runモード。信頼は理解に続く。自分のアクションを説明できない自動化システムは、作者を超えた採用を獲得しない。第2章 セクション2.1は、自動化への信頼を構築するための基礎を確立した。理解可能、予測可能、使いやすいという品質は、動くシステムの上に重ねる機能ではない。それがシステムを信頼に値するものにするものだ。

13.4.2 採用メトリクス#

採用はスクリプトの数やコード行数では測れない。次のメトリクスはチームが実際に自動化を受け入れているかどうかを追跡する。

• セルフサービス率: ネットワークチームの直接関与なしに実行された変更の割合。高いセルフサービス率は、アプリケーションチーム、セキュリティチーム、その他のコンシューマーがプラットフォームを独立して運用できることを意味する。
• 手動エスケープ率: エンジニアが自動化を迂回して直接デバイスにアクセスする頻度と理由。一部の迂回は正当だ（自動化がそのケースをまだカバーしていない）。他は信頼の欠如を示す。理由を追跡することは、数を追跡するのと同じくらい重要だ。
• 新しい自動化の本番投入時間: 「これは自動化すべき」から「これは本番で動いている」までの期間。長いサイクルタイムは、チームが新しいものを自動化する意欲を下げるプロセスの摩擦を示す。
• オンボーディング時間: 新しいチームメンバーが最初の意味ある自動化貢献をするまでの期間。ドキュメントの品質、コードベースの明確さ、環境セットアップの摩擦を同時に測定する。

13.5 プラットフォームの持続#

採用はしごの「持続」段に達することは問題の終わりではない。本番に到達して信頼を獲得した自動化も、チームが成長し、コードベースが老化し、構築したエンジニアが去るにつれて健全であり続けるには積極的な組織的サポートが必要だ。このセクションのプラクティスは、採用とは異なる課題を扱う。始め方ではなく、持続させ方だ。

13.5.1 DevOpsとアジャイルの継承#

この章で説明したパターンは、ネットワークエンジニアリングで生まれたものではない。前の10年間、ソフトウェアエンジニアリング組織で、最初はウェブ運用（DevOps運動）、次にプロダクト開発（アジャイル手法）で磨かれてきたものだ。

DevOpsは、速く出荷したい開発チームと安定性を守る必要のある運用チームの間の構造的な緊張を扱った。解決策は運用チームにより多くのリスクを受け入れさせることではなく、開発と運用のプラクティスを統合して、デプロイの信頼性を共有の責任にすることだった。同じ緊張がネットワーク自動化にも存在する。新しいワークフローを出荷したい自動化開発者と、本番の安定性を必要とするネットワーク運用エンジニアだ。DevOpsの継承は直接的に関連する。自動化パイプラインの共有所有権、本番前の自動テスト、障害を割り当てるのではなくシステムを改善するブレームレスな事後分析だ。

アジャイル手法は異なる問題を扱った。完全な事前仕様を必要とせずに、複雑なシステムで段階的な価値をどう提供するか。自動化における同等物は上記の採用はしごだ。完全なカバレッジを試みる前に動くパイロットを届け、段階的にカバレッジを拡大し、各段階を次が始まる前に機能させる。これは当然に見えるが、ネットワークプロジェクトの伝統的なスコープ設定、いかなるデプロイよりも前の完全な設計、いかなる本番使用よりも前の包括的なカバレッジ、とは相容れない。

ソフトウェアエンジニアリング文化からの借用は、そのボキャブラリーを採用することではない。同様の組織的課題を通じて得られた解決策を適用することだ。避けるべき失敗モードは意味論的採用だ。変更プロセスを「CI/CD」と名付け、四半期計画を「スプリント」と呼び、それらの運動が具体的に打破しようとしていたすべての行動習慣を保持したままDevOps組織を宣言するチーム。シグナルは、パイプラインが実行する各変更に4週間のCAB承認を必要とし続ける自動化パイプラインを持つチームだ。ボキャブラリーは変わった。文化は変わっていない。

13.5.2 新しい変更管理#

自動化は変更管理をなくさない。それを変換する。

従来のネットワーク変更管理は、予定されたウィンドウ、手動レビュー、明示的な承認チェーンを中心に構築されていた。すべての変更がミスを犯しうる人間による手動操作だったからだ。プロセスは、決定から実行へのパスを遅くし、人間がエラーをキャッチできるチェックポイントを追加するために存在していた。

自動化はリスクプロファイルを変える。変更が自動化されると、変更が実行されるときではなく、自動化が書かれたときにレビューされ、本番に到達する前にテストされ、自動的に監査証跡を生成する。定型プロビジョニング操作が昨年300回成功して障害なしに実行された場合、その操作の前に4週間の変更フリーズをかける論拠は弱くなる。

自動化対応の変更管理は獲得するものであり、宣言するものではない。ドライランと監督段階を完了させずに自律実行へ移行したチームはリスクを減らしていない。それを隠しただけだ。信頼性はしご (Confidence Ladder)は、ポリシーの決定やマネージャーの確信ではなく、実際の実行履歴に基づいて各段階を誠実に完了したときだけ機能する。

自動化対応変更管理への移行は段階的に獲得される。**信頼性はしご (Confidence Ladder)**パターンが進行に名前をつける。自動化は段階的に自律性を獲得する。新しい自動化は最初ドライランモードで動く。変更なしに実行プレビューを生成する。人間のレビューを伴う十分な成功したドライランの後、監督付き実行の権限を得る。変更は積極的な監視と介入できるエンジニアを伴って適用される。介入なしに十分な成功した監督付き実行の後、その種の変更について自律実行の権限を得る。例外ベースの人間による監視を伴う。

このプロセスは、優れたエンジニアがジュニアの同僚に適用する信頼モデルを反映している。自律性は証明された信頼性を通じて獲得され、事前に付与されて失敗後に取り消されるのではない。

13.5.3 学習とドキュメンテーションの文化#

ドキュメント化されていない自動化は、作者とともに消える。これは決まり文句ではない。重要な自動化ワークフローを構築したエンジニアがチームを離れるたびに現れるパターンだ。

自動化のドキュメンテーションの課題は、執筆の問題ではなくアーキテクチャの問題だ。後から別のアーティファクトとして書かれたドキュメントは、ほとんど常に不完全で、ほとんど常に古くなる。生き残るドキュメントは自動化に組み込まれたものだ。自己記述するスキーマ、何が起きているかを説明するドライラン出力、読むだけでほとんどの質問に答えられるほど明確に構造化されたコード、そして明らかでない選択（この設計が代替案より選ばれた理由、制約が決定をどう形作ったか）を記録するアーキテクチャ決定記録 (ADR)だ。コードが何をするかを説明するためではなく。

これをサポートするチームの実践は、チケットを閉じる前に完了させるタスクではなく、自動化レビューの品質基準としてドキュメンテーションを組み込むことだ。明確なドライランモード、読み取り可能な監査出力、ドキュメント化された障害挙動がない自動化ワークフローは不完全だ。ドキュメントが欠けているからではなく、それらの能力こそが自動化を信頼に値するものにするからだ。

移行して1年後、ジョルディはネットワークの経歴を持たないジュニアエンジニアとペアを組んだ。彼女は、自動化が単に削除コマンドを発行するのではなく、ピアを削除する前にアクティブなBGPセッションを確認する理由を尋ねた。ジョルディはそのチェックを10分で書いて、ドキュメント化していなかった。理由を説明した。まだルートを広告しているピアを削除すると、完全なルーティングプロトコルの収束時間、多くの場合キャンパスネットワークで30秒以上、かかるトラフィックのブラックホールが発生し、プロビジョニングワークフローには許容できない中断だ。説明しながら、チェックにまだコード化していない2番目の意味があることに気づいた。両方を書き留めた。3週間後、ジュニアエンジニアは2番目の意味のロジックエラーを発見した。教えるという行為が、元の推論よりも自動化を良くした。それを予期していなかった。その後も毎回そうなった。

13.5.4 知識の蓄積とオープンソース#

組織の記憶の問題は時間とともに複合する。3年の自動化の歴史と大きな入れ替わりを持つ組織は、現在のチームメンバーが完全に理解していないコードに組み込まれた、ドキュメント化されていない決定の大きな塊を持つ。

このリスクを下げるプラクティスはツールのプラクティスではなく、プロセスのプラクティスだ。コードレビューを必須の知識移転として行う。コードがなぜこう書かれたかを理解しないレビュアーはそれを承認する資格がない。自動化タスクのペア作業で、知識移転を提供と同等の主要な目標にする。明らかでない設計の選択に対するアーキテクチャ決定記録を、プラットフォームの現在の形の背後にある推論を蓄積する生きたドキュメントとして維持する。

AI支援開発のペースは、この問題の特定の変形を導入する。エンジニアがAIツールを使って自動化コードを素早く生成すると、結果は挙動としては本番グレードだが、理解においては孤立している可能性がある。チームの誰もコードがなぜそのように構造化されているか、どのエッジケースが考慮されたか、どの前提が組み込まれているかを完全に知らない。コードは動き続け、動かなくなるまではそうだ。失敗したとき、デバッグの連鎖はゼロから始まる。セクション13.3.3の監督される同僚パターンが緩和策だ。AIが生成したコードは、生成プロセスが明示しなかったことをドキュメント化するという追加の規律を伴って、他のどの貢献者からのコードと同じレビューと所有権移転を必要とする。

オープンソースのネットワーク自動化ツールは異なる種類の知識蓄積に貢献する。1つの組織ではなく多くの組織にわたって開発された共通の語彙と共通の障害モード。オープンソースツールを基盤にするチームは、コミュニティのデバッグ、設計、運用経験を継承する。コミュニティがすでにドキュメント化した障害モードに遭遇したとき、彼らはそれを認識する。小さな修正やドキュメントの改善であっても、貢献することで、チームはその知識ベースに効果的に関与する能力を構築する。これは組織的な能力であり、技術的な選択だけではない。

13.5.5 倫理的・人間的な意味#

完全な自動化は、業界がまだ完全に解決していない方法で説明責任をシフトする。

人間のエンジニアが障害を引き起こす変更を実行した場合、説明責任は明確だ。人が判断を下した。自動化システムが障害を引き起こす変更を実行した場合、説明責任の連鎖はより長く追跡が難しい。自動化を書いたエンジニア、それを承認したエンジニア、トリガーを設定したエンジニア、自律実行ポリシーを承認したマネージャー。これに対する法的・組織的フレームワークはまだ発展中だ。

AIの次元はこの問いを深くする。AI駆動のオーケストレーションシステムが自律的にルーティングの決定を下すとき（第17章で説明したように）、人間のインテントとネットワークのアクションの間の連鎖には、決定論的なコードのように完全に監査できない推論レイヤーが含まれる。AIシステムは、それを展開したエンジニアが予期しなかった理由で正しいアクションに到達することがある。同じ理由で誤ったアクションに到達することもある。自動化が間違ったとき、「誰が責任を負うのか?」という問いは真剣に難しくなる。

これは自律運用を避けるべきだという意味ではない。自律的なアクションの範囲、人間へのエスカレーションをトリガーする条件、事後レビューを可能にする監査証跡を、自動化ロジック自体と同じ厳格さで設計しなければならないということだ。自動化の成熟度にかかわらず2つの原則が適用される。自律的なアクションは境界を持つべきだ（自動化は何をする権限がないかを知り、停止する）、そしてシステムは常に何をしたか、なぜそうしたか、何を別にしただろうかを説明できるべきだ。

13.6 クロスドメインの協働#

ネットワークチームはファイアウォールルールプロビジョニングの信頼できる自動化を構築するために6ヶ月を費やした。セキュリティチームもセキュリティグループポリシー適用のために同じことをした。両方のプラットフォームは機能した。両方はパイロットを通過した。両方は本番稼働していた。

そしてネットワークチームは新しいIoTデバイスのセットを分離するためにキャンパスゾーンを再分割した。変更は自動化され、レビューされ、ネットワークのSource of Truthに対して正しく実行された。40分後、セキュリティチームのポリシーエンジンが違反を生成し始めた。新しいセグメントはセキュリティのSource of Truthに存在しなかったため、そこからのトラフィックは承認されたポリシーに一致せず、黙って落とされた。どちらの自動化にもバグはなかった。ネットワーク自動化は意図したネットワーク変更を実行した。セキュリティ自動化は意図したセキュリティポリシーを実施した。障害は両者の間に共有モデルが存在しないことだった。停止は4時間続き、両チームのエンジニアが2つの自動化システムが一緒に知っておくべきだったことを手動で再構築する間だった。

この章で説明した文化的変革は、単一のチーム内では起きない。意味のある組織的価値を提供するネットワーク自動化は、常に他のドメインに触れる。セキュリティポリシーの適用、クラウドインフラ管理、サービス提供ワークフロー。それらの境界における組織的摩擦こそが、成熟した自動化プログラムのほとんどが停滞するところだ。

問題は構造的だ。NetOps、SecOps、CloudOpsは通常、異なるSource of Truthスキーマ、異なる変更管理の儀式、重複しているが統合されていない異なるツールチェーンで別々の自動化能力を進化させてきた。自分のドメイン内で正しく機能する各システムは、他が何を変更したかについて認識がない。上記の話の障害は例外ではない。クロスドメイン自動化が意図的に設計されていないときのデフォルトの結果だ。

13.6.1 ガバナンスと権限付与のバランス#

すべてのクロスドメイン自動化プログラムは同じ緊張に直面する。プラットフォームチームは標準化したい。標準化こそが共有ツールを可能にするものだからだ。そしてドメインチームは自律性を求める。彼らの要件が標準にきれいに収まらないからだ。

実践で機能する解決策は**整備された道 (Paved Road)**パターンだ。プラットフォームエンジニアリングコミュニティ（特にNetflixと同様の大規模運用組織）で発展した。プラットフォームチームは回避するより使う方が簡単な、よく整備された道を構築する。代替を禁止しない。採用を強制しない。良い道を簡単な道にし、正当な理由でオフロードするチームがいることを受け入れる。

一貫して生じる関連する所有権の問いがある。物理的・プロトコル的アーティファクトとしてのネットワークと、自動化ターゲットとしてのネットワークの境界を誰が所有するか? ネットワークエンジニアはネットワーク設計、プロトコル挙動、インテントモデルの正確さを所有する。ネットワーク自動化エンジニアはそのインテントを実装するプラットフォームを所有する。実際にはこれらの所有権の境界は常に曖昧で、最も効果的なチームはきれいな区分ではなく、明確なエスカレーションパスを持つ共有責任として扱う。

クロスドメイン自動化プログラムは、ドメインチームの上に単一の責任あるオーナーがいないときに一貫して停滞する。ディレクターまたはVPレベルの共有責任点なしに、ガバナンスと権限付与のバランスは、競合する優先事項を持つ対等者間の交渉として残り、明確な裁定者のある管理された緊張ではなくなる。プラットフォームチームは、解決する権限のないクロスドメインコンフリクトを解決できない。説明責任の構造はアーキテクチャが機能する前に存在しなければならない。

13.6.2 共有プラットフォーム対フェデレーテッド自動化#

クロスドメイン協働の根底にあるアーキテクチャの問いは、自動化が共有プラットフォームに収束すべきか、ドメインツール全体にフェデレーションされたままであるべきかだ。

スケールするパターンはどちらでもない。共有データレイヤー、フェデレーテッド実行。クロスドメインインテント（ネットワークトポロジー、セキュリティポリシー、クラウドリソース割り当て）を一貫したスキーマとアクセスモデルで保持する単一のSource of Truth。共有データレイヤーから読み取り、結果を書き戻すドメイン固有の実行ツール（ネットワーク自動化プラットフォーム、セキュリティポリシーエンジン、クラウドプロビジョニングシステム）。

このアーキテクチャによって、ドメインツールはクロスドメインワークフローが必要とする共有コンテキストを維持しながら独立して進化できる。代替、すべてのドメインのための単一の統合自動化プラットフォーム、は異なる要件、異なる変更速度、プラットフォームロードマップをどのチームの優先事項が動かすかという組織的な政治の重みの下で一貫して失敗する。

このアーキテクチャの選択は第11章のスケーリングパターンに直結する。共有データレイヤーを持つフェデレーテッド実行モデルは特定の一貫性要件を持つ。データレイヤーはセキュリティポリシーの変更とそのネットワーク適用が調整できるほど一貫していて、ネットワーク変更がクラウドインフラの同期を待ってブロックしないほど疎結合でなければならない。

13.6.3 組み込みの協働#

ドメインチーム間の委員会ベースの調整は良いクロスドメイン自動化を生み出さない。会議を生み出す。動く自動化を生み出すパターンは**組み込みの協働 (Embedded Collaboration)**だ。定期的なレビューセッションではなく、特定の自動化問題について異なるドメインのエンジニアが互いにそばで働くことだ。

実践的なモデルはクロスファンクショナルスクワッドだ。1人のネットワークエンジニア、1人のセキュリティエンジニア、1人のクラウドエンジニアが、定められた期間、特定のクロスドメイン自動化能力を一緒に構築するために割り当てられる。スクワッドは提供と継続的な運用の両方を所有する。ローテーションにより、各ドメインの実践者がハンドオフや翻訳レイヤーを通じてではなく、他者の制約についての実用的な知識を身につける。

クロスファンクショナルスクワッドは、メンバーがスクワッドのミッションに真に専念しているときだけ機能する。各メンバーがまだ自分のドメインチームの完全な仕事量を抱えているスクワッドはスクワッドではない。別の名前を持つ委員会だ。効果的なクロスドメイン自動化には、スクワッドメンバーの時間を保護するためのマネジメントのコミットメントが必要だ。その保護なしに、スクワッドは最も抵抗の少ない道にデフォルトし、それは各自が既存のドメイン役割に合う仕事をすることで、クロスドメインの統合は決して構築されない。

クロスドメインSLOはこの協働を形式化する。自動化ワークフローがドメインの境界をまたぐとき、エンドツーエンドのワークフローの信頼性の期待は単一のドメインチームが所有できない。共有SLOを定義するには、両チームが互いの障害モードを理解し、結果の共有所有権を交渉する必要がある。ネットワーク変更で始まりセキュリティポリシー違反として現れた自動化障害を誰が所有するか? 答えは「インシデントチケットシステムが最初にルーティングしたどちらか」ではあり得ない。

flowchart TD
    classDef shared fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef domain fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    SoT["Source of Truth - クロスドメインインテント"]

    subgraph Domains["ドメイン実行レイヤー"]
        direction LR
        NP["ネットワークプラットフォーム"]
        SP["セキュリティポリシーエンジン"]
        CP["クラウドプロビジョニング"]
    end

    Obs["オブザーバビリティ - クロスドメインテレメトリ"]

    SoT --> NP & SP & CP
    NP & SP & CP --> Obs
    Obs -.->|"フィードバック"| SoT

    class SoT,Obs shared
    class NP,SP,CP domain

13.7. まとめ#

第13章は、ネットワーク自動化で最も難しい問題のいくつかは技術的なものではないという議論を展開した。それらは組織的なものだ。誰が仕事をするか、どうやってそれをする方法を学ぶか、組織が最初の採用の波を越えてそれを持続させる方法、そして歴史的に別々のサイロで運用してきたチームがどうやって共有システムを構築するか。

3つのテーマが章を貫いている。

• 役割は進化するが、消えない。 ネットワーク運用からプラットフォームエンジニアリングへの移行は変換マップであり、交換チャートではない。深いプロトコル知識は自動化された世界で価値が下がらない。異なる形で適用される。設定を実行することから、設定を正しく実行するシステムを設計することへ。セクション13.2で説明した5つの新たな役割は、T字型スキル開発パスが向かう先だ。

• 採用には積極的な設計が必要だ。 採用はしご（パイロット、スケール、持続）は、異なる成功基準を持つ3つのステージに名前をつける。最初の段を越えるにはカバレッジではなく信頼が必要だ。2番目を越えるにはセルフサービスが必要だ。3番目を越えるには、作者がいなくなっても生き続ける自動化が必要だ。抵抗パターン（凍り付いた専門家、見えないROI、ブラックボックス）は既知の対応を持つ予測可能な障壁だ（セクション13.4.1）。その採用を持続させるには、異なる習慣の集まりが必要だ。DevOpsとアジャイルの継承、自動化のリスクプロファイルに合わせた変更管理モデル、自動化自体に組み込まれたドキュメンテーション、チームの入れ替わりを超えて生き残る知識蓄積（セクション13.5.1から13.5.4）。

• クロスドメインの協働はアーキテクチャ的であり、組織的ではない。 三国問題（NetOps、SecOps、CloudOpsが別々のサイロで運用している）は善意やガバナンスの義務によって解決しない。共有データアーキテクチャによって解決する。一貫したスキーマを持つ単一のSource of Truth、それから読み取るフェデレーテッド実行ツール、そしてドメイン間の継ぎ目を所有する組み込みのクロスファンクショナルスクワッド。整備された道パターンは、すべてのチームが単一のプラットフォームに収束することを要求せずにこれを機能させるガバナンスモデルだ。

第14章は組織的な次元を別の方向に延ばす。自動化を単なるエンジニアリング能力としてではなく、独自のライフサイクル、ステークホルダーモデル、ビジネスインパクト測定のアプローチを持つプロダクトとして扱うことを。

参考文献・さらに読むために#

• The Phoenix Project, Gene Kim, Kevin Behr, George Spafford (IT Revolution Press, 2013). プレッシャーをかけられたIT組織でのDevOps変革の小説形式のアカウント。組織のダイナミクス、開発速度と運用安定性の間のコンフリクト、共有所有権の出現は、この章で説明した自動化プログラムのダイナミクスに直接対応する。

• The DevOps Handbook, Gene Kim, Patrick Debois, John Willis, Jez Humble (IT Revolution Press, 2016). The Phoenix Projectの実践的な補完。3つの方法（フロー、フィードバック、継続的学習）、デプロイメントパイプライン、ブレームレスな事後分析。この章のDevOps継承に関するセクションはこれらの基礎から引いている。

• Team Topologies, Matthew Skelton, Manuel Pais (IT Revolution Press, 2019). 高速なソフトウェア提供のためのチーム構造設計のための決定的なフレームワーク。ストリームアラインドチーム、プラットフォームチーム、イネーブリングチームの概念は、セクション13.6で議論されたクロスドメイン協働と組み込みスクワッドモデルに直接変換される。

• Accelerate, Nicole Forsgren, Jez Humble, Gene Kim (IT Revolution Press, 2018). ソフトウェア提供パフォーマンスを予測する組織的・技術的プラクティスの研究に基づいた分析。4つの主要メトリクス（デプロイ頻度、リードタイム、変更失敗率、復元時間）はセクション13.4.2の採用メトリクスの定量的基盤を提供する。

• Change by Design, Tim Brown (HarperCollins, 2009). T字型エンジニアモデルとそれを支えるデザイン思考アプローチを紹介している。深いドメイン専門知識と学際的なリテラシーを組み合わせたIDEOのフレームはセクション13.3のスキル変革パスの基盤だ。

💬 Found something to improve? Send feedback for this chapter