Slide 1

Slide 1 text

エンジニアとして関わる 要件と仕様 社内向け展開資料(公開版) Kei Ogane

Slide 2

Slide 2 text

要件と仕様

Slide 3

Slide 3 text

PdMがすべて決めるものだと思っていない? PdMが仕様まで決めて持ってきてくることが多い (それが悪いことだとは思っていないが説明すると長くなるのでここでは割愛) 具体的な社内の事例

Slide 4

Slide 4 text

ただし PdMが持ってきた仕様を 決定事項のように扱うと 色んな問題が発生する

Slide 5

Slide 5 text

最近の自分のやらかし(未遂) 具体的な社内の事例

Slide 6

Slide 6 text

結局途中で仕様を変更してもらった でも自分が仕様を決定事項のように扱っていたら もっとたくさん時間を使い、 大量のif分岐という負債をコードに残して 実現していたかもしれない

Slide 7

Slide 7 text

今行うべき開発かどうかはコスパが大事 それがとっても大きなビジネスインパクトを生 むならたくさんコストをかけて開発しても良い ただ逆に変えようが変えまいがビジネスインパ クトが変わらないものにたくさんコストかける ことを誰が望んでいるんだろうか

Slide 8

Slide 8 text

コストに関しては 実際にどれくらいコストがかかるのかは エンジニアが一番詳しい そのためPdMのみで出した仕様に関しては コストパフォーマンスが最適かどうかはわからない つまりエンジニアが積極的に関与し コストパフォーマンスが最適な仕様を一緒に検討する必要がある

Slide 9

Slide 9 text

MOYにおいては以下のプロセスでやってる バックログリファインメント及びスプリントプランニングにて 「これって〇〇を達成したいんですよね、であればこういうやり方でも達成でき る気がするんですが」 「そうですね、そっちのほうが良いと思います」or 「いや、そのやり方だとこういうユースケースに対応できないですね(初出)」 みたいな会話を自分のチームではしている

Slide 10

Slide 10 text

プロダクトマネージャー エンジニア 表示機能の要件を教えてください 一ページにつき 10件表示してください 余談)会話で要件は詳細になっていくのだよの図

Slide 11

Slide 11 text

プロダクトマネージャー 一ページにつき 10件表示したいなぁ 聞く側が思っている相手の頭の中

Slide 12

Slide 12 text

10件表示する 言語化できてる領域 言語化できてない領域 考えてなかったけど今 ある知識から導き出せ る領域 未ログイン ユーザはこう いう挙動して 欲しい 今ある知識では導き出 せない領域 この機能はこ ういう価値に つながる データが0件の ときはこんな 見た目 今回の機能とは直接関 係ない周辺知識 出てきた要件 ページネーション して欲しい 他の画面のデータが0件の ときはこんな見た目 実際の頭の中 プロダクトマネージャー

Slide 13

Slide 13 text

10件表示する 言語化できてる領域 言語化できてない領域 考えてなかったけど今 ある知識から導き出せ る領域 未ログイン ユーザはこう いう挙動して 欲しい 今ある知識では導き出 せない領域 この機能はこ ういう価値に つながる データが0件の ときはこんな 見た目 今回の機能とは直接関 係ない周辺知識 出てきた要件 ページネーション して欲しい 他の画面のデータが0件の ときはこんな見た目 頭の中に眠っている知識を要件にもってきたい

Slide 14

Slide 14 text

プロダクトマネージャー エンジニア 11件目以降はどう表示するんです か? (10件表示するという仕様を聞いて 表出した疑問) 一ページにつき 10件表示してください 11件目以降はページネーションでお 願いします (出てきた疑問に対して表出してき た知識) 対話(お互いに刺激を与え合う)

Slide 15

Slide 15 text

プロダクトマネージャー エンジニア 0件の場合はどうしますか? あー、◯◯画面がこんな表示です ね。そこと合わせましょうか 余談終わり)考えたことないところに気が付く

Slide 16

Slide 16 text

コストってイニシャルコストだけ考えてない? イニシャルコスト - 開発するのに最初払うコスト ランニングコスト - この機能を追加することで継続的に払うコスト - 追加される複雑性 - メンテナンスコスト

Slide 17

Slide 17 text

プロダクトには許容できる複雑性の限界がある プログラミングの中心にあるのは、複雑性との戦 いだ。新しい機能を追加すると、コードが複雑に なることが多い。 そして、コードが複雑になるにつれ、そのコード で作業するのがどんどん難しくなり、進捗がどん どん遅くなる。 そこでは、バグ修正だろうが機能追加だろうが、 先に進もうとするどんな試みも、問題を解くそば から、解いた問題の数だけ同じ数の問題を新たに 発生させる。 ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール Chris Zimmerman (著), 久富木 隆一 (翻訳)

Slide 18

Slide 18 text

