システム開発の受発注企業間で起きる問題点 − 「発注企業」編その2

今回は、前回ブログの続編になります。

前回のブログでは、システム開発時に、企業間で起こる問題として、次の3点の解説を行いました。

★「発注企業」編その1：http://msystm.co.jp/blog/20130208.html

・納期期日が過ぎたのに納品されない
・途中で追加料金を請求された
・納品されたシステムに期待した機能がない

発注企業、および受注企業のどちらにも、問題を発生させる原因が存在することをお解りいただけたかと思います。

今回は、上記3点の問題とは別に、次の4点をご紹介したいと思います。

・納品されたシステムが動かない
・納品されたシステムの処理の仕方が違う
・納品後、障害が起きたのに対応してくれない
・障害対応を依頼したらお金を要求された

今回の問題点に関しても、発注企業、および受注企業のどちらの側にも原因があります。

本ブログの主題は、「システム開発の受発注企業間で起きる問題点 − 「発注企業」編」となっておりますが、システム開発を受注する企業の方にも読んで頂きたいと思っております。

今回も宜しくお願いします。

- - - - -

■納品されたシステムが動かない

●現象

「システムが稼働しない」、ソフトウェア製品の成果物を納品した時に、よく、この言葉を聞きますが、実際には、この言葉に関しては、厳密に言うと次の3種類があります。

(1)本当に、システム、そのものが起動しない
(2)システム自体は稼働するが、全ての機能が動かない
(3)システムは稼働するが、ある機能だけ動かない

言葉は、正確に使わないと、相手に正しく現象が伝わりません。ソフトウェアに問題があることを、他者に訴えたいために「システムが動かない」と言いたい気持ちは解りますが、それでも、言葉は正確に伝えるべきだと思います。

ちなみに、上記(1)と(2)は、実際の動作は多少異なりますが、ほぼ「システムが動かない」と言っても差し支えないと思います。

しかし、(1)、および(2)と、(3)は違います。(3)においては、システム自体は稼働する訳ですから、「システムが動かない」でなく、「機能が動かない」が正しい現象です。

●原因

通常、受注企業は、成果物の納品前に、システム導入環境と同じシステム環境を構築し、その環境で結合試験を実施し、当初の想定通りに、ソフトウェアが稼働するか否かを確認し、正常動作が確認された後、成果物を納品します。

それでもソフトウェアが動かない場合、だいたいは、次の様な原因が考えられます。

(1)	ソフトウェアの稼働試験を行わずに納品した	義務違反
(2)	ソフトウェアにバグ(障害)がある	作成ミス
(3)	ソフトウェアの稼働環境が想定と異なる	導入ミス/作成ミス
(4)	ソフトウェアへのオペレーションを間違えた	操作ミス

順を追って説明します。

(1)ソフトウェアの稼働試験を行わずに納品した
これは、本来行うべき業務を行わない債務不履行です。このため、受注会社の義務違反となります。試験を行わずに成果物を納品するなど、一般常識のある企業であれば、考えられないことです。

しかし、世の中には、あまたのソフトウェア開発企業が存在します。中には、正しい環境で充分な試験を行わず、そのまま納品してしまう企業も存在するかもしれません。

また、開発作業が遅延した場合、遅れた分だけ試験期間を削って、そのまま納品するケースも考えられます。

これは、明らかに受注企業側の致命的なミスです。損害賠償の対象ともなるべき瑕疵と言えます。

結合試験の試験結果の提出を命じ、直ちに試験結果が提出できないようであれば、本当に、試験を行わずに納品した可能性が高いと思われます。

試験結果を提出した場合でも、提出までに何時間、あるいは何日も掛かった場合、試験結果ねつ造の可能性も否定できません。

(2)ソフトウェアにバグ(障害)がある
ソフトウェアは、人間が作成した物です。言い訳にも聞こえるかもしれませんが、完璧な物はありません。
必ず、バグ(障害)は発生します。

しかし、バグにも「程度」があり、システム導入時からソフトウェアが動かないとなると、さらに次の3つの原因が考えられます。

