プロダクトエンジニア:何を作るかまで決めるエンジニアの道
この職業をひと目で
出典・参考 (8)
- https://www.indeed.com/hire/job-description/software-engineer
- https://www.aha.io/roadmapping/guide/agile-development/what-is-the-role-of-a-software-engineer
- https://jessup.edu/blog/engineering-technology/what-do-software-engineers-do-on-a-daily-basis/
- https://www.computerscience.org/careers/software-engineer/
- https://www.mtu.edu/cs/undergraduate/software/what/
- https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm
- https://www.baesystems.com/en-us/who-we-are/electronic-systems/engineering-careers/software-engineering
- https://www.snhu.edu/about-us/newsroom/stem/what-does-a-software-engineer-do
この分野が重要な理由
Linearのエンジニア募集は職名がProduct Engineerだ。シニアやスタッフの区分でも、AIチームの席でも同じ名前を使い、その隣にフルスタックエンジニアの募集が別に並んでいる。名前を変えただけではなく、別の職種として扱っているということだ。Replitも同じ職名で採用している。
違いは範囲にある。プロダクトエンジニアは仕様書から始めない。ユーザーが何に詰まっているかを自分で確かめ、その中からどれを作るか選び、画面を描き、リリースし、二週間後の数字で自分の判断を採点する。PMやデザイナーがいないという意味ではない。同じテーブルで決定に加わるという意味だ。
この席がいま増えているのは、実装にかかる時間が短くなったからだ。エージェントがコードを出す速度が上がると、詰まる場所は前工程へ移る。OpenAIが公開した調査は、AIの導入が人の仕事を狭めるより、扱う範囲を広げる方向に現れると整理している。広告持株会社を作ったデビッド・ジョーンズは、自社の業務の95%を機械に任せているとフィナンシャル・タイムズに語った。一方で慎重な見方もある。スタンフォードSIEPRの政策ブリーフは、AIが雇用に与えた影響を実測データで誇張と切り分けようと提案している。職名が先に動き、統計が後から確認する区間だと見るのが正確だ。
必要なスキル
- 課題を選ぶ感覚。 ユーザーへのヒアリングを人任せにしない。難しいのは何を作らないかを決める側で、要望リストから三つ消す理由を説明できる必要がある。
- デザインの仕上げ。 デザイナーを待たずに、空の状態、ローディング、エラー、権限のない画面まで描く。ハッピーパスだけ作って残りを渡すのは、この職種では半分しかやっていない。
- 計測。 イベントスキーマを先に設計してからリリースする。あとから計測を足すと必ず遅れ、遅れれば自分の判断が正しかったか分からないままになる。
- フルスタックとデプロイ。 フロントからデータモデル、マイグレーション、段階的な公開まで。機能を一つ最後まで自分で出せて初めて決定権がついてくる。
- エージェントへの委任と検証。 実装を道具に渡し、空いた時間を判断に使う。返ってきたものを読んで弾く目がなければ、速く間違えるだけになる。
- 短い文章。 一枚の仕様、五行のリリースノート。決めた理由を残さないと、半年後に同じ議論をやり直す。
キャリアパス
ジュニアの区間では、機能を一つ、課題の定義からリリースまで自分で引っ張る。ここで身につくのはコードではなく、選んだ課題が外れたときの感触だ。シニアになると製品領域を一つ持ち、PMがいても優先順位を一緒に組む。スタッフやリードの区間では、チームが何に一切手を出さないかを決め、その基準を採用基準に移していく。
日本ではこの職名がそのまま制度化されている会社はまだ少ない。実態としては、スタートアップでエンジニアが企画を兼ねる形で存在している。新卒一括採用の配属では職種の枠が先に決まりやすく、大手では企画、デザイン、開発の分業がはっきりしているぶん、この道は見えにくい。だから日本での現実的な課題は職名ではなく証拠のほうだ。職務経歴書に「実装した」だけが並ぶと、どちらの会社からもプロダクトエンジニアとしては読まれない。何を作らないと決め、その判断で数字がどう動いたかを一行でも書けると、読む側の見方が変わる。
面接の準備を一つだけ選ぶなら、自分が作った機能のうちユーザーに結局使われなかったものを一つ取り上げ、なぜ外したのかを5分にまとめておくことを勧める。成功事例は誰でも持ってくる。失敗を分解した人はほとんどいない。