SES面談で「既存プロジェクトの解析で重視していること」を聞かれた

Posted at 2026-06-13

はじめに

先日、SESの面談でこんな質問をされました。

「既存のプロジェクトを解析する時に、重視していることは何ですか？」

その場では答えたものの、「何と答えるのがベストだったのだろう？」と考えていました。

この記事では、その問いに対して改めてじっくり考えたことをまとめています。

まず、面接官がこの質問で何を知りたいのかを考えることが大切です。

表面上は技術的な質問に見えますが、実際には以下を評価していることが多いです。

「解析」という言葉には、読む・動かす・理解する・課題を見つける、といった幅広い行動が含まれています。単に「コードを読む」だけでなく、プロジェクト全体を素早く把握してチームに貢献できるかを問われていると考えると、答えの方向性が変わってきます。

コードを読む前に、まずプロジェクトを頭に入れます。

確認するのは主に以下の点です。

細部を読む前に全体像を把握することで、「この処理はあのあたりにあるはず」という仮説を立てながら読めるようになります。いきなり個別のファイルを読み始めると、木を見て森を見失いがちです。

これが個人的に最も重要視していることのひとつです。

SESや受託開発の現場では、設計書（仕様書）とソースコードが乖離しているケースが頻繁にあります。以下のような状況がよく起こります。

乖離を放置すると、新規参入者や将来の自分が設計書を信じて実装し、バグを埋め込むリスクがあります。

解析の段階で乖離を発見したら、まず「意図的な変更なのか、更新漏れなのか」を確認します。その上で、

という動き方をします。乖離の発見を黙って抱え込まず、チームへの報告と合意形成をセットで動くことが重要です。

動かしてみることも重視しています。

実際に動作させると、以下のことがわかります。

「動いているコード」こそが最も信頼できるドキュメントです。README が古くて手順通りに動かない、というのはよくある話で、そこ自体が重要な情報になります。

git log やプルリクエストの履歴は、コードの「文脈」を理解するための貴重な資料です。

コミットログから読み取れること：

「なぜこんな複雑な処理が？」と思ったコードが、コミットログを見ると「〇〇の仕様変更対応」だとわかることがよくあります。

仕様書がない・古い場合、テストコードとログが仕様書代わりになります。

テストコードは「このメソッドはこう動くべき」という期待値の集合です。実装コードよりも読みやすいことが多く、処理の全体像を素早く把握するのに役立ちます。

テストがない場合は、実際にアプリを操作しながらログを眺めるのが有効です。どのAPIが呼ばれ、どんなデータが流れているかを追うことで、暗黙の仕様を拾い上げることができます。

これらを踏まえて、面談では以下の構造で答えるのが効果的だったのかなと考えました。

「重視していること」→「なぜ重視するか」→「具体的にどうやるか」

既存プロジェクトの解析で重視すべきことを改めて整理しました。