TOPプロジェクト管理> スケジュール管理

「即活用!企業システムにおけるプロジェクト管理」

第3回:スコープ管理とスケジュール管理

著者:システムインテグレータ  梅田 弘之   2004/12/13
前のページ  1  2   3  次のページ
説明の中で、(I1)や(S2)などの記号が出てきますが、これは第1回で使ったプロジェクト管理状況チェック表のNo.と対応しています。チェック表で明らかになった問題点に対応する部分は、特に注意して読んでみてください。
スケジュール管理

   プロジェクトがスタートしたのに、「まだタスクが不明確なのでスケジュールが引けません」という理由でいつまでもスケジュール表を作成しようとしないPLがいます。また、おおまかなスケジュール表が1回こっきり作成されてそのままになっているという、だらしないプロジェクトもあります(T1)。スケジュール表は作成したけれど、メンバーにそれを遵守するという気持ちが薄く、絵に描いたモチとなっているものもあります。

   夏休みの宿題と同じく、プロジェクトには期限がありますので、きちんと計画しないと最後にしわ寄せがどっと押し寄せます。人間はどうしても最初はのんびりスタートしがちなので、初期段階でスケジュール計画を立て、上流工程の段階からそれをキープしながらプロジェクトを進めることが大切です。


作業の定義、順序、所要時間見積

   PMBOKのスケジュール管理では、「作業の定義」「作業順序の設定」「所要時間の見積」「スケジュール作成」「スケジュール管理」という5つのプロセスが定義されています。作業の定義プロセスでは、WBSなどで洗い出された作業(プロジェクトスコープ)をベースにスケジュール表に記載すべきタスクを定義します。スケジュール管理で重要なのは、実はこのタスクの洗い出しです。全ての作業タスクが記載されていないと後で予定外の追加作業が発生してスケジュール遅延の原因となります(T2)。

   作業順序の設定プロセスでは、定義された作業の順序を決めます。システム開発の場合は、要求分析→基本設計→詳細設計…というような順序になるのは当たり前なのですが、テスト仕様書をどの段階で書くか、操作マニュアルはいつ作成するか、などはプロジェクトによりばらつきがあります。

   所要時間の見積プロセスでは、各作業で必要とする工数と要員数などを勘案して、タスク単位の所要時間を見積ります。総工数=所要期間×要員数という関係になるので、現実的には納期や要員数との調整を図りながらタスクごとの所要期間を算出します。

   スケジュール管理表ではガントチャート法が一般に使われており、PYRAMIDのスケジュール表もガチャートがベースになっています。ガントチャートでは、作業(タスク)が縦の欄となり、作業の順序は線の前後関係、所要時間は線の長さで表されるので、誰でも一目でスケジュールを把握できる利点があります。スケジュール管理手法には、このほかにもPERT(ネットワーク計画法)、CPM(クリティカルパス法)、マイルストーンチャート法、山積み・山崩しなどもありますので、興味のある方は調べてみてください。


スケジュール表の作成方針

   小規模のプロジェクトであればスケジュール表は1枚作成すれば済みますが、規模が大きくなると複数のスケジュール表を作成する必要があります。PYRAMIDでは「総合スケジュール表」(表3)と「機能別スケジュール表」(表4)という2種類のスケジュール表のテンプレートを用意し、表2のような組み合わせで規模に応じて柔軟に使い分けできるようにしています。

   プロジェクト全体のスケジュールを表すものが「総合スケジュール表」で、通常これは1枚に要約します。大規模なシステムの場合は、さらにサブシステム単位に「詳細スケジュール表」を用意します。詳細スケジュール表にはサブシステムにおける作業タスクが記載され、これをベースに進捗把握が行われます。スケジュール管理プロセスで、進捗管理に使うものが「機能別スケジュール表」です。プロジェクト実行段階における実質的な進捗管理は担当者単位に行われますので、タスクを細分化して担当者に割当てた管理表が必要になるのです。

   サブシステム単位に分けなくても良い程度の中規模のプロジェクトの場合は、計画プロセスで使う「総合スケジュール表」と管理プロセスで使う「機能別スケジュール表」の2本だてでもかまいません。また、小規模であれば「機能別スケジュール表」だけで総合スケジュール表を兼ねても良いとしています。

規模 スケジュール表の作成
大規模    「総合スケジュール表」・・・・1枚
+「詳細スケジュール表」・・・・n枚(サブシステムごと)
+「機能別スケジュール表」・・n枚(サブシステムごと)
中規模    「総合スケジュール表」・・・・1枚
+「機能別スケジュール表」・・1枚
小規模    「機能別スケジュール表」・・1枚

表2:PYRAMIDにおけるスケジュール表の使い分け



