2013年05月20日 08時00分 UPDATE
特集/連載

アジャイル開発は万能か?最高の成果を出す「アジャイル+ウォーターフォール開発」

アジャイル手法とウォーターフォール手法それぞれの長所を組み合わせて欠点を補うために、どのような工夫がなされているのか? 事例を通してヒントを探ってみよう。

[Cliff Saran,Computer Weekly]
Computer Weekly

 毎日打ち合わせをすることに抵抗を感じる開発者もいる。では、アジャイルソフトウェア開発を採用している組織はどのようにプロジェクト管理の改善を図っているのだろうか?

 かつてITチームは、話はよく聴くが、ユーザーの期待に応えられないとやゆされていた。従来のウォーターフォール開発では、ITチームは長い時間をかけて顧客と擦り合わせをし、プロジェクトの正規の仕様書をまとめ、そこから通常はさらに12カ月かけて、顧客が同意し承認した内容に従って機能を実装する。

注:本記事は、プレミアムコンテンツ「Computer Weekly日本語版 2013年5月15日号」(PDF:無償ダウンロード提供中)に掲載されている記事の抄訳版です。

 しかし、12カ月のうちにビジネスの状況は変わり、プロジェクトの仕様がビジネスのニーズに合わなくなることは日常茶飯事。紙やPowerPointスライド上では素晴らしく思えたアイデアは、ノートPCでのデモを見ると的外れかぶざまな印象を受けるときた。

 アジャイルソフトウェア開発およびプロジェクト管理は、顧客を開発に巻き込むことができるので、顧客に対し面目を失いたくないITチームによく採用されるようになった。アジャイル開発では、大規模なプロジェクトを細分化し、各機能コンポーネントを短期間で納品可能にすることで、ウォーターフォール手法特有のデメリットを克服している。

 顧客は成果物を定期的に確認できる。そのため、完成したプロジェクトが最終的に納品された時点で「これは頼んだものと違う」と言われるリスクが少なくなる。

アジャイル手法の欠点

 しかし、アジャイル手法によって全ての問題がなくなるわけではない。アジャイル開発では、具体的な仕様を定義するなど、優れたプロジェクト管理のプラクティスが損なわれると指摘されることがある。また、スケジュールと予算の管理が難しくなるし、複雑なプロジェクトの場合、プロジェクトチームが簡単な機能コンポーネントから手を付けがちだ。その結果、80%の作業が完了しても、最も難しい機能が残り、この残された20%がプロジェクト全体の成否を左右する要素であることは大いにあり得る。

 このような欠点に対応するために一部の組織では、ウォーターフォール手法にアジャイル手法を取り入れる、アジャイルプロジェクトの初期に正規の仕様策定により時間をかけて、難しい機能から完成させるなどの対策を取っている。

 例えば、英ワインメーカーのMajestic Wineの新しいWebサイトを構築する際に、英システムインテグレーターのJavelin Groupは、IBMのRational Unified Process(実績あるベストプラクティス)を基に8ステップを1単位とするイテレーションを用意して開発を行った。このアプローチのおかげで、Majestic Wineのeコマースディレクター、リチャード・ウィーバー氏とそのチームは、3週間ごとにプロジェクトの成果物を確認できた。

 英水道事業者のYorkshire Waterは、完全なアジャイル開発に対しては社内の抵抗があったため、従来のプロジェクト管理手法とアジャイル手法を組み合わせることにした。同社のシニアITプロジェクトマネジャーのジェームズ・ロッカー氏は、アジャイルソフトウェア開発のおかげで、関係者がコミュニケーションを取る機会が多くできたと話す。

 「私にとって毎日の打ち合わせはとても効果的だった。その日の作業に向けて全員の足並みをそろえることができた。私はむしろ(プロジェクトマネジャーではなく)プロジェクトリードになり、チームに障害がないよう目配りすることが仕事になった」とロッカー氏は言う。Yorkshire Waterでは、このアジャイルプロジェクトを準備するに当たり、英ITコンサルティング会社のLamriの協力を得た。「既存のプロセスに合わせてアジャイルを取り入れる必要があったため、ITアーキテクチャの作業にさらに10日間を費やすことになった」とLamriのマネージングディレクターのアンドリュー・グリフィス氏は振り返る。

 英製薬会社Napp PharmaceuticalsのIT部門も、英国国立カーディフ大学が運営する疼痛教育関連のWebサイト「Pain Community Centre」の構築プロジェクトにおいて、かなりの下準備をしなければならなかった。

成功要因はMoSCoW法

続きはComputer Weekly日本語版 2013年5月15日号にて

Pain Community Centreの構築プロジェクトはどう進められたのか? 同プロジェクトで開発に携わったアダム・ミッチェル氏が、プロジェクトの進め方や苦労点、成功要因について解説します。本記事の続きは「Computer Weekly日本語版 2013年5月15日号」で読むことができます。

Computer Weekly日本語版 2013年5月15日号のダウンロードページへ (TechTargetジャパン)

この記事を読んだ人にお薦めの関連記事

この記事を読んだ人にお薦めのホワイトペーパー

Loading

注目テーマ

ITmedia マーケティング新着記事

news064.jpg

シャノンの「イベント受付来場認証」がPepperと連携
シャノンは、MAツール「SHANON MARKETING PLATFORM」において、展示会・イベントの来場者...

news014.jpg

SalesTech最前線 世界の主要サービスを一気見
AdTech、Martechに続く注目分野であるSalesTechの現状はどうなっているのか。各領域の主...

news106.jpg

「Gotcha!mall」が「LINE」と連携
グランドデザインは、スマートフォンオムニチャネルプラットフォーム「Gotcha!mall(ガッ...