ドメインの性質に向き合う

縣：今日は「全員アーキテクトで挑む、巨大で高密度なドメインの紐解き方」というタイトルでお話しさせていただきます。この「全員アーキテクト」というワードですが、実はもともと言語化されていたコンセプトではありません。今回アーキテクチャカンファレンスでお話しさせていただくにあたり、これまでやってきたことを一緒に取り組んできたメンバーと振り返りながら、背景にあったコンセプトを言語化したものです。

プロダクト開発を持続的に行い、その先に事業を成功させて大きな価値を出すためには、ドメイン、ソフトウェア、組織という3つの歯車が噛み合い続けることが不可欠です。特にドメイン自体は短期的には変えることが難しいものですので、ドメインに合ったソフトウェアと組織を設計することが大切だと考えています。

ドメイン知識が大事だということは、近年のソフトウェアエンジニアリングでは常識になっています。しかしアーキテクチャを決めるという観点では、個別の知識だけでなく、その背後にある構造的な性質を捉えることが必要になります。この性質に合わせてアーキテクチャを決めることで、初めてアーキテクチャに一本の筋が通ると考えています。

ヘンリーという会社をご存じない方もいらっしゃると思いますので、簡単にご紹介します。日本の病院向けの電子カルテを作っている会社です。医療業界では「クラウドネイティブ」という言葉を、オンプレミスのサービスと対比する形で使っています。普通のWebアプリケーションで、マルチテナントな形でパブリッククラウド上に作られているものを指しています。この電子カルテに加えて、レセコンと呼ばれる医事会計システムも一体で持っているプロダクトを作っています。

縣：このドメインには3つの重要な性質があると考えています。1つ目が「巨大である」こと、2つ目が「高密度である」こと、そして3つ目が「変化がある」ということです。

1つ目、巨大であることについてお話しします。病院向けと言っているのは、入院機能のある医療機関を指しています。病院には医師、看護師、薬剤師、検査技師といったさまざまな専門職の方がいて、組織として動いています。ほとんど会社であると思っていただければ大丈夫です。その会社におけるすべての業務の起点であり、ハブになるのが電子カルテです。1つのプロダクトで、1つの会社の上から下まで全部の業務を押さえる必要があるという巨大さがあります。

縣：2つ目は高密度であることです。医療というものは、根本的に複数の専門職が緊密に連携することで達成されるという性質を持っています。1人の患者さんが外来を受けて入院し、退院準備をして退院し、また外来に来るという流れの中で、医師、看護師、薬剤師、検査技師、医療事務といったさまざまな専門職が、物理的なものや情報をパスし合いながら、1つの医療という業務をなしています。

縣：さらに厄介なのが診療報酬制度です。日本は保険診療で多くの方が保険適用で医療を受けられていますが、何をやったらいくらというルールが基本的に全部決まっています。初診だったら291点、1点10円なので2,910円といった具合です。

この制度では、お金を取るためにはカルテに特定の内容が記録されていないとダメだというルールがあったり、特定の様式で診察内容を記載して患者に署名をもらう必要があったりします。このルールが各専門職の方々の業務を横断的に縛っています。

具体例として、2024年10月に始まった「長期収載品の選定療養」という制度があります。ジェネリック医薬品があるのに、患者さんの希望で先発医薬品を使う場合は、その差額を患者さんが自分で払うというルールです。医療上必要があって先発品を処方している場合は、医師がその理由を記録する必要があります。記録がないと会計上の扱いが変わり、不正請求になってしまいます。

縣：これが何を意味するかというと、医師がカルテで診察をする際に、会計上のルールの都合で入力項目が増えるということです。逆に会計側から見ると、正しい会計にするためには医師がちゃんと入力しているかをチェックする必要があります。臨床と会計というコンテキストは分かれているように見えますが、そこをまたいだ依存が発生します。こういった事象があらゆる場所で発生するのが、この「高密度」という性質です。

最後、3つ目の「変化」についてです。診療報酬制度は2年に1回必ず改定されます。次は2026年6月ですね。それ以外にも、コロナや政治的な要因で不定期に制度変更が訪れます。先ほどの長期収載品も診療報酬改定とは別のタイミングで導入されたものです。

