Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エンジニアとして関わる要件と仕様(公開用)
Search
bayashi
November 19, 2024
Programming
0
340
エンジニアとして関わる要件と仕様(公開用)
社内向け展開資料から社内向けの情報を削除した版です
bayashi
November 19, 2024
Tweet
Share
More Decks by bayashi
See All by bayashi
個人事業主型開発からの脱却
murabayashi
13
8.6k
スクラムフェスを支える配信の仕組み
murabayashi
1
270
締切とはなにか、どういう効果があるのか #scrummikawa
murabayashi
0
1.1k
商用アプリケーション開発基本のキ
murabayashi
0
200
(新米)エンジニアリングマネージャーのしごと #RSGT2023
murabayashi
11
11k
Active Recordについてわかったことを説明するよ
murabayashi
0
300
話を聞き出す技術
murabayashi
43
46k
フィヨルドブートキャンプ ドリンクアップ用会社紹介資料
murabayashi
0
330
カスタマーサポートから運用までみんなでやってるうちのチームのスクラム
murabayashi
0
2.9k
Other Decks in Programming
See All in Programming
大規模サイトリビルドの現場から:成功と失敗のリアルな教訓 / Site Rebuild,Real Lessons Learned from Successes and Failures_JJUG Fall 2024
techtekt
0
200
N.E.X.T LEVEL
pluu
2
240
急成長期の品質とスピードを両立するフロントエンド技術基盤
soarteclab
0
500
物流システムにおけるリファクタリングとアーキテクチャの再構築 〜依存関係とモジュール分割の重要性〜
deeprain
1
270
Jakarta EE meets AI
ivargrimstad
0
930
Enabling DevOps and Team Topologies Through Architecture: Architecting for Fast Flow
cer
PRO
0
420
チームにとって最適なスキルアップ施策とは何か/what-is-the-best-skill-up-approach-for-team
nobuoooo
0
160
Cognitoが大型アップデート!Managed Loginとパスワードレスログインを実際に使ってみた@しむそくRadio Special Day1
tmhirai
2
150
TypeScriptでライブラリとの依存を限定的にする方法
tutinoko
3
830
Discord Bot with AI -for English learners-
xin9le
0
110
Leverage LLMs in Java with LangChain4j and Quarkus
hollycummins
0
130
layerx_20241129.pdf
kyoheig3
2
190
Featured
See All Featured
Statistics for Hackers
jakevdp
796
220k
Agile that works and the tools we love
rasmusluckow
327
21k
Making Projects Easy
brettharned
115
5.9k
Producing Creativity
orderedlist
PRO
341
39k
Embracing the Ebb and Flow
colly
84
4.5k
We Have a Design System, Now What?
morganepeng
50
7.2k
Gamification - CAS2011
davidbonilla
80
5k
GitHub's CSS Performance
jonrohan
1030
460k
Raft: Consensus for Rubyists
vanstee
136
6.7k
Adopting Sorbet at Scale
ufuk
73
9.1k
What's in a price? How to price your products and services
michaelherold
243
12k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
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