BCP管理システム開発の発注/外注/依頼/委託方法について

BCP管理システムの発注は、現状と優先範囲を整理し、提案を比べ、契約条件を決め、訓練で見直す順に進みます。この順に進めると、有事の復旧判断を支援できるシステムに近づきます。

発注形態から委託先の選定まで、各段階で確認する内容を順に見ていきます。

▼全体ガイドの記事
・BCP管理システム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

BCP管理システムの発注前に決める全体像

発注前には、災害やサイバー攻撃の際に何を判断するのかを定義し、誰がどの情報を更新するかも決めておきます。

判断の対象と更新担当が曖昧なままだと、有事に現場が何を入力すればよいか迷いやすくなります。

BCP管理システムは、従業員の安否確認だけを扱うものではありません。むしろ、重要業務や拠点・設備を、復旧手順とあわせて継続して管理します。

安否確認システムとBCP管理システムの違い

管理する情報と発注の範囲は、目的によって変わります。

• 安否確認システム：地震や警報時の通知と、安否や出社可否の集計が中心です。
• BCP管理システム：BIA（事業影響度分析）、許容停止時間、RTO（目標復旧時間）、RPO（目標復旧時点）の管理。
• 復旧情報：必要な要員、代替拠点、設備被害、取引先の状況、復旧タスクも含みます。
• 発注範囲：安否確認が最優先ならSaaSの設定で足りる場合があります。複数拠点の統合には、追加連携や個別開発が必要です。

MUSTとWANTに分けた初期範囲の決め方

初期導入では、災害時に必要な基本機能をMUSTに置きます。一方で、将来追加できる機能はWANTに分けます。

• MUST：一斉通知、安否回答、対策本部の掲示板、従業員・拠点マスタの更新
• WANT：設備確認、在庫、サプライヤー、細かな帳票、複数言語

専任の担当者が少ない企業では、平時の連絡網の更新やアンケートにも使える範囲を優先します。また、訓練や手順書の確認も運用に含めます。

内閣府の「事業継続ガイドライン（令和5年3月）」も、計画だけでなく教育・訓練と見直しを含む継続運用を示しています（出典：内閣府、2023年）。

BCP管理システムの発注形態の選び方

初めてBCPをシステム化する企業には、既製SaaSを小さく導入し、訓練で不足を測ってから連携や個別開発を足していく方法が向いています。

独自の復旧業務や厳しい可用性要件がある場合には、パッケージ連携、スクラッチ、ハイブリッドも候補に入れて比べます。どの形態でも、有事の安定稼働と運用負荷を評価の軸にします。

既製SaaSを発注する場合

既製SaaSは、導入のしやすさと契約前の確認事項の両面から比べます。

• 導入しやすさ：通知、安否回答・集計、掲示板、アンケートを、短期間で始められます。
• 運用負担：自社で冗長化や通知集中への対策をすべて設計せずに済みます。
• 適合範囲：独自の承認経路や業務分類には限界があるため、要件との適合を確かめます。
• 契約条件：マスタ更新、データ保管場所、API、解約時のデータ返却。
• 有事の負荷：全社員が同時にアクセスした場合の動きを、訓練で検証する必要があります。

大規模訓練のあとにSaaSへ移行した事例では、課題としてアクセス集中と担当者の負荷が挙がっていました（出典：NTTドコモビジネス「大成建設株式会社」導入事例）。

パッケージに設定・連携を加える場合

連携方式を選ぶ場合は、その利点と、追加で決める事項を発注前に整理しておきます。

• 標準機能との両立：信頼性を保ちながら、自社の業務に合わせられます。
• マスタ連携：人事の異動・退職情報や拠点・気象情報を連動し、古い連絡網のリスクを減らします。
• 連携時の論点：仕様変更、項目不一致、失敗時の再送、個人情報の扱い。
• RFPの記載：API・CSV等の接続方法、更新頻度、障害時の手動運用を明記します。

スクラッチ開発を発注する場合

スクラッチ開発は、自由度と、発注者側が負う運用責任をあわせて検討します。

