Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

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

More Decks by PharmaX(旧YOJO Technologies)開発チーム

Other Decks in Technology

Transcript

  1. (C)PharmaX Inc. 2023 All Rights Reserve 6 LINEから利用できるバーチャルな薬局 最短 即日

    ※ お薬をもっと手軽に、もっと安心して受け取れる「YOJO薬局」 お薬はお家までお届け LINEで薬剤師にいつでも相談 好きなときにお薬の説明 ※東京23区内のみ
  2. (C)PharmaX Inc. 2023 All Rights Reserve 7 ソフトウェアに閉じないプロダクト開発 独自の薬局オペレーションシステムを構築し、最適化されたオンライン薬局を実現 ×

    自社薬局をプロトタイプラボ化 ソフトウェア オペレーション リモート 薬剤師組織 薬局業務を効率化す るオペレーションシス テム(薬局OS) 質の高い患者さま対応 のためのオンライン特 化組織 対人業務の質を高め るための対物業務効 率化 「ソフトウェア×オペレーション×薬剤師組織」を プロダクトとして開発
  3. (C)PharmaX Inc. 2023 All Rights Reserve 10 LINE上でのチャットを通じて薬剤師と会話 日々の相談や健康状態に応じて、 漢方・サプリメントを購入

    使い慣れたUI上から手軽に細かく体質チェック 薬剤師から漢方・サプリのご提案 そのほか健康相談やオンラインでの処方箋受付 YOJOのオペレーションシステム 1 2 3 患者向けチャットシステム
  4. (C)PharmaX Inc. 2023 All Rights Reserve 13 ローンチ当初の構成 • フロントエンドは2010年代によく見た既視感のあるUI

    ◦ ERB(テンプレートエンジン) + webpacker & Vue.js on Rails • PaaS(Heroku)を利用した運用コストの少ないサーバー群で構成
  5. (C)PharmaX Inc. 2023 All Rights Reserve 15 管理画面リプレイス後 • フロントエンドにはNext.js

    + GraphQLを採用し、インフラもvercelに切り出した ◦ SPAでなめらかな操作性を実現 • チャットをFirestoreに保存することで、リアルタイムでチャットを表示可能に
  6. (C)PharmaX Inc. 2023 All Rights Reserve 16 管理画面のリプレイスに至る意思決定 • 管理画面は創業間からスピード重視でテンプレートエンジンで作られており、機能も継ぎ足しで

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

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

    フロントエンド バックエンド 技術スタック サービスに取り込むべき技術をプロダクト横断的に議論する場を設け、新しい技術も積極的に採用
  9. (C)PharmaX Inc. 2023 All Rights Reserve 20 PharmaXが行ってきたYOJO事業のリプレイス一覧 • 管理画面をRailsのERB(テンプレートエンジン)からNext.js

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

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

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

    2023年 後半)から、ビジネス的には△△に注力するということが分かっているのであれば、その時期まで には□□のリプレイスをした方がいいという議論をするべし • なぜそのリプレイスが必要なのか?は、その時期ごとのビジネス的な重点ポイントと紐付けて議 論すべし ◦ 特に目玉となる機能実現のためにリプレイスせざるを得ないのであれば簡単 ▪ 「この機能を実現するために構成を変更すれば、工数はざっくり 1/3ぐらいになります」 というようなコミュニケーションができる ◦ 仮に機能とは紐づけられなくても、将来的な変更容易性や工数の削減などとは紐づけて語 る必要はある 日頃からの負債の返済も重要だが、特にリプレイスのような大規模改修はどこかのタイミングで機能拡張を止めて差し込む必要がある ため、なぜ今なのか?の論理が重要
  13. (C)PharmaX Inc. 2023 All Rights Reserve 26 必要な時にリプレイス可能な文化を創る ビジネス的な意思決定と技術的意思決定を常にセットで語り、エンジニア以外のメンバーも現状の技術的リスクや将来のリプレイスの 可能性を議論できる組織にする必要がある

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