解説リファレンス：採点基準を逆算する

インバスケット試験では「全案件を完璧に処理したか」よりも、6つの評価ディメンション（判断力・統率力・問題分析力・計画組織力・対人関係力・主体性）でマネージャー行動の幅と質を測ります。

本章では各評価ディメンションの観点と、高得点行動／低評価行動の見分け方を整理します。採点基準を理解することで、案件ごとに「どのディメンションでアピールするか」を意図的に設計できるようになります。

この章で学ぶこと

インバスケットで合格するためには、何が採点されているかを知ることが最も重要です。採点基準がわかれば、解答の書き方が変わります。

多くの企業や試験機関が採用しているインバスケットの評価ディメンション（評価軸）は、概ね以下の6つに集約されます。

案件の表面的な事象の裏にある「本質的な問題」を見抜けるか。

エンジニア向けポイント: これはバグ修正の「根本原因分析（Root Cause Analysis）」と同じです。表面の症状ではなく、根っこの問題を特定する力が評価されます。

情報を整理・構造化し、問題の全体像を把握できるか。

低評価	高評価
思いつきで対応する	関係者・影響範囲・緊急度を整理してから対応する
情報不足のまま判断する	「○○を確認した上で判断」と不足情報を特定する

エンジニア向けポイント: システム障害対応で「影響範囲の調査」をするのと同じ考え方です。

限られた情報の中で、合理的な判断を下せるか。

これがインバスケットで最も配点が高いディメンションです。

エンジニア向けポイント: 技術選定と同じです。「なぜ React ではなく Vue を選んだか」の判断理由を述べるように、案件でも判断の根拠を明記しましょう。

案件の先を読み、リスクや波及効果を予測できるか。

低評価	高評価
今起きていることだけに対応する	「これを放置するとどうなるか」を考慮する
単一の解決策だけを示す	リスクに備えた代替案・予防策にも言及する

エンジニア向けポイント: セキュリティレビューで「この脆弱性が悪用されるとどうなるか」を考えるのと同じ先読み力です。

適切な人に適切な形で仕事を任せられるか。

エンジニア向けポイント: これはプルリクエストのレビュー依頼と同じです。「誰に」「何を」「いつまでに」を明確にする力が問われます。

人の感情や立場に配慮した対応ができるか。

エンジニア向けポイント: これはエンジニアが最も苦手としがちなディメンションです。コードレビューで「このコードはダメ」ではなく「こう改善するとさらに良くなります」と書くのと同じ感覚です。

試験によって異なりますが、一般的な配点の重みは以下のようなイメージです。

意思決定力が最も重要です。悩んで白紙にするぐらいなら、理由をつけて判断を示すことが得点に直結します。

合格のための最重要原則: インバスケットは「正解を出す」試験ではなく、「マネージャーとしての行動パターンを見せる」試験です。6つのディメンションを意識して、すべての案件に「判断」「理由」「指示」を書くことが合格への最短ルートです。