認知負荷とは？新人エンジニア向けに「頭がいっぱいになる理由」と学習・開発への活かし方を解説
山崎講師こんにちは。ゆうせいです。
今回は、新人エンジニアにぜひ知っておいてほしい「認知負荷」について解説します。
認知負荷とは、簡単に言うと「頭の中で情報を処理するときにかかる負担」のことです。
たとえば、こんな経験はありませんか？
説明を聞いているときは分かった気がしたのに、あとで自分でやろうとしたら手が止まる エラー文、コード、DB、画面、ログを同時に見ていたら混乱する Gitの操作、ブランチ名、コミット内容、レビュー依頼が一気に出てきて頭がいっぱいになる AWSの画面で、EC2、VPC、IAM、セキュリティグループという言葉が同時に出てきて疲れる 研修資料を読んでも、知らない用語が多すぎて内容が入ってこない
このような「頭がいっぱいで処理しきれない状態」が、認知負荷の高い状態です。
新人エンジニアは、認知負荷が高くなりやすいです。
なぜなら、プログラミング、データベース、ネットワーク、Git、クラウド、セキュリティ、業務知識など、同時に覚えることが多いからです。
だからこそ、「自分は頭が悪いのでは？」と落ち込む必要はありません。
多くの場合、問題は能力ではなく、頭に入れる情報の量や順番にあります。
認知負荷とは何か
認知負荷とは、人が情報を理解したり、記憶したり、判断したりするときに、作業記憶へかかる負担のことです。
作業記憶とは、頭の中で一時的に情報を置いておく場所です。
英語ではワーキングメモリと呼ばれます。
たとえるなら、作業記憶は机の上です。
机の上が広ければ、ノート、教科書、資料、ペンを置いて作業できます。
しかし、机の上が狭いのに、資料を10冊、ノートを5冊、パソコン、飲み物、工具まで置いたらどうなるでしょうか。
作業しにくくなりますよね。
人間の頭の中も同じです。
一度に扱える情報には限界があります。
コードを見る エラー文を見る 仕様を思い出す DB構造を考える 画面遷移を考える 上司の説明を聞く 次に何をするか判断する
これらを同時に処理しようとすると、作業記憶の机がいっぱいになります。
その結果、理解が止まったり、ミスが増えたり、疲れたりします。
新人エンジニアが認知負荷を感じやすい理由
新人エンジニアは、ベテランより認知負荷が高くなりやすいです。
理由は、知識がまだ自動化されていないからです。
たとえば、ベテランは「Controller」「Service」「Repository」という言葉を聞くと、だいたいの役割をすぐに思い出せます。
しかし、新人は1つずつ考えます。
Controllerって何だっけ？ Serviceは何をする場所だっけ？ RepositoryはDAOと同じ？ DTOとEntityは何が違う？ Formはどこで使う？
このように、用語を理解するだけで作業記憶を使います。
その状態で、さらにコードを書こうとすると、頭がいっぱいになります。
| 項目 | ベテラン | 新人 |
|---|---|---|
| 用語理解 | すぐ分かる | 毎回思い出す必要がある |
| エラー対応 | よくある原因を想像できる | エラー文の意味から調べる |
| コード構造 | 全体像をつかみやすい | どこを見ればよいか迷う |
| 作業手順 | 自然に進められる | 1つずつ確認しながら進める |
| 負荷 | 低くなりやすい | 高くなりやすい |
新人が疲れやすいのは、努力不足ではありません。
まだ多くの情報を意識して処理している段階だからです。
認知負荷の3種類
認知負荷は、大きく3種類に分けて考えると分かりやすいです。
| 種類 | 意味 | 新人エンジニア向けの例 |
|---|---|---|
| 内在的負荷 | 学ぶ内容そのものの難しさ | 再帰、非同期処理、VPC、IAM、トランザクション |
| 外在的負荷 | 説明や環境の悪さによって余計に増える負担 | 資料が分かりにくい、手順が飛ぶ、画面と説明が違う |
| 学習関連負荷 | 理解や成長に役立つ負担 | 自分で考える、比較する、整理する、説明する |
この3つはとても重要です。
特に、新人研修やOJTでは、「外在的負荷」を減らし、「学習関連負荷」を増やすことが大切です。
内在的負荷とは
内在的負荷とは、学ぶ内容そのものが持っている難しさです。
たとえば、HTMLの見出しタグを学ぶのと、Spring Securityの認証・認可を学ぶのでは、難しさが違います。
Spring Securityのほうが、関係する概念が多いため、内在的負荷が高くなります。
| 負荷が低めの内容 | 負荷が高めの内容 |
|---|---|
| HTMLの見出し | 認証・認可 |
| SELECT文 | JOINとGROUP BYを組み合わせた集計 |
| 変数 | オブジェクト指向設計 |
| 画面表示 | バリデーションと例外処理 |
| S3のファイルアップロード | VPC、サブネット、ルートテーブル、IAMロールの組み合わせ |
内在的負荷が高い内容は、分解して学ぶ必要があります。
いきなり全部を理解しようとしてはいけません。
たとえば、VPCを学ぶなら、次のように分けます。
VPCとは何か
↓
サブネットとは何か
↓
ルートテーブルとは何か
↓
インターネットゲートウェイとは何か
↓
セキュリティグループとは何か
↓
全体を組み合わせる
難しい内容は、階段にしろ！
一段ずつ上がれば理解できます。
外在的負荷とは
外在的負荷とは、本来の学習とは関係ない余計な負担です。
たとえば、説明資料が分かりにくい場合です。
専門用語の説明がない 手順が途中で省略されている 画面キャプチャが古い ファイル名が資料と違う エラーが出たときの対応が書かれていない
このような状態だと、受講者は本来学ぶべき内容ではなく、資料の読み解きに力を使ってしまいます。
エンジニアの研修で言えば、Spring Bootを学ぶはずなのに、資料の誤字や手順漏れで時間を使う状態です。
| 外在的負荷が高い状態 | 問題点 |
|---|---|
| 資料と画面が違う | 受講者が不安になる |
| 手順が飛んでいる | 初心者が再現できない |
| 用語説明がない | 理解の前に言葉で詰まる |
| コード例が長すぎる | どこを見ればよいか分からない |
| 目的が書かれていない | なぜその操作をするのか分からない |
外在的負荷は、できるだけ減らすべき負荷です。
初心者向けの資料では、説明の順番、用語、画面、コードの見せ方がとても重要になります。
学習関連負荷とは
学習関連負荷とは、理解や成長につながる良い負荷です。
負荷と聞くと悪いものに感じるかもしれませんが、すべての負荷が悪いわけではありません。
筋トレを思い出してください。
重すぎる負荷はケガにつながります。
しかし、適度な負荷がなければ筋肉は育ちません。
学習も同じです。
ただ答えを写すだけでは、あまり成長しません。
少し考える、比較する、自分の言葉で説明する、エラー原因を推測する。
こうした負荷は、学習に必要です。
| 良い負荷 | 理由 |
|---|---|
| コードの意味を説明する | 理解が深まる |
| 似た概念を比較する | 違いが整理される |
| エラー原因を予想する | デバッグ力が育つ |
| 自分で小さく改造する | 応用力がつく |
| 人に説明する | 知識が定着する |
研修では、外在的負荷を減らし、学習関連負荷を残すことが理想です。
つまり、「分かりにくさ」は減らし、「考える余地」は残します。
認知負荷が高いと何が起きるか
認知負荷が高すぎると、新人エンジニアには次のようなことが起きます。
| 状態 | 具体例 |
|---|---|
| 理解が止まる | 説明を聞いても頭に入らない |
| ミスが増える | ファイル名、変数名、手順を間違える |
| 視野が狭くなる | エラーの一部分だけ見てしまう |
| 質問できなくなる | 何が分からないか分からない状態になる |
| 疲れやすくなる | 短時間でもぐったりする |
| 自信を失う | 自分は向いていないと思ってしまう |
特に怖いのは、「何が分からないか分からない」状態です。
この状態では、質問も難しくなります。
たとえば、Spring Bootのエラーで詰まっているとします。
認知負荷が高すぎると、次のように混乱します。
Controllerが悪いのか HTMLが悪いのか Formが悪いのか 入力名が悪いのか URLが悪いのか DBが悪いのか そもそも何を見ればよいのか分からない
この状態になったら、頑張り続けるより、情報を減らすことが先です。
認知負荷を下げるコツ1：一度に学ぶ量を減らす
認知負荷を下げる基本は、一度に扱う情報を減らすことです。
初心者にいきなり全部を見せると混乱します。
たとえば、Webアプリ開発を学ぶときに、最初から次を全部扱うと大変です。
HTML CSS JavaScript Java Spring Boot Thymeleaf SQL DB接続 バリデーション セッション ログイン 例外処理 Git
この量を一度に扱うと、頭の机がいっぱいになります。
そこで分けます。
| 段階 | 学ぶ内容 |
|---|---|
| 1 | HTMLだけで画面を作る |
| 2 | Controllerから画面を表示する |
| 3 | Formで入力値を受け取る |
| 4 | Serviceで処理を書く |
| 5 | DBからデータを取得する |
| 6 | バリデーションを追加する |
| 7 | ログインやセッションを学ぶ |
分けると、1回あたりの認知負荷が下がります。
学習は詰め込みではありません。
順番が大事です。
認知負荷を下げるコツ2：用語を先に整理する
専門用語が多いと、認知負荷は一気に上がります。
新人エンジニアがSpring Bootを学ぶとき、次のような言葉が出てきます。
Controller Service Repository Entity DTO Form Model Validation BindingResult DI Bean
これらの意味が分からないままコードを見ると、コード以前に言葉で詰まります。
そのため、最初に用語を簡単に整理します。
| 用語 | 初心者向け説明 |
|---|---|
| Controller | 画面やURLから来たリクエストを受け取る入口 |
| Service | 業務処理を書く場所 |
| Repository | DBとのやり取りを担当する場所 |
| Entity | DBのテーブルに近いデータの入れ物 |
| Form | 画面から入力された値を受け取る入れ物 |
| DTO | データを運ぶための入れ物 |
用語を先に整理すると、コードを読むときの負担が下がります。
地図を見てから街を歩くようなものです。
地図なしで歩くと迷います。
認知負荷を下げるコツ3：コードを短く見せる
初心者に長いコードを一気に見せると、認知負荷が高くなります。
たとえば、最初からController、Service、Repository、Entity、HTML、SQLを全部見せると、どこに注目すればよいか分かりません。
コードは、学習目的に合わせて短く見せるのがコツです。
| 悪い見せ方 | 良い見せ方 |
|---|---|
| 完成コードを全部見せる | 今日見る部分だけ切り出す |
| 説明なしで貼る | 目的、入力、出力を添える |
| 一度に複数ファイルを見せる | 1ファイルずつ役割を説明する |
| 差分が分からない | 変更前と変更後を比較する |
新人エンジニアがコードを読むときは、次の順番がおすすめです。
このコードは何のためにあるのか
↓
どこから呼ばれるのか
↓
何を受け取るのか
↓
何を返すのか
↓
どこを変更すればよいのか
いきなり細部に入らないでください。
まず役割を見ましょう。
認知負荷を下げるコツ4：チェックリストを使う
新人エンジニアは、作業手順を覚えるだけでも負荷がかかります。
そこでチェックリストを使います。
チェックリストは、頭の中で覚える情報を外に出す道具です。
たとえば、Pull Requestを出す前のチェックリストです。
不要なconsole.logやSystem.out.printlnが残っていないか テストは通っているか レビューしてほしい点を書いたか Issue番号を記載したか 不要なファイルをコミットしていないか 画面表示を確認したか
チェックリストがあると、毎回頭の中で思い出す必要がありません。
| チェックリストなし | チェックリストあり |
|---|---|
| 毎回思い出す必要がある | 見れば分かる |
| 抜け漏れが起きやすい | 確認しやすい |
| 不安が残る | 安心して進めやすい |
| 作業が属人化する | チームで標準化できる |
覚えるな。外に出せ！
これが認知負荷を下げる基本です。
認知負荷を下げるコツ5：エラー対応を手順化する
エラー対応は、認知負荷が高くなりやすい作業です。
エラーが出ると焦ります。
焦ると視野が狭くなります。
その結果、さらに解決しにくくなります。
だから、エラー対応は手順化しましょう。
1. エラーメッセージを読む 2. 最初に出ているエラーを確認する 3. ファイル名と行番号を見る 4. 直前に変更した箇所を確認する 5. 入力値やURLを確認する 6. ログを確認する 7. 分からなければ、試したことを整理して質問する
手順があると、頭が真っ白になりにくくなります。
| 悪い対応 | 良い対応 |
|---|---|
| とにかくコードをいじる | エラー文を読む |
| 全部を疑う | 直前の変更から見る |
| 何となく検索する | エラー文の重要部分で検索する |
| 質問で「動きません」と言う | 状況、エラー、試したことを伝える |
エラー対応では、考える前に整理です。
整理すれば、認知負荷が下がります。
認知負荷を下げる質問の仕方
新人エンジニアは、質問の仕方にも認知負荷が関係します。
頭がいっぱいの状態では、質問もぼんやりします。
動きません 分かりません エラーが出ました 何が悪いですか？
この質問だと、先輩も状況を把握するために多くの情報を聞き返す必要があります。
質問するときは、次の型を使うとよいです。
やりたいこと： ログイン画面で未入力時にエラーメッセージを表示したいです。 起きていること： 送信すると400エラーになります。 見たエラー： Required request parameter 'email' is not present 試したこと： HTMLのinput nameを確認しました。 Controllerの引数名も確認しました。 見てほしいこと： HTMLのname属性とControllerの受け取り方が合っているか確認していただきたいです。
このように整理すると、自分の頭も整理されます。
質問は、相手のためだけではありません。
自分の認知負荷を下げるためにも役立ちます。
認知負荷とUI/UX設計
認知負荷は、ユーザー向けの画面設計にも関係します。
UIとは、User Interfaceの略で、画面やボタンなど、ユーザーが操作する部分です。
UXとは、User Experienceの略で、ユーザーがサービスを使う中で得る体験全体のことです。
認知負荷が高い画面は、ユーザーを疲れさせます。
| 認知負荷が高い画面 | 認知負荷が低い画面 |
|---|---|
| ボタンの意味が分からない | ボタン名が具体的 |
| 入力項目が多すぎる | 必要な項目だけ表示する |
| エラー文が抽象的 | どこを直せばよいか分かる |
| 次に何をすればよいか分からない | 次の行動が明確 |
| 情報が詰め込まれている | 見出しや余白で整理されている |
たとえば、エラーメッセージを比べてみましょう。
入力エラーです。
このメッセージは、ユーザーにとって不親切です。
どこを直せばよいか分からないからです。
改善例です。
メールアドレスを入力してください。
こちらのほうが、ユーザーの認知負荷が下がります。
新人エンジニアが画面を作るときは、「ユーザーが考えなくても次に進めるか」を意識してください。
認知負荷とドキュメント作成
ドキュメントも、認知負荷に大きく影響します。
良いドキュメントは、読む人の負担を減らします。
悪いドキュメントは、読む人の頭を疲れさせます。
| 悪いドキュメント | 良いドキュメント |
|---|---|
| 目的が分からない | 最初に目的が書いてある |
| 前提条件がない | 必要な環境や権限が書いてある |
| 手順が長文だけ | 番号付きで手順が整理されている |
| エラー時の対応がない | よくあるエラーと対処がある |
| 完了条件がない | 最後に確認方法が書いてある |
手順書を書くときは、次の順番がおすすめです。
目的 前提条件 作業手順 確認方法 よくあるエラー 片付け・注意点
この型にすると、読み手の認知負荷が下がります。
認知負荷とコードの読みやすさ
コードにも認知負荷があります。
読みにくいコードは、読む人の頭に余計な負担をかけます。
読みやすいコードは、認知負荷を下げます。
| 認知負荷が高いコード | 認知負荷が低いコード |
|---|---|
| 変数名が意味不明 | 変数名から役割が分かる |
| 1つのメソッドが長すぎる | 処理が小さく分かれている |
| 条件分岐が深すぎる | 早期returnなどで読みやすい |
| 責務が混ざっている | Controller、Serviceなど役割が分かれている |
| コメントがない、または多すぎる | 必要な意図だけコメントされている |
新人エンジニアは、コードを書くときに「未来の自分が読んで分かるか」を考えてください。
未来の自分は、今日の自分ほど文脈を覚えていません。
読みやすいコードは、未来の自分への親切です。
認知負荷とチーム開発
チーム開発では、認知負荷を下げる仕組みが重要です。
チーム全体で情報が散らばっていると、メンバーは毎回探す必要があります。
仕様はどこ？ 環境構築手順はどこ？ DB定義はどこ？ API仕様はどこ？ レビュー観点は何？ リリース手順は誰が知っている？
この状態では、作業そのものより、探すことに時間を使います。
チームで認知負荷を下げるには、情報の置き場所を決めます。
| 情報 | 置き場所の例 |
|---|---|
| タスク | Issue、Backlog、Jiraなど |
| 仕様 | 設計書、Wiki、README |
| 環境構築 | README、セットアップ手順書 |
| レビュー観点 | Pull Requestテンプレート |
| 決定事項 | 議事録、ADR |
| 運用手順 | Runbook、運用手順書 |
情報の置き場所を決めるだけで、チームの認知負荷は大きく下がります。
探す時間を減らせ！
認知負荷のメリット
認知負荷は悪いものだけではありません。
適度な認知負荷は、成長に必要です。
| メリット | 説明 |
|---|---|
| 理解が深まる | 少し考えることで知識が定着する |
| 応用力がつく | 自分で試行錯誤すると対応力が育つ |
| 記憶に残りやすい | 苦労して解いた内容は忘れにくい |
| 問題解決力が育つ | エラー原因を考える力がつく |
| 説明力が上がる | 自分の言葉で整理すると理解が深まる |
大切なのは、負荷をゼロにすることではありません。
余計な負荷を減らし、成長につながる負荷を残すことです。
認知負荷のデメリット
認知負荷が高すぎると、デメリットが目立ちます。
| デメリット | 説明 |
|---|---|
| 理解が止まる | 情報量が多すぎて処理できなくなる |
| ミスが増える | 注意力が分散する |
| 疲労が強くなる | 短時間でもぐったりする |
| 学習意欲が下がる | 自分には無理だと感じやすい |
| 質問しづらくなる | 何を聞けばよいか分からなくなる |
認知負荷が高すぎるときは、努力で押し切るより、情報を減らしてください。
資料を分ける。
タスクを小さくする。
用語を整理する。
チェックリストを使う。
それだけで、かなり楽になります。
新人エンジニアが明日から使える実践法
明日から使える方法をまとめます。
| 実践法 | やり方 |
|---|---|
| 今日のタスクを3つに絞る | やることを増やしすぎない |
| 分からない用語を書く | 用語リストを作って1つずつ調べる |
| 作業手順をメモする | 頭で覚えず、外に出す |
| エラー対応を型にする | エラー文、行番号、直前の変更を確認する |
| 質問をテンプレート化する | やりたいこと、起きていること、試したことを書く |
| 休憩を入れる | 頭がいっぱいになったら一度離れる |
特におすすめなのは、作業前に次のメモを書くことです。
今からやること： ログイン画面の未入力エラーを表示する 見るファイル： login.html LoginController.java LoginForm.java 完了条件： メールアドレス未入力で送信したとき、画面にエラー文が表示される 詰まったら見るもの： エラーメッセージ inputのname属性 Controllerの引数 BindingResultの位置
このメモがあると、頭の中で保持する情報が減ります。
認知負荷を下げるには、頭の外に情報を出すことが大切です。
まとめ
認知負荷とは、情報を理解したり、判断したり、作業したりするときに、頭の中へかかる負担のことです。
新人エンジニアは、知らない用語、初めて見るコード、慣れないツール、複雑な手順が同時に出てくるため、認知負荷が高くなりやすいです。
| 項目 | 内容 |
|---|---|
| 認知負荷 | 頭の中で情報を処理するときの負担 |
| 内在的負荷 | 学習内容そのものの難しさ |
| 外在的負荷 | 資料や環境の分かりにくさによる余計な負担 |
| 学習関連負荷 | 理解や成長につながる良い負担 |
| 対策 | 情報を減らす、分ける、外に出す、手順化する |
一言でまとめるなら、認知負荷は「頭の机の上にどれだけ情報を置いているか」です。
机の上が散らかると、作業しにくくなります。
だから、タスクを分ける、用語を整理する、チェックリストを使う、手順をメモする、質問を型にする。
このようにして、頭の机を片付けましょう。
情報を減らす
↓
順番に並べる
↓
外に書き出す
↓
小さく確認する
↓
理解が進む
↓
次の少し難しい課題へ進む
今後の学習では、認知負荷に加えて、フロー理論、ゴール勾配効果、ツァイガルニク効果、オヴシアンキーナ効果、タスク管理、ドキュメント設計、UI/UX心理学を順番に学ぶとよいです。まずは明日の作業で、「今日やること」「見るファイル」「完了条件」を3行で書き出すところから始めてみましょう！
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール
