# ヒアリング時の会話 — システム開発：開発依頼 → 納品

> **これは実際のヒアリング記録です。**（シナリオ① と違い、シミュレーションではありません）
> 業務の説明者は本リポジトリの利用者。聞き手は `flow-interview`（AI）。
> 記法がどんな質問から埋まっていくかを追えるように、やり取りをそのまま残しています。

**聞き手：** flow-interview（AI）
**話し手：** 依頼者（システム開発会社側）

`flow-interview` の手順どおり、**全体像 → 役割 → 時系列 → ステップ詳細 → 分岐・手戻り**
の順に、会話を小さく回して聞いている。
**聞けなかったこと・答えが無かったことは推測で埋めず、空欄のまま**にしている（末尾に一覧）。

---

## Round 1. 全体像

**Q：** どんな業務ですか。どこから始まってどこで終わりますか。現状（AS-IS）ですか理想（TO-BE）ですか。

**A：**
1. システム開発の一通りの流れのフローです
2. 顧客からの開発依頼から始まり、システムの納品にて終わります
3. AS-IS を書いて、ところどころ TO-BE を織り交ぜたいです

> → `view: AS-IS` ／ `start:` と `end:` が決まる
> ※ TO-BE については Round 3 で「特にない」と確認され、最終的に AS-IS のみとなった

---

## Round 2. 役割と流れ（話し手が時系列順にまとめて説明）

**Q：** 登場する役割を上流から順に。社外はいますか。兼務はありますか。

**A：**（時系列順に説明）

> まずは顧客から、こういうデジタル化がしたいんだけど、システム化がしたいんだけど、といった
> まず提案を受けるところから始まります。
>
> そこで弊社上流工程担当が、まずヒアリングを行い、現状の業務分析や課題の整理などを行い、
> ユーザーと合意を行います。
>
> そこで、共通の業務課題認識が持てた後に、コンセプトの定義と今回のシステム化の対象をざっくり決めます。
>
> ここで、第1回目の見積もり、要件・課題整理に対する見積もりを行います。
> **弊社はシステム開発までに2段階の発注を行っており**、第1回目はまず要件の整理と課題の整理を行います。
> ユーザーと現状の業務や課題を認識合わせし、それを成果物として提出するのが第1回目です。
> 第2回目は、その整理した要件や課題、実際に実現したいフローをもとに機能の開発、
> システム開発を行うのが第2回目です。
>
> **ここで顧客は、システム開発まで行うかどうかはまだ判断する必要はありません。**
> ひとまずは、第1回目の発注、要件の整理、課題の整理を行うかどうかを
> この見積もりをもとに判断していただきます。
>
> そこで合意に至り、発注となった際は、詳細な現状業務のヒアリングであったり、現状業務のフロー化、
> 課題の整理、課題の認識合わせなどを顧客と行い、
> 実際どんなところにシステム化改善の余地があるかを検討します。
>
> **システム化改善の前に、業務そのもの自体を**無駄な仕事の削減であったり、改善をできるかどうか、
> **時には社内風土まで踏み込んで**、そこをあるべき姿、理想の形をともにこのフェーズでは描きます。
>
> そこで最終成果物として、現状の業務フロー（As-is）と理想の業務（To-be）、
> さらには課題のマッピングを行ったものを成果物としてユーザーと合意を行い、
> システム化に進むかどうかの判断をしていただきます。
> この際に、第2回のシステム化に向けた見積もりも行い、提案いたします。
>
> そこで合意をいただけた際は、実際にシステム開発に進んでいきます。
>
> 今回の業務フローでは、**システム開発のフローについては詳細は省略**いたしますが、
> 基本的に要件の整理、詳細設計、実装、テスト、ユーザーでのユーザーテストなど一通りを行い、
> 実業務で運用できるとユーザーとも合意がいただけた場合に、開発完了納品という形になります。

**Q（聞き取った構造を返して確認）：** 15の行為として拾いました。担当者が分からないのが4か所あります。
（コンセプト定義／第1回見積／第2回見積／システム開発）

**A：** 4、5、11 は**上流工程担当**、13 は**会社全体の開発担当**が行います。

