難しいから面白い！医薬品×在庫管理ドメインの複雑性と向き合い、プロダクトの成長を支えるための取り組み / Initiatives to Support Product Growth

プロダクトエンジニアが語る！医療、決済、物流、不動産ドメイン
https://openlogi.connpass.com/event/326081/
での登壇資料です

Transcript

1. 日本の医療体験を、しなやかに。 © KAKEHASHI Inc. 2024/09/05 プロダクトエンジニアが語る！医療、決済、物流、不動産ドメイン 株式会社 カケハシ 松本 明紘 難しいから面白い！ 医薬品×在庫管理ドメインの複雑性と向き合い、 プロダクトの成長を支えるための取り組み
2. 自己紹介 もっち(@mottyzzz) 松本 明紘 株式会社 カケハシ(2023年2月〜) • AI在庫管理、新規事業 • バックエンドに軸足を置くテックリード 最近 • 仕事中も歩くようにしたことで 運動の習慣ができてきた
3. 日本の医療体験を、 しなやかに。 カケハシは、調剤薬局DXを入り口に 日本の医療システムの再構築を目指す ヘルステックスタートアップ
4. 患者 薬局 医薬品 サプライチェーン Vision 4 明日の医療の基盤となる、エコシステムの実現。
5. 日本スタートアップ大賞2024 厚生労働大臣賞受賞 日本スタートアップ大賞は、次世代のロールモデル となるような、インパクトのある新事業を創出した 起業家やスタートアップを表彰し称える制度です。 カケハシのプロダクトはすでに薬局の２０％でご利 用いただいており、医療・福祉分野におけるイノ ベーションの創出や発展に対する寄与を評価いただ きました。
6. カケハシの5つのプロダクト 今月リリース三周年 🎉🎉🎉
7. 医薬品×在庫管理
8. 薬局の在庫管理の業務 在庫管理 薬局 在庫が 増える 発注 発注(電子・FAX) 納品 医薬品卸 • 卸への発注(購入)によって在庫が増える 在庫が 減る 処方箋 処方 医薬品 患者さん • 患者さんへの処方(販売)によって在庫が減る
9. 処方と発注の医薬品の特徴(調剤方法の違い) • 処方の医薬品と発注の医薬品が一致しない セルベックスカプセル 50mg 処方の粒度 処方する種類が多くてたくさ んの薬を飲まなきゃいけない ので1回飲む単位に小分けして お渡ししよう！ PTP 10カプセルシート 10枚入り PTP 10カプセルシート 100枚入り PTP 21カプセルシート 10枚入り PTP 21カプセルシート 50枚入り バラ 500カプセル入り 1瓶 バラ 3000カプセル入り 1瓶 PTP 10カプセルシート 300枚入り PTP 21カプセルシート 150枚入り 発注の粒度 処方された薬は1種類だし PTPシートをそのままお渡し しよう！ • 処方箋の内容によって薬剤師さんの判断が入り、選択する調剤方法が異なる
10. 処方と発注の医薬品の特徴(患者さんの好み) • 処方の医薬品と発注の医薬品が一致しない • 処方では効能のみ気にするが、患者さんにとっては味なども重要な要素 エンシュア・H 処方の粒度 バニラ味 24缶入り 発注の粒度 今回はどの味になさいます か？ コーヒー味 24缶入り バナナ味 24缶入り 黒糖味 24缶入り メロン味 24缶入り ストロベリー味 24缶入り 抹茶味 24缶入り 画像の出典： https://www.abbott.co.jp/our-product s/ensure-h.html
11. 在庫管理と発注の医薬品の単位 • 発注の医薬品の単位は細かすぎて、在庫管理には向かない セルベックスカプセル 50mg PTP 10カプセルシート 10枚入り PTP 10カプセルシート 100枚入り PTP 21カプセルシート 10枚入り PTP 21カプセルシート 50枚入り バラ 500カプセル入り 1瓶 バラ 3000カプセル入り 1瓶 PTP 10カプセルシート 300枚入り PTP 21カプセルシート 150枚入り 処方の粒度 発注の粒度 結局、 PTP 10カプセルシートは何枚 残ってるの？ どれを何個持っていても 違いはない PTP 10カプセルシート PTP 21カプセルシート バラ 在庫管理に適切な粒度で モデル化 • AI在庫管理では在庫管理に適切な粒度で管理できるようにモデル化をしている
12. 医薬品の単位の違いに対するAI在庫管理の対応 • 処方箋のデータからは、どの医薬品の在庫を実際に減らし たかというのが分からない ◦ 塗り薬をミックスしたり、錠剤を粉砕機で粉にすることもある ◦ 正確な単位で在庫を減らすというのは難しい AI在庫管理ではその薬局が取り扱っている医薬品や 過去の発注履歴などから予測している
13. プロダクトのフェーズも変化してきた
14. プロダクトのフェーズの変化 • これまではSMBへの導入が中心 • 徐々に導入いただく薬局さまも増え、その規模も大きく なってきている • エンタープライズ特有の機能を注力して開発している最中
15. これまでと異なる医薬品の単位の重要性 • エンタープライズへの導入で在庫管理の正確性がより重要になってきた セルベックスカプセル 50mg PTP 10カプセルシート 10枚入り PTP 10カプセルシート 100枚入り PTP 21カプセルシート 10枚入り PTP 21カプセルシート 50枚入り バラ 500カプセル入り 1瓶 バラ 3000カプセル入り 1瓶 PTP 10カプセルシート 300枚入り PTP 21カプセルシート 150枚入り 処方の粒度 発注の粒度 PTP 10カプセルシート PTP 21カプセルシート バラ 在庫管理したい単位 実際のモノの粒度 ロット番号：XXX001 有効期限：2024/12/16 購入時原価：1280円 置き場所：棚001 ロット番号：XXX002 有効期限：2025/02/04 購入時原価：1340円 置き場所：棚002 ロット番号：XXX003 有効期限：2025/03/09 購入時原価：1140円 置き場所：棚001 在庫量の最適化だけではな く、資産管理としての在庫管 理が重要になってきた • これまではあまり重要視していなかった医薬品の単位も重要になった 処方や発注で 意識したい単位 在庫管理(資産管理) したい単位
16. 医薬品×在庫管理ドメインのプロダクトの難しさ • 医薬品自体の複雑さ • 同じ業務でも薬局ごとに異なる業務フローがあり、 どれが一般的なものか判断が難しく抽象化もしづらい • 複雑な医薬品や業務をとりまく課題にDeep Diveすると、 どうしても解決策も複雑になりがち • フェーズの変化による新たな発見
17. AI在庫管理の開発における課題
18. プロダクトの課題 • 機能間やデータ間の結合度が高くなってきている • 機能追加の影響範囲が広くなり、調査や動作確認などにコスト がかかっている • 考慮漏れによってリリース前に慌てたり、ヒヤリハットの件数 が増えてきた 品質を高めながら長期的に保守するために、 複雑になったプロダクトをシンプルに再構築していく必要性が出てきた 大きなリアーキテクチャが必要
19. カケハシはスタートアップ カケハシはスクラムの会社
20. まだまだ状況も組織も変化していく 大きな課題だからこそ小さく進めたい
21. 変化を味方につけてその循環の中で小さく進める • 機能開発は止めない 開発プロセスの中で自然とよくしていきたい • 短期的な効果を自分たちも実感しながら、 取り組み方自体もより良くしながら進めたい • そのときのベストなアーキテクチャよりも 今後も変化できる常にベターなアーキテクチャ そういうふうにプロダクトを成長させたい
22. 複雑さの中で プロダクトを成長を支えるための 3つの取り組みと小さく進める方法
23. 3つの取り組み 1. 外部仕様の複雑性を可視化しシンプルにする 2. すでに複雑になってしまったコンポーネントに対する リファクタリング 3. 自動テストの分かりやすさの向上 考慮すべきことを減らし てアウトプットの質をス ピードを維持 ねらい① 考慮漏れが原因によるイ ンシデント発生を減らす ねらい② (自分たちを含む)将来の 開発者が自信をもって コードを変更できる ねらい③
24. 外部仕様の複雑性を可視化して シンプルにする
25. デシジョンテーブルで既存仕様の共通認識を作る • お客様にも説明しづらい仕様になってきている • そこに機能を追加するとさらに複雑にしてしまう可能性がある • 機能開発のタイミングでデシジョンテーブルで既存仕様の複雑さを可視化 • ここにこの仕様を追加したらもう頭で理解できないよね、とか、先にUIを改善して から取り組もうとか、そんな会話をロールを超えてできる デシジョンテーブル プロダクトマネージャー エンジニア 外部仕様の複雑性を可視化しシンプルにする
26. 実際に作成しているデシジョンテーブル 外部仕様の複雑性を可視化しシンプルにする
27. • 抽象データモデルや物理データモデルなどで プロダクトマネージャーとエンジニアとの共通認識を作る活動 をしたことはあった ◦ 既存の複雑性を表現できずに課題感の認識合わせが難しかった ◦ 理想を描いたり業務理解にはよかったが、 既存実装とのギャップが大きくなりすぎて進めなくなった なぜデシジョンテーブルなのか デシジョンテーブルで既存の仕様を正確に認識して会話。 価値の低い既存仕様を削除していくなどの 大胆なアプローチにもつながる！ 外部仕様の複雑性を可視化しシンプルにする
28. • デシジョンテーブルを網羅的に作成するのは既存仕様をすべて理解し て記載する必要があり重いプロセスになりがち • ルールにはせず、ガイドラインとしてプロセスに組み込む 無理なくデシジョンテーブルを作成していく コミュニケーションガイド 説明 変更のしやすさ、変更の頻度 ルール 原則として守るべきもの 低 ガイドライン 理由があれば守らなくていい 守った方が多くの場合で良い効 果がある 中 Best Current Practice(BCP) ガイドラインほどではないけど 今一番良いプラクティス 高 外部仕様の複雑性を可視化しシンプルにする
29. すでに複雑になってしまった コンポーネントに対する リファクタリング
30. 既存のモジュール構成 すでに複雑になってしまったコンポーネントに対するリファクタリング ユース ケース 共通処理 ユース ケース ユース ケース ユース ケース ユース ケース データ 医薬品 データ データ データ データ 在庫管理 発注 処方 その他機能 ユース ケース ユース ケース データ データ • トランザクションスクリプトの構成 • 一つ一つのユースケースの開発は分かりやすく最速 シンプルな時期は良かったが、それぞれの責務の範囲を超えて複雑化
31. 将来のモジュール構成 • 業務領域ごとにモジュール化、責務で適切にレイヤー化 • 業務ロジックを抽象データモデルとして表現 ユース ケース ユース ケース ユース ケース ユース ケース ユース ケース データ 在庫品目とし ての医薬品 データ 購入対象とし ての医薬品 データ 処方対象とし ての医薬品 データ データ 抽象 データ 抽象 データ 抽象 データ 抽象 データ サービ ス サービ ス 在庫管理 発注 処方 その他機能 データ データ 抽象 データ その他医薬品 データ ユース ケース データ ユース ケース 抽象 データ 抽象 データ すでに複雑になってしまったコンポーネントに対するリファクタリング
32. 効果の大きいリファクタリングから小さく始める • 静的解析ツール＋αで メトリクスを取得し可視化 • 取得したメトリクスの例 ◦ インポートの数 ◦ クラス数、メソッド数、関数の数 ◦ 変更回数(効果の大きさ) ◦ 循環的複雑度(テスト容易性) ◦ 認知的複雑度(理解容易性) ◦ 保守容易性指数 ◦ データの参照数(データの結合度) すでに複雑になってしまったコンポーネントに対するリファクタリング
33. 自動テストの分かりやすさを 向上させていく
34. 自動テストを分かりやすくするってどういうこと • 開発が特定のメンバーに偏り 属人性が高くなっているコンポーネントが存在 • 理解できているメンバーが限られてしまっていた • そのコンポーネントを開発していないメンバーでも理解でき るようにするために、テスト自体を理解しやすくする 自動テストの分かりやすさを向上させていく
35. 自動テストを分かりやすくするってどういうこと • 既存の自動テストの理解容易性を向上させ、 変更に対して不安なく開発できる状態を目指す ◦ 将来の自分も新規参入者も何を確認しているかが分かる ◦ プロダクトコードを変更した際に、どの振る舞いを満たしている か/どの振る舞いが破壊されたかどうかが一目で分かる テストは知識の塊。 分かりやすいテスト群になることで 機能の分かりやすさも向上する 自動テストの分かりやすさを向上させていく
36. Gherkin記法によるテストの理解容易性の向上 Scenario: 同一処方箋番号の複数の処方箋データファイルが複数回取り込まれないこと Given: カケハシ薬局が存在する And: 処方箋の対象薬品のマスタが存在する And: 処方箋データファイルをアップロードする And: 同一処方箋番号の別の処方箋データファイルをアップロード When: 処方箋データ取り込み処理を実行する Then: 処方箋データが1件登録される And: 処方箋明細データが登録される And: 医薬品在庫出庫データが登録される And: 医薬品在庫出庫データが処方された医薬品に紐づいている And: 医薬品在庫は更新されない 前提条件をGivenに記述 期待動作をThenに記述 テスト実行対象の実行を Whenに記述 処方箋データ取り込みのテストに対するGherkin記法の記述例 自動テストの分かりやすさを向上させていく
37. 属人性が高いところから小さく始める 自動テストの分かりやすさを向上させていく • Gitの変更ログから、コンポーネン トごとに属人性(開発者がどのくら い偏っているか)を確認 • 重要なコンポーネント、かつ、1〜2 人で偏っているところから優先して 理解容易性を上げる活動を実施
38. まとめ
39. まとめ • 医薬品×在庫管理ドメインの難しい課題にDeep Diveする ことで、その解決策となる機能も複雑になってきている • 紹介したような取り組みによって、その複雑さの中でも少 しずつプロダクトを良い状態に変えられている • 小さく進めていることで、障害対応や重要な機能開発など の他の取り組みの温度感が上がったタイミングでも無理な く進められている
40. 複雑だから面白い！ • 変化が生き物のようでプロダクトを育てている感覚 • 課題や複雑性に本気でDeep Diveできて エンジニアリングでどんどん良くできるのが楽しい • プロダクトへの愛着が湧くので、難しい課題でもなんとか してやろうって思える。複雑性すらも可愛く見えてくる
41. これからも医療体験が日々進化する 世界の実現のために、プロダクトを 成長させていきます