LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

障害が起きるたびに、同じ担当者に電話がかかってくる。手順書はあるのに、どこから調べればよいかが書かれていない——。社内システムの運用保守の現場では、こうした状態が続きがちです。運用保守の障害対応手順整備とは、障害が起きたときの連絡の流れ、原因を切り分ける順番、復旧の作業、復旧後の記録を文書にまとめ、当番が誰であっても同じ手順で動けるようにすることを指します。

手順の中身には、システムを作った側の知識が要ります。そこで、開発に携わってきた専門人材に開発要員として一定の期間チームに加わってもらい、手順書を書き起こす方法があります。ただし万能ではなく、障害のときに何を優先するか、利用者にいつ知らせるかといった判断までは任せられません。本記事では、運用保守を担う開発の現場のマネージャーに向けて、手順書に書く4つの項目、開発要員に任せる範囲と社内に残す判断、進め方、そして専門人材に加わってもらうときに確認したい点を整理します。

運用保守の障害対応手順整備とは

障害のときにする作業は、ふだんの運用の作業とは分けて整理されています。デジタル庁の「デジタル・ガバメント推進標準ガイドライン解説書」（DS-110）は、運用業務の作業の例を表にまとめ、その中に「障害発生時対応」の区分を設けています。^*1 並んでいるのは、インシデント（システムが正常に動かない状態）の受付と記録、障害による影響を最小限にとどめて復旧する作業、修正プログラムの本番環境への適用、バックアップからの復旧などです。

インシデント管理の作業は「ヘルプデスク、監視業務、業務側からのインシデントの受付、記録、問題管理、変更管理への切り分け」から始まると書かれています。^*1 受け付けて記録し、どこで直すかを切り分けるところまでが、障害対応の最初の仕事です。

こうした作業を文書にしたものを、同じ解説書は「障害対策マニュアル」と呼び、運用や保守の作業手順書の例に挙げています。中身は「インシデント発生時の対応体制、連絡手段、報告要領及び具体的な作業手順」とされています。^*1 政府の情報システム向けの資料ですが、社内システムの手順書を整えるときの項目の見本としてもそのまま使えます。

なぜ開発要員に加わってもらうのか

手順書のうち連絡体制は社内の担当者だけで書けますが、切り分けの順番と復旧の作業は、システムの中身を知らないと書けません。どの画面の不具合なら、どのサーバーのどのログを見るのか。連携先のシステムが止まったときに、こちらの処理はどう振る舞うのか。こうした知識は、設計や実装に関わった人の頭の中にあることが多いものです。

IPAの「非機能要求グレード2018」は、運用・保守性の項目の一つとして、保守の対応者に求めるスキルの水準を段階で示しています。中ほどの段は「システムの構成を把握し、ログの収集・確認が実施できる」、いちばん上の段は「システムの開発や構築に携わり、業務要件やユーザの事情にも通じている」です。^*2 切り分けの順番を書き起こすのに向いているのは、いちばん上の段に近い人です。

復旧の作業をどこまで自動にするかも、同じ資料の項目にあります。障害復旧の自動化の範囲は、全て手動、一部を自動化、全てを自動化の3段階です。自動化には「障害のパターン毎に複雑な判断を行うスクリプトを作成する必要があり開発コストが増大する」一方で、復旧が速くなりミスも減るため運用のコストは下がると説明されています。^*2 スクリプトを書く作業は、まさに開発要員の仕事です。

DS-110も、設計・開発の段階で、開発を担う事業者とともに「定常時及び障害発生時において想定される運用体制、実施手順等を取りまとめる」ことを求めています。^*1 本来は作る段階でそろえておく手順を、稼働した後からでも作った側の知識を借りて埋める、というのがこの記事で扱う形です。

運用の責任は社内に残す

ここでいう開発要員の参画は、運用そのものを丸ごと委託することとは違います。障害の電話を受け、止めるかどうかを決め、利用者に知らせるのは、これまでどおり社内の運用担当です。開発要員が受け持つのは、その判断の材料になる手順を書き起こす作業です。

