架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。 記事「「承認処理」を4つの作業に分け、依存関係と衝突しやすい箇所を書く」（07-02）の本文で使った内容をまとめたもの。空欄版は 07-02-task-breakdown_template.md。

1. 作業分解・依存関係表

作業入力出力確認方法依存する作業
1. 状態の確認依頼の現在の状態「提出済みかどうか」の判定結果各状態を入力して判定結果を確認するなし
2. 権限の判定操作者の役割、割当情報「割当承認者かつ自己承認でないか」の判定結果割当外・自己承認のケースで拒否されることを確認する1
3. 状態変更と履歴追加判定結果（1・2が正常な場合）状態の更新、履歴の追加状態変更と履歴追加が両方完了することを確認する1、2
4. 重複対策同一操作の識別情報二重処理の防止結果同じ操作を2回実行し、履歴が1件のままであることを確認する3

2. 並行作業時（開発時）に衝突しやすい箇所

開発中に人とAI（または複数の開発者）が同じコードに手を入れることで起きる衝突。利用者どうしの同時更新（承認と再提出の入れ違いなど）は別の問題で、05-02・09-03で扱う。

箇所なぜ衝突しやすいか対処
作業1と作業2（同じ判定関数）状態の確認と権限の判定を同じ関数に同時に足すと、条件の順序や戻り値がかみ合わない作業1を先に終えて確認してから作業2に着手する。同じ関数に同時に2人が手を入れない
作業3と作業4（同じ保存処理）状態変更と履歴追加に重複対策を同時に足すと、「1回の書き込み」の約束（REQ-007）が崩れる作業3の確認が済んでから作業4に着手する
AIに複数の作業を一度に頼む場合指示された範囲を超えて隣の作業のコードも書き換えることがある1回の指示は1つの作業に限定し、変更されたファイルの差分を合流前に確認する

同時に触れてよい範囲の基準：1つの関数につき同時に1人（人またはAI）。別のファイルなら並行してよいが、合流時に差分を確認する。

3. 完了条件の確認

4. 次工程へ渡すもの