はじめに

あらゆる業界で変化のスピードが加速するにつれてビジネス環境は複雑性を増し、そのソリューションとして開発されるソフトウェアの数も増え続けています。
一方、ソフトウェア開発の現場では、そうした変化により迅速に対応するため旧来のウォーターフォール開発に代わり、アジャイル開発を取り入れることが増えてきています。

関連記事
あらためて、アジャイル開発とは｜その概要から進め方、メリット・デメリット、開発手法について

そうした中で、アジャイル開発手法の1つとして特に複雑で難しい問題に対応するために開発された「スクラム」および「スクラム開発」に対する注目が高まっています。
そこで、本連載記事ではスクラムの開発者が記した執筆時点での最新版となるスクラムガイド2020年版を解説しながら、スクラムについてご紹介します。

＜スクラム連載記事一覧＞
1. スクラムとは｜スクラムの定義や特徴、体制とチーム内の役割
2. スクラムイベントとは｜スクラムにおけるスプリントと4つのイベント
3. スクラムの3つの作成物｜プロダクトバックログ、スプリントバックログ、インクリメントについて

スクラムガイドとは

はじめに、そもそもスクラムガイドとは何かについてご紹介します。

スクラムガイドとは、スクラムを開発したKen Schwaber（ケン・シュエイバー）とJeff Sutherland（ジェフ・サザーランド）によって執筆された、スクラムの公式ガイドです。

2010年にスクラムガイドの最初のバージョンが発行され、以降継続的に更新されています。
スクラムは、もともとはソフトウェア製品開発の領域での問題に対応するために開発されたものですが、近年では複雑な作業を必要とする広範かつさまざまなドメインでスクラムが採用されていることから、世界中の人々がスクラムを理解できることを目的にスクラムガイドは執筆されました。
実際に、スクラムの広がりによって開発者だけでなく、研究者やアナリストといった幅広い領域の専門家もスクラムを利用するようになっています。

スクラムガイドはスクラムを理解・活用するための最も基本的な指針であり、いわゆる「スクラムにおけるバイブル」と言っても良いでしょう。

スクラムおよびスクラム開発とは

スクラムガイドによると、スクラムは以下のように定義されています。

あらゆる変化のスピードや複雑性が増す現代において、将来を正確に予想し適切な計画を事前に立てることはますます困難になってきています。
特に対応が難しい複雑な問題であれば、対応の過程で初めて正しい理解が得られるということも少なくないほか、場合によっては計画段階で見込んでいた条件や状況が実行段階になって大きく様変わりしてしまうことすらあります。

このように事前にいかに綿密に計画を立てて臨んだとしても、そもそもの前提や課題自体が変化してしまうこともあるため、スクラムでは適応型ソリューション（adaptive solutions）を採用しています。
このソリューションは、長期的な予想に基づいてあらかじめ綿密な計画を立てる代わりに、日々のチームの学習や経験によって段階的に改善するというアプローチを取ることから適応型と呼ばれます。

また、スクラムは軽量なフレームワークであり、厳密で詳細な指示の代わりに、最低限の枠組みのみを提供します。
この枠組みにはスクラムの価値観や体制（チーム）と役割、イベント、作成物などが含まれますが、具体的な手順やプロセスといったものは含まれません。

ちなみに、なぜスクラムがラグビーの「スクラム」と同じ名前なのかが気になった方もいるかもしれませんが、その理由はこのフレームワークがそもそもラグビーの「スクラム」になぞらえて命名されたものであるからです。

参照：The New New Product Development Game

こちらの論文は1986年に野中郁次郎氏と竹内弘高氏によって発表されたもので、日本の製造業による新製品開発手法をラグビーのスクラムに例えて紹介しました。
この論文に着想を得たエンジニアのKen Schwaber（ケン・シュエイバー）とJeff Sutherland（ジェフ・サザーランド）が、ソフトウェア開発にこの手法を取り入れて実践し、フレームワークとして開発したものがスクラムの元になっています。

スクラムは、もともとソフトウェア開発のために考案されたものであり、ソフトウェア開発におけるアジャイル開発手法の１つです。
また、特にスクラムのフレームワークを用いてソフトウェア開発を行うことを「スクラム開発」と呼びます。

