ソフトウェアの開発に携わると、エンジニアが作るWBSと呼ばれるものに遭遇することが多々あります。
エンジニアがクライアントの要件定義を満たすプロダクトを全て細分化して作業を見えるようにしたり、工数の見積もりをするのに利用されたりします。
しかし、WBSの通りに進むプロジェクトはないのにも関わらず、WBSを基準に見積もりや請負契約まで進みます。何か変更があれば、再見積もりという作業が度々発生しているので、再見積もりだけで工数が食われてしまい工数がたりなくなり、プロジェクトは炎上しがちになります。
UXデザイナーとしてプロジェクトへ関わると、なぜWBSをエンジニアは作るのだろうか？なぜ「認識していない」ものを探らずに開発を始めるのか疑問でした。その疑問を解き明かしていきたいと思います。
そもそもWBSって何
そもそも「WBS」は何でしょう？こういった略語の3文字は非常に多く、なんとなく使ってる人も多いのではないでしょうか。また、意味もわからず、それを作れば何かができるといった理解の程度の人もいるかもしれません。
WikipediaによるとWBSは「Work Breakdown Structure」の略です。簡単にいうとプロダクトの構造を分解して並べることです。
1957年くらいに、アメリカ軍でこのWBSを作ることがはじまったようです。United States Department of Defense のPERTとよぶフレームワークの中で紹介されたようです。アメリカ軍の武器や兵器など工業製品でつかわれていました。
トム・クルーズの主演のトップガンで有名になったアメリカの戦闘機F16というのがありますが、20年以上前の映画の頃に全盛期の飛行機でしたが、実は中東やアジアでは未だに現役で活躍しています。軍事で使われる設計というのは、ソフトウェアと異なり変更があまりありません。
下記がその、エアクラフトシステムのWBSです。Aircraft Systems WBSと右上に記載されています。
もともと戦闘機に利用されていたのがWBSの始まりでした。このように工業製品の中でも非常に何を作るのかはっきりしている分野がスタートです。しかし、これが私達のソフトウェア開発では使えない理由です。
WBSが使えない２つの理由
WBSには、2つの問題があります。一つは完成したものが正しいプロダクトなのか不明なこと。2つ目は、分解したとしても市場の不確かさに対応できないことです。
WBSの記入ルールに「100％ルール」と呼ぶものあるようです。工程を分解して小さいパーツにして、また足して戻しても100になるという理論です。100％で出来上がったものが正しい完成品かどう定義するのでしょう。
100％というのはあくまで、分解と組み立ての関係性にズレがないことを意味しており、製品が市場の問題解決にフィットしているかの100％ではありません。
十分な調査をおこない、プロダクトが市場にフィットしているかどうか実験を繰り返す必要があります。
市場の変化が早い現在では変更を何度も余儀なくされるのです。ましてソフトウェアのような未知なものや変更が多いものにWBSは使えないと考えますし。実際の案件でも多々WBSが意味のないものになるのを見届けてきました。
次に、WBSの利用方法に見積もりがあります。それぞれの工程にどのくらいの時間がかかるのかをざっくりと多目で見積もります。多目にすることをバッファと呼ぶ人もいます。多目で見積もりするのは、これは何かあった時に炎上するので保険の為です。すでにこの時点でWBSの精度に問題がありますが、ほぼWBSは多目の工数が計算されています。「このくらいのバッファがあれば十分でしょう」などという言葉を耳によくするひともいるでしょう。この時点でWBSがおかしいと考えねばなりません。
架空でしかも不確かさを基に見積もりをするのが間違いです。開発中に新たに見つかる問題や競合がいることで変わるプロダクトのビジネスバリューの変化を理解していません。繰り返すようですが軍事施設や兵器を開発しているのではありません。競合がいて、常に変化を求められる不確かさがある世界だということを認めるなければなりません。
WBSとプロダクト・マネジメント
そもそも、WBSが云々よりプロダクトマネジメントでは、不確かさがあることを認識することが最初です。PIJでは下記のようなフレームワークを紹介しています。非常に当たり前の図なので、知ってる方は多いかもしれません。この図の本当の目的は、認識していない事があることを理解し、どのように認識してないことにアプローチするかを説明しています。
WBSは残念なことに、「認識している」ことだけを基に作成されてしまっています。
「認識していない」ことがあるのが普通であり、その思考を私達は忘れてはいけません。私達の認識していることは不十分なのです。それを認めましょう。
WBSに代わるもの？何が必要なのか？
WBSが変化の激しい現在において、使い物にならなことが、わかったのではないでしょうか？では代わりに何をすれば良いでしょうか？にどうやって工数を見積もれば良いのでしょうか？
プロダクトマネジメントでは認識していないものがあることを前提にし、実験をしてプロダクトとして開発するべきものをまず見定めます。プロダクトとして何を作るのかだけ調査する費用からスタートすることをオススメします。開発の工数はその後の話です。
「そんなの困る」開発予算を決めなければという人がいるかもしれません。予算をたてて見積もってからというのは理解できますが、無理して作った見積もりは所詮は空想なのです。このことに時間をかけることは止めましょう。
