FD Saga の再理解とアーキテクチャ選択 / Fast DOCTOR Technologies
こんにちは、Startup Tech Live事務局です。「エンジニア組織のグロースに必要な知見の流通」をテーマに様々なイベントを開催しております。
2022年12月に開催したオンラインイベント「医療DXをリードする3社が考えるプロダクト・アーキテクチャ〜ソフトウェアアーキテクチャ・ハードバーツから学んだこと〜」のイベントレポートになります。今回はFast DOCTOR Technologies社CTOの宮田氏による「FD Saga の再理解とアーキテクチャ選択」です。是非ご覧ください。
スピーカー
私立開成高校、東京工業大学情報系学科大学院卒。製造業系のコンサルティング会社インクスに入社しソフトウェアエンジニアの経験を積む。2009年にインクスの同期4人で株式会社ガラパゴスを創業。 Qubena小中5教科の開発責任者を経て、2021年12月、ファストドクター株式会社に技術開発部長として入社、現在は同社CTOとして技術チームを牽引。
Fast DOCTOR Technologies CTO 宮田芳郎 氏（以下、宮田）：当社はこれまでテックカンパニーという印象があまりなかったかもしれませんが、今月（2022年12月）より「Fast DOCTOR Technologies」という組織に改組しました。当社がテックカンパニーだということを発信し、アーキテクチャ的な特徴も作っていきたいなと思い「FD Saga の再理解とアーキテクチャ選択」というテーマでお話することにしました。
まず書籍の概要について、翻訳者の島田浩二さんのスライドの抜粋で説明をさせてください。
この書籍は、具体的なコンテキストに沿ってアーキテクチャの議論を進めてみる内容になっています。特にこの基本的な設計以降のことは、ほぼトレードオフの解決になることを説明している本です。様々な制約に揉まれながらプロダクトをリリースしていかなければならない我々にとっては、とても重要な示唆を与えてくださる本だと思っています。
本日の資料の内容としては、学んだことや考えていることの共有がメインと本日の資料の内容としては、学んだことや考えていることの共有がメインとなります。このスライドは、色々悩みましたが、実際に現在進行中のものだけを書いています。
ただ現時点の理解・構想として書いているので、フィードバック・アドバイス・疑問点などがありましたら自由に意見をいただけますと嬉しいです。
私は今回、特にこの本の前半部分に着目して色々考えました。
特にモノリシックなシステムをどう分解していくのか、自分のシーンに当てはめて考えてみました。今の我々のシステムがモノリシックであり、チームが増えていくことで課題が出てくると思ったためです。
１．アーキテクチャ背景
ファストドクターは、夜間往診とオンライン診療のプラットホームです。最近、色々と賞も頂いております。特に最近のGood NewsはForbes JAPAN「日本の起業家ランキング2023」1位を頂いたことです。僕としても非常に名誉なことでした。
ファストドクターの課題
取り組んでいる社会課題についてご紹介します。高齢化社会で医療リソースが不足しており、個人の医療費や介護費が厳しい状況になろうとしている中、日本社会の持続可能性のためテクノロジーを駆使した医療/介護の生産性革新に取り組んでいます。
次にアーキテクチャの話になります。皆さんにも知って頂きたいと思っているのですが、2022年から2040年にかけて生産年齢人口7,500万人から6,000万人に減少し、医療+介護費は50兆円から95兆円へと倍近く増えることが予測されています。
今日一緒に登壇している医療系のスタートアップの皆さんは、このテーマに取り組んでいく同志だと思っています。
ファーストドクターについて
ファーストドクターのサービスについてご紹介します。複数のサービスの入り口があり、toC（コンシューマー向け）・toG（自治体向け）・toB（クリニック向け）になっています。それぞれ似たような幹となるサービスフロー、周辺業務、バックエンド、オペレーションがあります。これらが我々の業務自体の複雑さを表しています。
またありがたいことにお客様が増えております。合わせてトランザクションも増えるため、色々と対策をしなければいけない状況です。
更にビジョンも今月から新しく追加されました。
これまでは不要な救急車搬送を3割減らすことに取り組んできました。こちらついては、手応えがある状況になりつつあります。ここからはVISION2030として1億人のかかりつけ機能を担うというビジョンを持ち、救急だけではなくて5疾病6事業および在宅医療という幅広いところを押さえていこうとしています。
このチャレンジを実現するためにもアーキテクチャ上においても考えるべきことがあります。
２．FD(Fast DOCTOR) Saga
コンポーネント
Fast DOCTOR Sagaについてです。
こちらのスライドはコンポーネント構造になります。今回ご紹介している書籍の中にあったSagaのコンポーネントが書いてあるところを真似て書いてみました。
申し込みのフェーズや患者様が触るところが日々増加し様々な種類が発生しています。
患者マイページという横串で共通化ができているところもありますが、申し込み自体も増加しています。
その他、コールセンターの業務、往診とオンライン診療が我々の並列の大きな業務としてあります。また、薬を処方する業務や診療報酬の計算、受付から請求までの間に医療事務の確認作業、それからオペレーター管理で医師管理にドライブ管理などのリソースの管理業務があります。
現状はモノリシック アーキテクチャになっています。一部サービスベースと書いてあるのは、クリニック向きのところはデータベースを共通しつつコードとしては切り分けられているからです。
課題
次に課題についてです。業務の幅が広くて複雑ですが、モノリシックは依存性の解消が、とても課題になってきます。
我々はRailsで作っており、少数精鋭のエンジニアが効率良く書くと結構少ないコードで多様な業務を記述できます。しかし、新しい人が入ってきた時、なかなか慣れにくいという課題もあります。
続きまして、新規サービス追加時に各業務に少しずつ影響が出るのか出ないのかみたいなのがあり、これが毎回難しいなと思うところです。
また新規サービス立ち上げを並行するので、新しいサービスの申し込みの1と2が並立して少しずつ変えて行く必要が出てきたりします。これは我々が耐えないといけないところです。
それからこれはアーキテクチャというよりも、当社の特徴かもしれないですが爆発的なスピードでリリースを出してます。例えば、オンライン診療の特例的解禁が2020年4月10日にされた時、6日後にオンライン診療のサービスをリリースしています。
この期間では開発はできません。そのためオペレーションのみで回す、または管理用のスプレッドシートで回す、そして最低限の機能だけを絞って開発するというオプションをとっています。これが負債化の原因となってしまいます。
また現在ありがたいことに社内人員も急激に増加をしています。これまでいいディシプリンだった少数精鋭のエンジニアがDRYに書くということが維持しづらくなってきています。
将来構想とデータ上の特徴
次に将来の構想についてご紹介します。
現状この赤枠に注力していますが、今後はさらにカバーできる範囲を拡げて、取り組むことを考えています。
続いてデータの特徴についてです。主要なアクターはそこまで多くなく、患者・オペレーター・ドライバー・医師がいます。それぞれの人の間に業務がある構図になっています。
またデータ上の大きな特徴として、ある患者さんの複数の診療科のデータは、横軸ですごく関心があり、ロジックは強くなっています。しかし、ロジック的に他人のデータには全く関心がありません。
将来アーキテクチャを考える時、この特徴をうまく捉えて対応していく必要があります。診療科ごとに恐らくサービスや行動は増えて来るのですが、データベースも分ける必要があります。そして横軸でデータ参照ができる状態にしなければいけないと思っています。
３．現状のアーキテクチャ選択
MicroService on TypeScript + Classic Stack
ここまでお話ししたのが、我々のFD Sagaのこれまでとこれから目指すところの正義でした。これに対しての現時点の選択についてご紹介します。
ここまでの課題を全部捉えているわけではないです。今のアーキテクチャ選択としては未来予想図を描いた上で、開発戦術のあるものを取っていこうとしています。
一気にリアーキテクトすることは難しいです。
今のアプローチとしては、Next Stackという技術選択の中身を選択した上でBASEプロジェクトを作り新しいものから作っていきます。そして、新しいところで形にしていった上で、既存のモジュールを「この部分はそろそろ刷新した方がいいよね」と計画をして書き変えていくアプローチを取ろうとしてます。
今はアーキテクチャを決めて、新規のモジュールで形にするというのに着手し始めているところです。
今の選択として、TypeScriptで表も裏も書くところと、データベースはマイクロサービスごとに持ち、既存のものを基本的にまずは生かすアプローチをしています。周辺を整理しつつ、新しいもので作っていって、2-3年経つとすっかり入れ替わっているという未来を期待しているところです。
TypeScriptにしたのは型が付いているからで、個人的には型が付いてた方が新規参入者に優しいなと思っているからです。WebフロントでTypeScriptはやはりデファクトなので、競技人口も多いです。またフロントバックもTypeScriptで統一できると、フロントとバックのチームを柔軟に組むことができます。
NestJSにしたのは、Railsに近いためです。そして上から下まで充実してるっていうところが選定理由です。
４．悩んでいる点
今悩んでいるのがアーキテクチャ量子です。
書籍にも書いてありましたが、これは他のサービスに影響を与えずにリリース可能な括りをどう捉えるかという話になります。
マイクロサービスでサービスごとにDBを持っていれば、基本的にその単位でリリースできるだろうと思っています。
ただ結構大規模な法律の変更に追随するみたいな時は、同時に出さないといけないんだろうなと感じています。それらをうまく喚起するのはまだ考えられていないので、考えたいと思っています。私の発表は以上となります。
採用情報
ファストドクター 採用情報
Startup Tech Live
こちらのグループはVC「Globis Capital Partners」が主催するTechnologyにフォーカスしたcommunityになります。 スタートアップ×Engineeringに関する情報はもちろん、著名な方の登壇イベント等を発信していきます。
Globis Capital Partnersは日本初の本格的ハンズオン型ベンチャーキャピタルとして1996年に設立しました。 日々次世代のリーディングカンパニーを生み出すためにチーム一丸となり精進しております。
Twittter: https://twitter.com/gcp_byvc
connpass: https://gcp-tech.connpass.com/
この記事が気に入ったらサポートをしてみませんか？