1.事務所について

Q.依頼するのに、紹介者は必要ですか?
IT紛争/IT法務に十分対応できる弁護士へのアクセスは、まだまだ限られているのが実情です。そのため、当事務所では、IT関連の案件については紹介がなくても受任させて頂いています。ただ、事案の内容その他によっては、お引き受けできない場合もありますので、ご了承下さい。
Q.当社はシステムユーザ企業なのですが、受任してもらえますか?
当事務所は、依頼者を限定していませんので、もちろんお受けできます。ユーザ企業の場合、ベンダ企業に比べてITの内容に踏み込んだ交渉力に欠ける場合があり、ご依頼頂くメリットはより大きいものと考えています。実際、ユーザ企業様から、より多くの依頼を頂いています。
Q.当社はシステムベンダ企業なのですが、受任してもらえますか?
当事務所は、依頼者を限定していませんので、もちろんお受けできます。ベンダ企業の場合、自社内にトラブル解決の仕組みや経験があるために、かえって弁護士に相談するタイミングが遅れ、解決の糸口を逃してしまう場合がありますので、早めのご相談をお勧めしています。
Q.依頼することのできない案件はありますか?
当事務所の側からお断りすることは通常はありませんが、利益相反に当たるケース(例えば、紛争の相手方から既に相談を受けている場合)など、法令上お受けすることができない場合があります。また、特殊な知見を要する案件や、受任業務が集中している時期の案件については、やむを得ずお受けできないことがあります。
Q.料金はどのくらいですか?
所定の報酬規程によりますが、大雑把に言えば、訴訟や調停の場合は、経済的利益に応じた着手金(事件への着手時に必要となる費用)と報酬金(事件の結果による成功報酬)の形、それ以外の場合は、タイムチャージ(目安時間を設けておくこともできます)を基本としています。実際の金額は、事案の類型や難易度等によっても変わってきますので、まずはお問い合わせ下さい。

2.取扱い業務について

Q.相談だけでも良いのですか?
もちろん、相談だけでも構いません。むしろ、トラブルが初期のうちであれば、1~2回の相談だけで解決の目途がつく場合も少なくありません。何か問題が生じたら、早めに相談においで頂くことをお勧め致します。また、相談した結果によって、本格的に依頼するかどうかを判断して頂くこともできます。相談料は、初回に限り、割安のチャージレートを設定しています。
Q. いま抱えている事案は、「取扱業務」に載っているメニューにはピッタリ当てはまらないように思うのですが?
「取扱業務」のメニューは、どのようなものか分かりにくいと言われる弁護士のサービスを、説明のために類型化したものですが、実際の紛争解決や紛争防止は、一件一件が「カスタムメイド」のサービスと考えています。当事務所では他にも、IT紛争/IT法務の全般に対応していますので、事案の内容を良く伺ったうえで、最善の解決に向かえるよう提案させて頂きます。
Q.通常の契約書類のチェックのようなこともお願いできますか?
契約書をはじめ、RFPや個人情報保護規程、プライバシーポリシーなどの文書のチェックや作成も行っています。IT系の契約に特化した、契約書のひな形も用意してありますので、短期間でご要望にお応えすることができます。また、継続的なご依頼がある場合は、顧問契約をさせて頂くこともできます。
Q.スポットで依頼するのと顧問契約するのとでは、どういう違いがありますか?
どちらでも案件の進め方そのものに違いはありませんが、顧問契約をいただいている場合は料金に割引があるほか、一般の案件より優先して対応に当たります。また、顧問契約には、継続的な関係の中で組織や業務の状況が分かるほか、トラブル等に至る経緯も把握しやすくなるため、電話やメール一つですぐに初動に入れるというメリットもあります。

3.紛争/トラブル時の対応について

