変化を取り込む開発方式を採用しアプリケーションの価値を引き出す（第10回）

IT Leaders編集部 - 2010年7月15日(木) 09:00

環境変化が著しい昨今、アプリケーション開発においては急激な要件変更であっても迅速に対応できる方法論が求められる。だが現在主流のウォーターフォールにはその視点が欠けている。ユーザー企業は慣れ親しんだウォーターフォールにこだわらず、プロジェクトによって臨機応変に開発方式を選択しなければならない。

顧客のニーズは細分化し、かつ短いサイクルで変化を繰り返している。企業はこうしたニーズを的確に把握し、いち早く自社のサービスや製品に取り込んでいかなければならない。そのためには急な要件変更に対応するアプリケーション開発方式の採用が欠かせない。

だが実際は、どんなアプリケーションであっても、広く使われている開発方式「ウォーターフォール」モデルを採用するケースが大半である。使い慣れており無難だから、という安易な理由で採用しているのだ。しかしウォーターフォールの場合、要件定義や設計、開発、検証などに時間がかかるほか、変化が絶えない現在の市場に十分対応できないといった問題を抱える。市場の動きに適応できる開発方式を採用しなければ、せっかく構築したアプリケーションであってもビジネスに十分貢献できず、無駄な投資に終わりかねない。開発方式の選択ミスは、プロジェクトの失敗に直結する危険をはらんでいるのだ。

業務と市場変化に応じた開発方式の選択を

ではどのように開発方式を使い分けるのか。ガートナーは業務内容や要件変更の頻度に応じた、適切な開発方式の採用を推奨する（図）。それには図にある4区分のうち、どこに属しているのかを把握することが大切である。もし区分が不明瞭ならば、開発したアプリケーションに十分な効果は見込めない。

図　業務内容や要件変更の頻度によって分けられるアプリケーション開発方式

例えば、要件が安定しておりミッションクリティカルな業務向けアプリケーションならば、ウォーターフォールが適している。逆に要件変更が多く、ミッションクリティカルというほど厳格ではない業務ならば、対極にあるアジャイル的な高速開発手法（RAD）が適する。試行錯誤が多く、スピードが求められるCRM（顧客関係管理）やマーケティング、eビジネスなどが該当する。

現状、アジャイル開発に適したアプリケーションであっても、「要件変更は悪」としてウォーターフォールを採用するケースが少なくない。これらを洗い出し、アジャイル開発の区分に移行することが必要である。変化を取り入れることによりアプリケーションの価値を高められる。

一方、ミッションクリティカルな業務向けアプリケーションにおいても、要件変更が多い場合にはアジャイル開発が有効な選択肢となり得る。ただし、UMLに代表するモデリング言語を使う「アジャイルモデル駆動型開発」が望ましい。ドキュメントではなくモデルを活用することで、アプリケーションの検証や要件を図式化して機能分析でき、より確実な開発に効果を発揮する。

要件変更が少なく業務内容が厳密でないケースがある。この場合でも実際にはウォーターフォールを採用するのがほとんどだ。だが、厳密なプロセスが存在しないために予算超過や納期遅れなどを招くことが多い。

開発チーム・ベンダーが気をつけるアジャイル開発の留意点

ではアジャイル開発に取り組む開発チームやベンダーはどんな点に留意すればよいのか。ガートナーは主に以下の点を指摘する。

要件の優先度
顧客の要望をすべて聞き入れず、最初は優先度の高いものだけを実装する。最終的に必要な機能であっても、完璧を目指してすべて実装するのは避ける。
正確性
アジャイル開発の本質は、スピードよりもむしろ確実に納品することにある。ウォーターフォールの場合、完成間近になり「あと1カ月かかります」となりかねない。アジャイル開発では途中経過を見える化することが大切である。
ルールの作成
開発チームのスタッフ変更に備え、独自の開発コードではなく標準化したコードを利用する。また、コミュニケーションを密にし、作業内容をガイドラインとして策定する。
チーム内のチェック体制
開発チーム内で同僚をチェックできるようにする。これにより問題を顕在化し、アプリケーションの欠陥を早期に発見、解決できる。
改善を心がける
ユーザーからの困難な要件変更、予測の範囲を超えた問題に対処できるよう、絶えず改善する姿勢と開発スキルの向上を目指す。

本連載はガートナーのリサーチ「Best Development Methods:A Scenario View」をもとに日本法人アナリストが一部編集し、加筆したものです

“スピード”に価値を見い出し
人月計算によるコスト意識から脱却せよ

川辺謙介
ガートナージャパン
リサーチ部門
アプリケーション・ディベロップメント
主席アナリスト

日本企業は欧米企業に比べて、アジャイル開発によってアプリケーション開発期間を短縮できることに価値を見い出せずにいる。

原因の1つに、人月計算に基づくコスト意識が挙げられる。例えば半年かかっていた開発期間が、アジャイル開発により1カ月に短縮できたとする。このとき人月計算なら対価は6分の1となるが、開発期間を大幅に短縮したのだから、むしろ6倍の対価になってもおかしくない。だがユーザー企業の多くが、開発期間が短くなることでコストが上がるなら従来の開発方式、開発期間で十分と考えてしまう。期間短縮による効果を軽視し、眼前のコストを重視しているのだ。企業は短期間でアプリケーションを市場投入することで競争優位性を高められるメリットを強く認識しておかなければならない。

アプリケーションの対価は、開発に費やした人数や期間ではなく、アプリケーションを活用したことでビジネス上、どんな成功を収めたのかに依存すべきである。日本企業は人月計算ありきで開発費を考えるため、アプリケーション開発が目的になり、その後の効果という視点が欠如している。要件変更が当たり前となっていることもあり、これまでのように見積もり額に応じて開発を進めるという考え方自体を改める必要がある。

経営層がスピードの重要性を認識していない点も問題だ。日本企業の場合、決定した経営戦略を実行する手段としてITを捉えている。経営戦略とITは別モノであり、「ITによって経営が変わる」、「成功するにはITが必要だ」という考えに至っていない。

だが今後、中国や欧米企業の日本市場参入や日本企業の海外進出が加速するにつれ、経営戦略にITを組み込まざるを得なくなるはずだ。これまでの日本企業が考えるスピードが通用しなくなるからである。経営層の意思決定からITを実装するまでの期間は短くなり、経営層のIT部門に対する要求は変わってくるに違いない。「現在の経営課題に対処するためのプランをIT部門のメンバーとともに考えたい」という要望が経営層から持ち上がることを期待したい。