Close

スクラムの概要と始め方

スクラム・ガイド - その概要、仕組み、開始方法

トピック一覧
アジャイルの矢印

Jira スクラム テンプレートを無料で始める

プロジェクトを合理化して、スプリント間の作業を簡単に計画、追跡、管理しましょう。Jira スクラム テンプレートには、ボード、バックログ、ロードマップ、レポートなどが含まれています!

テンプレートを使用

スクラムとは何か

スクラムはアジャイル プロジェクト管理フレームワークです。チームが一連の価値観、原則、実践を通して作業を構造化して管理するのに役立ちます。大事な試合に向けて練習を積むラグビー チーム (これが名前の由来) と同じように、スクラムがサポートするのは経験を通じて能力を高め、問題に取り組みながら自己管理し、過去の成功と失敗を振り返って継続的に改善するチームです。

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

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

スクラムに関する記事

[続き]

アジャイル vs. スクラム

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

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

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

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

スクラム フレームワークの図

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

スクラム フレームワーク

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

スクラム チームのメンバー

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

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

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

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

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

スクラムマスター

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

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

スクラム開発チーム

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

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

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

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

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

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

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

ヒント

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

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

スクラムのフレームワークには、スクラム チームが定期的に実施するスクラム プラクティス、セレモニー、ミーティングが含まれます。アジャイル セレモニーではチームによる差異がもっとも顕著に出ます。たとえば、このようなセレモニーをすべて実施するのは面倒だしくどいと考えるチームもあれば、必要な確認の機会と見なすチームもあります。まずスプリント 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. スプリントのふりかえり: ふりかえりとは、チームメンバーが集まり、スプリント、プロジェクト、関係、ツール、さらには特定のセレモニーで成功したこと、しなかったことについて記録し、話し合う機会です。ここでのポイントは、次回に備え、成功したことや改善すべきことにチーム全体で集中することにあり、失敗は重点的には取り上げません。

アジャイルの矢印

Jira スクラム テンプレートを無料で始める

プロジェクトを合理化して、スプリント間の作業を簡単に計画、追跡、管理しましょう。Jira スクラム テンプレートには、ボード、バックログ、ロードマップ、レポートなどが含まれています!

スクラムの価値基準

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

コミットメント

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

勇気

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

重点

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

寛容性

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

  • 昨日何に取り組んだか?
  • 今日は何に取り組んでいるか?
  • 障害となっている課題は何か?

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

尊敬

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

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

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

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

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

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

スクラムを開始する

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

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

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

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

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

Claire Drumond
Claire Drumond

Claire Drumond は、アトラシアンでマーケティング戦略、スピーカー、ライターを担当しています。Trello とアトラシアンのブログ記事を多数執筆しているほか、HackerNoon、ART+marketing、PoetsUnlimited などのメディアのさまざまな刊行物に定期的に寄稿しています。世界中のテックカンファレンスでアジャイル、サイロの解体、共感の醸成について講演しています。

アジャイルの矢印

Jira スクラム テンプレートを無料で始める

プロジェクトを合理化して、スプリント間の作業を簡単に計画、追跡、管理しましょう。Jira スクラム テンプレートには、ボード、バックログ、ロードマップ、レポートなどが含まれています!

テンプレートを使用
次の記事
スプリント