システム開発で重要な役割を果たします。

システム開発の問題は、最初にスケジュールの問題として見える事が多いので、スケジュール管理がプロジェクトの成功を左右すると言っても過言ではありません。

 

スケジュールの作成

スケジュールについては大きく以下の３つに分けて作成すると良いと言われています。
・大工程スケジュール
・中工程スケジュール
・詳細スケジュール

なぜ３種類のスケジュールが必要かと言うと、プロジェクトを管理する立場によって見るスケジュールが変わっていくからです。

経営層がスケジュールをチェックする時、各担当のスケジュールが書かれているスケジュール表を見ても、全体感が掴めません。
大きなプロジェクトになると、詳細スケジュールを全て書き出すとA3用紙が数十ページ必要になります。

そんな中でプロジェクトの全体感を掴もうとするのは非常に困難です。

そこで、報告する単位にスケジュールを分けて作成していきます。

概ね以下のような目的で作成する事になります。

大工程スケジュール：経営者向け
中工程スケジュール：プロジェクトマネージャー向け
詳細スケジュール：プロジェクトチームリーダー、担当者向け

 

大工程スケジュール

大工程スケジュールは経営者向けのスケジュールになります。

従って細かいタスクよりも各開発工程の日程と、プロジェクトの大きなイベントなどを網羅していきます。

記載するポイントは、以下のようになります。

各工程の期間

各工程とは、「基本設計〜システムリリース」までの工程を言います。
スケジュールに表す項目は以下の項目になります。
・各工程がいつから開始されていつ完了するのかを線で記載します。
・テスト工程以降は準備期間も表現します。
・各工程の日数をどれくらい使うのか
・各工程は重複する期間があるのかないのか。

プロジェクトのイベント

プロジェクトに関わるイベントは期間で表現できるものなら開始と終了を線で表現しますが、経営審議など1日で完了するものは点で表現します。

記載する項目は
・各種レビュー（基本設計書レビューなど）
・各種審議（リリース判定審議など）
・リリースリハーサル、リリース日など
で、経営者に意識して欲しいイベントを記載します。

大工程スケジュールはプロジェクトの開始時に作成し、基本的にはプロジェクト終了まで更新する事はありません。
しかし、大工程スケジュールが変更になるような事態が発生すると言う事は、
・経営層への報告
・経営判断
が必要になると言う事です。

 

中工程スケジュール

中工程スケジュールは、プロジェクトマネージャーが管理するために使用するスケジュールです。

大工程スケジュールを基に、各工程を詳細化して作成します。

工程の詳細化と言っても、全てのタスクを追加する必要はありません。

例えば基本設計のスケジュールを作成する場合、
・影響調査
・設計作業
・内部レビュー
・外部レビュー
を表現します。
プロジェクトは複数のチームに別れて進む事が多いので、上記のタスクはチーム毎に分けて作成します。

チーム毎にスケジュールを分ける理由は、チーム単位にスケジュールの進捗を把握するためです。

プロジェクトが進んでいくと、前倒しで進捗するチームと遅れが発生するチームが出てきます。
全てのチームを一つの進捗線で表現すると、遅れが見えにくくなりますし、遅れが発生した時にどこに問題があるのかが見えなくなります。

そこで、チーム単位に進捗線を分けてスケジュールを作成します。

 

詳細スケジュール

詳細スケジュールはプロジェクトで必要なタスクを全て記載します。WBS（Work Breakdown Schedule）と呼ばれていますが、全てのタスクを記載するので、進捗線の数が非常に多くなりますし、多くの人が更新する事になるので、チーム単位に作成するのが良いでしょう。

作成するポイントは、一つの進捗線の最長を３日以内にする事です。

詳細スケジュールはプロジェクトの進捗遅れを検知する為の重要な役割を持っています。
例えば１０日と言う長い進捗線のスケジュールでは、タスクの進捗がほぼゼロと判明した場合、既に１０日遅れになってしまいます。
進捗線の長さを３日にしていれば、上記の問題が発覚しても３日の遅れで済みます。

 

スケジュールの管理

スケジュールを作成したら、スケジュールの管理を行います。
（どんなに素晴らしいスケジュールを作成しても管理できなければただの紙です）

スケジュール管理は、詳細スケジュールの確認になります。
プロジェクトマネージャーは詳細スケジュールまで確認する機会は少ないですが、チームリーダーから詳細スケジュールの内容をヒアリングする事で進捗状況を把握します。
（プロジェクトで決められたスケジュールが詳細まで守られているかをヒアリングする）

スケジュール通りにプロジェクトが進めば問題ありませんが、遅れが発生した場合、
・スケジュールに無理がなかったか？
・生産性は想定通りだったか？
・想定していない（詳細スケジュールにない）タスクが発生していないか？
・前工程で作成した設計書、プログラムは想定通りの品質か？

などをヒアリングし、対策を行います。
対策を行った後は、速やかにリスケジュールを行います。

プロジェクトによってはリスケジュールを行うことを嫌うこともあるようですが、遅れが発生しているスケジュールを管理するのは難易度が高くなるので、必ずリスケジュールを行います。

ここで気をつけなければならないのは、
・思ったより生産性が低い
・前工程の品質が低い
などが原因の場合、今後のスケジュールも延ばすことを忘れてはいけません。

今までの進捗が想定より遅れると言う事は、今後も確実に遅れが発生します。
想定より３割時間がかかっている場合は、今後も３割増しのスケジュールを設定する必要があります。
できる限り全体のスケジュールを延ばしたくないと言う気持ちは理解できますが、今後は生産性が向上すると言うなら、納得できる明確な理由が必要です。
また、
・生産性が戻っているか
・品質低下は解決しているか
を定期的にチェックすることをタスクとして追加する必要があります。