安否確認システムのRFP/要件定義書/提案依頼書について

安否確認システムの導入を成功させられるかどうかは、製品を選ぶ前の「要件定義」と、それを外部ベンダーに伝えるための「RFP（提案依頼書）」の質で大半が決まります。安否確認は平時にほとんど使わないため、要件を曖昧にしたまま「とりあえず有名な製品を入れておこう」と進めてしまいがちです。しかし、自社の想定災害や組織構造、運用体制を要件として明文化しないまま導入すると、有事に「想定していた使い方ができない」という致命的なギャップが露呈します。

本記事は、安否確認システムのRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から実務的に解説する「要件定義特化」の記事です。想定すべき災害シナリオの整理、機能要件と非機能要件の切り分け、組織情報と連携の要件化、運用・訓練を含めた要件、そしてRFPに盛り込むべき評価項目とベンダー選定の進め方まで、要件定義の段階で詰めるべき論点を体系的に扱います。読み終えるころには、自社のRFPに落とし込める要件項目の骨格が描けるはずです。なお、安否確認システム全体の選び方や費用相場をまだ把握していない方は、まず安否確認システムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・安否確認システムの完全ガイド

想定災害シナリオと利用目的の要件化

要件定義の出発点は、機能の比較ではなく「自社はどんな災害・緊急事態に備えるのか」というシナリオの整理です。地震だけを想定するのか、水害や台風、噴火、感染症の流行、さらにはシステム障害やテロといった人為的な緊急事態まで含めるのか。想定するシナリオによって、必要な配信トリガーや運用フローは大きく変わります。シナリオを曖昧にしたまま製品を選ぶと、有事に「この災害には対応していなかった」という落とし穴にはまります。

まず行うべきは、自社の拠点立地と事業特性から、備えるべき災害・緊急事態を網羅的に洗い出すことです。沿岸部に拠点があれば津波、河川近くなら水害、特定地域に集中していれば直下型地震、全国に分散していれば広域災害、というように、自社固有のリスクを具体化します。これを怠ると、汎用的な地震対応だけで満足してしまい、実際に起きやすいリスクへの備えが抜け落ちます。BCP（事業継続計画）の前提となるリスク評価と整合させて、シナリオを定義することが重要です。

洗い出したシナリオごとに、「誰に・どのタイミングで・何を確認するか」を整理します。たとえば地震なら震度5弱以上で全社配信、台風なら前日に出社可否を事前確認、感染症なら毎朝の体調報告、というように、シナリオごとに運用が異なります。これらを要件として明文化しておくと、製品が自社の全シナリオをカバーできるかを評価でき、RFPでベンダーに正確な要望を伝えられます。シナリオの整理は、要件定義のすべての土台になる最重要の作業です。

シナリオと並んで定義すべきが、安否確認の「利用目的とゴール」です。単に従業員の生死を確認するだけなのか、稼働可能な人員を把握して事業復旧の判断につなげるのか、家族の安否まで含めて従業員の業務復帰可否を見極めるのか。目的によって、必要な回答項目や集計の粒度が変わります。目的を「全員の安否確認」とだけ漠然と置くと、得られる情報が薄く、肝心の事業継続の意思決定に使えない、という事態になります。

あわせて、目標とする回答率や回答完了までの時間といった、定量的なゴールも要件に盛り込みます。たとえば「発災から1時間以内に回答率9割」を目標と定めれば、自動再配信やマルチチャネル配信といった機能の必要性が論理的に導けます。要件定義書には、これらの目的・ゴールを冒頭に明記し、後続の機能要件がすべてこのゴールに紐づくよう構成すると、ベンダーも提案の軸を理解しやすくなります。目的なき要件定義は、機能の寄せ集めに陥りがちです。

機能要件と非機能要件の切り分け

要件定義書の中核は、機能要件と非機能要件を明確に切り分けて記述することです。機能要件は「自動配信」「自動集計」といったシステムが何をするかを、非機能要件は可用性・セキュリティ・性能といった「どの品質で実現するか」を指します。安否確認システムでは、この非機能要件こそが有事の信頼性を左右するため、機能要件と同等以上に丁寧に定義する必要があります。両者を混同すると、提案の比較ができなくなります。

機能要件は、自動配信・トリガー設定、マルチチャネル通知、自動集計・可視化、未回答者フォロー、家族安否、掲示板、人事連携といった項目を一覧化し、それぞれに「必須・推奨・任意」の優先度を付けます。すべてを必須にすると、対応できる製品が限られたり費用が膨らんだりするため、自社のゴールに照らして本当に必須な機能を絞り込むことが肝心です。たとえば「気象庁連動の自動配信」は多くの企業で必須ですが、「掲示板」は組織規模によっては任意で構いません。

優先度付けの基準は、前段で定義した利用目的とゴールです。回答率9割を1時間以内に達成する、というゴールがあれば、未回答者への自動再配信は必須に分類されます。この紐づけが明確であれば、ベンダーからの過剰な機能提案に流されず、自社に必要な範囲で最適な提案を引き出せます。要件定義書には、各機能の優先度と、なぜその優先度なのかという理由をセットで書いておくと、社内の合意形成にもベンダーとの認識合わせにも役立ちます。

