Slide 1

Slide 1 text

PharmaX 事業の成長と技術的チャレンジを 両立させるリプレイスの極意 2023.08.24 #pharmaX_tech_collabo

Slide 2

Slide 2 text

(C)PharmaX Inc. 2023 All Rights Reserve 2 自己紹介 上野彰大 PharmaX取締役・エンジニアリング責任者 マイブームはLLMとRust Twitter:@ueeeeniki

Slide 3

Slide 3 text

3 (C)PharmaX Inc. 2023 All Rights Reserve プロダクトの簡単な説明

Slide 4

Slide 4 text

(C)PharmaX Inc. 2023 All Rights Reserve 4 「薬局」は医療体験の中でも身近な存在 日用品から処方薬まで。「薬局」は皆さまの日常の近くに存在している ドラックストア 調剤薬局

Slide 5

Slide 5 text

(C)PharmaX Inc. 2023 All Rights Reserve 5 医療体験を横断する2つの事業領域 YOJO事業 未病・予防 治療 薬局DX事業

Slide 6

Slide 6 text

(C)PharmaX Inc. 2023 All Rights Reserve 6 LINEから利用できるバーチャルな薬局 最短 即日 ※ お薬をもっと手軽に、もっと安心して受け取れる「YOJO薬局」 お薬はお家までお届け LINEで薬剤師にいつでも相談 好きなときにお薬の説明 ※東京23区内のみ

Slide 7

Slide 7 text

(C)PharmaX Inc. 2023 All Rights Reserve 7 ソフトウェアに閉じないプロダクト開発 独自の薬局オペレーションシステムを構築し、最適化されたオンライン薬局を実現 × 自社薬局をプロトタイプラボ化 ソフトウェア オペレーション リモート 薬剤師組織 薬局業務を効率化す るオペレーションシス テム(薬局OS) 質の高い患者さま対応 のためのオンライン特 化組織 対人業務の質を高め るための対物業務効 率化 「ソフトウェア×オペレーション×薬剤師組織」を プロダクトとして開発

Slide 8

Slide 8 text

(C)PharmaX Inc. 2023 All Rights Reserve 8 KDDI様のオンライン特化型薬局「au薬局」の開業を支援 ※このスライドの撮影および内容の SNS発信はお控えください ※このスライドの撮影および内容の SNS発信はお控えください

Slide 9

Slide 9 text

9 (C)PharmaX Inc. 2023 All Rights Reserve リプレイスで振り返る YOJO事業を支えるシステムとその変遷

Slide 10

Slide 10 text

(C)PharmaX Inc. 2023 All Rights Reserve 10 LINE上でのチャットを通じて薬剤師と会話 日々の相談や健康状態に応じて、 漢方・サプリメントを購入 使い慣れたUI上から手軽に細かく体質チェック 薬剤師から漢方・サプリのご提案 そのほか健康相談やオンラインでの処方箋受付 YOJOのオペレーションシステム 1 2 3 患者向けチャットシステム

Slide 11

Slide 11 text

(C)PharmaX Inc. 2023 All Rights Reserve 11 PSチームと患者をつなぐオペレーションシステム 患者とのスムーズなコミュニケーション 薬剤師向け管理画面 チャット形式での診断・相談・購入 患者向けチャットシステム

Slide 12

Slide 12 text

(C)PharmaX Inc. 2023 All Rights Reserve 12 LINE登録者数〜ローンチ初期〜

Slide 13

Slide 13 text

(C)PharmaX Inc. 2023 All Rights Reserve 13 ローンチ当初の構成 ● フロントエンドは2010年代によく見た既視感のあるUI ○ ERB(テンプレートエンジン) + webpacker & Vue.js on Rails ● PaaS(Heroku)を利用した運用コストの少ないサーバー群で構成

Slide 14

Slide 14 text

(C)PharmaX Inc. 2023 All Rights Reserve 14 LINE登録者数〜管理画面リプレイス期〜

Slide 15