1)(上述の様に)試験を実施せずに導入した
2)(後述する)システム導入環境が想定と異なる
3)試験環境と動作環境が異なる

1)については、前述の通り、言語道断ですが、2)と3)については、後述の説明をご覧下さい。

(3)ソフトウェアの稼働環境が想定と異なる
受注企業は、見積り段階で、発注企業のシステム環境をヒアリングし、発注企業のシステム環境で動作するソフトウェアを開発します。

このため、受注企業の社内に、発注企業と【同等】のシステム環境を構築し、その環境でソフトウェアの製造、および試験を行って納品します。

しかし、この【同等】と言う所が問題です。

システム環境を、完璧に発注企業側の環境に合致させるのは、非常に難しいものがあります。

ソフトウェアは、通常、バージョン番号とリリース番号で管理され、バージョンやリリース環境が異なると、それは、異なるソフトウェアになってしまいます。

バージョン番号とリリース番号の説明をすると、ブログが長くなってしまうため、今回は割愛させて頂きますが、簡単な例を紹介します。

皆さんが、普段使うソフトウェアに、「Microsoft Office Excel」があると思いますが、このエクセルにも、様々なバージョン番号とリリース番号があります

最新版から、過去に3世代遡ると、次の様なバージョン番号とリリース番号となります。但し、今回は、リリース番号以外のSP(Service Pack)番号で差異を表記します。

この「SP」とは、過去に発生したExcelのバグをFixしたものとなります。「Fix」とは、バグ修正を行うことを意味します。

つまり、「SP2」とは、「SP1」で発生したバグに対して、バグ修正の対応を行ったソフトウェアと言うことになります。「SP1」と「SP2」とは、ソフトウェアが異なってしまいます。

このため、例えば、受注企業側は、「Excel 2010 SP1」で試験を行ったが、発注企業は、「Excel 2007 SP2」だった、と言う場合、異なる環境で試験を行ってしまった、と言うことになります。

さらに、ソフトウェアの場合には、バージョン番号とリリース番号の他にも、「モード」と言う差異問題も存在します。

この「モード」には、通常「32ビット版」と「64ビット版」と言う2種類のモードが存在し、このモードが異なっても、ソフトウェアの動作は全然違ってしまいます。

原因の項目に、「導入ミス」と「作成ミス」と2種類のミスを記載しましたが、それは次の様な理由からです。

・「導入ミス」：本来は、AというPCに導入する予定が、Bと言うPCに導入してしまった。AとBは、稼働・導入ソフトウェアが異なる、と言う場合を想定しております。
・「作成ミス」：本来は、例えば上記Excelを例にしますと、「Excel 2007 SP3」を想定稼働環境とすべき所を、「Excel 2007 SP1」環境で作成試験を行ってしまった、と言う場合を想定しております。

さらに、上記「作成ミス」の場合は、当初のヒアリングを間違えた場合に発生します。この点に関しては、受注企業のみの責任と言うだけでなく、発注側での確認漏れも障害発生の原因と言う事になります。

(4)ソフトウェアへのオペレーションを間違えた
「ソフトウェアへのオペレーションを間違えた」と言う場合も、実際には、様々なケースが考えられます。

簡単に考えても、次の様なオペレーション・ミスが考えられます。
・入力データを間違えてしまった
・設定方法を間違えてしまった
・処理順番を間違えてしまった

この場合、おそらくシステム自体は起動すると思いますが、何か処理を行うと、ソフトウェアがダウンしてしまうとか、エラーが発生する、と言う現象が起きると思います。

このため、納品物として納められた、「マニュアル」を参照し、間違いを修正することで、対応が取れるケースもあると思われます。

受注企業を責める前に、マニュアルを精読し、受入側の、操作ミスが無い事を確認して下さい。

●対策
「システムが動かない」と言う問題に関して、前述の4つの項目毎に、発注企業として取れる対策をご紹介します。

