スクラムはアジャイル プロジェクト管理フレームワークです。チームが価値観、原則、実践を通して作業を整理および監督するのに役立ちます。スクラムは、チームが経験を通じて学び、問題に取り組みながら自己組織化し、成功と失敗を振り返って継続的に改善するように促します。

スクラム フレームワークを主に使用するのは誰ですか?

ソフトウェア開発チームとエンジニアリング チームは、変化する要件に適応し、コストを管理するために、スクラム手法を幅広く利用しています。ただし、ユーザーは開発者とエンジニアだけではありません。その原則と教訓は、マーケティング チームから IT チームまで、あらゆる種類のチームワークに適用できます。

スクラムの軸となる継続的な改善が、アジャイルの中核的な原則であることから、スクラムとアジャイルはよく同一視されます。実際は、スクラムは任務を達成するフレームワークを指し、アジャイルは考え方を指します。

アジャイルの考え方は、小規模で頻繁なリリースによって継続的に段階的な改善を行うことに集中しています。「アジャイルに移行」するには、顧客への価値の提供についてチーム全体で考え方を変える取り組みが必要なため、本当の意味ではアジャイルには移行できません。

ただし、スクラムのようなフレームワークを使えば、アジャイル型の思考を始め、日々のコミュニケーションや業務にアジャイル型の原則が根付くよう実践を重ねることができます。

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

• 個々のスタッフとプロセスやツールを介したインタラクション

• 包括的なドキュメントよりも機能するソフトウェアを

• 契約交渉よりも顧客との協調を

• 計画に従って変化に対応を

スクラムは経験主義とリーン思考に基づいています。経験主義では、経験から知識が生まれ、観察する内容に基づいて決定が下されるとしています。

多くの場合、カンバン ボードと組み合わせて使用され、リーン思考では、無駄を減らして必須要素に焦点を当てます。スクラムの理論の基本原則とは、経験主義、リーン思考、反復的な改善です。

これを適切に実行すると、スクラムの実装の構造、実践、継続的な改善の指針となります。

スクラム フレームワークの歴史において、その成功の大きな要因は Jeff Sutherland 氏による先駆的な取り組みです。Sutherland 氏は複雑なソフトウェア開発を管理するという課題に対処するために、1990 年代初頭に Ken Schwaber 氏とともにスクラムを開発しました。

Sutherland 氏はプロジェクト管理に独自の視点をもたらし、チームワーク、適応性、明確なコミュニケーションを重視しました。プレッシャーの強い環境での Sutherland 氏の経験から、スクラムの協調的で反復的な性質が形作られ、複雑な問題に取り組むための強力なツールとなりました。

現在、スクラム チームがどのように業務を整理し、価値をもたらし、継続的に改善しているかを見れば、Sutherland 氏の影響力は明らかです。

スクラムには、反復的なスプリントを通じて価値を提供するために、スクラム マスター、製品所有者、スクラム チームなどの特定の役割と構成要素が必要です。

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

これらのアーティファクトでは製品と製品作成の作業を定義し、スクラム セレモニーは作業を通してスクラム チームを導きます。スクラム チームは部門横断型の小規模な自己管理ユニットで構成されており、各スプリントで価値のある製品のインクリメントを提供する責任を負います。

スクラムは構造化されていますが、適度な柔軟性があり、実行時には各組織のニーズに合わせて、柔軟に調整できます。スクラム チームが成功するために必要な作業方法を具体的に説く理論はたくさんあります。

しかしながら、アトラシアンで 10 年以上アジャイル チームの活躍を支えてきた結果わかったことは、どのフレームワークを選んだとしても、明確なコミュニケーション、透明性、継続的改善への熱意が、あらゆる取り組みの中心になるということです。

それ以外の部分は、お客様次第です。

スクラム チームとは、製品のインクリメントに取り組むことに専念する、小規模で機敏なチームです。通常は 10 人ほどの無駄のない緊密なグループですが、

多くの場合、スプリント内で相当な作業量を完了するには十分な規模です。ほとんどのスクラム チームには、製品所有者、スクラム マスター、開発チームという 3 つの役割が必要です。

製品所有者はその製品の舵取り役であり、ビジネス、顧客、市場の要件を理解することに重点を置いています。

また、それに応じてエンジニアリング チームが行うべき作業に優先順位を付けます。有能な製品所有者とは、次のような人物です。

• 製品バックログの作成と管理を行う。

• スプリント バックログによる管理を活用する。製品バックログを作成し、注文し、透過的に管理することで、効果的な計画と優先順位付けを実現します。

• 業務部門およびチームと連携し、全員が製品バックログの作業項目を理解できるよう徹底する。

• 次に完了する機能に関して明確なガイダンスをチームに提供する。

• デリバリー頻度が高くなりやすい製品のリリース時期を決定する。

製品所有者は必ずしも製品マネージャーと同義ではないことに留意してください。製品所有者の仕事は、開発チームがビジネスにとって最大の価値を確実に生み出せるようにすることです。

製品所有者は個人である必要があります。複数の製品所有者から異なる指示を与えられると、開発チームが混乱します。

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

スクラム マスターの主な責任は、コーチングを行い、障害を取り除き、スクラム プロセスを促進して、スクラム チームの効果を高めることです。これを行うと、チーム全体のパフォーマンスと成果を向上させることができます。

有能なスクラム マスターは、チームの作業を深く理解し、チームが透明性とデリバリー フローを最適化できるようサポートできます。

主幹ファシリテーターとして、スクラム マスターは必要なリソース (要員と物流の両方) のスケジュールを決定します。これらのリソースには、スプリント計画から、スタンドアップ、スプリント レビュー、スプリントのふりかえりまで、あらゆるものが含まれます。

スクラム開発チームが作業を完了します。このチームは持続可能な開発プラクティスの推進者です。

もっとも効果的なスクラム チームとは、緊密であり、同じ場所にいて、通常、5 - 7 人のメンバーで構成されています。チーム規模の調整に当たっては、アマゾン社の最高経営責任者であるジェフ・ベゾス氏の提唱した有名な「2 枚のピザ ルール」、つまり、チーム規模は 2 枚のピザを分け合える範囲に抑えることを基準にする方法があります。

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

すべてのチーム メンバーは相互に助け合い、スプリントが無事に完了するようにします。スクラム チームは各スプリントの計画を推進します。

チームは過去のベロシティを参考にして、そのイテレーションで完了できる作業量を予測します。また、過去のパフォーマンスを活用してキャパシティの情報を伝え、スプリント計画の精度を向上させます。

イテレーションの長さを固定しておくと、開発チームは見積もりとデリバリー プロセスに関して重要なフィードバックを得ることができるため、予測精度が次第に高まります。チームはこの評価に基づいて、次のスプリントで実現できることを慎重に検討します。

スクラム アーティファクトは、スクラム チームが使用する重要な情報で、製品とその作成に必要な作業を定義するのに役立ちます。スクラムには 3 つのアーティファクトがあります。製品バックログ、スプリント バックログ、DoD (完了の定義) に応じたインクリメントです。

スクラム チームは、スプリント時や開発全体にわたって、この不変の 3 点を検討する必要があります。

製品所有者や製品マネージャーが行い、維持する必要がある主な作業のリストです。スプリント バックログの入力となる、さまざまな機能、要件、拡張、修正プログラムが動的にまとめられています。

基本的にはチームの To Do リストです。

製品バックログは製品所有者がこまめに検討を繰り返し、優先順位を付け直しながら維持します。ノウハウの蓄積や市場の変化を受けて、項目の関連性が薄れたり、問題が他の方法で解決されたりする可能性があります。

バックログ項目は顧客価値を最大化するために優先順位が付けられ、提供される機能が顧客満足度と長期的なビジネス価値を直接高めることが保証されます。

これは、開発チームが現在のスプリント サイクルで実装する対象として選んだ項目、ユーザー ストーリー、バグ修正のリストです。スプリント計画時の各スプリントの前に、チームは作業する項目をバックログから選択します。

スプリントバックログは柔軟に扱うことができ、スプリントの途中でも変更できます。とは言えスプリントの基本的な目標 (現在のスプリントで何を達成するか) は変えないでください。

