ガートナー ジャパン
メインメニュー ホーム リサーチ コンサルティング ベンチマーク エグゼクティブ プログラム イベント 会社情報 メインメニュー
SAMPLE RESEARCH

サンプル・リサーチ

イメージ

従来のプロジェクトがアジャイルから学べる7つの教訓

アプリケーション (APP) /APP-13-47
Research Note
N. Wilson
掲載日:2013年7月23日/発行日:2013年4月5日

本リサーチ分析レポートのテーマに関心をお持ちの方は、2013年10月15日(火)〜17日(木)に開催する 「Gartner Symposium/ITxpo 2013」 のページを是非ご覧ください。(イベント終了後も開催実績としてご覧いただけます)

 

アジャイルは、この11年間にソフトウェア開発において実績のある有効な手法へと成熟した。そのプラクティスの中には、プロジェクトの運営方法を全面的に変更することなく、従来のソフトウェア開発のライフサイクルに組み込めるものがある。

要約

主要な課題

    ● アジャイル・ソフトウェア開発では、従来のプロジェクトとはまったく異なるプロセスにおいて、いくつかの極めて有効な開発プラクティスが展開されている。

    ● 従来のプロジェクトは、これまでの開発プロセスの観点を離れ、現行のプロセスでも採用できる有益な開発プラクティスを見つける必要がある。
推奨事項
    ● アジャイルの世界からもたらされる開発プラクティスの進歩を無視しない。

    ● プラクティスの評価とパイロットを実施し、自社にとって有効なプラクティスを見つける。

    ● 実装とテストを1つのフェーズに統合する。

分析
アジャイル開発は破壊的な存在であり、しばしばソフトウェア開発に摩擦を生じさせてきた要因である。最良のソフトウェア開発プロセスをめぐる議論の中で見失われているものの、これまでに多くの革新的で有効な開発プラクティスが、アジャイル・プロジェクトで使用できるように開発されてきた。本リサーチノートでは、アジャイルの開発手法の中から、従来の開発プロセスに適用できる7つのプラクティスを検証する。これらの多くは、その起源を2001年の「アジャイル・ソフトウェア開発宣言」のはるか以前にまでさかのぼるため、それらが生み出されたことをアジャイルの取り組みの功績とすることは公正ではないかもしれない。しかし、アジャイル・プロジェクトにおいてそうした手法が幅広く活用され、洗練された結果、この10年間で、これらのプラクティスはアジャイルの取り組みと強く結び付けられるようになっている。

ソフトウェア方法論は、以下の2つの要素に大別される (図1参照)

    ● プロジェクト運営に使用されるプロセス

    ● 製品開発に使用される、設計/実装/テストの一連のプラクティス

アジャイル・プロジェクトでは、従来とは根本的に異なるプロセスが採用されるが、プラクティスの多くは、従来のプロジェクトにも適用可能である。本リサーチノートでは、従来のプロジェクトに効果的に適用できる、アジャイル実装の7つのプラクティスについて解説する。
 

図1 プロセス+プラクティス=方法論

出典:ガートナー (2012年6月)
 

シンプルな設計とコード
アジャイル開発で採用される主要な実装プラクティスでは、できる限りシンプルなコードを維持しようとする。アジャイル・ソフトウェア開発宣言は、そうしたシンプルさを「ムダなく作れる量を最大限にすること」と表現しており、この概念を適用するために、求める機能を実装する最もシンプルな設計とコードを開発する。

従来のプロジェクトでは、できる限り汎用性のあるコードを設計し、記述することを重視する。この方式によって拡張性に優れたコードを得られるが、それは通常、より複雑で抽象的なコードになる。拡張性の大半は決して生かされることなく、かなりの規模の投機的な開発が生じる。投機的な開発とは、住宅に買い手がつく前に近隣を開発するようなものである。近年の不景気の結果、荒れ地の広い範囲で住宅が売れ残っているように、投機的に開発されたソフトウェアは、しばしば使用されることなく、結果的に使用しないコードの開発、テスト、保守のためのコストが増加する。

