進ちょく管理の第一歩は，納期・コスト・品質を守るためのスケジュールを立てることにある。その時に最も重要なのは，現実感のある作業内容を明確に定義することだ。この記事では2回にわたって，「WBS（Work Breakdown Structure）」を使って緻密で現実的な計画を作るための勘どころを解説する。
「納期から半年遅れでようやくシステムが稼働した」，「要員の追加投入を繰り返し，人件費がかさんで予算を大きく超過した」——。
当初計画した納期を守ることができず，結果的に赤字に陥るプロジェクトが後を絶たない。仕様があいまいで手戻りが多発した，新しい技術の導入に手こずったなど，原因は様々だろう。
中でも多いのが，きちんと計画を立てていないこと，つまり基本ができていないことである。どこかの工程に遅延が生じたら，その場しのぎとばかりに別の工程を担当する要員を投入。今度は別の工程が遅れ始める。こうなると誰もプロジェクトの見通しを立てられず，メンバーはいつか終わることを祈りながら，ひたすら長時間の作業を続けることになってしまう。
こんな事態に陥らないようにするには，できるだけ詳細で，しかも現実的なスケジュールや作業計画を立てることが欠かせない。現実的な計画があれば，問題が起きた時に計画を見直すことができるし，仮に納期が遅れるにしても，どれくらい遅れるのかが分かるからである。
もちろん，そんな計画を立てるのは決して簡単ではない。まず詳細仕様が決まっていない場合が多いので，仮定をもとに計画を作らざるを得ない。立てた計画は，非常にあやふやなものに思えるはずだ。また要員のスキルが予想より低いと，実施段階ではどんどん誤差が生じてしまう。「計画なんてあまり意味はない」と考えてしまうゆえんである。
だが常に計画を立て，プロジェクト実施段階で見直す作業を定着させれば，何度か繰り返すうちに精度が上がってくる。何もしない場合に比べると，その差は大きい。そこでこの記事では，WBS（Work Breakdown Structure）をもとにした実現性の高いスケジュールの立て方や作業内容の定義方法を解説していく。
計画に使う用語を定義せよ
計画立案に入る前に知っておいて頂きたいことが2つある。1つは，スケジュール計画には大きく分けて3つの種類があること。(1)プロジェクト全体（全工程）の作業内容とスケジュールを示す「大日程計画」，(2)チーム単位の作業内容やスケジュールを示す「中日程計画」，最後に(3)個人レベルの作業内容とスケジュールである「小日程計画」，である。プロジェクトの規模が大きくなると，大日程計画ですべてを表現するのは無理があるし，管理も煩雑になる。そこで3レベルに分けるわけだ。小規模プロジェクトでは当然，すべてを作る必要はない。
3つの中で基本になるのが大日程計画であり，これをもとに中日程→小日程へと展開していく（表1[拡大表示]）。その過程で，例えば大日程計画と中日程計画に不整合が生じる場合がある。大日程計画における仮定が間違っていた場合などだ。それを避けるために，詳細化した結果は常に上位の日程計画へフィードバックし，整合性を保つよう心がける必要がある。
第2の注意点は，それぞれの日程計画の成果物である「スケジュール表」の表記方法や記載内容の詳細度，用語，支援ツールなどを，あらかじめ決めておく必要があること。特に大日程計画と中日程計画は，プロジェクト内部だけでなく，ユーザー企業や協力会社など様々なステークホルダー（利害関係者）がプロジェクトの状況を把握したり，意思決定をするために利用する。言葉の意味は，極めて重要である。
計画立案の7つのステップ
では日程計画の作成手順に移ろう。どのレベルの計画も作り方は同じなので，ここでは「大日程計画」を説明する。その作成手順は，7つのステップから成る（図1[拡大表示]） 。前半のステップ1～3では，主に作業内容を定義する。プロジェクト全体の作業の洗い出しとその詳細化，作業ごとの成果物・工数・要員の定義などである。
後半のステップ4～7では，時間軸に沿って作業手順を決めていく。作業同士の関連や各作業の期間を明確化したうえで，スケジュール表を作成する。通常は，スケジュール表を視覚的に見やすく表現したガントチャートと呼ぶ成果物を作成する。
WBSで作業を「体系化」
まずステップ1で，契約内容などに基づいて，成果物のスコープ（対象範囲）を正確に認識する。成果物にあいまいな部分があると，洗い出した作業内容に漏れが生じてしまう可能性が高いからだ。それを避けるために，成果物のスコープについては必ずユーザー企業に確認するなどして合意をとる。それでもあいまいな部分が残る可能性があるが，ステップ1では「何があいまいなのか」を明確にしておけばよい。
また契約上の納期や，ステークホルダーとの取り決めなど，プロジェクト全体の大きなマイルストーン（完了基準）についても確認しておくことが重要である。
次のステップ2では，プロジェクトで実施すべきすべての作業を，「成果物を作成する作業」を単位として階層的に分割・詳細化していく（以下では，分割した個々の作業を作業項目と呼ぶ）。最終的には，成果物を作成する作業の最小単位，すなわち「ワークパッケージ」にまで分割する。
この時に用いるのが作業項目ごとに成果物や工数，要員などを定義する手法，WBSだ。これを使うメリットは大きく2つある。1つは，成果物に基づいて作業を分割していくため，作業漏れの有無を検証しやすいこと。もう1つは洗い出した作業と成果物の関係が明確になるため，作成する成果物の量や作業にかかる工数の見積もりがしやすいことだ。
WBSによる作業分割の例を（図2[拡大表示]） に示した。まず「プロジェクト全体（システム全体）」をサブシステム単位に分割。次にサブシステムごとに「基本設計」，「詳細設計」，「プログラム作成」といった工程別に作業を分割する。要件定義や統合テストなど，システム全体にかかわる作業は，サブシステムと同じ階層に位置づける。
さらに，各工程で作成する成果物を，その種類に応じて最小の単位まで詳細化し，それに伴って作業をワークパッケージまで分割する。図の例では，「データフロー図作成」や「業務機能定義書作成」といった作業がワークパッケージである。ワークパッケージまで分割するという意味では細かいが，作業分割そのものには違和感はないはずだ。
ステップ2の注意点は，ワークパッケージの粒度である。成果物の種類や分量によっては，1つのワークパッケージの予定工数が極端に大きくなってしまい，スケジュールを計画するうえで精度が悪くなるケースがある。そこで一般的には，ワークパッケージのおおよその粒度を「工数にして2週間（80時間）」程度にするとよいと言われている。
ワークパッケージの粒度がこれを大きく上回る場合は，成果物を再分割するなど粒度を下げる工夫をするべきだ。筆者の経験でいえば，メンバーによる作業の進ちょく報告を「週報」で行うことにしているプロジェクトでは，ワークパッケージの粒度を「1週間（40時間）」にするとよい注1）。
成果物・工数・要員を定義
作業の分割が完了したら，ワークパッケージに，作業内容の詳細を定義していく（ステップ3）。具体的には成果物の種類や量，作業に要する工数（人日・人月など），責任者や要員の氏名，必要となるスキルなどである（図3[拡大表示]）。これをもとに，上位階層の作業項目についても順次，成果物の量や工数を集計して定義していく。
工数の算出には2つの方法がある。1つは，成果物の内容や過去の経験や知識に基づいてワークパッケージの個々の工数を見積もるものだ。これを積み上げて，上位階層の作業項目の工数を決めていく，言わば「ボトムアップ方式」である。もう1つは，ファンクション・ポイント法注2）などによって，あらかじめプロジェクト全体の総工数を算出。これをサブシステムごと，工程ごと，という具合に割り振っていき，最終的に個々のワークパッケージの工数を決定する「トップダウン方式」だ。
どちらか1つの方式だけで工数を確定するのは危険である。2つの方式で算出した工数をつき合わせ，合理的・現実的と思える工数になるよう調整を加える必要がある。
作成したWBSは，現実性を確認するために，プロジェクト経験が豊富な第三者にレビューしてもらうとよい。また，ステークホルダーにもレビューしてもらい，特にユーザー側とベンダー側の作業分担について間違いがないかどうかを確認しておく。
さらに，中期的にスケジュール計画作成の効率と精度を高めるために，「WBSテンプレート」の作成・活用をお勧めしたい。これは過去に実施したプロジェクトの実績をもとに，対象とするシステムの内容に応じて，典型的な作業の階層構造や，作業項目ごとの成果物の種類・量，要員数，工数などを定義した“ひな形”のこと。WBSの各階層に「レベル1」，「レベル2」…といった識別子を付けておくと，階層ごとの作業の内容や粒度を統一しやすく，管理や利用も容易になる注3）。
このようなテンプレートを作るには相当の実績データが必要になるし，作ったとしても，すべてのプロジェクトに適用できるわけではない。一見無駄な作業にも思えるが，こうした努力をしないと，スケジュール作成の効率化は難しい。（次回に続く）
初田 賢司／日立製作所 プロジェクトマネジメント本部 プロジェクトマネジメント技術センター長1980年，日立製作所入社。製造業のSEを経てソフトウェア生産技術の開発に従事。現在はPMO（Project Management Office）に所属し，プロジェクトマネジメント分野のエンジニアリング化に取り組む。日本ファンクションポイントユーザ会副会長，プロジェクトマネジメント学会理事 |
神子 秀雄／日立製作所 プロジェクトマネジメント本部 産業・流通プロジェクトマネジメントエンジニアリング部 担当部長1968年，日立製作所入社。信託銀行向け基幹システムのサポートSEを経て，地方銀行向け資金・証券パッケージの開発などに従事。現在はPMOに所属し，プロジェクトマネジメント技術の開発，プロジェクトの支援・指導に取り組む |
