ウォーターフォールとアジャイル開発の間に♡が足りない

初めて覚えたシステム開発手法がウォーターフォールだったので、覚えたシステム開発手法の順番は、ウォーターフォール→プロトタイプ手法→インクリメンタル開発…だったような気がする。暫くして、アジャイル開発のカンバンを使ってプロジェクトを運営した。

ネットでスクラムなどのスライドを見て、アジャイル界隈のコミュニティの存在を知り、イベントにもいくつかは参加してみた。スライドや書籍を読んだ理解の方向性があっているかそれとなく確かめたかったからだ。

2011年頃のアジャイル関連のいくつかのコミュニティに参加したときには、うんざりした気持ちになった。

冒頭に出てくるのが滝の写真でウォーターフォールは行けていないと揶揄するのだ。黙っていたが、正直、気分の良いものではなかった。登壇者にスライドの内容を批評するのが目的ではなかったし、そんなのトラブルの種でしかない。

自分の目的はどれだけやれるのか、理解の方向性をプラクティスから補強する材料が欲しかっただけだ。

でも、結局、自分のプロジェクトで試行錯誤することから得られる経験知の方が何倍もの価値があった。当たり前なことではあるが、人は少しでも自分の考えと似たことをした人がいると安心するのだ。論理的ではないが。

スコープに対する考え方は違うが、ショートタームのウォーターフォールであると捉えた。それを仮説とすると、アジャイルのコミュニティでうんざりしたスライドの登壇者は相当不幸なウォーターフォール型のプロジェクトにアサインされて懲り懲りな体験をしたか、ウォーターフォール型のプロジェクトは肌が合わなかったのかもしれない、と思った。もう一つのケースもあるがそれを書くと余計なことを引き起こすかもしれないのでそっとしまっておく。

そんな中で誰だったかがそうした揶揄することは止めて「仕事をしろ」「アジャイルの実績を作れ」と言うようにトレンドを必死に変えようとしていたことに、これは流れを変えないと後ろがないと危機感を感じているのだろうと思った。これは、自分にとって好ましく思った。実践フェーズに突入宣言をしたようなものと受け止めたからだ。

自分の（管理下の組織の）プロジェクトで欲しかったのは可視化と作業の流量制御と負荷の共有とプロジェクトの状況のメンバ全員の共通認識であった。

だから、カンバンだった。

プロマネを専門としているので、プロジェクトが目的どおりに成功するためにプロジェクトの目的達成ドブリンで考える。顧客とのインタフェースもある。スクラムではなかったのはそういった理由があったからだ。

目的がある。顧客や社内でのコミュニケーションプロトコルの制約などとプロジェクト内で抱えていた課題解決からウォーターフォールとカンバンを組み合わせて使うことにした。

そこには揶揄するような対立構造はなく、プロジェクトを成功させようとするチームが存在しただけだった。

ウォーターフォール　vs　アジャイル開発

ではなく

ウォーターフォール　♡　アジャイル開発

だけが存在した世界があった。

技術の間には♡を足そう。