アジャイル開発への一般的な批判には、入り組んだ、保守の難しいコードを生むことに対するものがある。実践に不備のあるアジャイル・プロジェクトではその危険があるものの、最良のアジャイル・チームでそのようなコードが生成されることはない。シンプルさは、ソフトウェアの設計とコードに正しく適用される限り、「手っ取り早くて雑な」ソリューションにつながることはない。よくできたシンプルなコードに「泥だんご (ball of mud)」構造の設計やコードがまったくないという意味ではないが、シンプルなコードとは、美しく、すぐに分かる機能性を備えている。再び宅地開発に例えるならば、シンプルな設計の場合、当初は建設される住宅や道路が少ないが、需要が増加するにつれて増やせるスペースが明らかに存在する。同様に、よくできたシンプルなソフトウェアとは、現行のニーズだけに対応しながらも、拡張が容易であり、明確な拡張の道筋を備えた構造である。

アジャイルの教訓:

    ● 現行の要件を満たす最もシンプルなコードと設計を実現する。

    ● コードは拡張に対応できるように設計し、拡張の実装は必要になるまで先送りする。

新たな情報の反映
アジャイル・プロジェクトは、プロジェクトの途中で「変化を受け入れる」ことを奨励している。アジャイル・プロジェクトは本質的に、問題の表明から始まり、その問題を解決する最良かつ最もシンプルなソリューションを目指す。実装過程で、新たな情報に応じてコードのリファクタリングを数回行うことは一般的である。従来のプロジェクトの場合、再作業は無駄とされるが、アジャイル・プロジェクトにおいて、リファクタリングはコードの改善につながるため、生産的と見なされる。熟練のアジャイル・プログラマーは、複雑なコードをよりシンプルなソリューションへとリファクタリングすることを誇りとする。複雑で入り組んだ大量のコードを廃棄し、よりシンプルで合理的なコードに置き換えることは、当然ながら、前向きな開発と見なされる。支援がなければおそらく退屈な作業となるこうした変更を容易に実施できるよう、多くの統合開発環境 (IDE) にはリファクタリング・ツールが組み込まれている。

従来のプロジェクトは、実装しようとするソリューションの具体的な説明から始まる。このように全体的な設計を事前に行う方式 (Big Design Upfront [BDUF]) の場合、設計の大部分が、十分に理解されないうちに固定される。ドメイン駆動設計の発案者であるEric Evans氏は、BDUFを「無知の中に閉じ込められること」(根拠1参照) と表現している。プロジェクトの過程で判明する新たな情報には、以下の2つのタイプがある。

    外部的な設計の見識 - 最良のソリューションにするために、ユーザーとのインタラクションはどのようにあるべきかという新たな理解:外部的な設計の見識を生かせることは、アジャイル・プロセスの核となる能力である。従来のプロジェクト過程において、外部的な設計見識を同程度に生かすことは難しい。エンドユーザーとのインタラクションの根本的な変更を伴わないならば、変更管理プロセスはおそらくより容易になるが、それでは限定的なソリューションとなる。

    内部的な設計の見識 - ソリューションの最良の構築方法に関する新たな理解:内部的な設計の見識は、実装期間中に設計をリファクタリングすることで活用される。経験を積んだ設計者は、BDUFの必要性と、プロジェクト過程で生じる見識によって詳細な設計が無効になる可能性のバランスを調整できるようになる。

アジャイルの教訓:

    ● 実装期間中に得た新たな知識を取り入れ、より適切でシンプルな問題解決の方法が発見されるたびに、コードと設計をリファクタリングする。

    ● 再作業を回避しようとするのではなく、ソリューション改善のためのリファクタリングを奨励する。熟練の設計者は、全体的な設計を事前に行う必要性と、開発過程で (特により詳細なレイヤにおいて) 設計が変更される現実のバランスを調整できる。

モックアップによる設計の実証
アジャイル・プロジェクトは、開発するソフトウェアのエンドユーザーまたはその代理人に対し、定期的にデモンストレーションを行うことを極めて重視する。このデモンストレーションこそが、アジャイルにおいて、エンドユーザーの問題を解決するアプリケーションが絶え間なく提供される主な理由である。デモによって、ユーザーは設計の変更がより安価に行える時期に、ソリューションを具体的に把握できる。アジャイル・プロジェクトにおいて要件がどのように処理されるかについては、「Agile and the Rest of the Organization: Requirements Definition and Management」を参照されたい。

