WBSをはじめて作るときのアプローチ

WBSってシステムエンジニアなら知らない人はいないですよね。なら、誰でも同じように作れるかというと…そう、みんなバラバラなんですよね。１つのWBSが１つのアウトプットになっていて、期間が２週間とか１ヶ月とかになっていると眩暈をしそうになります。と思えば、作業を手順ごとに分解したんだー、とか、それらのブレンドだったり。ブレンドというとカッコよさげですが筋が悪いからね。

アウトプットはなんだろう
システム開発だと工程やスプリントごとにアウトプットを決めていますよね。なぜだかわかりますよね。アウトプットを作るために作業を分解するからですね。

そのアウトプットも仔細に見れば、成果物として定義されているアウトプットとアウトプットを作るための中間生産物に分けることができます。中間生産物は名前のとおり、アウトプットをいきなり作成できないから段階を踏んで作る途中の生産物です。例えば、仕様検討のための資料などがあります。

WBSをいきなり展開、つまり、アウトプットをつくるための具体的で仔細な作業に分解する前にアウトプット自体が何であるかを確認しましょう。

アウトプットってどんな形だろう
アウトプットを確認するってどうやってなにをすればいいのでしょうか。それはアウトプットの完成したときに持っているハズの性質が何であるか、です。

ページ数、体裁、機能数、振る舞い、処理性能…作業をした結果がどんな形状をしているかを作業をする前に知らないとそれを作ることはかなり難しいですよ。できないとは言いませんが納期までにできるかどうかはかなり怪しくなります。

アウトプットを作る共通の作業手順はあるのかな
例えば、設計書を書くときにWBSをどのように展開したらよいのでしょうか。プロジェクトならチームで活動しているとするとメンバがみんなバラバラな手順でよいのでしょうか。そんなことをしたら全員のWBSを１つにまとめたときにプロジェクトのWBSはどうなっているでしょう。スケジュールがちぐはぐになりそうでそのちぐはぐなスケジュールを後から直していくのはずいぶんな手間になりそうですよね。

インプット情報の収集、仕様の検討、設計書の執筆、セルフレビュー、レビューなどプロジェクトとしての作業手順は必ずWBSとして織り込みましょう。

アウトプットの性質を決められないんだけど
そういうときもありますね。設計書などではなくて、フィージビリティスタディのような検証結果をまとめるとか。でも、全くWBSを作れないというわけではありません。

フィージビリティスタディであれば、検証するために必要作業が思いつくでしょう。環境の準備、検証テーマの選定、到達目標の設定、検証実施、まとめ、など。ただ、実際に検証をすると検証という作業の特徴からやってみないとわからないということがあります。そういうときは別の基準を設けておきましょう。いつまで、どこまで、と時間や最低限必須の項目を明示するだけで良いです。

作業をした結果がWBSのアウトプットになっているかな
当たり前ですが、アウトプットをつくるために作業を分解しているのですから、最後の作業が終わったらアウトプットになっていないと何をしてたのかさっぱりわからないことになってしまいますよ。

アウトプットとして持っていなければならない性質を作業が終わった最後で備えているか、アウトプット単位でみたときに備えていることを検証する作業を忘れずに入れておきましょう。

WBSに日付入れないんですか
厳密に言えばWBSは作業分解したものです。日付を入れたものをWBSと呼ぶことが多いですが。まぁ、厳密に言えはそれはスケジュールになっていまいますね。と言っても誰も得をしませんからどっちでもいいですけどねー。