JIRAチケットを数日かけて実装したのに、チームリードのレビューで「やり直し」を命じられた…そんな経験あると思います。
原因のほとんどは「コードを書く前の確認不足」です。
タスクの背景を理解せず、既存コードも読まず、解決策の認識合わせもしないまま実装を始めると、2日間の作業が丸ごと無駄になる事態も起こります。
コーディング着手前にやるべき確認は4つに絞られます。
「なぜ作るか」を問うこと、既存コードを把握すること、コメントで設計をスケッチすること、1ページ程度でいいので仕様書を書くこと。
この4ステップを踏むだけで、手戻りのリスクは大きく下がります。
コーディングを急ぐと何が起きるか
「2日間の手戻り」が生まれたケース
あるホテル管理ツールの開発プロジェクトでの実話です。
チームリードから「メール送信前にメールを保存する機能を追加してほしい」と依頼されました。
一見シンプルなタスクに見えたため、すぐに実装に着手し、2日間かけてコードを書き上げました。
ところがレビューの場で、チームリードの期待していた実装方針はまったく異なるものでした。
やり直しを命じられたのはフル実装ではなかったものの、アプローチを根本から変える必要がありました。
着手前に一言「こういう方針で進めようと思いますが、認識合っていますか？」と確認していれば、2日間の大半を別の作業に充てられたはずです。
認識ズレのコストは「書き直した時間」だけではありません。
レビュアーの時間、チームの信頼、リリーススケジュールへの影響まで含めると、実際の損失は着手から完了までの工数の2〜3倍に膨らむことがあります。
※一般的なソフトウェア開発における手戻りコストの試算に基づく
AIコーディング時代に認識ズレが増える理由
GitHub CopilotやCursorなどのAIコーディングツールが普及したことで、「コードを書く速度」は飛躍的に上がりました。
しかし速度が上がった分だけ、「間違った方向に速く進む」リスクも高まっています。
AIが自動補完したコードは一見完成度が高く見えるため、「これで合っているはずだ」という思い込みが生まれやすくなりました。
要件の確認を省いたまま、AIの提案を採用し続けた結果、1時間で100行の「的外れなコード」が生成されるケースも実際に起きています。
コードを書く前の確認プロセスは、AIツールを使う環境ほど重要になります。
着手前に確認すべき4つのステップ
ステップ1｜「なぜ作るか」を3つの質問で確認する
タスクの内容を理解しているつもりでも、「目的」まで理解できているかどうかは別問題です。
実装前に必ず次の3つを確認してください。
- なぜこのタスクが必要か（解決したいビジネス課題は何か）
- 本質的な問題は何か（表面的な仕様の背景にある課題）
- なぜ今解決するのか（優先度の根拠）
この3問に答えられない状態でコーディングを始めると、仕様書に書かれた通りに動くけれど「誰も求めていないもの」を作り上げてしまう可能性があります。
具体的な確認方法として有効なのは、Slackやチャットで「こういう理解で進めますが合っていますか？」と一文送ることです。
口頭の確認より記録が残り、後から認識ズレが起きたときの参照にもなります。
ステップ2｜既存コードを読んでから見積もりを出す
「シンプルなタスク」という印象は、既存コードを読む前の判断では信用できません。
実際に着手してみると、修正対象のモジュールが10年前に書かれたレガシーコードで、リファクタリングなしには手が出せない状態だったというケースは珍しくありません。
見積もりを出す前に、少なくとも以下の3点を確認してください。
- 変更対象のファイル・モジュールの現状の構造
- 依存しているライブラリやAPIのバージョン
- 関連するテストコードの有無と網羅率
この確認を省いた見積もりは「楽観的すぎる見積もり」になりがちです。
チームリードから「なぜこんなに時間がかかるのか」と問われたとき、既存コードの状況を把握した上で説明できるかどうかが、エンジニアとしての信頼に直結します。
ステップ3｜コメントで設計をスケッチしてから書き始める
実装前に、コード本体を書く代わりにコメントだけで処理の流れを書き出す手法があります。
設計のスケッチとして機能し、「何をどの順序で実装するか」を言語化できます。
例として、メール保存機能であれば次のように書き出します。
- 送信前のメールオブジェクトを取得する
- DBのメールキューテーブルに保存する
- 保存成功を確認してから送信処理を呼び出す
- 送信失敗時のロールバック処理を追加する
このスケッチをチームリードに見せて「この方針で進めますが合っていますか？」と確認するだけで、着手前の認識合わせができます。
コードを書く前に設計を共有することが、レビュー後の手戻りを防ぐ最も効率的な方法です。
実装が終わったら、スケッチ用に書いたコメントは必ず削除してください。
コード内に残ったノイズコメントは可読性を下げ、次の開発者を混乱させます。「コメントより名前、名前より型」という原則を念頭に置いてください。
ステップ4｜1ページ仕様書で自分の認識を固める
チーム共有が目的ではなく、自分の思考を整理するための仕様書を1ページだけ書くことを習慣にしてください。含める内容は最低限でかまいません。
- 実装する変更の概要（3行以内）
- 影響を受けるモジュールとその理由
- 想定している実装方針とその根拠
- 懸念点・未確認事項のリスト
書いているうちに「この部分は確認が必要だ」「この方針には穴がある」と気づくことがあります。
コードを1行も書く前に問題を発見できるのが、この仕様書の本質的な価値です。
フォーマットはNotionの1ページでも、テキストファイルでもかまいません。
他人に見せることを前提にしないため、完成度より「自分が考え切れたか」が基準です。
4ステップを実行する際によくある失敗
質問のタイミングを誤るケース
「質問は早ければ早いほどいい」は正しいですが、「質問の質」が低いと逆効果になります。
NG例として多いのが、既存コードを読む前に「どのように実装すればいいですか？」と聞くケースです。
チームリードやシニアエンジニアにとって、これは「自分では何も調べていない」と映ります。
有効な質問の形は「〇〇という方針で進めようと思いますが、△△の部分が不明です。××という理解で合っていますか？」という構造です。
自分の仮説を示した上で確認を求めることで、相手が答えやすくなり、回答の質も上がります。
ステップ2で既存コードを読み、ステップ3でスケッチを作ってから質問する流れを守ることで、「調べた上で聞いている」という印象を自然に与えられます。
スケッチコメントを本番コードに残すケース
ステップ3で書いたコメントを削除し忘れたまま、プルリクエストを出してしまうケースは非常によく起きます。
レビュアーから「このコメントは必要ですか？」と指摘されると、細部への注意力を疑われる原因になります。
対策として有効なのは、コミット前のセルフレビューに「スケッチコメントの削除確認」を1項目追加することです。
プルリクエストを出す直前に自分のdiffを通読する習慣があれば、この種の凡ミスは大幅に減らせます。
「質問しすぎ」は失礼か？よくある誤解と実際の判断基準
「何度も確認すると、チームリードに迷惑をかける」という懸念を持つエンジニアは少なくありません。
実際には、質問しないことで発生する手戻りのほうが、チーム全体のコストは高くなります。
「質問で迷惑をかける」と「ミスで迷惑をかける」を比較したとき、後者のほうがスケジュールへの影響・信頼へのダメージともに大きいのが現実です。
ただし、質問の回数よりも「質問の構造」が重要です。
次の条件を満たしていれば、何度質問しても「仕事ができる人が確認している」という印象になります。
- 自分の仮説・調査結果を先に示している
- 確認したい箇所が具体的に絞られている
- テキストで記録が残る形で聞いている
逆に避けるべきなのは、何も調べないまま「どうすればいいですか？」と聞くことです。
質問の内容ではなく、準備の有無が評価の分岐点になります。
4ステップの適用判断｜どの状況で何を省略できるか
4ステップすべてが毎回必要なわけではありません。タスクの規模と影響範囲によって、省略できるステップは変わります。
- 1〜2時間で完了する軽微な修正：ステップ3のコメントスケッチのみ実施。既存コードの確認は対象ファイルの読み込みで十分。
- 半日〜1日かかるタスク：ステップ1〜3を実施。1ページ仕様書は不要だが、スケッチを共有して確認を取る。
- 複数日にまたがる実装、または他チームへの影響があるタスク：4ステップすべてを実施。1ページ仕様書はチームリードへの共有にも使う。
判断基準は「手戻りが発生した場合に何日分の損失になるか」です。
1日以上の損失が見込まれるタスクには、4ステップすべてを適用することを推奨します。
着手前の準備が「タイピング速度」より価値を持つ理由
コーディングで本当に難しいのは、キーボードを速く打つことではありません。「何を打つべきか」を正確に把握することです。
タイピング速度を10%上げても、方向が間違っていれば成果はゼロです。
一方、着手前の確認に30分かけて方向を正しく定めれば、その後の実装時間全体が有効な時間になります。
4つのステップは、ツールでも儀式でもなく「正しい方向を確認するための思考プロセス」です。
- ステップ1：目的を確認し、「何を作るべきか」を固める
- ステップ2：現状を把握し、「どこから手を付けるか」を決める
- ステップ3：設計を言語化し、「どう作るか」を共有する
- ステップ4：認識を文字にすることで、「見落としがないか」を自己検証する
AIコーディングツールが普及し、実装速度がさらに上がる時代において、着手前の確認プロセスは差別化要素になります。
速く書けるエンジニアは増えますが、「正しいものを正確に作れるエンジニア」の価値は下がりません。
コードを書く前の30分が、数日間の手戻りを防ぎます。
