開発現場でこんなやり取り、一度は経験したことがありませんか？
先輩: 「あ、この処理ちょっとイマイチだから修正しておいて〜」
自分: 「わかりました！（良し、サクッと直して成果を見せるぞ！）」
……知識や経験が浅い時期、悲劇は静かに訪れます。
軽い気持ちで修正したコードが、思わぬ「副作用」を引き起こし、他の画面を破壊したりパフォーマンスを悪化させたり……。
今回は、私が過去にやらかした「修正依頼の言葉足らず」から発生した悲劇と、そこから学んだコードの影響範囲（副作用）およびコミュニケーションの捉え方についての考察をまとめます。
事故現場1：共通メソッドを直したら、他の画面が巻き添えで崩壊した
状況
Javaで記述されたバックエンド処理で、「入力値のフォーマットを整える処理」を修正するよう指示を受けました。
// 修正前の共通ユーティリティメソッド
public class StringUtil {
public static String formatCode(String input) {
if (input == null) return "";
return input.trim();
}
}
指示は**「コードの頭振りにゼロ埋め（Padding）をしてほしい」**というもの。「よし、このユーティリティメソッドを直せば一発だな！」と思い、以下のように修正しました。
// 軽い気持ちで修正したコード
public class StringUtil {
public static String formatCode(String input) {
if (input == null) return "";
// 8桁にゼロ埋めする処理を追加
return String.format("%8s", input.trim()).replace(' ', '0');
}
}
発生した悲劇
自分の担当画面ではバッチリ動くことを確認し、PR（プルリクエスト）をマージ。
しかし翌日、全く関係のない「商品検索画面」と「ユーザー設定画面」でエラーが多発していると連絡が届きます。
実はこの formatCode、システム全体で100箇所以上から呼び出されている共通メソッドだったのです。他画面では「ゼロ埋めされていない生のコード」を前提としたロジックが組まれており、全滅しました。
考察と反省
- 「共通処理」は牙をむく: 共通化されているコードを変更する際は、単体テストを通すだけでなく「影響範囲（どこから呼ばれているか）」の検索が必須。
- 安易な共通メソッドの改修より、個別ロジック化・別メソッド化: 「直しておいて」の真意は、「その画面で必要な処理を行って」であって「共通処理そのものを書き換えて」ではなかった。
事故現場2：SQLのパフォーマンス改善のつもりが、更新処理を殺した
状況
「この検索画面、表示が遅いからSQLのパフォーマンス改善しておいて」と言われ、実行計画（EXPLAIN）を確認。テーブルスキャンが発生していたため、インデックス（Index）を追加することにしました。
-- 検索速度向上のために複合インデックスを追加
CREATE INDEX idx_orders_status_date ON orders (status, created_at);
「よし、インデックス貼ったら検索が爆速になった！解決！」と達成感に浸っていました。
発生した悲劇
検索は速くなったものの、別機能である**「夜間注文データの一括インポート（INSERT/UPDATE）」が通常の3倍以上の時間を要するようになり、タイムアウトで落ちる**という事態が発生。
考察と反省
- トレードオフの意識不足: インデックスは「READ（検索）」を速くする反面、「WRITE（挿入・更新・削除）」のたびにインデックスの再構築が発生するため、書き込みコストが増加する。
- 単一の指標にとらわれる恐怖: 「検索を速くする」という目的に集中するあまり、データベース全体への副作用（書き込み性能の低下）に目が向いていなかった。
なぜこの悲劇は繰り返されるのか？（全体の考察）
今回の失敗を通じて、「言葉足らずな指示」と「それを受け取る自分」の間に存在する 2つの課題 に気づきました。
1. コミュニケーションにおける「文脈の非対称性」
指示を出す側（先輩・リーダー）は、頭の中にシステム全体の構造や背景文脈を持っています。そのため、「ここ直しといて」という短文の中に以下のような暗黙の前提が含まれています。
- (他の機能に影響を与えない形で) ここ直しといて
- (全体的なパフォーマンスのバランスを考慮して) ここ直しといて
一方、受ける側（特に経験の浅い段階）は指示された言葉通りの「点」でタスクを捉えてしまいがちです。言葉の行間にある「前提」をすり合わせないまま手を動かすと、事故に繋がります。
2. 「コードの影響範囲（副作用）」に対する解像度
プログラミングを始めたばかりの頃は、「動くコードを書くこと」に全神経を注ぎます。
しかし実務で求められるのは、「その1行を変えたとき、どこに波及するか」を予測する力です。
【視点の変化】
初心者：自分が書いたコードが期待通りに動くか？
中級者：自分が書いたコードが「他の既存コード」を壊していないか？
この失敗から得た「明日から使えるアクションプラン」
同じ悲劇を繰り返さないために、私は以下のルールを自分に課すようにしました。
-
修正前に「影響範囲」をGrep（全検索）する
- 共通クラスや共通メソッドを触る際は、呼び出し元（呼び出し階層）を必ず確認する。
- 影響範囲が大きい場合は、既存メソッドを修正するのではなく、新しくメソッドを生やす（または呼び出し側で処理する）ことを検討する。
-
「〇〇というやり方で修正します」と宣言してから手を動かす
- 「ここ直しといて」と言われたら、実装に入る前に「影響範囲を踏まえてA案で直そうと思いますがよろしいですか？」と一言チャットを入れる。これだけで手戻りは9割防げる。
-
トレードオフを意識する
- 特にSQLやメモリ空間、非同期処理などを扱う際は、「何かを良くすると、別の何かが犠牲にならないか？」を一度立ち止まって考える。
おわりに
「ここ修正しておいて」という短い言葉の裏には、実は数多くの罠が潜んでいます。
言葉足らずな指示を責めるのは簡単ですが、「影響範囲を察知し、確認を取れるエンジニア」へ成長するための良い経験だったと今では感じています。
皆さんも「軽い修正のはずが事故になった」思い出があれば、ぜひコメントで教えてください！