スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた

スクラムは多くの開発現場で取り入れられており、その原則を学ぶのは簡単です。しかし原則を現実に実行しようとすると、さまざまな課題が……。アジャイルコーチの吉羽龍太郎さんにスクラムの基礎から、ありがちな課題への対処法をたっぷり聞きました。

スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた

アジャイル開発の実践手法として、多くの開発に取り入れられているスクラム。簡潔なルールを理解するだけで実践可能ですが、いざ取り入れようと思っても、考えてもみなかった課題に直面することも。本稿では、先の記事でスクラムのありがちトラブルとその解決を教えてくれた、アジャイルコーチの吉羽龍太郎さんが、 スクラムの基礎知識と原則を解説します。そしてスクラムマスターとしてこれからスクラムマスターを務める方に向け、プロジェクトを推進するために必要な、現実に即したスクラムの実践手法を聞きました。

吉羽龍太郎さん(よしば・りゅうたろう)1@ryuzee

2
株式会社アトラクタ取締役CTO/アジャイルコーチ。クラウドコンピューティング、DevOps、インフラ構築自動化、アジャイル開発、組織改革を中心にオンサイトでのコンサルティングとトレーニングを提供。Scrum Alliance認定チームコーチ(CTC) 青山学院大学非常勤講師(2017-)。主な著書・訳書に『レガシーコードからの脱却』『Effective DevOps』など。スクラムを学ぶうえでの良質なリファレンスとされる『SCRUM BOOT CAMP THE BOOK』は、2020年5月20日に増補改訂版がリリースされる予定だ。Webサイト:ryuzee.com

スクラムは軽量で理解が容易、だけど実際にやるのが難しい

──今日は、若いエンジニアの方々がスクラムマスターになるためのノウハウについてお伺いしたいと思います。まずはスクラムがどういうものなのか、教えてください。

吉羽 アジャイル開発にはカンバンやエクストリームプログラミング(XP)など、いろいろなやり方があり、その中の1つの手法がスクラムです。ある調査では、アジャイル開発に携わる人のうち、7割くらいが何らかの形でスクラムを使っていると回答しています。

──7割ですか、すごいですね。

吉羽 アジャイル開発をやるとなると、最初に選択肢に挙がるのがスクラム、と言えるほどに一般的な手法でしょう。では、スクラムってどんなものかというと、『スクラムガイド』というドキュメントで定義されています。ここには、こんなことが書かれています……「軽量・理解が容易・習得は困難」と。

『スクラムガイド』における定義そのものはコンパクトで決めごとはそんなに多くない。スクラムでは何が決められているかというと、役割が3つ、イベントが5つ、作るものが3つ。3・5・3、これだけなんです。

3

▲以降、吉羽さんによる詳解があるが、スクラムガイドで定められた、役割、イベント、作成物は上記サマリー資料の通り。拡大、ダウンロードなどして参照してほしい。

【スクラムの基礎知識】3つの役割を理解する

4

──3・5・3ですか。分かりやすくていいですね。「3つの役割」とはどんなものなんですか?

吉羽 プロダクトオーナー、開発チーム、スクラムマスター、これが3つの役割です。

まずプロダクトオーナーが何をするのかというと、プロダクト・製品の持ち主で、「自分たちがどのような製品を作るのか」をリードします。プロダクトを作ろうとすると、やりたいことはたくさん出てきますが、お金も時間も限られているので、全部はできません。なので、どれをやる・やらない、何を先にやるかといったことを誰かが決めないといけない。それを担うのがプロダクトオーナーの主たる役割です。

ときに、外部の方から製品に対してさまざまな注文が入ることもあるでしょう……。その人たちとあらかじめ調整をしておいたり、場合によっては指示・指摘に反論したりといった、ステークホルダーマネジメントもプロダクトオーナーの重要な仕事です。

──なるほど、次に登場する開発チームは……その名のとおり開発の担当ですよね。

吉羽 製品のWhat(なにを作るか)やWhy(なぜ作るのか)を扱うのがプロダクトオーナーの仕事とすると、このWhatを形にする、つまりHow(どう作るのか)が開発チームの役割です。一般的に3~9人で構成されることが多いですね。設計から開発、テスト、リリースまで、スクラムの場合はすべて1つのチームでやります。

──では、スクラムマスターはどのような役割を担っているのでしょうか?

吉羽 スクラムマスターは、“スクラム”の仕掛けがうまく回るように何でもやる人、開発のプロセスに対して責任を持つ人です。例えばスクラムをやり始めたばかりのチームだと、「スクラムってこういうものですよ」と教えるのも仕事になりますし、後述するイベント・会議をファシリテーションしてみたり、プロダクトオーナーと開発チームが対立したら仲裁してみたり……、と、スクラムをうまく回すために、一歩引いて、全体を見てあげるのがスクラムマスターです。

【スクラムの基礎知識】5つのイベントを理解する

──次は実際の進め方ですね。「5つのイベント」ではそれぞれ、どんなことをするんですか?

