プログラミング学習を一通り終えて、いよいよポートフォリオを作ろうとしたとき、多くの人が「何を作ればいいのか分からない」という壁にぶつかります。チュートリアルは進められても、ゼロから自分で設計するとなると手が止まってしまう——これは初心者なら誰もが通る道です。
この記事では、ポートフォリオを「レゴブロック」にたとえながら、何のために作るのか、そしてどう作れば技術力を証明できるのかを整理していきます。読み終えるころには、作るべきものの輪郭がはっきり見えているはずです。
ポートフォリオは何のために作るのか
ポートフォリオは技術力を証明するものです。
-
自分はどんな技術を理解しているか（部品の種類＝知識の広さ）
-
その技術をどう組み合わせられるか（組み方の種類＝理解の深さ）
この2点を示すことが大切です。
作りたいものから入る学びの限界
「Todoアプリを作ろう」と完成品ベースで考えがちです。
しかしこれは、自分の知識だけで「何を作るか」を決めている状態です。
結果、同じようなポートフォリオが乱立してしまいます。
もちろん「作りたいものから始める」こと自体は悪くありません。むしろ最初のやる気を生むきっかけとしては大切です。問題は、そこで学びが止まってしまいやすいことにあります。完成させること自体がゴールになると、「次に何を学ぶか」が見えなくなり、すでに知っているブロックだけで作れるものを繰り返してしまうのです。
そこで、視点を一つだけ変えてみましょう。「何を作るか」ではなく「どのブロックを身につけたいか」から考えるのです。すると、作るものは『目的』ではなく『新しいブロックを試すための手段』に変わります。この発想の転換こそが、ありきたりなポートフォリオから抜け出す最初の一歩になります。
プログラミングはレゴブロック
プログラミングはレゴブロックのようなものです。
- 変数
- if文
- for文
これらは一つひとつが「レゴブロック」に当たります。
そして、それらを組み合わせることで Todoアプリのような完成品が作られます。
もう少しイメージを具体的にしてみましょう。たとえば変数は「データを入れておく箱」、if文は「条件によって進む道を変える分かれ道」、for文は「同じ作業を決めた回数だけ繰り返す仕組み」です。一つひとつは地味で単純なパーツですが、組み合わせ次第で買い物リストにも、ゲームのスコア計算にも、SNSの投稿一覧にもなります。
つまり、新しいアプリを作れるようになるとは、まったく新しい魔法を覚えることではありません。手持ちのブロックの種類と、その組み合わせ方が増えていくことなのです。この感覚がつかめると、一見「難しそうなアプリ」も、よく知っているブロックの集合体に見えてきます。
部品と組み方の種類
プログラミングの学びには、2つの方向があります。
-
部品の種類（知識の広さ）＝水平展開
-
例：変数を学んだら → if文・for文を学ぶ
-
「レゴブロックの部品を増やす」ことに相当します。
-
-
組み方の種類（理解の深さ）＝垂直展開
-
例：if文を学んだら → ネスト条件を学ぶ
-
「レゴブロックの組み方を増やす」ことに相当します。
-
👉 部品の種類（広さ）と組み方の種類（深さ）を増やすことにより、選択肢が増えます。
これは外国語の学習にも似ています。覚えた単語の数（＝部品の広さ）が増えれば表現できる話題が広がり、文法の使いこなし（＝組み方の深さ）が深まれば、同じ単語でもニュアンスを変えて伝えられるようになります。どちらか片方だけでは、言いたいことをうまく形にできません。
プログラミングも同じで、広さと深さの両輪がそろって初めて、「作りたいものを、適切な方法で作れる」状態に近づきます。ポートフォリオは、この両輪を一歩ずつ太くしていくための練習場だと考えてください。
ポートフォリオはどう作るべきか
ポートフォリオは、部品や組み方の種類を増やすために開発するものと考えるべきです。
-
大きなシステムを作る必要はありません。
-
レゴブロックの種類（部品や組み方）を増やすために作る小さな作品で十分です。
小さな作品で技術力を証明する
-
部品の種類を増やす（知識の広さ）
-
非同期処理を学んだ → APIを叩くアプリを作る
-
-
組み方の種類を増やす（理解の深さ）
-
配列操作を学んだ → 検索やフィルタリングができるアプリを作る
-
ポイントは、1つの作品で「証明したいこと」を1つに絞ることです。あれもこれもと詰め込むより、「この作品では非同期処理を理解していることを見せる」と決めたほうが、作るのも説明するのもぐっと楽になります。学んだブロックと、それを使った作品を1対1で結びつけていけば、いつのまにか『語れる作品』が自然と積み上がっていきます。
では、何から作り始めればいいのか
とはいえ、「小さな作品でいい」と言われても、最初の一歩が一番むずかしいものです。迷ったときは、次の順番で考えてみてください。
-
直近で学んだ技術を1つ選ぶ（例：非同期処理、配列操作、ログイン機能）
-
その技術が主役になる最小の題材を決める（例：APIから天気を取得して表示するだけ）
-
動いたら、ブロックを1つだけ足す（例：取得した結果を絞り込めるようにする）
ポイントは、最初から完成形を目指さないことです。レゴブロックも、いきなり巨大な作品を組むのではなく、小さなパーツの組み合わせから始めます。一度動くものができれば、そこに少しずつブロックを足していくだけで、自然と作品は育っていきます。
よくある勘違い：規模の大きさは評価に直結しない
初心者がやりがちなのが、「とにかく大きくて複雑なものを作れば評価される」という思い込みです。しかし採用担当者やレビュアーが見ているのは、システムの規模そのものではありません。むしろ、限られた要素をどれだけ的確に使いこなしているかを見ています。
-
なぜその技術を選んだのかを自分の言葉で説明できるか
-
一つひとつの実装に意図があるか
-
コードが他人にとって読みやすく書かれているか
レゴブロックでたとえるなら、闇雲に大きな城を積み上げることよりも、「この部品をここに使った理由」を一つずつ語れることのほうがずっと価値があります。小さくても設計の意図が伝わる作品のほうが、見る人の印象に残るのです。
コードだけでなく「見せ方」も評価される
意外と見落とされがちですが、「作品をどう説明するか」も立派な技術力です。どれだけ良いコードを書いても、それが相手に伝わらなければ、評価のしようがありません。せっかくのレゴ作品も、ただ箱に入れたまま渡すだけでは、何がすごいのか伝わらないのと同じです。
最低限、次の3つは用意しておきましょう。
-
README（説明書）：何ができるアプリか、どう動かすかを書く
-
作った理由・工夫した点：どんなブロックを、なぜ選んだのかを書く
-
動いている様子：スクリーンショットや短い動画、公開URLを載せる
特に「工夫した点」は、次の章で話す『建前』とそのまま結びつきます。「ここで配列を使ったのは、データが増えても処理を書き換えずに済むようにするためです」——このように選んだ理由を一言添えるだけで、まったく同じ作品でも、見る人に伝わる説得力が大きく変わります。
本音と建前
-
本音：「このレゴブロックを使ってみたかったから作った」
→ 学習の動機。自分が新しい技術を試したかった、という素直な理由。 -
建前：「要件に応じて、この技術を選んだ」
→ 面接や就職活動で説明するときの言葉。
「なぜこの技術を選んだのか」を、要件や課題解決と結びつけて語る必要があります。
大事なのは、「なぜそのレゴブロックを使ったのか」を説明できることです。
「なんとなく使った」はNGです。
👉 この「建前」の部分は、次の章に直結します。
なぜなら現場では、課題解決のために 「技術選定の理由を説明できること」 が求められるからです。
レゴブロックは仕事でどう生きるか
仕事の流れ
-
課題を理解する
-
手持ちのレゴブロックで解決策を考える
-
足りなければ新しいレゴブロックを追加する
開発例：売上を可視化したい場合
同じ課題でも、レゴブロックの組み合わせによって解決策は複数考えられます。
-
方法①：フロントだけで配列＋ループ＋DOM操作
👉 小規模データなら対応できるが拡張性は低い -
方法②：バックエンドでAPI集計＋フロントで描画ライブラリ
👉 実務でよく使われるバランス型の方法 -
方法③：DB集計＋API＋認証＋フロント描画
👉 大規模データや本番運用を見据えるなら最適
では、どれを選べばよいのでしょうか。判断のものさしは「要件」です。たとえば——
-
自分が試しに数値を見たいだけ → 方法①で十分
-
社内の複数人が日常的に使う → 方法②が現実的
-
顧客に提供し、データも増え続ける → 方法③を選ぶ
ここで大事なのは、「とりあえず一番すごそうな方法③」を選ぶのが正解ではないということです。小さな要件に大げさな仕組みを持ち込むと、作るのも後で直すのも大変になります。要件に対して“ちょうどいい”ブロックの組み方を選べること——これこそが、現場でもっとも求められる力なのです。
👉 エンジニアは、複数の選択肢を挙げ、要件に応じて最適なものを選びます。
つまり、
レゴブロックの部品と組み方の種類によって、提案できる解決策の「量」と「質」が決まります。
初心者からよくある質問
Q. 他の人と題材がかぶっても大丈夫ですか？
問題ありません。大切なのは題材の珍しさではなく、「どのブロックを、なぜ、どう組み合わせたか」です。同じTodoアプリでも、説明できる工夫があれば十分に差がつきます。
Q. ポートフォリオは何個作ればいいですか？
数を競う必要はありません。自分の言葉で説明できる小さな作品が2〜3個あれば、知識の広さと深さは十分に伝わります。中身の薄い作品を10個並べるより、語れる作品が数個あるほうが評価されます。
Q. デザインが苦手でも大丈夫ですか？
大丈夫です。見た目の美しさよりも、機能がきちんと動くこと、コードに意図があることが先です。デザインは、あとから足せる「もう1つのブロック」だと考えましょう。
Q. 完全オリジナルでないとダメですか？
いいえ。学習中は既存のアプリを真似て作ることが、そのまま力になります。真似たうえで「自分はここを変えた・足した」と言えれば、それは立派なあなたの作品です。
Q. どの技術から手をつければいいか分かりません。
まずは「今いちばん興味がある言語や分野」を1つだけ決め、その入門で出てくる基本ブロック（変数・条件分岐・繰り返し）を確実に使えるようにしましょう。土台ができれば、次に足すべきブロックは自然と見えてきます。
結論
完成品の見た目や規模に気を取られると、つい「すごいものを作らなければ」と気負ってしまいます。しかし本質は、あなたが扱えるレゴブロックの種類と、その組み合わせ方の引き出しを示すことにあります。
ポートフォリオとは、
自分が持つ「部品」と「組み方」を証明するもの。
部品と組み方を増やすことに集中して作りましょう。
まずは今持っている部品で小さな作品をひとつ作り、そこに新しいブロックを一つ足してみる。その小さな積み重ねが、やがて「提案できる解決策の量と質」となって、あなたの市場価値を確実に押し上げてくれます。
コメント