Off Shore Software Outsoursing Research Japan Software Contr

システムとソフトウェア技術者のための契約の知識

こちらのサイトから、有効かつ明快な説明は見つかった。まずメモカードとして情報をとっておく。

参考サイト
http://www12.plala.or.jp/junmyk/Contract.html

システムとソフトウェア技術者のための契約の知識

技術者にとっての取引ポリシーとは?

技術者は、交渉と契約関係が苦手です。(弊社では、営業職自体が苦手なようですが。)
しかしながら、交渉と契約の知識が無いと、顧客の無理を被害妄想的に受けることになり、経済活動にはなりません。
われわれの仕事は、顧客の主張のみに合わせて技術に奉じることではなく、対価的な経済活動を行うことです。
その時の交渉原則は以下の通りです。

  • 当社が有利かつ顧客が不利な交渉条件(Win-Lose)

当社の収益力が瞬間的に増加します。しかしながら、顧客側の競争力と信頼関係を低下させるため、長期的なマーケットは縮小します。したがって、当社の発展も望めません。
ここで脱線しますが、これを読んでいるあなたと、あなたの部下との関係もこうなっていませんか?
有名な格言を一つ、「他人に裁かれるより自らを裁く機会を与えられたほうが、人の精神は高められる。…」

  • 当社が不利かつ顧客が有利な交渉条件(Lose-Win)

顧客の市場競争力が瞬間的に増加します。しかしながらサプライヤ側が疲弊するため、品質や新技術開発に問題が出ます。なぜ、サプライヤ側が疲弊するのでしょうか。なぜなら、基準、希望、期待、ビジョンが全くないからです。当社の気持ちや信念を表現する勇気がなく、顧客の我の強さにすぐおびえることになります。ここに示す交渉原則を考慮することなく、低次元の顧客満足活動を闇雲に行うとこうなりがちです。
顧客側も歪んだ市場価格に慣らされるため、商品戦略上の原価配分バランスを欠いた製品が世に出ることになります。顧客にとって、サプライヤ側も広い目で見た場合のマーケットの一部であり、顧客のマーケットに対する感性と追従性を曇らせ、結果として長期的には顧客競争力が低下します。

  • 当社が不利かつ顧客も不利な交渉条件(Lose-Lose)

頑固で融通が利かないWin-Loseを考えているもの同士がぶつかるとこうなります。復讐は両刃の剣であることに気付くべきです。自分が惨めであるから、他人も惨めであるべきであるという姿勢です。即刻、商売をやめましょう。

  • 当社が有利かつ顧客も有利な交渉条件(Win-Win)

理想的な関係です。両者の建設的な信頼関係に基づいています。交渉条件を誇りをもって柔軟に変更する、もしくは、技術的なブレークスルーをつくる。両者が勝者にならないと長期的な発展は望めません。
(生物学的には共生進化と呼ばれている状態です。卑近な例としてイソギンチャクとクマノミ、原核生物とミトコンドリアなどです。こうしないと絶滅します。互いに寄生(parasite)し合うよりも共生(symbiosis)に基づいて行動するべきです。)
長期的に見ると、Win-Lose も Lose-Win も Lose-Lose になります。両方が勝たなければ、結局は両方が負けます。顧客との関係も、上司と部下との関係も、あるいは極論すれば、競合他社との関係もこれがいえると思います。(米国独占禁止法では、取引ルールが守られている限りにおいて、寡占は禁止しないとう方針を取りつつあります。なぜならば、寡占は長続きしないという経済理論が実証されつつあるからです。)
繰り返しますが、両者が何らかの形で勝者となることが、発展を前提とする経済活動には不可欠です。
そのためには、適正な二者間取引の知識が必要です。

共通フレーム98(SLCP-JCF98)という名前のグローバルスタンダードについて

ソフトウェアを中心としたシステム開発及び取引、特に保守作業ではなく、新規のシステム開発を行う場合には、「取得者が必要とする情報システムの作業内容を、前もって明確にすることが困難な場合が多い。」という取引上の根本的な問題を抱えております。結果として、取引での様々なトラブル(仕様変更、価格超過、納期遅延等)が発生する要因となっています。
これらの問題の解決策として、取得者と供給者の二者間で共通の言葉により取引内容を明確にする観点から共通フレームの取り組みは始まりました。具体的には、ISOの委員会がSLCP(Software Life Cycle Process)という名前で原案ガイドライン作りに動き始めました。