制度変更が起きると、もともと「このコンテキストとこのコンテキストはこういう関係性だ」と整理していたものが、ルールが変わったことによって、昨日まで正しかった設計の性質が変わってしまうことがあります。

縣：これら3つの性質をアーキテクチャが解くべきチャレンジとして捉えると、「巨大である」ことは開発をスケーラブルにできるかという課題に、「高密度である」ことは疎結合を保てるかという課題に、「変化がある」ことは柔軟に適応できるかという課題につながります。私たちはこの3つを同時に満たすアーキテクチャを考えなければなりませんでした。

全員アーキテクトというコンセプト

縣：私も一時期アーキテクトチームに所属していたのですが、「これはトップダウンに設計するのは無理だ」と思いました。私はヘンリーで4年半から5年ほど開発していますが、いまだに全容がつかめないぐらい広いですし、個々の領域も非常に複雑です。全体像を描き切った上で望ましいアーキテクチャを設計しきることは不可能だと感じました。

個々の業務も、メジャーケースとエッジケースに整理すると、ほとんどがエッジケースになります。ロングテールで、裾野に行けば行くほど全体設計を揺るがすような例外的な仕様が見つかります。アーキテクトチームのような存在がトップダウンで全体を見据えてやろうとすると、どうしてもメインケースしか見えない状態で作ることになりがちです。しかし実際にアーキテクチャレベルに大きなインパクトを及ぼすのは、ロングテールな部分だったりします。

ヘンリーというプロダクトは内部的にさまざまなコンテキストに分けて開発をしていますが、隣接するコンテキストとの整合性を取る場面は、特定のタイミングや特定の場所だけでなく、日々の開発のすべての場所で発生します。ヘンリーでは基本的にすべてのエンジニアが、あらゆる開発においてアーキテクト的な視点を持って開発することが求められますし、それが持続的に開発するためには必要不可欠だと考えています。

縣：アーキテクト視点がないと、アドホックな修正を積み重ねることになります。ロングテールのケースは、最初はメインケースから開発を始めて、段階的にエッジケースが見えてきます。段階的に見えてくると、ちょっとした修正で対応できるように見えてしまいます。そういうことを日々やっていくと、依存関係が崩壊して修正不可能な状態に簡単に陥ります。だからこそ、全員がアーキテクト視点や全体設計に意識を向け続ける仕組みや文化が大切です。

全員アーキテクトとして求められる振る舞いは2つあります。1つ目は「越境」です。隣接するドメインに関心を持ち、自分が今触っているドメインの周辺に対して常に想像を巡らせることが重要です。

2つ目は「探索」です。より良い整理を諦めないということです。既存のコードベースや、そのドメインに長く携わってきた人がいる領域を触る場面もあると思いますが、既存の概念整理が正しいという前提でコードを書くのは危険です。その領域に今最も詳しいのは常に自分だと考えるぐらいの振る舞いが大切です。

縣：ただし、こうした全員アーキテクトを実践するには、それ相応の環境が提供されていなければ実践できません。今もまだ道半ばですが、その実践を目指していろいろと改善を進めてきました。

全員アーキテクトを実現する技術戦略

縣：実はヘンリーというプロダクトは、創業当初から1プロダクトを2つのバックエンドサービスに分割する構成を取っていました。1つはメインサービス、もう1つは診療報酬に関する知識を閉じ込めるためのサブシステムです。複雑な診療報酬制度をブラックボックス化できれば、全員が制度に習熟しなくても開発を進められるのではないか、という狙いがありました。

縣：ただ、これは比較的早いうちに分断モノリスになってしまいました。診療報酬制度をブラックボックス化することができず、あらゆる開発で必ず2つのコードベースを同時に変更する必要が出てしまいました。この意思決定をしたときは、巨大であることや変化が起きることは分かっていましたが、「高密度である」という性質、つまり結合が強いという点が見えていませんでした。

また、この時代の一番良くなかったところは、探索と学習が阻害されたことです。リポジトリもサービスも分かれていたので、隣のコードが見えづらく、境界を直すコストが高くて手を出しづらい状態でした。

さらにコンウェイの法則的な話もあり、ソフトウェアが分断されることでチーム体制や知識も分断されていきました。そうすると、境界を直そうという力学も働きにくくなりますし、適切な境界がどこにあるのかを探索できる知識もなくなっていきます。両面を知っていて初めて境界は調整できると思いますが、片方しか知らないとその発想が出てこなくなります。

