Staffプロダクトデザイナーとして働く方法

• デザイン業界に蔓延する肩書きインフレーションの中で、Senior・Staff・Principalという役職の実際の意味と、最も誤解されやすいStaffレベルを紹介
• SeniorとStaffの本当の違いは年次ではなく、影響力の範囲と種類にあり、Seniorは「どうすればうまく作れるか」を、Staffは「これは作るべきなのか、作るならなぜか」を問う
• Staffは単一の機能・チームを超えて、製品全体がひとつとして理解されるように整合と意思決定を導き、デザイナーではない人たちにデザインを教える役割を担う
• Staffになる人は昇進を待たず、昇進前からそのように振る舞い、より多くこなすのではなく倍率（multiplier）で考え行動する方向へ切り替える
• AIによって何でも作れる時代だからこそ、より質の高いアイデアを見極めて説得する判断力中心の能力が重要になる

---

肩書きインフレーションと記事の背景

• デザイン職の肩書きインフレーションが蔓延しており、実際の力量以上の役職や主張を持つ人が多い
  • 企業が人材を採用・惹きつけ・維持する方法を分かっていないときに起こる
  • その結果、デザイナーは自分の力量以上の仕事に巻き込まれ、レベリングが希薄化し、組織内でデザインが十分に活用されなくなる
• インフレーションが最も起きやすいのはSenior、Staff、Principalの役職帯
  • 同じ肩書きでも会社ごとに意味が異なる
• とりわけ採用される側にも採用する側にも誤解されやすいStaffレベルを深く扱うため、3人のデザイナーと協業
  • Milan Jovanović — VEEDのProduct Designer
  • Mo Elmelegy — 現在Bolt所属のPrincipalレベルのデザイナー、17年以上の経験
  • Rachel Wu — MewsのLead Product Designer

Q1: Staffプロダクトデザイナーとは何か

• Milanの視点

  • Staffとは、整合と意思決定を強い推進力で前に進める人であり、その過程で非デザイナーにデザインを教え、一緒に働いていて楽しいパートナーでもある
  • 仕事は「どう実行するか」から「何を実行すべきで、なぜなのか」へ進化する
  • レイアウト・ボタン・シャドウと同じくらい会話や会議を設計し、ひとつの領域の体験をリリースするだけでなく、製品全体の戦略を形作る
  • ほとんどの時間は**カウンセラー（counsellor）**のように感じられる — 人々が不確実性に過敏になりすぎず、失敗を過度に恐れないよう助ける
    • 対象は自チームだけでなく、CPO、PM、ミドルレベルのエンジニアまで、プロダクト組織のかなりの部分に及ぶ
  • AIで何でも作れるからといって、思いついたものをすべて作るべきではなく、Staffはより質の高いアイデアを見極めて説得する声であるべき

• Moの視点 — 役職の区分

  • デザイン職の肩書きは混乱しており、会社ごとに使われ方が違い、期待値も不明瞭
  • レベル間の本当の違いは年次ではなく、影響力の範囲と種類
  • Senior
    • 範囲: ひとつの機能、フロー、製品領域
    • 主な影響: 強い成果物をリリースし、チーム内の品質を高める
  • Principal
    • 範囲: ドメインまたは会社レベルで、長期的な方向性やプロダクトシステムに影響する
    • 主な影響: 複数のチーム・製品領域にまたがり、製品全体の構造と整合を形作る
  • 全体的な成長経路は、問題を所有する → 問題をつなぐ → 製品の進化の仕方を形作るへと移る

Q2: Staffの役割へどう成長するか