非機能要件で最重要なのが、災害時の可用性です。「大規模災害でアクセスが集中しても安否確認を起動・集計できること」「特定地域のデータセンターが被災してもサービスが継続すること」を要件として明記します。サーバーの冗長構成や分散配置、想定する同時アクセス数への耐性を、可能な範囲で定量的に記述すると、ベンダーの実力を比較できます。可用性は平時には見えないため、要件として言語化しないと提案でも触れられず、有事に裏切られます。

セキュリティ要件では、従業員と家族の個人情報を扱うことを前提に、通信・保存データの暗号化、アクセス権限の制御、第三者認証の取得状況などを求めます。性能要件としては、配信から従業員の端末に届くまでの遅延や、集計のリアルタイム性を定義します。これらの非機能要件は、自社のセキュリティポリシーやBCPの目標復旧時間と整合させることが重要です。機能要件だけでなく非機能要件を厚く定義することが、安否確認システムの要件定義の質を決定づけます。

組織情報・連携・運用の要件定義

安否確認システムの精度は、宛先となる組織情報の正確さと、それを最新に保つ運用に大きく依存します。そのため、組織情報の管理方法や他システムとの連携、日々の運用と訓練までを要件として定義することが欠かせません。機能や非機能の要件が立派でも、組織情報が古ければ有事に取りこぼしが発生します。要件定義の段階で、組織情報のライフサイクルと運用体制まで踏み込むことが、実効性のある安否確認につながります。

自社の組織構造を、安否確認システムのグループ管理にどう落とし込むかを要件化します。本社・支社・工場・店舗といった拠点別、部門別、役職別の階層に加え、兼務者や出向者、派遣社員、業務委託をどう扱うかを明確にします。1人が複数グループに属せるか、拠点をまたぐ災害時に地域単位で絞り込めるか、といった要件は、既製品の標準機能で満たせるかを左右します。自社の組織が複雑な場合、この要件が製品選定やカスタマイズの要否を決めます。

連携要件としては、人事システムや勤怠システムから組織情報を自動同期できるか、その連携方式（API・CSV）と頻度を定義します。手動更新に頼ると名簿が陳腐化し、有事の取りこぼしにつながるため、可能な限り自動連携を要件に含めるべきです。既製品の連携メニューに自社のシステムがない場合、個別開発でAPIをつなぐ必要が生じます。riplaはフルスクラッチ受託の立場から、自社の人事・基幹システムと安否確認を密に連携させる開発を支援しており、こうした連携要件こそ作り込みの価値が出る領域だと考えています。

安否確認システムは導入して終わりではなく、運用と訓練を回し続けて初めて有事に機能します。そのため、要件定義には運用体制も含めます。誰が組織情報を更新し、誰が訓練を実施・分析し、誰が有事に配信を起動するのか、という役割分担を明確にします。あわせて、訓練を簡単に実施できる機能、未回答者を抽出する機能、訓練結果を分析する機能といった、運用を支える要件を盛り込みます。運用の主体が曖昧なまま導入すると、定着せず形骸化します。

ベンダーのサポート体制も要件化すべき項目です。初期設定の代行や従業員への操作説明、訓練の支援、有事の問い合わせ対応など、どこまで伴走してもらえるかを確認します。特に防災担当が少人数の企業では、ベンダーの支援が定着の成否を分けます。これらの運用・訓練・サポートの要件をRFPに含めることで、製品の機能だけでなく、導入後の運用まで見据えた提案を引き出せます。要件定義は、システムの機能だけでなく、それを使い続ける仕組みまで設計する作業なのです。

RFPの構成と評価項目・ベンダー選定

整理した要件を、ベンダーに伝えて提案を募るための文書がRFP（提案依頼書）です。RFPの構成と評価項目の設計が甘いと、各社の提案を横並びで比較できず、結局は知名度や価格だけで選んでしまいます。安否確認システムは有事の信頼性が命であるため、機能・非機能・運用・コストを多面的に評価できるRFPを用意することが、適切なベンダー選定の前提になります。

RFPには、(1)導入の背景と目的、(2)想定災害シナリオと利用目的、(3)機能要件（優先度付き）、(4)非機能要件、(5)組織情報・連携要件、(6)運用・訓練・サポート要件、(7)想定する従業員数や拠点数といった前提条件、(8)予算と希望スケジュール、(9)提案してほしい内容と評価基準、を盛り込みます。これらを構造化して提示することで、ベンダーは自社の状況を正確に理解し、的を射た提案を返せます。前提条件を曖昧にすると、提案の費用見積もりがばらつき、比較できなくなります。

