「アジャイル開発」は存在しない？ その２ ～Scrum（スクラム）基礎編　～

前回（ https://base.terrasky.co.jp/articles/py78i ）は「Agile」の歴史についてのふりかえりがメインだったので、「これからアジャイル開発とかいうやつを始めようと思うんだけど」とか、「今、現場で困っているんだけど」という人にはあまり興味を引く内容ではなかったかもしれません。なので、今回と次回で数あるAgileな開発手法の内、一番メジャーと言っても過言ではない「Scrum（以下スクラム）」について解説します。

始める前に1点だけ。現時点（2023年8月現在）入手できる最新版のスクラムガイド（2020年）の「スクラムの定義」からは記述が外されてしまっているのですが、以前の版（例えば2017年版）には

と、記述されています。

3つ目が要注意です。また、1つ目の「軽量」というのも、あくまでも「スクラムのフレームワーク自体が」であって、それを成立させること（＝顧客に対して「価値」を提供するという目的を達成すること）のためには、フレームワーク以外にもプロダクトの目的・状況やチーム、周辺との関係性、具体的な開発の道具・方法、プラクティス類など、いろいろと大切なピースが必要になってきます。

ですので、今回はあくまでも「スクラム」についての基礎的な解説に留めて、応用編というか実践におけるスクラムをうまく回すためのコツ・ポイントについては次回のテーマとさせていただきたいと思います。

と、その前に前回の予告通り「アジャイルソフトウェア開発宣言」（いわゆる「アジャイルマニフェスト」）と「アジャイル宣言の背後にある原則（アジャイルソフトウェアの12の原則）」について少し紹介しておきます。
「アジャイルソフトウェア開発宣言」https://agilemanifesto.org/iso/ja/manifesto.html
「アジャイル宣言の背後にある原則」https://agilemanifesto.org/iso/ja/principles.html

このテーマだけでも1本ブログが書けるレベルのトピックなのですが、どんどん本題から離れていってしまうので、2つだけ。
「アジャイルソフトウェア開発宣言」の

　というのは有名ですが、忘れちゃいけないのがこの後に続く一節です。

ココなんですよね。誰も「（プロセスやツールとか、包括的なドキュメントとか、契約交渉とか、計画に従うことのような）左記のことなんかどうでもいい」なんて一言も言っていません。
昔よくあった誤解に「アジャイル開発はソフトウェアさえ作れば良くて、その開発速度を落とすドキュメント作成なんてどうでもいい（作らなくてもいい）」というヤツがありました。

アジャイルソフトウェア開発宣言が世に出て20年以上経ち、平成も終わって令和のこの時代、もうそんな誤解している人はいないと思いますが、、、このあたりの話については昔のブログ
「Salesforce でアジャイル開発をする時の落とし穴」（ https://base.terrasky.co.jp/articles/8h7Ov ）で少し説明していますので、そちらに譲ります。

従来の「いわゆる」Waterfall手法に則る形の、要件定義から始まって、基本設計、詳細設計・・・とドキュメントを作成して、レビューして、、、という手法と比較すると、いわゆるアジャイルな開発手法の場合の方が、ドキュメントの作成量は少なくなると思います。ただ、だからと言って「アジャイルはドキュメント作成しなくていいので、設計書なんて作りません」というのは、ちょっと行き過ぎな感があります。

もちろん、アジャイルな開発においても、プロセスやツールは必要です（Salesforceの場合、Flosumというリリース管理ツールもあります。https://base.terrasky.co.jp/articles/eGmNU ）

次に、「価値（value）」についてです。ただ、こちらについてはまだ筆者の中でも明確な定義ができていません。そのため、現時点では（確度・確信はかなり高いものの）まだ「仮説」ですが、一言でまとめると「顧客が望むもの・こと・状態といったOutcome（成果）」と考えています。

もう少し具体的に言うと、「お金（＝それがリリースされることで得られる利益、ないしは削減できた損失）」や、「時間」、「ブランド」といった有形・無形の「成果」のことになるかと思います。（厄介なのが、ステークホルダーによってそれが微妙に異なっていたり、同一のステークホルダーでも、時間的経過による環境や状況の変化によって、変化したりする場合がある、というところだと考えています）
（※）「Output（結果・出力）≠Outcome（成果）」というところがキモになりますが、今回は「Mobius Loop」（https://www.mobiusloop.com/ ）という考え方があるということだけ紹介させてもらいます。

