なんとなく作っているWBSのその作り方が間違っているとしたら

システム開発には様々な手法や方法論があり、現場で使われている。こうした意見に対して反論するエンジニアは皆無だろう。

例えばWBSがある。ウォーターフォール型のシステム開発では有無を言わさず採用されているのでウォーターフォールでのシステム開発を経験したエンジニアなら100％経験しているはずだ。もし、WBSを経験してないとしたらどんな方法で作業計画を立てていたか教えて欲しいのでコメント欄に書き込んで欲しい。

では、誰でもが知っているWBSはなんのために作るかを知っているエンジニアはどのくらいいるのだろうか。さらに、WBSの作り方の教科書的な書籍を読み手法として学んでいるエンジニアはどのくらいいるのだろうか。

ほぼほぼのエンジニアはWBSをOJTで、つまりプロジェクトの中で、それも周りの見様見真似で覚えてきたのではないか。

WBSは作業分解ではない

WBSの正式名称は、Work Breakdown Structuresである。直訳すれば、仕事を（複数の）構造に展開したもの、である。あれ、何か違うと気づいたら流石。一般的な理解は、仕事と訳さず作業と訳され、使われていることが多い。もう少し具体的に言えば、（ある目的を持ち、努力して行う）仕事を指す。

システム開発において、ある目的を持って努力して行う仕事とは何か。答えられるだろうか。

何れにしても、WBSは作業を「分解」したものではない。目的を達成するための行為である。

WBSとは何か（復習）

 WBSは、お仕事の目的を構造展開したものである。では、お仕事の目的とは何かを考えてみよう。

さて、思いついただろうか。これだ、とはっきりと即答できただろうか。答えは、成果物を作ることだ。

システム開発に置き換えれば、プロジェクトのスコープを成果物の観点から定め、成果物を構造的な部品に具体化したものが成果物だ。部品化した構造物がどれ一つ欠けてもプロジェクトのスコープを満たさないため、プロジェクトの目的が達成されることはない。

プロジェクトの目的→成果物→部品（ドキュメント、プログラム、HW、etc）

成果物を確認する

 WBSを作成する際に一番最初にすることは何が成果物かを確認することだ。成果物に課せられる制約条件や前提条件があればそれを含めた成果物の仕様を確かめる。

成果物の作成手順を確認する

 次に確認するのは成果物の作成手順を確認する。システム開発はチームで行う。メンバが違うやり方をしていては、同じ成果物を作れなくなってしまう。なので、成果物の作成手順を確認する。

もし、作成手順がなければプロトタイプを行い、成果物を作成できるモデルとなるテンプレートを確立することから始めなければならない。

作成手順は、必要とするスキルとスキルレベルを前提とし、その前提に立って組み立てる。

よく、どこまで作業手順を詳細化すればいいか聞いてくるエンジニアがいるが、この質問が出てくる時点で、WBSの雛形がないと気づかなければならない。チームのエンジニアが同じ粒度でWBSを展開するためにもテンプレートを最初に作ること。

工数を見積もる

構造化したお仕事は、最小のお仕事ごとに作業を見積もる。これは感覚でやってはいけないし、過去のノウハウ（痛い目にあったからとか）でバッファを持たせないこと。

理想時間（割り込みなしで集中してやれたら）で見積もること。

見積もりは、チームでレビューし、チームの標準的な技術レベルか、やや下あたりのエンジニアが担当したときの理想時間で設定すること。

なお、理想時間で見積もるかどうかは、チームで決めておくこと。理想時間で見積もったら、チームのバッファを持つこと。

マンガでわかる! 幼稚園児でもできた!! タスク管理超入門 impress QuickBooks