従来のプロジェクトの場合、プロジェクト終了時に実現されるべき機能が、通常は要件仕様書に詳細に記載される。しかし、たいていの場合、エンドユーザーはソリューションを思い描くことができず、その仕様書を理解することなく要件を承認してしまう。

アジャイルの教訓:

    ● 仕様書はできる限り視覚的なものにする。ユーザー・インタフェース案のモックアップは、設計仕様をエンドユーザーにとって身近なものにする上で大いに役立つ。

    ● 開発の段階で繰り返しデモンストレーションを行う。不適切なソリューションを構築していることに気付くタイミングとして、開発の途中が良いというわけではないが、ソリューションのデプロイ後よりは望ましい。

ペアでの作業による協力
アジャイル・ソフトウェア開発は協調的なプロセスである。ペア・プログラミングとは、ソフトウェア・エンジニアがペアを組んでコードを開発する協業的なプロセスである。こうすることで、コードの見直しが継続的に行われ、異なるスキルセットを有するエンジニア間における協力とクロストレーニングが奨励される。2人のエンジニアに1つの作業を行わせることは無駄に見えるかもしれないが、調査によると、ペア・プログラミングの生産性は、個人でのプログラミングと同程度である (根拠2参照)。ペア・プログラミングは、クロストレーニングとコードの品質改善に有益である。

アジャイルの教訓:

    ● ペア・プログラミングを奨励する。多くのソフトウェア・エンジニアは本質的に内向的であり、もしペアを組むことを強制すれば、生産性を損ないかねない。しかし、ペアを組んだエンジニアだけに特別な作業環境を割り当てることによって、口頭でペア・プログラミングを促すことが可能である。

    ● エンジニアのペアに作業を割り当て、両者に対する (少なくともコード変更のレビューなどの) 期待値を設定し、ペア・プログラミングを促進する。

実装とテストの融合
アジャイル・プロジェクトでは、開発プロセスをコーディングとテストのフェーズに分離しない。その代わりに、テストはプロセスのできる限り早い時期に作成される。実装とテストのフェーズを融合することで、チームの構成も変わり、開発チームは実装とテストの要員で構成されるようになる。テスト要員は、開始当初からプロジェクトに携わることで、実装される要件についての理解を深めることができる。ホワイトボックス・テストは、一般的にコード実装者が、単体テストの形式で記述する。機能/受け入れテストの自動化された形式によるブラックボックス・テストは、専任の品質保証 (QA) テスト担当者が、コーディング担当者の支援の下で作成する。テストの適度な独立性を保つために、たいていの企業はマトリクス構造を採用し、QA/テスト要員向けに別の管理体制を備えている。

多くのアジャイル・チームは、このプロセスをさらに進め、コードの記述前にテストを記述する。こうすることで、チームの一員であるQA要員が、ソリューションの実装に近いところにいることで、テストの際に見方が偏ってしまうリスクを抑えられる。コードの開発前にテストを設計することで、テストは、実装が当初の要件に合致しているかどうかの確認になる。また、要件の誤解に起因する欠陥を、修正がより容易な早い時期に発見できる。

自動化テストを採用する場合、テストの作成は高額になるが、実施ははるかに安価になる。テストを最初に記述することで、テストからは最大の価値を得られる。テストを利用して、コードの開発途中で欠陥を発見できるからである。単体テストのレベルにおいて、テストを最初に記述することは、テスト駆動型開発 (TDD) と呼ばれる。ホワイトボックス方式の機能/受け入れテストの場合は、振る舞い駆動型開発または受け入れテスト駆動型開発 (ATDD) と呼ばれる。アジャイル・プロジェクトのテストの詳細は、「Agile and the Rest of the Organization: Software Quality and Test」を参照されたい。

