# PRISM — 次回ヒアリング設計書

**用途:** 株式会社リベラウェア 和田様への2回目ヒアリング。そのまま持ち込める質問票。
**所要:** 60〜90分。優先度★★★だけなら45分で回せる。
**目的:** `【要確認】` の解消と、Phase 0（PoC）の設計確定。

---

## 0. 冒頭で共有すること（5分）

1. 前回のヒアリングから、こちらが立てた仮説の骨格（Zero-Input／3階層翻訳／プロセス分解）
2. **今日の目的は「売り込み」ではなく「前提の検証」であること**
3. 特に確認したいのは「本当に入力なしで進捗が推定できるか」の技術的な可否

> 言い方の例：「前回のお話から企画を組んだのですが、成立するかどうかが1点の技術的な仮説に全部かかっています。今日はそこを潰させてください。」

---

## 1. プロジェクトの実態（優先度 ★★★）

| # | 質問 | 何を知りたいのか |
|---|---|---|
| 1-1 | 今、同時に動いているプロジェクトは何件ありますか | SAM 適合性の確認。10件以上か |
| 1-2 | その内訳を種類で分けると？（機体開発／ソフト開発／点検サービス／受託／実証実験／補助金） | 案件テンプレートの設計単位が決まる |
| 1-3 | 1人が同時に持っている案件数は平均で何件くらいですか | リソース競合検出の必要度 |
| 1-4 | 1件のプロジェクトが受注から完了までに通る標準的なステップを教えてください | **プロセスマイニングの基準プロセス。最重要** |
| 1-5 | そのステップは案件の種類によって違いますか。違うなら何種類ありますか | テンプレート数 |
| 1-6 | 「これは標準から外れた」と感じる進み方をした案件の例を1つ | バリアント分析の当たり所 |

### 1-4 の聞き方（重要）

ホワイトボードに書かせる。**「公式のフロー」ではなく「実際にどう進んだか」を聞く**こと。
「本当はこうあるべきなんですけど、実際は…」という言葉が出たら、そこがマイニングの金脈。

---

## 2. 現在のツールと形骸化の履歴（優先度 ★★★）

| # | 質問 | 何を知りたいのか |
|---|---|---|
| 2-1 | 今使っているツールを教えてください（プロジェクト管理／チャット／ファイル共有／勤怠／見積・請求） | **コネクタの実装順が決まる** |
| 2-2 | ソースコードは GitHub ですか。GitLab や社内 Git も混在していますか | 一次シグナルの取得可否 |
| 2-3 | Slack か Teams か。チャンネルは案件ごとに切っていますか | `project_hint` の設計。案件との紐付け可否 |
| 2-4 | 過去に導入して形骸化したツールはありますか。**なぜ使われなくなったと思いますか** | 訴求メッセージの核。顧客自身の言葉が最強のコピーになる |
| 2-5 | 今、進捗を「入力する」作業は誰が何にどれくらいの頻度でやっていますか | 削減原資の実測 |
| 2-6 | 週報・日報はありますか。1人あたり何分かかっていますか | ROI 計算の分子 |

---

## 3. 属人化の具体（優先度 ★★★）

| # | 質問 | 何を知りたいのか |
|---|---|---|
| 3-1 | 「属人化している」と感じる具体的な業務を **3つ** 挙げてください | バス係数分析の検証対象 |
| 3-2 | その3つは、なぜその人しかできないのですか（知識／権限／人間関係／慣れ） | 自動抽出できる種類かの判定 |
| 3-3 | その人が1週間休んだら、止まる案件は何件ですか | 経営層ビューの目玉指標の妥当性 |
| 3-4 | 引き継ぎを試したことはありますか。何が障害でしたか | ナレッジカードの設計要件 |

### 3-1 の聞き方

**必ず3つ出し切ってもらう。** 1つだと「たまたま」で終わる。3つ並ぶと共通構造が見える。
出てこないときは「じゃあ、いま一番"あの人に聞かないと分からない"のは何ですか」と言い換える。

---

## 4. 経営層の情報ニーズ（優先度 ★★☆）

| # | 質問 | 何を知りたいのか |
|---|---|---|
| 4-1 | 経営層が「知りたいのに知れない」情報は具体的に何ですか | 経営層ビューの設計 |
| 4-2 | それを今はどうやって知ろうとしていますか（誰に聞く／どの資料を見る） | As-Is の報告コスト |
| 4-3 | 月次・四半期で作っている報告資料はありますか。作成に何時間かかりますか | 自動化候補の第1号になりうる |
| 4-4 | 案件が「危ない」と判断するときの基準は何ですか | 赤信号の閾値設計 |
| 4-5 | 危ないと分かったとき、実際に打てる手は何がありますか | シナリオシミュレーションの選択肢設計 |

