システム運用マニュアルは、日次作業だけでなく、監視、障害、問い合わせ、変更、権限管理までを「誰が・いつ・何を・どこまで行うか」で整理します。外注費用の目安は小規模で30万〜80万円、中規模で80万〜200万円程度ですが、現状調査や手順検証の範囲で変わります。

システム運用マニュアルに必要な範囲と構成

システム運用マニュアルを作る目的は、特定の担当者がいなくても、必要な作業と判断を一定の品質で再現できる状態にすることです。単に管理画面の操作を並べるだけでは、担当者の退職、障害、問い合わせの集中といった状況に対応できません。

発注のご相談を受ける開発会社の立場から見ると、既存マニュアルがあっても「通常時の画面操作しか書かれていない」「エラーが起きたら誰へ連絡するのか分からない」というケースが少なくありません。操作方法に加えて、作業の目的、開始条件、完了基準、例外時の判断まで書くことが重要です。

運用設計書・手順書との違い

運用関連の文書には複数の種類があります。名称は会社によって異なるため、発注時は文書名だけでなく、必要な内容と納品物を確認してください。

文書 主な目的 記載する内容
運用設計書 運用全体の方針を決める 対象範囲、体制、役割、運用時間、監視、障害対応、変更管理
運用マニュアル 担当者が業務を遂行できるようにする 業務一覧、判断基準、作業の流れ、連絡先、注意事項
操作手順書 個別の作業を再現できるようにする 操作順序、入力値、画面、実行結果、エラー時の対応
チェックリスト 作業漏れを防ぐ 実施項目、確認者、実施日時、結果、証跡の保存先
障害対応手順書 障害発生時の初動を統一する 検知、影響確認、切り分け、連絡、復旧、事後報告

小規模なシステムでは、これらを一つの運用マニュアルにまとめても構いません。業務や関係者が多い場合は、運用設計書を上位文書とし、作業単位の手順書を分けたほうが更新しやすくなります。

最低限入れるべき項目

運用マニュアルには、次の項目を含めます。

  • 文書の目的、対象システム、対象外の範囲
  • 運用時間、休業日、作業カレンダー
  • 発注者、保守会社、インフラ会社などの役割分担
  • 日次、週次、月次、年次、随時作業の一覧
  • 各作業の開始条件、必要な権限、入力情報
  • 通常時の操作手順と完了基準
  • エラーや想定外の結果が出た場合の対応
  • 障害レベル別の連絡先とエスカレーション(=上位責任者や専門担当へ判断を引き継ぐこと)
  • 作業ログ、承認記録、報告書など証跡の保存先
  • バックアップ、復元、アカウント管理、変更管理のルール
  • 文書の管理責任者、承認者、更新日、変更履歴

パスワード、秘密鍵、APIキーなどの認証情報をマニュアルへ直接記載するのは避けます。認証情報は、アクセス権を制御できる専用の保管場所で管理し、マニュアルには参照方法と利用申請の流れだけを記載します。

また、SLA(=保守サービスの対応時間や品質水準を定める合意)と運用マニュアルは役割が異なります。SLAは「何分以内に受付するか」などの水準を定め、マニュアルは「受付後に誰が何を確認するか」を具体化します。契約面も整理する場合は、システム保守SLAの決め方|契約項目と費用相場も参考にしてください。

作成を外注する費用相場と期間

運用マニュアル作成の外注費用は、ページ数よりも、対象システム数、作業手順数、現状調査の難しさ、動作検証の範囲で決まります。ページ単価だけで比較すると、ヒアリングや例外対応の整理が見積もりから抜けやすいため注意が必要です。

以下は、一般的な外注費用と期間の目安です。

規模 想定する状況 費用の目安 期間の目安
小規模 1システム、手順10〜20件程度、既存資料あり 30万〜80万円 1〜2か月
中規模 2〜5システム、複数部門、ヒアリングと動作確認あり 80万〜200万円 2〜4か月
大規模 多数の連携先、24時間運用、障害訓練や教育を含む 200万〜500万円以上 4〜8か月以上

上記は、調査、構成設計、執筆、レビュー、基本的な検証を含む場合の目安です。実際の保守業務、監視ツールの導入、システム改修、インフラ構築、休日・夜間の立ち会いなどは別費用になることがあります。

費用を左右する主な要因

見積もりが高くなりやすいのは、次のような場合です。

  • 現在の運用が担当者の記憶だけで実施されている
  • システム構成図、アカウント一覧、問い合わせ履歴がない
  • 複数の開発会社やサービス提供会社が関係している
  • 作業ごとに承認者や実施条件が異なる
  • 夜間、休日、月末など限られた時間にしか確認できない
  • 本番環境での動作確認に厳格な申請が必要である
  • 障害対応訓練や担当者向け研修まで依頼する
  • 納品先が複数あり、文書形式やセキュリティ基準が異なる
  • 英語版など多言語での作成が必要である

特に費用差が出るのは、現状調査です。既存資料がなくても作成はできますが、担当者へのヒアリングや実作業の観察が必要になります。発注前にすべての資料を完成させる必要はないものの、「どの作業を、誰が、どの頻度で行っているか」という一覧だけでも用意すると、調査期間を短縮できます。

更新・保守にも予算を確保する

運用マニュアルは、納品時点で完成して終わる文書ではありません。機能追加、管理画面の変更、担当体制の変更、障害対応の振り返りに合わせて更新する必要があります。

更新支援を外注する場合の目安は、軽微な定期更新で月額5万〜30万円程度、複数手順の見直しをスポットで依頼する場合は10万〜50万円程度です。ただし、対象文書数、変更頻度、動作確認の有無で大きく変わります。

費用を抑えるには、開発会社へ更新を任せ続けるのではなく、編集可能な元データ、テンプレート、更新ルールの納品を受け、軽微な変更は社内で行える状態を目指すとよいでしょう。

運用マニュアルを作る6つの手順

作成は、文書を書く前の運用整理が重要です。現在の担当者から聞いた内容をそのまま文章にするのではなく、不要な作業、重複した確認、責任者が不明な判断を整理してから標準化します。

1. 目的・対象範囲・完成条件を決める

最初に、誰が何のために使うマニュアルかを明確にします。新人教育、属人化の解消、保守会社の変更、監査対応、内製化など、目的によって必要な粒度が変わるためです。

次の項目を決めておきます。

  • 対象となるシステムと業務
  • 対象外とするシステムや作業
  • 利用者の役割と知識レベル
  • 通常運用、障害対応、問い合わせ対応のどこまで含めるか
  • 納品形式と保管場所
  • 発注者側の確認者と承認者
  • 完成と判断する受入基準

受入基準(=納品物を合格と判断する条件)は、「必要な章がそろっている」だけでは不十分です。「作成に参加していない担当者が、口頭説明なしで対象作業を完了できる」といった検証可能な条件を入れます。

2. 現在の運用作業を棚卸しする

担当者へのヒアリング、チケット、作業記録、カレンダー、監視通知などから、現在行っている作業を洗い出します。定期作業だけでなく、不定期に発生する依頼や例外対応も確認します。

棚卸し表には、少なくとも次の項目を記載します。

項目 記載例
作業名 月次請求データの確定
実施時期 毎月第1営業日
担当・承認者 業務担当が実施、責任者が承認
開始条件 前月分の取引データが連携済み
使用システム 管理画面、会計サービス
完了条件 件数と金額が一致し、承認記録が保存済み
失敗時の対応 再連携せず、保守窓口へ調査を依頼

作業の存在だけでなく、「なぜ行うのか」も確認します。目的が説明できない作業は、過去のルールが惰性で残っている可能性があります。マニュアル化を機に廃止や自動化を検討できますが、影響確認なしに削除してはいけません。

3. 優先順位と役割分担を整理する

すべての作業を同じ細かさで文書化すると、費用が膨らみ、重要な手順の完成が遅れます。事業への影響、発生頻度、作業の難しさ、担当者の代替可能性から優先順位を付けます。

優先して整備したいのは、次の作業です。

  • 停止すると売上、顧客対応、法定業務へ影響する作業
  • 誤操作した場合にデータ消失や二重処理につながる作業
  • 一人の担当者しか実施方法を知らない作業
  • 月末や繁忙期など、やり直せる時間が限られる作業
  • 障害発生時の初動、連絡、復旧判断
  • 権限付与、削除、個人情報の抽出に関する作業

さらに、実施者、承認者、相談先を明確にします。「問題があればシステム担当へ連絡」と書くだけではなく、連絡条件、窓口、必要な情報、連絡がつかない場合の次の相談先まで決めます。

4. 共通テンプレートで手順を書く

手順ごとに形式が異なると、利用者が必要な情報を探しにくくなります。次のような共通テンプレートを使います。

  • 作業名、目的、対象システム
  • 実施者、承認者、実施タイミング
  • 事前条件、必要権限、準備するデータ
  • 操作手順と各手順の確認ポイント
  • 正常終了の条件と保存する証跡
  • 中止すべき条件
  • エラー別の対応方法
  • 元に戻す方法または復旧依頼の方法
  • 問い合わせ先と連絡時に伝える情報
  • 関連文書、更新日、作成者、承認者