(1)ソフトウェアの稼働試験を行わずに納品した
発注企業においては、正直なところ、受注企業が、本当に試験を行ったのか否かは確認できません。試験結果報告書を提出させても、それが本当の試験結果なのか否かも確認できません。ねつ造かもしれません。

厳密に試験結果を確認したいなら、試験結果報告書と同時に、試験結果をプリンターに出力させ、試験実施時のタイムスタンプ(時刻)を確認する必要があります。

但し、当初から、このような要求をすると、当然、試験工数が増えるため、開発費用も増加します。

企業間取引の基本は、契約書と相互信頼です。信頼関係がある間は、受注企業に、そこまでの結果を求める必要はないと思います。

しかし、企業間での信頼関係が崩壊した場合は、試験結果報告書と試験結果の提出を求めても良いと思います。

一方、通常ソフトウェアの受託開発の場合、費用は、成果物の納品後、検収試験が完了してからの支払いです。

このため、受注企業としては、契約通りの成果物を納品しないと、開発に掛かった費用を回収できないため、通常は、きちんと試験を行い、社内で動作確認を行ってから納品します。

そこで、契約書には、次の様な条項を設け、きちんとした成果物が納品されるまで、費用の支払いを行わないようにすることで、動かないソフトウェアへの支払いを防ぐことができます。

1)支払条件：納品検収後の支払いにする
2)瑕疵対応：瑕疵があった場合、早急に対応して再納品させるようにする
3)損害賠償：瑕疵が重大な場合、受取を拒否して、損害賠償が行えるようにする

但し、契約書に、上記の条項を付加する場合、発注企業側も、次の様な責任を負うことを理解して下さい。

1)受入試験の明確化：受入試験方法を作成し、事前に受注企業に提出する必要があります
2)瑕疵判定基準：どの程度の瑕疵なら再納品を認め、どの程度なら受入を拒否するのかを明確に提示する必要があります
3)損害賠償の基準：損害賠償額の最高値、および損害賠償基準を明確にし、受注企業に提出する必要があります。

(2)ソフトウェアにバグ(障害)がある
前にも記載しましたが、ソフトウェアにはバグは付き物です。

このため、バグの程度にも依りますが、「バグがあった、即損害賠償」と言うのは現実的とは思えませんし、裁判になっても、その主張は認められないと思います。

このため、バグに関しては、瑕疵担保期間内であれば、無償で何度でも対応させるように、契約書を作成するのが現実的です。

瑕疵担保期間は、民法と商法とで、定義内容が異なります。

ソフトウェアを発注する前に、民法と商法の、関連事項を理解することで、納品後のバグへの対応を検討した方が良いと思います。

商法：第526条
民法：第637条

(3)ソフトウェアの稼働環境が想定と異なる
「原因」にも記載しましたが、ソフトウェアは、導入環境が想定と異なると動作しない場合もあります。

このため、本事象を防ぐための対策としては、受注企業側の開発環境と、発注企業側の動作環境を、事前に一致させる必要があります。

開発環境と動作環境を、完全に一致させれば、本現象は防止する事が可能です。

しかし、現実問題として、開発環境と動作環境を、完全に一致させるのは不可能です。

なぜなら、双方とも開発に関連するソフトウェアだけを一致させるのは可能ですが、PCには、開発に関係の無いソフトウェアも導入されております。このため、環境を一致させるためには、PCのスペックを含めて、全てのソフトウェアを同じ物にする必要があります。

どうしても開発環境と動作環境を一致させたいなら、発注企業のPCを受注企業に貸し出し、貸し出したPCで開発作業を行わせる必要があります。

しかし、この対策も現実的とは思えません。

そこで、現実的な対応としては、次のような対応になると思います。

1)双方で事前に、開発作業環境について、開発環境と動作環境が一致、あるいは影響の無いと思われる範囲で、一致することを確認する。
2)もしも、開発環境と動作環境で、類似環境を構築することが難しい場合、発注企業側で、受注企業側に、類似環境を構築するための支援をする。

上記1)に関しては、「双方で」、かつ「事前に」と言うキーワードが重要です。