5

吉羽 イベントと表現すべきか難しいですが、1つ目のイベントとして定義されているのがスプリントです。アジャイル開発では1週間や2週間など、一定の時間で区切って開発を繰り返します。このひとつの開発期間をスプリントといいます。残りの4つのイベントは、全部スプリントの中に入ります。スプリントはコンテナのようなものなんです。

──スプリント内ではどんなイベントを実施するのですか?

吉羽 アジャイル開発ってよく「ひたすらコード書きまくるんでしょ?」とか「設計もしないんでしょ?」みたいに言われます(笑)。しかし、実際はスプリントをどう過ごすのか、きっちり計画を立てるんです。それが、スプリントの最初におこなうスプリントプランニングで、「今スプリントでは何をやるのか」「どうやるのか」といった話をします。

その後、開発に入りますが、「あとよろしくね」と任せっきりにするわけにもいきません。スプリントの最終日に、「実は全然できてません」となったらまずいですよね。なので、このまま進めて大丈夫なのかチェックするデイリースクラムを毎日おこないます。ゴールの達成が厳しい……と判断したら、軌道修正をしたりスコープ(やるべきことの範囲)を調整したりといった対処を取ります。

──毎日定点チェックをするわけですね。

吉羽 そうです。スプリントの最後の日には、スプリントの成果を確認するスプリントレビューが待っています。これはチームの中だけでレビューをするのではなくて、上司や営業担当といったステークホルダーを呼んで、スプリントの成果をレビューします。

なんのためにするのかというと、フィードバック受けるためです。気に入ったか・気に入らないか、もっとこうしたらいいんじゃないのとか、そもそも作ったものは利用者の問題を解決しているんだろうか……そういうようなことを議論します。

──最後、5つ目のイベントが残っています。

吉羽 スプリントの最後にやるのスプリントレトロスペクティブという、舌をかみそうな名前のイベントです(笑)。「振り返り」とも呼ばれますが、直近の期間を振り返って、自分たちのやり方がよかったのか悪かったのか、悪かったのならどこを改善すると次のスプリントをもっとうまく進められるのかといったことを話し合います。

【スクラムの基礎知識】3つの作成物を理解する

6

吉羽 残りの3つが「作成物」といわれているものです。これは「成果物」ではなくて「作成物」と呼ぶことに注意してください。

作成物でまず用意しないといけないのが、プロダクトバックログです。「これを作りたい」「あれは絶対にないとまずい」といった機能性の要求をまとめたもので、要は“やりたいことのリスト”です。重要なものから上から順に並んでいて、よくエクセルに表としてまとめていたりしますね。

いわゆるウォーターフォール型の開発だと、最初に要件定義をし、製品のゴールを決め、見積もりをして、発注するという形で進めます。一方、アジャイル開発の場合は、フィードバックをもらって、場合によっては途中でリリースするかもしれないし、製品のゴールが変わる可能性もある。ですから、初期のプロダクトバックログが、フィードバックや競合製品の影響で、「やっぱりあれもやろう」と項目を追加したり「これはいらない」と削除されたりもします。

──開発期間中、プロダクトバックログは常に変わっていくんですね。

吉羽 はい。そして、プロダクトバックログの中から“今回のスプリントで何をやるか”をスプリントプランニングで決めます。また、開発チームは抽出された項目を見て、具体的なタスクに分解します。ここで生まれた「このスプリントでやること」のリストが2つ目の作成物にあたるスプリントバックログです。 最後、3つ目の作成物はインクリメントです。これは分かりやすくて、プロダクト開発ならソフトウェアです。開発者の方はお分かりかと思いますが、インクリメントという言葉には“1増やす”という意味があります。時には「この機能はいらん!」と削除することもありますが……。

──スクラムで決められていることってこれくらいなんですね。たしかにこれは理解するのは簡単かもしれません。ただ、具体的にどうしたらいいの?という疑問も湧いてきます。

吉羽 そうでしょう。スクラムガイドには枠組みは書いてあっても、具体的な方法は書いてありません。スクラムガイド自体も、数年にごとに更改されていますが、「ちょっとHowっぽいよな」といった箇所は徐々に削られています。それだけに、実際にやろうとしたときに、「で、どうやるの?」といった疑問がついて回る。そこが難しいところなんです。

スクラムを“現実的に”実践する手法

見積もりは誰のもので、誰が作るのか

7

──では、スクラムを進める上での具体的なToDoについてお伺いしていきたいと思います。まずはプロダクトバックログと見積もりですよね。プロダクトバックログを作るのはプロダクトオーナーの仕事なのでしょうか?

吉羽 プロダクトバックログの最終責任者はプロダクトオーナーですが、見積もりの責任者は開発チームです。実際に開発をしない人が見積もった数字は、見積もり通りにはなりませんから。ですから、アジャイル開発では原則として、プロダクトの制作を担当する開発チームが見積もります。そして開発チームが出す見積もりに対して、プロダクトオーナーは原則的に口を出すことはできません。

