実装前に計画と差分を確認する

この記事で学ぶこと

• 計画の量を変更の影響へ合わせる
• 通常例と例外を先に決める
• 承認時には具体的な結果を示す

計画が必要な変更を選ぶ

計画の役割は、作業の目的、変更対象、検証方法を実行前に揃えることです。

決まった1行の誤字修正なら、依頼と差分確認だけで十分な場合があります。

一方、複数ファイルの構造変更や外部への書き込みを含む仕事は、手順の解釈によって結果が大きく変わります。

影響と不確実性に応じて計画の詳しさを変えます。

架空の例で、記事一覧の表示順を「更新日順」へ変えるとします。

単に並び替えるだけなのか、元データに更新日を追加するのか、日付がない記事をどう扱うのかで変更内容が違います。

実装後に初めて話すと、データと画面の両方を直すことになりかねません。

まず現状の構造と曖昧な条件を整理します。

Claude Codeの計画機能を使うかどうかに関係なく、「現状を読み、編集前に変更案を示す」という進め方は使えます。

ただし、特定のモード名だけであらゆる操作が制限されると決めつけず、利用環境の仕様と権限を確認します。

計画は人の認識を揃える文書、実行制限は環境の設定として区別します。

計画の詳しさは、変更の不確実さに合わせます。

誤字一つなら対象を確認して直せますが、一覧の並び順を変えるなら日付のない記事の扱いまで決めます。

すべての依頼へ長い計画を付けず、実装後に決め直すと手戻りになる条件を先に整理しましょう。

計画を出してもらう際は、実装の細部より決めるべき条件を先に並べます。

日付のない記事の扱いが未定なら、処理の書き方を詳しく説明されても判断できません。

利用者に見える違いを確定してから方法へ進む順番にします。

小さな計画でも、曖昧さを減らす役割を果たせば十分です。

成果を一文で固定する

計画の先頭には、今回の完了状態を書きます。

「記事一覧を改善する」ではなく、「更新日の新しい記事が先頭に並び、日付のない記事は末尾に表示される」です。

これなら実際のデータを使って合否を確認できます。

解決したい問題と変更する動作を結び付け、余計な機能追加を防ぐ基準にします。

成果の文には、対象外も必要に応じて添えます。

この例なら、記事の本文、見た目、公開日時の変更は含めません。

目的を達成するために不可欠な修正が後で判明することもあります。

その場合は、対象外を無理に守って不完全にするのではなく、理由と追加範囲を示して計画を更新します。

境界は判断のために置くものです。

効果と機能の完成は分けて扱います。

並び順を変えれば新しい記事が見つけやすくなる、という期待はありますが、閲覧数の増加を実装完了の証拠にはできません。

今回確かめるのは表示順であり、閲覧への影響は別の期間と方法で調べます。

実装の合否と事業上の効果を分けると、計画が測定可能になります。

完成条件には、同じ日付の記事や日付がない記事など、境界の例も添えます。

通常の記事だけが並ぶ見本では、例外の順番を確かめられません。

どの順番なら正しいかを実装前に人が決めておくと、表示結果を見てから基準を変えることを防げます。

並び順の例では、同じ日の記事がある場合の順序も必要です。

既存の順番を維持するのか、別の項目で決めるのかによって結果が変わります。

こうした境界条件は実装の好みではなく、利用者に見える仕様です。

判断が未定なら候補と影響を示し、採用する条件を完成の文へ反映します。

変更と検証を対応させる

変更予定ファイルを列挙するだけでは、なぜ触るかが分かりません。

表示順を決める処理、日付の入力元、確認用のデータというように、ファイルの役割を添えます。

必要がなければ設定や依存ライブラリを変更しない案を選びます。

変更が小さいほど常に正しいわけではありませんが、要求との対応を確認しやすくなります。

検証には、通常のケースと境界のケースを置きます。

更新日が異なる記事、同じ日の記事、日付がない記事を用意します。

何が先頭になるか、同じ日ならどう並ぶかを事前に決めます。

テストをたくさん実行することより、判断が曖昧になりやすい条件を選ぶことが大切です。

画面の表示確認も別に必要かを考えます。

計画には、既存の検証方法を調べる工程も含めます。

プロジェクトで決まった確認手順があるなら、それを根拠にします。