発注企業も、受注企業任せにせず、開発環境と動作環境の確認を行い、可能な限り、開発環境と動作環境が一致するか否か、あるいは影響がでないと思われる範囲で、一致するか否かを確認する必要があります。

開発環境と動作環境の確認を行わず、納品された後に、「稼働環境が違うから動作しない」と言われた場合には、発注企業側にも責任があることを自覚して下さい。

次に、2)に関しては、契約前に、双方で良く話し合いを行い、同一環境が構築できない場合、発注企業と受注企業とで、どちらが、どの程度の対応を行うのかを、決定しておく必要があります。

契約した後に、「稼働環境が違うから追加費用が必要」と言う問題を発生させないためにも、事前調査、および事前確認が必要です。

(4)ソフトウェアへのオペレーションを間違えた
オペレーション・ミス(略してオペミス)に関しては、前にも記載しましたが、まずはマニュアルを精読し、自身の操作・設定に間違いが無い事を確認する必要があります。

よく、マニュアルも何も読まずに、「システムが動かない」と騒ぐ企業が存在します。

確かに、ソフトウェアによっては、マニュアルが何十ページも存在し、読む気になれない物も存在します。

しかし、マニュアルも成果物の一種ですから、本当は、ソフトウェアの受入確認試験と同様、マニュアルの品質も確認する必要があります。

システム導入後、保守サービスを行ってもらえるならば、(余り言いたくはありませんが)マニュアルは、ほどほどに読んでいれば良いと思います。

しかし、保守サービスの契約を行わないならば、瑕疵担保期間が過ぎた後は、受注企業は保守を行いません。何か不具合が起きた時には、マニュアルだけが頼りになります。

瑕疵担保期間が過ぎた後、「マニュアルが解りにくい」と文句を言っても、受注企業は、無償修正はしてくれません。

一度、成果物の納品時に、最初から最後まで、マニュアルを読むことで、オペミスを防止することもできますし、品質の確認を行うこともできます。

- - - - -

■納品されたシステムの処理の仕方が違う

●現象

本現象は、残念なことに、納品後、ほぼ確実に起きる事象です。

本現象は、ソフトウェアが提供する機能によって、様々な種類、パターン等で現れます。このため、「これだ！」と言う現象の提示はできません。

簡単な例で示しますと、次の様な現象です。

あるソフトウェアは、A〜Eまでの情報を含んだデータを入力して、A、B、Dの項目だけを含んだデータを出力すべき所、誤ってA、C、Dの項目で、出力データを作成してしまった、と言う様な事象が、本現象になります。

●原因
本現象が起こる原因は、簡単に言うと、発注側と受注側の双方の意思疎通の失敗です。

意思疎通の失敗ですから、発注側と受注側のどちらかが、言った事・聞いた事を誤解した事になります。

意思疎通の失敗は、基本的に双方の過失です。意思疎通の失敗について、詳しく分析すると、また「言った/言わない」、「言った/聞いてない」になってしまいます。

このため、前述の「納品されたシステムに期待した機能がない」を参照して下さい。

●対策
本現象への対策も、前述の「納品されたシステムに期待した機能がない」を参照して下さい。

基本的に、本現象に関しては、記録を残すことで防止することが可能です。

しかし、記録を残したとしても、人間、間違える事はあります。このため、完全に防止することは不可能です。

但し、記録を残せば、発注側と受注側のどちらが間違えたのかは突き止めることが可能になります。

- - - - -

■納品後、障害が起きたのに対応してくれない

●現象

本現象も、良く聞く事象です。

成果物納品後、「納品直後は、障害が発生すると直ぐに修正してくれたが、暫くすると、障害が発生しても対応してくれなくなった」、と言う様な事象です。

また、少しニュアンスが異なりますが、次の様な事も良く聞きます。

「ずっ〜と、問題なかったが、急に障害が発生するようになった。そこで、ソフトウェアを作ってもらった企業に連絡したら、電話がつながらなかった。」

「障害が発生したから連絡したら、開発担当者は既に退職しており、対応できる社員が居なかった。」

