マルチバーティカル戦略を支える、 システムと組織のアーキテクチャ 〜ドメインDeep Dive × 光速開発を実現する両輪のアプローチ〜

アーキテクチャカンファレンス2025登壇時の資料です。

Transcript

1. マルチバーティカル戦略を⽀える、 システムと組織のアーキテクチャ ドメインDeep Dive × 光速開発を実現する両輪のアプローチ アーキテクチャカンファレンス 2025 2025.11.20 Thu
2. ⾃⼰紹介 株式会社メディカルフォース 代表取締役CTO 組⽥ 隆亮 Kumita Ryusuke 1997年⽣。東京⼤学⼯学部卒業。 2016年、⼤学在学中にtoC向けプラットフォームサービス を創業しCTOに就任。2018年に同サービスをメガベン チャー企業に売却。 2020年9⽉に株式会社メディカルフォースを設⽴し、2025 年1⽉に同社代表取締役CTO就任。
3. 会社‧事業紹介 医療ドメイン ⾃由診療向けAll-in-one SaaS事業 ⽪膚科‧形成外科向けAll-in-one SaaS事業 広告効果分析‧MA SaaS事業 ブランド設計‧リブランディング⽀援事業 顧客向けの集客⽀援（BPO‧広告運⽤）事業 警備ドメイン 警備会社向けAll-in-one SaaS事業 since 2021 since 2024
4. Agenda 1. メディカルフォースが⽬指す世界 2. マルチバーティカル戦略とは 3. システムアーキテクチャの現在 4. 組織アーキテクチャの現在 5. まとめ
5. メディカルフォースが⽬指す世界 ビジョンと取り組んでいる課題
6. メディカルフォースが⽬指す世界 これからの産業の 成⻑プロセスを メディカルだけではなく複数の産業に連続的に参⼊し ”誰も取り残さないDX”を実現する会社です。 現状はクリニック向けと警備会社向けのソリューションを提供しています。 合理化する
7. DXは⼀部の企業の特権である 多くの産業で本質的でない作業に追われて働いて いる⼈が存在 世の中が複雑すぎるのでDXは難しい ⼤企業や⼀部の巨⼤産業 DXはなぜ進まないか 01 世の中が複雑すぎる 各産業には独⾃の慣習や複雑なオペレーションが存在し、それら を理解し適切にデジタル化することは容易ではありません。 02 ニッチはイノベーションで劣後する 市場規模が⼩さい産業は、DXへの投資が後回しにされ、イノ ベーションの恩恵を受けにくい構造的な問題があります。 03 汎⽤ツールは解にならない 世にある多くのITツールは全業界向けの汎⽤的なものであり、業 界特有の商習慣や細かい業務フローには対応できず、定着しない 現実があります。
8. DXは⼀部の企業の特権である 多くの産業で本質的でない作業に追われて働いて いる⼈が存在 世の中が複雑すぎるのでDXは難しい あらゆる産業で働く⼈々に”余⽩”がある ⼤企業や⼀部の巨⼤産業 ソフトウェアの⼒
9. マルチバーティカル戦略とは DXを民主化するための解
10. マルチバーティカル戦略という解 複数産業で連続的にバーティカルSaaSを⽴ち上げ、誰も取り残さないDXを実現 この戦略の核⼼は、モジュールの組み合わせによるソリューション構築「アトミックソフトウェア構想」 産業A 産業B アトミックソフトウェア モジュール群 産業C アトミックソフトウェア構想 ※ソフトウェアに限らずBPOやファイナンス などの組織ケイパビリティも同様にモジュー ルとして扱い、ソリューションに付加する
11. アトミックソフトウェア構想の合理性 産業A 産業B 産業C アトミックソフトウェア構想 現場の複雑なオペレーションに アジャストした柔軟な設計 モジュール単位でのR&Dコストの按分 により⾼品質を担保 柔軟性の⾼さ 経済合理性
12. バーティカルの壁 表⾯的な機能ではなく「痒い所に⼿が届く」レベルの機能が求めら れます。 それに必要な産業独⾃の複雑なドメイン知識量は膨⼤です。医療、 警備など、それぞれの産業特有の業務フロー、規制、慣習を深く理 解する必要があります。 乗り越えるべき壁 顧客への執着や自律的な意思決定といった ものづくりカルチャー が原動力
 メディカルフォースには”顧客コミット”という顧客への執着を規定したコアバリューがある
 とはいえまだ壁がある 効率性の壁 産業の数だけ組織が肥⼤化し効率性が落ちるリスクがあります。 時間やコストの浪費はスタートアップの死を意味します。複数産業 に展開しながらも、開発速度と品質を維持し、組織の効率性を保つ ことが不可⽋です。 メディカルフォースの強み
