ベンダーから受領した提案書に「冗長構成オプション」という行があり、それを入れるか入れないかで見積総額が数百万円変わります。上司から「冗長化は入れておいたほうがいいのか」と聞かれ、はじめて自分も判断の根拠を持っていないことに気づく——システム刷新の発注を初めて担当する場合、こうした状況に置かれる方は多いはずです。
冗長化とは、ひとことで言えば「障害が起きても業務を止めないために、予備を用意しておく設計」です。言葉の意味だけなら難しくありません。しかし発注の現場で本当に困るのは、意味ではなく「自社はどの水準まで冗長化すべきか」という判断です。
判断できない理由は、知識不足ではなく順序が逆になっていることにあります。先に構成案と金額が提示され、それを見てから必要性を考えようとするからです。冗長化の水準は、本来は自社の業務から決まります。「この業務は何時間止まっても耐えられるか」を先に決めれば、必要な構成方式は絞られ、費用がどこで増えるのかも説明できる形になります。社内にインフラの専任者がいなくても、この順序であれば発注者自身で決められます。
本記事では、冗長化とは何かという用語の整理から始めて、構成方式ごとの「止まらない範囲」と費用の違い、稼働率を1段上げると費用が増える理由、自社の許容停止時間を決める手順、そして提案書・見積書で確認すべき5つのポイントと発注先への質問例までを順に解説します。提案書を読む側の意思決定に絞るため、サーバーの設定値やネットワーク機器の冗長化手順といった実装者向けの内容は扱いません。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
冗長化とは｜冗長性・二重化・バックアップとの違いを発注者目線で押さえる
提案書には冗長化・冗長性・二重化・バックアップといった言葉が混在します。これらが整理できていないと、ベンダーとの会話で「何にいくら払っているのか」が噛み合いません。まずは社内で説明できる粒度に揃えます。
冗長化・冗長性とは｜「手段・状態・結果」の関係で整理する
3つの言葉は、同じことを別の角度から言っています。
- 冗長化: 予備の機器や経路を用意する「手段」。設計・構築の行為を指します
- 冗長性とは: 1つ壊れても機能が維持される「状態」。冗長化の結果として備わる性質です
- 可用性: システムが使える状態を保てている度合いという「結果」。稼働率という数値で表されます
つまり「冗長化という手段で冗長性という状態を作り、その結果として可用性（稼働率）が上がる」という関係です。提案書の「可用性を高めるため冗長構成を採用」は、「稼働率を上げるために予備を持つ設計にした」という意味になります。
押さえておきたいのは、冗長化の目的が「壊れないようにすること」ではない点です。機器はいずれ壊れる前提に立ち、壊れたときに業務が止まらないようにするのが冗長化です。壊れにくい高性能な機器を1台買うのは、別の対策にあたります。
冗長化と二重化の違いは「何重にするか」だけ
冗長化と二重化の違いは、対立する概念の差ではありません。二重化は冗長化の一形態で、「2つ用意する」という数を示した言葉です。3つ以上なら多重化と呼びます。
用語 | 意味 | 使われ方 |
|---|---|---|
冗長化 | 予備を用意する設計全般 | 構成方式を問わず使える総称 |
二重化 | 2つ用意する冗長化 | 業務システムで最も一般的な水準 |
多重化 | 3つ以上用意する冗長化 | 金融・社会インフラなど停止が許されない領域 |
発注の実務では、二重化（2系統）で足りるケースが大半です。提案書に「多重化」と書かれていて金額が大きい場合は、なぜ2つでは不足と判断したのかを確認する価値があります。
冗長化とバックアップの違いは「守る対象」と「時間軸」
冗長化とバックアップの違いは、提案書を読むうえで最も重要な区別です。「バックアップを取っているなら冗長化は不要ではないか」と考えがちですが、守るものが違います。
- 冗長化が守るのは「業務の継続」: 機器が壊れた瞬間に予備へ切り替わり、業務を止めずに済みます。守る時間軸は「今この瞬間」です
- バックアップが守るのは「データ」: 誤削除・改ざん・ランサムウェア被害などで失われたデータを、過去の時点の状態に戻せます。守る時間軸は「過去に遡る」方向です
重要なのは、この2つが互いを代替しないことです。冗長化していても、誤って削除したデータは予備側にも反映されるため戻せません。逆にバックアップがあっても、復旧には数時間から1日の作業がかかり、その間は業務が止まります。つまり両方必要です。提案書でどちらかしか言及がない場合は、もう一方の扱いを確認してください。
冗長化の構成方式と、稼働率を上げると費用が増える理由
提案書の「Active-Standby」「Active-Active」「マルチAZ構成」といった表記は、ほぼ2つの基本形のどちらか、またはその組み合わせです。選び分けの軸は「止まらない範囲」「切替にかかる時間」「平時に使われない資源の量」の3つです。
アクティブ・スタンバイ型｜予備は待機するだけの冗長化構成
冗長化の構成方式のうち、最も基本となる形です。稼働中の本番系（アクティブ）と、待機する予備系（スタンバイ）を用意します。平時は本番系だけが仕事をし、障害が起きたときに予備系へ役割を引き継ぎます。
予備系は本番系と同じ構成を持つため、切り替わった後の性能は原則変わりません。構成が理解しやすく、障害時の挙動も読みやすい方式です。一方で平時は予備系の資源がまるごと遊びます。サーバー2台分の費用を払って、処理能力は1台分しか使えていない状態です。処理能力を倍にする必要がない社内の業務システム・基幹システムでは、この方式が選ばれやすくなります。
同時稼働型（アクティブ・アクティブ）｜複数を同時に動かして負荷を分ける
複数の系統を同時に稼働させ、処理を振り分ける方式です。平時から全系統が仕事をしているため、資源が遊びません。1系統が落ちても残りが処理を引き受けるので、切替作業そのものがほぼ発生しません。
ただし設計は複雑になります。どちらの系統で処理しても同じ結果になるようデータを同期する仕組みと、振り分けの制御が必要で、その設計・検証の工数が初期費用に乗ります。また1系統が落ちた状態では残りに全負荷がかかるため、性能を落とさないには各系統に余裕を持たせる必要があり、その余裕分も費用になります。利用者数の増減が大きいサービスや社外向けのWebサービスで選ばれやすい方式です。
なお予備系の持ち方には「常に同じ状態で動かし続ける」「最小限の起動状態で待たせる」「停止させておく」という温度差があり、切替時間と月額費用がこれで変わります。選び分けはホットスタンバイとコールドスタンバイの違いで切替時間とあわせて整理しています。また、障害を検知して予備系へ役割を移す動作は「フェイルオーバー」と呼ばれます。動作の仕組みはフェイルオーバー（自動切り替え）の仕組みを参照してください。
稼働率99.9%の年間停止時間｜「9の数」が1つ増えると何が変わるか
提案書の稼働率「99.9%」「99.99%」は、年間や月間でどれだけ停止を許容するかという意味です。差が0.09ポイントしかないように見えますが、許容停止時間は桁で変わります。計算式は「対象期間 ×（100% − 稼働率）」です。年間（365日＝8,760時間）で換算すると次のようになります。
稼働率 | 年間の許容停止時間 | 月あたりの許容停止時間 | 感覚的な目安 |
|---|---|---|---|
99% | 約87.6時間 | 約7.2時間 | 年に3日以上止まってもよい |
99.9% | 約8.76時間 | 約43分 | 年に1営業日ぶん止まってもよい |
99.99% | 約52.6分 | 約4.3分 | 気づかれる前に復旧する必要がある |
99.999% | 約5.3分 | 約26秒 | 人が操作して間に合う水準ではない |
ここに費用が増える理由が表れています。99.9%なら、障害を検知してから人が手順書に沿って切り替えても許容時間内に収まる可能性があります。しかし99.99%では年間52分しか止められず、人の判断を挟む余地がありません。検知と切替を自動化し、それが確実に動くことを定期的に検証する体制が必要になります。つまり「9の数」を1つ増やす要求は、予備機を増やすだけでなく、自動化の仕組みとそれを維持する運用体制を買うという意味になります。
この構造はクラウド事業者の保証水準にも現れています。Amazon Web Services の Compute SLA では、単一のEC2インスタンスに対する月間稼働率の保証は99.5%ですが、同一リージョン内の2つ以上のアベイラビリティゾーンに配置した場合のリージョン単位の保証は99.99%とされています（Amazon Compute Service Level Agreement）。提案書の「マルチAZ構成」は、この99.99%の保証を得るための配置を指します。1台構成のままでは、事業者側も99.5%以上を約束していません。
なお、ルーターやスイッチといったネットワーク機器の冗長化や、ディスク・ロードバランサの設定レベルの話は、発注者の意思決定には必要がないため本記事では扱いません。
冗長化で費用はどこが増えるのか｜初期費用・月額・運用保守の内訳
「冗長構成オプション +○○万円」という一行を分解できる状態にします。費用は必ず次の3区分に分かれます。
- 初期費用: 設計・構築・切替テストの工数
- 月額: サーバー・ストレージ・ライセンス・監視の継続費用
- 運用保守費: 切替訓練・手順書の維持・障害対応体制
提案書では1と2が分けて書かれていても、3が抜け落ちているケースが目立ちます。各区分に何が乗るのかを押さえます。
冗長化の費用｜初期費用に乗るもの
初期費用で増えるのは、ほぼ人件費（工数）です。機器が2台になるから倍、という単純な話ではありません。
- 設計工数: どのレイヤーをどこまで冗長化し、障害時にどう切り替わるかを設計します。1台構成では存在しない検討項目です
- 構築工数: 予備系の構築に加え、データを同期する仕組み・障害を検知する仕組み・切り替える仕組みの構築が増えます
- 切替テスト工数: 最も見落とされる項目です。本番系をわざと止めて予備系に切り替わることを確認し、切り替わった後に業務が正常に行えるかを検証します。シナリオの作成・実施・結果の記録が必要で、設計次第ではまとまった工数になります
初期費用が「サーバー1台ぶんの金額」よりはるかに大きくなるのは、この工数が乗るためです。逆に、見積の冗長化オプションが機器代相当しか積まれていない場合は、テストの工数が含まれていない可能性があります。
月額に乗るもの｜クラウドとオンプレミスで課金単位が違う
月額は、予備系を「どう持つか」で大きく変わります。
項目 | クラウドの場合 | オンプレミスの場合 |
|---|---|---|
サーバー | 起動時間に対して課金。停止させておけば抑えられる | 購入・リース費用が発生し、稼働の有無で変わらない |
ストレージ | 容量に対して課金。予備系ぶんが継続的に乗る | 購入時に確定 |
ソフトウェアライセンス | 製品により、待機系にも必要な場合がある | 同様に製品の条件を確認する |
監視 | 監視対象の台数・項目数で変わる | 監視ツールのライセンスと運用工数 |
データ転送 | 系統間のデータ同期で転送量が増える場合がある | 原則として発生しない |
クラウドには「予備系を停止させておけば月額を抑えられる」という選択肢があります。ただし停止中の予備系は障害時に起動と設定が必要なため、切替時間が長くなります。ここが月額と許容停止時間のトレードオフです。もう一つ確認すべきはライセンスの扱いです。待機しているだけの予備系にも必要な製品があり、見積から漏れていると後から月額が上振れします。
構成方式別・冗長化の費用の増え方の比較
金額は案件の規模・既存環境・採用製品で大きく変わるため、ここでは「どの区分がどの程度増えるか」という構造として示します。
区分 | 冗長化なし（1系統） | アクティブ・スタンバイ型 | 同時稼働型 |
|---|---|---|---|
初期費用（設計・構築） | 基準 | 増加（予備系＋切替の仕組み） | 大きく増加（同期・振り分けの設計） |
初期費用（切替テスト） | ほぼ不要 | 増加（切替シナリオの検証） | 増加（片系統停止時の性能検証も） |
月額（サーバー・ストレージ） | 基準 | 予備系ぶん増加（停止運用で抑制可） | 全系統が稼働するため増加 |
月額（ライセンス・監視） | 基準 | 対象台数ぶん増加 | 対象台数ぶん増加 |
運用保守費 | 基準 | 増加（切替訓練・手順書維持） | 増加（複数系統の状態管理） |
平時に遊ぶ資源 | なし | 予備系ぶんが遊ぶ | ほぼなし（負荷を分散できる） |
障害時の停止時間 | 復旧作業の時間がそのまま停止 | 切替にかかる時間だけ停止 | ほぼ停止しない |
読み方のポイントは、同時稼働型が「月額の効率は良いが初期費用と設計の難易度が高い」側に寄り、アクティブ・スタンバイ型がその逆になることです。したがって「どちらが安いか」に一般的な答えはありません。利用期間が長ければ月額の効率が効き、短期間であれば初期費用の差が効きます。提案書を比較するときは、初期費用と月額を合わせ、想定利用年数（たとえば5年）での総額で並べてください。
見落としやすい運用保守費
運用保守費は、提案書で最も曖昧になりやすい区分です。冗長構成を入れると、次の継続的な作業が増えます。
- 切替訓練: 切替の仕組みは定期的に動かして確かめなければ、「障害時に動かなかった」という結果になりかねません。年1回などの頻度で実施します
- 手順書の維持: システムに変更を加えるたび、切替手順書も更新が必要になります
- 障害対応体制: 稼働率99.99%を求めるなら、夜間・休日に検知して対応する体制が前提になります。この費用は構成の設計費とは別です
- 監視項目の追加: 予備系が正常に待機しているか、データ同期が遅れていないかを監視する項目が増えます
これらが作業範囲に含まれていない場合、「構成は冗長化されているが、切替が本当に動くかは誰も確認していない」という状態になりえます。費用を検討する際は、作らせる費用と維持する費用を分けて確認してください。
許容停止時間の決め方｜冗長化の必要性を業務から逆算する
ここまでの内容から、構成方式と費用は「許容停止時間」という一つの入力で決まることが分かります。そしてこの入力は、自社の業務を知っている発注者だけが決められる値です。逆に、ここを決めずに提案を受けると、ベンダーは安全側に倒した構成を出すしかなく、見積は高くなります。
まず業務を「止めてはいけない範囲」に切り分ける
全社システムをひとまとめに「止めてはいけない」と考えると、必要以上に大きな構成になります。最初にやるべきは業務の切り分けです。内閣府の事業継続ガイドラインでも、すべての業務を対象にするのではなく重要業務を特定して目標復旧時間を設定する手順が示されています。冗長化も同じ考え方で絞り込めます。次の問いで振り分けてください。
- 止まると社外に影響が出るか: 受注受付・出荷指示・顧客向けサービスなど、取引先や顧客に直接影響する業務
- 止まると法令・契約上の問題になるか: 期限のある申告・報告、SLAを結んでいるサービス
- 止まっても代替手段があるか: 紙やメール、表計算ソフトで一時的に回せる業務
- 止まっても後でまとめて処理できるか: 日次・月次のバッチ処理、社内申請の承認など
前2つに該当する業務だけを対象に絞ると、構成も費用も現実的な規模に収まります。
許容停止時間とデータの戻り幅を業務単位で決める
絞り込んだ業務ごとに、2つの値を決めます。
- 許容停止時間: 「何時間止まったら業務が破綻するか」。目標復旧時間（RTO）と呼ばれます
- データの戻り幅: 「どの時点までデータが残っていれば業務を再開できるか」。目標復旧時点（RPO）と呼ばれます
この2つは別の値です。受注システムなら「4時間以内に動けばよいが、受注データは1件も失えない」という組み合わせがありえ、停止時間には余裕があってもデータ同期には厳しさが要求されます。逆に社内の分析ツールなら「半日止まってよく、データは前日のバックアップまで戻ってよい」となり、冗長化そのものが不要になるかもしれません。
決め方のコツは、時間を先に決めず「止まったときに何が起きるか」から積み上げることです。1時間止まったら何件の受注が受けられないのか、半日止まったら出荷がどれだけ遅れるのか。この損失の見通しが、経営層に費用を説明する根拠にもなります。2つの指標の違いと数値の置き方はホットスタンバイとコールドスタンバイの違いでも整理しています。
許容停止時間から構成方式を対応づける
許容停止時間が決まれば、構成方式はおおむね対応づけられます。
許容停止時間 | 対応する構成の目安 | 想定される費用の方向 |
|---|---|---|
半日〜1日止まってよい | 冗長化なし＋バックアップ復旧。または予備系を停止させて持つ | 初期・月額ともに抑えられる |
数時間以内に戻したい | アクティブ・スタンバイ型（予備系を待機させる） | 初期費用が増え、月額は持ち方で調整 |
数十分以内に戻したい | アクティブ・スタンバイ型＋自動切替（稼働状態で待機） | 月額が増え、切替の構築費が乗る |
実質的に止めたくない | 同時稼働型（複数系統・複数拠点） | 初期・月額・運用保守のすべてが増える |
重要なのは、この対応づけを業務ごとに行うことです。全業務を最上段に合わせると費用は跳ね上がりますが、受注受付だけを最上段にし分析ツールを最下段にすれば総額は大きく変わります。提案書を受け取る前に振り分け表を作っておけば、ベンダーに「この業務はこの水準で設計してほしい」と指定できます。
冗長化のメリット・デメリット｜見送る・最小構成にしてよい判断基準
冗長化を入れないという判断も、根拠があれば正当な選択です。メリットは、障害時に業務が止まらない、復旧作業の切迫度が下がる、取引先への説明責任を果たしやすいという点です。デメリットは、初期費用・月額・運用保守費のすべてが増える、構成が複雑になって障害原因の切り分けが難しくなる、切替の仕組み自体が故障点になりうるという点です。次のいずれかに該当する場合は、見送るか最小構成にする判断を検討してよいと考えられます。
- 社内利用のみで、止まっても代替手段がある: 紙やメール、表計算ソフトで一時的に業務を回せる場合
- 停止による損失が、冗長化の費用を明確に下回る: 5年間の費用増分と想定停止損失を並べて比較します
- 稼働時間が限られている: 平日日中のみ稼働し、夜間に復旧作業ができる場合
- バックアップと復旧手順の整備が済んでいない: 冗長化より先に、データを確実に戻せる状態を作るほうが効果が大きい場合があります
この判断は文書に残しておいてください。「検討の結果、この業務は半日の停止を許容すると決めた」という記録があれば、障害が起きたときも経緯を説明できます。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
提案書・見積書で確認すべき5つのポイント
自社の許容停止時間が決まったら、提案書・見積書を点検します。確認すべき5点について、「何が書かれていれば良いか」と「書かれていない場合に何を疑うか」をセットで押さえてください。
冗長化の見積で最初に見る点｜どのレイヤーまで冗長化されているか
システムはWebサーバー・アプリケーションサーバー・データベース・ストレージといった複数の層で構成されます。このうち1箇所でも予備がなければ、そこが壊れた時点で全体が止まります。予備のない箇所を単一障害点と呼びます。
書かれていれば良いこと: 構成図上で、どの層が何重になっているかが読み取れること。冗長化していない層については、その理由が添えられていること。
書かれていない場合に疑うこと: 「サーバーを冗長化」とだけ書かれ、データベースやストレージの扱いが示されていない場合。データベースの冗長化は費用と難易度がともに上がるため、意図的に外されている可能性があります。外すこと自体は判断として成立しますが、共有されていないと障害時に想定外の停止が起きます。
切替は自動か手動か、切替時間の根拠が示されているか
予備系があっても、そこへ切り替わらなければ停止時間は短くなりません。
書かれていれば良いこと: 切替が自動か手動かの明示と、切替にかかる想定時間。そしてその根拠（検知・起動・確認作業それぞれの時間の内訳）。
書かれていない場合に疑うこと: 「冗長構成により速やかに復旧」といった表現のみで時間が示されていない場合。手動切替では、担当者が障害に気づくまでの時間と作業に着手できるまでの時間が停止時間に加算されます。夜間や休日の想定も含めて確認してください。切替動作の仕組みはフェイルオーバー（自動切り替え）の仕組みで整理しています。
冗長化部分の初期費用と月額が内訳として分離されているか
書かれていれば良いこと: 増える金額が初期費用と月額に分かれ、さらに初期費用は設計・構築・テスト、月額はサーバー・ストレージ・ライセンス・監視の内訳が示されていること。
書かれていない場合に疑うこと: 「冗長構成オプション 一式 ○○万円」という一行だけの場合。一式表記では他社と比較できず、構成を一段落としたときにいくら下がるのかも分かりません。内訳を求めれば、「データベースは冗長化せずバックアップ対応にすれば○○万円下がる」といった調整の余地が見えてきます。
切替テスト・定期訓練が作業範囲に含まれているか
書かれていれば良いこと: 構築時の切替テストが作業範囲に含まれ、シナリオ（どの機器を止めて何を確認するか）が示されていること。稼働後の定期訓練についても頻度と費用の扱いが示されていること。
書かれていない場合に疑うこと: 構築範囲にテストの記載がない場合。切替は一度試してみるまで動くかどうか分かりません。また定期訓練が保守契約に含まれていないと、年を追うごとに「切替が動くか誰も分からない構成」になります。
稼働率の数値がどの範囲に対する保証なのか
同じ「稼働率99.9%」でも、何に対する保証なのかで意味が変わります。
書かれていれば良いこと: 対象範囲（どのサーバー・どのサービスまでか）、測定方法（何をもって停止と数えるか）、計算期間（月間か年間か）、除外される事象（計画停止・天災・利用者側のネットワーク障害など）。
書かれていない場合に疑うこと: 数値のみが示されている場合。「サーバーが応答していれば稼働中とみなす」定義なら、画面が表示されないのに稼働率は100%と計算されえます。計画停止が除外されている場合は、その回数と時間の上限も確認が必要です。この定義と条項化の進め方はSLA・SLOの条項設計で整理しています。
発注先への質問例｜冗長化の要件定義でそのまま使える確認リスト
発注の各タイミングで使える文例をまとめます。要件定義の前に自社から伝えること、提案を受けた後に聞くことを分けて示します。
冗長化の要件定義の前に自社から伝えること
「冗長化はどうしますか」と聞かれる前に、次の3点を文書で渡してください。これだけで提案の精度が変わります。
- 対象業務の一覧と優先順位: どの業務が止まると社外に影響が出るか。前述の振り分け表をそのまま渡せます
- 業務ごとの許容停止時間: 「受注受付は2時間以内、在庫照会は半日以内、分析機能は翌営業日まで」といった形
- 業務ごとのデータの戻り幅: 「受注データは1件も失えない」「在庫データは当日朝の状態まで戻ってよい」といった形
この3点があれば、ベンダーは過不足のない構成を設計できます。渡さない場合は安全側に倒した一律の構成が提案され、不要な費用が乗ります。
提案を受けた後に聞くこと
提案書を受領したら、次の質問をそのまま投げてください。
- 構成図のうち、冗長化されていない箇所（単一障害点）はどこですか。そこが故障した場合、業務はどれくらい止まりますか
- 切替は自動ですか手動ですか。手動の場合、障害検知から業務再開までの想定時間を、作業の内訳で教えてください
- 夜間・休日に障害が起きた場合の対応開始までの時間は、保守契約のどの条件に基づきますか
- 冗長化によって増える金額を、初期費用（設計・構築・テスト）と月額（サーバー・ストレージ・ライセンス・監視）に分けて教えてください
- 構成を一段簡素にした場合（たとえばデータベースを冗長化せずバックアップ対応にした場合）、金額と停止時間はどう変わりますか
- 構築時の切替テストは作業範囲に含まれますか。シナリオと確認項目を教えてください
- 稼働後の定期的な切替訓練は、保守契約に含まれますか。含まれない場合の費用を教えてください
- 提示された稼働率は、どの範囲を対象に、何を停止と数えて、どの期間で計算した数値ですか。除外される事象を教えてください
- 待機系にもソフトウェアライセンスは必要ですか。必要な場合、見積に含まれていますか
回答の良し悪しを見分ける着眼点
返ってきた回答を評価する際は、内容の技術的な正しさを判断しようとしなくて構いません。次の3点が示されているかだけを見てください。
- 前提条件が明示されているか: 「○○という前提のもとで」と条件が添えられている回答は、検討された内容です。条件なしの断定は、確認されていない可能性があります
- 除外範囲が示されているか: 「この範囲は対象外です」と自ら示す回答は信頼できます。すべてを保証するような回答のほうが、むしろ注意が必要です
- 費用の区分が分かれているか: 初期費用・月額・運用保守費が分けて説明されるか。一式でまとめられる場合は、内訳を再度求めてください
まとめ｜「止めてはいけない範囲」を決めてから構成と費用を選ぶ
冗長化とは、障害が起きても業務を止めないために予備を用意する設計です。構成方式にはアクティブ・スタンバイ型と同時稼働型があり、稼働率を1段上げるという要求は、予備機を増やすだけでなく自動化の仕組みと運用体制を買うことを意味します。だからこそ費用が桁で変わります。
判断の順序は次の4ステップです。
- 止めてはいけない業務を絞り込む: 止まると社外・法令上の影響が出る業務だけを対象にする
- 業務ごとに許容停止時間とデータの戻り幅を決める: 停止したときに何が起きるかから積み上げる
- 許容停止時間に対応する構成方式を選ぶ: 半日許容なら冗長化なし、数時間ならアクティブ・スタンバイ型という対応づけで絞る
- 提案書の5点を確認する: 冗長化されていない箇所、切替方式と時間の根拠、費用の内訳、テストと訓練の範囲、稼働率の定義
この順序で進めれば、経営層への説明も「受注業務は2時間以上止められないため、この構成を選び、その差額はこの内訳です」という形になります。提案書の金額を見てから必要性を考えるのではなく、自社の業務から水準を決めて提案を評価してください。これが発注者の側で持てる最も強い判断材料になります。
まずは、自社のシステムで扱っている業務を書き出し、「止まると社外に影響が出るか」で振り分けてみてください。それが次の打ち合わせでベンダーに渡す最初の資料になります。
関連情報
冗長化オプションの金額を含めて、システム開発の見積全体をどう読み解くかを整理したい場合は、システム開発の費用を正しく理解するガイドブックもご活用ください。費用の内訳の考え方や、見積比較時の着眼点をまとめています。無料でダウンロードいただけます。
自社システムの冗長構成の水準や、受領した提案書の妥当性についてご相談されたい場合は、お問い合わせフォームからご連絡ください。許容停止時間の整理といった、要件が固まる前の段階からご相談いただけます。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 社内にインフラ担当がいなくても、冗長化の水準は自分で決められますか？
決められます。構成の技術詳細を理解していなくても、業務ごとの許容停止時間とデータの戻り幅さえ決めれば、見積依頼の前に必要な構成方式が絞れるため、まず止まると社外や法令に影響する業務だけを書き出してください。
- ベンダーの冗長構成の見積が高いと感じたとき、削ってよい部分はどこですか？
止まっても代替手段がある業務や半日止まってよい業務は、冗長化せずバックアップ復旧で対応する余地があります。ただし切替テストや定期訓練を削ると冗長化が機能しないため、まず「一式」表記の内訳を求めてください。
- バックアップを取っていれば、冗長化は不要ではありませんか？
目的が違うため代替になりません。バックアップは誤削除やランサムウェアでのデータ復元に、冗長化は機器故障時に業務を止めないために使うもので、許容停止時間が数時間以内なら復旧に時間がかかるバックアップだけでは足りません。
- 経営層に冗長化の追加費用を説明するには、何を示せばよいですか？
「業務が止まったときの損失見込み」と「冗長化の5年間の費用増分」を並べて示すのが有効です。たとえば受注業務が2時間止まったときの機会損失と、初期費用・月額・運用保守費の合計額を並べて比較してください。
- 稼働率99.9%と99.99%は、どちらを選ぶべきか迷ったらどう決めますか？
年間の許容停止時間で判断します。99.9%は約8.8時間、99.99%は約53分で、後者は自動切替と夜間対応の運用体制が前提になり費用が桁で上がるため、業務が耐えられる停止時間から逆算して選びましょう。
