面接対策：分解・ケーススタディラウンド — 最重要かつ最難関

「ユウキ、リクルータースクリーンは通ったのか」

金曜日の夕方、Arclight AI のオフィスでソウタはコーヒーを淹れていた。ジュニアエンジニアのユウキが興奮した表情でラウンジに駆け込んでくる。

「ソウタさん、通りました！ Palantir の FDE ポジション、次は分解ラウンドです」

ユウキは入社して1年が経つ。ソウタの下でFDEとしてのスキルを磨いてきた彼が、いよいよ転職市場に挑戦する。ソウタは嬉しさと同時に、ある懸念を感じた。

「分解ラウンドか。正直に言うぞ——FDE面接の中で最も落ちやすいラウンドだ」

ユウキの表情が曇る。

「通過率は約40%。コーディングラウンドやシステムデザインラウンドが60〜70%の通過率なのに対して、圧倒的に低い。しかも配点は全体の30%を占める。ここで落ちたら、他がどんなに良くても通らない」

「そんなに厳しいんですか……」

ソウタはホワイトボードの前に立った。

「落ちる理由で一番多いのは何だと思う？」

ユウキは少し考えて答える。「技術力不足？」

「違う。"最初の1分で技術的な解決策に飛びつくこと"だ」

ソウタはマーカーを手に取った。

「今日はこのラウンドを徹底的に練習する。カイさんから教わったフレームワークと、俺が実際に経験したケースを全部伝える」

なぜ分解ラウンドが最重要か

分解ラウンド（Decomposition Round）は、FDE面接に特有の選考プロセスだ。ソフトウェアエンジニアの面接には存在しない。

INFO

分解ラウンドの位置づけ: 通過率は約40%で、コーディング（約65%）やシステムデザイン（約60%）と比較して最も低い。配点は全体評価の約30%を占め、最も重みが大きいラウンドである。

このラウンドが難しい理由は3つある。

1. 正解がない

コーディング問題には明確な正解がある。しかし分解ラウンドでは「航空会社の遅延を予測するシステムを構築してください」といった曖昧な問題が提示される。正解は存在しない。評価されるのはプロセスだ。

2. SWE の訓練が邪魔をする

優秀なエンジニアほど、問題を聞いた瞬間に解決策が浮かぶ。しかし分解ラウンドでは、解決策に飛びつくことが最大の減点要因になる。面接官は「この人は顧客の前に出しても大丈夫か？」を見ている。

3. 複数のスキルが同時に問われる

面接官が評価する3つの軸は以下の通りだ。

評価軸	内容	配点目安
構造的思考	問題をMECEに分解できるか	40%
ステークホルダー認識	誰のための解決策か理解しているか	30%
曖昧さへの耐性	不完全な情報で前に進めるか	30%

「SWEの面接なら"正しいアルゴリズムを書けるか"で済む。FDEの面接は"正しい問題を見つけられるか"が問われる。根本的に違うんだ」

ソウタはそう言って、フレームワークの説明に入った。

5ステップフレームワーク

カイから教わったフレームワークをソウタはユウキに共有した。

Loading diagram...

Step 1: 問題の明確化

やること: 解決策を提案する前に、最低3つの質問をする。

面接官が「航空会社の遅延を予測するシステムを構築してください」と言ったとき、最悪の回答は「LSTMで時系列予測を構築します」だ。

最初にすべきことは質問だ。

「"遅延"の定義は何ですか？ 15分以上ですか？ 30分以上ですか？」
「対象は国内線のみですか？国際線も含みますか？」
「予測結果の利用者は誰ですか？旅客への通知？運航管理部門？」
「現在はどのように遅延を管理していますか？」

WARNING

最初の2分で質問を一つもしない候補者は、ほぼ確実に不合格になる。面接官は「この人は顧客の話を聞かずにコードを書き始めるタイプだ」と判断する。

Step 2: ステークホルダーと成功指標の特定

やること: 誰が関わり、何をもって成功とするかを定義する。

ステークホルダーを洗い出すことで、問題の全体像が見えてくる。

