はじめに
プログラミング学習を始めた頃、ポートフォリオ制作を少し甘く考えていました。
チュートリアルを進めているとき、コードの意味がなんとなく理解できていて、「この調子でポートフォリオも作れるだろう」と思っていました。
実際に取り組んでみると、全く違いました。プログラミング学習の中で最も苦労したのが、ポートフォリオ制作の過程だったかもしれません。
チュートリアルと自作は別物だった
学習中はチュートリアルに沿ってアプリを作ります。「次はこのコードを書いてください」という手順が用意されていて、エラーが出ても「こう直してください」という解説がある。そういう環境でコードを書くことと、ゼロから自分でサービスを作ることは、全く別の作業でした。
チュートリアルの中では、「何を作るか」「どんな機能を付けるか」「どう設計するか」——これらが全部決まっていました。自分でやることは「言われた通りに実装すること」だけでした。
ポートフォリオ制作に入ったとき、そのことに初めて気づきました。決まった手順がない。正解も分からない。「チュートリアルを理解した」と思っていたのは、実は「誰かが決めた道を歩いただけ」だったのです。
作りたいものが決まらなかった
技術的な問題よりも先に、アイデアで詰まりました。
何を作ればいいかが分からない。Todoアプリはありきたりすぎるのではないかとか、他の人と同じものを作っても意味がないとか、もっと差別化できるものがあるはずとか——そういったことを考え続けて、コードを一行も書かないまま何日も過ぎていきました。
振り返ると、最初から完璧な差別化を目指す必要はありませんでした。「自分が実際に困っていた問題を解決するアプリ」というだけで、アイデアとしての説得力が生まれます。技術よりも「なぜこれを作ったか」が説明できる方が、ポートフォリオとしては重要だったのです。
設計の重要性を軽視していた
アイデアが決まって実装を始めたとき、自分は設計をほとんど考えずにコードを書き始めました。
「とにかく動かしてみてから修正すればいい」という考えでした。最初は順調に進んでいましたが、機能が増えてくるにつれて問題が出てきました。
一つの機能を修正すると、別の場所が壊れる。機能を追加しようとすると、既存のコードに引っかかって上手くいかない。データの取り方を変えようとすると、表示側まで影響が出る——いわゆる「動いているけど崩れそうな状態」になっていました。
原因のひとつは、Controllerに全ての処理を書き込みすぎたことでした。バリデーション・ビジネスロジック・データ取得・画面への受け渡し——これらが一つのメソッドに詰め込まれていると、どこを直せばいいのかすら分からなくなります。
「まず設計の方向を決めてから実装を始める」ということを、この経験から学びました。完璧な設計が必要なわけではありませんが、「テーブル設計」「機能の流れ」くらいは事前に整理しておくと、後からの修正がずっと楽になります。
エラーで詰まり続けた
Laravelで制作を進めていると、予想外のエラーに何度も遭遇しました。
画面が真っ白になる。500エラーが出る。データが保存されない。一覧ページで何も表示されない。リダイレクト先がおかしい——最初は何時間調べても原因が分からないことが何度もありました。
特に苦戦したのはリレーション周りのエラーでした。EloquentのhasMany・belongsToの設定が間違っていて、データを取得しようとすると延々とエラーが出る。「モデルの関連付けの仕組み」を表面的に理解しているだけで、なぜそうなるのかを本質から理解できていなかったことが原因でした。
エラーを調べていく中で気づいたのは、「エラーメッセージをちゃんと読む」ということでした。最初は恐くて流し見していましたが、エラーメッセージには「どのファイルの何行目で何が起きたか」という情報が含まれています。慣れてくると、エラーメッセージだけでかなり原因を絞り込めるようになりました。
この経験が、後の案件でのデバッグ力の基盤になったと思っています。
一つの制作物を大幅に作り直した
制作物のひとつで、ある段階から大幅に作り直すことにしました。
機能を追加するたびに別の場所が壊れる状態が続き、「これ以上この状態で続けても限界がある」と判断したためです。
せっかく作ったものをゼロから作り直すのは、正直かなり抵抗がありました。今まで使った時間が無駄になる感覚。また同じところでつまずくのではないかという不安。それでも「このまま続けても良いものが完成しない」という判断で、作り直すことにしました。
作り直すにあたって変えたのは2点です。まずテーブル設計を見直してシンプルにしました。次に、Controllerの責務を分けました。バリデーションはFormRequestへ、ビジネスロジックはServiceクラスへ、Controllerは受け渡しだけに集中させる構成にしました。
結果、作り直してから実装のスピードが上がりました。「どこに何を書けばいいか」が明確になったことで、迷う時間が減ったのです。
完成させることを優先した
ポートフォリオ制作で学んだ一番大切なことは、「完璧を目指すと完成しない」ということでした。
「きれいなコード・充実した機能・整ったデザイン」を同時に達成しようとすると、どれも中途半端なまま時間が過ぎていきます。
途中から、「まず動く状態で完成させる」に切り替えました。リファクタリングは後でできる。機能は後で追加できる。デザインも後で整えられる。でも「完成させる」ことだけは、今やらないといつまでもできません。
この発想の切り替えをしてから、ペースが上がりました。制作物が完成してから改善に取り組む方が、永遠に完成しない状態で改善を追いかけるよりも、ずっと効果的でした。
複数の制作物を通じて得たこと
最終的にポートフォリオとして複数の制作物を作りました。
それぞれの制作物を通じて、技術的な学習よりも「仕事の進め方」に関する学びが多かったと感じています。
仕様を自分で決める力。詰まったときに調査して突破する力。「完成させる」という意志。設計をある程度考えてから実装する習慣——これらは、チュートリアルをこなしているだけでは身につかなかった部分です。
後に実際の案件に入ったとき、ポートフォリオ制作での経験が直接活きていると感じる場面が何度もありました。「似たようなエラーで詰まったことがある」「この設計の問題点はここだ」という感覚は、ポートフォリオ制作の苦労の中で培われたものでした。
ポートフォリオを見てもらう機会を作った
制作物が完成してから、もうひとつ意識したことがあります。「作って終わり」ではなく、見てもらう機会を作ることです。
クラウドソーシングの提案文にポートフォリオのリンクを貼る。GitHubに公開してREADMEを整備する。技術ブログに「こういうものを作りました」という記事を書く——これらをやることで、制作物が「存在するだけのもの」ではなく「見てもらえるもの」になります。
最初は恥ずかしい気持ちがありました。「こんな未完成のものを見せていいのか」という躊躇です。でも公開しないと誰にも見てもらえません。「完璧でなくていいから公開する」という姿勢は、ポートフォリオに限らず、フリーランスとして仕事をする上でも大切な感覚でした。
これからポートフォリオを作る人へ
もしこれからポートフォリオ制作に取り組む人がいれば、いくつか伝えたいことがあります。
完璧なアイデアを探さなくていい 自分が実際に困っていたことを解決するアプリ、日常の不便を改善できるもの——それだけで十分です。アイデアで悩む時間より、作り始める方が大切です。
実装前に最低限の設計を考える テーブルの構成と主要な機能の流れだけでも事前に書き出しておくと、実装中の迷いが減ります。あとから大きく変えることになっても、最初に考えた痕跡が判断の基準になります。
詰まることは無駄ではない エラーで何時間も詰まった経験は、後で必ず役立ちます。そのときは辛くても、その経験がデバッグ力・調査力の基盤になります。同じエラーで詰まることは二度とありません。
完成させることを最優先に きれいなコードでなくていい。機能が少なくてもいい。まず「動く状態で完成」を目指してください。リファクタリングは完成後にいつでもできます。
完成したら公開する GitHubに上げてREADMEを書く。ポートフォリオサイトに掲載する。誰かに見てもらえる状態を作ることが、次のステップ（応募・案件獲得）への入口になります。
まとめ
ポートフォリオ制作の過程は、想像以上に大変でした。アイデアに悩み、設計で失敗し、エラーで詰まり、一度大きく作り直しました。
それでも、あの過程があったから今の自分があると思っています。
チュートリアルの学習とポートフォリオ制作の間には、大きな壁があります。その壁を越えることで初めて「自分で考えて作れる」という感覚が身につきます。詰まっても、やり直しても、それ自体が大切な学習です。完璧を目指さず、まず完成させること——この一点を大切にして取り組んでみてください。
ポートフォリオを作った後に実感したこと
制作物が完成して、実際にクライアントへの提案で使ってみて初めて気づいたことがあります。
「ポートフォリオは完成品ではなく、進化させるもの」だということです。
最初に作った制作物は、3ヶ月後に見ると「もっと良く書けるのに」と感じる部分があります。スキルが上がった証拠でもあります。その感覚が出てきたら、積極的にリファクタリングして、GitHubを更新してください。「半年前より今の方が良いコードが書ける」という事実が、継続的な成長の証拠になります。
また、制作物に込めた「なぜこれを作ったか」というストーリーが、提案時に意外と効果的でした。「自分が実際に困っていたことを解決したくて作りました」という文脈があると、クライアントにとってその人の思考が伝わりやすくなります。技術的な完成度だけでなく、作った動機と目的を言語化する練習もしておいてください。
ポートフォリオのよくある失敗パターン
自分が犯したこと、他の受講生の話を聞いて知ったことから、ポートフォリオのよくある失敗パターンを整理しておきます。
TODOアプリだけで終わっている TODOアプリはLaravel入門として定番ですが、それだけでは「Laravelを触ったことがある」という証明にしかなりません。CRUDの基本の先にある「自分が作りたいサービス」を作ることが重要です。
動かすことに精一杯でREADMEがない GitHubに公開してもREADMEが空だったり、「サンプルアプリ」とだけ書いてある状態は、クライアントや企業に「説明できないものを作った」という印象を与えます。「このアプリは何か」「なぜ作ったか」「どんな技術を使ったか」を書いてください。
デプロイしていない ローカルでしか動かないアプリは、確認してもらいにくいです。HerokuやRenderなどのサービスを使って、URLを貼れる状態にしておくと大きく印象が変わります。
これらは技術力の問題ではなく、「見せ方の問題」です。同じ技術力でも、見せ方で評価が大きく変わることを知っておいてください。
おすすめのサービス
