プロダクトエンジニア：何を作るかまで決めるエンジニアの道

ある会社は求人の職名そのものを変えた

Linearのエンジニア募集は職名がProduct Engineerだ。シニアやスタッフの区分でも、AIチームの席でも同じ名前を使い、その隣にフルスタックエンジニアの募集が別に並んでいる。名前を変えただけではなく、別の職種として扱っているということだ。Replitも同じ職名で採用している。

違いは範囲にある。プロダクトエンジニアは仕様書から始めない。ユーザーが何に詰まっているかを自分で確かめ、その中からどれを作るか選び、画面を描き、リリースし、二週間後の数字で自分の判断を採点する。PMやデザイナーがいないという意味ではない。同じテーブルで決定に加わるという意味だ。

この席がいま増えているのは、実装にかかる時間が短くなったからだ。エージェントがコードを出す速度が上がると、詰まる場所は前工程へ移る。OpenAIが公開した調査は、AIの導入が人の仕事を狭めるより、扱う範囲を広げる方向に現れると整理している。広告持株会社を作ったデビッド・ジョーンズは、自社の業務の95%を機械に任せているとフィナンシャル・タイムズに語った。一方で慎重な見方もある。スタンフォードSIEPRの政策ブリーフは、AIが雇用に与えた影響を実測データで誇張と切り分けようと提案している。職名が先に動き、統計が後から確認する区間だと見るのが正確だ。

何を作らないかを決める方が難しい

• 課題を選ぶ感覚。 ユーザーへのヒアリングを人任せにしない。難しいのは何を作らないかを決める側で、要望リストから三つ消す理由を説明できる必要がある。
• デザインの仕上げ。 デザイナーを待たずに、空の状態、ローディング、エラー、権限のない画面まで描く。ハッピーパスだけ作って残りを渡すのは、この職種では半分しかやっていない。
• 計測。 イベントスキーマを先に設計してからリリースする。あとから計測を足すと必ず遅れ、遅れれば自分の判断が正しかったか分からないままになる。
• フルスタックとデプロイ。 フロントからデータモデル、マイグレーション、段階的な公開まで。機能を一つ最後まで自分で出せて初めて決定権がついてくる。
• エージェントへの委任と検証。 実装を道具に渡し、空いた時間を判断に使う。返ってきたものを読んで弾く目がなければ、速く間違えるだけになる。
• 短い文章。 一枚の仕様、五行のリリースノート。決めた理由を残さないと、半年後に同じ議論をやり直す。

機能一つを、要件定義からリリースまで

ジュニアの区間では、機能を一つ、課題の定義からリリースまで自分で引っ張る。ここで身につくのはコードではなく、選んだ課題が外れたときの感触だ。シニアになると製品領域を一つ持ち、PMがいても優先順位を一緒に組む。スタッフやリードの区間では、チームが何に一切手を出さないかを決め、その基準を採用基準に移していく。

日本ではこの職名がそのまま制度化されている会社はまだ少ない。実態としては、スタートアップでエンジニアが企画を兼ねる形で存在している。新卒一括採用の配属では職種の枠が先に決まりやすく、大手では企画、デザイン、開発の分業がはっきりしているぶん、この道は見えにくい。だから日本での現実的な課題は職名ではなく証拠のほうだ。職務経歴書に「実装した」だけが並ぶと、どちらの会社からもプロダクトエンジニアとしては読まれない。何を作らないと決め、その判断で数字がどう動いたかを一行でも書けると、読む側の見方が変わる。

面接の準備を一つだけ選ぶなら、自分が作った機能のうちユーザーに結局使われなかったものを一つ取り上げ、なぜ外したのかを5分にまとめておくことを勧める。成功事例は誰でも持ってくる。失敗を分解した人はほとんどいない。