パランティア FDE（Forward Deployed Engineer）完全分析：役割、必須スキル、顧客対応戦略

例: 製造会社のオントロジー

Object Types:
  - Factory（工場）: 所在地、生産能力、稼働率
  - Production Line（生産ライン）: 製品タイプ、速度、不良率
  - Product（製品）: SKU、原価、品質等級
  - Supplier（サプライヤー）: リードタイム、信頼度

Links:
  - Factory --has--> Production Line
  - Production Line --produces--> Product
  - Product --supplied-by--> Supplier

07:30 - 出勤前にメール/Slackチェック
        - 顧客の夜間イシュー確認、緊急事項のトリアージ

08:30 - 顧客サイト到着
        - 顧客ITチームとスタンドアップ（15分）
        - 昨日デプロイしたパイプラインの監視結果を共有

09:00 - データパイプライン開発
        - PySpark Transformコード作成
        - 新データソース（SAP）との連携作業

11:00 - ビジネスユーザーワークショップ
        - サプライチェーン担当者とダッシュボード要件を議論
        - オントロジーオブジェクトタイプの追加必要性を確認

12:00 - ランチ（顧客チームと一緒に）
        - 非公式な関係構築、隠れたニーズの把握

13:30 - Workshopアプリ開発
        - React/TypeScriptベースのUI構築
        - オントロジーAction接続

15:00 - パランティア内部シンク
        - 本社プロダクトチームと機能リクエスト議論
        - 他のFDEと類似ケース共有

16:00 - デモ準備
        - 今週の成果を経営陣に見せるデモシナリオ構成

17:00 - 経営陣デモ
        - VP級にパイプライン自動化による時間削減を実演
        - 次四半期の拡大提案

18:30 - 日次レビューとドキュメント化
        - 今日の進捗、ブロッカー、明日の計画を記録

-- 時間ベースの累積売上計算
SELECT
  order_date,
  customer_id,
  amount,
  SUM(amount) OVER (
    PARTITION BY customer_id
    ORDER BY order_date
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS cumulative_revenue,
  LAG(amount, 1) OVER (
    PARTITION BY customer_id
    ORDER BY order_date
  ) AS prev_order_amount,
  RANK() OVER (
    PARTITION BY EXTRACT(MONTH FROM order_date)
    ORDER BY amount DESC
  ) AS monthly_rank
FROM orders;

-- 組織図階層構造の探索（Recursive CTE）
WITH RECURSIVE org_hierarchy AS (
  -- Base case: 最上位管理者
  SELECT
    employee_id,
    name,
    manager_id,
    1 AS depth,
    CAST(name AS VARCHAR(1000)) AS path
  FROM employees
  WHERE manager_id IS NULL

  UNION ALL

  -- Recursive case: 部下
  SELECT
    e.employee_id,
    e.name,
    e.manager_id,
    oh.depth + 1,
    CAST(oh.path || ' > ' || e.name AS VARCHAR(1000))
  FROM employees e
  INNER JOIN org_hierarchy oh ON e.manager_id = oh.employee_id
)
SELECT * FROM org_hierarchy ORDER BY depth, name;

# Foundry Transformsで使用されるPySparkパターン
from transforms.api import transform, Input, Output
from pyspark.sql import functions as F
from pyspark.sql.window import Window

@transform(
    output=Output("/datasets/clean/daily_metrics"),
    raw_orders=Input("/datasets/raw/orders"),
    raw_products=Input("/datasets/raw/products"),
)
def compute(output, raw_orders, raw_products):
    orders_df = raw_orders.dataframe()
    products_df = raw_products.dataframe()

    # データクレンジング + 結合 + 集計
    result = (
        orders_df
        .filter(F.col("status") == "completed")
        .join(products_df, on="product_id", how="inner")
        .groupBy(F.date_trunc("day", F.col("order_timestamp")).alias("order_date"))
        .agg(
            F.count("order_id").alias("total_orders"),
            F.sum("revenue").alias("total_revenue"),
            F.countDistinct("customer_id").alias("unique_customers"),
            F.avg("revenue").alias("avg_order_value"),
        )
        .withColumn(
            "revenue_7d_avg",
            F.avg("total_revenue").over(
                Window.orderBy("order_date").rowsBetween(-6, 0)
            )
        )
        .orderBy("order_date")
    )

    output.write_dataframe(result)

ETL vs ELT 比較:

ETL（Extract-Transform-Load）:
  ソース --Extract--> ステージング --Transform--> クリーン --Load--> DWH
  長所: 変換後にロードし、ストレージ効率的
  短所: 変換ロジック変更時に再処理が必要

ELT（Extract-Load-Transform）:
  ソース --Extract--> データレイク --Load--> 原本保存 --Transform--> ビュー/テーブル
  長所: 原本保存、柔軟な再加工
  短所: ストレージコスト増加

Foundryアプローチ（ELT推奨）:
  ソース --> Data Connection --> Rawデータセット --> Transforms --> Cleanデータセット --> Ontology

Star Schema vs Ontology 比較:

Star Schema（伝統的）:
          dim_customer
              |
  dim_product -- fact_orders -- dim_date
              |
          dim_store

Ontology（Foundry）:
  Customer --places--> Order --contains--> Product
      |                   |
      +--located-in-->  Store <--shipped-from-- Warehouse

主な違い:
- Star Schema: 分析中心、静的構造
- Ontology: 運用中心、動的関係、Action実行可能
- OntologyのObjectにはPropertyだけでなくActionも定義可能

// Foundry Workshopウィジェットパターン例
interface SupplyChainDashboardProps {
  factoryId: string;
  dateRange: DateRange;
  onAlertDismiss: (alertId: string) => void;
}

interface FactoryMetrics {
  utilization: number;
  defectRate: number;
  throughput: number;
  alerts: Alert[];
}

const SupplyChainDashboard: React.FC<SupplyChainDashboardProps> = ({
  factoryId,
  dateRange,
  onAlertDismiss,
}) => {
  const [metrics, setMetrics] = useState<FactoryMetrics | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    async function fetchMetrics() {
      setLoading(true);
      try {
        const factory = await OntologyClient.getObject("Factory", factoryId);
        const lines = await factory.getLinkedObjects("hasProductionLine");
        const calculated = computeMetrics(lines, dateRange);
        setMetrics(calculated);
      } catch (error) {
        console.error("Failed to fetch metrics:", error);
      } finally {
        setLoading(false);
      }
    }
    fetchMetrics();
  }, [factoryId, dateRange]);

  if (loading) return <Spinner />;
  if (!metrics) return <ErrorState message="データを読み込めません" />;

  return (
    <DashboardLayout>
      <MetricCard title="稼働率" value={metrics.utilization} unit="%" />
      <MetricCard title="不良率" value={metrics.defectRate} unit="%" />
      <MetricCard title="スループット" value={metrics.throughput} unit="units/hr" />
      <AlertList alerts={metrics.alerts} onDismiss={onAlertDismiss} />
    </DashboardLayout>
  );
};