• 業務への適合：BIA、BCP文書の版管理、拠点被害、設備・在庫、復旧タスクに合わせられます。
• 追加機能：訓練評価や経営層向けダッシュボードも開発対象にできます。
• 有事と保守：アクセス集中、複数通信経路、バックアップ、監視、脆弱性対応、組織変更後の保守が必要です。
• 着手方法：要件未確定での大規模開発は未使用機能と追加費用を招きやすいため、要件定義や小規模PoCを先行します。

SaaSと自社ポータルを組み合わせる場合

SaaSと社内ポータルを組み合わせる場合は、役割分担、障害時の運用、契約終了時の扱いを先に決めておきます。

• SaaS側：安否確認と通知の基盤を担います。
• 社内ポータル側：BCP文書、拠点情報、復旧タスク、会議記録を管理します。
• 組み合わせる利点：通知基盤の安定性を保ち、自社の危機対策本部の画面を整えられます。
• 事前に決めること：障害時の正本、利用者認証、契約終了時のデータ移行を定めます。曖昧だと二重化や現場の混乱を招きます。

BCP管理システムを発注・外注する進め方

発注は、整理、比較、受入、訓練まで続くプロジェクトです。要件をすべて決めてから一度に渡す形では、途中で見えた課題を要件に反映しにくくなります。

社内のBCP担当と情報システム部門が、まず参加します。そのうえで、総務・人事、現場拠点、経営層も早い段階から加わります。これにより、後から重要な要件が加わる可能性を抑えられます。

現状調査と業務課題の洗い出し

現状調査では、管理資料と業務への影響を洗い出します。

• 管理資料：紙・ExcelのBCP文書、従業員・拠点・設備・取引先のマスタ
• 運用記録：連絡網と過去の訓練記録
• 業務影響：重要業務が止まると顧客や従業員へ影響する時間
• 復旧体制：復旧判断者と必要な人・データ・設備

BIAとRTO/RPOの考え方をそろえると、要件は安否確認にとどまりません。復旧判断を支える機能も、検討の対象に入ります。

2〜3社のデモと本番相当の訓練による比較

候補は2〜3社に絞り、自社の訓練シナリオを使ったデモを依頼します。確認項目をそろえておけば、提案を並べて比べられます。

• 通知と回答：発動、未回答者への再送、代理回答
• 状況把握：拠点別集計、対策本部の指示、設備の被害入力
• 有事対応：通信障害時の代替経路、同時アクセス時の処理能力

可能であれば、本番相当の負荷試験も行い、管理者が社外から発動できるかを確かめます。

評価では、現場が回答しやすいかと、担当者が状況をつかむまでの速さを重視します。

受入テストと訓練による導入効果の確認

開発の完了は、業務シナリオに沿った受入条件を満たしたかどうかで判定します。

• 通知と回答：対象者への通知完了時間、回答率、未回答者の把握
• 被害報告：集計時間と指示事項の既読状況
• 是正対応：訓練後の項目登録と担当者割当

NECの公式FAQでは、利用環境を申込後5営業日で提供すると案内しています（出典：日本電気、2026年確認）。この5営業日は、標準サービスの環境提供に関する期間で、自社のマスタ整備や訓練準備を含む全体の期間とは異なります。

RFPと要件整理で委託先に伝える内容

RFPは、機能の一覧にとどまらず、候補会社へ同じ条件を伝える文書です。

RFPには、発注背景、対象範囲、業務制約を示し、成果物と選定基準も書きます。

BCPでは、平時と有事で操作する人が異なります。そのため、通信や電源が不安定な状況も想定し、運用シナリオを具体的に書きます。

RFPに書く基本情報

RFPでは、まず会社の前提と導入時期を記載します。そのうえで、予算と段階ごとの範囲も示します。

• 会社と現状：従業員数、拠点数、国内外のグループ会社、想定災害、既存BCP文書、現在の連絡方法
• 導入条件：導入希望時期と予算の考え方
• 導入範囲：初期は安否確認・一斉通知、次段階は拠点被害・復旧タスクなどと区分します。
• 予算未確定時：SaaS、連携追加、個別開発の3案を求め、金額と機能を比べます。

機能要件と非機能要件の分け方

機能要件と非機能要件を分けておくと、候補会社に必要な条件を正しく伝えられます。