知らないコマンドを名前だけで追加すると、検証が動かないまま進むことがあります。

実行できなかった場合の報告方法も決め、未確認の項目が合格に紛れないようにします。

検証欄は「テストする」だけでなく、材料と期待する結果を書きます。

日付が新しい記事が先頭、日付なしは末尾、既存のリンクは維持、と対応させます。

計画を読んだ人が何を見るか理解できれば、実行担当者が交代しても確認の目的を引き継げます。

検証用の見本は、件数を少なくして期待順を人が書けるものにします。

数百件の一覧だけでは、並び替えの誤りを目で追うことが難しくなります。

小さな例でルールを確かめた後、実際の一覧に適用した表示も確認します。

原理の検証と実データでの確認を組み合わせる考え方です。

承認地点を影響で分ける

承認が必要かは、操作の影響と既存の権限に基づいて決めます。

練習用の原稿編集と、外部公開や本番データの更新は同じではありません。

すでに明確に許可された通常作業を毎回止める必要はありません。

一方、依頼に含まれない公開や共有範囲の拡大は、実装が終わったという理由だけで進めません。

承認を求めるときは、具体的に確認できる結果を揃えます。

「公開してよいですか」だけでは判断材料が不足します。

変更内容、検証結果、公開先、残る不確実性を短く示します。

例えば「記事一覧の更新日順への変更を確認済み。日付なしは末尾。公開先は本番サイト」とまとめれば、担当者が対象を理解できます。

承認待ちの間も、許可された範囲の検証や説明の整理は進められます。

逆に、必要な承認を得ていない操作を試行で実行しないでください。

外部送信や公開は、試すだけでも影響が生じます。

確認の境界は、作業を停滞させるためでなく、決定の責任を適切な担当者に戻すために置きます。

確認者へ渡す段階では、変更案を比較できる形にします。

公開前の画面、変更したファイル、確認済みの項目がそろっていれば、抽象的な実行許可より判断しやすくなります。

承認に必要な材料を準備する仕事も、計画の中へ含めておいてください。

承認記録には、何が許可されたかを残します。

下書きの採用と、本番への反映を同じ一言で扱うと解釈が分かれるためです。

日時や対象が変わった場合にも追えるよう、承認した成果物を特定します。

確認の回数を増やすより、判断した対象を明確にする方が引き継ぎに役立ちます。

予定変更を記録して進める

調査の結果、当初の計画では目的を達成できないと分かる場合があります。

例えば更新日がどこにも保存されていなければ、表示処理だけでなくデータの扱いを決める必要があります。

こうした発見を隠して作業を続けると、予定外の変更が増えます。

何が判明し、どの判断が変わるかを短く説明します。

計画の更新は、細かな実装判断をすべて人へ戻すことではありません。

許可された範囲内の実装方法は任せつつ、成果、影響、権限が変わる箇所を取り上げます。

同じ日付の並べ方のように利用者の体験へ影響する条件は、明示した基準で決めます。

未決定なら暫定案と理由を示し、完成時に残さないようにします。

作業終了時は、計画と結果を対応させます。

予定どおりに終わった項目、変更した項目、できなかった確認を分けます。

これにより、計画が単なる儀式にならず、結果を確認する土台になります。

次回の似た仕事では、曖昧になった条件を最初から依頼に含め、計画の手戻りを減らせます。

想定外の問題を見つけた場合は、今回の目的に必要かを先に判断します。

表示順に無関係な古い文章まで同時に直すと、確認範囲が広がります。

必要な変更と後日扱う改善を分け、目的に影響する追加作業だけを計画へ反映すると、終点を保ちやすくなります。

予定から外れた理由が分かれば、次回の依頼を改善できます。

更新日が未整備だったなら、表示修正の前にデータの確認を置くべきだったと分かります。

計画の失敗を単に時間超過として片付けず、何を先に確かめればよかったかを記録してください。

次の作業の準備に使える学びになります。

まとめ

計画は、実装前に成果、変更範囲、確認方法を揃える手段です。

詳しさは影響と不確実性に合わせます。

次の複数ファイルの修正では、完成状態を一文で書き、公開など影響の大きい操作の前に確認できる結果を揃えてください。

• 計画の量を変更の影響へ合わせる
• 通常例と例外を先に決める
• 承認時には具体的な結果を示す