【認定スクラムマスター】アジャイル開発とスクラム

免責

原著を正確に引用していない部分や筆者の考えが含まれる箇所があります。予めご了承ください。

アジャイル開発とスクラム

アジャイルソフトウェア開発宣言とは

従来のソフトウェア開発とは異なる軽量型開発手法を実践していた17名の開発者が2001年に公開した「マインドセット」のことを指しており，このマインドセットの背後には4つの価値と12の原則があります。「軽量」という語は悪印象を与えかねないため，複数の代案から「アジャイル」という語が選ばれました。

4つの価値

• プロセスやツールよりも，個人と対話を
• 包括的なドキュメントよりも，動くソフトウェアを
• 契約交渉よりも，顧客との協調を
• 計画に従うことよりも，変化への対応を

引用元: https://agilemanifesto.org/iso/ja/manifesto.html

アジャイルソフトウェア開発宣言では上記の4つの価値が主張されています。特に重要なのは，左記に価値があることを認めながらも右記のにより価値をおいている点です。決して左記に価値がないという主張ではありません。

12の原則

アジャイルソフトウェア開発宣言では12の原則が定められています。

顧客満足を最優先し，価値のあるソフトウェアを早く継続的に提供します。

顧客に価値を届けないと意味がないということです。開発者にとって重要なQCDの達成ではなく，あくまでもビジネスの実利を生み出さすことが本質であるという主張になります。顧客にとっての価値を見極めるためには，多数の取り組みを高速で回して価値検証を繰り返す必要があります。とにかく大切なのは「価値は提供元のチームや組織の外側で決まる」ということです。

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって，お客様の競争力を引き上げます。

複雑で変化の激しい現代社会では，最初から答えが分かっていることは少ないです。アジャイルの真価は変更に耐えるプロダクト開発を行うことであり，むしろ重要な変更を加速させることが重要であると考えています。従来の開発手法では変更は悪であるとされていた側面もありました。異なる役割を持つヒトが分業することにより，変更を抑止するインセンティブが働く構造になっていたのです。新しい価値を発掘するためには要求の変更を受け入れる必要があり，変化に強いプロダクトを作ることが顧客の競争力の強さに直結します。実際に，Marc Andreessen氏が2011年に発言した「Software is eating the world.」はソフトウェアが企業の競争力の源泉であることを端的に表しています。

動くソフトウェアを，2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

アジャイルソフトウェア開発宣言が公開されたのが2001年であるため，この2-3週間や2-3ヶ月というスパンは現在では1日や1週間といった長さになるでしょう。例えばAmazonは平均して1日当たり数十万回のデプロイを実施しているらしいです。短いサイクルで価値検証を繰り返すことにより初期投資の金額を抑えられるという恩恵も受けられます。

ビジネス側の人と開発者は，プロジェクトを通して日々一緒に働かなければなりません。

役割による分業は役割同士が敵対関係になってしまうことがあり，典型的にはビジネスサイドと開発サイドで意見や価値観の衝突が起こります。アジャイル開発では顧客への価値提供を目指すためにビジネスサイドと開発サイドが一体となって開発を行います。要求調整や要件定義の難しさは以下の「顧客が本当に必要だったもの」が有名です。

意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

アジャイル開発では人の意欲も重要視します。個人的には原則の中に人の感情が入り込む余地がある点に驚いたのですが，日本の衝突を嫌う文化はこの原則に合致しやすいと考えます。チームの外側のヒトはマイクロマネジメントせずに，のちに述べるようにチームの自己組織化を支援する必要があります。ただし，成果を出さずして信頼を得ることは不可能であるため，創出したアウトカムに基づいて信頼を獲得する繰り返しが大切です。

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

チームの本質は情報伝達であると言えます。ヒトが一人で動く場合は情報伝達の必要はありませんが，ヒトが増えるにつれて${}_{n}C_{2}$で情報伝達するべき組み合わせが爆発します。だからこそチームの構成人数は最小限にとどめ，重要な情報はface-to-faceで伝える必要があると考えます。ノンバーバルコミュニケーションにより得られる情報も重要であるため，アジャイルでは全員同席することに価値をおきます。

