2008年11月06日
契約のこと
先日、小室哲哉さんが逮捕されたという記事を見ました。自作の曲の権利を売るということでありながら、その権利を有していなかったということが問題になっているようです。この著作権に絡む問題は、実は私どものような業務システムを作っている商売でも非常に重要なことだったりします。
スタロジはオーダーメイドの業務システムを提供している会社です。いわゆる受託開発ということになります。オーダーメイドですからワンオフ、つまり一品ものを作っていることになります。提供にあたってはプロジェクトという形になるので、毎回契約書を締結します。何度もお取引頂く場合に備えて、通常は基本契約書と個別契約書という形になりますが、これは別に分けなければならないというわけではないので、一緒にまとめても問題ありません。
この契約書の内容ですが、基本的には「いつ・誰が・誰に・何を・どこに・どのように・何個・いくらで」納品するかということを明記しています。この「何を」が役務なのか具体的なブツ（成果物）なのかによって多少変わってきますが、大筋は納品に関することです。それに連動する形で対価のお支払い方法が記載されています。納品できなかった場合のペナルティなども併記されます。
さて、この契約書の中で役務ではない場合に、その成果物の取り扱いにおいて非常に重要なセクションがあります。それが「著作権に関すること」です。著作権者が誰になるのか。どのタイミングで移転するのか。どの部分までが誰の著作権となるのか。そういったことが書かれています。さらに重要なのが、著作権および著作人格権の行使に関する制限です。
この著作権については、率直に言って結構開発側に不利な契約が多いです。大手企業さんとのご契約に際しては現場レベルではプロジェクトに関する合意が出来ていたとしても、リーガルチェックのレベルでもめることが非常に多いです。「御社くらいですよ」などと言われてしまうということは、よもやスタロジのような中小企業がこのようなことであーだこーだと言ってくるというのが想定されていないのでしょう。それ以前に相当数のソフト会社がこの辺なぁなぁで済ませているのか、言いくるめられているのか、よくわかりませんが、とにかくこの権利関連については、ほっとくと死活問題になってしまうので、かなり交渉してきています。
例えば非常にタイトなプロジェクトがあるとします。そこで納期に間に合わせるために生産性向上のために色んな仕組みを作った。それが意外と上手くいってこの仕組みは今後も色んなケースで利用できそうだ、となったとします。ですが通例通りの契約のままでいくと、再利用出来ないということが多いのです。むしろ下手をすると、プロジェクトにおいて生まれた発想は許可無く他に転用してはならない系の縛り（遠回しに書いてますけど、まぁあるわけですよ。同業他社の仕事はしちゃいかん系とか）が契約書に書いてあると、似たような考え自体が使えなくなってしまう。端的に言えばノウハウを活かせなくなってしまいかねない。それはもうソフト会社としては根幹に関わる問題です。
これを何とかするためには、プロジェクト外で仕組みを作っておいて、「今回はこういうものを使います。ついてはこれについての一切の権利は乙（自社です）にあり、甲（お客様です）はその利用を許諾されるものとするってことにさせてね、うふ」みたいな風にするということになります。そうすると当然「それってどれ？」となるわけです。あるいは、交渉によってそういう基盤系の技術については権利を乙に残す代わりに全体の金額を安くするというような交渉を行う場合もあります。ここで自社プロダクトをオープンソースソフトウェアにしておくことのメリットというのが実はあるのですが、それについてはまた別の機会に気が向いたら書きます。
この著作権に関することがスタロジの元請けにこだわる理由のひとつでもあります。下請けだと元請けとの契約に際しての交渉になるのですが、元請け企業とお客様企業の間での内容がそのままスライドしてくることが多く、交渉の余地なしとなってしまいます。そうすると、落ちてくる仕様書を人海戦術でこつこつとやる以上のことが出来なくなってしまうのです。一方で自社が元請けであれば直接交渉が可能です。リーガルとの交渉は面倒なのですけど、リーガル以外の方はメリットを大抵理解してくれるので、手間はかかりますが自社にノウハウを残し続けていくことが出来ます。そういう点では受託開発よりもパッケージソフトを販売する方がわかりやすいのだとは感じます。あるいはASP/SaaSみたいなモデルですね。ギョイゾー！にはこのあたりの工夫も入っています。
ちなみに、契約は納品と支払がセットで定義されます。ですから分割発注や分割支払の場合には当然契約を分割することになります。そうすると、それぞれの契約における最終成果物というか納品物の定義は重要になります。それを定義できないのであれば役務ということになるしかありません。納品物はタイムシートです。もちろん役務の結果生じる様々なものに対しての著作権というテーマも発生します。
…一応世の中にはモデル契約書というのがあったりして、そこには発注側のお客様はもちろん開発側の企業にとっても不利益にならないような形式で書いているのですが、そのモデル自体が最近のものであり、得てして法務部門というのは前例・通例・慣例で通ってますからその企業の歴史が長いほど、モデルに沿った形に変更してもらうには相当に時間がかかります。下手するとこれだけで3ヶ月ほどかかってしまうことも度々です。そしてこの前例・通例・慣例というのが、裏返すと業界構造であるとも言えるのです。
自分たちの売り物の価値を粗末に扱われないためにも、契約というのは非常に重要なことです。自分たちが作る「何」に対して「いくら」の価値を設定するのか。ソフトウェアというのは、ハードウェアと違って重さもないですし触ることも出来ません。その点では音楽と同じようなものです。それだけに著作権に関することは非常に重要で、それは「価値を定義すること」そのものだからです。契約に関することを手抜きするというのは、それは自分の価値を粗末にするのと同義なのです。
契約に関することというのは、面倒ですし地味ですから興味を持つのはなかなか難しいのかもしれません。ですが、契約の内容が自分の仕事の価値を定義して、ひいては自分自身の給料にも関わってくるのですから、決して他人事では済まされません。たまには自分の仕事はどういう契約になっているのだろうかということを考えてみるのは、大切なことだと思っています。
この契約書の内容ですが、基本的には「いつ・誰が・誰に・何を・どこに・どのように・何個・いくらで」納品するかということを明記しています。この「何を」が役務なのか具体的なブツ（成果物）なのかによって多少変わってきますが、大筋は納品に関することです。それに連動する形で対価のお支払い方法が記載されています。納品できなかった場合のペナルティなども併記されます。
さて、この契約書の中で役務ではない場合に、その成果物の取り扱いにおいて非常に重要なセクションがあります。それが「著作権に関すること」です。著作権者が誰になるのか。どのタイミングで移転するのか。どの部分までが誰の著作権となるのか。そういったことが書かれています。さらに重要なのが、著作権および著作人格権の行使に関する制限です。
この著作権については、率直に言って結構開発側に不利な契約が多いです。大手企業さんとのご契約に際しては現場レベルではプロジェクトに関する合意が出来ていたとしても、リーガルチェックのレベルでもめることが非常に多いです。「御社くらいですよ」などと言われてしまうということは、よもやスタロジのような中小企業がこのようなことであーだこーだと言ってくるというのが想定されていないのでしょう。それ以前に相当数のソフト会社がこの辺なぁなぁで済ませているのか、言いくるめられているのか、よくわかりませんが、とにかくこの権利関連については、ほっとくと死活問題になってしまうので、かなり交渉してきています。
例えば非常にタイトなプロジェクトがあるとします。そこで納期に間に合わせるために生産性向上のために色んな仕組みを作った。それが意外と上手くいってこの仕組みは今後も色んなケースで利用できそうだ、となったとします。ですが通例通りの契約のままでいくと、再利用出来ないということが多いのです。むしろ下手をすると、プロジェクトにおいて生まれた発想は許可無く他に転用してはならない系の縛り（遠回しに書いてますけど、まぁあるわけですよ。同業他社の仕事はしちゃいかん系とか）が契約書に書いてあると、似たような考え自体が使えなくなってしまう。端的に言えばノウハウを活かせなくなってしまいかねない。それはもうソフト会社としては根幹に関わる問題です。
これを何とかするためには、プロジェクト外で仕組みを作っておいて、「今回はこういうものを使います。ついてはこれについての一切の権利は乙（自社です）にあり、甲（お客様です）はその利用を許諾されるものとするってことにさせてね、うふ」みたいな風にするということになります。そうすると当然「それってどれ？」となるわけです。あるいは、交渉によってそういう基盤系の技術については権利を乙に残す代わりに全体の金額を安くするというような交渉を行う場合もあります。ここで自社プロダクトをオープンソースソフトウェアにしておくことのメリットというのが実はあるのですが、それについてはまた別の機会に気が向いたら書きます。
この著作権に関することがスタロジの元請けにこだわる理由のひとつでもあります。下請けだと元請けとの契約に際しての交渉になるのですが、元請け企業とお客様企業の間での内容がそのままスライドしてくることが多く、交渉の余地なしとなってしまいます。そうすると、落ちてくる仕様書を人海戦術でこつこつとやる以上のことが出来なくなってしまうのです。一方で自社が元請けであれば直接交渉が可能です。リーガルとの交渉は面倒なのですけど、リーガル以外の方はメリットを大抵理解してくれるので、手間はかかりますが自社にノウハウを残し続けていくことが出来ます。そういう点では受託開発よりもパッケージソフトを販売する方がわかりやすいのだとは感じます。あるいはASP/SaaSみたいなモデルですね。ギョイゾー！にはこのあたりの工夫も入っています。
ちなみに、契約は納品と支払がセットで定義されます。ですから分割発注や分割支払の場合には当然契約を分割することになります。そうすると、それぞれの契約における最終成果物というか納品物の定義は重要になります。それを定義できないのであれば役務ということになるしかありません。納品物はタイムシートです。もちろん役務の結果生じる様々なものに対しての著作権というテーマも発生します。
…一応世の中にはモデル契約書というのがあったりして、そこには発注側のお客様はもちろん開発側の企業にとっても不利益にならないような形式で書いているのですが、そのモデル自体が最近のものであり、得てして法務部門というのは前例・通例・慣例で通ってますからその企業の歴史が長いほど、モデルに沿った形に変更してもらうには相当に時間がかかります。下手するとこれだけで3ヶ月ほどかかってしまうことも度々です。そしてこの前例・通例・慣例というのが、裏返すと業界構造であるとも言えるのです。
自分たちの売り物の価値を粗末に扱われないためにも、契約というのは非常に重要なことです。自分たちが作る「何」に対して「いくら」の価値を設定するのか。ソフトウェアというのは、ハードウェアと違って重さもないですし触ることも出来ません。その点では音楽と同じようなものです。それだけに著作権に関することは非常に重要で、それは「価値を定義すること」そのものだからです。契約に関することを手抜きするというのは、それは自分の価値を粗末にするのと同義なのです。
契約に関することというのは、面倒ですし地味ですから興味を持つのはなかなか難しいのかもしれません。ですが、契約の内容が自分の仕事の価値を定義して、ひいては自分自身の給料にも関わってくるのですから、決して他人事では済まされません。たまには自分の仕事はどういう契約になっているのだろうかということを考えてみるのは、大切なことだと思っています。