なぜ日本でアジャイルが普及しないのか、ウォーターフォール型開発の問題点とアジャイル開発との違い

(Photo by：gdsteam)

海外ではアジャイル開発手法の普及が進み、半数以上の企業が導入しています。しかし、日本では海外と比べると普及率が低いのが現状です。

外注を多用する日本のソフトウェア開発では、アジャイル開発を導入しにくいのが原因のひとつと言われています。たしかに、ウォーターフォール型開発は長年使い続けられており、多数の実績があります。しかしながら、いくつかの問題点もあり、それが原因でプロジェクトが失敗してしまうこともしばしばです。

ソフトウェア開発の形態も大きな要因のようです。
アメリカではソフトウェアに対する投資が自社開発（内製）とパッケージソフト開発で3分の2であり、ITエンジニアの7割以上がユーザー企業に属しているという特徴があります。（IPA:非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書）

この記事では、ウォーターフォール型開発の問題点とアジャイル開発との違いという視点でお伝えしていきます。双方の違いを比較して、適切な開発手法を選択しましょう。

ウォーターフォール型開発のおさらい

ウォーターフォール型開発とは

はじめに、ウォーターフォール型開発のおさらいをしておきましょう。ウォーターフォール型開発は、「要求定義→設計→プログラミング→テスト→リリース→運用・保守」という流れで開発を進めていきます。工程がすべて完了してから次の工程に進み、後戻りがないことを前提としています。しかし実際には、ほとんどの場合で手戻りが発生し、それにより納期が遅れたり、最悪の場合プロジェクトが頓挫してしまったりします。

ウォーターフォール型開発の問題点

開発期間中に要求が変化することを考慮していない

大抵の顧客は、最初から自分の欲しいソフトウェアをはっきりと説明できません。そのため、出来上がったソフトウェアを見てから、自分の欲しいものではなかったと気づきます。また、近年のビジネスは変化が非常に早く、外部環境の変化から要求が変更されることもあります。結果的に、無駄な作業が発生し、追加の作業によって納期が遅れるわけです。

顧客にソフトウェアを提供するまでに時間がかかる

上述の通り、顧客は実際にソフトウェアに触れるまで、自分の要求が正しかったのか確かめることができません。そのため、プロジェクトの後半になって受け入れテストを実施すると、そこで多数の変更が発生します。結局、大幅な手戻りと無駄な作業が発生し、納期に間に合わせることが困難になるわけです。

工程に後戻りがないことを前提にしている

ウォーターフォール型開発という名前の通り、上流工程から下流工程まで上から下に流れるように開発が進むことを前提にしています。実際には、ほとんどの場合で手戻りが発生するため、スケジュール通りにはいきません。どれだけ綿密に計画しても、複雑なソフトウェア開発を予定通りに進めるのは容易ではありません。これは、「不確実性コーン」からも明らかです。プロジェクト初期段階での見積もりは、最終的な結果と平均で2倍以上も乖離します。

ウォーターフォール型開発とアジャイル開発との違い

開発のスケジュール

ウォーターフォール型開発では、詳細に計画してスケジュール通りに進めることを重視しています。一方、アジャイル開発では、状況の変化に応じて、柔軟に計画を変更することで変化に対応しようとします。また、アジャイル開発では一気に詳細な計画を立てません。必要な分だけ、徐々に計画していきます。長期的な計画は変更されることが常なので役に立たないのです。

設計の方法

ウォーターフォール型開発では、主に上流SEが設計をして仕様を決めます。それから、下流のPGが仕様書通りにコーディングする流れですね。一方、アジャイル開発では、設計作業の一部を開発チームで行います。ユーザーストーリーなどの手法を用いて、徐々に設計を進めていくのです。これにより、インクリメンタルな設計が可能になります。仕様変更による再設計の無駄を避けることが目的です。

開発の進め方

ウォーターフォール型開発では、工程ごとに作業が進んでいくため、まだ必要のないものも、まとめて作ってしまいます。一方、アジャイル開発では、インクリメンタルに作業を進めるため、必要な部分に絞って作業していきます。実際に必要なものだけを作るので、無駄の発生を最小限に抑えられます。

ソフトウェアを顧客に提供するタイミング

ウォーターフォール型開発では、プロジェクトの最終局面まで顧客が動くソフトウェアを見ることはありません。多くの場合、受け入れテストで初めて触れることになるでしょう。一方、アジャイル開発では、早急に動くソフトウェアを開発し、定期的に顧客からのフィードバックを得て改善していきます。これにより、早期に要求とのズレを修正し、大幅な手戻りを防ぎます。リーンスタートアップのMVP（実用最小限の機能の製品）が代表例です。

テストの方法

ウォーターフォール型開発では、プロジェクトの最後に一斉にテストを行います。単体テストや結合テスト、受け入れテストなどです。一方、アジャイル開発では、CI（継続的インテグレーション）により、常にテストを行い、不具合を早期に発見しようとします。不具合は早期に発見するほど、修正に必要なコストが少ないからです。また、TDD（テスト駆動開発）を取り入れて、設計にテストを活用する方法もあります。テストの手間は増えますが、全体で見るとコストダウンになります。

アジャイル型開発の初心者向けノウハウ

アジャイル型開発に興味を持った方を対象に、「アジャイル型開発におけるプラクティス活用事例調査」と「プラクティス活用」という資料がインターネット上に公開されています。（IPA（独立行政法人情報処理推進機構）による公開文書）

ソフトウェア開発手法であるアジャイル開発手法は自社開発（内製）が主な手法となっているアメリカで発展した手法ですが、システム開発の受発注環境が異なる日本では普及したと言える状況ではないのが現状です。
そこで、日本の開発スタイルや適用分野、活用事例、アジャイル開発・スクラム開発のプラクティスをまとめられています。これからアジャイル開発の導入する場合、導入の失敗や試行錯誤が減少し、アジャイル開発手法によるプロジェクトの成功率向上に役立つノウハウがあります。ぜひ活用してください。

「アジャイル型開発におけるプラクティス活用事例調査」の報告書とリファレンスガイド
* http://www.ipa.go.jp/sec/softwareengineering/reports/20130319.html

まとめ

すべてのプロジェクトにアジャイル開発を採用する必要はありません。プロジェクトによっては、ウォーターフォール型開発が適している場合もあります。完全なアジャイル開発を適用することが難しいなら、双方を融合させた「ハイブリッドアジャイル開発」を検討してみましょう。型通りにやる必要はありません。現場に合わせて開発手法を改善してください。

---

本ブログは、Git / Subversionのクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。

エンタープライズ向け Git / Subversion 導入や DevOps による開発の効率化を検討している法人様必見！

「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。