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