A guide to writing specs toward engineers(Japanese)

This slide is for Product Managers who want to write specs that can get buy-in from engineers and that is well stated that a team can start working on it without hassle.

エンジニアから共感を得られて、チームがすぐに動き出せる仕様書を書きたいプロダクトマネジャーに向けたスライドです。

Transcript

1. エンジニアが嬉しい仕様の書き⽅方ガイド 今井智章 @Chomp, inc
2. HOW GOOD FRIENDS FOOD Goal • プロダクトマネジャーがエンジニアとスムーズに会話できる仕様書のポイント を理理解する • 読みやすく、チームがすぐに実装にとりかかる仕様書を書く • 詳細を書きすぎない(10ページもある仕様書は読まれない) • 説明が的確 etc • 対象外 • マーケットチームやデザインチームなど、他のステークホルダーへ向けた仕様書の書き⽅方 2
3. HOW GOOD FRIENDS FOOD エンジニアが仕様書に期待すること
4. HOW GOOD FRIENDS FOOD エンジニアが仕様書に期待すること 1.取り組みたい理理由がハッキリしている 2.提案内容が明確になっている 3.KISS原則(Keep It Short and Simple) が守られている
 4
5. HOW GOOD FRIENDS FOOD 1.取り組みたい理理由がハッキリしている • エンジニアの⽕火を付けるために重要 • この機能を作るにあたっての仮説は？ • ユーザー、プロダクトに与える影響は? 5 機能: Facebookと連絡帳からの友⼈人追加 問題提議 - 友⼈人のいないユーザーのx%以上は2回以降のアプリの利利⽤用をやめてしまう 仮説 - サービス内に友⼈人のいるユーザーは使い続ける可能性が⾼高い - 複数のチャネル(Facebookや連絡帳)があったほうが友⼈人追加をしやすいはず 影響 - 現状ユーザー名からしか検索/友⼈人追加ができない。この機能でユーザーはより簡単に友⼈人追加できるよう になる - ユーザーあたりの友⼈人数が増加する。この機能はQ1のOKR XXXに貢献する
6. HOW GOOD FRIENDS FOOD 2. 提案内容が明確になっている • 完了了条件 • どのような成果物を期待するのか - Ex. ユーザーが会員登録できる • ここには仕様の詳細を書かない! • スコープ/スコープ外と優先順位 • ターゲット層や影響を受ける画⾯面 • この機能で取り組まないこと • 最初のリリースで最⼩小限出したい機能 • リリース期⽇日とその理理由は? 6 完了了条件 - ユーザーが友⼈人リクエストを申請/許可できる - ユーザーがFBや連絡帳にアクセス許可を与えるこ とでサービス内の友⼈人を探せるようになる Scope - ターゲット層: 友⼈人数が2⼈人以下 - 影響のある画⾯面 - 友⼈人⼀一覧画⾯面 - 友⼈人追加画⾯面 スコープ外 - 外部アプリを使った友⼈人追加(招待機能) スケジュール - 2週間後、Q2スタート前に計測結果を出したい 最⼩小限の機能 - Facebookを利利⽤用してサービス内の友⼈人を探すこと ができる
7. HOW GOOD FRIENDS FOOD 3. KISS原則(Keep It Short and Simple) が守られている • ⻑⾧長い仕様書は重要な点を⾒見見落としがちになるし、そもそも読まれない • デザインでわかることは書かない • ユーザージャーニーを簡潔に説明する • ⾏行行動を時系列列にステップ化する • タッチポイント別の⾏行行動を整理理する 7
8. HOW GOOD FRIENDS FOOD 仕様書に必要なもの • 画⾯面/コンポーネントの遷移やふるまい • ボタンを押したらどのようになる? • どうに次の画⾯面に遷移する? • 機能のライフサイクル • アラートは何度出す?再起動後もでる? • データの保持期限は? • コーナーケース • アクションが失敗したときのふるまいは? • ⾮非機能要件 (この機能で特に必要なもの) • Ex1. 結果を1秒以内に表示し、ローディングは出さない • Ex2. ⼀一箇所記⼊入ごとにバリデーションチェックする 8 Addがタップされたら、 カード⾃自体が⾮非表示に 次のスクリーンは 下から上がってくる Add がタップされたら、pending表示に 切り替わる(タップはできなくなる) ⼀一度閉じられたら、⼆二度と表示しない 表示順序は - 共通の友⼈人数 - FBユーザーかどうか
9. HOW GOOD FRIENDS FOOD 仕様書に必要ないもの • UI仕様。デザインをみて⾒見見て明らかなもの • どのように実装するか(それを考えるのがエンジニアの責任) • あいまいさ • 実装すべきか否かエンジニアが判断に困る仕様 • もしあいまいでも重要と思う場合は備考として残しておく(エンジニアに判断を委ねる) 9
10. HOW GOOD FRIENDS FOOD 仕様書に関するあれこれ
11. HOW GOOD FRIENDS FOOD いつから仕様書は書き始めるべきか • なるはやで書き始める • 中規模な仕様であれば開発1週間前に、⼤大規模な仕様であれば2週間前までに • 下書きから始めてレビューをする • エンジニアからの合意を得るよいタイミング 11 - 下書き - モック - レビュー/フィードバック - ブレインストーミング - 詳細化 - より正確なデザイン - スケジュール - Q&A セッション - 実装キックオフ
12. HOW GOOD FRIENDS FOOD フィードバック • フィードバックを”攻撃”と捉えない • エンジニアは仕様を正確にしたい • エンジニアは隠れた要求を明らかにしたい • エンジニアはプロダクトマネジャーの⽬目的を達成するアイデアを提案したい • ⽿耳を傾けてよいが、従う必要はない • もし⾃自分の仕様がより良いと思うのであれば、変える必要はない! 12
13. HOW GOOD FRIENDS FOOD Misc • もし作れるかどうかわからない場合は? • エンジニアに実現可能性をまず相談してみる(仕様に実現が曖昧な点を残しておかない!) • 相談の上、調査タスクをまず積むのは良い⽅方法 • 仕様を途中から変えたくなったら? • 変更更点を明示する(下線をひく、メモを残す、いつ更更新したか書く) • 関わっているエンジニアに周知する。ミスコミュニケーションを避けよう! 13