医療系スタートアップが経験した 認知負荷問題の症状分析と処方箋 チーム分割による認知負荷の軽減 / Cognitive Load Busters

2023/06/16 の「認知負荷バスターズ！」登壇資料です。
https://henry.connpass.com/event/284107/
https://dev.henry.jp/entry/backend-monorepo-part-1
https://jobs.henry-app.jp

Transcript

1. 認知負荷バスターズ！ 2023-06-16 医療系スタートアップが経験した 
 認知負荷問題の症状分析と処⽅箋 チーム分割による認知負荷の軽減
2. Naomichi Agata • 2 0 2 1 . 0 4 ~ Henry, Inc. • 医事会計システムチーム • リードエンジニア ⾃⼰紹介 @agatan / @agatan_
3. • ヘンリー開発チームの直⾯した認知負荷増⼤による課題と、それらを乗り越え るためにチームが取り組んだことについてお話します。 • 領域問わず、ドメインが複雑で苦しんでいる⽅は多いと思うので、なにかしら 参考になれば幸いです！ 今⽇話すこと
4. ヘンリーの感じた認知負荷にまつわる課題
5. Henry は何をつくっているのか • ざっくり「レセコン⼀体型電⼦カルテ」といわれるものをつくっています。 • 電⼦カルテ .. 医療情報を記録‧管理するソフトウェア • レセコン (レセプトコンピュータ) .. 診療報酬制度に基づいた会計情報を管 理するソフトウェア • ドメイン知識の難易度が⾼く、量が多い • 厳格にルールに則ることが求められる • ルール⾃体が膨⼤で複雑 • 開発チーム内にドメインエキスパートがいる
6. チームの課題 • コードが複雑で理解に時間がかかる… • 特定のモジュールについて開発できる⼈が限られている… • 作るものを正確に理解できない… • どう作ったらよいか適切に判断できない…
7. ヘンリーにおける認知負荷増⼤の症状…
8. ヘンリーにおける認知負荷増⼤の症状… 認知負荷が⾼い状態で作ると、複雑化に⻭⽌めがかからない それが更に新しい認知負荷を⽣み出す負のループ
9. なぜこうなったのか • プロダクトやチームが育つにつれ、チーム体制が現実と乖離していっていた • チームの境界が適切でないために… • Project: ひとつの機能をリリースするのに、2つのチームの進捗をみる必要がある • Engineering: 触る必要のあるコードが散らばっている • Domain: 広い知識を理解する必要がある • Product: 仕様の認識齟齬が発⽣し、品質‧デリバリー速度が低下する • チームの認知負荷の許容量を超えていた 🤯
10. 対処するための取り組み
11. 認知負荷 • “ワーキングメモリで利⽤される⼼理的労⼒の総量” • by ⼼理学者ジョン‧スウェラー, 1988 • ワーキングメモリの容量は限定的 • 例えば、あるビジネスロジックを開発するときに… • 「ソフトウェアのビルドやデプロイの⽅法」には容量を割きたくない • 「ビジネスロジックそのもの」に容量を割きたい • 「ビジネスロジックをどうソフトウェアに落とし込むか」に最も容量を割きたい • 適切な割合になっていないと、ソフトウェアの進化が遅れる
12. 対処するための取り組み • 認知すべきものの総量を減らす • ひとつひとつの認知にかかる負荷を減らす チームの分解点を⾒直すことで、以下の2つを達成 / 効率化する
13. どういうチーム分解を⽬指したいか • 元々の体制は、ドメインが2つに割れてしまっていた • あるドメインについての開発が、1チームで完結する状態を⽬指したい • これによって以下のような状態になることを期待する • Project: チーム内の進捗が⾒えていればOK • Engineering: チームの所有物を変更するだけで開発できる（チームを変えただけで変わらないが） • Domain: 全体を知る必要がなくなり、範囲を絞って理解を深められる • Product: チームで品質‧デリバリーに責任を持てる
14. まずはドメインの⾒直し • 現状のプロダクトに存在する “ドメイン” を洗い出した • Entityや重要な処理を列挙し、関係性を図⽰した
15. まずはドメインの⾒直し • AsIs をもとに ToBe を作る • 細分化しすぎても意味がないので、まとめる • チーム体制に反映できない • 考えたToBeが真の正解かはわからない • サービスとしても発展途上 • 我々の練度‧理解度も恐らく不⾜している • → 将来的な発展‧修正の余地を折り込む
16. 現実的な移⾏プランに落とし込む • 単純な理想系は 1チーム = 1ドメイン = 1コードベース • 移⾏を現実的にするために解きたい課題は以下の２つ • ドメインの数だけチームを分けられるほどのリソースがない • 既存のコードベースが理想形と⼤きく乖離している
17. 現実的な移⾏プランに落とし込む • 関連の深いドメインを2~3個ずつ束ねて、1つのチームで⾒ることにした • PdM, ドメインエキスパートの⼈数的にもこれが限界だった • まだドメインの境界が曖昧な箇所もあるため、今後の発展を模索する余地を 残すという意味合いも
18. 現実的な移⾏プランに落とし込む • 既存のコードベースは主に2つのGitHub Repositoryに分かれていた • 理想形は既存の切り⽅とは⼤きく異なるイメージになった • → まずは初⼿として、モノレポへ移⾏ 詳細は技術ブログを参照してください！ dev.henry.jp
19. チーム分割の結果 • それぞれのメンバーのワーキングメモリを効率的に使えるようになった 🎉 • 当初の⽬論⾒は概ね達成できた 🎉 • Project: チーム内の進捗が⾒えていればOK 👍 • Engineering: ⽅向性は⽰せたので理想に向けて動ける状態に 🏃 • Domain: 全体を知る必要がなくなり、範囲を絞って理解を深められる 👍 • Product: チームで品質‧デリバリーに責任を持てる 👍
20. チーム分割の結果 • チーム分割がうまくドメインとアラインすると、知識共有の効果‧効率が 
 格段にあがる • ほとんどの知識共有が、それぞれのメンバーのタスクとリンクする • 愚直にモブプログラミングやドメイン勉強会を⾏なっている • チーム内に、ドメインに詳しいエンジニアやシステムもわかるドメインエ キスパートがいる！
21. 他にもいろいろな取り組みをやっています！ • Design Document / ADR (Architecture Decision Record) • 内部設計の意図や決定の経緯を記すドキュメント • ⼩さいTipsレベルの気配り • protoに設計の意図を表明する • 無理な英語変数名を避ける • 有志による医療事務資格勉強会
22. 宣伝！ • 開発における認知負荷を下げる設計や組織の営みに関⼼のある⽅！ • 複雑なドメインにダイブして社会課題を解決したい⽅！ • 医療の知識を活かして新しいプロダクトを作っていきたい⽅！ ぜひお話しましょう！！ https://jobs.henry-app.jp