# 面接での思考をコードに落とすとこうなる
class StakeholderAnalysis
  Stakeholder = Data.define(:name, :role, :pain_point, :success_metric)
 
  def self.for_airline_delay_prediction
    [
      Stakeholder.new(
        name: "運航管理部門",
        role: "意思決定者",
        pain_point: "遅延発生後の対応が後手に回る",
        success_metric: "遅延の2時間前に通知を受け取れる"
      ),
      Stakeholder.new(
        name: "旅客",
        role: "エンドユーザー",
        pain_point: "空港で長時間待たされる",
        success_metric: "事前に正確な到着時刻を知れる"
      ),
      Stakeholder.new(
        name: "地上スタッフ",
        role: "オペレーター",
        pain_point: "ゲート変更の連絡が遅い",
        success_metric: "ゲート再配置を30分前に完了できる"
      ),
    ]
  end
end

Step 3: インプットとデータ品質のマッピング

やること: 利用可能なデータ、その品質、欠損リスクを特定する。

FDEが直面する現実は「データが完璧に揃っていることなど絶対にない」ということだ。面接でもそれを示す必要がある。

利用可能なデータは何か
データの鮮度はどの程度か（リアルタイム？日次バッチ？）
欠損やバイアスはないか
データの取得にどのくらいのコストがかかるか

Step 4: サブ問題への分解と優先順位付け

やること: 大きな問題を3〜5個のサブ問題に分解し、インパクトと実現可能性で優先順位をつける。

サブ問題	インパクト	実現難易度	優先度
天候データと遅延の相関分析	高	低	1
過去の遅延パターンの特定	高	低	2
リアルタイム気象API連携	中	中	3
機材故障予測モデル	高	高	4
乗客への通知システム	中	低	5

Step 5: ウォーキングスケルトンMVPの提案

やること: 1〜2週間で動くものを見せられるMVPを提案する。

完璧なシステムではなく「価値を証明できる最小のシステム」を提案する。FDEにとってこれは最も重要なスキルの一つだ。

「MVPを提案できるかどうかで、"学生"と"実務者"が分かれる」——カイはそう言っていた。

6つの練習ケース

ソウタはホワイトボードに6つの問題を書き出した。

「この6つを全部解けるようになれば、本番で何が来ても対応できる。1つずつやっていくぞ」

ケース1: 航空会社の遅延予測システム

問題: 「航空会社が機械学習を使ってフライトの遅延を予測したいと言っています。どうアプローチしますか？」

NG回答

「LSTMを使った時系列予測モデルを構築します。過去のフライトデータと気象データをフィーチャーとして、遅延時間を回帰予測します。PyTorchで実装して……」

WARNING

この回答は技術的には正しいかもしれないが、分解ラウンドでは即座に減点される。面接官が聞きたいのは「どのモデルを使うか」ではなく「どう問題を理解するか」だ。

OK回答

「まずいくつか確認させてください。"遅延"はどの程度の時間を指しますか？ 15分以上？それとも1時間以上ですか？——対象は国内線のみですか？——予測結果は誰がどう使いますか？旅客への通知？運航管理部門の意思決定支援？——現在はどのように遅延に対応していますか？」

面接官の回答を受けて、ソウタは分解を始める。

「ありがとうございます。では、この問題を4つのサブ問題に分解します。第一に、遅延の定義と基準の合意。第二に、利用可能なデータソースの特定。第三に、ルールベースの予測MVPの構築。第四に、MLモデルへの段階的な拡張です」

MVPとして提案するのはルールベースの予測だ。

