20:02請負契約におけるサービスや成果物に追加が発生した時の考え方を教えていただけたら幸いです。おいては特に、さまざまな理由で発注元から請負側へ追加要求が行われることがあたりまえになっていますので、想定される追加部分については双方どの程度のサービスや成果物追加までなら許容するかを予め取り決めておくのが一般的だと思います。実はそれを満たさなければ、初期計画時に規定した機能も満たせないような場合はどう処理すればよいのでしょう。契約を取り交わし、仕事を進めていくうち、旧システムからのデータ移行が必要であることが分かったような場合です。実際はどうなるのでしょうか。出来れば、法律の専門家に教えていただけるとありがたいです。詳細リンク(3.0)法律の専門家ではありませんがご参考にして下さい。システム開発では最終目的を満たすために必要となる動作条件や作業項目は請負側が提示しなければなりません。例のような場合、既にデータがあるシステムの移行なので、たとえ契約書に文言が無かったとしてもデータ移行は要件の範疇だと思います。(文言の有無を言い始めると契約書が限りなく膨大になります)開発側には厳しいですが、意図的な契約後の作業追加を防ぐ為には仕方無いと思います。発注者が必要な情報を正確に伝えていない場合は協議の余地があると思います。移行作業を発注者が行える環境であればどちらが実施するか協議の余地はあります。このようなグレーな部分は、契約書の協議の取り決めや最悪裁判所の指定に従って進めるしか無いと思います。因みにデータ移行レベルの話しでしたらmtさんのご認識の通り確認不足として開発側が面倒を見るケースがほとんどだと思います。その場合でも、もしも正確な見積を提出していたのであればデータ移行作業などは完全に開発側負担で、発注側が得をしている事は発注者から見ても明らかです。発注者が開発会社を長期的なパートナーと考えて頂けているのであれば、温情的に別の条件と交換してもらえるかもしれません。このような協議を行っても話しが進まない場合は法律の専門家へ具体的な情報を全て提示し相談する必要があります。専門家でも実際の契約書及びその関連書類・やり取りのメール等をかき集めないとご質問1〜3のような内容へ断定的な回答はできないと思います。(TV番組にありますが法律の専門家でも解釈がよく別れますね)mtさんの仰るように「追加要求が行われることはあたりまえ」となりつつあるシステム業界ですが、どのようにすれば追加要求を出にくくできるのかを日々考えています。今後も情報発信を続けたいと思っています。評価・お礼mtさん日付も切り替わる時間帯のご対応、大変恐縮です。今後は登録の時間帯を配慮するようにいたします。仰るとおり、データ移行は契約書が完璧でなくとも作業実施が必須になってくるということは理解できますね。システムにはロジックの実装だけでなく、データも必須ですから。その意味でわたくしの質問における「データ移行」というのは不適切でした。請負人である開発サイドは、システムの実現に至るまでのアクティビティを一通り熟知していることが業界で要求・認知されているとしたら明記されていないものについても漏れなく吟味するべきで、作業項目を外す意図があるなら最低でも契約書に明記するべきということになりそうですね。ない場合は無償対応のリスクがあると。実施してもなお、履行遅滞となってしまう場合)には、確認書または覚書のようなもの(タイトルは何であれ書面)を交わすべきなのではないかと思った次第です。日本の慣習からは、濱田様の仰るように温情的措置で双方の痛みを最小限にするように計らわれることも多いでしょうね。契約の上書きは、一般的ではなさそうに感じてきました。ITコンサルタント)代表取締役この専門家に相談する090-6002-4611※お電話の際は「"プロファイル"を見た」とお伝え下さい。「金をかけたのに使えない」これらはシステムを導入した企業からよく聞かれる言葉です。致命的な問題を回避し、高いパフォーマンスが得られるシステムを導入できる手法を書籍でも紹介しています。お陰様で高い評価とご満足を頂いております。質問やお悩みは解決しましたか?解決していなければ...※あなたの疑問に専門家が回答します。質問の投稿と閲覧は全て無料です。詳細リンク(2.0)こんにちは。ホロデックスの村本です。わたしも法律専門家の立場としてではありませんが、業界人として回答させていただきます。***結論として、「一般的な考え方」というものはないと思って頂く方が、現実的だと思います。その起こった問題に対する対応という個別事象の問題ですし、立場によってゴールをどこに持って行くかが変わっていくと思います。ご質問者の立場は、コンサルタント?発注者?開発請負者?どこにあるのでしょうか?いずれにしても、まずこのような問題が発生した場合、作業見積を請負者は出して、発注者&コンサルタントとの話し合いからスタートだと思います。どのような追加事象にしろ、責任問題の前に、いつどのようなカタチでシステムを稼働させるか?という問題を解決するべきです。**発注者&コンサルタント側としてはいくら金をかければ、問題のない期間までに、システムを稼働させるかが大事です。その対応として「途中検収して、契約打ち切り。システム完成後、いずれかのカタチでの請負会社に金銭の支払いあるいは請求」となるでしょう。**請負側としては通常「追加契約」は、発展的な場合です。ご質問のケースは現実問題として非常に少ないとは思いますが、もし発生したら、その発注会社との関係を維持するのか、しないのか?で、ゴールは変わってきます。作業費をどう考え、そのコストをどう発展的に補填していくかが課題でしょう。私見ですが、「責任問題」として解決のスタートをきるべきではないと思います。追加コメントいただきありがとうございます。お立場とお気持ち、もっともなことと存じます。「2」のケースについては、通常よくあるパターンとしては、契約書には「解除」にあたるケースとして記述される場合が多いと思います。記して対応される企業もございます。追加コメントの中に指摘されたように、「協議事項」として話し合いにし、「3」をゴールにしたいというのであれば、もともと「契約」というのは、双方がお互いに納得するためにあるツールです。お考え通りで良いのではないでしょうか?評価・お礼mtさんご回答をありがとうございます。発注側でも担当者はプロジェクトマネージャであり、したがって、契約、調達、リスク管理に関する質問になります。いうのはまさしくその通りと思っております。準備する上で有効であり、どのような対応を採るにせよ、欲しい情報です。請負人との交渉に際しても、スポンサーに対応内容の根拠を説明するにしても、法的なルールは客観性の極みであり、最大の説得力を持つものであるからです。村本様の>「途中検収して、契約打ち切り。初期契約に相当する作業も切り捨てることになります。疑問、そして手続きとして?のような考え方で妥当なのかという視点でクリアに出来たら幸いです。「本来はこのようなルールですが、それでは双方にとって不幸なので、このようにしませんか。」と話し合いを持ちたいわけです。わたくしの表現不足につきましてはなにとぞご容赦ください。詳細リンク(4.0)おっしゃっておられる通り、詳しいことは法律の専門家にお聴き頂く必要があると思いますが、ベンダーと発注者側の間にはいるITコーディネータとして、コメントさせていただきます。ご期待されている回答にはならないと思いますが、何卒ご容赦願います。契約書にて、何をするかを明確にしているわけですから、追加要件が出れば、原則として追加料金が発生します。2.契約書には要件のみが記載されている場合この場合は、要件を達成することが契約条件ですから、追加作業が発生した場合のコストは、原則として開発者側が負担することになります。事前に十分な情報開示がなかく、開発者側で予見できなかった場合はこの限りではありません。いずれにせよ、初期の契約内容通りに納品できなくなるのであれば、条件変更が発生します。その場合、費用等の条件は話し合いになるはずです。開発者側と発注者側で十分な二信頼関係を築くことが成功の条件と思います。法的係争まで発展すると、法的対応最低限のラインしか成果物の完成度は出てこないでしょう。「書いていないけどこれくらいはできてほしい」と思っていることについては、契約書に記載していないのであれば履行する必要性は低いという解釈も成立します。なると、当初のシステム開発目的を達成できないが、費用は払わねばならないということも起こりえるわけで、できるだけ法的な争いに発展させることは避けるべきかと思います。システム開発の問題は開発者側に一方的に責任があるということはまれです。発注者側にも責任の一部があることが多いこともあり、法的係争の焦点となることがある様です。契約書に仕様が詳細に記述されている場合:注文者が追加負担しなければならない可能性が高い。契約書に要件が記述されている場合:請負人が負担しなければならない可能性が高い。(2)両者予想外の追加が初期契約の履行遅滞につながる場合これは、契約変更が必至ということですね。その内容は(1)における前者、後者の状況やビジネス的な関係によって幾通りにもなるということですね。落としどころまずは、岡本様の「開発者側と発注者側で十分な信頼関係を築くことが成功の条件と思います。」ということなのでしょう。契約内容を吟味するとともに、請負人との関係を充分配慮することにします。ご回答をありがとうございました。詳細リンク(4.0)弁護士さんとこのようなケースをなんどかクライアントでうけもった経験です。>1の答え難しいです。通常は、なぜ移行作業が必須だと、「立証」する必要があるからです。(常識だからでは難しい)>2の答え織り込んだ時点で、新しい契約です。元の契約書を部分上書きできます。>3の答えこれも、よくあります。契約をする前に、一度専門化に見て貰ってください。再契約したことで不利になる場合もあるからです。弁護士さんも向き不向きがありますので、ITを知らない弁護士さんの場合は苦労するでしょう。意外な落とし穴ですが、「裁判官がITをわかるか」というところも結構重要だったりします。(自分で選べませんが)結局判断するのは裁判官ですから、裁判官に、ITを知らなくても、これは当然だと思わせる事ができる弁護士でないと、泥沼化するおそれがあります。訴訟はもの凄くコストと労力がかかります。期間として一年は最低覚悟してください。(立証する為の資料作りも自分の仕事になります)200-300万の損害なら(くやしくても)、示談する方向が、結局は得になります。常に「発注スキル」を磨いていく必要があると思います。それか、第三者的に開発を見てもらえる「コンサルタント」を挟んで開発するかです。最終的に納期などもきちんと管理されコスト的に得をします。僭越ながら弊社でも、そのような管理サービスをしておりますので、ご要望があればお気軽にご相談ください。評価・お礼mtさんご回答をありがとうございます。このような、具体例に基づく断定的な回答が非常にありがたく、本心から求めるところでございます。システム開発においてはあらゆるリスクを排除する必要があり、常に回避されるべき法的な争いも、そのこと自体が大きなコスト上のロスとスケジュール遅延を発生するリスクとして捕らえなければなりません。ピーク時200人月程度の参画者が予想されるような案件において、契約うんぬんで揉めることで一ヶ月遅延すれば2億円以上の損失が発生します。両者折半となっても大きな痛手です。従って、現実に抗争となった場合の法的解釈と根拠をここで確認し、それをもとにビジネス的な立ち回りの考え方、契約の配慮点を検討しようと思った次第でした。本件については契約におけるほんの一つの例に過ぎないわけですが、皆様の一連のご回答に含まれていたようないくつもの注意点、考え方等を得ることとなりました。これ以外にも契約に関する疑問点はたくさんございます。システム開発においては契約ばかりが疑問点を生み出すものではなく、それ以外にいくつもの悩みが生じてまいります。解決にあたっては手段を選ぶことなくあたるつもりですし、そもそも解決しなければならない状況にならないように助言をいただく機会があればそれも検討していこうと思います。