💡

ゼロトラスト導入後に運用が立ち上がらない理由と“運用PMO”という処方箋

に公開
DevOps
Zero Trust
運用設計
pmo
itsm
idea

はじめに

ゼロトラスト導入プロジェクトというと、どうしても「技術導入」「移行設計」が花形になります。
ZTNA、IdP連携、MDM/EDRの実装、SD-WANの構築といった技術要素に注目が集まり、PMOの役割も移行計画やマイルストーン管理が中心です。

しかし、導入プロジェクトが解散したあと、定常運用フェーズで現場が混乱するケースが少なくありません。
本記事では、その背景と対策を「運用PMO」という観点から整理します。

導入プロジェクトの落とし穴（Before）

移行PMOばかりに光が当たる

  • PMOといえば移行スケジュールや移行計画が中心で、予算も人材もそこに集中する。
  • 運用設計や運用移行期は「プロジェクトが暫定的に面倒を見る」という形でお茶を濁されがち。

暫定期は勝手に終息しない

  • 「半年くらいすれば落ち着くはず」と考えられがちだが、実際は移行プロジェクトで積み残した課題がそのまま残る。
  • 例外処理やトラブル対応の経緯がブラックボックス化し、定常運用側は初動でつまずく。

移行と運用での温度差

  • 過去のトラブル事例
  • 拠点固有のシステムや制約（平日通信停止不可、繁忙期は完全NGなど）
  • ユーザー特性（在宅勤務率が高い、BYODが多い）

これらは移行プロジェクト側には共有感があるが、定常運用側には十分に伝わっていない。
しかも、定常運用チームには引継ぎ作業を並行してやる余裕がないため「知識の断絶」が起こる。

運用PMOという処方箋（After）

運用PMOの役割

  1. 知識移転の担保
    • 過去のトラブルや例外対応を棚卸し、FAQやRunbookに落とし込む
  2. 教育の定着
    • ヘルプデスク教育（例：SD-WANログ読み取り、問い合わせフローチャート）を必須マイルストーンに
  3. 例外処理ガバナンス
    • 例外ポリシーを期限付きで管理し、場当たり対応を防ぐ
  4. 問い合わせ設計
    • 問い合わせフォームやヒアリングシートを共通化し、一次切り分けの精度を上げる
  5. DevOpsループの推進
    • インシデント → ログ解析 → 改善 → FAQ反映のサイクルを回す

第三者目線かつ当事者目線

  • 第三者目線：移行プロジェクトの知識移転が十分かを監視
  • 当事者目線：運用側の余力や制約を理解し、現実的に回せる形に翻訳

最小実装（Small Start）

運用PMOをフル機能で立ち上げる必要はありません。
まずは「導入直後に必ず発生する問い合わせ」を題材に最小実装しましょう。

  • シナリオ例：ZTNA接続切れ時の問い合わせ対応
    1. 問い合わせフォームに必須項目を設定（端末種別、発生時刻、接続先など）
    2. ヒアリングシートを統一し、ヘルプデスクが一次切り分け可能にする
    3. ITSMツールでサブチケットを自動起票 → 設計／ネットワークチームと並行で対応
    4. 月次レビューで改善点を抽出し、フォームやフローチャートを更新

これだけでも「導入したはいいが、誰も動けない」状態は回避できる。

まとめ

  • 技術導入や移行設計は花形だが、導入後の混乱を防ぐには「運用PMO」が不可欠。
  • 暫定期のあいまいさや知識の断絶を放置すれば、ゼロトラストは“不便な仕組み”で終わってしまう。
  • リリースの本当のゴールは「定常運用が自走できる状態」。
  • そのために、運用PMOをプロジェクトの必須要素として設計に組み込むべきだ。

Discussion