面接対策：クライアントシミュレーション & 行動面接 — 顧客対応力を証明する

「分解力を鍛えるのは、戦いの半分に過ぎない」

前回のセッションを終え、ソウタはホワイトボードのマーカーを置きながらユウキに言った。ユウキは問題分解の演習を5時間以上こなし、手応えを感じていた。しかし、ソウタの表情は晴れない。

「分解できるのは、あくまで"ひとりで考える力"の証明だ。FDE の面接には、もうひとつ別次元のラウンドがある」

ユウキが首をかしげた瞬間、会議室のドアが開いた。

「——クライアントシミュレーションだろう？」

カイがコーヒーを2つ手に入ってきた。

「面接官が"顧客"を演じる45分間のロールプレイ。技術力だけじゃなく、目の前の人間とどう向き合えるかが試される。FDE 面接で最も落ちやすいラウンドだ」

カイはホワイトボードを消し、中央に大きく書いた。

「コードは書けても、顧客と話せなければ FDE にはなれない」

ソウタはうなずいた。自分自身、Arclight AI の面接でこのラウンドが最も緊張したことを覚えている。

「今日は、俺とカイさんで面接官役をやる。ユウキ、準備はいいか？」

ユウキは深呼吸した。「お願いします」

クライアントシミュレーションラウンド（45分）概要

クライアントシミュレーションは、FDE 面接において最もユニークなラウンドだ。コーディングでもシステムデザインでもない。面接官が「不満を抱えた顧客」「意思決定に迷う経営者」「競合に傾いている担当者」などの役を演じ、候補者が FDE として45分間対応する。

評価される4つの軸

ラウンドの典型的な流れ

1. 導入（5分）: 面接官がシナリオ設定を説明する
2. ロールプレイ本編（30分）: 顧客役の面接官とリアルタイムで対話する
3. 振り返り（10分）: ロールプレイを出て、自分の対応を分析する

5つの模擬シミュレーション

カイがホワイトボードに5つのシナリオを書き出した。

「これは実際の FDE 面接で出されたパターンを元にしている。全部やるぞ」

シミュレーション1: 技術的に不満な顧客

設定: あなたは Arclight AI の FDE。導入企業「メガバンクX社」の技術責任者が、パフォーマンスへの不満を訴えている。

ロールプレイ

顧客（カイ）: 「導入して3ヶ月経つのに、約束された性能が出ていない。レイテンシが500ms超えている。SLA では200ms以下のはずだ。うちの経営会議で "AI 導入は失敗だった" という声が出始めている」

NG 回答（やってはいけない例）:

「500ms ですか？ そんなはずはないんですが……。うちのテスト環境では100ms以下で動いてますよ。そちらのインフラに問題があるんじゃないですか？」

ソウタが解説した。「これは最悪だ。3つのミスを犯している。(1) 顧客の体験を否定している、(2) 責任を転嫁している、(3) 共感がゼロだ」

模範回答（ユウキが学ぶべきパターン）:

「ご報告ありがとうございます。レイテンシが SLA を大幅に超えているのは、経営会議で問題視されるのも当然です。まず、御社の体験している状況を正確に理解させてください。いくつか確認させていただいてもよろしいですか？」

1. 共感: 顧客の苦痛を認める。「当然です」という言葉で正当性を肯定する
2. 事実確認: 感情ではなくデータに基づいて会話を進める
3. 技術的切り分け: 問題の所在を特定するための診断を提案する
4. アクションプラン: 次のステップを明確にして会話を終える

技術的切り分けの実装例

ソウタは、実際に Arclight AI で使っているパフォーマンス診断サービスのコードをユウキに見せた。

