business-flow-visualizer

ヒアリング時の会話 — 自動車部品工場：受注 → 出荷

これはシミュレーションです。 実在の企業・担当者の発言ではなく、
flow-interview スキルの手順を検証するために作成した架空のヒアリング記録です。
記法がどんな質問から埋まっていくかを追えるように、やり取りをそのまま残しています。

聞き手： flow-interview（AI） 話し手：

• 田中さん（製造課・工場職員）… 現場の実作業、紙の運用、待ち、困りごと
• 佐藤さん（生産技術・エンジニア）… システム、EDI、リードタイム、自動化状況

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

---

Round 1. 全体像

Q（聞き手）： この業務、どこから始まってどこで終わりますか？ 現状（AS-IS）を描きますか、理想（TO-BE）ですか？

A（佐藤・エンジニア）： 始まりは自動車メーカーさんからの確定注文がEDIで飛んでくるところ。 終わりは製品を出荷して、ASN（事前出荷通知）を送るまでです。今回は現状（AS-IS）でお願いします。 理想を語る前に、今どこで詰まってるかを可視化したい。

A（田中・工場職員）： 現場感覚だと「注文が来た」→「作れ」って来て、「検査待ち」で止まって、 「出荷しろ」で終わる感じですね。

→ view: AS-IS ／ start: と end: が決まる

---

Round 2. 役割（＝行）

Q： 登場する部署と社外を、上流から順に挙げてください。社外・外部システムは分けたいので教えてください。

A（佐藤）： 社外が 自動車メーカー（発注元）と 部品サプライヤー。 社内は 受注管理課 → 生産管理課 → 調達課 → 製造課 → 品質保証課 → 出荷課 の順です。

Q： サプライヤーとのやり取りは人ですか、システムですか？

A（佐藤）： EDIの自動発注です。なので「外部」扱いでいいです。メーカーからの受注も同じくEDI。

→ roles: が確定。社外は #社外、外部システム連携は #外部 を付ける

---

Round 3. 時系列（＝列）とマイルストーン

Q： 時間の刻みは何が自然ですか？ 節目はどこですか？

A（佐藤）： 営業日で Day0受注 → Day1計画 → Day2部品入荷 → Day3製造 → Day4検査 → Day5出荷。 標準リードタイムが5営業日です。

A（田中）： 節目は現場的には3つ。生産計画が確定した時点、製造が終わった時点、出荷した時点。

→ timeline: と milestones: が確定。「5営業日」は sla: へ

---

Round 4. ステップの詳細（手段・成果物・時間・待ち・困りごと）

受注の取り込み

Q： Day0の受注取り込みから。誰が何をして、それはシステムですか手作業ですか？

A（佐藤）： EDIで受注管理システムに自動で入ります。 ただ内示（フォーキャスト）と確定数の突合は手作業。担当が毎朝30分くらいExcelで見比べてます。

→ by: 外部/EDI ／ artifact: 受注管理システム op: 受注登録 ／ time: 30分 freq: 毎日
→ 「突合は手作業」は issue: に

Q： そこは改善したいところですか？ 案があれば一緒に描けます。

A（佐藤）： うーん、そこはまだ具体的に考えていないです。今は製造の実績のほうが先。

→ 改善案（tobe）は書かない。案が無いものを勝手に書かない

Q： 差異があったらどうなりますか？

A（佐藤）： ±10%を超えたらメーカー担当に電話・メールで照会します。 回答が半日〜1日待ちになって、計画着手が翌日にずれることも。

Q： 照会はその日のうちに投げますか？

A（佐藤）： はい、その日の午後には投げます。

→ cond ／ wait: 回答待ち 半日〜1日 ／ rework: で受注確認へ戻す
→ 照会は「Day0 午後」の列に置ける

生産計画

Q： 計画は誰が、何を使って立てますか？

A（佐藤）： 生産管理課が生産管理システム（MRP）で立てて、確定させます。

Q： どれくらい時間がかかりますか？

A（佐藤）： 測ってないですね。 MRPを流すのは一瞬ですが、確認と調整が入るのでばらつきます。

→ by: システム/生産管理システム(MRP) ／ artifact: 生産計画 op: 計画確定
→ 所要時間は空欄にする（測っていないため）

部品の調達

Q： 計画のあとは？ 同時に走る作業はありますか？

A（佐藤）： はい、計画確定後に「部品発注」と「治具・段取り準備」が並行で走ります。 両方そろわないと製造に入れません。

A（田中）： そう、材料が来ても段取りができてないと着手できないし、逆もある。ここは「両方待ち」です。

Q： 発注は具体的にどうしますか？

A（佐藤）： 不足分の発注データをEDIで送信します。納入されたら受入検収をして計上します。

Q： 部品の納入に期限はありますか？ 遅れたら？

A（佐藤）： 発注翌日（1営業日）が納期。遅れたら調達から督促を掛けます。

Q： 部品の納入まわりで、困っていることはありますか？