経済産業省の「システム管理基準」は、運用体制の整備の管理活動として、運用管理者の役割と責任を明確にすること、運用管理に必要な情報を文書化して周知すること、運用担当者に必要な力量を明確にすることを挙げています。^*3 手順書は、この「文書化」に当たります。書く作業に社外の人が加わっても、役割と責任を持つのは社内の運用管理者です。

役割の分け方を決めるときは、非機能要求グレードの項目が確認の手がかりになります。障害の一次対応の役割分担は「全てユーザが実施」「一部ユーザが実施」と、全部を社外が担う段の3つに分かれています。インシデント管理の実施の有無も「インシデント管理について規定しない」「既存のインシデント管理のプロセスに従う」「新規にインシデント管理のプロセスを規定する」の3段です。^*2 開発要員に加わってもらう前に、一次対応は社内で受けること、既存の流れに合わせるのか新しく決めるのかを、社内で決めておきます。

DS-110は、障害が起きたときには手順に基づいて「運用事業者、保守事業者等の作業分担を明らかにし、対応を行う」としたうえで、必要に応じて外部組織の有識者や専門的な知見を持つ職員などの支援や助言を受けることにも触れています。^*1 専門人材の知見を借りながら、分担と判断は社内で持つという形は、この考え方に沿っています。

手順書に書く4つの項目

障害対応手順整備で書く項目は、連絡体制、切り分けの順番、復旧の作業、復旧後の記録の4つに分けると、開発要員と社内のどちらが書くかを決めやすくなります。

一つ目の連絡体制には、障害を受け付ける窓口、当番の決め方、連絡する順番と手段、報告する相手を書きます。開発要員に頼むのは、技術面で問い合わせる先と、そのときに渡すログや画面の記録の形です。連絡の順番と利用者への知らせ方は社内で決めます。

二つ目の切り分けの順番は、症状ごとに、どこから調べて何を確かめれば原因の場所を絞り込めるかを並べたものです。構成図、ログが出る場所、状態を確かめる手順を開発要員が書き、業務への影響がどのくらい大きいかの見極め方は社内の運用担当が書き足します。

三つ目の復旧の作業には、再起動、直前の版への切り戻し、バックアップからの復旧などの手順と、作業の後に確かめる項目を書きます。作業を実行してよい人と、システムを止めるかどうかの承認者は社内で決めて、手順の中に名前を入れておきます。

四つ目は復旧後の記録です。非機能要求グレードは、問題管理を「インシデントの根本原因を追究し、可能であれば取り除くための処置を講じるプロセス」と説明しています。^*2 発生、検知、復旧の時刻と、原因、取った処置、再発を防ぐための候補を書く型を決めておけば、記録がそのまま問題管理の入口になります。原因の技術的な書き方の型は開発要員に作ってもらい、再発防止に取り組むかどうかは社内で判断します。

どう進めるのか

進め方は、次の5つの段階に分けると、開発要員の参画の期間と作業の範囲を区切りやすくなります。

1. いまある手順書と、過去の障害の記録を集める
2. 記録から、よく起きる症状と対応に時間がかかった症状を選ぶ
3. 開発要員が、選んだ症状ごとに切り分けの順番と復旧の作業を下書きする
4. 社内の運用担当と読み合わせ、判断の箇所に社内の担当者を書き入れる
5. 訓練で手順どおりに動けるかを確かめ、更新の担当を社内に決める

最初から全部の症状を書こうとすると、参画の期間が延びるうえに、使われない手順が増えます。過去の障害の記録から、頻度の高いものと復旧に時間がかかったものを先に選ぶと、限られた期間でも効果の大きい手順から整えられます。

読み合わせでは、開発要員が書いた手順を、社内の運用担当が自分で読んで動けるかを確かめます。作った人にしか分からない略し方や前提が残っていれば、その場で書き直してもらいます。

