発注とは？/ ディック
[ 252] ＠IT情報マネジメント：システム発注で後悔しない契約書のチェックポイント 1/2
[引用サイト] http://www.atmarkit.co.jp/fbiz/cinvest/opinion/basic/07/01.html
|
システム構築では契約絡みのトラブルも多い。原因の主は、委託側の「目的の不明確、要件の不明確、仕様の不明確」と、受託側の「勝手な思い込み、勘違い、理解不足」などが入り乱れたコミュニケーション・ミスによるものだ。意図したシステムができなかったときに「いった、いわない」の水掛け論に終始して無駄な労力を使わないように、契約書にはしっかりと目を通しておきたい。 新しいハードウェアに新しいソフトウェアを搭載してシステム一式を納品してもらう場合は単純である。ところが、開発マシンと本番マシンが異なり、すでに既存のシステムが稼働している本番マシンに、新たなソフトウェアを導入したり更新したりする場合が問題となる。 この場合の納品形態は、以下のようなケースがある。どれにするかは、自社の力量とコストをてんびんに掛けて選択しなければならない。さもないと、思ってもいなかった追加の出費が必要になる。 業者は、ソフトウェア一式をCD-ROMなどで納品し、テストマシンへの導入および本番マシンへの移行は自社で行う。このケースでは、業者に支払う導入・移行作業費用が不要になるとともに、システムの動作環境を自社でしっかり押さえることができる。 業者は、ソフトウェア一式をCD-ROMなどで納品するとともにテストマシンへの導入および簡単な動作確認まで行う。本番マシンへの移行は自社で行う。このケースでは業者側に現地作業が発生するため、導入作業費用と出張旅費が発生する。稼働環境について詳しくない場合テストマシンでの立ち上げに手間取ることがない。一方、本番マシン移行時にスムーズに作業できるよう、環境設定などを業者に十分確認しておく必要がある。 業者は、ソフトウェア一式をCD-ROMなどで納品するとともに本番マシンへの導入および簡単な動作確認まで行う。このケースでも業者側に現地作業が発生するため、導入および移行作業費用と出張旅費が発生する。多地点や遠隔地への導入作業となると出張旅費が膨大になる。また、本番マシンへの導入・移行作業は、既存システムがすでに稼働している場合、休日対応するとなると、さらに費用がアップする。このケースでは、本番マシンでの立ち上げまで、業者に任せられるので楽ではある。しかし、環境設定などを十分把握しておかないと、いざトラブルになったときに自社では手も足も出ないという事態に陥る危険がある。◇ システムの納品物として、ハードウェア／ソフトウェアのほかに忘れてはならないドキュメント（仕様書など）がある。しかし、このドキュメントには結構、費用がかかる。完ぺきなものを求めたりすると、ソフトウェアの制作費より、ドキュメントの制作費の方が高く付いてしまう。また、納品は電子媒体でと指定しておくこと。この指定を忘れると、大量のドキュメントを紙で納品されて保管場所に苦慮したりする。-著作権──ソフトウェア改変の権利 ソフトウェアには著作権というものが付いて回る。これは、通常、そのソフトウェアを作成した人（個人／法人）が権利を所有する。そのため、契約書に何も言及がなかった場合、ソフトウェア著作権は業者側にあることになり、納入されたソフトウェアを自社で勝手に書き換えることができなくなる。この場合、別の業者に改修を依頼することもできなくなる。 こういったことにならないように、契約書には「納品したソフトウェアおよびドキュメント等納品物の著作権は発注者である自社が所有し、受注者は著作者人格権等を行使しないこと」などと明記しておくとよい。さらに、納品物であるソフトウェアに、業者が開発した汎用部品などが使用されている場合、その部分と自社の仕様書に基づいて開発された業務アプリケーションの部分を分けて検討する必要がある。 また、開発したソフトウェアが自社の独自ノウハウであり、他社に対し競争優位性がある場合、同類のソフトウェアを他社へ提供できないように取り決めたり、秘密保持契約を結んだりする必要もある。あるいは共同開発を行った場合に、権利をどのように保持し行使するのか。このように「著作権」と一口にいっても場合によっては複雑になるケースもあるで、心配であれば法律の専門家に契約書のチェックを依頼するのもよい。 仕様変更──エビデンスを残す仕組み 契約後、実際に仕事が始まるとすぐに問題になるのが、仕様変更である。契約においては、「仕様変更は必ず発生するもの」という前提で変更管理ルールについて、業者と十分に調整しておくことが必要だ。 いざ、仕事が始まってしまうと、自社の担当者と業者の担当者の間で、口頭ベースで仕様変更を指示し、実施されてしまい、後から多額の請求書が出てくるということも少なくない。 基本は、仕様変更に関するやりとりはすべて書面で行うことだ。担当者間では、仕事をスムーズに進めたい、人間関係を良くしたいという心理から、なんでも口頭で「よっしゃ、よっしゃ」で進んでしまう。特に、業者側の担当者は、委託先の担当者から頼まれた場合、なかなか断りにくいようだ。委託側である自社の担当者に、コスト意識を持ってもらい、安易に仕様変更を口頭でしないようにくぎを刺しておくことも必要である。 また、仕様変更の実施判断は担当者だけで判断せず、納期やコストへの影響をプロジェクト全体の観点からチェックできるような社内体制やルールを決めておくべきである。 担当者は、「良いシステム、使いやすいシステム」を作りたい一心で、仕様変更を依頼することが多い。それは一概に悪いことではないが、最小の投資で最大の効果を生むシステムを構築するという観点で見ると、オーバースペックで必要以上の投資になる傾向にもある。「なくてはならない機能、あったらいいな機能」をしっかり識別し、それが投資に値するものかどうかを経営的な観点で判断しなければならない。 |
ディックのサイトです。
