こんにちは。私は、以前にアジャイル開発を知って以来、アジャイルで開発を続けています。
私がアジャイルにハマることになるきっかけを作ったのは、アジャイルサムライという名著でした。
ただ、実際にアジャイル開発をやってみた結果、メリットやデメリットが色々と見えてきました。今回は、ウォーターフォール型の開発と比較しながら、考察していきます。
アジャイル宣言
アジャイル開発には、有名なアジャイル宣言があります。まずはご確認ください。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
http://agilemanifesto.org/iso/ja/manifesto.html
それでは、アジャイル宣言に沿いながら、実際に比較検討をしていきます。
プロジェクトメンバー数による違い - プロセスやツールよりも個人と対話を
アジャイル開発は、ドキュメントよりも動くソフトウェアを重視する傾向があります。
つまり、実際には納品をしない仕様書を作り込むくらいだったら、コミュニケーションで仕様を伝達し、ダイレクトに動くソフトウェアを開発していったほうが早いのです。
ところが、プロジェクトメンバーが増えれば増えるほど、コミュニケーションのコストは増大していきます。会議室にメンバーが一堂に会するだけでも、全員の15分が奪われてしまうのです。
コミュニケーションに対するコストが馬鹿にできないプロジェクトの場合、アジャイル開発は不向きになり、ドキュメントによる情報共有の効率のほうが勝ります。
アジャイル型の開発は少人数、ウォーターフォール型の開発は大人数のプロジェクトに適しているというのが、私の印象です。
ミニマムドキュメントという選択 - 包括的なドキュメントよりも動くソフトウェアを
ウォーターフォールのドキュメントと聞いた時に、エクセルの仕様書や設計書を思い浮かべる人はいませんでしょうか？
ウォーターフォールが嫌われやすい理由のひとつに、重厚長大で分厚い本のようなイメージの仕様書があります。ただ、これは仕様書を過剰に作り込んでしまうから発生してしまうことなのです。
現在は、モックアップやプロトタイピングを利用した画面設計が流行っています。
最小限のドキュメントで情報共有を図ることが最近の潮流であり「プロセスやツールよりも個人と対話を」とは限らないのです。
これは、アジャイル型開発にも適用できます。アジャイル型開発のコミュニケーションコストの高さを、最小限のドキュメントで補うのです。つまり、アジャイルが定義している問題は包括的なドキュメントにあるので、それさえ解消してしまえば良いのです。
最小限のドキュメントによる効率的な情報共有を、私は強くおすすめいたします。
なお、クックパッド様の開発手法は非常に参考になりますので、ぜひご参照ください。
アジャイルな顧客 - 契約交渉よりも顧客との協調を
顧客との協調を強くするためには、アジャイルな顧客が必要になります。アジャイルな顧客とは、平たく言ってしまえば協力的な顧客のことです。
つまり、協力的な顧客を獲得できるのであればアジャイル開発は優位性を持ち、そうでない場合はアジャイル開発の強みは減少してしまいます。
アジャイルは動くソフトウェアを重視しているので、実際に顧客にソフトウェアを触ってもらう必要があるのです。
・・・では、ウォーターフォール型開発の場合は協力的な顧客は必要ないのかと言うと、そうではありません。
ウォーターフォールが嫌われやすい理由のひとつとして、一枚岩の重厚長大なシステム開発によく用いられるので、後半の工程での手戻りが大きいといった理由があげられます。しかし、これは一枚岩だから発生するのです。
ウォーターフォールであったとしても、まずは最小限のプロダクトでリリースしましょうといった取り決めを締結できれば、リスクは抑えることができます。そこから、少しずつ機能拡張していけば良いのです。何も、一度のウォーターフォールですべてを解決する必要はありません。
結局のところ、アジャイルであろうがウォーターフォールであろうが、協力的な顧客は必要なのです。
変化量による違い - 計画に従うことよりも変化への対応を
アジャイルは変化への対応を柔軟にすることを重視します。言葉を言い換えてしまえば、アジャイルは変化が大きいプロダクトに向いているのです。
アジャイルは頻繁に機能を見直すようなスタートアップの自社プロダクトに、ウォーターフォールは変化量の少ない請負や受託開発のプロダクトに向いています。
なぜ、請負や受託開発に向いているかと申しますと、請負や受託開発では、計画の尊守をどうしても求められるケースが多いのです。そういった状況下において無理にアジャイルを回すくらいでしたら、素直にウォーターフォールで開発するという選択もありなのではないかと考えています。
視野を広く持ち、他の開発モデルも知ろう
開発モデルに関しては、以下の「tasuwo blog」様によくまとまっておりますので、ご確認ください。
ここで私が言いたいことは、一言に集約されます。
「アジャイルはウォーターフォールと比較されがちですが、開発手法はアジャイルとウォーターフォールだけではありません」
参考までに「tasuwo blog」様で言及されている開発手法を列挙してみます。
- ウォーターフォールモデル
- プロトタイピングモデル
- スパイラルモデル
- インクリメンタルモデル
- イテレーションモデル
開発手法は、さまざまな開発モデルの中から、取捨選択された結果として検討されることが望ましいのです。
さいごに
私が本記事において言いたいことは、アジャイルサムライの教えと似ています。
今回は、アジャイル宣言に沿いながら比較検討をしてみました。しかし、最も大事なことは、自分の頭で考えることです。
アジャイルを実践してみた結果、コミュニケーションコストの増加に悩まされることもあれば、ウォーターフォールでプロジェクトを進めた結果、手戻りの影響に悩まされることもあります。
結局のことろ、自分のプロジェクトの性質にあったプロジェクト管理手法を選択する必要があります。どのプロジェクト管理手法が合うのかという、絶対的な最適解はありません。
だからこそ、我々は考える必要があるのです。