Q.裁判所から訴状が届きましたが、どう対応すればよいのでしょうか?
相手方から訴訟を提起されており、訴訟そのものを回避することはできません。対応せずに放置してしまうと、いわゆる「欠席判決」となり、相手方の言い分が全て認められてしまいますので、注意が必要です。特に、提訴された直後は、呼出状で指定されている第一回口頭弁論期日までに一定の対応を取る必要があり、迅速な対応が求められます。訴訟対応は、本人自らが行うことも可能ですが、法人の場合は代表者か支配人に限られますので、弁護士を代理人に選任するのが通常です。
Q.訴訟をする場合の段取りはどうなりますか?
以下、原告側(訴える側)に立った場合の、中規模のIT訴訟のイメージです。
・ヒアリングや資料の収集・整理と訴状の作成(1か月少々)
・第1回口頭弁論期日(提訴後1か月少々)
・その後の期日(1か月~1か月半に1回程度)
・証人尋問や検証などの証拠調べ
・証拠調べと前後して和解期日
・判決言渡し(最後の期日から2か月程度)
判決まで行くとすると、少なくとも数回以上の期日を重ねますので、1年半から2年、場合によってはそれ以上かかることもあります。その間、証拠調べや和解を除けば、期日に出席頂く必要はありませんが、文書の確認や証拠の調査などをお願いすることになります。ご依頼頂いた場合は、タイムチャートを用いた詳しい説明を差し上げています。
Q.トラブルの相手方から内容証明郵便が届きましたが、どう対応すればよいのでしょうか?
まずは書面に書かれている相手方の主張を十分に理解することです。そして、事実関係の整理、関連するエビデンスの収集、関係者からの聞き取りなどを行ったうえ、相手方の主張の当否を評価し、争っていくか、融和の方向でいくかなど、対応方針を定めます。内容証明郵便が用いられるのは、本来は通知内容(例えば、契約解除の意思を示したこと)を証拠化するためですが、トラブルのレベルが一段階上がったこと、(書面の名義によらず)相手方に弁護士が関与していることを示している場合も多く、慎重な対応が望まれます。
Q.できれば「裁判沙汰」にはしたくないのですが、可能でしょうか?
IT関係の紛争は、訴訟になってしまうと、費用・期間・労力の点で負担も大きく、たとえ勝訴したとしても十分な救済にはならない面があります。そのため、交渉その他での解決や立て直し、あるいは未然防止を指向することが賢明で、当事務所でも、そうした意識で取り組んでいます。もっとも、対立が厳しい状況で訴訟の選択肢を初めから除外してしまうと、そのこと自体が交渉力を下げてしまうことがありますので、状況に応じた解決方法を選択することが必要です。

4.その他

Q.まだ話し合いの最中で決裂したわけではないのですが、弁護士に依頼する意味はありますか?
むしろ、まだ交渉の余地がある早期に相談頂く方が、選択肢が多く効果も上がります。弁護士が前面に出ると対立感が強くなり過ぎるという場合は、「IT顧問」として話し合いに同席したり、バックヤードから助言したりといったこともお勧めしています。
Q.既に顧問弁護士に頼んでいるのですが、重ねて依頼するメリットはありますか?
IT紛争には、考慮しなければならないITの専門的論点が多々あるため、通常のように顧問弁護士に「お任せ」するだけでは難しい場合があります。そのような場合、セカンドオピニオンの形でのサポートが有効と考えています。関与の内容・程度については、柔軟に対応させて頂きます。
Q.地方なのですが支障はないでしょうか?
当事務所は東京所在ですが、地方からのご依頼も多く頂いています。紛争解決にはコミュニケーションが重要ですので、できるだけ直接の面談をお願いしていますが、それほど複雑でない相談対応や契約書類のチェック等であれば、電話やメールのみでの対応も可能です。こちらからの地方出張が必要な場合は、旅費、日当が別途かかります。
Q.弁護士に依頼するのは初めてなので、どうすれば良いのか全く分からないのですが?
取扱業務」に掲載されている紛争事例をご覧になったうえで、早めに法律相談をお受け頂くことをお勧め致します。トラブルの状況を伺ったうえ、法的アドバイスはもちろんのこと、相手方との交渉の可能性、提訴した(された)場合の見込み、今後の進行のバリエーション、必要となる費用まで、詳しくまた分かりやすく説明致します。
Q.IT訴訟なら必ず勝てますか?
残念ですが、必ず勝つことはできません。しかし、より良い結果に向けて最大限の努力を致します。また、勝ち負け以外にも、将来の紛争の未然防止やリスク対策など、何かが残るような取組みを心がけています。

 契約は、契約の申込みとこれに対する承諾によって成立します。保証など一部の類型の契約を除けば、申込みや承諾は口頭でも構いません。
 逆に言えば、契約書がなくても契約は成立するということですが、契約の成否や内容についてのトラブルを避けるために、契約書は必ず取り交わすべきです。万一訴訟となった場合は、重要な証拠となります。
 契約が成立すると、契約当事者(例えば、買手であるユーザと売手であるベンダ)は、契約の内容どおりの権利を取得し、義務を負うことになります。契約に基づく義務は任意に履行するのが基本であり、多少のトラブルが生じても、多くは話し合いで解決されるのが通常です。
 それでも、関係がこじれてしまい、一方が完全に履行を拒むといった事態に陥ることもあります。このような場面でこそ契約の効力が期待されるわけですが、そのままでは契約に強制力はありません。訴訟を提起し、債務名義となる勝訴判決を得て初めて、強制執行することができるようになります。