動くソフトウェアこそが進捗の最も重要な尺度です。

逆説的に動かないソフトウェアには価値がないことを主張していると捉えられます。ヒトとヒトの間で認識を揃えるための基準は現物である必要があります。だからこそアジャイル開発では小さな単位でモノを作ります。「動く」はworkingの日本語訳ですが，本来は「役に立つ」や「価値を発揮する」と捉えた方がよいでしょう。

アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

プロダクト開発では持続可能性が非常に重要です。ビジネスでお金を生み出し続けるためには，プロダクトも生き続ける必要があります。一時的なリソース投入や開発者の気まぐれにプロダクト開発を依存させてはいけません。プロダクト開発には終わりはないため，一定のペースで顧客に価値を届け続けなければならないのです。これにより，ビジネスとして将来の見通しを立てやすくなります。

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

技術と設計が機敏さの手段であることを主張しています。どこまでいっても技術は手段でしかありませんが，技術を用いることによりアジャイル開発を支える機敏さを実現することが可能になります。この原則には継続的な学習もアジャイルの一環であることが含まれます。

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

顧客の求める価値に直結しない作業や機能を「ムダ」と定義し，ムダを減らすことが重要であるという主張です。例えば「その要求は本当に必要ですか？」という問いが有効であると考えれます。

デジタルプロダクト体験のプラットフォームを提供する企業であるPendoが2019年に行った調査によると，24%の機能は全く使われず，80%の機能はほとんど・全く使われないという結果が得られています。以下のThe Features Curveで説明されているように「機能を作れば作るほど便利になる」という訳ではありません。

トヨタ生産方式では7つのムダが定義されています。

最良のアーキテクチャ・要求・設計は，自己組織的なチームから生み出されます。

自己組織化とは自分たちでやり方を決めることを指し，アジャイル開発ではチームの自己組織化を重要視します。最強の個人の寄せ集めが技術的卓越性やムダの最小化に繋がる訳ではなく，チームが自己組織化することにより個々の能力以上の成果を発揮する構造にあります。

チームがもっと効率を高めることができるかを定期的に振り返り，それに基づいて自分たちのやり方を最適に調整します。

チームにおける振り返りの重要性を主張しています。振り返りは自己組織化の手段とも言えますが，アジャイル開発においてはプロダクトの進化だけでなくチームの進化も重要視するということです。知識労働においては管理者よりも労働者の方が仕事のやり方をよく知っているとPeter Ferdinand Druckerが説いたように，チーム自身のことを一番よく知っているのはチーム自身だから自分たちでやり方を最適化します。

スクラムの定義

スクラムとは複雑な問題に対応して価値を生み出すための軽量級フレームワークで，未知のことが多い場合に有効な手段です。よくある誤謬として「スクラムは効率を追い求めるものである」がありますが，スクラムでは効果を追い求めます。このスクラムの定義はスクラムガイドにより規定されています。スクラムガイドはKen Schwaber氏とJeff Sutherland氏を中心にとりまとめられ，2010年に初版が公開されました。現時点での最新版は2020年11月版で，前回版との主な差分はプロダクトゴールの導入などによりゴール志向が強められた点が挙げられます。

スクラムは3つの責任・3つの作成物・5つのイベントにより構成されます。これらのうちどれが欠けてもスクラムにはなりません。スクラムガイドは意図的に不完全であり詳細な指示を提供するものではないため，まずはこの軽量級フレームワークをそのまま使うことが大切です。

項目	内容
3つの責任	プロダクトオーナー・開発者・スクラムマスター
3つの作成物	プロダクトバックログ・スプリントバックログ・インクリメント
5つのイベント	スプリント・プランニング・デイリースクラム・レビュー・レトロスペクティブ

3つの責任・3つの作成物・5つのイベントは3-3-5と語呂で捉えると分かりよいです。

