今日の文書 — 運用設計書
運用設計書 — 本番稼働後のシステムを、誰が・いつ・何を見て・何かあったらどこまで自分でやり、どこから誰に渡すかを決める文書。開発が終わった後、運用する人が最初に開く。作った人（開発）と使う人（業務）と動かす人（運用）が別の部署のとき、その3者の間の線を引くのがこの文書の仕事である。
この文書の勝負どころ: 運用の担当分界点が明確か。 今日はこれを実務の言葉に言い換える。明確とは、「担当は情報システム部」と部署名を書くことではなく、事象ごとに「最初に動く人」「その人が単独でやってよい範囲」「次に渡す先と渡す条件」が決まっていることである。部署ごとの担当表は、どの部署の担当でもあるように見えて、夜中の障害では誰も動かない表になりやすい。
| 層 | 例（今日の題材） | 決める人 |
|---|---|---|
| 技術の判断 | 判定バッチが落ちたとき、再実行してよいか | 運用グループ（手順書で決めておく） |
| 業務の判断 | 判定が出ない朝、同梱物を入れて出荷するか、入れずに出荷するか | 業務の責任者（今井課長）。事前に既定動作を決めておく |
| 止める権限 | 現場が「この箱は贈り物のはず」と気づいたとき、その箱を抜いてよいか | 現場に委譲する範囲を承認者が決める |
シナリオ
あなたは株式会社ノヴァストア EC事業本部・販促システム部の MOpsチームマネージャー・宮田（Day004〜Day016の続き）。
2028年6月22日（木）。Day016のテスト計画書の確認会（6/21）で、受入テストは案B（無作為300件の目視）に決まりかけている〔Day016。決まらなければ6/22 12:00に案B〕。7/3（月）から、夏のレビュー依頼カードの同梱が始まる。同梱の判定は、夜間バッチで行う。22:00に注文を取り込み、2:00に判定し、5:30に納品書の印字データができ、7:00から印字、8:00に倉庫の出荷作業が始まる〔仮定: 倉庫システムの現行の時刻割〕。1日約925箱が対象〔導出: Day015〕。
判定のバッチを運用するのは情報システム部 インフラ運用グループ（夜間は委託の監視センターがアラートを受ける）で、判定ルールを作ったのは開発の長谷川さん、同梱物を決めるのはMOps、現場で箱に入れるのは物流。つまり、一つの機能に4つの組織が触る。ところが、運用グループは同梱物のことも「贈り物」の意味も知らない。
- 提出: 6/22（木）17:00 までに村上さん・今井課長・長谷川さんへ。運用確認会は 6/26（月）15:00（30分）。受入テスト6/27〜28、判定会6/29、本番反映6/30夜、同梱開始7/3
- 読み手: 村上さん（情報システム部 インフラ運用グループ・リーダー。新登場。夜間の呼び出しを受ける側で、自分のグループが何を判断させられるかを気にしている）、今井課長（朝の出荷の責任者）、長谷川さん（判定の中身の担当）
- カタログの主な読み手（運用チーム）が、今回の1周目のレベル（他部署）とそのまま一致する。ルール5の工夫は不要
- 制約: 現行の夜間バッチの失敗は過去12か月で6回〔実測: 長谷川さんの運用記録。シナリオ内〕。新しい判定の工程を足すので、同じ程度の頻度で失敗すると置く〔仮定〕。運用グループの夜間対応は手順書にある操作の範囲内（再実行は1回）で、判定の中身や出荷の可否には関与しない〔仮定: 運用グループの慣行〕
読み手プロファイル
| 項目 | 内容 |
|---|---|
| 誰が読むか | 村上さん（情報システム部 インフラ運用グループ・リーダー）。今井課長（物流本部 出荷管理課長）、長谷川さん（開発リード）も読む |
| 何を判断するために読むか | 村上さん: 運用グループが夜間の呼び出しをどこまで受けるか、運用を引き受けてよいか。今井課長: 判定が出ない朝の既定動作と、現場に渡す「止める」権限。長谷川さん: 自分に呼び出しが来る条件 |
| 何を知っているか | 村上さん: 夜間バッチの監視と再実行の手順、委託先との契約。今井課長: 朝の出荷の流れと、4月の誤投入。長谷川さん: 判定の中身 |
| 何を知らないか | 村上さん: 「贈り物」の判定の意味、4月の誤投入の経緯、同梱物の種類。今井課長: バッチの時刻割とアラートの仕組み |
| 何を気にしているか | 村上さん: 夜間に自分のグループが業務判断を求められないか、呼び出しが増えないか。今井課長: 朝8:00の出荷が止まらないか、また誤って入れないか |
| 読む時間と場面 | 6/26の確認会の前に、紙に印刷して各自10分。会議は30分 |
この読み手が変わると何が変わるか: 読み手が長谷川さん（開発）なら、バッチの処理内容と失敗の原因の切り分けを先に書く。村上さん（運用）なら、運用グループが単独でやってよい操作の範囲と、渡す先を先に書く。今井課長（承認者）なら、朝の既定動作と、止める権限を先に書く。
4段階で見る — 「運用体制と担当分界点」
以下は同じ運用設計書の 「運用体制と担当分界点」 の部分を、4段階で書き分けたもの。
「情報システム部が行う」「関係部署と連携」で担当が空。
「適宜」「必要に応じて」、夜間の担当なし。
「詳細は運用開始までに調整」で先送り。体制・時間・障害対応・エスカレーションの型は完璧。
分担が「部品別」で、2:00の失敗は原因が分かるまで誰も動かない。
朝の出荷の判断者と、止める権限が表にない。事象ごとに「最初に動く人／単独の範囲／渡す条件」。
運用グループは再実行1回まで、と引き受けない範囲を明示。
6:30に復旧しない朝の既定動作がまだない。冒頭は「決めていただきたい2点」。
既定動作3案を「誤る箱の数・戻せるか」で比較。
決まらなければ6/27に案B、見直しの条件つき。"We will coordinate with relevant departments".
"As appropriate / as needed"; nobody owns the night.
"Details before go-live".Roles, hours, incidents, escalation all in place.
Owners by component: nobody moves at 2:00 until root cause is known.
No owner for the morning shipping call; no stop authority.Rows by event: first responder / authority / hand off.
Ops group: one re-run only; out-of-scope stated.
No default action if not restored by 6:30."Decisions requested" first.
Three defaults compared by boxes affected and reversibility.
If undecided: Option B by Jun 27; revisit triggers.5. 運用体制
本システムの運用は情報システム部が行う。
障害時は関係部署と連携して対応する。
問い合わせは各担当へ。
6. 運用時間
24時間365日。
7. 監視
バッチの稼働状況を適宜監視する。
8. 保守
必要に応じて実施する。
9. 変更管理
変更は関係者の承認を得て行う。
10. その他
詳細は運用開始までに調整する。5. Operations structure
The IT Department is responsible for operating this system.
In case of failure, we will coordinate with relevant departments.
Inquiries should be directed to the person in charge.
6. Operating hours: 24/7
7. Monitoring: batch status is monitored as appropriate
8. Maintenance: performed as needed
9. Change management: changes require approval of stakeholders
10. Other: details to be coordinated before go-live"We will coordinate with relevant departments" は、英語圏では誰も責任を持たない文として最初に指摘される。"is responsible" と "24/7" が並ぶと、夜間に人が起きて動くという約束に読まれる。
運用設計書 OP-005（第1版 2028/6/22）
4. 運用体制と役割分担
区分 担当部署 役割
インフラ・OS 情報システム部 運用G 監視、再起動、バックアップ
アプリ（判定） 情報システム部 開発G 障害調査、修正
業務運用 物流本部 出荷作業、日報の確認
マスタ管理 MOps 同梱物マスタの登録
5. 運用時間: 平日8:00〜19:00（夜間バッチは無人運転）
6. 障害対応: 重大度1〜3で区分。重大度1は1時間以内に一次対応
7. エスカレーション: 運用G → 開発G → 部長
8. 変更管理: 月1回の変更審査会で承認
9. 問い合わせ窓口: 情報システム部ヘルプデスクBadから何が変わったか:
- ①結論の位置が動いた。「誰がどの区分を持つか」が表の先頭に出た
- ④次の行動が動いた。重大度ごとの一次対応の時間と、エスカレーションの順が書かれた
- ②読み手適合が動いた。部署ごとの役割が一覧になり、運用開始前に承認をもらう形式が整った
- 運用設計書の標準の型（体制・時間・障害対応・エスカレーション・変更管理・窓口）が揃っている。社内の書式があれば、これで提出できる
まだ足りないもの（ここが今日の本題）:
- 担当が「システムの部品」で分かれている。 判定バッチが2:00に落ちたとき、インフラの故障か、判定ロジックの不具合か、データの問題かは朝になるまで分からない。分界が原因別だと、原因が分かるまで誰も動かない
- 「業務運用: 物流」は日報の確認だけで、判定が出ない朝の出荷の判断が誰にもない。 朝の出荷開始は8:00で、運用時間（8:00〜）より前に問題が起きる。無人の夜間に起きたことの判断者が、表のどこにもいない
- 「重大度1は1時間以内に一次対応」は、2:00の失敗を3:00に見る意味にしかならない。 5:30のデータ作成、7:00の印字、8:00の出荷という締切は、重大度の表に載っていない
- 村上さんの質問「夜間に自分のグループは何をするのか」に答えていない。 再実行まで受けるのか、判定の中身まで見るのかが読めない
- 「止める」権限が誰にもない。 4月の誤投入は、現場が気づいても止める権限がなかった（Day015）
Operations Design OP-005 (v1.0, 22 Jun 2028)
4. Roles and responsibilities
Area Owner Role
Infra / OS IT Dept, Operations Monitoring, restart, backup
Application IT Dept, Development Investigation, fixes
Business ops Logistics Shipping, report check
Master data MOps Register insert master
5. Hours: weekdays 8:00-19:00 (nightly batch unattended)
6. Incidents: Sev 1-3; Sev 1 first response within 1 hour
7. Escalation: Operations -> Development -> Department head
8. Change management: monthly change review board
9. Contact: IT help deskRACI（Responsible / Accountable / Consulted / Informed）の簡易版で、部品ごとの "Owner" が揃っている。ただし事象の列がなく、"unattended"（無人）の時間に何かが起きたときの Owner が表にない。
4. 運用体制と担当分界点（村上さん・今井課長・長谷川さんへ）
事象 最初に動く人 単独でやってよい範囲 次に渡す条件・渡す先
判定バッチが失敗（2:00〜） 監視センター → 運用G 手順書どおり再実行を1回 再実行が失敗 → 長谷川さん（6:00までに電話）
判定の結果が疑わしい（現場） 早番リーダー その箱を抜く（1箱単位） 同じ指摘が出た → 今井課長に当日報告
同梱物の追加・変更 宮田（MOps） マスタの登録申請 反映は長谷川さん。開始の10営業日前まで
枚数差の表示（毎シフト終了） 物流 リーダー 日報に記録 差が出たら翌朝に宮田へ
夜間の運用グループ（村上さん）の範囲: 再実行1回まで。判定の中身と同梱の可否には関与しない
時刻の締切: 5:30 印字データ／7:00 印字／8:00 出荷開始Goodから何が変わったか（★ここが今日の学習の中心）:
読み手プロファイルの各項目に、変更を1対1で対応させている。
| 読み手プロファイルの項目 | Betterで行った変更 |
|---|---|
| 村上さんが判断すること「どこまで引き受けるか」 | 分界の単位を、システムの部品（インフラ・アプリ）から、起きる事象に変えた。村上さんは、自分のグループが単独でやってよい範囲（再実行1回まで）を1行で読める |
| 村上さんが気にすること「業務判断を求められないか」 | 「判定の中身と同梱の可否には関与しない」を、表の外に1行で明示した。Goodは「情報システム部が行う」で、全部を引き受けるように読めた |
| 今井課長が知らないこと「バッチの時刻割」 | 5:30・7:00・8:00の締切を表の下に置いた。夜間のどの時刻までに何が決まっていれば、朝の出荷に間に合うかが分かる |
| 長谷川さんが気にすること「いつ呼ばれるか」 | 「再実行が失敗 → 長谷川さんに6:00までに電話」と、呼び出しの条件と期限を書いた |
| 現場の止める権限 | 「その箱を抜く（1箱単位）」を、早番リーダーが単独でやってよい範囲として書いた |
| 判定が出ない朝の既定動作 | Betterではまだ書いていない。「再実行が失敗」のあとに、6:30になっても復旧しなければ、同梱物をどうして出荷するかが空白のまま |
「部品で分ける」と「事象で分ける」: 部品で分けると、原因が分かってから担当が決まる。事象で分けると、起きたことが見えた時点で最初に動く人が決まる。夜間の障害では、原因が分かるのは朝になってからである。Googleの運用の解説も、当番が動けるためには「明確なエスカレーションの道筋」と「定まったインシデント対応の手順」が要る、と書いている。
それでも残っている問題（Bestで扱う）:
- 判定が出ない朝の既定動作がない。 6:30に復旧しなければ、誰かが判断する。その人が休みだったら、出荷は8:00に始まる
- 既定動作の選択肢が、今井課長に見えない。 入れるか入れないかで、何がどれだけ起きるのかが書かれていない
- 「止める」権限の範囲が1箱だけで、同じ誤りが続いたときの当日停止の判断者がいない
- 決まらなかったときの動きがない。 6/26に決まらなければ、7/3の運用開始に手順書が間に合わない
ここで動いた軸: ②読み手適合（部品から事象へ、村上さんの引き受ける範囲を明示）、④次の行動（呼び出しの条件と期限）。
4. Operations and handoff points (for Mr. Murakami, Mr. Imai, Mr. Hasegawa)
Event First responder Authority without escalation Hand off when
Eligibility batch fails Monitoring -> Ops Re-run once per runbook Re-run fails -> Hasegawa (call by 6:00)
Result looks wrong (floor) Early-shift lead Pull that one box Same report again -> Imai, same day
New/changed insert Miyata (MOps) Master registration request Hasegawa applies; 10 business days before start
Count gap (each shift end) Logistics lead Log in the shift report Gap found -> Miyata next morning
Night operations (Ops group): re-run once only; no involvement in rule content or insert decisions
Deadlines: 5:30 print data / 7:00 printing / 8:00 shipping starts部品でなく事象で行を立て、"Authority without escalation"（エスカレーションなしで持つ権限）の列を置いた。英語圏の運用では、権限の上限を書くのが、当番の責任を限定する型。"no involvement in ..." の否定の形で、引き受けない範囲を明示した。
6/26（月）の確認会で、村上さん・今井課長に決めていただきたいこと（2点）
① 判定バッチが6:30までに復旧しないときの、朝の既定動作（案: B）
案 既定動作 誤る箱の数（1回／年6回） 戻せるか
A 判定なしで全箱に入れる 誤って入る約74箱／約440箱 戻せない
B 判定なしなら同梱しない 入らない925箱／5,550箱 後日メールで依頼できる（会員のみ）
C 6:30に今井課長が判断する 課長が不在の日は決まらない —
② 「止める」権限（案）: 早番リーダーは1箱単位で抜く。同日に誤投入の指摘が2件で、課長が当日の残りを止める
村上さんの範囲: 再実行1回（約15分）まで。判定の中身・同梱の可否には関与しない。事象ごとの分界は 3.
決まらなかったら: 6/27（火）12:00 に宮田が案Bで手順書に反映する
見直す条件: 初月の失敗が年6回のペースを超える、または後日メールの補填が2週間で追えない場合Betterから何が変わったか:
- ①結論の位置が動いた。冒頭を「決めていただきたいこと」にし、案と推奨を先に出した
- ④次の行動が動いた。決まらなかったときの扱い（6/27 12:00）と、見直しの条件が決まった
- ③事実と解釈の分離が動いた。74箱の根拠（贈り物の割合8%＝仮定）と、5,550箱の根拠（925×6）を数字で分けた
- ⑤想定反論が動いた。案Aの「入れておけば出荷は止まらない」という反論を、戻せないの列で先回りした。案Bの「同梱を逃すと損」には、後日メールで補える範囲を書いた
今回はBestまで作るべきか: Best必要。運用の分界を決める文書で、判断者が決まっていない状態で運用を始めると、無人の夜間に起きたことの責任が誰にもなく、4月の誤投入が再発する。ただし、同梱物の2本目以降は、案Bを既定として引き継ぎ、体制の表の変更だけの「Better相当」の1枚で足りる。
Decisions requested at the June 26 meeting (2)
1. Default action if the batch is not restored by 6:30 (we recommend B)
Opt Default action Boxes affected (per event / per year) Reversible?
A Insert in all boxes, no check ~74 wrongly inserted / ~440 No
B No insert if no result 925 not inserted / 5,550 Yes, by later email (members only)
C Mr. Imai decides at 6:30 Undecided on days he is out n/a
2. Stop authority (proposal): early-shift lead pulls one box. Two wrong-insert reports in a day: Mr. Imai stops the rest of that day.
Ops group scope: one re-run (~15 min) only; no involvement in rule content or insert decisions. Per-event handoffs in section 3.
If undecided: Miyata writes Option B into the runbook by noon Jun 27.
Revisit if: failures in month 1 exceed the 6-per-year pace, or email follow-up cannot be tracked within 2 weeks."Decisions requested" で始め、案の表に "Reversible?" の列を置いた。英語圏の運用では、既定動作（default / fail-safe）を事前に決め、戻せるかで選ぶのが型。"If undecided" と "Revisit if" で、決まらないときと前提が変わったときの動きを先に書いた。
日英差分ノート
1. 日本語の「関係部署と連携して対応する」は丁寧、英語の "coordinate with relevant departments" は責任の空白
日本語の運用設計書では、「連携して対応」が協調的な表現として通る。英語では、"who pages whom, with what authority"（誰が誰を呼び、どこまでの権限を持つか）が書かれていない文は、"no owner" の宣言と読まれる。英語版は"First responder / Authority without escalation / Hand off when" の3列が必須になる。
2. 「担当」は日本語では R と A が混ざる
日本語の「担当部署」は、実際に手を動かす人（Responsible）と、結果に責任を持つ人（Accountable）を区別しない。英語の RACI では、A は1人でなければならない、が通念である（出典ページ未確認。記憶による）。今日の題材では、朝の既定動作の A は今井課長、再実行の R は運用グループと分かれる。
3. "24/7" と「24時間365日」の重み
日本語の「24時間365日」は、システムが動いている意味にも、人が対応する意味にも使われる。英語圏の運用文書では "24/7" は人が対応する約束として契約に直結するので、"unattended"（無人）と対応時間を別に書く。今日の例では、夜間バッチは無人で、運用グループの対応は手順書の範囲に限る。
頻出表現
| 日本語 | English | トーンの強さ |
|---|---|---|
| 担当分界点 | Ownership boundary / Handoff point | 中立。事象ごとに書く |
| 一次対応 | First response / First responder | 中立。範囲を限定して書く |
| エスカレーション | Escalation | 中立。条件と期限を添える |
| 既定動作 | Default action / Fail-safe default | 強い。事前に決めておく |
| 当番 | On-call | 中立。呼び出しの頻度の上限を添える |
| 関係部署と連携する | Coordinate with relevant departments | 弱い。責任の空白。承認者には出さない |
| 手順書の範囲内 | Within the runbook | 強い。権限の上限を示す |
差分5軸まとめ
| 軸 | Bad | Good | Better | Best |
|---|---|---|---|---|
| ① 結論の位置 | 「情報システム部が行う」で結論がない | 部署ごとの担当表が先頭 | 事象ごとの分界の表が先頭 | 冒頭が「決めていただきたい2点」と推奨 |
| ② 読み手適合 | 想定していない | システムの部品（インフラ・アプリ・業務） | 村上さんの引き受ける範囲（再実行1回）を明示 | 朝の既定動作と止める権限を、承認者が選ぶ形 |
| ③ 事実と解釈の分離 | 「適宜」「必要に応じて」 | 重大度の区分がある | 時刻の締切（5:30・7:00・8:00）が別に置かれた | 74箱（仮定8%）と5,550箱（925×6）の根拠を分離 |
| ④ 次の行動 | 「運用開始までに調整」 | 重大度ごとの時間 | 呼び出しの条件と期限（6:00までに電話） | 6/27 12:00の既定動作と、見直しの条件 |
| ⑤ 想定反論 | 無視 | なし | 引き受けない範囲を明示 | 案Aの「出荷は止まらない」を「戻せない」の列で先回り |
Best版・全文
日本語版 全文を見る
運用設計書 OP-005（夏のレビュー依頼カード同梱・判定バッチ） 2028年6月22日 宮田 宛先: 村上さん（情報システム部 インフラ運用グループ）、今井課長（物流本部）、長谷川さん（情報システム部 開発）
1. 6/26（月）15:00の確認会で決めていただきたいこと（2点）
① 判定バッチが6:30までに復旧しないときの、朝の既定動作（案: B）
| 案 | 既定動作 | 誤る箱の数（1回／年6回） | 戻せるか |
|---|---|---|---|
| A | 判定なしで全箱に入れる | 誤って入る約74箱／約440箱〔仮定: 贈り物8%〕 | 戻せない |
| B（推奨） | 判定なしなら同梱しない | 入らない925箱／5,550箱 | 後日メールで依頼できる（メール会員のみ） |
| C | 6:30に今井課長が判断する | 課長が不在の日は決まらない | — |
② 「止める」権限（案）: 早番リーダーは1箱単位で抜く。同日に誤投入の指摘が2件で、課長が当日の残りを止める。
2. 夜間の時刻割と締切 22:00 注文取込 → 2:00 判定 → 5:30 印字データ完成 → 6:30 復旧の期限（過ぎたら既定動作） → 7:00 印字 → 8:00 出荷開始
3. 事象ごとの分界点
| 事象 | 最初に動く人 | 単独でやってよい範囲 | 次に渡す条件・渡す先 |
|---|---|---|---|
| 判定バッチが失敗（2:00〜） | 監視センター → 運用グループ | 手順書どおり再実行1回（約15分） | 失敗 → 長谷川さんに6:00までに電話。6:30で復旧しなければ既定動作（案B）に自動で切り替え |
| 判定の結果が疑わしい（現場） | 早番リーダー | その箱を抜く（1箱単位） | 同日に2件 → 今井課長が当日の残りを止める判断 |
| 同梱物の追加・変更 | 宮田（MOps） | マスタの登録申請 | 反映は長谷川さん。開始の10営業日前まで。反映前に試験用の1本で確認 |
| 枚数差の表示（毎シフト終了） | 物流 リーダー | 日報に記録 | 差が出たら翌朝に宮田へ |
4. 引き受けない範囲: 村上さんの運用グループは、判定の中身と同梱の可否には関与しない。夜間の対応は、再実行1回までとする。 5. 決まらなかったら: 6/27（火）12:00 に宮田が案Bで手順書に反映する。 6. 見直す条件: 初月（7/3〜8/2）の判定バッチの失敗が年6回のペース（月0.5回）を超える、または案Bで同梱を逃した購入者への後日メールの補填が2週間で追えない場合。
English 全文を見る
Operations Design OP-005 (Summer review-request card insert: eligibility batch) 22 June 2028 Miyata To: Mr. Murakami (IT Operations), Mr. Imai (Logistics), Mr. Hasegawa (IT Development)
1. Decisions requested at the June 26 (Mon) 15:00 meeting (2)
1. Default action if the batch is not restored by 6:30 (we recommend B)
| Option | Default action | Boxes affected (per event / per year) | Reversible? |
|---|---|---|---|
| A | Insert in all boxes without a check | ~74 wrongly inserted / ~440 (assumes 8% gift orders) | No |
| B (recommended) | No insert if there is no result | 925 not inserted / 5,550 | Yes, by later email (members only) |
| C | Mr. Imai decides at 6:30 | Undecided on days he is out | n/a |
2. Stop authority (proposal): the early-shift lead pulls one box at a time. Two wrong-insert reports in one day: Mr. Imai stops the rest of that day.
2. Nightly timeline 22:00 order import -> 2:00 eligibility -> 5:30 print data ready -> 6:30 restore deadline (default action after this) -> 7:00 printing -> 8:00 shipping starts
3. Handoff points by event
| Event | First responder | Authority without escalation | Hand off when |
|---|---|---|---|
| Eligibility batch fails (from 2:00) | Monitoring center -> Ops | One re-run per runbook (~15 min) | Re-run fails -> call Hasegawa by 6:00. Not restored by 6:30: switch automatically to Option B |
| Result looks wrong (floor) | Early-shift lead | Pull that one box | Two in one day -> Imai decides to stop the rest of the day |
| New/changed insert | Miyata (MOps) | Master registration request | Hasegawa applies; 10 business days before start; verified with one trial insert first |
| Count gap (each shift end) | Logistics lead | Log in the shift report | Gap found -> Miyata next morning |
4. Out of scope for Operations: Mr. Murakami's group has no involvement in rule content or insert decisions. Night work is limited to one re-run. 5. If undecided: Miyata writes Option B into the runbook by noon Jun 27 (Tue). 6. Revisit if: batch failures in month 1 (Jul 3 - Aug 2) exceed the 6-per-year pace (0.5 per month), or email follow-up for customers who missed the insert cannot be tracked within 2 weeks.
完成の定義チェックリスト
運用設計書を出す前に必ず確認する。「雑・妥協」を防ぐための外部基準。1つでも未チェックがあれば、まだ出さない。
今日の演習
Bad例の「5. 運用体制」の3行だけを、村上さん向けに書き直す。条件は2つ。①「判定バッチが2:00に失敗した」という1つの事象について、最初に動く人・単独でやってよい範囲・次に渡す先と条件を1行ずつ書く。②村上さんのグループが関与しないことを1行、否定の形で書く。
読み手を変えて、同梱物の2本目（9月の誕生月クーポン）の運用設計書の「体制と分界点」を書く。 読み手は、CSの松本リーダー（クーポンの誤配布の問い合わせを受ける側）。条件: ①Day017のB案を雛形にするが、既定動作は「判定が出ないときクーポンを配らない（戻せる）」と「配る（戻せない、費用が出る）」の2案にして、費用の根拠を〔仮定〕で置く。②「止める」権限を、CSが1件で受付停止を決められる範囲にするか、課長判断にするかで比べる。③運用グループが関与しない範囲を3つ書く。
取り組む前のヒント
- 先に「戻せるか」を決める。戻せない側が誤ったときの重さで、既定動作の向きが決まる
- 分界は起きた事象から立てる。原因（インフラかアプリか）は朝にならないと分からないので、原因別に分けない
- 罠: 「運用グループが全部見る」を安心だと思わない。引き受けられない範囲まで書かれた運用設計書は、受け入れてもらえない
- 罠: 「24時間365日」を書くときは、人が対応するのか、システムが動くだけなのかを分けて書く
実務での使いどころ
運用設計書は、システム設計書・テスト計画書（Day016）の後、本番稼働の前に置かれ、運用部門が「引き受ける」ことの根拠になる。ここで決めた分界は、次の文書にそのまま入る。Runbook（IT-運用・セキュリティ#2）は、今日の「再実行1回（約15分）」の手順を、深夜に未経験の当番が実行できる形にする続編にできる。監視設計・アラート設計（#3）は、2:00の失敗を検知する閾値と通知先を決める。SLO（#4）は、「6:30までの復旧」を目標値として扱う。業務側が運用を他部署に渡すときの型として、基幹システムの更新、新サービスの開始、委託先への運用移管で転用できる。
この回の設計メモ（迷った他案・扱わなかった範囲・出所）
迷った他案と採らなかった理由
- RACI表を中心にする案 — RACIは「誰が」を揃えるが、夜間に誰も動かない問題には効かない。事象ごとの「最初に動く人／単独の範囲／渡す条件」の方が、運用する人が読んで動ける。RACI は日英差分ノートで「R と A の混在」を示すのにとどめた
- 読み手を長谷川さん（開発）にする案 — 開発は判定の中身を知っていて、味方に近い。Lv2の「他部署で、業務を知らず、引き受ける側」である村上さんの方が、「引き受けない範囲」を明示する意味が大きい
- 既定動作を案A（判定なしでも入れる）にする案 — 出荷は止まらず、同梱漏れは0。ただし誤って入る約440箱／年は戻せない。4月の誤投入（約720箱）の再発に近い。前提（メール会員の割合、贈り物の割合）が変わったら推奨は変わる。会員への後日メールで補えない購入者が多い場合は、案Cか案Aに寄る
- 既定動作を案C（課長の判断）にする案 — 課長が不在・休暇の日に決まらず、出荷が8:00に判定なしで始まる。人の判断に依存する既定は既定ではない
- Betterで3案（A/B/C）まで出す案 — Bestとの差がなくなるため、Betterは「事象別の分界と、引き受けない範囲」にとどめた
- 監視項目・バックアップ・DR・セキュリティを本体に入れる案 — 勝負どころ（分界点）が薄まるため扱わなかった
扱わなかった範囲
- 監視項目の閾値・アラートの設計（IT-運用・セキュリティ#3 に回した）、手順書の本文（#2）、SLO（#4）、バックアップ・災害復旧、アクセス権・セキュリティ（#6〜8）
- 委託先の監視センターとの契約・SLA、オンコールの人員計画・手当
- 同梱物の2本目以降の運用（Better相当の1枚で足りると本文に記した）
数字と概念の出所
- 会社・人物・日付はすべて架空。〔実測〕は Day015〜016 までのシナリオ内の数字（1日約925箱、4月の誤投入約720箱、現行の夜間バッチ失敗 年6回＝長谷川さんの運用記録）。〔仮定〕は置いた値（時刻割 22:00/2:00/5:30/7:00/8:00、再実行約15分、贈り物の割合8%、運用グループの夜間の権限の範囲、同日の誤投入の指摘2件で当日停止）
- 計算は作成時に Python で行った〔導出〕: 925×8%＝74箱、74×6＝444箱（約440）、925×6＝5,550箱。曜日（6/22木・6/26月・6/27火・6/29木・7/3月）は作成時に確認した
- 当番が動けるには「明確なエスカレーションの道筋」と「定まったインシデント対応の手順」が要る: Google SRE Book "Being On-Call"。https://sre.google/sre-book/being-on-call/ （2026-10-01 扱いの作成時にページを取得して確認。1シフトのインシデントは12時間で2件までが目安、という記述も同ページ。本文では使っていない）
- RACI で A（Accountable）は1人、という通念、"24/7" が契約上人の対応を意味する、"coordinate" が責任の空白に読まれる、は一般的な実務知識として書いた。出典は確認していない（記憶による）
- 分量（行数）は、各コードブロックの行数を作成後にスクリプトで数えた実測値
何が起きているか:
これは怠慢ではなく、「運用は情報システム部の仕事」という社内の通念から生まれる形である。書き手には全員の顔が見えているが、読み手（村上さん）には、自分が何を引き受けるのかが見えない。