# FoundryでのOntology Action定義例
from ontology_sdk import action, OntologyObject

@action(
    name="create_maintenance_order",
    description="設備メンテナンス作業指示書の作成",
    parameters={
        "equipment_id": "string",
        "priority": "enum(HIGH, MEDIUM, LOW)",
        "description": "string",
        "scheduled_date": "datetime",
    },
)
def create_maintenance_order(params, context):
    equipment = context.ontology.get("Equipment", params["equipment_id"])

    if equipment.status == "DECOMMISSIONED":
        raise ValueError("廃棄済み設備にはメンテナンス指示書を作成できません")

    order = context.ontology.create("MaintenanceOrder", {
        "equipment": equipment,
        "priority": params["priority"],
        "description": params["description"],
        "scheduled_date": params["scheduled_date"],
        "status": "PENDING",
        "created_by": context.current_user,
    })

    assignee = find_available_technician(
        equipment.location,
        params["priority"],
        params["scheduled_date"],
    )
    order.assign_to(assignee)
    notify_stakeholders(order, assignee)

    return order

# AIPでのLLM + Ontology連携パターン
def aip_supply_chain_assistant(user_query, context):
    """
    自然言語クエリをOntology検索に変換
    """
    # 1. インテント分類
    intent = classify_intent(user_query)
    # 例: 「先週不良率が最も高かった工場は？」

    # 2. Ontologyクエリ生成
    if intent == "factory_defect_analysis":
        factories = context.ontology.search(
            "Factory",
            filters=[
                ("metrics.defect_rate", ">", 0),
                ("metrics.date", ">=", last_week_start),
            ],
            order_by="metrics.defect_rate DESC",
            limit=5,
        )

        # 3. LLMで自然言語応答を生成
        response = generate_response(
            template="factory_analysis",
            data=factories,
            user_query=user_query,
        )
        return response

    # 4. Action実行が必要な場合
    if intent == "create_action":
        action_plan = plan_action(user_query, context)
        return request_confirmation(action_plan)

顧客シナリオ: グローバル製造業のリアルタイム品質管理システム

データソース（世界20工場）:
  IoTセンサー --> Kafka --> Foundry Streaming
  MESシステム --> API Connector --> Foundry Batch
  SAP --> Magritte Sync --> Foundry Batch

処理レイヤー:
  Rawレイヤー:         原本データ（保存）
  Cleanレイヤー:       クレンジング/標準化（Transforms）
  Semanticレイヤー:    Ontologyマッピング
  Applicationレイヤー: Workshopアプリ、ダッシュボード

スケール:
  - 日次データ:     約50TB
  - リアルタイムイベント: 約100K events/sec
  - Ontologyオブジェクト: 約500Mオブジェクト
  - 同時ユーザー:   約5,000名

バッチ処理（Transforms）:
  実行周期: 毎時または毎日
  適するケース: 日次レポート、週次分析、過去データ再処理
  技術: PySpark、SQL Transforms

ストリーム処理（Foundry Streaming）:
  実行周期: リアルタイム（秒単位）
  適するケース: 異常検知、リアルタイムアラート、ライブダッシュボード
  技術: Kafka、Spark Streaming

Lambda Architecture（パランティアパターン）:
  バッチレイヤー: 正確な過去分析（遅延許容）
  スピードレイヤー: リアルタイム近似値（精度を少し犠牲）
  サービングレイヤー: バッチ + リアルタイム結果統合

Foundryのデータガバナンス要点:

1. アクセス制御（RBAC + ABAC）:
   - Organization --> Project --> Dataset --> Column レベル
   - Markingベースのアクセス制御（PII、Confidentialなど）

2. データリネージ:
   - すべてのTransformの入出力を自動追跡
   - データソースから最終消費まで追跡可能

3. 監査ログ:
   - 誰が、いつ、どのデータにアクセスしたかを記録
   - 規制準拠の証拠（GDPR、HIPAA）

4. データ品質:
   - Health Check: 自動品質モニタリング
   - Expectation: データルールの定義と検証

5日間ドメイン没入フレームワーク:

Day 1: 全体像の把握
  - 業界概要レポートを読む（McKinsey、Gartner）
  - 顧客企業の10-Kレポート分析
  - キーワード50個を整理

Day 2: プロセスマッピング
  - 顧客のコアビジネスプロセス3-5個を理解
  - As-Isプロセスダイアグラムを描く
  - ペインポイント仮説を立てる

Day 3: データランドスケープ
  - 使用中のシステム一覧（ERP、CRM、MESなど）
  - データフローダイアグラム
  - データ品質課題の把握

Day 4: ステークホルダーインタビュー
  - Cレベル: 戦略目標
  - 中間管理職: 運用課題
  - 現場担当者: 日常の困りごと

Day 5: 価値仮説の立案
  - Quick Win 3つを特定
  - 中期プロジェクト2-3個のロードマップ
  - ROI推定（時間削減、コスト削減、売上増加）

悪い例:
  顧客: 「データがリアルタイムで入ってきません」
  FDE: 「Kafkaコネクタの設定を確認します」（すぐ技術解決に飛ぶ）

良い例:
  顧客: 「データがリアルタイムで入ってきません」
  FDE: 「そのデータがリアルタイムで必要な理由は何ですか？
        どのような意思決定に影響しますか？」
  顧客: 「工場のラインで不良が発生したら30分以内に停止する必要が
        あるのですが、今は翌日にならないとわかりません」
  FDE: 「品質異常検知が核心のニーズですね。30分以内の
        アラートには、どのセンサーデータが最も重要ですか？」

積極的傾聴テクニック:

1. 反映（はんえい）:
   顧客: 「このレポート作成に毎週8時間かかっています」
   FDE: 「毎週8時間をレポート作成に費やされているのですね」

2. 明確化（めいかくか）:
   「8時間の中で最も時間がかかる部分はどこですか？」

3. 要約（ようやく）:
   「まとめると、データ収集に3時間、クレンジングに2時間、
    可視化に3時間ということですね」

4. 感情認識（かんじょうにんしき）:
   「その作業はかなり大変でしたでしょう」

オープンクエスチョン（探索段階）:
  「現在最大のデータ関連の課題は何ですか？」
  「理想的な状態はどのような姿ですか？」
  「このプロセスで最も不満な部分は何ですか？」

クローズドクエスチョン（確認段階）:
  「このダッシュボードに日次トレンドチャートが必要ですか？」
  「データ更新周期は1時間で十分ですか？」
  「承認権限はチームリーダーレベルまでで良いですか？」

5 Whyテクニック（根本原因探索）:
  1. 「なぜレポートの完成が遅れるのですか？」
     --> 「データ収集に時間がかかるからです」
  2. 「なぜデータ収集に時間がかかるのですか？」
     --> 「5つのシステムから手動で抽出する必要があるからです」
  3. 「なぜ手動なのですか？」
     --> 「システム同士が連携していないからです」
  4. 「なぜ連携していないのですか？」
     --> 「各部署が独立してシステムを導入したからです」
  5. 「なぜ独立して導入したのですか？」
     --> 「中央データ戦略がなかったからです」
  根本原因: データガバナンスの欠如 --> Foundry導入の核心的価値提案

実践方法:
  - 顧客が話している間は絶対に遮らない
  - メモを取りながら重要ポイントを記録
  - 非言語的サインで傾聴していることを示す（うなずき、アイコンタクト）
  - 話が終わったら要点を繰り返し、正確に理解したか確認

例:
  顧客: 「先週デプロイしたダッシュボードが毎朝壊れています。
        私たちのVPが毎朝このダッシュボードを見るのですが、
        毎回ITに電話して作り直してもらわないといけません。
        本当に信頼できません。」

  FDE: 「毎朝ダッシュボードが正常に表示されず、
       VPに見せる前に毎回ITチームに依頼されていたのですね。
       その状況が繰り返されることで信頼に影響が出たということですね？」

共感表現テンプレート:
  - 「その状況がどれほどご不便だったか、十分に理解しております」
  - 「毎朝そのようなことが繰り返されると、大変なストレスでしたでしょう」
  - 「VPの前で毎回そのような状況が生じると、お困りだったと思います」

注意: 共感は同意ではありません
  - 良い: 「その状況がご不便だったことを理解しています」
  - 悪い: 「はい、弊社のシステムは本当にひどいですね」（過度な自己卑下）

