Close

スクラム

スクラムのベストプラクティス

Browse topics

スクラムとは何か

スクラムはチームの共同作業をサポートするフレームワークです。大事な試合に向けて練習を積むラグビーチーム (これが名前の由来) と同じように、スクラムはチームが経験を通じて能力を高め、問題に取り組みながら自己管理し、過去の成功と失敗を振り返って継続的に改善することをサポートします。

スクラムは、ソフトウェア開発チームで活用されることが多いものの、その原則や知識はあらゆる種類のチームワークの役に立ちます。これがスクラムの人気が高い理由の 1 つです。アジャイル型プロジェクト管理フレームワークとみなされることの多いスクラムでは、複数のチームが作業を構造化し、管理できるよう、一連のミーティング、ツール、役割について記述します。

この記事では、従来のスクラムフレームワークの構造について、スクラムガイドと David West 氏 (Scrum.org CEO) の言葉を引用しながら説明します。また、アトラシアンのお客様がこれらの基本事項から逸脱して自社独自のニーズに適応させた事例をいくつかご紹介します。こちらについては当方の Megan Cook (Jira Software グループプロダクトマネージャー、前アジャイルコーチ) が、アトラシアンの「アジャイルコーチ」ビデオシリーズ (以下) でヒントやコツをご紹介します。

スクラムに関する記事

[続き]

フレームワーク

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

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

スクラムフレームワーク | アトラシアンアジャイルコーチ

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

スクラムのアーティファクト

まずスクラムで得られる 3 つのアーティファクトを理解しましょう。アーティファクトとは、問題を解決するツールなど私たちの製作物を指します。スクラムの場合、これら 3 つのアーティファクトはプロダクトバックログ、スプリントバックログ、"完了" の定義に応じたインクリメントです。これらはスクラムチーム内で不変の 3 つで、時間をかけて再考と投資を繰り返します。

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

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

ヒント

製品がアジャイルであるのと同程度に、フレームワークもアジャイルである必要があります。進行状況を確認するために時間を十分に取り、必要に応じて調整し、一貫性を守るという理由のためだけに何かを強制することがないようにしましょう。

スクラムのセレモニーやイベント

スクラムのフレームワークでよく知られたコンポーネントに、スクラムチームが定期的に実施する連続的なイベント、セレモニー (ミーティング) があります。セレモニーではチームによる差異がもっとも顕著に出ます。たとえば、このようなセレモニーをすべて実施するのは面倒で同じことの繰り返しだと捉えるチームもあれば、必要な確認の機会と見なすチームもあります。まずスプリント 2 回分はすべてのセレモニーを実施し、様子を見るようお勧めします。その後、簡単なふりかえりを実施し、調節の必要な箇所があるかを検討します。

 

