「現象」と「原因の仮説」を分けて、現状の業務フローと課題を整理する

原稿の管理表（13項目：記事ID・カテゴリ・要件ID・先に読むと理解しやすい記事・成果物パス・対象ツール・検証状況・最終更新日など）

管理項目	内容
記事ID	01-02
主な中カテゴリ	01-02 現状の流れと困り事を整理する
関連中カテゴリ	01-01、01-03、02-01
関連要件ID	REQ-001、REQ-005
先に読むと理解しやすい記事	01-01（利用者と業務の現場を知る）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	現状の作業、待ち時間、手戻り、例外、既存データを分けて説明し、「現象」と「原因の仮説」を混同しない理由を言える
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/01-02-current-flow_template.md、templates/01-02-current-flow_example.md
出典	第11節参照
対象ツール・バージョン	特定ツールに依存しない。AIへの指示例は汎用の文章
検証状況	本文・ひな形・記入例はClaude Codeが作成。第5.4節の指示文と第6節の初稿は説明用の例であり、実際にAIへ送信・観測した記録ではない。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成。同日、Phase 5B-1：Design型のPilotとして、読む順路・第4節の判断項目・第5.4節「AIに課題一覧の下書きを頼む」（渡す情報・指示文）・第6節の初稿→レビュー→修正→最終判断の流れを追加。業務フロー・課題一覧・完了条件・成果物は不変）

この記事の会社・人物・業務フローはすべて架空の設定です。実在する会社や案件とは関係ありません。第5.4節の指示文と第6節の初稿は説明用の例で、実際のAI出力を観測したものではありません。

この記事は何の話か。01-01で聞き取った発言をもとに、現状（メールとチャットに依頼が分散している状態）の業務フローを描き、そこにある課題を「現象」と「原因の仮説」に分けて整理する話です。

なぜ必要か。「メールとチャットに分かれているから」を確かめずに原因だと決めつけて解決策に進むと、実際の原因が別（例えば担当割当のルールが無いこと）だった場合に、見当違いの機能を作ってしまいます。AIに整理を頼むと、この決めつけが「もっともらしい文章」で返ってくるため、人が見分ける必要があります。

この記事を読むとできるようになること。

• 現状の作業、待ち時間、手戻り、例外、既存データを分けて説明できる
• 「現象」と「原因の仮説」を混同しない理由を説明できる
• AIに課題一覧の下書きを頼み、仮説の断定や現象と仮説の混同を見つけて直させ、確認方法まで書ける

読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。

• 基本だけ理解する：第1節→第3節（現象と仮説を分ける理由）→第4節（判断すること）→第5.2〜5.3節（業務フローと課題一覧）→第9節。ここまでで「現象・仮説・確認方法」の3欄の意味が分かり、ひな形を埋め始められます。AIへの依頼は出てきません。
• 作って確かめる：上に加えて第5.4節（AIに下書きを頼む：渡す情報と指示文）→第6節（初稿の不備を見つけて直す）→第7節（完了条件との照合）。
• 設計判断を深める：上に加えて第8節（仮説を確かめずに進む危険、適用限界）。

1. 今回の業務課題と完成するもの

この記事でやることは、01-01の聞き取りで得た発言をもとに、現状の業務フロー（依頼が誰からどこを通ってどう処理されるか）を描き、そこにある課題を「現象」「仮説」「確認方法」「影響を受ける役割」に整理することです。

01-01では「誰が」困っているかを、利用者・関係者の整理表にまとめました。この記事では、その表の「困り事」欄にある発言（総務課長の「承認したつもりが記録に残っていない」、総務担当の「誰が今の担当か分からず、同じ依頼に2人で対応した」など）を出発点に、「今、実際にどう業務が流れていて、どこで困っているか」を整理します。

この記事を読み終えると、次のものが手元にできます。

• 現状業務フロー（待ち時間・手戻りの箇所を含む）
• 課題一覧（現象、仮説、確認方法、影響を受ける役割）
• AIに課題一覧の下書きを頼むときに渡す情報と指示文

2. 前提知識と読む順路

この記事で使う言葉を先に説明します。

現象

一言でいうと、実際に起きている、確かめられる事実です。

たとえば、「総務課長が『承認したつもりが記録に残っていない』と発言した」は現象です。発言があったこと自体は、聞き取りメモで確かめられます。

これがないと、何を改善すべきかの出発点が「誰かの印象」になり、あとで「本当にそんなことが起きていたのか」に戻れません。

原因の仮説

一言でいうと、その現象がなぜ起きているかについての、まだ確かめていない推測です。

たとえば、「承認の記録場所が複数に分かれているのではないか」は仮説です。

これがないと、確かめていない推測を事実であるかのように扱い、実際には違う原因に対して解決策を作ってしまいます。

システム開発では、この「現象と仮説を分けて、確認方法を添える」作業が、要件定義の入力になります。要件定義では、確かめられた現象だけを要件の根拠にします。

待ち時間・手戻り

一言でいうと、待ち時間は次の作業に進むまでの空白の時間、手戻りは一度進んだ作業をやり直すことです。たとえば、「進捗が分からず、依頼者が問い合わせて総務担当が再確認する」のは手戻りです。

読む順路：利用者の整理は01-01が該当します。この記事の課題一覧は、01-03（改善の目的と効果を決める）の入力、および記事A（02-01）の聞取りメモ整理の元になります。

3. 理解する：なぜ現象と仮説を分けるか

3.1 分けないとどうなるか

結論から言うと、分けずに進むと「困り事」ではなく「誰かの推測」に対してアプリを作ることになります。

みらい業務サービスの例で考えます。総務課長の「進捗が見えない」という発言を聞いて、総務担当が「メールとチャットに分かれているからですよ」と言ったとします。これは筋の通った推測ですが、確かめてはいません。もし本当の原因が「誰が担当か決まっていないので、誰も状態を更新しない」ことだったら、依頼の受付をチャットに一本化しても、進捗は見えるようになりません。

3.2 よくある誤解

「困り事の発言そのものが現象」。「承認を簡単にしたい」という発言は現象ではなく希望です。「承認したつもりが記録に残っていない」という発言は現象です。この違いを区別します。希望の扱いは記事AのM-2の分解と同じです。

「原因はだいたい想像がつくので、確かめなくてよい」。想像で進めると、02-01以降で作った機能が実際の原因に対応していない可能性があります。

「AIに現状分析を任せればよい」。AIは一般的な業務フローの型を提示できますが、この会社で実際に何が起きているかは、01-01の聞き取りに基づいて人が整理します。AIの下書きは、仮説を「原因です」と断定した文章で返ってくることがあります（第6節）。

4. 判断すること

課題一覧を作るときに人が判断することは、次の4つです。

4.1 この記事で判断すること

4.2 勝手に決めてはいけないこと

• 01-01の聞き取りにない現象を、この記事で新しく作りません。
• 仮説を、確認していないのに確定した原因であるかのように書きません。
• 課題一覧の「確認方法」を、実際に確認したかのように書きません。この記事の時点では、確認方法を決めたところまでです。

4.3 AIに任せる範囲

一般的な業務フローの型や、現象・仮説の分け方の説明、01-01の発言を3欄に振り分けた下書き（第5.4節）はAIに任せられます。しかし、この会社で実際に何が起きているかの整理と、各発言が現象・希望・仮説のどれかの最終判断は、01-01の聞き取りに基づいて人が行います。AIの下書きは、第6節の見つけ方で人が照合してから使います。

5. 作って確かめる：現状業務フローと課題一覧を作る

5.1 準備

01-01の利用者・関係者の整理表（総務課長・総務担当の発言を含む）と、ひな形 templates/01-02-current-flow_template.md を用意します。

5.2 現状業務フロー

① 依頼者が、メールまたはチャットで総務担当へ依頼を送る
     │　（既存データ：メール・チャットに分散して残る）
     ▼
