スクラムの概要と始め方

スクラムの軸となる継続的な改善が、アジャイルの中核的な原則であることから、スクラムとアジャイルはよく同一視されます。実際は、スクラムは任務を達成するフレームワークを指し、アジャイルは考え方を指します。アジャイルの考え方は、小規模で頻繁なリリースによって継続的に段階的な改善を行うことに集中しています。「アジャイルに移行」するには、顧客への価値の提供についてチーム全体で考え方を変える取り組みが必要なため、本当の意味ではアジャイルには移行できません。それでもスクラムのようなフレームワークを使えば、アジャイル型の思考を始め、日々のコミュニケーションや業務にアジャイル型の原則が根付くよう実践を重ねることができます。

アジャイルとスクラムの定義の違いは、スクラム ガイドとアジャイル マニフェストでご確認ください。アジャイル マニフェストには、4 つの価値が概説されています。

• 個々のスタッフとプロセスやツールを介したインタラクション

• 包括的なドキュメントよりも機能するソフトウェアを

• 契約交渉よりも顧客との協調を

• 計画に従うことよりも変化への対応を

スクラムの定義は、経験主義とリーン思考に基づいています。経験主義では、経験から知識が生まれ、観察する内容に基づいて決定が下されると示しています。リーン思考では、無駄を減らして必須要素に焦点を当てます。スクラム フレームワークでは、経験則に基づいて効率的に近似解を模索する方法を採り、変動要素に合わせて学習と調整を続けます。チームはプロジェクトに着手した段階ではすべてを理解していなくても、経験を通じて次第に練度を高めていきます。プロセスに優先順位の付け直しを組み込み、短いリリース サイクルを繰り返す形で、チームが変化の激しい条件とユーザー要件にスムーズになじみ、学習と改善を続けていけるように、スクラムは構造化されています。

スクラムは構造化されていますが、適度に柔軟性を保ったフレームワークです。実行時には各組織のニーズに合わせ、柔軟に調整できます。スクラム チームが成功するために必要な作業方法を具体的に説く理論はたくさんあります。しかしながら、アトラシアンで 10 年以上もアジャイル チームの活躍を支えてきた結果わかったことは、どのフレームワークを選んだとしても、明確なコミュニケーション、透明性、継続的改善への熱意を中心に据えるべきだということです。それ以外の部分は、お客様次第です。

スクラム フレームワークは、スクラム チームが製品やサービスを提供するために従う一連の価値観、原則、プラクティスの概要を示しています。スクラム チームのメンバーとその責任、製品と製品制作の作業を定義する「アーティファクト」、作業を通してスクラム チームを導くスクラム セレモニーが詳述されています。

スクラム チームとは、製品のインクリメントに取り組むことに専念する、小規模で機敏なチームです。スクラム チームの規模は、通常は小規模で 10 人ほどですが、スプリント内で相当な作業量を完了するには十分な規模です。スクラム チームには、製品所有者、スクラム マスター、開発チームという 3 つの特定の役割が必要です。スクラム チームは部門横断型なため、開発チームには開発者に加え、テスター、デザイナー、UX スペシャリスト、運用エンジニアが含まれます。

スクラムの製品所有者

製品所有者はその製品の舵取り役です。ビジネス、顧客、市場の要件を把握した後、それに応じてエンジニアリング チームが行う作業の優先順位を決めることが主な仕事です。有能な製品所有者は以下のことを行います。

• 製品バックログの作成と管理を行う

• 業務部門およびチームと緊密に連携し、全員が製品バックログの作業項目を理解できるよう徹底する

• 次に提供する機能に関して明確なガイダンスをチームに与える

• デリバリー頻度が高くなりやすい製品のリリース時期を決定する

製品所有者は必ずしもプロダクト マネージャーと同義ではないことに留意してください。製品所有者の仕事は、開発チームがビジネスにとって最大の価値を確実に生み出せるようにすることです。また、製品所有者が 1 人であることも重要です。複数の製品所有者から異なる指示を与えられると、開発チームが混乱します。

スクラム マスター

スクラム マスターは、チーム内のスクラムの推進者です。スクラム プロセスでチーム、製品所有者、組織を指導し、それぞれの取り組み方を微調整する方法を探します。

有能なスクラム マスターは、チームが行っている作業を深く理解し、チームが透明性とデリバリー フローを最適化できるようサポートします。主幹進行役として、スクラム マスターはスプリント計画、スタンドアップ、スプリント レビュー、スプリントのふりかえりに必要なリソース (要員と物流の両方) のスケジュールを決定します。

スクラム開発チーム

