企業別ガイド 8 分で読める ·

マッキンゼー Solve よくあるミス:候補者が脱落する落とし穴

Ecosystem Building と Red Rock Study におけるマッキンゼー Solve の最頻出ミス10選——プロセス採点の盲点、ダミーデータ、時間管理の失敗——と具体的な改善策。

わからなくても大丈夫。
マスターするまでAIで練習しよう。
練習を始める → Proにアップグレード →

マッキンゼー Solve は、2020年前後にほとんどのオフィスで紙のPSTに取って代わりました。Ecosystem Building と Red Rock Study という2つのゲーム形式のミニゲームで構成され、所要時間はおよそ60〜81分です。アルゴリズムは最終回答だけでなく、意思決定のプロセスやクリックのタイミングも採点します。候補者の約70%がここで脱落します。多くの場合、分析力の不足が原因ではなく、避けられるミスの繰り返しが失敗を招いています。具体的には、無作為なクリック、制約条件の読み飛ばし、ダミーデータの追跡、1つの操作への時間の浪費などが挙げられます。本ガイドでは、10の落とし穴とそれぞれの対策を解説します。

マッキンゼーSolveは、2020年頃にほとんどのオフィスで紙のProblem Solving Test(PST)に代わって導入されたデジタルアセスメントです。現在はグローバルの標準となっていますが、一部のオフィスでは従来のPSTを引き続き実施している場合があります。Solveは、候補者の約70%をケース面接に進む前に脱落させます。驚くべきことに、その多くは純粋な問題解決能力とはほとんど関係がありません。

Solveは多肢選択式のクイズではありません。ゲーム形式の2つのシミュレーション——通常はEcosystem BuildingRed Rock Studyで、Sea WolfPlant Defenseが登場することもあります——を、約60〜81分で連続して行うものです。重要なのは、アルゴリズムがどのように作業したかを採点するという点です。最終的な結果だけでなく、意思決定のプロセス、行動の順序、クリックとタイミングのテレメトリーが評価されます。この一点が、どのミスが致命的かを大きく左右します。

本ガイドでは、Solveで起こりやすい10の典型的なミスを、発生する場面ごとに整理し、それぞれに具体的な改善策を示します。

Solveのエラー全体像

旧PSTではエラーの約半数がデータの読み違いでしたが、Solveの失敗はゲーム自体への誤解——何が評価されるのか、各ミニゲームの仕組み、時間の使い方——に集中しています。

mindmap
  root((Solveのエラー))
    採点モデルへの理解不足
      プロセスではなく答えを最適化する
      探索目的でランダムにクリックする
      きれいな最終状態で挽回できると思い込む
    Ecosystem Building
      制約を読む前に試行錯誤を始める
      食物連鎖とリソース制限を無視する
      一手を過度に最適化する
    Red Rock Study
      ダミーデータを追いかける
      フェーズをまたいで資料を読み違える
    時間とメンタル
      ゲームごとの残り時間を見失う
      出だしのミスでパニックになる
      慣れていないインターフェースに初めて直面する

エラーの原因を理解することが、それを排除するための第一歩です。私たちがコーチングした候補者の多くは、新しい知識を増やすよりも、ゲームへの向き合い方を変えることで最も早く改善しました。

カテゴリー1:採点モデルへの理解不足

これらのミスは、Solveがプロセスを監視しているという事実を理解していないことから生じます。「正しい」結果を出しても低スコアになり得るため、最も危険なミスです。

ミス#1:Solveを合否判定式のクイズとして扱う

最もよくある概念的なミスは、Solveが最終的なエコシステムの生存可否や答えの正誤だけを採点すると思い込むことです。そうではありません。アルゴリズムは意思決定のプロセス——どの行動をとったか、どの順序で行ったか、どれだけ効率的に結果に至ったか——を記録します。安定したエコシステムを構築した2人の候補者でも、一方が論理的なステップを踏み、もう一方が試行錯誤を繰り返した場合、スコアは大きく異なります。

改善策: すべての行動を採点対象の一手として扱いましょう。何かに触れる前に仮説を立てます。「この種はXを満たすからここに合うはずだ」というように。意図的で順序立てた行動は、有能な意思決定として評価されます。たまたまうまくいった慌ただしい行動は、運によるものと判断されます。

ミス#2:インターフェースを「探索」するためにランダムにクリックする

インターフェースに不慣れなため、候補者はどうなるかを確かめようとクリックしがちです。プロセスが採点されるアセスメントでは、これが記録されます。無目的なクリックの多さ、素早いアンドゥ・リドゥの繰り返し、不規則なタイミングは、推論ではなく推測をしているシグナルとなり、推測はペナルティの対象です。

改善策: インターフェースの探索は、採点セッション中ではなく、テスト当日の前に公式の練習版や忠実なシミュレーションで行いましょう。タイマーが始まったら、すべてのクリックに理由を持たせてください。何かを確認する必要があれば、一度だけ意図的に確認して次に進みましょう。

ミス#3:きれいな最終状態が乱雑なプロセスを帳消しにすると思い込む