作った瞬間に負債になる 働きたくない人の脳内 https://note.com/ak_iii/n/nc650 32dcc1b6 プロダクトは作った瞬間に負債になる。 世の中は絶えず変化・進化していくので、作った 瞬間から陳腐化が始まる。それを防ぐために継続 的なメンテナンスや改善が求められる。 通常、その負債が問題視されないのは、そのプロ ダクトが負債以上に大きな果実つまり価値をもた らすからである。

Slide 19

Slide 19 text

我々はプロダクト開発でこういうゲームをやっている 許容できる複雑性の残りゲージを削りつつ プロダクトの価値を積み上げていく 残りゲージが無くなったらゲームオーバー (追加開発ができなくなる) 複雑性 今までとは根本から違う機能の開 発。売上が30上がった!複雑性が40 上がった!

Slide 20

Slide 20 text

イニシャルコストとランニングコスト ランニングコストは、見積もりが難しい 今後複雑性を上げてしまったエリアの開発があれば、ランニングコストを払わな ければならないし、一生触らないのであれば払う必要はない またランニングコストは目先のコストとして見えないため軽視されがち

Slide 21

Slide 21 text

よくある話 機能Aの見積もりしてほしい です!コストどれくらいかか るかで優先順位決めるので! おk エンジニア PdM

Slide 22

Slide 22 text

よくある話 二ヶ月かぁ、厳しい。 もうちょい削れる方法はない ですかね 見積もってみたら大体二ヶ月 くらいかかりそうです エンジニア PdM

Slide 23

Slide 23 text

よくある話 一ヶ月ならこのタイミングで 開発できそうですね!複雑性 が上がるリスクは許容するん でそのやり方で行きましょ う! うーん、まぁ将来に負債残し ますけどこういうやり方だっ たら一ヶ月くらいかも... PdM エンジニア

Slide 24

Slide 24 text

よくある話 一ヶ月ならこのタイミングで 開発できそうですね!複雑性 が上がるリスクは許容するん でそのやり方で行きましょ う! うーん、まぁ将来に負債残し ますけどこういうやり方だっ たら一ヶ月くらいかも... PdM エンジニア ほんとに許容してる!? 考えてないだけじゃない!?

Slide 25

Slide 25 text

イニシャルコストとランニングコストの具体例 具体的な社内の事例

Slide 26

Slide 26 text

ビジネスはスケールする ビジネスはスケールする でもスケールするかどうかは不確実 スケールする前はオペレーションで回すのも そんなに難しくない その機能ほんとにスケールする前に必要かど うかを考える

Slide 27

Slide 27 text

ビジネスもプロダクトも実運用してからの学びが大きい スケールことがある程度高い確率でも見込まれていたとしても ビジネスもプロダクトも実運用してからわかることはとても多い その学びをプロダクトの機能に反映したいため 実運用が始まっていない段階では作り込みすぎない

Slide 28

Slide 28 text

ビジネスは不確実である 考えに考え抜いたものでも失敗する 具体的な社内の事例

Slide 29

Slide 29 text

余談)ランニングコストの感覚を養う 人の入れ替わりが激しいプロダクト、納期ゴール の開発だと、イニシャルコスト重視の開発が多発 する。メンテするのは自分じゃないから。 じゃけん継続的にプロダクトを開発し続ける安定 したチームを維持しましょうね

Slide 30

Slide 30 text

仕様と設計をいったりきたりする 仕様: 〇〇の時に△△を☓☓にしたい 設計案を色々考えてみても どれもコストパフォーマンスが見合わない

Slide 31

Slide 31 text

仕様と設計をいったりきたりする 仕様: 〇〇の時に△△を☓☓にしたい 仕様の☓☓を□□にしたらどんな設計になるだろう。 設計がシンプルになるし、メンテナンスコストも低い。実装もすぐできる。 価値も落ちてない! →コストパフォーマンスが見合う開発項目に早変わり

Slide 32

Slide 32 text

仕様を決める 仕様A 仕様B 仕様C 仕様D 設計A-A 設計A-B 設計B-A 設計D-A 価値をできるだけ落とさないように、仕様がいじれるかを探査する 要件について詳しいPdMと会話しながらやっている

Slide 33

Slide 33 text

必要なこと 仕様について言及するためには、要件やその背景について把握していないと頓珍 漢なアイディアばかりが出てくる。 そのためPdMより詳しくなくてもいいけど、 以下項目をエンジニアもある程度把握しておく - 自サービスのビジネスの仕組み - 今の注力ポイント - オペレーションの温度感

Slide 34

Slide 34 text

とっても大事なこと 要件や仕様に口を出すということは、PdMと議論するということです - ビジネスとして達成したいこと - ユーザ体験として提供したいこと をちゃんと踏まえて提案し、相手の思いも尊重しようね ここまで書いたことは「エンジニアがビジネスに向き合っている」大前提の上で の話です 決してエンジニアの楽園を作るためにこの手法を使わないように

Slide 35

Slide 35 text

No content