並行開発できるタスクに分解する
インターフェース契約で切り、互いを待たずに着手できるようにする
あなたはテックリードです。以下の要件を、並行して進められるタスクに分解してください：1）まず並行にできない順序制約（データモデル、インターフェース契約、移行）を特定する；2）それ以外を「1 人が 1 週間で独立して届けられる」単位に切り、入力・出力・受け入れ条件を書く；3）依存の向きと着手可能日を示す；4）共有ファイルやモジュールの衝突しやすい箇所と、その避け方を挙げる。フロントエンド／バックエンドのような粗い分け方ではなく、独立して検証できる成果物で分けてください。 ［要件／現行システム／チーム規模］
使い方
並行度は、インターフェース契約をいつ固定できるかで決まります。契約が未確定のまま着手すると、結合時に手戻りが発生します。
向いている場面
- 3〜5 人のチームで、複数領域にまたがる機能を 1 イテレーションで届ける必要があります。しかし、どこから手を付けるのか誰も説明できません。
- 要件は合意済みですが、どの見積もりも「誰かが先にやる」前提になっています。
向いていない場面
- 作業者が 1 人だけなら、並行化は調整コストだけを増やし、利益はありません。
- 重要な曖昧さが残っている場合（クーポンの適用可否を誰が決めるか、一部失敗時にどうするか）は、先に明確にしてから分解します。
例
入力
要件：既存の注文 API にクーポンを追加する。フロントはクーポンを選び、バックエンドは検証し、運用はクーポンを設定する。バックエンド 3 人、フロント 1 人、2 週間。
得られるもの
まず、クーポン検証 API、エラーコード、クーポンのデータ構造という契約を一つ固定します。その後、クーポン設定の CRUD、注文時の検証、フロントのクーポン選択に分け、設定はデータ構造に、選択は契約に依存させます。`OrderService` と API schema は衝突しやすい箇所なので、契約担当だけが編集し、他は読むだけにします。
よくある誤用
- 「フロント／バックエンド／テスト」の三つに分けることです。各グループが依然として他を待つため、実際の並行度はほぼゼロです。
- 受け入れ条件を書かないことです。結合時に意味のずれが見つかり、手戻りが直列作業より高くつきます。
こう変えると効く
- 「mock で先に開発できる部分を示す」と加えると、バックエンドが使える前からフロントが動き出せます。
- 「契約の固定期限を出す」と求めると、並行計画が願望ではなく期限付きの制約になります。