つまり、ドメインの実態とソフトウェア・組織がズレていたのです。ドメインは巨大・高密度・変化という性質を持っているのに、ソフトウェアは分断モノリスになり、組織はチームと知識の分断が起きていました。3つの歯車が噛み合わなくなっていたのです。

縣：そこで私たちはモジュラーモノリスへ移行することを決断しました。ドメインの性質と向き合うために、物理的な壁を取り払う決断です。

まずモノレポ化を行い、コードの可視性を高めて変更をアトミックに行いやすくしました。2つのバックエンドサービスでリポジトリもデプロイ単位も分かれていたものを、1つのリポジトリにまとめました。これにより、2箇所を同時に触る必要があること自体は変わりませんが、1つのプルリクエストで出せるようになりました。

次にデプロイ単位の統合を段階的に進め、API呼び出しという物理的分断の壁を取り払っていきました。API呼び出しを伴うと、API定義に手を入れないと変更ができませんし、境界面を調整するコストが非常に高くなります。その分断を取り払うことで、境界面の調整をやりやすくすることを狙いました。

そして論理的な分割としてモジュール分割を進めています。私たちはサーバーサイドKotlinでバックエンドを書いていて、Gradleモジュールのレイヤーで分割を進めています。これにより一定の秩序と柔軟性がもたらされると考えています。

モジュラーモノリスを選んだ理由は、全員アーキテクトとして振る舞うための環境として適していたからです。

縣：1つ目の理由は、全体構成の探索です。論理的な分割に留めることで、境界を調整するコストを下げられます。関数呼び出しやクラスのメソッドの位置を調整するコストは、API呼び出しを伴う場合と比べて格段に小さいです。私たちはgRPCでサーバー間通信をしていましたが、gRPCの定義に手を入れるコストは非常に高いものでした。調整コストを下げることで、常に全員が境界を調整することを実践できる環境を作りたかったのです。

2つ目は、一定の強制力があることです。Gradleモジュールをきちんと分割すると、モジュール同士の依存関係を事前に定義する必要があり、その依存を超えるような変な依存は作れないようにできます。全容が見えない中で、KotlinやJavaのようにIDEが強い言語だと、補完が効いてインポートが追加されてしまうことがあります。疎結合にしようという意識やスキルがあっても、容易に結合がついてしまうのは良くありません。コードベース上で依存ルールを強制できる仕組みがあることで、モジュール間の依存について意識が働きますし、「これがここにあるせいで呼べない」といった議論が日々行えるようになりました。

全員アーキテクトを実現する組織戦略

縣：全員アーキテクトを実践するために大事な考え方がいくつかあります。1つ目は、自律性が高くて安定したチームである必要があるということです。最適な境界を探索し続けるためには、継続的に1つの領域に触れ続けることで初めて見えてくるものがあります。

縣：毎回領域が変わってしまうと、たまたまそのタイミングで触っていたものに引きずられた境界面が引かれてしまいます。ヘンリーのプロダクトは本当にいろんな角度からいろんな依存が飛んでくるものなので、ある程度具体的なケースを3〜4つ見て、それを抽象化する形でないと正しい境界を引くのは難しいと考えています。

また、境界を調整するには自分たちのチームで独立した意思決定ができること、上から下まで全部を面倒見るからこそ見えてくるものがあります。そのため、基本的には開発対象の業務フローを中心としてチームを分割していく方針を取っています。

チームの中にはドメインエキスパートを含めて、フルサイクルのメンバーを揃えるようにしています。ドメインエキスパートの方がチームの中にいることは非常に重要です。開発者はドメイン知識を学習しながら開発していますが、どうしても今開発しているものにフォーカスが寄りがちです。未知のことを知ることはできませんから。ドメインエキスパートがチームにいることで、「今はこうだけど、こういうケースもあるからそうしない方がいいんじゃないか」といったディスカッションをチーム内でできる体制があることは、非常に価値があります。

2つ目は、越境しやすいチームであることです。自分たちのコンテキストだけを良くしようとすると、周辺に意図せぬ影響が及んでしまいます。1プロダクトでは全体最適が重要ですが、それは全体を見たことがないと実現できません。

