アジャイル開発にはたくさんの手法がありますが、その中の一つとしてスクラムがあります。スクラムはシンプルでルールを学ぶのは簡単です。しかし実際にやってみるとさまざまな課題が出てきます。

わたしたちも2017年からの取り組みの中で多くのアンチパターンを経験し、アジャイルの精神で改善を重ねてきました。この5年間取り組んできたスクラムについてのふりかえりと、課題にどう向き合ってきたかご紹介します。

スクラムとは

スクラムは「チームワーク」と「コミュニケーション」を重視し、チームで仕事を進めるための開発手法です。スクラムの公式ガイドである「スクラムガイド」は2010年に最初のバージョンが出され、それからさまざまな変更が加えられ2020年に最新版が出ています。

スクラムにおける3つの成果物

スクラムでは3つの成果物が定義されています。

プロダクトバックログ
プロダクトに必要な機能や改善の要望を一覧でまとめたものです。

スプリントバックログ
開発者がスプリントで⾏う作業を一覧でまとめたものです。

インクリメント
具体的な成果物です。

スクラムのやり方をいろいろと試すことはもちろん大切ですが、成果を出すためにはスクラムの価値基準を理解することがいちばんの近道だと感じています。

スクラムの定義

スクラムガイドにはこう記されています。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。

また、決まっているルールはこれだけです。

1. プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。
2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。
3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。
4. 繰り返す

スクラムはシンプルなフレームワークです。役割、イベント、成果物などその理論を実現するために必要な部分だけが定義されていて、具体的な手順やプロセスはチームに任されています。

だからこそスクラムの理論や価値基準を理解した上で実践していくことが大切になってきます。

スクラムの理論

スクラムは「経験主義」と「リーン思考」に基づいています。経験主義とは、知識は経験から⽣まれ、意思決定は観察に基づくという考え方です。複雑なものや不確実なものに対応するためには小さくすばやい実践と経験から学ぶことが重要です。また、リーン思考はムダを省いて本質に集中するという考え方です。

この考え方をもとにスクラムの柱として「透明性」「検査」「適応」があげられています。

透明性
プロセスや作業を見える化することで意思決定の判断が正しいものになるようにします。スクラムではプロダクトバックログ、スプリントバックログ、インクリメント（具体的な成果物）の3つの成果物が定義されています。プロダクトバックログの優先順をどのように決めるのか、スプリントバックログの進捗状況はどうなっているのか、インクリメントは期待したものになっているのか、透明性を高めることでそれぞれの成果物が正しい価値をもちます。

検査
よくない変化や問題を検知するために、進捗や成果物を検査します。スクラムで定義されているスプリント計画、デイリースクラム、スプリントレビュー、ふりかえりの4つのイベントによってスプリントごと、あるいは毎日のタイミングで見返しがされます。

適応
検査によって見つかったよくない変化や問題にすぐに適応します。デイリースクラムで問題が見つかればそのスプリントで対応する。ふりかえりで課題があがったら次のスプリントで改善する。こうしてすぐに適応することで無駄を最小限に抑えます。

スクラムの価値基準

スクラムが成功するかどうかは、つぎの価値基準を実践できるかどうかにかかっています。

• ゴールを達成し、お互いにサポートすることを確約する
• ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する
• スクラムチームとステークホルダーは、作業や課題を公開する
• お互いに能⼒のある独⽴した個⼈として尊敬し、同じように尊敬される
• 正しいことをする勇気や困難な問題に取り組む勇気を持つ

これらの価値基準からもわかるように、スクラムは「チームワーク」と「コミュニケーション」を重視しチームで成果を出すことを大切にしています。

アンチパターン１：ゴールの達成が確約されていない

ウォーターフォール開発からスクラム開発になってしばらくのあいだ「今まであった納品や検収が無くなった！できたものからリリースすればいいわけだし、これで自分たちの好きにできる！」と思っていた時期があります。ここでの”しばらくのあいだ”は結構長い期間だったので、あらゆる方面に申し訳ないことをした思いでいっぱいなのですが、スクラムは別に”好きにできる“わけではなく”自分たちで決められる“だけなのです。