スクラム チームは迅速に作業を完了します。スクラム チームは持続可能な開発プラクティスの推進者です。もっとも効果的なスクラム チームは、緊密であり、同じ場所にいて、通常、5 から 7 人のメンバーで構成されています。チーム規模の調整にあたっては、アマゾン社の最高経営責任者である Jeff Bezos 氏の提唱した有名な「2 枚のピザ ルール」 (チーム規模は 2 枚のピザを分け合える範囲に抑えること) を基準にする方法があります。

チーム メンバーは、さまざまなスキルを持ち、相互にクロストレーニングするため、作業のデリバリーで障害になる人はいません。強力なスクラム チームは、自己組織化して「チームで」という明確な姿勢でプロジェクトに取り組みます。チームのすべてのメンバーは相互に助け合い、スプリントが無事に完了するようにします。

スクラム チームは各スプリントの計画を推進します。チームは過去のベロシティを参考にして、そのイテレーションで完了できる作業量を予測します。イテレーションの長さを固定しておくと、開発チームは見積もりとデリバリー プロセスに関して重要なフィードバックを得ることができます。この結果、予測精度が次第に高まります。

スクラム アーティファクトはスクラム チームが使用する重要な情報で、製品とその製品を作成するために行うべき作業を定義するのに役立ちます。スクラムには 3 つのアーティファクトがあります。製品バックログ、スプリント バックログ、「完了」の定義に応じたインクリメントです。これらは、スクラム チームがスプリント時および継続的に検討する必要がある不変の 3 点です。

• 製品バックログは、製品所有者やプロダクト マネージャーによって管理される、達成すべき作業の主要なリストです。スプリント バックログの入力要素となるさまざまな機能、要件、拡張、修正プログラムが動的にまとめられます。本質的にはチームの「To Do」リストと言えます。ノウハウの蓄積や市場の変化を受けて、項目の関連性が薄れたり、問題がほかの方法で解決されたりするため、製品所有者はこまめに検討を繰り返し、優先順位を付け直しながら製品バックログを維持します。

• スプリント バックログは、開発チームが現在のスプリント サイクルで実装する対象として選んだ項目、ユーザー ストーリー、バグ修正のリストです。各スプリントの前にはスプリント計画ミーティング (この記事の後半で説明) で、チームがそのスプリント中に取り組む項目を製品バックログから選び出します。スプリント バックログは柔軟に扱うことができ、スプリントの途中でも変更できます。ただし、スプリントの基本的な目標 (現在のスプリントで何を達成するか) は変えないでください。

• インクリメント (またはスプリントの目標) は、スプリントで作成された利用可能な最終製品です。通常、アトラシアンではスプリント終了時に行われるデモで「インクリメント」を実演します。デモでは、チームがスプリントで完了したものを示します。「インクリメント」はチームの「完了」の定義、つまりマイルストーン、スプリント目標、フル バージョン、リリース済みエピックなどと呼ばれることが多いため、あまり耳にすることのない用語かもしれません。チームが「完了」をどう定義しているか、スプリントの目標をあなたがどう定義しているかによります。たとえば、あるチームは各スプリントの最後に顧客に向けて何かをリリースすることに決めます。この場合「完了」は「リリース済み」という意味です。一方でこのような考え方がほぼ成り立たないタイプのチームもあります。サーバーベース型の製品に取り組んでいて、顧客へのリリースは四半期ごとが精いっぱいとしたら、どうでしょうか。それでも 2 週間のスプリント単位で作業することを選択できますが、この場合の「完了」の定義は、一度にリリースする予定のより大きなバージョンの一部の完了となるでしょう。当然ながらソフトウェアのリリースに時間がかかるほど、守るべきソフトウェア納期を達成できないリスクが高まります。

ご承知のとおり、アーティファクトにさえたくさんのバリエーションがあるため、担当チームはその中から取捨選択して定義できます。このため、アーティファクトの継続的な管理方法にさえも、常に改善できる柔軟性を残しておくことが大切です。「完了」の定義をどう設定するかで、チームにかかるストレスを緩和できるため、場合によっては前の段階に戻って定義を選び直す必要も出てきます。

スクラムのフレームワークには、スクラム チームが定期的に実施するスクラム プラクティス、セレモニー、ミーティングが含まれます。アジャイル セレモニーではチームによる差異が最も顕著に出ます。たとえば、このようなセレモニーをすべて実施するのは面倒だし、多すぎると考えるチームもあれば、必要な確認の機会と見なすチームもあります。まずスプリント 2 回分はすべてのセレモニーを実施して、様子を見るようお勧めします。その後、簡単なふりかえりを実施して、調節の必要な箇所があるかを検討します。

以下は、スクラムチームが参加するすべての主要セレモニーです。

