エンジニアの作業方針書テンプレート｜PRが一発承認される設計文書の書き方・背景-目的-成功条件-ロールバックの7セクション構成術【2026年版】

なぜ「すぐコードを書く」と手戻りが発生するのか

タスクを受け取ったらすぐにコードを書き始める——これは多くのエンジニアが無意識にやっている行動です。しかし、この「即着手」が手戻りの最大の原因であることは、多くの開発現場で実証されています。

手戻りが発生する構造的な理由は明確です。「何をやるか」が曖昧なまま実装に入ると、レビューの段階で「そもそもスコープが違う」「なぜこの方法なのか不明」「ロールバック手順がない」と差し戻されるからです。

本記事では、PRが一発承認されるための「作業方針書」のテンプレートと書き方を、実際の開発チームで運用されている手法に基づいて解説します。

作業方針書とは何か——設計書でもチケットでもない

作業方針書は、一般的な設計書（PRD/FRD/SRS）やチケット説明とは異なる独自のドキュメントです。

ドキュメント	目的	読み手	粒度
PRD	ユーザー視点で何を作るか	PM・ビジネス	機能要件レベル
設計書	システム全体の構造を定義	アーキテクト・チーム全体	システム設計レベル
チケット	タスクの割り当て・進捗管理	チーム全体	タスクレベル
作業方針書	「このPRで何を、なぜ、どう変えるか」を事前合意する	レビュアー・上長	PR（コミット）レベル

作業方針書の価値は、実装前にレビュアーと方向性を合意できることにあります。コードを書いてからレビューで「そもそもアプローチが違う」と言われるのと、書く前に合意を得てから着手するのでは、手戻りのコストが桁違いです。

作業方針書の7セクション・テンプレート

1. 背景・経緯

なぜこの作業が必要なのかを記載します。単に「○○を修正する」ではなく、ビジネス上の問題から説明します。

悪い例：「認証基盤を除去する」

良い例：「お客様の閉域VM環境にデプロイする上で、認証サーバーのない環境でNextAuth認証チェックが全ページで走っている。これが起動遅延やエラーの原因になりうるため、認証基盤を除去する」

2. 現状の問題

問題を具体的なコードの現状まで落とし込みます。

• 「DBにprogressフィールドが存在するが、変換中に動的に更新されていない」
• 「onProgressコールバックは11箇所で呼び出されているが、DBには開始時(0)と完了時(100)しか書き込まれない」
• 「つまりフロントエンドからは0%か100%しか見えない状態」

コードベース調査の結果も記載します。「叩き（初版）では未記載だったが、コードベース調査で判明」——調査で新たに分かった事実を明記することで、方針の精度が上がります。

3. 対象ファイルと修正内容

変更対象のファイルを具体的にリストアップし、各ファイルの現状→修正後を明記します。

フォーマット例

対象ファイル:
- src/lib/fortran-conversion-service.ts（主な変更）
- src/agents/fortran-converter-agent.ts（インターフェース変更）

修正内容:
1. executeAndObserve の呼び出し位置をエージェント内部からサービス層に引き上げ
2. エージェント側のStage 0.5ブロックを削除し、サービス層から渡されたデータを受け取る形に変更

変更しないもの:
- fortran-execution-service.ts（実装自体は変更なし）
- テストファイル（既存E2Eはモック化済みで影響なし）

「変更しないもの」を明示することが重要です。これにより、レビュアーが「この修正の影響範囲はここまで」と安心できます。

4. 成功条件

PRマージ後の「完了状態」を客観的に定義します。曖昧な表現は避け、検証可能な条件にします。

• yarn buildがエラーなく完了すること
• 環境変数未設定時にデフォルト値で動作すること（既存の動作が変わらないこと）
• 変換実行中にDBのprogressが段階的に更新されること
• SSE接続失敗時にポーリングにフォールバックすること
• Before/Afterのスクリーンショットを成果物に含めること

5. コミット分割計画

PRを構成するコミットを事前に計画します。

コミット計画（6コミット）:
1. feat: バックエンド進捗更新ロジック修正
2. feat: SSEエンドポイント追加
3. feat: Progressバー + ステップインジケータ表示
4. feat: SSEクライアントフック + フォールバック
5. feat: 状態変化時トースト通知 + タブタイトル変更
6. feat: 行レベルローディング表示

コミットを機能単位で分割することで、問題発生時に特定のコミットだけgit revertできます。

6. 前提が崩れた場合

このセクションが作業方針書の最重要パートです。「前提が違っていた場合にどうするか」を事前に定義しておくことで、パニック時の判断ミスを防ぎます。

• 「ビルドエラーが出た場合はgit revertで戻し、importの依存関係を調査して報告する」
• 「SSE実装が複雑になる場合は、ポーリング＋進捗バー表示のみに絞り、SSEは将来課題とする」
• 「前提が違っていた/修正しても変わらなかった場合は自己判断せず相談する」

