©KAKEHASHI inc. プロダクトの成長に合わせた アーキテクチャの段階的進化と成長痛 そして、ユニットエコノミクスの最適化 2025年8月28日 松本 明紘 社会インフラ基盤開発に関わるアーキテクチャ設計を学ぶ会！ 

©KAKEHASHI inc. 株式会社 カケハシ(2023年2月〜) ● AI在庫管理、新規事業 ● バックエンドに軸足を置くテックリード もっち(X: @mottyzzz) 松本 明紘 2 自己紹介 https://speakerdeck.com/kakehashi 

© KAKEHASHI Inc. All Rights Reserved. ©KAKEHASHI inc. 3 

©KAKEHASHI inc. Musubi AI在庫管理(1/2) 4 患者さん・医薬品ごとに、AIが需要予測 めんどうな在庫管理の課題を解決 

©KAKEHASHI inc. Musubi AI在庫管理(2/2) 5 

©KAKEHASHI inc. 6 AI在庫管理の全体のアーキテクチャ 本日はこの範囲の お話をします https://findy-tools.io/companies/kakehashi/91 

©KAKEHASHI inc. 7 ソフトウェアアーキテクチャは変化していく ● 事業や組織や技術、トレードオフとなる制約を満たす必要がある ● 事業状況、組織構造、技術トレンドなどすべて変化していく 出展： ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making https://speakerdeck.com/snoozer05/software-architecture-and-decision-making 

