この記事で話したい「問題を早期に発見するScrum」とは

わたしスクラムマスターやっていたりアジャイルコーチやってたりします。

Scrumは非常に色々な面をもっていますので色々な語られ方をしますが、今回は「問題を早期に発見するためのフレームワーク」という面についてそのノウハウとともに紹介したいと思います。

わたし自身Scrumの本質は「問題発見」にあると思っているのでちょっと思い入れが強いです

Scrumとは？ちょっとだけ説明

モノづくりのための手法です。そしてモノづくりをうまく進めるために「問題を早期に発見するためのフレームワーク」と言えます。

勘違いされていそうですが「速くなる・生産性が上がる」「価値あるプロダクトになる」「チームビルディングができる」みたいなのはScrumの結果直接的に必ず得られるものではないです。

Scrumはあくまで「問題を発見」するためのフレームワークです。

ここで誤解のないように言いますが……Scrum は「価値の高いプロダクトを作る」ことも「生産的な開発」も目的としてあります。ただ Scrum という手法の中で「どうやって価値を高めるか？」「生産性を上げるか？」というやり方にはほぼ触れていません。そういう問題のほとんどがドメイン特有の問題であってベストプラクティスとして語れないからだと思います。逆にどのドメインでも使える共通のノウハウは Scrum としてきちんと語られていると思います。

もう1つ補足です…… 手法を変えたからって急に価値や生産性が上がったり開発速度が上がるなんてありえません。ウォーターフォールでもScrumでもやるべきことの総和に差はなく、要件定義も設計も必要ですしコーディングもテストも必要です。手法を変えるだけで人のスキルが急に変わるなんて普通に考えてあり得ないです。過度な期待はやめましょう。

ただ、結果的にそういう効果がでる可能性は高いので大丈夫です。

なぜかというと「問題に気づく」ことによって（善意ある開発者であれば）必然的に改善を繰り返していくことになりプロダクトの価値は自然に上がりますし、「問題に気づく」ためにはいわゆる心理的安全性の高い問題を共有しあえるチームビルディングも必要になってきます。

結果的にそういう効果はついてきます。

Product Backlog づくりのノウハウ

Product Backlog とは

Product Backlog List（PBL）は Product Backlog Item（PBI）が優先度順にならんだものです。そして Scrum では優先度が高い PBI から作っていきユーザーへリリースし続けます。

ここで PBI は「価値」が出るような単位で作ることが大事です。そして可能な限り小さな単位で作ります。2 week Sprint であれば 1.5～3h くらいでおわるくらいのイメージです。

PBI は「価値」の単位で作る

「価値」が出せる PBI というものがどういう意味かというと「ユーザーが判断可能」「ユーザーに見せることができる」という意味に近いです。

例えば、ソフトウェア開発の場合で「開発環境を作る」という PBI はあまり良くないと言われます。それよりはどれだけ些細で小さなものだったとしても、「ボタン」「マニュアル」を作るという方が良いです。これは何かしらの価値をユーザーに届けます。

なぜ「価値」の単位で作るか

ではなぜ「開発環境」はだめで「ボタン」「マニュアル」だといいのでしょう。それは PBI として「価値」を提供することによってユーザーがその価値を判断できるからです。ユーザーは開発環境の判断はできませんが、自分たちが使うボタンやマニュアルの良し悪しは少なからず判断できます。判断が出来るということは「問題があったら気付くことが出来る」ということです。 Scrumの「問題を早期に発見する」ための仕掛けの１つです。

ここも補足です。「ボタン」「マニュアル」では価値がないと考える場合もありますし、PBI は「ユーザーストーリー」で作るべきともいわれます。それはそれで正しいとは思います。でも普通にイメージされるユーザーストーリー「ログインしてピザの注文ができる」みたいなものは実際問題大きすぎる PBI であり作業できません、大きすぎて計画が立てられません。