従来の開発プロジェクトの多くが発展し、開発フェーズと並行してテスト・フェーズを実施できるようになっている。しかし多くの場合、具体的なユースケースのコーディングは、テストのためにQAに引き継がれるまでは完成途上にある。結果として、実装とテストはいまだに別々のサイロに閉じられている。テストの遅れは、欠陥の発見を遅れさせるため、欠陥が見つかった際に修正するコストは膨らむ。欠陥の数や、それらを修正するための労力が未知であるため、従来のプロジェクトの多くは、テスト・フェーズでスケジュールが遅れるか、または完全に失敗する。

アジャイルの教訓:

    ● 実装とテストを行う職務横断的な開発チームを結成する。

    ● プロセスの早期に、できればコードの記述前に、自動化テストを作成する。

継続的な統合
アジャイル・プロジェクトは、できる限り早期に欠陥を発見するために、継続的な統合とテストを採用している。こうすることで、プロジェクト終盤の安定化フェーズを廃止する。テスト・フレームワークを採用し、自動化テストを記述する。継続的統合サーバはソース・コントロール・システムに接続されており、コードの変更が提出されるたびにビルドが開始される。アジャイル・プロジェクトにおいて継続的統合がどのように行われているかの詳細は、リサーチノート、APP-11-89、2011年9月9日付「アジャイルに求められる3つのC (継続)」を参照されたい。

夜間ビルドの構想は、従来のプロジェクトにおいても目新しいものではない。自動化テストを伴わずにビルドを実行すると、コード基盤の安定性について完全な全体像がつかめない。さらに、1日1回のビルドの実行によって、複数の変更が同時にテストされることになり、ビルドの欠陥の原因究明が困難になる。従来のプロジェクトのテストは、ビルドの工程後に行われるため、バグが生じたかなり後に欠陥が発見される。

アジャイルの教訓:

    ● 自動化テスト・フレームワークを採用し、ビルドごとに自動化テストを実行する。

    ● 継続的統合サーバを使用して、迅速にビルドとテストの欠陥を発見する。継続的な統合とテストは、プロジェクト全体を通じてコード基盤の安定性を維持する上で有用であり、安定化フェーズの期間を大いに短縮し、不確実性を大幅に減らすことができる。

定期的なレトロスペクティブの実施
アジャイル・プロジェクトの開発チームでは、定期的にレトロスペクティブ (振り返り) を行い、前回以降に遭遇した課題や成功について話す。これによって、ソフトウェア開発で採用されたプロセスやプラクティスの継続的な改善が可能になる。

従来、レトロスペクティブはプロジェクトの最後に事後分析として行われていた。しかし、この場合、結局はプロジェクトの遅れの原因が何であったかが焦点になる。そのため、ミーティングは、プロセスやプラクティスの改善についてよりも、責任の所在の追求になっている。

アジャイルの教訓:

    ●プロジェクト全体を通じて、レトロスペクティブを定期的に実施する。

    ● プロセスやプラクティスにかかわる問題に着目し、個人への責任の追求を目的としない。

アジャイル開発プロジェクトを構成する革新的なプラクティスは、ソフトウェア開発プロセスを全面的に変更せずとも、従来の開発プロジェクトに適用することが可能である (図2参照)

図2 アジャイルの7つの教訓

出典:ガートナー (2012年6月)

推奨リサーチ
・ 「The Agile GPS: Planning in the Field」
・ 「アジャイル方法論への文化の転換:個人 (Me) からチーム (We) へ」(APP-10-72、2010年6月10日付)
・ 「アジャイルのベスト・プラクティス:自動化テストによる開発の迅速化」(APP-13-26、2013年2月15日付)
・ 「アジャイルへ移行するベスト・プラクティス:Scrumのコーディング手法」(APP-12-139、2012年12月25日付)

根拠
1. 詳しくはDomain-Driven Design Community ( http://domaindrivendesign.org/ ) を参照されたい。引用部はDan North氏らによる『Introducing Deliberate Discovery』 ( http://dannorth.net/2010/08/30/introducing-deliberate-discovery/ ) に書かれたEric Evans氏の言葉。

2. 『The Costs and Benefits of Pair Programming』および『Strengthening the Case for Pair-Programming ( http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF )』を参照されたい。

(監訳:片山 治利)

APP: APP-13-47

※本レポートの無断転載を禁じます。

←INDEXに戻る

 

gartner.com
TOP OF PAGE
Copyright