総合スケジュール表

   表3は、PYRAMIDにおける「総合スケジュール表」のテンプレートです。縦欄にWBSなどで洗い出した作業タスクを漏れなく記入し、横欄をスケジュール期間とするガントチャート方式となっています。横欄のメッシュはプロジェクトの総工程に応じて変更して使います。この例では、10日単位を列の単位としていますが、納期の短いプロジェクトなら日単位、長いプロジェクトなら月単位というように直してください。

   スコープ管理のところでプロジェクトスコープについて説明しましたが、スコープの作業分担もこのチャートで一緒に表しています。ただし、△部分は役割があいまいにならないように別途明確に取り決めておく必要があります。また、この例では予定と実績の両方を記述するフォームとしていますが、サブシステムごとに管理する場合は、総合スケジュール表は予定だけとし、予実管理は詳細スケジュール表だけにすることが多いでしょう。なお、詳細スケジュール表を作成する場合は、サブシステム名を追記してこのテンプレートを使います。


表3:総合スケジュール表(総合スケジュール表Sheet)
(画像をクリックするとEXCELファイルをダウンロードできます。/27KB)



機能別スケジュール表

   表4Aと表4Bは、どちらもPYRAMIDにおける「機能別スケジュール表」のテンプレートです。表4Aは期日管理型、表4Bは矢印管理型のフォームとなっており、どちらを使っても良いことになっています。また、両方を組み合わせたフォームを作成して使っているPLもいます。これらのスケジュール表は、担当者単位で進捗を管理・フォローする目的で使われるもので、一般に「進捗管理表」と呼ばれているスケジュール表もこれに相当します。また、PYRAMIDではMS-Projectなどのツールを使っても良いことになっています。


表4A:機能別スケジュール(期日管理型)
(画像をクリックするとEXCELファイルをダウンロードできます。/35KB)



表4B:機能別スケジュール(矢印管理型)
(画像をクリックするとEXCELファイルをダウンロードできます。/28KB)


   表4Aの様式は、矢印型に比べて横幅に余裕があるので、詳細設計作業とプログラミング作業を一緒に記入できるようになっています。機能単位に工数を見積し、担当者をアサインして開始予定日と終了予定日を記入します。必要な工数は難易度別に自動で簡便計算できるようになっていますが、通常は機能ごとに個別に必要工数を見積ることになります。実績欄はもちろん進捗管理のためにあるのですが、プロジェクトの最後で「プロジェクト完了報告書」を提出する際に、見積精度の向上にも活用されます。

   表4Bの方は、スケジュールの進捗状況を直感的に把握しやすいガントチャート方式の記入様式となっています。表4Aの様式だと設計作業とプログラミング作業を同じシートに書き込めるようになっていますが、表4Bの場合は別々の表で管理することになります。横軸のメッシュは日単位となっており、右端の進捗率で進捗状況を管理します。


進捗管理

   管理プロセスでは、詳細スケジュール表などを用いて進捗管理を行います。スケジュールがタイトで作業に追われていると、進捗確認の時間さえ惜しくなります。その結果、進捗の確認やフォローがおろそかになりやすいので、毎週火曜日とか毎朝10時とか開催時間を決めて短時間の進捗確認ミーティングを行うルールを決め、忙しくても守るようにしましょう(T4)。

   進捗確認により工程の遅れがはっきりした場合は、その分を反映してスケジュール管理表を修正しなければなりません(T3)。実際、回復困難な程度の遅れが発生しているのに、「納期を延ばすわけにはいかない」「増員もあてがない」などと問題を先送りして対策を打たないまま、スケジュール表も直そうとしないプロジェクトがあります。しかし、「がんばれ!」と声を掛けているだけでは管理とはいえませんし、必ずプロジェクトの最後に破綻が来るのです。

   PLが進捗の報告を受ける際に気をつけて欲しいのは、できるだけ現場、現物、数値で管理することです(T5)。通常、プロジェクトメンバーはなんとか自分の遅れをリカバリーしたいと一生懸命なので、遅れを少なめに報告してしまいます。また、プロジェクトリーダー自身も、「遅れているけど取り返します」という言葉の方が都合が良いので、ついつい甘い報告に対してメスを入れずに済ましてしまいます。メンバーや協力会社の報告に依存した管理だと、遅れが隠匿されてしまうことになり、やはり最後に破綻します。現場でアウトプットの現物を見せてもらう、それを数値で管理する、といった客観的な進捗管理が求められるのです。

前のページ  1  2   3  次のページ



著者プロフィール
株式会社システムインテグレータ  梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。 常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。 国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。


INDEX
第3回:スコープ管理とスケジュール管理
  スコープ管理
スケジュール管理
  まとめ