マネージャーこそ真剣に考える 「情報量の差」を意識したオンボーディング 1 

アジェンダ 2 

スー 所属 株式会社TechBowl 何やってる？ 「TechTrain」というサービスで反復横跳びし続けている何で も屋さん(Laravel, Next.js, AWS, etc...) 趣味 お酒(よく溺れる) サウナ 読書 3 

マネージャーの皆様方、こんなことありませんか？ すごいと聞いてたけど、思ったよりパフォーマンス出ないな チームメンバーが自由に動いてくれてることとチームとしてやりたいことがずれ始め ているな？ 色々伝えてるつもりなのになんでそうなるんだろ・・・？ どこで情報が失われてるんだろう？ 私が伝え方下手なのかな...もっと明確に伝えるべきだったの か... 4 

マネジメントされる側の方 こんなことありません？ 色々やってみてるけど、なんか評価されない。成果でない。 欲しいと思ってる情報あるけど、どこにあるんだ・・・？ いきなりマネージャーから新しい情報出てきたぞ・・・！？ やってる割になんか評価されないな・・・ 現場のことが伝わってないのかな・・・ 5 

情報差分がある or 情報の適切な提示ができていない 6 

マネージャーとメンバーの情報差分が なぜ生じるのか？ 7 

マネージャーとメンバーの情報差分が生じる原因 1. 役割の違いによる情報アクセスの差 2. 暗黙知の共有不足 3. コミュニケーションの非対称性 4. 期待値の不明確さ 5. 時間的制約とコンテキストスイッチング 6. 認知バイアスと視点の相違 7. 組織構造による情報遮断 8. 経験と知識の非対称性 8 

[現在の解決策] AIのために 情報を貯める場所と種類を決めて貯める (後ほど社内のサムシング見せます) 9 

マネージャーとメンバーの情報差分が生じる原因 1. 役割の違いによる情報アクセスの差 具体例： マネージャーは経営会議や他部門との調整会議に参加しており、会社全体の方針や 予算制約を把握している。一方、メンバーはそれらの情報にアクセスできず、「なぜ自分の アイデアが却下されるのか」理解できない。 マネージャー: (出せない情報で承認できないんだよなー) メンバー: 何で承認されないんだよー！ 10 

マネージャーとメンバーの情報差分が生じる原因 2. 暗黙知の共有不足 具体例： 設計の背景や過去の議論経緯がドキュメント化されておらず、過去のプロジェクト を経験したマネージャーだけが「なぜこの設計なのか」を理解している。新しいメンバーは 合理的と思える改善案を提案するが、考慮されていない制約があることを知らない。 メンバー: これってこっちの設計の方が良くないですか？ マネージャー: 実はこれ過去にやったことがあってこういう 形で失敗していてねー！ 11 

マネージャーとメンバーの情報差分が生じる原因 3. コミュニケーションの非対称性 具体例： マネージャーは「このタスクは優先度が高い」と伝えたつもりだが、メンバーは 「複数の高優先度タスクのうちの一つ」と解釈し、マネージャーの期待するタイミングで完 了しない。 マネージャー: 優先度高で進めといて〜！ メンバー: わかりましたー！（他の高いタスクの下に積んど こ！） 12 

マネージャーとメンバーの情報差分が生じる原因 4. 期待値の不明確さ 具体例： マネージャーは「自主的な行動」を期待しているが、具体的に何をどこまでの権限 で行うべきかを明示しておらず、メンバーは「指示を待つ」姿勢になってしまう。あるいは 逆に、メンバーが行動しすぎてマネージャーの想定と異なる方向に進んでしまう。 マネージャー: あとは好きにやっていいよ！ メンバー: わかりましたー！（terraform destroy） 13 

マネージャーとメンバーの情報差分が生じる原因 5. 時間的制約とコンテキストスイッチング 具体例： マネージャーは日々多くの会議と並行タスクに追われ、各メンバーと十分なコミュ ニケーションを取る時間がない。結果として、メンバーが抱えている技術的な課題や懸念に 気づかない、または誤解したまま判断を下してしまう。 マネージャー: あーそれは逆でこっちで進めておいて！ メンバー: あの人全然現場わかってないわ 14 