スクラムとアジャイルの関係

アジャイルは開発の「マインドセット」であり，スクラムはそれを実践するための「方法論」であるという関係です。スクラムはアジャイルの一部であり，スクラム以外でもアジャイルを実現することができます。スクラム以外の方法論としてはExtreme Programming・Lean Software Development・Scaled Agile Frameworkなどがありますが，スクラムが最もメジャーな方法論になっています。

スクラムの理論

スクラムの理論は「経験主義」「リーン思考」「反復的かつ漸進的であること」に支えられています。経験主義とは「知識は経験から生まれ，意思決定は観察に基づく」とするもので，透明性・検査・適応という三本柱によって構成されています。透明性とはスクラムにおけるあらゆるモノや情報を常に共有することを指していて，検査とは透明性に基づき期待する結果との差を明らかにすることを指していて，適応とは透明性と検査に基づき最速で変更を行うことを指します。

スクラムの適用範囲はソフトウェアに限りません。2020年版のスクラムガイドで「冗長で複雑な文章とITに関する記述を排除している」とある通り，意図的にITという文脈を排除していることが分かります。実際に，教育現場や医療現場でスクラムを活用している例があります。

スクラムの価値

スクラムでは5つの価値基準が定められています。これによりスクラムチームの行動が規定され，経験主義を構成する透明性・検査・適用が効果的に機能するようになります。

価値	説明
確約 (Commitment)	ゴールの達成とお互いの支援に全員が全力を尽くすこと
集中 (Focus)	作業やゴールに全員が集中すること
公開 (Openness)	全ての作業とそれらを遂行する上での課題を公開すること
尊敬 (Respect)	お互いを独立した個人として尊敬すること
勇気 (Courage)	困難な問題に取り組むために正しいことをする勇気を持つこと

スクラムチーム

自己組織化と機能横断性

スクラムではスクラムチームを構成します。スクラムチームは自己組織化しており，機能横断性を有している必要があります。自己組織化とは，スクラムチーム自体に「いつ」「何を」「どうやって」「誰が」が任されている状態のことを指します。これにより，スクラムチームは自律的な変化を推進することにより顧客への継続的な価値提供とチームの継続的なパフォーマンス改善を行うことができます。機能横断性とは，開発者のスキルセットが横断的であることにより開発者全員を集めるとプロダクトを作れる能力が揃う性質を指しています。これにより，外部依存を最小化して機敏性を向上させ，価値のあるインクリメントを毎スプリントで完成させることが可能になります。機能横断性を有するためには，継続的な学習に投資する必要があります。

スクラムチームの責任

スクラムチームには「スクラムマスター」「プロダクトオーナー」「開発者」という3つの責任があります。この責任は従来「役割」と呼ばれていたものが2020年に修正された語になるため，ついロールと呼ばないように注意しましょう。スクラムにおける責任とは説明責任であるAccountabilityを指すことがほとんどですが，開発者における作業規模の見積もりだけは実行責任であるResponsibilityを指します。実行責任があるとはいえ，開発者による見積もりの結果は尊重されます。

価値	説明
プロダクトオーナー (PO)	プロダクトのWhatとWhyを定め，プロダクトゴールの達成とプロダクトの価値を最大化することに責任を持つ。プロダクトに1人であることが原則で，効果的なプロダクトバックログの管理に対しても責任を持つ。
開発者 (DEVs)	プロダクトのHowを定め，実際にプロダクトを作ることに責任を持つ。開発者は機能横断的であることが求められ，全員揃えばプロダクトを作れる能力が揃う必要がある。
スクラムマスター (SM)	スクラムガイドで定義されたスクラムの確立とスクラムチームの有効性に責任を持つ。スクラムチームだけでなく，組織全体に奉仕する真のリーダー。

スクラムチームは通常10人程度までがよいとされ，スプリントごとに価値のある有用なインクリメントを作成する責任を持ちます。スクラムチームには管理者がいないため自己管理する必要があります。

