$30 off During Our Annual Pro Sale. View Details »

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

Agata Naomichi
June 16, 2023
230

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

Agata Naomichi

June 16, 2023
Tweet

Transcript

  1. 認知負荷バスターズ! 2023-06-16
    医療系スタートアップが経験した

    認知負荷問題の症状分析と処⽅箋
    チーム分割による認知負荷の軽減

    View Slide

  2. Naomichi Agata

    2 0 2 1
    .
    0 4
    ~ Henry, Inc.


    • 医事会計システムチーム


    • リードエンジニア
    ⾃⼰紹介
    @agatan / @agatan_

    View Slide

  3. • ヘンリー開発チームの直⾯した認知負荷増⼤による課題と、それらを乗り越え
    るためにチームが取り組んだことについてお話します。


    • 領域問わず、ドメインが複雑で苦しんでいる⽅は多いと思うので、なにかしら
    参考になれば幸いです!
    今⽇話すこと

    View Slide

  4. ヘンリーの感じた認知負荷にまつわる課題

    View Slide

  5. Henry は何をつくっているのか
    • ざっくり「レセコン⼀体型電⼦カルテ」といわれるものをつくっています。


    • 電⼦カルテ .. 医療情報を記録‧管理するソフトウェア


    • レセコン (レセプトコンピュータ) .. 診療報酬制度に基づいた会計情報を管
    理するソフトウェア


    • ドメイン知識の難易度が⾼く、量が多い


    • 厳格にルールに則ることが求められる


    • ルール⾃体が膨⼤で複雑


    • 開発チーム内にドメインエキスパートがいる

    View Slide

  6. チームの課題
    • コードが複雑で理解に時間がかかる…


    • 特定のモジュールについて開発できる⼈が限られている…


    • 作るものを正確に理解できない…


    • どう作ったらよいか適切に判断できない…

    View Slide

  7. ヘンリーにおける認知負荷増⼤の症状…

    View Slide

  8. ヘンリーにおける認知負荷増⼤の症状…
    認知負荷が⾼い状態で作ると、複雑化に⻭⽌めがかからない


    それが更に新しい認知負荷を⽣み出す負のループ

    View Slide

  9. なぜこうなったのか
    • プロダクトやチームが育つにつれ、チーム体制が現実と乖離していっていた


    • チームの境界が適切でないために…


    • Project: ひとつの機能をリリースするのに、2つのチームの進捗をみる必要がある


    • Engineering: 触る必要のあるコードが散らばっている


    • Domain: 広い知識を理解する必要がある


    • Product: 仕様の認識齟齬が発⽣し、品質‧デリバリー速度が低下する


    • チームの認知負荷の許容量を超えていた 🤯

    View Slide

  10. 対処するための取り組み

    View Slide

  11. 認知負荷
    • “ワーキングメモリで利⽤される⼼理的労⼒の総量”


    • by ⼼理学者ジョン‧スウェラー, 1988


    • ワーキングメモリの容量は限定的


    • 例えば、あるビジネスロジックを開発するときに…


    • 「ソフトウェアのビルドやデプロイの⽅法」には容量を割きたくない


    • 「ビジネスロジックそのもの」に容量を割きたい


    • 「ビジネスロジックをどうソフトウェアに落とし込むか」に最も容量を割きたい


    • 適切な割合になっていないと、ソフトウェアの進化が遅れる

    View Slide

  12. 対処するための取り組み
    • 認知すべきものの総量を減らす


    • ひとつひとつの認知にかかる負荷を減らす
    チームの分解点を⾒直すことで、以下の2つを達成 / 効率化する

    View Slide

  13. どういうチーム分解を⽬指したいか
    • 元々の体制は、ドメインが2つに割れてしまっていた


    • あるドメインについての開発が、1チームで完結する状態を⽬指したい


    • これによって以下のような状態になることを期待する


    • Project: チーム内の進捗が⾒えていればOK


    • Engineering: チームの所有物を変更するだけで開発できる(チームを変えただけで変わらないが)


    • Domain: 全体を知る必要がなくなり、範囲を絞って理解を深められる


    • Product: チームで品質‧デリバリーに責任を持てる

    View Slide

  14. まずはドメインの⾒直し
    • 現状のプロダクトに存在する “ドメイン” を洗い出した


    • Entityや重要な処理を列挙し、関係性を図⽰した

    View Slide

  15. まずはドメインの⾒直し
    • AsIs をもとに ToBe を作る


    • 細分化しすぎても意味がないので、まとめる


    • チーム体制に反映できない


    • 考えたToBeが真の正解かはわからない


    • サービスとしても発展途上


    • 我々の練度‧理解度も恐らく不⾜している


    • → 将来的な発展‧修正の余地を折り込む

    View Slide

  16. 現実的な移⾏プランに落とし込む
    • 単純な理想系は 1チーム = 1ドメイン = 1コードベース


    • 移⾏を現実的にするために解きたい課題は以下の2つ


    • ドメインの数だけチームを分けられるほどのリソースがない


    • 既存のコードベースが理想形と⼤きく乖離している

    View Slide

  17. 現実的な移⾏プランに落とし込む
    • 関連の深いドメインを2~3個ずつ束ねて、1つのチームで⾒ることにした


    • PdM, ドメインエキスパートの⼈数的にもこれが限界だった


    • まだドメインの境界が曖昧な箇所もあるため、今後の発展を模索する余地を
    残すという意味合いも

    View Slide

  18. 現実的な移⾏プランに落とし込む
    • 既存のコードベースは主に2つのGitHub Repositoryに分かれていた


    • 理想形は既存の切り⽅とは⼤きく異なるイメージになった


    • → まずは初⼿として、モノレポへ移⾏
    詳細は技術ブログを参照してください!
    dev.henry.jp

    View Slide

  19. チーム分割の結果
    • それぞれのメンバーのワーキングメモリを効率的に使えるようになった 🎉


    • 当初の⽬論⾒は概ね達成できた 🎉


    • Project: チーム内の進捗が⾒えていればOK 👍


    • Engineering: ⽅向性は⽰せたので理想に向けて動ける状態に 🏃


    • Domain: 全体を知る必要がなくなり、範囲を絞って理解を深められる 👍


    • Product: チームで品質‧デリバリーに責任を持てる 👍

    View Slide

  20. チーム分割の結果
    • チーム分割がうまくドメインとアラインすると、知識共有の効果‧効率が

    格段にあがる


    • ほとんどの知識共有が、それぞれのメンバーのタスクとリンクする


    • 愚直にモブプログラミングやドメイン勉強会を⾏なっている


    • チーム内に、ドメインに詳しいエンジニアやシステムもわかるドメインエ
    キスパートがいる!

    View Slide

  21. 他にもいろいろな取り組みをやっています!
    • Design Document / ADR (Architecture Decision Record)


    • 内部設計の意図や決定の経緯を記すドキュメント


    • ⼩さいTipsレベルの気配り


    • protoに設計の意図を表明する


    • 無理な英語変数名を避ける


    • 有志による医療事務資格勉強会

    View Slide

  22. 宣伝!
    • 開発における認知負荷を下げる設計や組織の営みに関⼼のある⽅!


    • 複雑なドメインにダイブして社会課題を解決したい⽅!


    • 医療の知識を活かして新しいプロダクトを作っていきたい⽅!


    ぜひお話しましょう!!


    https://jobs.henry-app.jp

    View Slide