画面キャプチャは、誤操作しやすい箇所や入力位置の説明に有効です。一方、画像に頼りすぎると、軽微な画面変更のたびに大量の更新が必要になります。操作の目的や完了条件は文章でも記載し、画像が古くなっても危険な判断をしない構成にします。

5. 担当者以外が実際に検証する

マニュアルの品質は、文章の読みやすさだけでは判断できません。作成に関与していない担当者が手順を読み、実際に作業できるかを確認します。

検証時のチェック項目は次のとおりです。

  • 必要なアカウントや権限を取得できるか
  • リンク先、ファイル名、メニュー名が正しいか
  • 手順の前提となるデータが用意されているか
  • 各操作後の正しい状態を判断できるか
  • エラー時に作業を続けるか中止するか判断できるか
  • 作業結果と証跡を指定場所へ保存できるか
  • 問い合わせ時に必要な情報を収集できるか

削除、決済、メール一斉送信など、取り消しにくい操作を本番環境で安易に試してはいけません。テスト環境、サンプルデータ、読み取り専用権限を使うなど、安全な検証方法を発注者と開発会社で決めます。

6. 公開・教育・更新の仕組みを作る

承認済みのマニュアルを一か所へ集約し、最新版がどれか分かる状態で公開します。ファイルをメール添付で配布すると古い版が残りやすいため、社内Wiki(=複数人で更新できる社内情報サイト)や文書管理サービスなどを利用すると管理しやすくなります。

公開時には、読み合わせだけでなく、実際の作業を模擬する研修を行います。内製化を目指す場合は、外注先が作業を見せるだけでなく、社内担当者が実施し、外注先が確認する段階まで含めることが重要です。

更新の仕組みとして、次を決めます。

  • 文書ごとの管理責任者と承認者
  • 機能変更時に更新依頼を出す担当者
  • 更新内容、更新日、承認者を記録する方法
  • 定期レビューの時期
  • 古い版を誤使用しないための保管ルール
  • 障害や作業ミスの振り返りを反映する手順

外注前の準備・見積もり比較・会社の選び方

外注を成功させるには、完成原稿を用意する必要はありません。依頼前に必要なのは、対象範囲、現状資料の有無、関係者、希望する完成状態を共有することです。

依頼前の準備チェックリスト

次の資料があると、開発会社が調査工数と作成範囲を見積もりやすくなります。存在しない資料は、無理に作らず「なし」と伝えて構いません。

  • 対象システムと外部連携先の一覧
  • 現在の運用担当者、承認者、問い合わせ窓口
  • 日次、月次、随時作業の大まかな一覧
  • 既存の手順書、メモ、チェックリスト
  • システム構成図、アカウント・権限一覧
  • 過去の問い合わせ、障害、作業ミスの記録
  • 保守契約書、SLA、連絡体制表
  • 操作確認に使えるテスト環境とテストデータの有無
  • 希望する納品形式と社内の文書テンプレート
  • 閲覧制限、個人情報、機密情報に関するルール
  • レビューへ参加できる現場担当者と責任者
  • 希望納期と優先して完成させたい手順

現行担当者が多忙でヒアリング時間を確保できないと、マニュアルの正確性が下がるか、調査期間が延びます。契約前に、誰が何時間程度レビューへ参加できるか確認しておきましょう。

見積書で比較する項目

総額だけでなく、どこまで調べ、何を納品し、どのように正しさを確認するかを比較します。

確認項目 見積書で見るポイント
現状調査 資料確認、ヒアリング回数、現場観察が含まれるか
対象範囲 システム数、業務数、手順数、障害対応の範囲が明記されているか
成果物 運用設計書、手順書、一覧表、チェックリストの内訳があるか
例外対応 正常操作だけでなく、エラーや中止条件も対象か
動作検証 誰がどの環境で検証し、修正するか
レビュー 発注者の確認回数、修正回数、承認方法が定義されているか
納品形式 編集可能な元データも受け取れるか
教育 説明会、実地訓練、質疑応答が含まれるか
更新支援 納品後の修正期間、月額更新の条件が明記されているか
セキュリティ アカウントの利用方法、データ持ち出し、再委託条件が明確か

「100ページを納品」のようなページ数中心の見積もりには注意が必要です。ページ数が多くても、重要な判断基準や例外時の対応が抜けていれば実務では使えません。対象作業の一覧と、作業ごとにどの深さまで書くかを合意してください。