真摯な謝罪の原則:
  - 言い訳をしない
  - 何に対して謝罪しているかを具体的に明示
  - 責任を認める

良い謝罪:
  「ダッシュボードの安定性問題で毎日ご不便をおかけし、
   心よりお詫び申し上げます。デプロイ前により十分な
   テストを行うべきでした。」

悪い謝罪:
  「申し訳ございませんが、元のデータソース側に問題があって...」
  （言い訳を含む謝罪は謝罪ではありません）

解決策提示テンプレート:

即時対応（24時間以内）:
  「本日中にダッシュボードのリフレッシュスケジュールのエラーを
   修正します。明朝7時前に正常動作を確認し、結果をご報告します。」

短期改善（1週間以内）:
  「今週中にダッシュボードに自動ヘルスチェックを追加し、
   問題発生時に自動復旧するようにします。」

長期防止（1ヶ月以内）:
  「すべてのダッシュボードに対してデプロイ前の自動テスト
   パイプラインを構築し、再発を防止します。」

核心: 具体的なタイムラインと担当者を明示すること

根本原因分析後の報告:

RCA（Root Cause Analysis）レポート構造:
  1. インシデント概要: 何が発生したか
  2. タイムライン: いつ始まり、いつ解決したか
  3. 影響範囲: 誰が、どの程度影響を受けたか
  4. 根本原因: なぜ発生したか
  5. 即時対応: どのように解決したか
  6. 再発防止: 今後どのように予防するか

例:
  根本原因: 夜間データパイプラインがUTC基準でスケジュールされており、
           JST午前8時にはまだ処理が完了していなかった。
  再発防止: スケジュールをJST午前4時完了に変更、
           完了通知の設定、モニタリングダッシュボードの追加。

L - Listen（傾聴）:
  顧客の話を最後まで聴きます。メモしながら重要キーワードを捉えます。

A - Acknowledge（認識（にんしき））:
  「おっしゃる問題を正確に理解しました。
   データのローディング速度が期待より遅いことが核心的な課題ですね。」

S - Solve（解決）:
  「2つの方法で解決できます。
   1つ目は、クエリ最適化で即座に2倍速くできます。
   2つ目は、キャッシングレイヤーの追加でさらに3倍の改善が可能です。」

T - Thank（感謝（かんしゃ））:
  「この問題をお知らせいただき、ありがとうございます。
   おかげで他のユーザーにもより良い体験を提供できるようになりました。」

Step 1: 安全な空間の確保
  - 可能であれば1対1の環境に移動
  - 公の場での恥をかかせない
  - ビデオ会議なら参加者を最小限に

Step 2: 傾聴と感情の認知
  - 「お怒りになるのは当然のことです」
  - 絶対に防御的に反応しない
  - 「ですが」「しかし」の使用を避ける

Step 3: 事実確認
  - 感情が落ち着いたら具体的な事実を確認
  - 「正確に理解したいのですが、何が起きたか順番に
    お教えいただけますか？」

Step 4: 即座に可能な対応を提示
  - 小さくてもすぐできることを提示
  - 「今すぐできることはAです。Bは明日までに可能です。」

Step 5: フォローアップ管理
  - 約束した時間より前にアップデート
  - 解決後も1週間後に確認連絡

予防戦略:
  1. プロジェクト開始時に明確なSOW（Statement of Work）に合意
  2. MoSCoW優先順位: Must/Should/Could/Won't
  3. 変更リクエストプロセスを定義

対応話法:
  悪い例: 「それはスコープ外です」（拒否感を与える）

  良い例: 「素晴らしいアイデアですね！現在Phase 1の核心目標が
           [X]ですので、おっしゃる機能はPhase 2で実装すると
           より効果的に反映できると思います。
           Phase 1をまず成功裏に完了した後に
           優先順位に反映するのはいかがでしょうか？」

核心: 「No」ではなく「Yes, but later/differently」

建設的な「No」の伝え方:

状況: 顧客がリアルタイム（1秒未満）分析を要求しているが、
      データ量が多すぎて技術的に不可能

悪い例:
  「不可能です。データが多すぎてリアルタイム処理ができません。」

良い例:
  「リアルタイム分析の必要性を理解しております。現在のデータ量
   （日50TB）では1秒未満の応答に技術的な制約がありますが、
   2つの代替案をご提案します。

   代替案1: 最も重要なKPI 5つについてのみリアルタイム処理
           --> 1秒未満の応答が可能
   代替案2: 全データを5分周期で事前集計
           --> すべてのKPIを3秒以内に提供

   どちらの方向がビジネスにより役立ちますか？」

原則: 不可能の代わりに代替案を、技術用語の代わりにビジネス影響を

状況: 顧客が3週間アーキテクチャの決定を先延ばしにしている

ナッジング戦略:

1. 期限設定:
   「来週木曜日までに決定いただければ、Q2内にPhase 1の完了が可能です」

2. コストフレーミング:
   「決定が1週間遅れるごとに、約X分の運用コストが追加されます」

3. 選択肢の単純化:
   「10個のオプションを検討されましたが、御社の状況に最も適した
    2つに絞りました。AとBの違いは...」

