|
[2011 年 9 月号] |
［技術講座］
アジャイル開発手法スクラムだけでは実現できないことや日本でアジャイル開発の普及を阻んでいる 7 つの不安を解消するためのフレームワークが OGIS Scalable Agile Method (以降 OSAM と略す)です。今月と来月の 2 回に渡り、OSAM の概要を紹介します。今月号では、アジャイル開発手法スクラムを補うために OSAM が用いているアジャイルUPを中心に OSAM の開発手法としての側面を説明します。なお、本記事に挿入したいくつかの漫画は同僚の正木氏が作成したものです。
これらの中で「アジャイル宣言とアジャイル開発手法」と「代表的なアジャイル開発手法であるスクラム」は、オブジェクトの広場に連載している「アジャイルモデリングへの道」の第 1 回と第 2 回の記事を抜粋、加筆したものです。
「日本でのアジャイル開発手法の普及」では、ユーザ企業とITベンダーに分かれた日本の産業構造がアジャイル開発の普及を阻む 1 つの障害になっていると論じています。さらに、その障害を克服する手段として変更への対応を含めた生産性の評価等のプロジェクト測定を用いることを提案しています。
以降の白書第 2 部の原稿で白書第 1 部を参照している箇所がいくつかありますが、アジャイル開発やスクラムをすでにご存じの方は白書第 1 部を読まなくても第 2 部の内容を理解できると思います。
白書第 1 部で述べたように、お客様（ユーザ企業）が現在直面しているのは以下のような問題です。
10年前に比べてビジネスの競争が激しくなっている現在、業務に必要なソフトウェアをタイムリーにソフトウェアが開発できないことのダメージは、戦略的な業務であればあるほど深刻になっています。しかし、開発スピードだけを追求して品質が低いソフトウェアができると将来の変更や保守のコストが増大する恐れがあります。
また、プラットホームの移行やOSS (Open Source Software)の導入によるシステムの近代化を行ったり、SOAなどによりシステムの連携を行う際にも、開発に伴う技術的なリスクに対処しながらタイムリーに開発を行うことの必要性はますます高まっています。
これらの問題を解決する方法として有効なのが、アジャイル開発です。白書第 1 部で述べたように、アジャイル開発の特徴は以下のとおりです。
これらの特徴により、「業務に必要なソフトウェアをタイムリーに開発する」ことが可能になります。具体的なアジャイル開発手法で言えば、スクラム[1]はこれらの特徴を満たす最小限の開発手法だと言えます。
また、「周期的に動くコードを作成する」というところをリスク管理の手段として使うことで、技術的リスクに対処して開発を進めることができます。この点は、統一プロセスのような反復型開発手法のメリットとして強調されてきました。アジャイル開発手法でも同様なことは実現可能であり、このことを意識して開発を進めることが重要です。
その一方で、最小限の開発手法であるスクラムを単純に適用するだけでは以下のようなことを実現できません。
これらの点を実現するためには、スクラムを補う手法やプラクティスが必要になります。
さらに、日本固有のユーザ企業とITベンダーに分かれた産業構造がここ数年間で大きく変わるという可能性が低いことを前提とする場合には、ユーザ企業とITベンダーの間でどのような契約を結べばよいかということも問題になります。このような問題を解決するというのは、スクラムに限らず、どのような開発手法であれ、開発手法の守備範囲を超えています。しかし、ユーザ企業とITベンダーに分かれた産業構造でアジャイル開発を活用するためには開発手法で解決できない、このような問題を解決する必要があります。
2000年から2005年の期間に、日本にもアジャイル開発が紹介され、XP (eXtreme Programming) [2] を中心としたアジャイル開発のブームが起こりました。その際、結果的にアジャイル開発が日本では定着せず、アジャイル開発がさらに普及した欧米とは異なる道をたどりました。また、欧米では最初に XP がアジャイル開発ブームに火をつけましたが、その後次第にスクラムを採用する割合が高まり、現在ではスクラムが最も普及しています。
XP は、テスト駆動開発など変化に対処するための技術プラクティスを中心とした開発手法であり、技術的な観点では非常によくできた手法です。しかし、幅広く普及しなかった原因は以下のようなところにあると考えられます。
これに対して、スクラムの特徴はアジャイル宣言の価値や原則を実現するために開発依頼者と開発者が実践すべき必要最小限のプラクティスに絞り込んでいる点にあります。これが、スクラムが日本以外で広く普及した大きな原因だと考えらえられます。但し、スクラムは XP の技術プラクティスを否定するものではなく、むしろ前述したようなスクラムの課題を解決するためにそれらのプラクティスを段階的に取り入れることを推奨しているという点も理解した方がよいでしょう。
日本でアジャイル開発が定着しなかった大きな要因は、以下のような開発依頼者の不安を解消できなかったことにあるのではないかと筆者は考えています。
このような不安のうち、A - C は日本固有のユーザ企業とITベンダーに分かれた産業構造ゆえに重要になるものです。G は、「XP の技術プラクティスをすべて実行しなければならない」という誤解に基づくものだと考えられます。
そもそも A, B, C を解決すべきか否かは、要求の不確定性とシステムの戦略性によって変わります。これらの点については、後編の「測定に基づく契約と見積もり」の節で論じたいと思います。
D は、以下のような 2 つの不安に分解することができます。
まず、ウォーターフォール型開発との開発生産性の比較で言えばアジャイル開発の方が 16% 開発生産性が高いというデータ [3] が報告されています。この報告は、26 のアジャイル開発プロジェクトの開発生産性を 7,500 のウォーターフォール型開発プロジェクトの生産性と比較したものです。
「手戻りで生産性が下がる」という疑問に対する回答は、「仕様変更は（アジャイル開発であろうとなかろうと）開発生産性を下げる」ということです。しかし、技術的プラクティスを使うことで仕様変更に対する開発生産性の低下を抑制できる可能性があります。つまり、変更のコストを抑制できるということです。
E については、従来の開発よりも業務の役立つソフトウェアを作るためには従来の開発以上に開発依頼者の積極的な関与が必要になるということです。従来の開発で業務に役立つソフトウェアが開発できなかったら、そのソフトウェアの改良を行うために次のリリースまで利害関係者の関与が続くことになります。アジャイル開発では、従来の開発において複数のリリースで行っていたことを前倒しで行うことになるので開発依頼者の積極的な関与が必要になるのです。但し、開発途上での開発依頼者の関与がどの程度必要であるかは、要求の不確定性が開発途上でどのように減るかによって決まります。要求の不確定性と開発依頼者の関与についても後編の「測定に基づく契約と見積もり」の節で論じたいと思います。
G は、「XP の技術プラクティスをすべて実行しなければならない」という誤解に基づくものなのでスクラムを採用することで解決できます。しかし、F)で言及されているような品質に対する不安に対処するためには技術プラクティスを必要になります。つまり、高い品質を求めるならばスクラムに技術プラクティスを加えることが必要になるのです。
最後に H ですが、これはアジャイル宣言の「包括的なドキュメントよりも動くソフトウェア」という価値に対する誤解に起因しています。アジャイル宣言が言っているのは、「包括的なドキュメント」を作成することで開発が進捗していると判断したり、顧客のニーズを確認するのではなく、「動くソフトウェア」で開発が進捗していると判断したり、顧客のニーズを確認した方がよいということです。また、アジャイル開発は「顧客の成功」を重視しますので、顧客が望めば「開発ドキュメント」を作成することを禁じているわけではありません。
これまで述べたことをまとめると、日本のお客様の抱くアジャイル開発への不安を解消するためには、以下の点が鍵になるということになります。
OGIS Scalable Agile Method (以降 OSAM と略す) とは、前節で述べた不安を解消し、以下のゴールを達成するためのフレームワークです。
お客様と開発者がより良いパートナーとして連携し、限られた時間と予算の枠内で、要求の変化への対応と技術的なリスクの管理を行いながらお客様のビジネスに役立ち、かつ高品質なソフトウェアを早く開発すること
このゴールを達成するために、OSAM は以下の 2 つの要素で構成されています。
アジャイル UP は、後編の付録で説明されている統一プロセス (Unified Process) [6], [7] をアジャイル化したプロセスフレームワークです。アジャイル UPは以下の点でスクラムを補います。
アジャイル UP の概要とスクラムとの関係については後の「スクラムとアジャイル UP を組み合わせることの利点」の節で説明します。
機能規模測定手法 COSMIC 法は、白書第 1 部で説明したように通常のファンクションポイント法よりも簡易な機能規模測定手法です。OSAM の測定部分では、COSMIC 法を用いてアジャイル開発の普及を阻む契約や見積もりの問題を解決するとともに、開発の継続的な改善のためのプロジェクトのパフォーマンス評価を実現します。
アジャイル UP とは、アジャイル開発の考え方を取り入れて軽量化した統一プロセスであり、Scott Ambler 氏が考案した開発プロセスフレームワークです。アジャイル UP は、統一プロセスと、アジャイルモデリング, XP などのアジャイル開発で提唱された技術プラクティスを融合させたものになっています。なお、統一プロセスの概要は本記事の後編の付録で説明されています。
アジャイルUPの全体像は、図 1で表現されます。
 |