©KAKEHASHI inc. 8 プロダクトのフェーズと事業や組織的な要件の変化 2020 2021 2022 2023 2024 2025 MVP期 SMB導入期 エンタープライズ導入期 Musubi AI在庫管理リリース 仮説検証の 早さ・速さ 機能開発のスケーリング チームの体制の強化 持続可能な成長 高信頼性・高品質 それぞれのフェーズで重要にしたい事業や組織的な要件 それぞれのフェーズでアーキテクチャに求められる品質特性 ● 機能適合性 (特に機能適切性） ● 保守性 ● 機能適合性 (特に機能完全性) ● 使用性 ● 保守性 (特にモジュール性、修正性) ● 機能適合性(特に機能正確性) ● 信頼性 ● 性能効率性 ● 保守性（特に解析性） ● そしてユニットエコノミクス 入社！(※) (※)入社より前のいなかった時期の情報は、正確ではない可能性があります 

©KAKEHASHI inc. 9 品質特性 システム/ソフトウェア製品品質 機能適合性 性能効率性 互換性 使用性 信頼性 セキュリティ 保守性 移植性 機能完全性 時間効率性 共存性 適切度認識性 成熟性 機密性 モジュール性 適応性 JIS X 25010:2013 製品品質モデルより 機能正確性 資源効率性 相互運用性 習得性 可用性 インテグリティ 再利用性 設置性 機能適切性 容量満足性 ユーザエラー 防止性 運用操作性 障害許容性 （耐故障性） 否認防止性 解析性 置換性 回復性 責任追跡性 修正性 ユーザインタ フェース快美性 真正性 試験性 アクセシビリティ ● 品質特性はトレードオフ。すべてを同時に満たすことはできない ● プロダクトの特性やフェーズに合わせて、アーキテクチャドライバとなる要素を自分たちで選択する 

©KAKEHASHI inc. 10 ユニットエコノミクス ● ユニットエコノミクスとは ○ 顧客あたり(1ユーザー、1店舗など)の採算性 ○ LTV（顧客生涯価値） > CAC（顧客獲得コスト） という健全な目指す ● アーキテクチャとどう関係するのか？ ○ どうすれば長く使い続けてもらえるか ■ ユーザーが増えても、サクサク動いて落ちないサービス ■ 魅力的な機能を素早く提供 ○ どうすればコストを下げられるか ■ 事業モデルに適したサービス選定、構成 ■ システムの負荷の削減 

MVP期 

©KAKEHASHI inc. MVP期の状況 12 ● 事業 ○ ヒアリング、モックアップでデモすることにより、プロダクトに必要な要素を洗い出し ○ 初期開発のカオス ● 開発チーム ○ 新規のスクラムチーム ○ バックエンドエンジニアの全員が業務委託のメンバー ■ 最初1人 ■ 徐々に増え3〜4人 ○ バーンダウンチャートがアップし続ける問題 

©KAKEHASHI inc. 13 MVP期のアーキテクチャ ● AWS Lambdaでトランザクションスクリプト構成 ● フルマネージドなサービスを選択し、インフラに手間をかけない 

©KAKEHASHI inc. 14 MVP期のアーキテクチャのふりかえり 良かったこと 課題 性能効率性 ● 考えることが少ない ー 信頼性 ● 考えることが少ない ー 保守性 ● 価値提供のリードタイムの短さ ー 

SMB導入期 

©KAKEHASHI inc. SMB導入期の状況 16 ● 事業 ○ SMB領域のPMFに向けて足りない機能をどんどん作っていく時期 ○ AIの精度向上も含めて、ユーザー体験の向上を推進 ○ オンボーディングや手作業での運用の課題 ● 開発チーム ○ 開発チームが20人〜40人ほどに ■ バックエンドエンジニアも10人程度に ○ コミュニケーションコスト、マネジメントコストの増加 

©KAKEHASHI inc. 17 SMB導入期のアーキテクチャ ● 基本的な構成は変えず ● AWS Lambdaのスケーラビリティを活かしつつパフォーマンス対策を行う 

©KAKEHASHI inc. 18 SMB導入期のアーキテクチャのふりかえり 良かったこと 課題 性能効率性 ● 最低限の対応でレスポンス性能へ対処でき る構成になっていた ● CI/CDの遅さ 信頼性 ● 考えることが少ない ー 保守性 ● 機能開発に集中できる構成 ● 修正の影響範囲 ● 単体テストの追加が難しい ● チームのパフォーマンスがスケールしな い 

エンタープライズ導入期 

©KAKEHASHI inc. エンタープライズ導入期の状況 20 ● 事業 ○ 大手法人の薬局に向けて、機能の正確性の向上や法人としての管理機能を開発 ○ システムの信頼性とスケーラビリティの重要度が一気に上がる ○ 持続可能な成長のため、インフラコスト削減を実施 ○ 「医療情報システムの安全管理に関するガイドライン」への対応 ● 開発チーム ○ 職能別のサブチームから、フィーチャーチームへの変化 ○ 技術的負債の解消をチームとして実施できるタイミング ○ 品質向上のための開発プロセスの見直し 

©KAKEHASHI inc. 21 エンタープライズ導入期のアーキテクチャ ● APIのコードにレイヤー構造を導入、単体テストを増やしていく ● 性能効率を向上させるため、DBの負荷軽減とスケール性の向上 

©KAKEHASHI inc. 22 エンタープライズ導入期のアーキテクチャのふりかえり 良かったこと 課題 性能効率性 ● 高いスケーラビリティ ● DBの変更の運用が容易 ● インフラコスト増加 信頼性 ● 高い信頼性 ● 可観測性の低さ 保守性 ー ● 変更の影響範囲も大きさ ● 動作確認の難しさ 

これから考えていること 

©KAKEHASHI inc. 24 これから目指そうとしているアーキテクチャ ● 影響範囲を小さく、テストしやすさを向上させるため、モノリスからモジュラーモノリスへ ● AppSyncとAWS LambdaをECS on Fargateへ 

©KAKEHASHI inc. 25 完璧なアーキテクチャは存在しない ● さまざまな制約で捨てざるを得ないものが存在する ● 変更を前提としたアーキテクチャに ○ ベストだったアーキテクチャも、事業やチームの状況が変わると課題に変わる ● 変えていくことで自分たちのものになっていく 

アーキテクチャの痛みは 事業やプロダクトが成長している証拠 

これからも医療体験が日々進化する世 界の実現のために、成長痛と向き合って プロダクトを成長させていきます 

© KAKEHASHI Inc. All Rights Reserved. PM・EM・エンジニアを積極採用中 https://kakehashi-dev.hatenablog.com/entry/2025/07/17/093000 We’re Hiring!!! 

©KAKEHASHI inc. プロダクトの成長に合わせた アーキテクチャの段階的進化と成長痛 そして、ユニットエコノミクスの最適化 2025年8月28日 松本 明紘 社会インフラ基盤開発に関わるアーキテクチャ設計を学ぶ会！