安否確認システム開発の発注/外注/依頼/委託方法について

安否確認システムの外注は、要件整理、開発会社の選定、契約、開発推進、検収、運用引き継ぎの順に進めることで、成功につながります。

各工程で決めることや、開発会社の選び方、RFPの作り方、契約時の注意点は、この後の見出しで取り上げます。

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

安否確認システム開発外注の全体フロー

安否確認システム開発外注の5工程と各工程の期間を横一列に示したタイムライン図
開発・テストが全体の中ほどを占めます。

安否確認システムの外注は、発注前の準備から運用の引き継ぎまで、次の5段階を順に進めます。前の段階で決めたことが次の段階の前提になるため、順番を飛ばさないようにします。

  1. 要件整理とRFP(提案依頼書)の作成
  2. 発注先候補の選定とヒアリング
  3. 提案・見積もりの比較と契約
  4. 開発とテストの推進
  5. 検収・導入・社内展開と運用引き継ぎ

発注前に社内で整理すべき要件と前提条件

RFPを作る前に、総務・人事・情報システム・BCP担当が協力して要件を整理します。社内の要件が固まっていないと、開発会社への依頼内容もあいまいになります。

決めておく項目は対象人数から訓練計画まで幅広く、次の5つの観点で整理できます。

  • 対象と発動:従業員の範囲・人数、自動または手動の発動条件
  • 通知と回答:メール・SMS・プッシュ通知・アプリ、従業員に確認する項目と入力画面
  • 集計と連携:取りまとめの形式と報告先(部門長・経営層など)、人事・勤怠・グループウェアとの連携
  • インフラ:クラウド・オンプレ、可用性要件、マルチリージョン構成の要否
  • 予算と時期:予算上限、希望リリース時期、年何回のBCP訓練を行うか

発注プロセスの全体スケジュールの目安

工程ごとの一般的な期間は次のとおりで、全体計画を立てる際の目安になります。

  • 要件整理・RFP作成:1〜2ヵ月
  • 候補選定・ヒアリング:1ヵ月
  • 提案比較・契約:1ヵ月
  • 開発・テスト:3〜6ヵ月
  • 検収・導入・社内展開:1〜2ヵ月

発注の検討から稼働まで、通常は7〜12ヵ月程度かかります。ただし、規模や要件の複雑さによって期間は変わります。

マルチリージョン構成や冗長化設計が必要な場合、開発期間は長くなる傾向があります。人事・グループウェアとの複雑な連携も、期間を延ばす要因です。このように期間が延びることがあるため、BCP見直しや防災の日(9月1日)に間に合わせるには、期日から逆算して計画を立てます。

ポイント

次の段階に進むかどうかは、前の段階で決めるべきことが揃っているかで判断します。要件が固まらないまま契約へ進むと、あとで手戻りが増えやすくなります。

開発会社の探し方・選定方法

選定では、技術力に加えて、BCP・災害対応への理解と高可用性インフラの設計経験を確認します。

会社を選ぶ際は、一般的なWebシステム開発会社よりも、安否確認・緊急連絡・BCP支援の実績がある会社を優先します。

候補会社の探し方と情報収集の方法

候補は、実績のある会社を中心に3〜5社に絞り、複数の方法で探します。

  • Web検索:「安否確認システム開発会社」「BCP対応システム開発」で検索し、実績紹介ページを確認
  • 一括見積もり:IT発注ナビ・システム幹事・発注ナビ
  • 紹介:業界の知人や同業他社から情報を得る
  • イベント:IT展示会や防災・BCP関連セミナーへの参加

実際に使っている企業の生の声は、ウェブ上の情報より信頼性が高い情報源です。

候補会社が見つかったら、まず無料相談で概算見積もりをもらい、予算感を確認します。次に、詳細な選定に進みます。

提案・見積もりの比較と評価方法

提案書と見積書は、要件への適合性や災害時の設計まで含めて比べます。

  • 提案と費用:RFPの理解度、見積額の内訳と妥当性
  • 可用性:冗長化やマルチリージョン構成の具体案
  • 通知処理:1万人への同時送信を想定した設計方針
  • 実績と保守:安否確認・BCPに関する開発の経験、24時間365日の保守・緊急対応体制の具体的な内容
  • 運用費:月額または年額で示される導入後の保守料金

さらに、最終候補の2〜3社には、担当予定のエンジニアへのヒアリングも行います。技術的な質問への答えから、担当者の技術力の深さを見極めます。

ポイント

開発会社を選ぶときは、技術力に加えて、安否確認やBCPの実績があるかと、提案と見積もりを同じ観点で比べられるかを見ます。

RFP(提案依頼書)の作成方法

RFPに記載する災害時性能、回答目標、稼働率、個人情報の4要件を示すパネル図
回答目標と稼働率は数値で示すと提案を比べやすくなります。

RFPは、開発会社への依頼内容を文書にまとめたものです。

要件やBCP特有の条件を具体化しておくと、提案の精度が上がり、見積もりも明確になります。

RFPに記載すべき必須項目

RFPには、比較に必要な条件を開発の背景から提案期限まで書きます。

  • 背景と方式:BCP対策の目的、自社開発またはカスタマイズパッケージの方向性
  • 機能・非機能:通知・回答・集計・管理それぞれの詳細、可用性・パフォーマンス・セキュリティ・アクセシビリティ、災害時の同時アクセス対応
  • 連携・利用者:人事システム・勤怠システム・グループウェア、ユーザー数・部門数・階層構造
  • 進行条件:希望スケジュール、マイルストーン、任意の予算目安
  • 選定条件:評価基準、提案期限

