エンジニアとの協業

面接ではこう答える 読み上げ

仕様書、いわゆる PRD で PdM が明確にするのは、なぜ作るか、誰のためか、何をもって成功とするか、そして今回は何をやらないかです。どう作るかはエンジニアと一緒に決め、決めた理由を仕様書に残します。私は要件を必須とできればに分け、エッジケースや非機能要件、未決事項と誰がいつまでに決めるかも書くようにしています。そうすると見積もりが合いやすく、作り始めてからの手戻りが減ります。

面接ではこう答える 読み上げ

非機能要件は、何ができるかという機能以外の性質のことで、表示の速さ、止まってよい時間、個人情報の扱い、アクセシビリティ、対応する端末やブラウザ、効果を測るためのログなどです。書いていないと後回しになり、見積もりも合わず、出す直前に問題になります。私は数字で書けるものは数字で、例えば一覧の表示は p95 で1秒以内、1万件まで、のように仕様に入れています。

面接ではこう答える 読み上げ

受け入れ条件は、何ができたら完成かを、確かめられる形で書いたものです。Given・When・Then、つまり前提・操作・結果の形で書くと、あいまいさが減り、そのまま QA のテストの観点や自分の受け入れ確認に使えます。「使いやすく」ではなく「3タップ以内で再注文できる」のように書きます。リファインメントでエンジニアや QA と見直すと、エッジケースも見つかります。

面接ではこう答える 読み上げ

エンジニアに「できますか」と聞くと、答えはできる・できないになりがちです。そこで私は、どこが一番難しいか、どこを削れば早く出せるか、リリースで何が壊れる可能性があるか、やり方が複数あるならそれぞれ何を得て何を諦めるか、を聞くようにしています。技術の話が分からないときは分かったふりをせず、ユーザーから見て何が変わるか、図に描いてもらえるか、と聞き直します。

面接ではこう答える 読み上げ

やり方が複数あるときは、エンジニアに2〜3の案とそれぞれの得失を出してもらい、期限、体験、出したあとの手間と費用、将来の拡張、戻しやすさで並べて比べます。PdM が決めるのは技術的な正しさではなく、事業として期限と体験と運用の軽さのどれを優先するかです。決めた案と理由は短く記録し、前提が変わったら見直せるようにしています。

面接ではこう答える 読み上げ

多くの開発チームは、1〜2週間のスプリントという区切りで、プランニングで何を作るか決め、毎日のデイリーで進み具合を合わせ、レビューで動くものを見せ、振り返りでやり方を直します。次の分の要件を詰めるリファインメントもあります。PdM は特にリファインメントで目的と受け入れ条件を説明し、レビューで受け入れ確認をします。一番大事なのは、PdM の返事待ちで作業を止めないことだと考えています。

面接ではこう答える 読み上げ

エンジニアとのすれ違いの多くは、同じ言葉を違う意味で使っていたり、相談が遅れたりして起きます。典型は、見積もりを約束として扱って外れたら責める、作り始めてから仕様を足す、負債の返済を毎回後回しにする、障害の優先度が人によって違う、の4つです。私は幅で見積もりを聞き、エッジケースを先に洗い出し、返済の割合と重大度の基準を事前に合意し、決めたことを記録に残して防ぐようにしています。