スクラムマスターとは？役割・スキル・資格の基礎知識を解説

アジャイル手法によるプロジェクト管理を紹介

この電子書籍では、組織はどのようにアジャイルを導入すれば機敏性の高い効果的な職場を作れるのかなど、アジャイルについて深く掘り下げています。

電子書籍を無料ダウンロード

スクラム開発とは？

スクラム開発 (Scrum) とはアジャイル手法のひとつです。少人数のチームに分かれ、短期間の開発サイクルをくり返し行うフレームワークです。チームのコラボレーション向上を促し、インパクトの大きな仕事の達成をサポートします。

スクラム開発のメリットは、価値観、役割、ガイドラインの設計図を明確化することにあります。これにより、チームが反復と継続的な改善に集中できるようになります。

スクラムの歴史

現在の形の「スクラム開発」は、竹内弘高氏と野中郁次郎氏によって書かれた 1986 年のハーバード・ビジネス・レビューの記事 The New New Product Development Game で初めて紹介されました。竹内氏と野中氏はラグビーから「スクラム」と名付けました。「ラグビーのように、ボールがチーム内で受け渡され、チームがユニットとしてフィールドを進んでいく」ことを表しています。

1995 年に、スクラムは Ken Schwaber 氏と Jeff Sutherland 氏によって発表されたアジャイルマニフェストと SCRUM Development Process によってさらに発展しました。この時点で成文化され、現在の形が確立されています。

Schwaber 氏と Sutherland 氏のスクラムは、ウォーターフォールモデルとは対照的なアプローチです。ウォーターフォールモデルではプロジェクトを一連のフェーズに分割し、各フェーズの成果物が完成すると次のフェーズに進みます。より柔軟で反復的なアプローチを取ることで、顧客にとって最高の製品を開発できると考えました。

その後、Schwaber 氏と Sutherland 氏は定期的に更新を続けるスクラムガイドを発表しました。スクラムガイドはチームに「自分たちの仕事のテクニックがどれほど効果的であるかを確認させ、継続的に進化・改善させようとする」ものです。

ワークマネジメントとは？チームがワークマネジメントを必要とする理由

この電子書籍では、ワークマネジメントとは何かを解説し、ビジネスにどう役立つかをご紹介します。

電子書籍をダウンロード

スクラムの仕組みと流れ

スクラム開発は「スプリント」という通常 2 週間程度の作業セッションで行われます。各スプリントの終わりまでに特定の成果物を作成します。スクラムにはさらに「デイリースタンドアップ」と「スプリントの振り返り」という 2 つの重要なイベントがあります。

スクラム開発を始める前に、「完了」とはどういう意味かについてチームで共通認識を持つことが、円滑な進行の鍵です。スプリントの初めには情報が少なくても、途中で得た情報に基づいてプロセスと要件を調整できます。

スクラム開発プロセスは、以下の 6 つのステップで進行します。

1. バックログを整理する

スクラムスプリントを始めるには、まずチームリーダー (スクラムマスター) が、バックログから取り組む仕事を決定します。製品バックログは一か所で文書化し、プロジェクト管理ツールで管理するのがおすすめです。

あらゆる仕事の課題解決に、Asana。

仕事を最大限効率化し、チームの生産性を上げるためには、Asana のプロジェクトマネジメント機能をお試しください。日々の業務と目標をつなげ、「誰が・何を・いつまでに行うのか」を可視化します。

Asana とは？

2. スプリント計画セッションを開く

スクラムスプリントを始める前に、そのスプリントでバックログのどの仕事に注力するのかを決定します。これをスプリント計画 (スプリントプランニング) と呼びます。テンプレートを活用すると効率的に進められます。

3. スクラムスプリントを開始する

通常、1 つのスプリントは 2 週間続きます。チームの状況に合わせて、より短くても、長くてもかまいません。スプリント期間中、チームはスプリント計画セッションでまとめたバックログの内容に取り組みます。

4. 毎日のスクラムスタンドアップを開催する

