第4部：人と組織の次元 on Designing Network Automation at Scale

13 - 文化的変革

Sun, 19 Apr 2026 00:00:00 +0000

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習熟がどれだけ積み上がっても生み出せない、より強力な立場だ。

ネットワーク自動化はプロビジョニングを加速するだけではない。それを構築したエンジニアの知識を記録する。10分で書いたBGPセッションチェックには15年の運用経験が込められている。そのチェックは、作者がオンコール中であれ、休暇中であれ、すでに退職していても正しく動作する。自動化はエンジニアを引き留めない。エンジニアが知っていることを引き留める。この違いは、シニアエンジニアがチームを離れるたびに、どれほどの組織の知恵が失われたかを考えるときに重要になる。

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

14 - プロダクトとしての自動化

Tue, 05 May 2026 00:00:00 +0000

14. プロダクトとしての自動化#

チームの仕事に対する考え方を変えることになったその会話の6ヶ月前、ネットワークプラットフォームチームは本当に印象的な成果を上げていた。2年間の継続的な努力により、ブランチのオンボーディングをエンドツーエンドで処理するプロビジョニングプラットフォームが完成していた。サイトリクエスト用のセルフサービスインターフェース、デプロイ前に設定ミスを検出するクローズドループ検証ワークフロー、そして300拠点全体のサービス健全性を追跡する運用ダッシュボードが揃っていた。チームは24時間の変更ウィンドウから40分の自動デプロイへと進化させた。彼らはそれを誇りに思っていたし、誇りに思うべきだった。

そこへ事業開発チームが小売チェーンの買収を完了させた。120の新規店舗が6ヶ月以内にネットワーク接続を必要としていた。インフラ担当リードがシンプルなメールを送ってきた。「この件は自動化プラットフォームを頼りにしている。どうすれば開始できるか？」

ネットワークプラットフォームチームの最初の内部反応は自信に満ちていた。これは自動化できる。ワークフローがある。テンプレートがある。ツールは実績がある。

しかし、メールに返信しようとしたときの2回目の反応は自信を欠いていた。インフラ担当リードは自動化が技術的に可能かどうかを聞いているのではなかった。彼らは別の質問をしていた。店舗オンボーディングのSLAとは何か、つまりサイト情報が提出されてから店舗が接続を受けるまでのコミットメントは何か？デプロイが途中で失敗した場合のエスカレーションパスは誰か？インフラ担当リードのチームが、ネットワークチームに直接尋ねることなく監視できるステータスページやダッシュボードはあるか？プラットフォームのキャパシティはどうか、20件の同時デプロイを処理できるか、それともリクエストをバッチ処理する必要があるか？そして最も不快な質問：プラットフォームインシデント中にオンボードされた店舗はどうなるか、自動的に修復されるか、それとも誰かが各店舗を監査する必要があるか？

ネットワークチームには自動化があった。しかし答え（ビジネス/プロダクトの観点での）がなかった。

このギャップ、つまり「動く自動化を構築した」と「他のチームが依存して計画を立てられるサービスを提供する」との間の差が、本章のテーマである。

これは私が情熱を持っているトピックだ。Autocon3で行ったセッションでは、設計主導の自動化の観点からこれを扱っており、本章の補足参考資料となっている。

14.1 ケイパビリティからプロダクトへ#

第13章では、チームが自動化を組織的ケイパビリティとして構築するために、人材、役割、仕事の進め方をどのように変革するかを説明した。その変革は必要だ。しかしそれだけでは不十分だ。

ケイパビリティとはチームができることだ。プロダクトとは、他のチーム（またはいずれはサードパーティのエンティティ）が依存できるものだ。その違いは技術的な品質についてではない。小売チェーンオンボーディングプラットフォームは技術的に優秀だった。違いは、プロバイダーとコンシューマーの関係にある。ケイパビリティはその作者のために存在する。プロダクトはそのユーザーのために存在する。

ネットワークチームのアウトプットは変化した。自動化以前のアウトプットはデバイス設定だった。プロビジョニングされたルーター、拡張されたVLAN、適用されたACL。そのアウトプットのコンシューマーはデバイス自身であり、成功の証拠はpingが通ることや、アプリケーションが動作することだった。自動化によってアウトプットは変わる。ネットワークチームのプロダクトは、他のチームが消費するネットワークサービスになる。ネットワークとのすべてのインタラクション、ブランチサイトのプロビジョニング、新しいアプリケーション向けのセグメント拡張、セキュリティポリシーの適用、VLANへの会議用アクセスの一時付与、インターネットエクスチェンジでのピアリング接続の追加、これらはすべて変更チケットではなくサービスリクエストになる。デバイス設定は実装の詳細だ。サービスがアーティファクトだ。

これが**ネットワークサービスをプロダクトとして (Network Service as Product)**パターンだ。サービスがプライマリのアーティファクトであり、下層のネットワークは実装だ。これはソフトウェアエンジニアリングでは新しくない。APIはインフラを抽象化し、呼び出し元はどのサーバーがリクエストを処理するかを知らないし、気にしない。しかし、これは歴史的にデバイス、ベンダー、プロトコルを中心に仕事を整理してきたネットワークチームにとっては大きな転換だ。ルーター設定スキルにアイデンティティを定義してきたエンジニアが、今やサービスデリバリーケイパビリティにアイデンティティを定義するよう求められている。このリフレームは第13章セクション13.1の職人のジレンマに直結する。古いクラフトの専門家こそが、最も急いでリフレームを行う必要がある人物であり、それを完全に実行するエンジニアはより価値が下がるのではなく、より価値が上がる。