「障害で連絡したら、当時の開発担当者は存在したが、違う部署に異動しており、もう技術スキルがないために、対応できないと言われてしまった。」

上記の3点は、現象としては、本章の題名と同じ「障害が起きたのに対応してくれない」ですが、ちょっとニュアンスが異なります。このため、本章での解説は割愛させて頂きます。

●原因

本現象に関しては、原因を探るためには、次の2点が重要になります。

(1)障害が発生したタイミング(時期)
(2)契約書の内容

そこで、上記2点毎に原因を解説して行きます。

(1)障害が発生したタイミング(時期)
障害が発生したタイミングが、瑕疵担保期間内か否かにより、原因が異なります。

瑕疵担保期間は、商法の規定で、当事者間の合意に依って決定します。まずは契約内容を確認して下さい。

契約書に瑕疵担保期間が明記されてなければ、商法第526条の規定により、瑕疵担保期間は、成果物の受領後、6ヶ月間となります。（※民法上は、瑕疵担保期間は1年となりますが、企業間取引の場合、商法は、民法より優先されます。このため、瑕疵担保期間は6ヶ月となります。）

そして、障害が発生した日が、瑕疵担保期間内であれば、障害対応を行わないのは、受注企業側の債務不履行となります。

一方、障害発生日が、瑕疵担保期間の終了後だった場合、受注企業側に、法律上は、障害対応の義務はありません。

この場合、障害原因がソフトウェアのバグであったとしても、受注企業には、障害対応の義務はありません。故に、別途契約を締結して障害対応を行ってもらうか、あるいは温情にすがって、無償で対応してもらうかしか方法はありません。

(2)契約書の内容
契約書の内容確認に関しては、上記でも説明しましたが、まずは、契約書上で、瑕疵担保期間が、どのように定められたのかを確認する必要があります。

次に、障害発生日が、瑕疵担保期間の終了後だった場合、ソフトウェアの開発契約とは別に、保守契約を締結したか否かを確認して下さい。

ソフトウェアの保守契約を締結したならば、保守契約における業務適用範囲を確認し、障害対応が、業務範囲にある事を確認して下さい。

保守契約を締結し、かつ業務適用範囲にソフトウェアへの障害対応業務があるならば、障害対応を行わないのは、受注企業側の債務不履行となります。

しかし、開発契約だけで、保守契約を結んでいないならば、前述と同様、受注企業には、障害対応の義務はありません。

●対策

本事象に対応するためには、既にお解りの様に、次の2点が重要になります。

・瑕疵担保の期間を、どの程度にするのか
・保守契約を締結するのか

瑕疵担保期間は、前述の通り、民法は1年、商法は6ヶ月です。このため、契約書上に瑕疵担保の記載が無い場合は、特別法である商法が民法に優先し、瑕疵担保期間は6ヶ月となります。

しかし、瑕疵担保期間に関しては、企業間の取り決めにより、期間を変更することが可能です。商法で6ヶ月間ですが、最長1年間、あるいは1年以上にも延長可能です。

但し、瑕疵担保期間を長期間に設定すると、受注企業側のリスクが大きくなってしまう事を理由として、契約金額が増加してしまう可能性もあります。双方が納得する期間、金額にする必要があります。

この点は、発注企業と受注企業との間で、擦り合わせを行って下さい。

次に保守契約に関してですが、瑕疵担保期間が過ぎた後でも、障害対応等を行って欲しいならば、別途保守契約を締結する必要があります。

保守契約に関しては、次の様に、様々な契約形態があります。この点も、受注企業と、よく相談して決めて下さい。

・年度単位：一括で前払い
・月単位：月毎の支払い

それと、保守契約は、成果物が明確に定義できません。このため、保守規約は、一般的に委任契約になります。(ソフトウェア開発の契約は、成果物が明確ですから請負契約になります。)

委任契約の場合、上述の通り、成果物を明確に定義できません。このため、業務適用範囲を明確に定義する必要があります。

