アジャイル開発とは（中編）スクラムとエクストリームプログラミング（XP）

アジャイル開発には、スクラム、リーン開発、XPなど様々な手法や方法論があり、それぞれ開発プロセスも多様です。

本稿では、それらの中でも代表的な「スクラム」と「エクストリームプログラミング（XP：eXtreme Programming）」を紹介します。

スクラムとは

スクラムとは、反復増加型ソフトウェア開発チームに適用するプロジェクト管理フレームワークです。

スクラムの由来

1986年、論文「The New New Product Development Game」が野中郁次郎氏と竹内弘高氏によって発表されました。日本の製造業における新製品開発や組織の形態が、ラグビー、スクラムのようであると例えられています。

1993年、ジェフ・サザーランド氏らが反復増加型の開発を実践する中で、この論文に触発されて名付けられたのがソフトウェア開発「スクラム」の最初です。

スクラムの特徴

スクラムの特徴を以下に示します。

• 反復増加型のソフトウェア開発プロジェクトを管理するためのフレームワークです。
• 開発技術を必要とする活動はありません。
• 反復期間内に開発する機能は、反復ごとに決定されます。
• 反復期間中、チームは外部（顧客やビジネスサイド）からの干渉を全く受けません。
• プロジェクト管理の権限はチームに委譲され、開発手法や利用技術もチームが決定します。

スクラムのプロセス概要

スクラムにおける開発プロセスの大まかな流れを以下に示します。

図 スクラムのプロセス概要

スクラムのプロセスは、スプリントと呼ばれる反復期間を繰り返すことで増加的に機能を開発します。
スプリントでは、以下に挙げるスクラムイベントが実施されます。

1. スプリントプランニング：

   • プロダクトオーナーと開発チームは、全体のプロダクトバックログ（実装予定機能の一覧）の中からスプリント（反復期間）で実装する機能を決定します。
   • 選定された機能一覧をスプリントバックログといいます。
2. デイリースクラム：

   • 決まった時刻に開発チームは短時間のミーティングを実施します。
   • 開発の進行状況や課題などを共有し一日の仕事の進め方を決定します。
3. スプリントレビュー：

   • スプリントの最後にステークホルダーに対して開発した機能をデモンストレーションします。ステークホルダーからフィードバックを受けます。
   • レビューの結果がOKの機能はリリースされますが、NGの場合には次回以降のスプリントにリリースは持ち越されます。
4. スプリントレトロスペクティブ：

   • スプリントレビューの終了後、スクラムチームは今回のスプリントのふりかえりを実施します。
   • レトロスペクティブとは「ふりかえり」のことです。次のスプリントの改善計画を行います。

スプリントの期間は1週間から1か月が設定されることが一般的です。

スクラムにおける役割

スクラムチームは以下の3つの役割で構成されます。

スクラムによる効果

スクラムの導入は、ソフトウェア開発プロジェクトに以下の効果をもたらします。

• スプリントごとに動くソフトウェアを顧客に提供し、フィードバックを受けられます。
• 顧客が提示した順番に機能を提供できます。
• 反復増加型のアジャイル開発に適した自律的なチームを早期に形成できます。
• 外部からの干渉を受けない権限移譲されたチームが、共有された目的達成のために新たなブレークスルーやイノベーションを生みます。

～小話～　スクラムの特徴を語るこんな小話があります。

ニワトリは出資はするものの再生産可能な卵を提供するといい、対してブタは死を伴う肉の提供を拒否しています。つまり、痛みを伴う者たちが自分たちの行動を決定すべきであることを伝えています。

プロジェクトの権限を委譲され、外部からの干渉は受けない開発チームは、自分たちで開発手法や利用技術を決定します。他の誰も決めてくれません。

期限のある反復期間の中で「誰が何をどのようにつくるか」を自分たちで決定しなければならない状態に（半ば強制的に）置かれたチームは、自律管理や自己組織化が高速に進行します。また、技術的なブレークスルーやイノベーションを生み出す動機ともなり得ます。

スクラムの効果は、短期の自己組織化とイノベーションを生む環境をつくりだすことです。

エクストリームプログラミング（XP:eXtreme Programing）とは

