システム運用保守ドキュメントの整備手順｜優先順位と更新が止まらない仕組み

運用保守のドキュメントは、作る順番を決めないまま始めると途中で止まります。何を書くかの一覧は出回っていますが、限られた工数でどれから手を付け、誰が更新し、どこまでを保守委託の成果物として契約に書くかは、発注者側が決めるしかありません。この記事では、障害対応フローを起点にした着手順序、運用設計書と運用手順書の書き分け、更新が止まる原因とトリガーの置き方、委託先の切り替え時に受け取る文書の範囲を整理します。JIS Q 20000-1:2020の文書化要求とIPAの非機能要求グレード2018を一次情報とし、整備を見送ってよい条件も示します。

まとめ：先に整える四点と更新が止まらない体制の要点

最初に作るのは障害対応フロー、連絡先一覧、システム構成図、運用設計書の四点です。運用手順書はこの後でよく、先に作ると更新が追いつかず全体が信用を失います。理由は損失の非対称性にあります。手順書が古くても作業が一件遅れるだけですが、夜間障害で連絡先と判断権限が辿れなければ、復旧そのものが数時間止まる。

更新を続ける仕掛けは一つです。変更管理の申請と障害報告のクローズ条件に「該当ドキュメントの更新」を組み込み、担当者名を文書ごとに一人ずつ置く。「みんなで更新する」という取り決めは、実務では誰も更新しないという意味です。外注を含む体制なら、契約書に納品文書の名称と更新契機、更新作業費が月額に含まれるかを明記してください。ここが空白のまま始まった現場は、切り替え時に手ぶらで引き継ぐことになります。

システム運用保守ドキュメントの全体像と発注者が押さえる文書の範囲

「運用保守ドキュメント」という言葉は、設計の記録と現場の作業指示と実績の記録をまとめて指します。この三つは更新頻度も責任者も違うため、同じ棚に置くと管理が破綻します。

運用保守ドキュメントが指す文書の分類と社内の管理台帳との違い

実務では三層に分けます。設計層は運用設計書・システム構成図・設定値一覧で、決めた内容が変わらない限り書き換えません。作業層は運用手順書・障害対応フロー・連絡先一覧で、担当者や手順が変われば都度直す。記録層は作業記録・変更履歴・障害報告書で、追記しかしません。

混同されやすいのが資産台帳やアカウント一覧といった管理台帳です。台帳は現物と一致していることに価値があり、乖離した瞬間に無価値になる。ドキュメントは判断の経緯を残すもので、多少古くても読む価値が残ります。同じ更新ルールを当てれば、台帳の精度が落ちるか文書の更新工数が膨らむかのどちらか。運用と保守の線引きから整理したい場合は、システム保守と運用の違い・費用相場・契約形態を先に確認すると、文書の割り当て先が決めやすくなります。

JIS Q 20000-1:2020が挙げる文書と現場に要る文書の差

ITサービスマネジメントの国内規格であるJIS Q 20000-1:2020（ISO/IEC 20000-1:2018に対応、2020年3月改正）は、箇条7.5.4でサービスマネジメントシステムの文書化した情報を列挙しています。主なものは次の通りです。

• サービスマネジメントの方針及び目的、サービスマネジメントの計画
• 変更管理方針、情報セキュリティ方針、及びサービス継続計画
• サービスカタログ、サービスの要求事項、サービスレベル合意書（SLA）
• 外部供給者との契約書、内部供給者との合意書
• 規格が要求する手順、及び適合の証拠を示す記録

規格側が求めるのは「合意の記録」が中心です。何を提供し、誰がどこまで責任を持つかを文書に固定させる思想で、夜間の障害をどう切り分けるかという作業層には踏み込みません。規格の目次を写経しても現場の止血にならないのはこのためです。一方、SLAと外部供給者との契約書を文書化した情報として名指ししている点は、後述する保守委託の設計にそのまま使えます。

非機能要求グレード2018の運用・保守性から逆算する必須文書

IPAが公開している非機能要求グレード2018は、非機能要求を6つの大項目（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー）に分け、階層構造で要求水準を決める枠組みです。利用ガイドは2019年3月28日に改訂され、2026年8月時点でもIPAのアーカイブから参照できます。