この図からアジャイルUPは、統一プロセスと同じ4つのフェーズで構成されているが、作業分野は 9 つから 6 つに減っているということが分かります。アジャイルUPの6つの作業分野の目的は、表 1に示されます。
| 作業分野名 | 目的 |
|---|---|
| モデル | 組織の業務とプロジェクトの対象となる問題を理解し、問題に対処するための実現可能な解決策を明らかにする |
| 実装 | モデルを実行可能なコードへ変換し、基本的なテスト（特に単体テスト）を実行する |
| テスト | 客観的な評価によって品質を保証する。 不具合の発見、システムが設計通りに動くことの検証、要求が満たされていることの確認などを行う |
| 導入 | システムの導入計画を立て、実施し、エンドユーザがシステムを使えるようにする |
| 構成管理 | プロジェクトの成果物に対するアクセスを管理する。 成果物のバージョンを継続的に追跡するほか、成果物に対する変更を制御、管理する |
| プロジェクト管理 | プロジェクトで生じる作業を指示する。 リスクの管理、要員への指示(タスクの割り当て、進捗の管理など)、プロジェクト外部の人やシステムと協調して予算内でスケジュール通りに導入できるよう気を配ることなどが含む |
| 環境 | 適切なプロセスやガイダンス(標準と指針)やツール(ハードウェア、ソフトウェアなど)をチームが必要な時に使えるようにして、ほかの作業を支援する |
アジャイル UP では、これら 6 つの作業分野に対するワークフローを提供しています。提供されているワークフローは、開発作業、役割、成果物の関係を大雑把に示すものにとどまっており、ラショナル統一プロセスで非常に多くの字数を割いていた以下の内容のほとんどが省かれています。
 |