エクストリームプログラミングとは、開発やマネジメントの経験則を適用の指針とともにまとめたものです。

XPの由来

ケント・ベックとウォード・カニンガムは、「パタン・ランゲージ（pattern language）」（注釈1）と呼ばれる建築理論に触発され、ソフトウェア開発の成功事例を「パターン」として集める活動を始めました。
その後、ベックは自らが参画したクライスラー社の開発プロジェクトで、集めたパターン群を実践して調整や改善を重ね、1999年にエクストリームプログラミングとして提唱されました。
ソフトウェアの開発現場における経験則を「極端（＝エクストリーム：extreme）」なまでに実践するという発想から命名されました。

XPの特徴

XPの特徴を以下に示します。

• 開発に関わるすべての人が互いに尊重し、働きかけ、協力し合うことが重視されています。
• 状況の変化を歓迎し、受け入れ、それにすばやく追従することができます。
• 顧客はチームメンバーの一員です。オンサイト顧客と呼ばれチームと常に同席し、技術者と協働してソフトウェアを開発します。
• 開発プロセスはチームにより新たにつくられ、よりよいものに改良され、合わなくなったものは捨て去られます。
• 開発技術を必要とする活動が多くあります。

XPのプロセス概要

XPにおける開発プロセスの大まかな流れを以下に示します。

図 XPのプロセス概要

XPのプロセスは、イテレーションと呼ばれる反復期間を繰り返すことで増加的に機能を開発します。
イテレーションおよびその前後に、以下に挙げる活動が実施されます。

1. 計画ゲーム：
   イテレーションの期間内に実装する機能を決定します。

   • 開発技術者は機能の規模を見積り、オンサイト顧客は機能の優先順位を提示します。
   • 両者のやりとりによって開発機能が決定されます。
2. イテレーション：
   オンサイト顧客と開発技術者が協働して開発を行います。

   • オンサイト顧客は機能の受入条件を作成します。
   • オンサイト顧客は開発技術者と協働して受入テストを作成、実施します。
   • オンサイト顧客と開発技術者は常に同席し緊密なコミュニケーションのもとで、機能の詳細／技術上の制約／ビジネスサイドの目的を明らかにします。
   • 開発技術者は機能の開発と同時にテストを作成実施し、ソフトウェアが正常に動作する状態を維持します。
   • 動作するソフトウェアを共にみて触れることで、オンサイト顧客と開発技術者は齟齬のないコミュニケーションを図ります。
3. リリース：
   イテレーションの終了時に、オンサイト顧客の受入テストが完了している機能をリリースします。

イテレーションの期間は1週間から2週間が設定されることが一般的です。

XPのプラクティス

XPでは、ソフトウェア開発における問題発生のリスクを低減する具体的かつ経験則的な活動を「プラクティス」と呼んでいます。プラクティスの多くはチームや組織のマネジメントを目的としていますが、実行に当たっては開発技術が必要なプラクティスがほとんどです。

ここでは、代表的なプラクティスをいくつか紹介します。

XPにおける役割

XPチームではメンバーの役割は固定化されず、状況に応じて全員が様々な役割を担当します。
以下のような役割があります

XPによる効果

XPはソフトウェア開発プロジェクトに以下の効果をもたらします。

• 計画ゲームによって、ビジネスサイドからの要求とチームの負荷の折り合いをつけるため、
  • ビジネス戦略の実現に、開発チームが無理なく継続的に貢献することが可能となります。
• 常時同席しているオンサイト顧客が、動作するソフトウェアを直接確認するため、
  • 確認待ち時間が最小化され、機能の開発完了までの時間が短縮されます。
  • すばやく詳細なフィードバックによって、使い勝手の良いソフトウェアとなります。
• 品質リスクへの対応を目的の一つとするプラクティスが充実しているため、
  • 問題の早期発見、解決の迅速化、手戻りの最小化、ソフトウェアの品質向上効果があります。
    （ペアプログラミング、継続的インテグレーション、コードの共同所有 etc.）
