職歴を並べるだけでは伝わらなかった。クラウドワークスのポートフォリオ15件にサムネイルを付けた理由
クラウドワークスに登録し、プロフィールとポートフォリオを整えました。思っていた以上に時間がかかりました。
職務経歴を入力すれば、ひとまず形になる。最初はそう考えていました。ところが実際には、「何を書くか」より「依頼者にどう見えるか」で何度も立ち止まりました。
私はPM／POとして進める仕事も、Webアプリを実装・改修する仕事も経験しています。その幅をそのまま並べると、何を頼める人なのかがぼやける。15件のポートフォリオを登録した後にも、一覧で内容を把握しづらいと感じました。
そこで、15件すべてに文字入りサムネイルを用意しました。
この記事は、受注につながった成功談ではありません。2026年9月8日時点の、プロフィール作成と見せ方を整えた記録です。これによって相談や受注が増えたかは、まだ検証できていません。
不具合修正だけに絞ると、伝わらない経験もあった
最初の自己紹介は、「既存Webアプリの不具合1件の調査・小規模修正」にかなり絞っていました。小さく切り出し、対応範囲を明確にするためです。
ただ、その文章だけでは、私の経験の一部しか伝わりません。
実務には、React／Next.js／TypeScriptによる画面の実装・改修、Java／Spring BootとPostgreSQLを含むAPI・DBの調査、AWS／Terraformの設定や運用改善があります。さらに、新規事業のMVP／PoCや顧客検証、PM・PO・PMO、スクラム、アーキテクチャの経験もあります。
そこで、「小さな不具合修正だけをする人」に見える紹介から、Web開発、クラウド、新規事業、プロジェクト推進を相談できる紹介へ広げました。
ここで気を付けたのは、技術名を増やすだけにしないことです。
Web開発なら、画面からAPI・DBまで、どこを担当したのか。
AWSなら、構築、リリース、監視、運用改善のどこに関わったのか。
PM／POなら、要件、優先順位、検証、受入条件の何を整理したのか。
「相談できる範囲」と「今回引き受ける範囲」は別です。経験を広く伝えても、実際の案件では対象、納品物、日程、確認条件を先に合わせる方針を残しました。
職種とスキルは、数よりも根拠をそろえる
プロフィール、職種、スキル、ポートフォリオは別々の欄ですが、読む側には一人の情報として見えます。PMだけが目立って実装経験が見えなくなったり、技術名は多いのに担当範囲が分からなくなったりしないよう、伝える順番を見直しました。
スキルの経験年数も、AIが資料から推測した数字をそのまま使うわけにはいきません。初期の作業では、技術ごとの正確な年数を確定できず、登録を止めた記録が残っています。
この記事のために公開画面を再確認すると、職種はITエンジニア配下に8種類、スキルは32件掲載されていました。過去の「未登録」というメモだけで書くと、今の状態とは食い違います。
ただし、画面に年数が載っていることと、その根拠を検証できたことも別です。この記事では年数を実績の裏付けとして転載しません。
表示名も迷った点でした。発信名を使う案と比較し、クラウドワークスでは依頼者からの信頼を重視して本名表示を選びました。信頼性が実際に上がったと測れたわけではなく、私自身の判断です。本名表示を一律に勧める意図はありません。
職歴を「案件単位」に分け、15件を登録した
職歴をそのまま貼るのではなく、案件ごとに役割、期間、使った技術、担当範囲を整理しました。原稿づくりはCodexに支援してもらい、内容を確認して、私が15件を登録しました。
扱った領域は、Webサービス開発、MVP／PoC、生成AIサービス、教育領域のSaaS、開発プロセスの標準化、スクラム、Webアーキテクチャ、AWS移行、品質改善、SSO、外部API、データ統合、Webシステム新規開発、WordPress基盤などです。
現在の案件は「PO補佐／開発リーダー」としました。肩書きだけではなく、画面・API・DB・インフラの改修、本番リリース、運用・保守、継続改善までの担当が分かるように整理しています。
その際、勤務先や顧客の名前、社内プロジェクト名、内部製品名は出さず、一般化した案件名にしました。顧客画面、非公開コード、設計書、社内URL、職務経歴書PDFもこの記事には掲載していません。
名前を伏せれば何でも公開できる、という意味ではありません。事例公開の許可と範囲は別に確認する必要があります。ここで紹介するのは、私自身のプロフィールの整理方法と、その説明用に作った画像です。15件をクラウドワークスで受注した実績として数えているわけでもありません。
一覧に戻って、文字だけでは見分けづらいと感じた
個別の入力欄を埋めているときには、説明はできたと思っていました。ところが一覧へ戻ると、似た文字情報が並び、案件ごとの違いをつかみにくいと感じました。
これは私が見たときの感想です。依頼者に比較テストをしてもらった結果ではありません。画像追加前のスクリーンショットも残せていないため、厳密な前後比較はできません。
それでも、「一件ずつ詳しく読んでもらえる」ことを前提にしない見せ方は必要だと考えました。画像だけでも、次の3点の手掛かりを置くことにしました。
何の案件か。
どの技術・領域か。
どこからどこまで担当したか。
目標は、3秒程度で概要がつかめること。これはデザイン上の目安で、読者の理解時間を実測した数字ではありません。
私の公開一覧の一部。2026年9月8日20:15 JSTに撮影し、氏名、アカウント情報、操作メニューを除いて切り抜いています。長い見出しは省略されるため、画像側にも案件を見分ける情報を置きました。
最初の1枚を基準に、残り14枚へ展開した
基準にしたのは「新規事業Webサービス開発」です。
上から、大見出し、技術を示すサブコピー、中央の3工程、補足という構成です。実際の顧客画面ではなく、説明用の抽象的なイラストです。
大見出し：新規事業Webサービス開発
サブコピー：React / Next.js × AWS
3工程：開発 → 本番リリース → 運用改善
補足：フロント・API・インフラを横断して対応
15枚の共通ルールは、16:9・1600×900px、白とブルー、短い言葉、大きなタイトル、中央の3工程です。重要な文字は中央80%以内に置く方針とし、会社名、顧客名、内部製品名、公式企業ロゴ、実際の顧客画面を使わない条件を付けました。
01用の完成プロンプトを、公開時の表記に合わせて整えた再利用用プロンプトは次のものです。
クラウドワークスのポートフォリオ用サムネイルを作成してください。大見出しは「新規事業Webサービス開発」、サブコピーは「React / Next.js × AWS」、中央は「開発 → 本番リリース → 運用改善」、補足は「フロント・API・インフラを横断して対応」です。左に抽象的なWeb画面とコード、中央にサーバーとロケット、右にクラウドと監視グラフを配置してください。クラウドワークスのポートフォリオ一覧で小さく表示されても何の実績なのか一目で理解できること。メインタイトルを最優先で大きく表示し、不要な説明文は入れず、文字数を最小限にしてください。16:9、1600×900想定、白背景＋ブルーを基調としたクリーンなSaaS／クラウド／Web開発デザイン。15枚を並べた時に同じ人物のポートフォリオシリーズだと分かる統一レイアウトにしてください。会社名・顧客名・内部製品名を使用せず、公式企業ロゴも使用しないでください。重要文字は画像の中央80%以内に配置し、クラウドワークスの縮小表示でも読める巨大文字にしてください。日本語の文字崩れを避け、文章ではなく短い単語中心にしてください。ここにある「一目で理解できる」はAIへの要望で、達成を保証する説明ではありません。同じプロンプトでも同じ画像になるとは限らないため、生成後の検査が必要です。
保存済み15枚を各320×180pxに縮小して並べた確認画像。クラウドワークスの画面ではありません。細部の配置は同一ではありませんが、白・ブルー、大見出し、3工程の型をそろえています。
大きい画像で読めても、一覧では小さくなる
生成後は、15枚の日本語、実務内容との一致、会社名や顧客名の混入、ロゴや顧客画面の有無を確認しました。サイズを1600×900pxにそろえ、320×180pxでも大見出しと3工程を見直しました。
画像ファイル自体は320×180pxです。note上の表示幅や端末によって、見える大きさは変わります。
今回の確認では大見出しと3工程は読めました。ただ、01の一番下の補足など、小さい文字まで同じ読みやすさではありません。実際の公開一覧ではさらに小さく表示されるため、細かい説明は本文へ任せる必要があります。
また、03の画像は「生成AI Webサービス開発」という案件の見出しですが、私の役割はPOです。画像の工程を、そのまま全工程を一人で実装した証拠にしないことも大切です。タイトル、役割、詳細を一緒に確認します。
表示が変わるスマートフォン、アプリ、別の画面幅では、同じ読みやすさになるか未確認です。完成した画像だけでなく、掲載先でも確認する工程が残ります。
AIで下書きを進めても、判断までは省けなかった
Codexに支援してもらったのは、職務経歴の分解、一般化した文章の下書き、サムネイル設計、画像生成、ファイル名とサイズの統一、縮小確認、記録の保存です。
一方で、どの経験を載せるか、本名を使うか、PM／POと実装のどちらをどう強調するかは、私が判断しました。顧客や勤務先を特定できないか、実務経験と自作検証を混同していないか、依頼者に誤解を与えないかも、人間が責任を持って確認する部分です。
想定以上に時間がかかったのは、文章入力に加えて、次の判断と確認があったためです。
職歴を案件に分け、役割・期間・技術・成果を照合する。
公開する情報と伏せる情報を分ける。
自己紹介を狭めすぎず、対応条件は曖昧にしない。
15件を個別に登録し、一覧の見え方を確認する。
共通デザインを決め、15枚の文字・サイズ・縮小表示を検査する。
文章入力より、確認と見せ方の判断に時間を使った感覚があります。ただし、正確な総作業時間、AIとのやり取り回数、私の修正回数は記録できていません。AIを使わなかった場合との時間比較もしていないため、何分短縮したとは書けません。
使用したのはCodexと組み込み画像生成です。当時の会話モデルと画像生成モデルの正確な名称は未取得です。サムネイルにあるGPT-4oなどの技術名は、そこで説明している実務経験のもので、今回の画像を作ったモデル名ではありません。
まずは、自分の経歴1件を一覧目線で見直す
同じようにプロフィールを整える方は、最初から15枚作る必要はありません。私なら、まず伝えたい経歴1件で次を確認します。
公開できる範囲を確認し、案件の種類を短い言葉で書く。
技術名と、自分が担当した範囲を分けて書く。
「案件名／技術・領域／担当した3工程」の形に整理する。3工程が事実に合わなければ、無理に埋めない。
画像を使うなら、タイトルを大きくし、細かい説明は本文へ移す。
縮小画像と実際の一覧を見て、文字切れや読みづらさを確認する。
最後に、役割の誇張、秘密情報、未確認の年数・成果がないか読み返す。
まずは紙や手元のメモで1件をこの形にするだけでも構いません。有料の画像生成を使うことや、画像を公開することは、この見直しの前提ではありません。
読みにくければ、文字を足すより、補足を外してタイトルと担当範囲を残す。内容が違って見えるなら、画像の見栄えではなく、実際の役割に合わせて言葉を直す。この順番で切り分けます。
入力欄を埋めることと、依頼を判断できる状態は違う
今回つくれたのは、プロフィールと15件の説明画像です。受注を生む仕組みが完成したわけではありません。
次は、閲覧、気になる登録、相談、応募への反応を、取得日時と対象期間を付けて記録します。画像だけの効果とは決めつけず、案件との適合や提案内容も含めて見直す予定です。
プロフィールは、私が書きたい職歴を並べる場所ではなく、依頼者が「何を頼めそうか」を判断するための情報。その視点に変わったことが、今回の一番の学びでした。
皆さんは、職歴をプロフィールへまとめるとき、どの情報を削るかで迷いますか。差し支えない範囲で、困った点を教えていただけるとうれしいです。
私の開発・検証の進め方や、小さなWeb開発・修正の相談範囲は、自己紹介と開発・修正のご相談にまとめています。技術構成、変更範囲、日程を確認したうえで、対応できる作業を相談する方針です。
