運用設計とは？運用設計書に書く項目と、担当者が使える形にする手順

運用設計と、設計書・操作手順書の役割を分ける

運用設計は、システムを使う業務を必要な状態で続けるために、仕事の進め方と判断する条件、担当の分担を決めることです。日常の取込や点検だけでなく、予定を変えるとき、異常に気付いたとき、担当が交代するときも対象になります。個々の画面操作と、その仕事を行ってよい条件をつなぐ考え方です。

運用設計書には、判断と責任のつながりを書く

例えば受注取込なら、開始してよい条件、扱う入力、担当者の権限、結果を確かめる場所、出荷担当へ渡す終点、うまく進まない場合の連絡を決めます。設計書に「受注取込」とだけ書いても、別の担当が、どこからどこまで自分の仕事か分からなければ引継ぎに使えません。

操作手順書には、対象の版や環境に対応する画面・操作・確認方法を具体化します。運用設計書から関連する手順書へたどれ、手順書から作業条件と判断先へ戻れるようにします。どちらか一方の名称で全てを済ませる必要はありません。

横に動かせる比較表です。左の資料名を残しながら右端の確認相手まで読み、同じ行の目的と対応させてください。

非機能要求は、仕事に求める速さや利用時間、復旧、閲覧範囲などの条件です。運用設計では、その条件に向け、誰がどんな作業をし、何を確かめるかへ結びます。保守会社への委託範囲は、運用設計書へ担当名を書くだけでは決まりません。契約と実際の窓口、社内に残る仕事を対応させます。

稼働する前から決め、既存の資料も確かめ直す

運用設計は、稼働した後でしか作れないものではありません。開発や受入の段階で、結果を確認する表示、必要な記録、権限、異常時の連絡などを検討すると、運用で必要な機能を相談できます。既に動くシステムを引き継ぐ場合は、資料を正しいものと決めつけず、現在の構成と仕事、担当者・契約を確認する所から始めます。

業務・構成・担当・契約から、決める対象を絞る

最初に、何の業務を、誰が、いつ必要としているかを説明します。サーバーや製品の一覧からだけでは、その機器が止まるとどの仕事が困るか分かりません。利用者、締めや予定、入力するもの、結果を受け取る担当、外部サービスとの接点を、具体的な仕事からたどります。

現状を調べる材料と、分からないことを分ける

• 業務と利用の条件：扱う業務、利用者の役割、利用する時間帯、重要な締めや予定、結果を待つ相手を聞きます。実際の条件が未確認なら、一般的な時間や人数で埋めません。
• 構成とつながり：対象の仕組み、入力と出力、接続先、共有する保存先などを、構成資料と担当者の回答で対応させます。知らない経路を図の線だけで補いません。
• 現在の運用：今の作業メモ、手順書、結果の記録、変更の履歴、問い合わせ先を集め、資料が現在の版と環境に合うか確かめます。資料がないことと、作業が存在しないことは別です。
• 担当と委託の境界：社内の判断者、実作業を行う担当、委託先、引継ぎ先を確認します。受付できる時間、調査や復旧を担う範囲、追加の依頼が必要な条件は契約へ戻って確かめます。

全てを一度に埋めず、仕事の切れ目から始める

引き継ぐ業務を一つ選び、開始から結果を受け取る相手まで説明します。「入力する人は分かるが、結果を見る担当が不明」「手順書はあるが、変更を判断する人が不明」といった切れ目を見つけてください。必要な資料と答えられる担当へ、具体的な質問を返します。

対象外と判断できた項目には理由を残します。まだ調べていない項目を「該当なし」として消してはいけません。未回答があれば、何が分かれば判断できるか、誰へ聞くか、現在進められる範囲を分けます。未確認の点を想像で埋めた設計書を、担当者が使える資料とは扱いません。

発注前の速さ・利用時間・復旧・閲覧範囲をどう求めるかは、業務から非機能要求を決める方法で詳しく扱っています。本稿は、その条件と日々の仕事を、担当・判断・資料へつなぐ運用設計を中心に説明します。

図で見る問い：手元の資料を、どの仕事の何を決めるために読むのでしょうか。「朝の受注取込」のメモと、それに結び付く資料の紙を見てください。

この解説図を原寸で見る

図の読み方：業務予定は始める条件、構成資料は入力や接続、担当表は誰へ確かめるか、契約書は委託の境界を調べる手掛かりです。資料の名前を集めるだけで終えず、その仕事のどの条件に答えるかを結び付けます。資料が古い・見つからない・答えが食い違う所は、正しいと決めず、必要な資料と答えられる担当へ質問を返してください。