4. パイロット提案:
   「全体を一度に決めるのではなく、まずA方式で2週間パイロットを
    実施し、結果を見てから判断されるのはいかがでしょうか？」

5. 社会的証拠:
   「同規模のX社がA方式を選択し、3ヶ月でROI 300%を達成しました」

状況: IT部長はセキュリティを優先、ビジネス部長はスピードを要求

ファシリテーション技法:

1. 共通目標の確認:
   「お二人とも顧客満足度の向上という同じ目標をお持ちですよね？」

2. 各立場の可視化:
   ホワイトボードに両方の要件と懸念事項を並べて整理

3. トレードオフの明示:
   「セキュリティを最優先にするとリリースが2週間遅れます。
    スピードを最優先にするとセキュリティレビューが不完全になります。
    中間案として、コアセキュリティのみ1週間以内に適用するのは
    いかがでしょうか？」

4. 意思決定者の明確化:
   「最終決定権者はどなたですか？
    その方の判断基準は何ですか？」

5. 書面での合意:
   決定事項を文書化し、すべての関係者の確認を得る

RACIマトリックス例: Foundry導入プロジェクト

                    | 要件定義 | データ連携 | テスト | Go-Live |
--------------------|---------|-----------|--------|---------|
プロジェクトスポンサー(VP)|   A    |     I     |   I    |    A    |
ITディレクター        |   C    |     A     |   A    |    R    |
ビジネスマネージャー   |   R    |     C     |   R    |    C    |
FDE（パランティア）    |   C    |     R     |   R    |    R    |
データエンジニア       |   I    |     R     |   C    |    C    |

R = Responsible（実行）、A = Accountable（最終責任）
C = Consulted（助言）、I = Informed（報告）

高い影響力 + 高い関心:  積極的管理（Key Players）
  --> CIO、VP of Operations
  戦略: 週1回定期報告、意思決定に参加

高い影響力 + 低い関心:  満足維持（Keep Satisfied）
  --> CEO、CFO
  戦略: 月1回サマリー報告、重要な意思決定時のみ参加

低い影響力 + 高い関心:  情報提供（Keep Informed）
  --> 現場アナリスト、データエンジニア
  戦略: 週次ニュースレター、Slackチャネルアップデート

低い影響力 + 低い関心:  モニタリング（Monitor）
  --> 一般ユーザー
  戦略: 四半期アップデート、必要時のみコミュニケーション

Championとは:
  顧客組織内でパランティア/Foundryの価値を積極的に広める内部推進者

Champion識別の特徴:
  - ミーティングで積極的に質問し、アイデアを提案
  - 同僚にFoundryの利用を推薦
  - 自発的にフィードバックを提供
  - 成功事例を経営陣に共有

Champion育成戦略:
  1. 早期接触: プロジェクト初期から関係構築
  2. 独占情報: 新機能、ロードマップを先に共有
  3. 能力強化: 深化トレーニングを提供
  4. 認知: 彼らの貢献を公式に認める
  5. ネットワーク: 他の顧客企業のChampionと繋げる

Executive Sponsor管理の原則:

1. 彼らの時間は金:
   - ミーティングは30分以内
   - 核心3つだけ伝達
   - ビジュアル資料（チャート、ダッシュボード）を活用

2. ビジネス言語でコミュニケーション:
   - 悪い例: 「Sparkクラスタ最適化でクエリ性能が40%向上」
   - 良い例: 「レポート生成時間が2時間から20分に短縮され、
              チームが週15時間を分析に充てられるようになりました」

3. リスクは早期報告:
   - 悪いニュースほど早く伝える
   - 問題だけでなく解決策と一緒に報告

4. 成果の可視化:
   - 月次ROIダッシュボード
   - Before/After比較データ
   - ユーザー満足度調査結果

週次アップデートメール構造:

件名: [プロジェクト名] 週次アップデート - W12 (3/17-3/21)

1. サマリー（3行以内）:
   今週サプライチェーンダッシュボードv2をデプロイ完了。
   ユーザーフィードバックを反映しフィルタリング機能を追加。
   来週在庫予測モデルのパイロット開始予定。

2. 今週の完了事項:
   - サプライチェーンダッシュボードv2 本番デプロイ（完了）
   - ユーザー5名向けトレーニング実施（完了）
   - SAPデータ連携テスト（完了）

3. 来週の計画:
   - 在庫予測モデルパイロット（3/24-3/28）
   - 経営陣デモ準備（3/28）

4. リスク/ブロッカー:
   - SAPサーバーアクセス権限待ち（IT チーム承認が必要）
   - 予想解決日: 3/25

5. 指標:
   - ダッシュボード日次ユーザー数: 45名（先週比+12）
   - レポート生成時間: 20分（従来2時間比 -83%）

Slackエチケットガイド:

DO:
  - スレッドを積極的に活用（チャネルを整理）
  - 緊急度を明示（緊急/通常/参考）
  - 質問には期待レスポンス時間を明示
  - 解決済みイシューは結果を共有

DON'T:
  - 業務時間外のメンション（緊急でない限り）
  - 同じメッセージを複数チャネルに重複投稿
  - 長い議論をDMで行う（他のチームメンバーも参考に）
  - 「お疲れ様です」だけ送って待つ（質問を即座に伝達）