契約と契約書 TOPICS (6)

契約条項と法律上のデフォルト

 契約書に条項が記載されていれば、法令に違反しない限りはその内容が有効となりますが、記載のない事項については、商法や民法に定められている法律上のデフォルトで補充されます。その意味で、契約書上の各条項は、法律上のデフォルトに対する特約という位置付けとなります。対象となる取引の性質に応じた条項を記載しておくことが望ましいですが、それらの記載がないからといって直ちに問題を生ずるわけではありません。
 他方で、契約の目的物や代金などについては、当然のことながら、法律上のデフフォルトは定められていません。そのため、契約書上の記載が不十分であると、契約内容が不明確となるばかりでなく、それ自体がトラブルの種となります。「営業システム一式」といった契約は、絶対に避けなければなりません。

基本契約書と個別契約書

 同じ相手方と継続的に取引を行う場合、契約書を基本契約書と個別契約書に分けることがあります。基本契約書は、支払条件や解除事由など、全ての取引に共通の条項を規定し、取引の最初に1回だけ(又は取引の類型ごとに1回だけ)締結しておきます。個別契約書は、数量や納期など、取引ごとに異なる条項を規定し、取引の都度締結します。
 基本契約書を用いると、取引条件の標準化が図られるほか、取引の都度条件交渉を行う必要がなくなって省力化を図れるなどのメリットがあります。反面で、基本契約書の条件にはそぐわない取引でも、条件の見直しを行わないまま契約してしまいがちであり、注意が必要です。

注文書による契約

 基本契約書を用いる場合、個別契約書は比較的単純なものになることが多いため、その代わりに注文書を用いることがあります。基本契約書を用いない場合でも、契約そのものが単純な場合には注文書を用いることがあります。注文書(申込み)に対して注文請書(承諾)が発行されて契約成立となるのが本来ですが、承諾は電子メールのような簡易な方法で済まされることも少なくありません。
 いずれにしても、紙(注文書)1枚に納まるくらいに記載事項が少ないことが前提ですが、簡素を求めるあまり、必要な記載事項まで漏らしてしまうことがあります。特に、基本契約書を前提とした注文書の書式を基本契約書なしで用いる場合は、注意を要します。

見積書を引き継ぐ契約

 見積書は契約書ではありませんが、見積金額のほか、一定の契約条件(厳密に言えば見積条件)の記載があるのが通常です。そこで、契約条件については見積書の記載を当てにして、後は条件らしい条件が書かれてない注文書(と請書)だけで契約を締結する場合があります。このような契約方法も有効ではありますが、見積書に記載された条件が契約に引き継がれるのかどうかが不明確なケースが散見されます。少なくとも、注文書に、特定の見積書に記載された条件で注文する、などと明記しておく程度の考慮は必要です。
 提案書やRFPといった文書の場合も、記載されている条件を確実に契約に引き継ぐためには同様の考慮が必要です。

約款による契約

 IT系の契約では、特殊な締結方法が採られることがあります。例えば、媒体のラップを破って開封することで契約成立とするシュリンクラップ契約、ダウンロードやサービス開始のためのボタンをクリックすることで契約成立とするクリックオン契約などです。このような方法による契約も、開封やクリックにより契約が成立する旨と約款(契約条件)があらかじめ示されていれば、有効であると考えられています。
 債権法の改正により、こうした契約の約款の多くは、「定型約款」に該当することになると考えられます。その場合、締結時に現実に約款を示す必要がなくなる(約款による旨が示されていれば、請求があった場合に示せば足りる)一方で、不当条項や不意打ち条項が効力を否定されるといった規律に服することになります。