---

## 5. 現場作業の記録（優先度 ★★☆）

| # | 質問 | 何を知りたいのか |
|---|---|---|
| 5-1 | 点検などの現場作業の実績は、どうやって記録されていますか | **R2（連携できないデータ）の核心** |
| 5-2 | その記録はデジタルですか。紙・Excel・写真だけ、というものはありますか | 一言報告ボットの必要度 |
| 5-3 | 現場から会社への報告は、いつ・どの手段で入りますか | Slack/LINE ボットの設置場所 |
| 5-4 | 現場作業の遅れは、社内でいつ気づきますか | 予兆検知の価値が出る場所 |

---

## 6. PoC の合意（優先度 ★★★）

ここが本題。**次のアクションを具体的に握るための質問。**

| # | 質問 | 目的 |
|---|---|---|
| 6-1 | 過去6ヶ月の GitHub / Slack / カレンダーのログを、匿名化した形でお借りできますか | PoC の入力 |
| 6-2 | 匿名化が必要な範囲を教えてください（顧客名／個人名／金額） | データ提供の障壁を先に潰す |
| 6-3 | 検証対象にする案件を2〜3件選んでいただけますか。できれば「うまくいった1件」「揉めた1件」「現場作業中心の1件」 | 検証の質。揉めた案件が最も学びが多い |
| 6-4 | その案件の「実際どう進んだか」を後で答え合わせできる方（PM）にお時間をいただけますか | 正解データの作成 |
| 6-5 | 業務プロセスを実際に見せていただく機会（半日程度）をいただけますか | As-Is の精度 |
| 6-6 | セキュリティ上、社外にデータを出せない場合、こちらが御社環境に入る形でも可能ですか | オンプレ要件の把握 |

### 合否ラインの事前合意（必ずこの場で握る）

> 「PoC で以下を満たせなかったら、正直に"この方式では無理でした"とご報告します。」

| 指標 | 合格ライン |
|---|---|
| フェーズ推定の一致率 | 80% 以上 |
| 遅延検知のリード | 実発覚より3日以上早い |
| 誤検知率 | 20% 未満 |

**この宣言が信頼を作る。** 「絶対できます」と言う相手より「できなかったらそう言います」と言う相手のほうが、技術者相手には強い。

---

## 7. 監視への抵抗の下見（優先度 ★★☆）

デリケートなので最後に、雑談のトーンで。

| # | 質問 | 何を知りたいのか |
|---|---|---|
| 7-1 | 進捗が自動で見えるようになると聞いて、社内で「監視されるみたいだ」と言う人はいそうですか | R3 の発生確度 |
| 7-2 | それを言いそうなのは、どのポジションの方ですか | 導入時に最初に味方につける相手 |
| 7-3 | 過去に、計測系のツールで社内が揉めたことはありますか | 地雷の場所 |

---

## 8. 聞かないほうがいいこと

- **予算感を初回から詰めない。** 前提検証の場で価格の話を出すと「売り込みだった」と受け取られる。向こうから聞かれたら答える程度に留める。
- **競合ツールの批判をしない。** Jira を使い続けたまま乗るのが PRISM の設計思想。「Jira はダメですね」と言った瞬間に矛盾する。
- **「AIで全部自動化できます」と言わない。** R1 が最大リスクである自覚を共有するほうが、技術者相手には信頼される。

---

## 9. 持ち帰るべきアウトプット（このヒアリングの成果物）

- [ ] 同時進行プロジェクト数と種類の内訳
- [ ] 案件種類ごとの標準プロセス（手書きでもよい）
- [ ] 使用中ツールの一覧と、案件との紐付け方法
- [ ] 形骸化したツールとその原因（**顧客の言葉のまま記録する**）
- [ ] 属人化している業務 3つとその理由
- [ ] 経営層が知りたいのに知れない情報
- [ ] 現場作業の記録手段
- [ ] PoC 対象案件 2〜3件の合意
- [ ] データ提供の可否と匿名化範囲
- [ ] PoC 合否ラインの合意
- [ ] 次回日程

---

## 10. ヒアリング後 48時間以内にやること

1. 議事録を送る（**顧客の言葉をそのまま引用した形で**。要約しすぎない）
2. `01_executive_summary.md` の `【仮説】` を `【確認済】` に書き換える。外れていた仮説は消す（言い訳を残さない）
3. PoC の実施計画書（対象案件・期間・合否ライン・データ受け渡し方法）を1枚で送る
4. **外れた仮説があったら、そこを最初に報告する。** 都合の悪い結果を先に出すのが信頼の作り方