「スクラム」は、今や一般的な開発手法の一つとして多くの現場にて取り入れられています。
それを裏付けるデータの一つとして、2021/2/26～2024/2/26の直近3年間のソフトウェア開発のキーワードとしての「スクラム」のGoogleトレンドを見ると、スクラムは一時的な流行りではなく、安定的に人気や関心を集めていることがわかります。

参照：Googleトレンド スクラム（ソフトウェア開発）

スクラムの特徴

スクラムの特徴として、「経験主義」と「リーン思考」に基づいているということが挙げられます。
経験主義とは、物事を理論より経験に基づいて考えようとする態度であり、スクラムガイドにおいては「知識は経験から生まれ、意思決定は観察に基づく」とあります。
スクラムにおいては、高まる複雑性・不確実性に対応するには、実践と経験による知識が極めて重要であると考えていることがわかります。

またリーン思考に基づいて、価値を生み出さない無駄なアクティビティを省き、本質にフォーカスすることが求められます。リーンによって未完了の作業を最小限にすることができ、それは無駄を減らすことにつながります。

参照：ソフトウェアのリーン思考入門

経験主義のスクラムにおいては、以下の三本柱「透明性」「検査」「適応」を実現することで初めて、スクラムが機能するとされています。

透明性（Transparency）

プロセスや作業、それらの状況や課題がチーム内で可視化されている状態を指します。
透明性を担保することで、検査が可能となります。

検査（Inspection）

変化や問題、リスクを検知するために、現状を正確に把握することを指します。
検査によって、適応が可能となります。

適応（Adaptation）

プロセスやプロダクトに異常が生じた場合に、それらの修正や改善を行うことを指します。
検査によって得られた情報をもとにできるだけ早く対応し、逸脱を最小限に抑え適切な方向に素早く修正することが期待されます。

つまり、あらゆる状況をスクラムのチームメンバーが相互に把握できる状態を維持・強化し、頻繁に検査を行うことで問題を早期に発見し、素早く修正を行うという漸進的なアプローチに特徴があると言えます。

スクラムの体制

スクラムガイドでは、スクラムの体制について以下のように定義されます。

一般的に小さなチームの方が生産性が高いと言われており、このサイズは敏捷性を維持するために十分に小さく、同時に必要な作業を完了するために十分に大きいサイズであるとされています。

またスクラムチームは自己管理型であるとされ、「誰が何を、いつ、どのように行なうか」をスクラムチーム内で決定することができる能力を備えているとともに、チーム内で作業を管理できる権限が与えられています。
これはすなわち、スクラムチームを構成するメンバーには特定の能力や資質、態度が求められるということを意味します。

スクラムガイドでは、チームメンバーは以下のような条件を満たすとされています。

これらはあくまでもスクラムガイドにおける定義であり、一つの理想的な状態が示されています。
スクラムのチームは「こうあるべき」というモデルケースとしてとらえ、全体として作業に必要なスキルを持つ、もしくは共有・習得できるチームとなるようにメンバーを選択するなど、チーム組成の際に参考とするのが良いでしょう。

またスキルと同時にチームメンバーとしてあるべき態度についても明確に示されていることから、これらの態度を善とする価値観をチームで共有することで、スクラムチームをより強化することが可能となります。
スクラムチームにおいてこちらの内容を完璧に満たすことは現実的には困難ですが、チーム組成における指針としては非常に役立つのではないでしょうか。

スクラムチーム内の役割

スクラムガイドでは、スクラムチームにおける「開発者」「プロダクトオーナー」「スクラムマスター」という3つの役割とその責任を定義しています。

開発者

はじめに、スクラムでは「開発者」という言葉が使われていますが、これは必ずしもエンジニアのことを指しているわけではありません。
スクラムにおける「開発者」とは、利用可能なインクリメント（完成の定義が満たされ、リリース可能な成果物）を作成する役割とされています。
つまり、ここでの「開発者」は、何をゴールとし何を作成するかによって変わるということです。
あるスクラムチームにおける開発者はエンジニアであり、またデザイナーやライターであることもあります。

開発者は、以下の4つの責任を持つとされています。

スプリントとは短期間（1ヵ月以内が推奨される）の開発や作業が行われる工程を指します。開発者はスプリントにおいて行う作業や成果物を計画し、完成の定義を満たす成果物の作成にあたります。

作業においては常に透明性を保ち状況を可視化させながら、課題や学習した内容をスクラムチームで共有し、日々計画を修正・改善します。
そして各自が目的を達成するために必要なスキル・知識を有する専門家が集まるチームの一員として、これらの責任を果たすことが求められます。

