所属

株式会社TechBowl

住んでるところ

東京

何やってる？

「TechTrain」というサービスで反復横跳びし続けている何でも屋さん(Laravel, Next.js, AWS, etc...)

趣味

• お酒(よく溺れる)
• サウナ
• 読書

それでは本題に入っていきます・・・！

認知負荷とは

認知負荷（Cognitive Load）：人間の作業記憶にかかる精神的な負担や処理要求の総量

認知負荷の種類

• 内在的認知負荷：タスク自体の複雑さから生じる負荷
• 外在的認知負荷：学習方法や情報提示の仕方から生じる不必要な負荷

内在的認知負荷（Intrinsic Cognitive Load）

内在的認知負荷（Intrinsic Cognitive Load）

内在的認知負荷とは、学習内容やタスク自体の本質的な複雑さから生じる避けられない負荷のこと。

内在的認知負荷（Intrinsic Cognitive Load）の特徴

• 学習素材自体の難しさや複雑さに直接関連
• 内容の要素間の相互関係性の数と強さに比例
• 学習者の既存知識や経験によって相対的に変化

エンジニアオンボーディングでの例

• 複雑なマイクロサービスアーキテクチャの全体像を理解する
• 多層の依存関係を持つライブラリやフレームワークを学ぶ
• 非同期処理や並列計算などの高度な概念を習得する

対処方法とその効果

複雑な概念を小さな単位に分割

• 作業記憶の容量制限（7±2項目）内で情報処理を可能にする
• 一度に処理する情報量を減らし、各単位の深い理解を促進
• 例：マイクロサービスを「認証」「決済」など機能別に分割してタスクを任せたり、学習させる

対処方法とその効果

学習の順序を依存関係に基づいて最適化

• 前提知識なしに新概念を学ぶと認知負荷が大幅に増加
• 適切な順序付けにより、新知識を既存の知識構造に効率的に統合
• 例：小売業で商品棚卸の基本を理解してから在庫予測システムの活用へ進む

対処方法とその効果

事前知識を活用できる類推や比喩を用いる

• 既存の知識に新情報を関連付けることで記憶の定着を促進
• 抽象的概念を具体的な日常例に置き換えて理解の障壁を下げる
• 例：イベント駆動型アーキテクチャを「郵便システム」に例える

TechBowlにおける例を出します。
-> その人の経験を聞いてその人の経験したことがあるような説明を口頭で行う

2. 外在的認知負荷

（Extrinsic Cognitive Load）

外在的認知負荷（Extrinsic Cognitive Load）

外在的認知負荷とは、学習方法や情報提示の仕方から生じる不必要な負荷。

外在的認知負荷（Extrinsic Cognitive Load）の特徴

• 学習内容の本質とは無関係な情報処理から生じる負荷
• 効果的でない教材設計や情報提示方法によって発生
• 学習設計の改善によって低減・除去できる
• 不必要な認知リソースの消費を引き起こす

エンジニアオンボーディングでの例

• 整理されていない膨大なドキュメント
• 不必要に複雑なコード例
• 一貫性のない命名規則や構造
• 分散した情報源（Wiki、Slack、メール、ドキュメント）
• 文脈なしに提示される断片的な情報

対処方法とその効果

情報の適切な構造化と視覚化

• 関連情報のグループ化により情報探索コストを低減
• 階層的なドキュメント構造で全体像を把握しやすくする
• 例：プロジェクトWikiをトピック別に整理し、関連リンクを明確に示す

対処方法とその効果

冗長性の排除と情報の最適化

• 重要でない情報を省くことで本質に集中できる環境を作る
• 同じ情報を異なる形式（テキスト＋図）で提示し理解を促進
• 例：コードコメントは「なぜそうしているか」に集中し、自明な部分の説明は避ける

対処方法とその効果

学習リソースの統一と一貫性確保

• 一貫したフォーマットと用語で認知的摩擦を減らす
• 単一の信頼できる情報源を確立して情報検索負荷を軽減
• 例：プロジェクト用語集の作成、統一されたコーディング規約の適用

