閉じる

スクラム

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

スクラムとは何か

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

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

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

Scrum articles

[続き]

フレームワーク

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

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

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

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

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

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

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

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

ヒント

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スクラムのプロダクトオーナー

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

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

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

スクラムマスター

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

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

スクラム開発チーム

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

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

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

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

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

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

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

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

スクラムが必要な理由

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

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

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


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

 

Claire Drumond
Claire Drumond

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

次の記事
スプリント