ITプロジェクトの実践～タイム・マネジメント～ 第2回 スケジュールを作ってみよう｜建設情報クリップ

 

 

---

前月号ではWBS（Work Breakdown Structure）のメリットや作成方法を紹介した。
WBSを作成することはプロジェクトを成功させるために必須ではあるが、十分条件ではない。
WBSをもとに綿密な計画を立てることが重要だ。
今回は、タイム・マネジメントの知識エリアからスケジューリング技法を取り上げ、
WBSをもとに現実的なスケジュールを立てる方法を解説する。
 
 

前月号でWBSのメリットや作成方法を紹介しました。
よいWBSを作成し、
「目的を達成するために必要な作業（Work）を漏れなく分解（Breakdown）し、構造化（Structure）して見える化する」ことは、
プロジェクトを成功させるための必須条件です。
しかし、これだけでは、まだ不十分です。
図-1に示すようにWBSを作っただけだとプロジェクト計画のしっかりした基礎ができたに過ぎず、
これをもとにスケジュール表まで展開して初めて効果的なマネジメントができる状態になります。
 

 
プロジェクト開始後、プロジェクトマネージャがもっともよく使い、かつ重要だと思っているドキュメントの1つは、
まちがいなくスケジュール表です。
スケジュール表をもとに日々の進捗を把握し、問題があれば対処します。
もしスケジュール表がきちんと作られておらず、問題の把握が遅れたり、対応が場当たり的になったりすると
納期遅延や大きな混乱に結びつきかねません。
こうした事態に陥らないよう実現性の高いスケジュールを立てるための勘所を身に付けましょう。
 
スケジュール作成は、プロジェクトマネジメント（PM）の知識体系「PMBOKⓇガイド」では
タイム・マネジメントの知識エリアに記述されています。
タイム・マネジメントの知識エリアは、
プロジェクトで定めた成果物を作成するための作業を定められた期間に完了させるための知識をまとめています。
 
 

もう一度、図-1を見てみましょう。
右側にスケジュール表の例を示しています。
「ガントチャート」と呼ばれる表記方法で書いています。
100年ほど前、米国のヘンリー・ガント氏によって考案されたためこの名がついています。
「工程表」あるいは単に「線表」と呼ばれることもあります。
縦軸に作業項目、横軸に日時を置き、作業期間を横棒で表します。
スケジュール表としては、もっともよく使われる記法です。
プロジェクトの日々の管理にはこのガントチャートを使いますが、いきなりこの形で記述していくわけではありません。
基になるのはWBSです。
整合性の取れた、実現性の高いスケジュールは、WBSからいくつかのステップを経て作成していきます。
では、どのようにして作成していくか、図-2をもとに順に見ていきましょう。
 

 

ここで洗い出すマイルストーンは、納期、機器の搬入日や利用者が参加するテスト日など、
これを守れないとプロジェクト外にも影響を与えるようなイベントを指します。
これに対し、全体レビューなど、成果物の品質を合わせていくためにプロジェクト内で設定するマイルストーンは、
「（6）ガントチャートの作成」の段階で行います。
 

ひと口にスケジュール表と言っても、
プロジェクト全体のスケジュールを示す「大日程計画（マスタースケジュール）」、
チーム単位のスケジュールを示す「中日程計画」、
個人レベルのスケジュールを示す「小日程計画」があります。
ここではどのようなスケジュール表を作るか決め、必要に応じWBSをさらに分解して作業を洗い出します。
 
プロジェクトの規模が大きくなると1枚のスケジュール表ですべてを表現するのは無理がありますし、管理も煩雑になります。
また、発注側は、管理するのにベンダー側のこと細かい作業まで知る必要はありませんので、
通常、大日程計画レベルの進捗状況をベンダーと共有します。
もちろん、小規模プロジェクトで、すべての種類のスケジュール表を作る必要はありません。
 
スケジュール表に記述する作業項目は、WBSに記述した作業項目を引きつがなければなりません。
これにより計画全体の整合性を保ちます。
ただ、WBSに記述している作業の粒度はコスト管理を意識して決めているケースが多くあります。
作業の粒度が中日程計画や小日程計画を作成するには、まだ粗いということであれば、さらに作業を分解します。
 

