「このAPI変更は開発チームでお願いします」と任された。しかし、画面の文言を誰が決めるのか、利用側への影響を誰が確認するのか、本番反映を誰が承認するのかは決まっていない。実装担当が全部を抱えたり、最後のレビューで判断が止まったりします。
この場面では、作業者を増やす前に、実行者・確認者・判断者を分けます。特に一つの判断に最終責任を持つ人を明記します。 その人が全ての情報を一人で集めるという意味ではありません。判断材料を作る人、影響を確かめる人と組み合わせます。
以下は架空の問い合わせ管理アプリで、件名の文字数エラーをAPIから返す変更を例にします。
「担当者」一列だけでは詰まりどころが隠れる
| 仕事 | 実行者 | 確認者 | 判断者 |
|---|---|---|---|
| 100文字上限とエラー文言の仕様を決める | 仕様担当が候補と利用者影響を整理 | 画面担当・API利用側が理解可能か確認 | 仕様責任者が最終決定 |
| APIの応答形式を設計・実装する | API担当エンジニア | 別のエンジニアとAPI利用側が互換性を確認 | 技術責任者が公開契約の変更を決定 |
| 100文字／101文字の動作を確認する | テスト担当または実装担当 | API利用側が実際の扱いを確認 | 不一致時の仕様判断は仕様責任者 |
| 本番へ反映する | リリース実行者 | 監視・利用側の確認者 | リリース判断者が続行・切り戻しを決定 |
一人が複数の欄に入る小さなチームもあります。その場合も役割を分けて書きます。「実装したので自分で仕様変更も承認した」ことと「実装者が自分の動作を一次確認した」ことは、影響が違うからです。権限や独立確認が必要な箇所は、チームの規程に従います。
最終判断者は、質問ごとに変わる
「リーダーが全て決める」とすると、判断が集中します。件名の上限は業務仕様の話、エラー応答形式はAPIの公開契約の話、本番反映は稼働リスクの話です。それぞれの判断を持つ人が違ってよいのです。
一方、同じ問いに二人の最終判断者を置くと、意見が割れたとき決まりません。例えば「101文字を受け付けるか」は仕様責任者一人へ、「エラーをどう表現するか」は技術責任者一人へ割り当てます。判断前にはAPI利用側や運用側の情報を集めます。
| 迷いやすい状況 | 先に決めておくこと |
|---|---|
| 判断者が不在 | 代行者と代行できる範囲。期限までに決められない場合の扱い |
| 確認者が反対 | 反対の根拠を記録し、最終判断者へ選択肢として渡す |
| 作業中に影響範囲が拡大 | 実行者が止め、変更要求として再判断する条件 |
| 本番で想定外の結果 | リリース判断者と連絡方法、切り戻し条件 |
「決定者を一人」と書いても、その人を無限の相談窓口にしてはいけません。判断期限、必要な情報、代行条件を決めることで、担当者の不在が全作業の停止にならないようにします。
この表を作るときの順番
最初に仕事を細分化しすぎる必要はありません。まず、後戻りが大きい判断を三つほど選びます。上の例では仕様、公開API、本番反映です。次に、各判断に必要な材料を出す実行者と、影響を受ける確認者を置きます。最後に、期限と不在時の代行を付けます。
既存の記事開発が遅れたら増員すればいい？では、人数を増やす前に分割できる仕事と受入負荷を確認する話をしました。今回の表はその次の一歩です。渡す仕事の境界と、誰が結果を受け取り判断するかが分かれば、追加メンバーも動きやすくなります。
分業と全体の一貫性を考える副読本として、『人月の神話【新装版】』の書誌を確認できます。この記事の役割表は本の収録表を再現したものではありません。リーダー候補の本棚（Amazon・アフィリエイトを含みます）で案内しています。
今の案件で曖昧になっている判断を一つ挙げ、実行者・確認者・最終判断者を一行に書いてください。名前を埋められない欄が、次に相談すべき場所です。