TechBowlにおける例を見せます。
-> それぞれの事業や担当領域ごとにドキュメントの内容を分ける

まとめ

認知負荷を考慮したエンジニアオンボーディングの要点

1. 認知負荷の基本概念と種類：
   • 認知負荷とは人間の作業記憶にかかる精神的な負担や処理要求の総量
   • 「内在的認知負荷」（タスク自体の複雑さ）と「外在的認知負荷」（学習方法や情報提示の仕方から生じる不必要な負荷）の2種類がある

認知負荷を考慮したエンジニアオンボーディングの要点

2. 内在的認知負荷への対処法：
   • 複雑な概念を小さな単位に分割する
   • 学習の順序を依存関係に基づいて最適化する
   • 事前知識を活用できる類推や比喩を用いる

認知負荷を考慮したエンジニアオンボーディングの要点

3. 外在的認知負荷への対処法：
   • 情報の適切な構造化と視覚化
   • 冗長性の排除と情報の最適化
   • 学習リソースの統一と一貫性確保

余談資料

本質的認知負荷（Essential Cognitive Load）

本質的認知負荷（Essential Cognitive Load）

本質的認知負荷とは、学習に効果的な認知的処理に関わる負荷。

本質的認知負荷（Essential Cognitive Load）の特徴

• 学習者の理解や応用能力を高めるための認知的処理に関わる負荷
• 学習者の自己評価や自己肯定感に影響を与える
• スキーマ構築や知識の転移に必要な深い認知プロセスを促進する
• 長期記憶への情報格納と既存知識との統合に関連する

エンジニアオンボーディングでの本質的認知負荷の応用

• 能動的処理タスク

  • コードリファクタリング課題
  • バグ調査と修正演習
  • 設計レビュー参加

• 説明生成（Self-explanation）

  • コードウォークスルーセッション
  • 学習内容のドキュメント化
  • ティーチバック（学んだことを教える）

エンジニアオンボーディングでの本質的認知負荷の応用（続き）

• 知識の関連付けと統合

  • 知識マッピングワークショップ
  • 類似概念の比較分析
  • 他分野知識との連携応用

• 反省的実践（Reflective Practice）

  • 学習ジャーナルの活用
  • 定期的なふりかえりセッション
  • メンタリングを通じた対話的内省

本質的認知負荷の最適化ポイント

• 内在的・外在的負荷とのバランスを考慮
• 「挑戦的だが達成可能」な適切な難易度設定
• 学習者の関心と動機づけを活用した課題設計
• スキャフォールディング（足場かけ）で徐々に自律性を高める

オンボーディングにおける認知負荷の問題

認知負荷が高まる状況

• 複雑なシステムアーキテクチャとの初接触
• 多数のツールと環境設定の同時学習
• 暗黙知とチーム固有のプラクティス
• マルチタスクと人間関係構築の並行

複雑なシステムアーキテクチャとの初接触

• 複数のフレームワークやライブラリの相互作用

  • LaravelとVue.jsの連携、LivewireとAlpine.jsの組み合わせなど
  • サービスコンテナ、依存性注入、イベントリスナーの理解

• 設計パターンの多様性

  • リポジトリパターン、サービスクラス、DTOなど複数の抽象概念
  • ドメイン駆動設計（DDD）やCQRSなどの高度なアーキテクチャパターン

• データフローの複雑さ

  • Eloquentモデル間のリレーション、イベントドリブンの非同期処理
  • キャッシュ層、クエリビルダ、RAW SQLの使い分け

多数のツールと環境設定の同時学習

• 開発環境のセットアップ

  • Docker、Laravel Sail、Homestead、Vagrant
  • WSL2、各種ターミナル設定、シェルスクリプト

• バージョン管理と継続的インテグレーション

  • Git操作（rebase、cherry-pick、interactive rebaseなど）
  • CI/CDパイプライン（GitHub Actions、GitLab CI、Jenkinsなど）

