# 作業分解・依存関係表ひな形（記入例）

架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「「承認処理」を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. 完了条件の確認

- [x] 各作業に確認方法がある
- [x] 依存関係が明示され、循環していない
- [x] 並行作業時の衝突しやすい箇所が書かれている

## 4. 次工程へ渡すもの

- [x] 作業分解・依存関係表（第1〜2節）
- [ ] 承認者：総務課長（架空）— 記入例のため未承認の扱い