• Milanの助言

  • まずこの道を本当に望むか決めること — 指示されるのが好きならStaffは向いておらず、Seniorも十分に尊重されるレベル
  • 最も早いが最も大変な道は、20人未満のスタートアップに唯一のデザイナーとして加わること
    • 試練の連続であり、燃え尽きの可能性もあるが、誰も指示してくれないときに何をすべきかを素早く学べる
  • 会社にすでにその役割があるなら、小さく始めて推進力を積み上げること
    • デザインプロセスを公開し、Slackで広く共有し、開発者を非同期で会話に参加させ、思考過程を声に出して説明する
    • 会社のあちこちにある**ペインポイント（pain point）**を見つけ、助けが必要な場所や空白を探る
    • 会社の目標を把握し、自分の領域を超えるアイデアを出し、Cursorで素早いモックアップやバイブコーディングを行いつつ、常にビジネス成果に結びつける
    • PMやGrowthチームが使う言語を学び、その言葉で話す
    • 他チームと通話を設定して何が最も重要かを尋ね、その後は口を閉じて傾聴する
    • 自分がいつ厄介になっているかを理解し、調整する — 間違った場での善意はとても厄介になりうる
    • 今すぐ不平をやめること — 不平はコントロールを手放したという認めであり、Satya Nadellaの言葉どおり、与えられた資源で成功を生み出すのが仕事
    • 同僚デザイナーを引き立て、デザイン機能のチャンピオンとして他のデザイナーの仕事を自分の仕事につなげる
    • セラピーを受ける

• Moが観察した成長パターン

  • Staff/Principalになる人は肩書きを待たず、昇進前からそのように振る舞う
  • 特定ドメインのgo-toな存在になる
    • Growthのメカニズム、オンボーディング、マーケットプレイスの力学、デザインシステム、モバイルアーキテクチャなど
    • 正式な割り当てによるのではなく、ひとつの問題空間を十分深く考え抜くことで、その領域の疑問が生じたとき人々が自然とその人を巻き込むようになる
  • 誰にも頼まれていないイニシアチブを作る
    • ロードマップが仕事を定義してくれるのを待たず、3つのチームが同じ問題を別々に解いていることや、断片化したオンボーディングフローのような構造的問題を早期に捉える
    • 現状をマッピングし、より明確な構造を提案し、適切な人々を集める
  • 仕事を実現させるための仕事まで担う
    • 解決策を出すだけでなく、曖昧な問題を明確にしたり、チームをひとつの方向に整合させたり、プロトタイプでアイデアを具体化したりする
    • 単に仕事をデザインするのではなく、その仕事が実際に起こるようにすること

Q3: Senior・Staff・Principalを日常ではどう見分けるか

• Milanの区分

  • Seniorは定義された空間の中で実行を磨く段階であり、Staffはその空間自体を問い直し、拡張し始める段階
  • 核心は同じことをより上手くやることではなく、根本的に異なる種類の仕事をすること
  • 画面の作業と同じくらい会話や整合に時間を使い、それは妥協ではなく仕事そのもの

• Moの区分

  • Seniorは通常、単一チームの中で製品の意味ある一部分を所有し、雑然とした製品課題を明快で洗練された解決策としてリリースする
  • Staffへ移ると、範囲は単一の機能・チームを超えて広がり、問う内容も変わる
    • 異なるチームが同じ問題を別々に解いていないか
    • これらの機能の背後にシステムはあるのか、それともバラバラに散らばっているのか
    • 製品が成長する中で、どこで断片化が起きているのか
  • 最も強いStaffデザイナーは、他チームが再利用できるパターンを定義し、関連課題を扱うチーム同士をつなぎ、漂流している領域に明確さを与える
  • Principalはより広いレベルでシニアリーダーシップと密に協働し、焦点は特定のプロジェクトから製品が時間とともに向かう方向へ移る

Q4: Staffレベルで働くとは実際にどういうことか

• Milanが描く日常

  • レイアウトと同じくらい会話や会議を設計し、CPO・PM・エンジニアと同じ部屋で、人々が失敗を過度に恐れないよう助ける
  • 実質的な転換: Seniorは「どうすればうまく作れるか」、Staffは「これは作るべきなのか、作るならなぜか」
  • これはより難しい問いであり、クラフトではなく判断力への自信を求める