インクリメントは一般的にスプリントのゴールとして知られ、スプリントに基づく利用可能な最終プロダクトです。通常、アトラシアンではスプリント終了時に行われるデモでインクリメントを実演します。デモでは、チームがスプリントで完了したものを示します。

多くの場合、この用語はチームの完了の定義、つまりマイルストーン、スプリントのゴール、フル バージョン、リリース済みエピックなどと呼ばれます。チームが完了をどう定義しているか、スプリントのゴールをあなたがどう定義しているかによります。

たとえば、チームによってはスプリントの最後に顧客に向けて何かをリリースします。この場合の「完了」の定義はリリース済みになります。ご承知のとおり、アーティファクト内であっても、チームはさまざまなパターンを定義できます。

このため、アーティファクトの管理方法に、常に改善できる柔軟性を残しておくことが重要です。完了の定義がチームに過度のストレスを与えているようであれば、もう一度見直して定義を選び直す必要があります。

スクラムのフレームワークには、スクラム チームが定期的に実施するプラクティス、セレモニー、ミーティングが含まれます。アジャイル セレモニーではチームによる差異がもっとも顕著に出ます。

2 回目のスプリントまではセレモニーをすべて実施して、様子を見ることをお勧めします。その後、簡単に見直して、調整する箇所を確認できます。以下は、スクラム チームが参加するすべての主要セレモニーです。

バックログ グルーミングと呼ばれることもあるこのイベントは、製品所有者の責任で実施されます。製品所有者の主な責務は、各製品を所定のビジョンに近づけ、市場や顧客の最新動向を常に把握することにあります。

ユーザーや開発チームのフィードバックを参考にしてこのリストを継続的に管理し、リスト内の優先順位を調整したり、必要な最新情報のみで再構成したりして、いつでも使える状態で維持します。

開発チーム全員が現在のスプリント中に実行する作業 (スコープ) をこのミーティングで計画します。スクラム マスターが、スプリント計画イベントと呼ばれるこのミーティングを主導します。

このミーティング中に、チームはスプリントのゴールを決定し、完了すべき作業を計画します。ここで、具体的なユーザー ストーリーを製品バックログからスプリントに追加します。

これらのストーリーは必ずゴールに合わせて調整します。また、スプリント中の実装が可能であることをスクラム チーム内で合意します。計画ミーティングの終了時には、スクラム チームのすべてのメンバーは、スプリント中に何が提供されるのか、そしてインクリメントがどのように達成されるのかを明確に理解している必要があります。

スプリントとは、スクラム チームがコラボレーションしてインクリメントを完了する実際の期間を指します。このような時間制限のあるイテレーションはスプリントと呼ばれ、通常は 1 週間から 4 週間続きます。

典型的なスプリントの長さは 2 週間ですが、スコープの作成には 1 週間、価値の高いインクリメントを実装し、提供するには 1 か月が妥当とするチームもあります。Scrum.org 所属の Dave West 氏は、作業内容が複雑で、未知の要素が多いほど、スプリントを短く設定するよう推奨しています。

とは言えスプリントの長さは各チーム次第です。スプリントの長さがうまく機能しない場合は、ためらわずに調整してください。この期間中は必要に応じて製品所有者と開発チームでスコープを練り直しても構いません。

スクラムの経験主義的な性質を形づくっているのは主にこの部分です。計画からふりかえりまで、すべてのイベントがスプリント中に発生します。スプリントの期間が具体的に決まったら、開発期間を通して、そのスケジュールを守る必要があります。

そうするとチームが過去の経験に学び、そのインサイトを以後のスプリントで活かせるようになります。

デイリー スクラムまたはスタンドアップ

この毎日のミーティングは、ごく短時間で同時に (通常は朝) 行われるもので、シンプルにまとめるための場です。これらの重要で時間制限のあるミーティングは "デイリー スクラム" と呼ばれ、スプリント ゴールに向けた進捗を調査し、チームのアクティビティを調整し、障害を特定することを目的としています。

多くのチームではこのミーティングを 15 分以内に済ませるよう努めていますが、適宜この時間は増減してください。さっと済ませる必要がある点を強調して、このミーティングは "デイリー スタンドアップ" とも呼ばれています。