チャネル構造推奨:
  palantir-general:    一般コミュニケーション
  palantir-technical:  技術議論
  palantir-urgent:     緊急イシュー（通知ON）
  palantir-demos:      デモ/プレゼンテーション日程

効果的なミーティングテンプレート:

ミーティング前:
  - 24時間前にアジェンダを共有
  - 参加者別の準備事項を明示
  - ミーティング目的を1行で要約

ミーティング中:
  - タイムキーパーを指名
  - ノートテイカーを指名
  - 各アジェンダに時間を配分
  - 結論の出ない議論は別ミーティングに分離

ミーティング後（24時間以内）:
  - 議事録を共有
  - アクションアイテム: 担当者 + 期限を明示
  - 次回ミーティング日程を確認

FDEデモ構成（15分基準）:

1分: Hook（関心を引く）
  「前四半期、在庫不足による売上損失が2億円でした。
   今日お見せするソリューションでこれを80%削減できます。」

3分: Context（コンテキスト）
  「現在の在庫管理プロセスの問題点3つを先にご説明します」
  （顧客の苦痛を可視化）

8分: Live Demo（ライブ実演）
  - 必ず実データで実演（ダミーデータは使わない）
  - 顧客の日常シナリオでフローを構成
  - 「もしA状況が発生したら...」シナリオベース

2分: Impact（影響）
  「このダッシュボードにより在庫不足の予測が3日前に前倒しされ、
   年間推定削減効果は1.6億円です」

1分: Next Steps（次のステップ）
  具体的なアクションアイテムとスケジュールを提示

パランティアFDE面接プロセス:

Stage 1: Online Assessment（1-2時間）
  - HackerRankスタイルのコーディングテスト
  - SQL + Python/Java問題 2-3問
  - アルゴリズムよりデータ処理重視

Stage 2: Phone Screen（45-60分）
  - 技術面接: SQLリアルタイム問題解決
  - またはシステム設計の簡単な議論
  - 「Why Palantir?」の質問はほぼ確実

Stage 3: Onsite（3-5ラウンド、1日）

  Round 1: Coding（60分）
    - PythonまたはJavaでデータ処理問題
    - 実際のビジネスシナリオベース
    - 例: 「物流最適化アルゴリズムの実装」

  Round 2: SQL Deep Dive（60分）
    - 複雑なクエリ作成（Window Functions、CTEs）
    - パフォーマンス最適化の議論
    - データモデリング設計

  Round 3: System Design（60分）
    - データパイプラインアーキテクチャ
    - スケーラビリティ、フォールトトレランスの議論
    - Foundryアーキテクチャの理解度評価

  Round 4: Case Study（60分）
    - 顧客シナリオベースの課題解決
    - 「製造会社が不良率を下げたい」
    - 技術 + ビジネス + コミュニケーションの総合評価

  Round 5: Behavioral（45分）
    - STAR方式の回答
    - 顧客経験、コンフリクト解決、リーダーシップ
    - パランティアのバリューとのフィット確認

# よく出題されるパターン: データ処理 + ビジネスロジック

# 問題: サプライチェーン遅延分析
# 注文データから遅延が最も深刻なサプライヤーTop 5と
# 遅延原因別パターンを分析せよ

import pandas as pd
from collections import defaultdict

def analyze_supply_chain_delays(orders_df):
    """
    サプライチェーン遅延分析関数

    Parameters:
    - orders_df: DataFrame with columns
      [order_id, supplier_id, expected_date, actual_date,
       product_category, quantity, region]
    """
    # 1. 遅延日数の計算
    orders_df["delay_days"] = (
        pd.to_datetime(orders_df["actual_date"])
        - pd.to_datetime(orders_df["expected_date"])
    ).dt.days

    # 2. 遅延注文のみフィルタリング
    delayed = orders_df[orders_df["delay_days"] > 0].copy()

    # 3. サプライヤー別遅延統計
    supplier_stats = (
        delayed.groupby("supplier_id")
        .agg(
            total_delayed_orders=("order_id", "count"),
            avg_delay_days=("delay_days", "mean"),
            max_delay_days=("delay_days", "max"),
            total_affected_quantity=("quantity", "sum"),
        )
        .sort_values("avg_delay_days", ascending=False)
        .head(5)
    )

    # 4. カテゴリ-地域別遅延パターン
    pattern_analysis = (
        delayed.groupby(["product_category", "region"])
        .agg(
            delay_count=("order_id", "count"),
            avg_delay=("delay_days", "mean"),
        )
        .sort_values("delay_count", ascending=False)
    )

    # 5. 時系列遅延トレンド
    delayed["month"] = pd.to_datetime(delayed["actual_date"]).dt.to_period("M")
    trend = (
        delayed.groupby("month")
        .agg(
            monthly_delays=("order_id", "count"),
            avg_monthly_delay=("delay_days", "mean"),
        )
    )

    return {
        "top_5_delayed_suppliers": supplier_stats,
        "delay_patterns": pattern_analysis,
        "monthly_trend": trend,
    }

-- 問題: 顧客セグメンテーション
-- 過去90日の購買パターンに基づき顧客をRFMセグメントに分類せよ