「アジャイル宣言の背後にある原則」（https://agilemanifesto.org/iso/ja/principles.html ）についてですが、こちらは有名な本「アジャイルサムライ」に譲りたいと思います。
（あとがきの方にも記述されていますが、この本自体が、「原則」に基づいて書かれた本で、次回投稿する予定のスクラムの実践編でもいくつか取り上げる予定の具体的なプラクティスまで踏み込んで説明されている名著です）

さて、以上で前回の伏線は回収できたことにして、やっと今回の本題である「スクラム」の基礎編について入りたいと思います。

スクラムを始めようと思ったなら、まずはなにはともあれ、「スクラムガイド」を読むことをおすすめします（というか、真剣にスクラムを始めるなら必須です）。
（※）毎年のように細かく更新されていますが、以下サイトで無償公開されています。分量的にも、A4で20ページにも満たないので、「会社でスクラムを始めるぞー」とか「来月からスクラムをやっているチームに配属されるみたいなんだけど・・・」というような方は、通勤時にでも一読していただいた方が良いでしょう。

かなり昔になりますが、スクラムマスターの認定トレーニングを受けた際、「スクラムガイドは毎年2～3回見直しが行われている。通常ならプロセスとかルールの類は時間が経つにつれて増えていくが（増やしてしまいたくなるが）、スクラムガイドの見直しではボリュームが増えないように気を付けられている」という説明がありました。確かに筆者がトレーニングを受けた頃から分量的には増えていません（むしろ減っている？）。大筋やコアになる考え方は大きく変化していませんが、詳細な部分については常にブラッシュアップされていることも特徴の一つです（今回のブログの冒頭の話もその一つです）。

スクラムは、「適応型」のソリューションであり、「価値を生み出すための」軽量級フレームワークである、というところがポイントです。言い換えると「適応」する必要がない事案に対しては、（不得手とは言いませんが）スクラムを導入する「うまみ」は減ってしまうことになります。（いわゆる「Cynefin framework（ https://en.wikipedia.org/wiki/Cynefin_framework ）」で言うところの「複雑（Complex）」な問題に対して向いている考え方ということになります。「Waterfall」の場合だと「単純（Simple）」「煩雑（Complicated）」が向いています）

また、「適応」は、変化する問題・課題に対してのみではなく、それに立ち向かうチームにも当てはまります。
スクラムガイドには、

と記載がありますが、その辺りが実際の現場で始めようとした際に「うっ」となったり、混乱したりする原因でもありそうです。また、具体的なプラクティスに（具体的であるがゆえに）引っ張られて、「プラクティスを実行する」事が目的になってしまって、スクラムのフレームワークが目指しているものから離れてしまったりする（というか、そもそも何故スクラムを始めようとしたのか？ということすらも見失ってしまったりする）一因になったりするのかもしれません。

はい、ここ重要です。「透明性」「検査」「適応」の順番自体も重要で、まず「透明性」、次に「検査」、そして「適応」の順番というのが重要です。

「透明性」に関しては

と説明されていますが、私がトレーニングを受けたときには「外から何も知らない人がスクラムをやっている開発チームのメンバーの誰かに質問した時、誰からも同じ答えが返ってくるような状態」というような説明を受けました。

具体的には、外からやってきた人が「どこまで進んでいますか？」と開発チームのメンバーに質問したら「今は4スプリント目です。今回のバックログは〇〇と××で、○○については実装完了し、スプリントレビューの準備を△△さんがやっています。××は課題があって、■■さんと私の方で、調査を進めています」という答えが誰からも返ってくるという状態です。もっと成熟している（練度が高い）チームなら、「あぁ、それなら壁のタスクボードの通りですよ」と言って指で示すかもしれません。

「検査」に関しては

と説明されています。以前（2017年版）のスクラムガイドでは「ただし、頻繁にやりすぎて作業の妨げになってはいけない。」という文言もあったのですが、最新版では外されています。理由を確かめたわけではないのですが、2017年当初に比べてスクラムを導入している各チームの練度が上がってそのような注意書きが必要なくなったのか、それともCI/CDといった技術が普及してその辺りの負荷を下げるような環境が増えたから書く必要がなくなったのかもしれません。

