こんにちは！
AXLBIT株式会社の@yangです。

本記事はプロジェクトマネージャーを目指している方や、PMP（Project Management Professional）資格を取得したい方を対象に、PMI（プロジェクトマネジメント協会）が発行したガイドブックPMBOKに記載するプロジェクトマネージメントに活用できる知識を説明する【PMP資格保持者が教える】シリーズの第3回です。第2回はこちら

前回ではプロジェクトの開発アプローチの選定について解説しましたが、開発アプローチを選定した後、次はどう開発を進むべきかが問題になります。

例えば適応型アプローチの一種、アジャイルというと、この名称の一つで決定した方法があるわけでもありません、これはただ「短期間で反復を繰り返して要求事項の変化に対応していく開発手法」の総称にすぎません。アジャイル型だけで代表的な以下の手法があります。

スクラム（Scrum）
ユーザー機能駆動開発（FDD：Feature-Driven Development）
動的システム開発手法（DSDM：Dynamic System Development Method）
エクストリーム・プログラミング（XP：eXtreme Programming）
カンバン方式（KANBAN）

今回はこの中のスクラムを詳しく紹介いたします。

概要

スクラムとは、アジャイル・フレームワークの一種で、チームでのコラボレーションを重視し、柔軟で効率的な開発を行うための手法です。

アジャイル型アプローチは短期間で反復を繰り返すことが特徴で、その繰り返しの単位であり、特定の目標を達成するための作業サイクルは通常イテレーションと呼びます。スクラムにおいて、イテレーションのことをまたスプリントとも呼べます。

スクラムチーム

スクラムチームにおいて、通常はプロダクト・オーナー、スクラム・マスター、開発チームの三つの役割があります。

プロダクト・オーナー

プロダクト・オーナーとは、何を開発するかを決める人です、プロジェクトの事業価値に責任を負って、顧客やステークホルダーのニーズを反映し、開発の方向性を示します。

プロダクト・オーナーは通常プロダクト・ビジョンやゴールを策定し、周知します。そして要求事項に対して変更が発生する際、その変更を優先順位をつけるのもプロダクト・オーナーの役名です。

スクラム・マスター

スクラム・マスターとは、プロジェクト全体を支援する人です、従来のコントロール型のリーダーと違って、コーチングやメンタリングを実施したり、障害を取り除くために外部との交渉を行います。

スクラム・マスターが発揮すべきのは奉仕型リーダーシップスタイルをサーバント・リーダーシップと呼びます。チーム・メンバーの意見を聞き、コーチングを行い、成長を可能にする環境を提供することで、チーム・メンバーの自己定義、自己発見、自己認識を促すことを目標とします。

開発チーム

開発チームとは、実際に開発に携わる人です、指示を受け、スプリント内で成果物を作成します。

スクラムにとって、理想的な開発チームは機能横断型、かつ自己組織型のチームです、そしてサブチームや階層は基本的に存在しません。

機能横断型チームとは価値あるプロダクトの増分を創出するのに必要なすべてのスキルを備えた実務者を含むチームのことです、そのため開発チームのメンバーにはT字型スキル（知識の幅が広くて、特定分野に深い理解を持つこと）が望ましいです。

自己組織型チームとは自律的にプロダクトを作り上げることができるチームのことです。

スクラムのスコープ

スクラムでは、プロダクト開発に関する情報を共有し、開発の進捗を可視化するために、通常以下のものでスコープを管理します。

プロダクト・バックログ

プロダクト・バックログとは、優先順位付けされた開発する予定があるすべての機能のリストのことです。通常はプロダクト・オーナーが管理し、機能の事業価値に応じて、優先度を決めます。

プロダクト・バックログには特に決まっている表現方法がないですが、ユーザー・ストーリーで表現することが一般的です。

プロダクト・バックログの洗練は、リファインメント或いはグルーミングと呼びます、プロジェクト全体において継続的に行われます。

プロダクト・オーナーが機能に優先順位をつける場合、よく使われる方法として狩野モデル、MoSCoW分析、一対比較法、100ポイント法があります。

スプリント・バックログ