1. バックログを整理する: 「バックロググルーミング」と呼ぶこともあるイベントで、プロダクトオーナーが責任者を務めます。プロダクトオーナーの主な責務は、各プロダクトを所定のビジョンに近づけ、市場や顧客の最新動向を常に把握することにあります。このためプロダクトオーナーは、ユーザーや開発チームのフィードバックを参考にしてこのリストを継続的に管理し、リスト内の優先順位を調整したり、必要な最新情報のみで再構成したりして、いつでも使える状態で維持します。詳細については、効率的なバックログの維持をご覧ください。

2. スプリント計画: 現在のスプリント中に遂行すべき作業 (スコープ) を、このミーティング中に開発チーム全体で計画します。このミーティングはスクラム マスターがリードします。チームがスプリントの目標を決定する場でもあります。ここで具体的なユーザー ストーリーをプロダクト バックログからスプリントに追加します。これらのストーリーは必ず目標に合わせて調整します。また、スプリント中の実装が可能であることをスクラム チーム内で合意します。

   計画ミーティングの終わりには、スプリント中にデリバリーできるもの、インクリメントのデリバリー方法について、スクラム メンバー全員が明確に理解している必要があります。

3. スプリント: スプリントとは、スクラムチームが共同作業し、インクリメントを完成するのに実際にかかる期間です。典型的なスプリントの長さは 2 週間ですが、スコープの作成には 1 週間、価値の高いインクリメントを実装し、提供するには 1 か月が妥当とするチームもあります。Dave West (Scrum.org 所属) は、作業内容が複雑で、未知の要素が多いほど、スプリントを短く設定するよう推奨しています。とは言えスプリントの長さは各チーム次第です。スプリントの長さがうまく機能しない場合は、ためらわずに調整してください。この期間中は必要に応じて製品所有者と開発チームでスコープを練り直しても構いません。スクラムの経験主義的な性質を形づくっているのは主にこの部分です。

   計画からふりかえりまで、すべてのイベントがスプリント中に発生します。スプリントの期間が具体的に決まったら、開発期間を通しそのスケジュールを守る必要があります。そうするとチームが過去の経験に学び、そのインサイトを以後のスプリントで活かせるようになります。

4. デイリー スクラムまたはスタンドアップ: これはシンプルに毎日同じ時間 (通常は朝)、同じ場所でごく短い時間で行うミーティングです。多くのチームではこのミーティングを 15 分以内に済ませるよう努めていますが、適宜この時間は増減してください。さっと済ませる必要がある点を強調して、このミーティングは「デイリー スタンドアップ」とも呼ばれています。デイリー スクラムの目標は、スプリントの目標に合わせる形でチームの全員が同じ情報と条件を共有し、次の 24 時間の計画を立てることにあります。

   スタンドアップとは、スプリント目標の達成やブロッカーについての懸念をすべて表明する場です。

   スタンドアップは、チーム メンバーが一人ひとりスプリント目標の達成について次の 3 つの質問に答えるやり方が一般的です。
   
   • 昨日は何をしましたか?
   • 今日は何をする予定ですか?
   • 何か障害はありますか?
   
   こうすると、ミーティングの参加者は各自、前日や翌日の予定表の確認を始めがちです。スタンドアップの意図は、雑談を毎日のミーティングに変え、チームが毎日ミーティング後の作業に集中しやすいようにすることにあります。そのため、毎日ただ予定表を読み上げるようになったら、すぐに内容を変え、創意工夫をするようにしてください。

5. スプリント レビュー: スプリント終了時のセッションではチームが集まり、非公式にインクリメントのデモを確認したり、検査したりします。開発チームが現時点で「完了」しているバックログ項目を関係者とチームメートに提示し、フィードバックを求めます。インクリメントをリリースするかしないかの決定権は製品所有者にありますが、多くの場合インクリメントはリリースされます。

   このレビュー・ミーティングは製品所有者が現在のスプリントに沿って製品バックログを作成し直したときにも開き、次のスプリント計画セッションで参考にします。1 か月のスプリントでは、スプリント・レビュー時間は最大 4 時間程度になるよう検討してください。

6. スプリントのふりかえり: ふりかえりとは、チームメンバーが集まり、スプリント、プロジェクト、関係、ツール、さらには特定のセレモニーで成功したこと、しなかったことについて記録し、話し合う機会です。ここでのポイントは、次回に備え、成功したことや改善すべきことにチーム全体で集中することにあり、失敗は重点的には取り上げません。

2016 年に、スクラムの 5 つの価値基準がスクラム ガイドに追加されました。これらの価値基準は、スクラム チームの業務、アクション、行動の方向性を示しています。この価値基準はスクラム チームの成功に不可欠だと考えられています。

コミットメント

