株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
なぜ「すぐコードを書く」と手戻りが発生するのか
タスクを受け取ったらすぐにコードを書き始める——これは多くのエンジニアが無意識にやっている行動です。しかし、この「即着手」が手戻りの最大の原因であることは、多くの開発現場で実証されています。
手戻りが発生する構造的な理由は明確です。「何をやるか」が曖昧なまま実装に入ると、レビューの段階で「そもそもスコープが違う」「なぜこの方法なのか不明」「ロールバック手順がない」と差し戻されるからです。
本記事では、PRが一発承認されるための「作業方針書」のテンプレートと書き方を、実際の開発チームで運用されている手法に基づいて解説します。
作業方針書とは何か——設計書でもチケットでもない
作業方針書は、一般的な設計書（PRD/FRD/SRS）やチケット説明とは異なる独自のドキュメントです。
| ドキュメント | 目的 | 読み手 | 粒度 |
|---|---|---|---|
| PRD | ユーザー視点で何を作るか | PM・ビジネス | 機能要件レベル |
| 設計書 | システム全体の構造を定義 | アーキテクト・チーム全体 | システム設計レベル |
| チケット | タスクの割り当て・進捗管理 | チーム全体 | タスクレベル |
| 作業方針書 | 「このPRで何を、なぜ、どう変えるか」を事前合意する | レビュアー・上長 | PR（コミット）レベル |
作業方針書の価値は、実装前にレビュアーと方向性を合意できることにあります。コードを書いてからレビューで「そもそもアプローチが違う」と言われるのと、書く前に合意を得てから着手するのでは、手戻りのコストが桁違いです。
作業方針書の7セクション・テンプレート
1. 背景・経緯
なぜこの作業が必要なのかを記載します。単に「○○を修正する」ではなく、ビジネス上の問題から説明します。
悪い例：「認証基盤を除去する」
良い例：「配布先では認証サーバーを利用できません。現在はすべてのページで認証を確認しているため、起動が遅くなったり、エラーになったりする可能性があります。そのため、配布先で動作できるよう認証処理を切り離します」
2. 現状の問題
問題を具体的なコードの現状まで落とし込みます。
- 「進捗情報がデータベースに保持されているが、処理中に動的に更新されていない」
- 「進捗通知は処理中に複数回発生するが、記録されるのは開始時と完了時のみ」
- 「つまりフロントエンドからは0%か100%しか見えない状態」
コードベース調査の結果も記載します。「叩き（初版）では未記載だったが、コードベース調査で判明」——調査で新たに分かった事実を明記することで、方針の精度が上がります。
3. 対象ファイルと修正内容
変更対象のファイルを具体的にリストアップし、各ファイルの現状→修正後を明記します。
フォーマット例
「変更しないもの」を明示することが重要です。これにより、レビュアーが「この修正の影響範囲はここまで」と安心できます。
4. 成功条件
PRマージ後の「完了状態」を客観的に定義します。曖昧な表現は避け、検証可能な条件にします。
yarn buildがエラーなく完了すること- 環境変数未設定時にデフォルト値で動作すること（既存の動作が変わらないこと）
- 処理実行中に進捗情報が段階的に更新されること
- SSE接続失敗時にポーリングにフォールバックすること
- Before/Afterのスクリーンショットを成果物に含めること
5. コミット分割計画
PRを構成するコミットを事前に計画します。
コミットを機能単位で分割することで、問題発生時に特定のコミットだけgit revertできます。
6. 前提が崩れた場合
このセクションが作業方針書の最重要パートです。「前提が違っていた場合にどうするか」を事前に定義しておくことで、パニック時の判断ミスを防ぎます。
- 「ビルドエラーが出た場合は
git revertで戻し、importの依存関係を調査して報告する」 - 「SSE実装が複雑になる場合は、ポーリング＋進捗バー表示のみに絞り、SSEは将来課題とする」
- 「前提が違っていた/修正しても変わらなかった場合は自己判断せず相談する」
特に重要なのは「自己判断せず相談する」という安全弁です。想定外の事態で実装を続行してしまうリスクを明示的に防ぎます。
7. 相談事項（オプション）
方針策定の過程で生じた設計判断の分岐点を、レビュアーに提示します。
フォーマット例
作業方針書の提出ワークフロー
作業方針書は以下のワークフローで運用します。
ステップ1：叩き（初版）の作成
概要レベルの方針を作成し、レビュアーに提出します。この段階では完璧である必要はなく、方向性の確認が目的です。
ステップ2：フィードバックの反映
「何がなぜ必要かわからない」「スコープが広すぎる」といったフィードバックを受け、方針を精緻化します。よくあるフィードバックパターンと対応：
- 「なぜ必要かわからない」 → 背景セクションにビジネス上の問題を追記
- 「影響範囲が不明」 → 「変更しないもの」リストを追加
- 「PRが大きすぎる」 → レイヤー別に分割
ステップ3：セルフレビュー
確認依頼の前に必ずセルフレビューを実施します。チェック観点：
- 成功条件が検証可能か（「正常に動作する」ではなく具体的なコマンドや画面確認手順があるか）
- 対象ファイルに漏れがないか
- コミット分割が機能単位になっているか
- ロールバック手順が明確か
ステップ4：確認依頼
「確認依頼。成果物：○○の作業方針。セルフレビュー済みです」——このフォーマットで提出します。レビュアーが「方針OK、作業着手してください」と返したら、初めてコードを書き始めます。
レビュー観点の設計
作業方針書のレビュアーは、以下の6つの観点で確認します。これをテンプレート化しておくと、レビュー品質が安定します。
- スコープの妥当性：合意した改善項目を漏れなくカバーしているか。スコープ外のものが混入していないか
- 対象の網羅性：関連するファイル・コンポーネント・APIが全て特定されているか
- 技術的整合性：既存のアーキテクチャと矛盾しない設計になっているか
- 動作確認方法：成功条件が具体的で検証可能か
- 優先順位・依存関係：PR間・コミット間の依存が明示されているか
- 前提崩壊時の対応：ロールバック手順が用意されているか
AIエージェントを活用した作業方針書の作成
AIコーディングエージェントは、作業方針書の作成を大幅に効率化します。
AIに任せるべき部分
- コードベース調査：対象ファイルの特定、import依存の分析、現状の挙動の調査
- 叩き（初版）の作成：背景・現状の問題・修正内容の初版を自動生成
- 影響範囲の分析：「変更しないもの」リストの自動生成
人間が判断すべき部分
- 「なぜ」の説明：ビジネス上の必要性は人間が記述
- 成功条件の定義：何をもって「完了」とするかの判断
- 前提崩壊時の対応：想定外の事態でどう動くかの意思決定
- 相談事項の抽出：レビュアーに確認すべき設計判断の分岐点
タスクを受け取ったら、まずAIにコードベース調査を依頼し、その結果を基に人間が「なぜ」と「成功条件」と「ロールバック」を書く——このハイブリッドアプローチが最も効率的です。
作業方針書が不要なケース
すべてのPRに作業方針書が必要なわけではありません。
- typo修正・1ファイル変更：コミットメッセージで十分
- 既存パターンの踏襲：「○○と同じ方法で△△を追加」で済む場合
- 緊急の障害対応：修正を優先し、事後に方針を文書化
目安として、3ファイル以上の変更または新規ファイルの作成を伴うPRでは、作業方針書を書くことを推奨します。
まとめ：作業方針書チェックリスト
| セクション | チェック項目 | 完了基準 |
|---|---|---|
| 背景 | ビジネス上の問題が記載されているか | 「なぜ必要か」が非エンジニアにも伝わる |
| 現状の問題 | コードレベルの具体的な問題が記載されているか | ファイル名・行番号まで特定 |
| 修正内容 | 対象ファイルと変更内容が網羅的か | 「変更しないもの」リスト含む |
| 成功条件 | 検証可能な条件か | コマンドや画面確認手順が明記 |
| コミット計画 | 機能単位で分割されているか | 各コミットが独立してrevert可能 |
| 前提崩壊 | ロールバック手順があるか | 「自己判断せず相談する」安全弁含む |
| 相談事項 | 設計判断の分岐点が提示されているか | 確認観点が明記 |
「コードを書く前に方針を書く」——この一手間が、手戻りをなくし、レビュー通過率を劇的に向上させます。まずは次のPRから、本記事のテンプレートを使って作業方針書を書いてみてください。
関連記事
開発プロセスの改善はrenueにご相談ください。
