これもよく見受けられるパターンです。半年や1年といった中長期のプロジェクトの場合、商用リリース時に具体的にどのような作業が発生し、どれだけ手間がかかるのか、契約の時点では想定しづらいものです。特に新しい取り組みの場合、これはさらに難しくなるでしょう。
契約も終盤になると、大体シビアな価格交渉に入るので、終盤のリリース作業の内容が“ふんわり”だと、「その部分の支援を削減して、価格を下げましょうか」とベンダーが提案することもあります。
安易にその交渉に乗ると、例えば、商用リリース時の支援が“メールベースのQAと立ち合いが1回だけ”みたいな契約になった場合、本当にそれだけの支援しか受けられなくなるでしょう。もし従来のSIにあるような、ベンダーに任せっきりの考えや体制だと、リリースを主体的に実行できる役割が不在となり、ほとんどのケースで失敗します。
ただ、リリースまでに十分な技術移管がベンダーからユーザーにできていて、ユーザー主体でプロジェクトが運営可能な状態になっていれば、それで十分事足りる場合もあると思います。
従って、商用リリース時の支援を見積もる際は、細かい部分まで話を詰めるべきです。自社にリリース時のガイドラインがある場合は、それに沿って支援してほしいことをできるだけ具体的に挙げ、ベンダーがそれに対して妥当な提案をしているか判断しましょう。仮にガイドラインがなくても、過去の似たプロジェクトを参考にして、どういった支援が必要になるのか想定するとよいです。ベンダー側に標準的なリリース時の支援サービスが用意されているなら、それが妥当かを検討するとよいでしょう。
次回は、同じく導入から運用に移行する段階で、ユーザー、ベンダー両社の認識のズレから起こる失敗例を扱いたいと思います。お楽しみに。
Copyright © ITmedia, Inc. All Rights Reserved.