② 総務担当が、複数の経路（メール・チャット）を確認して依頼に気づく
     │　── 待ち時間：総務担当が経路を確認するまで、依頼が認識されない ──
     ▼
③ 総務担当が、総務課長へ依頼の内容を伝える（口頭・チャット）
     ▼
④ 総務課長が内容を確認し、承認する（記録に残らないことがある）
     ▼
⑤ 依頼者へ結果が伝わる（伝わらないこともある）
     │　── 手戻り：進捗が見えず、依頼者が総務担当へ問い合わせ、総務担当が再確認する ──

既存データの所在：依頼はメールとチャットに分かれて残る。承認の記録は、明確な記録場所がなく、口頭・チャットでのやり取りに含まれてしまうことがある。件数・保存期間は未確認。

5.3 課題一覧

5.4 AIに課題一覧の下書きを頼む

ここまでの材料（01-01の発言、3欄の定義）がそろうと、課題一覧の下書きをAIに頼めます。AIがするのは、発言を3欄に振り分けて表の形に整えることです。どの発言が現象かの最終判断と、仮説の確認方法を実際に決めるのは人です。

渡す情報と、渡さない情報を先に決めます。

指示文は次のとおりです。これは説明のために書いた例で、実際にAIへ送信した記録ではありません。

架空企業「みらい業務サービス」の総務部門で聞き取った発言（下記）を、課題一覧の下書きに整理してください。

発言：
- 総務課長：依頼の進捗が見えない。承認したつもりが記録に残っていなくて、あとで「承認されてないですよ」と言われた。承認を簡単にしたい。
- 総務担当：依頼がメールとチャットにばらばらに来る。誰が今の担当か分からず、同じ依頼に2人で対応したことがある。

整理の形式：
- 表の列は「現象」「仮説」「確認方法」「影響を受ける役割」の4つ。
- 「現象」には、発言として確かめられる事実だけを書く（誰の発言かを添える）。
- 「仮説」には、その現象がなぜ起きているかの推測を「〜の可能性」の形で書く。
- 「確認方法」には、誰に何を聞けば仮説を確かめられるかを書く。

してはいけないこと：
- 発言にない現象を作らないでください。
- 仮説を「原因です」と断定しないでください。確かめていないことは推測として書いてください。
- 「承認を簡単にしたい」のような希望は、現象として書かず、「希望」として別に分けてください。
- 解決策（アプリの機能）を提案しないでください。この段階では現状の整理だけを行います。

返し方：
- 表だけを返してください。説明文は不要です。
- 判断に迷った発言は、表に入れずに「判断できなかった発言」として最後に列挙してください。

6. 初稿・失敗例・修正

6.1 説明用の失敗例（AIの初稿という設定）

第5.4節の指示に対して、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではなく、教えるために不備を入れた説明用の例です）。初稿のうち、問題のある2行を抜き出します。

6.2 見つけ方と直し方

見つけ方は共通しています。下書きの各行を、01-01の発言と、第2節の3欄の定義と、指示文の「してはいけないこと」に1行ずつ照合します。

AIへの修正指示は次のとおりです（説明用の例）。

指摘：
1. 現象欄に「〜ため」という因果関係が入っています。発言として確かめられる事実だけを書き、因果関係は仮説欄に移してください。
2. 仮説欄の「原因です」という断定を、「〜の可能性」という推測の表現に直してください。
3. 確認方法欄に解決策（一本化する、ルールを作る）が書かれています。確認方法は「誰に何を聞けば仮説を確かめられるか」です。解決策は書かないでください。

変えないこと：
- 発言の内容そのものは変更しないでください。
- 表の4列の構成は変更しないでください。

6.3 修正後の課題一覧

修正後の課題一覧は、第5.3節の表のとおりです。初稿の2行は4行に分かれ、現象欄は発言どおり、仮説欄はすべて「〜の可能性」、確認方法欄はすべて「誰に何を確認するか」になっています。

