エンジニアがウォーターフォールを嫌いな理由
アジャイル開発の手法というよりは、カンバンが好きなのはこんな理由からだ。
・作業プロセスを常時見られる
・アクティビティのステータスを見られる
・作業プロセスの改善をしやすい
・アクティビティのオーナシップがエンジニアになる
パッと思いつくだけをあげても4つある。
作業プロセスを常時見られるというのは、プロジェクトチームのエンジニアに作業プロセスのガイドを作り、研修する手間が省ける。研修が面倒というより、その場で理解しないで実践になって、ガイドを見ずに進めて、指摘されて初めてガイドの存在を認識するエンジニアもいる。最初から目の前にあり、ほかのエンジニアがそれでやっていれば、習うことがなくても門前のなんとかでやれる。作業プロセスがどうしてそうなっているかの背景は理解されなくても、作業品質は一定確保される。
アクティビティのステータスは、そのままだ。モニタリングしたい作業の粒度でカンバンの列を分解するのでどこまで進んでいるかが一目できる。進捗のきになるアクティビティを都度エンジニアに聞きに行かなくてもデイリースタンドアップミーティングで共有されるから、エンジニアの時間を煩わすこともない。
カンバンの作業プロセスはモニタリングしたい粒度を損なうことがなければチームに改善を委譲するからエンジニアの目線で改善しやすい。
カンバンの作業プロセスの改善をエンジニア自身でしやすくなるということは、アクティビティのオーナシップがエンジニアに移る。
これがWBSのレベル1をPMが作り、エンジニアリーダとエンジニアにアクティビティの分解とスケジューリングを頼むとやらされ感はいがめない。
カンバンの方がエンジニアに主導権がある。
トラブれば、手続きが多くてもタイムボックスの中でスピード感を持ってリリースするのだから、ウォーターフォールだろうがなんだろうが、開発スピードは（持続できるかは別として）確保できる。所詮、作業をするということは、作業プロセスを回すということなのだから、開発手法云々にはならない。
ウォーターフォールは目的最適化して目的を実現するアプローチをするから機能分解する。分解して再構成する作業ファーストの価値観だからエンジニアはそれを実現するアトリビュートでしかない。
なんかね、エンジニアはそれが嫌なんじゃないかと思う。ウォーターフォールで失敗プロジェクトが数多あるのは別問題だが、エンジニアが二の次に扱われるのが息苦しいのではないか。
とは言え、デイリーで全員の前でトレースされるプレッシャもあるが。
プロマネから見れば、アクティビティにする時点でアクティビティのアウトプットは決まるから、スコープが確定しているプロジェクトだろうが、都度決めるプロジェクトだろうがカンバンの使い勝手は変わらない。