ゲームの最初の3分の2を試行錯誤に費やし、最後にすべてを整えて最終画面が評価されると思い込む候補者がいます。しかし、テレメトリーはすでにその試行錯誤を記録しています。きれいな終わり方は、混乱した中盤を上書きしません。

改善策: 最後の一手ではなく、最初の一手からプロセスを正しくしましょう。早い段階でアプローチが間違っていると気づいた場合は、長い試行錯誤の連続ではなく、明確で論理的な方針転換——一つの明確な意思決定——で修正しましょう。

カテゴリー2:Ecosystem Buildingのミス

Ecosystem Buildingでは、食物連鎖の関係、リソース制限、地形の適合性などの制約を満たす種を選択し、指定された場所に適したエコシステムを構築します。ここでのミスのほとんどは、理解する前に行動することから生じます。

ミス#4:制約を読む前に試行錯誤に飛び込む

Ecosystem Buildingで最も多いミスは、種を先に配置してから機能するかどうかを確認することです。各種が何を食べるか、どれだけのリソースが必要か、どこに生息できるかといった制約は、構築を始める前に提示されています。それを無視して推測で繰り返す候補者は、行動を無駄に消費し、ノイズの多いテレメトリーを生成し、それでも安定したシステムを構築できないことが多いです。

改善策: 何も配置する前に、最初の数分間で制約を読み、整理しましょう。食物連鎖とリソース制限をメモ用紙にスケッチしてください。実際に構築するときは、答えを探すのではなく、計画を実行している状態にしましょう。

ミス#5:食物連鎖とリソース制限を無視する

ルールを読んだ候補者でも、個々には魅力的に見えるが、システム全体のバランスを崩す種を選んでしまうことがあります——有効な獲物がいない捕食者や、合計リソース消費量が利用可能量を超える種の組み合わせなどです。エコシステムは崩壊し、その崩壊と崩壊を招いたプロセスの両方が採点されます。

改善策: 各選択を単独ではなく、システム全体に対して検証しましょう。各種について3点を確認します。選んだ種の中に食料源があること、地形に適合していること、追加してもリソースの総需要が制限内に収まること。3点のいずれかが満たされなければ、その種は適しません。

ミス#6:一手を過度に最適化して時間切れになる

完璧主義の候補者は、わずかに良い組み合わせを求めて一つの種を何度も入れ替え続け、エコシステム全体が完成する前に時間切れになります。未完成のシステムは、完成した合理的なシステムよりも低いスコアになります。

改善策: まず完成した、説明できる解を目指し、時間が余った場合にのみ改善しましょう。大まかな内部チェックポイントを設けてください。同じ意思決定に数分以上費やしているなら、最善の選択を確定して前に進みましょう。説明できる完成したエコシステムは、半分しか構築されていない「完璧な」エコシステムより優れています。

カテゴリー3:Red Rock Studyのミス

Red Rock Studyは、複数のフェーズにわたってデータを解釈し、結論を導き出すマルチフェーズの調査シナリオです。ここでのミスは、ケース面接における典型的なデータエラーと共通しますが、情報量の多さと時間制限がそれを増幅させます。

ミス#7:ダミーデータを追いかける

Red Rockには意図的に、関連しているように見えるが実際の意思決定には関係しない情報が含まれています。提示されたすべてのデータを使おうとする候補者は時間を無駄にし、ノイズに基づいた推論を構築してしまいます。ダミーデータを識別して除外する能力も、このゲームが測定する要素の一つです。

改善策: 分析を始める前に、各フェーズが問うている具体的な問いを定義しましょう。そのうえで、その問いを前進させるデータだけを使います。あるグラフや数値が答えを変えないなら、メモして置いておきましょう——無理に推論に組み込まないでください。

ミス#8:フェーズをまたいで資料を読み違える

情報が複数のフェーズや画面に分散しているため、どの数値がどこから来たかを見失ったり、初期フェーズの前提を後のフェーズに持ち込んでしまったりすることがあります。時間的プレッシャーの下では、一つの数値の誤帰属が誤った結論の連鎖を引き起こします。

改善策: 進めながら、主要な数値とその出所を簡潔にメモしておきましょう。新しいフェーズがシナリオを再構成した場合、以前の前提を再利用する前に、それがまだ適用されるかどうかを確認してください。

カテゴリー4:時間とメンタルのミス

最後のカテゴリーは、2つのゲーム全体を通じた時間管理と心理状態に関するものです。

ミス#9:ゲームごとの残り時間を見失う

約60〜81分を2つのミニゲームに分けて使う以上、時間の規律がすべてです。最初のゲームに時間をかけすぎる候補者——慣れているからか、完璧な結果を追い求めているからか——は、2つ目のゲームに十分な時間が残らず、両方で低スコアになります。

改善策: 開始前に時間を配分し、固定のチェックポイントで確認しましょう。各ゲームの時間配分を厳格な境界として扱ってください。論理的で完成した作業で両方のゲームを終えることは、一方を完璧にこなしてもう一方を放棄することより優れています。私たちのSolveの時間管理ガイドでは、この時間配分をステップごとに詳しく解説しています。