各作業に要求されるスキルを考慮して、体制表から担当者を割り当てていきます。
図-1（右側）の「作業」の隣にある「担当」欄にメンバーの名前を書き入れます。
メンバーアサインには、「RAM （Responsibility Assignment Matrix）表」を用います。
RAM表は、「責任分担マトリクス」「作業分担表」とも呼ばれ、マトリクス型のチャートで作業とメンバーの関係を図示します。
WBSとの親和性も高いのでお勧めです。
RAM表の記述方法にはいくつかのバリエーションがあります。
代表的な記述方法は、「○まる付けチャート」（図-3①）と「RACI（レイシー）チャート」（図-3②）です。
 

 
両チャートとも、縦軸にWBSの作業項目、横軸に組織やメンバーを記述します。
○付けチャートは、作業の実行責任を持つメンバーに○印を付けていきます。
会社間で責任範囲を決める場合や少人数のチームで役割分担を決める場合に適しています。
RACIチャートは、○印の代わりに記号を入れてメンバーの役割を決めていきます。
具体的に設定できる役割は、実行責任（Responsible）、説明責任（Accountable）、相談対応（Consult）、情報提供（Inform）です。
○付けチャートより細かい設定ができますので、チーム内のメンバーの役割や権限を詳細に設定したい場合に向いています。
 

各作業の作業期間を設定するには、まず各作業の作業工数を見積もる必要があります。
作業工数は、人月や人日といった単位で表します。
1人月は、1人×1カ月分の作業量のことです。
各作業の工数は、成果物の内容や過去の経験などに基づいて見積もります。
これぐらいと検討がつく粒度まで作業を分解することが理想ですが、計画段階ではなかなかそうもいきません。
 
こうしたときに役に立つ、よく知られた方法が三点見積もりです。
最可能値（m）、楽観値（o）、悲観値（p）の三点を設定し、そのバラツキから期待値（μ）を計算します。
期待値は、「（o＋4m＋p）÷6」の計算式で求めます。
ある作業について
「5人日ぐらいだと思うけれども、上手くいけば3人日で終わるかもしれないし、下手をすれば12人日かかるかもしれない」
というケースでは、最可能値は5人日、楽観値は3人日、悲観値は12人日として三点見積もりの計算式に当てはめ、
期待値5.8人日、約6人日と求めます。
 
作業工数が設定できれば、これを要員数で割って作業期間を算出します。
予定工数が6人日の作業に3人の要員を割り当てると「2日」、2人を割り当てると「3日」という形です。
 

WBSに記された作業は、おおむね実施する順に並んでいますが、厳密ではありません。
作業の中には、「作業Bは作業Aの成果物を使うので作業Aが終わらないと着手できない」というものもありますし、
「作業Cと作業Dは並行して作業できる」というものもあります。
こうした作業同士の依存関係を意識してスケジュールを作らないと、
いざ作業に着手しようという段になって、作業に着手できない、
あるいは不完全な入力情報による手戻りリスクが発生するという事態を招きかねません。
ただ、大きなプロジェクトになると実行順序の整理は、そう簡単ではありません。
このとき助けになるのがネットワーク図です。
 

 
図-4は「2.2 提案内容の検討」の実行順序をネットワーク図を用いて整理したものです。
先行作業を分析した後、矢印で順序関係を表していきます。
色をつけたボックス（2.2.1→2.2.6→2.2.4→2.2.5）がクリティカルパスです。
クリティカルパスとは、プロジェクトの期間を決定する作業の流れのことです。
その作業に要する日数が書かれていますが、すべての経路の日数を計算して、もっとも長い日数の経路がクリティカルパスとなります。
クリティカルパス上の作業が遅れると、即、プロジェクト全体の遅延となりますので、
スケジュール作成時には必ずクリティカルパスを押さえておかなければなりません。
 

作業ごとの期間を設定したら,次に各作業の「開始予定日」と「終了予定日」を決定し、ガントチャートを作成します。
ガントチャートを作成する場合、営業日と休日を意識する必要があります。
土日や祝日はもちろん、ゴールデンウィークや年末年始など作業ができない期間を外して設定して、
開始予定日、終了予定日を決めていきます（図-5）。
 

 
また作業ごとの完了基準であるプロジェクト内の「マイルストーン」を設定することも忘れてはいけません。
マイルストーンは、作業を進めるうえで節目となる重要なポイントやイベントを示します。
作成したスケジュール表は、あくまでも素案（叩き台）です。
素案の段階では、仮に納期に納まらなくても、まずは実現可能なスケジュールを立てることに重点をおきます。
 

ガントチャートができあがったら納期など様々な制約条件を考慮してスケジュール表を見直します。
このときに皆さんがもっとも困るのが「このスケジュールでは納期を守れない」という問題に直面したときではないでしょうか。
期間を短縮する方法は大きく4つありますが、
納期を延ばせない限り、時間を短縮するためには何かを犠牲にしなければなりません。
 
1つ目は、残業や休日作業でカバーする方法です。
安易に行ってはいけない方法であることは言うまでもありません。
常態化すると生産性や士気が低下しますし、何よりも優先すべきメンバーの心や体に悪影響を及ぼしかねません。
もちろん休日にしかできない作業もありますが、
作業量確保のためだけに計画段階から休日出勤を当て込むようなことは避けなければなりません。
2つ目は、スコープを縮小する方法です。
成果物の機能を落としたり、作業を削ることで、作業量と期間を短縮します。
これにより品質や顧客満足度が低下するといった影響が考えられます。
 
