全員アーキテクトで挑む、 巨大で高密度なドメインの紐解き方 / Unraveling Massive and Dense Domains: The 'Everyone is an Architect' Approach

アーキテクチャConference2025 での発表資料

Transcript

1. Copyright © Henry, Inc. All rights reserved. 全員アーキテクトで挑む、 巨大で高密度なドメインの紐解き方 縣 直道 / @agatan_ 2025-11-21 アーキテクチャ Conference 2025
2. Copyright © Henry, Inc. All rights reserved. 󰳕 自己紹介 縣 直道 @agatan_ 株式会社ヘンリー VP of Product • 2022/04 ヘンリーにエンジニアとして入社 • 2025/10 より現職
3. Copyright © Henry, Inc. All rights reserved. 実はこのコンセプトは言語化されていたものではない。 モジュラーモノリス化やアーキテクトチームの組成と解散など、 これまでの技術戦略と組織戦略の変遷をふりかえって 背景にあったコンセプトを言語化したもの。 全員アーキテクト
4. Copyright © Henry, Inc. All rights reserved. ドメインの性質に向き合う 巨大・高密度・変化するドメイン 全員アーキテクトというコンセプト トップダウンの限界とボトムアップの探索 全員アーキテクトを実現する技術戦略 分断モノリスからモジュラーモノリスへ 全員アーキテクトを実現する組織戦略 自律・安定・越境 アジェンダ
5. Copyright © Henry, Inc. All rights reserved. Copyright © Henry, Inc. All rights reserved. ドメインの性質に向き合う アーキテクチャ
6. Copyright © Henry, Inc. All rights reserved. 3つの歯車 • 持続的な開発と事業の成功には 「ドメイン」「ソフトウェア」「組 織」の歯車を噛み合わせ続けること が不可欠 • ドメイン自体を変えることは難しい （短期的には） • ドメインにあったソフトウェアと 組織を設計することが大切
7. Copyright © Henry, Inc. All rights reserved. ドメインの性質 → アーキテクチャが解くべきチャレンジ ドメイン固有の知識（業務知識）も重要だが、 その背後にある構造的な「性質」を捉えることで、 初めてアーキテクチャに一本の筋が通る。 ドメインの”性質”とは？
8. Copyright © Henry, Inc. All rights reserved. Copyright © Henry, Inc. All rights reserved. ヘンリーが挑んでいる ドメインとその性質
9. Copyright © Henry, Inc. All rights reserved. 日本の病院向けに開発された 唯一のクラウドネイティブな電子カルテ 業務改革を実現する基幹システム レセコン（医事会計システム）も一体化 レセコン一体型電子カルテ「Henry」
10. Copyright © Henry, Inc. All rights reserved. 病院向け電子カルテの3つの性質 巨大 高密度 変化
11. Copyright © Henry, Inc. All rights reserved. 性質1：巨大 院内すべての業務の起点でありハブ 電子カルテは、病院という組織の基幹システム • 医師、看護師、薬剤師、検査技師、医療事務... • 多数のアクターが登場し、電子カルテで 日々業務を行っている
12. Copyright © Henry, Inc. All rights reserved. 医療は複数の専門職による緊密な連携プレー 12 / 43 性質2：高密度
13. Copyright © Henry, Inc. All rights reserved. 多様な専門職の業務が、「診療報酬制度」によって横断的に制約されている。 診療報酬制度による業務横断の結合 診療報酬制度とは？ 医療行為の価格（点数）を決める公的なルール。 たとえば... • 初診だったら291点（= 2910円） • 短時間の静脈麻酔をやったら120点（= 1200円） 算定するためにカルテに特定の内容が記録されていることを求めたり、定められた様式で診 察内容を記載し患者からの署名をもらうことを求めるようなものもあり、医療の現場での業 務に大きな影響を与えるもの。
14. Copyright © Henry, Inc. All rights reserved. 2024年10月開始の新制度 後発医薬品（ジェネリック）があるのに、患者希望 で先発医薬品（長期収載品）を使う場合、差額の一 部を患者が負担する、というルール。 例：長期収載品の選定療養 引用: 後発医薬品のある先発医薬品（長期収載品）の選定療養について
15. Copyright © Henry, Inc. All rights reserved. • 医療上必要があって先発品を処方している場合、 医師が「医療上必要な理由」を判断し、記録する必要がある。 • 記録がないと、会計上の扱いが変わってしまう。 • 正しく会計をするために「理由が正しく記録されているか」を チェックしたい要求が生まれる。 例：長期収載品の選定療養
16. Copyright © Henry, Inc. All rights reserved. • 医療上必要があって先発品を処方している場合、 医師が「医療上必要な理由」を判断し、記録する必要がある。 • 記録がないと、会計上の扱いが変わってしまう。 • 正しく会計をするために「理由が正しく記録されているか」を チェックしたい要求が生まれる。 例：長期収載品の選定療養 → コンテキストの境界をまたいで依存が発生する こういった事象があらゆる場所で発生する
17. Copyright © Henry, Inc. All rights reserved. 定期的かつ強制的な変化 診療報酬制度は2年に1回改定される （次回は2026年6月） それ以外にも、コロナや政治などの要因で、 制度変更は不定期に訪れる。 性質3: 変化 不確実な変化 制度変更によってコンテキスト同士の関係性・結合度が変わりうる 昨日まで正しかった設計が、制度変更で「間違い」になる
18. Copyright © Henry, Inc. All rights reserved. 性質 → 解決すべきチャレンジ 巨大 高密度 変化
19. Copyright © Henry, Inc. All rights reserved. 性質 → 解決すべきチャレンジ 巨大 高密度 変化 開発をスケーラブルにできるか 疎結合を保てるか 柔軟に適応できるか
20. Copyright © Henry, Inc. All rights reserved. Copyright © Henry, Inc. All rights reserved. トップダウンな設計の限界
21. Copyright © Henry, Inc. All rights reserved. これら全ての詳細を、トップダウンで事前に設計しきることは不可能 広大さ 全容が掴めないほどの広さ 深さ 個々の機能の複雑さ 全体像を描ききれない
22. Copyright © Henry, Inc. All rights reserved. 個々の業務も、例外パターンの山で構成される 裾野に行けば行くほど、全体設計を揺るがすような 「例外的な仕様」が潜んでいる。 ロングテールなパターンの塊
23. Copyright © Henry, Inc. All rights reserved. ドメインの性質との向き合い方 全員アーキテクト
24. Copyright © Henry, Inc. All rights reserved. 隣接するコンテキストとの整合性を取る場面は、 特定の人・領域・タイミングだけでなく、日々の開発の現場で発生する。 なぜ「全員」なのか？
25. Copyright © Henry, Inc. All rights reserved. 隣接するコンテキストとの整合性を取る場面は、 特定の人・領域・タイミングだけでなく、日々の開発の現場で発生する。 なぜ「全員」なのか？ ヘンリーでは、全てのエンジニアがいわゆる “アーキテクト的な視点” を持って開発することが求められているし、必要不可欠。
26. Copyright © Henry, Inc. All rights reserved. 一瞬で巨大な泥団子が構築される アドホックな修正の積み重ねで依存関係は崩壊し、 一瞬で修正不可能な状態に陥る。 → アーキテクト視点を意識し続ける仕組みや文化が必要 アーキテクト視点がないと...
27. Copyright © Henry, Inc. All rights reserved. 越境 隣接ドメインへの関心を持つ。 触るドメインの周辺ドメインへの 影響まで想像を巡らせる。 探索 より良い整理を諦めない。 既存の概念整理を疑い続ける。 その領域に最も詳しいのは、常に 「自分」だと考える。 求められる振る舞い
28. Copyright © Henry, Inc. All rights reserved. それ相応の環境が提供されていなければ、全員アーキテクトは実践できない。 いまもなお道半ばだが、実践を目指して歩みを進めてきた。 全員アーキテクトを実践するには
29. Copyright © Henry, Inc. All rights reserved. Copyright © Henry, Inc. All rights reserved. 全員アーキテクトを実践するための 技術戦略
30. Copyright © Henry, Inc. All rights reserved. 初期: マイクロサービスへの挑戦と期待 Main Service 診療報酬 Complicated Subsystem ブラックボックスとして利用 当時の仮説 複雑な診療報酬制度に関する知識を一箇所に閉じ込め、 ブラックボックスとして利用することで、 全員が制度に習熟しなくても開発ができる
31. Copyright © Henry, Inc. All rights reserved. 初期: マイクロサービスへの挑戦と期待 Main Service 診療報酬 Complicated Subsystem ブラックボックスとして利用 当時の仮説 複雑な診療報酬制度に関する知識を一箇所に閉じ込め、 ブラックボックスとして利用することで、 全員が制度に習熟しなくても開発ができる 分断モノリス化...
32. Copyright © Henry, Inc. All rights reserved. • 診療報酬制度をブラックボックス化することは不可能だった。 • あらゆる機能開発で、必ず2つのコードベースを同時に変更する必要があった。 • → 結果として、デプロイも開発も辛い「分断モノリス」へ。 高密度という性質が見えていなかった
33. Copyright © Henry, Inc. All rights reserved. 物理的な壁 リポジトリも分かれていて、隣のコード が見えづらい。 境界を調整するコストが高く、手が出せ ない。 コンウェイの法則 ソフトウェアの分断に合わせて、チーム 体制と知識も分断されていく。 「境界を直そう」という力学が働かなく なる。 最大の問題点：探索と学習の阻害
34. Copyright © Henry, Inc. All rights reserved. ドメインの実態と、ソフトウェア・組織がズレていた ドメイン ソフトウェア 組織 歯車が噛み合わなくなっていた 巨大・高密度・変化 分断モノリス チームと知識の分断
35. Copyright © Henry, Inc. All rights reserved. Copyright © Henry, Inc. All rights reserved. モジュラーモノリスへの移行
36. Copyright © Henry, Inc. All rights reserved. ドメインの性質と向き合うために、物理的な壁を取り払う決断。 • モノレポ化：コードの可視性を高め、変更を atomic に行いやすく • デプロイ単位の統合：API 呼び出しという物理的分断の壁を取り払う • 論理分割（モジュール分割）：一定の秩序と柔軟性 モジュラーモノリスへの移行
37. Copyright © Henry, Inc. All rights reserved. 一定の強制力 全容が見えない中で疎結合を保つため、 コードベース上で依存ルールを強制し、 意識し続ける仕組みが必要だった。 なぜモジュラーモノリスか？ 全員アーキテクトとして振る舞うための環境として適していた 全体構成の探索 論理的な分割に留めることで、境界の調 整コストを下げ、常に全員が境界の調整 を実践できる環境を提供したかった。
38. Copyright © Henry, Inc. All rights reserved. 宣伝：移行プロセスは開発者ブログに！ https://dev.henry.jp
39. Copyright © Henry, Inc. All rights reserved. Copyright © Henry, Inc. All rights reserved. 全員アーキテクトを実践するための 組織戦略
40. Copyright © Henry, Inc. All rights reserved. 自律性が高く安定したチーム • 最適な境界を探索し続けるためには、チームが自律し、かつ安定していな ければならない。 • 継続的にひとつの領域に触れ続けることで初めて見えてくるものがある。
41. Copyright © Henry, Inc. All rights reserved. 自律性が高く安定したチーム • 最適な境界を探索し続けるためには、チームが自律し、かつ安定していな ければならない。 • 継続的にひとつの領域に触れ続けることで初めて見えてくるものがある。 → 開発対象の業務フローを中心としてチームを分割する基本方針 チームにはドメインエキスパートを含めてフルサイクルなメンバーを揃える
42. Copyright © Henry, Inc. All rights reserved. 越境しやすいチーム • 全体最適を実現するためには、全体を俯瞰できるだけの経験が必要 • 社内留学や異動を適切に交えることで、固定化・局所最適化を防ぐ • 技術スタックや開発プロセスの標準を定義し、越境しやすいチームを目指す
43. Copyright © Henry, Inc. All rights reserved. • 開発体制も、ドメインの性質やフェーズに合わせて柔軟に再設計する。 • 例えば、アーキテクトチームの変遷もその一例。 ◦ 一時的にバーチャルチームとして組成し、解散した。 なぜ組成したか？ 指針がなく、個別最適の限界が見えてい た。 → 強力なトップダウンで方向性を示す 必要があった。 なぜ解散したか？ 「全員アーキテクト」を実践する土壌が 整った。 → 特定のチームがボトルネックになる のを避けるため。 開発体制も設計する
44. Copyright © Henry, Inc. All rights reserved. Copyright © Henry, Inc. All rights reserved. 現在地とこれからの課題
45. Copyright © Henry, Inc. All rights reserved. 1プロダクト・緊密連携の壁 • チームに完全な独立性をもたせることは幻想 ◦ 他チームの領域への意図せぬ影響 ◦ 「ちょっとした変更」が引き起こすドミノ倒し • 巨大で高密度な1プロダクトであるがゆえに、チームをどう分割するかは 自明でない ◦ 完全に綺麗な分割は不可能で、チーム構成自体もまだまだ探索が必要 ◦ メンバー構成の都合もあり、100%フルサイクルに自律できているわ けではないのが現状
46. Copyright © Henry, Inc. All rights reserved. これらをいかに単独チームの持ち物にできるか オーナーシップ ⼿段の模索 認知負荷の抑制 深い理解 安全性 独⽴性 理想的なチーム体制を目指す 3つの要素がすべて1:1でチームに紐付くのが理想
47. Copyright © Henry, Inc. All rights reserved. ソフトウェアも組織も螺旋階段を登る • ソフトウェアもチームも、探索の過程で 分割、統合、再整理を繰り返してきた • 大きな変化には常に揺り戻しが伴う • 振り子にならず、登り続けるためには、 目的の明確化とふりかえりが重要
48. Copyright © Henry, Inc. All rights reserved. まとめ • ヘンリーでは、全員アーキテクトというコンセプトでドメインに向き合っ ている • アーキテクチャに正解はなく、自身の学びや環境の変化に応じて、ソフト ウェアも組織も変化し、螺旋階段を登り続ける
49. Copyright © Henry, Inc. All rights reserved. 採用情報や事業や技術について、積極的に発信しています! 採用情報 採用募集ページ 募集中の採用ポジションや募集要項 がご確認いただけます。 オープンポジションのカジュアル面 談も募集していますので、お気軽に お申し込みください。 技術ブログ はてなブログ ヘンリー製品開発チームが運営する 技術ブログです。 会社公式ブログ note ヘンリーで働く人や医療業界や事業 のことが幅広くしれる公式ブログで す。 CEO の逆瀬川も個人で NOTE を発 信しているのでぜひ! 理想駆動ラジオ Spotify プロダクト開発・運営の様子をお届 けするポッドキャストです。