WITH customer_rfm AS (
  SELECT
    customer_id,
    DATEDIFF(day, MAX(order_date), CURRENT_DATE) AS recency,
    COUNT(DISTINCT order_id) AS frequency,
    SUM(total_amount) AS monetary
  FROM orders
  WHERE order_date >= DATEADD(day, -90, CURRENT_DATE)
  GROUP BY customer_id
),
rfm_scores AS (
  SELECT
    customer_id,
    recency,
    frequency,
    monetary,
    NTILE(5) OVER (ORDER BY recency ASC) AS r_score,
    NTILE(5) OVER (ORDER BY frequency DESC) AS f_score,
    NTILE(5) OVER (ORDER BY monetary DESC) AS m_score
  FROM customer_rfm
)
SELECT
  customer_id,
  r_score,
  f_score,
  m_score,
  CASE
    WHEN r_score >= 4 AND f_score >= 4 AND m_score >= 4 THEN 'Champions'
    WHEN r_score >= 3 AND f_score >= 3 THEN 'Loyal Customers'
    WHEN r_score >= 4 AND f_score <= 2 THEN 'New Customers'
    WHEN r_score <= 2 AND f_score >= 3 THEN 'At Risk'
    WHEN r_score <= 2 AND f_score <= 2 THEN 'Lost'
    ELSE 'Others'
  END AS segment
FROM rfm_scores
ORDER BY monetary DESC;

ケーススタディ回答フレームワーク（BRIDGE）:

B - Business Understanding（ビジネス理解）
  「まず顧客のビジネスを理解させてください。
   KPIと現在の最大の課題は何ですか？」

R - Requirements Gathering（要件収集）
  「具体的なニーズを整理すると:
   1. 不良率を現在の3%から1%未満に
   2. 検知時間を24時間から30分に
   3. 意思決定の自動化」

I - Investigation（技術環境調査）
  「現在使用中のシステムは何で、
   どのようなデータを収集していますか？」

D - Design（ソリューション設計）
  「Foundryベースで以下のように設計します:
   Phase 1: データ統合（2週間）
   Phase 2: リアルタイムモニタリング（3週間）
   Phase 3: 予測モデル（4週間）」

G - Go-Live Plan（本番稼働計画）
  「パイロット工場1箇所で4週間運用し、
   成果検証後に全工場へ拡大」

E - Expansion（拡張）
  「初期成功後の拡張可能領域:
   サプライヤー品質管理、予知保全、需要予測」

STAR回答テンプレート:

質問: 「顧客が不満を表明した経験を教えてください」

S（Situation）:
  「前職でグローバル銀行のデータマイグレーションプロジェクトを
   担当していました。顧客のITディレクターがプロジェクトの遅延に
   ついて強い不満を示しました。」

T（Task）:
  「私の役割は遅延原因の特定、顧客信頼の回復、
   プロジェクトの正常軌道への復帰でした。」

A（Action）:
  「1. まず顧客の話を30分間傾聴し、核心的な懸念事項を整理
   2. 24時間以内にRCAレポートと修正計画を提出
   3. 日次進捗報告を導入し透明性を確保
   4. 追加リソースを投入し並行作業を推進」

R（Result）:
  「2週間で遅延分を取り戻し、元のスケジュール通りに完了しました。
   顧客満足度調査で5点満点中4.8点を獲得し、
   その後追加プロジェクト3件を受注しました。」

良い回答の構造:

1. ミッションとの接続:
   「パランティアのミッションである『世界で最も重要な機関を助ける』
   ことに深く共感しています。単にソフトウェアを作るのではなく、
   現実世界の課題を解決することに価値を置いています。」

2. FDE役割の魅力:
   「技術とビジネスの交差点で働くFDEの役割が
   私の強みと完全にマッチしています。コードだけ書くのではなく、
   顧客の課題を直接解決し、価値を自分の目で確認できます。」

3. 具体的な経験との接続:
   「[前職]での顧客と直接コミュニケーションしながら技術
   ソリューションを構築した経験が、FDEの核心的な
   コンピテンシーと一致しています。」

回答のポイント:

1. AI倫理の重要性を認識:
   「AIが意思決定にますます使われるようになり、
    公正性、透明性、説明責任が非常に重要です。」

2. パランティアのアプローチを理解:
   「パランティアはHuman-in-the-loop AIを
    推進していると理解しています。AIが提案し、
    最終決定は人間が行う構造です。」

3. 自分の立場:
   「技術の力が強いほど、責任ある使用が重要であり、
    FDEとして顧客がAIを倫理的に活用するよう
    ガイドする役割も果たすべきだと考えています。」

テーマ: SQL + Python + データエンジニアリング基礎

Week 1-2: SQLマスター
  - LeetCode SQL 50問
  - Window Functions集中学習
  - CTE、Recursive Queries練習
  - 毎日2-3問解く

Week 3-4: Pythonデータ処理
  - Pandas核心（merge、groupby、pivot、apply）
  - PySpark基礎（DataFrame API）
  - データクレンジングパターン（null処理、型変換、重複削除）

Week 5-6: ETL/ELTパイプライン
  - Apache Airflow基礎
  - データウェアハウス概念（Star Schema、Snowflake）
  - 簡単なETLプロジェクト構築