# app/services/performance/diagnostic_service.rb
class Performance::DiagnosticService
  LATENCY_THRESHOLDS = {
    api_gateway: 50,    # ms
    inference: 100,     # ms
    postprocess: 30,    # ms
    network: 20,        # ms
  }.freeze
 
  Result = Data.define(:bottleneck, :measurements, :recommendations)
 
  def initialize(account:, date_range: 7.days.ago..Time.current)
    @account = account
    @date_range = date_range
  end
 
  def diagnose
    measurements = measure_each_layer
    bottleneck = identify_bottleneck(measurements)
    recommendations = build_recommendations(bottleneck, measurements)
 
    Result.new(bottleneck:, measurements:, recommendations:)
  end
 
  private
 
  def measure_each_layer
    LATENCY_THRESHOLDS.keys.each_with_object({}) do |layer, result|
      stats = LatencyLog
        .where(account: @account, layer: layer, created_at: @date_range)
        .pick(
          Arel.sql("AVG(duration_ms) AS avg_ms"),
          Arel.sql("PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY duration_ms) AS p95_ms"),
          Arel.sql("PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY duration_ms) AS p99_ms")
        )
 
      result[layer] = {
        avg_ms: stats[0]&.round(2),
        p95_ms: stats[1]&.round(2),
        p99_ms: stats[2]&.round(2),
        threshold: LATENCY_THRESHOLDS[layer],
      }
    end
  end
 
  def identify_bottleneck(measurements)
    measurements.max_by do |_layer, stats|
      ratio = stats[:p95_ms].to_f / stats[:threshold]
      ratio
    end.first
  end
 
  def build_recommendations(bottleneck, measurements)
    case bottleneck
    when :inference
      [
        "モデルの量子化（INT8）を検討: 推論速度が約2倍に改善",
        "バッチ推論の導入: 同時リクエストをまとめて処理",
        "GPU インスタンスのスケールアウト: 現在の負荷に対して不足の可能性",
      ]
    when :api_gateway
      [
        "API Gateway のキャッシュ設定を確認",
        "認証ミドルウェアの処理時間を計測",
        "リージョン間レイテンシの確認: エンドポイントの地理的最適化",
      ]
    when :postprocess
      [
        "後処理パイプラインの並列化",
        "不要な変換ステップの削除",
        "結果キャッシュの導入（同一クエリの再計算を回避）",
      ]
    when :network
      [
        "CloudFront ディストリビューションの設定確認",
        "VPC エンドポイントの利用（AWS 内部通信の最適化）",
        "接続プーリングの導入",
      ]
    end
  end
end

「このコードを面接で書く必要はない」とソウタは補足した。「でも、"具体的にどう切り分けるか" を口頭で説明できることが大事だ。レイヤーごとに計測して、ボトルネックを特定して、レイヤー別の改善策を提案する——この思考プロセスが評価される」

シミュレーション2: 非技術の経営者への説明

設定: あなたは FDE。導入を検討中の「中堅製造業Y社」の CFO が、投資対効果について説明を求めている。

ロールプレイ

顧客（ソウタが CFO 役）: 「このAI導入の投資回収はいつですか？ 技術の話は分からないので、数字で教えてください。年間5,000万円のライセンス料は、うちの規模では大きな決断です」

NG 回答:

「弊社の AI モデルは Transformer ベースで、推論精度が98.5%です。RAG パイプラインにより……」

ユウキが首を振った。「CFO に Transformer の話をしても意味がないですよね」

模範回答:

「5,000万円のご投資、慎重にご判断されるのは当然です。数字でお話しします。御社の現在の検品工程を拝見したところ、3つの領域でコスト削減が見込めます。第一に、目視検品の自動化で年間約2,800万円の人件費削減。第二に、不良品の早期検出で歩留まり率が3%改善し、年間約1,200万円の材料費削減。第三に、検品レポートの自動生成で月40時間の事務作業を削減、年間約600万円相当。合計で年間約4,600万円のコスト効果です。初年度はセットアップコストがあるため回収率92%ですが、2年目以降は年間4,600万円の効果が継続します。投資回収期間は約13ヶ月と試算しています」

技術→ビジネス翻訳の原則

シミュレーション3: 要件が矛盾するステークホルダー

設定: あなたは FDE。「金融サービスZ社」の CTO と事業部長が、同席するミーティングで正反対の要求をしている。

