プロダクトの成長に合わせたアーキテクチャの段階的進化と成長痛、そして、ユニットエコノミクスの最適化

社会インフラ基盤開発に関わるアーキテクチャ設計を学ぶ会！
https://finatext.connpass.com/event/365430/
での登壇資料です

Transcript

1. ©KAKEHASHI inc. プロダクトの成長に合わせた アーキテクチャの段階的進化と成長痛 そして、ユニットエコノミクスの最適化 2025年8月28日 松本 明紘 社会インフラ基盤開発に関わるアーキテクチャ設計を学ぶ会！
2. ©KAKEHASHI inc. 株式会社 カケハシ(2023年2月〜) • AI在庫管理、新規事業 • バックエンドに軸足を置くテックリード もっち(X: @mottyzzz) 松本 明紘 2 自己紹介 https://speakerdeck.com/kakehashi
3. © KAKEHASHI Inc. All Rights Reserved. ©KAKEHASHI inc. 3
4. ©KAKEHASHI inc. Musubi AI在庫管理(1/2) 4 患者さん・医薬品ごとに、AIが需要予測 めんどうな在庫管理の課題を解決
5. ©KAKEHASHI inc. Musubi AI在庫管理(2/2) 5
6. ©KAKEHASHI inc. 6 AI在庫管理の全体のアーキテクチャ 本日はこの範囲の お話をします https://findy-tools.io/companies/kakehashi/91
7. ©KAKEHASHI inc. 7 ソフトウェアアーキテクチャは変化していく • 事業や組織や技術、トレードオフとなる制約を満たす必要がある • 事業状況、組織構造、技術トレンドなどすべて変化していく 出展： ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making
8. ©KAKEHASHI inc. 8 プロダクトのフェーズと事業や組織的な要件の変化 2020 2021 2022 2023 2024 2025 MVP期 SMB導入期 エンタープライズ導入期 Musubi AI在庫管理リリース 仮説検証の 早さ・速さ 機能開発のスケーリング チームの体制の強化 持続可能な成長 高信頼性・高品質 それぞれのフェーズで重要にしたい事業や組織的な要件 それぞれのフェーズでアーキテクチャに求められる品質特性 • 機能適合性 (特に機能適切性） • 保守性 • 機能適合性 (特に機能完全性) • 使用性 • 保守性 (特にモジュール性、修正性) • 機能適合性(特に機能正確性) • 信頼性 • 性能効率性 • 保守性（特に解析性） • そしてユニットエコノミクス 入社！(※) (※)入社より前のいなかった時期の情報は、正確ではない可能性があります
9. ©KAKEHASHI inc. 9 品質特性 システム/ソフトウェア製品品質 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 機能完全性 時間効率性 共存性 適切度認識性 成熟性 機密性 モジュール性 適応性 JIS X 25010:2013 製品品質モデルより 機能正確性 資源効率性 相互運用性 習得性 可用性 インテグリティ 再利用性 設置性 機能適切性 容量満足性 ユーザエラー 防止性 運用操作性 障害許容性 （耐故障性） 否認防止性 解析性 置換性 回復性 責任追跡性 修正性 ユーザインタ フェース快美性 真正性 試験性 アクセシビリティ • 品質特性はトレードオフ。すべてを同時に満たすことはできない • プロダクトの特性やフェーズに合わせて、アーキテクチャドライバとなる要素を自分たちで選択する
10. ©KAKEHASHI inc. 10 ユニットエコノミクス • ユニットエコノミクスとは ◦ 顧客あたり(1ユーザー、1店舗など)の採算性 ◦ LTV（顧客生涯価値） > CAC（顧客獲得コスト） という健全な目指す • アーキテクチャとどう関係するのか？ ◦ どうすれば長く使い続けてもらえるか ▪ ユーザーが増えても、サクサク動いて落ちないサービス ▪ 魅力的な機能を素早く提供 ◦ どうすればコストを下げられるか ▪ 事業モデルに適したサービス選定、構成 ▪ システムの負荷の削減
11. MVP期
12. ©KAKEHASHI inc. MVP期の状況 12 • 事業 ◦ ヒアリング、モックアップでデモすることにより、プロダクトに必要な要素を洗い出し ◦ 初期開発のカオス • 開発チーム ◦ 新規のスクラムチーム ◦ バックエンドエンジニアの全員が業務委託のメンバー ▪ 最初1人 ▪ 徐々に増え3〜4人 ◦ バーンダウンチャートがアップし続ける問題
13. ©KAKEHASHI inc. 13 MVP期のアーキテクチャ • AWS Lambdaでトランザクションスクリプト構成 • フルマネージドなサービスを選択し、インフラに手間をかけない
14. ©KAKEHASHI inc. 14 MVP期のアーキテクチャのふりかえり 良かったこと 課題 性能効率性 • 考えることが少ない ー 信頼性 • 考えることが少ない ー 保守性 • 価値提供のリードタイムの短さ ー
15. SMB導入期
16. ©KAKEHASHI inc. SMB導入期の状況 16 • 事業 ◦ SMB領域のPMFに向けて足りない機能をどんどん作っていく時期 ◦ AIの精度向上も含めて、ユーザー体験の向上を推進 ◦ オンボーディングや手作業での運用の課題 • 開発チーム ◦ 開発チームが20人〜40人ほどに ▪ バックエンドエンジニアも10人程度に ◦ コミュニケーションコスト、マネジメントコストの増加
17. ©KAKEHASHI inc. 17 SMB導入期のアーキテクチャ • 基本的な構成は変えず • AWS Lambdaのスケーラビリティを活かしつつパフォーマンス対策を行う
18. ©KAKEHASHI inc. 18 SMB導入期のアーキテクチャのふりかえり 良かったこと 課題 性能効率性 • 最低限の対応でレスポンス性能へ対処でき る構成になっていた • CI/CDの遅さ 信頼性 • 考えることが少ない ー 保守性 • 機能開発に集中できる構成 • 修正の影響範囲 • 単体テストの追加が難しい • チームのパフォーマンスがスケールしな い
19. エンタープライズ導入期
20. ©KAKEHASHI inc. エンタープライズ導入期の状況 20 • 事業 ◦ 大手法人の薬局に向けて、機能の正確性の向上や法人としての管理機能を開発 ◦ システムの信頼性とスケーラビリティの重要度が一気に上がる ◦ 持続可能な成長のため、インフラコスト削減を実施 ◦ 「医療情報システムの安全管理に関するガイドライン」への対応 • 開発チーム ◦ 職能別のサブチームから、フィーチャーチームへの変化 ◦ 技術的負債の解消をチームとして実施できるタイミング ◦ 品質向上のための開発プロセスの見直し
21. ©KAKEHASHI inc. 21 エンタープライズ導入期のアーキテクチャ • APIのコードにレイヤー構造を導入、単体テストを増やしていく • 性能効率を向上させるため、DBの負荷軽減とスケール性の向上
22. ©KAKEHASHI inc. 22 エンタープライズ導入期のアーキテクチャのふりかえり 良かったこと 課題 性能効率性 • 高いスケーラビリティ • DBの変更の運用が容易 • インフラコスト増加 信頼性 • 高い信頼性 • 可観測性の低さ 保守性 ー • 変更の影響範囲も大きさ • 動作確認の難しさ
23. これから考えていること
24. ©KAKEHASHI inc. 24 これから目指そうとしているアーキテクチャ • 影響範囲を小さく、テストしやすさを向上させるため、モノリスからモジュラーモノリスへ • AppSyncとAWS LambdaをECS on Fargateへ
25. ©KAKEHASHI inc. 25 完璧なアーキテクチャは存在しない • さまざまな制約で捨てざるを得ないものが存在する • 変更を前提としたアーキテクチャに ◦ ベストだったアーキテクチャも、事業やチームの状況が変わると課題に変わる • 変えていくことで自分たちのものになっていく
26. アーキテクチャの痛みは 事業やプロダクトが成長している証拠
27. これからも医療体験が日々進化する世 界の実現のために、成長痛と向き合って プロダクトを成長させていきます
28. © KAKEHASHI Inc. All Rights Reserved. PM・EM・エンジニアを積極採用中 https://kakehashi-dev.hatenablog.com/entry/2025/07/17/093000 We’re Hiring!!!
29. ©KAKEHASHI inc. プロダクトの成長に合わせた アーキテクチャの段階的進化と成長痛 そして、ユニットエコノミクスの最適化 2025年8月28日 松本 明紘 社会インフラ基盤開発に関わるアーキテクチャ設計を学ぶ会！