アジャイル型において、イテレーション内で開発する機能および実行する作業のリストをイテレーション・バックログと呼びます。スクラムにおいて、これをスプリント・バックログと呼びます。

スプリントごとに作成される動く製品の増加分をインクリメントと呼びます。

スプリント・バックログに責任を持つのは開発チームで、それを可視化するためによく使う方法はタスクボードです。

アジャイル型の重要な価値観の一つとして、「計画に従うことよりも変化への対応を重視」がありますから、通常精確な見積はしません。故にスプリント・バックログを作成する際、よく使われるのは相対的な見積になります、それを作成するためによく使われる方法として、Tシャツのサイズ法やプランニング・ポーカーがあります。

そしてスプリントをタイムボックスして、その結果として以下の三つの項目を測定し、次のスプリントの予測に活用するのは一般的なやり方です。

サイクル・タイム：連続した作業の一つの工程に要する時間
スループット：単位時間当たりの処理能力
ベロシティ：開発の速度、一スプリントで完了できるストーリー・ポイント数

完了の定義

完了の定義（DoD：Definition of Done）とは、顧客に成果物が試用できると認められるために、満たすべき基準がすべて記載されたチームのチェックリストのことです。

準備の定義

準備の定義（DoR：Definition of Ready）とは、チームが取り込みを開始するために必要なすべての情報を収めた、ユーザー中心の要求事項に関するチェックリストのことです。

アジャイル・セレモニー

スクラムでは、開発サイクルの中でチームが進捗を確認し、改善を続けるためのアジャイル・セレモニーが実施されます。

スプリント計画

アジャイル型において、今回のイテレーションで行う作業を計画するミーティングを、イテレーション計画と呼びます。スクラムにおいて、それをスプリント計画と呼びます。

スプリント計画はスプリントの開始時に行われ、スプリント期間内に「何ができるか」、「どう達成するか」を明らかにして、スプリント・バックログを作成します。

デイリースクラム

アジャイル型において、毎日開催される10~15分の短い会議で、イテレーションにおける目標へのコミットメントを再確認し、潜在的な障害要因を明白にするミーティングを、デイリー・スタンドアップ・ミーティングと呼びます。スクラムにおいて、それをデイリースクラムと呼びます。

デイリースクラムはチームが日々の作業を調整する場で、プロダクト・オーナーが出席する必要がありません。

チーム全体の進捗の傾向を確認するため、よくバーンアップチャートやバーンダウンチャートを使います。

スプリント・レビュー

アジャイル型において、各イテレーションの最後にプロダクト・オーナー及びその他の顧客ステークホルダー（利害関係者）と行うレビューをイテレーション・レビューと呼びます。スクラムにおいて、それをスプリント・レビューと呼びます。

スプリント・レビューの目的は開発チームがスプリントで開発した機能をデモし、プロダクト・オーナーから受け入れを得て、事業価値を最適化するために早期のフィードバックを得ることです。

レトロスペクティブ

レトロスペクティブとは、スクラム・マスタが推進する、チームが教訓を集め、独自の改善点を特定し、改善計画を作成するための振り返り会議です。

まとめ

スクラムは、チームが自己組織化し、柔軟で迅速な開発を行うためのフレームワークです。プロダクト・オーナー、スクラム・マスター、開発チームがそれぞれの役割を果たし、プロダクト・バックログやスプリント・バックログなどの成果物を活用して、チームで協力してプロジェクトを進めます。

今回はあくまでもスクラムの入門解説で、名前のみを紹介し、その詳細まで説明できないものがありましたが、スクラムの基本を理解し、効果的に活用することで、チームの生産性や品質を向上させることが可能です。

より深く詳しい方法の紹介はまた後日このシリーズの新しい記事にお楽しみにしてください。

本シリーズ集

第1回：【PMP資格所持者が教える】見積手法の解説
第2回：【PMP資格保持者が教える】開発アプローチの比較と選定
第3回：【PMP資格保持者が教える】アジャイル開発フレームワーク・スクラム入門
第4回：【PMP資格保持者が教える】アーンド・バリュー・マネージメントの活用方法の解説

画像の引用元

図1 スクラム
 図2 タスクボード
 図3 バーンダウンチャート