特別講演「アジャイル開発の現状と今後」

IPAの松田氏による特別講演では、日本でのアジャイル型開発の現状を、実際に採用している22の事例をもとに考察、メリットや問題点を明らかにし、導入に何が必要であるのかを紹介しました。

なぜ今、“非”ウォーターフォール型開発か？

独立行政法人 情報処理推進機構ソフトウェア・エンジニアリング・センター（IPA/SEC）の所長である松田晃一氏は、特別講演「アジャイル開発の現状と今後」を行いました。IPA/SECでは、ソフトウェア開発力強化に向けて、技術開発と人材育成のための産学官連携の拠点として、産業競争力の強化を目指すとともに、情報システムの信頼性確保に向けたソフトウェア・エンジニアリングの推進を行い、生活の安心・安全の実現を目指して活動しています。

IPAが2,230のプロジェクトを対象に実施した調査によると、その96.0％が開発モデルにウォーターフォール型を採用していました。反復型はわずか2.8％にとどまっています。このように、現在ほぼすべての開発に採用されているウォーターフォール型ですが、多くの疑問もあると松田氏は言います。それは「要件が事前にすべては決まらない」「⁠要件の誤りが最後のテストまで解らない」「⁠時間がかかり過ぎて変化への対応が遅れる」「⁠運用へのしわ寄せが大きい」「⁠工程の完了判断＝次の工程へ進む基準があいまい」であるとしました。

ソフトウェア開発は、エンドユーザが企画や要件定義を行い要求仕様を作成し、その仕様を元にソフトウェアへの実装を行い、それをエンドユーザが運用するという流れを続けていくことが基本です。しかし、一括開発・一括リリースを行うウォーターフォール型では、リリースされるまでギャップに気づかないという問題があります。これを反復開発・順次リリースのアジャイル型にすることで、早期にギャップに気づき修正することが可能になります。開発プロジェクトには「スコープ」「⁠コスト」「⁠品質」「⁠納期」の要素がありますが、スコープを固定するウォーターフォール型に対し、アジャイル型はスコープを変数とする手法であるといえます。

日本でのアジャイル型開発の現状

続いて松田氏は、日本でのアジャイル型開発の現状について紹介しました。国内22事例を対象とした調査では、プロジェクトの規模は8名以下が大半を占めており、期間は1年以内がほとんどで、その半数は2カ月から4カ月に集中していました。工数にすると、100人/月のプロジェクトがほとんどであるといえます。反復（イテレーション）の期間では、1週間が5件、2週間が6件と大半を占め、この傾向は海外でも変わりません。また、自社内で利用するソフトを内製したり、販売するためのパッケージの開発といった内部開発にアジャイル型を採用する例が目立ちました。受託開発の例では、既存システムの更改や新規案件が多くなっています。

また、国内22事例から言えることとして、アジャイル型開発は要求の変化への柔軟な対応が可能であることと、市場への投入の迅速化に効果があり、生産性が改善した分、品質や保守性を向上できることがわかりました。大手のSI業者でもトライアルが行われており、社内標準への取り込みが始まっています。特に、ウォーターフォール型との使い分けや、成功体験のウォーターフォール型への取り込みに積極的であるといえます。

アジャイル手法への期待は非常に大きい

では、アジャイル型開発手法の導入に向けて、これから何に取り組むべきなのでしょうか。松田氏は、「⁠開発モデルの選択法・組み合わせモデルの開発」契約問題といった「外注における課題」「⁠アジャイル手法の理解促進」「⁠管理手法や技術面での環境整備」を挙げ、基本的には計画性・確実性・安定性を重視するならウォーターフォール型を、変化への適応性・迅速性を重視するならアジャイル型を選択すべきとしました。また開発対象の性質として、クリティカルなのかどうか、途中で変化する可能性があるかどうか、新規なのか改造、再構築なのか、アーキテクチャの成熟度はどうなのか、規模の大小などが判断基準になるとしました。

アジャイル手法の理解促進においては、ユーザや顧客との協調に価値を置くプロセスであるため、顧客の開発への参画が必須であるとしました。具体的には、繰り返しごとのリリース計画の作成や、要件の優先順位の決定などが必要であるといいます。また、開発担当者の意識改革も必要で、顧客への対応や業務知識が必要になるなど単能工から多能工へ進化しなければなりません。もちろん、イテレーションという決められた期間内に仕事をやり遂げる能力や、プログラムを共同所有することへの理解も必要になります。

最後に松田氏は、経営環境の変化に対しスピーディに柔軟に対応できること、「⁠生きたシステム」への対応が可能なこと、ソフトウェア開発のグローバルな競争に対応できることから、アジャイル型開発手法はこれからの時代が要求するパラダイムに対応できるソフトウェア開発であり、また開発者ひとりひとりがやりがいと働きがいを感じられ、意欲ある人材や優秀な人材が集まる職場になり、多重下請けなど日本の産業構造を転換する可能性も秘めているなど、アジャイル手法への期待は非常に大きいと締めくくりました。

セッション2「大規模システム向け日本版アジリティ開発手法『COMMONDATION-ReeL』」

日立システムアンドサービスの英氏によるセッションでは、日本でのアジャイル型開発導入の障壁となっている課題に対し、それを解決する大規模システム開発向けのアジリティ開発手法「COMMONDATION-ReeL」を紹介しました。