ゴールの達成が確約されてないのであればスプリントで区切る意味がなくなってしまいます。開発に1年かけてもまだリリースできるものがない、いつ完成するかもわからない、いまさらやめることもできない。顧客にとって価値のあるプロダクトを素早く継続的に提供するためにスクラム開発にしたはずなのに何かがおかしい、と気づきます。

“しばらくのあいだ”をかけて学んだわたしたちは、最初はどんなに小さなゴールでもいいので達成することをめざすことにしました。達成できないのであればそれはまだゴールが大きすぎるため次のスプリントではゴールをさらに小さくする、あるいはそのゴールをめざすことをやめる判断をするようにしました。

そして今は「いつまでにここをめざしたい」という目標から逆算してスプリントのゴールを決めるようにしています。

アンチパターン２：スプリント外の作業が発生する

調査依頼や優先的にこの作業をお願いしたいといったスプリント以外の作業が発生することがあります。開発メンバーに直接依頼が発生しないようにすることはもちろんですが、プロダクトオーナーやスクラムマスターはスプリントの進捗を妨げるものに対応する必要があります。

ビジネス上のインパクトから優先的に対応するのであればスプリントバックログを見直すようにしています。そうでなければ次のスプリントで作業時間を確保したり、場合によっては対応しないことを理解してもらっています。

以前はスプリント外の作業は絶対に排除すべき！と思っていました。しかし今では柔軟に対応することこそがアジャイルだと考えるようになりました。スプリントバックログ以外の作業が多くなってしまうとスクラムの意味がなくなるのでバランスには注意していますが、スプリントを守るよりも大事なのは顧客にとって価値のあるプロダクトを素早く継続的に提供することです。

アンチパターン３：いちど始めたらやめられない

始めたことをやめる判断をするのは難しいものです。もう少しやれば解決するかも。やると決まったことだから時間がかかっても最後までやりとげたい。誰しもそのような思いをかかえていると思います。しかし、撤退すべきと判断したときにはその勇気を持つことも強さです。

例えば1ヶ月以内でMVP（Minimum Viable Product）を作成する。無理であればペンディングする。のように撤退ラインを先に決めておくことで判断に迷うことがなくなります。

スクラムチームと3 つの役割

スクラムチームには「プロダクトオーナー」「スクラムマスター」「開発メンバー」の3つの役割があります。誰が何を、いつ、どのように行うかチーム内で決定する権限を持つことで、自走するチームをつくります。

プロダクトオーナー
作成するプロダクトの責任者。ステークホルダーもプロダクトオーナーの決定を尊重することでプロダクトオーナーが正しく責任を持てます。

スクラムマスター
プロジェクトを円滑に進めるための調整役。スプリントの進捗を妨げる障害を取り除くなど、さまざまなかたちでプロダクトオーナーと開発メンバーを支援します。

開発メンバー
実際に開発を行うメンバー。成果物に対して責任を持ちます。

スクラムにおける役割は責任の範囲と役割の違いであり、お互いに対等な立場だと考えています。

アンチパターン４：スクラムマスターがマスターすぎる

スクラム導入時にはスクラムマスターがチームメンバーをオンボーディングします。しかしスクラムマスターがマスターすぎると次第にメンバーの自発性が失われていきます。スクラムマスターはメンバーが自走できるように引っ張っていくポジションから支援するポジションに変わる必要があります。

デイリースクラムなどイベントの進行役をバトンタッチする、スプリントバックログの作成を任せるなど時期を見て権限を渡すようにしています。

スクラムにおける4つのイベント

スプリント計画
直近のスプリントだけ工数を見積もり、タスクを確定します。

デイリースクラム（朝会）
プロジェクトの状況や進め方に問題がないか、メンバー同士で毎日確認します。

スプリントレビュー
ステークホルダーにスプリントの成果を示し、今後について話し合いをします。

ふりかえり（スプリントレトロスペクティブ）
KPTAなどを利用してふりかえりを行います。

アンチパターン５：スプリントが長すぎる