以下はスクラムチームが参加する可能性のある主なセレモニーの一覧です。

  1. バックログの整理: 別名「バックロググルーミング」。このイベントの責任者はプロダクト所有者であり、その主な職務は製品をそのビジョンへと方向付けることと、市場と顧客を常に把握することです。そのためにユーザーや開発チームからのフィードバックを常にこのリストに反映して優先順位を決める際に役に立てると同時に、リストを整理していつでも作業できるようにします。健全なバックログの維持方法について詳しくはこちらをご覧ください。

  2. スプリント計画: 現在のスプリント中に実行する作業 (スコープ) はこのミーティング中に開発チーム全員で計画されます。スクラムマスターが統率するこのミーティングでチームはスプリントの目標を決めます。決定後、プロダクトバックログから具体的な使用ストーリーをスプリントに追加します。ストーリーは必ず最終目標に沿ったものを選び、スクラムチームはスプリント中での導入可能性について合意します。

    各スクラムメンバーは計画ミーティングの終了時に、スプリントで達成可能な事柄とインクリメントの提供方法を明確に理解している必要があります。

  3. スプリント: スプリントとはスクラムチームが協力してインクリメントを完了する実際の期間を指します。平均的には 2 週間ですが、1 週間または 1 か月がスコープや有用なインクリメントの提供に最適であると考えるチームもあります。Scrum.org の Dave West 氏は、作業が複雑で不明事項が多いほど、スプリントは短い方が望ましいと助言していますが、最終的にはチームの判断に委ねられます。また、うまくいかない場合は恐れずに変更した方が賢明です。スプリント中、プロダクト所有者と開発チームは必要に応じてスコープについて再度協議します。これはスクラムの実証的な性質の核心となる部分です。

    計画からふりかえりまで、すべてのイベントはスプリント中に発生します。スプリントの期間が定着したら、開発期間を通してその間隔を守り、チームが過去の経験から学び、学んだものをその後のスプリントに適用しやすくします。

  4. デイリースクラムまたはスタンドアップ: 毎日同じ時刻 (通常朝) に同じ場所で開催されるごく短時間の手軽なミーティングです。15 分以内に抑えるチームが多いものの、必ずそうしなければならないわけではありません。簡潔さに重点を置くために「デイリースタンドアップ」と呼ばれることもあります。デイリースクラムの目標は、チームメンバー全員が認識を共有し、スプリントの目標をすり合わせて、今後 24 時間の計画を立てることにあります。

    スタンドアップはスプリントの目標達成や障害に関する懸念を発表する機会となります。

    スタンドアップは通常、スプリントの目標達成に関して各チームメンバーが次の 3 つの質問に答える形で進行します。

    •      きのう何をしたか?
    •      今日は何をする予定か?
    •      障害となるものはあるか?

    残念ながら、このミーティングがメンバーにとって昨日と翌日のカレンダーの内容を読み上げる場に化しているケースを目にします。スタンドアップの趣旨は、雑多な議論はデイリーミーティングに回して、チームがその日の作業に集中できることにあります。単なるカレンダーの予定を読み上げる場と化しているのなら、躊躇なく創造的な場となるように刷新を図ってください。

  5. スプリントレビュー: スプリントの終了時に、チームはインクリメントのデモを見たり点検したりする非公式セッションのために集合します。開発チームは関係者とチームメイトからフィードバックを得るために "完了" しているバックログアイテムを共有します。インクリメントのリリースの決定権はプロダクト所有者にありますが、リリースされるケースがほとんどです。

    このレビューミーティングはプロダクト所有者が現在のスプリントに基づきプロダクトバックログを修正する機会でもあります。こうした修正は次のスプリント計画セッションに反映されます。1 か月のスプリントでは、スプリントのレビュー時間は最大 4 時間程度になるように配慮します。

  6. スプリントのふりかえり: ふりかえりでは、スプリント、プロジェクト、人材、関係、ツール、特定のセレモニーに関して効果的だったことと、効果的でなかったことをチームが協議し、文書にまとめます。ふりかえりの目標は、失敗したことより、効果的だったことおよび次回改善が必要なことにチームの意識を集中させる場を設けることにあります。

スクラムを成功に導く 3 つの基本的な役割

スクラムチームには、プロダクト所有者、スクラムマスター、開発チームという 3 つの役割が必要です。スクラムチームは部門を超えて結成されるため、開発チームには開発者に加え、テスター、デザイナー、UX スペシャリスト、運用エンジニアが含まれます。

スクラムのプロダクト所有者

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

  • プロダクトバックログの作成と管理を行う。
  • 業務部門およびチームと緊密に連携し、全員がプロダクトバックログの作業項目を理解できるよう徹底する。
  • 次にデリバリーする機能に関して明確なガイダンスをチームに与える。
  • デリバリー頻度が高くなりやすいプロダクトのリリース時期を決定する。

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

スクラムマスター

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

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

スクラム開発チーム

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

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

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

スクラム、カンバン、アジャイル

スクラムは特に人気の高いアジャイル型フレームワークで、スクラムとアジャイルはよく混同されています。ほかにも、カンバンのように幅広く採用されているほかのフレームワークもあります。スクラムとカンバンのハイブリッドモデルの採用を選ぶ会社もあり、"スクランバン" や "カンプラン" の名前で呼ばれていますが、実質的にはバックログを使うカンバンです。

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

スクラムでは比較的短い一定期間のイテレーションに重点をおきます。スプリントの期間が決定すると、そのスプリントサイクル中に実装できるプロダクトバックログやストーリーを決定できます。ところがカンバンでは、現在のサイクルで実装するタスク数や仕掛品の数 (WIP 制限) が最初に固定されます。その後、これらの機能を実装する時間を逆算します。

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

スクラムが必要な理由

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

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

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


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

Claire Drumond
Claire Drumond

Claire Drumond is a marketing strategist, speaker, and writer for Atlassian. She is the author of numerous articles published on the Trello and Atlassian blogs and is a regular contributor to various publications on Medium including HackerNoon, Art+Marketing, and PoetsUnlimited. She speaks at tech conferences around the world about agile, breaking down silos, and building empathy.

Up Next
Sprints