Close

Atlassian TEAM TOUR Tokyo 2022 の全セッションをアーカイブ配信中!会場実施のセッションもご覧いただけます。期間限定、2023年2月末まで。視聴はこちら >

スクラム

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

トピック一覧

スクラムとは何か

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

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

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

アジャイルの矢印

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

テンプレートを使用する

スクラムに関する記事

[続き]

スクラム フレームワーク

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

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

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

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

スクラムチーム

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

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

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

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

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

スクラムマスター

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

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

スクラム開発チーム

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

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

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

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

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

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

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

ヒント

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

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

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

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

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

  2. Sprint planning: The work to be performed (scope) during the current sprint is planned during this meeting by the entire development team. This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific user stories are then added to the sprint from the product backlog. These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint.

    At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how the increment can be delivered.

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

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

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

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

    スタンド アップは、チーム メンバーが一人ひとりスプリント目標の達成について次の 3 つの質問に答えるやり方が一般的です。

    • 昨日は何をしましたか?
    • 今日は何をする予定ですか?
    • 何か障害はありますか?

    こうすると、ミーティングの参加者が各自、前日や翌日の予定表の確認を始めます。スタンドアップの意図は、雑談を毎日のミーティングに変えて、チームが毎日ミーティング後の作業に集中しやすいようにすることにあります。 そのため、毎日ただ予定表を読み上げるようになったら、安心して内容を変えて創意工夫を織り込んでください。

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

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

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

アジャイルの矢印

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

テンプレートを使用する

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

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

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

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

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

Commitment

Because scrum teams are small and agile, each team member plays a significant role in the team’s success. Therefore, each team member should agree to commit to performing tasks they can complete and not overcommit. There should be frequent communication regarding work progress, often in stand-ups.

Courage

Courage for a scrum team is simply the bravery to question the status quo or anything that hampers its ability to succeed. Scrum team members should have the courage, and feel safe enough, to try new things. A scrum team should have the courage and feel safe to be transparent about roadblocks, project progress, delays, and so on.

Focus

At the heart of the workflow for scrum teams is the sprint, a focused and specified period of time where the team completes a set amount of work. The sprint provides structure but also focus to complete the planned amount of work.

Openness

The daily stand-up fosters an openness that allows teams to talk openly about work in progress and blockers. At Atlassian we often have our scrum teams address these questions:

  • What did I work on yesterday?
  • What am I working on today?
  • What issues are blocking me?

This helps to highlight progress and identify blockers. It also helps to strengthen the team when everyone shares progress.

Respect

The strength of an agile team lies in its collaboration and recognizing that each team member contributes to work in a sprint. They celebrate each other’s accomplishments and are respectful to one another, the product owner, stakeholders, and the scrum master.

Scrum, kanban, and agile

Scrum is such a popular agile framework that scrum and agile are often misunderstood to be the same thing. But there are other frameworks, like kanban, which is a popular alternative. Some companies even choose to follow a hybrid model of scrum and kanban, which has acquired the name of "Scrumban" or "Kanplan," which is Kanban with a backlog.  

Both scrum and kanban use visual methods such as the scrum board or kanban board to track the progress of work. Both emphasize efficiency and splitting complex tasks into smaller chunks of manageable work, but their approaches towards that goal are different.

Scrum focuses on smaller, fixed-length iterations. Once the time period for a sprint is finalized, the stories or product backlog entries that can be implemented during this sprint cycle are then determined. In kanban, however, the number of tasks or the work in progress (WIP limit) to be implemented in the current cycle is fixed at first. The time taken to implement these features is then calculated backward.

Kanban is not as structured as scrum. Other than the WIP limit, it is fairly open to interpretation. Scrum, however, has several categorical concepts enforced as part of its implementation such as sprint review, retrospective, daily scrum, etc. It also insists on cross-functionality, which is the ability of a scrum team to not depend on external members to achieve their goals. Putting together a cross-functional team is not straightforward. In that sense, kanban is easier to adapt whereas scrum can be considered as a fundamental shift in the thought process and functioning of a development team.

スクラムが必要な理由

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

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

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

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

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

Claire Drumond
Claire Drumond

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

次の記事
スプリント