業務適用範囲に、障害対応を含ませることで、障害が発生した場合でも、無償で障害対応を行ってもらうことが出来る様になります。

その他にも、保守契約の場合には、業務適用範囲に、データ等、環境バックアップも含ませることもできます。業務適用範囲については、受注企業とよく相談して下さい。

また、契約内容とは話は別ですが、やはり成果物を受け取ったら、きちんと受入試験を行い、瑕疵担保期間内で「バグ出し」を行った方が良いと思います。

「バグ出し」とは、ソフトウェアに対して、過酷な条件を課して試験を行うことを意味します。

ソフトウェアの受入試験に関しては、本ブログにおいては解説しませんが、(私が、こんな事を言うもの変ですが)【性悪説】に立って、「ソフトウェアにはバグはある」と言う前提で試験を行うことをお勧めします。

しかし、受入試験を行うのは大変です。通常は、普段の業務を行いながらソフトウェアの受入試験を行います。このため、詳細な受入試験は行えないと思います。

故に、作成したソフトウェアの立ち位置を考慮し、「万が一システムが停止したら業務が立ち行かない」様なシステム、いわゆる「基幹業務」に含まれるシステムであれば、保守契約を締結することをお勧めします。

- - - - -

■障害対応を依頼したらお金を要求された

●現象

本現象は、前章「納品後、障害が起きたのに対応してくれない」と、非常に深い関係がある事象です。

前章「納品後、障害が起きたのに対応してくれない」の場合は、単純に障害対応してくれない、と言う事象でしたが、本事象は、「費用を支払ってくれるなら障害対応を行う。」と言う事象になります。

●原因

本事象の原因も、前章同様、契約内容が重要になります。

障害発生日が、瑕疵担保期間内であるにも関わらず費用を請求された場合は、明らかに、受注企業の瑕疵担保への理解不足が原因だと思われます。

一方、障害発生日が、瑕疵担保期間の終了後だった場合は、これは費用を請求されても仕方が無い事だと思います。

受注企業としては、瑕疵担保期間は無償で障害対応を行いますが、瑕疵担保期間を過ぎたら、有償対応と考えるのは自然なことです。

弊社の場合も、本当に軽微な障害であれば、サービスとして無償で対応するケースもありますが、基本的な考えとしては有償対応です。

●対策

本事象への対策としては、やはり前章「納品後、障害が起きたのに対応してくれない」と同じ対策になります。

障害発生日が、瑕疵担保期間内であるにも関わらず費用を請求された場合は、受注企業に対して、契約書記載内容を提示すると共に瑕疵担保の意味を説明し、無償で対応するように要請して下さい。

また、障害発生日が、瑕疵担保期間の終了後だった場合は・・・・発注企業には残念ですが、基本的には有償対応となります。発注企業に、見積り依頼をするしか方法は無いと思います。

但し、これはビジネスです。ビジネスは、企業間の取引です。ビジネスである企業間取引に関しては、何か取引材料があれば、話は別です。

例えば、取引材料としては、次のような材料が考えられます。

・別システムの開発を検討中で、案件の発注先を、引き続き現在の受注企業にする
・現在のシステムへの機能追加を検討中
・システム開発に関して、別の企業を紹介する

このように、受注企業に対して、魅力的な材料を提案すれば、障害対応を無償で行ってくれるかもしれませんし、無償は無理かもしれませんが、割引率を上げてくれるかもしれません。

何か、障害対応の費用を抑止するための方策を考えて下さい。

また、前章の対策にも記載しましたが、やはり受入試験は重要です。瑕疵担保期間内に、出来る限りの試験を行う事をお勧めします。

それと、障害に関してですが、バグ以外でも障害が発生する場合があります。それは、これまでにも説明しましたが、システムの稼働環境の変更です。

特に、この時期、Windows XPのサポート停止に伴い、PCをWindows 7やWindows 8.1に変更する動きが活発になります。

一般的には、PCを変更したことによるソフトウェアの動作不良は、瑕疵には当りません。