要件定義で運用・保守性の水準を合意したなら、稼働後にその内容が残る場所は運用設計書しかありません。稼働時間、監視対象と通知先、バックアップの取得間隔と保管期間、保守作業を実施できる時間帯。これらが文書化されていない現場では、障害時に「何分以内に復旧する約束だったか」から議論が始まります。要件定義の成果物を運用設計書へ引き継ぐ工程は、開発の最終フェーズに必ず置いてください。

運用設計書と運用手順書の役割分担と障害対応フローに書く粒度の基準

判断と操作は変わる速度が違うため、一冊にまとめた現場では更新が止まります。

運用設計書に書く合意事項と運用手順書へ落とす作業の単位と粒度

振り分けの基準は「変更するときに承認が要るか」です。承認が要るものは運用設計書へ、要らないものは運用手順書へ。責任分界点、稼働時間、監視対象と閾値、エスカレーションの条件、定期保守の実施タイミングは前者に入ります。月次バッチの再実行、証明書の更新、ログの退避といった操作は後者です。

運用手順書は「1文書＝1作業」で切る。複数作業を1冊に束ねると、片方の手順が変わっただけで全体をレビューする羽目になります。粒度の目安は、その作業を初めて担当する人が上から順に読んで完了できるかどうか。判断が必要な分岐が出てきたら、条件は運用設計書側を参照させ、手順書には「設計書のどの条件に該当するか」だけを書きます。

障害対応フローに必要な連絡経路・判断権限・エスカレーション基準

障害対応フローは、書式より順序と権限が命です。次の六段階を1枚に収めます。

1. 検知（監視アラート、利用者からの申告、その両方の受付窓口）
2. 一次切り分け（影響範囲と再現性の確認、切り分けの制限時間）
3. 影響判定（業務停止か、性能劣化か、単発事象か）
4. 連絡（誰に何分以内に、どの手段で。夜間と休日の連絡先を分けて記載）
5. 復旧作業の可否判断（サービス停止を伴う操作を誰が承認するか）
6. 事後報告（報告書の提出期限と提出先）

抜けやすいのは4と5です。夜間にサービス停止を伴う再起動を打てる権限が誰にあるかを決めていない現場では、担当者が承認者に電話し続けている間に復旧目標時間を超えます。権限は役職ではなく時間帯で委譲を書いてください。「22時以降は当番が単独で判断し、翌朝報告」と書いてあれば、当番は迷いません。復旧目標時間（RTO）と一次連絡までの目標時間は、分単位の数値で記載します。

システム構成図と設定値一覧を一次情報として保つための更新単位

構成図は論理構成と物理構成を分けて2枚にします。依存関係を示す論理図は障害時の影響範囲の判断に、インスタンスやネットワークを示す物理図は復旧作業に使うもので、参照する場面も更新の契機も違う。1枚に詰め込んだ図はどちらの用途にも中途半端で、結局は更新されません。

設定値一覧では二重管理を避けます。IaCのコードや設定ファイルが一次情報として存在するなら、ドキュメント側は「どのリポジトリのどのファイルを見るか」の索引に徹してください。値そのものを転記した瞬間から乖離が始まり、半年後には文書と実機のどちらが正しいか誰も判断できなくなります。転記が要るのは、コード管理されていない機器設定や、外部サービスの管理画面でしか変更できない項目だけです。運用業務全体の切り出し方から見直す場合は、システム運用の業務一覧と委託判断の考え方も合わせて確認してください。

ゼロから全部は作らない整備の優先順位と着手順序を決める判断基準

整備の相談で最も多い失敗が、文書一覧を作って上から順に着手することです。一覧は網羅性で並んでおり、損失の大きさでは並んでいません。着手順序は損失の大きさと作成コストの比で決めます。

障害対応フローから先に着手する理由と一週間で形にする最小構成

障害対応フローを最初に置く理由は二つ。放置したときの損失が最大で、作成コストが最小だからです。手順書を作るには実機を触って手順を再現する必要がありますが、障害対応フローは既に行われている連絡と判断を書き起こすだけで済み、A4で2枚に収まります。