ロールプレイ

顧客A（カイが CTO 役）: 「セキュリティ最優先です。全データをオンプレミスに保管してください。金融庁のガイドラインがありますから、クラウドは使えません」

顧客B（ソウタが事業部長役）: 「スピード最優先です。来月にはローンチしたい。オンプレミスの構築なんて3ヶ月はかかるでしょう？ 競合に先を越されたら終わりです」

ユウキは一瞬固まった。

NG 回答:

「えーと……どちらを優先されますか？」

カイが解説した。「これは最悪の回答だ。候補者が問題を顧客に投げ返している。FDE の役割は、矛盾を解決する技術的な選択肢を提示することだ」

模範回答:

「お二方のご懸念、どちらも正当だと理解しています。CTO、金融庁ガイドラインへの準拠は必須ですし、事業部長、市場のタイミングを逃せないのも事実です。ハイブリッド構成をご提案させてください」

「まず、データを機密度で分類します。個人情報や取引データなど金融庁ガイドラインに該当するデータは、オンプレミスの閉域網に保管します。一方、モデルの推論ロジックや集計済みの統計データは、AWS の VPC 内でホストします。これにより、セキュリティ要件を満たしつつ、4週間でのβローンチが可能です」

「来月のローンチは、非機密データのみを使った限定機能でのβ版とします。並行してオンプレミス環境を構築し、3ヶ月後にフル機能をリリースする。段階的なアプローチで、両方のご要件を満たせます」

シミュレーション4: 競合製品を推す顧客

設定: あなたは FDE。商談中の「大手小売W社」のデジタル推進部長が、競合製品を高く評価している。

ロールプレイ

顧客（カイが部長役）: 「正直に言うと、○○社の製品のほうが機能が多いと思うんです。ダッシュボードも○○社のほうがきれいだし、事例も多い。なぜ御社を選ぶべきなのか、説得力のある理由をください」

NG 回答:

「○○社の製品は見た目だけですよ。実際の精度はうちのほうが上です。○○社は昨年セキュリティインシデントも起こしてますし」

ソウタが解説した。「競合を否定するのは、顧客の判断力を否定するのと同じだ。"あなたが評価している製品はダメですよ" と言っているに等しい」

模範回答:

「○○社のプロダクトは優れていますし、ダッシュボードの UI は確かに洗練されています。御社が比較検討されるのは正しいアプローチです」

「その上で、御社の小売業というコンテキストにフォーカスさせてください。弊社が御社に提供できる独自の価値は3つあります」

「第一に、FDE の常駐サポートです。○○社はプロダクトを納品しますが、弊社は人を派遣します。私が御社の業務を理解し、御社のデータに合わせてモデルをカスタマイズし続けます。御社の社員と同じフロアで働きます」

「第二に、小売特化の学習済みモデルです。弊社は過去18ヶ月で小売業12社への導入実績があり、小売特有の季節変動やプロモーション効果の予測精度で○○社を上回っています」

「第三に、スケーラビリティの実績です。御社は全国800店舗を展開されていますが、弊社は同規模の小売チェーンで、ブラックフライデーのトラフィック10倍増にも対応した実績があります」

シミュレーション5: 契約解除を検討中の顧客

設定: あなたは FDE。既存顧客「物流V社」の IT 部長が、契約の解約を検討している。

ロールプレイ

顧客（ソウタが IT 部長役）: 「予算も厳しいし、正直使いこなせていない。社内で使っているのは物流部の一部だけで、全社展開には程遠い。年間3,000万円の契約を解約しようと思っている」

NG 回答:

「お値引きしますので、もう少し続けていただけませんか？ 2,000万円まで下げられます」

カイが首を振った。「値引きは最悪の一手だ。3つの理由がある。(1) 自社の価値を自ら下げている、(2) 根本原因を解決していない、(3) 値引きで残っても、次の更新でまた同じ会話が発生する」

模範回答:

