株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
なぜ「すぐコードを書く」と手戻りが発生するのか
タスクを受け取ったらすぐにコードを書き始める——これは多くのエンジニアが無意識にやっている行動です。しかし、目的や変更範囲を確認せずに着手すると、実装後に認識の違いが分かり、手戻りにつながる場合があります。
手戻りが発生する構造的な理由は明確です。「何をやるか」が曖昧なまま実装に入ると、レビューの段階で「そもそもスコープが違う」「なぜこの方法なのか不明」「ロールバック手順がない」と差し戻されるからです。
本記事では、PRレビューを円滑に進めるための「作業方針書」のテンプレートと書き方を、renueの自社開発チームで運用している手法に基づいて解説します。
作業方針書とは何か——設計書でもチケットでもない
作業方針書は、一般的な設計書（PRD/FRD/SRS）やチケット説明とは異なる独自のドキュメントです。
| ドキュメント | 目的 | 読み手 | 粒度 |
|---|---|---|---|
| PRD | ユーザー視点で何を作るか | PM・ビジネス | 機能要件レベル |
| 設計書 | システム全体の構造を定義 | アーキテクト・チーム全体 | システム設計レベル |
| チケット | タスクの割り当て・進捗管理 | チーム全体 | タスクレベル |
| 作業方針書 | 「このPRで何を、なぜ、どう変えるか」を事前合意する | レビュアー・上長 | PR（コミット）レベル |
作業方針書の価値は、実装前にレビュアーと方向性を合意できることにあります。コードを書いてからレビューで「そもそもアプローチが違う」と分かる前に、方針を合意しておくことで、不要な実装を減らすことを目指します。Googleの開発ガイドでも、依存する変更の分割や構成を着手前に考える方法が説明されています。これは本記事の7項目や費用削減幅を保証するものではありません。（参考：Google Engineering Practices：Small CLs）
作業方針書の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：確認依頼
確認を依頼するときは、成果物が作業方針であることと、セルフレビューを済ませたことを明記します。レビュアーが方針を確認し、作業着手の了承を得てから実装へ進めます。
レビュー観点の設計
作業方針書のレビュアーは、以下の6つの観点で確認します。これをテンプレート化しておくと、レビュー品質が安定します。
- スコープの妥当性：合意した改善項目を漏れなくカバーしているか。スコープ外のものが混入していないか
- 対象の網羅性：関連するファイル・コンポーネント・APIが全て特定されているか
- 技術的整合性：既存のアーキテクチャと矛盾しない設計になっているか
- 動作確認方法：成功条件が具体的で検証可能か
- 優先順位・依存関係：PR間・コミット間の依存が明示されているか
- 前提崩壊時の対応：ロールバック手順が用意されているか
AIエージェントを活用した作業方針書の作成
AIコーディングエージェントは、調査や初稿作成の補助として活用できます。
AIに任せるべき部分
- コードベース調査：対象ファイルの特定、import依存の分析、現状の挙動の調査
- 叩き（初版）の作成：背景・現状の問題・修正内容の初版を自動生成
- 影響範囲の分析：「変更しないもの」リストの自動生成
人間が判断すべき部分
- 「なぜ」の説明：ビジネス上の必要性は人間が記述
- 成功条件の定義：何をもって「完了」とするかの判断
- 前提崩壊時の対応：想定外の事態でどう動くかの意思決定
- 相談事項の抽出：レビュアーに確認すべき設計判断の分岐点
タスクを受け取ったら、まずAIにコードベース調査を依頼し、その結果を基に人間が「なぜ」と「成功条件」と「ロールバック」を書く——このハイブリッドアプローチも選択肢です。
作業方針書が不要なケース
すべてのPRに作業方針書が必要なわけではありません。
- typo修正・1ファイル変更：コミットメッセージで十分
- 既存パターンの踏襲：「○○と同じ方法で△△を追加」で済む場合
- 緊急の障害対応：修正を優先し、事後に方針を文書化
目安として、3ファイル以上の変更または新規ファイルの作成を伴うPRでは、作業方針書を書くことを推奨します。
まとめ：作業方針書チェックリスト
| セクション | チェック項目 | 完了基準 |
|---|---|---|
| 背景 | ビジネス上の問題が記載されているか | 「なぜ必要か」が非エンジニアにも伝わる |
| 現状の問題 | コードレベルの具体的な問題が記載されているか | ファイル名・行番号まで特定 |
| 修正内容 | 対象ファイルと変更内容が網羅的か | 「変更しないもの」リスト含む |
| 成功条件 | 検証可能な条件か | コマンドや画面確認手順が明記 |
| コミット計画 | 機能単位で分割されているか | 各コミットが独立してrevert可能 |
| 前提崩壊 | ロールバック手順があるか | 「自己判断せず相談する」安全弁含む |
| 相談事項 | 設計判断の分岐点が提示されているか | 確認観点が明記 |
「コードを書く前に方針を書く」——この一手間が、実装前の認識合わせを助け、手戻りを減らすことにつながります。レビューでは、方針の合意後も実装内容と検証結果を確認します。まずは次のPRから、本記事のテンプレートを使って作業方針書を書いてみてください。
関連記事
開発プロセスの改善はrenueにご相談ください。
