ウォーターフォールは衰退しました


ウォーターフォールは衰退しました
ウォーターフォール、なんと荘厳で規律のありそうな響きでしょう。見積もりをするときからウォーターフォールを採用することを暗黙にして、だれもがウォーターフォールを実行できると疑わず、プロジェクト計画でもアサインされるプロジェクトマネージャもプロジェクトメンバも誰もがウォーターフォールというシステム開発手法を知り、実行できると思っている。プロジェクトにおいてウォーターフォール暗黙知であり、それを誰もができる“ハズ”であると信じて疑わないのに。


ステークホルダ、特にプロジェクトチームのマネージャは、暗黙で彼らプロジェクトチームがウォーターフォールでプロジェクトを期待する品質、コスト、納期プラス時間でやり切れると期待している。“暗黙”で期待しているから“形式”で外的にわかるような振る舞いとして働きかけないのです。


これを続けるとどうなるでしょうか。少し前の時代に、QMSとかCMMIとかでデミングサイクルとか組織のcapabilityやmaturityなどといってコンピテンシレベルの底上げを図ることが話題になったけれど、どれだけ形式知として身についたのでしょうか。


組織としてデミングサイクルが確実に実行されているなら、システム開発手法にウォーターフォールを採用し続けていれば、しくみとしてQMSのPDCAが改善として回るのでプロジェクトが自責でデスマになるようなことはありえないでしょう。しかし、ウォーターフォールを採用するプロジェクトは失敗を重ねるのです。それはどこに問題があるのか。


ウォーターフォールはしくみとして改善し続けられる。では、それを回す中の人はどうか。ここにウォーターフォールを改善し続けてもデスマがなくならない真の原因があるのではないでしょうか。


スクラムだけどアジャイルだから関係ないよね
最近、アジャイル界隈のスクラムが元気がいいですね。特にWebアプリあたりはスクラムシステム開発方法として採用して、早く顧客に価値を届けようとしている。アジャイル宣言アジャイル宣言の背後にある原則を読み、それを意識して行動するなら、全てのアジャイルなプロジェクトは成功するのではないか。

「その幻想をぶち殺す!! 」


そんなことを言いながら、誰か出てきそうですが。アジャイルなプロジェクトもご多分に漏れず半数以上が何等か問題を抱えたトラブルプロジェクトになるようだ。
#どうして?
ウォーターフォールのプロジェクトチームは規模が大きく、ロールに応じたスキルセットを持つエンジニアを寄せ集め護送船団方式でプロジェクトをキャリーするが、スクラムは、7人±2人くらいの小さ目なチームの人数で技術領域もメンバが技術レベルは夫々バラツキがあるとしても全員でカバーできるようなチーミングで、一人ひとりのマインドセットは高く...(略、つまり、“アジャイル宣言の背後にある原則”でさらっと書かれている高度な要求レベルをクリアしたメンバが高いモチベーションで取り組むことが出来る、そんなドリームチームなんて組めやしない。


何より、アジャイル宣言の背後にある原則を理解して、それをココロに留めて、実行を心掛けるエンジニアなんてほんの一握りだ。スクラムでそれができるなら、ウォーターフォールのプロジェクトだって、そういったメンバばかりだろうからどれだけうまくいったことだろう。でも、ウォーターフォールのプロジェクトはアジャイルのそれより失敗するプロジェクトの割合が多い。


ウォーターフォールのプロジェクトが上手くいかなかったから何かを変えて、特に同じメンバでチームを組み続けることを念頭に形式知をコミュニケーションで維持し、高いコンテキストを補完するしくみを作り上げたのではないか。だから、必要なものは作るけど、−もちろん、顧客が欲しいと言えばアジャイルなプロジェクトなら作りそうもないドキュメントも作るよ−、必要でないものは作らないし、先々のための必要になるかどうかわからないものはアウトプットしない。


それでもやっぱりスクラムだけどアジャイルだから(デスマとは)関係ないよね?って聞かれれば、何言っているんじゃい!って思うのだ。



俺のプロジェクトがこんなに可愛いわけがない
プロジェクトのフレームワークであるシステム開発手法なんて、所詮、仕組みだけの話なのだ。それがプロジェクトをやるわけではない。プロジェクトをやるのは人なのだ。当たり前のことを当たり前だと知っているのだろうか。知っているなら、なぜ、マネージャはメンバをそう育てないのだ?エンジニアは自分のコンピテンシを伸長しないのだ?


システム開発手法がプロジェクトをやるのではない。ウォーターフォールの中に妖精さんがいるわけでもないし、スクラムの中に魔法使いや能力者がいるわけでもないのだ。マネージャもエンジニアもプロジェクトに関わることの前にそれを実行できると宣誓してから参画してほしい。そうすれば、自分の、私の、俺のプロジェクトがこんなに可愛いわけがない、と愛着もわき、顧客に届けようとするだろう。