一週間で形にする最小構成は、連絡先一覧、一次切り分けの確認項目、エスカレーション基準、停止操作の承認者の四つ。網羅は狙わず、直近1年の障害履歴に出てきた事象だけをカバーすれば十分です。履歴がなければ、担当者への30分の聞き取りを2回行えば骨格は埋まります。着手初日に決めるのは、更新責任者を誰にするかの1点です。

システムの規模と担当者数で整備順を変える判断軸と着手時の目安

担当者が2名以下の体制では、運用手順書の整備を後回しにしてください。この規模で標準化の投資に見合う効果は出ず、更新工数だけが残ります。優先するのは引き継ぎメモとシステム構成図。当番制で夜間対応を回している5名以上の体制なら、手順書の標準化が作業品質の差を直接縮めます。

外部の保守ベンダーと社内が分担している体制では、規模にかかわらず運用設計書が最優先です。責任分界点の記述がないまま障害が起きると、切り分けの前に責任の押し付け合いが始まる。着手の目安は開発の受入テスト期間中で、稼働後に始めると日々の運用に追われて半年は動きません。

文書別に見る作成コストと更新頻度、放置した場合に生じる損失の比較

着手順序を決める材料として、主要文書を三つの軸で並べます。作成コストが低く損失が大きいものから着手する、という単純な原則で判断できます。

運用手順書が最下段にあることに違和感を持つ担当者は多いはずです。ただし手順書は作成コストが最も高く、更新契機が最も頻繁で、放置による損失は人手で補える。補えない障害初動の文書を先に固める、という順序に合理性があります。

ドキュメントの更新が止まる原因と更新トリガーを組み込む設計手順

整備の失敗は作成段階ではなく更新段階で起きます。作った直後は誰もが正しいと信じ、半年後には誰も信じていない。この落差を埋める設計を、作成と同時に入れておきます。

ドキュメントの更新が止まる三つの原因と放置が続く組織的な構造

原因は三つに集約されます。第一に、更新の契機が日常業務に埋め込まれていないこと。第二に、更新責任が「運用チーム全員」のように主語のない形で置かれていること。第三に、保存場所が共有フォルダとチャットと個人PCに分散していること。

放置が続くのは、間違った文書があっても書いた本人が痛まないからです。困るのは半年後に異動してきた別の担当者で、そのころ元の書き手はもう別の案件にいる。この時間差が是正を働かせません。情報共有基盤そのものが形骸化している場合の立て直し手順は、社内wikiが失敗する原因と運用設計の立て直し基準で整理しています。ドキュメントだけを直しても、置き場所が死んでいれば読まれません。

変更管理の申請と紐づけて更新を必ず発生させるトリガーの置き方

更新を人の善意に任せない方法は一つ、他の業務の完了条件に組み込むことです。変更申請のクローズ条件に「影響を受けるドキュメントの更新完了」を入れ、障害報告書のクローズ条件に「手順書への反映有無の記載」を入れる。JIS Q 20000-1:2020が変更管理方針を文書化した情報として挙げているのは、変更の管理と文書の管理が同じ運用に乗るという前提があるからです。

組み込むトリガーは四つ。構成変更、担当者の交代、契約の更新、年次棚卸しです。担当者交代は見落とされがちですが、暗黙知が最も失われる瞬間でもあります。交代時のチェックリストに「担当していた文書の一覧と最終更新日を引き継ぐ」を入れておけば、少なくとも何が古いかは可視化されます。

年一回のレビュー周期と棚卸しで陳腐化した記述を削る運用ルール

棚卸しは削る会にしてください。参照されていない文書を残すと、検索時に古い記述が先に見つかり、正しい文書の信頼まで下げます。直近1年で参照も更新もされていない文書はアーカイブへ移す。消すのが怖ければ、閲覧はできるが検索結果には出ない領域で十分です。

各文書の先頭には、最終更新日、更新者名、次回レビュー予定日の3行を置きます。読み手は記述を信じてよいか自分で判断でき、レビュー漏れも一覧で拾える。変更頻度の高いシステムでは、四半期ごとに対象を構成図と設定値一覧に絞って回すやり方が現実的です。

保守委託の契約と引き継ぎで納品成果物として定義する文書の範囲

外部に運用保守を委託している場合、ドキュメントは技術の話ではなく契約の話になります。契約に書いていない文書は、善意で作られることはあっても、更新され続けることはありません。