運用設計書の基本項目を、仕事の目的へ結び付ける

直前の仕事と資料の図で、どの資料がその仕事のどの条件に答えるかを見たうえで、次の基本項目へ対応させます。例えば、業務予定から始める条件、担当表から役割と確認先、構成資料から入力と接続、契約書から委託の境界を探します。未回答の条件を一覧の空欄を埋めるために確定しないでください。

基本項目は、会社の章立てを埋めるためでなく、必要な仕事と判断の抜けを見つけるために使います。次は代表的な対象です。全社に同じ章数や全項目を強制する一覧ではありません。対象業務の条件と現在の資料を確かめ、必要な記述と参照先を選びます。

対象と基本方針

何の業務を対象にし、誰がいつ使い、どの状態を維持したいかを示します。「安定稼働」だけで終えず、受注取込なら、取込結果を確認して出荷の対象へ渡す所までを説明します。対象外の仕組みと、別の会社や部署へ確認する接点も残します。

体制・担当・権限

作業する人、業務の優先度や再開を判断する人、技術的な調査を行う人、利用者へ知らせる人を対応させます。少人数で兼務する場合も、仕事としての役割を分けます。操作できる権限、代わりの担当、不在や時間外の扱いを確認し、担当名だけで了承や権限を得たことにしません。

定常作業とスケジュール

決まった条件で繰り返す作業について、始まりの条件、入力、担当、判断、結果の確認を結びます。営業日と休日、締めや月次など必要な周期を考えます。前の処理が終わっていることなどの前提があるなら、何を見て始めるかまで決めます。

監視と連絡

どの業務・機能を何で確かめ、異常が疑われたら誰へ何を伝えるかを示します。監視の項目名だけでなく、対象と判断の条件、通知先と受け取った後の仕事を対応させます。何も記録されていない状態を、そのまま正常とみなす設計にはしません。個別の監視の判断は、対象環境と責任者へ確かめます。

バックアップと復元

何をどの時点の状態で残し、誰が結果を確かめ、どんな条件で戻すかを決めます。バックアップを作る作業と、業務に必要な記録を戻して使えるかの確認は別です。戻す権限、必要な資料、復元後に確かめる担当までつなぎます。方式や保存期間、戻る時間を、この架空例から確定するものではありません。

障害・例外への対応

想定した仕事が進まないとき、何の記録を残し、どの操作を保留し、誰へ判断を依頼するかを示します。影響の確認、調査の引受け、利用者への案内、業務再開を分けます。あらゆる異常へ同じ再起動を行う、といった無条件の操作にはしません。

予定変更・更新と、実施後の確認

システムの設定や作業予定、外部サービスの接続が変わる場合、影響する仕事と資料、判断が必要な人を確かめます。実施の条件、問題が出た場合の連絡、戻す判断、変更後の確認を対応させ、変更したことだけを完了にしません。具体的な操作は対象の手順へ結びます。

資料の保管・共有・見直し

必要な人が現在の版と関連手順を見つけられる場所を決めます。版、対象環境、変更した点、更新する担当を残し、古い記述を今の手順と取り違えない状態にします。認証情報や顧客の実値を設計書へ無制限に書くのではなく、許可された管理方法と参照の範囲を定めます。

朝の受注取込を、一つの使える記述へ組み立てる

「受注ファイルを取り込む」を、開始から相手側の確認までつながる記述へ直します。ここからは朝の受注取込の例です。独立した一つの作業の説明例で、対象は架空の部品卸売会社、役割は社内IT担当、仕事は「受注ファイルを取り込み、出荷担当が当日の対象を確認する」としています。

これは未承認の記述案です。実際の運用を観測した結果と、現在の資料が実環境に合っているかは未確認です。以下は何を書くかを相談する案であり、そのまま実環境へ指示できる承認済み手順ではありません。

始める条件と入力を、担当が確かめられる形にする

開始のきっかけは営業日の朝の取込予定、入力は受注ファイルという架空例です。設計書では、対象の営業日、取り込む対象、開始前に確かめる状態と、その確認先を決めます。「朝になったら開始」だけで、入力が用意されていることや前の処理の完了まで確定しません。

作業者は社内IT担当という架空例で、操作できる権限の範囲は未確認です。誰が入力を用意し、誰が取込みを行い、通常と違う状態で誰が判断するかを、必要な権限とともに聞きます。ログイン方法の説明に、実際のパスワードや秘密の設定値を掲載する必要はありません。

判断の根拠と、完了を確かめる相手をつなぐ

