アジャイル vs ウォーターフォール
アジャイルが日本に広まっていくのと同時に、アジャイルとウォーターフォールが対比関係として語られることをしばしば目にするようになった。
個人的にはアジャイルとウォーターフォールはそもそも比較するものではなく、”括り”が違うのではないかなと思い、思考整理のためにnoteを書いてみる。
アジャイルとは
個人的なアジャイルの解釈は、「すばやく変化に適応できるよう目指し続けている状態」。
前半と後半に分けて言語化してみる。
「すばやく変化に適応できる」
「変化」というのは、ビジョンを実現するために向き合う「対象」の変化。
「対象」というのは、ユーザーでもあり、市場でもあり、競合でもあり、自身のプロダクトでもあり、自分たちチームでもある。
実現したいビジョンは1つで変わらない、Coreの部分。
そのゴールに向かうためのさまざまな「対象」に向き合い、それらの変化を捉え、そして適応する。
「目指し続けている状態」
Do でもなく、Be でもなくBecome。
成ることができるものではなく、「成ろうとし続ける」という状態と解釈している。
これが満たされていればアジャイルである、というチェックボックスがあるのではなく、それを目指し続けている状態こそがアジャイルではないかと思う。
ウォーターフォールとは
個人的な解釈として、これは明らかに”開発手法”。
主に以下のようなチェックリストに当てはまれば、それはウォーターフォールであると言えそう。
✅リリースまで工程が分かれており、順番に進める
✅基本的には前工程に戻ることができない
✅最初の段階で最終工程まで計画を決める
アジャイル vs ウォーターフォール
ウォーターフォールは開発の進め方であるのに対し、アジャイルは「適応しようとし続ける」というチームおよびプロダクトの状態のこと。
なのでこれらは対比関係ではない、というのが私の考えである。
前工程に戻れないことや、最初から最終工程まで決めないといけないことは会社ならいくらでもある。
取引先との兼ね合いでリリース日はずらせないとか、要件をがっちり決めて変更できないとか、予算を決めるために最終工程までの見積りがないとスタートできないとか。
この状況下で、いかに変化に適応しようとし続けるか、適応できる状態をつくろうとするかが、アジャイルを実践する上で重要なのではないかと思う。
たとえば・・・
変化をすぐに捉えるためにステークホルダーと定期的に同期をとるとか、
市場や競合の状態を追い続けるとか、
「やっぱこれじゃ使えない」とならないようにユーザー課題の解像度を上げておくとか、
うまくいってないことをいち早く検知できるようにデイリーで同期をとるとか、
すぐにヘルプが出せるように各自のタスク状況を見える化しておくとか、
変更容易性のあるコードを書くとか、
あとからここにも影響範囲があった!とならないよう、疎結合なアーキテクチャにするとか、
なんなら、アジャイルにウォーターフォール開発をすることだってできるはず。
まだまだアジャイル勉強中。