株式会社メディカルフォース- 医療から警備ドメインまで。DX民主化への挑戦

皆さんこんにちは、アトミックソフトウェア（旧：株式会社メディカルフォース）のCTOの組田と申します。今日は弊社のマルチバーティカル戦略を支えるシステムと組織の両輪のアーキテクチャについて、このアーキテクチャカンファレンスに絡めてお話しします。

まず簡単に自己紹介いたします。私は大学在学中に起業し、当時エンジニア経験はありませんでしたが、そのタイミングからCTOを務め、CTO歴＝エンジニア歴というキャリアです。そのため、経営目線でもお話ししたいなと思っています。

弊社は2020年に設立し、現在は医療ドメインに加えて警備ドメインのサービスも展開しています。バーティカルSaaSを開発する会社ですが、SaaSだけではなく、自由診療の分野ではBPOやリブランディングの設計支援といったDXプラスアルファの部分も手がけています。

我々は「未来に、もっと余白を。」というミッションを掲げています。自由診療／保険診療の産業だけでなく複数産業に連続的に参入し、誰も取り残さないDXを実現することを目指しており、現状のクリニックと警備会社向けソリューションに加え、来年以降も次々と新しい産業へ参入していく予定です。

DX市場の構造的課題

DXの課題だと我々が考えるのは、DXが一部の企業の特権になっているという実態です。世の中が複雑すぎるため、DXを実現するには莫大なリソースが必要となり、結果として大企業や一部の巨大産業しかその恩恵を享受できないのではないかと感じています。それ以外の領域で働く多くの方々は、本職ではない作業に追われているのが現状ではないでしょうか。

なぜDXが進まないのかというと、一つひとつの産業が非常に複雑で、1からキャッチアップして入り込んでいくのが容易ではないという点があります。また、日本のロングテールな市場においてはDXの投資が後回しにされ、AIを含め、イノベーションの恩恵を受けにくい構造にあります。

またDXツールは全体のオペレーションをまるごとカバーしなければ意味をなしません。オペレーションを構成する業務ごとに異なるシステムを採用してしまうと、システム間のつなぎ込み作業に摩耗してしまい、業界特有の商習慣や業務フローを拾いきれません。

多業種展開を実現する、マルチバーティカル戦略

こういった課題を踏まえ、我々はソフトウェアの力で、あらゆる産業で働く人々に余白がある状態をつくりたいと考えております。その解がマルチバーティカル戦略です。

マルチバーティカル戦略を実現するためには、機能をモジュール化させて、それらのモジュールを各産業に合わせてカスタマイズすることであらゆる産業にフィットしたプロダクトを構築していく「アトミックソフトウェア構想」がコアとなります。

また、ソフトウェアに限らず、BPOやファイナンスといった組織ケイパビリティもモジュールとして保持し、産業ごとにアドオンしていくことで顧客への提供価値を最大化させ、産業自体の底上げを図ります。

アトミックソフトウェア構想の強みは、1からつくると時間のかかるものでも、パーツとして持っておくことで柔軟に、かつ経済合理性を持って展開できることにあります。投資対効果を1つの産業だけでなく全体で見ることで、高品質なプロダクトを仕上げることが可能になります。

“壁”を突破する「ドメインDeep Dive」と「高速開発」

この戦略を進める上での我々の強みは、モノづくりカルチャーや自律的な意思決定にありますが、理想を実現するには高い壁があります。

1つは「バーティカルの壁」で、表面的な機能ではなく、現場の痛いところに手が届くレベルの深い理解に基づいた機能が求められ、膨大なドメイン知識が必要になります。もう1つは「効率性の壁」です。産業の数だけエンジニア組織を拡大させると、肥大化に伴って効率性が落ちるリスクがあります。

このような中で、我々は限られたリソースの中で開発速度を維持し続けなければなりません。マルチバーティカルを成功させる要件は、顧客以上に業務を理解する「ドメインDeep Dive」と、仮説検証サイクルを回す「高速開発」の2軸です。

マルチバーティカル戦略を成功させる、システムと組織のアーキテクチャ

しかし、1つのチームが複数のドメインに同時にDeep Diveするのは無理がありますし、産業ごとにプロダクトをゼロからつくっていては高速開発もできません。

これを解決するのがシステムと組織のアーキテクチャです。システムアーキテクチャにおいては、認証やログといった技術的な共通基盤に加え、予約、BI、給与計算、スケジューリングといったビジネス機能をもモジュール化し、各プロダクトに統合していく設計思想を持っています。

このビジネス機能の粒度設計は難しく、共通化しすぎると開発速度の低下や要件への不適合が起き、不足すれば車輪の再発明や挙動の不一致が起きます。

そのため、適切なタイミングで切り出せるように、DDD（ドメイン駆動設計）を用いてモジュラーモノリスを構成しています。これらを活用し、層構造の疎結合を保つことをカスタムESLintなどで強制しています。

実例として、BI機能ではAWS QuickSightを活用しています。権限管理などの最小限の機能をモジュールとして切り出すことで、各産業においてクエリを書くだけでリッチなダッシュボードを提供できる仕組みを構築できます。

「チームトポロジー×Scrum@Scale」で、自律的な開発と全社ガバナンスを両立

チームトポロジーに基づく「逆コンウェイ戦略」の実践

組織アーキテクチャについては、チームトポロジーの考え方を取り入れています。

クリニックと警備の各ドメインにストリームアラインドチームを配置し、横断的なプラットフォームチーム、そして必要に応じてアトミックソフトウェアチームを編成しています。

チーム分割を進めると、品質基準や生産性にばらつきが出るという課題があります。これに対してはイネイブリングチームが全社統一のテスト戦略を策定し、実装者が動作担保を行う体制を整えています。

また、AI活用による生産性の差を埋めるため、イネイブリングチームが全社統一のAI戦略をつくり、勉強会などを通じて全社にインストールする取り組みも行っています。

過度なコラボレーションの失敗から学んだ、適切なチーム境界

組織のサイロ化を防ぐには、横串のチームを機能させる必要があり、そこにはCTOなどの責任者がコミットすることが重要です。

以前、プラットフォームチームがストリームアラインドチームのバグ修正まで行い、過度なコラボレーションによってコミュニケーションコストが増大し、品質低下を招いたという失敗がありました。この経験から、適切なチーム境界を引く重要性を学びました。

現在はScrum@Scaleを導入し、チームごとの専門性を保ちつつ全社的なガバナンスと俊敏さを両立させています。

また、チームが増える中で、CTOが全てのイベントに関わるとパンクしてしまいますし、全ドメインを完璧に把握してディレクションするのは不可能です。そのため、大胆に権限委譲を行うことが不可欠です。完全に任せきりにするのではなく、上位のスクラムで方針やスケジュールを同期することで、現場の課題解決と全体の方針転換を両立できています。

まとめ - システムと組織の両輪で、「誰も取り残さないDX」の実現へ

多くの産業で人々が本質的ではない業務に忙殺されている現状を、マルチバーティカル戦略による適切なDXで変えたいと考えています。システムと組織の両輪のアーキテクチャを整備し、ドメインDeep Diveと高速開発を回すことで、「誰も取り残さないDX」を実現していきます。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。