通信インフラが一部遮断された場合に備えて、SMSやプッシュ通知の冗長化も要件に含めます。

安否確認システム特有の要件定義のポイント

安否確認システムでは、通常時の機能だけでなく、大災害時の非機能要件も具体化します。災害時のアクセス集中や個人情報保護は、具体的な数値や条件で示します。

  • 災害時性能:大地震・台風・洪水による極端なアクセス集中を想定
  • 回答目標:たとえば全従業員5,000人に対して30分以内に100%の回答率を達成
  • 稼働率:年間99.99%以上を保つなど、具体的な数値目標
  • 個人情報:従業員の連絡先・位置情報・回答内容の取り扱い

個人情報の保存場所と暗号化方式も明示します。また、アクセス権限とログ管理も書いておくと、開発会社は設計の前提を具体的につかめます。

ポイント

RFPの出来は、災害時の性能や回答目標を数値で示せているかで判断します。数値が揃うと、開発会社の提案と見積もりを比べやすくなります。

契約と発注時の注意点

個人情報を扱う安否確認システムを中央に置き、委託先管理、認証状況、再委託先、漏洩時対応と保守条件で囲む図
個人情報の管理体制と緊急対応の期限を契約で確認します。

契約では、一般的な開発条件に加えて、BCP、高可用性、24時間対応の条件を明確にします。契約時の条件があいまいなままだと、後のトラブルや想定外のコストにつながる可能性があります。

契約形態と契約書に盛り込むべき事項

仕様がどこまで確定しているかで契約形態を選び、納期や変更時の扱いは契約書に定めます。

  • 契約形態:仕様が明確なら請負、要件が流動的なら準委任(月額型)の方がリスクを抑えやすい場合があります
  • 納期と変更:マイルストーン、段階的リリース、仕様が変わったときの見積もりと対応
  • 検収と権利:負荷・可用性テストの合格基準、ソースコードの知的財産権
  • 機密と瑕疵:NDA、瑕疵担保期間と範囲
  • 保守SLA:深夜・休日を含む24時間365日対応、障害発生から1時間以内の初動対応など

安否確認システムは個人情報を扱うため、機密保持の条件は特に大切です。

保守や緊急対応の取り決めも、契約に明文化します。

個人情報保護と安全管理措置の確認

安否確認システムは、従業員の連絡先や位置情報などの個人情報を大量に扱います。

  • 委託先管理:個人情報保護法に基づき、体制を確認
  • 認証状況:開発会社がISO27001やPマークを取得しているか
  • 再委託先:インフラ会社やサブ開発会社の管理方針を確認
  • 漏洩時対応:通知義務と手順を契約に盛り込む

個人情報の取り扱い方針も、契約に記載します。

ポイント

契約書に書かれていない条件は、後のトラブルや想定外のコストの原因になりやすいため、個人情報の扱いと保守の条件まで書き切れているかを見ます。

発注後のプロジェクト管理

発注後も、発注者側の積極的な関与がプロジェクトの成功を左右します。要件の認識違いが後から見つかると、修正コストが膨らむおそれがあります。そのため、災害時に使えるシステムにするには、発注者側も進行と検証に加わります。

発注者側が行うべき推進管理のポイント

発注者側の関わりは、設計の確認から導入後の訓練まで続きます。

  • 進捗確認:週次または隔週の会議に参加し、課題を早めに見つける
  • 設計レビュー:BCP担当・人事担当・情報システム担当が連携して確認し、設計書や画面案を承認
  • UAT:ユーザー受け入れテストに参加し、業務の流れどおりに動くかを確認
  • 社内展開:従業員への告知と操作説明を企画・実施
  • 訓練計画:リリース後に、年1〜2回の実施を決めておく

スマートフォン操作に慣れていない従業員には、特に丁寧な説明が必要です。UATでは、実際の災害シナリオを想定したテストを強くお勧めします。また、深夜に一斉送信して回答が集中した場合の動作も確認します。

検収・リリース時の確認ポイント

検収では、通常の機能に加えて災害時の性能と代替手段を確認します。

  • 同時送信:全従業員への一斉送信が指定時間内に完了する
  • 負荷:ピーク時のサーバーが設計値の範囲内に収まる
  • 代替経路:一部インフラの障害時も別経路で通知が届く
  • テスト結果:負荷・可用性・セキュリティの各検証が済んでいるかを確認

合格基準は契約時に定めておき、検収のときに実施結果と照合します。

リリース時には、全従業員への周知と、操作マニュアルの配布、ヘルプデスクの整備を行います。

リリース後1〜2ヵ月は、開発会社と密に連携して、現場の意見を改善に素早く反映します。

ポイント

発注後は、設計の確認から訓練計画まで発注者側が関わり続けているかを見ると、要件の認識違いに早く気づけます。

まとめ

外注は、BCP要件の整理とRFPの作成から始まります。相見積もりと提案の比較を経て契約し、その後は開発の推進から検収・リリースへと進みます。

発注時には、高可用性、24時間対応の保守、個人情報保護を確認します。そのうえで、負荷テストと訓練計画も含めて、災害時に使えるかを検証します。

▼関連記事

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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