まず、よくある失敗パターン3つ

自分がやってしまったこと、そして他の受講生を見ていて気づいたことから、典型的な失敗を挙げます。心当たりがあれば、そこが伸びしろです。

TODOアプリだけで終わっている。 TODOアプリはLaravel入門の定番ですが、それだけでは「Laravelを触ったことがある」という証明にしかなりません。CRUDの基本は、できて当たり前の地点です。その先にある「自分が作りたかったサービス」まで踏み込まないと、他の応募者との差が出ません。

READMEが空、あるいは「サンプルアプリ」の一行だけ。 これは想像以上に致命的です。GitHubに公開しても、READMEがなければ、見る側は何のアプリか分からないまま閉じます。「説明できないものを作った人」という印象すら与えかねません。

デプロイしていない。 ローカルでしか動かないアプリは、実質的に「見られないアプリ」です。URLを開くだけで動くものと、環境構築が必要なものとでは、確認してもらえる確率がまるで違います。

この3つは、どれも技術力の問題ではありません。見せ方の問題です。同じ実力でも、ここで評価が大きく変わります。

だから、READMEに何を書くか

READMEは、ポートフォリオの顔です。最低限、次の3つは書いてください。

このアプリは何か。 一行で説明できる形にする。「飲食店向けの予約管理アプリです」で十分です。

なぜ作ったか。 ここが一番効きます。後述しますが、動機のストーリーは提案時の武器になります。

どんな技術を使ったか。 使用言語、フレームワーク、DB、インフラ。読む側は、ここで「うちの案件に合うか」を判断しています。

余裕があれば、画面のスクリーンショットとER図も添えてください。文字を読む前に、視覚で伝わります。

デプロイして、URLで見せる

ローカルで完結させず、URLを貼れる状態にしてください。デプロイ先はRenderやRailwayなど、個人開発で使いやすいサービスがあります。

「まだ完成度が低いから公開したくない」——僕もそう思っていました。恥ずかしさがありました。でも、公開しなければ誰にも見てもらえません。存在しないのと同じです。「完璧でなくていいから公開する」という判断は、ポートフォリオに限らず、フリーランスとして仕事をするうえで必要な感覚でした。

「なぜ作ったか」は、想像以上に効く

実際にクライアントへの提案でポートフォリオを使ってみて、意外だったことがあります。

技術的な完成度より、「なぜこれを作ったか」というストーリーの方が、相手に刺さる場面が多かったのです。

「自分が実際に困っていたことを解決したくて作りました」——この一文があるだけで、クライアントには「この人はどういう思考でものを作るのか」が伝わります。逆に、技術的にきれいでも動機が語れないと、ただのサンプルに見えてしまう。

だからアイデア出しの段階で悩んでいる人には、こう言いたいです。完璧な差別化を探さなくていい。自分が実際に困っていたことを解決するアプリ、それだけで説得力は生まれます。 「他の人と被らないもの」を探して何日もコードを書かずにいるより、そちらの方がはるかに価値があります。

ポートフォリオは「一つの完成品」ではなく「積み上げるもの」

ここは、僕が最初に誤解していた点です。

ポートフォリオを「渾身の一作」だと思っていました。実際は違います。複数の制作物の積み重ねが、そのままポートフォリオになります。一つのアプリを磨き続けるより、いくつか作って並べた方が、できることの幅が伝わります。

そして重要なのは、更新し続けることです。最初に作ったものを3ヶ月後に見ると、「もっと良く書けるのに」と感じる部分が必ず出てきます。それはスキルが上がった証拠です。その感覚が出てきたら、リファクタリングしてGitHubを更新してください。「半年前より今の方が良いコードを書ける」という事実そのものが、成長の証明になります。

古いままのポートフォリオは、古い評価しか呼びません。

制作でつまずいたときに、僕がやったこと

ここからは、実際に作る過程での話を短く書きます。

一番つらかったのは、作り始めてから設計の甘さに気づいたときでした。とにかく動かしてから直せばいい、と考えて書き始めた結果、機能が増えるにつれて「一つ直すと別の場所が壊れる」状態になりました。原因ははっきりしていて、Controllerに全部を詰め込んでいたことです。バリデーションもビジネスロジックもデータ取得も、一つのメソッドの中にありました。

最終的に、制作物のひとつを大幅に作り直す判断をしました。せっかく書いたものを捨てるのは、正直かなり抵抗がありました。使った時間が無駄になる感覚がある。でも「このまま進めても良いものにならない」と分かっている状態で進む方が、もっと無駄です。

作り直しで変えたのは2点。テーブル設計をシンプルにしたことと、Controllerの責務を分けたこと（バリデーションはFormRequestへ、ロジックはServiceクラスへ、Controllerは受け渡しに集中）。結果、実装スピードが上がりました。「どこに何を書くか」が決まっているだけで、迷う時間が消えるからです。

ここから得た教訓は、完璧な設計は要らないが、テーブル構成と機能の流れくらいは、実装前に書き出しておくべきだということ。あとで変えることになっても、最初に考えた痕跡が判断の基準になります。

エラーで詰まった時間は、無駄にならない

Laravelでの制作中、画面が真っ白になる、500エラーが出る、データが保存されない、一覧に何も表示されない——数え切れないほど詰まりました。特に苦しんだのはEloquentのリレーション周りで、hasManyとbelongsToの設定を理解しきれておらず、延々とエラーを出し続けていました。

ただ、この時間は無駄ではありませんでした。エラーメッセージには「どのファイルの何行目で何が起きたか」が書いてあります。最初は怖くて流し読みしていましたが、ちゃんと読む習慣がついてから、原因の絞り込みが一気に速くなりました。

この経験が、後の実案件でのデバッグ力にそのままつながっています。今つらい人に言えるのは、同じエラーで二度は詰まらないということです。

まとめ

ポートフォリオ制作は、想像以上に大変でした。アイデアで悩み、設計で失敗し、エラーで詰まり、一度は大きく作り直しました。

でも、作ったあとに評価されるかどうかを分けたのは、技術力ではありませんでした。READMEを書いているか。デプロイしてURLで見せているか。「なぜ作ったか」を語れるか。更新し続けているか。——ここでした。

作って終わりにしないでください。ポートフォリオは完成品ではなく、育てていくものです。完璧を待たず、まず公開する。そこから、評価してもらえる状態が始まります。