知っていて損はない。アジャイルとウォーターフォールの違い

こんにちは。Co-Liftのミドリです。

さて。

「アジャイル」

と言われると、「（ウヒー…！でたでた開発用語！）」と心の中で思ってたりしませんか？

もしくは、「（新しいK-popアイドルかな？）」とか思っちゃったりしませんか？

私だけ？

「アジャイル」も「ウォーターフォール」も、確かに開発用語ではあるのですが、システム開発を生業としていない人も実は知っていて損はない用語です。むしろ、デジタルプロダクトを考える上では、欠かせない用語だったりします。

「これからの時代はDXやでーーー！！！ガハハハ」

「弊社は今期、DXを加速していく所存です」

みたいなことを、もし経営陣や上司が言っていたら、知っておいて損はないと思います。

今日は、それぞれの違いについてお伝えしたいと思います。

「オープン・エンド」な課題と「アジャイル」

Co-Liftでは、「オープン・エンド」な問いを解決するために発展し、標準化されたソフトウェア開発手法が「アジャイル」である、という捉え方をしています。

「アジャイル」とは、「俊敏な」「素早い」といった意味を持ち、システムのリリースを小単位に区切り、細かく頻繁に実装とテストを繰り返しながら開発を進めていく手法です。

上図のように、［計画→デザイン→開発→テスト→実装→レビュー（分析）→ローンチ］の一連の流れ（スプリント）を何度も何度も繰り返して、プロダクトを改善していきます。

「クローズド・エンド」な課題と「ウォーターフォール」

一方で、「アジャイル」の対義概念として、設定したゴールをブレイクダウンし、計画に落とし込み遂行する「ウォーターフォール」という手法も存在します。「ウォーターフォール」とは、その名の通り、滝が下に流れ落ちるが如く、ビジネス要件定義から始まって、設計→開発→テスト→リリース→運用・保守といったように、前の工程が完了したら次の工程に進めていく手法です。

次の工程に進んだのちに、後になって前の工程に戻ることができないので、テスト時になって「ここの機能をやはり変えたいから、要件定義からやり直そう」といったようなやり直しが効かないというデメリットがあります。

「アジャイル」と「ウォーターフォール」の違い

「アジャイル」と「ウォーターフォール」について、いくつかの違いを纏めたいと思います。

1.　リリースの捉え方

まずは「リリース」に関する捉え方の違い。

ウォーターフォールにおいて、プロダクトのリリースは「完成」。つまりゴールを意味します（もちろん、リリース後も”運用・保守”は存在しますが、あくまでも完成品をそのままの品質で保つためのものになります）。一般的には、要件通りにプロダクトが作られれば、開発チームは解散します。

一方でアジャイルでは、プロダクトのリリースは細かな単位に区切られて何度でも繰り返されるので、ゴールはありません。開発チームは、常にビジネスチームとタッグを組みながら、ユーザーの声に耳を傾けながらプロダクトの改善に尽力します。

2.　計画の立て方

アジャイルとウォーターフォールでは、「計画の立て方」にも違いがあります。

ウォーターフォールにおける「計画」では、明確化されているゴールから逆引きして要件（スコープ）が決められます。そして、その要件に沿って「期間」「費用」「品質」が定められていきます。要件は固定ですが、「期間」「費用」「品質」は計画段階では可変で、各々がトレードオフの関係にあります。

どういうことかと言うと、「めっちゃ安く作りたい」と言うお客様がいた場合は、工数を圧縮するために設計やテストの工程を短縮したり、技術力の低い（つまり低単価の）エンジニアしか集められないので、その分品質は落ちまっせ、ということです。

もしくは、「絶対にバグが出ない完璧なシステムを作りたい」と言うお客様がいた場合は、ありとあらゆるケースを想定して不具合の発生しない設計をし、宝くじの一等に10回連続当選するくらいの確率でしか起きないような可能性も想定したテストを実施し、、、と、「期間」と「費用」が、それはそれは膨大になります（それでも人間が作る以上、「完璧」はなし得ません）。

ただ現実としては、カネもヒトも時間も足りないことがほとんどで、「金も時間もいくらでも使っていいからええもん作ってや！」おじさんは現実には存在しません。また、もし仮にヒトもカネも時間も好きなだけ使って、ありとあらゆる機能をてんこ盛りにしたところで、たくさんの機能があり過ぎるとユーザーには伝わりにくくて逆効果なことすらありますよね。

