忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
1  2  3  4  5  6  7  8 
 情報システムは、その企業固有のカスタムメイドのものですから、開発をベンダに委託したとしても、ユーザは必要な情報提供などの協力義務を負います。のみならず、ユーザは、当該システム(あるいは開発プロジェクト)のオーナーとして、ベンダの業務について、厳しく目を光らせる必要があります。

 確かに、ベンダはシステムを完成させるための専門家責任であるプロジェクトマネジメント義務を負います。これは、開発経験のないユーザが協力義務を怠っているような場合に、適宜これを指導してシステム完成への障害を取り除くことまで含む、重い義務です。したがって、少なくとも法的には、ベンダがまずいプロジェクト遂行をしている場合に、ユーザにはこれを是正する義務はありません。
 しかし、これは、実際にプロジェクトが失敗してしまった場合の事後的な責任配分の問題だと認識すべきです。プロジェクト遂行中に、ユーザが主体的な立場を失うと、開発に失敗した後で「損害賠償」は取れるかもしれませんが、開発に成功して「望むシステム」を手に入れることはできません。裁判で取れる損害賠償と、望むシステムを運用して得られる利益は、下手をすれば一桁違います。損害が莫大であるばかりでなく、事後処理を含めて数年から十年近くが費やされ、事業展開自体に深刻な影響が及んだ事例も稀ではありません。
 ひとたびシステム開発を決断したなら、相当の経営資源を投入する覚悟がなければならないはずであるのに、安易に考えている例があまりにも多いことに、驚かされます。

拍手[0回]

PR
author : ITS 
 通常のシステム開発委託契約は、ベンダが総合テストを終えると一旦「納品」し、これをユーザが運用テストや受入テストなどの形で「検査」をし、それに合格すると「検収」となり、その後「本稼働」を迎えるというものです。今回考えてみたいのは、この「検収」と「本稼働」の関係です。

 上に見たように、検収後に本稼働を迎えるというのは、ユーザが品質の確認をしたうえで了解し、支払義務を負う反面でシステムに対する権利を得てから利用を開始するというのですから、極めて自然に思えます。経産省の「モデル取引・契約書」をはじめ、殆どのサンプル契約書ではそうなっているようです。
 しかし、見方を変えると、検収と本稼働の関係は常にそうではないのではないか、というのが今回の話です。(実はここが重要なところでもあるのですが)検収は大雑把に言って請負契約における完成(債務の履行)を確認する行為ですから、これによってベンダは瑕疵担保責任の除く免責を得、ユーザは支払義務を負います。逆に言えば、そのような効果を付与しても良い場合にユーザは検収を出すということになります。他方、本稼働は、権利とか義務とかを特段考えることなく、ユーザが自らの業務にシステムを利用できるレベルの品質確認ができれば足りるものです。このレベルの品質確認は、厳密に言えば、「検収」(あるいはその前提の検査)ではなく「稼働判定」でしょう。
 なぜこのようなことを考えるのかと言うと、(契約書での想定にかかわらず)現実のシステム開発、それも一応成功したと言えるシステム開発でも、その多くが、本稼働後に検収を迎えているという事実があるからです。本稼働前のドタバタは別にしても、稼働直前の時期に悠長にドキュメントの最終チェックなどやっていられませんし、受入テスト段階で出た不具合の対応を本稼働までに終えるのも、多くの場合スケジュール的に無理があります。しかし、検収するとなれば、建前上はこれらをクリアしておかなければならないはずです。
 確かに、代金を支払わない可能性を残しながら先走ってシステムを使ってしまうのは変ではあります。しかし、検収の有無にかかわらずシステムが客観的に完成レベルに達していれば支払義務は発生するわけですし、結局のところ代金の支払義務が発生しなくても先走ったシステム利用の分を利得として代金と別に精算することも観念的には考えられるところです。また、システムに対する権利について言えば、ユーザが著作権の譲渡を受ける場合でも、その移転時期は検収時ではなく代金の支払時とされることが多く、これは検収が本稼働前だとしても、ほぼ確実に本稼働後のタイミングとなります。契約書上、このタイムラグ分の利用権がケアされていることは稀ですが、ここに黙示の利用権設定を認めるなら、検収が本稼働後にずれ込んだ場合でも同様のはずです。
 結論として、「納品→検収→支払」という権利義務に関わる流れと、「納品→稼働判定→本稼働」という稼働に関わる流れがあるような気がします。気はしますが、実務でここまで踏み込んだことはありません。本稼働近くになれば非現実的に見える建前も、契約締結時に否定してしまって良いものか、若干の躊躇があるというのが本音だからです。検収前、つまり完全な確認をする前に本稼働してしまった場合に、実は本稼働に耐えない不具合が発見されたとすると、その責任を完成義務を負うベンダが負担するのか、稼働判定でOKを出したユーザが負うのかという問題も生じそうです。

拍手[0回]