13. マルチバーティカルの成功要件 顧客の業務や課題を、 顧客⾃⾝よりも深く理解する DeepDiveで得た仮説の検証サイクルを 光速で回す ドメイン Deep Dive 光速開発 各産業の現場に深く⼊り込み、表⾯的な理解ではな く、顧客⾃⾝も気づいていない本質的な課題を発⾒ します。 これにより、圧倒的な業務適合性を持つソリュー ションを提供できます。 ドメイン理解から得た仮説を、迅速に実装‧検証‧ 改善するサイクルを⾼速で回します。 圧倒的な展開速度でイテレーションを重ねること で、市場の変化に素早く対応し、競争優位性を確⽴ します。
14. マルチバーティカルの成功要件 ドメイン Deep Dive 光速開発 産業ごとに慣習や課題が全く異なるため、1つのチームが複数の 産業のドメインDeepDiveを同時に⾏うのは不可能です。 各産業の深い専⾨知識と現場理解が必要になります とはいえスケールの壁がある 産業ごとにプロダクトを0から作っては光速開発ができません。 開発リソースが分散し、コストも時間も膨⼤になってしまいます。 マルチバーティカル戦略でこのスケールの壁を克服するのに 
 必要なものが組織とシステム両輪のアーキテクチャだと考えています 

15. ここまでのまとめ システム アーキテクチャ 
 
 モジュール設計 
 組織 アーキテクチャ 
 
 チームトポロジー 
 Scrum@Scale
 ものづくりカルチャー 
 “顧客コミット ”
 ドメイン DeepDive × 光速開発 
 マルチバーティカル 
 スケール 
 メディカルフォースの強み
16. 今回話すこと システム アーキテクチャ 
 
 モジュール設計 
 組織 アーキテクチャ 
 
 チームトポロジー 
 Scrum@Scale
 ものづくりカルチャー 
 “顧客コミット ”
 ドメイン DeepDive x 光速開発 
 マルチバーティカル 
 スケール 
 マルチバーティカル戦略を⽀える組織アーキテクチャとシステムアーキテクチャについて実例と つまづきから得た要点を交えてご説明します メディカルフォースの強み
17. システムアーキテクチャの現在 モジュール設計の思想と実例
18. 技術的汎⽤機能を超えた、ビジネス機能のモジュール化 独⽴性を担保しつつビジネス要件を正しくモデルに落とし込む モジュール設計の思想 認証・認可
 ログ
 監視
 通知
 検索
 技術的汎用機能群 ビジネス機能 予約
 BI
 広告計測
 給与計算
 産業別アプリ スケジューリ ング
 other apps…

19. モジュールの粒度設計 最初は何が共通化できるかわからない、どこまで共通化できるかも不明 共通化が過剰 共通化が不⾜ 適切な粒度 複雑な抽象化により、開発速度が低下、 産業特有の要件を充⾜できない ⾞輪の再発明により、展開速度が低下、 品質の⼀貫性が保てない 実装していきながら、適切なタイミング で切り出していく
20. 境界づけられたコンテキストの 
 定義が固まったタイミングで 
 物理的な分割を行う • 単⼀のコードベースで運⽤コストを抑える • ドメインロジックをカプセル化し疎結合に • オニオンアーキテクチャで層構造も疎結合に • モジュール間の連携は依存性注⼊ • CIでPR作成時にチェック • DDDに精通したエンジニアがランダムでPRをレビュー モジュール作成の要点 必要なタイミングで切り出せるように 
 DDDでモジュラーモノリスを構成
 カスタムESListルールで強制
 Nest.jsやInversifyJSのモジュール機能を利用

21. 可視化のニーズは各産業にあるが表⽰データは異なる Amazon QuickSightをラップした共通モジュールを作ることで各産業で「クエリを書くだけ」でリッチなダッシュ ボードを提供可能に。 モジュールの実例：経営分析などで⽤いるBI機能 警備app
 BI モジュール
 埋め込みURLの発行
 権限管理
 クリニックDB
 警備DB