毎日スクラムチームと 15 分間話し合います。デイリースタンドアップミーティングは、進捗状況を共有し、予想外の障害があれば優先度を調整する機会です。デイリースタンドアップ用の無料テンプレートを活用すると効果的です。

5. スプリントレビューで作業内容を報告する

スクラムスプリントが終わったら、チームで集まってスプリントレビューを行います。スクラムチームのメンバーが「完了」した仕事を報告し、関係者の承認やチェックを受けます。

6. スプリントの振り返りで共有、反省を行う

スプリントが終わったら、その感想を共有し、次回以降の改善点について話し合います。この振り返りはレトロスペクティブと呼ばれます。スクラム開発では継続的な改善に重きが置かれているため、新しいプロセスを試し、効果が少ない戦略は修正しましょう。スプリント振り返りはテンプレートを活用して効率化できます。

スクラムチームの役割

スクラムでは主に 3 つの役割があります。

1. プロダクトオーナー

プロダクトバックログの責任者です。ユーザーの要望を把握し、ユーザーの体験談をチームや経営陣の関係者に伝えることに重点を置きます。次に何を納品すべきかを明確にし、納品物が出荷できる状態かどうかを最終判断します。

2. スクラムマスター

スクラムマスターはさまざまなスクラムイベントを実行します。スクラムのプロジェクトマネージャー兼進行役として機能します。デイリースタンドアップミーティングを進行し、スプリント計画・スプリントレビュー・振り返りミーティングを開催します。

3. スクラムチーム

スクラムチームはスプリントに取り組むすべての人々を指します。チームメンバーは継続的な改善という目標を達成すべく、自己組織化し、協力的に動く必要があります。

Asana を使った製品リリース完全ガイド

Asana の製品マーケティング部門長が Asana を使ってどう製品リリースプロセスを管理しているのか、その秘訣をご紹介します。

電子書籍をダウンロードする

スクラムマスターの役割と責務

スクラムマスターは、スクラムガイドで定義されたフレームワークをチーム内に確立させることに責任を持つ存在です。チームの管理者ではなく、チームが自律的に判断し行動できる状態を保つために、障害を取り除き、プロセスを改善し続けます。

スクラムマスターの責務は大きく 3 つの領域に分かれます。

チームへの支援

スクラムマスターは、開発チームが自己組織化できるよう支援します。デイリースクラムの進行、スプリントゴールへの集中の維持、チーム内の課題の可視化などを通じて、チームが最大限の力を発揮できる環境を整えます。

具体的には、スプリント中に発生する技術的・対人的な障害を早期に特定し、チームと協力して解消に取り組みます。チームに指示を出すのではなく、チーム自身が解決策を見つけられるよう問いかけや対話を通じて導くことが重要です。

プロダクトオーナーへの支援

プロダクトオーナーが価値の判断に集中できるよう、優先順位の整理やステークホルダーとの対話の場を整える支援を行います。プロダクトバックログのリファインメントを補佐し、バックログ項目が明確で見積もり可能な状態を維持することで、意思決定の質を高めます。

プロダクトオーナーとの連携が弱いと、スプリントの方向性がぶれやすくなります。スクラムマスターはこの橋渡し役を担い、チームとプロダクトオーナーの間で情報の透明性を確保します。

組織への働きかけ

チームの外にある障害を特定し、関係者と対話しながら改善を推進することもスクラムマスターの重要な責務です。承認フローの遅延、部門間連携の課題、外部依存の問題など、チーム単独では解決できない構造的な障壁に取り組みます。

スクラムの理論と実践を組織全体に浸透させることで、チームが持続的に成果を出せる土壌をつくります。この組織変革の推進者としての役割が、スクラムマスターを単なる進行役と区別するポイントです。

スクラムマスターとプロジェクトマネージャーの違い

スクラムマスターとプロジェクトマネージャー (PM) は混同されやすい役割ですが、責任範囲と立ち位置が根本的に異なります。

スクラム開発にはプロジェクトマネージャーという役割は定義されていません。従来 PM が担っていた品質、コスト、納期の責任は、プロダクトオーナー、スクラムマスター、開発チームの 3 つの役割に分散されます。

