Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エンジニアとして関わる要件と仕様(公開用)
Search
bayashi
November 19, 2024
Programming
0
400
エンジニアとして関わる要件と仕様(公開用)
社内向け展開資料から社内向けの情報を削除した版です
bayashi
November 19, 2024
Tweet
Share
More Decks by bayashi
See All by bayashi
個人事業主型開発からの脱却
murabayashi
13
9.1k
スクラムフェスを支える配信の仕組み
murabayashi
1
610
締切とはなにか、どういう効果があるのか #scrummikawa
murabayashi
0
1.2k
商用アプリケーション開発基本のキ
murabayashi
0
220
(新米)エンジニアリングマネージャーのしごと #RSGT2023
murabayashi
11
11k
Active Recordについてわかったことを説明するよ
murabayashi
0
340
話を聞き出す技術
murabayashi
44
47k
フィヨルドブートキャンプ ドリンクアップ用会社紹介資料
murabayashi
0
350
カスタマーサポートから運用までみんなでやってるうちのチームのスクラム
murabayashi
0
2.9k
Other Decks in Programming
See All in Programming
pylint custom ruleで始めるレビュー自動化
shogoujiie
0
110
時計仕掛けのCompose
mkeeda
1
290
Unity Android XR入門
sakutama_11
0
150
iOSエンジニアから始める visionOS アプリ開発
nao_randd
3
130
Rails アプリ地図考 Flush Cut
makicamel
1
120
第3回関東Kaggler会_AtCoderはKaggleの役に立つ
chettub
3
1k
ペアーズでの、Langfuseを中心とした評価ドリブンなリリースサイクルのご紹介
fukubaka0825
2
320
『GO』アプリ バックエンドサーバのコスト削減
mot_techtalk
0
140
Pythonでもちょっとリッチな見た目のアプリを設計してみる
ueponx
1
550
color-scheme: light dark; を完全に理解する
uhyo
3
210
さいきょうのレイヤードアーキテクチャについて考えてみた
yahiru
3
750
Immutable ActiveRecord
megane42
0
140
Featured
See All Featured
KATA
mclloyd
29
14k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Being A Developer After 40
akosma
89
590k
Raft: Consensus for Rubyists
vanstee
137
6.8k
Navigating Team Friction
lara
183
15k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
240
Agile that works and the tools we love
rasmusluckow
328
21k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Designing for humans not robots
tammielis
250
25k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Transcript
エンジニアとして関わる 要件と仕様 社内向け展開資料(公開版) Kei Ogane
要件と仕様
PdMがすべて決めるものだと思っていない? PdMが仕様まで決めて持ってきてくることが多い (それが悪いことだとは思っていないが説明すると長くなるのでここでは割愛) 具体的な社内の事例
ただし PdMが持ってきた仕様を 決定事項のように扱うと 色んな問題が発生する
最近の自分のやらかし(未遂) 具体的な社内の事例
結局途中で仕様を変更してもらった でも自分が仕様を決定事項のように扱っていたら もっとたくさん時間を使い、 大量のif分岐という負債をコードに残して 実現していたかもしれない
今行うべき開発かどうかはコスパが大事 それがとっても大きなビジネスインパクトを生 むならたくさんコストをかけて開発しても良い ただ逆に変えようが変えまいがビジネスインパ クトが変わらないものにたくさんコストかける ことを誰が望んでいるんだろうか
コストに関しては 実際にどれくらいコストがかかるのかは エンジニアが一番詳しい そのためPdMのみで出した仕様に関しては コストパフォーマンスが最適かどうかはわからない つまりエンジニアが積極的に関与し コストパフォーマンスが最適な仕様を一緒に検討する必要がある
MOYにおいては以下のプロセスでやってる バックログリファインメント及びスプリントプランニングにて 「これって〇〇を達成したいんですよね、であればこういうやり方でも達成でき る気がするんですが」 「そうですね、そっちのほうが良いと思います」or 「いや、そのやり方だとこういうユースケースに対応できないですね(初出)」 みたいな会話を自分のチームではしている
プロダクトマネージャー エンジニア 表示機能の要件を教えてください 一ページにつき 10件表示してください 余談)会話で要件は詳細になっていくのだよの図
プロダクトマネージャー 一ページにつき 10件表示したいなぁ 聞く側が思っている相手の頭の中
10件表示する 言語化できてる領域 言語化できてない領域 考えてなかったけど今 ある知識から導き出せ る領域 未ログイン ユーザはこう いう挙動して 欲しい
今ある知識では導き出 せない領域 この機能はこ ういう価値に つながる データが0件の ときはこんな 見た目 今回の機能とは直接関 係ない周辺知識 出てきた要件 ページネーション して欲しい 他の画面のデータが0件の ときはこんな見た目 実際の頭の中 プロダクトマネージャー
10件表示する 言語化できてる領域 言語化できてない領域 考えてなかったけど今 ある知識から導き出せ る領域 未ログイン ユーザはこう いう挙動して 欲しい
今ある知識では導き出 せない領域 この機能はこ ういう価値に つながる データが0件の ときはこんな 見た目 今回の機能とは直接関 係ない周辺知識 出てきた要件 ページネーション して欲しい 他の画面のデータが0件の ときはこんな見た目 頭の中に眠っている知識を要件にもってきたい
プロダクトマネージャー エンジニア 11件目以降はどう表示するんです か? (10件表示するという仕様を聞いて 表出した疑問) 一ページにつき 10件表示してください 11件目以降はページネーションでお 願いします
(出てきた疑問に対して表出してき た知識) 対話(お互いに刺激を与え合う)
プロダクトマネージャー エンジニア 0件の場合はどうしますか? あー、◯◯画面がこんな表示です ね。そこと合わせましょうか 余談終わり)考えたことないところに気が付く
コストってイニシャルコストだけ考えてない? イニシャルコスト - 開発するのに最初払うコスト ランニングコスト - この機能を追加することで継続的に払うコスト - 追加される複雑性 -
メンテナンスコスト
プロダクトには許容できる複雑性の限界がある プログラミングの中心にあるのは、複雑性との戦 いだ。新しい機能を追加すると、コードが複雑に なることが多い。 そして、コードが複雑になるにつれ、そのコード で作業するのがどんどん難しくなり、進捗がどん どん遅くなる。 そこでは、バグ修正だろうが機能追加だろうが、 先に進もうとするどんな試みも、問題を解くそば から、解いた問題の数だけ同じ数の問題を新たに
発生させる。 ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール Chris Zimmerman (著), 久富木 隆一 (翻訳)
作った瞬間に負債になる 働きたくない人の脳内 https://note.com/ak_iii/n/nc650 32dcc1b6 プロダクトは作った瞬間に負債になる。 世の中は絶えず変化・進化していくので、作った 瞬間から陳腐化が始まる。それを防ぐために継続 的なメンテナンスや改善が求められる。 通常、その負債が問題視されないのは、そのプロ ダクトが負債以上に大きな果実つまり価値をもた
らすからである。
我々はプロダクト開発でこういうゲームをやっている 許容できる複雑性の残りゲージを削りつつ プロダクトの価値を積み上げていく 残りゲージが無くなったらゲームオーバー (追加開発ができなくなる) 複雑性 今までとは根本から違う機能の開 発。売上が30上がった!複雑性が40 上がった!
イニシャルコストとランニングコスト ランニングコストは、見積もりが難しい 今後複雑性を上げてしまったエリアの開発があれば、ランニングコストを払わな ければならないし、一生触らないのであれば払う必要はない またランニングコストは目先のコストとして見えないため軽視されがち
よくある話 機能Aの見積もりしてほしい です!コストどれくらいかか るかで優先順位決めるので! おk エンジニア PdM
よくある話 二ヶ月かぁ、厳しい。 もうちょい削れる方法はない ですかね 見積もってみたら大体二ヶ月 くらいかかりそうです エンジニア PdM
よくある話 一ヶ月ならこのタイミングで 開発できそうですね!複雑性 が上がるリスクは許容するん でそのやり方で行きましょ う! うーん、まぁ将来に負債残し ますけどこういうやり方だっ たら一ヶ月くらいかも... PdM
エンジニア
よくある話 一ヶ月ならこのタイミングで 開発できそうですね!複雑性 が上がるリスクは許容するん でそのやり方で行きましょ う! うーん、まぁ将来に負債残し ますけどこういうやり方だっ たら一ヶ月くらいかも... PdM
エンジニア ほんとに許容してる!? 考えてないだけじゃない!?
イニシャルコストとランニングコストの具体例 具体的な社内の事例
ビジネスはスケールする ビジネスはスケールする でもスケールするかどうかは不確実 スケールする前はオペレーションで回すのも そんなに難しくない その機能ほんとにスケールする前に必要かど うかを考える
ビジネスもプロダクトも実運用してからの学びが大きい スケールことがある程度高い確率でも見込まれていたとしても ビジネスもプロダクトも実運用してからわかることはとても多い その学びをプロダクトの機能に反映したいため 実運用が始まっていない段階では作り込みすぎない
ビジネスは不確実である 考えに考え抜いたものでも失敗する 具体的な社内の事例
余談)ランニングコストの感覚を養う 人の入れ替わりが激しいプロダクト、納期ゴール の開発だと、イニシャルコスト重視の開発が多発 する。メンテするのは自分じゃないから。 じゃけん継続的にプロダクトを開発し続ける安定 したチームを維持しましょうね
仕様と設計をいったりきたりする 仕様: 〇〇の時に△△を☓☓にしたい 設計案を色々考えてみても どれもコストパフォーマンスが見合わない
仕様と設計をいったりきたりする 仕様: 〇〇の時に△△を☓☓にしたい 仕様の☓☓を□□にしたらどんな設計になるだろう。 設計がシンプルになるし、メンテナンスコストも低い。実装もすぐできる。 価値も落ちてない! →コストパフォーマンスが見合う開発項目に早変わり
仕様を決める 仕様A 仕様B 仕様C 仕様D 設計A-A 設計A-B 設計B-A 設計D-A 価値をできるだけ落とさないように、仕様がいじれるかを探査する
要件について詳しいPdMと会話しながらやっている
必要なこと 仕様について言及するためには、要件やその背景について把握していないと頓珍 漢なアイディアばかりが出てくる。 そのためPdMより詳しくなくてもいいけど、 以下項目をエンジニアもある程度把握しておく - 自サービスのビジネスの仕組み - 今の注力ポイント -
オペレーションの温度感
とっても大事なこと 要件や仕様に口を出すということは、PdMと議論するということです - ビジネスとして達成したいこと - ユーザ体験として提供したいこと をちゃんと踏まえて提案し、相手の思いも尊重しようね ここまで書いたことは「エンジニアがビジネスに向き合っている」大前提の上で の話です 決してエンジニアの楽園を作るためにこの手法を使わないように
None