保守契約書に明記する納品文書の一覧と更新責任の所在を決める観点

契約書に書くのは文書名だけでは足りません。名称、更新の契機、更新作業が月額の保守費に含まれるか個別見積りか、保管場所と発注者側のアクセス権限。この四点をセットで定義します。三点目が空白だと、構成変更のたびに図面更新の見積りが飛んでくるか、黙って更新されないかのどちらかです。

JIS Q 20000-1:2020が外部供給者との契約書を文書化した情報に含めている意味はここにあります。契約が文書管理の起点になる、という構造です。委託先の選定段階から文書の扱いを比較条件に入れるなら、システム運用保守の会社選びと相見積りを揃える手順で提案依頼書に書く項目を確認してください。見積り比較の土俵を揃える段階で定義しておけば、後から追加費用になりません。

委託先の切り替え時に受け取る文書の範囲と受領時に見る確認項目

切り替え時に受け取った文書をそのまま倉庫にしまう発注者は珍しくありません。受領時に見るべき項目は五つあります。

• 各文書の最終更新日（1年以上前のものは現物との一致を疑う）
• 構成図と本番環境の一致（サンプルで3か所を実機照合する）
• 設定値の一次情報の所在（コード管理か、機器上のみか）
• アカウントと権限の一覧（退職者・旧ベンダーの権限が残っていないか）
• 文書化されていない暗黙作業の一覧（月次の手作業、口頭連絡の慣習）

五つ目が最も価値があり、最も出てきません。引き継ぎの打ち合わせで「手順書に書いていないが毎月やっている作業はありますか」と一度聞いてください。移行期間中の運用責任も、切り替え日ではなく期間で契約に書いておきます。

内製と外注で分ける文書作成の範囲と外部の支援を頼む判断の目安

内製すべきなのは業務判断が絡む部分です。障害の影響度をどう判定するか、どの操作に誰の承認が必要か。自社の業務都合そのものであり、外部が代筆しても実態と合いません。一方、構成図の書き起こし、設定値の棚卸し、手順書の書式統一は、外部の手を入れたほうが速く仕上がります。

外部に頼む判断の目安は二つ。運用担当者が1名で他業務と兼務している場合と、現行ベンダーとの契約終了まで3か月を切っている場合です。どちらも社内工数だけでは間に合わず、そのまま切り替え日が来ると暗黙知ごと失われます。書き起こしから更新体制の設計、内製への引き戻しまで段階的に進めるなら、保守運用・内製化支援で現行体制の棚卸しから相談できます。

整備しないと決めてよい文書の条件と過剰な文書化を避ける線引き

網羅を目標に置いた整備は途中で力尽きます。作らないと決めるのも設計です。

整備を見送ってよい文書の三条件と作っても読まれない典型パターン

次の三条件をすべて満たす作業の手順書は作らないでください。作業頻度が年1回未満であること、操作が画面の表示に沿って進められること、失敗しても復旧が容易であること。この場合は手順書の代わりに実施記録だけを残し、次回はその記録を読んで進めます。記録は実施のたびに増えるため、更新が止まりません。

読まれない典型は三つ。1操作ごとに画面キャプチャを貼った手順書、全システム共通の運用ガイドライン、目次だけが立派な運用設計書です。二つ目には立場を明確にしておきます。全社共通の運用ガイドラインを最初に作るのは見送ってください。個別システムの障害対応フローが揃った後に共通項を抽出する順序でなければ、中身が一般論で埋まります。

手順書を細かく書きすぎた現場で起きる更新の破綻と是正する順序

細かすぎる手順書の末路は決まっています。画面が一度変わると全ページが実態と合わなくなり、量が多いため誰も直さず、すべての手順書が信用されなくなる。一部が古いのではなく全体が疑わしいという状態になるのが厄介なところです。

是正は次の順序で進めます。

1. 直近1年で実際に参照された手順書を、閲覧履歴か担当者への聞き取りで特定する
2. それ以外を凍結し、アーカイブ領域へ移して検索対象から外す
3. 残した手順書を、操作の羅列から判断の分岐を中心とした記述へ書き直す
4. 画面キャプチャは、迷いやすい1画面だけに絞って残す

