見出し画像

アジャイルになるために：アジャイルをウォーターフォールと対比するのはやめようという話

Tomy

ソフトウェア開発会社で働いているとアジャイル or ウォーターフォールという開発スタイルの話がよく挙がりますよね。アジャイルに関する知識や事例がかなり広まってきていると感じる一方で、明らかに間違った意味でアジャイルなりウォーターフォールという表現が使われてるなと思っていて、今回は自分の考えをまとめるためにアジャイルとウォーターフォールを対比するのはやめようという話をしようと思います。

（注）この記事はいわゆる受託の開発会社での体験をもとに書いてます。SaaSなどソフトウェアプロダクトを提供する会社ではそもそもウォーターフォールという単語が出ること自体が(私の経験上は)ほぼないですし、大きな会社や歴史ある会社はわからないですが初期のスタートアップでは意識せずともアジャイルの価値観ベースで開発がスタートしていくことが多いと思います。

筆者の前提知識

私の考えはほぼこちらの記事に依拠しています。アジャイル宣言のメンバーの一人です。記事の内容はなんか小難しいことを言ってるのですが、わかる人は「おお、それなw」となっていただけたら嬉しいです。

開発会社でよくある議論

クライアント「作りたいものは決まっててこの要件です、スケジュールは6カ月後リリースでお願いします。」
PM「作りたいものやスケジュールが明確に決まっているならウォーターフォールで進めることになりますね。」

3カ月後
クラ「やっぱりこの機能が欲しいので、こういう要件に変更でお願いします！」
PM「それやっちゃうと期限守れなくなるのでできません！」
クラ「」

さんざん要件定義の時に確認したのに、後になって違うことを言い始めるパターンです。えらい人が出てきて違うことを言い始めてその意見にみんな流されるみたいなのもありますね。こういう恐怖体験を積んだ結果なのか、クライアントの一言に非常に防衛的に反応してしまう開発者は、経験を積んだ人ほど多い印象があります。笑

ということで開発者の中では、こういうのはクライアントがわかってないみたいな印象になりますが、正直数ヶ月も経てばビジネス的な状況は全然変わりますから、作るべきものも変わって然るべきだと思ってます。うろ覚えなので表現が間違ってるかもですがClean Agileにも「ソフトウェアというのは変更しやすい(ソフトな)製品であって変更を受け入れられない開発プロセスは間違ってる」という内容があります。

何が違っているのか

結論、作りたいものやスケジュールが最初から明確 ＝ ウォーターフォールという解釈になっているところが違っていると考えています。

作りたいものが明確だったとしても、スケジュールを進めていくとさっきの話の通り作りたいものは変わってきます。そうなると開発チームはそれは無理ですとかプラスNカ月かかりますとなっちゃいますよね。加えて、そもそも数ヶ月や半年の開発スケジュールが当初見積もりの通りに進むことは開発者の経験上なかなか難しいし、半年〜とかになるともはやギャンブルなんじゃないかと思えます。
(ウサギさんも心折れるわけですね…)

失敗するアジャイル

ウォーターフォールは失敗するからと言って、突然「アジャイル型でいこう」みたいなのも失敗パターンとしてありがちだと思います。スクラムの手法を取り入れて振り返りやプランニングをやってみたりするものの、スプリント内にプランニングした内容が全然終わらなかったり、振り返りで特に振り返りたい内容がなかったり。あるいはスケジュールをかっちり決める過去のやり方を否定して、スプリントごとにやることを決めるんだと言ってみるものの開発が終わらず延々とリリースできなくなったりというのも。

アジャイル/スクラムやる気なくなるあるある
・これ意味なくね？って思いながらやる振り返り (しょうもない改善点捻り出す時間あったら開発したい…、改善点挙げても実施されないし…など)
・スプリントバックログに大量にタスクが残ったままスプリントが終わる (スプリントで区切ってる意味ないじゃん…)
・プランニング、レビュー、振り返りといったMTGが多すぎて開発に時間が割けない。特にプランニングが無限に終わらない