スプリントは1週間がおすすめです。1年は53週です。つまり1週間のスプリントだと1年で53回のチャレンジができます。しかし2週間のスプリントだとその半分しかスプリントを回せません。2週間のスプリントで1週目の終わりに課題に感じることがあっても、翌週におこなわれるふりかえりの時まで持ち越してしまうと改善のスピードが落ちてしまいます。すばやく判断をしていくためにも、スプリントは1週間がおすすめです。

アンチパターン６：プランニングポーカーめっちゃ時間かかる問題

スプリント計画で工数を見積もりますが、そもそも正確に見積もることに時間をかけてもあまり意味がないと考えています。そのため、1,3,5のいずれかで見積もるようにしています。「Tシャツ見積もり」とも言われる方法ですね。

わたしたちはいままで100人以上の学生インターンをエンジニアとして受け入れてきました。学生のメンバーが週10時間の勤務でも成果を出せるようにしくみを作ってきました。その結果たどりついたのが1,3,5の数字です。

インターンのシフトを1日3コマに区切り、その1コマ分で完了するボリュームを「1」としています。「3」であれば1日で終わる作業ボリューム、「5」であれば2日以内に完了する作業量です。もしもそれ以上に大きいタスクがあれば、このサイズに収まるように細分化をします。

以前は一つの大きいチケットを複数人で引き継いで担当していました。ただインターン同士だとシフトが異なり直接顔を合わせずに引き継ぎをするケースが多く、どうしてもコミュニケーションコストがかかっていました。

作業量を細分化することで週10時間のコミットでも確実に成果が出るようになりました。どのタスクでも最大2日なので、3日目に突入しようとしたタイミングでタスクを分ける、ペンディングするなどの判断ができます。

また、1,3,5のボリュームであればメンバー同士での見積もりのズレも起きにくくなるため、全員が集まってプランニングポーカーをする必要がなくなりました。今はひとりが工数を出したものを他のメンバーがチェックする程度にとどめています。

アンチパターン７：スプリントレビューの準備に時間がかかる

自社サービスの開発のためリリースする機能や時期をスクラムチーム内でコントロールすることが多く、ステークホルダーがほぼいないので定期的なスプリントレビューは行っていません。それでも大きめの機能をリリースする前にはビジネスサイドのメンバーに説明・確認の時間を設けることがあります。

成果物を確認してもらうための準備に時間がかかってしまうようでは本末転倒なので、CI/CDの環境を整えています。早めにCI/CDの整備をしてリリースまでのフローを作っておくことでリリース直前になって発覚しがちな問題を早めに解消しておくことができます。

アンチパターン８：イベントによって開発の時間が短くなる

1週間のスプリントだとイベントが占める時間が多くなりがちです。次に紹介するやり方でふりかえりを効率的に進めています。ふりかえりにはKPTAをつかっています。K（Keep）、P（Problem）、T（Try）はふりかえりの時間までに各自が出しておくようにしています。ふりかえりは”決める場”のため、KPTのなかで次のスプリントでやるA（Action）を決めています。

スクラム開発のメリット

ウォーターフォール開発→カンバン→スクラムと経験してきましたが、スクラム開発にはこのようなメリットがあります。

短い期間で最大限の成果をあげる
定期的な振り返りで、優先順位の高い機能から順に開発できるので、限られた時間で成果を出すことができます。カンバンは継続的なフローの中で改善を行いますが、定期的な見直しがないため数週間経過しても進行中の作業が変わらないまま、ということも発生してしまいます。その点スクラムはスプリントという決められた期間の中で成果をあげるしくみがあります。

早めに軌道修正ができる
短期間でリリースすることで、プロダクトがマーケットにフィットしているかを最短で検証できます。スプリントごとに軌道修正ができるので、方向転換や撤退の判断も素早くできます。

自立的なチーム作りができる
目標をチームで共有しながらタスクを進められます。自分たちでスプリントごとの目標を決めることで、目標を達成するための障害を取り除くためにはどうしたらいいか、より良いチームにするためにはどうしたらいいか考える自立的なチームに成長します。