スクラムマスター

スクラムマスターは，スクラムガイドで定義されたスクラムを確立し，ススプリントごとに価値のある有用なインクリメントを作成する責任を持ちます。スクラムチームに対するティーチングやコーチングはもちろんのこと，組織全体に対してスクラムの理論とプラクティスを理解してもらうために振る舞います。スクラムガイドで言及されている通り，スクラムイベントが1つでも欠けるとスクラムは成立しませんので，スクラムマスターは全てのスクラムイベン トが開催され，タイムボックスの制限が守られるようにする必要があります。ただし，バックログアイテムをアサインする権限がないことには注意してください。

スクラムマスターとは，時には先生であり，時にはファシリテーターです。「結果に対する度合い」と「成長に対する度合い」によってスクラムマスターは様々な役割が期待されます。スクラムチームの自己組織化を実現するためにはスクラムマスターが忙しくなってはいけず，行動を起こす前に観察してみることが重要です。

スクラムイベント

イベント	説明
スプリント	スクラムの営みを繰り返す1つの単位のこと。1週間など一定の単位で区切り，他のイベントの入れ物となる。スプリントの唯一の目的はプランニングで定めるスプリントゴールを達成すること。
プランニング	スプリントの冒頭でスプリントを計画するためのイベント。スプリントゴールを1つ定め，プロダクトバックログからスプリント内で実行するアイテムを選択し，具体的な作業計画まで策定する。スプリントゴールはステークホルダーが理解できるものでなければならない。
デイリースクラム	スプリントゴールに向けた進捗を毎日検査するためのイベント。最長15分間というタイムボックスを守る必要がある。必要に応じてスプリントバックログを適応させ，実行可能な計画を具体化する。
レビュー	ステークホルダーを招待して今後の適応を検討するイベント。スクラムチームはスプリントで完成したインクリメントをデモしてステークホルダーからのFBを得る。進捗報告の場でも承認の場でもない点，およびプロダクトオーナーもフィードバックされる側である点に注意する。
レトロスペクティブ	今回のスプリントを検査するための振り返りを行うイベント。プロセス観点はもちろん，個人観点や相互作用観点で今後の改善点を整理する。スクラムチームとしてパフォーマンスを改善する上で最も効果的である変更を明らかにして，なるべく早く着手するようにする。

スプリントはプロダクトオーナーによりキャンセルされることもありますが，キャンセルされた場合に何を行うべきかはスクラムガイドでは規定されていません。スプリントレビューでデモできるのは完成の定義を満たしたバックログアイテムだけであり，完成の定義を満たしていることはプロダクトオーナーが判断することが一般的です。

リファインメントについて

スプリント中に次回以降のスプリントで実行するプロダクトバックログの手入れをする作業のことを指しますが，5つの作成物に含まれません。着手可能なプロダクトバックログをスプリント開始前までに準備する必要があります。

スクラムイベントの出席者

それぞれのイベントに対し，出席者は以下の組み合わせになります。

責任	プランニング	デイリースクラム	レビュー	レトロスペクティブ	(リファインメント)
プロダクトオーナー	◎	△	◎	◎	◎
開発者	◎	◎	◎	◎	◎
スクラムマスター	◎	○	◎	◎	○
ステークホルダー	△	△	◎	△	△

◎は参加必須，○は基本的に参加，△はチームの求めに応じて参加を表します。

スクラムの作成物

スクラムでは経験主義の三本柱である透明性・検査・適応の機会を提供するために，3つの作成物を規定しています。したがって3つの作成物には透明性が担保されている必要があり，この透明性が欠けてしまうとアウトカムとの接続性が霞んでしまい，最速で実利を生み出すことができなくなってしまいます。スクラムチームのアウトプットの品質を担保するためには，統一的な完成の定義を活用するとよいでしょう。「何をもって完成か」をチーム全員で共有することにより透明性が向上し，効果的な検査と適応を行うことが可能になります。

具体的には，スクラムでは以下の3つの作成物があります。