A（佐藤）： そこは今、大きな問題にはなっていないです。だいたい期日どおり来ます。

→ 課題（issue）は書かない。困りごとが無いなら空欄

A（田中）： ただ、材料待ちで手が空くことはありますよ。

→ wait: 部品入荷待ち

段取りと製造

Q： 段取りの準備はどれくらいかかりますか？

A（田中）： 半日くらいです。品種を切り替えるので。

Q： 製造の実作業について。何を使って、記録はどう残しますか？

A（田中）： 紙の製造指示書を持ってラインで加工・組立。まる1日かかります。 実績は紙の日報に手書きして、翌朝まとめて生産管理システムに入力してます。 ここが一番のムダで、実績がリアルタイムで見えない。

Q： 改善案のイメージはありますか？

A（佐藤）： MESで設備から実績を自動収集したい。それが本命です。

→ artifact: 製造指示書（紙） op: 実績を手書き記入 ／ time: 1日
→ issue:「日報が紙。翌朝まとめて入力で、実績がリアルタイムに見えない」／ tobe: MES

検査

Q： 検査は？ 待ちは発生しますか？

A（田中）： 品質保証の出荷検査。ロットが溜まるまで検査待ちが半日くらい出ます。

Q： 検査そのものは何を使いますか？ 成績書はどこで作りますか？

A（田中）： 検査は治具に当てて測ります。成績書は検査システムで、測定値を入れると出ます。

Q： 検査そのものの所要時間は？

A（田中）： ロットの大きさでまちまちですね。測ってはいないです。

→ by: 人手/検査治具 ／ artifact: 検査成績書 op: 検査システムで作成 ／ wait: 検査待ち 半日
→ 所要時間は空欄にする（測っていないため）

---

Round 4.5. 出てきた専門用語を拾う

Q： いま出てきた言葉、業務を知らない人にも分かるようにしたいので教えてください。 「内示」って、どういう意味ですか？

A（佐藤）： 確定前にメーカーから示される見込みの注文数量です。確定注文とは数量が変わることがあります。

Q： EDI、MRP、MES、ASN は？

A（佐藤）： EDIは電子データ交換、企業間でデータを決まった形式でやり取りする仕組み。 MRPは資材所要量計画、計画から必要な部品と数量・時期を割り出すもの。 MESは製造実行システム、設備や作業者から実績をその場で集めるもの。 ASNは事前出荷通知、何をいつ送るかを出荷前に知らせるデータです。

Q： 現場の言葉も。「治具」「段取り替え」「受入検収」「検査成績書」は？

A（田中）： 治具は加工や組立のときに部品を正しい位置で固定する道具。 段取り替えは生産する品種を切り替えるために治具や設定を入れ替える作業。 受入検収は納入された部品を検査して、数量と品質を確認して受け入れる手続き。 検査成績書は検査の結果を記録した書類で、出荷する製品の品質を証明します。

→ glossary: に9語を定義。本文では [[用語]] で参照する

---

Round 5. 分岐・例外・手戻り

Q： 検査でNGが出たときは？

A（田中）： 手直し（ライン外）して再検査に回します。 この手直しの記録が紙で残るので、後追いが大変。

Q： 出荷は？ 梱包は手作業ですか？

A（佐藤）： 梱包・ラベル貼りは手作業です。そのあと納品書を発行、 最後にASNをEDIでメーカーに送信して完了です。

→ except: 検査NG? ／ ng: で手直しへ ／ rework: で再検査へ戻す
→ 出荷課の2ステップ ／ 最後は by: 外部/EDI(ASN)

---

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

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

箇所	項目	理由
生産計画を立案・確定する	所要時間	「測っていない」（佐藤さん）
出荷検査を行う	所要時間	「ロットによってまちまち、測っていない」（田中さん）
部品を納入する	課題	「大きな問題にはなっていない」（佐藤さん）
受注データを取り込む	改善案	「まだ具体的に考えていない」（佐藤さん）
各ステップ	頻度	受注取り込み（毎日）以外は聞けていない

推測で補った箇所

箇所	内容	根拠
梱包・納品書発行 と ASN送信 を2ステップに分けた	聞き手による構造化	発言は「梱包して、納品書を出して、ASNを送る」という一連の流れ
治具・段取り準備を Day2 に配置	聞き手による配置判断	「両方そろわないと製造に入れない」からの逆算

未ヒアリングの項目

• 初品検査の有無
• ロット・トレーサビリティ記録の運用
• 複数ラインの並行稼働
• 督促を誰がどの手順で行うか

---

この会話から生まれたもの

• order-to-shipment.flow … 上記のやり取りを記法に落としたもの
• order-to-shipment.html … .flow から flow-visualize で生成した業務フロー図

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

これは実際のヒアリング記録です。（シナリオ① と違い、シミュレーションではありません）
業務の説明者は本リポジトリの利用者。聞き手は 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役割以外の関与者の有無