判断の根拠は「取込結果と対象日の確認を要する設計案」、完了の条件は「出荷担当が当日の対象を確認できるかを設計書で定義する案」です。取込みの操作を終えたことと、出荷担当が必要な当日の対象を扱えることを分けます。どの表示や結果を見て、どの対象日と照らし、誰が確認するかを相談してください。

この作業が実際に完了した結果は未確認です。できない場合に連絡する担当と委託先と社内の契約上の境界も未確認です。結果が分からない状態で取込みを繰り返す、出荷側の確認を省く、といった行動を既定の解決方法にはしません。

図で見る問い：朝の受注取込を別の担当者へ渡すには、設計書のどこに何を結び付けるのでしょうか。入力、開始条件、IT担当、出荷担当の確認、例外の連絡先を見てください。

この解説図を原寸で見る

図の読み方：資料が存在するだけでは、作業を任せられると判断できません。担当が入力と開始条件を探し、操作手順へ進み、業務の終点と例外の相談先までたどれるかを確認します。未承認の条件や答えがない箇所は、その担当へ質問して保留し、実行済み・成功済みの印に変えないでください。

予定変更と例外時の判断・連絡を分けて決める

予定どおりに行う作業と、条件が変わる場合の判断・連絡を分けます。ここでは予定変更・例外の条件例を取り上げます。朝の受注取込の後続や修正後とは別の説明例です。対象は別の架空の業務システム、役割は業務責任者とIT窓口、仕事は「予定した作業を変更するか、例外時に誰へ連絡するかを決める」です。

この条件も未承認の記述案です。実運用の観測結果と現在の資料が正しいかは未確認です。前の例の未確認が解消された事例として読まないでください。

変更を実施してよい条件と、判断する人を決める

開始のきっかけは予定変更または例外の申告、入力は申告内容という架空例です。作業者については担当は条件に応じて決める案とし、実際の権限の範囲は未確認です。予定が変わる場合、対象の作業と影響する相手、業務の締め、外部の予定などを確認し、必要な判断を依頼します。

判断の根拠は「変更の影響と承認の要否を確認する案」、完了の条件は「関係者への連絡と資料更新の確認点を定義する案」です。変更を了承する人、実施する人、連絡する人、資料を更新する人を対応させます。申告されたことや、連絡を送ったことだけで、変更の了承と完了を確定しません。

実際の完了結果、例外を引き継ぐ担当、契約の境界は未確認です。設計書では、通常の手順で進められない条件、その際に残す事実と相談先、判断を受けた後の確認を決めます。具体的な障害の初動・利用者への案内は、障害の受付と連絡の手順へつなげます。

委託しても、社内に残る判断を確かめる

提供会社が監視や作業を行う場合も、業務の優先度、変更の影響、利用者への案内、再開の判断が誰の仕事かを確認します。社内の設計書に「保守会社へ連絡」と書くなら、連絡先と受付方法、渡す情報、引き受ける範囲、社内へ返す結果を取り決めへ対応させます。

受付、最初の返答、調査の開始、復旧、業務の再開は同じ条件ではありません。運用設計書へ書いた希望を、相手が同意した保証へ読み替えないでください。費用や対応範囲を比べる詳細は、システム保守の作業範囲と応答条件で扱います。

図で見る問い：予定変更や例外の申告を受けたら、何を判断してもらい、誰へ何を伝える必要があるでしょうか。申告のメモ、業務責任者とIT窓口、連絡と更新の紙の関係を見てください。

この解説図を原寸で見る

図の読み方：申告は判断の入口です。業務への影響と了承の要否を確かめる仕事、技術や対応範囲を相談する仕事、関係者へ知らせる仕事、資料を直す仕事を分けます。図に役割があるだけでは、実施者と権限が決まったことにはなりません。条件と担当が未確定なら、その点を相談先へ返し、実施を了承されたことや完了の結果に置き換えないでください。

初めて読む担当が、資料と判断をたどれるか試す

初めて読む担当者が、資料の場所と開始・判断・終点をたどれるかを、安全な条件で確かめます。資料を書いた人が口頭で毎回補わないと進められないなら、参照先や判断の条件が不足している可能性があります。権限と対象の環境、使用する説明材料を会社の条件に合わせて決めます。

