はじめに

下請けSIerでエンジニアをやって3年目になります。
業務系のWebアプリケーションを中心に、改修・保守・バグ調査をやってきました。

3年間でいろんなスキルを身につけてきたつもりですが、振り返ってみると一番実務で使っているのは「コードを読む力」だったということに最近気づきました。

書く力じゃなくて、読む力。
最近ではAIに全投しているエンジニアもいるように思えますが、やっぱり人間が読める力も持つことは重要だと思っています。

新しいフレームワークを覚えることよりも、設計パターンを勉強することよりも、**「今目の前にあるコードが何をやっているのか、処理の流れを頭の中で組み立てられること」**が、自分の仕事を一番助けてくれています。

特にそれを強く実感したのが、バグ調査や障害対応の場面です。

この記事では、自分が3年間で身につけてきた「コードを読むときの思考法」を整理してみます。
同じくらいの年次のエンジニアの方に「あー、分かる」と思ってもらえたら嬉しいです。

なぜ「書く力」より「読む力」なのか

業務系のシステム開発、特に保守・改修フェーズにいると、こんな場面が日常的に出てきます。

「この画面でエラーが出てるんだけど、原因を調べて」
「前任者が作ったこの機能、仕様と違う動きをしてるっぽい」
「このバッチ、特定のデータだけ処理が失敗してるらしい」

こういうとき、求められるのは「コードを書く力」ではなく、**「既存コードを追って、何が起きているか突き止める力」**です。

そして業務系システムって、だいたいこんな特徴があります。

コードベースが巨大（何百、何千クラスある）
自分が書いていないコードの方が圧倒的に多い
ドキュメントが追いついていない（あるいは古い）
複数人・複数世代のコードが混在している

この環境で仕事をする以上、「読んで理解する」スキルは避けて通れません。
むしろ、読む力がある人ほど早く正確に仕事が終わる、というのが自分の実感です。

バグ調査で学んだ「読み方の思考法」

ここからは、自分がバグ調査を繰り返す中で身につけてきた思考法を紹介します。
特別なテクニックというよりは、コードを追うときに頭の中でやっていることの言語化です。

1. 「出口」から逆にたどる

バグ調査のとき、最初にやりがちなのは「処理の先頭から順番に追っていく」ことです。
でも業務システムのコードは深い。先頭から追うと、途中で迷子になります。

自分がよくやるのは、「出口」から逆にたどる方法です。

たとえば「画面にエラーメッセージが表示される」というバグなら：

まずそのエラーメッセージの文言でgrepする
メッセージをセットしている箇所を見つける
その箇所に到達する条件（if文やバリデーション）を確認する
その条件に渡されているデータがどこから来ているかを遡る

ゴールから起点に向かって逆走するイメージです。

処理の全体を理解する必要はなくて、「このバグに関係する経路だけ」を特定すればいい。
こう考えると、読むべきコードの量がぐっと減ります。

2. 処理の流れを「層」で分けて意識する

業務系のWebアプリケーションは、だいたい層構造になっています。
Spring Bootの例で言えば、Controller → Service → Repository → DB のような流れです。

バグ調査のときにやりがちなのが、層をまたいで一気に追おうとすることです。
Controllerのコードを読みながら、途中でServiceに飛んで、そのままRepositoryまで潜って……としていると、「あれ、今どこにいるんだっけ？」となります。

自分が意識しているのは、まず「どの層の問題か」を切り分けてから、その層に集中することです。

画面に表示されるデータがおかしい → まずControllerの戻り値を確認
戻り値は正しい → Serviceのロジックは問題ない → DBのデータ or SQLを疑う
戻り値がおかしい → Serviceの加工ロジックを詳しく読む

こうやって「今どの層の話をしているか」を常に意識しておくと、頭が整理された状態でコードを読めます。

3. 「データの形」を追う

処理のロジック（if文やfor文）を目で追うのも大事ですが、自分が一番重視しているのは**「データがどう変化していくか」**を追うことです。

たとえばこんな場面。

APIから受け取ったJSONが、DTOに詰め替えられて
Serviceで加工されて、別のDTOに変換されて
最終的にレスポンスとして返される

このとき、各ステップでデータの中身がどう変わっているかを意識しながら読むと、「ここで値が消えてる」「ここでnullになってる」といった原因に気づきやすくなります。

デバッガで実際にブレークポイントを張って変数の中身を見るのも有効ですが、まず頭の中で「このタイミングでこの変数にはこういう値が入っているはず」とシミュレーションする癖をつけておくと、読むスピードが段違いに上がります。

