転職活動用のポートフォリオに、使った技術スタックをずらりと並べた。フロントはこれ、バックエンドはこれ、DBはこれ。それなりに動くものを作ったのに、面接ではなぜか手応えがない。技術の話をしているはずなのに、相手の反応が薄い。そんな経験はないでしょうか。

結論から言うと、採用側が見ているのは「何を使ったか」ではありません。見られているのは「何のために何を作り、なぜその技術を選んだのか」という、技術選定と設計の根拠のほうです。この記事では、ポートフォリオで差がつくポイントが「理由を語れるか」にあることを、具体的な言い換えの例で整理します。

ムチオ
ムチオ
使った技術はぜんぶスタックに書いたんだけどな…なんか面接であんまり刺さらないんだよね。
ルミナ
ルミナ
スタックの一覧は、実は誰でも書けてしまうんです。採用側が知りたいのは、その一覧そのものよりも「なぜそれを選んだのか」のほうなんですよ。

実装できるのは当たり前。差がつくのは「理由を語れるか」

生成AIが当たり前になったいま、動くものを作ること自体のハードルは下がりました。教材も無料の解説も充実し、手を動かせば形にはなります。だからこそ、実装できること単体では差がつきにくくなっています。

では何で差がつくのか。技術選定と設計の根拠を、自分の言葉で語れるかどうかです。採用側は、あなたが書いたコードの1行1行を審査したいわけではありません。「この人は、目的から逆算して手段を選べる人か」を見ています。同じものを作っていても、なぜその構成にしたのかを説明できる人と、できない人では、印象が大きく変わります。

なぜこれが効くのかは、AI時代のエンジニアに本当に必要な力でも触れている「手を動かす力」から「判断できる力」への移り変わりと重なります。

やりがちなNG例：構成を並べるだけは「当たり前の自白」

まず、多くの人がやってしまう説明の例を見てみます。

「フロントエンドはVue.jsでSPAとして実装し、axiosでバックエンドのLaravelのAPIと連携しました」

一見それらしく聞こえますが、これは工夫を語っているようで、実は何も語れていません。使った部品を順番に読み上げているだけで、そこにあなたの判断が入っていないからです。

ムチオ
ムチオ
えっ…これ、ぼくがまさに言いそうなやつだ。ちゃんと構成を説明したつもりだったのに。
ルミナ
ルミナ
構成の説明としては正しいんです。ただ、その内容は仕様書を読めば誰でも言える範囲なんですね。だから採用側には「作った結果をなぞっているだけ」に聞こえてしまいます。

言い換えると、これは「私はこの構成にした理由を考えていません」という当たり前の自白になりかねない、ということです。VueとLaravelとaxiosを使った、という事実は、あなたでなくても言えてしまいます。

良い例：この問いに自分の言葉で答えられるか

差がつく人は、同じ構成でも次のような問いに答えられます。ポートフォリオを見直すときの、そのままチェックリストとして使えます。

  • なぜバックエンドにLaravelを選んだのか。なぜRailsやほかのフレームワークではなかったのか
  • なぜフロントにVue.jsを選んだのか
  • なぜSPA構成にしたのか。サーバー側でページを組み立てる方式ではなかったのはなぜか
  • なぜ認証にJWTを使ったのか
  • なぜデータベースにMySQL(RDS)を選んだのか

一つひとつに、たとえ短くても自分の言葉で答えられるか。ここが分かれ目です。

ムチオ
ムチオ
なぜLaravelか、なんて考えたことなかったな…なんとなく解説記事が多かったから、くらいで。
ルミナ
ルミナ
最初はそれでも構いません。大事なのは、作り終えたあとに「では、なぜそれが良かったのか」を言葉にしておくことです。使いながら気づいた理由を、後から言語化するだけでも十分に語れるようになりますよ。

改良した説明の例：目的と理由でつなぐ

先ほどのNG例を、目的と理由で語り直すとこうなります。

「このツールは非同期でリッチに動く機能が多く、検索エンジン対策(SEO)が不要な社内向けの用途だったので、画面の切り替えが速いSPA構成にしました」

「標準機能が充実していて開発を速く進めやすく、あとから機能を足すときも保守しやすいと考えて、バックエンドにはLaravelを選びました」

使っている技術名は同じです。違うのは、頭に「何のために」があり、後ろに「だからこれを選んだ」がついていることだけ。この前後がつくと、聞き手には「この人は目的から手段を逆算できる」と伝わります。

作ったものを「動けばいい」で止めず、選んだ理由や見えないところの設計まで語れる状態は、個人開発で見るべきセキュリティ・非機能要件の考え方とも地続きです。

完璧な正解を選ぶ必要はない。トレードオフを語れるか

ここで安心してほしいのは、技術選定に唯一の正解を当てる必要はない、ということです。どの技術にも得意なことと苦手なことがあり、選択にはトレードオフがつきものです。採用側もそれを分かっています。

見られているのは「最適解を引き当てたか」ではなく、「その状況で、何を優先し何を捨てて、なぜそれを選んだのかを説明できるか」です。たとえ後から見て別の選択肢のほうが良かったとしても、当時の判断の筋道を語れれば、それは十分に評価されます。

ムチオ
ムチオ
なるほど、間違ってたらどうしようって身構えてたけど、理由を言えるかどうかが大事なんだね。
ルミナ
ルミナ
そうなんです。そして、いまはAIに技術選定そのものを相談して作る人も増えていますよね。その場合こそ、なぜその構成になったのかを自分でも説明できる状態にしておくのが安心です。AIに任せて作る進め方はバイブコーディングとはで触れています。

AIが出してきた構成をそのまま使うのは悪いことではありません。ただ、面接でその構成の理由を聞かれたときに「AIがそう言ったので」としか答えられないと、判断を人任せにしている印象が残ってしまいます。AIに手段を相談したとしても、最終的な理由は自分の言葉で言えるところまで持っていく。そこまでやって、はじめてポートフォリオがあなたの実力の証明になります。

次の一歩

ポートフォリオを作り終えたら、コードを1行も書き足さなくてもできることがあります。使った技術一つひとつに「なぜこれを選んだのか」を1〜2文で書き添えてみることです。書けない項目があれば、そこがあなたの伸びしろです。

まとめ

  • 実装できることは、もう差になりにくい。差がつくのは技術選定と設計の根拠を語れるかどうか。
  • 採用側は「何を使ったか」より「何のために何を作り、なぜそれを選んだか」を見ている。
  • 構成を並べるだけの説明は、工夫のようで「当たり前の自白」になりやすい。
  • 目的と理由でつないで語れば、同じ技術でも印象は大きく変わる。
  • 完璧な正解は不要。トレードオフを理解し、その状況で選んだ理由を言えることが評価される。AIに選定を任せたときこそ、理由を自分で語れる状態にしておく。

独学でつまずきやすいのは、知識そのものよりも「何をどの順番で学ぶか」です。技術選定の理由を語れるようになる練習も、あなたの目標から逆算した学ぶ順番の一部として、1対1で一緒に整理できます。