ミス#10:(慣れていないインターフェースで)出だしのミスの後にパニックになる

多くの候補者は採点セッションで初めてインターフェースに触れ、序盤でつまずいてパニックに陥ります——クリックが速くなり、計画を放棄し、アルゴリズムがペナルティを与えるまさにその不規則なテレメトリーを生成してしまいます。出だしのミス自体が致命的になることはほとんどありません。問題はパニック反応です。

改善策: インターフェースが退屈に感じるまで、実際のゲーム形式で練習しましょう。慣れることで、パニックを引き起こす驚きがなくなります。ゲーム中に何か問題が起きた場合は、5秒間立ち止まり、計画に戻り、次の行動を意図的に行いましょう。回復も採点対象の行動であり、冷静で論理的な方針転換は、慌てた対応よりはるかに高く評価されます。

Solveの意思決定フレームワーク

意識的な理解と、プロセスをクリーンで採点可能な状態に保つシンプルなゲーム内ルーティンを組み合わせましょう:```mermaid flowchart TD A[“新しいゲームまたはフェーズ”] –> B[“まず制約条件と問題を読む”] B –> C[“計画を描く:食物連鎖 / 主要データ”] C –> D{“行動する準備はできているか?”} D –>|Yes| E[“意図的かつ根拠のある一手を打つ”] D –>|No| B E –> F{“想定通りに機能しているか?”} F –>|Yes| G[“次の手に進む”] F –>|No| H[“試行錯誤ではなく、明確な方向転換を一度行う”] H –> G G –> I{“完了し、かつ残り時間はあるか?”} I –>|Complete| J[“時間が許す場合のみ改善する”] I –>|Time short| K[“最善の守れる状態で確定し、次へ進む”]


## 5日間のSolveエラードリル

Solveのセッションが近づいている場合、この集中ドリルは純粋な内容よりも、ゲームとのインタラクションの仕方に焦点を当てています。

| 日 | フォーカス | アクティビティ |
|-----|-------|----------|
| 1 | インターフェース | 忠実なSolveシミュレーションを一度通して行う。目標:インターフェースへの驚きをすべて取り除く |
| 2 | エコシステム | 構築する*前に*制約条件を読み、食物連鎖をマッピングする練習をする。試行錯誤はしない |
| 3 | レッドロック | データシナリオを練習する。各フェーズで、まず問題を書き、次に撹乱データにフラグを立てる |
| 4 | 時間とプロセス | 厳格なタイマーのもとで両方のゲームを実行する。クリックパターンを追跡し、焦りではなく意図的な操作を目指す |
| 5 | 完全シミュレーション | 試験条件のもとで時間制限付きセッションを完了する。プロセスが乱れた箇所とその理由を振り返る |

目標は答えを暗記することではありません――シナリオは毎回異なります――むしろ、時間的プレッシャーのもとで*プロセス*を冷静に、秩序立てて、完全に実行できるようにすることです。

## 重要なポイント

- Solveはプロセス採点方式です:アルゴリズムはあなたの意思決定の経路とクリックのタイミングを読み取るため、ランダムなクリックと整った最終画面では得点になりません
- エコシステムビルディングは、最初の種を配置する前に制約条件を読み、食物連鎖をマッピングすることで高評価を得られます
- レッドロックスタディには意図的に撹乱データが含まれています――各フェーズの問いを定義し、それに答えるデータだけを抽出してください
- ゲームごとのタイマーは厳格な制限です。両方のゲームに対する完全で合理的な解答は、一方が完璧で他方が未完成の場合より高い評価を得られます
- パニックに陥るケースのほとんどは、インターフェースに初めて触れることに起因しています――飽き飽きするくらい実際のフォーマットで練習してください
- インタラクションの習慣に焦点を当てた5日間のドリルは、目的のない数週間の練習より効果的です

## 次のステップ

まずフォーマット自体から始めましょう。あなたのオフィスがSolveを使用しているのか、旧来のPSTを使用しているのか不明な場合は、[マッキンゼーSolve完全対策ガイド](/en/guides/mckinsey-pst-solve-preparation/)を参照して、オフィスごとの状況とゲームの全体像を確認してください。

タイマーに関するミスを具体的に修正するには、[マッキンゼーSolve時間管理ガイド](/en/guides/mckinsey-pst-time-management/)に取り組み、テスト当日までにゲームごとの時間配分を構築してください。

旧来のPSTがまだ選択肢にある場合は、[マッキンゼー問題解決テスト戦略ガイド](/en/guides/mckinsey-problem-solving-test-strategy/)で選択式問題の種類とペース配分を確認してください。

CasesCoach AIモック面接とそのフィードバックは、まだ修正できるテスト当日*前に*、ランダムなクリック、制約条件の見落とし、タイマーのオーバーランといった、まさにこれらのミスを明らかにします。無料プランには3つの練習ケースとAIモックが含まれており、Proプランでは835以上のケースと複数回のAIモックセッションが利用可能になるため、プロセスが第二の本能になるまで繰り返し練習できます。[AIモック面接](/account?tab=mock&lang=en)を試すか、[料金ページ](/pricing/)でオプションを比較してください。