じゃあどうするのか

開発期間が6カ月だとしたら、「まずは1カ月だけ固定してみよう」というところから始めるとやりやすいかなと思います。ただしそれ以降のスケジュールは白紙というわけではなく、当然ビジネス上の制約があるのでスケジュールは作成します。また1カ月後に最適なプランを立てましょうということで仮置きにするというのがウォーターフォールの失敗ケースからの変化です。1カ月なら見積もりからブレる可能性をある程度抑えられるし、クライアントの新しい要望に来月になれば(理論上)応えることができるし、何より作りかけだとしても形あるものができるとあれこれレビューできてより良いアイデアが出たりするのでメリットが大きいです。

やりたい機能は企画しておくが、スケジュールを固定するのは1月分のみ

スクラムを知っている人からすれば1カ月スプリントって長すぎると思うでしょうし、別に1カ月じゃなくてもいいんですが、アジャイル/スクラムの本に書いてある正解とか理想論から始めるのではなくて、ちょっとずつ「アジャイルになる」考え方がいいよね、ということです。1カ月ごとに以下のような「学習」の機会を設けることでチームが良くなってることを実感できます。

①1カ月で作った成果物をレビューすることで、このUIもっとこの方が…とか盛り上がれる。クライアント含めレビューMTGしても盛り上がる。1カ月もあれば十分盛り上がるくらいの成果物はできてる
②クライアントの要望に対してスコープを調整し直せる。優先度調整がシビアな場合もあるが、1カ月単位であれば今月やりましょうor来月以降やりましょうと振り分けれる
③反省点を出して次の月は改善する振り返りができる。1カ月もあれば有意義な反省点が出てくる

ということで、1カ月単位であればMTGまみれになったりやることがコロコロ変わりすぎたりしないです。開発者が疲弊しないで作るべきものを作っていくことが可能なので脱ウォーターフォールの1歩目としておすすめです。これでうまくいく実感が出れば、1~2週間のスプリントでスクラム開発を本格導入してもうまくいくチャンスがあると思います。繰り返しですがちょっとずつ「アジャイルになる」です。

アジャイルになるということ

最後に、上で紹介した小難しい記事に出てくる図の話をしたいと思います。ぱっと見よくわからないんですが、めっちゃ好きな図です。

上記Martin Fowler氏の記事より引用

まず青い丸の部分を見ると、ウォーターフォールと「Iterative」(つまり繰り返し)が対比されています。ウォーターフォールは要件定義→実装→テストみたいな感じで、一連のフローを一度実行するだけで何かを繰り返すことはないということなので、繰り返しとウォーターフォールが対比されてますね。

次にIterative(繰り返し)の中にある「Adaptive(適応) Planning」ですが、これはさっきの話でいうと1カ月単位で学習できることで改善する、ってのをイメージしてもらえるといいです。繰り返しがあることでビジネスの変化に応じたスコープ調整ができたり、成果物をレビューして改善するチャンスがあったりするわけです。さらにこのAdaptiveな(適応する)やり方を前提として、アジャイル宣言にあるような価値観をベースに開発するのがアジャイルだと理解できます。アジャイルの価値観についてここでは触れませんが、「繰り返すことで適応する」がアジャイルの前提です。

最後にAdaptive Planningと対比されている「Predictive(予測) Planning」ですが、これはまだ何も作ってない段階で予測だけで計画を立てちゃうイメージだと理解しています。こういうとダメな計画法みたいですが、どんなプロジェクトでも最初は何も作ってない状態なので、最初だけは100%予測で計画する必要があります。肝心なのはその予測だけで最後まで突っ走ってしまう、つまりウォーターフォールで終わるのではなくて、1カ月なり何なりで区切って繰り返しを作ることでちょっとずつ「アジャイルになる」です。大事なことなので3回言いましたということで以上です。いいねください！

いいなと思ったら応援しよう！