こんにちは！データサイエンティストの青木和也（https://twitter.com/kaizen_oni）です！
今回の記事では、スクラムについてさらっと学びたい方必見の1冊「スクラムチームではじめるアジャイル開発 SCRUM BOOT CAMP THE BOOK」を読んで、私が得た学びについてご紹介させていただきたいと思います。
本書はスクラム開発初心者の方に読みやすいように、マンガ形式を織り交ぜながら、アジャイル開発の概要と実際のスクラムでどのような困り事が発生し、それらに対してスクラムという開発手法の観点からどのように対応していけばいいのかについてまとめられた1冊になります。
本記事を読んで、アジャイル開発を実践する方にせよ、アジャイル開発ではないスタイルで開発をする方にせよ、本書からどのような学びが得られるのかのイメージをつけていただけると幸いです！
本書の概要
本書は「スクラムチームを組んでアジャイル開発を進める方法」をマンガ形式を織り交ぜながら学ぶことができる、アジャイル開発の概要をさらっと把握するのに適した1冊です。
一方で、アジャイル開発をフレームワークとしてしっかりと把握する目的には、本書はアジャイル開発の内容が書籍内に散りばめられた構造になっているため適しておりません。
あくまで本書はアジャイル開発を学ぶためのとっかかりとして読み、「プロジェクト進行における困りごとにスクラムチームでそうやって対処していくのか」というざっくりとしたケーススタディを学んでいただくのに適していると考えています。
アジャイル開発とは？
本書では、アジャイル開発とは以下のようなものであると例示しています。
西村直人/永瀬美穂/吉羽龍太郎『SCRUM BOOT CAMP THE BOOK』(翔泳社/2014) 基礎編 | はじめに P21
- 関係者は目的の達成のためにお互いに協力し合いながら進める
- 利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する
- 一度にまとめてではなく、少しずつつくる。そして実際に出来上がったものが求めているものと合っているかを頻繁に確認する
Scrumとは？
本書では、スクラムについて以下のように定義しています。
Scrumは、説明した通り、アジャイル開発手法の1つです。常に進む方向を調整しながら目的を達成できるプロダクトをつくるために、全員が一丸となって行うべき作業、会議、成果物を定めたものです。
Scrumには以下の特徴があります。
西村直人/永瀬美穂/吉羽龍太郎『SCRUM BOOT CAMP THE BOOK』(翔泳社/2014) 基礎編 | はじめに P22
- 要求を常に順番に並び替えて、その順にプロダクトをつくることで成果を最大化します。
- Scrumでは実現される価値やリスクや必要性を基準にします。
固定の短い時間を区切って、作業を進めます。この期間のことをタイムボックスと呼びます。- 現在の状況や問題点を常に明らかにします。これを透明性と呼びます。
- 定期的に進捗状況やつくっているプロダクトが正しいのか、仕事の進め方に問題がないかどうかを確認します。これを検査と呼びます。
- やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変えます。これを適応と呼びます。
本書の章立ては以下のとおりです。
- 基礎編
- Scrumってなに？
- 実践編
- プロジェクト概要と人物紹介
- ロールを現場に当てはめる
- プロジェクトを理解する
- プロダクトバックログをつくる
- 見積もりをしていく
- 見積もりをより確実にする
- プロジェクトの計画を立てる
- 詳細な計画を立てる
- 素早くリスクに対処する
- 何が終わったか明確にする
- 状況をうまく把握する
- 先を予測しやすくしておく
- 次にやることを明確にする
- みんなの自律を促していく
- ベロシティを上げていく
- 問題を見つけやすくする
- 意図を明確にしておく
- プロジェクトを支援していく
- より良い状態にしていく
- 先のことをいつも明確にする
- 手戻りをなくしていく
- あふれそうなものを調整する
- さまざまな状況に対応する
- より確実に判断をしていく
- リリースに必要なことをする
- 実践編で伝えたかったこと
本書から得た学び
私が本書を読んだ動機は、現在参画している現場でDaily Scrumと称した朝会をやっているものの、あまり体系だった形で実践できていない気がしたので、「スクラムってこんな感じだっけ？」という確認をしたかったからです。
本書を読んで、アジャイル開発の中のScrumの手法について学ぶことはもちろん、たとえScrum的な開発でないとしても応用できそうないくつかのTipsに出会うことができました。
- 実装が終わったかどうかの判断にはデモが最適
- 「完了の定義」を事前にして決めておくことでPO（プロダクトオーナー）と開発チームの齟齬を防ぐ
- ユーザーストーリーを使うことでPOと開発チームの齟齬を防ぐ
順に解説していきます。
実装が終わったかどうかの判断にはデモが最適
終わったかどうかを判断するのに、終わったという報告を鵜呑みにするわけにはいかない。報告は人によって認識がバラバラだからだ。そのために、実際にできあがったものをデモをして、実際に目で見て判断しないといけない。
西村直人/永瀬美穂/吉羽龍太郎『SCRUM BOOT CAMP THE BOOK』(翔泳社/2014) Scrum9 何が終わったか明確にする P131
これについては、新人エンジニアとベテランエンジニアの「タスクが終わりました」をイメージしていただけると分かりやすいかもしれません。
新人エンジニアの「タスクが終わりました！」は、ただ単にコードを全て書き終えたことを意味するかもしれません。
一方でベテランエンジニアの「タスクが終わりました」は、コードを書き終えたことはもちろんのこと、そのコードがさまざまなテストケースにおいて正常に機能するかテストし、テストエビデンスをドキュメントとしてまとめ、プロダクトオーナー（以下PO）のレビューを経た状態のことを「終わった」と表しているかもしれません。
このように、「終わった」という言葉に対して経験年数に応じて認識の違いが生まれる以上、確実に終わったかどうかを確かめる方法は、実際に実物を見てみるしかありません。
つまり、「デモを確認するまでは終わったとは言えない」というのが本文中の趣旨です。
そして、ここから先さらに確認が必要なことは「デモでどこまでの動作を確認できたら終わりと言えるのか」というデモの質に関わる部分です。
たとえば、正常パターンで動くことまでがデモの範囲なのか、ある程度の網羅性のあるテストケースまで動かしてみるのがデモの範囲なのか、ということです。
ここは開発しているプロダクトとプロダクトの目的によるところなので、ケースバイケースですが、このようなデモの質についてもある程度合意しておくことが手戻りを最小にする方法なのかな、と本書を読んで考えました。
「完了の定義」を事前にして決めておくことでPO（プロダクトオーナー）と開発チームの齟齬を防ぐ
中身についても終わったと判断できるようにしておく。それが完了の定義と呼ばれているもので、たとえばこういうものだ。
西村直人/永瀬美穂/吉羽龍太郎『SCRUM BOOT CAMP THE BOOK』(翔泳社/2014) Scrum9 何が終わったか明確にする P133
- デモ手順の通りに動作する
- publicメソッドのテストコードがある
- 調査した内容はWikiにまとめてある
- 最新の仕様がWikiにまとめてある
- リポジトリからいつでも最新のでも可能でテスト済みのソフトウェアが取得できる
先ほどのデモの終了基準の少し外側の話ですが、タスクの完了基準ということを事前に決めておくことが重要である、という示唆を与えてくれる一節です。
本節を読んで、完了基準を決めておくことは、PO側も開発側もどちらも怪我しないために重要だなと感じました。
PO側にとっては、開発側が「完了した」として報告してきたものがこちらの要求を満たさない水準までしか出来上がっていなかった場合に、「その要件って、ちゃんとこっち（=開発側）に伝えてくれてました？」という責任転嫁を防ぐ働きがあります。
一方で、開発側にとっては、POに開発完了と報告したにもかかわらず、完了基準が明確になっていなかったために、「これって社内説明用のプレゼン資料まで作ってくれるんだよね？」という元々要件に含まれていなかったところまでも要求されてしまうことを防ぐ働きがあります。
こうして、完了基準を設けることによって、しっかり終わることを保証し、ずるずるとプロジェクトが長引くことを防ぐのです。
ユーザーストーリーを使うことでPOと開発チームの齟齬を防ぐ
実現したいことを実際に使う人たちを軸にして伝えてみよう。そのための工夫がユーザーストーリーというものだ。実際に使う人たちの視点で機能を簡潔に記述したもので、こんなふうなフォーマットで書かれることが多い。
西村直人/永瀬美穂/吉羽龍太郎『SCRUM BOOT CAMP THE BOOK』(翔泳社/2014) Scrum16 うまく伝わってるのかな？ P188〈どういったユーザーや顧客〉として
〈どんな機能や性能〉がほしい
それは〈どんなことが達成したい〉ためだ
上記のユーザーストーリーはPO側と開発側の責任範囲の違いによる乖離を防いでくれる働きがあります。
PO側は「プロダクトがユーザーにとって有用なものになっているか」に対して責任を追うので、1つ目のユーザーに対する解像度が高く、3つ目のプロダクトの活用場面・目的についても十分な理解をしている一方、目的を実現する手段・実装方法については多くを知りません。
一方で、開発側は注文された要望に対する解としての実装方法・達成方法については専門的な知識を有しているかもしれませんが、技術的な方面に思考が特化しているが故に、注文された要望の裏側にある目的をブレることなく念頭に置き続けることが難しいかもしれません。
上記のように立場の違いによって、開発側から提示された解決策が、PO側の想定している目的を達成しないようなパターンが多々発生してしまうかもしれません。
そのような状況に対する特効薬が、〈ユーザー〉〈方法〉〈目的〉を盛り込んだユーザーストーリーなのです。
このユーザーストーリーをプロダクトバックログにも書き込むことによって、デモ手順（=完了条件の一部）やデモを充足した機能の実装にかかる工数についてもよりイメージがつきやすくなってきます。
まとめ
今回の記事では、スクラムについてさらっと学びたい方必見の1冊「スクラムチームではじめるアジャイル開発 SCRUM BOOT CAMP THE BOOK」を読んで、私が得た学びについてご紹介させていただき舞した！
Scrumという手法については本書に譲るため、本記事ではアジャイル開発に限らない、開発を円滑に進めるために私が重要だなと思った項目についていくつかピックアップをしてみました。
本書はアジャイル開発の本としてはかなりラフで読み進めるのが容易なため、
「これからアジャイル開発でやってみたいけど、そもそもアジャイル開発が何か分からない」
「アジャイルとスクラムという言葉の違いも分からない」
「本格的にアジャイル開発をするのは当分先だが、先に情報としてえアジャイル開発というのはどういうものなのか概観を知りたい」
という方におすすめの本です。
ぜひ皆さんもアジャイルについてふわっと学びたい時は本書を読んでみてください！
コメント