このため、アジャイル UP は非常にシンプルになっています。
ラショナル統一プロセスでは膨大な文書で説明されていた開発作業の具体的な進め方をアジャイル UP では開発者が自ら決める必要があります。そのために、アジャイル UP では以下のようなプラクティスを提示しています。
長期的なマイルストーンは、開発を進める途上で開発が約束通り進んでおり、開発依頼者の期待している方向と一致しているかどうかを確認するチェックポイントです。また、各フェーズでは力点を置くところが以下のように変わります。
方向づけ以外の各フェーズでは、複数の反復を実行し、反復毎に動くコードで進捗を判断します。
ユーザ企業とITベンダーという枠組みの場合は、方向づけまでの検討はユーザ企業が主導し、推敲フェーズ以降の開発作業をITベンダーにアウトソースするという場合も多いでしょう。そのような場合には、ITベンダー側は推敲フェーズ以降の 3 フェーズで開発を進めればよいことになります。
アジャイルモデル駆動開発（AMDD: Agile Model Driven Development）は、アーキテクチャや設計を考えたり、要求を表現するために軽量にモデリングを行いながら開発を行うものです。アジャイルモデル駆動開発は、以下のような特徴を持ちます。
 |
テスト駆動開発（TDD: Test Driven Development）は、各クラスが備えるメソッドのコードを書く前に、そのメソッドの動作を検証するためのテストコード(テストケース)を先に書くべしというプラクティスを元々意味しています。つまり、開発対象のソフトウェア本体のコードを書く前に単体テストのテストコードを書くことを求めています。また、単体テストはテストを自動化するためのxUnit（x は開発言語の種類に対応する文字が入る）というテスティングフレームワークを使って実装することが推奨されています。
テスト駆動開発の狙いは、以下の 2 つの点です。
特に、後者は仕様変更に対する開発コストの増加を抑制するための鍵となるものであり、アジャイル開発の定石の1つと言えます。
リファクタリングは、既に存在するプログラムコードの機能を変えずに品質を改良するための作業です。例えば、2つ以上のクラスの間にコードやインタフェースの共通性を共通のクラスに括りだしたり、１つのメソッドの複雑度が非常に高く保守性が悪いコード部分を分割して保守性を高めるなどの作業を指します。リファクタリングを安全に行うためには、テストの自動化を行うことが必要になります。
常時結合は、常にプロジェクト全体のソースコードにより実行コードをビルドする環境を整え、運用するというものです。常時結合を行う際には、以下のような2つの環境を導入することも多いです。
例えば、個人の環境で単体テストを実行して合格したコードだけを構成管理システムでチェックインすることを許し、チェックインされた最新のコードを定期的にビルドし、作成された実行コードの動作を自動化されたテストで自動検証するというような環境を構築します。また、ビルドエラーを発生した部分やテストの不合格の部分はプロジェクトメンバーにメール等で通知するようにします。
アジャイル UP に関して注意すべき点としては、「アジャイルUPのプラクティスを一挙にすべて取り入れるのは難しい」という点が挙げられます。特に現在の開発方法と大きく異なるプラクティスについては注意が必要です。そのために、アジャイル UP の各作業分野を開発メンバーに説明し、とりあえず実行できそうなプラクティスを話し合いで決めていき、段階的に取り入れるというアプローチが必要になります。
後編：スクラムとアジャイル UP との組み合わせの利点と測定の活用次回は、スクラムとアジャイル UP を組み合わせることの利点を説明し、さらに OSAM の測定部分で提案する機能規模測定手法 COSMIC 法を用いたスコープ変動型開発契約について説明します。
後編：スクラムとアジャイル UP との組み合わせの利点と測定の活用
| © 2011 OGIS-RI Co., Ltd. |
|
