最初に決めるのは「何時間止まったら業務が止まるか」です
稼働率の数値から決めるのではなく、どの業務が何時間止まると実害が出るかを先に洗い出し、そこから稼働率と復旧時間を逆算します。先に「稼働率99.9パーセント」のような数字を置いてしまうと、その数字が自社の業務にとって過剰なのか不足なのかを誰も判断できなくなります。
止まると困る業務を3つに絞る
最初の作業は、対象のシステムで扱う業務を並べ、止まったときに外部へ影響が出るものを3つまで選ぶことです。受注の受付、出荷の指示、請求の締めのように、相手がいる業務から選ぶと絞りやすくなります。社内の集計や閲覧だけの業務は、この段階では後回しにして構いません。
「困る」を時間で書き出す
選んだ業務について、止まってから何時間で実害が出るかを書き出します。「午前中に復旧すれば当日の出荷に間に合う」「翌営業日の朝までに戻れば締めに影響しない」といった業務の言葉のままで十分です。この時間が、後で決めるRTO (目標復旧時間) の上限になります。
復旧目標は中核業務から逆算する
この順序は、国が示している事業継続の考え方と同じです。内閣府防災の中小企業向けBCPの資料では、BCPを緊急事態に備えて事前に取り決めておく計画と説明し、従来の防災計画と比べた特徴として、中核となる事業の継続に集中することと、復旧目標時間を設定することを挙げています (内閣府防災「中小企業BCP」)。システムの復旧時間は、この中核事業の復旧目標から逆算して決める位置づけになります。
つまずきやすい点は、この洗い出しを情報システムの担当者だけで行ってしまうことです。どの業務が何時間で困るかを知っているのは現場であり、担当者の想像で埋めると、後の水準の議論がそのままずれていきます。所要時間の目安は、3業務の聞き取りと表への整理で1日です。
なお、ここで対象にしているのは社内で使う業務システムです。ホームページのリニューアルにおけるバックアップの決め方は別の記事で扱います。次の章では、書き出した時間を発注書の項目に落とすために、決めるべき4つの項目を整理します。
決めるべき項目は4つです (稼働率・RTO・RPO・運用時間)
発注時に数値で指定する項目は、稼働率、RTO (目標復旧時間)、RPO (目標復旧時点)、運用時間の4つに整理できます。前の章で書き出した「何時間で困るか」を、この4つの欄に移していく作業だと考えると進めやすくなります。
| 項目 | 何を決めるか | 書き方の例 |
|---|---|---|
| 稼働率 | 決めた利用条件のもとで使える割合 | 稼働率99パーセント |
| RTO | 障害発生から復旧までの目標時間 | 12時間以内 |
| RPO | どの時点のデータまで戻せるか | 障害発生時点 |
| 運用時間 | 利用できる時間帯と停止してよい時間帯 | 平日8時から20時、日曜深夜は保守枠 |
稼働率は何を分母にした割合か
稼働率は、利用条件を決めないと意味が定まりません。三条市が公開している非機能要件の資料では、稼働率を明示された利用条件の下でシステムが要求されたサービスを提供できる割合と定義し、例として稼働率99パーセントを挙げています (三条市「非機能要件」)。24時間を分母にするのか、営業時間だけを分母にするのかで、同じ99パーセントでも許される停止の長さが変わります。発注書には割合だけでなく、分母にする時間帯も併記します。
RTOとRPOの違い
RTOは「いつまでに動くようにするか」、RPOは「どこまでのデータを守るか」です。同じ資料では、業務停止を伴う障害時の目標として、RTOを12時間以内、RPOを障害発生時点とする記載例が示されています (三条市「非機能要件」)。RPOを障害発生時点にすると直前の入力まで守れますが、その分だけ構成と費用が増えます。1時間前までの復元で業務が回るなら、そう書いたほうが現実的です。
運用時間と保守の時間帯を分けて書く
運用時間は、使える時間帯と、更新や点検のために止めてよい時間帯の2つに分けて書きます。ここを分けずに「24時間利用」とだけ書くと、更新作業のたびに調整が必要になり、結果として更新が後回しになります。月に1回の保守枠をあらかじめ決めておくほうが、長く使うには向いています。
この4項目をどの水準に置くかは、次の章で公的な枠組みを使って決めます。
水準の目安は公的な枠組みから引けます
IPAの非機能要求グレードは非機能要求を6つの大項目に整理しており、グレード表は3つのモデルシステムごとに推奨レベルを示すため、自社がどのモデルに近いかを決めれば水準の議論が具体化します。自社だけで考えて数字を置くより、公開されている枠組みに当てはめたほうが、相手の見積もりと比べやすくなります。
6つの大項目のうち可用性と運用・保守性を見る
IPA (独立行政法人情報処理推進機構) の非機能要求グレードは、非機能要求を可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分けて整理する枠組みです (IPA「システム構築の上流工程強化 (非機能要求グレード)」)。稼働率やバックアップは、このうち可用性と運用・保守性に位置づけられます。この記事で扱うのはその2つで、表示や処理の速さについては性能・拡張性の話になるため、別の記事で扱います。
3つのモデルシステムから自社に近いものを選ぶ
グレード表は、社会的影響が殆どないシステム、社会的影響が限定されるシステム、社会的影響が極めて大きいシステムという3つのモデルシステムごとに、推奨される要求レベルを示す構成になっています (同上)。社内の数人が使う管理台帳であれば1つ目、取引先からの受注を受ける仕組みであれば2つ目が近くなります。どれに当てはめるかを先に決めておくと、稼働率や復旧時間の議論が具体的な数値に落ちやすくなります。
可用性のレベルは、冗長化の方式と復旧時間の組み合わせで段階化されています。非機能要求グレードを解説したNTTデータの技術記事では、社会的影響が限定されるシステムの例として、レベル0が非冗長化、レベル1がコールドスタンバイ、レベル2がホットスタンバイ、レベル3がデュアルシステムという段階が示され、レベル2は12時間以内の復旧、レベル3は6時間以内の復旧という目安が併記されています (NTT DATA TECH「非機能要求グレードの可用性レベルの解説」)。これは公式資料の解説であるため、実際の発注ではIPAのグレード表 (活用シート) の該当行を併せて確認することになります。
合意するのは小項目、確認するのはメトリクス
IPAの資料では、大項目が最も広い分類、中項目が検討すべき単位、小項目がユーザと開発ベンダの間で合意される項目、メトリクスが小項目を定量的に表す指標という位置づけが示されています (IPAセミナー資料)。発注側が合意の対象とすべき単位は小項目であり、見積もりや契約で数値として確認する対象がメトリクスです。打ち合わせで「可用性を上げたい」と大項目のまま話すと話が噛み合わないため、小項目まで降りてから数値を置きます。
公共調達の仕様書は、書き方の実例として使えます
自治体が公開している非機能要件の資料には、稼働率とRTO・RPOを数値で書き下した記載例があり、自社のRFPの文面の参考になります。ゼロから文章を考えるより、公開されている書き方を土台にして数値だけ差し替えるほうが早く、相手にも意図が伝わります。
稼働率の定義ごと書き写す
三条市が公開している非機能要件の資料では、稼働率を明示された利用条件の下でシステムが要求されたサービスを提供できる割合と定義し、例として稼働率99パーセントを挙げています (三条市「非機能要件」)。参考にするときは、割合の数字だけでなくこの定義の一文ごと書き写します。定義が書かれていないと、提案する側が自社に都合のよい分母で計算でき、後から「約束した稼働率は守っている」という説明が成り立ってしまいます。
障害時の目標を3点セットで書く
同じ資料には、業務停止を伴う障害時の目標として、RTO (目標復旧時間) を12時間以内、RLOを全業務、RPO (目標復旧時点) を障害発生時点とする記載例があります (同上)。RLOは、復旧した時点でどの範囲の業務が使える状態になっているかを指します。この3つを揃えて書くと、「12時間で復旧する」と言われたときに、全機能が戻るのか一部だけなのかが曖昧になりません。
- 稼働率とその定義の一文を書く
- RTO、RLO、RPOの3点を並べて書く
- 運用時間と保守の時間帯を併記する
つまずきやすい点は、公共調達の数値をそのまま自社に持ち込んでしまうことです。上の例は自治体の業務を前提にしたものであり、社内で数人が使う台帳に同じ水準を当てると、構成も費用も過剰になります。所要時間の目安は、前の章で選んだモデルシステムに合わせて数値を差し替える作業で半日です。
自社の事情に合わせて数値だけ差し替える
差し替えの判断材料は、第1章で書き出した「何時間で実害が出るか」です。翌営業日の朝までに戻れば足りる業務なら、RTOを12時間以内より緩く書いても構いません。逆に当日の出荷に間に合わせる必要があるなら、RTOを短くし、その分の構成と費用を見積もりに出してもらいます。次の章では、この文面を実際の見積もり依頼に載せる手順をまとめます。