マネージャーとメンバーの情報差分が生じる原因 6. 認知バイアスと視点の相違 具体例： マネージャーはプロジェクト全体の進捗を気にしている一方、メンバーは自分の担 当範囲の技術的完成度に関心がある。この視点の違いから、成功の定義や優先すべき事柄に ついて認識のズレが生じる。 15 

マネージャー: (全体のデッドラインを考えると難しいんだよ なぁ...) マネージャー: このチケットの対応はどうなっていますか？ メンバー: 実装は完了しました！リファクタリングを進めて ます！ 16 

マネージャー: それより先に他のチケットを進めてもらえま せんか？事業としてはこちらの機能を早くリリースしたい です メンバー: (せっかく良いコードを書いているのに、数だけ気 にして...)　わかりました。 マネージャー: (品質も大事だけど、今はスケジュールが厳し いんだよな...) 17 

マネージャーとメンバーの情報差分が生じる原因 7. 組織構造による情報遮断 具体例： 会社の意思決定構造がサイロ化しており、関連部門間の情報共有が不足している。 その結果、マネージャーもメンバーも、他チームの動きを十分に把握できず、連携が必要な 作業で齟齬が生じる。 マネージャー: このAPIの仕様変更、なぜ事前に教えてくれ なかったんですか？ 他チームのメンバー: え？先週のアーキテクト会議で承認さ れたと聞いていますが... 18 

マネージャー: そんな会議の招待すら来ていないよ... メンバー: （また急な仕様変更か...）結局しわ寄せは現場に 来るんだよな 19 

マネージャーとメンバーの情報差分が生じる原因 8. 経験と知識の非対称性 具体例： ベテランのマネージャーは過去の失敗事例から学んだ教訓を持っているが、それを メンバーと十分に共有していない。メンバーは「車輪の再発明」をして同じ失敗を繰り返し てしまう。 20 

メンバー: マネージャー、このAPIキャッシュの実装方法を 考えてみたんですが、どうでしょう？ マネージャー: んー、それだとスケーラビリティに問題が出 そうだから、別の方法にしよう メンバー: なぜですか？理論的には問題ないはずですが... 21 

マネージャー: （3年前に同じ方法で大失敗したんだよなぁ... でも細かく説明する時間がない）とにかく違う方法で頼む よ メンバー: （また根拠のない指示か...）わかりました... 22 

情報差分がもたらす問題のまとめ 信頼関係の毀損 「マネージャーは重要なことを隠している」「メンバーは言っても理解してくれない」とい う不信感 意思決定の質の低下 不完全な情報に基づく判断により、最適でない選択をしてしまう モチベーション低下 「自分の努力が正しく評価されていない」「自分の意見が反映されない」という不満 非効率な作業 誤解に基づくやり直しや、無駄な二重作業の発生 23 

情報差分は、組織的な施策が必要 24 

TechBowlの場合の決定 [過去の決断] 人間が見やすい 情報のまとまりを意識 認知負荷が低い 25 

実際に見せる 26 

TechBowlの場合の決定 [最近の決断] 1. AIの読み先を減らすため、GitHubとFigmaにツールを集約 2. AIが読みやすい場所にドキュメントを配置 3. AIが読みやすいドキュメントの形式を決める 27 

実際に見せる 28 

ご清聴ありがとうございました! 29 

おまけ 30 

以降は認知負荷についての話。 聞きたい人がいればそちらを話す 31 

認知負荷理論とは何か？ 認知負荷理論（Cognitive Load Theory） は、1980年代にオーストラリアの教育心理学者ジョ ン・スウェラー（John Sweller）によって提唱された理論です。 本質的認知負荷 学習対象そのものの複雑さによる負荷 外在的認知負荷 学習方法や環境による余計な負荷 ドメイン的認知負荷 新しい知識を既存知識と関連付ける負荷 新しいメンバーが感じる「情報差分」は認知負荷の一種な 32 