• 機能要件：通知、回答、掲示板、BIA、文書版管理、承認、被害報告、復旧タスク、訓練、CSV・API連携
• 非機能要件：有事の可用性、同時アクセス、復旧時間、バックアップ、監視、認証、暗号化、権限、ログ、保管、サポート時間

IPAの2026年4月の事業継続・復旧体制に関する実践情報は、サイバー攻撃による停止やサプライチェーンを含む演習を示しています（出典：IPA、2026年）。

RFPには、自然災害に加え、ランサムウェアやクラウド障害を想定した要件も含めます。

成果物と責任分界の明確化

納品物と担当範囲は、契約前に次のとおり分けて確かめます。

• 設計・移行：要件定義、画面・権限設計、データ移行計画、連携仕様書
• テスト・運用：テスト計画、操作マニュアル、訓練シナリオ、運用手順書
• SaaSの作業範囲：初期設定、マスタ登録、訓練支援が料金に含まれるか確認します。
• 責任分界：障害窓口、復旧、バックアップ、脆弱性対応、仕様変更通知、終了時のデータ返却

担当範囲を明らかにしておけば、導入後になって、想定していた作業が含まれていないと分かる事態を防げます。

BCP管理システムの契約形態と注意点

契約は、SaaSや標準製品のライセンスと、個別開発の請負・準委任、導入・運用支援の保守に分けて考えます。

複数の契約を組み合わせることもあります。

費用は、システム本体と、それ以外の作業ごとに分けて比べます。設定や移行、訓練、保守がそれにあたります。

請負契約と準委任契約の使い分け

契約の対象と成果の条件が異なるため、工程に合わせて選びます。

• 請負契約：成果物の完成と検収を重視し、要件・受入条件が明確な開発に向きます。
• 要件追加：請負契約後の追加は変更契約や費用につながるため、範囲を決めて発注します。
• 準委任契約：一定期間の専門作業を依頼し、要件定義、現状調査、運用設計に使えます。
• 組み合わせ：完成物を一括で決めにくいアジャイル改善や、要件定義を準委任、開発を請負とする構成も選べます。

契約書で確認するSLA・データ・変更管理

契約書では、次の4点を確かめます。

• SLA：稼働率のほか、有事のサービス継続、障害連絡の時間、復旧目標、バックアップ頻度を確かめます。
• データ・委託先：データセンターと再委託先も確認の対象に含まれ、解約時のデータ形式と返却期限は契約条件に残します。
• 個人情報・ログ：個人情報の取り扱いとログの保存期間を定めます。位置情報や家族情報を扱う場合は、まず目的と閲覧権限を整理し、保存期間と本人への説明も決めます。
• 変更・料金：追加機能の単価、ユーザー追加の条件、SMS・音声通知の従量料金、API変更の扱いを確認します。

保守・運用契約と開発契約の切り分け

開発後も更新が続くため、保守・運用で担う作業を決めておきます。

• 更新が必要な理由：組織改編、異動、拠点増減、災害想定の見直しでデータや手順が変わります。
• 保守を終える影響：連絡網が古くなり、訓練で見つけた課題が放置されるおそれがあります。
• 定期運用：月次のマスタ更新、四半期または半期の訓練、年次の計画見直しを整理します。
• 障害・引き継ぎ：障害連絡、脆弱性対応、担当者交代後も使える手順と権限を定めます。

BCP管理システムの費用相場とコスト内訳

費用は、利用人数や通知手段、対象拠点によって変わります。連携数に加え、BIA・文書管理、訓練支援、可用性要件も影響します。

公開価格のある安否確認SaaSと、BCP業務を作り込む個別開発では、価格の意味が異なります。そのため、「導入費」だけで比べないことが大切です。

ここに示すのは、リサーチノートと公式の公開料金をもとにした目安です。実際の契約金額を保証するものではありません。

公開SaaSの初期費用と月額料金

公開されている安否確認SaaSの料金例と、比べる際の範囲を整理します。

• 公開料金の入口：初期費用0円〜20万円程度、月額5,000円〜5万円程度です。
• Biz安否確認／一斉通報：初期0円・10万円・20万円、月額400円〜・1万円台〜（10ID、出典：NTTドコモビジネス公式料金、2026年確認）。
• ANPiS：初期費用無料、月額6,600円（税込）から（出典：各社公式料金、2026年確認）。
• 料金に含む範囲：公開価格は通知・回答・集計が中心です。BIA、文書承認、設備・在庫、復旧タスク、個別API、移行、訓練支援は別料金の場合があります。
• 比較条件：50名、300名、1,000名など同じ規模で、初期設定、オプション、SMS・音声従量、追加利用者、保守を含む3年総額を比べます。

