アジャイルでもウォーターフォールでも、WBSの作り方が肝になるんじゃね？

はじめに

アジャイル vs ウォーターフォールという（想像上の）議論が花盛りな職場にいるのですが、実際にやった事が無い人がいくら何を言っても机上の空論。

そんな人が決まって言うのは、「アジャイルの危険性をきちんと認識して、間違ったプロジェクトに適用しないように事前に議論しているんだ。」ということで、たしかに仰っていることは正論なんですが、結局なんだかんだでケチ付けているように思う今日この頃です。

進捗20%

アジャイルという方法論自身は割とどうでもよくて、問題は目の前にあるプロジェクトをうまく動かすためにはどのような試みをするべきかを考えるほうが私は興味あります。

そんな中、とあるウォーターフォールで進んでいるプロジェクトの進捗会に出たとき、「進捗20％です」という声が聞こえたので、ちょっと突っ込んでみました（我ながら性格悪い

その20％っていう根拠ってなんでしょう。全体の作業量がどれぐらい有って、そのうち、何が終わっているから20％っていうのなら分かります。それぞれ言って頂けませんか？

すると、案の定

全体の作業量も、全体に占める現在終わった作業もわかりません。なんとなくで付けました。

というお答え。う〜ん、勘で報告するって、論理的な指向が武器の我々がやったらいけないことなんじゃなかろうか思う今日この頃ですが、それが現実です。

PMP

PMPというプロジェクトマネジメントを体系化したものがありまして、その中に「プロジェクトスコープマネジメント」という章があります。
そこに、「WBS作成」という節があり、そこには

WBS作成は、プロジェクトの要素成果物およびプロジェクトの作業を、より細かく、マネジメントしやすい要素に分解するプロセスである。ワーク・ブレークダウン・ストラクチャー（WBS）は、プロジェクト目標を達成し、必要な要素成果物を生成するために、プロジェクト・チームが実行する作業を、要素成果物を主体に階層的に要素分解したものである。（『プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第4版』P116より）

A Guide to the Project Management Body of Knowledge: Official Japanese Translation(プロジェクトマネジメント　知識体系ガイド　PMBOKガイド)

と書かれています。難しい言葉で書かれていますが、要はやることを細かい単位で管理しやすい（定量化しやすい）ものとして取り扱うことができるようにすることを述べています。

このことは、まんまアジャイル開発でのユーザーストーリーの作り方と一緒です。

ユーザーストーリーに抽出に当たっては、小さくて、具体的な、エンドツーエンドの機能にすることを心がけよう（『アジャイルサムライ』P121より）

アジャイルサムライ−達人開発者への道−

な〜んだ。結局一緒やん。

だけど、それが一番難しい

結局、ウォーターフォールだろうが、アジャイルだろうが、WBSの作り方がプロジェクトをうまく動かすための一つになります。

が、WBSを小さくて、具体的な単位に落としていくのは結構難しい話です。

抜け・漏れはないか。他の作業と比較して、細かすぎないか・大雑把すぎないか。そもそもそんなに細かくつくっていくと時間ばっかり取られて早く（帰れない／コード書けない／見積もりが出せない／etc）。

結局はある程度の粒度で落ち着かせて、見積もりを出したり作業を切り出したりするのが現実です。

その状態は、最初の見積の段階だといいのでしょうが、実装の段階までそのままというのは致命的です。

PMPでもアジャイルでも言われていますが

（初期の）見積もりは適当です。

それをずっとメンテナンスせずに実装まで突き進んでいるのが、プロジェクト管理の現実のような気がします。