author : ITS 

 一時期、情報システムのTCO(Total Cost of Ownership)ということが喧伝されました。新規システムの導入時に、導入コストだけでなくその後のランニングコスト(運用・保守コスト)を考慮して初めて、正確な費用対効果が出せる、というものです。恐らく、このTCOの考え方は、改めて「TCO」などと言うまでもなく実践されるほどに、実務に浸透したものと思われます。しかし、一点だけ、平時のランニングコストのさらに先にあるもの、すなわち情報システムないし情報技術の継続性という観点だけは、どうも抜け落ちがちのようです。

 この点は、2〜3年毎にリプレースを繰り返さなければならない、ウェブ・サービスやECサイトの方が、はるかに意識が進んでいます。というより、初めから短期間でのリプレース・サイクルが、中長期計画のなかに組み入れられた形で投資判断がなされているからです。ある求人サイトでは、次期システムの企画段階で、既に次々期のシステムの青写真が出来ていると言います(もちろん、別の部署が取り組むとのことです。)。
 これに対して、数年から十年のサイクルが通常である基幹系システムでは、構築段階で次を見通すなど、現実的ではありません。それだけならまだ良いのですが、旧プラットフォームであるホスト機のメーカー保守が終わりに近づいて始めて、大慌てで対応をとる、などといった事例も稀ではありません。いまさらホスト機ではないし、オープン系にストレート・コンバージョンするにも新規開発に匹敵する期間とコストがかかる、これを機に新規開発に取り組もうとしても、明らかに時間不足...継続性リスクが適切に対応されていなかったわけです。
 ウェブのような新しい技術を用いていても、更新サイクルが比較的長い場合には、同様のことが起こります。技術が新しければ反って技術サイドのサイクルが早いため、旧バージョンのミドルウェアのセキュリティ保守が終了したり、互換性のない新バージョンに移行したり、また、利用していたデータ・センターが突然に休止するといった事態もあるでしょう。こうした場合の対応は、システム全体の改修(場合によっては再構築)に及び、制度変更などによる部分的改修とは比べものにならないコストを発生させます。定期的に継続性情報をウオッチし、早めの対応ができるよう体制を整えておくことが不可欠です。

拍手[0回]

author : ITS 
 システム開発にデータ移行はつきものです。しかし、開発本体の契約が請負とされる場合でも、データ移行の部分だけは準委任として切り出されることがあります。ベンダとしては、移行対象データの正確性にまでは責任を持てないため、完成義務はとても負えないということになるのでしょう。
 
 もっとも、請負だと見ても、ベンダは移行計画どおりに最終工程までやり切れば履行したことになると考えることもできますし、仮に移行後のデータの不正確性が瑕疵に当たるとしても、ユーザの提供した「材料の性質」によって生じた瑕疵として、ベンダは免責されるはずです(民法636条)。逆に、移行作業の途中で対象データに不備があることを知りながら、これをユーザに知らせてデータ・クレンジングの機会を与えることなく移行を強行してしまったような場合には、ベンダに責任を負わせる(同条ただし書)必要があるでしょう。そう考えると、ベンダの責任を準委任契約の善管注意義務という漠然とした責任の中に押し込むより、開発部分と同じ請負契約の完成義務だと言った方がスッキリするようにも思えます。
 しかし、データ移行には、ベンダがコントロールできない事柄が多すぎます。経験のあるベンダであれば、移行元データの調査はできるかも知れませんが、それですべてが分かるわけではありません。移行設計をしようにも、移行元データの構造・定義はデータの「オーナー」であるユーザにしか分かりません。本当にその定義どおりのデータが入っているかといった、データ入力の実情はなおさら分かりません。移行試行後のデータチェックでも、ベンダには「異常」であることは分かっても、何が「正常」なのかは、ユーザでなければ分かりません。請負と見た場合の完成すべき「仕事」は、「移行プログラムの作成」ではなく「データの移行」と言うほかなく(移行プログラムは納品物にすらならないでしょう。)、そうだとすれば、この意味の仕事の完成をベンダの責任とするのは、いかにも無理があります。
 何れにしても、ベンダとユーザの責任分解点として、対象データの調査や不整合データがあった場合の対応の方法や程度などを、きちんと取り決めておく必要があります。ユーザとしても、どんなデータが入っていようとお構いなしに、ベンダに「新システムに合うデータ」を求めるような「丸投げ」では話になりません。データ移行を、既存のデータ資産の棚卸しの機会であるというくらいの意識で取り組む必要があるでしょう。

拍手[1回]

author : ITS 

 システム運用の委任契約書には印紙税はかかりませんが、システム開発の請負契約書には「2号文書」として印紙税がかかります。契約額が10億円を超えると、印紙税も40万円になりますから、馬鹿になりません。

 だからといって、内容的に請負の類型の契約について、契約書だけ「委任契約書」とタイトルを付けても、委任契約に化けるわけではありません。あくまで、契約の実質で判断されます。逆にいえば、システム開発に関わる契約でも、タイトルだけでなく、実質的にも完成義務を負わない支援契約にとどめるならば、非課税と判断される余地はあることになります。
 では、ASP契約にカスタマイズが付いた契約はどうでしょうか。これには、「通則2」に明文の規定があって、請負と請負以外の事項が「併記又は混合記載されているもの」として、(委任部分の金額を含めて)全体が請負となってしまうのが原則です。請負部分と委任部分では規定すべき条項も相当に違いますから、契約書もそれぞれに分けるのが賢明です。同様に、要件定義業務や外部設計業務の委託ように、契約の性質上、請負と委任のそれぞれの要素を持っている場合、請負の契約書として課税扱いされることもあり得るので、注意が必要です。
 なお、これに限らず、税法上は、一定の成果に対価が定められている契約は、請負として広く課税扱いされる傾向にあるように思われます。他方で、いわゆる基本契約書でないものであっても、それだけで契約額を確定できない契約(例えば、従量制の契約)は、「7号文書」として4000円になるなど、特有の解釈があるようです。

拍手[0回]

author : ITS 
忍者ブログ | [PR]
 | PAGE TOP
write | reply | admin