このプロダクトの技術的な拠点は、第8章で説明したプレゼンテーションブロックだ。セルフサービスインターフェース、APIサーフェス、Webhook統合、ロールベースのアクセスモデル、これらはサービス契約がコンシューマーに見える場所だ。第14章では、技術的なインターフェースを超えて、それを取り巻く組織的・ビジネスモデルにズームアウトする。インターフェースにはどんなコミットメントが伴うか？壊れたときは誰が所有するか？サービスはどのように進化するか？次に何をするかは誰が決めるか？

14.2 プロダクトの定義#

ネットワーク自動化をサービスに変えようとするチームに一貫して現れる2つの失敗モードがある。

1つ目は過剰露出だ。インターフェースが実装の詳細を露出させ、コンシューマーがそれを使うためにネットワークの内部を理解しなければならない。VLAN ID、サブネットマスク、OSPFエリア番号を要求するブランチプロビジョニングサービスはサービスではない。ウェブフォームを持つCLIだ。小売チェーンの設備コーディネーターは、OSPFエリアが何であるかを知らないし、知る必要もない。

2つ目は過剰制限だ。インターフェースがネットワークチームが想定した正確なユースケースしか処理できないほど制約されている。テンプレートから逸脱したリクエストには例外プロセスが必要だ。恒久的な小売拠点とは異なる接続要件を持つ期間限定のポップアップストアをプロビジョニングする必要がある設備コーディネーターは、セルフサービスできない。チケットを提出する。チケットはネットワークチームに届く。自動化のメリットがそのコンシューマーに届いていない。

**サービス契約パターン (Service Contract Pattern)**は、インターフェース定義を明示的、バージョン管理済み、意図的に境界設定することで、両方の失敗モードを解決する。サービス契約には3つのコンポーネントがある。

インプットサーフェス: コンシューマーが提供するもの。ネットワーク用語ではなくビジネス用語で表現される（申し訳ないが、これは重要なことだ）。ブランチサイトリクエストは、ロケーション名、物理的な住所、サイト階層（標準、スモール、ポップアップ）、および有効化日を受け取る。VLAN IDは受け取らない。この契約はビジネスの意図をネットワークの実装に内部で変換し、その変換が自動化プラットフォームの責任だ。階層の定義は永続的ではない。一時的な小売キオスク向けに定義されたポップアップ階層は、異なる接続要件を持つポップアップイベントスペースには対応しない。インプットサーフェスは、コンシューマーチームと同じケイデンスでロードマップとともにレビューされなければならない。そうすることで、階層が最初に契約が書かれたときにネットワークチームが想定したユースケースではなく、実際のユースケースを反映するようになる。
アウトプットサーフェス: コンシューマーが観察するもの。成功した完了と失敗の両方を含む。適切に設計されたアウトプットサーフェスは「ステップ14のうち7番目でデプロイ失敗：gNMIプッシュがエラーコード400で拒否されました」を露出させない。「有効化失敗：このアドレスの物理回線がまだキャリアによってプロビジョニングされていません。予想完了日：[SoTからの日付]。あなた側のアクションは不要です。回線がオンラインになったときにシステムが自動的に再試行します」を露出させる。自動化は単に成功や失敗するだけでなく、コンシューマーが理解できる用語でオブザーバブルなライフサイクルイベントを発行する。
内部依存関係: サービスが内部で追跡するもの。コンシューマーには見せないが、チームは管理しなければならない。キャリアからの回線状態。このサービスとインフラを共有している隣接サービス。新しいサイトのSoTレコードと自動監視を駆動するインベントリレコードとの整合関係。回線がキャリアメンテナンスに入ったとき、ネットワークチームはどのサービスが影響を受けるか、それがどんなSLO露出を生み出すかを知る必要がある。コンシューマーはサービスへの影響を知る必要があるかもしれないが、それを引き起こした実装の詳細を知る必要はない。

flowchart LR
 classDef consumer fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
 classDef contract fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
 classDef internal fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

 subgraph Consumer["コンシューマーインターフェース"]
 IN["インプットサーフェス<br/>ロケーション、階層、日付<br/>ビジネスの意図"]
 OUT["アウトプットサーフェス<br/>ステータス、ライフサイクルイベント<br/>ビジネス言語"]
 end

 subgraph Contract["サービス契約"]
 TRANS["変換レイヤー<br/>意図から実装へ<br/>VLAN、サブネット、OSPFエリア"]
 end

 subgraph Internal["内部依存関係"]
 CIRC["回線状態"]
 SOT["SoT整合性"]
 NEIGHBOR["隣接サービス"]
 end

 IN --> TRANS
 TRANS --> OUT
 TRANS --> CIRC & SOT & NEIGHBOR
 CIRC & SOT & NEIGHBOR -.-> OUT

 class IN,OUT consumer
 class TRANS contract
 class CIRC,SOT,NEIGHBOR internal

サービス契約が定義されたら、次の問いはそれが時間とともにどうなるかだ。