2) ファイナンサー（又は、投資家）の目的は何か？それは、ソフトウェアの 資金調達に早い段階から取り組むことによって、そのソフトウェアから上がる であろう利益に対してより大きなシェアを確保し、結果としてより大きなリター ンを得ることだ。
3) しかし、ここでは、残念ながら、ソフトウェアそのものを担保にすること が困難だ。何故か？まだ、ソフトウェアができていないからだ。従って、これ から開発しようとするソフトウェアに対する著作権そのものを譲渡したり質権 を設定することには現実味がないし、対抗要件を備えることもできない。
4) これから開発しようとするソフトウェアについては、クリエータは、構想 （アイディア）しか持っていない［＊。そのアイディアは、例えば、不正競争 防止法によって保護され得る営業秘密であるかもしれない。けれども、営業秘 密を担保にするのは現実味がないし、合法的に（例えば、リヴァース・エンジ ニアリングによって）その営業秘密を明らかにした第三者に対しては何の法的 効果もない。
5) では、特許権はどうか？ソフトウェアの開発に莫大な資金を要する場合で あっても、その土台となる仕組みの構想は頭の中でできるから、特許出願に必 要な情報を整える段階ではさほど資金を要しない場合もあり得る。だから、ソ フトウェア・ハウスが特許権を担保として［＊資金を調達するということは、 理論的には可能なことだ。けれども、残念ながら、多くの場合、それは現実的 な解とはならない。なぜか？ソフトウェア・プロダクト（とりわけ、アプリケー ション・プログラムやエンターテインメント・ソフトウェアの場合）とは、し ばしば、特許法上新規性があるとみられるような画期的な技術が売りである場 合よりも、むしろ、既存のデバイスの組み合わせの巧みさや、既存のデバイス に載せる内容のコンテクストの目新しさが収益力につながることが多い。とこ ろが、こういったものは特許によっておさえることはできない。だから、特許 権を担保にとっても、それを利用して創り上げられるソフトウェアの収益力を ファイナンサーが押さえることはできない（もちろん、一つ一つの取引に関与 して、債権を譲渡担保に供させれば別）。
2) ソフトウェア著作権を担保にとったとしても、それを金に換えるためには、 著作権をおさえたソフトウェアを第三者宛に処分するか、それとも、その著作 権と抵触するようなソフトウェアを製作したり販売したりする第三者（あるい は、融資を受けた本人かもしれないが）の収益を攻撃して取り上げるほかない。
3) ところが、著作権が第三者におさえられているからといって、同様の製品 を製作したり販売したりしようとする第三者（とりわけ、融資を受けたソフト ウェア・ハウスが左前になったのだとしたら、そこから逃げ出したエンジニア、 あるいは、そのエンジニアの転職先）を捕捉することは極めて困難。
4) なぜなら、著作権は、プログラムのストラクチャーを保護対象とはしない し、また、独自にコーディングされたコードを排除する力もなく、また、コン ピュータ・プログラムのような機能的な（つまり、実用的な機能を達成すると いう合理性に支配された）著作物の保護範囲は極めて薄いものであるからだ。
5) もちろん、エンタテインメント・ソフトの場合は、プログラムのコードに 対する著作権よりも、出力やストーリー（例えば、ビデオ・ゲームは全体とし て映画の著作物と同様に考えることが可能）に対する伝統的な著作権をおさえ ることによって類似のソフトウェアの出現を排除することも可能だろう。
6) けれども、オペレーティング・システム、ミドルウェア、ビジネス・アプ リケーション、デバイス制御システム等は、エンタテインメント・ソフトと異 なり、コード以外に著作権でおさえる意味があるところがあまりない。
7) さらに、製品としてウリモノになるソフトウェアには、多くの既存のプロ グラム・モジュールが含まれている。つまり、完成品のソフトウェアの著作権 をおさえたとしても、それは、モジュールの権利者に無断で利用できるわけで はない。結局、それらのモジュールの権利も抑えなければ無意味だということ も十分にある。
2) まず、一つのソフトウェア製品が、一つの特許対象技術のみによって形成 されているということはあまりない。仮にその特許技術がそのソフトウェア製 品を製作するために不可欠だったとしても、通常は、そのソフトウェア製品に おいては、担保としておさえた特許権以外に多くのノウハウや著作物（著作権 の対象となるプログラム・モジュールや新たに用意されたプログラム・コード） がその構成の様々な重要部分を構成しているはず。だとすると、果たして問題 の特許がソフトウェア製品による収益に寄与した割合は一体どれだけなのか？ おそらく、調達した資金は、ソフトウェア製品の開発全体のために使われるは ず。それにもかかわらず、特許権のみが担保となるとすれば（実際にそういう ことはないが）いわゆる担保割れになるのは必然。
3) さらに、多くのソフトウェアはハードウェアと切り離して、単純にCD-ROM やFDのような媒体に納めた形で販売されるのが通常だ。ところが、ソフトウェ ア関連特許のクレームの多くは、"自然法則を利用したものであるべし"という 条件を満たすべく、CPU、メイン・メモリ、ペリフェラル・メモリ等の存在を 前提としたものとなっている。そうすると、第三者が資金調達者の製品と同様 なプログラムを売り出しても、直接侵害にはならない。間接侵害になるかどう かについてすら明確な回答は出せない［＊。そうなると、".....を達成するプ ログラムを格納した記憶媒体"といった形の媒体特許が定着しない限り、模倣 者への対処がなかなか困難だろう。
4) また、特許権の成立には現状で二-三年の時間がかかる。ところが、開発 費用の調達は今すぐしなければ無意味になる。だとすると、開発費用を調達す る時点で開発対象のソフトウェア製品から上がるであろう収益と密接にリンク した特許権を担保化することは事実上困難ということになろう。
2) The Internetに代表されるようなグローバルな国境を越えたネットワーク への接続が普及している現在、プログラムを知的財産権によるコピー禁止を前 提として、一部いくらで売るという商売は"cool"ではなくなってきている。
3) むしろ、ソフトウェア（とりわけ、クライアント・サーバ型システムにお けるクライアント用プログラム）は、ネットワーク上でフリーウェア（無償） 又はシェアウェア（有償ではあるが、ネットワーク上で配布され、料金徴収は 専ら利用者の良心や簡易なプロテクトに任すこととして経費をあまりかけず、 料金も極めて安価であるのが一般的）によって広く普及させ、収益は専ら、コ ンサルティングやサーバ用プログラムの販売によって挙げるというのが、 "cool"なやり方となりつつある。
4) また、プログラムを従来通りパッケージングして店頭で結構な値段で販売 する場合であっても、ソフトウェアハウスの収益力は、そのソフトウェア製品 を利用してユーザ向けのサービスを行うインテグレータの育成と認証に依存す る場合もますます多くなってくるだろう。
5) 完全に伝統的な販売がなされる場合ですら、バージョン・アップの継続と ケアなしには、収益力は持続しないのではないか。
6) それに、そもそも一国で担保を抑えても、世界中におけるソフトウェア・ ハウスの収益力とは必然的な関連性がない。
7) 結局のところ、知的財産権を担保におさえたとしても、ソフトウェア・ハ ウスの収益力の中から一定のシェアをファイナンサーに戻してもらい、それに よって、より多くの資金をソフトウェア開発のために投下できる仕組みを構成 するのは、残念ながら困難なことだ。
2) そこで、共同事業型のファイナンスが指向されることになる。
3) 共同事業型のファイナンスは、基本的には、エクィティ投資家が資金を出 し(contribute)、ベンチャーが知的財産と労力を出す(contribute)；そして、 収益はエクィティ投資かとベンチャーの間で分配される、という形をとる。
4) その形によって、初めて、投資家がソフトウェアの収益力そのものに参加 することができる。
2) もっとも重要なのは、共同事業体である。
3) 共同事業体の形としては、いくつもの方法がある。その中でも、我々の頭 にすぐ浮かぶのは、会社、ジョイント・ベンチャー、パートナーシップ（民法 上の任意組合を含む）、匿名組合等。
4) この中で会社は、二重課税があって投資家に不利なこと、投資家が出資金 が開発によって費消されていってもそれを容易には税務上損金化できないこと （米国のS Corporationのようなものなら別）、収益を各種の法定準備金を控 除した後の配当又は会社解散時の清算配当の形でしか得られない。だから、事 業者同士でファイナンスする場合（例えば、大規模な会社がベンチャーに対し て資金を供給して支援するような場合）にはよいとしても、純粋な金融機関や 投資家としては使いづらい。
5) 仮に、会社とかパートナーシップといった明確な共同事業体の受け皿がな く、１対１に類する契約関係によってのみ共同事業体を形成する方法をジョイ ント・ベンチャーと呼ぶならば、この方法は、やはり、少数の事業者同士の関 係には使えるとしても、事業を共同執行するわけではない金融機関や複数の投 資家としては使いづらい。
6) そうすると、パートナーシップや匿名組合が最も有力な方法としてクロー ズ・アップされることになる。匿名組合については、パートナーシップを類推 して検討できる面が多いから、ここでは、パートナーシップを前提として考え るべきだろう。
7) パートナーシップの目的は、開発の成果をパートナー全員の共有（互いに 勝手に切り離せない、という意味で、"合有"といえる）とし、その成果から生 ずる収入も共有し、一方では、開発に要するコストを税務上全員でシェアし合 うことである。
8) おそらく、このパートナーシップは、実際に開発業務を行うベンチャーと、 投資を行う何人かの投資家パートナーによって構成されることになろう。そし て、多くの場合、投資家パートナーの利益を代表してビジネスの遂行を監督す るマネジャー（ベンチャー・キャピタルがこの役にふさわしい）もパートナー として参加するであろう。
9) このパートナーシップは、日本国内であれば、民法上の任意組合、例えば、 タックス・ヘイブンであればリミテッド・パートナーシップ（ベンチャーとマ ネジャーがジェネラル・パートナーとなり、その他の投資家はリミテッド・パー トナーとなる）として構成されることになろう。
10) ベンチャーに対するファイナンスを共同事業型によって行う最大の目的 は、開発成果であるソフトウェア製品の利用から得られる収入の受け皿をファ イナンサーが直接コントロールできるところにおき、もって、リターンをファ イナンサーのために確保することである。もちろん、これは、デット・ファイ ナンスであっても、ソフトウェア製品の販売によって得られる債権を集合的に 担保として譲渡することによって同じ効果が得られる。しかし、共同事業型の 場合は、そもそも、共同事業体の名義でマネジャーが管理する口座への入金と マネジャーによる事業及び財務の監督が行われることによって、もっと直接的 に目的を達成することができる。従って、共同事業型のベンチャー投資を行う 以上は、共同事業体（又は、共同事業体が指定するノミニー）の名義の口座を 通じて金銭の出入りが行われるべきである。（もちろん、小規模な共同事業体 において、入出金管理をベンチャー自身にまかせる選択肢がとられることもあ るが、規模が大きい場合には適切でない。）
11) このように、公正な立場のマネジャーが投資家全員の利益のためにベン チャーによる事業執行を監督しなければならない点、マネジャーの役割は極め て重要で且つ責任が重い。その分、マネジャーが一定の手数料を受け取るのは 当然のことである。
12) さらに、投資家とすれば、マネジャーによる管理、特に財務管理の適正 さが担保されないと安心してマネジャーに対してベンチャーの監督を任せられ ない。そこで、監査人による監査が必要になってくるはずである。
13) もし、このようなストラクチャーが投資家にとってタックス・メリット が大きいとなれば（現時点で果たしてそうなるかどうかは確言できないから留 意されたい）、投資家は銀行から融資を受けてその資金をもって投資にあてる という場合も出てくるかもしれない。そのような場合には、融資を行う銀行等 も、共同事業体の契約内容と事業執行に大きな利害関係を持つ当事者として登 場することになる。
14) さて、共同事業体による開発の成果として生まれる知的財産権及び収益 については、共同事業体又はノミニーの名義とすることによって実質的な担保 価値を押さえることは可能だ。しかし、それに問題がないわけではない。とり わけ、知的財産権の寿命は（著作権の場合に典型的であるが）、共同事業体の 寿命よりも相当長いはずである。また、ノミニー名義による特許権の出願をし た場合、ノミニー（及びノミニーから専用実施権の設定を受けた者）しか差止 請求権を行使できない。しかし、それでは不都合であり、ベンチャー自身がそ のような権利行使をできるほうがスムーズに事業遂行ができるのではないか、 という疑問がある。そうすると、これらの成果を信託できるとよいのではない か、というはなしになる。残念ながら、日本では、知的財産権を信託銀行に信 託することが許されていないから、これはできない。そうすると、結局は、知 的財産権をスペシャル・パーパス・カンパニーに"信託的"譲渡して、専用実施 権をベンチャーに対して設定するという回りくどい方法によるほかない。本来 であれば、知的財産権及び収益の双方を信託銀行に信託の上、受益者として共 同事業体（参加者全員）を指定することによって、信託銀行の機能を有効に活 用すべきところである。
2) しかし、それは、現実の世界においては、共同事業型ファイナンスがシン プルなデット・ファイナンスに比べてよりリスキーであることの裏返しでもあ る。
3) シンプルなデット・ファイナンスは、既に述べたように、ソフトウェアに 対する担保を実行したとしても、このソフトウェアの潜在的収益力のごく一部 しか顕在化できないはず。
4) だとすると、シンプルなデット・ファイナンスは、実は、ソフトウェアそ のものの現実の担保価値を前提として行うことはできない。
5) 従って、シンプルなデット・ファイナンスは、担保が実行されることには ならない確率が相当程度高いことを前提として、本当は無担保でも回収の見込 みが十分高いのではあるが、金融機関の見かけ上の健全性を維持するために、 なんらかの担保をおさえておく、というものになる。
6) 結局、このようなシンプルなデット・ファイナンスの対象となる企業は、 既に一定の安定した成果を挙げているソフトウェア・ハウスでなければあまり にも危険が高い。
7) そして、ファイナンスされた資金は、完全な新製品の開発ではなく、その アップ・グレード又は既に旧来の製品で開拓されたマーケット向けの代替品又 はアド・オン的製品の開発に向けられるのでなければリスクが高すぎてファイ ナンサーは身動きがとれなくなってしまう。
8) また、シンプルなデット・ファイナンスで担保となるソフトウェアは、アッ プ・グレード前の製品だったりするのであって、これから開発するソフトウェ アということにはなりえない。
9) これに対して、共同開発型ファイナンスは、あくまでも、これから開発す るソフトウェアの開発資金（及び、マーケティング資金）を調達するために行 われる。
10) だから、共同開発型ファイナンスは、ソフトウェア・ハウスが倒れる可 能性があるということが前提となる。つまり、リスクは極めて高い。
11) リスクが高い場合には、それを分散しなければならない。となると、ハ イ・リスク・ハイ・リターンのプロジェクトからロー・リスクのプロジェクト に至るまで、うまく組み合わせてポートフォリオをくまなければならない。
12) 結果として、当然のごとく、共同開発型ファイナンスは、会社横断型 （又は、プロジェクト横断型）になるべきである。
13) さらに、一つのプロジェクトのすべての資金を一つのファイナンス・グ ループがまかなう（つまり、そのグループがそのプロジェクトのリスクをすべ て背負い込む）のではなく、一つのプロジェクトの資金をいくつかのグループ でシェアして負担する（結果として、そのプロジェクトが倒れても、個々のグ ループの傷は浅くて済む）ようにすべきである。
14) デット・ファイナンスの対象となり得るような成熟したソフトウェア・ ハウスに対するファイナンスは、デット・ファイナンスとエクィティ・ファイ ナンスで資金をシェアしあうことにより、双方のリスク軽減に役立つはずであ る。
15) すなわち、デット・ファイナンスは、ソフトウェアの"現実の"担保価値 （現実の担保価値がそのソフトウェアの本来の潜在的収益力から大幅にディス カウントされなければならないことに注意せよ）に見合った資金を供給すると すれば、しばしば、プロジェクトに必要な資金の一部しか安全に供給できない はずである。一方、エクィティ・ファイナンスは収益力を現実に自分のものと できるのだから、より大きな投資ができるはずである。しかも、そのような成 熟したソフトウェア・ハウスに対する投資は、ロー・リスクであるからポート フォリオの成績を安定させるのにも役立つ。
16) 例えば、あるソフトウェア・ハウスが既に存在するソフトウェアを担保 として銀行からプロジェクト資金の一部を調達しつつ、残りの必要な資金をそ の銀行の系列のベンチャー・キャピタリストが組成したパートナーシップから の投資によってまかなうという方法があり得るし、そうでなければ、銀行も受 け入れ可能な程度に安全な資金供給を行うことはできない。
17) また、銀行としては、ソフトウェア・ハウスに対して直接融資を行うの ではなく、プロジェクト資金を供給するパートナーシップそのもの（又は、個々 のパートナー）に対して融資を行なうということも可能である。
//Shin Teramoto //E-Mail (Business): PEC00422@niftyserve.or.jp //E-Mail (Private): terra@st.rim.or.jp //Snail Mail: // Dohke & Teramoto, KIMURA Bld. 3rd Fl. // Hongo 3-39-3, Bunkyo-ku, Tokyo 113, Japan //Fax. +81-3-3818-0429