特に重要なのが、評価基準をRFPの中で明示することです。「機能の充足度」「災害時の可用性」「運用のしやすさ」「サポート体制」「総コスト」といった評価軸と、それぞれの重み付けを示しておくと、ベンダーは何を重視すべきかを理解して提案を組み立てます。発注側も、提案を同じ物差しで採点でき、社内の合意形成がスムーズになります。RFPは、要件を伝えるだけでなく、評価の枠組みをあらかじめ共有する文書だと捉えると、選定の精度が格段に上がります。

RFPを通じて見極めるべき本質的な判断が、既製のSaaSを導入するのか、自社専用に個別開発するのか、という選択です。組織構造が標準的で、想定災害も一般的なら、実績豊富なクラウド型SaaSで十分なことが多く、短期間・低コストで導入できます。一方、複雑な組織モデル、海外拠点の多言語対応、基幹・人事システムとの密な連携、業務システムへの組み込みといった独自要件が多い場合は、SaaSでは満たしきれず、個別開発が現実的な選択肢になります。

この判断は、要件定義で洗い出した「必須要件のうち、既製品で満たせない項目がどれだけあるか」で決まります。満たせない項目が多いほど、無理にSaaSへ寄せると運用で歪みが出るため、作り込みが合理的になります。riplaはフルスクラッチ受託と国内開発の立場から、要件定義の支援から、SaaSと個別開発の比較、自社要件に合わせた開発までを一貫して支援しています。RFPは、製品を選ぶだけでなく、そもそも自社にとって最適な調達方式を見極めるための重要なプロセスでもあるのです。

コスト要件とTCO評価の盛り込み方

要件定義とRFPで見落とされがちなのが、コストの要件化です。月額の利用料だけを比較して選ぶと、初期設定費や訓練支援費、連携開発費といった隠れたコストを見落とし、導入後に「想定より高くついた」となります。安否確認システムは長期にわたって運用するため、初期費用と運用費用を合わせた総保有コスト（TCO）の観点で評価する要件を、RFPに明示することが重要です。価格の安さだけで選ぶと、有事の信頼性や運用のしやすさを犠牲にしかねません。

クラウド型の安否確認システムは、1名あたり月額数十円から百数十円程度の利用料が中心ですが、これに加えて初期設定費や、人事システムとの連携開発費、訓練支援費などが発生します。RFPでは、提示してほしいコストの内訳を明確に指定し、初期費用・月額費用・オプション費用・連携開発費を分けて見積もるよう求めます。これにより、表面上の月額が安くても総額では高い、といった逆転を見抜けます。従業員数の増減で費用がどう変わるかも、あわせて確認しておくべき項目です。

退職者や休職者のアカウントをどう扱うか、データの保存期間にどんな制約があるかも、長期コストに効いてきます。SaaSではアカウント数で課金されることが多く、組織が拡大すると月額が膨らみます。一定規模を超えると、ユーザー数に依存しない個別開発のほうがTCOで有利になる損益分岐点が存在します。要件定義では、現在だけでなく数年後の従業員規模を見据えて、コストの見通しを評価することが大切です。

安否確認システムは「保険」的な性格を持つため、稟議で投資対効果を問われたときに答えられるよう、要件定義の段階で効果の根拠を整理しておきます。平時の効果としては、災害訓練時の集計工数の削減や、管理職が個別に安否を取る手間の削減を定量化できます。さらに大きいのが有事の効果で、安否確認と初動の迅速化によって事業復旧が早まれば、操業停止による逸失利益の回避という形で、システム費用を大きく上回るリターンを示せます。

これらの効果の根拠を要件定義書に添えておくと、経営層への説明資料としてそのまま使え、稟議がスムーズに進みます。コストはRFPで各社から引き出し、効果は自社の事業特性から算出する、という両面の整理が、納得感のある投資判断を支えます。riplaはフルスクラッチ受託と国内開発の立場から、要件定義に基づくTCO比較や投資対効果の整理を含め、自社にとって最適な調達方式の見極めを支援しています。コスト要件を要件定義に組み込むことで、機能と費用の両面で後悔しない選定が可能になります。

まとめ

安否確認システムの要件定義とRFP作成を振り返ると、その要諦は「想定災害シナリオと利用目的を起点に、機能要件と非機能要件を切り分け、組織情報・連携・運用までを要件化し、それを評価基準とともにRFPへ構造化する」という一連の流れに集約されます。可用性やセキュリティといった非機能要件、人事システム連携、運用・訓練・サポートまで踏み込んで定義することが、有事に本当に使える安否確認システムを選ぶ条件です。要件を曖昧にしたまま知名度や価格で選ぶと、いざというときに想定外のギャップに直面します。

要件定義で大切なのは、機能の比較から入るのではなく、自社の災害シナリオと組織から逆算して、本当に必要な要件を見極めることです。その結果として、既製のSaaSが最適なこともあれば、独自要件の多さから個別開発が合理的なこともあります。riplaはフルスクラッチ受託と国内開発を組み合わせ、要件定義の支援から調達方式の見極め、自社要件に合わせた開発までを一貫して支援します。要件定義の全体像をあらためて確認するには、完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。