最後の訓練も、非機能要求グレードに項目があります。オペレーション訓練の範囲は、通常運用の訓練、保守運用の訓練を加えた段、さらに「障害発生時の復旧作業に関する訓練を実施」する段に分かれています。^*2 システム管理基準も、事業継続管理の項目の中で、訓練を定期的に実施して復旧手続を最新の状態に維持することを達成目標に挙げています。^*3 手順書は書いて終わりではなく、訓練で使ってみて直す前提で進めます。開発要員が抜けた後も訓練を回せるように、訓練の進め方も手順書と一緒に残してもらいます。

専門人材に加わってもらうときに確認しておきたい点

一つ目は、対象のシステムで使っている言語、データベース、クラウドなどを扱った経験です。切り分けの順番は技術ごとに見る場所が違うため、同じ種類の技術で障害に対応した経験がある人のほうが、手順を具体的に書けます。

二つ目は、本番環境で触ってよい範囲です。手順書を書くためにログや設定を見る必要はあっても、変更の権限までは要らないことがほとんどです。参画の最初に、見てよい環境と記録、使ってよいアカウントを決めておきます。

三つ目は、成果物の形と承認者です。手順書をどこに置き、どの形式で書くか、誰が読んで承認するかを先に決めておけば、参画の終わりがはっきりします。承認者は社内の運用担当から選びます。

四つ目は、参画が終わった後の更新です。システムを改修すれば手順も変わります。更新する担当は社内に置き、開発要員には、どの改修でどの手順を見直すかの目安まで書き残してもらうと、引き継ぎが楽になります。

起きてしまった不具合の原因調査を頼みたいときは「外部エンジニアに不具合の原因調査を頼む手順」を、運用保守の人を社内で抱えるか外部から迎えるかを考えるときは「運用保守の開発要員の社内・外部分担」を参考にしてください。

まとめ：障害対応の手順書で確かめておきたい3つの点

運用保守の障害対応手順を開発要員と整えるうえで、確かめておきたい点は3つに整理できます。第一に、手順書を連絡体制、切り分けの順番、復旧の作業、復旧後の記録の4つに分け、どれを誰が書くかを決めること。第二に、一次対応を社内で受けること、止めるかどうかの承認者、手順書の承認者を、開発要員に加わってもらう前に社内で決めておくこと。第三に、訓練で手順を使ってみて直し、参画が終わった後の更新の担当を社内に置くことです。この3点を踏まえておけば、「手順書はそろったのに、書いた人が抜けたら誰も直せない」という事態を避けやすくなります。手順を書ける人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：2026年6月12日版。第7章4.5)「運用・保守の設計」と解説(16)、第9章1.の表9-1「運用業務の対象作業例」（障害発生時対応）と3)運用実施要領の作業手順書の例、第9章2.の解説(5)(6)、保守の実施を参照（2026年9月確認）
2. *2　参考：IPA「非機能要求グレード2018 改訂情報 ～初版との差異～」（PDF・2018年4月25日）（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000066170.pdf）。出典：独立行政法人情報処理推進機構。付録の「非機能要求グレード2018 活用シート」から、運用・保守性のC.3.2.1 障害復旧自動化の範囲、C.5.5.1 一次対応役割分担、C.5.6.3 対応者の要求スキルレベル、C.5.8.2 オペレーション訓練範囲、C.6.3.1 インシデント管理、C.6.4.1 問題管理を参照（2026年9月確認）
3. *3　参考：経済産業省「システム管理基準」（令和5年4月26日）（PDF）（https://www.meti.go.jp/policy/netsecurity/sys-kansa/sys-kanri-2023.pdf）。出典：経済産業省「システム管理基準」。Ⅱ.5.1 運用体制の整備（管理活動の例3〜5）と、Ⅱ.9.4 訓練、演習及びテストの実施（達成目標2）を参照（2026年9月確認）

Tweet