イベント	説明
プロダクトバックログ	「プロダクトゴール」と「プロダクトバックログアイテム」により構成される。プロダクトオーナーが管理に責任を持つが，アイテムの作成は移譲できる。
スプリントバックログ	「スプリントゴール」「選択したプロダクトバックログアイテム」「実行計画」により構成される。スプリントを通して更新されていくもの。開発者が作成する責任を持つ。
インクリメント	これまでのスプリントでの成果と今回のスプリントで完成したプロダクトバックログアイテムをあわせたもの。開発者が作成する責任を持つ。利用可能であるものである必要があり，完成の定義を満たしている必要がある。1つのスプリントに対して1つのインクリメントが対応するため，複数のスプリントで1つのインクリメントを作ることはない。

イベント	管理者	作成者
プロダクトバックログ	プロダクトオーナー	プロダクトオーナー・開発者
スプリントバックログ	開発者	開発者
インクリメント	開発者	開発者

完成の定義はプロダクトオーナーと開発者の合意を元にスクラムチーム全体で定められます。

学び集

CSMの学習を通じ，筆者が特に学びになったと感じたポイントをQ&A方式でまとめます。

アジャイルとは？

4つの価値と12の原則により規定される概念です。

ウォーターフォールモデルとアジャイル開発は比較できますか？

そもそも比較するレイヤーが異なります。ウォーターフォールモデルは具体的な手法のことを指しますが，アジャイル開発は4つの価値と12の原則により規定される概念のことを指します。

「スクラム開発」という語の使い方は正しいですか？

正しくないです。アジャイルは形容動詞であるためアジャイル開発という言葉は日本語として成立していますが，アジャイル開発のアジャイルを方法論であるスクラムに置き換えたスクラム開発はトートロジー的であり不適切です。

ウォーターフォールモデルとアジャイル開発で着目するポイントに違いはありますか？

ウォーターフォールモデルでは開発する工程に着目し，アジャイル開発では開発するヒトに着目します。

完成の定義はプロダクトバックログごとに定めるのですか？

完成の定義は共通の基準であるため，全てのプロダクトバックログアイテムが同一の完成の定義を参照する形になります。

プロダクトバックログアイテムがTODOリストになってしまうのですが。

ゴール志向を達成するための手段の一例としてユーザストーリー形式があります。これは受益者を主語にして「XXのためにYYがZZできること」のように記述します。受益者には開発者自身も含まれるため，プロダクトバックログアイテムは保守運用作業とすることもできます。

プロダクトバックログアイテムに保守運用作業を含めると顧客に価値を提供できないのでは？

スクラムチームはインクリメントについてスプリントレビュー会で説明を行う必要がありますから，インクリメントが保守運用作業のバックログアイテムだけから構成されるようなことはないはずです。

スクラムチーム内で責任を兼任することはできますか？

スクラムガイド上では禁止していませんが，スクラムでは責任を明確に分離することによる相互作用を期待しているため，責任を兼任することは推奨されません。

効果的なプロダクトバックログアイテムの可視化方法を教えてください。

横軸を優先度，縦軸を見積もりにしてアイテムを一列に並べます。

以下のように責任の所在を明確にしてプロダクトバックログアイテムを整理します。

• プロダクトオーナー：横軸の並び替えを実施
• 開発者：縦軸の並び替えを実施

左上に立ち入り禁止区域を設け，このゾーンに入ってしまったアイテムは分割して縦軸を下に移動するか重要度を整理して右に移動するようにするとボトルネックが解消されやすいです。なお，図中の縦軸はTシャツサイズ見積もりを利用しています。

事業分散ポートフォリオの観点からアジャイル開発の必要性を理解しましたが，そもそもアジャイルが適していない業界はありますか？

あるかもしれないです。例えば，

• 要件の変更がない
• 顧客ニーズが明確で作るだけで実利が得られることが確実

これらの特徴を有する場合はアジャイルである必要はないです。

