ポートフォリオは「NOT作品集」。クライアントの課題を解決する「提案書」

就職活動や案件獲得の場において、多くのエンジニア志望者が犯す致命的なミスがあります。それは、ポートフォリオを単なる「作品の陳列棚」にしてしまうことです。

「ReactでToDoアプリを作りました」

「架空のカフェのランディングページです」

「使用技術はVue.jsとFirebaseです」

断言しますが、採用担当者やクライアントは、あなたが何を作れるか（What）には、そこまで興味がありません。彼らが真に知りたいのは、あなたがその技術を使って「自分たちのビジネスの課題をどう解決してくれるか（How & Why）」です。

AIの進化により、コードを書くこと自体の価値がコモディティ化した今、綺麗なコードや整ったデザインが並んでいるだけのポートフォリオは、何のアピールにもなりません。それは、建築家が「私はレンガを積めます」とアピールしているようなものです。

勝てるポートフォリオとは、作品集（Gallery）ではなく、顧客への提案書（Proposal）でなければなりません。本稿では、アクトハウスが提唱する「Marketing/Strategy」の観点から、見る側の心を動かし、高単価な契約を勝ち取るためのポートフォリオ構築論を解説します。

自己満足な「技術の羅列」は、即座にブラウザを閉じられる

エンジニア学習の初期段階では、新しい技術を覚えることが楽しく、それを披露したくなる気持ちは分かります。しかし、ビジネスの現場において、技術はあくまで手段に過ぎません。

多くのスクール卒業生が作成するポートフォリオは、まるで「技術のカタログ」です。どの言語が書けるか、どのフレームワークを使ったかが延々と記されています。しかし、クライアントの視点は冷ややかです。「で、その技術で私の売上を上げてくれるの？」「業務効率を改善してくれるの？」という問いに答えていないからです。

特に、英語でのプログラミング学習を売りにする短期スクールや、カリキュラムをなぞるだけの自習型スクール出身者のポートフォリオは、この傾向が顕著です。彼らは「学習の成果」を見せようとしますが、プロの世界で求められるのは「実務への貢献」です。この視点のズレが、書類選考での不採用や、低単価案件での疲弊に直結します。

必要なのは、技術自慢ではなく「私はあなたのビジネスを理解しています」というメッセージです。

ポートフォリオの構造を「課題解決型」にリフォームせよ

では、具体的にどうすればよいのか。まずは、ポートフォリオの各プロジェクトの構成を根本から変える必要があります。

「作品名」「使用言語」「URL」だけの構成は今すぐ捨ててください。代わりに、以下のフレームワークを導入しましょう。

Context（背景）：

なぜそのプロダクトを作ったのか。どのような仮想（または実在）クライアントを想定したのか。
Problem（課題）：

そのクライアントはどのようなビジネス上の悩みを抱えていたのか（例：予約管理がアナログで機会損失が発生していた）。
Solution（解決策）：

その課題を解決するために、なぜその技術選定をしたのか。デザイン（Art&Science）でどうアプローチしたのか。
Result（結果）：

実装の結果、どのような定量的・定性的な効果が見込めるのか。

この構成にするだけで、あなたのポートフォリオは「作品集」から「ケーススタディ」へと進化します。読み手は、あなたと一緒に働いた時のシミュレーションが可能になり、「この人に任せれば、ウチの課題も解決してくれそうだ」という期待感を抱きます。

AI時代において、単なるコーディングはAIが担います。人間であるあなたに求められるのは、この「課題（Problem）」と「解決策（Solution）」を繋ぐ論理的思考力（Logic Prompt）です。

AIを使い倒し、「思考の深さ」をアピールポイントにする

「AIを使って作った作品をポートフォリオに載せていいのか？」という質問をよく受けますが、答えは「イエス」であり、むしろ必須です。ただし、見せ方が重要です。

AIにコードを書かせたこと自体を隠す必要はありません。重要なのは、「なぜAIにその指示を出したのか」というプロンプトの設計意図（Logic Prompt）と、出力されたものをどうビジネス要件に合わせて修正・統合したかというプロセスです。

例えば、「ChatGPTを使用して基本的なCRUD機能を30分で実装し、余った時間をUX向上のための非同期処理のロジック設計と、データベースのパフォーマンスチューニングに充てました」という記述があれば、それは「AIを活用して生産性を最大化できる人材」という強力なアピールになります。

逆に、AIを使わずに全て手書きしたことを誇っても、「生産性の低い人」と見なされるリスクすらあります。アクトハウスでは、AIを「知的パートナー」として扱い、その対話を通じて導き出した最適解こそが、真の成果物であると定義しています。

[ >> アクトハウスにLINEで質問 ]

さて、構成やAI活用といったテクニック論も重要ですが、最も強力な説得力を持つのは「中身」そのものです。後半では、架空のプロジェクトでは決して埋められない「実案件」の圧倒的な強さと、それを半年間で手に入れる方法について論じます。

架空の「カフェサイト」では、1円も稼げない現実

ポートフォリオの説得力を決定づけるのは、そこに掲載されているプロジェクトが「遊び（Fake）」か「実戦（Real）」か、という点です。

多くのスクール課題で見られる「架空のカフェのサイト」や「Airbnbのクローン」には、決定的な要素が欠けています。それは「他者からの制約」と「責任」です。架空のプロジェクトでは、仕様は自分で決められ、納期は調整可能で、気に入らないデザインは変更できます。しかし、ビジネスの現場はそうではありません。

「予算はこれだけだが、機能は譲れない」「急遽、決済システムを変更してほしい」「既存の古いデータベースと連携させなければならない」。こうした理不尽とも言える制約の中で、いかに最適解（Solution）を導き出したか。その泥臭いプロセスこそが、クライアントが最も評価したいポイントです。

アクトハウスの「稼ぐ100日の実務」では、受講生が実際の企業や店舗から案件を受注し、納品まで行います。そこには、予測不能なトラブルや、コミュニケーションの齟齬が必ず発生します。しかし、それを乗り越えて「納品完了」まで漕ぎ着けたという事実は、架空のプロジェクトを100個並べるよりも遥かに重い「信頼の証」となります。あなたのポートフォリオには、この「血の通った実績」が必要です。

コードの向こう側にある「数字」を語れ

「提案書」としてのポートフォリオにおいて、技術スタック以上に重要なのが「マーケティング視点（Marketing/Strategy）」です。

クライアントは、ReactやLaravelといった技術名にお金を払うのではありません。それによって得られる「ビジネス上の利益」にお金を払います。したがって、あなたのポートフォリオには、コードを書いた結果としてどのような数字が動いたかが記されていなければなりません。

「サイトの表示速度を改善しました」ではなく、「表示速度を1.2秒短縮し、直帰率を15%改善しました」。

「予約フォームを作りました」ではなく、「入力項目を最適化し、問い合わせ件数を前月比120%に引き上げました」。

このように、エンジニアリングをビジネス指標（KPI）に接続して語ることができる人材は、市場において極めて希少です。英語でプログラミングを学ぶことや、ツールの使い方を覚えることに終始する環境では、この視座は養われません。アクトハウスがビジネスとテックを融合させて教える理由は、まさにこの「数字で語れるエンジニア」を育成するためです。