実際には「リリース期限が決まっていて（期間＝固定）、予算も上限があるので、品質を若干妥協する」とか、「期間は固定かつ品質は妥協できないので、予算を多めに取る」などの選択肢がとられていきます。

一方で、アジャイルにおける「計画」で固定されるのは「期間」と「費用」で、「要件」や「品質」は可変です。

言い換えると、「チーム」を固定して、そのチームのアウトプットを最大化しようという考え方をします。

顧客やユーザーの課題やその解決策に対する「仮説」が、「機能」に翻訳され、その機能の開発に優先順位が付けられている状態（この優先順位付の要望リストを「バックログ」と言います）をインプットに、チームが上から順番に出来るだけたくさん作る、という形でスコープが各スプリントで定義されます。

欲張ってスコープを大きくし過ぎると、（期間と費用=チームが固定なので）品質が犠牲になるという構造になります。

3.　評価の考え方

3つ目の違いは、評価の考え方の違いです。

ウォーターフォールでは、計画通りにプロダクトを作り上げることが評価に繋がります。ゴールに合わせて計画した「品質」「費用」「期間」と、いかに差分なくリリースさせるかが最重要となります。ここでは、リリースされたプロダクトが、実際に価値を生んでいるかどうかは問われていないのがポイントです。

これは、「正解」が事前に定義可能で、「ゴール」が厳密に設定可能なクローズドエンドな課題では、「ゴールに到達すること」＝「価値を創出すること」となるため、「ゴールへの到達」に集中すれば良いという考え方が前提にあります。

一方でアジャイルでは、ユーザーの課題解決度合いの増分（インクリメンタル）で価値を評価します。1回の試行では十分にユーザーの課題を解決できなかった場合は、その要因を分析し、次の要件に落とし込んで、課題が解決するまで試行を繰り返します。

4.　ユーザーにとっての価値

この2つ異なるアプローチで開発されたプロダクト。開発プロセスの話なので、関係ないと思いがちですが、実は、ユーザーにも影響があります。

ウォーターフォールの場合、要件が決まり開発され、実際にリリースされるまでは、ユーザーが享受できる価値はゼロです。例えば、開発に1年かかるプロダクトがあった場合、リリースされる1年後まで、ユーザーはそのプロダクトを見ることはありません。なので、当然ながらその1年間は、ユーザーのフィードバックなしで進めていくことになります。（繰り返しになりますが、ウォーターフォールなので、後から「やっぱ要件変えるわ」も基本的にはできません）

一方で、アジャイルの場合、少しでも早く市場にプロダクトを投入して、ユーザーのフィードバックを得ることが重要とされているので、多少イケてないプロダクトであったとしても、ユーザーに提供される価値はゼロではありません。

このとき、ユーザーに提供する価値を実現するときの最小限の機能を備えたプロダクトのことをMVPと言います。Minimum Viable Productの略です。Most Valuable Personではありません。

MVPについては、上図のような移動手段の例で捉えられることが多いです。「ユーザーに提供したい価値＝徒歩よりも簡単に移動できるもの」とした場合、「タイヤと土台」だけではその価値を満たせませんが、「スケボー」や「キックボード」であれば価値を満たすことができます。

アジャイルでのMVP開発においては、最初から自動車を作ろうとはしません。例えば上図のように「ユーザーへの価値提供＝移動を楽にする手段の提供」だとすると、まずMVPとして作り上げるのは簡易的なスケートボードになります。これに対し、ウォーターフォールでアプローチする場合は、あくまでも自動車を作ろうとするので、最初のステップはタイヤを作ることになります。

まとめ

あれやこれやと言ってきましたが、全てのシステム開発において「アジャイル」が正しいということではありません。

重要なのは、直面している課題の性質（クローズド・エンドなのかオープン・エンドなのか）に合わせて、適した手法をとっていくことです。

重要なことなので、もう一度言います。

直面している課題の性質に合わせて、適した開発手法を取りましょう。

なぜ重要なのか。

それは長くなったので次回に持ち越します。

これまで真面目な話が続いてしまったので、次回は「直面している課題の性質に合わせた手法を取らないと事故る」ということを、ある家庭に例えてお伝えしたいと思います。

こんな感じです。

今日も最後までお読みいただきまして、ありがとうございました！！

次回の異作はこちら↓