初めての見積もり~WBS(Work Breakdown Structure)の作り方

上司や先輩が、プロジェクトマネジメント理論を軽んじる人だと、ここで書くことはあまり役に立たないかもしれない。でも、一応、基本なので、知っておいた方がよいかも。

見積もりスキルを習得する最初のステップとして、まずは、自分の仕事の作業量を見積もることから始めましょう。

この記事は、若手SEが自分の仕事量を見積もってWBS(Work Breakdown Structure:詳細に分解した作業を積み上げてスケジュール表にした資料)を作成する際の注意点をまとめました。

見積もりとは、作業時間を予測すること

システム開発プロジェクトの特徴の一つとして”独自性”があります。全く同じ内容のシステム開発はないということです。言い換えれば、システム開発作業の各工程の一つ一つの設計・プログラミング・テストの内容について全く同じ作業はないということです。

見積もりとは「その作業にどれくらいの時間がかかりそうかを予測する」行為ですが、上記の通り、全く同じ仕事が2度とないのであれば、「似た経験から予測する」やり方が有力な方法となります。これを類推見積もりと呼びます。

従って、見積もりの基本は、経験を積むことです。そして似た仕事をする時に「以前やったあの仕事は1週間くらいかかったな。今回は、それよりも難易度が高いので2週間かかるだろう。」と予想します。

また、経験済みの仕事と、これから行なう仕事を比べる際、予想開発ステップ数など作業量のボリュームだけでなく、経験済みの仕事になかった「初めて」の要素がこれから行なう仕事にどれくらいあるか、つまり「難易度・リスク」といった要素を加味しましょう。

作業を見積もってWBSを作成する流れ

例として、先輩システムエンジニアから、「じゃあ、この機能の詳細設計からコーディング、単体テストまでをやってみて。どれくらいかかりそうか見積もって、スケジュールを立てて下さい。」と指示を受けたとしましょう。その場合、以下の手順でWBSを作成します。

1.1つ1つの作業に分解して、類似経験を元に見積もる

自分の仕事を頭の中でシミュレーションして、一つ一つの作業に分解して書き出します。慣れてくれば大きな塊で作業を書き出しても構いませんが、初めのうちは、1つ4時間くらいの作業にまで分解しましょう。

例えば、詳細設計書作成だけでも、担当プロジェクトの標準書式の確認、上流工程の基本設計の理解、設計方法の検討、設計書作成、レビュー、レビュー指摘の反映、といったプロセスに詳細化できます。

2.未経験の要素があれば、別タスク・課題として書き出す

自分が似た経験をしていない作業は「リスク」となります。ここでいう「リスク」とはプロジェクトマネジメントの用語で、「発生するかどうか予想できず、プロジェクト進行に影響を与える不確実な事象」を意味します。要するに「やったことがないから、うまくいくかわからない」ということです。これをしっかり認識して明文化・可視化することが大切です。

大きなプロジェクトのマネジメントでも、個々のシステムエンジニアの詳細なタスクでも、計画通り開発が進まないのは、この「リスク」が顕在化することが原因です。従って、何が「リスク」なのか意識して可視化する、これは習慣としてしっかり身につけて頂きたいです。

3.WBSのスケジュール表を作成する

1と2の作業を元に、スケジュール表を作りましょう。この例の場合では、基本的には作業に前後関係があり、自分一人だけでほとんどの作業が完結しますので、開発作業を順番に書き出していけばよいです。このとき、「リスク」顕在化の可能性を考えて、早めに上位者のレビューを受ける、リスクのある作業は前倒して着手する、完了時期にバッファ期間を設けるなどをスケジュール表に織り込みましょう。

まとめ

システムエンジニアとしてキャリアアップしたいなら、見積もりはいずれ習得しなければならないスキルの一つですが、見積もるためには、類似の経験や知識があることが前提となります。また、これから行なう仕事全体に対して、経験済みの仕事(開発リスクが低い仕事)と、未経験の仕事(開発リスクが高い仕事)に分解して、スケジュール表や課題一覧表などに書き出し、可視化しましょう。

繰り返しになりますが、書き出して可視化することが大事です。他のプロジェクトメンバーと情報を共有し、組織としてその作業・課題を管理することができるからです。

タイトルとURLをコピーしました