全員アーキテクトで挑む、巨大で高密度なドメインの紐解き方

by Agata Naomichi

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright © Henry, Inc. All rights reserved. 多様な専門職の業務が、「診療報酬制度」によって横断的に制約されている。診療報酬制度による業務横断の結合診療報酬制度とは？医療行為の価格（点数）を決める公的なルール。たとえば... ● 初診だったら291点（= 2910円） ● 短時間の静脈麻酔をやったら120点（= 1200円）算定するためにカルテに特定の内容が記録されていることを求めたり、定められた様式で診察内容を記載し患者からの署名をもらうことを求めるようなものもあり、医療の現場での業務に大きな影響を与えるもの。

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Copyright © Henry, Inc. All rights reserved. 一定の強制力全容が見えない中で疎結合を保つため、コードベース上で依存ルールを強制し、意識し続ける仕組みが必要だった。なぜモジュラーモノリスか？全員アーキテクトとして振る舞うための環境として適していた全体構成の探索論理的な分割に留めることで、境界の調整コストを下げ、常に全員が境界の調整を実践できる環境を提供したかった。

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Copyright © Henry, Inc. All rights reserved. 自律性が高く安定したチーム ● 最適な境界を探索し続けるためには、チームが自律し、かつ安定していなければならない。 ● 継続的にひとつの領域に触れ続けることで初めて見えてくるものがある。 → 開発対象の業務フローを中心としてチームを分割する基本方針チームにはドメインエキスパートを含めてフルサイクルなメンバーを揃える

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Copyright © Henry, Inc. All rights reserved. ● 開発体制も、ドメインの性質やフェーズに合わせて柔軟に再設計する。 ● 例えば、アーキテクトチームの変遷もその一例。 ○ 一時的にバーチャルチームとして組成し、解散した。なぜ組成したか？指針がなく、個別最適の限界が見えていた。 → 強力なトップダウンで方向性を示す必要があった。なぜ解散したか？「全員アーキテクト」を実践する土壌が整った。 → 特定のチームがボトルネックになるのを避けるため。開発体制も設計する

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Copyright © Henry, Inc. All rights reserved. 1プロダクト・緊密連携の壁 ● チームに完全な独立性をもたせることは幻想 ○ 他チームの領域への意図せぬ影響 ○ 「ちょっとした変更」が引き起こすドミノ倒し ● 巨大で高密度な1プロダクトであるがゆえに、チームをどう分割するかは自明でない ○ 完全に綺麗な分割は不可能で、チーム構成自体もまだまだ探索が必要 ○ メンバー構成の都合もあり、100%フルサイクルに自律できているわけではないのが現状

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Copyright © Henry, Inc. All rights reserved. 採用情報や事業や技術について、積極的に発信しています! 採用情報採用募集ページ募集中の採用ポジションや募集要項がご確認いただけます。オープンポジションのカジュアル面談も募集していますので、お気軽にお申し込みください。技術ブログはてなブログヘンリー製品開発チームが運営する技術ブログです。会社公式ブログ note ヘンリーで働く人や医療業界や事業のことが幅広くしれる公式ブログです。 CEO の逆瀬川も個人で NOTE を発信しているのでぜひ! 理想駆動ラジオ Spotify プロダクト開発・運営の様子をお届けするポッドキャストです。