ポートフォリオのプレゼンでは、面接官があなたの考え方、担当したこと、作品から実際にわかることを理解できるようにします。希望する職種に合う案件をいくつか選び、完成物に至る判断を説明しましょう。見栄えのよい画像を並べるだけでは、相手の推測に頼る部分が多くなります。

採用面接では、まず指定された時間と内容に従います。自己紹介や職務との適合性を含む全体の準備は、面接プレゼン資料の作り方で扱っています。この記事ではポートフォリオに絞り、3つの案件を選んで、つながりのある発表にする方法を説明します。

例にするのは、業務用ソフトウェアの開発チームに応募する架空のプロダクトデザイナーです。3つの案件を通じて、判断、個人の貢献、まだリリースされていない仕事をどう説明するかを示します。

業務フロー、代替案の判断、引き継ぎという3つの案件をつないだポートフォリオ。

それぞれ違う強みを示せる案件を選ぶ

募集職種で求められる能力から考え、具体的に話せる案件を選びます。似た完成画面を3つ並べるより、完成した機能、難しいトレードオフ、限界まで説明できる小さな改善を1つずつ示すほうが、伝わることがあります。

例の職種では、わかりやすい業務フロー、実務での協働、既存製品を改善する力が求められています。そこで次の案件を選びます。

案件示せること見せたい根拠
シフト交代の申請わかりにくい操作を、判断しやすい流れに整理する力。元のフロー、検討した別案、最終プロトタイプ。
経費申請フォーム既存システムの制約下で、トレードオフを調整する力。制約、変更案、ある案を採用しなかった理由。
権限機能の引き継ぎ実装・保守を担うチームが使える形で設計を渡す力。注記付きの状態図と引き継ぎ資料の例。

顧客名が有名という理由だけで選ばないようにします。自分の貢献を説明できない、十分な資料を共有できない場合は、小さな案件のほうが適しています。また、1件を深掘りするよう指定されている面接に、無理に3件を詰め込む必要はありません。

最も関連性の高い案件を中心にする

応募職種に最も合う案件には、判断の背景が伝わるだけの時間を取ります。他の案件で幅を補います。12分の発表枠を例にすると、導入1分、シフト交代5分、経費フォーム3分、引き継ぎ2分、締め1分です。これは計画例です。実際の面接形式に合わせ、質疑を含める指定があれば、その時間も確保します。

導入は具体的にします。「これらの案件では、業務フローの整理、既存製品の中でのトレードオフ、実装に向けた引き継ぎへの取り組みを紹介します」。すべてに精通していると主張しなくても、異なる3件を聞く理由が伝わります。

各案件では、変える必要があったこと、自分の担当、重要な判断、作ったもの、その後の状況を押さえます。詳しさは案件ごとに変えて構いません。工程を踏んだことを証明するためだけに、すべての調査メモや試作を見せる必要はありません。

具体例:シフト交代の申請

問題を目に見える形にする

架空の業務アプリでは、従業員は交代を頼む相手を選んだ後で、その人が対象シフトに入れるかを知ります。そのため、申請の後半で処理が進まなくなることがあります。設計課題は、ルールを隠さずに、選択と承認の流れを理解しやすくすることです。

元の流れを「シフトを選ぶ→同僚を選ぶ→申請する→交代条件に関するメッセージが出る」と短く示します。影響は業務フロー上の問題として説明します。記録による裏付けがなければ、離脱率を付け加えません。

自分の役割とチームの仕事を分ける

この例でデザイナーが担当したのは、操作の整理、代替案の作成、プロトタイプと引き継ぎ資料の準備です。勤務ルールはプロダクトマネージャーが運用担当者と定め、申請前にどの適格性チェックを実行できるかは開発側が判断します。

この区分を口頭でも伝えます。「申請フローを設計しました」は具体的です。「勤務管理を変革しました」では、誰が何をしたかが見えなくなり、貢献を評価しにくくなります。

試作をすべて見せるより、判断を説明する

デザイナーは2案を検討します。対象外の同僚を選択一覧から隠す案と、理由を短く示したうえで選択できなくする案です。

プロトタイプでは後者を採用します。この架空の事例では、従業員は同じチームのメンバーを知っているため、理由なく名前が消えると一覧の不具合に見える可能性があります。そこで状態と理由を表示します。これは議論するための設計理由であり、すべての勤務管理製品で同じ方法が適切だという証拠ではありません。