> → `roles: [顧客#社外, 上流工程担当, 開発担当]` の3行に確定

---

## Round 3. 時系列・分岐・TO-BE

**Q：** 時系列の刻みはフェーズ名ですか期間ですか。判断が NO のときはどうなりますか。
図に併記する TO-BE（御社の進め方の改善案）はありますか。

**A：**
- 時系列の好みは**「フェーズ名」**です
- 判断が NO だった場合は基本的には終了になりますが、**機能の縮小や再見積もりなどを行い、再提案する場合もあります。
  それは顧客から要望があった場合のみに限ります**
- **14の運用できないは、開発フェーズに戻るでやり直し**です
- **このシステム開発フローに関する TO-BE は特にありません。AS-IS をただ視覚化したいだけです**

> → `view: AS-IS`、`tobe` は使わない

---

## Round 4. 成果物・期間・待ち・課題

**Q：** 再提案のループはどこに付きますか。成果物の呼び方は。期間は分かりますか。
顧客の判断待ちは発生しますか。課題（⚠）は付けますか。

**A：**
- 基本的には、**NO を言われた際の見積もりに戻ります**
- **見積もりは「見積書」**でいいです。**10 の成果物もそれでいい**です
  （現状業務フロー／理想業務フロー／課題マッピング）
- **2、8 の段階でも途中、成果物は共有します。ただし、納品という形ではありません**
- **各フェーズの期間は、場合によってまちまち**なので、一回視覚化できてからちょっと考える
- **顧客の判断待ちは、もちろん発生します**
- **特に課題はなし**でいいです

> → `artifact: 見積書` ／ `artifact: 現状業務フロー・理想業務フロー・課題マッピング`
> → 2・8 は `artifact: 途中成果物` `op: 共有`
> → `time` / `freq` は**空欄**。`issue` は**使わない**。判断ノードに `wait: 顧客の判断待ち`

---

## Round 5. 残りの確認（NOの既定・途中成果物の名前・マイルストーン）

**Q：** NO のときの既定は「終了」ですか「見積もりに戻る」ですか。
途中で共有する成果物の呼び方は。マイルストーンは置きますか。

**A：**
- **B（NO → 見積もりに戻って再提案するのが基本。まとまらなければ終了）**
- **途中成果物**で
- マイルストーンは、**第1回発注、第2回発注、納品**にしましょう

> → 分岐の `else` は再提案へ。再提案がまとまらないときだけ終了
> → `milestones: { 第1回発注, 第2回発注, 納品 }`

---

## 空欄にした項目（聞けなかった／答えが無かった）

`flow-interview` の鉄則に従い、**推測で埋めずに空欄のまま**にした。

| 箇所 | 項目 | 理由 |
|------|------|------|
| 全ステップ | 所要時間（`time`） | 「場合によってまちまち。視覚化してから考える」 |
| 全ステップ | 頻度（`freq`） | 伺っていない |
| 全ステップ | 課題（`issue`） | 「特に課題はなしでいい」 |
| 全ステップ | 改善案（`tobe`） | 「このフローに関する TO-BE は特にない」 |
| 判断の待ち | 待ち時間の長さ | 「判断待ちは発生する」とだけ伺った。日数は未確認 |
| 手段（`by`） | 各行為をどう実施するか（対面／オンライン／ツール等） | 伺っていない |

## 推測で補った箇所

| 箇所 | 内容 | 根拠 |
|------|------|------|
| フェーズ名15個 | 聞き手が命名し、確認を取った | 話し手の説明を区切って命名。Round 3 で提示し了承を得た |
| 「顧客が判断する」を1ステップとして独立させた | 聞き手による構造化 | 「判断していただきます」という発言を、顧客レーンの行為として明示するため |
| 再提案がまとまらない場合の終了を分岐として表現 | 聞き手による構造化 | 「まとまらなければ終了」（Round 5・B）を分岐で表した |

## 未ヒアリングの項目

- 各フェーズの期間・工数
- 各行為の手段（対面／オンライン／使用ツール）
- システム開発フェーズの内訳（本人の指示により詳細は省略）
- 営業・PM など、3役割以外の関与者の有無