PM 経験者がスクラムマスターに転向する場合、最も大きな変化は「管理する」から「支援する」への意識転換です。チームに答えを与えるのではなく、チームが自ら答えを見つけるプロセスを促進する姿勢が求められます。

スクラムマスターに必要なスキル

スクラムマスターとして効果的に活動するには、技術的な知識だけでなく対人スキルが重要です。以下の 5 つが代表的なスキルです。

• ファシリテーション力: スクラムイベントを効果的に進行し、チーム全員が発言しやすい場をつくる能力です。議論が停滞したときに適切な問いを投げかけ、合意形成を導きます。

• コーチング力: アジャイルの原則をチームに浸透させ、自律的な行動を引き出す能力です。指示ではなく問いかけを通じて、メンバーの気づきと成長を促します。

• 問題解決力: チームの障害を特定し、根本原因にアプローチして解消する能力です。表面的な対処ではなく、再発防止まで視野に入れた対応が求められます。

• コミュニケーション力: チーム内外の関係者と透明性の高い情報共有を行う能力です。技術チームと非技術チームの間で、意図が正確に伝わるよう橋渡しします。

• 共感力: チームメンバーの課題や状況を理解し、適切なサポートを提供する能力です。メンバーが安心して課題を共有できる心理的安全性の構築に寄与します。

これらのスキルは一朝一夕で身につくものではなく、スクラムの実践と振り返りを通じて継続的に磨かれます。

スクラムマスターの資格と認定制度

スクラムマスターとしてのスキルを客観的に証明する認定資格は複数あります。代表的な 3 つの資格を比較します。

初めてスクラムを学ぶ方には、研修付きの CSM や RSM がおすすめです。講師から直接フィードバックを受けられるため、実務に活かしやすい知識が身につきます。

すでに実務経験があり、コストを抑えたい方には PSM が適しています。オンラインで受験でき、スクラムガイドを深く理解していれば独学で合格可能です。

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

スクラム (Scrum) においては、3 つのアーティファクトが存在します。アーティファクトとは課題解決のための道具のようなものです。

• プロダクトバックログ

• スプリントバックログ

• 製品インクリメント

それぞれについて詳しく見ていきましょう。

【プロダクトバックログ】

プロダクトバックログは、やるべき仕事のマスターリストです。プロジェクトマネージャーやプロダクトオーナーによって優先順位がつけられます。バックログに入っているからといって、すぐにチームの仕事になるわけではありません。

プロダクトバックログの内容は、スクラムスプリント中にチームが取り組める仕事の選択肢です。プロジェクトオーナーは顧客や市場、チームからの情報を基に、バックログの順位を頻繁に見直す必要があります。

【スプリントバックログ】

スプリントバックログは、スクラムスプリント中にチームが取り組む仕事のリストです。スプリント計画セッションで選ばれた項目が含まれます。スプリント計画プロジェクトがある場合はそこに移されます。

1 回のスプリント中にバックログの内容すべてを完了できないこともあります。スプリント中に新しい項目を追加することは避けましょう。頻繁に追加が発生する場合は、スプリント計画フェーズにより時間をかけることをおすすめします。

【製品インクリメント】

製品インクリメントとは、スプリントの終わりに納品するものです。新製品・機能・改善・バグ修正など、チームによって内容は異なります。インクリメントはスプリントレビュー中に提示し、関係者が「完了」かどうかを判断します。

ワークマネジメントツールを活用することで、会議中に議事録をリアルタイムで記録できます。アクションアイテムをその場で作成し、担当者に割り振ることも可能です。

スクラムの原則

スクラム開発には、その適用と有効活用に役立つ 6 つのスクラムの原則があります。

1. 経験的プロセスを管理する

スクラムでは透明性、検査力、適応力が重視されます。

• 透明性: チーム内で進捗や課題、リスクなどの情報が可視化されている

• 検査力: 作成物および進捗は適切に検査されている

• 適応力: 必要な場合は、柔軟かつ迅速に軌道修正を行う

この 3 つは「スクラムの 3 本柱」と呼ばれます。後述する「スクラムの価値基準」と併せて、スクラム開発手法を特徴づける要素です。

