すがブロ

sugamasaoのhatenablogだよ

認知負荷の種類と対策と組織文化について

このエントリは、SmartHR Advent Calendar 2023 シリーズ1の3日目です。

これは何

当初、Rubyを取り巻く型情報に関するツールの関係性についてまとめようと思ったのですが、既に良いドキュメントがあり、自分が満足してしまったので別の話題として認知負荷をテーマに筆をとっております。

ツールの関係性については↓のエントリをご覧ください

Ruby 3の静的解析機能のRBS、TypeProf、Steep、Sorbetの関係についてのノート - クックパッド開発者ブログ

閑話休題

認知負荷という言葉、よく聞きますよね。私もよく言いがちでした。しかし、「認知負荷」という言葉をふわふわな認識のまま「なんか大変」という言葉の言い換えにしておくのはせっかくの気づきをフワッとさせたままになってしまうので、正しく概念を理解して、立ち向かえる単位に分割できるとより成果に繋げられると思いませんか？思いますよね。思ってください。

さて、そんな話題については 【増枠！】Developers Meetup 急成長ベンチャーが向き合う「開発生産性」 - connpass というイベントで登壇してお話しさせていただきました。

一方で、タイトルがへちょすぎて内容が想像できないという意見も想像に難くないためこちらで少し補足プラスアルファを書いていこうと思います。

認知負荷 is なに

認知負荷とは記憶に関するモデルのうち「ワーキングメモリ」と呼ばれる、何らかの作業おこなっているときに使用する記憶に関する負荷です。 認知負荷という言葉が位置するもの

そして、その「負荷」にはいくつかの種類があり、それを包括したものが認知負荷と呼ばれるものです。

認知負荷の種類

認知負荷理論として教育心理学者、ジョン・スウェラー氏によって確立された理論で、3つあります

  • 課題内在性負荷
  • 課題外在性負荷
  • 学習関連負荷

それぞれは以下のスライドを見てください

課題内在性負荷の説明 取り組むタスクの難しさによって発生する負荷 課題外在性負荷の説明 取り組むタスクの外側にあり、本質的ではない難しさによる負荷 学習関連負荷 学習するための負荷なので、これが十分に高い状態が望ましいとされる

世の中には私が調べたことより丁寧な資料もあるので、ぜひ併せてご覧くださいませ

www.ipii.co.jp

で、これがわかるとどうなるんだってばよ

ここに書いてあることは認知負荷に私の独自解釈であるため、諸説ある可能性があります。有識者のご意見があればぜひ教えてください🙏

課題内在性負荷 であれば本質的な難しさを減らすことはできないけれど、取り扱うサイズを小さくすることで理解しやすくすることができます。 複雑なロジックを小さなメソッド名に切り出し命名していく、変数名を適切なものに変える、（DDD的な文脈で）ユビキタス言語を利用する、などが挙げられるでしょう。

課題外在性負荷 であれば継ぎ足しで複雑になってしまったif文やループ処理をリファクタリングする、Why Notが正しくコメント化されている、ADRなどによりコードの設計方針を記録として残すなどして、コードを読んでいて「アレ？」となる部分を解消できるようにしていくと良いでしょう。

認知負荷とコードの話は、「プログラマー脳」という書籍がめちゃくちゃ参考になるので、ぜひ読んでみてください

www.shuwasystem.co.jp

これらを推進するには組織文化が重要

ここまで書いてあることは、一般的なエンジニアであれば「まあ個別には気になったら対応するよな」というものも多いでしょう。しかし、これらを「気になった個人」駆動でプロダクト全体に一定の規律をもたらすのはとても難しい*1ため、チームや組織の望ましい振る舞いとして浸透・後押ししている必要があるんですよね。

さらに、組織文化だけではなくプロダクトに対してオーナーシップを持てているか？ということも重要な観点になります。 今この瞬間はちょっと妥協できても、半年後、一年後にこのコードが耐えうるかは考慮できる状態になっていてほしいし、既に難しくなってしまったコードにもきちんと立ち向かえる環境である必要があります。

そういった観点で、こういった文化をより強固にしていくための取り組みは社のテックブログに書きました チーム内にテックな話題を話す場を作っておよそ半年が経ちました - SmartHR Tech Blog

さて、ここまで書いた負荷を減らすという話と似た概念として技術的負債（の解消）というワードがあるかと思いますが、これに関してはさいきん目にした↓の資料が良すぎて血の涙が流れました。

このエントリではどちらかと言えば個人がどのように認知負荷を捉えるか？という話題を書いたのですが、例えば「チームトポロジー」のような組織構造と認知負荷の話もありますし、個人としても組織としても両方で立ち向かっていかないといけないんですよね。つまり、ハサミ討ちの形になるな…

認知負荷の詳細を把握してから問題を見ると、フワフワな課題の輪郭を捉えやすくなる

ここまで書いてきたことは、身も蓋もないことを言うと何らかの課題を分割するためにどのような尺度を使って捉えるかという話でした。 もちろん、「認知負荷」で全ての課題を分類できるわけではないと思いますが、成長していくソフトウェアや組織に携わっていると有用なシーンも多いと感じます。

引き続き頑張っていきましょう。

*1:もちろん、十分スキルフルで少人数なチームであれば労せず達成できる可能性はあります