NECは初期費用が不要で、100名以下は月額12,000円、1,000名以下は月額30,000円（税抜）です。

連携追加と個別開発の費用レンジ

個別開発の費用と期間は、範囲や連携方式によって変わります。

• SaaS連携追加：人事・拠点・気象・チャット、帳票、承認、掲示板で推定100万〜500万円、1〜3か月程度
• 中規模開発：BIA、文書、被害報告、復旧タスク、訓練、ダッシュボードで推定500万〜1,500万円、3〜6か月程度
• 大規模開発：多拠点・多言語・複数会社、設備・供給網、DR、高度な権限、多数のAPIで推定1,500万〜4,000万円以上、6〜12か月程度

これらは、要件と連携方式をもとにした推定で、BCP専用の公的な価格統計ではありません。公開SaaSの料金、一般的な開発工数、BCP固有の連携・可用性要件を基にしています。

見積もりでは、人数と拠点数、同時アクセス、通知経路の前提をそろえます。移行や負荷試験、訓練の条件も前提に含めます。24時間対応やバックアップ・DR、保守の条件も、提案に明記してもらいます。

3年総額で比較するコスト項目

3年総額には、初期費用と月額・ライセンスを含めます。導入支援やマスタ整備、データ移行も加えます。API連携と訓練支援も、そこに入れます。

SMS・電話通知やユーザー追加の費用も確認します。サーバー・ストレージや保守、障害対応に加え、脆弱性対応と計画変更も含めます。

提案によっては、訓練が別料金であったり、移行が発注者の作業であったり、24時間対応が対象外であったりします。通常の年と大規模災害の年、両方の費用を見ておきます。

委託先の選定と見積比較で確認するポイント

委託先は、知名度や導入社数よりも、BCP業務と災害時の運用を理解し、検証できるかで選びます。

安否確認サービスの会社、業務システムのSIer、クラウド基盤やDRの会社では、得意領域が異なります。そのため、自社の主目的に合う会社を候補にします。安否確認とIT基盤の継続は、重なる部分もありますが、同じものではありません。

実績と運用支援の実態確認

導入実績だけでなく、有事の処理と運用支援の実態も確かめます。

• 導入経験：同規模の従業員数・拠点数での事例、豪雨・感染症・停電・サイバー攻撃への対応
• 訓練と処理能力：支援実績、ピーク処理、通知再送、代理回答、複数通信経路
• 継続運用：管理者の社外発動、国内保管、バックアップ、復旧目標、24時間365日の窓口
• 確認資料：可能なら匿名化画面や訓練結果を見せてもらい、提案書の記述だけに頼らないようにします。

同じ条件での見積書の比較

提案と費用は同じ業務条件でそろえ、対応範囲や後工程の負担まで比べます。

• 機能の扱い：標準・設定・追加開発・対象外に分け、対象外の代替運用も記載します。
• 工程別費用：要件定義、移行、テスト、訓練、マニュアル、保守、障害対応、API、通知従量費を分けます。
• 評価軸：価格、機能適合、非機能要件、期間、担当者の専門性、運用支援、セキュリティ、将来拡張、データ返却
• 回答の確認：RFPの回答漏れや「個別相談」の条件は、契約前に確定します。
• 追加費用の確認：マスタ整備、外部連携、権限設計、訓練、負荷試験、24時間対応を確認します。

工程別に分けると、安く見せるために後工程へ費用を移した提案を見つけやすくなります。

個人情報・セキュリティ・障害時のリスク確認

情報の保護と、システム停止時の代替手順は、まとめて確認します。

• 扱う情報：氏名、所属、連絡先、安否、位置・家族情報、設備や取引先の被害情報
• 管理策：閲覧権限、多要素認証、操作ログ、暗号化、バックアップ、再委託、異動・退職時の削除、保存期間
• 緊急時の例外：災害時に設定を緩める場合は、承認者と事後監査の方法を定めます。
• 代替手順：クラウド障害や攻撃に備え、紙の連絡先、電話、別系統メール、チャット、代替サイトを用意します。
• 訓練とBCP：IPAが示すように、攻撃は重要システムを停止させます。自然災害のBCPとインシデント対応を連携し、代替経路の訓練も成果物に含めます。