Slide 15 text

(C)PharmaX Inc. 2023 All Rights Reserve 15 管理画面リプレイス後 ● フロントエンドにはNext.js + GraphQLを採用し、インフラもvercelに切り出した ○ SPAでなめらかな操作性を実現 ● チャットをFirestoreに保存することで、リアルタイムでチャットを表示可能に

Slide 16

Slide 16 text

(C)PharmaX Inc. 2023 All Rights Reserve 16 管理画面のリプレイスに至る意思決定 ● 管理画面は創業間からスピード重視でテンプレートエンジンで作られており、機能も継ぎ足しで やってきていたので画面の構成もかなり無秩序だった ○ リモートで薬剤師が医薬品販売のチャット対応するというビジネスモデルが世になかった以上、どのよ うなオペレーションが最適なのかは自分たちでもよく分からなかった ○ 理想のオペレーションがある程度見えてくるまで作り込むのはやめようという意思決定をしていたの で、これ自体は間違ったことではなかった ● ある程度オペレーションが整ったところ & ユーザー数が急増する前に作り直そうというのは合意 できていたので、意思決定自体はそこまで難しくなかった ○ ユーザー数の急激な増加と同時に PS(薬剤師・登録販売者)チームの増加も起こるので、オペレー ションやオンボーディングの負荷を軽減したかった ● 2つの管理画面を並行稼働させることで、旧管理画面からも従来どおりオペレーションできること は担保していたこともあって、ビジネス影響ない形でリリースできた

Slide 17

Slide 17 text

(C)PharmaX Inc. 2023 All Rights Reserve 17 LINE登録者数〜インフラリプレイス期〜

Slide 18

Slide 18 text

(C)PharmaX Inc. 2023 All Rights Reserve 18 インフラリプレイス後 ● バックエンドもフロントエンドもCloud Runをフルに使う構成に ● セキュリティ、分散していたログの集約などによるオブザーバビリティの向上を実現 ● LINEのWebHookの受信に失敗した場合の救済も可能に

Slide 19

Slide 19 text

(C)PharmaX Inc. 2023 All Rights Reserve 19 その他 BI インフラストラクチャー フロントエンド バックエンド 技術スタック サービスに取り込むべき技術をプロダクト横断的に議論する場を設け、新しい技術も積極的に採用

Slide 20

Slide 20 text

(C)PharmaX Inc. 2023 All Rights Reserve 20 PharmaXが行ってきたYOJO事業のリプレイス一覧 ● 管理画面をRailsのERB(テンプレートエンジン)からNext.js & Firestoreへのリプレイス ○ SPAの実現、チャットの管理画面へのリアルタイム反映などを実現 ● 決済システムを決済手段や決済パターンの拡張性のある構成に移行 ○ クレジットカード以外の決済手段やサブスク以外の決済パターンに対応 ● YOJO事業のバックエンドのアーキテクチャを DDDに移行 ○ Rails wayに乗るのではなく、処理の依存関係が分かりやすいように階層化されたアーキテクチャへの 移行も同時行った ● インフラをHerokuからCloud RunメインのGCP構成に移行 ○ 可用性、セキュリティ、オブザーバビリティの向上を実現

Slide 21

Slide 21 text

(C)PharmaX Inc. 2023 All Rights Reserve 21 なぜリプレイスが必要になるのか? ● 特に創業間もないスタートアップでは、ビジネスモデルやプロダクトがどう発展していくのかは誰に も分からない ○ 資金調達したり、ビジネスが伸びて安定してくれば、プロダクトのロードマップとして見通せる期間も 数ヶ月→半年→1年→数年と伸びていく ● 将来の変更を見越して様々な拡張に耐え得る設計にすることは典型的バッドプラクティスで、むし ろこのような意思決定は負債化を招くことの方が多い ○ ある程度以上確からしい将来の拡張を大きく手戻りせずに取り込めることを担保するぐらいがちょうど いい ○ Point of no returnな技術的意思決定だけは慎重に行う必要がある ● リプレイスはビジネスが変化できていることの副産物ぐらいに捉えて、ある程度仕方がないものと 割り切るべきだというのが個人的な意見 ○ スピード vs 品質で語られるようなテストを書くべき等の議論とは全く別問題なので注意 スタートアップのような変化の激しい企業では、ビジネスモデルやプロダクトの発展を読み切ることは不可能に近く、 過去の技術的設計(アーキテクチャやドメインの境界など)が、目指すべきプロダクトの構造とズレてしまう