「適応」に関しては

と説明されています。こちらの実現のためのイベントとして用意されているスクラムのイベントが「スプリントレトロスペクティブ（いわゆる「ふりかえり」）」というものになります。

以前「スクラムのイベントで一番重要なイベントは？」という質問を筆者がとある有名なコーチにした時「ふりかえり（スプリントレトロスペクティブ）。ほかのイベントは外したこと（やらなかったこと）もあるけど、これだけは外したらダメ」ということをおっしゃっていました（その時伺った「何故なのか？」については次回のブログで）

こちら、スクラムガイドの著者の一人である Ken Schwaber が昔出版したスクラムの本「アジャイルソフトウェア開発スクラム」には載せられていたのですが、その後で出されたスクラムガイド（筆者が確認できたものでは2009年版以降）からは除外されていて、2016年版のスクラムガイドから再び登場しているようです。

「確約（Commitment）」、「集中（Focus）」、「公開（Openness）」、「尊敬（Respect）」、「勇気（Courage）という5つになりますが、これらについては、スクラムガイドの著者の二人が直接語っている動画がありますので、そちらを見ていただいた方が良いと思います。

余談ですが、アジャイルな開発手法としてスクラムと並んで有名な「XP（extreme programming）」でも、「価値（観）」について語られていて、現在では「コミュニケーション」「シンプリシティ」「フィードバック」「勇気」「リスペクト」の5つが挙げられています（後半の2つについてはスクラムと完全に被っています）

　続けて、もう少しスクラムの具体的な中身（構造・仕組み）について説明を進めましょう。

スクラムの基本単位はスクラムチームという小さなチームになりますが、その中には3つの役割が定義されています。「開発者」「プロダクトオーナー」「スクラムマスター」の3つです。「プロダクトオーナー」と「スクラムマスター」は1名ずつで、「開発者」は複数名（通常10人以下）となっています。スクラムチームは自己組織化された機能横断的なチームであり、最新のガイドでは「自己管理型」であるということも追加されています。

「開発者」に関しては、それぞれに得意な分野（例えばプログラミングとかテストとか）があるのは良いのですが、スクラムの定義では（設計者や、実装者、テスト担当者等の区分けは無く）あくまでも1つだけです。これはどういうことかというと、「QA担当なので、テストのタスクしかやりません」とか、「プログラミング担当なので、インフラの設定については別の人に任せます」という感じで、チーム内で作業を分割・分業で進めていくというのではなく、逆にメンバーであれば誰でも同じように作業ができること（できるようにしていくことを）を意味します。実際の現場ではペアプログラミングとかモブプログラミングとかのプラクティスを導入するのが効果的でしょう。

「プロダクトオーナー」に関しては「スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ」という所がポイントですが、複数名プロダクトオーナーの合議体制で決定するのではなく、あくまでも「1人である」という所がポイントです。

「スクラムマスター」ですが、Waterfall型の開発に慣れた人にとって、一番理解しにくい役割がこの役割になると思われます。あくまでもスクラムマスターは「スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ」「スクラムチームの有効性に責任を持つ」という役割となります。プロダクトオーナーと1対1で話し合って、プロジェクトを円滑に進めることに責任を持つわけではなく、プロダクトオーナーと開発方針や管理を進めることに責任を持つ役割というわけではありません（では、誰がそれをするのか？という疑問を持たれると思いますが、それは次回のブログで）

次に、スクラムを構成しているイベントについての説明です。軸になるのは「スプリント」という入れ物（時間の単位）になります。長さは1か月以内と定義されていますが、ポイントは「決まった長さ」であるという点です。基本的にスクラムでプロジェクトを開始したら、開始時に決めたスプリントの長さを変えることはしません。筆者が聞く限り日本では結構1週間スプリントというプロジェクトが多いようですが、海外（欧米）の方では、2週間くらいが一般的のようです（以前、海外から来日したアジャイルコーチが、「え？日本って1週間スプリントが一般的なの？！短い！」って驚いていました）。後、余談ですが、XPではスクラムで言うスプリントのことを「イテレーション」と呼んでいます。