# MVP: ルールベースの遅延予測サービス
class FlightDelayPredictor
  WEATHER_THRESHOLDS = {
    wind_speed_knots: 35,
    visibility_miles: 1.0,
    snow_inches_per_hour: 0.5,
  }.freeze
 
  DelayPrediction = Data.define(:flight, :risk_level, :estimated_delay_minutes, :factors)
 
  def predict(flight)
    factors = []
    factors.concat(check_weather(flight))
    factors.concat(check_historical_pattern(flight))
    factors.concat(check_inbound_aircraft(flight))
 
    risk_level = calculate_risk(factors)
    estimated_delay = estimate_delay_minutes(factors)
 
    DelayPrediction.new(
      flight:,
      risk_level:,
      estimated_delay_minutes: estimated_delay,
      factors:
    )
  end
 
  private
 
  def check_weather(flight)
    weather = WeatherService.current(flight.departure_airport)
    factors = []
 
    if weather.wind_speed > WEATHER_THRESHOLDS[:wind_speed_knots]
      factors << { type: :weather, detail: "強風: #{weather.wind_speed}kt", severity: :high }
    end
 
    if weather.visibility < WEATHER_THRESHOLDS[:visibility_miles]
      factors << { type: :weather, detail: "低視程: #{weather.visibility}mi", severity: :high }
    end
 
    factors
  end
 
  def check_historical_pattern(flight)
    # 同一路線・同一時間帯の過去90日の遅延率
    stats = FlightStats.where(
      route: flight.route,
      hour_of_day: flight.departure_time.hour
    ).where("departure_date > ?", 90.days.ago)
 
    delay_rate = stats.delayed.count.to_f / stats.count
    return [] if delay_rate < 0.2
 
    [{ type: :historical, detail: "過去遅延率: #{(delay_rate * 100).round}%", severity: :medium }]
  end
 
  def check_inbound_aircraft(flight)
    inbound = flight.aircraft.current_inbound_flight
    return [] unless inbound
 
    if inbound.estimated_arrival > flight.scheduled_departure - 45.minutes
      [{ type: :aircraft, detail: "機材到着遅れ", severity: :high }]
    else
      []
    end
  end
 
  def calculate_risk(factors)
    high_count = factors.count { |f| f[:severity] == :high }
    return :high if high_count >= 2
    return :medium if high_count >= 1 || factors.size >= 2
    return :low if factors.any?
 
    :none
  end
 
  def estimate_delay_minutes(factors)
    factors.sum do |f|
      case f[:severity]
      when :high then 45
      when :medium then 20
      else 10
      end
    end
  end
end

INFO

ルールベースMVPのポイント: 1〜2週間で構築可能で、結果の説明可能性が高い。顧客が「なぜこの予測になったのか」を理解できる。MLモデルへの移行は、ルールベースの精度をベースラインとして比較できる。

ケース2: 保険会社の請求処理自動化

問題: 「保険会社が年間100万件の請求処理を自動化したいと言っています。どうアプローチしますか？」

NG回答

「OCRとNLPパイプラインを構築して、全ての請求を自動処理します」

OK回答

「年間100万件ということは、1日あたり約2,700件ですね。まず確認したいのですが、請求にはどのような種類がありますか？——現在の処理時間はどのくらいですか？——自動化の目標は処理速度の向上ですか？コスト削減ですか？——完全自動化ですか、それとも人間のレビューは残しますか？」

このケースの分解で重要なのは、全てを一度に自動化しようとしないことだ。

Loading diagram...

請求タイプを分類することが第一歩だ。

請求タイプ	年間件数	自動化可能性	MVP対象
少額定型（通院）	40万件	高	○
中額定型（入院）	30万件	中	Phase 2
高額複雑（手術）	20万件	低	×
特殊ケース	10万件	低	×

MVPでは「少額定型」の40万件に集中する。これだけで全体の40%をカバーでき、リスクが最も低い。

# 請求処理の自動化パイプライン
class ClaimProcessor
  CONFIDENCE_THRESHOLD = 0.85
 
  ProcessingResult = Data.define(:claim, :decision, :confidence, :requires_review)
 
  def process(claim)
    classification = classify_claim(claim)
    return route_to_human(claim, "複雑な請求タイプ") unless classification.auto_eligible?
 
    extracted = extract_claim_data(claim)
    return route_to_human(claim, "データ抽出の信頼度不足") if extracted.confidence < CONFIDENCE_THRESHOLD
 
    validated = validate_against_policy(extracted, claim.policy)
    return route_to_human(claim, "ポリシー検証エラー") unless validated.passed?
 
    auto_approve(claim, extracted, validated)
  end
 
  private
 
  def classify_claim(claim)
    ClaimClassifier.new(claim).classify
  end
 
  def extract_claim_data(claim)
    # OCRで書類を読み取り、構造化データに変換
    OcrExtractor.new(claim.documents).extract
  end
 
  def validate_against_policy(extracted, policy)
    PolicyValidator.new(extracted, policy).validate
  end
 
  def auto_approve(claim, extracted, validated)
    ProcessingResult.new(
      claim:,
      decision: :approved,
      confidence: extracted.confidence,
      requires_review: false
    )
  end
 
  def route_to_human(claim, reason)
    ProcessingResult.new(
      claim:,
      decision: :pending_review,
      confidence: 0.0,
      requires_review: true
    )
  end
