はじめに

こんにちは、MSPセクションの小野瀬です。

本連載では、私が取り組んだ「AIを活用した問題管理プロセスの構築」について、全2回にわたってお話しします。
第1回となる今回は、私たちが直面していた課題と、なぜ今「仕組み」を変える必要があったのか、その背景をお伝えします。

実は私自身、これまで問題管理の経験があったわけではありません。むしろ、アラート対応では多くの失敗をしてきました。

  • 慣れた作業ゆえの油断から、手順書の細かな更新点を見落としてしまった。
  • 複数の対応が重なった際、確認プロセスが疎かになってしまった。
  • 「相手も分かっているはず」という思い込みから、チーム間の連携で認識齟齬を生んでしまった。

こうした自身の弱点や失敗経験を通じて、私はひとつの事実を突きつけられました。
「個人のスキルアップはもちろん重要です。しかし、人間の認知能力にはどうしても限界があり、人だけに頼る運用には無理がある」

この実感が、今回のプロジェクトの原動力になっています。

「解熱剤」を飲み続けていませんか？

まず、少しだけ視点を変えてみましょう。IT運用の世界には「インシデント管理」と「問題管理」という言葉がありますが、これを医療に例えると分かりやすくなります。

  • インシデント管理（対症療法）:
    • 熱が出たから、とりあえず解熱剤を飲む。
    • 目的：症状（サービス停止）を抑え、日常に戻ること。
    • アクション：手順のやり直し、バックアップからの復旧、顧客へのお詫び。
  • 問題管理（根本治療）:
    • なぜ熱が出たのか精密検査し、病巣を取り除く、あるいは生活習慣を改善する。
    • 目的：病気（トラブル）にならない体を作ること。
    • アクション：根本原因の特定、恒久対策、プロセスの改修。

多くのシステム運用の現場では、どうしても「対症療法」のプロフェッショナルになりがちです。お客様のサービスを止めてはいけない、止まったら一秒でも早く戻さなければならない。

しかし、解熱剤で熱を下げても、病気が治ったわけではありません。薬が切れればまた熱が出ます。
「対症療法」だけで満足してしまうと、現場は永遠に薬を飲み続け、次第に疲弊していきます。

なぜ、忙しいのに「問題管理」をやるのか？

「根本治療が大事なのはわかる。でも、そんな時間はない」
現場のメンバーなら、誰もがそう思うはずです。

しかし、「忙しいからこそ、問題管理をやるべき」だと思っています。

組織にとっては「サービス品質の向上」や「属人化の解消（誰でも対応できる体制）」といった経営的なメリットがありますが、実は現場のメンバーにとってこそ、最大のメリットがあります。

少し想像してみてください。
毎回、複雑なコマンドを手入力し、「絶対に間違えられない」という緊張感の中でEnterキーを押す作業（個人の注意深さに依存した運用）と、検証済みのスクリプトをワンクリックで実行するだけの作業（仕組み化された運用）。

前者は常に事故のリスクと隣り合わせですが、後者は誰がやっても安全かつ確実に遂行できます。
「仕組み」を変えるということは、日々の業務からこの「無用なプレッシャー」を取り除くことと同義です。

その結果、現場には以下のような変化が訪れます。

  • 「心理的負担」からの解放:
    「ミスをするかも」という不安を仕組みでカバーし、現場の安心感を担保します。
  • 「本来の業務」への集中:
    トラブル対応という「負の資産」を減らし、サービス改善などの「正の価値」に時間を使えるようになります。

問題管理は、会社のためだけでなく、あなた自身が「本来やるべきこと」に向き合うための手段なのです。

「原因」には3つの顔がある

では、どうすれば「根本治療」ができるのでしょうか？
ここで重要になるのが、「原因」をどこまで深く掘り下げるかという視点です。

トラブルの再発を防ぐためには、原因を以下の3つの階層で捉えることが重要です。
ここでは、運用現場でよくある「手順書の記載ミスによる作業トラブル」を例に、3つの階層で深掘りしてみましょう。

1. 直接原因（Direct Cause）

  • 「何が起きたか？（事象の直接的な引き金）」
  • 例：手順書に記載されたパラメータが古く、設定変更作業に失敗した。
  • ここへの対策：手順書のパラメータを正しい値に修正し、再作業を行う。
  • 結果： 今回の作業は完了できますが、「なぜ古かったのか？」は解決されていないため、また別の箇所で同じミスが起きます。

2. 根本原因（Root Cause）

  • 「なぜそれが起きたか？（発生のメカニズム）」
  • 例：先月の構成変更時に、手順書の更新作業が漏れていた。
  • ここへの対策：担当者に注意喚起し、手順書更新ルールの再周知を行う。
  • 結果： 一時的に意識は高まりますが、「人の注意力」に依存しているため、担当者が変わったり繁忙期になれば再発します。

3. 流出原因（Outflow Cause）

  • 「なぜその原因を作り出し、見逃してしまったのか？（プロセスの欠陥）」
  • 例：構成変更の承認フローの中に「手順書の修正確認」という工程が存在しなかった。あるいは、更新漏れを検知する仕組み（チェックリスト等）がなかった。
  • ここへの対策：変更管理チケットの完了条件に「手順書更新」を必須化する。あるいはパラメータを自動取得する仕組みに変える。
  • 結果： 「人が忘れてもプロセスが止めてくれる」状態になり、類似の更新漏れが組織全体でなくなります。

多くの現場では、「何が起きたか（直接原因）」や「なぜ起きたか（根本原因）」まではたどり着けます。
しかし、本当に大切なのは、もう一歩踏み込んで「なぜ、そのミスを防げなかったのか（プロセスの弱点）」を掘り下げることです。

この原因を突き止める作業は、「自分たちの今のルールに、どんな穴があったのか」を冷静に見つめ直す作業でもあります。
しかし、個人の頑張りに頼るのをやめ、仕組みでカバーできる範囲を広げていくこと。それこそが、現場のエンジニアをミスから守る盾になります。

私たちは機械ではありません。疲労もすれば、記憶も曖昧になりますし、間違いもします。
必要なのは「次は気をつけます」という精神論に頼る運用ではなく、「誰がやっても間違えようがない、あるいは間違えても大事に至らない仕組み」への転換です。

しかし、深い分析は難しい…

しかし、現実には大きな壁が立ちはだかります。
「全員が同じレベルで、深く分析することは難しい」という壁です。

「なぜ？」を繰り返して根本にたどり着くには、高度なスキルと根気、そして何より「いつもの業務の当たり前を疑う」という多角的な視点が必要です。

しかし、日々の業務に追われる中で、ゼロベースでプロセスを見直すことは容易ではありません。
「分析の質を上げたい。でも、時間もないし、どうしても思考の死角ができてしまう」

この「人間ゆえの限界」を突破するために選んだパートナーが、生成AI（Gemini） でした。

次回予告

私たちは、AIを単なる「文章作成ツール」としてではなく、思考を深めるための「壁打ち相手」としてプロセスに組み込みました。

次回、【後編】AI×問題管理：AIは「答え」ではなく「気づき」をくれる。Geminiと実践する原因分析 では、実際に私たちが構築したAI活用のフローと、AIがどのようにエンジニアの思考を「流出原因」へとガイドしていくのか、その具体的な中身をご紹介します。

「AIに任せたら、勝手に報告書ができるんでしょ？」
そう思った方こそ、ぜひ次回をご覧ください。私たちが作ったAIは、答えを教えるのではなく、「気づき」を与えるコーチのような存在です。

お楽しみに！