Slide 22

Slide 22 text

22 (C)PharmaX Inc. 2023 All Rights Reserve 技術的負債の返済やリプレイスの極意 〜実践編〜

Slide 23

Slide 23 text

(C)PharmaX Inc. 2023 All Rights Reserve 23 藪から棒にならないコミュニケーションを心がける ● 技術選定や技術的構成を決める際には、何を得て(スピード等)、何を失っているのかをセットで 社内に発信する ○ 特にマイナス面はきちんと伝える &伝え続ける ■ 「こういう拡張はしづらい構成である」「このようにビジネスが発展すると、〇〇の部分 は△△の方針で作り変える必要がある」 ○ ここは「スピードを優先してかなり雑に作ってる」みたいなカジュアルな議論もする ● 発信する手段は、MTG・スプリントイベントの場だけではなく、日報や timesなどもフル活用する ○ 現時点で想定されるリスクや将来起こりうる技術的意思決定の分岐のパターンを非エンジ ニアにも認識しておいてもらうための工数を厭わない リプレイスせざるを得ないような状況になってからアラートを発するのでは遅いため、将来的にどういう問題が起こるのかを予め発信し ておく必要がある

Slide 24

Slide 24 text

(C)PharmaX Inc. 2023 All Rights Reserve 24 リプレイスはタイミングこそが命 ● (プロダクトのロードマップは本当に必要なのかという議論は別途あるが、)ある時期(例: 2023年 後半)から、ビジネス的には△△に注力するということが分かっているのであれば、その時期まで には□□のリプレイスをした方がいいという議論をするべし ● なぜそのリプレイスが必要なのか?は、その時期ごとのビジネス的な重点ポイントと紐付けて議 論すべし ○ 特に目玉となる機能実現のためにリプレイスせざるを得ないのであれば簡単 ■ 「この機能を実現するために構成を変更すれば、工数はざっくり 1/3ぐらいになります」 というようなコミュニケーションができる ○ 仮に機能とは紐づけられなくても、将来的な変更容易性や工数の削減などとは紐づけて語 る必要はある 日頃からの負債の返済も重要だが、特にリプレイスのような大規模改修はどこかのタイミングで機能拡張を止めて差し込む必要がある ため、なぜ今なのか?の論理が重要

Slide 25

Slide 25 text

25 (C)PharmaX Inc. 2023 All Rights Reserve 技術的負債の返済やリプレイスの極意 〜マインドセット編〜

Slide 26

Slide 26 text

(C)PharmaX Inc. 2023 All Rights Reserve 26 必要な時にリプレイス可能な文化を創る ビジネス的な意思決定と技術的意思決定を常にセットで語り、エンジニア以外のメンバーも現状の技術的リスクや将来のリプレイスの 可能性を議論できる組織にする必要がある ● マネージャーやリーダーと呼ばれる人は、常に技術的意思決定とビジネス的なインパクトと紐づ けて議論をする癖をつける ○ 必ずしも定量的である必要はなく、将来のビジネスの障壁になり得る懸念を言語化する癖 を付ける ● 非エンジニア以外の職種のメンバーの技術的意思決定に対するリテラシーを上げることも自分の 仕事であると捉え、大胆な技術的意思決定もしやすい文化を創る ○ エンジニアがどのようなことを考えて技術的な意思決定をしているのかを分かりやすく伝え ていく ● そもそもリプレイスは起こりうるものなのだという意識付けも常々行う必要がある