アジャイル開発って仕様変更に強いし、すぐに動くものを見せられるからクライアントの満足度も高い気がする。ウォーターフォールモデルをやめて、アジャイルにした方がいいんだろうか？
アジャイル開発は、「要件は変わるもの」という前提に基づいて考えられた比較的新しい手法で、多くの魅力とメリットがあります。
要件定義がうまくいかない、仕様変更に振り回されるといった課題を感じている開発チームであれば、一度試してみたいと考えるでしょう。
しかし、ウォーターフォール開発がうまくいかないからアジャイルを導入する、とうことであれば、そのプロジェクトは間違いなく失敗します。
その理由についてご説明します。
ウォーターフォールは基礎技術、アジャイルは応用技術です
ウォーターフォールモデルとアジャイルモデルの違いについて簡単にご紹介します。
ウォーターフォールモデル
要件定義→設計→実装→テストのフェーズを上から順番に実施する。最初に仕様を固めてから、設計に入るという流れ。
- メリット 予定を立てやすくスケジュール管理しやすい
- デメリット 最初に仕様をかっちり固めてから設計、実装に進むため、プロジェクトの後半にならないと動くものが確認できない
アジャイルモデル
計画→設計→実装→テストのサイクルをイテレーション（基本的に１～２週間）という短いスパンで繰り返す。イテレーションを繰り返しながら仕様を固めていく。
- メリット 動くものを作りながら仕様を固めていくため、実際に動かしてみて問題があれば即座に仕様を変更できる
- デメリット 容易に仕様変更ができるため、開発方針がブレて納期も定まりにくい
「要件定義→設計→実装→テスト」の大きいサイクルを１回行うのがウォーターフォール。各フェーズの対象範囲を変えながら、短く何サイクルも回すのがアジャイルです。
つまり、アジャイルとは、規模の小さいウォーターフォールモデルの繰り返しなのです。
そのため、開発手法をアジャイルに変えたからといって、ウォーターフォールモデルとマネジメントのやり方が大きく変わるわけではありません。
ウォーターフォールモデルでうまくマネジメントできないのであれば、アジャイルでもうまくいかない理由はここにあります。
でも、規模の小さいウォーターフォールなら、アジャイルの方が簡単なのでは？
そう思われるかもしれませんが、実際は逆です。
アジャイルは、「数週間おきに納期がある」と考えてください。
ウォーターフォールであれば、腰を落ち着けて要件や設計方針の検討ができますが、アジャイルは時間勝負になりがちです。
例えば開発メンバーが体調不良で１日休んでしまった場合、全体から見れば大した影響でないように思いますが、イテレーションという短い期間で見ると致命的な遅れになりかねません。
引き出しの浅いマネジメント初心者では、このようなトラブルに対処しづらいでしょう。
まずは、自分のマネジメントスタイルを確立させることが重要です。そして、マネジメントスタイルの確立は、じっくり開発できるウォーターフォールモデルの方が適していることが多いです。
それぞれのフェーズでは、どんな成果物が必要か、クライアントとはどんなコミュニケーションが必要か。それが分かることで、イテレーションで省略できるポイント、してはいけないポイントが見えてきます。
アジャイル開発はウォーターフォールモデルの応用なのです。スポーツと同じで、基礎ができてない状態で応用技に挑戦すると、痛い目に遭いますよ。
ウォーターフォールモデルは情報処理技術者試験で学べる
ウォーターフォールモデルを学ぶなら、情報処理技術者試験がオススメです。
基本情報処理技術者試験で開発の基礎が学べますし、応用情報処理技術者試験では、さらにマネジメントの知識が手に入ります。
実際に試験を受けるかどうかは、どちらでも良いと思いますが、試験勉強自体に価値があります。
国家試験なだけあって、要点がまとまっていますので、時間をかけてWebサイトを漁るより、手っ取り早く正確な知識が手に入ります。
試験対策本を一冊買って、読み込めば十分です。きたみりゅうじさんの本は、イラストが多く読みやすいのでオススメです。
勉強以上に大切！実践しましょう
学んだ知識は実践することで身に着きます。業務の中で使ってみましょう。
今まで作ってないドキュメントがあったら作ってみるとか、仕様書や議事録のフォーマットを変えてみるとか。
どうすれば、要件定義や設計がスムーズに進むかを考えて創意工夫しましょう。
当サイトでも、マネジメントのヒントとなる情報を発信していますので、ぜひご活用ください。
アジャイル開発を成功させる条件
ウォーターフォールモデルには自信がある、という方向けに、アジャイル開発を成功させるための条件をご紹介します。
- クライアントがアジャイルについて理解と協力体制がある
- 開発メンバーに"足手まとい"がいない
- プロジェクトがアジャイルに適している
クライアントがアジャイルについて理解と協力体制がある
アジャイル開発はものを作りながら仕様を詰めていきます。
そのため、クライアントは毎回成長するプロトタイプを見ながら、その都度、仕様に対して良い/悪いのジャッジをしていかなくてはいけません。
打ち合わせに毎回違う担当者が出てきたり、ステークホルダーが多すぎて仕様の合意に時間がかかるようであれば、アジャイルの柔軟性とスピード感という２つのメリットがつぶれてしまいます。
仕様検討を開発側でフォローする場合もありますが、ただでさえ短いスパンで成果物を提供する必要があるのに、さらにクライアントの面倒までみるというのは、、、私ならやりたくありません笑。
アジャイルを成功させる上で、クライアントの理解と協力は必須と言えます。
開発メンバーに"足手まとい"がいない
厳しい言い方ですが、開発メンバーに仕事が遅いメンバーがいる場合、アジャイルは成功しづらいです。
アジャイルはイテレーションごとに成果物を決めて開発を進めます。イテレーション内で作成できなかった機能は次回のイテレーションに回しますが、それは仕事が遅いメンバーのタスクが徐々に積みあがることを意味します。
アジャイルの基本はチームメンバー全員によるセルフマネジメントです。
スクラム（アジャイル開発手法の一つ）では、メンバーフォローをチームメンバーが主体的に行うことを推奨しています。
しかし、アジャイルのように五月雨式に要件が出てくるプロジェクトで、他メンバーのフォローまで回れる優秀なエンジニアはそう多くないでしょう。
つまり、セルフマネジメントできないメンバーがいると、計画が破綻しやすいのです。
プロジェクトがアジャイルに適している
そもそも論ですが、プロジェクトの向き、不向きというものがあります。
ウォーターフォールモデルの方が楽に進められるのに、無理にアジャイル開発で進める必要はないわけです。
ケースバイケースでどちらが適しているかは変わってきますが、おおよその判断基準をご紹介いたします。
Webアプリやスマホアプリはアジャイル向き
Webアプリやスマホアプリは、開発スピードが重視され、マーケティング戦略次第で仕様が変わる傾向があります。このようなシステムはアジャイル開発が適しています。
業務システムはアジャイルに向かない
業務システムのように、複数のサブシステムが連携し仕様変更の影響が多岐に渡るシステムは、最初に要件をかっちり決めるウォーターフォールの方が適しています。
また、ウォーターフォールモデルを理解しているプロマネであれば、ウォーターフォールモデルに向いているかどうかで判断できると思います。
アジャイル開発のおすすめ書籍
アジャイル開発の参考なる書籍をご紹介しますので、よろしければご活用ください。
アジャイルの考え方が分かる入門書にして良著です。
アジャイルの実践的な進め方が、分かりやすく解説されています。
まとめ：ウォーターフォールモデルでマネジメントの基礎を学ぼう
ウォーターフォールモデルは、昔からある手法で「古くさい」といった捉え方がされることもありますが、アジャイルに劣っているわけではありません。
それぞれメリット、デメリットがありますので、状況によって使い分ければ良いのです。
しかし、そのためにはどちらの手法が適しているかを判断するための知識と経験が必要となります。
ウォーターフォールモデルはプロセスが単純な分、考え方を理解しやすいです。ですので、まずはこれでマネジメントの基礎を学び、その後アジャイルを学ぶのがオススメです。
スポーツと同じで「基礎」が大事です。基礎がどれだけできているかで、アジャイル開発の成功率は変わりますよ。
アジャイルのような"華"はありませんが、ぜひウォーターフォールモデルにも興味を持っていただけたらと思います。