この場合は、全て有償での対応になります。PCのリプレースを行う場合には、事前に互換性を確認した方が良いと思います。

- - - - -

■「言った/言わない」、「言った/聞いてない」問題への対応

最後に、「おまけ」ですが、「言った/言わない」、「言った/聞いてない」問題への対応策をご紹介したいと思います。

この問題は、これまでに紹介してきた問題点の内、次の2点で、よく発生します。

1)納品されたシステムに期待した機能がない
2)納品されたシステムの処理の仕方が違う

ソフトウェア開発や、それ以外の分野でも、「言った/言わない」問題、いわゆる「口約束」の問題は、頻繁に起きる問題です。

このため、「言った/言わない」問題を解決するためには、発注側、および受注側の双方で、文章、つまりドキュメントとして、話した内容を確認し、記録を残すことが重要です。

「文章 !?」と言うと、引いてしまう方も居ると思いますが、文章と言っても、形式は問いません。それがメールであっても構いません。

以前、これが20年位前なら、メール等はありませんから、相手に伝えたいことは、全て電話連絡でしたが、現在は、メールで全て伝えることが可能ですし、メール記載内容は、裁判でも証拠として採用されます。

中には、メールをするのも面倒臭がり、相変わらず電話でしか要件を伝えない方もいますが、その様な方の場合には、電話で伝えられた内容を、メールで送り返すことで対応できます。

『お世話になります、XXです。先ほど、お電話で伝えて頂いた内容を、確認のため次に記載します。間違いありましたら、ご指摘願います。ご指摘がない場合、本件に関しては、このメール記載事項を最終決定とさせて頂きます。

1.Aの件は、〜の対応とする。
2.Bの件は、〜の対応とする。

宜しくお願いします。』

このメールで、全て解決します。相手から異議を唱える返信が来なければ、このメール内容が最終決定となります。

弊社の場合は、このような手段の他に、「言った/言わない」問題を起こさないために、次のような方法を採用しております。

・ソフトウェアの細部に関わる仕様決定：質疑応答表による仕様確認
・ご契約時の仕様決定：ご提案書、およびお見積書への詳細作業内容の記載
・打合せ時の決定事項：議事録の作成と提出

とにかく、相手と何らかの打合せや話をした場合、その結果を記録に残します。当然、お客様とのメールも保存しております。

「言った/言わない」問題は、お客様との関係を悪化させる原因の一つです。普段から記録を残すことで、お客様との関係を良好に維持することが可能となります。

しかし、中には、

『確かに、あの時は、こう言った。しかし、今は違う。』

と平気で開き直る人間も居ます。

私も、過去には、このように「人間の風上にも置けない」上司の下で働いたこともありますが、そう言う人間には、こちらから何を言っても無駄です。付き合わないのが賢明です。

しかし、ビジネスにおいては、相手を選べないケースも存在しますが、最終的には契約書の存在と記載内容が決め手になります。相手が何を言おうとも、契約書を全面に出せば、「人間の風上にも置けない」人も引き下がると思います。

また、このような場合、発注側と受注側とで、対応は異なると思いますが、基本的に、相手先企業と、今後もお付き合いしたいのか、お付き合いする価値があるのかで、判断すれば良いと思います。

お付き合いしたいならば、相手の言い分を100%、無条件で呑むばかりでなく、何らかの付帯条件を付けて対応することをお勧めします。

お付き合いしたくない、付き合う必要が無いと判断した場合は、証拠物件がありますから、最後まで、意見を通せば良いだけだと思います。

- - - - -

■契約書の重要性

もうひとつ「おまけ」で、「契約書の重要性」についてもご紹介したいと思います。

契約書は、金額を決定するだけでなく、次の点で重要になります。

(1)成果物で提供する機能の内容
(2)成果物の種類/内容
(3)納期
(4)瑕疵担保期間の設定

このため、これまでに紹介してきた様々な問題においても、最終的に契約書の記載内容が重要になります。

