はじめに
あらゆる業界で変化のスピードが加速するにつれてビジネス環境は複雑性を増し、そのソリューションとして開発されるソフトウェアの数も増え続けています。
一方、ソフトウェア開発の現場では、そうした変化により迅速に対応するため従来のウォーターフォール開発に代わり、アジャイル開発を取り入れることが増えてきています。
関連記事
あらためて、アジャイル開発とは|その概要から進め方、メリット・デメリット、開発手法について
そうした中で、アジャイル開発手法の1つとして、特に複雑で難しい問題に対応するために開発された「スクラム」および「スクラム開発」に対する注目が高まっています。
そこで、本連載記事ではスクラムの開発者が記した執筆時点での最新版となるスクラムガイド2020年版を解説しながら、スクラムとスクラム開発についてご紹介します。
<スクラム連載記事一覧>
1. スクラムとは|スクラムの定義や特徴、体制とチーム内の役割
2. スクラムイベントとは|スクラムにおけるスプリントと4つのイベント
3. スクラムの3つの作成物|プロダクトバックログ、スプリントバックログ、インクリメントについて
スクラムガイドとは
はじめに、そもそもスクラムガイドとは何かについてご紹介します。
スクラムガイドとは、スクラムを開発したKen Schwaber(ケン・シュエイバー)とJeff Sutherland(ジェフ・サザーランド)によって執筆された、スクラムの公式ガイドです。
2010年にスクラムガイドの最初のバージョンが発行され、以降継続的に更新されています。
スクラムは、もともとはソフトウェア製品開発の領域での問題に対応するために開発されたものですが、近年では複雑な作業を必要とする広範かつさまざまなドメインでスクラムが採用されていることから、世界中の人々がスクラムを理解できることを目的にスクラムガイドは執筆されました。
実際に、スクラムの広がりによって開発者だけでなく、研究者やアナリストといった幅広い領域の専門家もスクラムを利用するようになっています。
スクラムガイドはスクラムを理解・活用するための最も基本的な指針であり、いわゆる「スクラムにおけるバイブル」と言っても良いでしょう。
スクラムおよびスクラム開発とは
スクラムガイドによると、スクラムは以下のように定義されています。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。
あらゆる変化のスピードや複雑性が増す現代において、将来を正確に予想し適切な計画を事前に立てることはますます困難になってきています。
特に対応が難しい複雑な問題であれば、対応の過程で初めて正しい理解が得られるということも少なくないほか、場合によっては計画段階で見込んでいた条件や状況が実行段階になって大きく様変わりしてしまうことすらあります。
このように事前にいかに綿密に計画を立てて臨んだとしても、そもそもの前提や課題自体が変化してしまうこともあるため、スクラムでは適応型ソリューション(adaptive solutions)を採用しています。
このソリューションは、長期的な予想に基づいてあらかじめ綿密な計画を立てる代わりに、日々のチームの学習や経験によって段階的に改善するというアプローチを取ることから適応型ソリューションと呼ばれます。
また、スクラムは軽量なフレームワークであり、厳密で詳細な指示の代わりに、人々やチーム、組織が価値を生み出すために最低限必要となる枠組みのみを提供します。
この枠組みにはスクラムの価値観や体制(チーム)と役割、イベント、作成物などが含まれますが、具体的な手順やプロセスといったものは含まれません。
そのため、厳密で決まりごとの多い重厚なフレームワークとは対照的に、スクラムは「軽量級フレームワーク」であるとされています。
ちなみに、なぜスクラムがラグビーの「スクラム」と同じ名前なのかが気になった方もいるかもしれませんが、その理由はこのフレームワークがそもそもラグビーの「スクラム」になぞらえて命名されたものであるからです。
参照:The New New Product Development Game
こちらの論文「The New New Product Development Game」は1986年に野中郁次郎氏と竹内弘高氏によって発表されたもので、日本の製造業による新製品開発手法をラグビーのスクラムに例えて紹介しました。
この論文に着想を得たエンジニアのKen Schwaber(ケン・シュエイバー)とJeff Sutherland(ジェフ・サザーランド)が、ソフトウェア開発にこの手法を取り入れて実践し、フレームワークとして開発したものがスクラムの元になっています。
このように、スクラムはもともとソフトウェア開発のために考案されたものであり、スクラムはソフトウェア開発におけるアジャイル開発手法の1つです。
また、特にスクラムのフレームワークを用いてソフトウェア開発を行うことを「スクラム開発」と呼びます。
詳しくは後述しますが、スクラムではプロダクトゴールの達成を目的として「開発者」「プロダクトオーナー」「スクラムマスター」の3つの役割からなる小さなチーム(通常は10人以下)を構成します。
そして、スクラムチームが成果物をつくる工程である「スプリント」を比較的短い期間で何度も繰り返し、そのなかで得られた情報やステークホルダーからのフィードバック、移り変わる状況などに素早く柔軟に対応しながら、本当に価値のあるプロダクトを開発していきます。
「スクラム」は、今や一般的なソフトウェア開発手法の一つとして多くの現場にて取り入れられています。
それを裏付けるデータの一つとして、2021/10/10~2024/10/10の直近3年間のソフトウェア開発のキーワードとしての「スクラム」のGoogleトレンドを見ると、スクラムは一時的な流行りではなく、長期的に安定した人気や関心を集めていることがわかります。
スクラムの特徴
スクラムの特徴として、「経験主義」と「リーン思考」に基づいているということが挙げられます。
経験主義とは、物事を理論より経験に基づいて考えようとする態度であり、スクラムガイドにおいては「知識は経験から生まれ、意思決定は観察に基づく」とあります。
スクラムにおいては、高まる複雑性・不確実性に対応するには、実践と経験による知識が極めて重要であると考えていることがわかります。
またリーン思考に基づいて、価値を生み出さない無駄なアクティビティを省き、本質にフォーカスすることが求められます。リーンによって未完了の作業を最小限にすることができ、それは無駄を減らすことにつながります。
経験主義のスクラムにおいては、以下の三本柱「透明性」「検査」「適応」を実現することで初めて、スクラムが機能するとされています。
透明性(Transparency)
プロセスや作業、それらの状況や課題がチーム内で可視化されている状態を指します。
透明性を担保することで、検査が可能となります。
検査(Inspection)
変化や問題、リスクを検知するために、現状を正確に把握することを指します。
検査によって、適応が可能となります。
適応(Adaptation)
プロセスやプロダクトに異常が生じた場合に、それらの修正や改善を行うことを指します。
検査によって得られた情報をもとにできるだけ早く対応し、逸脱を最小限に抑え適切な方向に素早く修正することが期待されます。
つまり、あらゆる状況をスクラムのチームメンバーが相互に把握できる状態を維持・強化し、頻繁に検査を行うことで問題を早期に発見し、素早く修正を行うという漸進的なアプローチに特徴があると言えます。
スクラムの体制
スクラムガイドでは、スクラムの体制について以下のように定義されます。
スクラムの基本単位はスクラムチームという小さなチームであり、ひとつの目的(プロダクトゴール)に集中している専門家が集まった単位である。
スクラムチームはスクラムマスター1人、プロダクトオーナー1人、複数人の開発者で構成され、通常は10人以下である。
一般的に小さなチームの方が生産性が高いと言われており、このサイズは敏捷性を維持するために十分に小さく、同時に必要な作業を完了するために十分に大きいサイズであるとされています。
またスクラムチームは自己管理型であるとされ、「誰が何を、いつ、どのように行なうか」をスクラムチーム内で決定することができる能力を備えているとともに、チーム内で作業を管理できる権限が与えられています。
これはすなわち、スクラムチームを構成するメンバーには特定の能力や資質、態度が求められるということを意味します。
スクラムガイドでは、チームメンバーは以下のような条件を満たすとされています。
・スクラムを構成するのは、作業に必要なすべてのスキルや専門知識をグループ全体として備える。また必要に応じてそうしたスキルを共有または習得できる人たちである
・スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている
・お互いに能力のある独立した個人として尊敬し、一緒に働く人たちからも同じように尊敬される
・スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ
これらはあくまでもスクラムガイドにおける定義であり、一つの理想的な状態が示されています。
スクラムのチームは「こうあるべき」というモデルケースとしてとらえ、全体として作業に必要なスキルを持つ、もしくは共有・習得できるチームとなるようにメンバーを選択するなど、チーム組成の際に参考とするのが良いでしょう。
またスキルと同時にチームメンバーとしてあるべき態度についても明確に示されていることから、これらの態度を善とする価値観をチームで共有することで、スクラムチームをより強化することが可能となります。
スクラムチームにおいてこちらの内容を完璧に満たすことは現実的には困難ですが、チーム組成における指針としては非常に役立つのではないでしょうか。
スクラムチーム内の役割
スクラムガイドでは、スクラムチームにおける「開発者」「プロダクトオーナー」「スクラムマスター」という3つの役割とその責任を定義しています。
開発者
はじめに、スクラムでは「開発者」という言葉が使われていますが、これは必ずしもエンジニアのことを指しているわけではありません。
スクラムにおける「開発者」とは、利用可能なインクリメント(完成の定義が満たされ、リリース可能な成果物)を作成する役割とされています。
つまり、ここでの「開発者」は、何をゴールとし何を作成するかによって変わるということです。
あるスクラムチームにおける開発者はエンジニアであり、またデザイナーやライターであることもあります。
開発者は、以下の4つの責任を持つとされています。
・ スプリントの計画(スプリントバックログ)を作成する
・ 完成の定義を忠実に守ることにより品質を作り込む
・ スプリントゴールに向けて毎日計画を適応させる
・ 専門家としてお互いに責任を持つ
スプリントとは短期間(1ヵ月以内が推奨される)の開発や作業が行われる工程を指します。開発者はスプリントにおいて行う作業や成果物を計画し、完成の定義を満たす成果物の作成にあたります。
作業においては常に透明性を保ち状況を可視化させながら、課題や学習した内容をスクラムチームで共有し、日々計画を修正・改善します。
そして各自が目的を達成するために必要なスキル・知識を有する専門家が集まるチームの一員として、これらの責任を果たすことが求められます。
プロダクトオーナー
プロダクトオーナーとは、その文字通りスクラムチームから生み出されるプロダクトのオーナーであり、責任者です。責任者としてプロダクトの価値を最大化する責任を持ちます。
顧客や社内外の関係者のニーズをもとに、プロダクトバックログと呼ばれるプロダクトの改善に必要なものの一覧を作成・管理することが、特に重要な責任の1つとされます。
具体的には、以下の4つの責任が挙げられています。
・ プロダクトゴールを策定し、明示的に伝える
・ プロダクトバックログアイテムを作成し、明確に伝える
・ プロダクトバックログアイテムを並び替える
・ プロダクトバックログに透明性があり、見える化され、理解されるようにする
プロダクトオーナーはさまざまなステークホルダーのニーズをもとに、プロダクトゴールとプロダクトバックログアイテムを作成し、スクラムチームに正しく正確に伝える責任があります。
また、各プロダクトバックログアイテムには優先順位を割り振る必要があり、優先順に従って並べ替えられます。適切に優先順位をつけるために、プロダクトオーナーはビジネスの環境やチームの状況、その他さまざまな複合的な情報を取得・整理し、判断する必要があります。
特に多くの関係者が含まれる場合は、頻繁にコミュニケーションや調整の機会が発生しますが、それもプロダクトオーナーの重要な役割の1つです。
プロダクトバックログアイテムの追加や並び替えは、ステークホルダーによってなされることもあるとされていますが、その場合でも必ず責任者であるプロダクトオーナーの許可を取ることが必要です。
また、プロダクトバックログは常にスクラムチームで理解・共有されるよう、透明性を持ち可視化されていることが重要です。
スクラムマスター
スクラムマスターとは、スクラムチームや組織においてスクラムの理論とプラクティスの理解を支援し、スクラムを確立させ有効に機能させる責任を持つ役割です。
混同されがちなスクラムマスターとプロジェクトマネージャーとの違いとしては、プロジェクトマネージャーはプロジェクトの責任者としてプロジェクト全体を管理し、自らがチームを指揮して計画の立案や意思決定を行うのに対し、スクラムマスターはスクラムチームの管理は行わず、チーム全体を支援しながらスクラムのフレームワークの導入・定着を促進し、スクラムの成果の最大化を図ります。
スクラムマスターは、自らがトップに立ち組織を引っ張るというよりも、サーバントリーダーとして組織に奉仕するリーダーであることが望ましいとされています。
スクラムマスターの支援範囲は幅広く、様々な形で組織全体やスクラムチーム、プロダクトオーナーを支援します。
具体的には、以下のような形で支援するものとされています。
・ 自己管理型で機能横断型のチームメンバーをコーチする
・ スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できるよう支援する
・ スクラムチームの進捗を妨げる障害物を排除するように働きかける
・ すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守られるようにする
・ 効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援する
・ 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう
・ 複雑な環境での経験的なプロダクト計画の策定を支援する
・ 必要に応じてステークホルダーとのコラボレーションを促進する
・ 組織へのスクラムの導入を指導・トレーニング・コーチする
・ 組織においてスクラムの実施方法を計画・助言する
・ 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう
・ ステークホルダーとスクラムチームの間の障壁を取り除く
スクラムマスターは支援型のリーダーであることが望ましいとされ、チームのメンバーがスクラムチームの定義を満たすよう(望ましい状態に近づくよう)コーチングを行います。
関連記事
サーバントリーダーシップとは|注目を集める、支援型リーダーのあり方
コーチングの内容には「自己管理型」「機能横断型」といったスクラムチームが備えるべき特徴に加え、経験主義やその三本柱である「透明性」「検査」「適応」など、スクラムにおいて重要とされる考え方や価値観の浸透も含まれます。
また組織やステークホルダーに対しても、スクラムへの理解やその導入・実践を行うために指導を行います。
またスクラムチームが作業に集中できるように、あらゆる障害や障壁を取り除き、課題の解決も支援します。
そのためにはあらゆる活動が含まれる可能性があり、場合によってはミーティングのファシリテートを担当することや、関係者を集めたイベントを開催するといったこともあり得るでしょう。
さらに、プロダクトの計画の策定やゴールの定義、プロダクトバックログの管理といったプロダクトオーナーが果たすべき役割の支援など、スクラムマスターが果たす役割は多岐に渡ります。これらを通じ、スクラムマスターは自律的に学び改善し続けるスクラムチームを構築し、組織にスクラムを浸透させるとともに、関係するさまざまなメンバーがスクラムを理解し、サポートするような環境を形成できるよう支援します。
このように、スクラムマスターはスクラムの成否に関わる非常に重要な役割を果たすと言えます。
ここまでスクラムの定義や特徴、その体制と役割について紹介をしてきましたが、スクラムガイドではその他にスクラムにおけるイベントや作成物についても詳しく述べられています。
続編となる「スクラムイベントとは|スクラムにおけるスプリントと4つのイベント」では、スクラムにおいて具体的に「いつ」「誰が」「何をするのか」といった運用に関するトピックとして、「スクラムイベント」についてご紹介しています。
宜しければ、合わせてご参照ください。
お問い合わせContact
ご不明点やご相談などがありましたら、お気軽にお問い合わせください。