とは言えもう１つ補足です…… 「ログインしてピザの注文ができる」というユーザーストーリーでも良い場合もあります。それはチームがかなり育ってきた場合です。それくらいの大きな粒度であっても作業可能、計画可能、見積もり可能なチームに育っていれば粒度は荒くなっても大丈夫です。

PBI につきものの Acceptance Criteria（A.C.）についてです。 PBI には A.C. を書きます。 A.C. とは何をやったらその PBI が完成したと言えるかという評価項目です。A.C. はかなり明確に細かく書かないといけません。 A.C. に書いてあることさえ守れば他はどうでもよいです。例えば「1+1が2であること」という A.C. なら「1+1=2」さえ出来ればよく「1+2=3」が出来なくてもよいことになります。A.C. というのはそれくらい明確で大事なものです。A.C. を明確に厳密にすることで「完成したか／していないか」がはっきりします。 8割できましたということはあり得ません。 Scrum の世界で出来るということは、0% か 100% かです。なぜここにこだわるかというと、問題があるのか／ないのか、をはっきりさせるためです。何となくできているというような状態は許されません。

ついでにちょっとだけ Sprint Planning の話

Sprint の最初には Sprint Planning をします。ここで PBL の優先度の高いモノから順にみていき、
・この Sprint で出来るもの（届けられる価値）は何か？
・それをどうやって作っていくか？
を考えます。

そしてこの Planning ではかなり細かいところまで How を作り込みます。イメージで言えば、どのファイルをいじるか、変数名を何にするか、と言うくらいです。そのくらいまで話し込むことでこの後の作業が楽になります。なにも考えずに一気に作り上げることができるくらいませここで徹底的に設計します。

どうしてそんなに徹底的に話し合うのでしょうか。それは、この Planning 中に問題点や疑問点を出し切るためです。そして Planning には PO が参加しているor 連絡可能です。なので Planning 最中に細かな質問がでたらすぐそこで PO に聞くことができます。これも問題を早くに発見して解決に導くための仕掛けの１つです。

さらについでに Sprint の話

Planning でやることが決まっているので、Sprint では精一杯その計画された作業を行います。ただただそれだけです。

Sprint の最中には Daily Scrum が行われます。ここでは一般的には昨日やったことと今日やること等が話されます。もし問題があったらここで問題を話します。もうお気づきと思いますがここでもデイリーレベルでの「問題の発見」に努めます。

そして Sprint Review の話

Review では、Sprint の成果物が A.C. を満たしているかを判断します。満たしているか、満たしていないか、に気付くことが出来ます。満たしていなければそれは開発側の問題です。チームの生産性や見積もり精度や PBI の粒度という「問題」に目を向けます。

満たしていたとしても実際に完成したものを見てみると満足しない可能性もあります。それはそれで「問題」としてとらえ PBI を変えていきます。こういう「問題」に早くに気付くためにも最初に話した PBI が「価値」を単位に作られている必要性があります。

もし PBI が開発環境→インフラ→・・・という刻み方になっていたら、実際に作られるプロダクトに「問題」があるかどうかは最後の最後までユーザーにはわかりません。それではいわゆるウォーターフォールと同じです。早期に問題に気付くことはできません。

ということで

Scrum は「問題を早期に発見する」ためのフレームワークという意味が分かってくれたと思います。そのための仕掛けが多くいれられています。 Product Backlog という大きなレベルから Daily Scrum という小さなレベルまで、様々な工夫がはいっています。問題を早期に発見することで様々な改善が出来るようになるフレームワークです。

本当はもっとたくさん言いたいことありますが Qiita にそんなに長文書いても…… と省略しましたがエッセンスは伝えられたと思います。

それではよい Scrum Life を！！

補足

ちなみに以前に「アジャイル」についてまとめたQiitaはこちらです。これはこれでアジャイル開発についての大事な部分をまとめて書いたつもりです（手前味噌）のでぜひ読んでいただければと思います。