3つ目と4つ目は、プロジェクトマネジメントでよく使われる期間短縮の方法です。
 
3つ目のファストトラッキング（図-6）は、作業を並行化する方法です。
先行する作業の終了を待たずに見切り発車しますので、手戻りのリスクを覚悟で作業を前倒しすることになります。
 

 
4つ目は,クラッシング（図-7）という方法です。
 

 
期間を短縮したい作業の要員を追加して対応するというものです。
例えば、1人で2日かかる作業を2人にすることで1日に短縮します。
なお、クラッシングにも注意が必要です。
1人で実施する予定の作業を2人にしたら、工数はそのままで単純に期間が半減すると考えがちですが、
実際にはそうならないケースも少なくありません。
要員が増えれば、マネジメントやコミュニケーションのコストが増えるからです。
特にそれまでチームに参加していなかったメンバーを外部から追加すると、
作業の理解に要する工数や準備に要する工数が加わります。
 
以上の4つの方法は一長一短がありどれがよいとはいえません。
時間は取り戻すことのできない貴重なリソース（資源）です。
繰り返しになりますが、時間を得るには何らかの犠牲が伴います。
コツとしてはWBSのできるだけ下位のレベルで期間短縮を検討することです。
そうするとリスクも限定的で問題が発生したときの影響も小さくできます。
 
また、メンバーアサインの観点からもチェックし、実現可能性を検証しておく必要があります。
観点の例としては、
「同一人物が同時期に複数の作業にアサインされていないか」、
「特定のメンバーに作業が偏りすぎていないか」、
「クリティカルパス上にある作業には信頼できるメンバーが割り当てられているか」などです。
各メンバーになったつもりで、いつ、どういう作業をするのか、スケジュール表に従ってトレースしてみるとよいでしょう。
 
 

冒頭に記したとおり、プロジェクト開始後、プロジェクトマネージャがもっともよく使うドキュメントの1つはスケジュール表です。
スケジュール表をもとに日々の進捗を把握し、問題があれば対処します。
図-8は、6月12日終了時点の進捗を記述した例です。
終了した作業の横棒を塗りつぶし、イナズマ線で結んでいきます。
 

 
では、1つの作業（1本の横棒）の進捗状況はどのように測ればよいでしょうか？
これにもいくつかの方法があります。
1つは、着手と完了しかみない「固定比率計上法」です。
「0：100ルール」とか「20：80ルール」などがあります。
「0：100ルール」は、着手から途中段階までは評価せず進捗0％で、完了して始めて100％にする方法です。
「20：80ルール」は、着手で20％、途中段階は評価せず、完了で100％にします。
 
2つ目は、成果物の完成量に応じて進捗を測る「加重比率計上法」です。
例えば、ある作業の成果物の量を設計書100ページと見積もっておき、20ページまで完成したから進捗は20％とするようなやり方です。
これらは、それぞれの作業の性質を考慮して使い分けます。
比較的短い作業は、固定比率計上法を使い、成果物がはっきりしていて、ある程度の期間を要する作業は、加重比率計上法を使います。
また、両方のやり方を組み合わせて使う方法もあります。
着手で20％、80％までは完成量に応じて測り、レビュー完了で100％にするといった方法です。
各作業の進捗の測り方は予め決めておき、メンバーに周知しておきます。
 
 
今回は、スケジュール作成を取り上げ、作成手順や調整の方法について紹介しました。
WBS、スケジューリング技術ともプロジェクトマネジメントの基本的なテクニックです。
しっかりマスターしましょう。
 
 
〔編注〕
プロジェクトマネジメントにつきましては、「積算資料」2013年10～12月号に「プロジェクトマネジメントの薦め ～ ITプロジェクトを成功に導く～」も掲載しております。
 
第1回：なぜプロジェクトマネジメントが大事なのか？《前編》
第1回：なぜプロジェクトマネジメントが大事なのか？《後編》
第2回：プロジェクトマネジメントの知識体系《前編》
第2回：プロジェクトマネジメントの知識体系《後編》
最終回：プロジェクトマネジメント・オフィス《前編》
最終回：プロジェクトマネジメント・オフィス《後編》
 
 
 

［1］PMI（Project Management Institute）「プロジェクトマネジメント知識体系ガイド（PMBOKⓇガイド） 第5版 日本語版」、
　　 PMI、2013
［2］初田賢司「システム開発のためのWBSの作り方」、日経BP社、2012
 
 
 
ITプロジェクトの実践～スコープ・マネジメント～ 第1回 WBSを作ってみよう
 
 
 
【出典】

---

月刊積算資料2014年8月号

 
 

最終更新日：2014-11-04

 

ピックアップ電子カタログ