プロダクトの新機能の要件定義って、PdMがリードしてくれることが多いけど、要件を決めるのにはプロダクト面以外にも技術面の材料が必要になる。
そこで、ひとつの方法としては、プロダクト面の洗い出しをPdMが色々とやってしまってから、次よろしくってエンジニアにパスするやり方がある。エンジニアは、プロダクト面の情報を元にして技術面を詰めていく。
でも僕は、このやり方はあまり好きではない。
PdMは「エンジニアが困らないようにしっかり準備しなきゃ」ってすごくがんばって準備するけどそこまでやらなくてよかったのにってことも多い。
エンジニアは「なんでこんな要件なんだろう？このスコープを削れたら全然簡単なのにな」と思いつつ「まぁ要件だから仕方がないか」って、要件は変えられないものという認識になったりする。
そして、PdMとエンジニアの間に壁が自然とできてしまう。そんな状況だと、良い要件につながりにくい。
もうひとつ別の方法もある。それは、プロダクトに詳しいエンジニアが全部やってしまうこと。PdMとエンジニアでいったりきたりをする必要もないから、開発も速く進む。
でも、これをやると全てを知っているエンジニアが誕生する。そして、そのエンジニアは忙しいのでドキュメントも後回しになってほぼ作られない。だから、その人に聞かないと分からない。だから、その人はさらに忙しくなる。そして、要件を把握できていないPdMは「エンジニアに確認します」という動きになってしまう。
50人以下の開発組織で、ロールを分けるようなフェーズじゃないならアリだと思う。でも、ロールを分けたい規模なのに、これをやると結局その全部知ってるエンジニアがボトルネックになってしまう。
じゃあ、どういうやり方が好きなの？ってことだけど、僕は一緒にちょっとずつ進めるのが好き。
PdMとエンジニアがそれぞれの視点から要件について考えて意見を持ち寄って、エンジニアが「その選択肢は考えなくても大丈夫。技術的にはこうしたほうがいいからね」とか、PdMが「その部分は技術的な細かい調査はしなくていいよ。そこは運用でカバーできてる範囲だから」とか、そんな風に会話をしながら「あ、それなら、この技術チェックしてみるね」「そこはスコープから外せないか考えてみるね」って少しずつ前に進めていくのが好き。
今の自分のチームはそうなっているので好き。
これは、お互いにガーッと進めて「自分の部分は終わった！」みたいにすることができないので、少しストレスにはなるんだけど、でも、たどり着くところは良い場所であることが多い。
それに、お互いにゴールが共有できているから、開発中に何かに気づいたときに「これ、前提条件変わったから要件見直したほうがいいかも」って意見が出しやすい。
関係者が多いプロジェクトのときは、なかなか難しいけど、でもやることは同じ。PdMがプロダクトよりのステークホルダーと相談しながら少しずつ前に進めて、エンジニアが技術よりのステークホルダーと相談しながら少しずつ前に進めて、その両者が毎日情報を交換しながら少しずつ要件を作り上げていくのがいいなって思う。
PdMとエンジニアで話を書いたけど、デザイナーと進めるときも同じだな。
今日2つ目のしずかなインターネット。