プロダクトオーナー

プロダクトオーナーとは、その文字通りスクラムチームから生み出されるプロダクトのオーナーであり、責任者です。責任者としてプロダクトの価値を最大化する責任を持ちます。
顧客や社内外の関係者のニーズをもとに、プロダクトバックログと呼ばれるプロダクトの改善に必要なものの一覧を作成・管理することが、特に重要な責任の1つとされます。

具体的には、以下の4つの責任が挙げられています。

プロダクトオーナーはさまざまなステークホルダーのニーズをもとに、プロダクトゴールとプロダクトバックログアイテムを作成し、スクラムチームに正しく正確に伝える責任があります。

また、各プロダクトバックログアイテムには優先順位を割り振る必要があり、優先順に従って並べ替えられます。適切に優先順位をつけるために、プロダクトオーナーはビジネスの環境やチームの状況、その他さまざまな複合的な情報を取得・整理し、判断する必要があります。
特に多くの関係者が含まれる場合は、頻繁にコミュニケーションや調整の機会が発生しますが、それもプロダクトオーナーの重要な役割の1つです。

プロダクトバックログアイテムの追加や並び替えは、ステークホルダーによってなされることもあるとされていますが、その場合でも必ず責任者であるプロダクトオーナーの許可を取ることが必要です。
また、プロダクトバックログは常にスクラムチームで理解・共有されるよう、透明性を持ち可視化されていることが重要です。

スクラムマスター

スクラムマスターとは、スクラムチームや組織においてスクラムの理論とプラクティスの理解を支援し、スクラムを確立させ有効に機能させる責任を持つ役割です。

混同されがちなスクラムマスターとプロジェクトマネージャーとの違いとしては、プロジェクトマネージャーはプロジェクトの責任者としてプロジェクト全体を管理し、自らがチームを指揮して計画の立案や意思決定を行うのに対し、スクラムマスターはスクラムチームの管理は行わず、チーム全体を支援しながらスクラムのフレームワークの導入・定着を促進し、スクラムの成果の最大化を図ります。
スクラムマスターは、自らがトップに立ち組織を引っ張るというよりも、サーバントリーダーとして組織に奉仕するリーダーであることが望ましいとされています。

スクラムマスターの支援範囲は幅広く、様々な形で組織全体やスクラムチーム、プロダクトオーナーを支援します。
具体的には、以下のような形で支援するものとされています。

スクラムマスターは支援型のリーダーであることが望ましいとされ、チームのメンバーがスクラムチームの定義を満たすよう（望ましい状態に近づくよう）コーチングを行います。

関連記事
サーバントリーダーシップとは｜注目を集める、支援型リーダーのあり方

コーチングの内容には「自己管理型」「機能横断型」といったスクラムチームが備えるべき特徴に加え、経験主義やその三本柱である「透明性」「検査」「適応」など、スクラムにおいて重要とされる考え方や価値観の浸透も含まれます。
また組織やステークホルダーに対しても、スクラムへの理解やその導入・実践を行うために指導を行います。

またスクラムチームが作業に集中できるように、あらゆる障害や障壁を取り除き、課題の解決も支援します。
そのためにはあらゆる活動が含まれる可能性があり、場合によってはミーティングのファシリテートを担当することや、関係者を集めたイベントを開催するといったこともあり得るでしょう。

さらに、プロダクトの計画の策定やゴールの定義、プロダクトバックログの管理といったプロダクトオーナーが果たすべき役割の支援など、スクラムマスターが果たす役割は多岐に渡ります。これらを通じ、スクラムマスターは自律的に学び改善し続けるスクラムチームを構築し、組織にスクラムを浸透させるとともに、関係するさまざまなメンバーがスクラムを理解し、サポートするような環境を形成できるよう支援します。

このように、スクラムマスターはスクラムの成否に関わる非常に重要な役割を果たすと言えます。

ここまでスクラムの定義や特徴、その体制と役割について紹介をしてきましたが、スクラムガイドではその他にスクラムにおけるイベントや作成物についても詳しく述べられています。

続編となる「スクラムイベントとは｜スクラムにおけるスプリントと4つのイベント」では、スクラムにおいて具体的に「いつ」「誰が」「何をするのか」といった運用に関するトピックとして、「スクラムイベント」についてご紹介しています。
宜しければ、合わせてご参照ください。