end

INFO

自動化プロジェクトの鉄則: 「100%の自動化」を目指さない。80%を自動化して20%は人間に任せるほうが、圧倒的に早く価値を出せる。面接でもこの判断力が評価される。

ケース3: 物流会社のルート最適化

問題: 「配送ルートを最適化して燃料費を20%削減したいと言っています。どうアプローチしますか？」

NG回答

「巡回セールスマン問題として定式化し、遺伝的アルゴリズムで最適解を求めます」

OK回答

「20%削減という具体的な目標があるのですね。まず確認させてください。現在の配送ルートはどのように決めていますか？ドライバーの経験ベース？それとも何かシステムを使っていますか？——配送車両は何台で、1日の配送先はどのくらいですか？——時間指定配送はありますか？——車種による制約（冷蔵車など）はありますか？」

分解のポイントは、最適化の前に現状把握が必要だということだ。

ステップ	内容	期間
現状計測	GPS データで実際のルートと燃料消費を記録	2週間
ボトルネック特定	非効率な区間を可視化	1週間
ルールベース改善	明らかな迂回の排除	1週間
ヒューリスティック導入	近傍探索による最適化	2週間
高度な最適化	制約条件付き最適化	以降

WARNING

よくある失敗: 「燃料費20%削減」を技術だけで解決しようとすること。実際にはドライバーのアイドリング習慣や積み込み順序の改善だけで5〜10%削減できるケースが多い。技術と運用の両面を提案することが高評価につながる。

ソウタはユウキに補足した。

「このケースで面接官が見ているのは、"いきなり高度なアルゴリズムを持ち出さないか"だ。まず計測し、簡単な改善を試し、それでも足りない分を技術で解決する。この順番が重要なんだ」

ケース4: 大学のオンライン試験不正検知

問題: 「大学がオンライン試験での不正行為を検知するシステムを作りたいと言っています。どうアプローチしますか？」

このケースには技術的な落とし穴がある。多くの候補者がカメラ監視やブラウザロックダウンから話し始めるが、最初に議論すべきは倫理だ。

OK回答の方向性

「これは技術的な問題であると同時に、倫理的な問題でもあります。まず確認させてください。不正行為の定義はどこまでですか？カンニングペーパーの使用？他者との通信？生成AIの利用？——誤検知の場合、学生にどのような影響がありますか？——学生のプライバシーに関するポリシーはありますか？——障がいのある学生への配慮はどうしますか？」

分解のポイントは以下の通りだ。

側面	考慮事項
倫理	プライバシー権、誤検知の影響、同意の取得
公平性	障がい者対応、ネットワーク環境の差
技術	検知手法、精度、スケーラビリティ
運用	教員の負担、学生サポート体制

INFO

倫理的配慮を最初に挙げられる候補者は非常に少ない。しかしFDEは実際のデプロイ現場で、技術的に可能なことと倫理的にすべきことの境界線を判断しなければならない。面接官はまさにこの判断力を見ている。

「顔認識で試験中ずっと監視するシステムは技術的には構築できる。でもそれは学生にとって刑務所のような体験になる。FDEは"作れるか"ではなく"作るべきか"を考えるんだ」

ケース5: 自治体の災害情報集約プラットフォーム

問題: 「自治体が災害時に各機関からの情報を一元管理するプラットフォームを構築したいと言っています。どうアプローチしますか？」

このケースの難しさは、技術よりも組織間の調整にある。

OK回答の方向性

「災害情報プラットフォームは、技術的な課題よりも組織的な課題のほうが大きいケースです。まず確認させてください。どの機関が参加しますか？消防、警察、自衛隊、医療機関？——各機関は現在どのようなシステムを使っていますか？——データフォーマットの標準は存在しますか？——災害時にインターネット接続が不安定になった場合はどうしますか？」

分解のポイントは以下だ。

サブ問題	本質的な課題
データ標準化	各機関のフォーマットが異なる
認証と権限	機関ごとのアクセス制御
オフライン対応	災害時のネットワーク不安定
組織間合意	誰がデータを入力する責任を持つか
訓練と運用	年に数回しか使わないシステムの習熟

