この記事の要点

  • 生成AIの普及でコードを「書ける」こと自体の希少性は下がり、採用担当が見るポイントが意思決定プロセスの言語化に移っている
  • ポートフォリオは「成果物」ではなく「思考の証拠」として機能するよう設計する必要がある
  • 面接・READMEで問われる「なぜその技術を選んだか」への答えを事前に構造化しておくことが内定率に直結する
Contents

AI時代に「何を作ったか」だけでは足りなくなった背景

2024年以降、GitHub Copilot・Cursor・Claude Code といった生成AIツールの浸透により、コードを書くスピードと品質の下限が大きく底上げされました。これは良いことですが、転職市場では副作用も生まれています。

採用側からすると、「ポートフォリオにアプリがある」という事実だけでは、応募者の実力を測りにくくなったのです。コードの大半が AI 生成であっても、見た目の完成度はそれなりのものが作れてしまいます。

実際、エンジニア採用に関わる人たちの間では「ポートフォリオのコードより、それについて話せるかどうかを見るようになった」という声が増えています（筆者が参加した勉強会での複数の採用担当者の発言）。

「言語化力」とは何か：エンジニア文脈での定義

言語化力とは、自分の思考・判断・試行錯誤を他者が理解できる言葉に変換する能力のことです。

エンジニアの転職文脈では、具体的に次の3層に分かれます。

層 問われること 例
技術選定の理由 なぜ Next.js を選んだか SSR/SSG の使い分け、チームの習熟度など
失敗と学習 詰まったポイントと解決プロセス パフォーマンス問題をどう調査・改善したか
ビジネス文脈との接続 何のために作ったか ユーザーの課題、KPI、スコープの意思決定

この3層すべてを語れる人は、AI が実装を補助しようとしまいと、チームに価値をもたらせます。逆に言えば、「作りました」しか言えない人は、AI が台頭した今の市場では以前より差別化が難しくなっています。

ポートフォリオ：思考の証拠として設計する

README の書き方を根本から変える

多くのエンジニアの README は「機能一覧 + 使い方」で終わっています。これは「何を作ったか」の説明であって、「なぜ・どう考えたか」ではありません。

採用担当が読んで差を感じる README には以下の要素が入っています。

## なぜこれを作ったか（課題の定義）
既存の〇〇サービスでは△△ができず、自分が▽▽する場面で毎回不便を感じていた。

## 技術選定と理由
- **フロントエンド: SvelteKit** → React より学習コストが低く、個人開発で速度を優先したため
- **DB: PlanetScale** → スキーマの変更が頻繁な初期フェーズに branching 機能が有効と判断

## 試行錯誤したポイント
認証周りは最初 NextAuth を使ったが、Edge Runtime と相性が悪くはまった。
Lucia Auth に移行したことで解決。その過程で OAuth フローの理解が深まった。

## 今後やりたいこと・やらないこと
〇〇は実装したいが、△△は本質ではないため意図的にスコープ外にした。

「やらないこと」を明記することで、スコープを意識して判断できるエンジニアであることが伝わります。

commit メッセージも言語化の場

コミット履歴は採用担当が実際に見ることがあります。fix bug や update だらけでは何も伝わりません。

# 悪い例
fix bug
update styles

# 良い例
fix: 検索結果が空のとき500エラーになる問題を修正
- Prisma の findMany は存在しないレコードでもnullを返さず空配列を返すため
- ガード節の条件を length === 0 に変更

変更の「なぜ」を一行でも添えるだけで、思考が見えます。

面接で問われる「言語化」の典型パターンと答え方

面接で頻出する質問と、言語化力のある答えのポイントを整理します。

「なぜこの技術スタックを選びましたか？」

NGパターン: 「人気があるから」「よく聞くから」

言語化できている答えの構造:

  1. 制約を明示する（チーム規模、納期、予算、自分のスキルセット）
  2. 比較した選択肢を挙げる（他の候補と何を基準に比較したか）
  3. トレードオフを認める（この選択の弱点も把握している）

例：「TypeScript を選んだのは、型安全性よりも、後から参加するメンバーが意図を読みやすい点を重視しました。コンパイルエラーが増えても、チームへの認知負荷を下げる方が長期コストが低いと判断しました」

「一番難しかった技術的な課題は？」

ここで問われているのは「どんな問題か」ではなく「どう考えて解決したか」のプロセスです。

  • 問題の発見経路（ログ・ユーザー報告・計測）
  • 仮説を何個立てたか
  • 何を試して、なぜそれが失敗したか
  • 最終的な解決策にたどり着いた理由

「結果オーライ」ではなく「なぜそこに至ったか」を語れると、再現性のある問題解決力として評価されます。

日常から言語化力を鍛える方法

転職直前に急に鍛えられるものではないですが、日々の習慣で積み上げられます。

1. 技術的な意思決定を Notion や Zenn のドラフトに残す
自分用メモでも構いません。「今日なぜこのライブラリを選んだか」を3行書くだけでも、言語化の筋トレになります。

2. ペアプロ・コードレビューで「なぜ」を口に出す習慣をつける
実装の選択肢を説明することを義務化されると、曖昧な判断が減ります。

3. 読んだ技術記事を自分の言葉で再要約する
インプットをアウトプットに変換する練習です。Zenn や社内 Wiki への投稿が理想ですが、X（Twitter）への3行まとめでも有効です。

AI ツールとの付き合い方と言語化力

AI が実装を担当する割合が増えても、言語化力が重要である理由はもう一つあります。AI への指示自体が言語化そのものだからです。

「ユーザー認証機能を作って」という曖昧な指示より、「メールアドレスとパスワードで登録・ログインができ、JWTをhttpOnly Cookieで管理し、パスワードはbcryptでハッシュ化する認証機能を実装して」という指示の方が、AI から的確なコードが返ってきます。

AI を使いこなせるエンジニアは、要件を細かく言語化できるエンジニアです。この点でも言語化力は今後ますます差別化要素になります。

よくある質問

Q. ポートフォリオのコードの質は見られないのですか？

コードは見られます。ただし「クリーンに書けているか」より「なぜこの設計にしたか」を問われる比重が増えています。コードが粗くても言語化できていれば評価されるケースがあり、逆に綺麗なコードでも「どこかからコピーした？」と感じさせてしまうと疑義が生じます。最低限の読みやすさ＋言語化の組み合わせを目指しましょう。

Q. 言語化力がないと感じる場合、短期間で改善できますか？

完全な習慣化には時間がかかりますが、面接への即効策はあります。ポートフォリオの技術選定・失敗談・スコープ判断を箇条書きで書き出し、面接前に声に出して練習するだけでも、答えのまとまり方が変わります。

Q. AI が書いたコードをポートフォリオに入れても良いですか？

問題ありません。AI ツールを使って実装した旨を正直に示した上で、「どういう指示を与えたか」「出力をどう評価・修正したか」を README や面接で語れれば、むしろ AI 活用力のアピールになります。

関連記事

AI 初心者 新人プログラマ応援 未経験エンジニア 生成AI