契約関係の解消

 いったん契約が成立した後は、契約当事者は契約に拘束されますので、たとえ契約から不利益を受ける場合であっても、契約を一方的に破棄することはできません。一方的に破棄してしまうと、そのこと自体が契約違反となり、損害賠償等の責任を問われます。契約の成立後に契約関係を解消することができるのは、当事者双方の合意で解約する場合のほか、契約や法律で定められている解除の要件を満たす場合(例えば、相手方に一定の契約違反がある場合)に限られます。
 もちろん、契約の解消や変更を求めて協議することはできますが、相手方が応じなければ叶いません。契約関係に入る前の段階で、慎重な判断が求められます。

 システム開発の委託契約は、多くの場合、請負契約となります。この場合、ベンダは(システム開発という)仕事の完成義務を負い、これに対してユーザは報酬の支払義務を負います。報酬の支払は、システムの納品と引換えでの後払が原則ですが、開発資金に充てるなどの目的で、約定により、前払や中間金が支払われる場合もあります。
 システム開発契約におけるトラブルとしては、まず、契約書などによる明確な合意がないまま、開発の先行着手がなされたものの、結局は折り合わずに開発中止となる、というケースが挙げられます。中止までの作業の費用負担やその前提としての契約の成否が問題となります。
 開発の進行段階で多く見られるトラブルは、ユーザからの要求が契約の範囲内にあるかどうかが問題となるケースです。範囲内であれば仮にどれほど工数がかかってもベンダはこれに応じなければなりませんが、範囲外であれユーザは別途の追加発注として費用や納期の変更を受け入れなければなりません。このような場合、契約書に添付された仕様書や、開発過程でのドキュメントが重要な判断資料となります。
 システム開発が途中で頓挫し、あるいは品質不良が判明する、というのが最も深刻なトラブルです。このような場合、ユーザはなお開発の続行を求めることもできますが、契約を解除した上で前払報酬の返還や損害賠償を請求することも選択肢となります。もっとも、こうした状況では逆にベンダから、責任原因はユーザ側にあるなどとして、未払報酬や損害賠償の請求がなされることも少なくありません。 

システム開発契約 TOPICS (6)

請負契約

 請負契約は、準委任契約と異なり、受託したベンダは仕事の完成(システム開発の業務を予定された工程まで終えること)が求められます。また、完成後も納品後1年間は、瑕疵(バグ等の欠陥)担保責任として、瑕疵の修補、損害賠償、状況によっては契約の解除を受ける責任を負います。
 なお、請負契約では、仕事の完成が必要であることから、原則として出来高報酬は認められません。もっとも、成果の一部だけでもユーザに利益となる場合は、出来高的な報酬が認められることがありますが(債権法改正で明文化されます)、成果の引継ぎが困難なシステム開発では、分割検収などの場合を除けばかなり例外的と考えられます。

多段階契約と再見積

 中小規模の開発の場合は、開発全体を一個の契約で行う「一括請負」の契約もありますが、比較的大規模の開発の場合は、工程ごとの見積と契約を繰り返す多段階契約とすることが推奨されています。
 多段階契約には、開発の進行を踏まえた精度の高い見積を行える利点がある反面で、開発総額や最終納期に歯止めがないこと、履行や責任の単位が細かく区切られること、開発が完了するまで契約が継続する法的な保証がないことなど、ユーザにとって注意が必要な点があります。

開発基本合意書

 多段階契約を採用する場合、主にユーザ側のリスクを軽減するために、開発総額や最終納期の目処を置くなど、開発プロジェクト全体に関する基本合意をしておくことがあります。法的な拘束力はあくまで個別契約によって生じるため、額面どおりの効力があるわけではありませんが、契約の解釈上一定の意味があると考えられています。
 多段階契約とする場合でも、最終的にはシステムの完成を目指している以上、開発プロジェクト全体の目標について内々の握りはしているものですが、開発基本合意書は、それを紳士協定から一歩進めたものと位置付けることができます。

発注内示書

 システム開発契約は高額の契約となることが多く、契約の交渉や締結も慎重となりますが、ユーザの都合で稼働時期が既に決まっており、正式の契約締結を待っていたのでは開発が間に合わないことがあります。そのような場合、やむを得ず、ベンダが開発に先行着手するに当たり、リスク軽減のためにユーザに求めるのが発注内示書です。
 ただ、正式契約の締結前であることから、結果的に開発が取り止めとなる不確実性は残っており、そのような場合、中止までの作業の費用精算を巡ってトラブルとなることが少なくありません。発注内示書は、契約書に代わる確実なものとまでは言えませんが、先行着手がユーザの求めによるものである(したがってベンダの営業行為ではない)ことを示す根拠となり得ます。

検収と報酬支払

 検収(検査合格)は法的な概念ではありませんが、契約上あるいは実務慣習上、支払の前提手続とされているもので、完成に代わる(あるいは完成を推認させる)報酬発生の条件と位置付けられます。
 検査によって完成を確認するという意味があるため、検収未了のうちは報酬が支払われないのが原則ですが、既にシステムが納品されているにもかかわらずユーザの都合で検査が行われないような場合は、報酬が認められることがあります。契約書にあらかじめ、納品後一定期間内に検査結果の通知がなければ検収とみなす「みなし検収」条項を入れておくこともあります。