特に重要なのは「自己判断せず相談する」という安全弁です。想定外の事態で実装を続行してしまうリスクを明示的に防ぎます。

7. 相談事項（オプション）

方針策定の過程で生じた設計判断の分岐点を、レビュアーに提示します。

フォーマット例

相談事項:

セッション単位でZIPを切る方針
- 既存の日付単位ログDL導線との役割が重複・矛盾しないか
- 確認観点: この切り分けで問題ないか

ファイル保存 vs DB保存
- MVPではファイルベースで実装し、将来的にDB保存へ寄せる余地を残す
- 確認観点: 永続化・容量管理の観点で懸念があれば指摘いただきたい

作業方針書の提出ワークフロー

作業方針書は以下のワークフローで運用します。

ステップ1：叩き（初版）の作成

概要レベルの方針を作成し、レビュアーに提出します。この段階では完璧である必要はなく、方向性の確認が目的です。

ステップ2：フィードバックの反映

「何がなぜ必要かわからない」「スコープが広すぎる」といったフィードバックを受け、方針を精緻化します。よくあるフィードバックパターンと対応：

• 「なぜ必要かわからない」 → 背景セクションにビジネス上の問題を追記
• 「影響範囲が不明」 → 「変更しないもの」リストを追加
• 「PRが大きすぎる」 → レイヤー別に分割

ステップ3：セルフレビュー

確認依頼の前に必ずセルフレビューを実施します。チェック観点：

• 成功条件が検証可能か（「正常に動作する」ではなく具体的なコマンドや画面確認手順があるか）
• 対象ファイルに漏れがないか
• コミット分割が機能単位になっているか
• ロールバック手順が明確か

ステップ4：確認依頼

「確認依頼。成果物：○○の作業方針。セルフレビュー済みです」——このフォーマットで提出します。レビュアーが「方針OK、作業着手してください」と返したら、初めてコードを書き始めます。

レビュー観点の設計

作業方針書のレビュアーは、以下の6つの観点で確認します。これをテンプレート化しておくと、レビュー品質が安定します。

1. スコープの妥当性：合意した改善項目を漏れなくカバーしているか。スコープ外のものが混入していないか
2. 対象の網羅性：関連するファイル・コンポーネント・APIが全て特定されているか
3. 技術的整合性：既存のアーキテクチャと矛盾しない設計になっているか
4. 動作確認方法：成功条件が具体的で検証可能か
5. 優先順位・依存関係：PR間・コミット間の依存が明示されているか
6. 前提崩壊時の対応：ロールバック手順が用意されているか

AIエージェントを活用した作業方針書の作成

AIコーディングエージェントは、作業方針書の作成を大幅に効率化します。

AIに任せるべき部分

• コードベース調査：対象ファイルの特定、import依存の分析、現状の挙動の調査
• 叩き（初版）の作成：背景・現状の問題・修正内容の初版を自動生成
• 影響範囲の分析：「変更しないもの」リストの自動生成

人間が判断すべき部分

• 「なぜ」の説明：ビジネス上の必要性は人間が記述
• 成功条件の定義：何をもって「完了」とするかの判断
• 前提崩壊時の対応：想定外の事態でどう動くかの意思決定
• 相談事項の抽出：レビュアーに確認すべき設計判断の分岐点

タスクを受け取ったら、まずAIにコードベース調査を依頼し、その結果を基に人間が「なぜ」と「成功条件」と「ロールバック」を書く——このハイブリッドアプローチが最も効率的です。

作業方針書が不要なケース

すべてのPRに作業方針書が必要なわけではありません。

• typo修正・1ファイル変更：コミットメッセージで十分
• 既存パターンの踏襲：「○○と同じ方法で△△を追加」で済む場合
• 緊急の障害対応：修正を優先し、事後に方針を文書化

目安として、3ファイル以上の変更または新規ファイルの作成を伴うPRでは、作業方針書を書くことを推奨します。

まとめ：作業方針書チェックリスト

セクション	チェック項目	完了基準
背景	ビジネス上の問題が記載されているか	「なぜ必要か」が非エンジニアにも伝わる
現状の問題	コードレベルの具体的な問題が記載されているか	ファイル名・行番号まで特定
修正内容	対象ファイルと変更内容が網羅的か	「変更しないもの」リスト含む
成功条件	検証可能な条件か	コマンドや画面確認手順が明記
コミット計画	機能単位で分割されているか	各コミットが独立してrevert可能
前提崩壊	ロールバック手順があるか	「自己判断せず相談する」安全弁含む
相談事項	設計判断の分岐点が提示されているか	確認観点が明記

「コードを書く前に方針を書く」——この一手間が、手戻りをなくし、レビュー通過率を劇的に向上させます。まずは次のPRから、本記事のテンプレートを使って作業方針書を書いてみてください。

関連記事

• デプロイ障害の6ステージ切り分け
• 作業方針書テンプレート
• ポストモーテム設計
• 納品前セキュリティ検品

開発プロセスの改善はrenueにご相談ください。