3-1変更管理
日曜の夜10時、ミナトは予約システムを作った業者と電話をつなぎ、予約画面に「受け取り時間を選ぶ」欄を足す変更を本番に入れました。動作を一度だけ確かめて、その夜は眠りました。月曜の朝6時半、店の電話が鳴ります。「予約画面が開かない」という電話が、カフェから二軒続きました。店長は受話器を置くと、ミナトに聞きました。「昨日の変更を元に戻す？ それとも、このまま直す？」。ミナトはその問いに答えながら、別のことを思い出していました。先週の水曜にも、一軒のカフェで同じように画面が開かなかったのです。そのうえ夕方のニュースは、週の後半に台風が近づくと伝えていました。
店長の問いには、すぐに答えが出ました。カフェの注文の締め切りは朝7時です。原因が分からないまま直そうとすれば、7時の締め切りに間に合う保証はありません。日曜の変更より前の状態なら、少なくとも予約は受けられていました。変更や新しい版を入れたあとに問題が起きたとき、入れる前の状態に戻すことをロールバック（切り戻し）といいます。業者に頼んで受け取り時間の欄を外した版に戻すと、6時50分、三軒とも予約画面が開くようになりました。
戻せたのは、運がよかったからです。日曜の夜、戻し方を誰も決めていませんでした。業者が前の版を残していなければ、戻す先がなかったことになります。変更そのものに問題があったとは限りません。変更を入れる手順のほうに、確かめる所が抜けていました。
サービスに手を加えるときに、変更の申し出を記録し、影響を見積もってから承認し、計画どおりに入れ、結果を確かめるまでを決まった手順で進める活動を変更管理と呼びます。目的は、変更をやめさせることではありません。カフェに新しい便利さを届けながら、届けている途中のサービスを止めないことです。手順の中には、失敗したときに戻す方法を前もって決め、できれば試しておくことも入っています。
ここから基本情報！変更の申し出と、変更の分類
変更管理は、変更の申し出を形にするところから始まります。何を、なぜ、いつまでに変えたいのかを書いて出す正式な申し出が変更要求（RFC：Request for Change）です。カフェから「受け取り時間を選びたい」と頼まれたとき、ミナトが業者に電話で伝えたのは、まだ変更要求ではありませんでした。紙に書いて残していれば、誰が、どの変更を、どの理由で頼んだのかを後から追えます。
変更要求はどれも同じ重さではありません。毎月の価格表の差し替えと、予約画面の作りを変える工事を、同じ手続きで扱うのは無駄でもあり、危なくもあります。そこで、危険の大きさや急ぎの度合いによって変更を分けたものを変更のカテゴリーといいます。分け方の代表は、次の四つです。
| 分類 | どんな変更か | こむぎ堂の例 |
|---|---|---|
| 標準変更 | 危険が小さく手順が決まっているので、前もって承認したものとして扱える | 月初めの価格表の差し替え |
| 通常の変更 | 標準変更にも緊急変更にも当たらず、そのつど評価と承認を経る | 受け取り時間の欄を足す |
| プロジェクト変更 | プロジェクトとして計画を立てて進める規模の変更 | 土曜の配達を始め、予約の仕組みを作り直す |
| 緊急変更（緊急の変更） | 障害への対応などで急ぐため、手続きを短くして入れる | 月曜の朝、前の版へ戻す |
緊急変更は、手続きを省いてよいという意味ではありません。承認する人の数や時間を減らしても、誰が許可したか、何を変えたかは記録に残し、落ち着いてから振り返ります。プロジェクト変更は、標準変更・通常の変更・緊急変更の三つに比べると挙げられることの少ない分類で、どの範囲をこう呼ぶかは組織によって違います。
通常の変更をどう承認するかを決めるとき、一人の判断だけでは見落としが出ます。変更の内容と危険を評価し、承認するかどうかについて助言する集まりが変更諮問委員会（CAB：Change Advisory Board）です。こむぎ堂なら、店長、ミナト、業者の担当者の三人で十分です。受け取り時間の欄を足す変更を三人で見ていれば、「戻し方は？」「試したのは一軒分の画面だけ？」と、誰かが聞いたかもしれません。
変更を入れたら、それで終わりにはしません。申し出から承認、実施、結果までの経過を書き残したものを変更記録といいます。そして実施のあとに、変更がねらいを果たしたか、思わぬ影響が出ていないかを評価するのが変更実施後のレビュー（PIR：Post Implementation Review）です。月曜の朝の出来事は、まさにこのレビューで扱う題材です。
基本情報の範囲ここまで
月曜の昼、店長とミナトは日曜の変更をやり直すと決めました。受け取り時間を選びたいというカフェの頼みは、そのまま残っているからです。ただし今度は、申し出を書き、戻し方を決め、試してから入れます。
3-2新規サービスの計画と設計
火曜の閉店後、ミナトは相棒に聞きました。「受け取り時間の欄を足すだけなのに、何を決めておけばよかったんだろう」。相棒は聞き返します。「その欄で、カフェは何ができるようになる約束だった？ それが守れたと、どうやって確かめる？」。ミナトは答えに詰まりました。
受け取り時間の欄を足すことは、画面に欄を一つ増やす作業に見えます。カフェの側から見ると違います。「朝7時までに頼めば、選んだ時間に届く」という約束が一つ増えるのです。約束が増えるなら、増やす前に、何を約束するのか、どこまでできたら使い始めてよいのかを決めておく必要があります。
新しいサービスや変更したサービスを、カフェや店に受け入れてもらってよいかを判断するために、前もって決めておく条件をサービス受入れ基準といいます。こむぎ堂なら、「三軒のどのカフェの画面でも受け取り時間を選べる」「選んだ時間が配達表に正しく載る」「予約画面が開くまでの時間が今と変わらない」といった条件です。日曜の変更は、この基準がないまま入れたので、一軒分の画面が開いたことで「できた」と判断してしまいました。
ここから基本情報！計画と設計の文書
新しいサービスや、影響の大きいサービスの変更は、変更管理の手続きに加えて、設計から移行までを一続きの活動として管理します。これをサービスの設計及び移行と呼びます。最初の仕事は、何を、誰が、いつまでに、どの資源で行い、どんな危険があり、何をもって受け入れるかを書いた新規サービス又はサービス変更の計画を立てることです。受け取り時間の欄なら、業者の作業日、カフェへの知らせ方、戻し方、受入れ基準までが一枚にまとまります。
計画が決まったら、サービスの要求を満たすように仕様を決め、作れる形にまで具体化します。この工程が設計・開発です。設計で決めたことは、要件、システムの構成、運用の手順などを含めてサービス設計書に書き残します。サービス設計書には、何ができるかという機能だけでなく、画面が何秒で開くか、何時から何時まで使えるかといった、性能や使える時間などの非機能要件も書きます。日曜の変更では、この非機能の側の約束がどこにも書かれていませんでした。
基本情報の範囲ここまで
ミナトは、受入れ基準の三つの条件を紙に書いて店長に見せました。店長は三つめを指で押さえます。「画面が開くまでの時間って、月曜の朝はどれくらいだったの？」。測っていなかったので、答えられませんでした。
3-3構築と移行
水曜、業者から作り直した版が届きました。今度は、いつ入れるか、入れる前に何を試すか、カフェにいつ知らせるかを先に決めます。店長は言いました。「入れたあと毎朝の面倒を見るのは、結局わたしだからね。何を渡してもらえばいいのか教えて」。
使っている仕組みから新しい仕組みへ、データや仕事の進め方を切り替えることを移行といいます。受け取り時間の欄を足す場合でも、これまでの予約データに「受け取り時間」の項目を足す、配達表の作り方を変える、カフェの店員に使い方を伝える、という切り替えが要ります。画面を差し替えるだけでは、移行は終わりません。
ここから基本情報！作ってから切り替えるまで
設計に沿って、ハードウェアやソフトウェアを実際に動く形に組み上げる活動が構築（ビルド）です。業者が作り直した版は、この構築の成果です。組み上がったら、サービス受入れ基準を満たすかを試験で確かめます。利用者の側が、自分たちの使い方で満たせるかを確かめる試験を受入れテストと呼びます。
移行はシステムだけの話ではありません。システムの切り替えと、それに合わせた仕事の進め方の切り替えを一緒に扱うことを業務及びシステムの移行といいます。こむぎ堂の場合、配達表に受け取り時間の列が増えれば、朝のパンを袋に詰める順番も変わります。システムだけ切り替えて、詰める順番を変え忘れれば、7時半に届けるはずのパンが8時半の便に乗ることになります。
切り替えは、次の順に進めます。
| 段階 | すること | こむぎ堂の受け取り時間の例 |
|---|---|---|
| 移行計画 | 日程、手順、体制、予行演習、失敗したときの戻し方を決める | 日曜の夜10時から作業し、0時までに終わらなければ前の版に戻す |
| 移行準備 | 計画に沿って、環境・人・手順書をそろえる | 前の版の控えを取る。業者と店長の連絡先を一枚にまとめる |
| 運用テスト | 本番に近い条件で、運用の流れまで含めて動きを確かめる | 三軒分の予約を入れ、翌朝の配達表を実際に印刷してみる |
| 移行リハーサル | 本番と同じ手順を前もって試し、所要時間を測る | 試験用の環境で切り替えを通しで行い、50分かかると分かる |
| 移行判断 | 試験と予行演習の結果から、本番の切り替えをするかを決める | 受入れ基準を全部満たしたので、日曜に入れると決める |
| 移行の通知 | 切り替えの日時と中身を、関係する人全員に前もって知らせる | 三軒のカフェに「日曜の夜は10時から0時まで予約を止めます」と伝える |
| 移行実施 | 計画どおりに、実際に切り替える | 日曜の夜、手順書の順に切り替える |
移行準備と移行実施の二つは、シラバスの用語例には無く、移行の流れを段階に分けて呼ぶときに使われる語です（移行計画は用語例に挙がっています）。表の中でいちばん見落とされやすいのは、移行判断です。予行演習で50分かかると分かっていれば、0時の締め切りに対して余裕は70分です。もし予行演習で2時間かかっていたら、「日曜に入れる」とは決められません。切り替えたあとは、計画どおりに進んだか、問題が残っていないかを移行評価で確かめます。
移行の前に確かめる条件には、受入れ基準のほかに、運用する側から見た条件もあります。シラバスでは運用サービス基準という語が、構築と移行の用語例に挙がっています。毎朝の配達表が何時までに出るか、止まったときに誰が何分で動くかのように、移行のあとでサービスを毎日運用していくうえで満たしてほしい水準をまとめた基準と考えると、受入れ基準との違いが見えてきます。
基本情報の範囲ここまで
店長の「何を渡してもらえばいいのか」という問いは、切り替えが終わったあとの話です。作った人と毎日動かす人が違うとき、作った人の頭の中にしかない知識は、切り替えの夜が明けると届かなくなります。業者の担当者は月曜の朝6時半には電話に出られませんが、店長は店にいます。
ここから基本情報！作った人から使う人へ渡す
作る側や移行を担った側から、毎日運用する側へ、運用に要る情報と責任を渡すことを運用引継ぎといいます。渡し忘れを防ぐために、何を渡したかを一覧にして、渡した側と受け取った側の両方で確かめます。
引継ぎのときには、プログラムや文書のほかに、運用の手順書やマニュアル、システムの構成の情報のように、毎日の運用に使うものも渡します。店長が受け取るべきだったのは、「画面が開かないとき最初に見る所」「前の版に戻す手順」「業者の夜間の連絡先」を書いた数枚の紙でした。
基本情報の範囲ここまで
3-4リリース及び展開管理
作り直した版を入れる前の日、業者から連絡が来ました。「ついでに、配達表の文字を大きくする直しと、ログインの不具合の直しも一緒に入れていいですか」。ミナトは手元の一覧を見ます。三つの直しを一度に入れたら、何かが壊れたとき、どれのせいかが分かるでしょうか。
本番に入れるために、一つ以上の変更をひとまとめにした単位をリリースといいます。受け取り時間の欄、配達表の文字、ログインの直しの三つを一つのリリースにすることもできますし、分けることもできます。まとめれば切り替えの回数は減ります。その代わり、問題が出たときに原因の候補が三つに増え、戻すときも三つ一緒に戻ることになります。
どの変更をどのリリースにまとめ、いつ、どの順で、どう本番に入れるかを計画し、試し、実際に入れるまでを管理する活動がリリース及び展開管理です。以前はリリース管理と呼ばれることが多く、いまもこの名前で説明されることがあります。変更管理が「この変更をしてよいか」を決めるのに対して、リリース及び展開管理は「承認された変更を、どうやって本番に届けるか」を受け持ちます。
ここから基本情報！リリースを本番に届けるまで
リリースには、決めた日程で定期的に入れるもののほか、障害を止めるために急いで入れる緊急リリースもあります。こうした分け方をリリースの種類といいます。月曜の朝に前の版へ戻したのも、急いで入れたという点では緊急リリースの一つです。
リリースを本番に入れてよいかを判断するために、前もって決めておく条件がリリースの受入れ基準です。その条件を満たすかを、本番に入れる前に確かめるための試験用の環境を受入れ試験環境と呼びます。一方、カフェが実際に予約を入れている本番の環境が稼働環境（本番環境）です。日曜の夜、ミナトは稼働環境で一軒分の画面を開いて確かめました。受入れ試験環境で三軒分の予約を流していれば、月曜の朝を待たずに問題が見えたはずです。
試験を通ったリリースを稼働環境に置き、使える状態にする活動が展開（デプロイ）です。展開の中で、承認されたソフトウェアや修正のプログラムを、実際に動かす場所まで送り届ける作業を配布と呼ぶことがあります。こむぎ堂の予約システムはサーバ1台なので配布先も1か所ですが、店のレジ3台に同じ修正を入れるなら、3台すべてに届いたかを確かめるところまでが配布です。
基本情報の範囲ここまで
ミナトは業者に返事をしました。受け取り時間の欄だけを先に入れ、配達表の文字とログインの直しは次の週にまとめる。原因の候補を一つに保つほうを選んだのです。
3-5インシデント管理
あとで振り返ると、月曜の朝の30分は混乱していました。一軒目の電話は店長が取り、二軒目の電話はミナトが取り、三軒目はメールで来ていて誰も気づいていませんでした。業者に電話したのは6時45分、誰が連絡するかを決めるまでに10分かかっています。
予約画面が開かない、開くけれど遅い、配達表の時間がずれている。サービスが予定外に止まったり、質が落ちたりする出来事をインシデントといいます。まだ利用者に影響が出ていなくても、放っておけば影響が出る出来事（たとえば予備のディスクが一台壊れた）も、インシデントとして扱います。
インシデントが起きたときの目的は、原因を突き止めることより先に、サービスをできるだけ早くふだんの状態に戻し、仕事への影響を小さくすることです。この活動をインシデント管理と呼びます。月曜の朝、店長が「原因は後で調べよう、まず7時までに予約を受けられるように」と決めたのは、インシデント管理の考え方に沿っています。インシデント管理では、受け付けた出来事をすべて記録し、分類し、どれから手を付けるかを決めます。
手を付ける順番を決めるための区分が優先度です。優先度は、仕事にどれだけ大きな影響が出ているかと、どれだけ急いで直す必要があるかの二つから決めます。三軒すべてのカフェが7時の締め切りまでに注文できないという月曜の出来事は、どちらから見ても最も高い優先度です。
ここから基本情報！優先度の決め方と、解決までの目標
優先度を決める二つの材料には名前があります。サービスや仕事、利用者に及ぶ結果の大きさが影響（インパクト）、対応をどれだけ急ぐ必要があるかが緊急度です。影響と緊急度は、インシデントだけでなく、変更要求の優先度を決めるときにも使います。こむぎ堂で表にすると、たとえば次のようになります。
| 影響＼緊急度 | 高（締め切りまで1時間以内） | 低（今日中なら困らない） |
|---|---|---|
| 大（三軒とも注文できない） | 優先度1 | 優先度2 |
| 小（一軒の画面だけ文字がずれる） | 優先度2 | 優先度3 |
優先度ごとに、受け付けてから解決するまでにかけてよい時間の目標を決めておきます。これを解決目標時間といいます。「優先度1は30分以内に予約を受けられる状態に戻す、優先度3は翌営業日まで」と決めておけば、月曜の朝のように、誰が何をどこまで急ぐかで迷う時間が減ります。
基本情報の範囲ここまで
月曜の朝、ミナトは自分では直せないと分かった時点で業者に電話しました。受けた担当者だけでは解決できないとき、より詳しい人や、より権限のある人に対応を引き上げることをエスカレーションといいます。引き上げる先によって、二つに分けて呼びます。
一つは、より専門の知識や技術を持つ担当者や部署に対応を渡す機能的エスカレーションです。ミナトから業者への電話がこれに当たります。もう一つは、判断や権限が要るときに、上の立場の管理者に報告して判断を仰ぐ階層的エスカレーションです。「7時までに直らなければ、今朝の注文は電話で受けると三軒に知らせてよいか」を店長に聞いたのは、こちらでした。
ここから基本情報！原因が分からないうちの手当てと、重大なインシデント
業者が原因を調べている間も、7時の締め切りは近づきます。そこで店長は、三軒のカフェに「今朝だけは電話で注文してください」と伝え、ミナトが紙の台帳に書き取りました。このように、根本の原因は解決しないまま、影響を小さくしたり取り除いたりする一時的な手当てを回避策（ワークアラウンド）といいます。ロールバックも、原因を直したわけではないので、この朝の回避策の一つでした。
影響がとくに大きいインシデントは、ふだんの手順とは別に、前もって文書にした手順で扱います。これを重大なインシデントといい、分類し、管理し、トップマネジメント（組織をいちばん上で指揮し、管理する人や人の集まり）に知らせることが求められます。こむぎ堂なら「全部のカフェが注文できない」が重大なインシデントで、知らせる先は店長です。
対応が終わったら、何が起きて、何が原因と考えられ、どう手当てし、いつ戻ったかを文書にまとめます。この文書を障害報告書といいます。月曜の報告書には、6時30分の最初の電話、6時45分の業者への連絡、6時50分の復旧が並びました。
インシデント管理と、次の節で扱うサービス要求の管理は、どちらも利用者の連絡を受けて記録し、対応し、終える流れが似ています。規格の以前の版（JIS Q 20000-1:2012）では、二つを一つにまとめてインシデント及びサービス要求管理と呼んでいました。いまのシラバスでは、インシデント管理とサービス要求管理が別の項目に分かれています。
基本情報の範囲ここまで
3-6サービス要求管理
月曜の昼過ぎ、カフェの一軒からまたメールが来ました。ミナトは身構えて開きます。中身は「新しく入った店員にも、予約画面のIDを作ってほしい」というものでした。
電話やメールで来る連絡が、すべて障害の知らせとは限りません。IDを作ってほしい、配達先の住所を変えたい、先月の注文の明細を送ってほしい。こうした、決まった手順で応えられる利用者からの依頼をサービス要求といいます。何かが壊れたわけではないので、インシデントとは分けて扱います。
サービス要求を受け付けてから、記録し、分類し、順番を決め、応えて、終えるまでを管理する活動がサービス要求管理です。IDの発行のようによくある依頼は、手順を一枚の紙に決めておけば、ミナトでも店長でも同じように応えられます。月曜の朝、障害の電話とIDの依頼が同じ順番待ちに並んでいたら、IDの依頼が先に片づいて、障害の電話が後回しになっていたかもしれません。
ここから基本情報！依頼に応える
サービス要求管理の流れの中で、依頼されたことを実際に行って、依頼した人が求めた結果を届けることを実現と呼びます。新しい店員のIDを作り、ログインできることを確かめてカフェに伝えるまでが、この依頼の実現です。実現が終わったら、対応した結果を記録して依頼を閉じます。
基本情報の範囲ここまで
3-7問題管理
月曜の夜、ミナトは先週の水曜の記録を探しました。開かなかったのは、三軒のうち注文がいちばん多いカフェの画面だけ。そのときは、しばらくして開いたので「たまたまだろう」と片づけていました。前の版に戻した今は、三軒とも画面が開きます。それでも相棒はこう返してきました。「戻したら直った、は、原因が分かった、とは違うよね」。
インシデント管理は、サービスをとにかく早く元に戻すための活動でした。戻ったあとに残る「なぜ起きたのか」「また起きないか」を受け持つのが問題管理です。インシデントの記録や傾向を分析して、まだ分かっていない原因を突き止め、同じことが起きないように、起きても影響が小さくなるように手を打ちます。
先週の水曜と、今週の月曜は、別々の出来事として記録されていました。並べてみると、どちらも朝の注文が多い時間に、予約画面の読み込みが止まっています。インシデントを一件ずつ処理しているだけでは、この共通点は見えてきません。
ここから基本情報！問題、根本原因、既知の誤り
一件以上のインシデントの原因を問題といいます。まだ起きていない、これから起きうるインシデントの原因も含みます。問題として記録した時点では、その原因の中身はたいてい分かっていません。水曜と月曜の二件のインシデントの裏には、一つの問題があると考えられます。インシデントは「起きた出来事」、問題は「出来事を起こしている、まだ分からない原因」です。
業者が調べると、予約画面は開くたびに、そのカフェの過去の予約を全部読み込んでいました。注文の多いカフェは予約が数百件あり、読み込みに時間がかかりすぎて画面が止まります。日曜の変更で受け取り時間の項目が一件ずつに増えたため、ほかの二軒も止まる側に入ってしまったのです。表に出た症状ではなく、症状を引き起こしている元の原因を根本原因といいます。根本原因は「受け取り時間の欄」ではなく、「過去の予約を全部読み込む作り」でした。受け取り時間の欄が原因なら、先週の水曜、欄がまだ無いころに画面が止まることはなかったはずです。
根本原因が突き止められているか、サービスへの影響を小さくしたり取り除いたりする方法（回避策など）が分かっている問題を既知の誤り（既知のエラー）といいます。英語の known error の訳で、二つの呼び方があります。こむぎ堂の記録には「原因：過去の予約を全部読み込む。回避策：画面が止まったら電話で注文を受ける。恒久対策：直近の予約だけを読み込むように直す」と書きました。次に同じ症状が出たとき、誰が電話を取っても、この記録を見れば迷わずに動けます。
恒久対策は、変更要求として変更管理に回します。起きたことを繰り返さないための手当てだけでなく、まだ起きていない不具合を先回りして防ぐ手当て（予防処置）を決めるのも、問題管理の仕事です。
基本情報の範囲ここまで
インシデント管理と問題管理は、同じ出来事を別の時間の幅で見ています。インシデント管理は「今朝の7時」を、問題管理は「来週も、来月も」を見ます。月曜の朝の店長は前者を、月曜の夜のミナトは後者を受け持ちました。
3-8サービス可用性管理
火曜の朝、カフェの店主の一人が言いました。「ほかのことはいいけど、朝の6時から7時に止まるのだけは困るの」。ミナトは、この一か月で予約画面が何回止まり、そのたびに何分止まっていたのかを数えてみることにしました。
サービスが、約束した時間帯に、約束した働きをできる度合いをサービス可用性といいます。カフェにとって大事なのは、深夜に止まらないことではなく、朝の6時から7時に確実に使えることです。可用性は、約束した時間帯の中で測ります。
可用性を約束どおりに保つために、実際に使えた割合を測って記録し、目標と比べ、予定外に使えなくなったときは原因を調べて手を打つ活動がサービス可用性管理（可用性管理）です。測るときによく使う指標が三つあります。
故障から次の故障までに正常に動いていた時間の平均をMTBF（平均故障間隔）といい、長いほど故障しにくい、つまり信頼性が高いことを表します。故障してから修理を終えて使えるようになるまでの時間の平均がMTTR（平均修復時間）で、短いほど早く直せることを表します。障害が起きてから次の障害が起きるまでの時間の平均はMTBSI（Mean Time Between Service Incidents）と呼び、動いていた時間と直していた時間の両方を含みます。
ミナトが数えた30日（720時間）の記録で計算してみます。予約システムは3回止まり、止まっていた時間は合計で6時間でした。
| 指標 | 計算 | 結果 |
|---|---|---|
| MTBF | 動いていた時間 ÷ 故障の回数 ＝（720 − 6）÷ 3 | 238時間 |
| MTTR | 止まっていた時間 ÷ 故障の回数 ＝ 6 ÷ 3 | 2時間 |
| MTBSI | MTBF ＋ MTTR ＝ 238 ＋ 2 | 240時間 |
| 稼働率 | MTBF ÷（MTBF ＋ MTTR）＝ 238 ÷ 240 | 約0.992（99.2％） |
稼働率は99％を超えていて、数字だけ見れば悪くありません。それでも店主が困ったのは、3回のうち2回が朝の6時台に起きていたからです。1回に2時間かかる修理が朝の6時に始まれば、7時の締め切りには間に合いません。稼働率を上げるには、故障の回数を減らして MTBF を延ばす方法と、直す速さを上げて MTTR を縮める方法の二つがあり、こむぎ堂がまず手を付けたのは後者でした。前の版に戻す手順を紙に書いておけば、2時間の修理を10分の切り戻しに替えられます。
ここから基本情報！止まりにくさと、立ち直りの速さ
障害や妨げを受けても働きを保ち続ける力、または保てなくなっても素早く立ち直る力を回復力（レジリエンス）といいます。故障しにくさ（信頼性）と、故障しても直しやすいこと（保守性）は、どちらも回復力を支えます。
機器の故障に限らず、利用者から見てサービスが止まってから使えるようになるまでの平均の時間は平均サービス回復時間（MTRS：Mean Time to Restore Service）と呼ばれます。MTTR が修理にかかる時間を見るのに対して、MTRS は、故障に気づく、連絡する、切り替える、といった時間まで含めて、サービスとして戻るまでを見ます。月曜の朝なら、最初の電話を受けた6時30分から数えて、三軒とも画面が開いた6時50分までの20分です（電話より前から止まっていたなら、もっと長くなります）。
基本情報の範囲ここまで
3-9サービス継続管理
木曜の夕方、台風の進路が町に近づいてきました。予約システムのサーバは、店の奥の棚に1台だけ置いてあります。店長は窓の外を見ながら言いました。「停電したら、明日の朝の配達はどうなるの。カフェには約束してるんだよね」。
故障は直せば終わりますが、災害は店そのものを止めます。地震や台風、火事のような大きな出来事が起きても、サービスを約束した水準で続けられるように、あるいは決めた時間内に戻せるように、前もって備えておく活動をサービス継続管理といいます。ITILで使われてきた呼び方ではITサービス継続性管理とも呼ばれ、ITサービスを止めないための備えを企業向けにまとめた指針として、経済産業省が2008年に公表したITサービス継続ガイドラインもあります。
こむぎ堂が守りたいのは、予約システムそのものより、毎朝カフェにパンが届くことです。災害や事故で仕事が止まったときに、大事な事業を続ける、あるいは早く戻すための計画を事業継続計画（BCP：Business Continuity Plan）といいます。BCPは店全体、つまりパンを焼くこと、運ぶこと、お金を受け取ることまでを対象にします。予約システムの備えは、その一部です。
ここから基本情報！何を、どこまで、いつまでに戻すか
災害や重大な障害で中断したサービスを、あらかじめ決めた時間と水準まで再開させることを復旧といいます。台風の夜に備えるのは、この復旧を約束どおりに行うためです。
BCPのうち、ITサービスを対象に、事業が止まったときにどう続け、どう戻すかを決めた計画がサービス継続計画です。サービス継続計画は作って終わりではなく、決めた間隔で、またはサービスの環境が大きく変わったときに試験します。規格の以前の版（JIS Q 20000-1:2012）では、サービスの継続と可用性を一つの項目にまとめ、サービス継続及び可用性管理と呼んでいました。
計画を作る前に、仕事が止まったら何がどれだけ困るのか、どれくらいの間なら止まっても耐えられるのかを評価します。この分析をビジネスインパクト分析（BIA：Business Impact Analysis）といいます。内閣府の事業継続ガイドラインでは「事業影響度分析」と呼んでいます。こむぎ堂で分析すると、予約の受付が半日止まってもカフェに電話してもらえば何とかなりますが、配達表が無いと朝の配達そのものができません。
分析の結果から、三つの目標を決めます。
| 目標 | 決めること | こむぎ堂の台風の夜 |
|---|---|---|
| RTO（Recovery Time Objective：目標復旧時間） | 止まってから、いつまでに戻すか | 停電が起きても、朝5時までに配達表を出す |
| RPO（Recovery Point Objective：目標復旧時点） | どの時点のデータまで戻すか | 毎晩10時の控えの時点。10時より後の予約は失われてもよいと決める |
| RLO（Recovery Level Objective：目標復旧レベル） | 戻したときに、どの水準まで働かせるか | 予約画面は止めたまま、配達表を出すことだけを戻す |
RPOを10時にするなら、夜の10時より後に入った予約は、控えに入っていない可能性があります。そこで、締め切りを過ぎた予約は受け付けない、10時以降に入った予約は翌朝電話で確かめる、と決めておきます。三つの目標は、無理のない対策で実際に届くものでなければなりません。
BCPが事業全体を続けるための計画であるのに対して、停電や機器の故障のような不測の出来事ごとに「起きたら誰が何をするか」を決めた行動の計画をコンティンジェンシープラン（緊急時対応計画）といいます。そのうち、災害で壊れたシステムを戻し、仕事を再開させるための対策と体制をディザスタリカバリ（DR）と呼びます。
基本情報の範囲ここまで
戻すまでの時間を縮めるには、壊れたときに代わりに動く予備の機械を用意しておきます。どれだけ早く切り替えたいかで、用意の仕方が変わります。
予備の機械を用意しておくだけで、ふだんは電源も入れず、障害が起きてから起動し、設定を整え、データを入れ直すのがコールドスタンバイです。切り替えには時間がかかりますが、ふだんの手間と費用は小さく済みます。反対に、予備の機械を本番と同じように動かしておき、データも常にそろえておいて、障害が起きたらすぐに切り替えるのがホットスタンバイです。切り替えは速い代わりに、2台分の電気代と手間がかかり続けます。
ここから基本情報！中間の待ち方
二つの間にあるのがウォームスタンバイです。予備の機械を起動しておき、決めた間隔でデータを写しておくので、電源を切ってあるコールドスタンバイより早く切り替えられます。データは最後に写した時点のものになるので、写す間隔がそのまま、どの時点まで戻せるかに関わります。
基本情報の範囲ここまで
こむぎ堂が選んだのは、いちばん手間の小さい備えでした。木曜の夜10時、ミナトは翌朝分の予約の控えを取り、配達表を前の晩のうちに印刷して、店長の家にも一部置いてもらいました。予備のノートパソコンには予約システムを入れておき、電気が戻らないときは店長の家で立ち上げます。予備の機械を電源を切ったまま置いておくやり方なので、コールドスタンバイに当たります。
金曜の夜中、台風は町の上を抜け、店は4時間停電しました。土曜の朝5時、店長は前の晩に刷った配達表を手に厨房へ入り、三軒のカフェに予定どおりパンを届けました。翌週の日曜の夜には、直近の予約だけを読み込むように直した版を、試験用の環境で三軒分の予約を流して確かめてから、戻し方を書いた紙を横に置いて入れ直しました。月曜の朝6時半、店の電話は鳴りませんでした。カフェの一軒から届いたのは、受け取り時間を7時半から8時に変えたいというメールでした。サービス要求です。ミナトはそれを記録して、手順どおりに応えました。