『スクラムの要素』（2011年）は、時代遅れのソフトウェア開発プロセスが変化の激しい市場で企業の足かせになっていることを説き、現代の成功するチームには俊敏性と柔軟性が不可欠であり、最高の企業はスクラムと呼ばれる方法論を採用していると解説します。本書は、自社でスクラムベースのプロセスを始めるために必要な知識をすべて提供します。
この要約で得られるもの：俊敏かつ柔軟に、スクラムで仕事の質を高める方法を学ぶ
プロジェクトを完璧に進める最善の手法を持っていると思っていませんか？これは特にソフトウェア開発でよくある誤りです。チームごとに好みや思い込みがあり、デザイナーはこうしたい、コーダーはああしたいと主張し、その混乱の中で顧客は置き去りにされてしまいます。
結局のところ、優れたソフトウェア製品を開発するための決まった手順や、AからZへの完璧な道筋など存在しません。しかし、完璧に限りなく近づくためのいくつかのコツはあります。
今日のチームは柔軟で俊敏でなければなりません。降りかかる気まぐれや課題に合わせて変化できる態勢が求められます。計画を立てたら、あとはそれを脇に置き、最終目標を見据えながらその場で新たな計画を組み立てていくのです。
では、どうすればいいのでしょうか？ 旧来のウォーターフォール手法を捨て、スクラムを取り入れましょう。スクラムは俊敏で柔軟なシステムであり、あなたの考え方を変え、開発プロセスに革命をもたらします。
この要約では、以下のことを学びます。
- なぜ今日の“ウォーターフォール”開発ではうまくいかないのか
- 15分のデイリーミーティングが成功への鍵となる理由
- 短いスプリントの繰り返しが、長くゆっくり進むよりもはるかに効率的な理由
従来のソフトウェア開発手法は非効率で、コスト超過を招く
伝統には魅力があるかもしれませんが、テクノロジー開発においてはほとんど支持されません。テクノロジーは常に更新されてこそ意味があり、最新であることはテクノロジー自体だけでなく、それを作り出すプロセスにも不可欠です。
ウォーターフォール手法と呼ばれる開発方式は、ソフトウェアを生み出すためのフィニッシュ・トゥ・スタート（完了-開始）のプロセスです。このシステムでは、要求をまとめ、設計し、コードを書き、テストした後で完成品を納品するという流れが一般的です。
「フィニッシュ・トゥ・スタート」の部分が重要です。作業Aが完了しなければ、作業Bに着手できないのです。たとえば、コーディングが終わるまで設計のテストは始められません。
なぜ人や組織はこの方法を好むのでしょうか？
開発の各工程を分離することで、スケジュールや計画が立てやすくなります。マネージャーは、スケジュールや予算をより正確に管理できると考えて、ウォーターフォール的なアプローチを好むのです。
しかし、ウォーターフォール手法はあまり信頼できません。ソフトウェアはあまりに複雑な製品であり、開発が始まる前に完璧に設計しきることは難しいのです。完璧な設計を求めれば、生産中に変更する余地はほとんど残されません。
完璧な設計から完璧な生産プロセスへとシームレスに移行できるのは、通常、車のような静的な製品を製造する場合に限られます。その例では、クルマのあらゆる要素を設計し、製造時にはその設計図通りに忠実に作業します。
しかし、ソフトウェア開発は対照的に、あまりにも複雑なのです。
そのため、デザイナーが完璧だと考える製品を思い描いても、いざ設計を適用しようとすると必ず問題が生じます。数字が物語っています。ウォーターフォール手法のプロジェクトのうち、納期に間に合うのはわずか16％で、31％は途中で中止され、53％は予算を超過しているのです。
では、自分のプロジェクトでこのような落とし穴を避けるにはどうすればいいのか？ 読み進めて学んでいきましょう。
アジャイルプロセスはウォーターフォールと同じ要素を持つが、より柔軟性をもたらす
ペースが速く予測不能なテクノロジー市場では、開発プロセスを素早く適応させるための柔軟性が求められます。つまり、ある要素が別の要素を待たせて足止めしてしまうのを防ぐ必要があるのです。
では、どうすれば開発の流れを止めずに進められるでしょうか？
それがアジャイルプロセスです。変化を成長の機会として受け入れる開発戦略です。
アジャイルチームの作業の流れは、ウォーターフォール手法と大きくは変わりません。要求を集め、設計し、コードを書き、テストし、製品を納品します。ただし、しないのは、各工程が完全に終わるのを待ってから次に進む、ということです。
その代わりに、アジャイルチームは各工程を少しずつ進め、製品の一部を顧客に届けます。このサイクルを完了まで何度も繰り返します。これをイテレーション（反復）と呼びます。
写真編集ソフトウェアの開発チームを考えてみましょう。アジャイルプロセスなら、まずカラー写真を白黒に変える機能を完成させるかもしれません。その小さな機能を顧客に送り、フィードバックをもらいます。次のイテレーションではそのフィードバックをもとに改良を進めることができるのです。
ただし、アジャイルプロセスは単なる「ミニウォーターフォール」ではありません。完全に統合されたプロセスなのです。つまり、アジャイルチームは各プロジェクトを分断されたパーツとしてではなく、ひとつのまとまりとして扱います。フィニッシュ・トゥ・スタートのチームとはここが違います。
だからこそ、アジャイルチームはデザイナーとコーダーが「自分の担当部分」だけを考えて他を無視するのではなく、お互いの貢献が補完し合うように意識するのです。
ウォーターフォールとアジャイルのもう一つの決定的な違いは、顧客との関わり方です。ウォーターフォールでは、顧客はプロジェクトの開始時に要求を伝え、その後は製品が納品されるまで関与しません。一方、アジャイルプロセスでは、チームはプロセス中ずっと顧客と絶えず接し、要求は常に調整・変更が可能です。
アジャイルの4つの核となる価値が、無駄なく効率的で成功するプロセスへの道を開く
いつもの通勤路を運転していると、前方の交差点で事故が起きて道を塞いでいます。あなたならどうしますか？ 事故が片付くまで待ちますか？ それとも、知らない道を曲がって迂回路を探りますか？
後者の「曲がって探る」を選んだなら、あなたはすでにアジャイルの4つの重要な価値のひとつを持っています。それぞれの価値は、異なるアプローチの間の優先順位、つまり選択を表しています。
アジャイルの第一の価値は、プロセスやツールよりも個人と対話を優先することです。これは、プロジェクトを導くプロセスよりも、プロジェクトに関わる人々の方が重要だという意味です。
基本的に、ツールやプロセスは人に仕えるべきであり、その逆ではありません。
第二の価値は、詳細なドキュメントよりも動くソフトウェアを優先することです。もちろんドキュメントは重要ですが、製品そのものよりも優先されるべきではありません。時間がなければ、優れた製品を生み出すことに集中し、大量の記録写真を撮ることに気を揉まないことです。
第三の価値は、契約交渉よりも顧客との協調を優先することです。開発チームと顧客の間の契約合意は、開かれた状態を保つことが不可欠です。そうしてこそ、顧客が本当に求めているものを生産し、届けることができます。
アジャイルチームは定期的にミーティングを持ち、すべてのイテレーションで開かれたコミュニケーションを維持します。契約は重要ですが、それだけでは顧客の品質基準が守られる保証はありません。しかし、開かれた流動的なコミュニケーションなら保証できるのです。
そして第四の価値は、計画に固執することよりも変化への対応を優先することです。計画は、どこへ向かい、どうやって辿り着くかを示しますが、突然の変化（あの交通事故のように）が起きたときは、柔軟かつ俊敏に適応し、目標に辿り着く必要があります。
アジャイルの4つの価値を忠実に守るとき、適応的で効率的なプロジェクトの優先順位を設定できるようになるのです。
スクラムは、集中した開発プロセスを通じてアジリティを体現するシステムである
アジャイルの価値がわかったところで、それを実践するためのシステムが必要です。そこで役立つのがスクラムです。
しかし、具体的に「スクラム」とは何でしょう？
スクラムは、一連のスプリントを通じて新製品を構築するソフトウェア開発プロセスであり、各スプリントには要求の調査から製品の納品に至るまでの開発工程がすべて含まれています。
各スプリントでは、プロジェクト全体のほんの一部に取り組むため、スプリントの期間は1週間程度から長くても1カ月までとさまざまです。
では、どうやってスプリントを始めるのでしょうか？
各スプリントはスプリント計画ミーティングでスタートします。このミーティングは2部構成で、前半ではスプリントの成果物を決定し、後半ではそれを達成する方法を考えます。
まず、チームがスプリントの最後に何を納品すべきかを明らかにします。この部分をリードするのはプロダクトオーナーです。プロダクトオーナーは、顧客の要望に基づいて、何をいつ作るかを決定するチームメンバーです。
写真編集ソフトウェアの例で言うと、プロダクトオーナーは「今週は白黒機能のスプリントを行い、来週は別の機能に取り組む」と指示するかもしれません。
プロダクトオーナーは、理想的なユーザー体験をストーリーとして提示する役割も担います（これについては次のセクションで詳しく説明します）。
前半の合意が得られたら、後半ではチームが目標をどうやって達成するかを決めます。
そのために、ユーザーインタビューやテストといったタスクを設定します。大切なのは、どのタスクも半日以上かからないようにすることです。大きなタスクは複数の小さなタスクに分割しましょう。
スプリントはユーザーの体験とストーリーを中心に展開する
スプリント計画ミーティングの極めて重要な要素は、優れたユーザー体験を描くことです。では、スクラムはこの要素をプロセスにどう取り入れるのか？ それがユーザーストーリーです。
ストーリーは、人々が実際に製品をどう使うかをシンプルに示す手段です。これがユーザーストーリーと呼ばれるのは、チームがプロダクトオーナーやデザイナー、コーダーではなく、常に最終顧客に注意を向け続けるためです。
すべてのユーザーストーリーは3つの要素で構成されます。対象ユーザーは誰か、ユーザー要件は何か、その要件が必要な理由は何か、です。
ストーリーのテンプレート例を見てみましょう。「＜ユーザーの種類＞として、私は＜何かを＞したい。そうすれば＜何らかの価値＞が生まれるからだ。」この空欄を埋めると、チームはたとえばこんなストーリーを考え出すでしょう。「カメラ付きスマートフォンのユーザーとして、私が撮った写真を携帯電話のソフトウェアが自動編集してくれるようにしたい。そうすれば時間を節約できるからだ。」
スプリントを成功させるには、ユーザーストーリーがどれほど複雑か、つまりどれほど「大きい」かを見積もる必要があります。ストーリーが大きいほど、必要な開発時間は長くなります。たとえば、ユーザーの購買プロセス全体を追跡するのは大きなストーリーで1カ月のスプリントが必要ですが、新しいヘッダーを開発するのは小さなストーリーで1週間で済みます。
では、ストーリーのサイズをどうやって測ればいいのでしょう？
ひとつの方法は、ストーリーの相対的なサイズに注目することです。つまり、プロジェクト内の他のストーリーと比べてどれくらい「大きい」かを見るのです。結局、ストーリーは抽象的な概念であり、正確に「大きさ」を測る方法はありません。
そこで、プロジェクトを見渡してユーザーストーリーを比較しましょう。一番「小さい」と思われるストーリーを見つけ、その最小のストーリーを基準に他のストーリーを測定するのです。
大きなストーリーと小さなストーリーを素早く識別できるように、チーム独自の番号システムを参照ツールとして考案してもいいでしょう。たとえば、ヘッダーの再設計がプロジェクト一覧で最も小さいスプリントなら、購買プロセスのスプリントを「ヘッダー再設計4つ分」と測ることができます。
スプリントの即応性と俊敏性を確保するために3種類のスクラムミーティングを取り入れる
チームが新しいプロジェクトを立ち上げ、全員がスコープと期待を理解し、懸命に取り組んでいると言ったとします。1カ月が過ぎ、集まってノートを共有した途端、トラブルが始まります。
3人のチームメンバーはタスクを終えていますが、2人は問題に頭を悩ませて作業が止まっています。そして1人は、他のメンバーの仕事を台無しにするようなやり方で自分のタスクを勝手に変更していました。
こんな経験、身に覚えがありませんか？
スクラムは、こうした事態を避けるために3種類のミーティングを用います。
まず、デイリースクラムは、変化を「リアルタイム」で特定します。これは、障害を特定しすぐに対処することで、チームを軌道に乗せ続けるための、毎日行うごく短いミーティングです。
デイリースクラムは毎日同じ時間に、最大15分間だけ行い、出席するのはコアチームメンバーだけです。
ミーティングでは、各メンバーが前日に達成したこと、今日取り組むこと、進捗を妨げている障害を共有します。
別のミーティングとして、スプリントレビューがあります。これは各スプリントの終わりに顧客からのフィードバックを得るために開かれます。ここでチームは作業成果を顧客に示し、プロダクトオーナーとチームは顧客の反応を注意深く記録します。
顧客の反応によって、プロダクトオーナーはプロダクトバックログ（優先度順に並べられたTo Doリスト）を調整します。
最後はレトロスペクティブ（振り返り）ミーティングです。ここでは、チームと共に終わったスプリントを振り返り、全員が学んだことを話し合います。このミーティングはスプリントレビューの後、スプリントが完了したその日のうちに行うべきです。
このミーティングでは、得た知識を次のスプリントにどう適用するかについても検討します。たとえば、テストプロセスをより効率的にするために変更が必要だ、という発見があるかもしれません。
最後のまとめ
この本の主要メッセージ：
ソフトウェア開発を管理する従来の手法は非効率で融通が利きません。プロジェクトを定義し、作業を始めたら完成するまで止まらない、というやり方ではなく、早い段階で顧客をプロセスに巻き込み、頻繁に助言を求めることが不可欠です。望む顧客満足を生み出すには、あらゆる変化に適応できる俊敏性と柔軟性を備えたプロセスが必要なのです。それこそがスクラムです！
実践的なアドバイス：
プロジェクトを第一に考えよ。
ソフトウェアを開発するということは、問題を解決するシステムを構築することであり、問題解決はチームワークそのものです。なぜなら、どんなに中心的な役割であっても、ソフトウェアプロジェクトが一人の人間によって完成することは決してないからです。開発プロセスは、解決策を見つけ障害を乗り越えるためにチームワークに頼っています。言い換えれば、自分のエゴではなく、プロジェクトを第一に考えるのです。
さらなるおすすめ書籍：ジェフ・サザーランド著『スクラム』
スクラムについてすべてを学びましょう。テクノロジー業界に革命をもたらしたプロジェクト管理システムです。これは独自の適応性と柔軟性を備えたシステムで、チームが現実的に計画を立て、絶え間ないフィードバックを通じて目標を調整することを可能にします。スクラムを使えば、不必要なストレスや長時間労働を生むことなく、チームの生産性（そして最終成果物）を向上させることができます。
