スクリーンショット-2018-08-21-0

ヘルスケア領域におけるプロダクト開発の落とし穴

はじめに

ここ数年間でいくつかの医療系サービスの開発に携わる機会に恵まれ、その内1つは、実際にユーザーの生活をサポートするサービスとして、今も動き続けています。しかし自分が携わったプロダクトには、リリースに行き着かなかったもの、リリースしたもののすぐに閉じてしまったものなどがあり、苦い思いもしてきました。

そうしたプロダクト開発の経験の中で学んだのは、サービスを作るためにはいくつもの落とし穴を乗り越える必要があり、一般的なIT業界で用いられている手法や手順に沿っていると、避けることの出来ない落とし穴があるということです。

本記事では、ヘルスケア領域におけるプロダクト開発の中で意識しないといけない落とし穴について、そして自分自身の経験上から学んだその落とし穴への対処法についてまとめたいと思います。

想定する一般的なプロダクト開発の手順

まずは、ヘルスケア領域特有の問題をより浮き立たせるために、私の考える一般的なプロダクト開発の手順について整理したいと思います。

上の図は、ダブルダイヤモンドと呼ばれる、課題の発見から解決策の提供に到るまでのフローを示したものです。以下、この図に沿ってフローを書き出します。

課題の発見と探索
1. 不便を感じ、課題に気付く
2. 課題の探索
- 誰にどんな課題がある?
- 他に良い解決策はない?
 - 無いのであればなぜ無いのか?
- 課題を感じているのはどんな人?

課題仮説の定義
3. 課題仮説の洗練化
4. 課題仮説の検証
5. 要件定義(ユーザー要件・ビジネス要件)

解決策の探索
6. アイデア出し
7. プロトタイプの作成
- ペーパープロトタイプ
- ワイヤーフレームの作成
- 仕様書の作成
8. MVPの作成(場合によっては課題仮説の検証も含める)

解決策の洗練化
9. MVPを用いた解決策の検証

そもそもこれを書いている自分が、これで良かったかなと不安ではありますが、まあざっくりこんな手順だと思います。

以下、こうしたスタンダードを踏まえた上での、ヘルスケアサービス特有の落とし穴についてです。

1. 解決するべき課題のスコープが定まらない

原因1 メンバーの思いが強くなり過ぎる

ヘルスケア領域はユーザーに対するメンバーの共感や課題感がとても強くなりやすい領域です。その分やりがいもあるのでとても良い事なのですが、その副作用として、メンバー間でのその想いの強さが別の方向に向かってしまいどちらの手段を取るべきかで対立が起こってしまう事があります。

思いが強いが故の対立の為、一概にどちらが正しいとは言い切れず、プロジェクトが硬直状態に陥ってしまう事があります。

原因2 ステークホルダーが増えやすい

ヘルスケアサービスはtoCでのマネタイズが難しく、必然的にtoBやBtoBtoCなどのビジネスモデルを取る可能性が高くなります。また、その際外部の研究機関や医師等に協力を依頼する事も多く、ステークホルダーが増えやすい特徴を抱えています。

ステークホルダーが増えた結果、それぞれが抱える課題のすり合わせが難しく、そもそもチームメンバー間で何を目指してプロジェクトに取り組むのかが定まりにくくなります。

対策 メンバー選びとタイミングが超重要

プロジェクトに参加してもらうメンバー選びとそのタイミングがとても重要です。初期段階では出来るだけ少人数で課題の発見と深掘りを行い、その後、その発見した課題感や解決策の方法などに共感できるメンバーを慎重に選ぶ必要があると感じています。

2. ユーザー理解に対する認識がチーム内で揃わない

原因 医療従事者と開発メンバーとの間でのユーザーへの認識に差が出やすい

ヘルスケアサービスのターゲット層は40 ~ 50代のユーザーになりやすい傾向にあります。その際、医療従事者のメンバーは臨床経験があれば、十分にコミュニケーションを取った経験がありますが、開発メンバーには、そのターゲット層へのコミュニケーション量は少ないメンバーがほとんどだと思われます。

また、医療従事者が抱えるユーザー像は、あくまでも病院の中でのユーザー像であり、その時取り組んでいるプロジェクトのユーザー像とはズレている可能性もあります。

対策 メンバーのターゲット層へのコミュニケーションの機会を増やす

ここは淡々とやるしか無い部分だと感じています。

3. プロトタイプを用いた仮説検証の精度が低い

原因 UIモックやペーパープロトタイプだけでは十分な検証にならない

