健康管理アプリ開発の進め方/やり方/流れや方法/手法/工程/手順

健康管理アプリの開発は、利用者が何を記録し、どう振り返るかを決めてから進みます。機器連携や通知を増やす前に、一日の利用が無理なく終わる流れを確かめます。

ここでは生活習慣の記録を支えるアプリを想定し、企画から実証、公開後の改善までを工程順に説明します。診断や治療を目的とする機能は、別途専門的な検討が必要です。

最初に支援する健康行動の決定

健康行動の設計で確認する入力の機会、中断の原因、見返す目的、医療目的の有無を4枚のカードで示した図。
日常の記録場面を起点に、機能を絞る観点を並べています。

利用者の日常に基づく目的の絞り込み

必要な機能を決めるには、「健康になってもらう」より具体的な利用場面が要ります。たとえば、夕食後に体重を記録し、週末に変化を振り返るまでを、一つの利用場面として書きます。

対象者への聞き取りでは、記録が止まる理由を確かめます。

  • 入力の機会:いつ、どの端末で記録できるか。
  • 中断の原因:測り忘れ、入力の手間、表示の分かりにくさのどれに当たるか。
  • 見返す目的:本人の振り返りか、支援者との面談準備か。

生活のリズムが異なる利用者を、一つの設計に当てはめすぎないことが大切です。交代勤務の利用者がいる場合は、暦日と睡眠のまとまりが一致しないことがあるため、そうした場合も試作品で確認します。

医療目的の有無の整理

記録の表示と、疾病について判断する機能は、仕様書の中で分けて定義します。画面文言やサービス説明も含めて、どのような利用目的を掲げるかを、企画の段階で決めておきます。

PMDAのプログラム医療機器案内では、目的性やリスクに関する考え方を確認できます。そのうえで、名称だけで該当性を判断せず、必要な相談を工程に組み込みます。

ポイント

必要な機能は、利用者の一日の記録場面と中断の理由から絞ります。医療目的に当たるかは、名称ではなく判断機能の有無で、企画の段階で確かめておきます。

記録とデータ利用の仕様づくり

一つの記録を中心に、数値、測定日時、単位、入力元、未記録の状態を注釈線で示した図。
値だけではなく、記録の条件も合わせて扱う構成です。

一つの記録に必要な情報の定義

体重の記録であれば、数値だけでなく、測定日時と単位、入力元を含めて検討します。後から修正した履歴も扱いを決めます。値がない日をゼロとして表示すると意味が変わるため、未記録の状態も設計に含めます。

記録票を作り、取得から保持までのデータの扱いをそろえます。

  • 取得方法:手入力、端末連携、ファイル取込のいずれを使うか。
  • 編集方法:本人が修正できる期間と、元の値を残す要否。
  • 保持方法:保存期間、出力形式、退会時の処理。

機器の故障や通信断が起きても、生活の記録まで消えない流れを考えます。また、端末に一時保存する場合は、再送信のあとに同じ記録が二重に登録されない条件も定めます。

データの流れに合わせた説明と権限

本人、運営担当者、外部の支援者のあいだで、どの情報をどこへ渡すかを図にします。個人の詳細記録と集計結果を、同じ管理画面に無条件で表示しない設計も検討します。

病歴などを含む場合は、要配慮個人情報の定義と取得条件を、個人情報保護委員会の通則編で確認します。ただし、生活記録のすべてを一律に同じ区分として扱うわけではありません。

ポイント

記録1件に必要な項目と未記録の扱いを決め、取得、編集、保持の方法をそろえておくと、データの扱いで迷いにくくなります。誰に何を見せるかは、データの流れと権限に合わせて決めます。

試作品と実装の順序

試作品の操作を登録、記録、グラフの確認、通知設定の順に矢印でつないだ図。
入力から振り返りまでを一本の操作として確認できます。

入力から振り返りまでの試作品での確認

最初の試作品では、登録から記録、グラフの確認、通知設定までを一本の流れにつなげます。対象者には説明せずに操作してもらい、どこで止まるかを観察します。

試作品の評価を、見た目の好みだけで終わらせないようにします。

  • 操作完了:初回の記録を自力で保存できるか。
  • 意味の理解:グラフの日付や欠測を正しく読めるか。
  • 継続の負担:通知を止める操作と、記録を休む操作が分かるか。

外部連携の小規模な接続検証

端末連携を使う場合は、対象の項目を一つだけ選び、取得から表示までを先に検証します。接続の確認を実装の後半まで残すと、利用できるデータの違いが、画面設計にまで及んでしまいます。

権限は、AppleのHealthKit認可手順とAndroidのHealth Connect開始手順に照らして確認します。

権限が許可されない場合でも、アプリを使える範囲を決めておきます。手入力へ切り替える設計にする場合は、連携を再開したときにどちらの記録を採用するかも、試験できる形で仕様に書き起こします。

ポイント

試作品では、入力から振り返りまでを説明なしで操作してもらい、どこで止まるかを見ます。外部連携は、対象の項目を一つに絞って先に接続し、画面設計に影響が及ぶ前に把握しておきます。

公開前の試験と公開後の改善

データがそろわない状況での試験

正常な値が毎日届くケースだけを試しても、十分とはいえません。そのため、実機を使い、未許可や連携停止のほか、機種変更と日付変更も組み合わせて確認します。

公開判定に使う試験記録を、担当者が再現できる形で残します。

  • 境界の確認:日付をまたぐ記録や単位変更が集計を壊さないか。
  • 権限の確認:別の利用者の記録を開けないか。
  • 終了の確認:退会や連携解除後の処理が説明と一致するか。

問い合わせ窓口には、同期の遅延と記録の消失を切り分ける手順を渡しておきます。問い合わせの添付画像に健康情報が写り込む場合もあるため、受け取ったあとの扱いまで決めておきます。

継続率と記録の質の切り分け

公開後は、登録者数だけでなく、初回記録の完了と翌週の再利用を分けて確認します。ただし、自動取得だけで記録が増えている場合は、本人が振り返っているとは限りません。

欠測が多い理由も、生活上の中断と連携の不具合に分けて考えます。そのうえで、通知を増やす前に入力の負担や接続状態を確かめると、原因に合った改善を選べます。

ポイント

公開前の試験では、データがそろわない場面を組み合わせて確かめます。公開後は、登録者数ではなく、初回記録の完了と翌週の再利用を分けて見るのが目安です。

健康管理アプリ開発に着手する前の準備

利用場面と記録票を小さくそろえ、閲覧権限と試験条件も同じ範囲で決めておくと、関係者の判断が進めやすくなります。まず、最初の対象者と記録項目を絞り、実際の生活で試してから機能を広げてください。

会社紹介

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

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

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

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

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

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