日本でも、これらの動きと同期して、前記SLCPを取り入れる形で、日本における開発と取引の実態を反映させたシステム開発のライフサイクルプロセスが策定されました。これが二者間取引のための共通フレーム(SLCP-JCF94:Japan Common Frame 1994)です。具体的なアクション項目は、以下の2本の柱で構成されています。

契約書の整備(盛り込むべき事項:仕様の確定、仕様の変更、検収、瑕疵担保責任、知的財産権)

契約手続きの慣行化(提案依頼書(RFP:Request For Proposal≒発注書)による発注の慣行化、契約形態の違い(請負と委任)の明確化)
前者については、(社)日本電子工業振興協会や(社)情報サービス産業協会においてモデル契約書が発表され、情報サービス産業界の業界標準となりつつあります。下記のリンクより一読をお願いします。

1995年8月、ISOはSLCPの国際規格(ISO/IEC 12207)を制定しました。1996年7月に、日本は、ISO/IEC 12207を翻訳し、JIS X 0160として規格化しました。この標準化動向を踏まえて94年版共通フレームをJIS(ISO)を包含して改訂したのが98年版共通フレームです。
98年版共通フレームと94年版共通フレームとの大きな相違点は、98年版共通フレームにはJIS規格にそって修正プロセスが設けられたことです。契約条項のガイドラインには変更はありません。上記ソフトウェア開発モデル契約書は、そのまま98年版共通フレームとして利用可能です。

システム開発担当者、ソフトウェア開発担当者、および営業は、上記のモデル契約に基づき顧客と契約するよう強く勧めます。これは、国際規格(ISO/IEC 12207)に準拠しているグローバルスタンダードです。CS(顧客満足度)とは関係ありません。

繰り返しますが、これはグローバルスタンダードです。広く産業界の発展に資するために決められたことです。法的な拘束力はありませんが、ISO9000、QS9000と同様に企業ステータスの問題です。

顧客には何の負い目もありません。これを元にした交渉のテーブルにつかないのは2流3流の会社です。大いに主張しましょう。

また、これは国際規格ですので、海外外注との契約にも適用できます。とくに、中国は、国家体制はさておき、民衆は日本以上に資本主義的です。繰延資産の税法怖さにコーディングしかやらせないとか、ちゃんとした契約書も作らないとなると、はなから馬鹿にされてしまいます。注意しましょう。彼らにとって商売人としての知恵のない人間は軽蔑の対象です。

2本目の柱…契約形態の違いの明確化について

役務の提供を目的とする契約には、請負、委任、準委任、雇用、派遣などがあります。ソフトウェアを中心としたシステムの開発に関する二者間の取引契約については、契約当事者が個々の業務を民法の典型契約(有名契約)である請負と委任(準委任)のいずれかに整理することにより、責任の主体を明確化して契約を締結することが重要です。
契約自由の原則により、強行規定に抵触しない限り、民法が典型契約としていない内容・方法での契約(無名契約または双方の要素を併せ持つ混合契約)も可能です。しかしながら、実務上の要請としては、請負と委任(準委任)への整理が有用かつ効率的です。(透明性がある。)

1993年7月の通産省 産業構造審議会 情報産業部会報告書「ソフトウェアの適正な取引を目指して」でも、取得者および供給者が「請負」と「委任」の区別を明確化せずに契約を締結し、トラブルに発展する場合を指摘し、区別の重要性を強調しています。

下表に、一般的な請負契約と委任契約の特徴を示します。

情報順番:

請負契約と委任契約の特徴 請負契約 委任契約
定義
・「請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してこれに報酬を与えることを約する」契約(民法第632条)、
当事者の一方:請負人、
相手方:注文者
・「委任は、当事者の一方が法律行為をなすことを相手方に委任し、相手方がこれを承諾する」契約(民法第643条)、
当事者の一方:委任者、
相手方:受任者
・「本節の規定は、法律行為にあらざる事務の委託に準用す」(民法第656条)
性質
・仕事の完成を目的とするもの
・仕事とは、労務によって発生する結果であり、有形的な仕事(家屋の建築、服の仕立て)と無形的な仕事(物の運搬、講演)の双方を含む。
・仕事の完成を目的としたものであるから、請負人が労務に従事しても、約定した結果が発生しなければ、契約の履行とならない。
・従って、結果の評価が可能でなければならない。
・注文者は完成すべき仕事の内容を、図面・仕様書・設計書等で示し、そのとおり仕事が行われたかを確認するのみで、完成に至るプロセス(実施方法、スケジュール、労務者の指揮・監督等)は、一切請負人の責任で行うのが原則である。
 -いわゆる責任施工
