BCP支援システムの発注は、発注形態を選び、要件をRFPにまとめて候補を比べ、有事のシナリオで確かめてから契約する流れで進みます。その前に、どこまでを自社で判断し、どこを委託するかを決めておくと、稼働後の責任分担も明確になります。
▼全体ガイドの記事
・BCP支援システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
BCP支援システムの発注・外注の全体像

BCP支援システムの発注は、安否確認SaaSを契約するだけの購買とは性質が異なります。危機管理ポータルやDR基盤を含めるかによって、発注形態や委託範囲が変わります。また、何を自社で判断し、何を委託するかが曖昧なまま進むと、稼働後に責任の所在が分かりにくくなります。
発注形態の種類(SaaS利用/開発委託/一括委託)
発注形態は、社内の体制と導入のスケジュールに合わせて選びます。主な違いは次の3つです。
- SaaS利用:安否確認SaaSをそのまま使います。
- 開発委託(追加開発):SaaSに独自の連携や機能を加えます。
- 一括委託:BCP計画の策定からシステム開発まで、まとめて任せます。
一括委託は、BCP専任担当が少ない企業でも進めやすい一方で、委託先への依存度が高くなります。SaaSのみであれば、運用の主導権を持ちやすい反面、独自要件への対応力には限りがあります。
発注前に整理すべき前提情報
発注先によって提案の範囲がばらつかないよう、相談の前に次の前提をまとめておきます。
- 対象範囲:対象人数・拠点数と想定する災害シナリオ。
- 復旧要件:重要業務のRTO・RPO。
- 既存環境:連絡網や人事データの状態。
- 法令要件:介護・医療分野の計画・訓練・記録、業務継続計画未策定減算への対応など。
総務・情シス・現場のどこが窓口となり、稼働後は誰が運用するかも、発注の前に決めておきます。発注を担当する人と運用する人が異なる場合は、両者を早い段階から発注の流れに加えることで、引き継ぎの漏れを防げます。
発注時に想定しておきたい主な悩み
担当者が抱えやすい課題をRFPに書いておくと、それを候補企業への質問に変えられ、比較の材料になります。
- 要件と責任分担:要件の定め方や、情シス・総務・リスク管理・現場の責任分界が曖昧。
- 連絡網と操作:異動で連絡網が古くなり、平時に操作へ慣れにくい。
- 有事の利用:災害時にSaaSや通信が使えるか不安。
- 審査と費用:個人情報や位置情報の審査、年間運用費・訓練費が見えにくい。
悩みをすべて自社だけで解決しようとせず、発注先が持つ知見も引き出します。
BCP支援システムの発注の進め方

発注は、要件を整理してRFPを作るところから始まり、候補を選んで比べ、契約へ進みます。工程ごとの目安を踏まえて準備しておくと、スケジュールを組み立てられます。
- 要件整理とRFP作成に1〜2か月。
- 発注先候補の選定・ヒアリングに1か月。
- 提案・見積もり比較・契約に1か月程度。
このスケジュールはひとつの参考値です(出典: 安否確認・BCP支援システムのRFP作成に関する公開情報、2026年確認)。
RFP作成・要件整理フェーズ
各社が同じ前提で提案できるよう、RFPには機能・運用の要件と現在の課題を具体的に書きます。
- 対象と復旧:人数・拠点、重要業務のRTO・RPO。
- 機能と連携:通知チャネル、連携先の既存システム。
- 非機能要件:可用性、同時アクセス数、バックアップ、権限管理。
- 法令と課題:介護・医療の計画・訓練・記録要件や現状の悩み。
人事異動による連絡網の劣化、操作への不慣れ、災害時のSaaSや通信への不安も共有しておくと、実態に即した提案を引き出せます。
BCP義務への対応はシステムの完成で終わらないため、どこまで支援を受けるかを発注先と確認しておきます。
コンペ・見積比較フェーズ
有事に必要な動作を確かめるため、候補企業には通信断や管理者不在などの場面を実演してもらいます。
- 通信断:通知の再送がどう行われるか。
- 管理者不在:代替権限へ切り替えられるか。
- 大量アクセス:同時アクセス時にどう処理するか。
- データ復元:復元にかかる時間。
画面が動くかどうかだけで判断せず、機能・実績・費用・サポート体制も比べます。特に個別開発が中心の提案では、追加費用・期間・稼働後の保守負担まで評価します。一方で、標準機能で対応できる範囲が広い候補は、稼働後の改修負担を抑えやすい傾向があります。
契約・移行フェーズ
稼働後の対応漏れや移行時の混乱を防ぐため、契約書に支援・障害対応・データ移行の条件を明記します。
- サポート:有事の対応時間と障害報告のルール。
- データ:取り扱い、契約終了時の返却・移行支援。
- 乗り換え:連絡先の移行方法と移行中の並行運用。
契約後も、要件定義の内容と設計・開発の間にずれが出ていないかを、定期的に確認します。
対象人数や拠点数が発注時から変わった場合は、契約と費用への影響を早めにベンダーへ確認しておくのが望ましいです。
費用相場と契約形態
契約形態によって、費用の発生の仕方や変更への柔軟性が変わります。そのため、要件が固まった部分と変更が起きやすい部分を分けて考えます。
請負・準委任・SaaS利用の使い分け
委託する業務の性質に合わせて契約方式を選びます。判断の基準になるのは、要件の確定度と、変更の起きやすさです。
- 請負:要件と成果物が明確な開発部分に適する場合があります。
- 準委任:要件整理や運用支援など、変更が起きやすい業務に適する場合があります。
- SaaS利用:規約、サービスレベル、データ保管場所を確認します。障害通知、バックアップ、料金改定、終了時の返却も確かめます。
方式を一つに統一せず、企画・開発・運用の性質に合わせて契約を使い分けます。
BCP計画の策定コンサルティングは、システム開発と別の準委任契約になることが多く、計画書や訓練記録などの文書が成果物の中心です。そのため、開発の請負契約と混同しないよう、契約書を分けて管理することをおすすめします。
費用相場の目安
ここに示すのは、公開情報から見える現実的な費用の幅です。安否確認SaaSのみの場合と、危機管理ポータルやDR基盤まで含めた独自開発・連携開発を委託する場合とでは、費用の水準が異なります。
- 安否確認SaaS:初期費用0〜30万円程度、月額5,000円〜数十万円程度。
- 小規模MVP:独自開発・連携開発の委託で300万〜600万円程度。
- 中規模:独自開発・連携開発の委託で600万〜1,500万円程度。
- 大規模・高可用性構成:独自開発・連携開発の委託で1,500万〜3,000万円以上となる場合があります。
保守費は、初期開発費の年15%前後を仮置きして比べる目安があります。そのうえで、保守費を含む複数年の総額を提示してもらうと、稼働後の予算を立てやすくなります。
委託先選定と見積比較のポイント

