理事長コーナー
先号　　　次号

アジャイル開発のすゝめ

PMAJ理事長　光藤　昭男　[プロフィール]　：9月号
　プロジェクトマネジメントは、計画した予算と期日にある品質の成果物を得るための方法論である。対象が、製造物や建築物などのハードシステムであれ、IT開発などのソフトシステムであれ、基本的なプロセスは変わらない。しかし、そのプロジェクトは、7割が計画を達成できない“失敗プロジェクト”であると報告されている。(IPA社レポート、日経コンピュータ誌記事など)

　失敗は、目標・目的・条件が曖昧のまま開始するプロジェクトに多いとされている。リーダーシップの欠如、大規模で複雑性を内包した大型プロジェクト、顧客による仕様変更、外部環境の変化などが、プロジェクトの失敗を誘引するとされている。特に、IT開発、なかでもモバイル系などでは、装着する機材や基本ソフトの枠組みが半年ごとには更新されており、失敗に陥りやすい。このような本質的に不確実性の高いプロジェクトの開始時に、綿密な計画を立てるのは合理的ではない。これに対処するために辿りついたのが、機能を分割した小規模開発を繰り返し、目標にたどり着く方法論である「アジャイル開発」だ。

　従来の企画・計画・設計・構築・検証の一連の開発は、「ウォータフォール(WF)開発」だ。「アジャイル開発」とは、「小さく始めて大きく終わる」ことだ。到達目標を定め、目的を確認することは同様だが、WF開発が綿密に計画をたてることに比べると、曖昧度があってもよい。目標を達成するために必要な全機能からまとまった部分機能を抽出する。その部分機能ごと、設計・構築・検証の開発小サイクルを繰り返す。この小サイクルは2～3週間程度が良いとされ、その期間に、チーム員は部分機能の完成に向け集中する。

　小サイクルは、小規模、短期間であるため、不具合による出戻りも対処しやすく、手間も限定的である。WF開発の統合テストでは、往々にして各種不具合の原因追及に時間がかかり、稼働に手間取ることが多く、規模が大きいほど、時間と費用が膨大となり勝ちだ。さらに、通常のプロジェクト期間は、年単位の長期となるため、外部環境が変化することによる仕様変更も起きやすい。これらに挑戦するのが、アジャイル開発だ。だが、万能ではない。成功のポイントは、部分機能に分割ができることのようだ。

　先行した米国では、1990年頃から試行錯誤を続けた結果、一時は様々な「アジャイル開発」の方法論が提案されたため、その方法論を一義的に定義することは困難だったという。関係者が議論を重ねた結果、基本的な合意がなされた。その挑戦してきた関係者が米国ユタ州に集まり、基本コンセプトを「アジャイルソフトウェア開発宣言」として一つにまとめ、2001年2月に発表した。
　このコンセプトは、「①プロセス・ツールより人との対話、②ドキュメントよりも動くソフトウェア、③契約交渉よりも顧客との協調、④計画よりも変化への対応、この四項を価値とする」である。①では、プロセスやツールを軽視している訳でなく、開発対象の目標・目的などを明確化するために、コミュニケーションをより良くする。②では、開発内容に深入りするのではなく、動くソフトウェアをつくることが真の目的だと確認する。③では、システムの利用者である“顧客”を巻き込み、お互い齟齬をなくすよう協力し合う。④では、厳格な計画立案よりも変化への対応に注力する。この①から④の内容は、お互い関連している。この宣言は、アジャイル開発の根本を宣言したということで、大変意味深い。

　これ以降、米国でのソフト開発は、急速にアジャイル開発が中心となり、一説では現在80%がアジャイル開発であるという。ITはすべての産業の競争力を向上する可能性を秘めている。開発対象を精査し、工夫すればアジャイル開発の適用の可能性も高い。変化に対応するので、利得も多い。しかし、日本では米国ほど普及していない。その理由として、IT開発でのビジネス慣習の相違、IT業界の多重外注構造、IT人材のITサービス企業への偏在などが、指摘されているが、徐々にだが、適用が拡大基調にあるようだ。また、「アジャイル開発」は、ソフトプロジェクトだけでなく、ハードプロジェクトにも適用が始まっている。

　このような状況からアジャイル開発の適用の更なる拡大の一助になればと願い、PMAJでは、「アジャイル開発の道案内」(近代科学社)を近く発刊する。興味ある方は、是非、ご高覧願えれば幸いである。

以　上
ページトップに戻る