安否確認システムのRFPと要件定義書は、災害シナリオと利用目的を定めるところから作ります。機能と非機能の要件を分けて整理し、評価基準を添えたRFPで提案を比べると、有事に使える仕組みにつながります。全体像は安否確認システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・安否確認システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
想定災害シナリオと利用目的の要件化
要件定義では、機能を比べる前に、自社が備える災害や緊急事態を整理します。想定するシナリオによって配信のきっかけや運用の流れが変わるため、地震だけを想定するか、水害・台風・噴火、感染症の流行、システム障害やテロまで対象を広げるかを決めます。シナリオが曖昧なまま製品を選ぶと、有事に対象の災害へ対応できない事態を招くおそれがあります。
自社が備えるべき災害・緊急事態の洗い出し
拠点の立地や事業の特性から、自社で備えるシナリオを具体化します。自然災害以外に想定する事態も、あわせて確認します。
- 自然災害：地震、水害、台風、噴火など
- 感染症：流行の拡大
- 人為的な緊急事態：システム障害やテロ
沿岸部なら津波、河川近くなら水害、特定地域に拠点が集中するなら直下型地震を想定します。全国に拠点が分散する企業は、広域災害も検討します。
汎用的な地震対応を基準にすると、実際に起きやすいリスクへの備えが抜けるおそれがあります。そこで、BCP（事業継続計画）の前提となるリスク評価と整合させます。
各シナリオで「誰に、いつ、何を確認するか」を定めます。たとえば、地震は震度5弱以上で全社に配信し、台風は前日に出社可否を確認し、感染症は毎朝の体調報告を求める、といった例があります。
運用を要件に明記すれば、全シナリオを製品がカバーできるかを評価できます。RFPにも同じ内容を書けば、ベンダーに要望を伝えられます。シナリオの整理は、要件定義全体の土台となる重要な作業です。
安否確認の利用目的とゴールの定義
利用目的によって、必要な回答項目や集計の細かさが変わります。そのため、目的をどこまで広げるかを先に整理します。
- 従業員の安否：生死を確認する
- 事業復旧：稼働できる人員を把握し、復旧判断につなげる
- 家族の安否：従業員の業務復帰可否を見極める
目的を「全員の安否確認」に限ると、事業継続の意思決定に使える情報が得られないことがあります。そこで、必要な情報の範囲を目的に合わせて定めます。
回答率や回答完了までの時間も、定量的な目標として設定します。たとえば「発災から1時間以内に回答率9割」と定めれば、自動再配信や複数チャネルでの配信が必要かどうかを判断できます。
要件定義書の冒頭に目的と目標を明記し、後続の機能要件をそれらに結び付けます。こうすると、ベンダーは提案の方向性を理解しやすくなります。
機能要件と非機能要件の切り分け
要件定義書では、機能要件と非機能要件を分けて記述します。機能要件はシステムが行う処理を、非機能要件は可用性・セキュリティ・性能などの品質を指します。
非機能要件は有事の信頼性を左右するため、機能要件と同じように丁寧に定義します。両者を混同すると、各社の提案を比較できません。
必須機能と「あれば望ましい」機能の優先度付け
機能は、利用目的と目標に照らして分類します。優先度は「必須・推奨・任意」の3段階に分けます。
- 配信・通知：自動配信、トリガー設定、複数チャネル通知
- 回答管理：自動集計・可視化、未回答者フォロー
- 付帯機能：家族安否、掲示板、人事連携
すべてを必須にすると、対応できる製品が限られたり、費用が膨らんだりします。そこで、自社のゴールに照らして本当に必要な機能を絞ります。
たとえば、気象庁と連動する自動配信は多くの企業で必須になる一方で、掲示板は組織の規模によっては任意でも構いません。回答率9割を1時間以内に目指すなら、未回答者への自動再配信を必須にできます。
各機能の優先度は、その理由とセットで要件定義書に記載します。過剰な提案を避けられ、社内合意やベンダーとの認識合わせにも役立ちます。
優先度は、前段で定めた利用目的とゴールを基準にします。両者の結び付きを明確にすれば、自社に必要な範囲で提案を受けられます。
可用性・セキュリティ・性能の非機能要件
非機能要件は、有事にサービスを使えるか、情報を守れるか、必要な速度で処理できるかの観点で整理します。
- 可用性：災害時の起動・集計とサービス継続
- セキュリティ：従業員・家族の個人情報の保護
- 性能：配信の遅延と集計のリアルタイム性
大規模災害時のアクセス集中や、データセンターが被災した後も稼働する条件を明記します。冗長構成や分散配置、想定する同時アクセス数への耐性も、可能な範囲で数値化します。こうした条件をそろえて示すと、ベンダーの実力を比較できます。
通信・保存データの暗号化、アクセス権限、第三者認証の取得状況を求めます。また、配信から端末に届くまでの遅延や、集計のリアルタイム性も定義します。
非機能要件は、自社のセキュリティポリシーやBCPの目標復旧時間に合わせます。要件に書かなければ提案に現れにくく、有事の信頼性にも関わります。非機能要件まで厚く定義することが、要件定義の質を左右します。
組織情報・連携・運用の要件定義
安否確認の精度は、宛先となる組織情報の正確さと、それを最新に保つ運用によって決まります。そのため、要件には情報管理や他システムとの連携を含め、日々の運用や訓練についても定めます。
機能や品質の要件が整っていても、組織情報が古ければ有事に対象者を取りこぼします。組織情報のライフサイクルと運用体制まで決めることが、実効性につながります。
組織構造とグループ管理・連携の要件
安否確認の対象者を正しく配信グループに分けるには、組織階層や雇用形態、複数所属の扱いを決めておく必要があります。
- 組織階層：拠点、部門、役職
- 雇用・所属：兼務者、出向者、派遣社員、業務委託
- 絞り込み：複数グループ所属や地域単位の配信
本社・支社・工場・店舗の拠点ごとに、組織をどこまで区切るかを整理します。1人が複数グループに属せるか、拠点をまたぐ災害時に地域で絞れるかも定義します。複雑な組織構造では、この要件が製品選定やカスタマイズの要否を左右します。
人事・勤怠システムからの自動同期では、連携方式（API・CSV）と頻度を決めます。手動更新だと名簿が古くなるおそれがあるため、可能な限り自動連携を含めます。
自社システムが既製品の連携メニューにない場合、個別開発が必要になることがあります。riplaは、フルスクラッチ受託の立場から、人事・基幹システムと安否確認を密に連携する開発を支援しています。
運用体制・訓練・サポートの要件
安否確認システムは、運用と訓練を続けてこそ有事に機能します。要件定義では、日常の担当と支援内容を明確にします。
- 役割分担：組織情報の更新と有事の配信起動
- 訓練：実施、未回答者の抽出、結果の分析
- ベンダー支援：初期設定、操作説明、有事の問い合わせ対応
訓練については、誰が実施し、誰が分析するかも決めます。あわせて、訓練を簡単に行う機能や、未回答者を抽出する機能も要件に含めます。
運用の担当者が曖昧なまま導入すると、システムが定着せず形骸化するおそれがあります。そこで、発注側はベンダーの対応範囲を確認します。防災担当が少人数の企業では、支援体制が定着に関わります。
運用・訓練・サポートをRFPに記載すると、導入後の運用も踏まえた提案を受けられます。要件定義では、機能に加えて、システムを使い続ける仕組みまで設計します。
RFPの構成と評価項目・ベンダー選定
RFP（提案依頼書）は、整理した要件をベンダーに伝え、提案を募る文書です。評価項目が不明確だと提案を比べられず、知名度や価格で選びがちになります。
有事の信頼性が重要なシステムだからこそ、機能や品質を評価できるRFPを用意します。運用やコストも評価できるようにしておくことが、適切なベンダー選定の前提です。
RFPに盛り込むべき構成要素
RFPには、前提条件と依頼内容を次の5つの情報にまとめて含めます。
- 背景・目的：導入背景、狙い、想定災害シナリオ
- システム要件：優先度付き機能要件と非機能要件
- 組織・運用：組織情報、連携、運用、訓練、サポート
- 前提・計画：従業員数、拠点数、予算、希望スケジュール
- 提案・評価：依頼内容と評価基準
これらを整理して示すと、ベンダーは自社の状況をつかみ、具体的な提案を返しやすくなります。一方で、従業員数や拠点数などの前提が曖昧だと、費用の見積もりに差が出て比較が難しくなります。
評価基準はRFPに明示し、評価項目には機能の充足度や災害時の可用性を入れます。運用、サポート、総コストも並べて設定します。各項目の重み付けも示します。
発注側は共通の基準で提案を採点でき、社内の合意形成も進みます。RFPは、要件と評価の枠組みを共有する文書です。
SaaS導入か個別開発かの判断軸
既製SaaSと個別開発のどちらが要件に合うかは、組織や連携の条件から見極めます。
- SaaS：標準的な組織構造や一般的な災害想定に合う
- 個別開発：独自の組織・多言語・密なシステム連携に対応する
標準的な組織構造で災害想定も一般的なら、実績のあるクラウド型SaaSで十分なことが多く、短期間・低コストで導入できます。
一方で、独自要件が多い場合は、個別開発も選択肢になります。独自要件には、複雑な組織モデルや海外拠点の多言語対応があります。基幹・人事システムとの密な連携や、業務システムへの組み込みも含まれます。
判断の目安は、必須要件のうち既製品で満たせない項目の数です。該当する項目が多いと、SaaSに合わせることで運用に無理が生じ、作り込みが合理的になる場合があります。
riplaは、フルスクラッチ受託と国内開発の立場から、要件定義、SaaSと個別開発の比較、自社要件に合わせた開発を支援しています。RFPで調達方式も見極めます。
コスト要件とTCO評価の盛り込み方
月額利用料だけで比べると、初期設定、訓練支援、連携開発費を見落とし、導入後に想定より高くなることがあります。そのため、初期費用と運用費用を合わせた総保有コスト（TCO）で評価します。
安さだけを優先すると、有事の信頼性や運用のしやすさを損なうおそれがあります。TCOの観点をRFPに記載します。
初期費用・月額・隠れコストを含めたTCO要件
見積もりの内訳を指定し、導入時と運用時の費用を分けて比較します。
- 初期費用：設定や導入時の費用
- 月額費用：利用料と従業員数による変動
- 追加費用：オプション、連携開発、訓練支援
クラウド型は1名あたり月額数十円から百数十円程度が中心です。これに初期設定費、人事システムとの連携開発費、訓練支援費などが加わる場合があります。
各費用を分けて見積もれば、月額は安くても総額が高いケースを見抜けます。また、従業員数が増減した場合の費用も確認します。
退職者・休職者のアカウントの扱いや、データ保存期間の制約も、長期コストに影響します。特にSaaSはアカウント数で課金されることが多く、組織の拡大に伴って月額が増えることがあります。
一定規模を超えると、ユーザー数に依存しない個別開発のほうがTCOで有利になる損益分岐点もあります。この分岐点を見極めるため、数年後の従業員規模も考慮します。
投資対効果と稟議を通すための根拠の整理
安否確認システムは「保険」的な性格があり、稟議では投資対効果の根拠が求められます。平時と有事の効果を分けて整理します。
- 平時：訓練の集計工数や個別確認の手間を減らす
- 有事：初動と事業復旧を早め、逸失利益を避ける
平時の効果は、訓練時の集計工数や、管理職が個別に安否を確認する手間として定量化できます。一方で、有事には、安否確認と初動が早まって事業復旧につながれば、操業停止による逸失利益を避けられる可能性があります。その効果がシステム費用を上回るリターンになる場合もあります。
効果の根拠を要件定義書に添えると、経営層への説明にも使えます。各社のコストはRFPで確認し、効果は自社の事業特性から算出します。
riplaは、フルスクラッチ受託と国内開発の立場から、TCO比較や投資対効果の整理を含め、要件定義に基づく調達方式の見極めを支援しています。
コスト要件を要件定義に含めると、機能と費用の両面から納得できる選定につなげられます。
まとめ
要件定義とRFP作成は、災害シナリオと利用目的から始める流れです。機能要件と非機能要件を分けて整理し、組織情報、連携、運用を要件にしたうえで、評価基準とともにRFPへまとめます。
可用性やセキュリティ、人事連携、訓練・サポートまで定義しておくことが、有事に使えるシステムを選ぶ条件です。曖昧な要件のまま知名度や価格で選ぶと、想定外のギャップが生じるおそれがあります。
自社の災害シナリオと組織から必要な要件を見極めます。既製SaaSが適する場合もあれば、独自要件から個別開発が合理的になる場合もあります。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、要件定義、調達方式の見極め、自社要件に合わせた開発を支援します。全体像は安否確認システムの完全ガイドもご覧ください。
▼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を創業。