縣：ここでいう「経験」は、キャリア的な経験というよりは、ヘンリーというプロダクトの中でいろんな領域を見たことがあるという意味です。影響を与える側になったり、受ける側になったりという経験があることで、全体最適が見えてくると思います。社内留学や異動を適切に交えることで、固定化・局所最適化を防ぐことが大切です。

先ほど「安定したチーム」と言いながら「異動」というキーワードが出てくるのはバランスが難しいところですが、完全にメンバーが固定してその領域しか見ないという形になると、全体最適にはなりません。また、「隣のチームで境界をこういうふうに調整してうまくいった」という学びが組織の中に定着しなくなります。適切なバランスで社内留学や異動をしていくことは価値があると考えています。

越境しやすくするためには、チーム間で開発スタイルを揃えておくことも重要です。ヘンリーは1プロダクト・モノレポなので技術スタック自体は共通ですが、レイヤードアーキテクチャの書き方といったディテールの部分も、なるべく全社的にポリシーを統一するようにしています。歴史的経緯で揃っていない部分もありますが、隣のチームのコードを見に行ったり、機能開発に口を出したりできる状態を作ることが大切です。

開発体制も、ドメインの性質やフェーズによって柔軟に再設計するものだと考えています。例えばアーキテクトチームの変遷もその一例です。一時的にバーチャルチームとして組成し、解散しました。現在はアーキテクトという組織図上の明確な役割やチームは存在しない状態になっています。

縣：なぜアーキテクトチームを組成したかというと、当時は指針がなく、個別最適の限界が見えてきていたからです。分断モノリスになっていることは分かっていましたが、その先どうするかについては、強力に意思決定をして実装していく必要がありました。そこで方向性を示すためにバーチャルチームとして組成しました。

なぜ解散したかというと、ある程度構造が整って、モジュラーモノリスとしてやっていくというコードベース的なところが整ったタイミングで、もうアーキテクトチームでやるよりは各チームの中でそれぞれが調整をしながら探索していくほうがいいという話になったからです。

現在地とこれからの課題

縣：まだまだ道半ばで、挙げたものも完璧にできているものはほとんどありません。今一番感じている壁は、1プロダクトの中でチームに完全な独立性を持たせることは幻想だということです。

縣：どうしても他のチームが触っているコードベースに意図せぬ影響が及ぶことがあります。例えば、こちらのチームから見ると小さな変更が、隣のチームには大きなインパクトを与えてしまうこともあります。そもそも巨大で高密度な1プロダクトにおいて、チームをどう分割するかは自明ではありません。そのため、完全に綺麗な分割は不可能で、チーム構成自体もまだ探索が必要ですし、現状では100%チームに閉じてリリースできているわけでもありません。

理想的なチーム体制には、ビジネスゴール、ドメイン知識、コードベース、という3つの要素があり、これらがすべて1対1でチームに紐付いている状態が理想だと考えています。

まずビジネスゴールがチームに紐付いていれば、オーナーシップが育まれ、目標達成のための手段の自由度も上がります。次にドメイン知識については、いろんな領域を全部理解しようとすると認知負荷が高くなり、理解が浅くなってしまいます。そしてコードベースを1つのチームが責任を持って管理できれば、安全性が高まり、デプロイも独立して出せるので探索もしやすくなります。

ただし、ヘンリーではまだこの理想に向けて探索が必要な状況です。

縣：ソフトウェアも組織も、探索の過程で分割して統合して、また違う切り口で分けて、また統合してということを繰り返しています。大きい変化をすると常に揺り戻しが伴いますが、単純に同じ場所で振り子になっていては何の価値もありません。揺り戻しながらも登り続けることが大切です。

そのためには、なぜこの分割をするのか、なぜこの統合をするのか、どういう意図でこういう整理をするのかを明確にして、かつ振り返っていくことをやりながら、ソフトウェアと組織の両方の設計を育てていく必要があると考えています。

最後にまとめです。ヘンリーでは「全員アーキテクト」というコンセプトでドメインに向き合っています。アーキテクチャに正解はなく、自分たちの学びや環境の変化に応じて、ソフトウェアも組織も変化し、螺旋階段を登り続けることが大切だと考えています。ご清聴ありがとうございました。