スクラムは何であって何ではないのか。XP、そしてLeanXPは何が違うのか。
こんにちは、TanzuLabs by BroadcomのYukaです。
最近いろいろあって社名が変わりましたが、私たちは引き続き ”Transforming How The World Builds Software” を実現し続けますのでこのブログ共々今後もよろしくお願いします！
さて、「アジャイル開発」という言葉は日本のソフトウェア開発の現場ですっかりお馴染みになっていると思いますが、アジャイルと聞いてまず「スクラム」を思い浮かべる人も多いのではないでしょうか。
私たちTanzuLabsはエクストリーム・プログラミング（XP）を内包したLeanXPという開発手法を得意としていますが、「XPやLeanXPってスクラムとどう違うの？どちらがいいの？」と聞かれることがよくあります。
実際にはスクラム、XP、LeanXPはそれぞれカバーしている領域が違うため、単純に比較して優劣をつけられるものではありません。
私もLabsで働く前には複数の会社でスクラムやXPを含めたアジャイル開発に挑戦してきましたが、そもそもスクラムという手法は有名がゆえに人によっていろんな理解や解釈をしていることも多いです。
この記事ではまずは「スクラムは何であって何でないのか」を探り、それとの比較からXP、LeanXPを紹介していこうと思います！
※この記事のスクラムに関する記述は2020年版スクラムガイド（日本語版）、XPに関する記述は書籍「エクストリームプログラミング」を参照して書かれています
スクラムとは
まずはスクラムの定義についておさらいしましょう。スクラムガイドには以下のように書かれています。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。
スクラムはスクラムガイドと呼ばれるドキュメントによって提唱されており、様々な言語のPDFが無料で公開されています。上記の定義はスクラムガイドの冒頭にある一文です。
日本語版スクラムガイドから目次などを除いた本文は13ページほどで、このドキュメントの中に「アジャイル」という単語は存在しません。意外ですね！
次にスクラムのベースとなる理論を見てみましょう。これもスクラムガイドからの引用です。
スクラムは「経験主義」と「リーン思考」に基づいている。 経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。 リーン思考では、ムダを省き、本質に集中する。
（中略）
これらのイベントが機能するのは、 経験主義のスクラムの三本柱「透明性」「検査」「適応」を 実現しているからである。
詳しくはガイドを読んでもらうのが一番ですが、ざっくり言うと
- 透明性を高めることで誤解と無駄を省きリスクを低下させる
- 価値を生み出しているかを常に検査し、そこから計画を適応（変化）させていく
というのがスクラムの基本的な考え方になります。スプリントプランニングやデイリースクラムなどお馴染みの各イベントは検査と適応のために存在しているんですね。
スクラムはシンプルである
簡単にスクラムのコアな部分を紹介しましたが、皆さんはどう感じましたか？
私は初めてスクラムガイドを読んだとき、想像以上にシンプルなことを言っているなと感じました。まさにリーン（無駄がない、削ぎ落とされた状態）です！
スクラムガイドを読み込むと、様々なプラクティスが紹介されていても最終的には「計画を細かく検査し適応しよう」としか言っていないことに気が付きます。つまりソフトウェア開発において「何を作るか、どう作るか」という部分への言及はありません。
このシンプルさによりスクラムはソフトウェア開発以外にも使える汎用性の高さ、スクラム以外の考え方を柔軟に取り込むポテンシャルを獲得しています。
下記はスクラムガイドからの引用です。
スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。
実際、スクラムガイドは2020年の改訂でITに関する単語（設計やテストなど）を削除しました。
なにかしらの価値を提供するプロダクトを中心に活動する組織であればスクラムの導入を検討する余地があり、調査してみるとソフトウェア開発を目的としていない組織での導入事例も見つけることができます。
スクラムはシンプルだけど簡単ではない
ここからは私の過去の経験も踏まえた話をしていきます。
ここまでアジャイル開発の手法であるスクラムについておさらいしてきました。それではスクラムを採用すれば、それだけでアジャイルなソフトウェア開発を実現しビジネスを前進させることができるのでしょうか。
スクラムガイドに忠実にスクラムを実践しようとしたとき、私はこう感じました。
「優れたソフトウェアを作ろうとするとスクラムガイド通りにやるだけでは足りない」
前述した通り、スクラムガイドには「何を作るか、どう作るか」という部分の記載はありません。ビジネスモデルやユーザー価値をどうやって発見・検証していくか、細かな検査と適応のためにはどういう開発スタイルやチーム文化を育てていくか、などソフトウェア開発には様々な課題が存在します。
スクラムだけではそれらすべてをカバーできないため、その他の手法やフレームワークを組み合わせたり自分たちで考えていく必要があります。多くのスクラムチームがバックログのポイント見積もりを行なっていると思いますが、それすらもスクラムガイドには載っていないのです。
しかしこれは逆にメリットでもあります。チームがこれまでやってきたやり方をある程度維持したままスクラムを採用し、小さく始めるということを可能にしてくれています。
どちらにしろスクラムという手法を自分たちの組織やプロダクトにフィットさせるには自分たちで経験し改善していくことが必要不可欠であり、時にはチーム外の組織の協力なども必要になってきます。
スクラムの特長のひとつにチーム全体のスクラムの実践を支えるスクラムマスターという役割がありますが、スクラム自体の実践・継続・改善が難しいからこそ存在している役割なのではないでしょうか。
XP、LeanXPはスクラムとどう違うの？
XPもスクラムと同じくアジャイルを代表する手法のひとつです。
有名なプラクティスとしてはテスト駆動開発、ペアプログラミングなどがあり、スクラムと比べるとよりソフトウェア開発に特化したものになっています。
開発（プログラミング）に関する部分が有名なのでXPはソフトウェアエンジニアのみで採用するものと捉えられがちですが、スクラムと同じようにエンジニア以外も含めたチームでの活動やステークホルダーとの関わり方も含まれており、職種に関わらず全員で実践していく包括的な内容です。
そしてXPに加えてリーンスタートアップとユーザー中心設計を採用し、
- 価値あるビジネスをどうやって探索するか
- ビジネスを実現するために必要なプロダクトは何か
- ユーザーから何をどうやって学ぶか
などの課題にも応えられるようにしたものが我々TanzuLabsが提唱するLeanXPになります。
つまり、それぞれの手法は「プロダクト開発においてカバーする領域」が少しずつ違っているんですね。もちろんどの手法を選ぼうと必ず成功できるわけではないのがビジネスの世界ではありますが、チームが抱える課題や特性によって自分たちにはどの手法がマッチしそうかが変わってくると思います。
次に各手法の価値基準を比較してみましょう。LeanXPではXPと同じ価値基準を採用し、様々なプラクティスや意思決定のベースにしています。
面白いですね！
5つのうち「尊敬」と「勇気」の2つは同じものの、特に興味深いのが
- スクラムは「確約」と「集中」
- XPは「コミュニケーション」と「フィードバック」
を採用している部分です。
これにはスプリント単位で計画していくスクラムと、予測はするけど約束はせずにいつでも柔軟に変更していくXPの性格が表れているように思います。
もちろん、3つのプロセスのどれもアジャイル宣言やリーン思考に基づいた考えによって生まれているため似ている部分もたくさんあります。
例えばスクラムで言う「検査と適応」のように現状を正確に把握しながら改善を繰り返していくことをLeanXPでは「Build, Measure, Learn（構築、計測、学習）」という言葉で表現しますし、デイリースクラム（LeanXPではチームスタンドアップ）やレトロスペクティブなどもどの手法でもほとんどのチームで行われているイベントです。
今回は少ししか紹介していませんが、このようにそれぞれの手法は同じようにアジャイル開発を目指しつつも、適応できる領域や考え方にそれぞれの個性を持っています。皆さんは各手法に対してどういった印象を持ちましたか？きっと良さを感じる部分や必要なエッセンスは人（や組織）によって様々だと思います。
これらのアジャイル開発の手法は決まったやり方というよりも考え方など概念的な要素が占める割合も多く、気をつけないと人によって理解や解釈がずれてしまうことも少なくありません。各手法の本質的な違いを把握し、チームメンバーと理解を揃え、そのうえで自分たちにあったものを採用することがアジャイルをうまく実践するためのポイントの1つではないでしょうか。
最後に
この記事ではスクラムを中心に説明してきましたが、XPおよびLeanXPもスクラムと同じく高い柔軟性を持っています。
アジャイル開発を採用するような不確実性に立ち向かわなければならない状況では一貫した価値観と柔軟性を同時に持つことが重要であり、だからこそアジャイルに関する多くのコンテンツではオープンなマインドや変化を起こす勇気の大切さが説かれています。
そのためアジャイル開発の在り方というのはたとえ同じ手法を採用している場合でも、チームによって大きく異なる形になっていることが多いです。成功事例を簡単にコピーすることができないのは難しいところでもあり、私にとっては仕事のやりがいでもあります。
今回私が紹介した内容が自分の過去の経験とは違うと感じる人もいると思います。ひとりの人間が一生で参加できるプロダクトチームの数はそう多くありません。だからこそお互いに経験を共有していくことが重要であり、そういったOpennessやFeedback、そしてRespectの精神がソフトウェア開発文化を急速に発展させているのだと思います。
勇気を出して書いたこの記事が、あなたがよりアジャイルについての理解や興味を深めるきっかけになれていたら嬉しいです。これからは「スクラムとXPってなにが違うの？」と聞かれても困りませんね！