デイリー スクラムのゴールは、スプリント ゴールに向けてチーム全員の意識合わせを行い、次の 24 時間の計画を立てることにあります。デイリー スタンドアップ テンプレートを使用すると、ミーティングをすぐに開始し、より速く整理することができます。

スタンドアップとは、スプリント ゴールの達成やブロッカーについての懸念をすべて表明する場です。スタンドアップは、チーム メンバーが一人ひとりスプリント ゴールの達成について次の 3 つの質問に答えるやり方が一般的です。

• 昨日は何をしましたか?

• 今日は何をする予定ですか?

• 何か障害はありますか?

こうすると、ミーティングの参加者は各自、前日や翌日の予定表の確認を始めがちです。スタンドアップの意図は、雑談を毎日のミーティングに変え、チームが毎日ミーティング後の作業に集中しやすいようにすることにあります。

そのため、毎日ただ予定表を読み上げるようになったら、すぐに内容を変え、創意工夫をするようにしてください。

スプリント終了時のセッションではチームが集まり、非公式にインクリメントのデモを確認したり、検査したりします。開発チームが現時点で完了しているバックログ項目を関係者とチームメートに提示し、フィードバックを求めます。

インクリメントをリリースするかしないかの決定権は製品所有者にありますが、多くの場合インクリメントはリリースされます。このレビュー ミーティングは製品所有者が現在のスプリントに沿って製品バックログを作成し直したときにも開き、次のスプリント計画セッションで参考にします。

1 か月のスプリントでは、スプリント レビューの時間は最大 4 時間程度になるよう検討してください。

ふりかえりとは、チームで集まり、スプリント、プロジェクト、関係、ツール、さらには特定のセレモニーで成功したこと、しなかったことについて記録し、話し合う機会です。

ここでのポイントは、次回に備え、成功したことや改善すべきことにチームで集中することであり、失敗は重点的には取り上げません。

2016 年に、スクラムの 5 つの価値基準がスクラム ガイドに追加されました。これらの価値基準は、スクラム チームの作業、アクション、行動の方向性を示しています。アジャイル環境でチームを成功させるには、効果的なコラボレーション、タスクへの取り組み、スクラム原則の順守が不可欠です。

コミットメント

スクラム チームは小規模かつアジャイルであるため、各チーム メンバーがチームの成功に重要な役割を果たします。各チーム メンバーは、自分が完了できるタスクを実行することに取り組み、過度なコミットをしないよう同意する必要があります。

作業の進捗については、多くの場合はスタンドアップで、頻繁にコミュニケーションを取る必要があります。

勇気

スクラム チームにとっての勇気とは、現状や成功する能力を妨げるものに疑問を投げかける勇気です。スクラム チームのメンバーは、勇気を持って、安心して新しいことに挑戦する必要があります。

スクラム チームは、勇気を持って、安心して障害物、プロジェクトの進捗、遅延に関して透明性を保つ必要があります。

重点

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

寛容性

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

• 昨日何に取り組んだか?

• 今日は何に取り組んでいるか?

• 障害となっている課題は何か?

これにより、進捗を強調してブロッカーを特定できます。進捗を共有すると、チームを強化することもできます。

尊敬

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

スクラムは最も広く採用されているアジャイル フレームワークですが、利用できるのはスクラムだけではありません。カンバンでは、固定期間のイテレーションではなく、継続的なデリバリーとフローに重点を置いた別のアプローチを提供します。

カンバンの場合:

• 作業項目はボード上で視覚化され、進行中の作業 (WIP) の制限付きで管理されます。

• チームはキャパシティが解放されて初めて新しい作業を引き受けられるため、安定した継続的なフローを生み出します。

• 決まった役割やセレモニーがないため、カンバンはスクラムよりも柔軟で簡潔です。

カンバンを使用すべき状況:

• 次から次へとタスクを受け取るチーム (サポートや運用など) に最適です。

• 優先順位が頻繁に変わり、固定されたスプリント コミットメントを維持するのが難しい場合に役立ちます。

スクラムを使用すべき状況:

• 段階的な提供、構造、予測可能性が不可欠な製品や機能の開発に最適です。

• 役割、セレモニー、スプリント ゴールを明確に定義することでメリットがあるチームに適しています。

