はじめに
この記事では、
“評価されるポートフォリオの条件” について、僕の視点で書いていこうと思います。
僕はこれまで、自分自身が30歳で完全未経験から自社開発企業に転職した経験があり、
現在では逆に、スタートアップ企業の開発責任者として、未経験者の採用面談も行っています。
両方の視点を知っているので、
自分が採用してもらった時に、ポートフォリオで評価してもらえた点
自分が採用する時に、「おっ良い」と思える点
を中心に紹介していきたいと思います。
1つだけ先に書いておきたいのが、
ここ数年で ”見られるポイント” 自体が変わってきたな、と感じていることです。
AIのおかげで、動くものを作ること自体のハードルはかなり下がりました。
なので「動くものが作れる」だけでは、以前ほど差がつかなくなったと思います。
代わりに見られるようになったのが、
自分の言葉で説明できるか
自分の課題から出発しているか
最後まで完成させ切っているか
の3つだと思っています。
この記事で紹介する項目も、結局はこの3つに繋がるものが多いです。
⚠️ 注意点
1
本記事では
「未経験者がWeb系自社開発企業 or 受託開発企業に転職するためのポートフォリオ（= Webアプリ）」
を対象としています。
Web制作やWebデザインの場合とは全く異なります。
（転職ではなく案件獲得が目的の場合でも、Webアプリを作るのであれば、見られるポイントは基本同じです。）
2
今回紹介するのは、”良いポートフォリオのチェック項目” であって、
”Webサービス公開時のチェック項目” ではありません。
商用Webサービスを本格的にリリースする際には、
セキュリティ、アクセシビリティ、SEO面などなど、留意事項が大量にあります。
ただ、未経験者の転職に用いるポートフォリオはそこまでは見られないので、
本記事ではこういった内容には触れず、
未経験者のポートフォリオのポイントに絞った形で紹介します。
ただ、.envファイルやAPIキーをGitにコミットしないことだけは、
転職用のポートフォリオでも気をつけましょう。（理由は後半で書きます）
良質なポートフォリオの条件
1. フロントエンド〜バックエンドまで開発したオリジナルアプリであること
これはほぼ必須条件にはなりますが、
フロントエンド〜バックエンドまで自分で開発していることが重要です。
フロントエンドエンジニアを目指す場合でも、バックエンドを全く学んでいない場合、
Webアプリと言えるようなものを作ることは基本できません。
できたとしてもヘッドレスCMSを用いたブログサイトのようなものですが、
転職の際の技術力アピールとしては少し弱いです。
アルバイトやインターンの募集に応募する場合であれば、
Webアプリでなくとも、Reactで作ったWebサイトをポートフォリオとしても
採用してもらえる可能性は十分あります。（僕もそうでした）
アルバイトやインターンの働き方でも許容できて、
”とにかく最短で現場に” という方はこのやり方もありだと思いますが、
正社員として転職したい場合は、バックエンドもオリジナルで開発しましょう。
これを当たり前のように感じる方もいるかもしれませんが、
採用活動をしていると
「フロントのみ経験があり、バックエンドは触ったことがない」という方がとても多いです。
フロントからバックエンドまで自分で作っている人はやはり多くないので、
それだけで一定の差はつきます。
ただ、今は作れることに加えて
”自分の言葉で説明できること” までが評価の分かれ目、というイメージです。
2. サービスの内容がわかるLPを用意
よく、採用活動をしていてあるのが、
ポートフォリオが送られてきたけど、トップページがいきなりログインページになっていて、
何のサービスなのか分からない
という事象です。
ログインして中を見ればわかるかもしれませんが、
その手間を採用担当者に踏ませている時点で「あまり仕事できないのかな？」
と思ってしまいます。
なので、サービスのトップページはLPの構成にして
なんのアプリなのか
どんなことができるのか
サービスの特徴（3つくらい）
は最低限、説明するページにしておくことが望ましいです。
最近はLPを用意している方も増えてきたので、
LPがあること自体は前提になりつつあると思います。
基準としては、
「ぱっと見て何のアプリなのかが分かるか」に置いておくと良いと思います。
また、トップページが綺麗にまとまっているだけで、単純に興味をそそられます。
本も、内容がいくら良くても、表紙が良くないとそもそも読まれないといいますが、
それと同じだと思います。
3. GitリポジトリのREADME.mdを充実させる
そもそもですが、採用担当者にポートフォリオを送る際は、
GitHubのリポジトリも一緒に送りましょう。
（少なくとも採用期間中はリポジトリを公開設定にしておくことがおすすめです。）
開発会社の採用では、ポートフォリオのGitHubリポジトリも一緒に確認することが多いです。
その際ですが、リポジトリのページを開いた時にまず目に入る、
READMEが充実しているとかなりポイント高いです。
理由としては
READMEで分かりやすく説明されていると、採用担当者の時間を取らせない気遣いを感じれる（仕事できそう）
READMEはmarkdown記法を用いるので少し技術的な知識も必要なので、充実していると技術への関心度の高さを感じれる
トップページのLPと同じで、充実しているとビジュアル的にも良い第一印象を残せる
READMEに記載すべき内容は以下です。
開発者向けの情報
パッケージインストールコマンド
サーバーの立ち上げコマンド
その他必要なコマンド
閲覧者（採用担当者）向けの情報
トップページのビジュアル
サービスのURL
開発の経緯（なぜそのアプリを作ったか）
機能一覧
使用技術
システムの構成図
ER図
今後の開発の展望
以下にREADMEの1例を載せます。
実際に、僕が現在運営しているサービスのREADMEです。
（コードは公開できないので、READMEのみを置いてるリポジトリです。）
ポイントは
閲覧者向けの情報は画像を多く使って、文字よりもビジュアルメインに
ER図やシステムの構成図は、markdownの
Mermaidという記法で
READMEに直接書いてしまうのが1番ラクだと思います。GitHubがそのまま図として表示してくれます。
（Prismaであればschema.prismaをAIに投げて、「Mermaidで書いて」と指示すれば書いてくれます）
凝った書き方をすると表示されないことがあるので、基本の構文にとどめておくのが安全です。
Miroなどで作ってある場合は、そのスクショとリンク添付でもOKです。「開発の経緯」は結構読まれます。ここでその人の人間性や、課題解決力を結構読み取ります。
なぜそのアプリを作ったのか、なぜその技術を選んだのか、
途中でハマって試行錯誤したこと、あえてやらなかったこと。
ここまで書いてあると、かなり印象に残ると思います。
こんな感じで、READMEを充実させましょう。
閲覧者向けの情報の部分は、Notionにまとめて、GitHubにはリンクだけ載せるでもOKだと思います。（Notionの方がリッチに作れると思うので）
4. ゲストログインボタンを設置する
前提として、デプロイまで済ませて、URLを渡せば誰でも触れる状態にしておきましょう。
「ローカルでは動くんですけど」は、採用側からすると、まだ完成していないのと同じに見えてしまいます。
ゲストログインボタンとは、メアドやパスワードを入力せずとも、押すだけでログインできる機能を持ったボタンです。
転職活動でとにかく大切なのが「採用担当者に時間を取らせない」です。
Webサービスの場合、ログインして中までみてもらいたいと思いますが、
そこまでの手間を可能な限り簡略化してあげる必要があります。
ポートフォリオを送る際に、1番ダメな例が、
「そちらで登録してログインしてください」です。
見られもせずに採用見送りとなる可能性が高いです。
よくあるのが「ログイン情報はこちらです」でメアドとパスワードをメールなどで送られてくるケースですが、
採用担当者としては、それをコピペするのも面倒です。
理想は、ログインページにゲストログインボタンがあって、
それを押すだけでテストユーザーでログインできて、中を確認できるようになっている状態です。
今はもう定番になっているので、あって当たり前に近くなっていると思います。
実装自体は難しくないと思うので、少なくとも採用期間中はゲストログインボタンを設けておくことをお勧めします。
1点だけ実装のTipsとして、
ゲストアカウントのメアドやパスワード、プロフィールは変更できないようにしておきましょう。
次に見る人がログインできなくなる事故を防げますし、
ゲストから他のユーザーのデータに触れないようにもしておくと安心です。
5. テストコードを1つは書いておく
面接で「テストコードは書きましたか？」と問われることが割と多いです。
そこで「ありません」だと少しマイナスになってしまいます。
ただ、だからと言って、未経験者のポートフォリオの全部のページ・処理に対してテストコードが必要かといったら、僕は必要ないと思います。
（実務では必要ですが）
そこでおすすめなのが、1つのページ・機能に対してだけテストコードを書いておくことです。
これで一応テストコード書いたことになりますし、最低限の知識も得られると思います。
その1つを選ぶときに、「なぜそのケースを選んだのか」を説明できるようにしておくと、それだけで話せるネタになります。
また、AIにテストを書かせると正常系（うまくいくケース）に偏りがちなので、
異常系（エラーになるケース）を1つ自分で書いておくと良いと思います。
未経験者がどれだけ勉強を頑張ったところで、実務を毎日やっている人には勝てません。
重要なのは「1日でも早く現場に入ること」なので、
必要最小限のことだけをやって採用されるのが理想です。
最低1つは書いておいた方が良いですが、テストコードに膨大な時間を使うのはやめましょう。
6. AIはどこまで使って良いか
今はAIを使って開発するのが当たり前になってきたので、
「ポートフォリオもAIで作って良いのか？」と気にされる方が結構います。
結論、AIを使って作って全く問題ないですし、隠す必要もありません。
実務でも普通に使っているので、使っていること自体がマイナスになることはないです。
ただ、条件が1つあって、
設計やコードの意図を、自分の言葉で説明できる状態にしておくことです。
ここだけは外せないと僕は思っています。
面接では、ポートフォリオについてほぼ確実に深掘りされます。
「なぜこの構成にしたのか」「ここはどういう処理なのか」あたりは聞かれるので、
そこで答えられないと、作ったものごと評価されなくなってしまいます。
面談でどう聞かれるかはコチラの記事でも解説しています。
また、READMEに「どこをAIに任せて、どこを自分で書いたか」を書いておくのは、
むしろ加点になると思います。
AIに任せる範囲を自分で決められている人、という印象になるからです。
採用側の本音を書いておくと、
「ここはAIに書いてもらいました」と言われて減点することはないです。
むしろ正直に言ってくれた方が、その後の話が早いです。
自己チェックの方法としておすすめなのが、
自分のリポジトリからランダムに1ファイル開いて、上から全部の行を説明できるか試してみることです。
説明が止まる箇所があれば、そこが面接で崩れるポイントだと思います。
7. その他Tips
その他、印象UPに有効なテクニックを紹介します。
GitHubでプライベートリポジトリでも草が生えるように設定する
（草が生える = コミット履歴のある日 = コードを書いてる日）
GitHubのプロフィールページで、草が多く生えていると好印象です。（毎日緑になっていると、めっちゃ頑張ってるな、となる）
毎日コードを書いて、草をたくさん生やして、毎日頑張ってるアピールをしたいところですが、
ちょっと落とし穴があって、GitHubのデフォルトの設定では、プライベートリポジトリへのコミットは、他者から見ると草が生えません。
そこで「Private contributions」の設定をONにしておくと、プライベートリポジトリへのコミットでも草が生えるようになるので、設定しておきましょう。
自分のプロフィールページを開いて、草（コントリビューションカレンダー）の上にある「Contribution settings」から変更できます。
設定画面の見た目は変わることがあるので、「Private contributions」という名前で探してみてください。
（日本語表示だと「コントリビューション設定」→「プライベート コントリビューション」です）特に、オリジナルアプリを非公開リポジトリにするパターンが多いと思いますが、大量にコミットすると思うので、設定しない手はありません。
ちなみに、公開されるのは草だけで、コミットの内容やリポジトリ名は非公開のままです。
コミットメッセージも見られていると思っておく
草の数だけでなく、コミットメッセージの中身を見られることもあります。
fix bugだけ、のようなメッセージがずっと並んでいると、少しもったいないです。何をなぜ直したのかが書いてあると、それだけで丁寧に開発する人だなと感じます。
全部のコミットを綺麗にする必要はないので、書けるときに書く、くらいで十分だと思います。
SNSのリンクを貼っておく
ポートフォリオのアプリに、できればSNSのリンクを入れておきましょう。
採用担当者の心境として、技術力以上に、「どんな人間性の人なのか」の方が気になります。SNS自体の運用もできればした方が良いです。
内容は、学んだことなどの技術的な発信だったり、日常の発信でも良いと思います。
それらを通して人間性が伝わるような状態にしておくのが良いです。（ネガティブな発信はNG）
これがあるだけでも「この人と話してみたい」と思うことは結構ありますし、コスパよく加点を作れると思います。
ブログやYouTubeをやってるなら、それも載せましょう。
逆に、避けておきたいこと
これは避けておいた方が良い、というものを3つだけ挙げておきます。
量産型のテーマで作ってしまう
ToDoアプリ、ブログ、ECサイトのクローンあたりは、昔から数が多いテーマです。
AIで誰でも作れるようになったぶん、以前よりさらに埋もれやすくなったと思います。
題材は、自分が普段困っていることから探すのが1番強いです。
そこから作ると、「開発の経緯」も自然と書けるようになります。
自分で一度も読んでいないファイルがある状態で提出する
AIに任せた部分でも、提出する前に全ファイル目を通しておきましょう。
読んでいないファイルは、そのまま面接で答えられない箇所になります。
.envやAPIキーをコミットしてしまう
これだけは、転職用のポートフォリオでも気をつけてほしいところです。
一度コミットすると、後から消しても履歴から読めてしまいます。
.gitignoreに.envが入っているかどうかは、最初に確認しておきましょう。
逆に、加点になると思うのが、
「やらないと決めたこと」をREADMEに書いておくことです。
「◯◯も実装したかったが、今回作りたいものの本質ではないので入れなかった」
のように書いてあると、自分で優先順位をつけられる人だな、という印象になります。
チェックシート
できれば全てにチェックが入っている状態で、転職活動に挑みましょう！
☐ フロントエンド〜バックエンドまでオリジナルで開発したアプリになっている
☐ AIで書いても良いが、設計やコードの意図を自分の言葉で説明できる
☐ デプロイして、誰でも触れる状態になっている
☐ トップページがサービス内容を説明したLPになっている
☐ GitリポジトリのREADMEに3章で挙げた内容がすべて記載されている
☐ ゲストログインボタンが設置されている
☐ テストコードを1つ以上書いている
☐ GitHubでプライベートリポジトリでも草が生えるように設定されている
☐ SNSのリンクが貼られている
ここまで読んでいただいた方へ
ここまで読んでいただき、ありがとうございます🙇
最後まで読んでいただけた方にだけ、お知らせです。
僕の運営するReact特化のプログラミングスクール「ShiftB」では、
受講生全員に、カリキュラム内で個人開発をして頂きます。
ご自身の作りたいものを完成させた上で、転職活動や案件獲得をして頂いています。
↓紹介動画です。
1on1で開発題材の壁打ち相談、コードレビュー、マネタイズを目指す場合は決済面や法律面の相談にも乗り、
転職市場では上位数%に入るクオリティにまで引き上げる
他のスクールにはない実践型カリキュラムです。
ご興味ある方には、スクールの無料相談会に招待させていただきますので、
コチラからお申し込みください。
