作業計画とスケジュール作成の実践知識--緻密なWBS定義こそが重要
|
「納期から半年遅れでようやくシステムが稼働した」、「要員の追加投入を繰り返し、人件費がかさんで予算を大きく超過した」――。
当初計画した納期を守ることができず、結果的に赤字に陥るプロジェクトが後を絶たない。仕様があいまいで手戻りが多発した、新しい技術の導入に手こずったなど、原因は様々だろう。
中でも多いのが、きちんと計画を立てていないこと、つまり基本ができていないことである。どこかの工程に遅延が生じたら、その場しのぎとばかりに別の工程を担当する要員を投入。今度は別の工程が遅れ始める。こうなると誰もプロジェクトの見通しを立てられず、メンバーはいつか終わることを祈りながら、ひたすら長時間の作業を続けることになってしまう。
こんな事態に陥らないようにするには、できるだけ詳細で、しかも現実的なスケジュールや作業計画を立てることが欠かせない。現実的な計画があれば、問題が起きた時に計画を見直すことができるし、仮に納期が遅れるにしても、どれくらい遅れるのかが分かるからである。
もちろん、そんな計画を立てるのは決して簡単ではない。まず詳細仕様が決まっていない場合が多いので、仮定をもとに計画を作らざるを得ない。立てた計画は、非常にあやふやなものに思えるはずだ。また要員のスキルが予想より低いと、実施段階ではどんどん誤差が生じてしまう。「計画なんてあまり意味はない」と考えてしまうゆえんである。
だが常に計画を立て、プロジェクト実施段階で見直す作業を定着させれば、何度か繰り返すうちに精度が上がってくる。何もしない場合に比べると、その差は大きい。そこで第2部では、WBS（Work Breakdown Structure）をもとにした実現性の高いスケジュールの立て方や作業内容の定義方法を解説していく。
計画に使う用語を定義せよ
計画立案に入る前に知っておいて頂きたいことが2つある。1つは、スケジュール計画には大きく分けて3つの種類があること。(1)プロジェクト全体（全工程）の作業内容とスケジュールを示す「大日程計画」、(2)チーム単位の作業内容やスケジュールを示す「中日程計画」、最後に(3)個人レベルの作業内容とスケジュールである「小日程計画」、である。プロジェクトの規模が大きくなると、大日程計画ですべてを表現するのは無理があるし、管理も煩雑になる。そこで3レベルに分けるわけだ。小規模プロジェクトでは当然、すべてを作る必要はない。
3つの中で基本になるのが大日程計画であり、これをもとに中日程→小日程へと展開していく（表1）。その過程で、例えば大日程計画と中日程計画に不整合が生じる場合がある。大日程計画における仮定が間違っていた場合などだ。それを避けるために、詳細化した結果は常に上位の日程計画へフィードバックし、整合性を保つよう心がける必要がある。
|
|
|
| 表1●スケジュールの種類と目的 ひと口にスケジュールと言っても、(1)プロジェクト全体の進ちょくを示す「大日程計画」、(2)チーム単位の進ちょくを示す「中日程計画」、(3)個人レベルのスケジュールを記した「小日程計画」の3つがある。 大日程から中日程、小日程の順に詳細化していく [画像のクリックで拡大表示] |
第2の注意点は、それぞれの日程計画の成果物である「スケジュール表」の表記方法や記載内容の詳細度、用語、支援ツールなどを、あらかじめ決めておく必要があること。特に大日程計画と中日程計画は、プロジェクト内部だけでなく、ユーザー企業や協力会社など様々なステークホルダー（利害関係者）がプロジェクトの状況を把握したり、意思決定をするために利用する。言葉の意味は、極めて重要である。
計画立案の7つのステップ
では日程計画の作成手順に移ろう。どのレベルの計画も作り方は同じなので、ここでは「大日程計画」を説明する。その作成手順は、7つのステップから成る（図1）。前半のステップ1～3では、主に作業内容を定義する。プロジェクト全体の作業の洗い出しとその詳細化、作業ごとの成果物・工数・要員の定義などである。
|
|
|
| 図1●スケジュール作成の一般的な手順 大日程計画を作成する手順を示した。このうち特に重要なステップは、WBSによる作業の分割である |
後半のステップ4～7では、時間軸に沿って作業手順を決めていく。作業同士の関連や各作業の期間を明確化したうえで、スケジュール表を作成する。通常は、スケジュール表を視覚的に見やすく表現したガントチャートと呼ぶ成果物を作成する。
WBSで作業を「体系化」
まずステップ1で、契約内容などに基づいて、成果物のスコープ（対象範囲）を正確に認識する。成果物にあいまいな部分があると、洗い出した作業内容に漏れが生じてしまう可能性が高いからだ。それを避けるために、成果物のスコープについては必ずユーザー企業に確認するなどして合意をとる。それでもあいまいな部分が残る可能性があるが、ステップ1では「何があいまいなのか」を明確にしておけばよい。
また契約上の納期や、ステークホルダーとの取り決めなど、プロジェクト全体の大きなマイルストーン（完了基準）についても確認しておくことが重要である。
次のステップ2では、プロジェクトで実施すべきすべての作業を、「成果物を作成する作業」を単位として階層的に分割・詳細化していく（以下では、分割した個々の作業を作業項目と呼ぶ）。最終的には、成果物を作成する作業の最小単位、すなわち「ワークパッケージ」にまで分割する。
この時に用いるのが作業項目ごとに成果物や工数、要員などを定義する手法、WBSだ。これを使うメリットは大きく2つある。1つは、成果物に基づいて作業を分割していくため、作業漏れの有無を検証しやすいこと。もう1つは洗い出した作業と成果物の関係が明確になるため、作成する成果物の量や作業にかかる工数の見積もりがしやすいことだ。
WBSによる作業分割の例を図2に示した。まず「プロジェクト全体（システム全体）」をサブシステム単位に分割。次にサブシステムごとに「基本設計」、「詳細設計」、「プログラム作成」といった工程別に作業を分割する。要件定義や統合テストなど、システム全体にかかわる作業は、サブシステムと同じ階層に位置づける。
|
|
|
| 図2●WBSによる作業分割の例 WBSとは、プロジェクト全体を、成果物を生み出す作業単位に分割すること。大日程計画では、WBSの最小レベルである「ワークパッケージ」まで分割し、中日程計画や小日程計画では成果物の有無を考慮しない作業単位である「アクティビティ」まで分割する |
さらに、各工程で作成する成果物を、その種類に応じて最小の単位まで詳細化し、それに伴って作業をワークパッケージまで分割する。図の例では、「データフロー図作成」や「業務機能定義書作成」といった作業がワークパッケージである。ワークパッケージまで分割するという意味では細かいが、作業分割そのものには違和感はないはずだ。
ステップ2の注意点は、ワークパッケージの粒度である。成果物の種類や分量によっては、1つのワークパッケージの予定工数が極端に大きくなってしまい、スケジュールを計画するうえで精度が悪くなるケースがある。そこで一般的には、ワークパッケージのおおよその粒度を「工数にして2週間（80時間）」程度にするとよいと言われている。
ワークパッケージの粒度がこれを大きく上回る場合は、成果物を再分割するなど粒度を下げる工夫をするべきだ。筆者の経験でいえば、メンバーによる作業の進ちょく報告を「週報」で行うことにしているプロジェクトでは、ワークパッケージの粒度を「1週間（40時間）」にするとよい＊1。
成果物・工数・要員を定義
作業の分割が完了したら、ワークパッケージに、作業内容の詳細を定義していく（ステップ3）。具体的には成果物の種類や量、作業に要する工数（人日・人月など）、責任者や要員の氏名、必要となるスキルなどである（図3）。これをもとに、上位階層の作業項目についても順次、成果物の量や工数を集計して定義していく。
|
|
|
| 図3●WBSによるワークパッケージの定義の例 個々のワークパッケージに対して、作成すべき成果物の種類・量や、作業に要する工数、責任者や要員の氏名などを記述する。このほかの項目としては、作業に必要なスキルや、ユーザー企業とベンダーの作業分担などがある [画像のクリックで拡大表示] |
工数の算出には2つの方法がある。1つは、成果物の内容や過去の経験や知識に基づいてワークパッケージの個々の工数を見積もるものだ。これを積み上げて、上位階層の作業項目の工数を決めていく、言わば「ボトムアップ方式」である。もう1つは、ファンクション・ポイント法＊2などによって、あらかじめプロジェクト全体の総工数を算出。これをサブシステムごと、工程ごと、という具合に割り振っていき、最終的に個々のワークパッケージの工数を決定する「トップダウン方式」だ。
どちらか1つの方式だけで工数を確定するのは危険である。2つの方式で算出した工数をつき合わせ、合理的・現実的と思える工数になるよう調整を加える必要がある。
作成したWBSは、現実性を確認するために、プロジェクト経験が豊富な第三者にレビューしてもらうとよい。また、ステークホルダーにもレビューしてもらい、特にユーザー側とベンダー側の作業分担について間違いがないかどうかを確認しておく。
さらに、中期的にスケジュール計画作成の効率と精度を高めるために、「WBSテンプレート」の作成・活用をお勧めしたい。これは過去に実施したプロジェクトの実績をもとに、対象とするシステムの内容に応じて、典型的な作業の階層構造や、作業項目ごとの成果物の種類・量、要員数、工数などを定義した“ひな形”のこと。WBSの各階層に「レベル1」、「レベル2」…といった識別子を付けておくと、階層ごとの作業の内容や粒度を統一しやすく、管理や利用も容易になる＊3。
このようなテンプレートを作るには相当の実績データが必要になるし、作ったとしても、すべてのプロジェクトに適用できるわけではない。一見無駄な作業にも思えるが、こうした努力をしないと、スケジュール作成の効率化は難しい。
作業同士の「関連」を設定
ここから大日程計画作成の後半のステップに移る。後半ではWBSで定義した作業項目を、時間軸に沿って効率的に実施できるように作業手順を定義していく。最初に行うのは、作業同士の関連を明確にすることだ（ステップ4）。効率的に作業を進めるようにするには、作業の順序や作業同士の依存関係をはっきりさせなければならない。
作業同士の関連には、大きく4つのタイプがある。(1)前の作業が終わらないと、次の作業に着手できない関係、(2)作業を同時に開始できる関係（ただし、必ずしも同時に開始しなくてもよい）、(3)作業の終了が同時になる関係（必ず同時に終了しなければならない）、そして(4)互いの作業は完全に独立し、並行作業できる関係（作業同士が無関係）、である＊4。
洗い出した作業について、これら4つの関係を明らかにすること自体は、さほど難しくはないだろう。ただし、作業同士の関連に影響する様々な制約事項を考慮することを忘れてはならない。例えば確保できる要員を明確にしておかなければ、並列化できる作業とできない作業を見極められない。他のプロジェクトと兼務する要員がいる場合も、着手する時期や完了時期を考慮する必要がある。機器や設備といったリソースを使える期間に制限がある場合も同様だ。
作業の順序や作業同士の依存関係（これをプロジェクト・ネットワークと呼ぶ）を的確に定義するには、モデリング技法を使うとよい。代表的なモデリング技法には、「PDM（Precedence Diagram Method」と「ADM（Arrow Diagram Method）」の2種類がある（図4）。
|
|
|
| 図4●作業同士の関連をモデル化する際の方法 各作業の順序や依存関係は、図で示すと分かりやすい。 一般によく用いる表記法には、「PDM（Precedence Diagram Method）」と「ADM（Arrow Diagram Method）」がある |
PDMでは長方形の中に作業名を記し、作業間の関係を矢印で表す。作業名とともに、各作業の開始日と完了日、期間、担当者名などを記載しておく。一方のADMでは、作業名を矢印の上に示し、矢印の前後に付加する丸印の「ノード」によって作業間の区切りを表す。矢印にも2種類あり、実線の矢印は作業の流れ、点線の矢印は作業同士の依存関係を表す。2つのモデリング技法は、表現できる内容に大きな違いはないので、好みで選んでも問題はない。
作業期間を見積もる
次に、個々の作業項目の「期間」を見積もる（ステップ5）。ステップ3で個々の作業に要する工数を定義したが、これを要員数で割れば期間を算出できる。例えば、予定工数が12人日の作業に4人の要員を割り当てると「3日」、2人を割り当てると「6日」という具合だ。
ただし、この時点では確保できる要員数や時期などが具体的に分からないケースが多い。また期間の設定は、外部の要因や機器・設備などの制約によっても影響を受ける。したがって、この時点で期間を確定することは難しいので、後ですべてのワークパッケージを対象に再度見直して調整することを前提に暫定的な期間を設定しておく。
ガントチャートを作成する
作業ごとの期間を設定したら、次に各作業の「開始予定日」と「終了予定日」を決定し、日付入りのスケジュール表を作成する（ステップ6）。日付入りのスケジュール表は、「ガントチャート（バーチャートとも呼ぶ）」で表記することが多い（図5）。ガントチャートでは、縦軸に作業名、横軸に経過期間（日・週・月など）をとり、個々の作業の開始から終了までを1本の線や棒（バー）で表す。作業同士の依存関係は矢印で示す。
|
|
|
| 図5●作業日程を示したガントチャートの例 ガントチャートは、横軸に日程をとり、縦軸に作業名を明記し、作業の開始と終了を線（あるいは帯）で示す＊。先にWBSで定義した小項目の作業について、順序や依存関係を考慮しながら開始日と終了日を設定する |
「営業日」にしか作業を実施しない場合でも、休日も含めてバーを引く。例えば、ある作業の期間が「7日」で土日を挟む場合、ガントチャート上にはその土日を含めた「9日」分の長さのバーを引く。
スケジュール表に示した各作業には、作業ごとの完了基準である「マイルストーン」を設定することも忘れてはならない。マイルストーンは、作業を進めるうえで節目となる重要なポイントやイベントを示す。図5の例では、「業務フロー設計」という作業に、「レビュー」というマイルストーンを設定している。プロジェクトの実施段階では、作業が完了した時点で「▽」を「▼」にするなど、進ちょくが一目で分かるように工夫する＊5。
作成したスケジュール表は、大日程計画の素案（叩き台）と位置づける。大切なのは、納期を意識しすぎて、無理なスケジュールになっていないかどうかを確認することである。素案の段階では、仮に納期に納まらなくても、実現可能なスケジュールを立てればよい。
また、スケジュール表を作成すると、プロジェクト全体の期間が見えてくる。プロジェクトは通常、複数の作業の流れ（経路）で構成されるが、これらの経路のうち総期間の決定に最も大きな影響を与える経路を「クリティカルパス」と呼ぶ。例えば合計10日かかる作業A～Cと、合計8日かかる作業D～Fを並行に実施する場合、必ずしも合計期間の長い作業A～Cがクリティカルパスになるわけではない。作業Cが作業Fの成果物を受け取ってからしか実施できないとすれば、作業D～Fがクリティカルパスとなる。この段階で、どの経路がクリティカルパスなのかを見極めておくことは極めて重要だ。
EVMの「PV」で現実性を評価
最後に、納期を含む様々な制約条件を考慮してスケジュール表を見直し、現実的で、しかもステークホルダーが合意できる状態にまで持っていく。これがステップ7だ。
特に「人的資源の配分は適切か」、「期間ごとの作業負荷のバランスはどうか」といったことに重点を置いてチェックする。そのためには、各作業の工数を月別に積み上げてバランスを見る「工数山積み表（グラフ）」などを用いるとよい。
進ちょく管理手法としてEVMを用いる場合は、時間軸に沿って各作業の予定工数「PV（Planned Value）」を積み上げた折れ線グラフの形状を見ることによっても、作業負荷のバランスをチェックできる（第3部を参照）。PVは通常、S字カーブを描く。このため、PVがなだらかなS字を描いていない場合は、特定の時期に作業が集中している可能性があるので、計画を見直す必要がある。
以上の検討を経て、スケジュール表の実現性を確保し、ステークホルダーの合意がとれた時点で、これを「大日程計画」とする。
以上、大日程計画を中心に作業内容の定義とスケジュール作成の勘どころについて解説してきた。中日程計画と小日程計画も、基本的な作成作業の手順は同じである。大日程計画をもとに、対象となるサブシステムや工程、チームや個人ごとに、中日程計画と小日程計画を作成していく。
現実には、プロジェクトのキックオフミーティングや、次の工程が始まる直前になっても、こうした日程計画ができていないケースがある。「納期を遵守するためには、まず実現性の高い計画作りから」。これを心がけて作業計画とスケジュール作成を実践してほしい。