──そうなんですね!

吉羽 もちろん、「ちょっと見積もりが大きすぎるんじゃない?」と相談することはできますが、「やり方は変えずに、その内容を半分の時間でやれ」といったことは言えない。開発チームは自分たちの能力に基づいて見積もっているので、尊重されないといけないんです。

ただ、「見積もりが大きすぎてビジネスの観点から無理がある」こともあるでしょう。そういうときはプロダクトオーナーと開発チームで相談して、別の手やなんらかのソリューションを考える必要があります。とにかく、理由もなく半分の時間でやってくれ、半分の金額でやってくれとなんてことを言ってはいけない。これが重要です。

フィボナッチ数列よりも「Tシャツ見積もり」。素早く見積もりを作る手法

8

──スクラムならではの見積もりの作り方はありますか?

吉羽 アジャイル開発では「経験主義」といって「やってないことは分からないし、将来のことは約束できない」という考え方が基本です。なので、開発中に何度も、スプリントごとに見積もります。

最初にプロダクトバックログを見ながら、各項目にどれくらいの時間がかかるかざっと見積もりを作って、だいたいの規模感を推定しますが、それはあくまで推定にすぎず、決して“約束”ではありません。で、何度かスプリントをやってみて、開発チームの力量や要素技術の使い方、過去の実績などの情報が増えてくれば、どんどん正確な見積もりに更新していけるわけです。

──毎スプリント、見積もりを見なおすって大変じゃありませんか?

吉羽 頭から最後まで全部見なおすのは大変なので、必要な箇所だけ見積もるのがポイントです。プロダクトバックログは上から順番に重要な項目が載っていて、逆に言うと、下のほうにあるのは優先度が低く、やるかどうかさえ分からない。

一方、上のほうにある項目は、次のスプリント、次の次のスプリントで取りかかるので、中身がある程度具体的になっていないと、すぐに「何やればいいんだっけ?」となてしまいます。そうならないように、バックログリファインメントという手入れを定期的に実施します。これは直近でやりそうな項目を重点的に見なおす活動で、中身を見なおしてみたり、項目が大きすぎる場合は分割したりします。バックログリファインメントのタイミングで見積もりも見なおすことが多いですね。

──見積もりにはやはり人月や人日といった数字を使うんですか?

吉羽 スクラムでは見積りに使う単位は決められていませんが、私は人月や人日といった数字は使いませんね。見る人によって、1人日がどのくらいのタスク消費量なのか解釈が異なる、いわば一人歩きしやすい指標だからです。それに、チームの成長を見込んだ数字でもありません。アジャイル開発は同じチームでずっとやるんで、同じタスクをやるにしても、最初のスプリントでかかった時間と、10スプリント後でかかる時間は違ってくるはずです。人日や人月にすると、そこって見えづらいんですよね。

──では、具体的にどういう数値を見積もりで使っていますか?

吉羽 チームが1スプリントで作れる量は「ベロシティ」というポイントで表します。プロダクトバックログの各項目の作業量をポイントで表して、その合計が全体の見積もりとなるわけです。

以前は1,2,3,5,8,13……といったフィボナッチ数列をよく使っていたんですが、最近ではそんなに細かくポイント設定しません。「Tシャツ見積もり」と言って、S,M,L,XLみたいな感じで、数パターンに分けてポイント換算する、そんな感じでラフにやることも増えていますね。

──タスクのサイズが4つしかないんですね。それで正確に見積もれるものなんですか?

吉羽 アジャイルの見積もりは、極端に言えば「どうせ外れるよね」という考え方です。だから見積もりに過剰に時間をかけても仕方がない。すばやく見積もって、新しい情報が入ったらもう一度見積もることが重要で、そのために素早く判断できるTシャツ見積もりを使っているんです。

──規模が大きくなればなるほど、誤差が大きくなるものですしね。

吉羽 あと見積もりで大事なのは、開発チームが作れそうかどうかを判断できるか、です。直近のスプリントで作るものは、開発チームのメンバーが見て「こうすれば作れる」というところまで、中身がきちんと理解できるかどうかが重要なんですよね。

──見積もりは、開発チームの中で担当者を決めて作ったりするものなんですか?

吉羽 僕は開発チームの全員でやるべきだと思っています。「ベテランじゃないと分からないから」といって属人的に進めたら、若手はタスクの中身がよく理解ができず、言われたとおりの作業をするしかなくなってしまいます。開発チーム全員の見積もり感覚を集約するのは、最初は大変ですけど、若手が理解できるようにしていくためにも、見積もりをみんなでやる必要はあると思います。

スプリントの期間は1週間が計画しやすくておすすめ

9

──見積もりが完了したら、スプリントに入って実際に開発をしていくわけですよね。スプリントには4つのイベントが含まれるというお話でしたが、それぞれのイベントにどれくらいの時間を配分すべきか、お教えいただいてもよろしいでしょうか?

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く