スクラム・XP・DevOpsの違いが5分でわかる！アジャイル開発を徹底図解

リビングにプールを作りたい、と言ったら

動画は、こんなたとえ話から始まります。夢のマイホームを建てるために、腕利きの請負業者にお願いしたとします。基礎が終わり、柱も立って、これから壁を作るという段階で、あなたが「やっぱりリビングのど真ん中にプールを作りたい」と言い出したらどうなるでしょうか。

従来型のやり方なら、業者は「最初に決めた設計図どおりにしかできません。ここからの変更は一切不可能です」と断ります。これがウォーターフォールモデルです。最初に完璧な計画を立て、一度決めたら後戻りしない。上から下へ水が落ちるように一直線に進むので、この名前で呼ばれます。計画どおりに進むなら安心感のある手法ですが、動画は「計画どおりに行けば、ですが」と付け加えます。

アジャイルの「素早い」は、タイピングの速さではない

アジャイルは「素早い」という意味の言葉です。動画の説明では、アジャイル開発とは、ウォーターフォールモデルのような従来型の開発と比べて、よりスピーディに行うシステム開発の手法の総称です。

素早さとは、タイピングが速いという意味ではなく、ビジネス環境や顧客の要求の変化に素早く対応するスピードのことです。スピード競争ではなく、変化に対する柔軟性のスピードです。

（補足：IPAの応用情報技術者試験シラバス（Ver.7.2）と基本情報技術者試験シラバス（Ver.9.2）でも、開発モデルの用語例にアジャイルとDevOpsが挙がっています。）

4つの価値：まず精神論から押さえる

動画が挙げる4つの価値は、下の表の左の列のとおりです。非常に人間臭く、現場に寄り添った価値観だ、と聞き手も感心しています。

動画の言い方	宣言の文言（日本語版）
プロセスやツールより人	プロセスやツールよりも個人と対話を
文書より動くプログラム	包括的なドキュメントよりも動くソフトウェアを
契約上の交渉より協調	契約交渉よりも顧客との協調を
計画より変化への対応	計画に従うことよりも変化への対応を

（補足：動画は短くまとめた言い方です。4つは、2001年2月に米ユタ州スノーバードで17人が集まって作った「アジャイルソフトウェア開発宣言」の価値で、右の列が公式サイト日本語版の文言です。宣言には「左記のことがらに価値があることを認めながらも、右記のことがらにより価値をおく」とあり、プロセスや契約、計画を無視するのではなく、どちらに重みをおくかを述べた文です。）

家の例なら、何か月も会議室で分厚い文書を作るより、「1部屋できたから住んでみてよ」と言うほうが早い。顧客自身が実際に触れてみないと本当に欲しいものは分からない、ネット通販で買って初めて「思っていたのと違う」と気づくのと同じだ、と動画は言います。

XP：設計よりコーディングとテストを重んじる

精神論だけではシステムは作れません。価値を現場で実行する手法として最初に紹介されるのがXP（エクストリーム・プログラミング）です。資料に「設計よりもコーディングとテストを重視する」とあることに、聞き手が驚く場面から入ります。

動画によると、XPは、プロジェクトの規模が比較的小さく、顧客の要求仕様が不明確で、開発中に変更される可能性が高いプロジェクトに有効です。要求がころころ変わる案件に向く、と聞き手がまとめています。

XPは、アジャイルの4つの価値を具体化した5つの基本原則に従って進められる、と動画は説明します。

• 素早いフィードバック
• 単純さの採用
• 漸進的な変更（一気に作り替えず、少しずつ段階的に変える）
• 変化を取り込む
• 質の高い作業

（補足：XPには別に「価値」があり、1999年の初版ではコミュニケーション、シンプルさ、フィードバック、勇気の4つ、第2版でリスペクトが加わって5つです。動画の「5つの基本原則」とは別の話です。この5つ（素早いフィードバック・単純さの採用・漸進的な変更・変化を取り込む・質の高い作業）は、大学の講義資料（二次資料）にもXPの「5つの主要な運用原則」として英語で同じ5つ（Rapid Feedback、Assume Simplicity、Incremental Change、Embrace Change、Quality Work）が挙がっており、動画の並びと対応します。ただしその資料はベックのどの著書・版の原則かを明記しておらず、ベックの原著そのものは確認していません。）