よくある質問（FAQ）

外注では、安否確認の範囲や導入期間についての質問が多くあります。スクラッチ開発の必要性や費用についても、よく尋ねられます。

自社の規模や業務の重要度に置き換えて読むと、判断しやすくなります。

BCP管理システムは安否確認だけでも導入できますか？

導入できます。まずは通知と安否回答、集計、再送といった機能から始められます。訓練で課題を確かめてから、機能を段階的に追加するやり方が現実的です。

• 追加の候補：拠点被害や設備、BCP文書の管理です。復旧タスクや外部連携も、あとから加えられます。
• 監査や復旧の要件が厳しい場合：金融・医療・重要インフラのように、SLAやDRを初期から要件に含めます。
• ログ・権限の管理：初期から要件として定めておきます。

BCP管理システムはスクラッチ開発で発注すべきですか？

スクラッチ開発にするとは限りません。標準SaaSで初動対応を満たせるなら、初期費用と導入期間を抑えられます。さらに、災害時のインフラ運用の負荷も抑えられます。

個別対応を検討するのは、独自のBIAや複雑な承認、拠点・設備・取引先の統合が必要な場合です。既存の基幹システムと深く連携し、それが競争力や復旧に直結する場合も対象になります。

要件定義の段階で、上に挙げた条件に照らして適合度を確かめます。

BCP管理システムの導入期間はどれくらいですか？

環境提供だけの期間と、準備や訓練を含む導入全体の期間は、分けて考えます。

• SaaS環境：標準環境の提供は数営業日から始められるサービスがあります。
• 社内準備：利用者登録、権限設計、連絡網整理、訓練、社内教育は別に見積もります。
• 連携・帳票追加：既存SaaSへの追加は推定1〜3か月程度です。
• 個別開発：中規模は推定3〜6か月、多拠点・多言語・DR構築は推定6〜12か月程度です。

期間は機能数だけでなく、要件の確定度とデータ準備の進み具合にも左右されます。

見積を比較するときに最も重要な項目は何ですか？

比べるときは、同じ業務シナリオと非機能要件で見積をそろえることが最も大切です。初期費用と月額だけでは、全体を判断できません。

データ移行や連携、訓練、負荷試験の費用を確認します。保守や通知の従量費、障害時の復旧も対象です。3年総額と解約時のデータ返却も、比べる対象になります。

価格が低くても対象外が広ければ、追加費用や社内作業が生じます。標準・設定・開発・対象外に分けて比べます。

まとめ

発注では、安否確認だけで始めるか、BIAやBCP文書まで扱うかを決めます。拠点・設備・取引先の被害、復旧タスク、訓練まで含めるかも、あわせて判断します。

MUSTと将来のWANTを分けたうえで、発注形態をSaaSからハイブリッドまで、運用と可用性に照らして比べます。

発注前のRFPと見積条件の整理

RFPには、重要業務とRTO/RPO、対象人数と拠点を書きます。通知と回答、連携、権限、バックアップの条件も含めます。負荷試験、訓練、成果物、責任分界も明記します。

見積は、初期費用だけでなく3年総額で比べます。月額や追加開発、データ移行も総額に含めます。そのほか、次の費用も総額に入れます。

• 訓練費
• 保守費
• 障害対応費
• 通知の従量費

委託先には、実績に加えて、有事の処理能力や代替経路、運用支援、データ返却の条件を確認します。

訓練による測定と次の開発範囲の判断

訓練では運用状況を測り、その結果をもとに次の開発範囲を判断します。

• 測定項目：回答率、初回通知完了時間、被害報告の集計時間、未回答者の把握、是正項目の完了率
• 追加開発：訓練で見つけた不足だけを次段階で追加し、未使用の大規模システムへの過剰投資を抑えます。

BCP管理システムは、作って終わりではありません。平時の訓練と見直しを続け、担当者が替わっても更新できる状態を目指します。

▼全体ガイドの記事
・BCP管理システム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

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