青山システムコンサルティングのコンサルティングコラムです

TEL:03-3513-7830|お問い合わせ

コラムカテゴリー:

プロジェクトスケジュールは、プロジェクト終了までの予定が記載されており、プロジェクトを進めていくうえで無くてはならないものです。
作成されたプロジェクトスケジュールを見ると、そのプロジェクトに関する様々なことが読み取れます。
中にはプロジェクトのリスクとなる点も読み取れる場合があります。
どのようなリスクが、どのような形で、プロジェクトスケジュールに現れるのか、一例をお伝えします。

簡略版になりますが、あるサーバリプレースプロジェクトの体制図とプロジェクトスケジュールを下記に記載します。
このプロジェクトスケジュールから、どのようなリスクが読み取れるでしょうか。

体制図
プロジェクトスケジュール
上部に全体のマイルストーンと全体スケジュールを記載。
下部に基盤・アプリそれぞれの担当範囲におけるスケジュールを記載。

上記のプロジェクトスケジュールからは、以下の2点が読み取れるとともに、そのプロジェクトのリスクが見えてきます。

上記プロジェクトスケジュールから読み取れる点

  1. ユーザーテスト、リリース予定、データ移行が記載されていない
  2. クリティカルパスが記載されていない

「1. ユーザーテスト、リリース予定、データ移行が記載されていない」場合の注意点

このプロジェクトは、ユーザー視点のタスクが洗い出せていないため注意が必要です。
ベンダの作る全体スケジュールをもとにスケジューリングをしている場合に、このようなスケジュールが出来上がります。

なぜなら、ベンダの作るスケジュールにはユーザーの目線が不足することが多いからです。

このようなスケジュールが作成されている場合は、プロジェクトスケジュールを修正するだけでなく、プロジェクトが進んでいく最中もユーザー視点から、不足しているタスクはないか注意することが大切です。

逆に、ユーザー主体で作る全体スケジュールは開発者の目線が不足している場合があります。

どちらかに依存することなく、協力してスケジューリングすることで、モレのないスケジュールを作成することができます。

「2.クリティカルパスが記載されていない」場合の注意点

プロジェクトスケジュールを見ると、基盤の単体テストが終わる前に、アプリが構築を始めています。
基盤はアプリに影響のある部分を先行して構築しているのですが、それらが明記されていません。

そのため、このプロジェクトは基盤で遅延が発生した場合に、アプリにどのような影響を与えるかをユーザー側で把握できていないことが読み取れます。

このままでは、遅延が発生した際に影響確認が必要となり、遅延を悪化させてしまいます。
タスクの前後関係やクリティカルパスが判明した段階で、スケジュールに明記するようにしましょう。

もし記載事項が多くスケジュールが見づらくなってしまう場合には、「留意事項」などの枠を設けて、線表外に記載するなどの対策が有効です。

最後に

今回は、プロジェクトスケジュールに現れるリスクの一例を紹介いたしました。

当たり前の内容ではありますが、実際に見落とされている事例も少なくありません。

皆さまのプロジェクトにおいても、ぜひ一度スケジュールの見直しをしてみてはいかがでしょうか。

関連サービス

この投稿をシェア

2017年10月23日 (月)

青山システムコンサルティング株式会社

高橋 和大