・一定のまとまった仕事の処理を任せるもの・労務の供給自体が行われることに意味があるとされる。
・仕事の目的が結果的に達成されない場合でも、履行の割合に応じて報酬を請求できる。(民法第648条)
契約内容
・図面、仕様書等により、完成すべき仕事の内容を明確にすることが必要である。
・完成の時期も、完了遅延に対する違約金や損害賠償との関係において、重要な意味を持つ。
・契約の性質上、完成・引渡を強調することはそぐわない。
・実施管理については受任者の裁量に委ねられているが、随時及び終了時の報告を要求される例が多い。
業務例
・土木建設工事
・運送
・注文による機械製作
・服の仕立て
・清掃業
・取引における代理人の選任
・弁護士への訴訟依頼
・不動産売買のあっせん
・警備 (準委任)
・設備運転 (準委任)
権利関係
・完成した仕事の検査(検収方法)、引渡の時期・方法、所有権・知的財産権の帰属関係(移転時期)を明確にすることが必要である。
・物の引渡という要素が希薄なことから、所有権の帰属関係よりも、知的財産権の帰属関係(移転時期)を明確にすることが必要である。
担保・債務不履行責任
・完成した仕事に欠陥がある場合は、請負人の故意・過失を問わず、注文者は、瑕疵の修補請求、契約解除、損害賠償請求を行うことができる。
・ただし、瑕疵が、注文者の提供した材料や、注文者の与えた指示に起因する時は、瑕疵担保責任を追及できない。
・担保責任の存続期間は、原則として、目的物の引渡もしくは仕事の終了後1年である。
・物の引渡という要素が希薄なことから、瑕疵担保責任の問題が生じることは少ない。
・委任の本旨に従って「善良な管理者の注意を持って委任事務を処理する義務(善管注意義務)」が懈怠された場合、債務不履行責任が発生する。
下請・再委任
・仕事の完成が主たる目的であるため、請負人自身が労務を提供する必要はない。
・従って、下請(請負人が、さらに第三者に請け負わせる)、再委任(請負人が履行補助者を使用する)は自由である。
・委任者の受任者個人への信頼が契約の基礎となっているため、受任者自身が事務処理を履行することを要求される。

例えば、請負契約の時には、検収日より1年※以上経過して発見された不具合には、瑕疵担保責任を負わなくても良いことになります。当社もサプライヤとして不具合対応を実施せざるを得ないわけですが、瑕疵担保責任を主張されるいわれはないわけで、非常に有利に交渉を進められます。
※実際にはOEM供給の場合、下記、商法上の規定が有効となり、6ヶ月となります。

<商法第526条>
商人間の売買において、買主がその目的物を受け取りたるときは、遅滞なくこれを検査し、もしこれに瑕疵あること、またはその数量に不足あることを発見したるときは、直ちに売主に対してその通知を発するにあらざれば、その瑕疵または不足によりて、契約の解除または代金減額もしくは損害賠償の請求を為すことを得ず。売買の目的物に直ちに発見することあたはざる瑕疵ありたる場合において、買主が6ヶ月以内にこれを発見したるときまた同じ。
前項の規定は売主に悪意ありたる場合は、これを適用せず。

また、請負契約では、完成後の所有権の移転が原則です。したがって、旧来のような仕様の管理保管義務はなく、顧客からの仕様問い合わせに煩わされる筋合いがなくなります。また、量産仕様の変更などの保守業務に際しても、対価的な再契約を強く主張できます。そのうえ、下請・再委任は請負人側の完全な裁量に基づくので、海外外注などの導入も原則自由です。
一方、委任契約の場合は、瑕疵担保責任を問われないので、多くのアウトソーシング契約に用いられる形態です。プロジェクト自体が途中で中止になっても、応分の報酬が請求できます。委任者の合意の下、目的の遂行のために途中で経費が過分にかかった場合は、報酬の増額も請求できます。(これは、解除権と同様に、主張し始めた側に自動的に発生する権利で、形成権と呼ばれます。)

いずれにせよ、上記「請負」か「委任」かのどちらかの形態に分類して、契約を勧めることが肝心です。両方の形態を取りいれることも原則自由ですが、トラブルが発生した時の抗弁権を非常に限定したものにしてしまいます。注意してください。

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License