採用担当は、あなたのコードより先に「README」を開いている
ポートフォリオを提出したのに、面接で一度も中身を聞かれなかった。そんな経験をした人は少なくありません。手をかけた本人ほど、力作を隅々まで見てもらえると思いがちです。けれど採用側の現実は違います。
一次選考でポートフォリオを開く採用担当は、何十件ものリポジトリをさばいています。一つひとつのコードを最後まで追う時間はありません。最初に見るのは、たいていリポジトリの一番下に表示されるREADMEです。複数の採用支援メディアが口をそろえて「READMEはプロジェクトの顔」と言うのは、ここが入口だからです。冒頭の200〜300字で「何を作ったのか」「なぜ作ったのか」が伝わらなければ、その時点で次の候補へ移ってしまう。技術力以前の、伝える力の勝負がもう始まっています。
未経験から目指している人は、土台になる学習の順番を未経験からITエンジニアになるロードマップで先に押さえておくと、ポートフォリオに載せる題材も選びやすくなります。
機能の多さで勝負しようとして外す
つまずく人がよくやるのが、機能を盛ることです。ログイン、検索、決済、通知、管理画面。詰め込むほど評価が上がる気がして、未完成のまま数を増やしていく。
採用担当が見たいのは、機能の数ではありません。「この課題を、こう考えて、こう解いた」という筋道です。なぜそのアプリを作ったのか。誰のどんな不便を解消したかったのか。その問いに一行で答えられないポートフォリオは、いくら画面がにぎやかでも印象に残りません。逆に、解決したい場面がはっきりしている小さなアプリは、面接で話が広がります。「ここで詰まって、こう調べて乗り越えました」という会話こそ、相手が聞きたかったものです。
機能の派手さは、二次的な要素だと割り切ったほうがうまくいきます。
コードの読みやすさは、チームで働ける証拠として見られる
コードを見るとき、採用担当が気にしているのは「正しく動くか」だけではありません。むしろ重視されるのは「チームで一緒に書けるコードか」という一点です。
変数名や関数名から意図が読み取れるか。同じ処理をだらだら繰り返していないか。一つの関数が何でも詰め込んだ巨大な塊になっていないか。インデントや書き方のスタイルが最後まで揃っているか。複雑なところに、なぜそうしたのかが一言添えてあるか。どれも難しい話ではありません。それでも、できていない応募者は多い。
実務の開発は、自分が書いたコードを他人が読み、引き継ぎ、直していく作業の連続です。読みやすいコードを書けることは、協調性やコミュニケーション能力の遠回しな証明として扱われます。きれいに書く意識があるかどうかは、画面の派手さよりもよほど雄弁です。どの言語で見せるか迷うなら、エンジニアが市場価値を上げるために重要な言語も判断材料になります。
Gitの履歴に、仕事の進め方が出る
意外と見られているのが、コミットの履歴です。
「update」「fix」だけが延々と並ぶ履歴と、何をどう変えたかが一目で追える履歴では、与える印象がまるで違います。前者は行き当たりばったりに見え、後者は段取りよく進める人に見える。一度に大量のファイルをまとめてコミットしているか、意味のある単位で小さく分けているか。ブランチを切って作業しているか。そうした痕跡から、採用担当は「入社後、どんなふうに仕事を進める人か」を想像します。
コードそのものを読めない非エンジニアの人事でも、コミットメッセージの丁寧さやプロフィールの整え方は判断できます。一次スクリーニングでは、まさにそういう「中身を読まずに分かる部分」で候補が絞られていく。履歴は後から書き換えにくいぶん、ふだんの仕事ぶりがそのまま透けて見える場所だと考えておいてください。
「動くURL」がないと、見てもらえない
地味ですが、決定的に効くのがこれです。デプロイされていて、クリックすればすぐ触れる状態にしておく。
採用担当は、わざわざ手元の環境を整えてあなたのアプリを起動してくれるわけではありません。READMEに長い手順が書いてあっても、動かすところまで付き合う余裕はない。動くURLが用意されていなければ、それだけで評価の土俵から外れてしまうことがあります。せっかく中身が良くても、入口で触れられないのは大きな損です。
公開したら、別の端末やスマホからも一度開いて、初見の人がつまずかないか確かめておく。テストが通っていることを示すバッジや、自動でデプロイされる仕組みまであれば、品質への意識が伝わって加点されます。
一本を仕上げ切るほうが、数より効く
未完成のプロジェクトを三つ並べるより、完成した一つのほうが、はるかに評価されます。
採用担当の本音として、中途半端な作品がいくつあっても「最後までやり切れない人」という印象が残るだけです。READMEが整い、コードが読みやすく、テストが通り、デモが動く。その状態の一本があれば、一次選考を抜けるには十分です。あれもこれもと手を広げたくなる気持ちはわかりますが、まずは胸を張って「これを見てください」と言える代表作を一つ仕上げる。そこに力を集中したほうが、結果は早く出ます。
文系出身で遠回りに感じている人も、やることは同じです。文系からWebエンジニアは目指せるかで土台を確認したうえで、小さくても完結した一本を作れば、出身は関係なく評価されます。
評価されるのは、技術自慢ではなく伝える姿勢
ポートフォリオは、技術力を見せる場であると同時に、「この人と働けるか」を測られる場でもあります。
採用担当がたどる順番は、だいたい決まっています。READMEで全体像をつかみ、コードで読みやすさを確かめ、Gitで進め方を推し量り、動くURLで仕上がりを見る。派手な機能で勝負するより、この一筋の流れを丁寧に整えるほうが、ずっと通りやすい。
作る側の「すごいでしょう」より、見る側の「これなら一緒に働けそう」を引き出せたとき、ポートフォリオは本当の武器になります。提出する前に、初めて見る人の目で一度たどり直してみてください。
よくある質問（FAQ）
Q1. ポートフォリオは何個あればいいですか？
数より完成度です。READMEが整い、コードが読みやすく、デモが動く一本があれば一次選考は十分に戦えます。未完成のものを並べると、やり切れない印象につながるため逆効果になりがちです。
Q2. 採用担当はコードを全部読みますか？
読みません。多くのリポジトリをさばくため、まずREADMEで全体像を確認し、気になった部分のコードを拾い読みします。だからこそ冒頭で「何を・なぜ作ったか」が伝わる構成が大切です。
Q3. デザインが苦手でも大丈夫ですか？
問題ありません。見た目の華やかさより、課題設定の明確さとコードの読みやすさが重視されます。動くURLとわかりやすいREADMEがあれば、シンプルな見た目でも評価されます。
Q4. GitHubの「草」は濃いほうが有利ですか？
継続性の参考にはされますが、絶対的な指標ではありません。草が薄くても優秀な人は大勢います。それより、コミットメッセージの丁寧さや一本の完成度のほうが見られています。
Q5. 業務で書いたコードは載せていいですか？
基本的に避けてください。会社の資産や機密に当たる可能性があります。題材は個人開発や、許可の取れた範囲にとどめ、どうしても見せたい場合は会社の規定を確認しましょう。