• モニタリングとデバッグツール

  • Laravel Telescope、Laravel Debugbar、Xdebug
  • New Relic、Sentry、ELKスタックによるログ分析

暗黙知とチーム固有のプラクティス

• 文書化されていないワークフロー

  • PRレビュープロセスの暗黙的なルール
  • 「このコードはこの人に確認」などの非公式な承認フロー

• コーディング文化とスタイル

  • フレームワークの「正しい使い方」に対するチーム独自の解釈
  • PSR-12を基本としつつもプロジェクト固有の命名規則

• トラブルシューティングのノウハウ

  • 「この環境ではこのバグが起きやすい」といった経験則
  • 本番環境特有の問題と対処法

マルチタスクと人間関係構築の並行

• 業務知識と技術知識の同時習得
  • ビジネスドメインの理解とコードの理解を並行して進める
  • 「なぜそのように実装されているか」の背景理解

マルチタスクと人間関係構築の並行

• コミュニケーションチャネルの多様性
  • Slack、メール、JIRA、Confluence、GitHubなど複数ツールでの情報追跡
  • 各ツールの使い分けルールとチーム文化

マルチタスクと人間関係構築の並行

• 人間関係構築に伴う認知負荷
  • 新しいチームメンバーの名前・役割・専門性の記憶
  • コミュニケーションスタイルの違いへの適応（直接的vs間接的など）

下記の図の画像を生成してください

結果として生じる問題

• 学習効率の低下
• 疲労感と挫折感
• 長期的な定着率の低下

重要要素1：段階的な情報提供と

構造化された学習計画

認知負荷理論の「分割原則」に基づく情報の小分け提供

認知負荷理論の「分割原則」とは？

段階的オンボーディングプラン

重要要素2：視覚的な情報マッピングとメンタルモデル構築

外在的認知負荷を減らすための視覚的表現

視覚的な情報マッピングとは

複雑な情報や概念を図表や図式を使って視覚化する手法

効果:

• 情報の全体像を一目で把握
• 要素間の関連性を直感的に理解
• 記憶に残りやすく、後から想起しやすい
• 言語処理とは別の脳領域を使い、認知負荷を分散

メンタルモデル構築とは

人が頭の中で形成する「システムがどのように動作するか」についての内的理解や表現

メンタルモデルの重要性:

• 断片的な情報から内的な「地図」を構築
• 不完全なモデルは誤解や混乱の原因に
• 正確なモデルは問題解決や応用を容易に

オンボーディングでの活用法 (1)

システム全体図の提供

• バックエンド、フロントエンド、DB、外部APIの関係性を図示
• 学習者が「自分が今どこを学んでいるか」を常に把握できる

処理フローの可視化

• 典型的なリクエスト処理の流れをフローチャートで表現
• 「このAPIリクエストが来たとき、どのように処理されるか」を視覚化

オンボーディングでの活用法 (2)

コードマップの作成

• 主要なクラスやモジュール間の依存関係を図示
• 複雑な部分は拡大図で詳細説明

段階的な詳細化

• 大まかな全体像から始め、徐々に詳細を追加
• 「ズームイン・ズームアウト」できる層状の図を用意

効果

• 学習者が情報を効率的に整理・構造化
• 正確なメンタルモデルを短期間で構築
• チーム内でのコミュニケーションが円滑に
• 曖昧な理解による実装ミスの減少
• 長期的な知識定着率の向上

効果的な視覚ツール

• アーキテクチャ図：システム全体の構造を視覚的に把握
• データフロー図：情報の流れを可視化
• 関係性マップ：主要コンポーネント間の関連性を図示
• 決定木とフローチャート：一般的な処理フローの可視化

重要要素3：マルチモーダルな学習リソース

モダリティ効果を活用した多様な学習チャネル

情報提供手段の多様化

• ドキュメント（視覚）：テキストベースの説明やコード例
• スクリーンキャスト（視覚+聴覚）：実際のコーディング/操作の様子
• ハンズオン（触覚）：実際に触れながら学ぶワークショップ
• ペアプログラミング（社会的+聴覚+視覚）：対話しながらの学習

