架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。 記事「「最初に一巡させる範囲」を区切り、作業・順序・費用・役割を決める」（03-04）の本文で使った内容をまとめたもの。空欄版は 03-04-plan-roles_template.md。

1. 開発計画（最初に一巡させる範囲）

作業順序依存担当完了条件費用の見積条件リスクと対処
画面の原型を作る1なし開発担当（人・AI協働）依頼作成・一覧・詳細の3画面の項目が定義されている画面数3、項目数が少数という前提での見積り項目が後から増えると見積りが変わる。増えたら見積りを更新する
データ項目を洗い出す21に依存開発担当（人・AI協働）画面の項目と対応するデータ項目の一覧ができている1と同じ前提画面の項目が変わるとやり直しになる。1の完了後に着手する
状態遷移を設計する32に依存開発担当（人・AI協働）下書き・提出済み・差戻し・承認済みの4状態と遷移が図か表になっている状態数4という前提での見積り状態が後から増えると見積りが変わる
依頼作成〜提出〜承認の一連の処理を実装する41・2・3に依存AIが実装、人がレビュー架空データで依頼作成→提出→承認→差戻し→再提出が一通り動く「最初に一巡させる範囲」に限定した前提での見積り実装中に機能一覧との食い違いが見つかったら、機能一覧の記事に立ち返って確認する
自動テストを用意する54に依存AIが作成、人がレビュー一連の処理について、正常時と異常時（差戻し後の再提出など）のテストがある4と同じ前提テストで見つかった不具合は4に戻って修正する
受入確認を行う65に依存依頼者役・承認者役（人）架空データでの一連の流れを、依頼者役・承認者役が実際に操作して確認できる4・5と同じ前提確認で見つかった問題は、影響する作業（1〜5）に戻って対処する

2. 完了条件の確認

3. 次工程へ渡すもの