# 災害情報の正規化レイヤー
class DisasterInfoNormalizer
  SUPPORTED_FORMATS = %i[xml csv json pdf_ocr].freeze
 
  NormalizedReport = Data.define(:source_agency, :report_type, :severity, :location, :timestamp, :raw_content)
 
  def normalize(raw_input, source_agency:)
    format = detect_format(raw_input)
    parsed = parse_by_format(raw_input, format)
 
    NormalizedReport.new(
      source_agency:,
      report_type: classify_report(parsed),
      severity: extract_severity(parsed),
      location: extract_location(parsed),
      timestamp: extract_timestamp(parsed) || Time.current,
      raw_content: raw_input
    )
  end
 
  private
 
  def detect_format(input)
    case input
    when /\A\s*</ then :xml
    when /\A\s*[\[{]/ then :json
    else :csv
    end
  end
 
  def parse_by_format(input, format)
    case format
    when :xml then XmlParser.parse(input)
    when :json then JSON.parse(input, symbolize_names: true)
    when :csv then CsvParser.parse(input)
    end
  end
 
  def classify_report(parsed)
    # 報告タイプを分類: 被害状況、避難情報、救助要請、インフラ状況
    ReportClassifier.classify(parsed)
  end
 
  def extract_severity(parsed)
    SeverityExtractor.extract(parsed)
  end
 
  def extract_location(parsed)
    LocationExtractor.extract(parsed)
  end
 
  def extract_timestamp(parsed)
    TimestampExtractor.extract(parsed)
  end
end

WARNING

災害情報システムの最大の落とし穴: 「平時に使われないシステムは、有事にも使えない」。年に数回の災害のためだけに新しいシステムを導入しても、操作を覚えている人がいない。日常業務でも利用できる設計にすることが鍵だ。

検証段階	手法	指標
課題検証	顧客インタビュー（20社）	課題の深刻度スコア
解決策検証	デモ + PoC（5社）	PoC後の有償契約率
PMF検証	NPS + リテンション	NPS 40以上、月次リテンション80%以上
スケール検証	営業プロセスの再現性	CAC回収期間12ヶ月以内

「ここでFDEが価値を発揮するのは、"技術的にすごいもの"を作ることじゃない。"顧客が金を払う最小のもの"を見つけることだ。PMFの検証は、コードを書く前に半分終わっているべきなんだ」

ソウタはそう言って、次のセクションに進んだ。

分解ラウンドの「型」

フレームワークと練習ケースを一通り終えたところで、ソウタは実践的なテクニックを共有した。

ホワイトボードの使い方

「面接にはだいたいホワイトボードかiPadがある。必ず使え」

ホワイトボードの使い方には型がある。

左上にステークホルダーを書く
中央に問題をサブ問題に分解したツリーを描く
右側に成功指標を書く
下部にMVPのスコープを線で囲む

「頭の中で考えていることを可視化するだけで、面接官の評価は劇的に上がる。なぜなら、面接官はあなたの思考プロセスを評価しているからだ」

「考える時間をください」の使い方

「沈黙を恐れるな。でも使い方がある」

× 「えーと……」と言いながら30秒黙る
○ 「30秒だけ考える時間をいただいてもいいですか。
     問題の構造を整理したいので」

時間をもらうときは、何のために使うかを宣言する。これだけで面接官には「構造的に考える人だ」と映る。

面接官とのインタラクション

WARNING

最も危険な行動: 一人で5分以上考え込むこと。分解ラウンドは独白ではなくダイアログだ。面接官を顧客だと思って対話せよ。

面接官は敵ではない。顧客のシミュレーションだ。以下のフレーズを使いこなすこと。

「ここまでの理解で合っていますか？」——中間確認
「Aの方向とBの方向がありますが、どちらに深掘りしましょうか？」——優先度の確認
「ここは仮定を置いて進めてもいいですか？」——曖昧さへの対処

時間配分

45〜60分のラウンドでの推奨配分は以下の通りだ。

フェーズ	時間	やること
問題の明確化	5〜8分	質問、ステークホルダー特定
分解と構造化	15〜20分	サブ問題の洗い出し、優先順位
MVP提案	10〜15分	ウォーキングスケルトンの説明
技術的深掘り	10〜15分	面接官からの質問に対応
まとめ	3〜5分	リスク、次ステップの整理