最大100名程度、1年以上のプロジェクト規模を想定

（⁠株⁠）日立システムアンドサービス 生産技術部の英繁雄氏は、セッション「大規模システム向け日本版アジリティ開発手法『COMMONDATION-ReeL⁠』⁠」を行いました。このセッションはタイトル通り、2002年から社内システムの開発にアジャイルを適用していた同社が、日本でも運用可能な大規模システム開発向けのアジリティ開発手法「COMMONDATION-ReeL」を紹介するものです。

この開発手法は、システムの複雑化により要件定義がまとまりきらないこと、そして変化のスピードアップにより要件変更が発生するという課題を解決するために開発されたものです。その背景には、日本国内では圧倒的にウォーターフォール型が採用されているが、要件変更に柔軟に対応するプロセスが求められていること、海外でアジャイル型を適用した大規模システム開発の成功事例が増えてきたこと、アジャイル型に適したツールが整備されてきたことが挙げられると英氏は言います。

「COMMONDATION-ReeL」の特徴は、ウォーターフォール型のフェーズを大きく「要求」「⁠作成」「⁠検証」の3つのフェーズに分割していること、請負契約に対応しスコープ調整を可能とする「目標コスト契約」を基本とすること、ドキュメントの軽量化とツールによる自動化環境を整備することで修正コストを低減していること、標準開発基盤を整備していることです。そして、最大100名程度、1年以上のプロジェクト規模を想定し、派遣・委任契約を基本としながらも請負契約にも対応、顧客同席または代理役の存在を必要としており、Webアプリケーションの開発形態を想定しています。

アジャイル型の課題を解決する「COMMONDATION-ReeL」

アジャイル型の「大規模開発に向かない」「⁠請負契約に向かない」「⁠顧客同席」「⁠要件管理手法が確立されていない」といった課題を、「⁠COMMONDATION-ReeL」では「プロセス」「⁠体制」「⁠契約とコスト管理」「⁠品質管理」「⁠開発環境」で解決しています。プロセスでは前述のように3つのフェーズで構成され、アーキテクチャ検証と主機能開発、サブ機能開発にイテレーションを導入しています。イテレーションは3カ月で1ステージを基本としています。また、アプリケーション設計ドキュメントを大幅に削減し、要件変更による修正量を削減しています。

体制については、プロジェクトオーナー、プロジェクトマネージャをはじめ、ファシリテーター、ビジネスアナリスト、ユーザビリティ・エンジニア、ITアーキテクト、モデラーなど14種類の役割を設定し、作成フェーズでは上位層スクラムと業務開発チーム層スクラムの二重構造としています。契約とコスト管理では、請負契約の場合は目標コスト契約を基本とし、固定価格に対し変更見込み20％程度以内のバッファを上乗せした予算とします。この合計が最大保証価格となり、発注者と開発者はともに、修正コストを目標コスト内に収め最大保証価格を超えないよう最大限努力します。

品質管理においては、仕様確認、単体テスト結果確認、結合テスト結果確認、総合テスト結果確認、システムテスト結果確認など8種類を対象に品質確認を実施します。イテレーションで繰り返されるテストに重点を置いて品質管理を行うことが特徴で、イテレーション自体の品質管理も行います。なお、テスト以降のステージはウォーターフォール型と同様になります。開発環境は、社内の開発環境はPaaSとして仮想サーバと接続し、社外の開発環境はVPN接続によるシンクライアントとしています。仮想開発基盤によって開発環境をセキュアに一元化します。

精度の向上や開発環境の整備、アジャイル型への理解が今後の課題

現段階での「COMMONDATION-ReeL」の評価は、コスト見積もりと要件管理手法が整備されている、予算と実績コストの乖離を少なくできる、開発環境が整備されウォーターフォール型の生産性向上にも適用できる、お客様と開発者の一体感、信頼関係を築きやすいといったメリットがある反面、管理手法と管理ツールに不慣れなことが原因で要件定義の確定度とコストの管理が難しい、ファシリテーターやマスタとなる人材の不足や複数企業で各社が請負契約の場合には向かないなど体制が組みづらい、開発手法のプロジェクトメンバー全員の認識が合わないといったデメリットも明らかになっていると英氏は言います。

この評価を受け、今後の課題として、要件定義項目や見積もり手法のブラッシュアップといった「見積もりと要件管理手法の精度向上⁠」⁠、自動生成ツールのブラッシュアップや社内クラウドによる開発環境とツール提供環境の整備拡大、オフショア先の開発環境整備拡大といった「開発環境の整備⁠」⁠、前提知識教育の整備やプロジェクト教育体制と教育ガイドの整備、社外団体との交流といった「アジリティ開発手法の啓蒙と普及」を挙げました。

最後に英氏はまとめとして、大規模ユーザアプリケーションの運用時には、アジャイル型を気安く採用すべきではないこと、修正変更が迅速に行えない未整備な環境でアジャイル型適用すべきではないこと、全員に十分なアジャイル型の理解が必要であること、信頼できるリーダーが存在すること、顧客との間に信頼関係が築けていること、契約に修正コストの扱いをしっかり盛り込むこと、の6項目を必要事項として挙げました。そして「幸せなプロジェクトとなるために、日本の大規模システム開発に合ったアジリティ開発手法を作り出しましょう」としてセッションを締めくくりました。