ポートフォリオの物語とは、誰のどんな問題を捉え、どの選択肢から何を選び、実装後に何を確認したかを証拠でつなぐ説明です。 面接や発表で「Reactを使いました」だけでは、自分の判断も成果も伝わりません。
なぜ必要か
技術一覧は構成を示しますが、課題発見、優先順位、設計判断、検証能力を示しません。採用担当、講師、共同開発者は、完成画面だけでなく、制約の中でどう考えたかを知りたい場面があります。問題・判断・結果の順に整理すると、README、発表、面接で同じ事実を一貫して説明できます。
物語は成果を大きく見せる演出ではなく、確認できる事実と自分の担当範囲を正確に伝える構造です。
登場人物と対象
主役は利用者であり、制作者自身ではありません。制作者、チームメンバー、レビュー・検証に協力した人、説明を読む採用担当なども登場します。対象には利用者の困りごと、候補案、制約、実装、テスト・操作確認、残課題を含めます。
作成の流れ
- 利用者と場面を一つに絞る。
- 観察・聞き取り・自分の経験など、問題の根拠を書く。
- 少なくとも二つの案と評価軸を並べる。
- 採用理由と自分の担当範囲を明示する。
- 実装後の確認方法と結果を、誇張せず記録する。
- 限界と次に検証することを残す。
四つの流れ
- 問題：誰が何に困っていたか
- 判断：どんな案を比較し、なぜ選んだか
- 実装：自分が担当した範囲と難所
- 結果：どう確認し、次に何を改善するか
例
問題: 提出済み課題を探すのに時間がかかっていた。
判断: 検索より先に、状態と更新日で絞る機能を選んだ。
理由: 件数が少なく、利用者の主な探し方が状態だったため。
結果: 操作確認で目的の課題へ到達する手順を比較した。
残課題: 件数増加後は全文検索を検討する。
人数や改善率は実際に測定した場合だけ記載します。測定していなければ「実装した」「確認した」と「改善した」を区別します。たとえば、クリック数が減っても、利用者が迷わなくなったとは限りません。
説明パターンの比較
| 書き方 | 伝わること | 不足しやすいこと |
|---|---|---|
| 技術一覧 | 使用経験 | 選定理由 |
| 機能一覧 | 作った範囲 | 利用者の問題 |
| 苦労話 | 粘り強さ | 再現可能な判断 |
| 問題・判断・結果 | 思考と検証 | 技術詳細へのリンク |
技術一覧や機能一覧も不要ではありません。概要として短く置き、重要な1〜3件を判断の物語として深掘りします。
具体例を深くする
「検索を実装した」ではなく、件数、主な探し方、更新頻度を確認し、状態フィルターと全文検索を比較した、と説明します。件数が少なく状態で探す利用が中心なら、先にフィルターを選ぶ判断ができます。将来件数が増えた時の再評価条件も残せます。
採用しなかった案を書くと、技術を知らなかったのではなく、条件に合わせて選ばなかったことを示せます。
よくある誤解
「最新技術ほど評価される」とは限りません。問題に合うこと、説明できること、運用できることが重要です。「失敗は隠すべき」でもありません。誤った仮説をどう検証し変更したかは判断力を示します。ただし、チーム成果を自分一人の成果として語ってはいけません。
注意とベストプラクティス
- 利用者の発言や数値を創作しない。
- チーム全体と自分の担当を分ける。
- 非公開コード、顧客情報、秘密情報を掲載しない。
- 結果にはテスト、画面、コミット、Issueなどの証拠をリンクする。
- 制約と残課題を隠さず、次の判断条件を書く。
デバッグ・確認方法
READMEとコミット履歴、Issue、テスト結果を照合し、説明と実装が一致するか確認します。第三者に「なぜその案か」「何を確認したか」「自分の担当はどこか」を質問してもらい、答えが証拠へ戻れるか試します。
ケーススタディ：課題提出一覧を探しやすくする
学習管理アプリで、受講生が過去の提出物を探す場面を取り上げます。悪い出発点は「検索機能を作って技術力を示したい」です。これでは制作者の都合が主役です。まず、テスト利用者の操作や自分の利用記録から、「再提出する課題を探す時、未提出・提出済みが混ざり、詳細を順に開いていた」という問題を記録します。
候補は全文検索、状態フィルター、科目別タブの三つです。現時点の件数が少なく、課題名を正確に覚えていない一方、提出状態は分かっているという観察があるなら、状態フィルターを先に選べます。実装では自分が一覧の状態設計、絞り込み処理、空状態、テストを担当し、APIは共同制作者が担当した、と境界を示します。結果は「3人の操作確認で全員が目的の課題へ到達した」のように事実を述べ、比較前の所要時間を測っていないなら「時間を短縮した」とは書きません。
物語を組み立てる判断手順
最初に、成果物全体ではなく一つの利用場面を選びます。次に、問題の根拠を観察、Issue、操作記録のどれで示せるか確認します。根拠が自分の仮定だけなら「想定した課題」と明記します。その後、実際に比較した候補と評価軸を並べ、採用案だけでなく見送った理由を残します。実装範囲はチーム成果と自分の担当に分け、最後に結果を「実装」「動作確認」「利用者への効果」の三段階で分類します。
結果の強さは証拠の強さを超えないようにし、テスト合格から利用者満足まで飛躍させないことが重要です。
失敗条件と観測方法
物語は、利用者より技術名が先に来る、比較していない案を後から比較したように語る、チーム成果と個人担当が混ざる、測定していない改善率を書く、現在は動かない公開URLを成果の証拠にする、という時に信頼を失います。また「苦労したが頑張った」で終わり、判断を変えた観測がない場合は、再現可能な学びが伝わりません。
観測方法は主張ごとに変えます。機能が存在する証拠には画面とコード、仕様を満たす証拠にはテスト、選定経緯にはIssueや設計記録、利用者行動には操作観察を対応させます。README公開前に、各文へ「これは何で確かめられるか」と問い、証拠がない効果表現を削るか今後の検証仮説へ移します。リンクはログイン不要で閲覧できるか、非公開情報を含まないかも確認します。
良い例と悪い例
悪い例は「Reactと高度な検索ライブラリを使い、使いやすさを50%改善した」です。問題の根拠、比較軸、測定方法がなく、数値も検証できません。良い例は「提出状態を把握している利用場面を観察し、全文検索と状態フィルターを比較した。件数が少なく検索語を思い出しにくかったため、状態フィルターを先に実装した。成功・0件・取得失敗をテストし、3人の操作確認では目的の課題へ到達できた。所要時間の改善は未測定」です。
面接では、この短い説明から評価軸や実装難所を深掘りできます。READMEでは根拠となるIssueとテストへリンクし、発表ではフィルター前後の操作を見せます。媒体に合わせて長さは変えても、人数、担当範囲、測定の有無は変えません。
実践演習：一機能を三分で説明する
成果物から重要な一機能を選び、問題30秒、比較と判断60秒、実装60秒、結果と残課題30秒で説明します。各部分に対応するIssue、コミット、画面、テストを一つずつ用意し、証拠へ戻れない主張を削ります。
聞き手から「なぜ別案ではないか」「問題はどう確認したか」「自分の担当はどこか」「結果をどう測ったか」と質問してもらいます。測っていない効果には測っていないと答え、代わりに実装・テストで確認した範囲を示します。
チーム制作なら、共同で決めた判断、自分が提案した判断、自分が実装した範囲を分けます。技術的に高度でも利用者の問題と関係が薄い要素は補足へ回します。
媒体ごとの組み立て
READMEでは、最初に成果物の目的と利用方法を示し、その後に重要な判断を短く載せます。発表では画面操作と判断を同じ順に結び、面接では質問に応じて一つの判断を深掘りします。媒体が変わっても、問題・判断・結果の事実は変えません。
デモが通信や外部サービスへ依存する場合は、動画や画像など安全な代替も用意します。ただし画像で動作全体を証明したことにはせず、リポジトリ、テスト、公開環境の役割を分けます。公開環境へ実在人物の個人情報や本番用認証情報を置かないよう確認します。
説明を更新する契機も決めます。機能、URL、採用技術、検証結果が変わった時にREADMEと発表資料を照合し、古い成果を現在の状態として語らないようにします。
まとめ
ポートフォリオは機能の展示だけでなく、問題の根拠、比較した案、採用理由、実装後の確認を正確につなぐことで判断力を示せます。 実測していない効果は断定せず、残課題と次の検証を含めます。
参考リソース
失敗も説明材料
最初の案が機能しなかった場合、観察して修正した過程を話せます。完成品だけでなく判断の変化が学習を示します。
