開発計画・技術選定学習記事全11節Design
「最初に一巡させる範囲」を区切り、作業・順序・費用・役割を決める
この記事で身につくこと作業を小さく分け、依存関係と完了条件を置き、費用の見積条件とリスクへの対処を決める理由を説明し、最初に一巡させる範囲を選んだ理由を書ける。
記事内目次（25項目）
この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。03-03で決めた技術を前提に、これから行う作業を小さく分け、順序・担当・完了条件・費用の見積条件・リスクへの対処をまとめた開発計画を作る話です。
なぜ必要か。作業を分けずに「全部まとめて作る」と進めると、どこまで進んだか分からなくなったり、途中で問題が起きた時にどこに影響するか分からなくなったりします。
この記事を読むとできるようになること。
- 作業を小さく分け、依存関係と完了条件を置き、費用の見積条件とリスクへの対処を決める理由を説明できる
- 「架空データで依頼作成→提出→承認の一巡」を最初の区切りにした開発計画を、担当・完了条件・前提とともに作れる
- 段階的拡張の順序を、失敗の影響と不確実性から比較し、最初に一巡させる範囲を選んだ理由を書ける
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「作業の分け方」と「計画表の形」が分かり、ひな形を埋め始められます。
- 作って確かめる：上に加えて第6節（失敗例と直し方）→第7節。
- 設計判断を深める：上に加えて第8節（段階的拡張の順序、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、03-03で決めた技術を前提に、これから行う作業を小さく分け、開発計画（作業、順序、依存、担当、完了条件、費用の見積条件、リスクと対処）を作ることです。
技術が決まっても、「何を、どの順番で、誰が、どこまでやれば完了か」が決まっていなければ、作業が始められません。この記事では、最初に一巡させる範囲を区切ったうえで、その範囲の開発計画を作ります。
この記事を読み終えると、次のものが手元にできます。
- 開発計画（作業、順序、依存、担当、完了条件、費用の見積条件、リスクと対処）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
依存関係
一言でいうと、ある作業を終わらせないと次の作業を始められない、という順番の制約です。たとえば、画面の項目が決まっていなければ、その項目を保存する仕組みは作れません。
これがないと、依存する作業を先に終わらせないまま並行して進めてしまい、後戻りが発生します。
費用の見積条件
一言でいうと、「この前提（利用者数・作業範囲など）であれば、これくらいの費用になる」という、前提とセットになった費用の目安です。確定した金額と区別して扱います。
最初に一巡させる範囲
一言でいうと、依頼の作成から提出、承認までの一連の流れを、最小限の形で最初に動かしてみる範囲です。設計書第5.5節「段階的拡張」の考え方に基づき、この記事では「架空データで依頼作成→提出→承認の一巡」を最初の区切りとします。
役割表
一言でいうと、誰が何を担当するかの一覧です。この業務では、記事Aで確認したとおり、依頼者・承認者・運用管理者という役割がすでにあります（運用管理者を「総務の担当者1名」とする人数は、03-01が置いた教材上の仮定です）。この記事では、そこに開発を担当する人・AIを加えて整理します。
読む順路：技術選定の結果は03-03が該当します。次工程の作業単位・作業分解は04-01以降が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。
3. 理解する：なぜ作業を分け、範囲を区切るか
3.1 作業を分ける理由
| 分けないとどうなるか | 分けるとどうなるか |
|---|---|
| どこまで進んだか分からない | 作業ごとに完了条件があり、進み具合が分かる |
| 問題が起きた時にどこに影響するか分からない | 依存関係が書いてあるので、影響範囲が分かる |
| 費用が「作ってみないと分からない」まま進む | 費用の見積条件が前提とセットで書いてある |
3.2 最初に一巡させる範囲を区切る理由
設計書第5.5節「段階的拡張」では、最初から全機能を作るのではなく、小さく動く状態を作ってから広げていく考え方が示されています。この記事では、02-02の機能一覧のうち、依頼の作成・提出・承認・差戻しという一連の流れ（記事Aの業務課題そのもの）を「最初に一巡させる範囲」とします。理由は、この一巡が動けば、依頼者・承認者という異なる役割の連携が確認でき、02-02の残りの機能（一覧の絞込みなど）は、この一巡の上に追加できるためです。
3.3 よくある誤解
「計画は最初に全部決めておくべき」。作業を進めるうちに分かることもあります。この記事の計画は「最初に一巡させる範囲」に絞り、その先は04以降の記事で具体化します。
「費用は作ってみるまで分からないので、見積もらなくてよい」。前提条件つきの見積もりであれば、作る前でも出せます。前提が変わったら見積もりも変わる、という形で扱います（第3.1節）。
「役割は依頼者・承認者だけでよい」。開発を進める人・AIも役割の一つです。誰が何を担当するかを役割表に含めます。
「AIに計画を作らせればよい」。AIは作業の一般的な分け方を提示できますが、この業務でどこまでを「最初の一巡」とするかは、02-02の機能一覧に基づいて人が判断します（第4.3節）。
4. 判断すること
4.1 何を確認すればよいか
| 確認すること | この記事での扱い |
|---|---|
| 「最初に一巡させる範囲」に、依頼作成・提出・承認・差戻しの一連の流れが含まれているか | 第3.2節・第5.2節で確認する |
| 各作業に担当（人／AI）・完了条件・前提があるか | 第5.2節で確認する |
| 費用が見積条件つきで、確定値と区別されているか | 第5.2節で確認する |
4.2 勝手に決めてはいけないこと
- 03-03で決めた技術選定の結果を、この記事で変更しません。
- 02-02の機能一覧にない作業を、この記事で新たに追加しません。
- 見積条件つきの費用を、確定した金額であるかのように書きません。
4.3 AIに任せる範囲
作業の一般的な分け方、依存関係の整理はAIに任せられます。しかし、どこまでを「最初に一巡させる範囲」とするか、誰が何を担当するかは、この業務固有の判断であり人が行います。
5. 作って確かめる：開発計画を作る
5.1 準備
03-03の技術選定理由書、02-02の機能一覧、03-01で確認した役割（依頼者・承認者・運用管理者）を用意します。
5.2 開発計画（最初に一巡させる範囲）
| 作業 | 順序 | 依存 | 担当 | 完了条件 | 費用の見積条件 | リスクと対処 |
|---|---|---|---|---|---|---|
| 画面の原型を作る | 1 | なし | 開発担当（人・AI協働） | 依頼作成・一覧・詳細の3画面の項目が定義されている | 画面数3、項目数が少数という前提での見積り | 項目が後から増えると見積りが変わる。増えたら見積りを更新する |
| データ項目を洗い出す | 2 | 1に依存 | 開発担当（人・AI協働） | 画面の項目と対応するデータ項目の一覧ができている | 1と同じ前提 | 画面の項目が変わるとやり直しになる。1の完了後に着手する |
| 状態遷移を設計する | 3 | 2に依存 | 開発担当（人・AI協働） | 下書き・提出済み・差戻し・承認済みの4状態と遷移が図か表になっている | 状態数4という前提での見積り | 状態が後から増えると見積りが変わる |
| 依頼作成〜提出〜承認の一連の処理を実装する | 4 | 1・2・3に依存 | AIが実装、人がレビュー | 架空データで依頼作成→提出→承認→差戻し→再提出が一通り動く | 「最初に一巡させる範囲」に限定した前提での見積り | 実装中に02-02の機能一覧との食い違いが見つかったら、02-02に立ち返って確認する |
| 自動テストを用意する | 5 | 4に依存 | AIが作成、人がレビュー | 一連の処理について、正常時と異常時（差戻し後の再提出など）のテストがある | 4と同じ前提 | テストで見つかった不具合は4に戻って修正する |
| 受入確認を行う | 6 | 5に依存 | 依頼者役・承認者役（人） | 架空データでの一連の流れを、依頼者役・承認者役が実際に操作して確認できる | 4・5と同じ前提 | 確認で見つかった問題は、影響する作業（1〜5）に戻って対処する |
5.3 AIに計画の下書きを頼む
作業の一般的な分け方と依存関係の下書きをAIに作らせます。
依頼・承認管理アプリの「架空データで依頼作成→提出→承認の一巡」を最初に作ります。02-02の機能一覧（作成・提出・承認・差戻し・一覧閲覧）を渡します。
依頼：
1. この範囲を実現するための作業を、依存関係が分かる順序で挙げてください。
2. 各作業に、完了条件の案を付けてください。
してはいけないこと：
- 02-02にない機能（一覧の絞込みなど、最初の一巡に含めないもの）を作業に含めないでください。
- 費用の確定額を断定しないでください。前提条件つきの見積りとしてください。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。
- 「一覧の絞込み機能」など、02-02の機能一覧にはあるが「最初の一巡」には含めない機能まで作業に混ぜて記載
- 「開発費用は総額◯◯円です」と、前提条件を示さずに確定額のように記載
6.2 見つけ方と直し方
- 範囲外の機能が混ざっている：「最初に一巡させる範囲」（第3.2節）の定義に合いません。一覧の絞込み機能を作業から除外します。
- 費用が確定額のように書かれている：完了条件「費用は見積条件付きで確定値と区別」を満たしません。前提条件（画面数、状態数など）を明記し、見積りであることを明確にします。
指摘：
1. 一覧の絞込み機能は、最初に一巡させる範囲に含まれません。作業から除いてください。
2. 費用は前提条件つきの見積りとして書き直してください。確定額のように書かないでください。
変えないこと：
- 02-02・03-03の内容そのものは変更しないでください。6.3 修正後の計画
修正後の開発計画は、第5.2節のとおりです。
7. 確認結果
第5.2節の計画を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 各作業に完了条件と担当がある | 6作業すべてに完了条件・担当を記載 |
| 依存関係が矢印か番号で示されている | 「順序」列（番号）と「依存」列に前作業の番号を記載 |
| 費用が見積条件付きで、確定値と区別されている | 各作業の「費用の見積条件」列に前提条件を明記し、確定額は記載していない |
残る制限：この計画は架空の機能一覧・技術選定に基づく一例です。実際の作業時間・費用は、実装を進めてみないと分からない部分があります。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 段階的拡張の順序を、失敗の影響と不確実性から比較する
| 選択肢 | 失敗した場合の影響 | 不確実性 |
|---|---|---|
| 最初から全機能（一覧の絞込みなども含む）を一度に作る | 失敗した場合、どこに原因があるか切り分けにくい | 機能が多い分、見積りの前提が崩れやすい |
| 「架空データで依頼作成→提出→承認の一巡」を最初に区切る（採用） | 失敗しても影響範囲が一巡の中に限られ、切り分けやすい | 範囲が小さい分、見積りの前提が保ちやすい |
失敗の影響を小さくし、見積りの前提を保ちやすくするという理由から、最初に一巡させる範囲を区切る方法を採用します。
8.2 適用限界
この記事の計画は、架空企業「みらい業務サービス」の小規模な社内利用を前提にしています。最初の一巡が完了した後、02-02の残りの機能（一覧の絞込みなど）をどの順序で追加するかは、この記事の範囲外であり、04以降の記事で扱います。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 開発計画ひな形（作業、順序、依存、担当、完了条件、費用の見積条件、リスクと対処） | templates/03-04-plan-roles_template.md | templates/03-04-plan-roles_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（03-03の技術選定結果、02-02の機能一覧）を用意する
- 「最初に一巡させる範囲」を区切る
- その範囲を実現する作業を、依存関係が分かる順序で挙げる
- 各作業に担当・完了条件・費用の見積条件・リスクと対処を書く
10. 次工程への受渡し
次へ渡すもの：開発計画（最初に一巡させる範囲の作業・順序・担当・完了条件・費用の見積条件・リスクと対処）。
次工程での使われ方：04以降の記事では、この計画の作業単位（画面の原型、データ項目、状態遷移など）を、それぞれ具体化していきます。07-02（作業分解）では、この計画をより細かい作業に分解します。
前工程へ戻る条件：実装を進める中で02-02の機能一覧と食い違いが見つかったら、02-02に戻って機能一覧を確認します。
11. 根拠と更新情報
- この記事の会社・人物・計画・費用はすべて架空の設定です。
- 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- 「最初に一巡させる範囲」を区切るという考え方は、教材設計書
AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第5.5節「段階的拡張」に基づきます。 - 役割表は、記事Aおよび03-01ですでに確認した役割（依頼者・承認者・運用管理者）に、開発担当（人・AI）を加えて整理したものです。00-04（役割表）の記事本文は本記事作成時点では未作成であり、独立した記事としての参照はできません。
- 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 未確認事項：実際の作業時間・費用は架空の見積りであり、実際の開発では前提条件が変わる可能性がある。