はじめて
本記事では、スケジュール管理の基本である線表から、「やばい線表」というものについて記載しております。ご自身が線表を引かれる際だけでなく、ベンダーから受領した線表においてもこのような状況になっていないかを確認してください。またチェック観点も記載しておりますので、ベンダーの方に指摘されるのも良いかと思います。
最終納期しか見てないパターン
キックオフにおいて上記のような線表が出てくることはよくあります。特にRFPにおいて、納期を強く記載した場合、とりあえず最終納期にお尻を合わせる形で、線表をひかれることはよくあります。しかし、実際プロジェクトを進めるにあたり、上記のように要件定義も決めていない段階から総合試験までの計画を立てることは簡単ではありません。
また要件定義はシステム開発側（ベンダー）とユーザ企業の合意事項です。要件定義が決まらないとシステムのボリュームは決まらず、上記のような線を引くことは難しいでしょう。また、各工程がきっちり1か月ずつというのも危険臭がします。仮線表であることを強調されていれば良いのですが、そうでなければ非常に危険です。
確認ポイント
上記のような線表を出された場合は、まず次の内容を確認しましょう。
- 開発人員は最大どの程度まで増強できるのか？（人員投入による期間短縮の可能性）
- どこかの工程でスケジュール遅延が発生した場合のバックアップ方法（W字モデルの対応などに移行するのか？）
基本的に、上記線表がそのまま維持されることは稀です。最後喫緊の状態になれば、コスト増加だけでなく、”スケジュールを伸ばす”か、”要件を落とす（品質を落とす）”かの選択をユーザ企業は迫られます。そのような選択を迫られた際に、すぐに判断できるよう、事前に決裁者などに相談しておくことが良いでしょう。
レビュー期間が考慮されていないパターン
絵は先ほどと同じですが、違う観点で記載しています。
先ほどのような、納期しか意識していない線表でも、”さらに危険なのが”こちらのユーザ企業がレビューが考慮されていない線表です。システム開発は特性として”受注生産”となります。オーダーメイドのウェディングドレスを注文する場合に、「仮縫い」や「試着」、「仕立て直し」を行わず、一発で当初予定の内容を作り上げることはできるでしょうか？仮にできたとして、それが新婦が真に喜ぶものになるでしょうか？システムも同じです。開発途中にビジネス要件が変更するなど、どうしても追加要望が発生するものです（大小あれ、経験上100%発生します）。これも含め、最終的な成果としての製品を考慮した線表である必要があります。
そのため、各工程において以下を考え、レビュー期間を設けておくのが良いと考えます。
- レビュー期間はどれくらい必要か？
- 誰がレビューするのか？
- 指摘事項・不具合はどれくらい見込んだらよいか？
- 見込みが外れたらどうするか？
よくシステム開発をしていると、ベンダー側から「レビュー後の反映に想定以上に手間取ったため、進捗遅延している」と報告されることがあります。そういったプロジェクトではそもそも計画時点でレビュー期間がなかったり、レビュー後の修正期間が設けられていないものです。（★レビュー！とイベントの点が打たれ、変更期間は考慮されないというケースもよく見ます。）
プロジェクト開始時は、不透明なことが多く、線表をしっかり引くのが難しいのはその通りです。そのため、要件定義工程や、プロジェクト開始後1~2か月は仮線表で引っ張り、その後再度プロジェクトメンバーでスケジュールを再合意するなどといった形式にするのが良いでしょう。発注者の立場からすると、発注時点で全ての予測をベンダーに強いるのではなく、こういった猶予期間を設けてプロジェクト進行することが望ましいと考えます。（決裁がとりにくいのはわかりますが、最終的にはそれが一番幸せになります）
確認ポイント
上記のような線表が出てきた場合は、以下を確認しましょう。
- レビューが設けられていないようだが、どのような対応を想定しているか？
- 仮にレビューで指摘が多く発生した場合は、どのような対応を想定しているか？
- レビューでの想定指摘件数は、何件程度を想定しているか？
レビューが考慮されていないプロジェクトも多くが遅延します。このような線が出てきた場合、ユーザ企業としてベンダーへリスク指摘をしたうえで、再度線表の作成を依頼し、並行して社内にてリスク報告を上げるのが良いでしょう。（ベンダーさんが言うてるから大丈夫だろう、とは思わないほうが良いです）
おわりに
こちらでは「やばい線表」を記載しました。開発を依頼したからと言って油断せず、ユーザ企業としてしっかり目を光らせておくことで、早期に遅延の予兆を発見し対処することができるようになります。
コメント