システム開発(開発契約)

 前回までにRFP発行ベンダー選定までの説明をしました。

  私自身、RFPとまではいきませんが、システム計画書を策定して何社かのベンダーに見積依頼したことが何回かあります。その際、実績があり仕事を取りにこようとする会社は、必ず経験者を同席させるか知識のある営業を表に出してきます。また、こちらが依頼した以上のものを持ってくる場合が多いです。提示される予算はこちらの希望枠内か+α程度ですから、こちらもその気になる場合が多いです。逆に、実績獲得のために低価格で提案してくるところもありますが、根拠をきちんと示さない社はあとで必ず追加予算を要求してくるものです。

 中小企業では、多くの場合、機能を満たせばよく、他社との差異化を求めるシステム開発は少ないものです。よって、パッケージをベースにいくつかのカスタマイズ、アドオンを行うことと業務手順を若干見直しすることで目的を達成するのですが、そこまで踏み込んだ提案をするベンダーは稀です。
 

つまり、言われた機能をそっくりそのまま実現するためには幾らかかりますと、自分たちの実力のレベルで必要な金額を提示してきます。例えば、経験がないために開発期間がかかるにもかかわらず平気で通常単価を提示したり、自社に開発ソフトがないからと、そのまま費用に転記してくる(実際には上乗せ価格)社もあります。ライセンスの関係上、仕方のないものもあるでしょうが、自社経費でまかなうべきものもあるはずです。こちらが分からないのに付け込み、悪質なことをやっているケースを何回も見てきました。
 もちろん、良心的な提案をしてくれる企業もあります。しかし、「知らないやつが悪い」と、相場がないことを錦の御旗にしている感があります。これが結局、システム開発だけでなくIT業界自体の信頼をなくしす原因でしょう。私のところにシステム開発で相談に来る多くの企業が、この見積は本当に正しいのだろうかと不安に思い、不信感をあらわにするのです。

 では、企業がシステム開発で失敗しないためにはどうすればよいでしょう。それが契約です。契約の雛形は、RFP関連サイトのリンク集で紹介済みですから参考にしていただくとし、今回はポイントをお話します。

 まずは納品物。ソフトそのものだけでなく、マニュアルや仕様書、プログラムソースなどです。知的財産権との兼ね合いがありますので、必ず契約時に決めてください。また、納品形態は、実機(実際に仕事に使うパソコン)にインストールして動作確認までというのが普通ですが、中にはインストールCDを渡して終わりという困ったベンダーもいます。最終的にどういう状態を望むかまでを明確にしておきましょう。

 次に再委託契約です。小さなベンダーではあまりありませんが、大きなベンダーでは協力会社に開発自体を振り、自社では管理のみというところもあります。再委託は原則禁止とし、パッケージソフトのようにその会社でないと中身が見られない等のやむをえない場合のみにします。これを許してしまうと責任の所在が不明瞭になるだけでなく、「言った言わない」で開発に支障をきた
こと間違いなしです。(以前、痛い目にあいました。)

 次に検収と不具合による対応に関してです。建築では10年の瑕疵期間が常識ですが、ITの世界でそのような長期間はありえません。数ヶ月からせいぜい1年程度です。また、検収も一通りの操作ができればOKというケースが多いです。たとえば、年に1回しか行わないがとても重要な操作がある場合、本番同様のデータで検収するのがベストですが、現実には非常に困難です。そういったときは、その箇所だけ部分検収を可能にするなど、契約時に詳細に決めておくのがよいでしょう。不具合についても、システムなのかOSなのか他のソフトなのかと、切り分けが難しいものもありますので、保守に自信がなければこの点を踏まえた保守契約をお勧めします。

 最後に守秘義務で、通常、NDA(機密保持契約)を結びます。これの雛形は、インターネットで検索するとサンプルがいくつか出てきますので、参考にしてください。内容をこと細かに決めるのでなく、不利益にならないように釘をさす
程度でOKです。

 契約は、開発の際に守るべき最低必要のルールを決めるものです。ベンダーによっては予め自社形式で作ってくる場合もありますが、小さい字で読みにくい場合がほとんどです。その際「まあいいか、どうせわからないだろう」と思わず、拡大コピーしてでも内容をきちんと理解してください。不明な点は質問し、納得したでサインすることが、企業とベンダー双方の利益になるはずです。ベンダー側からの契約書であれば、事 前ににトラブルになりそうな箇所を説明してくれるようならば信頼度があがります。(説明してくれないところも少なくないですが)

 建設業でも仕様書や契約書、図面の疑問点を理解し、発注者、設計者、施工者が相互理解のうえ仕事をできるものはいい仕事になります。システム開発も同様です。大変だと思いますが、手間隙をかけるのがよいのです。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする