健康管理アプリ開発の発注/外注/依頼/委託方法について

健康管理アプリを外注するときは、開発会社に渡す情報と、利用目的や支援内容のように発注側が決める事柄を分けて考えることが大切です。

生活記録を扱うアプリを例に、依頼から運用の引継ぎまでの流れを順に見ていきます。治療や診断を目的とする機能は、別の検討範囲として扱います。

依頼前に用意する資料

依頼資料で具体化する対象者と目的、データの範囲、終了時の扱いを並べた図解。
三つの観点をそろえると、見積もりの前提を整理しやすくなります。

記録から利用終了までの業務の書き方

画面のイメージだけでは、誰がどの作業を担当するのかが分かりません。そこで、本人が体重を記録し、担当者へ共有し、後から共有を止めるまでを一続きの業務として書き出します。

依頼資料では、次の三つを具体化します。

  • 対象者と目的:一般利用者の振り返りか、面談などの支援に使うか。
  • データの範囲:記録項目、取得元、閲覧者、保存期間。
  • 終了時の扱い:退会、連携解除、事業終了で何を残すか。

未確定の事項を空欄のまま見積もりに進むと、前提がそろわないまま話が進みます。そこで、決定担当者と期限を添えておきます。たとえば、支援者が見られる項目は、開発見積もりの前に発注側の運用責任者が判断します。

連携先に渡す条件

スマートウォッチ対応とだけ書くと、何を作るのかが定まりません。そこで、取得するデータ、対象OS、端末候補、窓口や仕様書の所在を示しておきます。

確認の起点には、Health Connectのデータ型と権限のような公式仕様を使います。希望する記録が取得できるかはっきりしないときは、調査と試作を先に依頼します。

ポイント

依頼資料は、記録から利用終了までの業務として書きます。連携先は名称ではなく条件で示し、未確定の事項には決定担当者と期限を添えます。

開発会社への確認事項

開発会社の連携経験、運用経験、検証体制を示す三つのチェックカード。
各社へ同じ観点を尋ねると、実績の内訳を比べられます。

実績の名称より担当範囲

健康関連のアプリを公開した会社でも、表示画面だけを担当した可能性があります。そのため、難しい工程を自社の案件で担当できるかを、実績の内訳から確かめます。

面談では、候補となる各社に同じ質問を投げます。

  • 連携経験:許可変更や重複データをどう扱ったか。
  • 運用経験:同期不良やデータ訂正の問い合わせにどう対応したか。
  • 検証体制:実機、権限、削除処理を誰が試験するか。

公開実績にない機能は、「対応できるはず」と推測で補わず、確かめる対象にします。開発会社が説明できない部分は、試作の提案や担当予定者の確認で判断します。

医療上の判断をする責任者

症状から病気を推測するなど、医療目的に関係する機能を含む場合は、実装できるかだけを尋ねて済ませないようにします。仕様、表示、提供体制を誰が確認するかを、あらかじめ決めておきます。

PMDAのプログラム医療機器に関する情報を参照し、該当性について相談が必要かを検討します。開発を受託した実績は、規制対応の保証とは見なしません。

ポイント

開発会社は実績の名称ではなく、担当した工程と担当範囲で比べます。医療目的の機能を含むなら、仕様や表示、提供体制を確認する責任者を発注側で決めておきます。

契約前に決めておく条件

契約で合意する対象として、開発資産、運用資産、契約条件、アカウント、健康情報を示す図解。
成果物だけでなく、運営権限やデータの扱いも合意範囲に含まれます。

納品物と変更の扱いの文書化

契約の対象には、アプリの納品だけでなく、運用を続けるための資料も含めます。ソースコードを受け取っても、再構築の手順がなければ、保守を別の会社へ移すのが難しくなります。

協議する成果物は、次のとおり具体名で挙げます。

  • 開発資産:コード、設計書、試験結果、構築手順の一式。
  • 運用資産:監視設定、管理者手順、障害時の連絡先。
  • 契約条件:権利の帰属、再委託、仕様変更の見積手続き。

また、ストアやクラウドのアカウントも、名義と操作権限を合意しておきます。担当会社が変わった場合でも、発注側がサービスを続けて運営できる状態を目指します。

健康情報の取り扱いと委託範囲

本番データに誰がアクセスするか、調査用に持ち出してよいか、終了時の削除をどう確認するかを決めます。そのうえで、開発用には実在しないテストデータを用意する方法を検討します。

個人情報保護委員会の通則編には、委託先の監督や安全管理の考え方が示されています。契約文面の確認だけでなく、実際の管理手順と報告の経路も確かめます。

ポイント

契約では、運用を続ける資料やアカウントの名義と操作権限まで合意します。健康情報の閲覧や持ち出し、削除の扱いは、委託範囲として契約に落とします。

検収と運用引継ぎの進め方

検収に含める同意変更とデータ不整合

検収では、画面が表示されるかだけでなく、利用者への説明と実際の保存・共有の処理が一致するかも確かめます。発注側の担当者も、この試験に加わります。

生活記録アプリでは、少なくとも次の三つの流れを確かめます。

  • 取得を拒否する:許可しない項目が取り込まれず、理由が画面で分かるか。
  • 記録を訂正する:修正後のグラフと共有先表示が仕様どおり変わるか。
  • 利用を終える:退会後のアクセス停止と保存済み記録の処理が一致するか。

不具合と追加要望は、合意済みの仕様に照らして分けます。判定できない場合に備えて、受入条件、再試験日、未解決事項の扱いをあらかじめ決めておきます。

運用開始前の問い合わせの模擬試験

「今日の歩数が反映されない」という問い合わせを例に、窓口から技術担当までの引継ぎを試します。確認に使う端末情報や記録日時をあらかじめ決めておくことで、健康情報を必要以上に集めずに済みます。

保守契約では、受付時間と初動、復旧作業を分けて決めます。さらに、OS更新への対応と追加改修も、保守の範囲に入るかどうかを分けておきます。月額の有無だけで比べると、誰が何を担う契約なのかが食い違ったままになりやすいため、この範囲をそろえて比べます。

ポイント

検収では、取得拒否、記録訂正、利用終了の流れを発注側も加わって試験します。運用の引継ぎは、問い合わせを模擬して窓口から技術担当までを通してから、開始の判断をします。

外注内容の具体化

発注側で決めるのは、健康支援の目的とデータ利用のルールです。この二つを依頼資料、契約、検収条件に一貫して反映させると、開発会社と実装範囲を確定させやすくなります。

会社紹介

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

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

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

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

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

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