ハイブリッド アプローチ:

チームによっては、両方のフレームワークの要素を組み合わせて、しばしばスクラムバンまたはカンプラン (バックログ付きのカンバン) と呼ばれるものにしています。このハイブリッドにより、チームはカンバンの柔軟性を実行に取り入れながら、スクラムのバックログと計画の規律を維持することができます。

Scrum Alliance は、スクラムの原則への理解を深め、キャリアアップを図りたいと考えている人々のための主要なリソースです。スクラム フレームワークの推進に専念するグローバル組織として、Scrum Alliance はさまざまな認定資格やトレーニング プログラムを提供しています。

これらはスクラム マスター、製品所有者、その他のスクラム実践者向けに設計されています。実際、認定スクラム マスター (CSM) と認定スクラム製品所有者 (CSPO) の資格は特に人気があります。

プロフェッショナルな人材にスクラムの実践と価値の強固な基盤をもたらすものであり、これらの資格を取得することは、アジャイル手法に取り組んでいることを示し、新しいプロジェクト管理とソフトウェア開発の機会につながる扉を開きます。

活気に満ちたコミュニティへのアクセス、継続的な教育、業界で認められた認定資格により、Scrum Alliance は個人や組織がスクラムで成功できるよう支援します。

スクラムやその他のアジャイル手法を採用することは、どの組織にとっても大きな変化となる可能性があり、アジャイル コーチが支援する場でもあります。アジャイル コーチはスクラム チームと緊密に連携して移行をガイドし、チーム メンバーがスクラムの原則を日常作業に適用できるように導きます。

スプリント計画やふりかえりなどのスクラム イベントを進め、コラボレーションとコミュニケーションのベスト プラクティスについてチームにコーチングを行います。アジャイル コーチは、チームの進捗を妨げる障害を取り除く上で重要な役割を果たします。

主なゴールは、スクラム チームが価値の提供に集中できるようにすることです。アジャイル コーチは、カスタマイズされたトレーニングとサポートを提供することで、チーム メンバーがアジャイル プラクティスを取り入れることができるようにします。

これにより、継続的な改善の文化が育まれ、複数のチームやプロジェクトにわたるスクラム チームの有効性が高まります。

経験豊富なスクラム チームでさえ、変更に対する抵抗、方向性の不明確さ、スクラム トレーニングの不足などの課題に直面します。1 つのプロジェクトまたはチームから小規模に始めると、このようなハードルを克服できます。

包括的なトレーニングや継続的なコーチングを行うことで、スクラムとアジャイルの手法での自信が高まります。ゴール、役割、責任が明確になり、全員が足並みを揃えることができます。

定期的なふりかえりとフィードバック セッションは、チームが考察し、適応し、改善するのに役立ちます。これらの課題に早期に取り組むことで、スクラム チームはレジリエンスを構築し、より良いコラボレーションを行い、スクラムのフレームワークで成功することができます。

スクラム チームの進捗と有効性を追跡することは、継続的な改善とプロジェクトの成功に不可欠です。スクラム チームは、スプリント ベロシティ、バーンダウン チャート、顧客満足度スコアを使用してパフォーマンスを測定することがよくあります。

リード タイム、サイクル期間、欠陥密度を監視することで、チームのワークフローと製品品質に関するインサイトも得られます。定期的なスプリント レビューとふりかえりは重要なスクラム イベントです。

これらのレビューにより、チームは自分たちの成果をふりかえり、成長すべき分野を特定し、スプリントを成功裏に完了したことを祝うことができます。これらの指標を一貫して測定し、フィードバックに基づいて行動することで、スクラム チームはプラクティスを強化し、顧客価値を高め、スクラム フレームワークの継続的な成功を確保します。

スクラムのフレームワーク自体はシンプルです。ルール、アーティファクト、イベント、役割はスムーズに理解できます。ゆるやかな規範を提供するスクラムのアプローチでは、開発プロセスから解釈のぶれを排除できます。

ただし、企業ごとに独自の特徴を盛り込める余地もあります。複雑なタスクを管理しやすいユーザー ストーリーに整理すると、複雑なプロジェクトもスムーズに遂行できます。

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

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

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

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