開発を始める前の基礎学習記事全11節Integration
14の工程のつながりと、前の工程へ戻る場面を地図にする
この記事で身につくこと01〜13の各工程の目的と主な成果物を一覧で説明でき、「前の工程へ戻る場面」と「小さく作って確かめる流れ」を例で言える。
記事内目次（24項目）
この記事の会社・人物・工程例はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。この教材が扱う14の大きな工程（企画から運用まで）が、それぞれ何を目的とし、何を成果物として次へ渡すか、そして途中で前の工程へ戻ることがある、という全体のつながりを地図にする話です。
なぜ必要か。工程ごとの記事を1本ずつ読んでいると、「今、全体のどこにいるのか」「なぜこの記事の前にあの記事が必要なのか」が分からなくなります。工程は「決まりだから」並んでいるのではなく、前の工程の答えが無いと次の工程の判断ができないから並んでいます。この記事は、その理由ごと持ち歩ける共通の地図です。
この記事を読むとできるようになること。
- 14の工程それぞれの目的と主な成果物を一覧で説明できる
- 検証や試作で発見があったときに、前の工程へ戻る場面を例で言える
- 「ローカルの演習」「限定的な試行」「実業務への導入」という3つの適用範囲の違いと、AIが手伝っても工程が消えない理由を説明できる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3.1節（小さく作って確かめる）→第3.3節（工程がこの順につながる理由）→第5.2節の対応表→第9節。ここまでで、これから読む記事が全体のどこに当たるかを、対応表で指せるようになります。
- 作って確かめる：上に加えて第3.4節（AIと工程）→第4節（今どの工程か・戻るか進むか・どの段階かの判断）→第5.3〜5.4節（戻る例と適用範囲）→第6〜7節。
- 設計判断を深める：上に加えて第8節（規模によって工程の重さがどう変わるか、この教材の適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、この教材が扱う14の工程（00〜13）について、それぞれの目的と主な成果物を対応表にまとめ、工程を戻る例を書き込むことです。
00-01・00-02では、アプリの中の仕組み（登場人物、ファイル）を見ました。この記事では視点を変え、「アプリを作る前から、作ったあとの運用まで」という時間の流れ全体を見ます。
題材は同じです。架空企業「みらい業務サービス」の総務部門で、メールとチャットに散らばる依頼を、依頼・承認管理アプリで管理できるようにする。「困っている」という声から始まり、要件を決め、設計し、作り、確かめ、使い始め、使い続け、直し続ける。その全体を14の工程に分けたものが、この記事の地図です。
この記事を読み終えると、次のものが手元にできます。
- 工程と成果物の対応表（14大カテゴリすべて）
- 前工程へ戻る例（2件以上）
- 「ローカルの演習」「限定的な試行」「実業務への導入」の適用範囲の注記
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
工程
一言でいうと、目的が異なるひとまとまりの作業段階です。たとえば、「何を作るか決める」（要件定義）と「実際に作る」（実装）は、別の工程です。
成果物
一言でいうと、その工程が終わったときに残る、次の工程へ渡す文書やコードです。たとえば、要件定義の成果物は「業務要件一覧」です。
前工程へ戻る
一言でいうと、後の工程で見つかった問題を、前の工程の内容を見直すことで解決することです。たとえば、検証（09）で「承認者の割当条件が曖昧だ」と気づいたら、要件定義（02）に戻って条件を明確にします。
これがないと、後で見つかった問題を、無理に後の工程だけで押し切って解決しようとしてしまい、根本的な原因が残ったままになります。
読む順路：登場人物の見取り図は00-01、ファイル・データの区別は00-02が該当します。この記事の対応表は、これから読む01〜13のすべての記事の冒頭で参照する共通の地図になります。
3. 理解する：工程は一度しか通れない道ではない
3.1 「小さく作って確かめる」流れ
この教材は、企画→要件→設計→実装→検証→運用という順序で進みますが、一度通ったら後戻りしない一本道ではありません。設計書5.5「段階的な拡張」にあるとおり、最初は小さく作って確かめ、発見があれば前の工程に戻って直す、という繰り返しを想定しています。
3.2 よくある誤解
「工程は上から下へ一直線に進むもの」。実際には、検証や試作で「これでは要件を満たせない」と分かることがあり、その場合は前の工程に戻ります。
「戻ることは失敗のしるし」。早い段階で戻って直せることは、後になって（例えば公開後に）気づくよりもずっと負担が小さく、むしろ望ましいことです。
「すべての工程を、どんな規模のアプリでも同じ重さでやる」。小規模な社内アプリと、高リスク・大規模なシステムでは、同じ工程順でも確認の厳密さが変わります（第8節）。
「AIが作ってくれるなら、工程は要らない」。AIは各工程の作業を速くしますが、工程が答える問い（何に困っているか、何を作るか、本当にそう動いたか）が消えるわけではありません（第3.4節）。
3.3 工程がこの順につながる理由
結論から言うと、各工程は「1つの問いに答える」ためにあり、前の問いの答えが次の問いの材料になるから、この順に並んでいます。
みらい業務サービスの例で追ってみます。総務課長の「依頼の進捗が見えない」という困り事（01）を、「依頼者は自分の依頼の状態を一覧で見られる」という要件（02）に変えます。要件が決まって初めて、「状態を4つに固定し、依頼ごとに承認者を1人持つ」という設計（05）ができます。設計があって初めて、承認可否を判定する関数（08）を作れます。関数ができて初めて、「割当外の承認者が承認しようとしたら拒否される」という期待結果と照合する検証（09）ができます。検証で確かめた範囲が分かって初めて、「使い始めてよいか」の判断（10）ができます。どこかの答えが無ければ、次の判断は勘で行うことになります。
| 問い | 答える工程 | 答えの形（主な成果物） | 前の答えが無いと何が起きるか |
|---|---|---|---|
| 何に困っていて、作る価値があるか | 01 課題発見・企画 | 課題一覧、目的・評価指標 | 作っても「何が良くなったか」を説明できない |
| 何を作れば完成か | 02 要件定義 | 業務要件一覧、受入条件 | 作る人（またはAI）が決まっていない部分を想像で埋める |
| どう作るか | 03〜05 計画・設計 | 方式比較表、画面の原型、状態遷移表、権限表 | 実装のたびに判断がぶれ、画面と処理で「承認者」の意味が食い違う |
| 実際に動くか | 06〜08 準備・AI協働・実装 | 環境構築手順、AI作業指示書、コードと実行記録 | 「できました」という報告だけが残り、動いた証拠が無い |
| 本当に要件どおりか | 09 テスト・レビュー | 要件・テスト対応表、リスク別の検証結果 | 正常な操作しか確かめておらず、権限のない承認が通る |
| 使い始めてよいか | 10 導入・受入の準備 | 受入確認記録、利用開始判定記録 | 未確認のものを実際の依頼データに載せる |
| 安全に置き、戻せるか | 11 公開・本番移行 | 配置手順・実行記録、切戻し手順 | 障害のときにどこへ戻すかが決まっていない |
| 使い続けられるか | 12 運用・障害対応 | 運用項目一覧、障害対応記録 | 「起動しているが業務としては壊れている」状態に気づけない |
| 次に何を直すか | 13 保守・改善・引継ぎ | 改善要望一覧、変更影響調査 | 直したことで別の要件を壊しても分からない |
戻る流れも、この表で説明できます。09で「承認者の割当条件が曖昧」と分かるのは、02の答え（要件）が検証に耐える形になっていなかったからで、直す場所は09ではなく02です（第5.3節）。
3.4 AIは工程を横断して支援するが、工程そのものは消えない
AIは、01の聞き取りメモの整理から13の変更影響の洗い出しまで、どの工程でも下書き・候補出し・実行・整理を手伝えます。その意味でAIは工程を横断します。しかし、第3.3節の表の「問い」に答えるのは、その業務に責任を持つ人です。
| 工程 | AIが手伝えること（例） | それでも工程が残る理由 |
|---|---|---|
| 02 要件定義 | 聞取りメモから確認事項の候補を洗い出す、要件の下書き | 自己承認を認めるかは、この会社の決定であってAIの一般論ではない（記事A） |
| 08 実装 | 指示書どおりにコードを書く | 何を渡し、何を完成条件にするかは人が決め、初稿を人が確認する（07-03） |
| 09 検証 | テストの下書き、実行、失敗原因の説明 | 期待結果は実装より先に要件から決める。AIの「動作確認済み」は確認の代わりにならない（記事B） |
| 12 障害対応 | ログの整理、照合スクリプト、記録の下書き | 止める・戻す時点・再開の判断と関係者への連絡は人が決める（記事C） |
工程が消えないのは、各工程が「証拠を残す場所」でもあるからです。要件一覧・対応表・実行記録・判定記録は、後から「なぜそう決めたか」「本当に確かめたか」を説明するために残ります。AIが速く作れるほど、この証拠が無いまま先へ進む危険は大きくなります。
4. 判断すること
この記事は地図を作る記事ですが、地図を使うときには3つの判断が要ります。
4.1 この記事で判断すること
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| 今、自分はどの工程にいるか | 工程ごとに「答えるべき問い」と「残すべき成果物」が違う（第3.3節）。位置が分からないと、何を作ればよいかも分からない | 可（迷ったら「前の工程の成果物が手元にあるか」で判定する。無ければまだ前の工程） | 要件が無いのに設計を始め、設計が無いのに実装を始める。AIに頼むと速く進むぶん、気づくのが遅れる |
| 発見があったとき、戻るか、その場でしのぐか | 後の工程で見つかる問題の多くは、前の工程の答えが足りないことが原因（第5.3節） | 不可。戻る先の工程まで決めてから進む | 09で見つけた要件の曖昧さをテスト側の書き換えでしのぐと、検証をやめたのと同じになる（記事B） |
| 今の取り組みは「演習」「限定的な試行」「実業務への導入」のどれか | 段階によって、載せてよいデータ（架空か実データか）と必要な確認が変わる（第5.4節） | 不可。段階を上げるには10-04の条件を満たす | 「ローカルで動いた」を「業務で使ってよい」と取り違え、未確認のものに実際の依頼データを載せる |
4.2 勝手に決めてはいけないこと
- この記事では、各工程の細かい内容（例えば05-02の状態遷移の中身）まで踏み込みません。それぞれの工程の記事で扱います。
- 14大カテゴリのID・名称・順序を、この記事で変更しません（設計書第3節が正本）。
- 工程を飛ばしてよいかどうかを、この記事で決めません。小規模だから省略できる工程はありますが、その判断は第8節の観点で記事ごとに行います。
4.3 AIに任せる範囲
工程の一般的な説明、成果物の下書き、「今どの工程か」を判断するための材料の整理はAIに任せられます。しかし、「戻るか進むか」「演習・試行・導入のどの段階か」の判断は、その業務の責任者が行います。AIは工程を横断して手伝いますが、工程の間の判断は人に残ります（第3.4節）。
5. 作って確かめる：工程と成果物の対応表を作る
5.1 準備
00-01・00-02で確認した用語（登場人物、ファイルとデータの区別）を用意します。
5.2 工程と成果物の対応表
| 大カテゴリ | 目的 | 主な成果物 |
|---|---|---|
| 00．開発を始める前の基礎 | 仕組み・用語・全体像を理解する | アプリの見取り図、基本用語対応表、工程地図（この記事） |
| 01．課題発見・企画 | 業務の困り事と改善の目的を明らかにする | 利用者・関係者の整理表、現状業務フロー、目的・評価指標、企画書 |
| 02．要件定義 | 何を実現するかを確認可能な条件に決める | 業務要件一覧、機能一覧・対象範囲、品質条件一覧、受入条件一覧 |
| 03．開発計画・技術選定 | 制約を確認し、作り方と技術を選ぶ | 制約一覧、方式比較表、技術選定理由書、開発計画 |
| 04．業務・画面の設計 | 利用者の操作と画面を設計する | 操作シナリオ、画面の原型、正常系確認記録、例外時の画面 |
| 05．データ・システム構成の設計 | データ・状態・権限・構成を設計する | データ項目表、状態遷移表、権限表、構成図・復旧方針 |
| 06．開発環境・変更管理の準備 | 作業場所と変更管理のルールを整える | 環境構築手順、環境一覧、変更管理ルール、秘密情報管理ルール |
| 07．AIと進める作業の設計 | AIと協働する作業の進め方を決める | AIへ渡す情報セット、作業分解表、AI作業指示書、AI実行ルール |
| 08．実装 | 実際に動く仕組みを作る | 最小の動作例、保存確認記録、連携の実行記録、修正差分 |
| 09．テスト・レビュー | 実装が要件を満たすかを確かめる | テストケース、要件・テスト対応表、リスク別の検証結果、レビュー記録 |
| 10．導入・受入の準備 | 実際の利用者に確認してもらい、開始可否を決める | 受入確認記録、移行計画、利用手順書、利用開始判定記録 |
| 11．公開・本番移行 | 本番へ安全に配置し、段階的に利用を始める | 公開前チェック結果、配置手順・実行記録、初期利用の確認記録、切戻し手順 |
| 12．運用・障害対応 | 稼働状況を把握し、障害から復旧する | 運用項目一覧、異常時の初動手順、障害対応記録、復元演習記録 |
| 13．保守・改善・引継ぎ・終了 | 改善を続け、必要なら引継ぎ・終了する | 改善要望一覧、変更影響調査、更新・再検証記録、引継ぎ資料 |
この表の「主な成果物」は、この教材の各記事で実際に作っているものです。たとえば02の業務要件一覧と受入条件一覧は記事A、09の要件・テスト対応表は記事B、12の障害対応記録と復元演習記録は記事Cにあります。
5.3 前工程へ戻る例
| 発見した場面 | 戻る先 | 理由 |
|---|---|---|
| 検証（09-02）で「承認者の割当条件が曖昧」と分かる | 02（要件定義） | 誰が承認者になれるかという条件そのものが確認可能になっていなかったため |
| 正常系確認（04-03）で「割り当てられた承認者の一覧を見る画面がない」と分かる | 04-02（画面の原型） | 業務の流れに必要な画面が設計時に抜けていたため |
| 受入確認（10-01）で「差戻し理由が必須である理由が伝わらない」と分かる | 02-04（受入条件） | 受入条件のもとになる要件の説明が不足していたため |
この教材の中で実際に起きた戻りの例も1つあります。10-01の受入確認で「提出時の必須項目チェックが実装に無い」と分かり、10-04ではこれを「08-02へ戻して修正する」未解決問題として扱っています。発見は10で、直す場所は08です。
5.4 適用範囲の注記
| 区分 | 内容 |
|---|---|
| ローカルの演習 | 自分のパソコンの中だけで、架空データを使って一連の流れを確かめる段階。この教材のすべての記事はこの段階を扱う。10-04の判定区分では「演習成功」に当たる |
| 限定的な試行 | 一部門・少人数など、範囲を絞って実際の業務で試す段階。実際に動く画面があり、業務担当者による受入確認で観測した結果があって初めて進める。この教材の題材アプリはこの条件を満たしておらず、10-04で「限定試行へ進む条件」として延期している |
| 実業務への導入 | 業務として広く使い始める段階。限定的な試行で問題がないことを確認してから進む |
これら3つを混同すると、「ローカルで動いたから本番に導入してよい」といった判断の飛躍が起こります。この教材の11〜12の記事（配置・初期利用・障害対応）も、すべて演習の範囲で行っています。
6. 確認結果
第5.2〜5.4節の内容を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 14大カテゴリすべてに目的と成果物が入っている | 第5.2節の表に14行すべて記載 |
| 前工程へ戻る例が2件以上ある | 第5.3節に3件と、教材内で実際に起きた例1件を記載 |
| 「ローカルの演習」「限定的な試行」「実業務への導入」が別の判定として書き分けられている | 第5.4節に3区分を記載し、10-04の判定区分と対応付けた |
残る制限：この対応表は、教材全体の構成を要約した一例です。各工程の詳細は、それぞれの記事で確認する必要があります。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
7. よくある勘違いと直し方
- 成果物さえあれば工程が完了したことになる、という勘違い：成果物は次の工程が使える形になっている必要があります。完了条件（各記事の第7節相当）との照合まで含めて工程の完了とします。
- 戻る先を一つ前の工程だけだと思い込む：第5.3節のとおり、戻る先は発見した内容によって異なり、02（要件）まで戻ることもあります。
- AIに頼めば工程を飛ばせる、という勘違い：AIが速く作れるのは、前の工程の答え（要件・設計）を渡したときです。答えが無いまま頼むと、AIは足りない部分を一般論で埋めます（記事A）。
8. 設計を判断する
8.1 規模によって工程の重さが変わる
| 観点 | 小規模な業務支援アプリ（この教材の題材） | 高リスク・大規模システム |
|---|---|---|
| 要件定義の厳密さ | 主要な役割・状態・条件を確認できれば十分 | 法令・規制、監査対応など、追加の確認が必要になることが多い |
| 検証の範囲 | 主要な機能・権限・重複操作の確認が中心 | 大規模な負荷試験、第三者機関による監査などが必要になることが多い |
| 運用・復旧の目標 | 小さな損失・短い停止時間を許容できることが多い | 停止や損失の許容度が極めて低いことが多い |
この教材は、みらい業務サービスという架空の小規模な社内アプリを題材にしています。同じ14工程の順序を使っても、高リスク・大規模なシステムでは、各工程での確認がこの教材よりはるかに厳密になります。
8.2 適用限界
この教材は、小規模な社内業務アプリを想定した初版であり、金銭支払・医療行為・銀行取引などの高リスク業務は題材にしていません（設計書5.1）。それらの業務にこの教材をそのまま適用することはできません。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 工程と成果物の対応表・戻り経路の例・適用範囲の注記ひな形 | templates/00-03-process-map_template.md | templates/00-03-process-map_example.md |
自分の業務に使うときの手順は次のとおりです。
- 自分が今どの工程にいるかを、前の工程の成果物が手元にあるかで確認する（第4.1節）
- その工程が答える問いと、残す成果物を確認する（第3.3節）
- 検証や試作で問題が見つかったら、戻る先の工程を判断する
- 今の取り組みが「演習」「試行」「導入」のどの段階かを明確にする
10. 次工程への受渡し
次へ渡すもの：工程と成果物の対応表、戻り経路の例、適用範囲の区分。
次工程での使われ方：01〜13の各記事は、この対応表を全体の中の自分の位置として参照します。00-04では、第3.4節の「AIが手伝えること・人に残ること」を役割表として決めます。
前工程へ戻る条件：この記事の対応表と、実際の各記事の内容に食い違いが見つかったら、00-01・00-02に戻って用語・見取り図を確認します。
11. 根拠と更新情報
- この記事の会社・人物・工程例はすべて架空の設定です。
- 14大カテゴリのID・名称・順序、段階的な拡張の考え方は、教材設計書
AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第3節・第5.5節に基づきます。 - 各工程の目的・成果物は、
docs/CONTENT_MAP.mdの該当する中カテゴリの記載を要約したものです。 - 第3.4節の「AIが手伝えること・工程が残る理由」は、
docs/content/LEARNING_UNIT_SPEC_V1.md第6節（人とAIの責任分界）に基づきます。 - 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 2026-09-20（Phase 5B-1）：Integration型のPilotとして、読む順路（3つの深さ）、第3.3節「工程がこの順につながる理由」、第3.4節「AIは工程を横断するが、工程は消えない」、第4節の判断項目、記事間の参照を追加した。第5.4節の「限定的な試行」の説明を、10-04（Remediation Phase 1で「演習成功」に改めた判定）と整合する内容に修正した（初版は「11-03で扱う」としていたが、11-03は演習であり限定的な試行ではない）。対応表・完了条件・成果物は変えていない。
- 未確認事項：この対応表と各工程の記事本文との整合性は、各記事が完成するたびに継続して確認する必要があります。