既存資料が少なく見積もりが難しい場合は、最初から全範囲を固定金額で依頼せず、現状調査と代表的な数手順の試作を先に依頼する方法があります。試作後に残りの手順数と難易度を確定すれば、追加費用の認識違いを抑えられます。

委託先を見極めるポイント

運用マニュアルは、文章制作だけでなく、システム、業務、保守体制を理解して整理する仕事です。次の観点で委託先を確認します。

  • システム開発や保守運用の経験があるか
  • 現場担当者から暗黙の判断基準を引き出せるか
  • 正常操作だけでなく、障害や例外時の流れを設計できるか
  • 作成者以外による動作検証を提案しているか
  • 認証情報や個人情報を安全に取り扱えるか
  • 業務改善とマニュアル化を混同せず、変更の影響を説明できるか
  • 編集可能な形式で納品し、更新方法まで引き継げるか
  • 内製化を見据えた教育や伴走支援ができるか

候補会社へは、実績資料のページ数ではなく、「情報が不足した状態から、どのように調査して手順を確定するか」を質問すると進め方の違いが分かります。可能であれば、重要な一作業をサンプルとして作成してもらい、構成、質問の質、検証方法を比較します。

運用の棚卸しから手順書作成、検証、社内への引き継ぎまで整理したい場合は、開発のご相談はこちらからご相談ください。

よくある失敗と回避策

よくある失敗 原因 回避策
実際の運用と内容が合わない 管理者だけへヒアリングした 現場担当者の作業観察と実地検証を行う
正常時にしか使えない 画面操作だけを記載した エラー、中止条件、連絡先、復旧方法を入れる
誰も更新しない 管理責任者が決まっていない 文書ごとに責任者と更新契機を設定する
情報を探すのに時間がかかる 一つの巨大なファイルへ集約した 業務、頻度、障害種別で分割し、一覧からリンクする
納品後に社内で編集できない PDFだけで納品された 編集可能な元データとテンプレートを契約に含める
認証情報が漏えいする パスワードを本文へ記載した 認証情報を別の安全な場所で管理する
現在の無駄な作業まで固定化する 現行手順を無条件に書き写した 作業目的と必要性を確認し、変更は承認後に反映する
内製化が進まない 説明会だけで引き継いだ 社内担当者による実作業と外注先の確認を行う

特に避けたいのは、マニュアルの納品を内製化の完了と考えることです。社内担当者がアクセス権を持ち、実際に作業し、問題が起きたときの相談先まで理解して初めて引き継ぎが成立します。

まとめ

  • システム運用マニュアルは、操作方法だけでなく、目的、開始条件、完了基準、例外対応、役割分担まで記載します。
  • 外注費用の一般的な目安は、小規模で30万〜80万円、中規模で80万〜200万円、大規模で200万〜500万円以上です。
  • 期間の目安は小規模で1〜2か月、中規模で2〜4か月ですが、既存資料や検証環境の有無で変動します。
  • 作成は、対象範囲の決定、作業の棚卸し、優先順位付け、執筆、実地検証、更新体制の整備という順序で進めます。
  • 見積もりはページ数ではなく、対象手順、現状調査、例外対応、動作検証、教育、更新支援の範囲で比較します。
  • 委託先は、文章力だけでなく、システム保守の経験、現場へのヒアリング力、検証方法、セキュリティ対応で選びます。
  • 内製化を目指す場合は、編集可能な元データと更新ルールを受け取り、社内担当者による実作業まで行います。

よくある質問

運用マニュアル作成を外注する費用はいくらですか?

一般的な目安は、小規模な1システムで30万〜80万円、中規模で80万〜200万円、大規模または複数システムで200万〜500万円以上です。既存資料の有無、手順数、現場調査、動作確認、教育の範囲によって変わります。

既存の運用資料がなくても外注できますか?

外注できます。ただし、担当者へのヒアリング、実作業の観察、管理画面やログの確認から始めるため、既存資料がある場合より現状調査の費用と期間が増えます。まず重要な業務を対象に試作する方法が現実的です。

画面キャプチャは運用マニュアルに必要ですか?

操作箇所を明確にするために有効ですが、すべての操作へ付ける必要はありません。判断に迷う画面や誤操作の影響が大きい箇所へ絞り、画像だけでなく操作目的、入力条件、完了基準、エラー時の対応も文章で記載します。

運用マニュアルはどのくらいの頻度で更新すべきですか?

一律の正解はありませんが、機能変更、運用ルール変更、障害対応後、担当体制変更のタイミングでは更新が必要です。加えて、月次または四半期など業務に合った定期レビューを設定し、責任者と更新履歴を明確にします。