1)	納期期日が過ぎたのに納品されない	納期遅延への対応
2)	途中で追加料金を請求された	条件変更への対応
3)	納品されたシステムが、動かない	品質不備への対応
4)	納品後、障害が起きたのに対応してくれない	瑕疵担保、あるいは保守への対応
5)	障害対応を依頼したらお金を要求された	同上

基本的に、上述の問題は、契約書への記内容で対応が分かれます。

しかし、契約書自体が存在しない、と言う、とんでもないケースも多く見受けられます。

よく、次の様な理由により、ソフトウェア開発に関して、契約書を結ばずに作業を依頼した話をお聞きします。

・収入印紙代がもったいない
・知人からの紹介で、そのまま開発を依頼した
・社長のコネで開発を依頼した
・昔からの知り合いだから、そのまま開発を依頼した

収入印紙に関しては、基本契約書で4,000円、個別契約においては、発注金額により収入印紙代が異なりますが、ソフトウェア開発は、通常は「請負契約」となるため、500万円を超えると、収入印紙代だけで10,000円もします。

収入印紙が無くても、契約書があれば、契約自体は成立します。もったいない感じもしますが、そこは法律です。仕方が無いと諦めるしかありません。(回避する方法もありますが、それは個別に相談を承ります。)

しかし、上述のような問題を回避するためには、契約を締結するしか解決策はありません。

また、契約書が存在しても、記載された条項が、上述の問題に、きちんと対応する必要があります。

つまり、これらの問題は、契約書が存在しない、あるいは契約書は存在しても、契約内容に不備があるために発生する問題です。
それならば、どのような契約書を締結すれば良いでしょうか ?

それは簡単です。上述の様な問題が起きない様に、次の様な条項を含んだ契約書を、最初から作成すれば良いだけです。

1	納期遅延の問題	不可抗力以外の納期遅延の場合、遅れた分だけ料金を差し引く、または損害賠償条項を入れる
2	追加料金の問題	契約締結後には、条件変更は認めない、と言う文言を入れる
3	品質の問題	受入検査方法、および検査期間の条項を入れ、かつ受入検査不合格時に損害賠償できる文言を入れる
4	瑕疵担保の問題	瑕疵担保期間を明確にし、瑕疵担保期間は無償で障害対応を行う、と言う文言を入れる
5	保守の問題	保守はソフトウェア開発とは別契約のため、瑕疵担保期間が過ぎた後、別途保守契約を締結する

簡単ですよね!

「契約書を作成するのが面倒」とか「収入印紙代がもったいない」等と言う、どうしようも無い理由で、契約を締結せずにソフトウェア開発を進め、その挙句の果てに、数々の問題が発生するのは、いわば【自業自得】だと思います。

中には、契約を締結しても、平気で契約内容を踏みにじる企業も存在します。弊社も、そのような企業と取引したことがありますが、後始末が大変でした。

契約内容を踏みにじる企業への対応は、また別の機会に紹介したいと思いますが、企業との取引は、契約書が基本です。

この点を忘れない様にして下さい。

- - - - -

次回ブログでは、受注企業側で起こる問題に関しては、次の点をご紹介したいと思います。

・納品後に、約束通りに入金してもらえるのか ?
・途中で、機能を変更しろと言われないか ?
・途中で、契約を解除されないか ?
・瑕疵担保期間が過ぎても、障害対応をしろと言われないか ?
・約束通りのシステムを納品したのに、機能不足を理由に、費用を値切られないか ?

それでは宜しくお願い致します。

以上

【株式会社 エム・システム】
本      社　 ：〒124-0023 東京都葛飾区東新小岩8-5-5 5F
 　 　 　 　 　 TEL : 03-5671-2360 / FAX : 03-5671-2361
盛岡事業所　 ：〒020-0022 岩手県盛岡市大通3-2-8 3F
 　 　 　 　 　 TEL : 019-656-1530 / FAX : 019-656-1531
E-mail　 　　： info@msystm.co.jp 
URL　　　　　： http://msystm.co.jp/
ブログ       ： http://d.hatena.ne.jp/msystem/ 
Facebook　 　： http://www.facebook.com/msysteminc