2つの案、制約、選んだ方法を並べます。面接官は、プライバシー、適格性の変化、ルールを確認できない場合の対応を質問できます。ほとんど同じワイヤーフレームを20枚紹介するより、実りのある話になります。

成果物と、まだわからないことを説明する

案件では、同僚を選択した状態、理由付きで選択できない状態、承認待ち、申請が却下されたときの戻り先を示します。各状態がどうつながるかを説明します。

この例の仕事は、プロトタイプと引き継ぎで終わっています。何を、なぜ設計したかは説明できますが、申請失敗の減少、従業員満足度の向上、リリースの成功は主張できません。後に公開された場合は、実際の結果と、その根拠を追加します。

個人の設計とチームの判断を分け、4つの状態を示すプロトタイプと未測定の成果を区別した図。
自分の担当とチームの判断を分け、プロトタイプを測定済みの成果と混同しないようにします。

残りの案件で別の側面を伝える

2件目では、1件目で伝わらなかった能力を見せます。経費フォームの例では、デザイナーが必須項目の削除を提案します。しかし経理担当者は、現在の承認手順にその項目が必要だと説明します。この意見の違いを隠さず、説明を項目の近くへ移し、入力形式を明確にするという、より限定した変更を示します。

最良のフォームを実現したことが要点ではありません。制約を説明し、デザイン上の好みと運用上の要件を区別し、可能な範囲で役立つ変更を行えることが伝われば十分です。採用しなかった案は、選んだ案の理由がわかる程度に短く示します。

3件目は引き継ぎです。架空の権限機能では、閲覧者、編集者、所有者が何をできるかは、画面だけでは伝わりません。小さな役割・状態図、操作できない状態の例、アクセス権が変わったときのメッセージを用意します。

成果物が実装チームに何を伝えるかを説明します。リリース後の結果を確認していないなら、設計どおりに実装された証拠として扱わないようにします。

各スライドに、示す根拠を1つ決める

9枚のポートフォリオなら、次の構成が使えます。

  1. 紹介する強み:選んだ案件で示す3つの能力。
  2. シフト交代の問題と役割:元の流れ、利用者の困りごと、自分の責任。
  3. シフト交代での判断:代替案、制約、選択の理由。
  4. シフト交代の成果物:主要な状態、納品した資料、現在の進捗。
  5. 経費フォームの制約:求められた改善と、変えられなかった要件。
  6. 経費フォームへの対応:限定した設計判断と、そこから言えること・言えないこと。
  7. 権限機能の引き継ぎ:状態図と、それが答える実装上の質問。
  8. 案件に共通する姿勢:不確実性、協働、説明への取り組み方。
  9. 対話:さらに詳しく話せる案件や判断。

説明している判断が見えるよう、読み取れる大きさの部分画像や図を使います。デスクトップ画面全体をサムネイルほどに縮めても、細部は伝わりません。切り抜くことで画面やフローを誤解させる場合は、周辺の文脈も示します。

機密案件と未完成の仕事を正確に扱う

採用向け資料を作る前に、共有できる範囲を確認します。画面に顧客データ、非公開の戦略、特定可能な内部情報があれば、ロゴを隠すだけでは不十分です。許可が限られる場合は、適切な抽象度で課題と役割を説明するか、別の案件を選びます。

再構成した資料を使うなら、その旨と何を表すかを明記します。構想、プロトタイプ、公開済みの仕事、測定済みの成果を区別します。未完成でも、考え抜いた判断は伝えられます。実際には得られていない成果を添えると、誤解を招きます。

質疑用に、別案、成果物の拡大図、結果の根拠などを少量の付録にまとめます。本編と分けることで、最初の説明を絞れます。

共有可能な案件メモから資料を作る

案件を選んだら、背景、自分の役割、判断、成果物、進捗、共有できる結果を短くまとめます。Presentiでは、案件メモを編集可能なスライドの下書きにすることができます。公開可能な資料を渡し、指標、調査参加者、顧客コメント、リリース成果を作り足さないよう指示します。

出力された資料は、貢献の主体と強調の仕方を確認します。チームの成果はチームの成果として、期待できるプロトタイプはプロトタイプとして扱います。実際の面接時間で練習し、重要な判断を急いで話すより、余分な説明を付録に移します。

よいポートフォリオは、自分の仕事を深く話し合える資料です。何に貢献し、なぜその判断をし、どこまで共有可能な根拠で支えられているのかが、相手に伝わるようにしましょう。