計画主導型を採用しない場合は経営側にも一定の理解が求められるはずですが，その理解を得るための営みも含めてアジャイルなのでしょうか？

アジャイル開発はソフトウェア開発の文脈で語られていますので，厳密には含まれないです。特にスクラムにおいては，誰かに何か頼まれていたものを作るためのフレームワークではなく価値のあるプロダクトを作るためのフレームワークであることに注意してください。

スクラムチームの構成人数は通常10人以下とされていますが，2020年版のスクラムガイドで述べられている1チーム1プロダクトを意識するとプロダクトの規模が制限されてしまいませんか？

チーム内に別の構造が発生しない状態で問題を扱えるサイズの閾値が10人程度ということです。チームのアウトカムを最大化したいのであって，アウトプットを最大化したい訳ではない点に注意してください。大規模スクラムのフレームワークはいくつかありますが，これらは「常に1チーム1プロダクトで成功して」「チームのアウトプットがプロダクトの成功のボトルネックになっていること」を確かめてから使い始めてください。いきなり大規模スクラムのフレームワークを使うのは大失敗への約束された道です。

開発者が全員揃えばプロダクトを作れる能力が揃うのは現実的に厳しくないでしょうか？

2020年版のスクラムガイドに「スクラムを構成するのは，作業に必要なすべてのスキルと経験をグループ全体として備える人たちである。また，必要に応じてそうしたスキルを共有または習得できる人たちである。」との記述がある通り，スクラムチーム自体がスキルを獲得できる必要があります。

ステークホルダーが不特定多数のユーザであるサービスの場合，スプリントレビューの相手は誰になるのでしょうか？

例えば廊下で捕まえた社員などです。ランダムサンプリングすることができます。

スクラムではフロー効率を追い求めるので，手を動かさせて学ばせる新人育成には向かないのでは？

ステークホルダーからのFBを高速に得られる観点から学びが多く，スクラムは新人育成に向いています。手を動かす形式の学習はe-learning等で実現可能であり，現場ではFBに対する適応能力を身につけるべきでしょう。

スプリントレトロスペクティブでKPTは使えますか？

有効でない場合があります。KPTは振り返りを発散させる構造にあるため，スクラムの価値基準の1つである「集中」に反するだけでなく，ムダを省く原則にも反します。KPTを行っていると数多くのProblemと対峙することになりますが，扱う数を限定すると毎回同じようなProblemが出現し，スクラムチームの雰囲気が暗くなってしまうことがあります。スクラムガイドにおける「スクラムチームは，自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は，できるだけ早く対処する」を実現させるために，レトロスペクティブではパフォーマンス改善に対するインパクトの大きい課題のみに「集中」する必要があります。

スプリント0とは何ですか？

そもそもスプリント0は存在しません。スクラムガイドの定義に基けば，スプリントは他のスクラムイベントの入れ物となる単位のことを指しており，スクラムにおいてはすべてのスクラムイベントを実施する必要がありますので，スプリントにはスプリントプランニング・デイリースクラム・スプリントレビュー・レトロスペクティブが入っている必要があります。俗に言うスプリント0は初回スプリントの準備期間のことを指しますが，スプリント0にはこれらのスクラムイベントが存在しないため，そもそもスプリントと呼ぶことはできません。循環論法的ですが，スプリントの準備のことをスプリントと称することはできないということです。

参考文献

• スクラムガイド. [Ken Schwaber and Jeff Sutherland, 2020.]
• アジャイルソフトウェア開発宣言の読みとき方. [IPA, 2020.]
• The 2019 Feature Adoption Report. [Pendo, 2019.]
• The New New Product Development Game. [Takeuchi and Nonaka, Harvard business review, 1986.]
• The Effects of Task Difficulty and Multitasking on Performance. [Adler, Interacting with Computers, 2015.]
• Supertaskers and the multitasking brain. [Strayer, Scientific American Mind, 2012.]
• The Swing Cartoon. [2025年3月閲覧]
• Creating Passionate Users. [2025年3月閲覧]