2022
5/21
ベンダー提案書におけるプロジェクト計画の評価項目は、主に6点あります。
① スケジュール
② 開発手法
③ 移行計画
④ プロジェクトマネージャー
⑤ プロジェクト体制
⑥ ユーザー教育
そのうちの、「① スケジュール」について解説します。
① スケジュールの見どころ
一言でいえば「そのスケジュールで成功するか？」を見ていきます。
各工程の順番と長さ、本番リリースまでの期間を確認します。期間はもちろん短い方が良いのですが、短すぎると「実現性」が一気に落ちてしまいます。
期間が短いということは、ベンダー側が「がんばる」のはもちろんですが、ユーザー側もかなり「がんばる」ことが必要です。この考慮をせずに「短さ」だけで評価してしまうケースが多いのです。いくらベンダーが手厚い体制を整えても、ユーザー側の体制が弱すぎるなら、ユーザー側がボトルネックとなり、遅延してしまいます。
ユーザーの動きが遅いことで、ベンダー側の手厚い体制が「待ち」になります。すなわち、それは「高い人件費」を浪費することになります。その後、必ずベンダー側はスケジュール遅延に伴い、追加費用を要求してきますが、ここで揉めてしまいます。
開発工程でいくと、システム設計・開発・結合テストなどはベンダー主体でできるので、単純に短い方がいい。一方で、要件定義や受入テストなどユーザー主体の工程については、短くしすぎるとユーザー側が対応できなくなります。ユーザー側の体制もふまえて、長さを判断すべきです。
また、現場の「繁忙期」も考慮した上で、妥当かどうかを判断します。
例えば、会計システムを入れようとしているのに決算処理をしている最中に受入テストをかぶせてくるようでは、ベンダーは常識がなく、経験もないと読み取れます。
そのような配慮もできないベンダーは、専門家でも何でもありません。もしプロジェクトを一緒にやったとしても、今後も配慮のない、残念な動きをするはずです。
さらに、パッケージなのに、スクラッチ開発のような線の引き方をしている場合は、大きな問題があります。パッケージは「既に動くシステム」が存在するので、それを動かしながらの「アジャイル開発」や「スパイラル開発」などのスケジュールが組み込まれるべきです。
それが「ウォーターフォール開発」となるなら、それは、もはやパッケージではありません。パッケージの完成度が低いから、カスタマイズを前提としないと動かないのです。
カスタマイズ開発が多くなると、スケジュールは長くなり、費用も高くなります。パッケージの恩恵はまったくありません。
スケジュールにはベンダーの力量がにじみ出る
このように、スケジュールには、ベンダーの実力や経験が反映されています。ベンダーの自信やプライドも乗っかっています。
短いスケジュールであっても、ベンダーが「絶対にできます」と断言するなら、検討する価値はあります。多くの実績に裏付けされた短さであれば「パッケージは短納期」というメリットを体現してくれる可能性は高いでしょう。
（プロジェクト計画の各項目解説）
【提案評価その4】プロジェクト計画「①スケジュール」をどう読み解くか？
【提案評価その4】プロジェクト計画「②開発手法」をどう読み解くか？
【提案評価その4】プロジェクト計画「③移行計画」をどう読み解くか？
【提案評価その4】プロジェクト計画「④プロジェクトマネージャー」をどう読み解くか？
【提案評価その4】プロジェクト計画「⑤プロジェクト体制」をどう読み解くか？
【提案評価その4】プロジェクト計画「⑥ユーザー教育」をどう読み解くか？
