はじめに
ソフトウェアを作るのは簡単ではありません。
最初にどんなものを作るかをきちんと考えて作り始めても、いざ進めてみると途中でほしいものが変わったり、さまざまな要望が出たりします。
ソフトウェアを作るのに時間がかかりすぎてそれ自体に意味がなくなってしまったり、たくさんお金がかかってしまったり、なんとか完成させても実際に手にしてみたらほしいものとは違っていたり、といったことが起こります。
ソフトウェアを作るうえで本当に重要なことは何でしょうか？ それは、できあがったソフトウェアを実際に活用することで顧客や利用者の課題を解決したり、お金を稼いだりする、つまり成果を上げることです。
ソフトウェアを作ること自体は目的ではなく、成果を上げるための手段なのです。したがって、何のために作るのかを明らかにし、現在作っているものが本当に成果を実現できているのかを小まめに確認しながら進めていくことが必要です。
その過程で当初作ろうと思っていたものよりも良いアイデアが出てくれば、それを受け入れ、作るものを変えていきます。そうすることで成果が最大化していきます。
アジャイル開発とは？
では、目的を達成し、成果を最大化するためには、どう進めればよいのでしょうか。それは次のような進め方です。
- 関係者は目的の達成のためにお互いに協力し合いながら進める
- 一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届け続けて評価を繰り返す
- 利用者の反応や関係者からのフィードバックを継続的に得ながら、作っているもの自体や計画を調整する
このような進め方をアジャイル開発と呼びます。
アジャイル開発という単語が生まれたのは2001年です。従来の重厚な開発プロセスの問題点を解決するために、もっと軽量なやり方ができないのか試行錯誤していた人たちがさまざまな議論を行った結果、自分たちの根底にある考えには多くの共通点があることに合意し、アジャイルソフトウェア開発宣言を示したのが始まりです。
つまりアジャイル開発とは何か単一の開発手法を指すものではなく、似たような開発手法に共通した価値観と行動原則に名前がついたものであり、それを体現するさまざまな手法があるということです。主な手法にスクラム、エクストリーム・プログラミング（XP）、カンバンがあります。
これらさまざまなアジャイル開発手法に共通するのは、「事前にすべてを正確に予測し、計画することはできない」ということを前提にしている点です。従来の開発手法では、あらかじめすべての要求を集め、すべてを作るためにはどのくらいの期間がかかるのか、どのくらいの人数が必要なのか、どのくらいのコストが発生するのかを見積もります。
一方でアジャイル開発では、どのくらいの期間や人数で仕事をするかを決めて、その範囲の中で大事な要求から順にプロダクト（アジャイル開発において実際に作られるもののこと。主にソフトウェアを指しますが、必要なドキュメントなども含まれます）を作っていきます。つまり、重要なもの、リスクの高いものほど先に作り、そうでないものは後回しにすることで成果を最大化していきます。
スクラムってなんだろう？
スクラムは、前述の通りアジャイル開発手法の1つです。
スクラムは、1990年代にジェフ・サザーランド氏とケン・シュエイバー氏によって作られました。1986年のハーバード・ビジネス・レビュー誌に掲載された野中郁次郎氏と竹内弘高氏による論文「The New New Product Development Game」の内容をソフトウェア開発に応用したもので、スクラムという名前自体もこの論文から取っています。
スクラムには以下の特徴があります。
- 要求を価値やリスクや必要性を基準にして並べ替えて、その順にプロダクトを作ることで成果を最大化します
- スクラムでは固定の短い時間に区切って作業を進めます。固定の時間のことをタイムボックスと呼びます
- 現在の状況や問題点を常に明らかにします。これを透明性と呼びます
- 定期的に進捗状況や作っているプロダクトで期待されている成果を得られるのか、仕事の進め方に問題がないかどうかを確認します。これを検査と呼びます
- やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変えます。これを適応と呼びます
スクラムはわかっていることよりもわからないことが多いような複雑な問題を扱うのに適しており、5つのイベント（会議など）、3つのロール（人の役割）、3つの作成物など最低限のルールのセットで構成されています。あくまで最低限のルールのみ用意されているので、そのルールを実際どのように適用していくのかは自分たちで考えなければいけません。
また、スクラムで決まっていない部分、たとえばコードの書き方やテストのやり方など、プロダクトを作るうえで必要な点についても、自分たちの状況を踏まえて取り組んでいく必要があります。そのため、フレームワークとも表現されています。
スクラムのルールはスクラムガイドで定義されています。2010年に初版が公開され、以降1～2年おきに内容が改訂されています。スクラムのルール自体も検査と適応を繰り返して更新されていると考えれば良いでしょう。
本書では、執筆時点の最新版である2017年版のスクラムガイドをもとに説明していきます。なお、今後も改定されていくため、適宜最新版の有無を確認するようにしてください。
では、特徴がわかったところで、スクラムで決められていることを順番に見ていきましょう。
機能や要求を並べ替える
スクラムでは、機能や要求、要望、修正などプロダクトに必要なものを抽出し、順番に並べ替えたプロダクトバックログと呼ばれるリストを作成します。プロダクトバックログはプロダクトにつき1つと決められています。プロダクトバックログの項目の順番は、その項目が実現されたときに得られる価値やリスク、必要性などによって決定します。
それぞれの項目はプロダクトバックログ上で一意な順番を持ち、順番が上位のものから開発します。そのため上位の項目ほど内容が具体的で詳細なものになります。また、計画の際に利用するために、それぞれの項目（とくにリストの上位の項目）は見積もられている必要があります。見積りには時間や金額などの絶対値ではなく、作業の量を相対的にあらわした値がよく使われています。
プロダクトバックログは、一度作って順番に並べ替えたら完成ではありません。絶えず要求が変わったり、新たな要求が追加されたりします。また作る順番も状況に合わせて変わります。したがってプロダクトバックログは、プロダクトを作っている間はずっと更新を続け、常に最新に保たなければいけません。
プロダクトバックログの項目の書き方にはとくに決まりはありませんが、ユーザーストーリーと呼ばれる形式で書くことが多いようです。
プロダクトの責任者は誰？
プロダクトバックログの管理の責任者をプロダクトオーナー（PO）と呼びます。
プロダクトオーナーはプロダクトの責任者であり、1プロダクトにつき1人です（合議制の委員会ではありません）。開発チームを活用して、そのプロダクトが生み出す価値を最大化する責任があります。そのためにプロダクトバックログの並べ替えのほかに、次のようなことを行います。
- プロダクトのビジョンを明らかにし、周りと共有する
- おおよそのリリース計画を定める
- 予算を管理する
- 顧客、プロダクトの利用者や組織の関連部署などの関係者と、プロダクトバックログの項目の内容を確認したり、作る順番や実現時期を相談したりする
- 既存のプロダクトバックログの項目の内容を最新の状態に更新する
- プロダクトバックログの項目の内容を関係者が理解できるように説明する
- プロダクトバックログ項目が完成しているかどうかを確認する
プロダクトバックログの作成や更新は、プロダクトオーナー1人ではなく、開発チームらとともに行う場合もありますが、最終的な責任はあくまでプロダクトオーナーにあります。
プロダクトオーナーが決めたことを他人が勝手に覆してはいけません。プロダクトオーナー自身が決めることで、結果に対して責任を持てるようになります。
動作するプロダクトを開発する
2つめのロールが開発チームです。開発チームの主な役割は、プロダクトオーナーが順位づけしたプロダクトバックログの項目を順番に開発していくことです。
開発チームは通常、3人から9人までで構成されます。3人未満の場合は、お互いの相互作用が少なかったり、個人のスキルに依存する場合が多くなったりするため、開発チームとして活動した効果が出にくくなります。10人以上の場合は、コミュニケーションコストが増えることによって開発の効率が落ちるため、開発チームを分割してサイズを適切に維持するのが一般的です。
開発チームは、プロダクトを作るために必要なすべての作業ができなければいけません。たとえば、要求の分析をする、設計する、コードを書く、サーバを構築する、テストをする、ドキュメントを書くといった能力が開発チームの中に必要です。これを機能横断的なチームと呼びます。
たとえば「要求分析チーム」や「テストチーム」のように、特定のことしか行わない専門のサブチームは作りません。開発チームのメンバーごとにできることが違ったり、能力に差があったりしますが、作業を進めていく過程でなるべく個人が複数のことをできるようになることが望まれます。
開発チーム内では役職やスキルなどによる特定の肩書きや役割はありません。開発チーム内での仕事の進め方は、開発チームのメンバーの合意のもとで決め、外部から仕事の進め方を指示されることはありません。あくまで開発チーム全体で責任を持って作業を進めます。これを自己組織化と呼びます。このように開発チームで主体的に作業を進めることによって、開発チームの能力は継続的に向上していきます。
短く区切って繰り返す
スクラムでは最長1か月までの固定の期間に区切って、繰り返し開発を行います。この固定の期間のことをスプリントと呼びます。開発チームはこの期間の中で、計画、設計、開発、テストなどプロダクトバックログ項目を完成させるのに必要な作業すべてを行います。
このように固定の期間に区切って開発を繰り返すことによって、開発チームにリズムができて集中できるようになり、全体のゴールに対する進捗が把握しやすくなったり、リスクに対応しやすくなったりします。
たとえスプリントの最終日に作業が残っていても、スプリントは終了し、期間は延長しません。スプリントの期間は、プロダクトの規模や開発チームの人数や成熟度、ビジネスの状況などを踏まえて決定します。短ければ1週間、長くて4週間と、週単位で期間を設定することが一般的です。
なお、状況の変化によって現在のスプリントでの作業の意味がなくなった場合は、プロダクトオーナーの判断によってのみスプリントを途中で中止することができます。
頻繁に計画する
スプリントを始めるにあたっては、まずスプリントで何を作るのか（What）、どのように作るのか（How）を計画する必要があります。計画は、スプリントプランニングと呼ばれるイベントで決定します（スプリント計画会議と呼ぶこともあります）。スプリントプランニングに使える時間は、1か月スプリントであれば8時間、スプリント期間が短ければそれに合わせて短くするのが普通です。
スプリントプランニングでは、2つのトピックを扱います。
1つめのトピックは、スプリントで何を達成するかを決めることです。
最初に、プロダクトオーナーが今回のスプリントで達成したい目的を明らかにします。次に、今回のスプリントでそれを達成するために完成させるプロダクトバックログ項目を選びます。選択する項目は並べ替えてあるプロダクトバックログの上位の項目になるのが一般的です。選択するプロダクトバックログの個数は、それぞれの項目の見積りのサイズや開発チームの過去の実績（これをベロシティと呼びます）、今回のスプリントで作業に使える時間（キャパシティと呼びます）などを踏まえて仮決定します。
また、検討した内容を踏まえて今回のスプリントの目標を簡潔にまとめておきます。これをスプリントゴールと呼び、開発チームがなぜここで選択したプロダクトバックログの項目を開発するのかを理解しやすくなります。
このようにプロダクトバックログの上位から順に、今回のスプリントで開発する対象として検討を行うため、スプリントプランニングを開始する前に、プロダクトバックログの上位の項目については事前準備が必要です。
準備の内容はさまざまですが、たとえば、項目の中身を具体的にする、項目の疑問点を解決する、項目は何ができたら完成なのか（受け入れ基準）を明らかにする、項目を自分たちが扱えるサイズに分割する、項目を見積もる、といったことを行います。これらの活動のことをプロダクトバックログリファインメントと呼びます（リファインメントと略して呼ぶことも多いようです）。
リファインメントをいつどのように行うのかはスクラムでは定義していませんが、スプリント開始直前だと準備が間に合わない可能性があるため、時間に余裕をもって行います。リファインメントに使う時間はスプリントの10%以内にするのが一般的です。
次に2つめのトピックとして、開発チームがどうやって選択したプロダクトバックログ項目を実現するかについて計画を立てます。つまり選択したプロダクトバックログ項目ごとに、具体的な作業を洗い出すなどして作業計画を立てます。選択したプロダクトバックログ項目と作業の一覧を合わせて、スプリントバックログと呼びます。スプリントバックログは開発チームの作業計画であり、スプリント期間中も自由に作業を追加したり削除したりすることができます。また、個々の作業は1日以内で終わるように分割するのが一般的です。
スプリントバックログを検討した結果、トピック1で検討して選択したプロダクトバックログ項目を完成させるのが難しいと開発チームが判断した場合は、プロダクトオーナーと相談し、選択したプロダクトバックログの項目の一部を外したり、作業計画を検討し直したりすることによって、作業量を調節します。
注意しなければいけないのは、開発チームはスプリントプランニングで合意した内容を完成させるように全力を尽くす必要はあるものの、計画したことをすべて完成させることを約束しているわけではないという点です。すべての完成を約束してしまうと、見積りが外れたり、難易度が高かったり、不測の事態が発生したりした場合に、開発チームが長時間残業したり、必要な作業を省いたりしてしまうかもしれません。その結果、プロダクトにはさまざまな問題が発生することになります。
スプリントバックログの項目の担当者を特定の人が決めることはありません。またスプリントプランニングの時点で、すべての項目の担当者を決めるといったこともありません。実際に作業に着手するときに、作業する人自身がスプリントバックログの項目を選択するようにします。
スプリントごとに完成させていく
スクラムでは、スプリント単位で評価可能なインクリメントを作ることが求められます。
インクリメントとは、過去に作ったものと今回のスプリントで完成したプロダクトバックログ項目を合わせたものです。多くの場合、動作しているソフトウェアとして提供され、スプリント終了時点で完成していて正常に動作しなければいけません。そのため、プロダクトオーナーと開発チームが「完成」の指す内容について共通の基準を持つ必要があります。これを完成の定義と呼びます。開発チームは、この定義を満たしたプロダクトを作らなければいけません。
完成の定義は、品質基準と言い換えることもできます。途中で定義を追加してもかまいませんが、途中で定義を削ってしまうとプロダクトに要求される品質を達成できなくなる可能性があるので注意が必要です。
「基礎編 スクラムってなに？」から紹介するのはここまでです。本書ではこのあと、
- ゴールの達成に向けて進んでいるか毎日検査する「デイリースクラム」
- スプリントの成果をレビューするイベント「スプリントレビュー」
- 問題がなかったか、もっと成果を出すための検査を行う「スプリントレトロスペクティブ」
- プロダクトオーナーや開発チームを支える「スクラムマスター」
についても解説しています。
以降は「実践編 どうやればうまくいくの？」の「Scene No.00 開発したいものの概要と人物紹介」を抜粋します。
▼よし、始めようか!!
スクラムで決められているイベントや作成物については完璧にわかったぞ。ロールについても理解できた気がする。これなら部長に色々と聞かれても大丈夫そうだな。じゃあ、そろそろ部長のところに行ってみよう。まずはどんなモノを開発したいのかを詳しく聞いておかないとね。
まず、部長の紹介をしておこう。この人がブチョー。僕たちが所属する開発部署のトップだ。この会社の開発に関しては、割と上の立場にいるんだ。
ブチョーから早速、今回の開発について色々と聞いてみた。僕たちがこれから作るのは、社内の営業部が使うシステムで、いわゆる営業支援システムと呼ばれているものだ。営業活動を効率化するために、営業活動の日報や商談の進捗を管理したり、得意先情報を見たりするものだそうだ。これは営業マンが外出先で毎日使うものらしい。
また、得意先の訪問履歴や商談の進捗状況から商談成立の見込みなどを営業部全体に共有する、なんてこともやりたいそうだ。大昔に自社で作ったシステムがあるんだけど、古くて使い物にならなくなってきているので、新たに作り直すのが今回の目的ってことがわかった。ほかにも色々とブチョーから聞いたことをまとめると、こういう内容らしい。
- 営業部が使っている営業支援システムを新しく作り直したいそうだ。
- 全国の営業部で使っている重要なシステムらしい。
- まずは分析機能といった高度なものは必要ないらしく、外出先で日報や商談の進捗管理や得意先情報の参照などをできるようにしたい。
- なぜか開発はスクラムで進めるようにと会社から指示があったらしい。
ふむふむ。なんとなく開発したいものがわかったぞ。あとは既存のシステムについての資料を読めばなんとかなりそうだ。これなら、ふだんの開発と変わらずにやれそうだぞ。
ブチョーにどうしても聞きたかったことがあった。どうして僕が担当することになったんだろう？ 答えは簡単だった。「キミがやりたそうにしていたから」。たしかに社内ミーティングでの発言も、そういう気持ちのあらわれだったのかもしれない。
これまで自分がリーダーとして担当してきた開発では大きな失敗をしたことはなかった。けれど、もっと色々とやれたはずという気持ちがずっとあった。そのために何か新しいことを始めてみたかったんだ。スクラムはそのきっかけになるんじゃないかと思ったから興味を持ったんだ。
けど、そんな前向きな気持ちもブチョーの「いやー、けど体制図に書いてあるスクラムマスターって肩書きはかっこいいね」という一言で、台無しになりそうになったのは内緒だ。
よし、まずは開発チームに会いに行こう。いよいよ社内初のスクラムによる開発が始まるぞ。今回の経緯については色々と言いたいこともあるけど、僕にとっては新しいチャレンジだ。大役を任されているしがんばるぞ!! なんか楽しくなってきた。
さて、新しいスクラムマスターがこの現場にも登場したみたいだ。これから彼と一緒に、スクラムに取り組むとはどういうことなのかを学んでいくとしよう!!
▼登場人物紹介
