ウォーターフォールモデルとアジャイルソフトウェア開発について

システムエンジニアになって早くも半年が過ぎて、
初めて参画したプロジェクトもやっと終わりが見えてきました。

ウォーターフォールモデルによるシステム開発に一通り関わる事ができましたので、
ウォーターフォールモデルを通じて自分なりに感じた事と
最近注目を浴びているアジャイル開発についてまとめます。

ご存知の通り、日本のシステム開発のほとんどはウォーターフォールモデルで行われます。

ウォーターフォールモデルを簡単に説明すると、
開発プロジェクトを作業工程に分割して、時系列に行っていくモデルです。

例： 「要件定義」→「基本設計」→「詳細設計」→「開発」→「テスト」

このような感じで、一つの作業工程が完了してから、
次の作業工程に移っていき、開発していく手法です。

ウォーターフォールモデルは古くからある開発手法ですが、
現在でも、ほとんどのシステム開発で用いられています。

日本のシステム開発では外注を多様するため、
工程作業がはっきり分割できるウォーターフォールモデルは相性が良いみたいです。
（要件定義～基本設計まではA社で、詳細設計～開発をB社に外注みたいな感じ）

この開発手法は、作業工程が明確に分かれているため、各作業工程で成果物が求められ、
その成果物にOKが出て、やっと次の工程に移れます。

成果物と言っても、システムを納品するのは最終的にテスト作業が完了した後なので、
ほとんどの工程ではドキュメントが成果物となります。
今回参画したプロジェクトでも、ドキュメント作業が多く、wordやexcelがいつも以上に嫌いになりました。

要件定義工程では、要件定義書。
基本設計工程では、基本設計書。
詳細設計工程では、詳細設計書。
といった風に、各工程できっちりと成果物を作成し、
それを基に次の工程に移っていきます。
モデルの性質上では、後戻りはせず、計画性の高い開発ができます。

しかし、システム開発に携わった人なら経験あると思いますが、
いくら綿密な計画を立てても、作業の後戻りが発生しないなんてことはありません。
また、クライアントがシステムを触れるのは、全行程が完了した後なので、
実際にシステム触ってみて、想像してたのとは違うなんてことも起こります。

クライアントの要求が途中で追加又は変更になって、
後戻りバンザーイ状態なんてのも誰しもが経験したことがあるのではないでしょうか。
システムの要件は変更するけど、納期は変更しないなんてドＳなクライアントに
当たった時には、連日の徹夜作業が待っています。

ウォーターフォールモデルでは、各工程できっちり成果物を出すので、
後戻りが発生すると、 多くの時間が要求されます。

福の神がついてたはずが、いつの間にかキングボンビーになってたように、
計画性の高いプロジェクトからデスマーチプロジェクトに変貌します。

今回、ウォーターフォールモデルでの開発を経験して、
このモデルが抱える問題点についても経験できました。
多くのドキュメントに時間を取られて、肝心の現場作業を圧迫したことも少なくありませんでした。
（まぁ、それは僕がドキュメント作成に慣れていないってのも理由なんですけどね・・・）
それだけでなく、途中でクライアントの要求が増えて、急遽対応したことも・・・・・。
その度にリスケする作業は終電帰りの機会を見事に増やしてくれました・・・・・。

このようにウォーターフォールモデルだけでは、プロジェクトが破綻してしまう恐れがあるため、
後戻りも考慮した柔軟な開発手法も注目されています。

そのひとつが、アジャイルソフトウェア開発（以下、アジャイル開発）です。
wikipediaには以下のように記載されています。

アジャイルソフトウェア開発とは、ソフトウェア工学において、

迅速且つ適応的にソフトウェアを開発を行う軽量な開発手法郡の総称である。

（アジャイルソフトウェア開発より引用）

アジャイル開発とは、一つの確立された開発手法でなく、
いくつかの定義があり、それを基に確立されたソフトウェア開発手法の総体です。
その為、アジャイル開発と言っても、いろいろと種類があり、それぞれに長所短所があります。

さすがに現在公開されているアジャイル開発の手法を全部紹介すると長くなるので、
アジャイル開発によく見られる特徴といえば、以下のような感じですね。

1. 少人数精鋭のチームをつくる。
2. システム全体をいくつかの機能に小分けする。
3. 小分けた機能を一つずつ作成していき、全体を作成。
4. 一つの機能にかける時間は数週間レベル。
5. 成果物は、実際に動くシステム。
6. ドキュメント類は極力少なくする
7. クライアントの要求や変更に対応しやすい。
8. クライアントが、早い段階で、実際に動くシステムを目にするので、システムの齟齬が発見しやすい。
9. システム開発の途中でのクライアントの要求にも対応しやすい。

紹介されている情報では、ウォーターフォールモデルの問題点を
解決できる開発手法で、より良いシステムが作成できそうです。

ただ、日本での導入実績は非常に少なく、正当に評価することは難しいです。
また、最初の方にも記載しましたが、日本のシステム開発は実際の開発を
外注なんてザラにあるので、アジャイル開発は現実的に難しいようです。

しかし、クライアント目線からしたら、ドキュメントばかり見せられて、
肝心のシステムは最後のお楽しみでは不安要素が大きいと思います。
（そのせいか、やたらとミーティングが多いんですよね～）
プロジェクトの早い段階で動くシステムを見て、
自分が想像してたベクトルとあっているかなどをチェックしたいはずです。

過酷な現場が多い、システム開発ですが、
いつまでも同じようなシステム開発をするのではなく、
うまくいかなかったときは、違う手法も試すくらい柔軟になっていってほしいものです。
今後、日本でもアジャイル開発のような柔軟なシステム開発が増えていくことを期待します。