個人開発は転職で評価されるのか。経験者が見せるべきは完成度ではなく判断
「個人開発 転職」で出てくる記事はほぼ未経験者向けで、実務経験がある人の疑問——業務のコードを出せない中で何を示せるのか——には答えていません。経験者の個人開発が面接でどう読まれるのかを整理し、評価される形と意味が薄い形を分けました。
目次
「個人開発 転職 評価される」で検索すると、ポートフォリオの作り方を解説した記事がいくらでも出てきます。ただ、実務経験があるエンジニアが読んでも、たいてい途中で手が止まります。
並んでいるのは「GitHubのアカウントを書きましょう」「ToDoアプリは埋もれます」「READMEに技術スタックを書きましょう」といった話で、想定されている読者が未経験からの転職者だからです。すでに現場で2年、5年とコードを書いている人の疑問は、そこにはありません。
経験者の疑問はもっと具体的です。業務で書いたコードは外に出せない。職務経歴書に「〇〇システムの開発に従事」と書いても、自分がどんな判断をしたのかは伝わらない。その穴を個人開発で埋められるのか——この記事はそこだけを書きます。
未経験のポートフォリオと、経験者の個人開発は別の読まれ方をする
同じ「個人で作ったアプリ」でも、職務経歴に実務経験が載っているかどうかで、面接官の読み方が変わります。
「書けること」の証明として読まれる
- 文法とフレームワークを扱えるか
- 最後まで作り切れるか
- 学習を継続できるか
- 動いていること自体に意味がある
「判断できること」の証明として読まれる
- 要件に対して構成をどう決めたか
- どの案を捨てたか、理由は何か
- 異常系や運用をどこまで考えたか
- 動くことは前提で、見られるのはその先
ここを取り違えると、時間をかけたのに評価されないという結果になります。経験者が「3ヶ月かけて機能を20個のせました」と見せると、面接官が受け取るのは実装力ではなく、作業量です。実装力はすでに職務経歴から読めているので、新しい情報になりません。
逆に、機能が3つしかなくても「この要件に対してA案とB案を比べ、こういう理由でAを選んだ」が言えると、職務経歴書では見えなかった判断の質が初めて見えます。経験者の個人開発は、量ではなくここで差がつきます。
経験者ほど「判断を見せる手段」を持っていない
実務経験があるのに個人開発が必要になるのは、転職の場で使える材料が意外なほど少ないからです。
- 業務のコードは、ほぼすべて外に出せない
- 職務経歴書に書けるのは担当範囲と技術名までで、判断の中身は書けない
- 社内で評価された設計も、前提を共有していない人には伝わらない
- コードテストは出題者の課題なので、自分で要件を決めた経験は示せない
この4つはどれも、個人の努力では解消できません。だから、自分で要件を決めて、自分で判断した跡が残っているものが1つあると、それだけで説明の材料になります。個人開発が効くのは、実装力の証明ではなく、この一点です。
市場での評価が何で決まるのかを先に整理したい人は、エンジニアの市場価値を上げる方法も合わせて読んでください。
評価されにくい個人開発に共通する4つ
作ったのに話が広がらないケースには、はっきりした共通点があります。
正常系しか動かない
ログインして一覧が出て、登録できる。ここまでで止まっているものは、チュートリアルの延長として読まれます。実務で時間を取られるのは、読み込み中・失敗・0件・権限がない・通信が切れたときの扱いで、面接官もそこを見ます。
技術名の数で勝負している
READMEに「Next.js / TypeScript / Prisma / Docker / AWS / CI」と並んでいても、評価は上がりません。むしろ「なぜこの構成なのか」を聞かれて答えられないと、使ったことがあるだけだと判断されます。使った技術の数より、選んだ理由を説明できる技術の数です。
規模だけが大きい
画面が30あるアプリより、画面が5つで設計の意図が説明できるアプリのほうが通ります。面接で話せる時間は長くても10分程度で、全体像を説明し終わるだけで終わってしまうものは、中身に入れません。
公開していない
ローカルでしか動かないものは、面接の場で開けません。デプロイして、URLを渡せる状態にしてあるかどうかで、話せる深さが変わります。
評価される個人開発には、判断の記録が残っている
やることは、派手な機能を足すことではありません。作る過程で下した判断を、あとから読める形にしておくだけです。
1つの機能について残しておくこと
- 01何を解決したかったのか（自分が困っていたことなら、それがいちばん強い）
- 02考えた案が2つ以上あり、採用しなかった案とその理由が書いてあるか
- 03その選択で何を捨てたか（速度・拡張性・開発時間のどれを諦めたか）
- 04作ってみて間違っていたと分かった判断があるか
4つ目を書けると強いです。「最初は状態を親に全部持たせたが、画面が増えて破綻したので途中で分けた」という話は、設計を自分で検証した証拠になります。最初から正しかった話より、修正した話のほうが信用されます。
書く場所は、READMEの数行でも、個人ブログでも、Qiitaやnoteでも構いません。コードの外に判断が残っていることが条件です。
規模を広げるより、1箇所を深くする
限られた時間で判断の質を見せるなら、全体を薄く作るより、1箇所だけ実務と同じ深さまで作るほうが効きます。深くする場所は、どれか1つ選べば十分です。
| 深くする箇所 | 判断が生まれる場所 |
|---|---|
| 認証と権限 | 誰が何を見られるかの線引きを自分で決める |
| 状態の持ち方 | どこに置き、どこまで共有するかを毎回決める |
| エラーと異常系 | 失敗したときに何を見せ、何を記録するか |
| データの構造 | 後から項目が増えても壊れない形にするか |
| 計測 | 使われているかをどう確認するか |
このうち1つを選んで、「なぜその形にしたか」を説明できる状態まで持っていけば、面接の10分は十分に埋まります。設計の判断そのものが苦手だと感じている場合は、実装はできるのに設計ができない原因のほうが先かもしれません。
面接で実際に聞かれること
評価されるかどうかは、結局この種類の質問に答えられるかで決まります。作り終わったあとに、自分で一度やってみてください。
- なぜこれを作ったのか（誰のどんな困りごとか）
- この構成を選んだ理由は何か。他に検討した案は何か
- いちばん時間がかかった箇所はどこで、何に詰まったか
- 今もう一度作るなら、どこを変えるか
- ユーザーが100倍になったら、最初に壊れるのはどこか
1つでも詰まるなら、機能を足すより先にそこを埋めたほうが通ります。逆に5つ全部に答えられるなら、規模が小さくても個人開発は材料として成立しています。
正直なところ：個人開発は職歴にはならない
ここは曖昧にしないほうがいいので、はっきり書きます。個人開発は、職務経歴としての実務経験にはなりません。業務としてコードを書いて報酬を受け取った期間だけが実務経験で、職歴の欄に個人開発を書くことはできません。「個人開発で実務経験が積めます」という説明を見たら、疑ったほうがいいと思います。
一方で、面接で評価されるかどうかは別の話です。見られているのは「どこで作ったか」ではなく「どんな判断をして作ったか」なので、個人開発でも対象になります。この線引きについては経験者向けスクールの選び方でも触れました。
つまり個人開発は、書類を通すためのものではなく、面接で話すためのものです。応募要件の年数を埋める用途には使えません。ここを期待して始めると、だいたい徒労になります。
個人開発に手を出す前に確かめること
経験者の場合、個人開発が最適な手段ではないこともあります。次のどれかに当てはまるなら、先にそちらを片付けたほうが早いはずです。
- 業務のなかで設計から任されている案件がある → それを言語化するほうが材料として強い
- 転職の軸が「同じ領域で待遇を上げる」 → 職務経歴の書き方を直すほうが効きます
- 使いたい技術が決まっていない → 題材より先に、どの判断を見せたいかを決める
逆に、業務が保守や運用中心で設計の判断をする機会がない人には、個人開発以外に手段がほとんどありません。この場合は作る価値があります。Reactで「実務レベル」をどう見られるかを整理したReactの「実務レベル」とは何かも、作る題材を決めるときの基準になります。
まとめ
| よくある前提 | 経験者の場合 |
|---|---|
| 完成度が高いほど評価される | 判断が説明できるほど評価される |
| 機能は多いほうがいい | 1箇所が深いほうがいい |
| 技術名を並べると強い | 選んだ理由を言えないと逆効果 |
| 実務経験の代わりになる | 職歴にはならない。面接の材料になる |
経験者の個人開発でやることは、自分が下した判断を、他人が読める形にして外に出すことです。業務ではそれができない——だから個人開発を使う、という順番で考えると、作るものの大きさも、かける時間も決めやすくなります。
JISOUでは、自分のアイデアでサービスを作る段階を通して、提出したコードに現役エンジニアのレビューが入ります。学んだこととつまずいた点を記事としてアウトプットすることも受講の前提になっているので、判断の記録が自然に残ります。「作ったが評価されるか分からない」状態が続いているなら、一度外の目を通してみてください。