「スクラムフレームワークを使用する具体的な方法。僕の場合。」というタイトルでスクラムフェス大阪で発表してきました。楽しかった。今回のは説明がある方がいいかなーと思ったので、スライドをアップロードするんじゃなくてここで紹介してみることにする。長くなりそうなので、今日は前編。
## TL;DR
計画を持った開発のサイクルと、それとは異なる周波数の様々なイベントを、どううまく組み合わせて開発を進めるか。それを、自分の現場で自分の仲間と探していく道のり。
## 全体像
左上が「1. チーム」、左下が「2. スプリントの内側」、右半分が「3. スプリントの外側」。この3つを紹介。正解やオススメというわけではなくて、自分たちの現場ではこういうやり方をしている、という紹介。
## 1. チーム
ビジネス・デザイン・開発の3つの組織に分かれている。そんな中で、どんな風に協力しながら開発を進めているか。
### 三角形の部分: マネージャーロール
開発を進めるときのコアになる3つのマネージャーロール。
- PDM (Product Manager): プロダクトオーナー+組織周りの色々
- PJM (Project Manager): スクラムマスター+組織周りの色々
- DVM (Development Manager): テックリード+組織周りの色々
### 丸の部分: プロダクトオーナーチーム
プロダクトオーナーをひとりにしない。それぞれのリーダーがその専門知識をもって支えながら、全員でプロダクトの方向性を話し合う。最終的な決定はプロダクトオーナーがする。けど、誰がプロダクトバックログアイテムを作ってもいいし、並び替えてもいい。
## 2. スプリントの内側
### PBL: プロダクトバックログ
ベロシティが10〜15ポイントくらいになるのが好き。1スプリントで40ポイントとか50ポイントのベロシティーになってしまうと、せっかくざっくり見積もりをしてるのに細かく考えないといけなくなってしまうから。
それと、ベロシティーは上げようとしない。安定すれば良い。数字を追いかけてる人は自然と「ベロシティを上げること」に目を向けてしまうけど「そういうためのものではないよ」と伝えるようにしている。
1つのストーリーの粒度は、チームで2,3日で終わるくらいだと進みが分かりやすくて好き。
### SBL: スプリントバックログ
スプリントプランニングでストーリーをタスクに落とし込む。ペアで2,3時間で終わるぐらいの粒度が進みが分かりやすくて好き。
まだチームが自分たちのスピードを分かってない場合には理想時間で見積もりをする。「今回は160時間あるからって160時間ぶんのタスクを積んでたけど、終わったのは120時間ぶんだったね？ということは、このチームは160時間で120時間ぶんのタスクを終わらせることができるってことだから、次からはそれでプランニングをしよう」って。
それでだんだんチームが慣れてきたら、理想時間の見積もりはしなくても良くなって、チケットの枚数でバーンダウンできるようになるし、最後はバーンダウンチャートもいらなくなる。
### Feature Definition
プロダクトオーナーが中心になって作る。何を作るのか、だけじゃなくて、なぜ作るのか？ということが書いてある。例えば
- ユーザーAさん（ペルソナ）は、今、こういうことで困っている
- だから、このサービスでこういうことができるようになるといいなと思っている
- なぜならば、それによってAさんはこういう嬉しいことがあるからだ
- そして、Aさんが嬉しくなることによってこのサービスにはこういう嬉しいことがある
だから、開発チームは「なぜ作るのか」を理解して作ることができる。なので、もし何か実装上の難しい問題があった場合でも、その目的に沿った別の良い方法がないかを探すことができる。
僕は納得しないと作らないので、テックリードをしてたときはプロダクトオーナーと「この機能をAさんが使いたいと思うモチベーションに納得できない。そんな動機では使わないと思う」って話をよくしてた。そしたらユーザーインタビューとかで裏付けをしてきてくれたりしてた。
それとリリースした後に、その「嬉しさ」をどうやって計測するか、も書いてある。別に想定通りになる必要はないけど、僕らが作ったものがどういう数字に貢献できる想定なのかは知っておきたい。
僕は、ユビキタス言語を書くようにしてる。「あのCSVのレポート」とか「あのエクセルの帳票」とか「class Report」とか喋る人によって違う言葉で表現するんじゃなくて「日次販売レポート（class DailySalesReport）」みたいに名前をつけておいてあげることで、認識のずれや見落としに気づきやすくなるから。
このFD(Feature Definition)がReady(開発に着手できるよう)になったら、それをスプリントに放り込んで開発チームが開発を始める。その時点では仕様書として完成していなくて良い。スプリントの中でペアワークをしながらブラッシュアップして完成させていく。
### ダブルペアワーク
FDを元にして、テストペアと開発ペアに分かれて作業をするのが好き。
テストペアは、FDを元にユースケースレベルのテストを設計・実装する。自動テストもマニュアルテストもある。この「テストを設計する」ということでFDに対して「この場合はどうなるのが正解か？」という疑問がでてくるので、それを潰していくことでFDがブラッシュアップされていく。
特に、まだ慣れていないプロダクトオーナーの場合、ユーザーが想定外の操作をしたときの異常系の考慮が漏れている場合が多いので、その辺りを話し合って決めていくことになる。
開発ペアは、FDを元に実装をしていく。こちらでももちろんFDがブラッシュアップされる。Unit Testはこちらのペアが実装する。
この2つのペアに分かれて開発を進めることで、思い込みによる見落としやバグを減らすことができるのと、「その仕様書から（実装を担当していなくても）テストを設計することができる」というレベルの情報が記載されることになるので、外から見える仕様がより明確に記載されることになって良い。
### プロジェクトドキュメント
そんな風にして開発を進めて、スプリントが終わる頃にはインクリメントのリリースができていて、プロジェクトドキュメントが完成している。そのプロジェクトドキュメントをマスタードキュメントにマージすることで開発が完了する。
Release Approvalは「リリースする際には、こういう観点のチェックはしておきましょう」というプロジェクトのDoneの定義みたいなもの。
Risk Registerは「リスクをどうハンドリングすることにしたか」というリスト。このリリースが失敗したらすぐに戻せるように手順を用意しておく、という開発的なものから、例えばユースケースレベルの「今回のユーザーAにとって使いやすい機能をリリースすると、別のユーザーBにとっては使いにくいものになる可能性がある」というリスクに対して「ユーザーAをメインターゲットとするのでこのリスクは許容する」とプロダクトオーナーチームで決断して進めるものまである。
### マスタードキュメント
プロジェクトを重ねた結果、いまシステムはどういう仕様で動いているのか、また、どういうテストを実施すればリグレッションがないと言えるか、を記載しているドキュメント。サービス運用のために必要なドキュメント。
マスタードキュメントとして大切なのは、全体としての読みやすさ、サービス運用に必要な情報が揃っていること、そして、メンテナンスし続けることができるように最低限の情報になっていること。
よく言われるのが「マージが大変だし、マスタードキュメントを直接更新すれば良くない？」ってことなんだけど、プロジェクトドキュメントは「体裁にこだわらずに気軽にメモを取り続ける」ということが大切だと考えている。
最初からマスタードキュメントを更新していると、マスタードキュメントが読みにくいものになってしまうか、またはプロジェクト中に体裁を整えることに時間を使ってしまうことになる。プロジェクト中は方針が二転三転することが多いのでその都度体裁を整えていたら時間がムダになる。
今日はここまで。
