エンジニアとして関わる要件と仕様(公開用)

社内向け展開資料から社内向けの情報を削除した版です

Transcript

1. エンジニアとして関わる 要件と仕様 社内向け展開資料（公開版） Kei Ogane
2. 要件と仕様
3. PdMがすべて決めるものだと思っていない？ PdMが仕様まで決めて持ってきてくることが多い （それが悪いことだとは思っていないが説明すると長くなるのでここでは割愛） 具体的な社内の事例
4. ただし PdMが持ってきた仕様を 決定事項のように扱うと 色んな問題が発生する
5. 最近の自分のやらかし（未遂） 具体的な社内の事例
6. 結局途中で仕様を変更してもらった でも自分が仕様を決定事項のように扱っていたら もっとたくさん時間を使い、 大量のif分岐という負債をコードに残して 実現していたかもしれない
7. 今行うべき開発かどうかはコスパが大事 それがとっても大きなビジネスインパクトを生 むならたくさんコストをかけて開発しても良い ただ逆に変えようが変えまいがビジネスインパ クトが変わらないものにたくさんコストかける ことを誰が望んでいるんだろうか
8. コストに関しては 実際にどれくらいコストがかかるのかは エンジニアが一番詳しい そのためPdMのみで出した仕様に関しては コストパフォーマンスが最適かどうかはわからない つまりエンジニアが積極的に関与し コストパフォーマンスが最適な仕様を一緒に検討する必要がある
9. MOYにおいては以下のプロセスでやってる バックログリファインメント及びスプリントプランニングにて 「これって〇〇を達成したいんですよね、であればこういうやり方でも達成でき る気がするんですが」 「そうですね、そっちのほうが良いと思います」or 「いや、そのやり方だとこういうユースケースに対応できないですね（初出）」 みたいな会話を自分のチームではしている
10. プロダクトマネージャー エンジニア 表示機能の要件を教えてください 一ページにつき 10件表示してください 余談）会話で要件は詳細になっていくのだよの図
11. プロダクトマネージャー 一ページにつき 10件表示したいなぁ 聞く側が思っている相手の頭の中
12. 10件表示する 言語化できてる領域 言語化できてない領域 考えてなかったけど今 ある知識から導き出せ る領域 未ログイン ユーザはこう いう挙動して 欲しい 今ある知識では導き出 せない領域 この機能はこ ういう価値に つながる データが0件の ときはこんな 見た目 今回の機能とは直接関 係ない周辺知識 出てきた要件 ページネーション して欲しい 他の画面のデータが0件の ときはこんな見た目 実際の頭の中 プロダクトマネージャー
13. 10件表示する 言語化できてる領域 言語化できてない領域 考えてなかったけど今 ある知識から導き出せ る領域 未ログイン ユーザはこう いう挙動して 欲しい 今ある知識では導き出 せない領域 この機能はこ ういう価値に つながる データが0件の ときはこんな 見た目 今回の機能とは直接関 係ない周辺知識 出てきた要件 ページネーション して欲しい 他の画面のデータが0件の ときはこんな見た目 頭の中に眠っている知識を要件にもってきたい
14. プロダクトマネージャー エンジニア 11件目以降はどう表示するんです か？ (10件表示するという仕様を聞いて 表出した疑問) 一ページにつき 10件表示してください 11件目以降はページネーションでお 願いします (出てきた疑問に対して表出してき た知識） 対話(お互いに刺激を与え合う)
15. プロダクトマネージャー エンジニア 0件の場合はどうしますか？ あー、◯◯画面がこんな表示です ね。そこと合わせましょうか 余談終わり）考えたことないところに気が付く
16. コストってイニシャルコストだけ考えてない？ イニシャルコスト - 開発するのに最初払うコスト ランニングコスト - この機能を追加することで継続的に払うコスト - 追加される複雑性 - メンテナンスコスト
17. プロダクトには許容できる複雑性の限界がある プログラミングの中心にあるのは、複雑性との戦 いだ。新しい機能を追加すると、コードが複雑に なることが多い。 そして、コードが複雑になるにつれ、そのコード で作業するのがどんどん難しくなり、進捗がどん どん遅くなる。 そこでは、バグ修正だろうが機能追加だろうが、 先に進もうとするどんな試みも、問題を解くそば から、解いた問題の数だけ同じ数の問題を新たに 発生させる。 ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール Chris Zimmerman (著), 久富木 隆一 (翻訳)
18. 作った瞬間に負債になる 働きたくない人の脳内 https://note.com/ak_iii/n/nc650 32dcc1b6 プロダクトは作った瞬間に負債になる。 世の中は絶えず変化・進化していくので、作った 瞬間から陳腐化が始まる。それを防ぐために継続 的なメンテナンスや改善が求められる。 通常、その負債が問題視されないのは、そのプロ ダクトが負債以上に大きな果実つまり価値をもた らすからである。
19. 我々はプロダクト開発でこういうゲームをやっている 許容できる複雑性の残りゲージを削りつつ プロダクトの価値を積み上げていく 残りゲージが無くなったらゲームオーバー （追加開発ができなくなる） 複雑性 今までとは根本から違う機能の開 発。売上が30上がった！複雑性が40 上がった！
20. イニシャルコストとランニングコスト ランニングコストは、見積もりが難しい 今後複雑性を上げてしまったエリアの開発があれば、ランニングコストを払わな ければならないし、一生触らないのであれば払う必要はない またランニングコストは目先のコストとして見えないため軽視されがち
21. よくある話 機能Aの見積もりしてほしい です！コストどれくらいかか るかで優先順位決めるので！ おｋ エンジニア PdM
22. よくある話 二ヶ月かぁ、厳しい。 もうちょい削れる方法はない ですかね 見積もってみたら大体二ヶ月 くらいかかりそうです エンジニア PdM
23. よくある話 一ヶ月ならこのタイミングで 開発できそうですね！複雑性 が上がるリスクは許容するん でそのやり方で行きましょ う！ うーん、まぁ将来に負債残し ますけどこういうやり方だっ たら一ヶ月くらいかも... PdM エンジニア
24. よくある話 一ヶ月ならこのタイミングで 開発できそうですね！複雑性 が上がるリスクは許容するん でそのやり方で行きましょ う！ うーん、まぁ将来に負債残し ますけどこういうやり方だっ たら一ヶ月くらいかも... PdM エンジニア ほんとに許容してる！？ 考えてないだけじゃない！？
25. イニシャルコストとランニングコストの具体例 具体的な社内の事例
26. ビジネスはスケールする ビジネスはスケールする でもスケールするかどうかは不確実 スケールする前はオペレーションで回すのも そんなに難しくない その機能ほんとにスケールする前に必要かど うかを考える
27. ビジネスもプロダクトも実運用してからの学びが大きい スケールことがある程度高い確率でも見込まれていたとしても ビジネスもプロダクトも実運用してからわかることはとても多い その学びをプロダクトの機能に反映したいため 実運用が始まっていない段階では作り込みすぎない
28. ビジネスは不確実である 考えに考え抜いたものでも失敗する 具体的な社内の事例
29. 余談）ランニングコストの感覚を養う 人の入れ替わりが激しいプロダクト、納期ゴール の開発だと、イニシャルコスト重視の開発が多発 する。メンテするのは自分じゃないから。 じゃけん継続的にプロダクトを開発し続ける安定 したチームを維持しましょうね
30. 仕様と設計をいったりきたりする 仕様: 〇〇の時に△△を☓☓にしたい 設計案を色々考えてみても どれもコストパフォーマンスが見合わない
31. 仕様と設計をいったりきたりする 仕様: 〇〇の時に△△を☓☓にしたい 仕様の☓☓を□□にしたらどんな設計になるだろう。 設計がシンプルになるし、メンテナンスコストも低い。実装もすぐできる。 価値も落ちてない！ →コストパフォーマンスが見合う開発項目に早変わり
32. 仕様を決める 仕様A 仕様B 仕様C 仕様D 設計A-A 設計A-B 設計B-A 設計D-A 価値をできるだけ落とさないように、仕様がいじれるかを探査する 要件について詳しいPdMと会話しながらやっている
33. 必要なこと 仕様について言及するためには、要件やその背景について把握していないと頓珍 漢なアイディアばかりが出てくる。 そのためPdMより詳しくなくてもいいけど、 以下項目をエンジニアもある程度把握しておく - 自サービスのビジネスの仕組み - 今の注力ポイント - オペレーションの温度感
34. とっても大事なこと 要件や仕様に口を出すということは、PdMと議論するということです - ビジネスとして達成したいこと - ユーザ体験として提供したいこと をちゃんと踏まえて提案し、相手の思いも尊重しようね ここまで書いたことは「エンジニアがビジネスに向き合っている」大前提の上で の話です 決してエンジニアの楽園を作るためにこの手法を使わないように