マッキンゼーの旧来の筆記式問題解決テスト(PST)は、デジタル形式の Solve アセスメントに置き換えられました。1セッションは2つのミニゲームで構成され、多くの場合エコシステム・ビルディングとレッド・ロック・スタディが出題されます。所要時間は約60〜81分で、採点はアルゴリズムによって行われます。最終的な回答だけでなく、意思決定のプロセスや操作のタイミングデータも読み取られます。受験者の約70%が脱落します。従来のような選択式問題を繰り返し練習する学習法はもはや通用しません。そのため、戦略の核心は各モジュールの思考様式を習得することにあります。エコシステム・ビルディングでは制約付き最適化、レッド・ロック・スタディでは仮説主導のデータ調査が求められます。
長年にわたり、マッキンゼー問題解決テスト(PST)は26問の筆記試験であり、問題タイプを繰り返し練習することで攻略できるものでした。しかし、このテストはすでに廃止されています。2020年頃から、マッキンゼーは候補者のスクリーニングにSolveというデジタルゲーム型アセスメントを採用しており、現在はグローバルの標準となっています(一部のオフィスでは旧来のPSTが引き続き実施される場合があります)。Solveには選択式の問題形式が存在しないため、「問題タイプ別の戦略」はもはや通用しません。今重要なのは、ほぼすべてのセッションを構成する2つのモジュールをどのようにプレイするか、そしてスコアリングエンジンがそのプレイ方法をどのように読み取るかです。
Solveとは何か、そしてどのようにスコアリングされるか
Solveのセッションは、2つのミニゲームで構成され、所要時間はおよそ60〜81分です。最も出題される可能性が高い2つのゲームは、Ecosystem BuildingとRed Rock Studyです。候補者によってはSea WolfやPlant Defenseといったバリアントが出題される場合もありますが、この2つの組み合わせが主流であり、推論スキルはすべてのゲームに共通して活用できます。
Solveを理解する上で最も重要なのは、どのようにスコアリングされるかという点です。スコアリングはアルゴリズムに基づき、プロセス重視で行われます。エンジンは、クリックやタイミングのテレメトリーとともに、あなたの意思決定の経路——選択の順序——を記録します。単純に「正解数を数える」試験ではありません。2人の候補者が似たような最終状態に達したとしても、一方が明確で意図的な推論の経路を示し、もう一方が迷走していた場合、スコアは大きく異なります。これには3つの直接的な影響があります:
- 推測はペナルティの対象となります。 旧PSTでは無害だったランダムなクリックによる回答は、Solveでは不利に働きます。エンジンは、根拠のある選択と無作為な選択を区別することができます。
- プロセスそのものが評価対象です。 情報をどのように収集するか、どの順序で収集するか、そしてそれに基づいてどれだけ一貫して行動するかが、すべてスコアに反映されます。
- 基準は厳しいです。 この段階でおよそ70%の候補者が脱落するため、単に「完了した」セッションでは不十分です——経路が一貫していなければなりません。
Solveは、書類選考と一次ケース面接の間に位置しています。どちらの段階も、同じ根本的なスキル——構造的思考、データ解釈、時間的プレッシャー下での規律ある意思決定——を評価します。
flowchart LR
A[書類選考] --> B[Solveアセスメント]
B --> C{合格?}
C -->|~30%| D["ケース面接(1次)"]
C -->|~70%| E[不合格]
D --> F["ケース面接(2次)"]
F --> G[最終判定]
| パラメータ | 詳細 |
|---|---|
| 形式 | デジタル・ゲーム型(筆記PSTの代替) |
| 構成 | セッションあたり2つのミニゲーム |
| 主要モジュール | Ecosystem Building + Red Rock Study |
| 所要時間 | 合計約60〜81分 |
| スコアリング | アルゴリズム/プロセス重視(意思決定経路+タイミングテレメトリー) |
| 推測 | ペナルティあり——根拠のある選択のみ有効 |
| 脱落率 | 候補者の約70% |
アセスメントの全体像と各形式における準備方法については、マッキンゼーSolve準備ハブをご覧ください。
2つのモジュールの概要
各モジュールは、異なる推論モードを評価します。Ecosystem Buildingは制約付き最適化とシステム思考のタスクです。厳格なルールのもとで機能するシステムを組み立てます。Red Rock Studyは仮説主導のデータ調査です。複数フェーズにわたるケースを進みながら、適切な数値を抽出し、時間的プレッシャーの中で正確な回答を導き出します。Solveの準備には、両方のモードを意識的に練習することが必要です。なぜなら、それぞれがほぼ正反対の直感を求めるからです——一方では忍耐強いルールの整理、もう一方では果断なデータの取捨選択が求められます。
flowchart TD
A[Solveセッション] --> B[Ecosystem Building]
A --> C[Red Rock Study]
B --> B1[ルールと制約を読む]
B --> B2[種を選択/食物連鎖を構築する]
B --> B3["カロリー・連鎖の長さ・地形を満たす"]
C --> C1[ケースのフェーズを進む]
C --> C2[適切なデータを抽出する]
C --> C3[分析し正確に回答する]
モジュール1 — Ecosystem Building
特定の環境(例:珊瑚礁、山岳地帯、その他の地形)が与えられ、ルールに従って共存できる種のセットを選択し、自立した食物連鎖を構築することが求められます。一見すると自然をテーマにしたゲームですが、実質的には制約付き最適化問題です。成功の鍵は「最もかっこいい」動物を選ぶことではなく、パズルが課すすべての制約を同時に満たす組み合わせを選ぶことにあります。
フェーズごとのアプローチ方法:
-
何も操作する前にルールを読む。 Ecosystem Buildingでは、制約を理解する前に種を配置し始めた候補者はペナルティを受けます。典型的な制約には、カロリー要件(各種は食べるものから十分なエネルギーを得る必要がある)、食物連鎖の長さ(連鎖が必要なレベル数に達していなければならない)、地形/深度ルール(種はその生息条件が満たされる場所にのみ生息できる)が含まれます。何も選択する前に、これらを書き留めるか、明確に把握しておきましょう。
-
種から考えるのではなく、制約から逆算して考える。 「この動物は好きか」と問うのではなく、「すべてのルールを同時に満たせる種の組み合わせはどれか」と問いましょう。システムとして捉えてください。すべての生産者は消費者に食べられなければならず、すべての消費者は十分なカロリーを得なければならず、連鎖全体が地形の制限内で必要な長さに達していなければなりません。このシステム的な視点こそ、マッキンゼーが実際に測定しているスキルです。
-
各種をカロリーと地形の条件に対して個別に確認し、次にセット全体として確認する。 単独では機能する選択が、システム全体を破綻させることがあります。例えば、唯一の食料源が十分なカロリーを生産しない捕食者や、選択した深度では生存できない種などです。個別の適合性と連鎖全体の適合性の両方を検証してください。
-
余裕を持たせることで行き詰まりを避ける。 最もよくある失敗は、早い段階で種を確定してしまい、後になってどの組み合わせでも連鎖が完成しないことに気づき、やり直す時間がなくなることです。選択を確定する前に、頭の中で実行可能な完全な連鎖を描き、より多くの選択肢を残せる種を優先しましょう。
-
時間を独立した制約として管理する。 ルールの読み込みと検証には時間がかかるため、意識的に時間を配分し、バランスが取れていない連鎖を修正するための余裕を残しておきましょう。一つの頑固なスロットにウィンドウ全体を費やさないようにしてください。
Ecosystem Buildingで勝つためのマインドセットは、ケースのスコープを定める際に使う、規律ある制約優先の構造化と同じです。ゲームのルールを定義し、一つの変数を最適化して残りがうまくいくことを期待するのではなく、すべての制約を同時に満たすソリューションを設計してください。
モジュール2 — Red Rock Study
Red Rock Studyは複数フェーズにわたるデータ調査です。ケースをステージごとに進み、各ステージで収集する情報を決定し、資料を解釈し、分析を実行し、時間的プレッシャーの中で回答を確定します。このモジュールは古典的なケース面接に最も近く、仮説主導の分析——早い段階で見解を形成し、無差別にすべてを読むのではなくデータで検証する——を評価します。
フェーズごとのアプローチ方法:
-
意図を持って進む。 初期フェーズでは、データの収集やシナリオの探索が求められます。手当たり次第に何でも開かないようにしましょう。ケースが本当に何を問うているかについて仮説を立て、それを指針として最初に引き出す情報を決めてください。スコアリングはあなたの意思決定経路を読み取るため、的を絞った調査は散漫なものより高く評価されます。
-
すべてのデータではなく、適切なデータを抽出する。 各資料には必要以上の情報が含まれています。グラフや表を詳しく見る前に、自分が答えようとしている具体的な問い——トレンド、比較、ドライバー——を明確にし、それだけを抽出してください。これは分析作業を迅速かつ正確にする「資料を見る前に問いを読む」という規律と同じです。PST/Solveデータ解釈ガイドでは、このスキルを徹底的に練習できます。
-
直感ではなく、フレームワークで分析する。 指標が変動した場合、結論を出す前に分解してください。利益が変化した場合は売上高とコストを分けて考え、売上高が変化した場合は価格と数量を分けて考えます。これはケース面接で使われる収益性のロジックと同じであり、推論の経路を明確で説明可能なものに保ちます——まさにスコアリングエンジンが評価するものです。
-
正確に、そしてデータが証明することだけを回答する。 罠は「もっともらしい」ことと「裏付けられている」ことを混同することです。数値が実際に示す結論にコミットし、正しいと感じる結論ではなく、正しいと証明された結論を選んでください。ある主張がデータに含まれていない前提を必要とする場合、それは証明されていません——これらの判断は論理チェックとして扱ってください。
-
フェーズ全体でペースを管理する。 Red Rockは複数フェーズで構成されているため、初期フェーズで時間を使い果たすと、後のフェーズに割く時間がなくなります。フェーズごとに内部的な時間配分を設定し、確信のある判断は素早く行い、ケースの残りを犠牲にして一つの曖昧な資料に過剰な時間を投資しないようにしましょう。
Red Rock Studyは、コンサルタントのように調査する候補者を評価します。仮説を最初に立て、次に的を絞ったデータを収集し、構造的な分析を行い、証拠に完全に裏付けられた結論を導き出す。データ読み取りのメカニズムについてより深く学ぶには、データ解釈の詳細ガイドをご覧ください。
両モジュールにわたる時間管理
2つのモジュールを約60〜81分でこなすため、時間は共有リソースです。そして推測がペナルティの対象となる以上、「最後に何かを埋めればいい」という安全策はもはや通用しません。ペース管理をスコアリングされるプロセスの一部として捉えてください:
flowchart TD
A[モジュールに入る] --> B[まずルールを読む/ケースを整理する]
B --> C{時間のかかる判断?}
C -->|はい| D["時間を配分し、バッファを確保する"]
C -->|いいえ| E[確信のある判断を下し、先に進む]
D --> F{経路はまだ一貫しているか?}
E --> F
F -->|はい| G[次のフェーズへ進む]
F -->|いいえ| H[確定する前に今すぐ修正する]
```- **理解を前倒しにする。** どちらのモジュールも、最初に時間をかけることで有利になります――エコシステム構築では制約のマッピング、レッドロックではケースのフレーミングです。セットアップを急ぐことが最もコストの高いミスです。
- **修正バッファを確保する。** 食物連鎖を再調整したり、分析をやり直したりする余裕を残しておきましょう。修正した一貫性のあるパスは、時間切れで直せなかった壊れたパスより優れています。
- **答えを盲目的に埋めない。** エンジンは根拠のある選択を読み取るため、意図的だが不完全な判断は、でたらめな判断よりも優れています。詳細なペース配分の戦術は、[PST/Solveの時間管理ガイド](/en/guides/mckinsey-pst-time-management/)をご覧ください。
## Solveのための準備プラン
答えを暗記してSolveを詰め込むことはできません――モジュールは手続き的に多様であり、採点はプロセスを読み取ります。代わりに、2つの推論モードを鍛えましょう。
| 日数 | フォーカスエリア | 毎日の練習 |
|------|-----------|----------------|
| **1〜2日目** | オリエンテーション | [Solve準備ハブ](/en/guides/mckinsey-pst-solve-preparation/)を読む。両モジュールと採点がプロセスベースであることを理解する。各モジュールを1回ずつ練習する。 |
| **3〜4日目** | エコシステム構築――制約 | 制約付き最適化パズルを練習する。まずルールを読み、制約から逆算し、確定前に連鎖全体を検証することを繰り返す。 |
| **5〜6日目** | レッドロックスタディ――データ | 仮説主導の図表読解を練習する。結論を出す前に指標を分解し、「証明済み」と「もっともらしい」を区別する。[データ解釈ガイド](/en/guides/mckinsey-pst-data-interpretation/)を活用する。 |
| **7日目** | スピードとテレメトリー | 厳格なタイマーのもとで両モジュールを実施する。盲目的なクリックなしに、明確で意図的な判断パスに集中する。 |
| **8〜9日目** | フルシミュレーション | 時間制限付きの2モジュールセッションを完了する。結果だけでなく、判断の*順序と根拠*を振り返る。 |
| **10日目** | 軽い復習+休息 | 2つの思考モードを定着させる。アセスメント当日の前に休む。 |
レッドロックの分析は計算が自動化されていると速く進むため、毎日10分の暗算練習――パーセンテージ、割り算のショートカット、概算――を補足しましょう。[暗算ガイド](/en/guides/mental-math-consulting/)で強化してください。
## Solveのスキルがケースインタビューにどのように活かされるか
Solveは孤立したハードルではありません。各モジュールは、[マッキンゼーのケース面接](/en/guides/mckinsey-case-interview-guide/)で使うスキルを鍛えます。
| Solveモジュール | ケース面接への応用 |
|-----------|---------------------------|
| エコシステム構築――制約マッピング | 現実的な制約のもとでケースをスコープし、イシューツリーを構造化する |
| エコシステム構築――システム思考 | オペレーションや戦略ケースでレバーがどのように相互作用するかを把握する |
| レッドロック――ターゲットを絞ったデータ抽出 | インタビュアー主導のケースで図表を解釈する |
| レッドロック――指標の分解 | [収益性](/en/case-types/profitability/)および[市場規模推定](/en/case-types/market-sizing/)の分析を構造化する |
| レッドロック――証拠に基づく結論 | データが実際に裏付ける提言を提示する |
Solveを別途乗り越えるべき試験としてではなく、ケース準備の第一フェーズとして捉える候補者は、その後の面接ラウンドで一貫して優れたパフォーマンスを発揮します。
## アセスメント当日のチェックリスト
- 何か行動を起こす前に、すべてのルールやケースフレームを*完全に*読む――セットアップ時間は採点されるプロセスであり、無駄な時間ではない
- エコシステム構築では、制約(カロリー、連鎖の長さ、地形)から逆算し、選択を確定する前に連鎖全体を検証する
- レッドロックでは、まず仮説を立て、それを検証するデータのみを取得する
- 結論を出す前に動いている指標を分解し、もっともらしさではなく証拠を求める
- モジュールごと・フェーズごとに時間を配分し、壊れたパスを修正するためのバッファを確保する
- 答えを埋めるために盲目的にクリックしない――推測はペナルティの対象であり、判断パスは読み取られる
- 推論パスを最初から最後まで一貫して保つ;エンジンはそこへの到達プロセスを採点する
## 重要なポイント
- 筆記式PSTは廃止され、**Solve**はマッキンゼーのグローバルデフォルトのデジタルアセスメントとなっている(一部のオフィスでは引き続きPSTを実施している場合がある)
- セッションは約60〜81分で**2つのミニゲーム**から構成され、多くの場合**エコシステム構築**と**レッドロックスタディ**が出題される
- 採点は**アルゴリズムによるプロセスベース**――判断パスとタイミングを読み取るため、**推測はペナルティの対象**となり、候補者の約70%が脱落する
- **エコシステム構築**は制約付き最適化:ルールを読み、制約から逆算し、連鎖全体を検証し、行き詰まりを避ける
- **レッドロックスタディ**は仮説主導のデータ調査:意図を持ってナビゲートし、適切なデータを抽出し、指標を分解し、証明されたことのみに答える
- これらのスキルはケース面接に直接活かされ、Solveの準備を二重に価値あるものにする
## 今すぐ練習を始めよう
2つのモジュールが報いるのは、ケース面接と同じことです:時間的プレッシャーのもとでの、構造的かつ仮説主導の推論。CasesCoach AIの練習はまさにその力を鍛えます――実際のケースに取り組み、各ステップの根拠を問われ、時計が動いている中でも明確な判断パスを維持することを学びます。[マッキンゼースタイルのケース](/en/company/mckinsey/)と[仮説主導の問題解決](/en/guides/hypothesis-driven-problem-solving/)から始め、[AIモック面接](/account?tab=mock&lang=en)でプレッシャーをかけてみましょう。無料アカウントには3つの練習ケースとAIモックが含まれており、[Pro](/pricing/)では835件以上のケースと複数回のAIモックセッションが利用可能で、両Solveモジュールが求める推論を徹底的に練習できます。