Startup Tech Live_FD Sagaの再理解とアーキテクチャ選択

＜登壇資料＞
Startup Tech Live
医療DXをリードする3社が考えるプロダクト・アーキテクチャ
https://gcp-tech.connpass.com/event/267313/

Transcript

1. 1 FD Saga の再理解と アーキテクチャ選択 医療DXをリードする3社が考える プロダクト・アーキテクチャ CTO 宮田芳郎 2022 年 12月6日
2. 2 本日のテーマ x
3. 3 書籍の概要 具体的なコンテキストに沿って アーキテクチャの議論を進める https://speakerdeck.com/snoozer05/20221129-software-architecture-the-hard-parts?slide=19 https://speakerdeck.com/snoozer05/20221129-software-architecture-the-hard-parts?slide=22 今日は書籍の内容については説明しないため、内容について知りたい方は 翻訳者 島田浩二 さんの スライドをご参照ください 翻訳者 島田浩二 さんの スライド「ソフツェアアーキテクチャ ハードパーツ」より 翻訳者 島田浩二 さんの スライド「ソフツェアアーキテクチャ ハードパーツ」より
4. 学んだこと、考えていることの共有 4 資料の目的 • 現在進行形のもの • 現時点の理解・構想です • ここは、もっとこう考えると良いのでは? フィードバック、アドバイス頂けると嬉しいです
5. 5 私の発表の範囲 https://speakerdeck.com/snoozer05/20221129-software-architecture-the-hard-parts?slide=25 翻訳者 島田浩二 さんの スライド「ソフツェアアーキテクチャ ハードパーツ」より
6. 6 自己紹介
7. 自己紹介:宮田芳郎 ex: ガラパゴス(創業者) (このサービスについては私は何もしていないですが、嬉しかったです)
8. 自己紹介:宮田芳郎 ex: COMPASS 開発責任者 全国シェア 12% (公立小中学生約800万人) 2021/4にリリースしたQubena小中5教科
9. 自己紹介:宮田芳郎 now: ファストドクターテクノロジーズ CTO
10. 1. アーキテクチャ背景 a. ファストドクターの課題 b. ファストドクターのサービスについて 2. FD(Fast DOCTOR) Saga a. コンポーネント b. 課題 c. 将来構想とデータ上の特徴 3. 現状のアーキテクチャ選択 a. MicroService on TypeScript + Classic Stack 4. 悩んでいる点 10 AGENDA
11. 1. アーキテクチャ背景 a. ファストドクターの課題 b. ファストドクターのサービスについて 2. FD(Fast DOCTOR) Saga a. コンポーネント b. 課題 c. 将来構想とデータ上の特徴 3. 現状のアーキテクチャ選択 a. MicroService on TypeScript + Classic Stack 4. 悩んでいる点 11 AGENDA
12. ©2022 FastDOCTOR Inc. All rights reserved..
13. ©2022 FastDOCTOR Inc. All rights reserved.. 審査員からの評価コメント 夜間・休日の時間外救急のプラットフォームとし て、症状に応じて救急病院案内や往診、オンライ ン診療など適切な医療を選択できるように支援 することで、救急医療の新しい選択肢となるサー ビスに先鞭をつけたこと、コロナ禍においてそうし た救急医療の社会的な期待に応えていることが 高く評価された。また、医療機関や行政との連携 による医師や看護師の確保や、患者からの診察 評価フィードバックを品質改善に活用する等によ り、地道で丁寧なサービスデザインがなされてい る点も評価された。
16. 16 2024年問題: 医師の時間外労働の上限規制 医師の働き方改革について - 厚生労働省 https://www.mhlw.go.jp/content/10800000/000991166.pdf
17. ©2022 FastDOCTOR Inc. All rights reserved..
18. 課題③ 社会保障における医療・介護費が増大 超高齢社会の進行が国の財政を圧迫 年金受給年齢は引き上げされ、支給額は現在の半分になることが予測されているため伸び率が低い一方で、医療・介護費は大幅増となり、社会保 障費を圧迫している要因に。 
 出典：2040年を見据えた社会保障の将来見通し（議論の素材） －概要－（内閣官房・内閣府・財務省・厚生労働省　平成 30年5月21日） 要修正 出典：2040年を見据えた社会保障の将来見通し (議論の素材) ©2022 FastDOCTOR Inc. All rights reserved..
