BOY MEETS XP - スクラムマスターがXPと出会っちゃった話

こんにちは、アドプラットフォーム事業でリードアプリケーションエンジニアとして働く、おおしまと申します!
去年はグラフDBについて取り上げましたが、今年はスクラムマスターとしての一面もお見せできればと思います!

普段はスクラムマスターとしてミーティングのファシリテーションや社内でのスクラム研修を実施したりしていますが、そんな私がTanzuLabs(以下Labs)様とのJANetモダナイゼーションプロジェクトに携わって学んだXP(Extreme Programmingの略)について、スクラムと比較しながら考察して参ります。
なお本稿におけるXPについての説明の一部は、LabsによるXPの発展系であるLeanXPを指している場合がありますので、ご了承ください。

また本プロジェクトに携わった社員による学びについていくつか記事がございますので、ぜひご一読ください。

フレームワーク比べてみました

違いについて述べる前に、まずは共通する部分に目を向けてみましょう。

XPは、スクラム同様アジャイル開発に属するフレームワークです。
以下でも、XPの採用によって短いサイクルでの開発および継続的なフィードバックを得られると記されており、スクラムと近しい思想を持っていることがわかります。

XP is a path of improvement to excellence for people coming together to develop software. It is distinguished from other methodologies by:
✧ Its short development cycles, resulting in early, concrete, and continuing feedback.
Extreme Programming Explained より引用

また名称こそ異なりますが、スクラムの各イベントに相当するイベントがXPにも用意されています。

では違いはどこにあるのでしょうか?

思想・方向性の違い?

まずはそれぞれのフレームワークでベースとなっている考え方について見てみましょう。

スクラムでは、三本柱(透明性・検査・適当)を最重要概念として設定し、これを実現するための5つの価値基準(確約・集中・公開・尊敬・勇気)が設定されています。
これに対してXPでも5つの価値基準(コミュニケーション・単純さ・フィードバック・勇気・尊重)が設定されています。

お気づきでしょうか。同じものとそうでないものが混在していますね。

以下の記事でLabsの方が言及されている通り、スクラムではプランニングで立てた計画に集中し達成することを確約することが求められています。

これにはスプリント単位で計画していくスクラムと、予測はするけど約束はせずにいつでも柔軟に変更していくXPの性格が表れているように思います。
XPとスクラムの違い より引用

対してXPでは常にあらゆるタイミングでフィードバックを受けながら柔軟に計画を変更していくことが求められています。
さらに以下の記事で記載の通り、ペアプログラミング(以下ペアプロ)含めてさまざまなタイミングでフィードバックと改善が起こるようになっています。

ペアでフィードバックループを秒で回し、問題に対する適応を早く行えるようにするのが良いペアプロなんじゃないかと思っています。
ペアプロは秒のフィードバックを回し続ける より引用

私は、この軌道修正がリアルタイムに行われるところにエクストリームさを強く感じました!

スクラムでは先述の通り(明確かつ厳密なサイクルである)スプリントごとに計画を立ててこれに従うため、この計画という部分が暴走し、ミニウォーターフォールに陥りがちな危険性を秘めていると個人的には感じています。

スプリントの最初の数日で複数のプロダクトバックログアイテムをまとめて設計し、次にそれをまとめて開発をし、最後にまとめてテストをするやり方です。 これはまさにミニウォーターフォールと言えます。
スプリントでの作業の進め方 より引用

サイクルに現れるエクストリームさ

ではそれぞれの開発サイクルについて比較してみましょう。

スクラムではスプリントごとにプランニング、レビュー、そして振り返りを行います。
スプリントごとに、どのような価値を提供するか・どのように実装するか・チームはどのように動くべきかを考えていくということです。
つまりスクラムでは、基本的にさまざまな事柄をスプリント単位(数週間)で実行します。

これに対してXPでは、これが数日から週に短くなる傾向にあります。

本プロジェクトではおおよそイテレーション(スプリントのような1~2週のサイクル)ごとにIPM(Iteration Planning Meetingの略)というスプリントプランニングに近いイベントを実施しましたが、あくまで認識合わせや簡単な見積もりを行うために行いました。(IPMの実施頻度は決まっておらず、やることがなくなってきたら実施でOKです)
つまりスプリントプランニングで行う「どんな価値を生み出すのか」の検討はストーリーごとに行っていきました。
これによって、開発サイクルがスクラムよりも短くなる傾向があります。

こうした傾向は振り返りにも表れています。
スクラムではスプリントごとに振り返りを行いますが、XPでは価値基準の1つであるフィードバックがペアプロなどの密なコミュニケーションを通じて行われるため、継続的にチームが改善されていきます。
本プロジェクトではイテレーションごとの振り返りも実施しましたが、上記の通り日々改善が起きるような形となっているので、スクラムでの振り返りのように1サイクルの内容が一気に吐き出される→ミーティングが終わらないということが起こらなかったです。

XPとスクラムの差異

上記の画像の通り、スクラムでは基本的にスプリントごとに改善が起こるのに対し、XPでは改善をあらゆる頻度・タイミングで起こるように設計されています。

XPが最強?

ではXPはスクラムの上位互換なのでしょうか?
サイクルの短さは非常に魅力的ですが、結論を急ぐ前に他の事柄も比較してみましょう!

スクラムでは、ソフトウェア開発以外にも適用可能なように抽象度が高めに設計されています。
これにより、チームによって適用するプラクティスを柔軟に選択できるようになっています。

対してXPは名前にプログラミングが含まれている通り、ソフトウェア開発に特化しています。
各種プラクティス(ペアプロやテスト駆動開発など)やチーム構成について、ソフトウェア開発に適用されることを前提に、スクラムよりも具体的に記されています。(以下のスライドでいくつかXPのプラクティスが紹介されています)

Extreme Programming (XP) 概要

そのため、スクラムで陥りがちな「とりあえず導入したけど具体的にどうすればいいのかわからない」という状況を避けやすいと言えそうです。(とはいえスクラムに関するプラクティスは多数公開されているので、そこから選ぶこともできます)

筆者的オススメ

では両者はどのように使い分ければ良いのでしょうか?

まずアジャイルをとりあえずやってみたいとお考えの方、スクラムを導入してみましょう。
定義がコンパクトでどんなジャンルにも適用できる柔軟さを持ちつつ、チーム構成やミーティングのサイクルについての記述はしっかりしているので、アジャイル開発を行える体制を整えるのに適していると言えるでしょう。

私はスクラムもやったことがあるんですけど、やはりスクラムは始めやすいと思います。角さんが言うようにXPですべてが満たせますが、その「始めやすい」という意味でスクラムはお勧めできます。
すべてがXPになる ─ エクストリームプログラミングで見える開発風景(セミナーレポート) より引用

またスクラムから派生したフレームワークも多数存在しているため、スクラムを導入することで他のフレームワークへの移行もスムーズに行えるかもしれません。 ネット上に知見が溢れている点も魅力的です。

XPは、スクラムやその他のアジャイル開発を導入しているが、伸び悩んでいる・次の一手を考えているというチームにピッタリな印象です。
具体的なプラクティスはもちろん、思想も短いサイクルを実現できるように設計されているので、開発スピードを加速させる突破口になるかもしれません。

とはいえそれなりに導入難易度が高いので、いきなりすべてのプラクティスを導入するのに抵抗がある方は、一部を取り入れてみるのも良い方法でしょう。(弊社でもペアプロは本プロジェクトの前から一部チームで導入済みでした)
しかし、XPのプラクティスや考え方は相互作用するようになっているので、特定のチームだけすべて試してみるやり方もオススメです!(Labsの方も小さい範囲から着実に導入しておくのがオススメとおっしゃっていました)

最後に

本稿では、XPとスクラムについて比較して参りました。

本プロジェクトに携わるまで、プロダクトチーム(新規開発系のチーム)でスクラム開発を行っていた私ですが、今回技術改善系のチームでXPを体験することで、アジャイル開発の幅広さを感じることができました。
それまではアジャイル開発は新規開発に向いていて技術改善系のチームではアジャイル開発(ましてやその中でも尖っているXP)は難しいというイメージを持っていましたが、技術改善でこそビジネス的価値を再考するという動きの中でそんな偏見はどこかへ飛んでいきました。
今後は、とっつきやすくエンジニアとしての背景がない方にも比較的馴染みやすいスクラムを引き続き活用しベースを整えつつ、高速なフィードバックサイクルを持つXPを用いてプロダクトチームの方でもアジャイル開発の向上を図っていきたいと考えております。

どんな組織にも適用可能な最強の開発フレームワークというものは残念ながらこの世に存在しませんが、スクラムは抽象度が高くて迷いがち、アジャイル開発を極めたいと思っていた方はぜひ、エクストリームなXPを楽しんでみてください!

ではまたどこかで!