プロトタイプを用いた仮説検証をする際の相手がエンジニアやデザイナー、または若いITリテラシーの高い人の場合、ペーパープロトタイプやワイヤーフレームなどでも、十分に検証の意図は伝わります。

しかし、検証時のインタビュー相手が医療従事者や40 ~ 50代以上のITリテラシーが高くないような人たちの場合、簡易的なプロトタイプだけでは十分な仮説検証にならず、実装してから実は違ったという事が十分に起こりえます。

対策 検証に求められるMVPの要件のハードルを上げる

MVPを初めからしっかり作る事を想定しておきましょう。デザインや開発の工数が無駄になるかもしれないリスクはありますが、仕方ないものだと割り切ってやるしか無いです。

意図が理解し切れていないエンジニアやデザイナーがいると不満の種になりやすいために、メンバー間での丁寧な意識合わせとコミュニケーションが必要です。

4. ユーザーのニーズを特定しきれていない

原因 開発メンバーのターゲット層への理解が深めにくい

ヘルスケア領域のサービスのターゲットユーザーは40 ~ 50代以上の層になりやすいかと思います。また、サービスの開発メンバーは必然的に若いメンバーになりやすく、若い開発メンバーにとっては40, 50代が抱える健康に関する悩みなどは想像しにくいものがあります。

対策 メンバーのターゲット層へのコミュニケーションの機会を増やす

2. の解決策と同じです。淡々とターゲット層へのインタビューやコミュニケーションを重ねていきましょう。

5. 実は自分達のリソースでは解決出来ない課題だった

原因 真にユーザーが求めていたのは、延命や疾患の完治である

重症疾患の患者さんへのサービスなどを作る場合、究極のところその患者さんが抱えている課題は疾患の苦しみに付随している事が多いです。

ITサービスなどでは介入し切れず、結局は医療機関での治療や服薬治療などをどう改善していくかでしか無い場合もあります。

変えられるものを変える勇気を、変えられないものを受け入れる冷静さを、そして両者を識別する知恵を与えたまえ​

有名な一節ですが、変えられるものと変えられないものを識別出来ることはとても重要です。

対策 特に重症度の高い疾患やユーザーの声が大きい領域では注意する

私自身も経験があった事ですが、特にガン領域などの重症度の高い疾患領域ではこうした事は起こりやすいです。また、ユーザーの声が大きい領域というのも十分注意が必要です。

6. 仕様詳細が中々詰まらない

原因 ドメイン知識の溝を埋め切れていない

ヘルスケア領域のサービスを作る場合、医療用語や概念が頻出する事があります。開発メンバーは十分な予備知識がなければ全て呪文の様に見えてしまうでしょう。そうした状況ではキメ細やかな配慮がされたサービス作りを行う事は難しくなります。

また、医療従事者側もサービス開発について十分な予備知識を持っておく事が大切です。なぜなら、医療従事者がプロダクトオーナーになる事は良くある事であり、作った機能が十分に要件を満たしているのかどうかを判断するのも医療従事者である可能性が高いからです。

対策 医療従事者及び開発メンバーの双方の知識の溝を埋める

お互いのドメイン知識を越境するメンバーが現れない場合、プロダクトはとても厳しい状況になります。またどちらかだけが、一方の知識を持っていたとしても十分な効果は見込めません。

医療従事者及び、開発メンバー双方が越境してドメイン知識をインプットして一緒にサービス開発が出来る状況を目指しましょう。その努力が出来なければ、その代償は後からプロダクトの失敗という形で被ることになります。

7. 活用するはずのデータが実は価値がなかった

原因 チームに臨床力が足りなかった

ヘルスケア領域のマネタイズの手段として、サービス内で得られたデータを活用して、次の展開を目指すのはよくある手段だと思います。

しかし、ヘルスケア領域のデータの臨床活用はそれなりにハードルが高く、データを集めたものの、結局どれも使えないデータだったということは十分に起こり得ます。

対策 ビジネスモデルによっては最初から専門家をチームに加える

データ活用に関するビジネスモデルを想定している場合は、出来るだけ早くシステム要件の決定などのタイミングから、サービス開発に加わってもらう事が必要です。

どうすれば臨床活用可能なデータになるのかは、研究領域及び製薬業界出身者などがいないと難しい側面があります。


以上、ヘルスケア領域におけるプロダクト開発の落とし穴についてでした。今後も引き続き市場毎、対象疾患毎の視点から遠隔医療に関する記事を公開してく予定です。
ご指摘・ご意見等ありましたら、是非Twitterの方に直接お声がけください。

https://twitter.com/aritaku03



この記事が気に入ったらサポートをしてみませんか?