重要要素4：認知的な「呼吸空間」の確保

内在的・外在的・本質的認知負荷のバランスを取るための時間配分

一日のスケジュール推奨例

ただこれは、あくまでも認知負荷のことを考慮したものであるため、

重要要素5：スキャフォールディング（足場かけ）アプローチ

徐々に支援を減らしていく段階的な自律支援

段階的な支援レベル

• 初期：高レベルのガイダンスと詳細な手順書
• 中期：部分的なサポートとチェックポイント
• 後期：最小限のサポートと自律的な問題解決

重要要素6：コンテキスト切り替えの最小化

マルチタスキングによる認知負荷増大を防ぐための工夫

効果的な集中戦略

• テーマデー：特定の技術や領域に集中する日を設定
  例：「APIデー」「データベースデー」

• 集中作業ブロック：中断のない2-3時間の集中タイムブロック

• 通知管理：不要な通知をオフにし、集中を妨げる要素を排除

重要要素7：実践的な学習と知識の符号化

本質的認知負荷を促進し、知識の定着を図る実践機会

効果的な実践方法

• シャドーイング：熟練エンジニアの作業を観察し模倣

• スモールプロジェクト：独立した小規模プロジェクトの完全実装

• バグ修正チャレンジ：実際のコードベースでの問題解決

• ドキュメント作成：学んだ内容を自分の言葉で説明

重要要素8：メタ認知スキルの育成

自己の学習プロセスを監視・評価・調整する能力の開発

メタ認知スキル開発のための質問プロンプト例

学習効率に関する問いかけ

• 今日学んだ内容で最も理解しやすかった点は？
• 最も難しいと感じた概念とその理由は？
• 次回同様の内容を学ぶ際、どのようなアプローチが効果的？

知識適用に関する問いかけ

• 学んだ概念を別のコンテキストでどう応用できる？
• 現在のプロジェクトのどこに今日の学びを活かせる？

知識ギャップの特定

• 更に調査したい点は？
• 現時点で不明確な点や質問したい内容は？

重要要素9：心理的安全性の確保

認知的余裕を生み出すための心理的安全環境の整備

質問文化：「バカな質問はない」という価値観の醸成

なぜ行うのか（認知負荷の観点から）

• 質問を躊躇する環境では「質問すべきか」という判断自体が外在的認知負荷となる
• 未解決の疑問点が作業記憶内に蓄積され続け、有効な認知処理容量を圧迫する
• 質問への否定的反応を恐れる不安が情報処理能力を低下させる

どうやって行うのか

• シニアメンバーが積極的に「わからない」を認める姿勢を見せる
• 「良い質問をありがとう」と質問者を称賛する習慣づけ
• 質問用のSlackチャンネルなど低障壁の質問環境を用意

失敗の許容：失敗を成長機会として捉える文化

失敗の許容：失敗を成長機会として捉える文化

なぜ行うのか（認知負荷の観点から）

• 失敗への恐怖は「失敗回避のための監視」という外在的認知負荷を常に発生させる
• 認知リソースが学習内容から「ミスを避ける」という二次タスクに分散される
• 失敗への不安が作業記憶の処理容量を圧迫し、新しい情報の符号化を阻害する

失敗の許容：失敗を成長機会として捉える文化

どうやって行うのか

• リーダーが自身の失敗体験と学びを共有する
• 「失敗レトロスペクティブ」で失敗から得た教訓を形式化
• 「安全に失敗できる」サンドボックス環境の提供

建設的フィードバック：成長を促す具体的なフィードバック

建設的フィードバック：成長を促す具体的なフィードバック

なぜ行うのか（認知負荷の観点から）

• 否定的な批判は防衛反応を誘発し、感情処理に認知リソースが消費される
• 曖昧なフィードバックは「何を意味するのか」の解釈に余分な認知負荷を生じさせる
• 適切なフィードバックは本質的認知負荷（有意義な学習活動）に集中できる環境を作る