今回は仮に「スプリント」の期間を1か月としますが、そのスプリントの開始時に行われるのが「スプリントプランニング」になります。これはスプリントが1か月なら、最大で8時間で行います。内容としては、プロダクトゴールを達成するために、プロダクトオーナーが作成したプロダクトバックログから優先順位が高いものを選択してそれらを実現するための、具体的な計画を立てます。また、その際には、各プロダクトバックログに対して、プロダクトオーナーと相談しながら開発者が見積りを行います（具体的な手法としては、プランニングポーカーとか、Ｔシャツサイズ見積りとかの方法がありますが、それは次回のブログで）。スプリントプランニングを前半と後半に分けて、前半で見積り、後半でその見積りから選択されたプロダクトバックログの詳細化（＝スプリントバックログの作成）を行う、というのが一般的な流れになると思います。

次のイベントは「デイリースクラム」です。これは別にアジャイルな開発に限らず、Waterfallの開発でも「朝会」という名前で馴染みがあるイベントではないでしょうか？ただ、スクラムでの「デイリースクラム」はいわゆるWaterfallの開発における朝会の進捗確認という意味合いよりも、あくまでも「検査」の場であり、それを踏まえた「再計画」の場という意味合いの方が強いものになります。ポイントになるのが、最大で15分という時間制限であり、毎日同じ時間に実施する、という点です（これによって開発期間中のリズムを作るわけですね）

さらに次のイベントは、スプリントの最終日に行われる「スプリントレビュー」です。こちらはその「スプリントの成果を検査し、今後の適応を決定する」場になります。1か月スプリントの場合、最大で4時間と定義されており、ステークホルダーに対して作業の結果を提示して、今後プロダクトについて話し合う場といえます。「実際に動くプロダクト」でデモをしたり、参加者に操作してもらってフィードバックをもらったりしますが、業界や会社によって結構違うようです。その辺りに関しては、スクラムのイベント・セミナーなんかに参加して、参加者に話を聞いてみると結構面白い話が聞けたりします。

最後に一番重要な「スプリントレトロスペクティブ（いわゆる「ふりかえり」）」です。こちらに関しては1か月スプリントの場合、最大で3時間と定義されていますが、スクラムに慣れていないチームだと、先の「スプリントレビュー」と区別がつかなくなって、いつの間にかそのスプリントの成果物のレビューをやっていた、という事になったりします。また、スクラム、アジャイルに慣れていない人（特にWaterfallに慣れたベテランの人）だと、「スプリントレトロスペクティブ」に価値を見出せずそもそも実施しない、というような判断をしてしまうチームも出てきたりします。（ただ、これは個人的にはわかる気がします。Waterfallのプロジェクトの場合、「ふりかえり」を行うプロジェクトは（最近は増えたかもしれませんが）少なく、実施したとしてもプロジェクトが終わった後に1回だけという事が多いようです。確かにそのような形でしか「ふりかえり」を経験したことがなければ、そのような考え方になるのも十分に理解できます）

さて、次にスクラムにおける成果物です。

1つ目は「プロダクトバックログ」です。こちらは基本的にプロダクトオーナーが作成しますが、2020年版のスクラムガイドから「プロダクトゴール」という概念が追記されています。正確には以前から概念・考え方はあったが、2020年版になって明記したということかもしれません。筆者の理解としては、こちらは「その製品・サービスを市場にリリースすることで、実現される世界観・ビジョン・状態・状況」ということになりそうです。プロダクトバックログはそれを具体化するために記述された一覧になります。ポイントは「優先順位」という考え方です。これは「優先度」という考え方とは似て非なる考え方です。

次に「スプリントバックログ」ですが、こちらは、「プロダクトバックログ」を元に、「スプリントプランニング」で作成する、「開発者による、開発のための計画」になります。

最後に「インクリメント」ですが、こちらは「プロダクトゴールに向けた具体的な踏み石」ということになります。具体的にはそのスプリントで作成したプロダクトやサービス・機能のことです。

以前は「完成の定義（Definition of Done）」の話なども項目として記載されていたのですが、最新版では前述の項目にマージされてしまったようです。次回のブログでもう少し掘り下げてみたいと思います。

今回はスクラムガイドをベースにスクラムの基礎的な事項を説明しましたが、次回はそれぞれの項目について、もう少し掘り下げて説明させてもらいたいと思います。