「率直にお伝えいただきありがとうございます。"使いこなせていない" というお言葉が気になりました。もう少し詳しく教えていただけますか？ 具体的に、どの時点で活用が止まったのでしょうか」

（顧客の回答を聞いた後）

「なるほど。導入時のトレーニングが物流部だけに留まっていて、営業部やカスタマーサポート部への展開が進んでいないのですね。これは弊社側の支援不足でもあります。率直に申し訳ありません」

「ご提案があります。解約を決定される前に、4週間だけお時間をいただけませんか。私が御社に週2日常駐し、営業部とカスタマーサポート部の5名ずつに集中トレーニングを実施します。4週間後に、全社での活用率と成果を改めて評価していただき、その時点で解約のご判断をいただければと思います。追加費用はいただきません」

ユウキは模範回答の構造を分析した。

1. 値引きに飛びつかない: 価値を守る
2. 根本原因を探る: 「使いこなせていない」の真因を深掘り
3. 自社の責任を認める: 信頼構築
4. 具体的なリカバリープラン: 期間、頻度、対象を明確に
5. 最終判断は顧客に委ねる: 強引に引き留めない

行動面接（STAR フォーマット）

5つのシミュレーションを終えたユウキは、椅子の背もたれに深く沈んだ。

「こんなに汗をかいた面接練習は初めてです」

カイが笑った。「シミュレーションは体力を使うだろう。次は行動面接だ。こちらは頭の勝負になる」

STAR フォーマットとは

行動面接では、候補者の過去の経験を通じて将来のパフォーマンスを予測する。回答は STAR フォーマット で構造化する。

STAR 回答の良い例と悪い例

質問: 「技術的に困難な問題を解決した経験を教えてください」

悪い例（STARになっていない）:

「データベースのパフォーマンス問題がありました。チームで調査して、インデックスを追加して解決しました。良い経験でした」

良い例（STAR で構造化）:

• S: 「前職の EC サイトで、ブラックフライデー当日にデータベースのレスポンスが10秒を超え、注文処理が停止しました。毎分約200件の注文が処理できない状態でした」
• T: 「バックエンドチームのリードとして、2時間以内にサービスを復旧させる責任がありました。CEO からは "1時間で100万円の損失" と伝えられていました」
• A: 「まず、スロークエリログを分析し、注文テーブルの結合クエリが全テーブルスキャンしていることを特定しました。次に、その場でコンポジットインデックスを追加しましたが、4億行のテーブルでのインデックス作成は30分以上かかると判断しました。そこで、私は代替策として AWS ElastiCache にホットデータをキャッシュするレイヤーを緊急実装しました。本番環境にデプロイするため、CTO に直接電話し、緊急リリースの承認を得ました」
• R: 「キャッシュ導入から23分でレスポンスタイムが200ms以下に回復し、停止していた注文処理が再開しました。ブラックフライデー当日の売上は前年比120%を達成。後日、恒久対策としてインデックス最適化とリードレプリカの追加を実施し、翌年のブラックフライデーではゼロダウンタイムを実現しました」

FDE 行動面接の頻出質問15問

カイがノートを開いた。「過去3年間で Arclight AI の FDE 面接に来た候補者の質問パターンを分析した。頻出15問を5つのカテゴリーに分類してある」

顧客対応系

1.「最も困難な顧客対応の経験を教えてください」

フレームワーク: 顧客の感情と技術的問題の両方に対処したエピソードを選ぶ。単なるバグ修正ではなく、人間関係の修復を含むストーリーが高評価。

2.「技術的に不可能な要求をどう断りましたか」

フレームワーク: 「No」を言った事実よりも、代替案をどう提示したかを語る。「できません」ではなく「この方法なら実現できます」への転換。

STAR 例（Q2 詳細）:

• S: 「担当顧客の CTO から、リアルタイムで全ユーザーの行動を AI 分析してパーソナライズする機能を要求されました。月間アクティブユーザー500万人で、レイテンシ50ms以内という条件でした」
• T: 「技術検証の結果、リアルタイム処理ではコストが月額2,000万円を超え、現実的ではないと判断しました。しかし、顧客にとってパーソナライズは事業戦略の根幹であり、単に "無理です" とは言えませんでした」
• A: 「私は3つの代替アーキテクチャを設計しました。(1) ニアリアルタイム（5分遅延）でコスト80%削減、(2) セグメントベースのバッチ処理で90%削減、(3) ハイブリッド（VIP ユーザーのみリアルタイム、他はバッチ）で70%削減。各案の精度・コスト・実装期間を比較表にまとめ、CTO とのワークショップを設定しました」
• R: 「CTO はハイブリッド案を選択。VIP ユーザー（上位5%）へのリアルタイム対応で、売上の35%をカバーできることがデータで示せました。最終的にコンバージョン率が12%向上し、CTO から "最初の要求より良い結果になった" と評価されました」

3.「顧客からのフィードバックでプロダクトを改善した例は」

フレームワーク: フィードバックを受けた → 社内に持ち帰った → プロダクトチームと協働した → リリースされた、という一連の流れを示す。FDE が「顧客の声のパイプライン」であることを証明する。

チーム・コラボ系

4.「社内の別チームと意見が対立した経験は」

フレームワーク: 対立の内容、自分の立場、相手の立場、どう解決したかを構造化。「勝った」ストーリーよりも「互いに歩み寄った」ストーリーが好まれる。

5.「チームメンバーのパフォーマンス問題にどう対処しましたか」

フレームワーク: 直接的かつ建設的なフィードバック。「陰で愚痴を言った」は NG。「1対1で話し合い、具体的な改善策を一緒に作った」が模範。

6.「リモートワークでの信頼構築をどうしましたか」

フレームワーク: 非同期コミュニケーションの工夫、定期的な1on1、ドキュメント文化の推進など、具体的なアクションを語る。

STAR 例（Q4 詳細）:

• S: 「FDE チームがプロダクトチームに提案した API 変更が、プロダクトマネージャーから "ロードマップにない" と却下されました。しかし、この API 変更がなければ3社の大型顧客が解約するリスクがありました」
• T: 「プロダクトチームとの関係を壊さずに、顧客の声を反映させる必要がありました」
• A: 「私はまず、3社の顧客から具体的なユースケースと影響度のデータを収集しました。次に、プロダクトマネージャーとの1on1を設定し、"ロードマップへの追加" ではなく "既存の優先項目との統合" として提案しました。具体的には、Q3 に予定されていた API v2 リファクタリングに、顧客が必要としているエンドポイント3つを含める形です。工数の増加は2日間だけであることを技術検証で示しました」
• R: 「プロダクトマネージャーが合意し、API v2 に3つのエンドポイントが追加されました。3社の顧客は全て契約を更新し、ARR で年間4,500万円を維持できました。この経験をきっかけに、FDE → プロダクトチームへの月次フィードバックサイクルが正式に制度化されました」

困難・失敗系

7.「締め切りに間に合わないと分かった時どうしましたか」

フレームワーク: 早期エスカレーション、スコープ調整の提案、ステークホルダーへの透明な報告。「ギリギリまで頑張って結局間に合わなかった」は最悪のパターン。

8.「失敗したプロジェクトから何を学びましたか」

フレームワーク: 失敗の事実を正直に語り、自分の責任を明確にし、具体的な改善策を示す。「〜のせいで失敗した」は NG。

STAR 例（Q8 詳細）:

• S: 「前職で、大手保険会社向けの AI チャットボット導入プロジェクトを担当しました。6ヶ月のプロジェクトで、予算は8,000万円でした」
• T: 「技術リードとして、チャットボットの設計・実装・導入を統括する立場でした」
• A: 「私は技術的な完成度を追求するあまり、顧客との週次ミーティングを月次に減らしてしまいました。その結果、3ヶ月目に顧客が "この方向性は違う" と声を上げた時には、すでに全体の60%を実装済みでした。私は即座にプロジェクトを2週間止め、顧客の現場で保険査定員5名にインタビューし、要件を再定義しました。実装済みの40%を捨てる判断をし、CTO に報告しました」
• R: 「プロジェクトは2ヶ月遅延し、追加コスト1,200万円が発生しました。しかし、再設計後のチャットボットは顧客満足度92%を達成しました。この経験から、私は "週次デモ" を自分のルールにしました。以降の全プロジェクトで毎週顧客に進捗をデモし、方向性のズレを早期に検出する仕組みを作りました」