設計図がないまま漸進的に変えていくリスクは、習慣でカバーします。動画は、開発チームが行うべき習慣（プラクティス）として、「共通」「開発者」「管理者」「顧客」の4つのカテゴリーで合計19が定義されている、と説明します。これらが連動して初めて、設計図に縛られない開発ができる、というのが動画の主張です。

（補足：プラクティスの数え方は資料で違います。日本語版Wikipediaは「4つの領域にグループ化された12のプラクティス」、旧版の転載ページには「5つの価値と19のプラクティス」とあります。動画の「共通・開発者・管理者・顧客」という4分類は確認できた資料になく、19という数字と合わせて動画での説明として受け取ってください。）

代表例の1つがテスト駆動開発です。普通はプログラムを書いてからテストしますが、XPでは書く前に「どう動くべきか」というテストケースを先に作り、そのテストに合格するようにだけプログラムを書き、動作を確認して洗練させていきます。ゴールを先に作るので、設計図がなくても迷子になりにくい、という説明です。

ヤグニ（YAGNI）：「You aren't gonna need it」の略で、直訳すると、今いらないものは作らない、です。「念のため」に作った機能の多くは結局使われず、システムを複雑にしてバグの温床になります。無駄な予測を捨て、今確実に必要なものだけをシンプルに作る。つまり「単純さの採用」の体現だ、と動画は整理します。

ほかにも、コードの内部をきれいに保つリファクタリング、誰でも修正できるようにして俗人化を防ぐコードの共同所有、顧客が求める機能のコンセプトを共有するストーリーの作成などがあります。

聞き手のまとめはこうです。プラクティスはバラバラのルールではなく、変化の波を乗りこなすための、支え合う歯車です。

スクラム：チームのリズムをつくる

「チームがバラバラに動いたら、いつまでも完成しないのでは」という疑問に応えるのが、チームの進め方とリズムに焦点を当てたスクラムです。ラグビーのスクラムにちなんだ名前で、チームが肩を組み、1つのボールを一丸となって前に運ぶイメージです。

（補足：「スクラム」という語の由来は、竹内弘高・野中郁次郎の1986年のハーバード・ビジネス・レビュー論文「The New New Product Development Game」だとされています。論文の書誌はHBRで確認、「由来」の記述は二次資料によります。）

動画の説明では、スクラムは設計とプログラミングを交互に行いながら、反復的で漸進的な開発サイクルを取り入れた手法です。リズムを生む最重要キーワードがスプリント（短距離走）で、スプリントという一定の期間ごとに開発を区切ります。期間はプロジェクトによりますが、動画は「1週間から1か月くらいが一般的」と言います。

（補足：スクラムガイド（2020年版・日本語）には「スプリントは1か月以内の決まった長さとする」とあります。ガイドが定めるのは上限の「1か月以内」で、「1週間から」は動画の目安です。）

ここで使うのがプロダクトバックログです。作りたい機能や改善点などの項目を、優先順位の高い順に並べたリストのことです。スプリントごとに、この中から優先順位が高いものを切り出し、動くソフトウェアを作ります。

半年かけて一度に作るから、途中で要件が変わってパニックになる。まず2週間で最優先の機能だけ完璧に動かし、この短距離走を繰り返す、と聞き手は整理します。

スプリントの完了時には、スプリントレビューという重要なイベントがあります。動画では、主要なステークホルダー（顧客や関係者）に実際の作業の結果を提示し、プロダクトゴールに対する進捗を話し合う場、と説明されます。（スクラムガイド2020日本語版の「主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う」という記述と合っています。）

ここで自作の数字の設例を1つ置きます。5人のチームが2週間（10営業日）のスプリントを回し、1人1日6時間を開発に使えるなら、5人×10日×6時間＝300時間です。バックログの項目を優先順位順に次のように見積もったとします。

