アジャイルソフトウェア開発概論 Victor Szalvay アジャイルとは何でしょうか。アジャイルは、自分の組織の改善にどのよ うに役立つのでしょうか。これらは、このアジャイルソフトウェア開発手法 紹介記事でその答えを明らかにする質問の一部にすぎません。 この記事は、開発の生産性向上に関心のあるITマネージャおよび CXO向けに書かれたものです。最初に、ソフトウェア開発で一般的な 2つの主要な開発手法、「ウォーターフォール手法」とも呼ばれる従来 の逐次型手法と、アジャイルをサブセットとして含む反復型手法を紹 介します。ここでの目的は、ウォーターフォール手法の欠点を指摘し、 反復型手法、特にアジャイル手法による解決方法を示すことです。 アジャイルとは何でしょうか。アジャ イルは、自分の組織の改善にどの ように役立つのでしょうか。これら は、このアジャイルソフトウェア開発 手法紹介記事でその答えを明ら かにする質問の一部にすぎませ ん。 パート I：従来のウォーターフォール手法の欠点 ウォーターフォールソフトウェア開発の基本は、作業を段階的に逐次進める方法で複雑なソフトウェアシステムを構築 できることです。ウォーターフォール手法では、最初に全ての要件を収集し、続いてすべての設計を完了し、最後に主 要設計を本番稼動が可能なソフトウェアに実装します。この手法では、ビジネスや技術の状況変化を考慮して要件 や設計案を再検討することなく、シングルパスで複雑なシステムを構築できるとされています。このモデルが初めて紹 介されたのは、1970年に発表されたWinston Royceの論文で、当初は政府のプロジェクトで使用される予定でした 1。 ウォーターフォールでは、ソフトウェア開発を生産ラインのベルトコンベヤーになぞらえます。「要求分析者」は、システム の仕様をまとめ、完成した要求仕様書を「ソフトウェア設計者」に渡します。「ソフトウェア設計者」は、ソフトウェアシス テムを設計し、コードの記述方法を文書化した図表を作成します。設計図表は「開発者」に渡され、「開発者」は設 計に基づいてコードを実装します(図1を参照)。 図1： 従来の手法：逐次段階的手法 これまでのITマネージャは、ウォーターフォール手法を使用し、並々 ならぬ努力を払って大規模な開発計画を作成し、実行してきまし た。これらの計画は一般に、開発プロジェクトが始まる前に数カ月 あるいは数年後までの詳しい作業や開発グループの各要員の依 存関係をガントチャートやパート図を使って作成されます。しかしな がら、過去のソフトウェアプロジェクトに関する調査によれば、時間 通りにまた予算通りに進んだプロジェクトは9～16パーセントにすぎ ません 2 。この記事では、それほど多くのケースでウォーターフォール 重要なソフトウェアシステムを構築 するために、ソフトウェアグループを 雇ったとします。開発者たちが 必要とする微細な情報を、即座に 提示することができると思いますか。 手法が失敗した理由に対する現在のコンピュータ科学者の見解を 要約します。また、ウォーターフォールの主要な代替手法である「アジャイル」手法についても検討します。アジャイル手 法は、プロジェクトのライフサイクルを通じて、要求、設計、実装、テストを継続的に行う、付加的で反復的な開発に 重点を置いています。 事前の要求分析 要求とは何でしょうか。関係者の観点では、要求とはシステムの機能および仕様です。要求は、開発者が構築する ものを定義します。例えば、システムには1時間当たり10,000件の購入を処理できるEコマース機能を備えたウェブサイ トが含まれていなければならない、あるいは99.999パーセントいつでもアクセス可能なシステムであるなどです。 ウォーターフォール手法の最大の問題のひとつは、この手法が、全てのプロジェクトの要求をプロジェクトの初期に的確 に収集できることを前提とする点です。図1では、ブロック1が、ソフトウェア開発プロジェクトの要求分析フェーズを表し ています。分析者は、数週間あるいは数カ月間あくせくと働き、提案されたシステムに関して収集できるあらゆる情報 を、包括的な「ソフトウェア要求仕様書(SRS)」という文書にまとめます。この作業が完了すると、SRSは設計者に送 られ、要求分析者は次のプロジェクトの作業に移ります。 重要なソフトウェアシステムを構築するために、ソフトウェアグループを雇ったとします。開発者たちが必要とする微細な 情報を、即座に提示することができると思いますか。そのようなお客様に会ったことはまだありませんし、そのようなお客 様に会ったら非常に苦労することになります。初めに、対応しなければならない領域を検討します。業務ルールと例外、 拡張性とユーザの同時サポート、ブラウザやOSへの対応、ユーザの役割と制限、ユーザインタフェースの基準などの領 域があります。実際のところ、関係者はプロジェクトの開始時にシステムに関する全ての情報を開発者に伝えることが できないというだけの理由で、事前の要求定義で一部の重要な詳細が欠落することを避けられません 3。つまり、要 求は通常、「変更指示」という形で、要求フェーズ以外の段階で変更されます。そして、多くのウォーターフォールプロ ジェクトで、要求変更は非常に費用がかかる可能性があります。要求変更のため、複雑な設計は著しく影響を受け る可能性があり、回りまわって実装およびテストの戦略にも影響を及ぼします。開発者はプロジェクトの初期に全てを 決定せざるを得ないため、ウォーターフォールプロジェクトでの変更コストは、やがて急激に増加します。 ビジネスニーズが新しいものであったり、システムのある側面が急速に変化していたりまだ定義できない状態だったら、 どうなるでしょうか。多くの場合、特に情報が簡単に入手できる今日 のような時代では、ビジネスの環境や目標は急速に変化します。変 橋の建設は、物理的および数 更にかかる費用が急激に増加する厳格な長期プロジェクトに固執で 学的法則に依存していますが、 きるだけの財政的余裕がありますか。例えば、まもなく標準化される 検査のシミュレータを開発するよう、国営の検査準備機関から委託さ ソフトウェア開発には、法則や れたとしましょう。検査自体がまだ公表されていないので、開発開始 基盤となる明らかな確実性は 時には、検査で問われるであろう設問の種類は不明でした。それでも、 ありません。そのため、ソフトウェア 検査の公表後まもなくシステムは完成しなければなりません。ソフトウ ェア開発業界は、変更にかかる費用を抑えた柔軟な開発計画に対 はほとんどいつも不備があったり、 応することを市場に強いられています。 最大限に利用できません。 顧客は、何かを見て感じないと、自分が必要なものを本当には知る ことができません。IKIWISI (目にすれば分かる)法則は、ソフトウェア開発の顧客は機能ソフトウェアを目にして試用す れば本当に必要なものをより明確に説明できるということを表しています。私は、ときどき「描画」を例にしてこの状況 を説明します。下手な絵描きは、絵を描くとき、筆を進めながらその絵をながめる必要があります。目を閉じて同じ絵 を描こうとすると、良い絵は描けません。しかし、これは、ウォーターフォール手法で顧客が求められることです。つまり、 顧客は、進捗を定期的に評価する機会を持たずにシステム全体を明確に説明し、必要に応じて要求を調整する必 要があります。ウォーターフォールは、「フェンス越し」のアプローチです。ユーザから要求を収集し、後日完成した製品 をユーザーに提示します。顧客は、ソフトウェアの開発過程を注意深く見守ることなくそのソフトウェアを完璧に説明す ることは困難であると気付いていますので、ウォーターフォール手法は実に不自然です。 要件の未定義、変更、明確化の問題は、ウォーターフォール手法のプロジェクトにとっては非常に大きな課題です。と 言いますのは、後から費用のかかる変更する危険を冒しながら、全ての要求を、定義することにより前もって把握しな ければならないからです。 2 アジャイルソフトウェア開発概論： Copyright ©2004-2010 CollabNet, Inc . 製造より新製品開発に近いソフトウェア開発 ソフトウェア開発は、システムに影響を及ぼす無数の変数を伴う非常に複雑な分野です。全てのソフトウェアは、数 学的あるいは物理的な確実性を備えて構築することができないため、不備があるものです。橋の建設は、物理的お よび数学的法則に依存していますが、ソフトウェア開発には、法則や基盤となる明らかな確実性はありません。そのた め、ソフトウェアはほとんどいつも不備があったり、最大限に利用することができません。また、ソフトウェアプロジェクトの 構成要素は通常、ほかのソフトウェアシステム(プログラミング言語、データベースプラットフォームなど)であること、構成 要素として機能するそれらのシステムにはバグがあり、自信を持って信頼することはできないことを考えてみてください。 ソフトウェア開発の基盤は本来不安定で不確かなので、ソフトウェアを開発する組織は、管理コントロールから大きく 外れた変数が存在することを認識する必要があります。したがって、ソフトウェア開発は、流れ作業による製造よりも 新製品の研究開発に似ていると言えます。ソフトウェア開発は、革新であり、発見であり、芸術です。開発プロジェク トへの参加は、そのつど画一的な型にはまったソリューションでは太刀打ちできない、手のかかる新たな挑戦です 4。 ウォーターフォール手法では、事前の設計が、開発工程に影響を与 える可能性のある全ての変数を考慮していると仮定します。実際のと ころ、ウォーターフォールプロジェクトは、起こり得るあらゆるリスク、緩和 策、不測の事態を列挙する作業に多大な労力を注ぎます。しかし、 ウォーターフォールプロジェクトに影響を与える可能性のある全ての変 数を予測することは可能なのでしょうか。ウォーターフォールプロジェクト の限られた成功例を考え、経験に基づけば、答えは「不可能」です 5。 開発を最初から最後まで完全に 記述できるほど単純なソフトウェア システムはほとんどありません。全 てのソフトウェアプロジェクトに内在 する不確実性と複雑性は、不確 実性と多数の未知の変数に対処 する、適応性のある開発プランを 必要とします。 したがってウォーターフォールで、ソフトウェア開発の動的な工程を静的 な流れ作業になぞらえても、正確には一致しません。この理想的な、 そして非現実的な開発手法では、各工程は、逐次実行された場合 に成功するように定義されます。最初のステップはX、2番目のステップ はY、結果は必ずZです。逐次実行した場合に新しい製品が完成する一連のステップに、調査を組み込むことができ るのでしょうか。この型通りの手法が十分なら、医学分野の研究者は変数を方程式に当てはめるだけで新薬を発見 できます。反対に、1970年代以降、トヨタ、ホンダ、富士通、3M、HP、キャノン、およびNECが先導した製品開発企 業は、新製品開発のアプローチとして、逐次的な「段階的プログラム計画(PPP)」手法の代わりに、従来の開発フェ ーズが製品ライフサイクル全体に重なる柔軟で総体的な手法を採用しました 6。この結果、費用と出荷までの期間が 激減し、最終的には、「リーン開発」および「かんばん方式」による製造の普及につながりました。日本の自動車メーカ ーのトップに追随し、新製品開発において、逐次型のウォーターフォール手法は、ソフトウェア開発以外の業界では 1990年代に事実上使われなくなりました 7。しかし、単純な流れ作業の連続としてソフトウェア開発を分類するという 長年に渡るITマネージャたちのこだわりが、この業界においては、より優れた手法への進化を妨げました。ほかの新製 品開発業界が何十年もその恩恵を受けてきたのとは対照的です。ソ アジャイル手法は、工程の膨大 フトウェアのような最先端技術の分野が、開発手法に関して、より伝 な間接費や成果物よりも、生 統的なエンジニアリングに後れを取っているのは皮肉なことです。 産性と価値を重視します。 開発を最初から最後まで完全に記述できるほど単純なソフトウェアシ ステムはほとんどありません。全てのソフトウェアプロジェクトに内在する 不確実性と複雑性は、不確実性と多数の未知の変数に対処する、適応性のある開発プランを必要とします。 3 アジャイルソフトウェア開発概論： Copyright ©2004-2010 CollabNet, Inc . パート II：反復とアジャイル手法 反復型開発 開発の各フェーズを繰り返すことができるというだけで、プロジェクトの効率が劇的に向上します。各フェーズを繰り返す 考え方は、「反復型開発」と呼ばれます。反復プロセスでは、従来のライフサイクルは一連の「短い」反復(1つの反復 は通常は2～4週間)に、各反復は従来の開発の各「フェーズ」になります。例えば、要求の収集は定期的に再検討 される進行中のプロセスです。新しい要求が明らかになり、プロジェクトの範囲が広がるにつれ、反復を繰り返すごとに、 反復プロセスは継続的に要求を取り込んでいきます。興味深いことに、 (ウォーターフォールプロセスで有名な) Winston Royce氏は、後に、自分の考えが間違って理解されていること、「シングルパス」のフレームワークは決して機 能しないこと(彼の論文では、実際に尐なくとも2番目のパスが推奨されています)を述べています 8。複雑性およびリス クの要因に適切に対処するには、プロジェクトのサイクルを通じて複数の「パス」または反復が必要です。 図2：反復型手法：開発フェーズの重複 反復型開発のこの考え方は、1980年代の「リーン開発」に由来します。上述のように、日本の自動車メーカーは、段 階的で逐次型手法を放棄して反復型手法を導入しただけで、驚異的な効率化と技術革新を実現できました。反 復型手法では短期間のマイルストーンでプロトタイプが開発されました(図2を参照)。各フェーズは、実際には開発の ライフサイクル全体を通して連続する層でした。要求、設計、および実装のサイクルは、短期間のマイルストーンのた びに繰り返されました。この「並行開発」のアプローチから、試行錯誤の実験を行い、最終的にはそれにより現状が分 析されて効率的な技術革新につながるということが分かりました 9。ある業界から別の業界を直接類推しても決してシ ームレスではありませんが、リーン開発の成功は、統一プロセス、Evo、スパイラル、およびアジャイルを含む広範な「反 復」ソフトウェア開発手法に影響を与えてきました。 アジャイル手法：変更の受容 アジャイル手法は、工程の膨大な間接費や成果物よりも、 生産性と価値を重視します。アジャイル手法は90年代から 存在していましたが、アジャイルの価値を要約したアジャイ ルマニフェスト 10は、2001年に作成および署名されました。 「アジャイル」とみなされるプロセスでは、 個々の反復で、完全に動作する機能の 開発または機能の追加が行われます。 このようにして、完成品は一部分ごと、 反復ごとに開発されていきます。 アジャイル手法は、ソフトウェア開発のための反復的メカニ ズムの普及を促し、さらに設計-コーディング-テストを、反 復ごとに1回ではなく1日に最低1回に強化して(1日に1回より頻度が低い場合)、ソフトウェアのライフサイクルの反復 の特性を向上させました。アジャイルの未来を予見したKent Beckは、20年以上も前にBarry Boehm 11 が開発した 従来の変更コスト曲線に挑戦しました。Beckのモデ ルでは、システムの品質を維持または向上させながら、 プロジェクトのライフサイクルの遅い時期でも、変更コス トを抑えることができるとされています 12。Beckの理想 的 な 「 横 ば い 」 の 変 更 コ ス ト 曲 線 は 、 Alistair Cockburn13 およびScott Ambler14 によって、現在の 企業の現実を反映するよう修正され、緩やかになって います。それでもなお、変更コストが完全に横ばいで なくても、アジャイルの理想を適用して、ソフトウェアラ イフサイクルを通じた変更コストを削減することができ ます。 この「よりフラット」な変更コスト曲線を実現するため、 図3：変更コスト曲線 4 アジャイルソフトウェア開発概論： Copyright ©2004-2010 CollabNet, Inc . アジャイル手法は、コスト効率が高い変更を可能にする多数のエンジニアリング基準を推進しています。執筆および 講演活動を行っているMartin Fowlerは、短時間での開発や最低限の事前設計などのアジャイルの長所をもたらす 「イネーブリング」の実践としてテストおよび継続的反復を記述しています 15。「テスト駆動型開発」は品質第一のアプ ローチです。このアプローチでは、開発者によるテスト(「単体テスト」と呼ばれます)がその機能のコードより先に記述さ れます。大掛かりな事前の設計分析のための多大な努力を重視するのではなく、差し迫ったビジネスニーズに応じて 機能のコードを尐し追加します。開発者が、発覚していないリグレッションエラーを恐れず積極的にコードを変更でき るようにする装置として機能することが、急速に進化するコードの周辺に構築された自動テスト群の役割です。 テストおよびリファクタリングの機構を備えたオブジェクト技術とモダンな統合開発環境(IDE)は、Boehmの変更コスト 曲線を無効にし、プロジェクトのライフサイクル後期においてでも、コストを抑えた変更を可能にします。 アジャイル手法：付加的かつ経験的プロセス アジャイル手法は、「追加開発」が特徴であり、そのために他の反復型手法(RUPなど)と区別されます。*追加開発と は、製品開発ライフサイクルを通じて、製品が機能ごとに構築されていく開発です。「アジャイル」とみなされるプロセス では、個々の反復で、完全に動作する機能の開発または機能の追加が行われます。このようにして、完成品は一部 分ごと、反復ごとに開発されていきます。したがって、アジャイル手法は反復的で付加的なプロセスです。 アジャイルプロジェクトの管理方法として知られているスクラム アジャイル手法で一般的な、ソフト は、複雑で変化するソフトウェアプロジェクトの管理に、経験 的なプロセスコントロールの概念を取り入れました。スクラムで ウェアのひんぱんなデモンストレーションと は、単純な定義済みのプロセスを使用するだけでは、複雑で リリースにより、顧客は定期的に「ソフト 動的なソフトウェアプロジェクトを効率的に管理できないと考え ウェアを試用」し、フィードバックを行う ます。リスク要因と新たな要求が、定義済みプロセスが不十 分なソフトウェア開発をある程度複雑にします。これまでに試 機会に恵まれます。要するにアジャイル みはありましたが、ソフトウェアプロジェクトの途中で起こり得る は、企業が「適正な製品」を開発する 全ての状況に対処する定義済みプロセスを含む包括的な単 のに役立ちます。 体ライブラリは存在しません。実際のところ、製造業界は、例 えば特定の化学工程の記述および定義が非常に難しくて不 可能であることを以前から知っています。代わりに、経験的あるいは適応的管理手法を導入し、必要な成果を達成 するために化学工程を定期的に計測し、調整しています 16。各反復から具体的な追加機能が開発されるので、スク ラムプロセスでは、プロジェクト計画は、開発の経験的現実性に基づき、継続的に検証され、適応します。 リーンの考え方 アジャイルが組織にとってどのようなメリットがあるかを分析する別の有効な方法は、リーン生産方式をソフトウェア開 発に適用することです。全業界の分析はほんのわずかですが、アジャイルメソッドの概念は、1980年代の日本の生産 性ブームに基づいています 17。 例えば、「尐量バッチ生産」の原則を考えてみましょう。第一に、尐量バッチ生産で製造されたものは、フィードバックル ープが短いので、品質と効率に優れています。コントロールはよりひんぱんに調整され、リソースは「待ち行列」を避け るよう効率的に使用されます(「待ち行列理論」と制約条件の理論を参照してください)。第二に、アジャイル手法では、 責任を負えるぎりぎりの瞬間まで、取消しできない決定を先延ばしにすることが奨励されます。アジャイル手法による ソフトウェア開発を導入している多くのソフトウェア開発組織は、この方法が予想もしなかった別の選択肢を提示して くれることに気付きます。プロジェクト開始時の決定にしばられず、組織は、選択肢を残して、より正確な情報を利用 できるようになった時に決定するようにすることで、リスクを軽減できます。第三に、頻繁なあるいは継続的な統合の考 え方により、ソフトウェア開発チームは同期をとって作業できます。チームは尐しの間単独で作業できますが、コードベ ースが長期に渡って分岐しないので、プロジェクト後半の大規模な統合に関するリスクが軽減されます18。 5 アジャイルソフトウェア開発概論： Copyright ©2004-2010 CollabNet, Inc . アジャイル要件：企業 ROI の重視 上記の理由から、アジャイルプロジェクトでは事前の要求収集を行いません。顧客は、プロジェクトの開始時に考え付 く実装に必要な全ての要求を、効率的に詳しく定義することができません。顧客は、多くの場合、十分な情報に基づ いた決定を行うための情報を入手するまで、システムに関する決定を延期することを希望します。アジャイルは、透明 性、開かれたコミュニケーション、顧客への直接的関与を重視します。アジャイル手法で一般的な、ソフトウェアのひん ぱんなデモンストレーションとリリースにより、顧客は定期的に「ソフトウェアを試用」し、フィードバックを行う機会に恵ま れます。要するにアジャイルは、企業が「適正な製品」を開発するのに役立ちます。反復的手法では、顧客による決 定も延期が可能です。決定は、その選択肢を最適化するためにより優れた情報または技術を利用できる将来の反 復に延期できます。例えば、現時点で必要な機能が利用できないという理由で、あるアプリケーションのデータベース パッケージの選択を延期したとします。このため、データベースに依存しない方法でシステムを構築していたところ、問 題を解決したデータベースベンダーから新しいバージョンがリリースされました。 アジャイルの最も優れた長所のひとつは、すべての要求を把握する前に作業を開 始できる点です。多くの組織は、多数の要求仕様を送り出す十分な人数のビジネ ス分析者を配置できません。反対に、私たちの経験では、開発プロセスのボトルネ ックは、詳しい要求分析を行う顧客の分野の専門家を確保できない結果であるこ とが尐なくありません。これは特に、特定分野の専門家がさまざまな仕事を担当し ているため、2～3カ月のまとまった要求分析に専念できない小規模な企業に該当 します。したがってアジャイル手法は、顧客が簡単に把握できる細分化された要求 への対応に理想的です。 優先度の高い機能だ けでも本番稼動すれ ば、全く稼動しないよ りはましです。 アジャイルプロジェクトでは、どのようにして作業の優先順位を決めるのでしょうか。Standish Groupの調査によれば、 典型的なソフトウェアシステムでは、機能の45%は実際には全く使用されず、それ以外の19%の機能はほとんど使用さ れません 19。これは主に、価格に対する費用の比率を検討したり把握可能になる前に、事前設計で使用されない 機能が指定されたためです。したがって、最初に事業価値の高い機能に焦点を合わせることが、効率的なアジャイル 開発に欠かせない要素になります。開発の方向を(反復ごとに)すばやく変更できるうえ、変更にかかる費用は低額な ので、顧客は、各反復の開始時にビジネス要因を見直し、事業のROIに応じて現在の反復で開発対象に含める機 能を選択する貴重な機会を得ることができます。当然のことながら、開発チームは顧客に技術的なリスクを提示する 必要がありますが、結局のところ、開発チームが何を構築するかを決定するのは顧客です。 アジャイルによる意思統一 アジャイルを調査している方から最も多くいただく質問は、「事前設計がない場合、ソフトウェアの完成をどのようにして 知るのですか。」というものです。この質問の後には、当然、「そのようなプロジェクトの予算はどのようにして立てればい いのでしょうか。」という質問が続きます。痛い所をついた質問です。あらゆることを事前に設計せずにソフトウェアをデモ ンストレーションできる、短い反復サイクルで作業を開始しましょう。ただし、私たちは、あらゆることを事前に設計でき ないことを既に知っています。 アジャイルの答えは、プロジェクトがきちんと進んでいるかどうかを演繹的に推測するのではなく、経験に基づいてプロジ ェクトの進捗を確認することです。スクラムやXPなどのアジャイル手法では、速度という概念が使用されます。これは、 ある時間で区切られた反復でチームが完了可能な、およその作業量です。チームがある速度を定めたら、プロジェク トバーンダウンチャートを使用して、およそのバックログの最終結果を見積もります。図4のチャートの各ポイントは反復 (またはスクラムのスプリント)、Y軸はバックログで残っているおよその全作業を表します。反復の進行中、傾向線は、 速度（チームが反復ごとに完了できる作業）を形成するポイントを通って定まります。さらに傾向線に外挿してX切片 を決定することができます。X切片は、経験に基づいて見積もった完了日を表します。 図4は、典型的なプロジェクトのプロジェクトバーンダウンチャートです。最初の9回の反復を通して、プロジェクトの「バー ンダウン」傾向線は、その後のX切片を示していました(図のチャートにはありません)。10回の反復までに、プロジェクト が20回目の反復までに完了するよう製品範囲が調整されました。速度(傾き)が改善されたことにも注意してください。 このケースでは、おそらく、効率的な進行を妨げる重要な障害を取り除くことで、範囲が縮小されたのでしょう。 6 アジャイルソフトウェア開発概論： Copyright ©2004-2010 CollabNet, Inc . 図4：速度に関する製品バーンダウンチャート プロジェクトの意思統一のような複雑な問題について、アジャイル手法では、ソフトウェア開発の4つの変数(コスト、ス ケジュール、範囲、品質)のすべてを顧客が指定することはできないと言われています。上記の問題に答えるには、期 限とコストの変数が固定している場合、作業範囲を変更可能にするか、各機能の堅牢性を調整できるように高いレ ベルで範囲を定義する必要があります 20。つまり、作業は最初に最も優先順位の高い要求に基づいて行われ、期日 までにまたは資金がなくなる前に最も重要な作業を確実に完了します。特に、前述のStandishによる、ほぼ65%の機 能が実際には全くまたはほとんど使用されていないという報告を考慮した場合、優先度の高い機能だけでも本番稼 動すれば、全く稼動しないよりはましです。また、品質については妥協は許されません。コーディングおよびテストの厳し い基準を順守し、高い品質の機能を構築しなければなりません。すべての機能を構築する保証はありませんが、最 優先の機能を高い品質で本稼動させることは確実です。 結論 しかしながら、アジャイルは機能するのでしょうか。もちろん、プリ ンの味は食べてみないと分からないように、品質は試してみな ければわかりません。Standish Group CHAOSによる2004年 の調査では、ソフトウェアプロジェクトの失敗率の劇的な改善が 報告されています。Standishの調査では、1994年には31%の 失敗率が報告されていますが、2004年には15%に改善された ことが報告されています 21。Standish Groupの会長であるJim ウォーターフォール手法はたびたび 「従来型」と呼ばれますが、ソフトウェア エンジニアリングの歴史は、他のエンジ ニアリング分野に比較すると、非常に 短いものです。 Johnsonは、この劇的改善は、より小規模なプロジェクトでウォーターフォール手法とは対照的な反復手法を使用し た結果であると考えています 22。 アジャイルは、確立されて久しいウォーターフォールソフトウェア開発の実験実証済みの歴史から極端に逸脱した手法 であるという考えは、間違っています。ウォーターフォール手法はたびたび「従来型」と呼ばれますが、ソフトウェアエンジ ニアリングの歴史は、他のエンジニアリング分野に比較すると、非常に短いものです。ソフトウェア開発は、橋の建設と は異なり、数千年の試行錯誤に基づいて構築されるものではありません。ですから、エンジニアリングの原理として急 速に発展しつつある黎明期にあるのです。アジャイルは、ウォーターフォール手法に広く取って代わる最新理論にすぎ ず、これからずっと将来も変化し、発展していきます 23。 推奨文献 入門的な記事を読んだ後、そのテーマについて知識を深めるのに適した書籍や記事を著者に尋ねたいと感じることが あります。アジャイルソフトウェア開発についてさらに学びたい方の出発点として、以下の文献をお奨めします。 Craig Larman、Agile & Iterative Development:A Manager’s Guide、Addison-Wesley、2003年。この本は、ア ジャイルに関心をお持ちのマネージャにお奨めします。現在出回っている書籍の中で、アジャイル/反復手法に関して 最も総合的で経験的な証拠を読むことができます。また、スクラム、XP、統一プロセスなどの主要なアジャイル/反復 手法のいくつかを丁寧にまとめ、比較しています。 Mary Poppendieck、Tom Poppendieck、Lean Software Development:An Agile Toolkit、Addison-Wesley、 2003年。この本は非常に優れています。各ページに貴重な情報が記載されています。アジャイルに関して、これまで 7 アジャイルソフトウェア開発概論： Copyright ©2004-2010 CollabNet, Inc . に目にした逐次型手法の開発で最も説得力のある事例が掲載されています。内容の多くは、Poppendiecksの研究 に基づいています。また、アジャイルを導入するための優れたツールも紹介しています。 Ken Schwaber、Mike Beedle、Agile Software Development with Scrum、Prentice Hall、2001年。これは、非 常に効果の高いアジャイルプロジェクト管理手法である「スクラム」に関する書籍です。理論とレトリックはすばらしいで すが、アジャイルをどのように実践するのでしょうか。スクラムは、管理側から開始するのに非常に適した方法です。 Kent Beck、Extreme Programming Explained:Embrace Change、Addison-Wesley、2000年。それではアジャイ ルで、開発者はどのように違った開発を行うのでしょうか。エクストリームプログラミング(XP)では、ペアプログラミングやテ スト駆動型開発のようなエンジニアリング原理を推奨しています。Beckの書籍は事実上XPの信頼できる情報源です。 著者について Victor Szalvayは、CollabNet社スクラム事業部門の最高技術責任者です。アジャイルソフトウェア開発 手法、特にスクラム手法の経験が豊富な認定スクラムトレーナー(CST)で、官民両部門のソフトウェア開 発チームにアジャイルフレームワークを導入した経験があります。 COLLABNET について クラウド環境におけるアジャイルアプリケーションライフサイクル管理 (アジャイルALM)で、業界をリードしています。 CollabNet TeamForge ALM platform 、 CollabNet Subversion ソ フ ト ウ ェ ア 構 成 管 理 (SCM) ソ リ ュ ー シ ョ ン 、 ScrumWorksプロジェクト管理ソフトを活用すれば、開発チームは環境、方法、技術を自由に選択し、生産性を最 大50%引き上げてソフトウェア開発コストを最大80%削減することができます。Applied Biosystems、Capgemini、ドイ ツ銀行、Oracle、Reuters、米国国防省など、2,500を超える組織で数百万人のユーザーがソフトウェア開発方法を 転換し、CollabNet製品を採用しています。詳細については、www.collab.netをご覧ください。 参考文献 1. Winston Royce、Managing the Development of Large Software Systems、Proc. Westcon、IEEE CS Press、1970年、 328-339ページ 2. Standish Group International, Inc.、『Chaos Chronicles』、1994年、http://www1.standishgroup.com//sample_research/chaos_1994_1.php 3. Kent Beck、Extreme Programming Explained: Embrace Change、Addison-Wesley、2000年、18-19ページ 4. Ken Schwaber、Mike Beedle、Agile Software Development with Scrum、Prentice Hall、2001年、89-94ページ 5. Standish Group International, Inc.、『Chaos Chronicles』、1994年、http://www1.standishgroup.com//sample_research/chaos_1994_1.php 6. 野中郁次郎・竹内弘高、『The New New Product Development Game』、Harvard Business Review、1986年1月、137146ページ 7. Mary Poppendieck、Tom Poppendieck、Lean Software Development:An Agile Toolkit、Addison-Wesley、2003年 8. Craig Larman、Victor R. Basili、『Iterative and Incremental Development: A Brief History』、Computer、IEEE CS Press、 2004年6月、48ページ 9. 野中郁次郎・竹内弘高、『The New New Product Development Game』、Harvard Business Review、1986年1月、137146ページ 10. Agile Manifesto：http://www.agilemanifesto.org/ 11. Barry Boehm、Software Engineering Economics、Prentice Hall PTR、1981年 12. Kent Beck、Extreme Programming Explained:Embrace Change、Addison-Wesley、2000年 13. 『Reexamining the Cost of Change Curve, year 2000』、Alistair Cockburn、XP Magazine、2000年9月 14. 『Examining the Cost of Change Curve』、Scott Ambler、The Object Primer, 3rd ed.:Agile Model-Driven Development 8 アジャイルソフトウェア開発概論： Copyright ©2004-2010 CollabNet, Inc . with UML2に収録されたアジャイルモデリングに関する論文、Scott Ambler、Cambridge University Press、2004年 15. Martin Fowler、『Is Design Dead』、http://martinfowler.com/articles/designDead.html、2004年 16. Ken Schwaber、Mike Beedle、Agile Software Development with Scrum、Prentice Hall、2001年、100-101ページ 17. スクラムアジャイル手法は、上記の野中-竹内の論文から派生したものです。 18. Mary Poppendieck、Tom Poppendieck、Lean Software Development: An Agile Toolkit、Addison-Wesley、2003年、28 ページ 19. Jim Johnson、『ROI, It’s Your Job!』、Published Keynote Third International Conference on Extreme Programming 、 2002年 20. Mary Poppendieck、Tom Poppendieck、Lean Software Development: An Agile Toolkit、Addison-Wesley、2003年、32 ページ 21. Standish Group International, Inc.、『Chaos Chronicles』、2004年 22. 『 Standish: Project Success Rates Improved Over 10 Years 』 、 Software Magazine and Weisner Publishing 、 http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish 23. ソフトウェア設計者のMichael Jamesは、安価なクラスター型のスーパーコンピューティングの進歩によって「テストのみ」の開発 がまもなく実現可能になるという半ば真剣な見解を持っています。開発者は堅牢なテストを記述するのみで、スーパーコンピュ ーティングが、すべてのテストをパスするまでコードを記述し、コンパイルします。 9 アジャイルソフトウェア開発概論： Copyright ©2004-2010 CollabNet, Inc .
© Copyright 2024 ExpyDoc
