このユニットの結論
「絶対に止まらないこと」は、そのままでは要件になりません。満たしたかどうかを確かめる方法がなく、かける費用にも上限がないからです。
「止まりにくくする目標」と「止まったときに業務を続ける方法」の2つに分けて決めることで、確かめられて、費用とつりあう要件になります。
1. 何の話か
このユニットは、STAGE 06「壊れることを前提に設計する」のまとめです。
要件を決める場で、業務の側から「このシステムは絶対に止まっては困る」という声が出ることはよくあります。その気持ちはもっともです。しかし、この言葉をそのまま要件の一覧に書いても、作る人も、テストする人も、何をすればよいか分かりません。
2. なぜ必要か
「絶対に止まらない」をそのまま受け取ると、
- どこまで作れば満たしたと言えるかが決まらず、テストで確かめられない
- 止まりにくくする仕組みに、際限なく費用をかけることになる
- 「止まらない前提」なので、止まったときの備えが考えられていない
ということが起きます。最後の点がいちばん危険です。どんなに備えても、システムはいつか止まります。
3. このユニットで分かること
- 「絶対」が要件にならない理由
- 費用と止まりにくさのつりあいの考え方
- 止まったときに業務を続ける方法
- この判断で、AIに任せてよいことと人間が決めること
4. 「絶対」が要件にならない理由
要件は、満たしたかどうかを確かめられる必要があります。
- 「1年間止まらなかった」ことは、1年たたないと分からない
- テストで一度も止まらなくても、本番で止まらない証明にはならない
- 機器の故障、処理の誤り、連携先の停止、災害など、止まる理由は多く、すべてを防ぐことはできない
そこで実務では、「絶対に止まらない」という願いを、
という、確かめられる目標に言い換えます。
5. 費用とのつりあい
止まりにくくする方法には、たとえば、同じ仕組みを2つ用意して片方が止まっても動き続けるようにする（冗長化）、離れた場所に予備を置く、などがあります。どれも費用がかかり、止まりにくくするほど費用は急に増えていくのが一般的です。
つりあいを考えるときは、次の2つを比べます。
| 比べるもの | 考えること |
|---|---|
| 止まったときの損失 | 業務が止まる時間の長さ、取引先への影響、期限に間に合わない影響、信用 |
| 止まりにくくする費用 | 仕組みを作る費用、動かし続ける費用、保守の手間 |
損失より費用が大きいなら、止まりにくくするより、止まったときの備えにお金を使う方がよい場合があります。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- 売上高 約5,000億円、従業員 約4,000名
- 大規模基幹システム刷新、約36本のシステム連携
- M18 本番稼働、M21 初期安定化完了
アステリア案件で「止まらないこと」をどの業務にどこまで求めたか、止まりにくくする仕組みの有無、止まったときの業務の続け方は、正本に記載がありません。未確定 会社の規模が大きいことは、すべての業務に最高水準が必要という意味ではありません。
6. 止まったときに業務を続ける方法
止まりにくくすることと同じくらい大切なのが、止まったときに業務をどう続けるかを決めておくことです。一般的な方法の例です。
- 手作業で代わりをする：決めた様式の紙や表計算で受け付け、戻ったあとにまとめて入力する
- できることを減らして続ける：見るだけはできる、急ぎのものだけ受け付ける、など
- 後回しにする：止まっている間は受け付けず、戻ったら順に処理する。その間の問い合わせへの答え方を決めておく
- 知らせる：誰が、社内と取引先に、何を、どの方法で知らせるかを決めておく
どの方法も、止まってから考えたのでは間に合いません。手順と担当を決め、使う人が練習しておきます。障害のときの対応の決めごとは OPS-004 障害対応計画、大きな障害や災害のときの計画は OPS-008 災害復旧計画・訓練結果 にまとめます。
7. THINK — 「止まらない仕組みを入れたので、手作業の手順は要らない」
（教材上の例）受注の業務について、止まりにくくする仕組みを入れることが決まりました。そのあと、業務の担当から次の声が出ました。
「止まらない仕組みを入れたのだから、止まったときの手作業の手順を作る必要はないですよね。」
問題
手作業の手順づくりを省いてよいでしょうか。
判断例を開く
判断
省くべきではありません。
確認すること:
- 入れた仕組みは、どんな止まり方に備えたものか（機器の故障だけか、処理の誤りや連携先の停止にも効くか）
- 仕組みが働かない止まり方が起きたとき、業務はどうなるか
- 手作業の手順を、最低限どこまで作っておくか（受け付けの様式、戻ったあとの入力の担当）
- 手順を、使う人が一度は試しているか
止まりにくくする仕組みは、止まる回数を減らしますが、ゼロにはしません。止まったときの備えは別に持ちます。
8. よくある失敗
- 「絶対に止まらない」を、そのまま要件の一覧に書く
- 費用を見ずに、すべての業務に最高水準を求める
- 止まりにくくする仕組みを入れたことで、止まったときの備えを作らない
- 手作業の手順を作ったが、使う人が知らない・試していない
9. 成果物との接続
- REQ-003 非機能要件一覧：「止まらない」という願いを、業務ごとの確かめられる目標に言い換えて管理する
- OPS-004 障害対応計画：止まったときの体制と、業務を続けるための決めごとを示す
- OPS-008 災害復旧計画・訓練結果：大きな障害のときの計画と、訓練で確かめた結果を残す
10. AI WORKFLOW — 止まったときの続け方の案を広げさせる
指示例:
「次の業務について、システムが止まったときに業務を続ける方法の候補を、手作業で代わりをする・できることを減らす・後回しにする・知らせる、の観点で挙げてください。どの方法を採るかは決めないでください。業務の担当に確かめる質問も添えてください。」
11. REVIEW — AIの案を確認する
- AIの案が、実際の業務の流れで使えるか、業務の担当に確かめたか
- 取引先や法令の期限への影響が抜けていないか
- AIが、止まってよい時間や費用の水準を決めていないか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 稼働率の数字と、直列の掛け算
稼働率を時間に直す
「99% 動く」は、年に約 3.7 日止まってよい、という意味です。99.9% なら年に約 8.8 時間、99.99% なら年に約 53 分です。小数点以下の 9 が 1 つ増えるごとに、必要な仕組み（二重化、切り替えの自動化、訓練）と費用は大きく増えます。「絶対に止まらない」は、この表のどこにも書けません。
直列は掛け算になる
利用者が業務を終えるまでに、認証、連携の基盤、業務のシステムを順に通るなら、全体の稼働率は各部品の掛け算です。99.9% の部品が 3 つ直列なら、全体は約 99.7% になり、年に約 26 時間です。全体の目標は、部品の目標より高くはなりません。目標を決めるときは、経路上の部品をすべて数えます。
計画停止を含めるか
夜間の更新作業で止める時間を「停止」に数えるかどうかで、数字は大きく変わります。先に定義を決めておかないと、あとで「約束と違う」になります。
要件の書き方を変える
「絶対に止まらない」の代わりに、「止まったら何分で、誰が、どの手順で戻すか」と「その間、業務はどう続けるか」を要件にします。この形なら、費用と釣り合わせて決められます。
現場で確かめる問い
- 稼働率の目標は、年間の止まってよい時間に直すと何時間か。関係者がその時間を知っているか
- 利用者が業務を終えるまでに通る部品をすべて数え、直列の掛け算をしたか
- 計画停止を「停止」に含めるかどうかが、要件に書かれているか
- 「止まったら何分で、誰が、どう戻すか」が、止まらないことの代わりに要件になっているか
アステリア案件の稼働率の目標と、計画停止の扱いは、正本に記録がありません。記録なし
12. 人間が判断すること
- どの業務に、どこまで止まりにくさを求めるか
- 止まりにくくする費用と、止まったときの損失のどちらを受け入れるか
- 止まったときの業務の続け方と、その担当
13. 判断演習
業務の責任者から「うちの業務は絶対に止めないでほしい」と言われました。
この要望を、確かめられる要件に言い換えるために、責任者に聞く質問を3つ書いてください。そのうち1つは、止まったときの業務の続け方に関する質問にしてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
「絶対に止まらない」は、確かめられる目標と、止まったときの業務の続け方の2つに分けて要件にします。
止まりにくくする費用と、止まったときの損失を比べて、業務ごとに水準を決めます。