9.「予想外の障害が起きた時の対応を教えてください」

フレームワーク: 初動の速さ、エスカレーション判断、コミュニケーション、恒久対策の4段階で語る。

FDE 特有系

10.「なぜ FDE になりたいのですか（SWE ではなく）」

フレームワーク: 「コードを書くだけでは物足りない」「顧客の課題を直接解決したい」「技術とビジネスの交差点で働きたい」など、FDE ならではの動機を語る。

11.「顧客の成功のために自分の担当範囲を超えた経験は」

フレームワーク: 「それは私の仕事ではない」と言わなかったエピソード。FDE は "自分の範囲" を自分で定義する仕事だ。

12.「曖昧な状況で方向性を決めた経験は」

フレームワーク: 限られた情報で仮説を立て、小さく検証し、方向を修正したプロセスを語る。

自己管理系

13.「複数の優先度の高いタスクをどう管理しますか」

フレームワーク: 優先順位付けのフレームワーク（緊急度×影響度マトリクス等）と、具体的なツール・習慣を語る。

14.「技術的に深い問題を非技術者にどう説明しましたか」

フレームワーク: アナロジーの活用、ビジュアル化、段階的な説明。シミュレーション2と共通するスキル。

15.「データに基づいて意思決定を変えた経験は」

フレームワーク: 最初の仮説を語り、データが示した事実を語り、仮説をどう修正したかを語る。「データに従う柔軟性」を示す。

面接全体の準備タイムライン — 8週間プラン

カイがホワイトボードに8週間のタイムラインを描いた。

「面接準備は短距離走じゃない。8週間のマラソンだ。各週にフォーカスエリアを設定する」

# 面接準備の進捗管理ツール
class InterviewPrepTracker
  PHASES = {
    research: { weeks: 1..2, weight: 15 },
    coding: { weeks: 3..4, weight: 25 },
    system_design: { weeks: 5..6, weight: 25 },
    client_sim: { weeks: 7..7, weight: 20 },
    final_review: { weeks: 8..8, weight: 15 },
  }.freeze
 
  def initialize(start_date:)
    @start_date = start_date
    @progress = Hash.new { |h, k| h[k] = [] }
  end
 
  def log_activity(phase, description, duration_minutes:)
    @progress[phase] << {
      date: Date.current,
      description: description,
      duration: duration_minutes,
    }
  end
 
  def weekly_report(week_number)
    current_phase = PHASES.find { |_, v| v[:weeks].include?(week_number) }&.first
    phase_logs = @progress[current_phase] || []
 
    total_hours = phase_logs.sum { |l| l[:duration] } / 60.0
    target_hours = current_phase == :client_sim ? 15 : 20
 
    {
      week: week_number,
      phase: current_phase,
      total_hours: total_hours.round(1),
      target_hours: target_hours,
      on_track: total_hours >= target_hours * 0.8,
      activities: phase_logs.map { |l| l[:description] },
    }
  end
 
  def readiness_score
    PHASES.sum do |phase, config|
      phase_logs = @progress[phase]
      completion = [phase_logs.size.to_f / 10, 1.0].min
      (completion * config[:weight]).round(1)
    end
  end
end

企業別の面接プロセス全体像

ソウタはノートPCを開き、主要企業の FDE 面接プロセスを一覧にまとめた。

「企業ごとにプロセスが違う。志望企業に合わせた準備が必要だ」

企業別の対策ポイント

Google FDE を受ける場合:

# Google の Googleyness 質問に備えるフレームワーク
class GoogleynessPrep
  DIMENSIONS = [
    { name: "曖昧さへの快適さ", question: "不完全な情報で判断した経験は？" },
    { name: "協働力", question: "意見の異なるチームメンバーとどう協力した？" },
    { name: "ユーザー第一", question: "ユーザーのために困難な決断をした経験は？" },
    { name: "当事者意識", question: "担当範囲外の問題に取り組んだ経験は？" },
  ].freeze
 
  def self.practice_questions
    DIMENSIONS.map do |dim|
      {
        dimension: dim[:name],
        question: dim[:question],
        tip: "30秒で状況説明、2分で行動、30秒で結果。合計3分以内",
      }
    end
  end
end

Palantir FDSE を受ける場合:

分解ラウンドが最も独特だ。「日本全国のコンビニの年間売上を推定せよ」のようなフェルミ推定に近いが、より実践的で、最終的にソフトウェアソリューションの設計に着地させる必要がある。第33章の分解演習を重点的に練習すること。

クロージング — ユウキの覚悟

全てのシミュレーションと行動面接の練習を終えた頃、会議室の時計は22時を指していた。

ユウキはノートを閉じ、深く息を吐いた。

「ソウタさん、カイさん。今日一日で、FDE の面接がどれだけ多面的かを実感しました。コードが書けるだけじゃダメ。システムが設計できるだけでもダメ。顧客の前に立って、感情に寄り添いながら、技術で問題を解決する。全部が求められる」

カイがうなずいた。「そうだ。そして、その全部を45分の面接で証明しなければならない。だから準備がすべてだ」

ソウタは窓の外を見た。自分が Arclight AI の面接を受けた日のことを思い出していた。あの時、クライアントシミュレーションで「契約解除を検討している顧客」のシナリオが出た。汗だくになりながら対応した記憶がある。

「ユウキ、ひとつ言っておきたいことがある」

ソウタはユウキの目を見た。

「今日のシミュレーションで、お前が最初に出した "NG 回答" ——あれは、かつての俺だ」

ユウキが驚いた表情を見せた。

「俺も最初は、顧客の不満に対して "うちのテスト環境では問題ないんですが" と返していた。競合の話が出たら "あそこの製品はダメですよ" と言っていた。FDE になる前の俺は、技術的に正しいことが最も重要だと信じていた」

ソウタは続けた。

「でも、カイさんに教わった。技術的に正しいことと、顧客にとって正しいことは、必ずしも同じじゃない。FDE は、その2つを橋渡しする存在だ」

カイが口を開いた。

「ソウタ、お前がユウキを指導する姿を見ていて思ったことがある。教えることで、お前自身が成長している。ユウキの素朴な質問に答えるために、お前は自分の経験を言語化し、構造化し、再現可能なフレームワークに落とし込んだ。それは FDE としてのお前の価値を確実に上げている」

ソウタは少し照れた。「確かに、ユウキに教えるために整理した内容が、実際の顧客対応でも役に立っています」

カイは立ち上がり、二人の肩に手を置いた。

「ユウキ、最後にひとつだけアドバイスだ。面接当日、緊張して頭が真っ白になることがある。その時は、今日のこの部屋を思い出せ。ソウタと俺が顧客役をやって、お前がたじたじになりながらも最後まで対応しきったこの経験を。模擬面接で経験したことは、本番で必ず活きる」

ユウキは立ち上がり、深く頭を下げた。

「ありがとうございます。8週間、全力で準備します」

会議室を出る時、ユウキの足取りは来た時とは別人のように力強かった。

ソウタはカイと二人、散らかったホワイトボードを片付けながら言った。

「カイさん、俺がユウキくらいの時、カイさんも同じことをしてくれましたよね」

カイは笑った。

「FDE の知識は、顧客に渡して初めて価値になる。同じように、FDE の経験は、次の世代に渡して初めて意味を持つ。お前はもう、教える側の人間だよ、ソウタ」

深夜のオフィスに、3つの空になったコーヒーカップが残されていた。