建設的フィードバック：成長を促す具体的なフィードバック

どうやって行うのか

• SBI（状況・行動・影響）フレームワークの活用
• コードレビューでは「何が問題か」だけでなく「なぜ問題か」「どう改善するか」を明示
• フィードバックトレーニングの実施

定期的な1on1：懸念事項を安全に共有できる場

定期的な1on1：懸念事項を安全に共有できる場

なぜ行うのか（認知負荷の観点から）

• 未解決の懸念事項は「バックグラウンドプロセス」として継続的に認知リソースを消費する
• 定期的な対話により懸念事項を外部化し、作業記憶から解放できる
• 1on1の構造化された場があることで「いつ問題を提起すべきか」という判断負荷が軽減される

定期的な1on1：懸念事項を安全に共有できる場

どうやって行うのか

• オンボーディング初期は頻度を高める（毎日/隔日）
• 明確な構造と議題（進捗、障害、認知的状態、必要なサポート）
• アクティブリスニングの実践（割り込まず、要約し、質問する）

心理的安全性の測定と改善サイクル

心理的安全性の測定と改善サイクル

認知負荷の観点から重要な測定項目

• チーム内で質問することの心理的コストをどの程度感じるか
• ミスを恐れて行動を躊躇することがどの程度あるか
• 懸念事項を共有せずに抱え込むことがどの程度あるか

心理的安全性の測定と改善サイクル

フィードバックループの確立

• 安全性に関する問題点を特定して即座に対応する体制
• 匿名でのフィードバック収集メカニズム
• 定期的な「認知負荷と心理的安全性」に関する振り返り

重要要素10：パーソナライズされた進捗トラッキング

個人の学習速度や認知特性に合わせた可視化と調整

効果的なトラッキング手法

• スキルマトリクス：技術スキルの習得状況を視覚化

• マイルストーン達成：小さな成功体験を積み重ねる構造

• 適応型難易度調整：進捗に応じてタスク難易度を調整

• 学習ダッシュボード：主要指標の一元管理と可視化

作業記憶の容量制限について

作業記憶の容量制限（7±2項目）とは

作業記憶（ワーキングメモリ）の容量制限は、心理学者ジョージ・ミラーが1956年に発表した「マジカルナンバー7±2」として知られる研究に基づく概念。

作業記憶の容量制限（7±2項目）とは

重要ポイント：

• 人間は一度に約7つの情報チャンク（プラスマイナス2）しか作業記憶内に保持できない
• この制限を超えると情報処理効率が大幅に低下する
• オンボーディングプロセスの設計において最も重要な認知的制約の一つ

作業記憶の主な特徴

• 制限された容量: 一度に処理・保持できる情報の量が限られている
• チャンキング: 関連する情報をまとめることで実質的な処理能力を高められる
• 個人差: 人によって5〜9項目の範囲で容量に違いがある
• 時間制限: 情報は約10〜20秒しか保持されない（リハーサルなしの場合）
• 干渉効果: 類似情報間で相互干渉が起こりやすい

エンジニアオンボーディングとの関連性

新入エンジニアが直面する認知的課題：

• 複数の新技術、フレームワーク、設計パターンを同時に学ぶ必要がある
• コードベース、アーキテクチャ、業務ドメイン知識の並行学習
• チーム固有のプラクティスや暗黙知の吸収
• これらが作業記憶に同時に負荷をかけることで認知オーバーロードを引き起こす

効果的な対処法

作業記憶を考慮したコードレビュープロセス

効果的なレビュー方法：

• ファイル数の制限: 一度のレビューで5-7ファイル以内に制限
• コンテキスト提供: 変更の理由や背景を明確に説明
• レビューセッション: 大規模な変更は対面/ビデオでの説明を追加
• 段階的レビュー: 大きな変更を複数の小さなプルリクエストに分割
• 視覚的補助: 必要に応じて図表でロジックを説明

これにより新入エンジニアの学習曲線が緩やかになり、より深い理解が促進される。