22. 組織アーキテクチャの現在 チームトポロジーと Scrum@Scale
23. チームトポロジー 産業ごとにストリームアラインドチームが存在 アトミックソフトウェアチームは常設ではなく必要 に応じて招集/解散 インフラや監視についてはプラットフォームチーム ストリーム
 アラインド
 チーム
 A
 ストリーム
 アラインド
 チーム
 B
 クリニックドメイン 警備ドメイン ストリーム
 アラインド
 チーム
 C
 ストリーム
 アラインド
 チーム
 D
 プラットフォームチーム α
 ・・・ プラットフォームチーム β
 アトミックソフトウェアチーム 
 イネイブリングチーム 
 逆コンウェイ戦略を意識したチーム設計
 コードオーナーのレビュー下で Inner Source活動によりモ ジュールをブラッシュアップ
24. チームトポロジーの要点 チーム分割を進めると品質基準がバラバラになった • イネイブリングチームで全社統⼀のテスト戦略を策定 • Shift Leftで設計段階でのテスト観点の洗い出し、 実装者による動作の担保を⾏う チーム分割を進めると⽣産性にばらつきが出てきた • イネイブリングチームで全社統⼀のAI戦略を策定 • ルールベースで誰でも活⽤できる状態にし、勉強会を 通して全社にインストール 出てきた課題
 課題に対する取り組み
 サイロ化を防ぐためにイネイブリングチームや プラットフォームチームをワークさせることが重要
25. チームトポロジーの要点 ストリーム
 アラインド
 チーム
 A
 ストリーム
 アラインド
 チーム
 B
 クリニックドメイン 警備ドメイン ストリーム
 アラインド
 チーム
 C
 ストリーム
 アラインド
 チーム
 D
 プラットフォームチーム α
 ・・・ プラットフォームチーム β
 アトミックソフトウェアチーム 
 イネイブリングチーム 
 チーム分割を進める中で認知負荷を下げるため プラットフォームαチームにストリームアラインドチー ムのバグ修正を依頼するなどして 過度なコラボレーションをしてしまった 結果コミュニケーションコストが⾼くなり ストリームアラインドチーム内での学習が進まず 品質低下につながった 適切なチームの境界を引くことが重要
26. Scrum@Scale マルチバーティカルという”遠⼼⼒”が働く組織で、ガバナンス（求⼼⼒）を効かせる仕組み チーム独⾃の専⾨性を保ちつつ全社としてのアジリティを担保 出典：https://scruminc.jp/scrum-at-scale/
27. • 全スクラムイベントに参加すると1週間がほぼ全てMTGで埋まる • 異なるドメインのプロダクト開発をコンテキスト理解した上でディレクションするのは不可能 ロードマップ策定や機能設計、リリースなど⼤幅に権限を委任 とはいえ完全に委任すると開発プロセスのブラックボックス化が進んでしまう... スクラムオブスクラムのイベントで⽅針やスケジュール、状況を同期 • 全社の⽅針とインクリメントがずれない • 現場の課題が即座に解消される • 適正なリソース配置ができる Scrum@Scaleの要点
28. まとめ 多くの産業で人々は本質的ではない業務に忙殺されている。 DXは莫 大なリソースが必要。
 
 ジャストフィットと言わないまでも正解に近いオペレーション DXを実現で きるマルチバーティカル戦略という解。 
 
 ドメインDeep Diveと光速開発の両立がカギ 
 
 それを実現するにはシステムと組織のアーキテクチャを両輪駆動する 必要あり
 ドメイン DeepDive × 光速開発 組織のアーキ
 テクチャー システムのアーキ
 テクチャー この結果として誰も取り残さないDXが実現できる

29. エンジニア募集してます 提供できる経験 01 マルチバーティカル戦略という新しい挑戦 前例のないアプローチをほぼゼロから構築できます。⾃分たちで道を 切り開く醍醐味を味わえます。 02 多岐にわたるポジションや役割 戦略の特性上チームが多⾓化し、多様なポジションや役割が発⽣し ます。 03 ⽇本の産業全体の底上げに貢献 ⽇本の産業のほとんどはDX投資のできないロングテール市場です。 それらに対しアトミックソフトウェア構想を掲げDXを⺠主化してい きます。 求める⼈物像 左の挑戦にワクワクできる方 
 ”顧客コミット”精神のある方
 私たちと一緒に、誰も取り残さない DXを実 現しませんか？