スクラム チームは小規模でアジャイルなため、各チーム メンバーがチームの成功において重要な役割を果たします。そのため、各チーム メンバーは、自分が完了できるタスクを実行することに取り組み、過度なコミットをしないよう同意する必要があります。作業の進捗については、多くの場合はスタンドアップで、頻繁にコミュニケーションを取る必要があります。

勇気

スクラム チームにとっての勇気とは、現状や成功を妨げるものに疑問を投げかける勇気です。スクラムのチーム メンバーは、勇気を持って、安心して新しいことに挑戦する必要があります。スクラム チームは、勇気を持って、安心して障害、プロジェクトの進捗、遅延などに関して透明性を保つ必要があります。

集中

スクラム チームのワークフローの中心はスプリントです。スプリントとは、チームが一定量の作業を完了する、集中した特定の期間です。スプリントでは、計画された作業量を完了させるための構造を提供するだけでなく、焦点を合わせることもできます。

オープン性

デイリー スタンドアップでは、オープン性を高めて、チームが進行中の作業や障害について率直に話し合えるようになります。アトラシアンでは、スクラム チームに次の質問によく取り組んでもらいます。

• 昨日は何に取り組んだか?

• 今日は何に取り組んでいるか?

• 障害となっている課題は何か?

これにより、進捗を強調し、障害を特定できます。また、全員が進捗を共有することで、チームの強化にも役立ちます。

敬意

アジャイル チームの強みは、チームのコラボレーションと、各チーム メンバーがスプリント内の作業に貢献していることを認識していることです。メンバーはお互いの成果を祝い、お互いやプロダクト所有者、関係者、スクラム マスターに敬意を払っています。

スクラムは人気の高いアジャイル型フレームワークであるため、スクラムとアジャイルはよく混同されます。ただし、カンバンのように幅広く採用されている、その他のフレームワークもあります。スクラムとカンバンのハイブリッド モデルは「スクラムバン」または「カンプラン」と呼ばれ、これを採用する会社もあります。これはバックログを持つカンバンです。

スクラムとカンバンはどちらも、スクラム ボードやカンバン ボードといった視覚的な手法を使って作業の進捗を追跡します。どちらも効率性を重視して複雑なタスクを比較的小さく管理しやすい作業に分割するやり方を多用しますが、目標へのアプローチが異なります。

スクラムでは比較的短い一定期間のイテレーションに重点を置きます。スプリントの期間が満了すると、そのスプリント サイクル中に実装できるストーリーや製品バックログのエントリーが決定します。一方、カンバンでは、現在のサイクルで実装するタスク数や進行中の作業の数 (WIP 制限) を最初に決定します。次に、これらの機能を実装する時間を逆算します。

カンバンはスクラムほど構造化されていません。WIP 制限を除くと、解釈の自由度がかなり大きくなっています。これに対して、スクラムではスプリント レビュー、ふりかえり、デイリー スクラムなど、実装の一部として厳守すべき概念がいくつか決まっています。また、部門横断型の取り組みを非常に重視しているため、スクラム チームは外部のメンバーに依存することなく目標を達成できます。部門横断型チームをまとめることは簡単ではありません。このように、カンバンは比較的簡単に採用できる一方、スクラムは開発チームの機能や思考プロセスの根本的な変化につながる場合があります。

スクラム フレームワーク自体はシンプルです。ルール、アーティファクト、イベント、役割はスムーズに理解できます。ゆるやかな規範を提供するスクラムのアプローチでは、開発プロセスから解釈のぶれを排除しつつ、企業ごとに独自の特徴を盛り込める余地があります。

複雑なタスクを管理しやすいユーザー ストーリーに整理すると、難しいプロジェクトもスムーズに遂行できます。また役割や計画済みイベントを明確に区分化すると、開発サイクル全体を通して透明性や集団的な責任を維持できるようになります。迅速なリリースを重ねていくと、短期間の進捗がよく見えるため、チームのモチベーションを維持でき、ユーザーの満足度が上がります。

ただしスクラムを完全に理解するには時として時間がかかり、典型的なウォーターフォール モデルに依存してきた開発チームでは、その傾向が特に強く表れます。多数の細分化したイテレーション、デイリー スクラム ミーティング、スプリント レビュー、スクラム マスターの特定といった考え方は、慣れていないチームには難しい文化的転換が必要となることもあります。

ただし、初期の学習曲線の苦労より、長期的なメリットの方が重要です。大小さまざまな業界で複雑なハードウェア製品、ソフトウェア製品の開発を成功に導いてきたスクラムは、御社でもぜひご採用いただきたい優秀なフレームワークです。

Jira を使用したスクラムの詳細については、このチュートリアルをご確認ください。