この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。
第6回目のテーマは、世界で大人気のフレームワーク「スクラム」です。
この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編」の内容を元にしています。
シンプルなフレームワーク「スクラム」
現在、もっとも有名な開発手法であるスクラムを解説します。スクラムは日本人の書いた論文をヒントに作られたフレームワークです。アメリカで体系化され、世界に広がり、日本に戻ってきました。
スクラムはとてもシンプルなフレームワークです。よって、改善を行うときは「シンプルかどうか」を忘れずにチェックすると良いと思います。そうしなければ、せっかくの軽量級フレームワークも、いつのまにか重量級フレームワークになってしまい、アジリティ（俊敏さ）が失われてしまうでしょう。
スクラムはスクラムガイドというガイドラインが公開されています。アジャイル開発らしく分厚いドキュメントではありません。2020年11月現在のガイドだとわずか18ページです。スクラムはシンプルであることが有名ですが、ガイドもシンプルになっています。
逆に言うと、細かい解説のない書き方になっているとも言えるので、読み解くのが難しい人もいるでしょう。たとえば、スクラムを解説する本は、どれも18ページ以上の本ばかりなのが、シンプルさが生み出す難しさを表しています。
スクラムはシンプルですが、いくつもの分厚いスクラムの解説本が発売されているように、シンプルすぎてわかりにくい、解釈に困る、習得が難しい部分があります。この記事ではできるだけそうならないようにガイドできればと思っています。
ただ、スクラムやスクラムガイドがシンプルなのは、自分たちで考えてプラクティスを選ばせるためでもあることを覚えておくと良いでしょう。
スクラムガイドは、スクラムを理解するのにとてもいいドキュメントです。ただ、「スクラムガイドに書いてあるから」や「スクラムガイドに書いていないから」と解説する人がたまにいますが、書いてあるかどうかが重要ではありません。盲目的にガイドを受け入れすぎないように注意したほうがいいでしょう。
スクラムガイドは、時代に応じてどんどん更新されるドキュメントです。このセクションでは、2020年11月バージョンのスクラムガイドをもとに解説を行っていきます。
スクラムの三本柱
透明性、検査、適応はスクラムの三本柱と呼ばれています。
- 透明性： プロセスや作業、成果物を見えるようにしましょうということです。透明性なくして次の検査は実現できません。
- 検査： 見えるようになったものを頻繁かつ熱心に検査します。検査によって、次の適用が実現できます。
- 適応： いわゆる調整です。検査して理想と現実にギャップがあれば、調整して本来あるべき方向に調整していきます。
これらは後述するスクラムイベントの基盤になっています。
スクラムイベント
スクラムイベントとは、スクラムのサイクルの中で発生するMTGを指しています。スクラムでは以下のようなイベントを行います。
- スプリントプランニング： 短い期間内の計画を立てるイベント
- デイリースクラム： いわゆる朝礼
- スプリントレビュー： 作ったものを検査するイベント。いわゆる成果発表
- スプリントレトロスペクティブ： 自分たちを検査するイベント。いわゆるふりかえり
スクラムの流れを見ながら、スクラムイベントがどういった役割を持っているか見ていきましょう上記の図は、マウンテンゴート社が公開しているスクラムの全体図です。日本語訳が公開されていたのでこの図を使ってスクラムを使った仕事の流れを見ていきます。マウンテンゴート社は、『アジャイルな見積もりと計画づくり』の著者でも有名なマイクコーンさんのいる会社です。
まず、開発をはじめる前に、プロダクトバックログを作ります。プロダクトバックログは、いわゆる「やりたいことリスト」です。スクラムチームはプロダクトバックログを優先度順で開発し、リリースしていきます。開発やリリースが進むとプロダクトバックログが減っていくので、プロダクトバックログに責任を持つプロダクトオーナーは、プロダクトバックログを定期的にメンテナンス（増やしたり減らしたり磨いたり）していきます。
次に、スプリントプランニングで計画を立てます。スクラムはスプリントという短い開発期間を繰り返していきます。このスプリントに合わせた開発計画がスプリントバックログです。すでにやりたいことリストはプロダクトバックログとしてあるので、そこからスプリントでやれる量を選び、スプリントバックログを作成します。
やりたいことリスト（プロダクトバックログ）ができて、スプリントでやることリスト（スプリントバックログ）ができたので、いよいよスプリントを開始します。スプリントは通常2週間から4週間のサイクルです。図の中央にある大きな円を描く緑色の矢印がスプリントをさしています。
スプリントの中にもうひとつ小さい矢印があります。これがデイリースクラムミーティングのサイクルです。デイリースクラムはいわゆる朝礼のようなもので、日々の計画の確認や調整を行う場です。
スプリントで開発を進め、最終的にスプリントのおわりに、プロダクトをリリースします。図にはありませんが、リリース前にスプリントレビューで成果物を検査し、スプリントレトロスペクティブによってスプリントでの開発を検査します。
これがスクラムの流れです。
スクラムはスクラムチームでこの流れを繰り返していきます。みてのとおり、とてもシンプルな流れです。おそらく、部分的に自然にやっているチームも多いでしょう。
スクラムチーム
スクラムを行うチームをスクラムチームと呼びます。スクラムチームには、プロダクトオーナー（PO）、開発者、スクラムマスター（SM)がいます。
POは「プロダクトゴール」を決め、「やること」や「やる順番」を定義します。POだけでやることをきめられないのであれば、開発者などに相談しても問題ありません。あくまで、最終的な決定責任がPOにあるというだけです。従来型だと「要件に落とし込む人」に近い存在です。
組織が大きくなると、POがあつまるプロダクトオーナチームを作る場合もあります。
現在の人材市場を見ていると、POを仕事とする人が少ないので、一人のPOが複数チームをみるケースも多く見られます。
次に登場するのは、開発者です。開発者は開発を行います。スクラムガイドでは、フロントエンドエンジニア、バックエンドエンジニア・・・といったふうにこまかく分類されておらず、「開発者」とだけ定義されています。従来型だと「仕様を作り開発・テストする人」に近い存在です。
実際のスクラムチームは、チームだけで開発を完了させられる力が求められます。みなさんの現場で、フロントエンドとバックエンドが1名ずつ必要であれば、スクラムチームにはその2名を参加させる必要があります。
最後はスクラムマスターです。スクラムマスターはスクラムの理論やプラクティスを全員に理解してもらえるよう支援します。従来型だとプロジェクトマネージャーが近い存在です。
今回はスクラムの概要を解説しました。次回は、スクラムチームの責任に焦点を絞って解説を行います。
連載一覧
第1回：アジャイル開発の過去、現在、未来を知ろう！
第2回：声に出して読みたいアジャイルマニフェスト
第3回：従来型開発とアジャイル開発の違い その１
第4回：従来型開発とアジャイル開発の違い その２
第5回：アジャイル開発のよくある誤解を解いていこう！
第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発
第7回：わかるようでわかりにくいスクラムチームの責任
第8回：スクラムイベントの実践方法
第9回：エクストリーム・プログラミングとその価値
第10回：エクストリーム・プログラミングの原則と基礎プラクティス
第11回：エクストリーム・プログラミングの応用プラクティス
第12回：リーンソフトウェア開発
第13回：ソフトウェア開発における「かんばん」
第14回：さまざまな方法論 − リーンスタートアップ・DevOps
