書籍「ソフトウェア開発はなぜ難しいのか」を読んで

十数年のソフトウェア開発経験から、ソフトウェア開発のマネージメントにおけるWBSの使用方法への違和感があります。

プロジェクトマネージメントでは、WBS(Work Breakdown Structure)を計画と進捗管理に使うとされています。同じ開発組織・メンバーで類似したシステムを開発する場合は、WBSによるタスクもタスクの予定工数もぶれないのですが、毎回違う開発組織・メンバーを集めるような開発をしている現場や、インデント開発でまったく仕組みが違うものを開発する場合、WBSはぶれぶれです。しかもウォーターフォールで開発すると、ぶれをフィードバックによる修正で抑えることなんてできませんから、ぶれが拡大する一方になります。
また、WBSはツリー分解ですが、複雑なシステムでは作業を単一のツリーで表現することはできず、横串を指す作業、品質のように全体を制約するような作業、開発・試験環境、構成管理作業など常に継続する作業を表現するのにかなり工夫が必要です。

といっても、WBSは正論なので、WBSを否定する発言をすると大変なことになります。

そんなとき、ヒントになりそうな書籍を見つけたのでとりあえず読んでみました。

ソフトウェア開発はなぜ難しいのか ~「人月の神話」を超えて (技評SE選書)

本の主題は別にあるのですが、WBSについて言及している箇所がしっくり来たので引用します。

ソフトウェアづくりのプロジェクトでは、段取りだけではうまくいくことはありません。その第一の理由は、最初からWBSを明確に定義することが難しいことが挙げられます。要件の分析、設計、プログラミング、テストといった対局の流れは定義できますが、要件分析をして初めて設計の作業が見えてくるでしょうし、設計が完了してからでないとプログラム開発の部分も作業定義することができません。場合によっては設計まで進んでから新しい要件が見えてくることもあります。つまり、どのような段階でも作業を明確にすることが難しいのです。中間的な成果物を含めて依存関係もありますから、作業間の段取りも動的に変化していくことになります。
(同書 p.113より）

この問題はすごく実感しています。すべての問題を見通して設計できることは稀なので、たいてい出来上がったソフトウェアに対して評価（テスト）をした結果、浮き上がった問題の解決を再度設計することが毎回あります。今流にいえば、一発で設計できるのは神、ということでしょうか。経験を培えば、多くの問題を予め見通せるようにはなるので、設計の質は向上しますが、それでも完璧にはなりません。

よく分かっていない不明瞭なプロセスを分解することはできませんから、WBS主体のプロジェクトマネジメント手法は、それだけではうまくいかないのは自明です。
(同書p.115より）

残念ながら、同書では以降WBSについての言及は見当たらなかったので、WBSをどううまくいくように活用するかは考えねばなりません。