Week 7-8: データモデリング
  - 正規化 vs 非正規化
  - ディメンショナルモデリング（Kimball方法論）
  - Ontology思考の練習（オブジェクト-関係設計）

テーマ: React/TypeScript + API + システム設計

Week 9-10: React/TypeScript
  - React Hooks深化
  - TypeScript核心（インターフェース、ジェネリクス、ユーティリティ型）
  - ダッシュボードコンポーネント構築実習

Week 11-12: Backend API
  - REST API設計原則
  - Python FastAPIまたはJava Spring Boot
  - 認証/認可（OAuth、RBAC）

Week 13-14: システム設計
  - データパイプラインアーキテクチャ
  - リアルタイム vs バッチ処理
  - スケーラビリティパターン（パーティショニング、キャッシング、キュー）

Week 15-16: クラウド/インフラ
  - AWS/GCP基本サービス
  - Docker/Kubernetes基礎
  - CI/CDパイプライン

テーマ: コミュニケーション + ビジネス + パランティアプラットフォーム

Week 17-18: 顧客対応スキル
  - HEARD/LASTフレームワーク反復練習
  - De-escalationロールプレイ
  - Active Listeningトレーニング

Week 19-20: プレゼンテーション/デモ
  - ストーリーテリング構造の学習
  - 技術デモ練習（実データベース）
  - タイミング練習（15分、30分、60分）

Week 21-22: ドメイン知識
  - ターゲット業界1-2個を深化学習
  - 業界レポートを読む（McKinsey、Deloitte）
  - 該当業界のKPI、プロセス、規制を理解

Week 23-24: パランティアプラットフォーム学習
  - Foundry公式ドキュメントを精読
  - YouTube: Palantir Tech Talks
  - コミュニティフォーラムに参加

テーマ: 面接実戦準備

Week 25-26: コーディング面接練習
  - SQL: 毎日上級問題2問
  - Python: データ処理問題に集中
  - システム設計モック面接2-3回

Week 27-28: ケーススタディ練習
  - BRIDGEフレームワーク適用練習
  - 同僚とモック面接（顧客ロールプレイ）
  - 業界別ケース3-5個を準備

Week 29-30: 行動面接練習
  - STAR回答10個を準備
  - 「Why Palantir」回答を精錬
  - Ethical AI質問の準備

Week 31-32: 最終レビュー
  - フルモック面接（5ラウンド）
  - 弱点領域の補強
  - 自信管理、コンディション調整

目的: Ontology設計 + データパイプライン + ダッシュボード構築能力の証明

技術スタック:
  - Python（PySpark）+ SQL
  - React/TypeScript（ダッシュボード）
  - PostgreSQL + Apache Spark

実装内容:
  1. サプライチェーンOntology設計
     - Object Types: Supplier、Order、Product、Warehouse
     - Links: supplies、contains、stored-in
     - Properties + Actions定義

  2. ETLパイプライン
     - CSV/APIデータソース --> クレンジング --> 分析データセット
     - PySpark Transformsパターン適用
     - データ品質チェック含む

  3. ダッシュボード
     - リアルタイムサプライヤーパフォーマンスモニタリング
     - 遅延予測アラート
     - ドリルダウン分析機能

GitHubリポに含めるもの:
  - README: 設計判断プロセスの説明
  - アーキテクチャダイアグラム
  - デモ動画（2-3分）

目的: ビジネス分析 + 顧客コミュニケーション能力の証明

プレゼンテーション形式:
  - 3業界（製造、金融、医療）各1ケース
  - 各ケース10-15スライド

ケース1: グローバル製造業の品質管理
  - 課題: 不良率3% --> 目標1%
  - データ分析: 不良パターンの特定
  - Foundryソリューション設計
  - ROI: 年間5000万円削減

ケース2: 銀行AMLモニタリング
  - 課題: 不正検知精度60%
  - データ分析: 取引パターンネットワーク
  - Foundryソリューション設計
  - ROI: 偽陽性50%削減

ケース3: 病院の患者フロー最適化
  - 課題: 救急待ち時間4時間
  - データ分析: 患者経路最適化
  - Foundryソリューション設計
  - ROI: 待ち時間50%短縮

目的: 実際の顧客対応能力を動画で証明

3シナリオ（各5-7分）:

シナリオ1: 怒っている顧客のDe-escalation
  - 設定: ダッシュボード障害で経営陣報告が失敗
  - FDE役割: HEARDフレームワーク適用
  - 結果: 即時対応 + 再発防止計画を提示

シナリオ2: Scope Creep管理
  - 設定: 3回目の追加要件リクエスト
  - FDE役割: 建設的No + Phase分離提案
  - 結果: 現在のスコープ合意 + 今後のロードマップ

シナリオ3: 経営陣デモ
  - 設定: CFOへの15分ROIデモ
  - FDE役割: ストーリーテリングベースのプレゼンテーション
  - 結果: Phase 2予算承認を獲得

撮影のコツ:
  - 友人/同僚とロールプレイを録画
  - 各シナリオ後に自己分析を含める
  - 「なぜこのアプローチを選んだか」を解説