【ご相談内容】
当社はシステム開発・制作業を営んでいます。最近トラブルが立て続けに起こったため、社内のリスク管理やコンプライアンス体制のチェックを進めています。
システム開発・制作事業特有の法律問題はどういったものがあるのか、教えてください。
【回答】
システム開発・制作事業の場合、対内的には個々の従業員が単独で作業を行うことが多く、しかも職人的なところがあり、従業員管理が不十分になりがちという特徴があります。また、対外的にはユーザとのコミュニケーション不足に由来するトラブルが起こりやすいこと、システムに不具合が生じた場合はシステム以外の業務に支障を来すことが多く多額の損害賠償問題が起こりやすい等の特徴があります。
以下では、いくつかのシステム開発・制作業の顧問弁護士を務めるなどして、日常的にシステム開発・制作事業者とお付き合いさせて頂いている執筆者の経験事例を踏まえながら、システム開発・制作事業者に注意してほしい法律問題について解説を行います。
【解説】
1.概要
システム開発・制作業特有の法律問題の概観は、上記回答でも記載した通りです。いわゆる経営四資源の考え方をベースに、「人に関する法律問題」、「物に関する法律問題」、「金に関する法律問題」、「情報に関する法律問題」に分類して、その特徴的な問題点を記載します。
2.人に関する問題
(1)ユーザへの現場派遣と偽装請負
ユーザ（客先・委託者）の現場に常駐して、ユーザシステムの運用管理や保守業務を行うことは一般的によくみられる作業方式です。ここで注意しなければいけないのは、ユーザが現場常駐者に対して、細かな業務命令を行っていないかという点です。もちろん、ユーザの要望に応えながら業務遂行する必要がありますので、ユーザの指示を現場で一切受けてはならないという話ではありません。しかし、理屈の上では現場常駐者はユーザの労働者ではありませんので、言われたとおりに機械的に業務遂行するという場合は、偽装請負（労働者派遣法違反）と言われてしまうリスクがあります。
業務上の指示にすぎないのか（適法）、指揮命令に該当するのか（違法）非常に境界線が曖昧なところがあるものの、指揮命令に当たらない体制整備とその運用構築がリスク回避のポイントとなります。
なお、上記問題を解消するために、労働者派遣業の許認可を取得した上で、現場派遣するという方法が取られることがあります。もちろん、このやり方は問題ないのですが、時々、委託者（派遣元）の元発注者の現場で業務遂行するといったことがあったりします。この場合、二重派遣の問題も生じることに注意が必要です。
(2)再委託先（協力事業者）と労働者性
受託した業務を自社内で処理できないため、協力先に再委託するといった多重下請構造があることが、システム業界の特徴となります。もちろん、専門業務は専門業者に任せること自体は問題ありませんが、上記(1)とは逆に、自社が協力先の担当者等に細かな業務命令を行っている場合、実質的には指揮命令を行っているのと同様であるとして、偽装請負や労働者派遣法違反の問題が生じます。
また、協力先が個人事業主（フリーランス等）である場合、特に当該個人事業主が自社との取引に依存している場合、裁量性のない細かな業務命令を行っている等の事情があれば、当該個人事業主は労働者と同様の扱いになるといったリスクも生じえます。この場合、各種の労働法規違反を指摘されると共に（未払い残業の問題が出てくることが多い）、社会保険等の加入を怠っていたことによる制裁など金銭面での負担がかなり大きくなることから、是が非でも避けたい問題です。
業務上の指示か指揮命令に該当するのかの区別に関する正確な知識と現場運用がリスク回避のために必要となります。
(3)人材紹介と契約違反
システム業界は人手が不足しており、人材確保のために人材紹介会社を利用する頻度が高いようです。人材紹介会社と取引すること自体は問題ないのですが、問題は人材紹介契約書に定められている内容です。よく起こるトラブル類型としては次のようなものがあります。
- 紹介を受けた人材を採用したところ数日で出社しなくなった。満額の紹介料を支払うのはおかしいのではないか。
- 紹介を受けた人材の採用を見送ったが、後日、当該人材から接触がありそのまま採用した。その後、人材紹介会社よりみなし報酬の請求を受けたが支払う必要があるのか。
- 紹介を受けた人材のスキル・能力が当社の要求水準に達していない。にもかかわらず、紹介料を支払うのは納得がいかない。
こういったトラブルを回避する場合、人材紹介会社との契約内容を事前に精査し、リスクが認められる条項の修正協議を行った上で契約を締結する等の対策を講じることが必要となります。
(4)専門業務型裁量労働制
システムを開発・制作する個々のプログラマーの業務は属人的なところがあり、一人親方による職人作業のような形になりがちです。このため、なるべくプログラマーの都合に合わせて（労働時間を拘束しない形で）業務遂行してもらおうと、専門業務型裁量労働制を採用するシステム開発・制作会社も見かけるところです。
ただ、専門業務型裁量労働制に定める、例えば「情報処理システムの分析または設計の業務」に、直ちにプログラマーが該当するのか極めて高度な知識が必要となります（執筆者が関与した案件でも、通達等を踏まえる限り非該当になると考えられる事例も少なからずありました）。また、専門業務型裁量労働制を採用していると労働者に告知していたとしても、必要な手続きが実行されていなかった（労使協定の締結等）といった問題も散見されます。
万一、専門業務型裁量労働制が否定された場合、莫大な残業代の請求を受けるといった経営存続危機になるようなリスクが生ずることにもなりかねません。専門業務型裁量労働制を用いるのであれば、正確な知識と運用、適切な手続きの実行が必要となります。
(5)労働時間管理
上記(4)で記載した専門業務型裁量労働制を適切に運用できている場合はともかく、これ以外の場合はプログラマーも一労働者として、適切な労働時間管理を行う必要があります。
しかし、上記でも触れた通り、個々のプログラマーのやり方に任せるほかないようなところがあり、例えば、他の従業員がいる時間帯は集中して作業できないとして昼間は作業せず、他の従業員が帰宅した夜間に作業を行うといったプログラマーも存在したりします。この場合、昼間は働いていないのだから、夜の作業時間だけ勤務したことにし、賃金を支払うといった対応をとることがあるのですが、果たして労働法上そのような対応が適切と言えるのかは疑義があるところです。
万一、会社の対応が否定された場合、多額の未払い残業代が発生することになりかねません。また、プログラマーが体調を崩すなどした場合、安全配慮義務違反を問われることにもなります。プログラマーの希望する働き方に合わせつつ、労働法に違反しない体制整備をどのように構築するのか、専門的な知識を踏まえてのリスクヘッジが必要となります。
弁護士へのご相談・お問い合わせ
当サイトの記事をお読みいただいても問題が解決しない場合は
弁護士にご相談いただいた方がよい可能性がございます。
下の電話番号もしくはメールにてリーガルブレスD法律事務所までお問い合わせください。
06-4708-7988メールでのご相談
3.物に関する問題
(1)成果物の内容＝受託範囲の認識共有
単純な演算だけでは物足りず、様々な機能と高度な電算処理を実装したシステムが日進月歩で生まれてきています。この結果、複雑多様化するユーザの要求事項とシステム開発・制作会社の対応能力にミスマッチングが起こる等のトラブルが続発しています。また、システムに実装したい内容をユーザが上手く言語化できないために、ユーザ要求事項がシステム会社に正確に伝わらないまま開発・制作が進行し、成果物完成後に要求事項が実装されていないといったトラブルも起こっています。
上記のようなトラブルが発生する根本的な原因は、成果物に対して何をどこまで実装するのか、ユーザとシステム開発・制作会社との認識共有が図られていないという点に尽きます。システム開発・制作会社としては、何をどこまで実装するのか、個別具体的に契約書や注文請書に明記することで対策を講じる必要があります。ただ、個別具体的に明記すると口では簡単に言えますが、言語化することが難しい実情もあり、実際には明記できないといったこともあります。この場合、逆転の発想となりますが、システム会社としては、ユーザが勘違いしていそうな事項を読み取ったうえで、あえて受託していない業務を明記するといった対応をとることも有用です。
(2)契約不適合責任と保守との関係性
契約不適合責任という言葉は聞きなれないかもしれませんが、瑕疵担保責任というと耳にしたことがあるかもしれません。2020年4月1日に民法が改正されたため、改正前は瑕疵担保責任、改正後は契約不適合責任という名称変更があったと、とりあえずイメージしておけばよいかと思います（法律論としては色々と変更事項がありますが、法律家以外の方が正確に理解するのは困難な部分がありますので、この点はひとまず置いてください）。
さて、契約不適合責任とは、成果物の完成後に不具合が見つかった場合、システム開発・制作会社が不具合回避のための修正や損害賠償等の責任を負うというものです。ただ、最近のシステム開発・制作の現場実務では、100％完全なシステムはこの世に存在せず、何かしらのバグ等の不具合は発生するという前提に立っています（この点は裁判例を見ていても徐々に認識されているようです）。そのため、システムを完成させ納品したら終了ではなく、納品後は保守・運用管理を引き続き継続して行う契約形態が増えています。この際、バグ等の不具合があることを前提に保守・運用管理契約の範囲で修正を行うこと、すなわち修正を行うことでシステム開発・制作会社の責任を限定しているにもかかわらず、ユーザが契約不適合責任に基づき損害賠償や契約解除等を要求してきた場合、どのように対処すればよいのかという相談が増えてきています。
保守・運用管理を行う場合に、契約不適合責任をどのように整理するのか（契約書上どういった記載にするのか等）、検討及び見直しを行う必要があります。
(3)再委託
システム開発・制作と一口にいっても、内部プログラミングを担当する者もいれば、UIなどを含む外部表示を担当する者がいたりするなど、各専門家が作業分担することで、1つの成果物を開発・制作することが一般的です。このため、システム開発・制作会社は、作業工程内容を切り分け、協力会社に一部作業工程を再委託するというのが当然の流れになっています。
しかし、システム開発・制作に関する契約書などを見ていると、再委託禁止となっていたり、書面によるユーザの同意が要求されていたりするなど、システム開発・制作会社の現場実務感覚とは異なる内容になっていることが多いようです。
再委託が禁止されているにもかかわらず、システム開発・制作会社の都合のみで協力会社に再委託した場合、当然契約違反の問題となります。また、システム不具合等のトラブルが発生した際に再委託禁止違反が発覚した場合、ユーザの怒りをさらに助長させトラブルの拡大・長期化要因にもなってしまいかねません。
システム開発・制作会社の現場実務の常識が契約書に反映されているのか、また当該常識をユーザが理解しているのか、改めて確認する必要があります。
(4)下請法違反
下請というと建設業界をイメージする方も多いかもしれませんが、下請法という法律は建設事業には適用されません。もともとは製造業などを対象とした法律だったのですが、システム開発・制作等の業種も現在では適用対象となっています。
ところで、下請法の問題を検討する場合、自社にとって武器になる場面もあれば、自社にとって爆弾・地雷になる場面があることを押さえておく必要があります。
すなわち、対ユーザとの関係であれば、システム開発・制作会社は下請法による保護を受ける立場となりますので、不合理な契約条件等の修正要請を行う場合の有力な根拠となります。一方、対協力会社（再委託先）との関係であれば、システム開発・制作会社は下請法を遵守しなければならない立場（親事業者）に入れ替わります。このため、対協力会社（再委託先）より下請法を根拠に契約条件等の修正要請を受けた場合、修正に応じなければならない立場となります。
下請法は、システム開発・制作会社（再委託するに際して親事業者に該当）が中小零細事業者であっても、形式的に適用されます。協力会社に無理難題を押し続けた結果、業務受託を拒否され開発・制作が進まなくなったという問題のみならず、下請法違反による法的制裁を受けるといったシステム開発・制作会社の事例も存在します。自社の立ち位置が真逆になってしまうことを認識し、特に協力会社との適切な関係構築を図る必要があります。
4.金に関する問題
(1)契約書の締結の有無（特に契約締結準備段階での見切り発車）
汎用性のない＝ユーザ用にカスタマイズされたシステム開発・制作を行う場合に起こりがちなのですが、システムの完成納期との関係上、ユーザ及びシステム開発・制作会社の現場担当者間ではどんどん話が進んでいき、作業が開始されているにもかかわらず、発注書の交付や契約書の締結等の契約管理が後回しになるということがあります。そして、何らの事由（多くの場合はユーザ都合）でシステム開発・制作の話が頓挫した場合、これまでの作業に対する報酬はどうなるのかという問題が発生し、ユーザとシステム開発・制作会社との間で激しい対立が生じます。
システム開発・制作会社としては作業を進めた以上、作業に見合った報酬をもらって当然と考えがちですが、実は法的には当然に報酬が発生するとは考えにくいところがあります。このような回答を行うと、システム開発・制作会社より「泣き寝入りですか！」「作業はすべて無駄になるんですか！」といった悲痛の声を聴くことになるのですが、気持ちは理解できるものの如何ともしがたい事例も中には存在します。
結局のところは、契約管理が甘かったという話に帰着してしまうのですが、仮に契約書の締結がなかなか前に進まない場合であっても、なぜ作業を開始することになったのか（例えばユーザ側より指示があった等）の経緯や交渉経過をまとめると共に、そのエビデンスを残しておくといった、ちょっとした対応を実践することで、結果に大きな差異が生じるというのが執筆者の実感です。有償で作業を行う以上、請求するための根拠として何が必要となるのかを考えながら行動することが重要となります。
(2)報酬の発生時期
システム開発・制作会社からすれば、システム完成前に報酬を支払ってもらいたいところですし、ユーザとしては、システムが完成した上で不具合等の問題がないことを確認してから報酬を支払いたいと考えますので、大きく利害対立する事項となります。
これについてはユーザと協議の上、支払い時期・方法を定めるほかないのですが、例えば、第三者ソフトウェアを用いる場合などの実費を先行してシステム開発・制作会社が負担する必要がある場合、当該実費分だけでも前払いにするといった落しどころも考えられるところです。
なお、システム開発・制作会社にとって全額前払いしてもらうことのみが常に有用という訳ではないことにも注意が必要です。例えば、支払いを受けた後に、ユーザより仕様の変更要求があった場合、実際のところ追加報酬を請求しづらいといった問題があったりします（法律論ではなく、事実上の心理的抑制力とでもいえばよいでしょうか）。
システム開発・制作の場合、通常は請負契約と考えられますので、成果物であるシステム完成後が報酬の支払い時期になるのが原則です。システム会社が（一部でも）前払いを希望する場合、この原則を変更するだけのユーザ向け説得材料を準備することが重要となります。
(3)中途解約時の清算方法
上記(1)は正式な契約が成立しないまま、開発・制作作業がスタートし途中で頓挫したという場合ですが、ここでは正式な契約自体は成立しているものの、完成前に何らかの事情で契約を途中で解消したという場面となります。
やはりシステム開発・制作会社としては作業を進めた以上、作業に見合った報酬をもらって当然と考えがちですが、実は法的には当然に報酬が発生するとは考えにくいところがあります。特に改正民法では、システム開発・制作会社が途中まで開発・制作することによって生じた未完成成果物について、ユーザに引渡しが可能であり（可分給付）、かつ当該引渡しによってユーザが利益を受ける場合であれば、割合的報酬が可能というルールを定めたため、作業量それ自体を請求することは法律の原則論としては難しいと言わざるを得ません（あくまでも未完成成果物の出来高評価額を基準とするということです）。
したがって、改正民法とは異なる清算ルールを明文化する等の対策が極めて重要となります。
(4)損害賠償の制限
システムの不具合により、他の業務に支障が生じ莫大な損害が生じたとしてトラブルになったという話はニュースなどでも聞いたことあるかと思います（例えば証券取引所のシステムが不具合を起こした等）。システムの不具合が生じた場合、システムそれ自体に留まらず、他の業務にもその不具合が波及し、システム会社にとっては予想もしえない損害賠償請求をされてしまう可能性があることから、リスクヘッジ策として、契約書等で損害賠償額につき制限（損害の範囲を通常損害に限定する、損害賠償額の上限を委託料相当額にするなど）を設けることが通常です。
ユーザからは、損害賠償責任の制限条項について難色を示されることも多いかと思います。どういった説得を行うのかは各社の実情や取引状況に応じて検討するほかないのですが、IPAが公表しているモデル契約書などを一例に出しながら説明を行うというのも1つの考え方になるかもしれません。
なお、損害賠償額の制限につきたとえ双方が合意していたとしても、システム開発・制作会社に故意又は重過失がある場合、損害賠償額の制限に関する合意条項は無効と判断する裁判例が相次いでいます。このような裁判動向を踏まえる限り、システム開発・制作会社として、どういった情報を収集し、どういった検討を行った上で開発・制作したのか、開発・制作に至った判断プロセスの合理性を説明しうる資料を日常的に管理するといった対策を講じるなどして、故意・重過失に該当しないと評価してもらうためのエビデンス確保が必要となります。
5.情報に関する問題
(1)成果物の権利帰属（特に著作権）
意外とシステム開発・制作会社も気にしていない場合も多いのですが、システムに用いられているプログラム等の権利関係については注意を払う必要があります。
例えば、プログラム等に関する著作権について当然にユーザに帰属すると合意した場合、理屈の上では、システム開発・制作会社は同一又は類似プログラムを用いて他社のシステムを開発・制作することができなくなってしまうからです。また、安易にプログラム等の著作権をユーザに帰属させた場合、ソースコードの開示要求を受け、運用保守業務を他社に奪われる又はユーザが内製化することでシステム開発・制作会社が得ようとしていた利益を取り逃がしてしまうといった事態も想定されます。
対価の支払いと著作権の帰属は連動しないことを意識しながら、権利関係の帰属問題に対処することが肝要です。
(2)ノウハウの保護
上記(1)のような著作物に該当するプログラムであれば、著作権法に基づくルールを意識すればよいのですが、著作物に該当しないプログラムやアイデア・ノウハウ等といった知的財産権の対象とならないものについては、その取扱いに注意が必要となります。
例えば、システム開発・制作会社としては、受注確実と勝手に判断し、他社では提案ができないようなアイデア等をユーザに次々提供したところ、当該アイデア等をユーザが他の開発・制作会社に転用し、失注するといった事例もあったりします。この場合、システム開発・制作会社としてユーザや他の開発・制作会社に何か物言えないかと考えることになるのですが、アイデアそれ自体は知的財産権の対象物ではない以上、法律上の権利を行使することは難しいというのが実情です。
秘密保持契約を締結するといった対策はもちろんですが、秘密保持契約の内容としてアイデアやノウハウ等が適切に保護されるのかについても、十分に確認検証する必要があります。
(3)セキュリティ対応（安全レベルの合意、セキュリティルームの設置等）
情報漏洩は重大なコンプライアンス問題であることが認知されて久しいですが、契約締結の条件として、ユーザがシステム開発・制作会社に対し、厳しいセキュリティ対策を要求してくる場合があります。例えば、システム開発・制作会社に対して、ユーザが提供する情報のみを保存するスタンドアローン（インターネットと遮断された）サーバの設置要求や、世界最高水準のセキュリティ対策の実施、物理的なユーザ専用設備の造営など、過剰と言わざるを得ないような内容があったりします。
もちろん、このような要求事項をすべて遵守できるのであれば問題視する必要はありません。しかし、中小のシステム開発・制作会社の場合、要求事項と明記されていることは認識しつつも、実際には遵守できない（遵守するつもりもない）といった事態が横行しているところもあります。当然のことながら、要求事項を満たしていないことが明らかとなった場合はもちろんのこと、万が一にも情報漏洩が発覚した場合、システム開発・制作会社はユーザより厳しい責任追及（情報漏洩の場合、実損よりも対策費用が莫大になる傾向あり）を受けることになり、仕事どころじゃなくなるといった事態も想定されます。また、意図的に要求事項を無視していたとなると、損害保険金の支給も受けることができないといったこともあり得ます。この場合、システム開発・制作会社の存続危機にもなりかねません。
受注することばかりに意識がいってしまい、要求事項を勝手に軽く受け流してしまわないよう自らを律する必要があります。
＜2021年5月執筆＞
※上記記載事項は弁護士湯原伸一の個人的見解をまとめたものです。今後の社会事情の変動や裁判所の判断などにより適宜見解を変更する場合がありますのでご注意下さい。
|
|
弁護士 湯原伸一