6.4 最終判断

修正後の表を採用します。ただし、採用したのは「整理の形」であって「原因」ではありません。4つの仮説はいずれも未確認のまま01-03と記事Aへ渡し、確認方法に書いた聞き取りは02-01の要件を決める前に行う、という扱いにします。AIに「この整理で合っているか確認して」と頼んでも、同じ前提の上での再確認であり、独立した確認にはなりません。

7. 確認結果

第5.2〜5.3節の内容を、完了条件と照合します。

残る制限：この業務フロー・課題一覧は架空の聞き取りに基づく一例です。仮説はいずれも未確認であり、確認方法として書いた聞き取りは実施していません。第5.4節の指示文と第6節の初稿は説明用の例であり、実際にAIへ送信・観測した記録ではありません。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 確かめずに解決策へ進む危険

この記事では、仮説を確認してから次工程（01-03・02-01）へ進む方法を採用します。ただし、実際にこの記事の時点で確認を実施したわけではなく、確認方法を明記したところまでがこの記事の範囲です。

AIを使うと、この危険は小さくならず、むしろ見えにくくなります。第6.1節の初稿のように、推測が「原因です」という整った文章で返ってくると、人はそれを事実として読みがちです。AIが速く整理してくれるほど、発言との照合（第6.2節）を省かないことが重要になります。

8.2 適用限界

この業務フローは、架空企業「みらい業務サービス」の総務課長・総務担当の2人の発言に基づく一例です。実際の業務では、より多くの関係者への確認が必要になることがあります。

9. 持ち帰る成果物

自分の業務に使うときの手順は次のとおりです。

1. 前工程（利用者・関係者の整理表）を用意する
2. 現状の業務の流れを、待ち時間・手戻りが分かる形で図にする
3. 課題を、現象（確かめられる事実）と仮説（まだ確かめていない推測）に分けて書く。AIに下書きを頼むなら、第5.4節の指示文の形で頼む
4. 下書きを発言と1行ずつ照合し、断定・混同・解決策の混入を直す
5. 各仮説の確認方法を書く

10. 次工程への受渡し

次へ渡すもの：現状業務フロー、課題一覧（現象、仮説、確認方法、影響を受ける役割）。仮説はすべて未確認の扱い。

次工程での使われ方：01-03（改善の目的と効果を決める）では、この課題一覧の現象から改善の目的を決め、待ち時間・手戻りを指標にします。記事A（02-01）では、この課題一覧の発言が聞取りメモ整理表（M-1〜M-5）になり、仮説は確認事項（Q表）の候補になります。

前工程へ戻る条件：課題一覧の現象が01-01の聞き取りと食い違う場合は、01-01に戻って確認します。

11. 根拠と更新情報

• この記事の会社・人物・業務フローはすべて架空の設定です。
• 第5.4節の指示文は、この記事のために書いた指示文の例であり、実際にAIへ送信した記録ではありません。第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
• 課題一覧の現象（総務課長・総務担当の発言）は、01-01および記事Aの聞取りメモと同じ設定に基づきます。記事Aの困り事分析（M-1〜M-5）は、この課題一覧を踏まえて作成されたものという位置づけです。
• AIへの指示の構造（渡す資料、形式、してはいけないこと、返し方）は、templates/ai_request_template.md の構成に沿っています。
• 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
• 2026-09-20（Phase 5B-1）：Design型のPilotとして、読む順路（3つの深さ）、第4節の判断項目（判断すること・仮置き可否・間違えた場合の影響・AIに任せる範囲）、第5.4節「AIに課題一覧の下書きを頼む」（渡す情報の表と指示文）、第6節の初稿（表の形）→不十分な点と人の修正→修正指示→最終判断の流れ、記事間の参照を追加した。業務フロー・課題一覧の内容・完了条件・成果物は変えていない。
• 未確認事項：第5.3節の仮説はいずれも未確認であり、実際の確認（聞き取り）は行っていません。