優先	項目（設例）	見積（累計）
1	商品検索	90時間（90）
2	カート	70時間（160）
3	会員登録	60時間（220）
4	決済	110時間（330）
5	レビュー投稿	90時間（420）

4番目まで入れると累計330時間で300時間を超えるので、このスプリントには上から3つ（220時間）を入れ、残りは次以降に回す、という考え方です。（補足：スクラムガイドは、開発者がプロダクトオーナーとの話し合いで項目を選び、過去のパフォーマンスと今回のキャパシティを踏まえて予測する、と述べるだけで、この割り算を求めてはいません。）

聞き手が気づいたルールがもう一つあります。スクラムはチームの密接な連携を必要とするけれど、作業者は必ずしも同じ場所にいなくてよい、という点です。動画は、場所の共有より、スプリントという共通の時間軸とプロダクトバックログという共通の目的で連携することを重視するのだ、と説明します。

（補足：スクラムガイド（2020年版）には、イベントは複雑さを減らすため同じ時間と場所で開催されることが望ましい、とあり、遠隔作業の可否には触れていません。「同じ場所でなくてよい」は動画の説明として受け取ってください。）

使い分けのための3つの手法：クリスタル・FDD・LSD

現場は小さなチームから大規模プロジェクトまでさまざまで、同じ手法がすべてに効くわけではありません。動画は使い分ける代表として3つを紹介します。

手法	動画の説明	覚え方
クリスタル	単一の手法ではなく、複数の開発手法の集合体。目的に合う手法を選んで使う	道具箱
FDD	フィーチャー駆動開発。ユーザーにとって価値のある機能（フィーチャー）を重視し、比較的大規模なプロジェクトにも適用可能と動画は説明	機能重視
LSD	リーンソフトウェア開発。リーンは「無駄がない」の意味で、トヨタ生産方式（リーン生産方式）を参考に効率性を追求する	無駄を省く

（補足：クリスタルはアリスター・コーバーン（アジャイル宣言の署名者の一人）の手法群で、色分けで手法の「重さ」を表します。FDDは1997年にジェフ・デ・ルーカが、シンガポールの銀行の約50人・15か月のプロジェクトのために考案しました。「大規模向け」は動画の整理で、確認できた資料にはありません。LSDは、メアリーとトム・ポッペンディークの2003年の同名書籍で広まった語です。いずれも二次資料での確認です。）

（補足：動画は「リーン生産方式、つまりトヨタ生産方式」と言い換えますが、「リーン」はトヨタ生産方式そのものの名前ではなく、1988年にジョン・クラフチックが論文で使い、書籍『The Machine That Changed the World』（1990年）などで広まった欧米側の呼び名です。トヨタ式が手本という趣旨は変わりません。）

DevOps：作るだけでなく、届けるところまで

システムは作って終わりではなく、運用するフェーズがあります。そこで最後に出てくる関連概念がDevOpsです。動画は、アジャイル開発そのものとは異なるが、関連した概念として非常に重要だと位置づけます。

聞き手の例えでは、ブレーキを踏まれっぱなしのスポーツカーです。そこでDevOpsは、開発（Development）と運用（Operations）を組み合わせた造語のとおり、両者が連携して協力し、より迅速かつ確実に価値を提供することを目指します。安全に素早く届けるところまで連携して初めて、アジャイルの価値が最大限に発揮される、という整理です。

（補足：DevOpsという語は、2009年にベルギーのゲントで開かれた「DevOpsDays」から広まったとされています。公的機関による定義は、今回の確認では見つけられませんでした。）

まとめ：手法の「焦点」で整理する

観点	XP	スクラム
焦点	プログラミングのやり方	チームの進め方とリズム
動画のキーワード	テスト駆動開発・ヤグニ・ペアプログラミング・リファクタリング	スプリント・プロダクトバックログ・スプリントレビュー
進め方	プラクティスの組み合わせで品質と変化対応を支える	一定期間（スプリント）ごとに作って見せる反復

動画は最後に問いかけます。ヤグニやスプリントの考え方は、試験勉強の計画にも使えないでしょうか。完璧な計画をやめて、小さなところから素早く始めてみる、という提案です。