エンジニアの「調べてみないと分かりません」
エンジニアに
「この修正ってどれくらいかかりますか？」
と聞いたとき、少し間があってから
「……調べてみないと分からないですね」
と言われた経験はないでしょうか。
「画面の表示を少し変えるだけ」
「ボタンの色を変えるだけ」
そう聞くと、すぐ終わりそうに思えるかもしれません。
しかし実際には、小さな修正が想像以上に時間がかかることがあります。
私も以前、「1週間くらいで終わるだろう」と思っていた改修が
結果的に1ヶ月かかったことがありました。
「ちょっと直すだけ」のはずだった改修
その改修は、CMSのLP（ランディングページ）作成画面でした。
LPとは、キャンペーンや商品紹介のための1ページのWebページです。
そのCMSでは、LPを作る画面の中に
作成中のページを確認するためのプレビューが表示されていました。
ただ、このプレビューが画面の半分を占めていて、
作業画面としてはかなり使いづらい状態でした。
そこで
「プレビューを別ウィンドウで表示できるようにしよう」
という改修を行うことになりました。
内容だけ聞くと、それほど大変な変更には見えません。
私も最初は
「1週間くらいで終わるかな」
と思っていました。
しかし実際には、この改修には 約1ヶ月 かかりました。
なぜそんなに時間がかかったのか
理由はシンプルです。
コードが想像以上に複雑だったからです。
そのLPは、Reactの「コンポーネント」という仕組みで作られていました。
コンポーネントとは簡単に言うと 画面の部品 のようなものです。
例えばWebページは、ヘッダー・ボタン・枠・リストといった部品を組み合わせて作られています。
LPも同じです。
しかし問題は、この部品の構造でした。
LPの表示は「実際のサイト」と「CMSのプレビュー」の両方で使われており、
- 共通で使われる部品
- CMS専用の部品
- サイト専用の部品
が混ざった構造になっていました。
そのため、ある部品を変更すると
- 本番サイトのLP表示が崩れる
- CMSのプレビューが壊れる
- 両方壊れる
可能性がありました。
変更前に「どこに影響が出るのか」を確認する必要があります。
実際にPRを確認すると、変更ファイルは約80、関係ファイルは100以上という規模になっていました。
こういう状況のとき、エンジニアはこう言います。
「このコード、複雑ですね。」
エンジニアが言う「複雑」の意味
エンジニアが「このコードは複雑ですね」と言うとき、それは
「読みにくい」 という意味ではありません。
本当の意味はこうです。
「触ると何が壊れるか分からない」
つまり「変更の影響範囲が追えない」「どこに影響するか分からない」という問題です。
この状態だと、修正の前に調査が必要になり、テスト範囲が広がり、修正リスクが高くなります。
結果として、改修には時間がかかります。
コードはなぜ複雑になるのか
システムは最初から複雑ではありません。
時間とともに、少しずつ複雑になります。
主な理由は次の3つです。
機能追加
新しい機能が追加されると、コードは増えます。
仕様変更
最初の想定とは違う使い方が増えます。
応急処置
「とりあえず動くようにする」という修正が積み重なります。
技術的負債の例
LP改修の調査を進めていると、あるコンポーネントに行き着きました。
それは 「四角い枠を表示するだけの部品」 でした。
本来はとてもシンプルなはずのコンポーネントです。
しかし中を見てみると、そこには大量の条件分岐がありました。
「この画面ではこのデザイン」
「あの画面では少し違う表示」
そうした修正が何年も積み重なった結果、
シンプルなはずの部品が複雑なコードになっていました。
こうした状態は 技術的負債 と呼ばれます。
短期的には便利でも、長期的には開発を難しくします。
リファクタリングとは何か
そこで重要になるのが リファクタリング です。
リファクタリングとは、コードの動作を変えずに整理することです。
例えば
- 無駄なコードを削除する
- 似た処理をまとめる
- 名前を分かりやすくする
といった作業です。
以前、似た処理が多く書かれていたコードを整理したところ、
100行あったコードが50行程度になったことがあります。
機能は同じでも、読みやすさは大きく変わります。
なぜコードレビューをするのか
多くのチームでは、コードを書いたあと コードレビュー を行います。
主な目的は3つあります。
バグの発見
自分では気づかなかったバグが見つかることがあります。
設計の改善
「ここは共通化できそう」といった改善の提案がもらえます。
知識共有
担当者しか分からないコードを防ぐことができます。
良いコードとは何か
「良いコードを書く」とは、センスや経験だけの話ではありません。
エンジニアの世界には、長年の試行錯誤から生まれた 原則 があります。
例えば KISS（Keep It Simple） ——「シンプルに保て」という考え方です。
機能追加のたびにコードは自然と複雑になっていくため、意識してシンプルさを守らないとすぐに崩れます。
あるいは DRY（Don’t Repeat Yourself） ——「同じことを繰り返すな」という原則です。
似たコードが複数の場所に存在すると、修正漏れやバグの温床になります。
こうした原則を判断軸にしながら、エンジニアは「どう書くか」を選んでいます。
「なんとなく動くコード」ではなく、
将来の自分や仲間が扱いやすいコードを目指して。
まとめ
ソフトウェア開発では、動くコードを書いた時点で終わりではありません。
重要なのは、
- 読みやすいこと
- 修正しやすいこと
- 影響範囲が分かること
です。
だからエンジニアはリファクタリングやコードレビューを行います。
それは 将来の開発を楽にするための投資 でもあります。
「ちょっと直すだけ」が1ヶ月かかることがあるのも、そうした背景があるからです。
そして、もしそういう場面に出くわしたとき——
それはエンジニアが怠けているのではなく、
過去の積み重ねのツケを、今払っているのかもしれません。
「調べてみないとわからないですね」の裏に何があるか——それを知っているだけで、エンジニアとの会話が少し変わるかもしれません。
コメント