1. 対象と前提を合わせる。設計書・操作手順書の版、対象のシステムと環境、利用者の役割、入力の例、確認する作業をそろえます。実顧客のデータや本番の変更を、説明のために行う必要はありません。
2. 必要な資料を探す。担当者が設計書から現在の操作手順、結果の確認場所、例外時の判断先へたどれるかを確認します。参照できる権限と、不在時の連絡も確かめます。
3. 通常と例外の場面を選ぶ。入力がそろう場合、開始条件が不足する場合、結果を確かめられない場合、予定を変える場合など、対象の仕事に必要な場面を選びます。全社に一律の試験件数は置きません。
4. 期待と実際を対応させる。何を探し、何を根拠に判断し、どこまで進められたかを残します。操作できたこと、相手が必要な結果を確かめたこと、業務側が了承したことを分けます。
5. 不足を直し、関係する範囲を確認する。読めなかった説明、見つからない資料、判断が曖昧な条件を、答えられる担当へ返します。修正した記載と影響する場面を対応させ、必要な所を確かめ直します。

AWSの運用準備レビューも、運用で得た学びを、対象の業務や組織に合う確認の問いへつなぐ考え方を扱っています。特定の製品や全社共通の追加承認手続きが必要だという意味ではありません。この例に、実際の試行結果や了承を付け足すものでもありません。

図で見る問い：説明どおりに進められるかを確かめるとき、何を分けて残せば判断を取り違えずに済むでしょうか。資料をたどる場面と、「予定」「観察」「担当の返答」「残る不明点」の別々の欄を見てください。

この解説図を原寸で見る

図の読み方：予定は「こう進められるはず」という前提、観察は安全な条件で実際に確かめた事実です。担当の説明は返答として残し、まだ答えがない点と区別します。この図の空欄は成功や失敗の記録ではありません。試す前に環境・版・権限と確認する場面をそろえ、確かめた事実に足りない条件があれば、該当する資料と担当へ戻って補ってください。

変更と担当交代の後も、資料を使える状態に保つ

変更する仕事に、関連資料の更新も結び付けます。取込の入力、対象日、保存先、手順、権限、委託先、連絡先などが変わる場合、どの記述と参照先が影響を受けるかを確認します。新しい手順だけ作り、設計書の判断条件が古いまま残る状態を避けます。

更新の担当と、更新を確かめる時点を決める

誰が資料を書き換え、誰が業務と技術の条件を確かめ、いつ現在の版として扱うかを決めます。変更した点、対象の版と環境、関係する手順、未完了の確認を残します。過去の記録は、当時の条件で得た結果として読めるようにし、現在の版の成功を示すものへ置き換えません。

担当交代では、読む人の仕事から確かめる

交代する担当へ、通常の入口と完了、例外時の相談先、必要な資料と権限、残る未確認を渡します。受け手が何を引き受けるかを確かめ、業務側と委託先の接点も更新します。関係者全員の一律の返信を待つ仕組みにするのではなく、必要な判断と引受けが誰の仕事かを明確にします。

この架空原票の未確認は、未観測または未確定を意味し、0・不成立・成功へ読み替えません。二つの例は独立した条件で、修正前後や改善の実績ではありません。記述案を読みやすくしても、未知の権限、資料の正確性、実行結果、契約の範囲まで決まったことにはなりません。

図で見る問い：仕事や担当が変わったら、どの資料を誰が直し、次の人へ何を渡す必要があるでしょうか。変更・交代の入口から、影響する紙、更新担当、版と環境、受け渡す相手へたどってください。

この解説図を原寸で見る

図の読み方：変更した手順だけでなく、その手順を選ぶ設計書の条件や連絡先にも影響がないかを見ます。書き換える担当と、現在の版として扱う条件を決め、受け手へ参照先と未確認を渡します。紙を渡しただけでは引受けや実運用の完了は確定しません。どこまで更新でき、何の回答や確認が残るかを、その仕事に必要な担当へ結び付けてください。

まとめ：一つの仕事を、開始から例外までつなぐ

直前の変更と受渡しの図も使い、選んだ仕事について、関係する資料、更新する担当、現在の版、次に受け取る人へたどってください。答えが途切れる所が、次に確かめる資料と相談先です。

運用設計では、対象の業務を起点に、開始条件、入力、担当と権限、判断の根拠、作業の終点、結果の確認、例外の連絡をつなぎます。設計書は方針・役割・作業条件を説明し、具体的な操作を対応する手順書へ結び付けます。

一般的な基本項目を自社の仕事へ当てはめ、該当しないことと未確認を分けてください。初めて読む担当が必要な資料と判断をたどれるかを、安全な条件で確かめ、変更や担当交代の後も現在の仕事に合う状態へ更新します。資料の存在、担当の了承、試行結果、実運用の結果を一つにまとめないことが大切です。