ここでも見送る判断を添えます。半年以内に更改や移行が決まっているシステムに手順書を作り込むのは見送ってください。投じた工数は移行と同時に失われる。残すべきは現行システムの設定値と外部連携の一覧だけで、これは移行先の設計に使えます。属人化そのものの解消を段階的に進める手順は、ヘルプデスク効率化における可視化と属人化解消の着手順序の考え方がそのまま応用できます。

操作動画やスクリーンショットに頼る文書で膨らむ更新コストの実態

操作動画は作成が速く、更新が遅い形式です。文章なら1行の差し替えで済む変更が、動画では撮り直しと編集を伴う。使ってよいのは二つの条件がそろったときだけです。手順が半年以上変わらない見込みであること、操作を言葉で書きにくいこと。機器の物理的な接続作業や現地での目視確認は後者に当たります。画面操作は文字と分岐で書けるため、動画にする必要がありません。

よくある質問

整備の相談で発注者や情シス担当者から実際に寄せられる質問をまとめました。

運用保守ドキュメントは誰が作るべきですか？

文書の層で分けます。運用設計書は責任分界や稼働時間の合意を含むため、発注者側の担当者が主体となって作り、ベンダーがレビューする形が適しています。運用手順書とシステム構成図は、実機を触る側、つまり保守を担当するベンダーか社内の運用担当が書くほうが正確です。障害対応フローは連絡と承認の相手が両側にまたがるため、両者の合同で作成してください。作成者と更新責任者は別でも構いませんが、更新責任者は一人の氏名で決めます。

運用設計書と運用手順書は分けるべきですか？

分けてください。判断基準は「変更するときに承認が要るか」です。承認が必要な合意事項は運用設計書に、承認なしで現場が変えられる操作は運用手順書に置きます。一冊にまとめると、手順の軽微な変更でも設計書全体のレビューが発生し、その煩雑さから更新が止まる。分けたうえで手順書側から設計書の該当条件を参照させると、二重記載を避けられます。

ドキュメントはWordとwikiのどちらで管理すべきですか？

更新頻度で選びます。年1回程度しか変わらない運用設計書や契約に紐づく文書は、版管理と押印の運用が要るため文書ファイルのままで問題ありません。手順書や連絡先一覧のように頻繁に変わるものは、検索と履歴が残る社内wikiやドキュメント共有サービスが向いています。誤りやすいのは全部を一方に寄せること。保存場所が2種類に分かれるなら、索引を1ページ作り、そこを全員の入口にします。

運用保守ドキュメントの整備にはどのくらい期間がかかりますか？

着手範囲で変わりますが、障害対応フローと連絡先一覧に限れば1週間程度で骨格ができます。システム構成図と運用設計書まで含めると、現行環境の調査を伴うため1か月から3か月が目安。運用手順書を全作業分そろえるのは半年単位の仕事になるため、最初から全部を計画に入れないでください。対象を「直近1年で発生した事象と月次で必ず行う作業」に絞れば、最初の2週間で実用に足る範囲が埋まります。

既存システムでドキュメントが一切ない場合は何から始めますか？

担当者への聞き取りから始めます。30分の聞き取りを2回行い、障害時の連絡先と承認者、月次で行っている手作業、外部サービスとの連携先の三点を先に書き出してください。この三点は担当者が退職すると復元が難しく、失われたときの影響が最も大きい情報です。図面や手順書はその後、変更が発生した箇所から書き足す方式にします。稼働中のシステムを全面調査して一気に文書化する計画は、日々の運用と並行できず途中で止まります。

関連記事

• システム保守とは？運用との違い・費用相場・契約形態を発注者視点で解説：文書をどちらの責任範囲に置くかの判断材料
• システム運用とは？保守との違い・業務一覧から委託判断まで発注者視点で解説：文書化する対象を業務一覧から選ぶ材料
• システム運用保守の会社はどう選ぶ？相見積りを比較できる形に揃える手順と契約前の確認点：納品文書の定義を提案依頼書へ組み込む方法
• 社内wikiが失敗する五つの原因とメリットを取り戻す運用設計｜形骸化からの立て直し基準：文書の置き場所が形骸化したときの立て直し
• ヘルプデスク効率化の施策と進め方｜可視化・自動化・属人化解消の着手順序：属人化の解消を工程として進める順序