システム運用設計書の作り方

はじめに

新しいシステムが完成しても、仕事はそこで終わりません。毎月の権限確認は誰が行うのか。データが更新されないとき、現場はどこへ連絡するのか。開発会社と利用部門の間で決まっていなければ、稼働後の問い合わせや判断が宙に浮いてしまいます。

システム運用設計書は、日々の作業と異常時の判断を関係者が共有するための文書です。ここでは、受注管理システムを導入する架空の会社を例に、専門知識がなくても業務担当者が確認できる5つの項目と作成の順番を整理します。数値や役割は説明用であり、自社にそのまま適用する基準ではありません。

運用設計書は何を決める文書か

運用設計書は、システムを使い続けるために「何を、いつ、誰が、どの条件で行うか」を決める文書です。運用手順書が画面操作などの具体的な手順を示すのに対し、運用設計書では作業の目的、役割、判断基準、必要な手順書との関係を整理します。組織によって文書名や分け方は異なります。

たとえば「毎月末に利用者の権限を確認し、業務責任者が不要な権限の削除を承認する」は設計上の決めごとです。「管理画面のどこを開き、どのボタンを押すか」は手順書に記します。設計書に操作画面をすべて貼る必要はありませんが、最新版の手順書へたどれるようにしておきます。

IPAの非機能要求グレードは、利用者と開発者の認識違いを防ぐため、システムの非機能要求を分類して要求レベルを示しています。運用設計でも、使える時間帯や復旧の考え方を「止まらないようにする」のような曖昧な言葉で済ませず、業務側と開発・保守側で確認することが大切です。

システム移行計画の6項目とあわせて、切替後に誰が運用を引き受けるかも整理しておきましょう。

運用設計書に入れる5つの項目

1. 対象業務と運用の範囲

まず、何のために、どこまで運用するのかを決めます。対象システムだけでなく、そのシステムを使う業務と、前後の受け渡しも書きます。受注管理の例なら、注文の受付から出荷依頼までが対象なのか、請求書の発行まで含むのかを明確にします。

次の点を関係者に確認しましょう。

• 利用する部署、業務の目的、利用時間帯
• 対象となるデータと、連携する別システム
• 運用対象外の業務と、その責任者
• 止まると困る時期や、手作業で代替できる範囲

「平日9時から18時に利用する」と書く場合も、月末の締め処理や休日注文が例外にならないか確認します。サービスの提供時間、担当者が問い合わせに対応する時間、障害からの復旧目標は別物です。一つの時間だけで合意したつもりにならないようにします。

2. 定常作業と実施時期

次に、普段行う作業を洗い出します。日次の処理結果確認、月次の利用者棚卸し、バックアップの確認、連携先へのデータ送付などを、頻度と担当を添えて一覧にします。

表の頻度は例です。必要な頻度や保持期間は、業務上の影響、契約、社内方針などを踏まえて決めます。バックアップは「取得した」だけでなく、必要なデータを戻せるかの確認も検討します。訓練は本番データへの影響を避ける方法を担当者と決めてから実施します。

作業の入力と完了の証拠も残します。たとえば連携確認なら「連携結果の一覧を確認し、失敗があれば受付番号を記録する」と書けば、担当者が交代しても未確認のまま見落としにくくなります。

3. 役割分担と連絡先

作業名だけでは、複数部署が関わる場面で責任が曖昧になります。実際に作業する人、内容を判断する人、結果を受け取る人を分けて記載します。

社外委託の場合は、自社と委託先の分担を契約内容と照合します。クラウドサービスを使う場合も、サービス提供者が担当する範囲と自社で対応する範囲を確認します。「ベンダーに連絡」で止めず、誰が連絡し、返事を待つ間に誰が業務継続を判断するかまで決めます。

個人名だけに依存しないよう、役割名と窓口を併記し、担当変更時の更新責任者を決めておきます。機密性の高い緊急連絡先は設計書に直接書かず、閲覧制限された連絡先台帳を参照する方法もあります。

4. 監視・障害対応・復旧

異常を見つけた後の流れを、検知、連絡、判断、対応、再開確認に分けます。監視とは、処理の失敗や遅延などを継続して確かめることです。何を異常とみなすかを、業務側にも分かる表現で記します。

受注データの連携が予定時刻に終わらなかった場合の例を見てみます。

1. 運用担当が連携結果と受付時刻を確認する。
2. 未連携があれば、決められた窓口へ影響範囲と確認済みの内容を連絡する。
3. 業務責任者が出荷を待つか、承認済みの代替手段へ切り替えるか判断する。
4. 保守担当が原因を調査し、承認された手順で復旧する。
5. 業務担当と保守担当が件数や重複の有無を確認し、再開を記録する。

再送や手作業による入力は、二重登録を招く可能性があります。操作してよい人、再送前に確かめる項目、判断がつかない場合の停止条件を事前に決めてください。障害の分類や対応の管理は、AWSのイベント対応ガイダンスでも、手順書を使った一貫した対応とあわせて説明されています。

復旧目標は、技術側だけでなく業務側が「どの時間帯に、どの処理が使えないと困るか」を示して決めます。目標を決めたことと、その時間内に実際に復旧できることは別です。訓練や検証の結果で実現可能性を確かめ、未検証なら未検証と記録します。

5. 引き継ぎ・変更・見直し

最後に、作成した設計書を誰が保管し、いつ見直すかを決めます。公開前に、運用担当が必要な手順書や権限を受け取り、問い合わせ先を使えることを確認します。未決事項は担当者と期限を付け、決まっていないまま完了扱いにしません。

システムや業務が変わったら、関連する運用も確認します。たとえば連携先を追加した場合、通常処理だけでなく、監視対象、障害時の窓口、復旧後の件数確認も更新対象です。変更前後の内容、承認者、反映日を残し、現場が参照する手順書へ反映します。

作成から合意までの進め方

最初から詳細な文書を一人で作るより、現場、情報システム担当、開発・保守担当で次の順番に確認すると進めやすくなります。

1. 対象業務と利用時間、業務が止まった場合の影響を整理する。
2. 日常作業と例外を洗い出し、担当・頻度・完了条件を仮置きする。
3. 監視から連絡、代替運用、復旧確認までを一つの例でたどる。
4. 手順書、契約、権限表との食い違いや、担当未定の項目を確認する。
5. 責任者が内容と未決事項を確認し、保管先と更新方法を決める。

会議では「担当は運用チーム」とだけ決めず、通知を受ける窓口、判断に必要な情報、代理担当まで確かめます。作成途中の表に空欄があっても、推測で埋めるより、未決として担当者へ確認する方が安全です。

業務の境界や作業順序を整理したいときは、Kakusillで要件や仕様を整理する方法もあります。内容をそのまま確定とせず、現場の例外や運用責任を確認してから合意につなげます。

まとめ

システム運用設計書は、文書を完成させることより、稼働後の仕事と判断を共有することに意味があります。対象業務、定常作業、役割、障害対応、引き継ぎ・変更の5項目を起点に、まず一つの業務で通常時と異常時をたどってみてください。

Atsumellでは、業務の流れや要求の整理から開発に渡す仕様づくりを支援しています。現場の暗黙知や部署間の分担を整理したい場合は、お問い合わせからご相談ください。