4. 「分岐の条件」を言語化する

業務ロジックが複雑なコードでは、if-elseやswitchの分岐が大量に出てきます。
これを全部追おうとすると頭がパンクします。

自分がやっているのは、分岐の条件を日本語で言語化することです。

// コード上の分岐
if (status == 1 && checkFlag == true) { ... }

これを頭の中で「ステータスが承認済み、かつチェック済みの場合にこのルートを通る」と読み替える。

こうすると、単なるコードの構文ではなく業務上の意味として理解できるので、「今回のバグはこのルートを通っているのか、通っていないのか」または「通るべきなのか、通らないべきなのか」の判断がしやすくなります。

設計書やテーブル定義書にフラグの意味が書いてあることも多いので、コードだけじゃなくドキュメントを横に置いて読むのもおすすめです。

5. 「ここは読まなくていい」を判断する

これは3年目になって、ようやくできるようになってきたことです。

業務システムのコードは、全部を理解しようとすると膨大すぎます。
バグ調査のときに大事なのは、関係ないコードを「読まない」と判断することです。

共通処理のユーティリティメソッド → 名前と引数から動きが推測できるなら中身は読まない
正常系のルート → 今回のバグは異常系だと分かっているなら飛ばす
別画面でしか使われていないService → 今の調査には関係ないのでスルー

最初のうちは「読まない」が怖いと思います。自分もそうでした。
でも、全部読もうとして時間が溶けるよりは、仮説を持って「ここは関係ないはず」と判断して、外れたら戻る方がトータルで速いです。

「読む力」を鍛えるために意識していること

ここまで書いたような思考法は、一朝一夕で身につくものではないです。
自分もまだまだ発展途上ですが、日常的に意識していることを3つだけ紹介します。

読んだ結果をメモに残す

バグ調査のときに追った処理の流れを、簡単でいいのでメモに残しておくようにしています。

画面A → ControllerA.submit() → ServiceA.execute() → RepositoryA.update()
  └ ここでstatusが2のときだけ分岐してServiceB.notify()を呼ぶ

こういうラフなメモでも、次に同じあたりのコードを読むときに圧倒的にラクになります。
チームメンバーへの共有資料にもなるので、一石二鳥です。

「なぜこう書いたのか」を想像する

コードを読むとき、処理の内容だけじゃなくて**「なぜこの実装にしたのか」**を考えるようにしています。

なぜここでtry-catchしているんだろう → あ、外部API呼び出しだからか
なぜこの処理だけ別メソッドに切り出しているんだろう → 再利用されてるのか、それとも可読性のためか
なぜこの条件分岐がこんなに複雑なんだろう → 仕様変更の積み重ねかもしれない

「意図」を読み取る癖をつけると、初見のコードでも「ああ、このパターンね」と構造が見えるようになってきます。

人のレビューを読む

自分が直接関わっていないプルリクエストのレビューコメントを見るのは、かなり勉強になります。

「なぜここを指摘しているのか」「何が問題なのか」を考えながら読むと、ベテランの人がコードのどこを見ているかが分かってきます。これは自分一人でコードを読んでいるだけでは得られない視点です。

まとめ

3年間の実務で一番実感しているのは、「コードを読む力」は技術力の土台だということです。

バグ調査でも、改修でも、コードレビューでも、まず必要なのは「今ある既存コードを正しく理解すること」。ここができないと、何をやっても空振りになります。

そして「読む力」は、ツールの使い方だけの話ではなく、頭の中で処理の流れを組み立てる思考法が核になっています。

思考法	ポイント
出口から逆にたどる	全体を読まず、バグに関係する経路だけを特定する
層で分けて意識する	「今どの層の問題か」を切り分けてから集中する
データの形を追う	ロジックよりも「データがどう変化するか」を見る
分岐の条件を言語化する	コードの構文を業務上の意味に読み替える
読まない判断をする	仮説を持って、関係ないコードをスキップする

もちろん読む力だけで全部解決するわけじゃないですが、「読める人」はどんな現場に行っても戦えるというのが、3年目の自分の結論です。

同じような環境で働いている方の「自分はこうやって読んでる」みたいな話も聞いてみたいので、コメントもらえると嬉しいです。

3年目の一人のSIerエンジニアの経験をもとに書いています。
現場やプロジェクトによって事情は異なると思いますが、何かの参考になれば幸いです。