IT法務関連のよくある質問です。
・行政書士の業務内容を教えてください。
・良い契約書とはどのようなものでしょうか。
・客先との関係で契約書を交わせない場合はどうしたらいいのでしょうか。
・アプリケーションを開発業者に委託して開発したのですが、開発業者が著作権を主張しています。自社でお金を出して開発したものなので納得がいきません。
・システムを開発する場合、従来から保有していた汎用モジュールや、新規に発した汎用性のあるモジュールの著作権の帰属はどうしたらいいでしょう。
・著作権の対象はなんでしょう。
・著作権の譲渡において注意する点はなんでしょう。
・戦略的な契約書を作成するにはどうしたらいいでしょう。
・ソフトウェアの法的責任にはどのようなものがあるでしょうか。
・委任と請負の違いはなんでしょうか
・プログラム登録（著作権）とはなんですか。
IT法務関連でご質問・ご要望などございましたら、お気軽にお問合せください。
（TEL&FAX 043-207-0037 フォームでのお問合せはこちらから)
Q2.良い契約書とはどのようなものでしょうか
Ａ． よい契約書とはなんでしょうか。人によって異なると思いますが、それを考えるためには、契約書の役割を考えてみる必要があります。契約書は大きく４つの役割を持っています。
１．当事者双方の合意内容の確認・承認
契約書の第一義は、当事者が合意した取引内容（特に経済的な取引内容）を相互に確認・承認することです。後から何を合意したかわからない契約書など何の役にも立ちません。
２．法律の任意規定の内容を自分サイドに少しでも有利になるように修正する道具
当事者間で合意した契約内容は、強行法規に反しない限り、民法や商法などの法律で定められている規定よりも優先されます。契約の内容は本来「契約自由の原則により」当事者間で自由に決められます。ただしまったくの自由意思で決定できるわけでなく、法の強行規定に反するような条項は認められません。反面、任意規定は、当事者の意思により変更することができます。
そこで任意規定に関する事項を、自社に有利に規定した条項（例：瑕疵担保期間を短く規定する等）を盛り込むことにより、自社にとって少しでも有利にすることが可能です（当然ながら相手も同じことを狙ってきます）。
＊法律の条文には、強行規定と任意規定があります。
強行規定：必ず守らなければならない規定
任意規定：当事者の意思が法律の規定と異なっていた場合、当事者の意思が優先する規定
３．予想される揉め事に対する当事者間の紛争予防規範
あらかじめ予想される揉め事に対し、制定法や判例法などで対応するのではなくて、当事者間で自分たちの解決基準（紛争予防規範）を決めておくことにより、どういう結論がでるかわからない裁判所の判決に任せるというリスクを低減することができます（裁判官は法律の専門家であってＩＴの専門家でない）。
裁判になると第三者の裁判官に対して、取引内容から理解してもらう必要があり、膨大な時間とコストがかかります（生産性のない後ろ向きの時間とコスト）。その上どのような結論が導き出されるかわかりません。
４．残念ながら裁判所の判断を仰がなければならない場合の証拠書類
揉め事が発生して当事者間で合意が得られなくなった場合、裁判所の判断を仰がなければならなくなります。裁判所は契約書等の証拠を元に判断することになります。
上記のような役割をはたせる契約書のことを、良い契約書というのかもしれません。
１．当事者双方の合意内容の確認・承認
契約書の第一義は、当事者が合意した取引内容（特に経済的な取引内容）を相互に確認・承認することです。後から何を合意したかわからない契約書など何の役にも立ちません。
２．法律の任意規定の内容を自分サイドに少しでも有利になるように修正する道具
当事者間で合意した契約内容は、強行法規に反しない限り、民法や商法などの法律で定められている規定よりも優先されます。契約の内容は本来「契約自由の原則により」当事者間で自由に決められます。ただしまったくの自由意思で決定できるわけでなく、法の強行規定に反するような条項は認められません。反面、任意規定は、当事者の意思により変更することができます。
そこで任意規定に関する事項を、自社に有利に規定した条項（例：瑕疵担保期間を短く規定する等）を盛り込むことにより、自社にとって少しでも有利にすることが可能です（当然ながら相手も同じことを狙ってきます）。
＊法律の条文には、強行規定と任意規定があります。
強行規定：必ず守らなければならない規定
任意規定：当事者の意思が法律の規定と異なっていた場合、当事者の意思が優先する規定
３．予想される揉め事に対する当事者間の紛争予防規範
あらかじめ予想される揉め事に対し、制定法や判例法などで対応するのではなくて、当事者間で自分たちの解決基準（紛争予防規範）を決めておくことにより、どういう結論がでるかわからない裁判所の判決に任せるというリスクを低減することができます（裁判官は法律の専門家であってＩＴの専門家でない）。
裁判になると第三者の裁判官に対して、取引内容から理解してもらう必要があり、膨大な時間とコストがかかります（生産性のない後ろ向きの時間とコスト）。その上どのような結論が導き出されるかわかりません。
４．残念ながら裁判所の判断を仰がなければならない場合の証拠書類
揉め事が発生して当事者間で合意が得られなくなった場合、裁判所の判断を仰がなければならなくなります。裁判所は契約書等の証拠を元に判断することになります。
上記のような役割をはたせる契約書のことを、良い契約書というのかもしれません。
Q3.客先との関係で契約書を交わせない場合はどうしたらいいのでしょうか
Ａ． 契約は口約束でも成立することになっています（申し込みと承諾で成立します）。しかし現実のビジネスにおいて口約束だけで契約を結ぶことは危険です。トラブルになったとき立証することが大変だからです。
ただし、業界や人によっては、契約書という形で文書にすることを嫌がることがあります。その場合、覚書や合意書などを利用することを検討してみてはいかがでしょうか。一般的には覚書・合意書は契約書の内容を補足する書面として用いられます。ただし法律的にはタイトルが契約書でも覚書・合意書でもきちんと内容が書かれており署名押印がされていれば、同じ効力があります。契約書という文書では締結してもらえなくても覚書・合意書等のというタイトルなら締結してもらえる場合もあると思います。
お互いの信頼関係からビジネスが成り立っており、残念なことに覚書・合意書というタイトルでも契約を締結してもらえない場合はどうすればいいのでしょうか。
その場合は議事録等を活用することでリスクの低減を図る必要があります。証拠力という面では文書による契約（契約書・覚書など）と比べると弱いことは否めませんが、証言などよりは証拠力として高いといえます。
議事録では逐語的に記載されているだけではなにが決まったのか分かりづらいので、決まった事項が明確になるようにし、内容を確認後、相手の署名押印があるといいでしょう。また記載内容に誤りが無いという意思表示がわかる形での署名押印なら証拠力が高まります。
ただし、業界や人によっては、契約書という形で文書にすることを嫌がることがあります。その場合、覚書や合意書などを利用することを検討してみてはいかがでしょうか。一般的には覚書・合意書は契約書の内容を補足する書面として用いられます。ただし法律的にはタイトルが契約書でも覚書・合意書でもきちんと内容が書かれており署名押印がされていれば、同じ効力があります。契約書という文書では締結してもらえなくても覚書・合意書等のというタイトルなら締結してもらえる場合もあると思います。
お互いの信頼関係からビジネスが成り立っており、残念なことに覚書・合意書というタイトルでも契約を締結してもらえない場合はどうすればいいのでしょうか。
その場合は議事録等を活用することでリスクの低減を図る必要があります。証拠力という面では文書による契約（契約書・覚書など）と比べると弱いことは否めませんが、証言などよりは証拠力として高いといえます。
議事録では逐語的に記載されているだけではなにが決まったのか分かりづらいので、決まった事項が明確になるようにし、内容を確認後、相手の署名押印があるといいでしょう。また記載内容に誤りが無いという意思表示がわかる形での署名押印なら証拠力が高まります。
Q4.アプリケーションを開発業者に委託して開発したのですが、開発業者が著作権を主張しています。自社でお金を出して開発したものなので納得がいきません。
Ａ． 著作権法では、著作者物の著作者の著作者に著作権が発生することになっています。
企業の業務で作成されたプログラムの著作権はそれを開発した企業が持つことになります（著作権法第15条）。そのため契約に何も記載がなければ、ユーザは著作権を取得することができません。
対抗するには契約で著作権を開発業者からユーザへ譲渡する項目をいれる必要があります。ただし、その場合も著作者人格権（著作者が氏名を表示できる権利等）は移動することはできません（Q7.も参照）。
企業の業務で作成されたプログラムの著作権はそれを開発した企業が持つことになります（著作権法第15条）。そのため契約に何も記載がなければ、ユーザは著作権を取得することができません。
対抗するには契約で著作権を開発業者からユーザへ譲渡する項目をいれる必要があります。ただし、その場合も著作者人格権（著作者が氏名を表示できる権利等）は移動することはできません（Q7.も参照）。
Q5.システムを開発する場合、従来から保有していた汎用モジュールや、新規に発した汎用性のあるモジュールの著作権の帰属はどうしたらいいでしょう。
Ａ． システムを開発する場合、従来から保持していた汎用モジュールや新規に開発した汎用モジュールの帰属はなにもしなければ、著作者である開発ベンダーに帰属します。ただしそれではユーザ企業に不利益が発生することがあります（システムの改修もできなくなる可能性もあります）。
そこで具体的な著作権の帰属は契約で定める必要があります。例えば、ベンダー側に既存モジュールの権利留保し、新規モジュールは権利移転の後、使用許諾を取得し、ユーザ側は既存モジュールについては使用許諾をもらい、新規モジュールは権利を取得する等が考えられます。利害関係がぶつかりますので慎重に対応する必要があります。実際は権利者同士で自分たちが使いやすいように検討して、契約書に盛り込みます。
そこで具体的な著作権の帰属は契約で定める必要があります。例えば、ベンダー側に既存モジュールの権利留保し、新規モジュールは権利移転の後、使用許諾を取得し、ユーザ側は既存モジュールについては使用許諾をもらい、新規モジュールは権利を取得する等が考えられます。利害関係がぶつかりますので慎重に対応する必要があります。実際は権利者同士で自分たちが使いやすいように検討して、契約書に盛り込みます。
Q7.著作権の譲渡において注意する点はなんでしょう
Ａ． 開発ベンダーから著作権を譲渡してもらう場合、契約書の中に著作権（著作財産権）の譲渡を規定する必要があります。但しその際注意が必要です。
単なる『著作権に関する一切の権利を譲渡する』と記載するだけでは、著作権法２７条（翻訳権、 翻案権等）、２８条（二次的著作物の利用に関する原著作権者の権利）の権利は移転しません。契約書でそれらの権利も含んで譲渡すると明記する必要があります。
著作権（財産権）の移転はこれで移転しますが、もう一点気をつけなければならない点があります。それは著作者人格権といわれる権利です。
著作者の権利は、著作権（財産権）と著作者人格権の２つの権利があります。著作人格権とは、著作したものに与えられる権利で、
公表権 ：著作物を公表する・しないを決める権利
氏名表示権 ：著作者として氏名を表示する・しないを決める権利
同一性保持権：著作物の同一性を保持できる権利
（プログラムの場合例外規定があります）
の３つの権利が認められており、また著作人格権は譲渡することができません。
例えばベンダーは氏名表示権でプログラム中に自己の社名を表示させる権利や、同一性保持権で改変を禁じる権利を持ち続けるため（特に別のベンダーにバージョンアップさせる場合問題がでる可能性があります）、後々しこりが残る可能性があります。
後々のトラブルを防ぎたい場合は、「著作者人格権は行使しない」旨を契約上に記載しておいたほうが安全です。
単なる『著作権に関する一切の権利を譲渡する』と記載するだけでは、著作権法２７条（翻訳権、 翻案権等）、２８条（二次的著作物の利用に関する原著作権者の権利）の権利は移転しません。契約書でそれらの権利も含んで譲渡すると明記する必要があります。
著作権（財産権）の移転はこれで移転しますが、もう一点気をつけなければならない点があります。それは著作者人格権といわれる権利です。
著作者の権利は、著作権（財産権）と著作者人格権の２つの権利があります。著作人格権とは、著作したものに与えられる権利で、
公表権 ：著作物を公表する・しないを決める権利
氏名表示権 ：著作者として氏名を表示する・しないを決める権利
同一性保持権：著作物の同一性を保持できる権利
（プログラムの場合例外規定があります）
の３つの権利が認められており、また著作人格権は譲渡することができません。
例えばベンダーは氏名表示権でプログラム中に自己の社名を表示させる権利や、同一性保持権で改変を禁じる権利を持ち続けるため（特に別のベンダーにバージョンアップさせる場合問題がでる可能性があります）、後々しこりが残る可能性があります。
後々のトラブルを防ぎたい場合は、「著作者人格権は行使しない」旨を契約上に記載しておいたほうが安全です。
Q8.戦略的な契約書を作成するにはどうしたらいいでしょう
コンピュータシステムが企業にとってインフラになっている現在、ひとたびトラブルが発生すると、業務に大きな影響を与えることになり、その逸失利益や信用喪失は膨大なものとなります。その膨大な損害賠償を請求された場合、経営に大きな影響を及ぼす可能性もあります。反面バグのまったく無いシステムを開発することは、事実上不可能といわれています。更に最近は他社のモジュールなどを組み合わせてシステムを構築することを考えれば、トラブルを１００％防ぐことは難しいといわざるをえません。また今後は知的財産権の侵害などで訴えられることもあるやもしれません。
システム開発はこのようなリスクを伴う業務ということをあらかじめ認識し、そのリスクを少しでも減少させる戦略性のある契約書を作成しなければなりません。
戦略的な契約書を作成するにあたっては、瑕疵担保責任、損害賠償、解除条件などに工夫をする必要があります。これらの条項はベンダー側かユーザ側かで記載したい内容が大きく異なります。
ベンダー側から見た場合、瑕疵担保の期間は短く・責任を負うべき範囲を限定的にする特約や、損害賠償についても、なるべく損害賠償義務を負わない特約や損害賠償義務の上限を限定する特約を入れ、リスクの低減を図りたいはずです。（例えば損害賠償の上限は契約金額を上限にする特約を入れるなど）。ユーザ側からみたらその反対の特約をいれたいはずです。
瑕疵担保や損害賠償についてはユーザとベンダーの利害は相反するものとなります。契約金額・リスク・顧客との関係など検討し、リスク対応を考慮した契約書を作成する必要があります。
システム開発はこのようなリスクを伴う業務ということをあらかじめ認識し、そのリスクを少しでも減少させる戦略性のある契約書を作成しなければなりません。
戦略的な契約書を作成するにあたっては、瑕疵担保責任、損害賠償、解除条件などに工夫をする必要があります。これらの条項はベンダー側かユーザ側かで記載したい内容が大きく異なります。
ベンダー側から見た場合、瑕疵担保の期間は短く・責任を負うべき範囲を限定的にする特約や、損害賠償についても、なるべく損害賠償義務を負わない特約や損害賠償義務の上限を限定する特約を入れ、リスクの低減を図りたいはずです。（例えば損害賠償の上限は契約金額を上限にする特約を入れるなど）。ユーザ側からみたらその反対の特約をいれたいはずです。
瑕疵担保や損害賠償についてはユーザとベンダーの利害は相反するものとなります。契約金額・リスク・顧客との関係など検討し、リスク対応を考慮した契約書を作成する必要があります。
Q9.ソフトウェアの法的責任にはどのようなものがあるでしょうか
Ａ． ソフトウェア取引における法的責任に関しては、契約上の責任として、債務不履行責任と瑕疵担保責任があげられます。債務不履行責任は、ソフトウェアの開発などにおいて、所定の期限までに完成させられないなどの契約上の債務を履行しない場合の責任です。
債務不履行には、履行遅滞（民法５４１条）、履行不能（民法５４３条）とがあります。
履行不能とは仕様を満足させるソフトウェアを作成することが出来なくなった場合です。
瑕疵担保責任は完成されたとして納入されたソフトウェアなどにバグなどの瑕疵があった場合の責任です。請負契約であれば別段の定めが無い限り１年間（民法６３７条）、その他有償契約であれば売買契約規定の準用により１年間となっています。
ただし企業間においては、商法上の瑕疵通知義務（商法５２６条）がありますので、ユーザ側は遅滞なく検査をし、瑕疵を発見した場合直ちにベンダーに知らせる必要があります。
また契約によらない法的責任としては、故意過失により他人の権利や義務を侵害した場合に発生する不法行為責任などがあります。
債務不履行には、履行遅滞（民法５４１条）、履行不能（民法５４３条）とがあります。
履行不能とは仕様を満足させるソフトウェアを作成することが出来なくなった場合です。
瑕疵担保責任は完成されたとして納入されたソフトウェアなどにバグなどの瑕疵があった場合の責任です。請負契約であれば別段の定めが無い限り１年間（民法６３７条）、その他有償契約であれば売買契約規定の準用により１年間となっています。
ただし企業間においては、商法上の瑕疵通知義務（商法５２６条）がありますので、ユーザ側は遅滞なく検査をし、瑕疵を発見した場合直ちにベンダーに知らせる必要があります。
また契約によらない法的責任としては、故意過失により他人の権利や義務を侵害した場合に発生する不法行為責任などがあります。
Q10.委任と請負の違い
Ａ． 仕事を第三者に実施してもらう場合、契約形態として委任契約（正確にはシステム開発業務の場合は準委任）や請負契約の等の形態が考えられます。
よくシステム開発契約書のタイトルで『システム開発委託契約』というものがあります。タイトルだけ見ても委任か請負かわかりませんが、委任なのが請負なのか意識して契約締結をしないと、思いもよらないトラブルに巻き込まれることがあります。
委任契約は、仕事や製品の完成が目的ではなく、契約で合意した内容を実現するための作業を遂行することを契約の目的とする契約で、結果を確約できない契約形態です。
（お願いされたことを一生懸命履行することが目的）
それに対して請負契約は、契約で合意した内容を実現することが契約の目的で、契約を完了するためには、合意した内容を完成させなければなりません。
単純に考えると次のような感じでしょうか
委任契約 ⇒ 依頼されたサービスを提供し、作業を履行することが目的
（完成しなくても求められたことを履行すればよい）
請負契約 ⇒ 依頼された内容の完成が目的。実現方法は任されている。
さてシステム開発の工程は大きく分けて『システムの仕様を策定するフェーズ』（仕様策定フェーズ）と『策定した仕様に基づいてシステムを開発するフェーズ』（開発フェーズ）に大きく分かれるのではないでしょうか。
仕様策定フェーズはユーザとベンダーが協力して仕様を確定する作業になります。つまりユーザの協力なしには、作業を完結することができず、ベンダーから見るとリスク要因となります。
それに対し、開発フェーズでは既に確定した仕様に基づき作業をするわけですからユーザの関与の度合いは低く、ベンダー側は自己の裁量・責任で作業を遂行することができます。
そこで、仕様策定フェーズは委任契約で、開発フェーズは請負契約が、どちらかというと向いた契約形態といえます。またコンサルティングの契約等は委任契約で行われることが多いようです。
実際にはユーザの関与度合いなどから、仕様策定は委任契約、開発は請負契約と２つの契約に分けて行う場合や、ベンダーがリスクを受入れて一括請負契約で行う場合などいろいろなパターンがあります。
どちらで締結するにしても法的には意味が違いますので、注意が必要です。
よくシステム開発契約書のタイトルで『システム開発委託契約』というものがあります。タイトルだけ見ても委任か請負かわかりませんが、委任なのが請負なのか意識して契約締結をしないと、思いもよらないトラブルに巻き込まれることがあります。
委任契約は、仕事や製品の完成が目的ではなく、契約で合意した内容を実現するための作業を遂行することを契約の目的とする契約で、結果を確約できない契約形態です。
（お願いされたことを一生懸命履行することが目的）
それに対して請負契約は、契約で合意した内容を実現することが契約の目的で、契約を完了するためには、合意した内容を完成させなければなりません。
単純に考えると次のような感じでしょうか
委任契約 ⇒ 依頼されたサービスを提供し、作業を履行することが目的
（完成しなくても求められたことを履行すればよい）
請負契約 ⇒ 依頼された内容の完成が目的。実現方法は任されている。
さてシステム開発の工程は大きく分けて『システムの仕様を策定するフェーズ』（仕様策定フェーズ）と『策定した仕様に基づいてシステムを開発するフェーズ』（開発フェーズ）に大きく分かれるのではないでしょうか。
仕様策定フェーズはユーザとベンダーが協力して仕様を確定する作業になります。つまりユーザの協力なしには、作業を完結することができず、ベンダーから見るとリスク要因となります。
それに対し、開発フェーズでは既に確定した仕様に基づき作業をするわけですからユーザの関与の度合いは低く、ベンダー側は自己の裁量・責任で作業を遂行することができます。
そこで、仕様策定フェーズは委任契約で、開発フェーズは請負契約が、どちらかというと向いた契約形態といえます。またコンサルティングの契約等は委任契約で行われることが多いようです。
実際にはユーザの関与度合いなどから、仕様策定は委任契約、開発は請負契約と２つの契約に分けて行う場合や、ベンダーがリスクを受入れて一括請負契約で行う場合などいろいろなパターンがあります。
どちらで締結するにしても法的には意味が違いますので、注意が必要です。
Q11.プログラム登録（著作権）とはなんですか
Ａ． 著作権は、著作物を作った時点で作った人（法人・個人）に自然に発生する権利です。特許や実用新案と違い、著作権を取るための登録はありません。
しかし自然に発生する権利ですから、いつ発生したかを客観的に証明することが難しい場合があります。
そこで「プログラムの著作物に係る登録の特例に関する法律」に基づき、文化庁長官から指定を受けた「指定登録機関」として財団法人ソフトウェア情報センターがプログラムの著作物の登録を実施しています。
登録の種類として
１．創作年月日の登録、２．第一発行（公表）年月日の登録、３．著作権の登録、４．実名の登録 の４つの種類があります。
登録することにより
・登録したした創作年月日（創作年月日の登録の場合）に創作があったものと推定され、後日訴訟問題が発生し、当事者のうちいずれが正当な権利者であるか争われる場合有利な証拠となります。[創作年月日の登録]
・登録に係わる年月日（第一発行年月日の登録の場合）に最初の発行又は最初の公表があったものと推定され、後日訴訟問題が発生し、当事者のうちいずれが正当な権利者であるか争われる場合有利な証拠となります。[第一発行（公表）年月日の登録]
・著作権保護の起算点が明確になる
等の効果が発生します。
また登録は官報で公示または告示されます。
提出書類（例：創作年月日の登録、第一発行（公表）年月日の登録の場合）
・申請書
・著作物の明細書
・プログラム著作物の複製物（A6版マイクロフィッシュで提出）
・代理人が申請する場合委任状
登録は本人申請だけでなく、代理人（行政書士など含む）による申請も認められています。
登録手数料
・登録手数料 47,100円
・登録免許税 3,000円（創作年月日の登録、第一発行（公表）年月日の登録の場合）
その他 マイクロフィッショ製作代（数万円）
当事務所は、プログラム登録サービスを実施しております。
お気軽にお問い合わせください。
しかし自然に発生する権利ですから、いつ発生したかを客観的に証明することが難しい場合があります。
そこで「プログラムの著作物に係る登録の特例に関する法律」に基づき、文化庁長官から指定を受けた「指定登録機関」として財団法人ソフトウェア情報センターがプログラムの著作物の登録を実施しています。
登録の種類として
１．創作年月日の登録、２．第一発行（公表）年月日の登録、３．著作権の登録、４．実名の登録 の４つの種類があります。
登録することにより
・登録したした創作年月日（創作年月日の登録の場合）に創作があったものと推定され、後日訴訟問題が発生し、当事者のうちいずれが正当な権利者であるか争われる場合有利な証拠となります。[創作年月日の登録]
・登録に係わる年月日（第一発行年月日の登録の場合）に最初の発行又は最初の公表があったものと推定され、後日訴訟問題が発生し、当事者のうちいずれが正当な権利者であるか争われる場合有利な証拠となります。[第一発行（公表）年月日の登録]
・著作権保護の起算点が明確になる
等の効果が発生します。
また登録は官報で公示または告示されます。
提出書類（例：創作年月日の登録、第一発行（公表）年月日の登録の場合）
・申請書
・著作物の明細書
・プログラム著作物の複製物（A6版マイクロフィッシュで提出）
・代理人が申請する場合委任状
登録は本人申請だけでなく、代理人（行政書士など含む）による申請も認められています。
登録手数料
・登録手数料 47,100円
・登録免許税 3,000円（創作年月日の登録、第一発行（公表）年月日の登録の場合）
その他 マイクロフィッショ製作代（数万円）
当事務所は、プログラム登録サービスを実施しております。
お気軽にお問い合わせください。