オンボーディングにおける認知負荷の問題 研究によって明らかになった事実： 新しいチーム参加者は平均して 300〜400% の認知負荷を経験する これは通常業務の 3〜4倍の精神的負担 を意味する 結果として約 23% の新入社員が最初の6ヶ月で退職を検討 なぜ新メンバーはすぐに活躍できないんだろう？ 認知リソースが情報処理だけで消費されてしまい、本来の 能力発揮ができないんですね 33 

認知的徒弟制（Cognitive Apprenticeship）モデル 研究者のCollins、Brown、Newmanによって提唱されたこのモデルは、複雑なスキル習得を効 果的に支援します。 1. モデリング 熟練者が作業プロセスを実演 2. コーチング 学習者が試行する際の観察と指導 3. 足場かけ 徐々に支援を減らしていく段階的自立 4. 明確化 暗黙知を言語化して共有する 34 

認知負荷を考慮したオンボーディング設計のポイント 1. チャンク化（情報の分割） 研究結果：一度に処理できる情報は5±2チャンクが限界 → 大量の情報を意味のある小さな単位に分割して提供 2. 段階的複雑性（Progressive Complexity） 研究結果：複雑性を徐々に上げることで学習曲線が最大40%改善 → シンプルなタスクから始め、徐々に難易度を上げていく 3. マルチモーダル学習 研究結果：異なる知覚チャネルを利用すると記憶定着率が22%向上 → 文書、図解、実践、ディスカッションなど複数の方法を組み合わせる 35 

実践例：エンジニアオンボーディングの構造化設計 第1週：基盤構築 チーム文化とツールのみに集中 同僚との1対1ミーティング 環境セットアップのペアプログラミング 認知負荷対策: 社会的負荷と技術的負荷を分離 第2-3週：コンテキスト獲得 小規模な修正タスク ドキュメント改善への貢献 コードベースのペア探索 認知負荷対策: アクティブラーニングで記憶定着率向上 36 

情報差分を減らすドキュメント設計の研究知見 情報アーキテクチャの最適化 研究結果: 適切な情報構造化により検索時間が最大68%減少 知識マップ: 情報間の関連性を視覚化 階層的整理: 3レベル以内の階層構造が最も理解されやすい 命名規則: 一貫した命名により検索負荷を軽減 ジャストインタイム情報提供の効果 研究結果: 必要なタイミングでの情報提供で学習効率が31%向上 コンテキスト依存ヘルプ: 作業中に必要な情報だけを表示 FAQ形式: 実際に発生した問題と解決策の整理 チェックリスト: 認知負荷を外部化して作業精度を向上 37 

マネージャーができる認知負荷軽減アプローチ 1. メンタルモデル構築支援 システム全体の概念図を提供し、徐々に詳細を追加 研究効果: 複雑システム理解が45%向上 2. 意図的な反復 重要概念を異なる文脈で計画的に繰り返す 研究効果: 長期記憶への定着率70%向上 3. コンテキスト共有の明示化 決定理由や背景情報を常に提供 研究効果: チーム間の認識齟齬が36%減少 38 

参考文献・研究論文 Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12, 257-285. Collins, A., Brown, J. S., & Newman, S. E. (1989). Cognitive apprenticeship: Teaching the crafts of reading, writing, and mathematics. Knowing, learning, and instruction: Essays in honor of Robert Glaser, 18, 32-42. Artino, A. R. (2008). Cognitive load theory and the role of learner experience: An abbreviated review for educational practitioners. AACE Journal, 16(4), 425-439. Mayee, R. E., & Moreno, R. (2003). Nine ways to reduce cognitive load in multimedia learning. Educational Psychologist, 38(1), 43-52. Begel, A., & Simon, B. (2008). Novice software developers, all over again. Proceedings of the Fourth International Workshop on Computing Education Research, 3-14. Johnson, A., & Senges, M. (2010). Learning to be a programmer in a complex 39