IT訴訟解説：ソフトウェア開発における秘密保持義務が争われた裁判「エンジニアにはただの計算式の塊でも、われわれにとっては秘伝のノウハウなんです！」

　IT訴訟事例を例にとり、システム開発にまつわるトラブルの予防策と対処法を解説する本連載。今回は「ソフトウェア開発における秘密保持義務」を取り上げる。

【その他の画像】

　プログラムの権利といえば、著作権が代表的なものである。あるプログラムを作成して著作権をユーザー企業に譲渡したにもかかわらず、元の作成者がこれとよく似たプログラムを作って第三者に販売したとき、作成者はユーザー企業から著作権違反として訴えられる可能性があることを、以前本連載で扱った。

　プログラムの権利について注意すべきことは他にもある。ソフトウェアを開発する際、その委託契約に秘密保持を義務付ける条項がある場合、作成するプログラムのアルゴリズムも「営業機密」と捉えられ、これを流用して別の顧客向けのプログラムを作ると秘密保持義務違反として訴えられる危険がある。

　プログラムにはユーザー企業の業務上のノウハウや独自の工夫が含まれており、それが他企業に流出するとユーザー企業は損害をかぶる可能性がある。これらは営業機密であり、ベンダーが勝手に流用することは、許されない。

　普段開発をする際には、著作権は気にしても営業機密までは注意が及ばないこともあり、思わぬ損害賠償請求を受ける可能性もある。そこで今回は、ベンダーの開発者に対して、あるいはユーザー企業の担当者に対する注意喚起として、本件を今回取り上げることとした。

●秘密保持義務違反を訴えられた裁判

　まずは概要をご覧いただきたい。

---

東京地方裁判所 平成18年12月13日判決より

ある繊維関連事業の協同組合（以下 協同組合）がトーションレース（目の粗いレースの一種）の編み機を制御するソフトウェアの開発をソフトウェア開発会社（以下 ベンダー）に委託した。

協同組合とベンダーの間に結ばれた開発委託契約には秘密保持条項があり、業務上知り得た営業機密の漏えいをしてはならないことが定められていた。

ソフトウェアは完成し協同組合に納品されたが、その後ベンダーの開発者の一人が退職した上で、別のレース製造業者（以下 訴外企業）からの依頼に基づき、同じようなトーションレース編み機の制御ソフトウェアを開発して納品した。2つのソフトウェアの機能がほぼ同じであったことから協同組合はこれを営業機密の漏えいと判断し、開発者による訴外企業へ向けプログラムの開発と納品は信義則上の秘密保持義務違反であるとして、損害賠償などを開発者に求める訴えを提起した。

出典 裁判所ホームページ　事件番号 平成17年（ワ）12938

---

●平凡なプログラムで実現される独自のノウハウ

　私はレース編みについて知識を持ち合わせていないが、高品質なものを効率的に制作するには、それなりの工夫があるであろうし、そこに独特のノウハウや独自の工夫があることは想像に難くない。協同組合としては、これも立派な営業機密であると主張したいところだろう。

　ただ一方で、そうしたノウハウや工夫がプログラムという形になった場合にはどのような判断になるのか。判決文を読む限り、プログラム自体は比較的平凡な、独自の工夫やノウハウといったものが見当たらないものであったようだ。

　プログラム自体は平凡でも、それによって実現されるレース編みの手法は独特なものであった。仮にレース編みに知見のない私が開発者の立場であったなら、自分が要件を聞き、設計・開発したプログラムが営業機密を実現したものなのだとは気付きかないかもしれない。秘密保持義務は民法第一条2項の「信義誠実の原則」を根拠とするものだが、少なくとも開発自体はそうした原則に外れることなく遂行したと主張するかもしれない。

　本件の開発者が、ノウハウや工夫を営業機密として認識していたかどうかは不明だが、少なくともプログラム自体には営業機密といえるほどの高度なノウハウや工夫はなかったようである。

　この点を裁判所はどのような判断したのだろうか。判決の続きを見ていただきたい。

---

東京地方裁判所 平成18年12月13日判決より（つづき）

開発者が協同組合から開示された協同組合特有のトーションレースの編み方のノウハウや、協同組合のアルゴリズム全体を他に開示するような行為は、信義則上の秘密保持義務に違反する。

しかし（中略）（本件については開発者が）従来システムエンジニアなどとして有していた技術を適用した結果であったり、技術上の合理性の観点から必然である処理手順であったりすることが考えられ（中略）秘密保持義務に反したものと認めることはできない。

---

●原則としては秘密保持義務違反。ただし……

　「結局、どっちなんだい」と言いたくなるような文面なので、判決文の前半と後半に分けて考えたい。

　前半では基本的な考えとして、「ユーザー企業独自のノウハウやそれを基にしたアルゴリズムを開示してはいけない」と言っている。レースの編み方というのは、他者にまねしてほしくない独特のノウハウであり、これを実現するプログラムを開示することはレース編みのノウハウを開示するのと同じ秘密保持義務違反だというわけだ。

　一方で後半は、前半の原則に対して例外を述べている。「開発者がもともと有していたプログラムやアルゴリズムの知識に基づいて作った部分、合理的に考えて当然そうならざるを得ない処理手順については、営業機密には当たらない」とのことだ。これらはもともと開発者の頭の中にあったものであり、ユーザー独自のノウハウや工夫というわけではないということだ。結局、本件で協同組合の請求は棄却された。

　しかし開発に携わる者としては、やはり前半部分に注意したいところだ。

　「ユーザーのノウハウや独自の工夫を含むようなプログラムを流用して、別の顧客に向けたプログラムを作ってはいけない」と考えた方がよいだろう。これについてはプログラムの著作物性とは分けて考えた方がいい。

　ユーザーのノウハウや工夫が著作物と認められるほどに独特のものではなくても、営業機密に該当する可能性はある。少なくともそうした注意深さは必要となる。本件でトーションレースの編み方がそうであるように、保険会社の料率計算のアルゴリズムなども、プログラム自体は単なる計算式の塊であっても、それが保険会社には重要な知見や分析の詰まった営業機密かもしれない。世にあまたあるデータ解析ソフトウェアなどもそうかもしれない。

　プログラムとしては平凡でも、それがもともと開発者の頭の中にあったアルゴリズムや誰が作っても同じようなロジックになるというわけでなければ、営業機密になる可能性がある。ある意味、著作権よりも注意が必要かもしれない。

　要件提示時点、設計時点において、ベンダーは、そこに営業機密が存するかどうかをよくよくユーザー企業に確かめる必要がある。無論、ユーザー企業にも同じような注意が求められる。いくら後々裁判で勝てても、流出してしまったノウハウは取り戻せないからだ。

　ビジネスモデル特許というものがあるように、現代のビジネスには各社のノウハウや工夫、アイデアがたくさん詰まっており、それを支援するためのシステムにそれらが紛れ込むことはむしろ普通であろう。本件では、アルゴリズムが平凡なものであり、その内容も営業機密とまではいえないことからユーザー企業の訴えは棄却されたが、いつも結果がこうなるとは限らない。

●細川義洋

ITプロセスコンサルタント。元・政府CIO補佐官、東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員NECソフト（現NECソリューションイノベータ）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまでかかわったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わった