プロジェクトマネジメント義務と協力義務

 システム開発プロジェクトの成功には、ベンダとユーザの協働が不可欠です。そのため、ベンダには所定の開発手法や作業工程の遵守、進捗管理や阻害要因への対処といったプロジェクトマネジメント義務が、ユーザには必要な資料や情報の提供、要件や仕様の決定といった協力義務が、裁判例でも認められています。
 これらはプロジェクトの確実な遂行のために認められているものですので、契約書に記載がある場合ばかりでなく、プロジェクト遂行の必要な場面場面で、ベンダとユーザのそれぞれの立場や役割にふさわしい義務が生じるものと考えられています。

 IT系の業務委託契約としては、システム開発やインフラの敷設といった請負類型のものも重要ですが、実数として(圧倒的に)多いのは、準委任類型のサービス系の契約です。多くの場合、期間に応じた報酬体系となっており、サービス業務が提供される限りはそれに応じた報酬の支払義務が発生します。
 サービス契約の場合、システム開発契約のように、合意が不明確なままに着手されることは通常はありません。ただ、新規開発のシステムの開発ベンダが稼働後に保守を担当する場合、稼働当初は不具合の対応に追われるなどして、開発契約から保守契約への切替の時期が不明確となるといったことはあります。
 サービス遂行中のトラブルの場合、その内容や程度によっては契約を解除することができますが、あくまで将来分を解除するにとどまり、遂行済みの部分を解除して報酬の返還を請求することはできないのが原則です。ただし、遂行結果に問題があり、それに起因して損害が生じている場合は、損害賠償請求することができます。

サービス契約 TOPICS (5)

準委任契約

 準委任契約は、請負契約と異なり、仕事の完成ではなく、業務の遂行に対して報酬が支払われます。また、受託者は、瑕疵担保(契約不適合)責任のような、業務の結果に対する責任は負いません。
 もっとも、債権法改正により、準委任であっても成果に対して報酬が支払われる類型が設けられました。仕事の完成を要しない点ではあくまで準委任ですが、請負に接近するものと位置付けられます。要件定義や現状調査のような無定形の成果のある業務の委託に用いられることになると考えられます。

SLA(Service Level Agreement)

 あるサービスを提供する事業者(ベンダ)とその利用者(ユーザ)との間で、サービス契約に付随して結ばれるサービスレベルに関する合意をいいます。サービス契約におけるサービスレベルの保証水準を表したものと言え、多くの場合、この保障水準を達成できない場合の(段階的な)ペナルティが定められていることが特徴です。
 準委任のように品質に対する担保責任のない契約類型において、サービスの品質についての契約上の穴を補充する意味があります。逆に、請負のような担保責任のある契約類型のサービスに設定されることもありますが、この場合は品質基準を明確化することに意味があると言えます。

情報システムの運用・保守契約

 情報システムの開発契約と並んで、大半の企業が経験するIT契約の代表と言えます。基幹システムであれば、オンサイトで情報システム部員と協働することが多く、業務委託ではなく派遣労働に頼ることも少なくありません。
 通常は準委任契約ですが、保守の中にはプログラムの改修など、請負の性質を持つ業務も含まれるため、約定に注意を要します。また、人数、日数、時間数にどのような制約を置くのか(置かないのか)、それらと報酬はどのように連動させるのか(させないのか)、運用・保守業務の内容をどのように範囲付けるのか(付けないのか)も、重要です。

SES(System Engineering Service)

 IT業界で古くからあるサービス業務で、多くの場合、企業やプロジェクトの現場に常駐して技術系のサービス業務に従事します。サービス内容は、情報システムの開発や保守、コンサルティング、技術支援等、多岐に渡ります。
 一般に準委任形態の業務委託と位置付けられていますが、実態として委託者側からの指揮命令を受けているのではないかと疑われる場合もあります。そのような場合は、派遣法の厳しい規制を潜脱する、いわゆる偽装請負の問題となります。

SEO(Search Engine Optimization)

 検索エンジンの検索結果において、ウェブサイトがより多く露出されるようにするために行う最適化の取組みを言います。ターゲットとするキーワードの選定、当該キーワードでのランキングの上昇、クリック率の向上等を通して、サイトへの流入やサイト経由の売上といった目的達成を図るものです。
 SEOは自社でもできますが、一定の知見や手間を要することもあり、多くのベンダがサービスとして提供しています。本来は成果を保証しない準委任契約ですが、成果に目が行きがちなユーザとトラブルになるケースが少なくないため、成果と連動した報酬とすることもあります。