スクラムの概要と始め方

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

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

• 個々のスタッフとプロセスやツールを介したインタラクション
• 包括的なドキュメントよりも機能するソフトウェアを
• 契約交渉よりも顧客との協調を
• 計画に従うことによる変化への対応

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

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

• 製品バックログは、製品所有者や製品マネージャーによって管理される、達成すべき作業の主要リストで、スプリント バックログの入力となる、さまざまな機能、要件、拡張、修正プログラムを動的にまとめたリストです。基本的にはチームの「To Do」リストです。ノウハウの蓄積や市場の変化を受けて、項目の関連性が薄れたり、問題が他の方法で解決されたりするため、製品バックログは製品所有者がこまめに検討を繰り返し、優先順位を付け直しながら維持します。
• スプリントバックログは、開発チームが現在のスプリントサイクルで実装する対象として選んだ項目、ユーザーストーリー、バグ修正のリストです。各スプリントの前にはスプリント計画ミーティング (この記事の後半で説明) で、チームがそのスプリント中に取り組む項目をプロダクトバックログから選び出します。スプリントバックログは柔軟に扱うことができ、スプリントの途中でも変更できます。とは言えスプリントの基本的な目標 (現在のスプリントで何を達成するか) は変えないでください。
• インクリメント (または「スプリントの目標」) は、スプリントに基づく利用可能な最終プロダクトです。通常、アトラシアンではスプリント終了時に行われるデモで「インクリメント」を実演します。デモでは、チームがスプリントで完了したものを示します。「インクリメント」はチームの「完了」の定義、つまりマイルストーン、スプリント目標、フルバージョン、リリース済みエピックなどと呼ばれることが多いため、あまり耳にすることのない用語かもしれません。チームが「完了」をどう定義しているか、スプリントの目標をあなたがどう定義しているかによります。たとえば、チームによってはスプリントの最後に顧客に向けて何かをリリースします。この場合「完了」は「リリース済み」という意味です。一方でこのような考え方がほぼ成り立たないタイプのチームもあります。サーバーベース型のプロダクトに取り組んでいて、顧客へのリリースは四半期ごとが精いっぱいとしたら、どうでしょうか。2週間のスプリントの範囲で作業するという選択肢もありますが、この場合の「完了」の定義は、一度にリリースする予定の、より大きなバージョンの一部を完了させることを指す可能性があります。当然ながら、ソフトウェアのリリースに時間がかかるほど、守るべきソフトウェア納期を達成できないリスクが高まります。

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

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

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

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

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

4. デイリー スクラムまたはスタンドアップ: これはシンプルに毎日同じ時間 (通常は朝)、同じ場所でごく短い時間で行うミーティングです。多くのチームではこのミーティングを 15 分以内に済ませるよう努めていますが、適宜この時間は増減してください。さっと済ませる必要がある点を強調して、このミーティングは「デイリー スタンドアップ」とも呼ばれています。デイリー スクラムの目標は、スプリントの目標に合わせる形でチームの全員が同じ情報と条件を共有し、次の 24 時間の計画を立てることにあります。
   
   スタンドアップとは、スプリント目標の達成やブロッカーについての懸念をすべて表明する場です。
   
   スタンドアップは、チーム メンバーが一人ひとりスプリント目標の達成について次の 3 つの質問に答えるやり方が一般的です。
   
   • 昨日は何をしましたか?
   • 今日は何をする予定ですか?
   • 何か障害はありますか?
   
   こうすると、ミーティングの参加者は各自、前日や翌日の予定表の確認を始めがちです。スタンドアップの意図は、雑談を毎日のミーティングに変え、チームが毎日ミーティング後の作業に集中しやすいようにすることにあります。そのため、毎日ただ予定表を読み上げるようになったら、すぐに内容を変え、創意工夫をするようにしてください。

5. Sprint review: At the end of the sprint, the team gets together for an informal session to view a demo of, or inspect, the increment. The development team showcases the backlog items that are now ‘Done’ to stakeholders and teammates for feedback. The product owner can decide whether or not to release the increment, although in most cases the increment is released.
   
   This review meeting is also when the product owner reworks the product backlog based on the current sprint, which can feed into the next sprint planning session. For a one-month sprint, consider time-boxing your sprint review to a maximum of four hours.

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