忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
 通常のシステム開発委託契約は、ベンダが総合テストを終えると一旦「納品」し、これをユーザが運用テストや受入テストなどの形で「検査」をし、それに合格すると「検収」となり、その後「本稼働」を迎えるというものです。今回考えてみたいのは、この「検収」と「本稼働」の関係です。

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

拍手[0回]

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

拍手[1回]

author : ITS 

 システム開発に途中での仕様変更はつきものです。経産省のモデル契約書でも、これに対処するために、変更管理の条項を手厚くしています。しかし、その内容は主に手続面に限られており、十分とは言えません。具体的に何が仕様変更に当たるのかの具体的な基準がなければ、事は解決しないのです。これについて、一般的には、「ユーザの承認を受けた設計書の記載」が基準とされているようです。つまり、記載されていることを記載されているとおりにやることが必要だが、記載されていないことはやらなくて良い、という考え方です。客観的なドキュメントを持ち出して、かつ、ユーザの承認も問題にするのですから、十分な考え方に思えます。しかし、もう少し突っ込んで考えてみる必要がありそうです。

・記載されていない場合
 まず、「Aをやる」と記載されていなことと、「Aはやらない」と記載されていることは違います。後者の場合、Aをやるのかやらないのか、あるいはA’をやるのかが検討され、やらないことに決定されたことが分かります。そして、そのことが明確にドキュメントされているのですから、その記載どおり、実装されていないことが正しいのです。しかし、何も記載がない場合、おそらく何も検討がされず、ドキュメントでも手掛かりがないのですから、ユーザとしては、AやA’を本当にやらなくて良いのか、判断する機会を与えられていないことになります。端的に言えば、検討漏れ、記載漏れという事態です。これがAをやらなくて良いことの根拠になるというのは、少し無理があります。少なくとも、上位のドキュメントにAに関することについて、抽象的な記載がある場合や、標準的なシステム設計においてAに関することについて検討課題に挙げるべきとされている場合、改めて検討の上、設計・実装をすべきです。

・記載されている場合
 次に、「Aをやる」と記載されていてAを実装したが、正しくはA’を実装すべきであった場合です。この場合、AでもA’でも、合理的設計内容として成り立つのであれば、ベンダは免責されるべきです。ベンダは、ユーザに確認してもらう以外に、自らAとA’のどちらが正しいのか、知る術がないからです。しかし、記載されていることに、それ自体として論理的誤りがある場合、他の設計部分と整合しない場合、などは、設計バグというべき事態です。設計バグを瑕疵と見れば、ユーザが承認したからといって、ベンダが直ちに免責されることがないのは当然です。裁判例でもユーザの検査漏れは瑕疵担保責任に基づく請求権を放棄したものとはみないとされていますし、殆どのモデル契約書では検収後の瑕疵担保責任追及を認めています。なお、ユーザが間違った要求を出し、それが設計書に記載された場合は、瑕疵がユーザの指図に起因すると言えるので、民法の原則から言っても、ベンダは免責されます。ただし、ベンダが専門家として気づくべきことを気づかずに、ユーザの間違いを漫然と受け入れた場合は、善管注意義務違反となる可能性があるでしょう。

拍手[1回]

author : ITS 

 システム開発委託契約は、一応は、民法上の典型契約である請負の類型に入るものと考えられています。しかし、請負そのものではありません。その最大の違いは、発注者であるユーザが、オーダーメイド・システムの開発に必要な情報を提供するなどの「ユーザ責任」を負っている点にあります。このような「ユーザ責任」は、裁判例にも「協力義務」として表れるなど認知が進んでおり、経産省のモデル契約でも強調されているところです。このような義務は、事の性質上、取り立てて言うまでもなく存在するはずのものですが、あえてこれを強調しなければならないのは、ベンダへの開発の「丸投げ」が横行しているからでしょう。

 この「ベンダにお任せ」というユーザの第三者的姿勢は、なかなか根強いものがあるようです。かつて、A社の基幹システム再構築のプロジェクトに関与したときのことです。プロジェクト名を仮に「ロペス」としましょう(最後の「ス」は、もちろん「system」の「s」です。)。これは、A社の副社長をプロジェクト・リーダとする、れっきとした「A社の、A社による、A社のための」プロジェクトです。ところが、当のA社の管理職の面々は(自らもシステム化委員会のメンバーとしてプロジェクトに関わっているはずなのですが)、当事者意識どころか、プロジェクトの存在すら良くご存じではないようでした。とうとう、ある会議の席上でこんな発言が飛び出しました。曰く、「そういった面倒な問題は、ロペスさんの方でお願いしますよ。」自分達が関与している(関与させられている)訳の分からないプロジェクトは、「外部のベンダのプロジェクト」であって、(ちょっと人名のような感じのする)「ロペス」をそのベンダの社名とでも勘違いしたようなのです。このA社が自ら望むシステムを手に入れるのは、困難と言わざるを得ません。
 ただ、ベンダ側も、システム開発の専門家として、ユーザをしっかりコントロールすることが求められます。ユーザが要求仕様を明らかにしなかったために、出来上がったシステムがユーザの業務に使えなかった場合、ユーザの協力義務違反だけでなく、ベンダのプロジェクトマネジメント義務違反が問われます。ある裁判例は、これについて「注文者である原告のシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しない原告によって開発作業を阻害する行為がされることのないよう原告に働きかける義務」とまで言っています。裁判において、専門家の責任は意外なほど重いのです。

拍手[1回]

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