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

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

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

スクラムとは

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

スクラムの由来

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

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

スクラムの特徴

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

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

スクラムのプロセス概要

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


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

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

  1. スプリントプランニング:
    • プロダクトオーナーと開発チームは、全体のプロダクトバックログ(実装予定機能の一覧)の中からスプリント(反復期間)で実装する機能を決定します。
    • 選定された機能一覧をスプリントバックログといいます。
  2. デイリースクラム:
    • 決まった時刻に開発チームは短時間のミーティングを実施します。
    • 開発の進行状況や課題などを共有し一日の仕事の進め方を決定します。
  3. スプリントレビュー:
    • スプリントの最後にステークホルダーに対して開発した機能をデモンストレーションします。ステークホルダーからフィードバックを受けます。
    • レビューの結果がOKの機能はリリースされますが、NGの場合には次回以降のスプリントにリリースは持ち越されます。
  4. スプリントレトロスペクティブ:
    • スプリントレビューの終了後、スクラムチームは今回のスプリントのふりかえりを実施します。
    • レトロスペクティブとは「ふりかえり」のことです。次のスプリントの改善計画を行います。

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

スクラムにおける役割

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

プロダクトオーナー(PO)
プロダクトオーナーはソフトウェアの価値を最大にすることに責任を持ちます。
  • プロダクトバックログを優先順位順に並べ(並び替え)ます。
  • 開発チームに対して次に開発する機能を示し、開発の動機づけを行います。
スクラムマスター(SM)
スクラムチームの価値を最大にする役割があります。
  • 開発チームがスクラムイベントを理解し、スプリントを円滑に回すことに責任を持ちます。
  • プロダクトオーナーに対して開発チームの現状を説明し理解を得ます。
  • ステークホルダーに開発プロセスの実態や狙いを説明し理解を得ます。
  • スプリントバックログの開発に寄与しない活動がないか監督し改善に寄与します。
開発チーム
スプリントごとにソフトウェアを提供することに責任を持ちます。
  • 開発チームは実際に動作するソフトウェアを開発します。
    (リリースの可否はスプリントレビューで判断されます。リリース判断可能な状態にすることに責任を持ちます)
  • 開発プロセスや開発手法の新たな採用や、改善の方法を決定します。
  • 開発チームの人数は7±2人が望ましいとされています。

スクラムによる効果

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

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

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

書籍「アジャイルソフトウェア開発スクラム」から

ニワトリとブタがいた。
  ニワトリは「さあ、レストランでもやろうよ」と言った。
  ブタはよく考えてから「レストランの名前は何にしようか」と言った。
  ニワトリ は考えた。「ハム-エッグさ」
  ブタは言った。「僕は止めておくよ。君は産むだけだけど、僕は切り刻まれるんだよ」

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

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

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

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

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

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

XPの由来

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

XPの特徴

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

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

XPのプロセス概要

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


図 XPのプロセス概要

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

  1. 計画ゲーム:
    イテレーションの期間内に実装する機能を決定します。
    • 開発技術者は機能の規模を見積り、オンサイト顧客は機能の優先順位を提示します。
    • 両者のやりとりによって開発機能が決定されます。
  2. イテレーション:
    オンサイト顧客と開発技術者が協働して開発を行います。
    • オンサイト顧客は機能の受入条件を作成します。
    • オンサイト顧客は開発技術者と共働して受入テストを作成、実施します。
    • オンサイト顧客と開発技術者は常に同席し緊密なコミュニケーションのもとで、機能の詳細/技術上の制約/ビジネスサイドの目的を明らかにします。
    • 開発技術者は機能の開発と同時にテストを作成実施し、ソフトウェアが正常に動作する状態を維持します。
    • 動作するソフトウェアを共にみて触れることで、オンサイト顧客と開発技術者は齟齬のないコミュニケーションを図ります。
  3. リリース:
    イテレーションの終了時に、オンサイト顧客の受入テストが完了している機能をリリースします。

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

XPのプラクティス

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

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

全員同席
十分な広さのスペースに全員が集まって開発を行います。オンサイト顧客も常に同席します。
技術上の問題の発見や解決までの時間を短縮するとともに、ビジネスサイドの要望や詳細な仕様も即座に確認できるため誤解を極めて短時間で検知できます。
計画ゲーム
オンサイト顧客と開発技術者が優先順位と技術的な見積りをもとに、イテレーションで開発する機能を決めます。(見積りには実装方法の検討つまり設計行為が必要です)
ビジネスサイドからのリリースタイミングの制約と、チームが開発可能な規模の折り合いをつけることが目的です。 ビジネス戦略の実現に、開発チームが無理なく継続的に貢献することが可能となります。
ストーリー
開発する機能を、顧客から見てどう動くのかを簡潔な文章で表現します。
機能単位での増加型開発を容易にします。
ストーリーには受入条件を併記するため、過剰な実装を防ぐと共に品質の向上が図れます。
ペアプログラミング
1台のPCを2人ペアで使い開発します。
調査、設計、実装、テストなどの開発作業をペアで一緒に実行します。
問題の発見、解決策の実行が即座に実施されるため、機能提供の時間が短縮されるとともに品質が向上します。
個人の知見や知識が伝搬され、開発技術者のスキル、チームの開発能力、ソフトウェアの品質が向上します。
継続的インテグレーション
開発中のソフトウェアのビルド、テストを自動的にかつ即座に実行します。
「いつでも出荷できる状態」を継続的に保つことを目指し、「テストされていない時間」を最小化することで問題の発生をすぐに検知し、すばやい対応が行えます。
コードの共同所有
チームのメンバーはすべてのコードを参照し改修することができます。コンポーネントごとの「担当者」は存在しません。
個々の開発技術者が広範囲のコードを扱うことで、個々の開発技術者の知識範囲が拡大します。
担当者不在による開発遅延の防止に効果があります。

XPにおける役割

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

コーチ
ストーリーの開発には直接参加しません。技術的な、例えばアーキテクチャやテスト戦略などに課題が発生した場合には、遊撃的に解決にあたります。
開発の停滞を防ぐとともに、開発技術者に対して具体的に支援することでチームやメンバーの能力向上に寄与します。
トラッカー
完了状況と残量つまり進行状況を常に追跡(トラッキング)して把握します。
チームの負荷状況やイテレーション内での完了見込みをチームに知らせます。
顧客
顧客はチームの一員です。オンサイト顧客と呼ばれ開発技術者と常に同席します。
ビジネス的な視点に基づき、チームが開発する機能の意思決定を行います。
開発する機能とその受入条件を明示し優先順位を付けます。
受入テストを開発技術者とともに作成し実行します。
ビジネスサイドの目的や仕様詳細を開発技術者に伝えます。

XPによる効果

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

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


図 XPのプロセス概要(再掲)

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

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

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

注釈

参考文献

  • 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).

ページの先頭へ

Agile+メインビジュアル