はじめに
「アジャイルプロセスは、大規模ユーザアプリケーション開発には向かない」というのが昨年までの私の考えでした。多くの方も同じ考えではないでしょうか？
ここでは、私たちが検討している「大規模システム向け日本版アジリティ開発手法」を3回の連載で、簡単にご紹介させていただきます。まだまだ改善が必要な状態ではありますが、日本のソフトウェア生産技術の向上のため、一緒にご検討いただければ幸いです。
アジャイル再挑戦
私がアジャイルプロセスに関わり始めたのは2002年です。社内システム開発にアジャイルプロセスを適用し、その評価を行いました。当時は開発事例紹介として講演なども行っていました。しかし、アジャイルプロセスは大規模ユーザアプリケーションには向かないという考えがあり、社内外から大規模ユーザアプリケーション開発へのアジャイル適用相談を何度か受けたものの、その難しさを説明して諦めていただいていました。
転機は昨年の暮れでした。海外で大規模なユーザアプリケーション開発をアジャイルで成功させている企業の方と話し合う機会をいただきました。自社製品開発だけではなく、実際に大規模なユーザアプリケーション開発を行っていることを知りました。夜も一緒に飲みながら、日本に合った新たな開発手法を作れないかと盛り上がりました。
もともと「日本の製造業を手本に生まれた生産方式が、なぜ日本のソフトウェア開発に向かないのか？」という疑問もありました。既存のアジャイルプロセスを実行するのではなく、大規模システム開発向けの日本版アジャイルプロセスを作り出す決意をしました。プレッシャーのせいでしょうか、今年の初夢は「新アジャイル手法」の開発に失敗した夢を見ました。
なぜ、新たな開発手法が必要か？
目的は、アジャイルプロセスで開発することではありません。ウォーターフォール型プロセスで問題がなければ、無理にプロセスを変える必要はないでしょう。
しかし、複雑化した業務、多様なIT技術、変化の激しい社会情勢に対し、仕様変更が発生したり、要件定義工程の期間内に詳細な仕様まで決めきれないといったプロジェクトが数多くあります。要件定義が曖昧なまま、スケジュールに合わせて無理矢理に後工程に進め、問題を後送りにしたプロジェクトもあると思います。ウォーターフォール型では、仕様変更があれば修正コストが大きくなるため、追加費用の再調整が必要となるケースがあります。顧客にとっては何とも納得のいかないことだと思います。修正コストをできる限り抑えてあげることが、開発者側の役割だと思います。
アジャイルな開発手法では、「要件とコストの管理をどうするか？」と「なぜ修正コストが減るのか？」が多くの人が抱く疑問だと思います。これは、ウォーターフォール型にも該当することであり、アーンドバリューの管理やドキュメント削減などで、ある程度解決できることでもあります。アジャイルの効果は、顧客と開発者が一体となったプロジェクトでコスト、スケジュール、品質などに対して常に共通認識を持ち、短いイテレーションを繰り返し進めていくことで、仕様間違いの早期発見、仕様変更の早期対応が可能になることだと思います。結果として当初の見積りコストと実績コストとの乖離を小さくするための手法だと私は思っています。
アジリティ開発手法「COMMONDATION－ReeL」
当社は、ウォーターフォール型が合わないプロジェクトに対し、要件変更に対応するためのアジリティ開発手法として「COMMONDATION-ReeL」を開発しました。
アジャイルプロセスではなくアジリティ開発手法と呼んでいる理由は、要求／作成／検証の3つのフェーズに分割していることと、プロセスだけでなく分散開発環境で行うためのコミュニケーション環境やツールなど開発環境を重視し、広く捉えているためです。これは、「アジャイルソフトウェア開発の価値」にある4つの定義の中の1つ「プロセスやツールより人と人同士の相互作用を重視する」に反するかもしれません。しかし、大規模開発に対応するためには、プロセスやツールを整備することは重要なことだと思います。
図1は1年の期間を想定した場合のCOMMONDATION-ReeLのイメージです。要求フェーズで要件をできる限り確定し、残りを作成フェーズで吸収します。
図1 COMMONDATION-ReeLの特徴
次にCOMMONDATION-ReeLの特徴を紹介します。
① 要求／作成／検証の3フェーズ
ウォーターフォール型の要件定義／基本設計／詳細設計／製造／テストのフェーズを大きく要求／作成／検証の3つのフェーズに分割し、画面など一部の開発作業は並行して進めます。
- 要求フェーズは、ウォーターフォール型の要件定義／基本設計フェーズとあまり変わりません。できる限り要件を確定し、未確定となった部分の確定予定日と予測コストを明確にしておきます。
- 作成フェーズでは、スクラムをベースとしたアジャイル開発を行います。3イテレーションを基本に1ステージというマイルストーンを設けます。
- 検証フェーズでは品質を保証するための総合／システムテストとユーザテストを行います。
② 受託開発でのスコープ調整
受託開発では、事前に納期と成果物の内容を決定する必要があります。そこに要件変更の余地を残すために、「目標コスト契約」を基本としています。
③ 修正コストの低減
修正コストを低減するためのドキュメントの軽量化とツールによる自動テスト環境を整備しています。またお客様には、イテレーションの中で動作確認していただくことで問題の早期発見ができます。
④ 標準開発基盤の整備
- ストーリー／タスク管理ツールや開発／テストツールの標準環境を整備しています。
- 管理者向け／エンジニア向けの教育を整備しています。
- 分散開発用には、セキュアなクラウド環境を利用した開発環境とバーチャル会議を実現するコミュニケーションツールを整備しています。
次回は「契約と要件管理」、最終回は「品質管理と修正コスト低減」について紹介させていただきます。