2. 自己組織化する

スクラム開発には役割やルールがありますが、すべてのメンバーにタスクや仕事の責任が課されます。責任を共有することで、チームはよりクリエイティブでダイナミックになります。

3. コラボレーションする

スクラムスプリント中や終了後に協力し合うことで、最大限の成果が得られます。

4. 価値観に基づいて優先順位を付ける

スクラムスプリントのゴールは、最高のビジネス価値を提供することです。プロセスの最初から作業に優先順位を付けることが重要です。

5. 時間を区切る

スクラムプロセスにはスプリント、デイリースタンドアップ、振り返りなど、時間ベースのアクティビティが多数あります。継続的な改善を実現するために、仕事の時間を明確に区切ることが鍵です。

6. 反復的に開発する

スクラムでは、最初の製品が完璧である必要はありません。反復的な開発を繰り返すことで、顧客のニーズに対応し、価値観に基づく優先順位に従って製品を改善していけます。

スクラムの価値基準

スクラムを成功させるには、スクラムガイドで定義されている 5 つの価値基準に従う必要があります。

【確約】

スクラムチームは 1 つのユニットです。チームメンバーはお互いを信頼し、スプリントに全力を注ぎます (コミットし)、継続的な改善に専念します。

【勇気】

スクラム開発中、正確な答えのない難題に遭遇することもあります。チームは難しい質問を率直に投げかける勇気と、正直に答える勇気を持つ必要があります。

【集中】

どのスプリントでも、チームは製品バックログから作業します。スプリントの終わりまでに成果物を完成させるために、選んだ作業に集中することが大切です。

【公開】

スクラム中、予期せぬ事態も起こります。メンバーは新しい意見や機会を受け入れ、製品やプロセスの改善に活かす姿勢が求められます。

【尊敬】

コラボレーションはスクラム開発の重要な要素です。チームのコラボレーションを促進するには、他のメンバー、スクラムマスター、そしてスクラムプロセスを尊重する姿勢が不可欠です。

スクラム、かんばん、アジャイルの違い

スクラム、かんばん、アジャイルという手法は、リーン方式のフレームワークという枠組みの中ですべて密接に関連しています。それぞれの特徴や考え方の違いを見てみましょう。

アジャイルとスクラムの違いは？

アジャイルは、継続的な改善を行うのに役立つプロジェクト管理の考え方 (方法論) です。アジャイルチームでは変化への対応と不確実性への対処を重視し、反復的・段階的な開発が行われます。スクラムとかんばんは、どちらもアジャイル方法論のひとつです。

スクラムを使っているのなら、それはアジャイルチームだと言えます。ただし、アジャイルはより広い概念で、方針やフレームワーク全体を指します。スクラムはスプリントやスタンドアップ、振り返りなどの具体的な手段を通じて、アジャイルを実践する方法論です。

かんばんとスクラムの違いは？

かんばんフレームワークもアジャイルのひとつです。かんばんは、継続的なプロセスや仕事を管理する視覚的な手段として機能します。かんばんツールを使えば、仕事が完了するまでの動きを視覚化できます。

多くの場合、スクラムを使用するチームはかんばんボードで仕事を視覚化しますが、それがスクラムフレームワークの必須条件というわけではありません。

ウォーターフォール開発との違い

スクラム開発をウォーターフォール型開発と比べることで、それぞれの特性がより明確になります。ウォーターフォール型開発では、要件定義・設計・実装・テスト・リリースという工程を順番に進めます。スクラム開発はスプリントと呼ぶ短いサイクルを繰り返し、各サイクルの終わりに動作する成果物を届けます。

主な違いを以下の観点で整理します。

• 柔軟性: ウォーターフォール型は工程が固定されており、後工程での要件変更が困難です。スクラム開発はスプリントごとに優先順位を見直せるため、変化する要件に対応しやすい設計になっています。

• 成果物の頻度: ウォーターフォール型はプロジェクト最終段階で成果物を届けます。スクラム開発は各スプリントの終わりに製品インクリメントをリリースするため、早期からフィードバックを得られます。

