実務3年目が新人だった自分に伝えたい、改修案件に入ったときにやるべきこと
はじめに
これからエンジニアとして社会人デビューする皆さん、おめでとうございます。
自分は技術派遣系の会社でエンジニアとして働いて、今年で3年目になります。
3年目なんてまだまだひよっこですが、だからこそ「新人の頃の気持ち」をまだ覚えているうちに、当時の自分に伝えたかったことを書いておこうと思います。
この記事は、最初の案件（たぶん改修案件）に入ったときに意識してほしいことをまとめたものです。
技術的な話というよりは「仕事の進め方」や「心構え」寄りの内容になります。
新人はまず改修案件から始まることが多い
研修ののち、いきなり新規開発にアサインされることは、正直あんまりないと思います。
多くの場合、既存システムの改修案件である画面の項目追加、バリデーションの修正、帳票のレイアウト変更、といった比較的小さめのタスクからスタートするはずです。
「地味だな……」と思うかもしれませんが、改修案件は学びの宝庫です。
既存のコードを読む力、仕様を理解する力、影響範囲を考える力。これらは新規開発でも絶対に必要になるスキルで、改修案件はその最高の練習場所になります。
改修案件に入ったら、まずやること
1. 「何を」「なぜ」変えるのかを把握する
コードを触る前に、まず改修の目的を理解してください。
- この改修は誰のための、何を解決するものなのか？
- 現状はどうなっていて、どう変わるのか？
設計書やチケットの説明を読むだけで済ませず、自分の言葉で「つまりこういうことですよね？」と先輩やリーダーに確認するのが大事です。ここがズレたまま進むと、どれだけきれいにコードを書いても全部やり直しになります。
※チケットとは簡単に言うと課題管理表のようなものです。
2. 現行の仕様と動きを確認する
改修対象の画面やバッチを、まず今の状態で動かしてみてください。
- 実際に画面を操作して、今どういう挙動になっているのか
- DBのどのテーブルが使われているのか
- どういうデータの流れになっているのか
ここを飛ばしてコードだけ読もうとすると、けっこうハマります。「動いているもの」を先に見ておくと、コードの理解が格段に早くなります。
3. 影響範囲を調べる
改修で一番怖いのは「思わぬところが壊れる」ことです。
- このメソッド、他の画面からも呼ばれていないか？
- このテーブルのカラムを変えたら、他のバッチに影響しないか？
- 共通部品を触る場合、他のチームの機能に影響しないか？
IDEのgrep機能や呼び出し元の追跡は積極的に使いましょう。自分で調べた上で「ここが影響しそうなんですが、合ってますか？」と先輩に聞けると、とても良いです。
※grepとは、特定のディレクトリ配下に特定の文字列などが存在しないか調べることです
4. 小さく変えて、こまめに動かす
一気にドカッと変えてから動かすと、どこでバグが入ったか分からなくなります。
変更は小さく、確認はこまめに。これは3年目の今でも意識していることです。
特に最初のうちは「1つ変えたら1回動かす」くらいの慎重さでちょうどいいと思います。
「間違えないこと」より大事なこと
ここからが一番伝えたいことです。
新人のうちは、ミスをすることが怖いと思います。自分もそうでした。
コードを書くたびに「これ合ってるかな……」とビクビクしていたし、レビューで指摘を受けるたびに落ち込んでいました。
でも3年やってみて思うのは、新人がミスをするのは当たり前だし、先輩もそれは分かっているということです。
大事なのは「間違えないこと」じゃなくて、取り返しのつかないミスをしないことです。
そして、取り返しのつかないミスを防ぐのは、技術力ではなくコミュニケーションです。
取り返しのつかないミスってどんなもの？
たとえば、こういうものです。
- 検証環境のデータを消してしまった（本番環境でなくても自分以外に影響がある）
- 仕様の認識がズレたまま2週間開発を進めてしまった
- 「たぶん大丈夫」で確認を飛ばして、リリース後に障害が出た
共通しているのは、**「途中で誰かに聞いていれば防げた」**ということです。
だから、聞いてほしい
「こんなこと聞いたら迷惑かな」と思うかもしれません。
でも、先輩の立場からすると、聞いてくれない方がずっと怖いんです。
- 「この理解で合ってますか？」
- 「ここ、自信がないんですが確認してもらえますか？」
- 「想定と違う動きをしているんですが、仕様ですか？」
こういう一言が言えるだけで、プロジェクトにおけるリスクが大きく下がります。
質問は迷惑じゃないし、確認はサボりじゃないです。それは立派な仕事です。
聞くときのコツ
ただし、「分かりません、教えてください」だけだと、先輩も答えづらいです。
聞くときは、自分なりの仮説をセットにするのがおすすめです。
❌ あまり良くない聞き方
「ここ、どうすればいいですか？」
✅ おすすめの聞き方
「ここはAの方法で進めようと思っているんですが、Bの方法もあり得ると思っていて、どちらが良いでしょうか？」
仮説が間違っていても全然OKです。「自分で考えてから聞いている」ということが伝われば、先輩も安心して教えられます。
今の時代はAIもかなり発達しているので、現場がAIを許容していたりする場合は壁打ちにAIを使うのも全然良いと思います。私が今いる現場はむしろ積極的に使って工数削減しよう派です。
今の作業の「目的」を常に意識する
これは地味に見えるけど、成長速度に直結する話です。
改修作業をしていると、目の前のタスクに集中するあまり「手を動かすこと」が目的になってしまうことがあります。
- このSQLを直すのは、何の画面のどの表示を変えるためなのか
- このバリデーションを追加するのは、どんな業務上の問題を防ぐためなのか
- このテストケースを書くのは、何のリスクを潰すためなのか
これまでアルバイトなどしていたのなら、「動く=働いている」と思いがちです。
ですが、エンジニアは結構机に座って腕組みしながら天井眺めること30分、1時間はザラです。笑
最初は上記をやると「サボってるように思われるかも...」と罪悪感に襲われるかもしれませんが、エンジニアは手を動かすことよりも考えている時間のほうが長いです。
「なぜこの作業をしているのか」を言語化できる状態をキープしてください。
これができると、3つの良いことがあります。
① 手戻りが減る
目的が分かっていれば、「あれ、これ方向性違うかも」と早めに気づけます。気づいた時点で確認すれば、大きな手戻りにはなりません。
② レビューの質が上がる
コードレビューを出すときに「この改修の目的はこうで、この実装にした理由はこうです」と説明できると、レビュアーも的確なフィードバックを返しやすくなります。
③ 応用が利くようになる
「このパターンはこういう目的で使うんだな」と紐づけて覚えると、似たような場面で「前にやったあれが使えるかも」と引き出しが増えていきます。
まとめ
改修案件に入ったら意識してほしいことを改めて整理すると、こんな感じです。
| やること | なぜ大事か |
|---|---|
| 改修の目的を自分の言葉で確認する | 認識のズレを早期に潰すため |
| 現行の動きを実際に触って確認する | コード理解の土台を作るため |
| 影響範囲を調べてから着手する | 予期しない不具合を防ぐため |
| 小さく変えて、こまめに動かす | 問題の切り分けを容易にするため |
| 分からないことは仮説付きで聞く | 取り返しのつかないミスを防ぐため |
| 今の作業の目的を常に意識する | 成長速度を上げるため |
完璧なコードを書けることよりも、**「危ないときにちゃんと声を上げられること」**の方が、プロジェクトにとってはずっと価値があります。
皆さんもエンジニアやるからにはいずれPLやPMを目指している方も多いと思います。
危ないときに上長へエスカレーションを投げられるという事実は、必ず評価されることです。
最初は分からないことだらけで当然です。
焦らず、でも考えることはサボらず、一つずつやっていけば大丈夫です。
皆さんのエンジニア生活が良いスタートを切れることを願っています。
この記事は実務3年目のいちエンジニアの個人的な経験に基づいています。
「自分はこうだったよ」「うちの現場ではこうだよ」など、コメントいただけると嬉しいです。