• 知識の伝搬を促進するプラクティスが多いため、
  • 技術知識や業務知識がチーム全体に伝搬され、開発技術者の多能工化とスキル向上、チームの開発能力向上、ソフトウェアの品質向上に効果があります。
    （計画ゲーム、ストーリー、ペアプログラミング、コードの共同所有 etc.）
• 開発技術者の多能工化とチームの開発能力向上によって、
  • より少ない開発技術者によって、以前と同じ負荷をこなすことが可能となります。
  • 高い技術レベルを有する技術者が、他の開発プロジェクトに移動してもインパクトが最小化されます。
  • 開発技術者の移動でチームが少人数になった場合には、他チームと合併しメンバー数を増やすことで多くの知識を共有する機会を復活させることができます。

図 XPのプロセス概要（再掲）

再掲した図“XPのプロセス概要”を見ると、イテレーションのアウトプットは、リリースされるソフトウェアだけではありません。

• 改善されたプロセス
• 新たに生み出されたプラクティス
• プロセスを実現能力が高まったチームメンバー

これらもイテレーションのアウトプットです。アウトプットは次のイテレーションのインプットとなります。
ソフトウェアが反復増加型で開発され成長し続けるのと同様に、プロセス（Process）もプラクティス（Practice）もチーム（People）も成長し続けます。

続いて後編では、アジャイル開発プロセスの事例を紹介します。

注釈

• 注釈1
  https://ja.wikipedia.org/wiki/パタン・ランゲージ

参考文献

• Jim Highsmith. “アジャイルソフトウェア開発エコシステム”. 株式会社テクノロジックアート訳, 長瀬嘉秀監訳, 今野睦監訳, 株式会社ピアソン・エデュケーション, 2003, 404p, ISBN 978-4894717374.
• Ken Schwaber, Jeff Sutherland. “The Scrum Guide”. Scrum Guides. 2017. https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf, (参照 2018-08-24).
• Ken Schwaber, Mike Beedle. “アジャイルソフトウェア開発スクラム”. スクラム・エバンジェリスト・グループ訳, 株式会社テクノロジックアート編, 長瀬嘉秀監訳, 今野睦監訳, 株式会社ピアソン・エデュケーション, 2003, 183p, ISBN 978-4894715899.
• Kent Beck, Cynthia Andres. “Extreme Programming Explained: Embrace Change”. 2nd ed., Addison-Wesley Professional, 2004, 224p, ISBN 978-0321278654.
• Glenford J. Myers他. “ソフトウェア・テストの技法”. 松尾 正信訳, 株式会社近代科学社, 第2版, 2006, 221p, ISBN 978-4764903296.
• 株式会社永和システムマネジメント. “ - eXtreme Programming - Embrace Change”. オブラブ. http://objectclub.jp/community/XP-jp/xp_relate/essential-ec, (参照 2018-8-10).
• 江渡浩一郎. “パターン、Wiki、XP－時を超えた創造の原則”. 技術評論社, 2009, 224p, ISBN 978-4774138978.
• 角谷信太郎. “デブサミ2009:パネルディスカッション：テストを行うこと、テストを続けること”. 角谷HTML化計画. 2009. https://kakutani.com/20090213.html#p01, (参照 2018-8-10).
• 角谷信太郎. “アジャイル開発者の習慣－acts_as_agile”. gihyo.jp. http://gihyo.jp/dev/serial/01/agile, (参照 2018-8-10).
• 規世やよい. “XP再入門”. WEB+DB PRESS. 2012, Vol.72, p.125-146, ISBN 978-4774153957.
• 佐藤善昭. “ケーススタディ 富士通ソフトウェアテクノロジーズ”アジャイルとトヨタ生産方式が融合した俊敏な開発プロセス””. PM magazine. 2005, vol.003, p.48-50, ISBN 978-4798107707.
• 独立行政法人情報処理推進機構, “アジャイル型開発におけるプラクティス活用リファレンスガイド”. IPA 独立行政法人 情報処理推進機構. 2013. https://www.ipa.go.jp/files/000026850.doc, (参照 2018-8-10).
• 野中郁次郎, 竹内弘高. “The New New Product Development Game”. Harvard Business Review. 1986. ISSN 0017-8012.
  https://hbr.org/1986/01/the-new-new-product-development-game, (参照 2018-8-16).