• リスク管理: ウォーターフォール型は終盤まで問題が表面化しにくいリスクがあります。スクラム開発はデイリースタンドアップやスプリントレビューによって問題を早期に発見し、対処できます。

• 適した状況: ウォーターフォール型は要件が明確で変更が少ない案件に適しています。スクラム開発は要件が変化しやすく、継続的な改善が求められる案件に向いています。

どちらの手法が優れているという話ではなく、プロジェクトの性質や組織の状況に応じて使い分けることが重要です。

スクラムのメリットとデメリット

スクラム開発 (Scrum) は、どんなチームにでも合うものではありませんが、製品やソフトウェアの開発チームにのみ有効な手段というわけでもありません。どんなチームもスクラムフレームワークに適応し、継続的な改善を利用して大きな成果を上げることができます。

スクラムのメリット

スクラムは、コードや新機能など典型的な「製品」であれ、マーケティングキャンペーンやクリエイティブアセットなど一般的ではない形の「製品」であれ、頻繁に何かを開発・納品する必要のあるチームで最も効果的です。

スクラム開発のメリットは以下のとおりです。

• 機敏かつ柔軟に仕事をできるようになる

• チームワークが促進され、より効果的な目標達成に役立つ

• スクラムメンバーは製品バックログからタスクを引き出しているため、常に自分が何に取り組んでいるかを正確に把握できる

• 何を「完了」とするか、チーム全員が共通認識を持っているので、目標が何であるかも正確に理解できる

スクラムの制約

スクラムプロセスでは変更が良しとされているため、しばしばスコープクリープに苦しむことがあります。変更が多すぎる場合や顧客フィードバックがバラバラな場合、スプリントを繰り返しても意味ある結果を得られないことがあります。

• 解決策: 各スプリントの目的とインクリメントを明確に定義しましょう。「完了」の基準をチーム全体で明確に理解させ、必要な場合は変更管理プロセスを導入してください。

スクラムチームでは多くのミーティングが開催されます。定期的なスプリント計画・スプリントレビューに加え、毎日のスタンドアップミーティングもあります。

• 解決策: スタンドアップに意味が感じられないようであれば、やり方を変えましょう。記録をつけることで、チームにとって何が役立ち、何がそうでないかが見えてきます。

スクラムは、製品・エンジニアリング・ソフトウェア開発チーム以外への導入が難しい可能性があります (不可能というわけではありません)。

• 解決策: スクラムの導入が決まったら、プロセスがどのように役立つかを明確にしましょう。現在の問題点を特定し、役立つスクラムイベントを挙げてください。最初の数スプリント中にトレーニングセッションを開催することもチームの成功につながります。

スクラム開発に向いているプロジェクト

スクラム開発はあらゆるプロジェクトに適しているわけではありません。以下の特性に当てはまる案件では、スクラムの強みが最大限に発揮されます。

スクラムに向いているプロジェクトの特性

• 要件が変化しやすい: 市場や顧客のフィードバックによって仕様が変わりやすい案件では、スプリントごとに優先順位を柔軟に調整できるスクラムが力を発揮します。

• 頻繁なリリースが必要: 小さな改善を継続的に提供するサービス開発や、段階的にリリースするプロダクト開発に向いています。

• チームが自律的に動ける: スクラム開発は自己組織化したチームを前提とします。メンバーが主体的に動き、互いに情報を共有できる環境が整っている場合に効果的です。

• 複雑な問題を扱う: 正解が最初から明確でない複雑な課題に取り組む際、反復的なアプローチによって徐々に解決策を見つけることができます。

スクラムが難しい状況

• 要件が最初から固定されており変更がほとんど発生しない案件

• チームメンバーが複数プロジェクトを兼務しており、スプリントへの集中が難しい状況

• 短期間の単発プロジェクトで、スクラムのオーバーヘッド (各種ミーティングなど) が負担になるケース

スクラムの導入を検討する際は、現在のプロジェクトの特性とチームの状況を照らし合わせて判断しましょう。

スクラム関連のよくある質問