委託先は価格だけで決めず、実災害や訓練での稼働実績、運用体制も含めて判断します。
委託先選定の比較項目
同じRFPを使い、次の項目を横並びで比較します。
- 実績と対応:実災害・訓練の稼働実績、SLA、障害時の連絡体制。
- 復旧と連携:データセンターの分散、復元実績、人事・SSO・既存BCP文書との連携。
- 導入後の支援:導入支援、訓練、保守の体制。
- 総額と委託方法:5年間の総額と、計画策定・開発を別発注するか一括委託するか。
候補には、安否確認SaaSに強い会社と、基幹システムの可用性向上やDR基盤に強い会社があります。そのため、安否確認・危機管理ポータル・DR基盤のどこを求めるかに応じて、候補企業を変えることも検討します。
見積比較で確認すべき項目
見積もりの妥当性を判断できるよう、費用項目と工数を分けて提示してもらいます。
- 要件定義・設計・開発:工程ごとの費用と工数。
- 利用・連携:SaaS利用料、API・データ連携、データ移行。
- 運用準備:テスト、訓練支援、保守・運用。
「一式」の見積もりや、前提条件の記載がない見積もりは、追加費用が発生しやすいため注意が必要です。不明な点は、提示の段階で前提を書面で確認しておきます。
契約時に確認すべきリスク
BCP支援システムの契約では、有事の対応に加えて、要件変更への対応や委託の体制も確かめておく必要があります。
- 変更と遅延:要件変更への対応方法と遅延時の責任分担。
- 委託体制:再委託先の有無と管理体制。
- 障害対応:連絡フローと復旧目標。
- データと審査:個人情報・位置情報のセキュリティ、終了時の返却・移行支援。
個人情報や位置情報を扱うため、セキュリティ審査に通らないという悩みも多く聞かれます。そのため、審査に必要な資料や体制を、事前にベンダーへ確認しておきます。
2026年公表のガイドラインは、調達先の役割やサプライチェーンを確認する材料になります(出典: 経済産業省・内閣官房国家サイバー統括室「サイバーインフラ事業者に求められる役割等に関するガイドライン」、2026年)。
よくある質問(FAQ)
発注形態や委託範囲について、判断の基準とあわせて回答します。
BCP支援システムはどこまで外部に委託できますか?
安否確認・通知・掲示板の運用や、システム開発・保守は外部に委託できます。一方で、重要業務の優先順位や復旧の意思決定、連絡ルールの最終判断は自社が担います。そのため、発注の前に双方の責任範囲を分けておきます。
発注から稼働までどのくらいの期間がかかりますか?
発注準備は、要件整理・RFP作成に1〜2か月、候補選定・ヒアリングに1か月、提案・見積比較・契約に1か月程度が目安です。
開発期間は、小規模MVPで2〜4か月程度、中規模で4〜8か月程度、大規模・高可用性構成では8か月〜1年超が目安です。
複数のベンダーに分けて発注することはできますか?
分割発注は可能で、一般的です。安否確認・一斉通知は専業のSaaS、拠点・人事連携や危機管理ポータルの開発は別の会社、基幹システムの可用性向上はDR・HA基盤に強いベンダーへ、それぞれ依頼できます。
分けて発注する場合は、各社の役割と障害時の連絡フローを、契約書と運用手順の両方で明確にしておく必要があります。
コンペで確認すべき最も重要なポイントは何ですか?
通信断や未回答、管理者不在、データ復元など、有事のシナリオを実演してもらうことが、最も大切な確認点です。平時のデモでは、災害時に必要な機能や運用の不足が見えにくく、稼働後になって気づく場合があります。
まとめ
発注では、自社が決める事項と委託範囲をまず明確にします。そのうえで、RFPには人数・拠点、RTO・RPO、セキュリティを具体的に書いておきます。そのほか、災害時の想定や運用の取り決め、成果物の範囲も、RFPに盛り込みます。
- 災害シナリオ:想定する災害の場面。
- SLA:サービスの水準。
- 訓練:有事に備えた訓練の内容。
- 保守:稼働後の保守の範囲。
- 納品物:委託先から受け取る成果物。
有事のシナリオによる比較と契約条件の確認
コンペでは画面のデモだけで判断せず、通信断や管理者不在を想定して、各社の対応力を確かめます。契約時には、有事の支援時間や障害報告、データの返却・移行支援も取り決めます。
発注の段階から、人事異動による連絡網の更新や災害シナリオの見直し、訓練と改善を含む運用体制について、委託先とすり合わせておきます。そうしておくと、BCP支援システムを長く使い続けるための前提が整います。
▼全体ガイドの記事
・BCP支援システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。