19. 生産年齢人口が7500万人→6000万人に減少 医療+介護費は50兆円→95兆円に倍増 課題の整理 2022年 → 2040年 19 日本社会の持続可能性のため テクノロジーを駆使した医療/介護の生産性革新が必要 2022年 → 2040年
20. 1. アーキテクチャ背景 a. ファストドクターの課題 b. ファストドクターのサービスについて 2. FD(Fast DOCTOR) Saga a. コンポーネント b. 課題 c. 将来構想とデータ上の特徴 3. 現状のアーキテクチャ選択 a. MicroService on TypeScript + Classic Stack 4. 悩んでいる点 20 AGENDA
21. サービス全体像 toC toG toB クリニック ポータル toC コールセンター 自治体 コールセンター 法人事業部 コールセンター フロントオペレーション バックエンドオペレーション 薬剤管理 備品管理 労務管理 医師採用支援 フォローアップ 保険証回収 医師シフト管理 ドライバーシフト管理 レセプト請求の精算管理 往診バッグのパッキング 薬剤発注 医師面談 死亡診断書 等の提出 発生届 疑義照会 幹となる業務フロー
22. ©2022 FastDOCTOR Inc. All rights reserved..
23. 修正済 •プラットフォーム利用件数（往診・オンライン診療） 診療対応エリアの拡大とともに、プラットフォーム利用数も増加 2022年 2020年 2021年 2022年 ©2022 FastDOCTOR Inc. All rights reserved..
24. VISON2030 1億人のかかりつけ機能を担う 05 ファストドクターのこれから •ビジョンについて 広域で“生活者の不安と医療者の負担をなくす”ためのアップデート VISON2025 不要な救急車搬送を3割減らす 厚労省の医療計画の核となる「 5疾病6事業および在宅医療」 地域包括的に 事業を推進 救急医療の領域を超えて、5疾病6事業および在宅医療の全 般で”医療”インフラとしての使命を発揮 ©2022 FastDOCTOR Inc. All rights reserved..
25. 1. アーキテクチャ背景 a. ファストドクターの課題 b. ファストドクターのサービスについて 2. FD(Fast DOCTOR) Saga a. コンポーネント b. 課題 c. 将来構想とデータ上の特徴 3. 現状のアーキテクチャ選択 a. MicroService on TypeScript + Classic Stack 4. 悩んでいる点 25 AGENDA
26. 26 FD Saga の コンポーネント構造 アプリ 患者マイページ 申込 サイト 自治体 申込 サイト1 自治体 申込 サイト2 Line Bot 受付コールセンター (診察前) 往診コーディネータ オンライン診療 コーディネータ 往診診察 オンライン診察 診療点数計算 院内処方 医療事務 院外処方 請求 オペレータ管理 医師管理 ドライバー管理
27. 27 FD Saga の アーキテクチャ アプリ 患者マイページ 申込 サイト 自治体 申込 サイト1 自治体 申込 サイト2 Line Bot 受付コールセンター (診察前) 往診コーディネータ オンライン診療 コーディネータ 往診診察 オンライン診察 診療点数計算 院内処方 医療事 務 院外処方 請求 オペレータ管理 医師管理 ドライバー管理 データベース クリニック向け モノリシック アーキテクチャ(一部サービスベース)
28. 1. アーキテクチャ背景 a. ファストドクターの課題 b. ファストドクターのサービスについて 2. FD(Fast DOCTOR) Saga a. コンポーネント b. 課題 c. 将来構想とデータ上の特徴 3. 現状のアーキテクチャ選択 a. MicroService on TypeScript + Classic Stack 4. 悩んでいる点 28 AGENDA
29. 29 FD Saga の 課題① アプリ 患者マイページ 申込 サイト 自治体 申込 サイト1 自治体 申込 サイト2 Line Bot 受付コールセンター (診察前) 往診コーディネータ オンライン診療 コーディネータ 往診診察 オンライン診察 診療点数計算 院内処方 医療事務 院外処方 請求 オペレータ管理 医師管理 ドライバー管理 ①業務の幅が広い
30. 30 FD Saga の 課題① アプリ 患者マイページ 申込 サイト 自治体 申込 サイト1 自治体 申込 サイト2 Line Bot 受付コールセンター (診察前) 往診コーディネータ オンライン診療 コーディネータ 往診診察 オンライン診察 診療点数計算 院内処方 医療事務 院外処方 請求 オペレータ管理 医師管理 ドライバー管理 ①業務の幅が広い これまでの対処 少数精鋭のエンジニアがDRYに効率良く多様な業務を記述
31. 31 FD Saga の 課題② アプリ 患者マイページ 申込 サイト 自治体 申込 サイト1 自治体 申込 サイト2 Line Bot 受付コールセンター (診察前) 往診コーディネータ オンライン診療 コーディネータ 往診診察 オンライン診察 診療点数計算 院内処方 医療事 務 院外処方 請求 オペレータ管理 医師管理 ドライバー管理 新サービス申込みサイト① 新サービス①用 周辺業務 ②新サービス追加時に各業務に影響が出る
32. 32 FD Saga の 課題③ アプリ 患者マイページ 申込 サイト 自治体 申込 サイト1 自治体 申込 サイト2 Line Bot 受付コールセンター (診察前) 往診コーディネータ オンライン診療 コーディネータ 往診診察 オンライン診察 診療点数計算 院内処方 医療事 務 院外処方 請求 オペレータ管理 医師管理 ドライバー管理 新サービス申込みサイト① 新サービス①用 周辺業務 ③新サービス立ち上げは平行する 新サービス②用 受付業務 新サービス②用 フォローアップ業務
33. 33 FD Saga の 課題④ https://www.mhlw.go.jp/content/000620995.pdf オンライン診療の特例的解禁 2020年4月10日 厚生労働省事務連絡 ファストドクター オンライン診療サービスリリース 2020年4月16日 6日後 ④数日でリリースしたい • オペレーションのみで回すことも • 管理用のスプレッドーシートを作ることも • 最低限の機能を開発することも ※ 必ずしも開発することを意味しない
34. 34 FD Saga の課題⑤ ⑤社内人員が急に増加する → 少数精鋭のエンジニアがDRYに効率良く多様な業務を記述、の アプローチが維持しづらい
35. 1. アーキテクチャ背景 a. ファストドクターの課題 b. ファストドクターのサービスについて 2. FD(Fast DOCTOR) Saga a. コンポーネント b. 課題 c. 将来構想とデータ上の特徴 3. 現状のアーキテクチャ選択 a. MicroService on TypeScript + Classic Stack 4. 悩んでいる点 35 AGENDA
36. 36 今後の構想 現状のシステムは「急性期」向 け。別の業務が登場する見込 み。
37. 主要なアクター x 業務 37 FD Saga の データ上の特徴 患者 医師 オペレータ ヒアリング 問診 診察(往診) ドライバー 診察(On) バックオフイ ス系
38. 38 データのあり方の見込み 患者A 診療科1 診療科2 診療科3 診療科4 患者B ロジックはある患者の 他業務・システムのデータには 強い関心がある(持ちたい) ロジックは他の患者のデータには ほとんど関心が無い (集計業務は除く) ロジックごとにデータへの関心のばらつきが強い見込み
39. 1. アーキテクチャ背景 a. ファストドクターの課題 b. ファストドクターのサービスについて 2. FD(Fast DOCTOR) Saga a. コンポーネント b. 課題 c. 将来構想とデータ上の特徴 3. 現状のアーキテクチャ選択 a. MicroService on TypeScript + Classic Stack 4. 悩んでいる点 39 AGENDA
40. 40 現状のアーキテクチャ選択のアプローチ アーキテクチャ決定 開発戦術を立てる 未来予想図を描いて 枠組みを決める +
41. 41 現状のアーキテクチャ選択 Classic Stack Next Stack Database ①新モジュール ②新モジュール ③ ④ ①ベースプロジェクトを作る → ②新規のモジュールで形にする → ③既存のモジュールを載せ替えていく Now!
42. 選択理由 • TypeScriptなのは? ◦ 型がついているため、新規参入者にやさしい(と思う) ◦ Webフロントではデファクトであり競技人口が多い • フロントもバックエンドもTypeScriptなのは? ◦ 統一出来ると、フロント/バックのチームを柔軟に組める ◦ API仕様のコミュニケーションがPRで済む • VueJSなのは? ◦ 社内で使われていたため • NestJSなのは? ◦ Nodeのフレームワークで上から下までの充実度が高いと感じた ◦ TypeORMがあってRDBをDBにしたときに、Railsと近しい開発プロセスを取れる • API通信は? ◦ 現状RESTのAPI 42 現状のアーキテクチャ選択
43. 1. アーキテクチャ背景 a. ファストドクターの課題 b. ファストドクターのサービスについて 2. FD(Fast DOCTOR) Saga a. コンポーネント b. 課題 c. 将来構想とデータ上の特徴 3. 現状のアーキテクチャ選択 a. MicroService on TypeScript + Classic Stack 4. 悩んでいる点 43 AGENDA
44. アーキテクチャ量子 • アーキテクチャ量子 ◦ 他のモジュールに影響を与えないリリース可能単位 ◦ マイクロサービスにDBが属していれば、基本的にリリース可能と思う ◦ API通信形式の大幅な変更や同期的なマイグレーションをどうするか → 現状は利用していないがKubernetes でサービス間のバージョン、起動順序をコントロールする必 要が出てきそう 44 悩んでいる点
45. 以上です 45