• Moが示す具体的パターン

  • 他人が活用できるシステムを作る — 単一機能を解く代わりに、複数チームが使えるパターン（拡張可能なオンボーディング構造、複数チームが採用するインタラクションパターンなど）を形作り、影響は複利的に積み上がる
  • 人々を仕事の周りに結集させる — このレベルでは権限ではなく、明確さと推進力で動かし、複雑な製品課題を明快に説明してチームを早い段階から思考に参加させる
  • 意図性を与える — なぜその決定をしたのか、どんなトレードオフがあるのか、その仕事が製品全体とどうつながるのかについて意図的であるほど信頼が蓄積し、その信頼も複利的に積み上がる

• Personioの事例

  • Personioでモバイルアーキテクチャを担当し、ネイティブiOS・Androidアプリをゼロから構築
  • このレベルでは**「仕事の前の仕事」**が業務の大半 — プロダクト・エンジニアリング・ブランド・プラットフォームの各チームを、モバイルに関する共有ビジョンへ整合させる
  • ブランドをネイティブでどう翻訳するか、エンジニアとどうテーマを構築するか、時間追跡のようなワークフローがモバイルとデスクトップでどう動くかについてのパートナーになる
  • 位置ベースの時間追跡・ジオフェンシングコンプライアンスから、モーションやインタラクションのプロトタイピングまで自ら作ることもあった
  • リリース・改修の成果
    • アプリ採用の月間アクティブユーザーが約40Kから200Kへ成長
    • モバイル関連の取引損失が8%以上から0.2%へ減少
    • モバイル時間追跡の採用が5倍に増加

Q5: Seniorデザイナーが転換のために今週すぐ始めるべきこと

• Rachelの助言

  • SeniorからStaff/Leadへの移行は、より多くこなすことではなく、倍率（multiplier）で考え行動する方法を学ぶこと
  • Seniorの影響はたいてい局所的 — ひとつのサーフェスを担い、その中で問題を解く
  • Staff/Leadレベルの問いは「何を作ったか」ではなく、「あなたの存在によって、同僚・製品ドメイン・ビジネス全体で何が可能になったか」
  • システムとして考える — 2つのチームが同じ問題を反対側から解いており、協力すれば単独では作れない結果が生まれることに気づく人になること。一貫性は競争優位につながる
  • 時間・野心との関係を切り替える — 組織全体の大きな野心を抱きつつ、「今日、私たちが一緒に取れる最もレバレッジの高い一手は何か」を問う
    • 次のステップのない野心は浪費されたエネルギーであり、そのエネルギーを転換するのが仕事
  • 同僚に影響を与える — プロダクトやビジネス、そして次第にAIエージェントにまで影響する
    • 動かす必要のある人にとって何が最も重要かに心から好奇心を持ち、信頼を築き、互いに挑み合い挑まれ合えるようにする
  • すべてには**節度（restraint）**が求められ、ひとりで解く人ではなく、他者がよりうまく解ける条件を整える人になること
  • 今日できる戦術的な行動 — 現在の自分の影響が終わる地点をマッピングする
    • どこで自分がいないまま意思決定が行われているか
    • どこで自分の仕事が翻訳の過程で影響を失っているか
    • まだ本当の対話をしていないが、対話すべき相手は誰か
    • ひとつ選んで、そこから始める

結論: 肩書きより仕事

• Seniorは優れた機能をリリースし、Staffは製品全体が意味を持つように助ける
• 会社ごとに肩書きは異なるため、肩書きよりも**求められる成果（outcomes）**に焦点を当てるべき
• 多くのデザインチームは静かに肩書きを廃止しつつある — 対外的には全員を「Designer」に統一しつつ、内部のレベリングは維持する
  • よりフラットな構造により意思決定が速くなり、社内政治に割くエネルギーも減る
  • AIが役割の境界を急速に曖昧にしており、3年目の人が20年目の人よりAIに詳しいこともあるため、範囲と影響が肩書きより重要になっている
  • 仕事とデザインクラフトそのものに集中するデザイナー採用へと焦点が移る
• 仕事を見るときは、肩書きではなく仕事に注目すること