判例紹介：元勤務先企業の立場で秘密管理の認識が異なる？

所属している会社が従業員に秘密保持誓約書の提出を求める場合は少なからずあると思います。今回紹介する裁判例（東京地裁平成14年12月26日中間判決 東京地裁平成15年11月13日判決　事件番号：平１２（ワ）２２４５７号）は、そのような誓約書を提出しなかったことを持って被告が秘密管理性を否定する主張を行った事件です。

本事件は、原告会社及び被告会社共に一般労働者（人材）派遣事業等を主たる営業目的として設立された株式会社です。被告会社は、原告の取締役営業副本部長の地位にあった被告Ｂが設立して設立と同時に代表取締役に就任し、原告の取締役営業部長であった被告Ａは被告会社営業部長に就任しています。

そして、原告会社は、原告の営業秘密である派遣労働者の雇用契約に関する情報及び派遣先の事業所に関する情報を、被告Ｂ及び被告Ａが不正の目的で使用あるいは被告会社に開示したと主張しました。

本事件において、原告は被告は原告の各種情報の秘密管理性に対する否定において、原告が従業員に求めていた秘密保持の誓約書について下記のように主張しています。

エ　誓約書について

　原告会社は、従業員全員から誓約書を徴していたことをもって、秘密として管理していたことの根拠の一つとしているようであるが、甲６１の誓約書の束に被告小野及び被告大湊のものがないことから、少なくとも被告小野ら両名が誓約書を提出していなかったことは明らかである。このように、従業員全員が誓約書を提出していたわけでないから、一部の従業員から誓約書を徴していたとしても、被告小野ら両名が当該情報を秘密と認識できた根拠とはならない。

そして、裁判所は原告会社の派遣スタッフ名簿と被告会社の派遣スタッフ名簿との記載内容について以下のように認めています。

これらを比較すると、まず、被告会社の別紙「日本人材サービス株式会社登録派遣スタッフ名簿」は、４頁からなり、被告会社への登録順に第１頁～第３頁に各頁６２名、第４頁に３４名の合計２２０名の派遣スタッフの氏名等が記載されているところ、このうち原告会社の名簿にも登録されていた者は、第１頁に４７名、第２頁に２２名、第３頁に５名（第４頁は０名）の合計７４名である。このように、始めに近い頁ほど重複者が多い、すなわち被告会社に初期に登録した者ほど重複が多いのは、被告会社が設立当初は、原告会社に登録していた派遣スタッフを移籍ないし重複登録させることで自己の派遣スタッフを集め、その後事業の進展とともに、徐々に原告会社と関わりのない新たな派遣スタッフを募集したためと認められる。

また、上記によれば、被告会社の派遣先の事業所は全部で２６社であるところ、うち原告会社の派遣先と重複しているものは２３社に及んでいる。

さらに、裁判所は、原告による「派遣スタッフ及び派遣先の事業所の情報」の秘密管理性について、コンピュータによる管理とスタッフカード（帳簿）による管理の両方に対して、その秘密管理性を認め、被告が主張する誓約書については以下のように判断しました。

なお、被告B及び被告Aは、誓約書を差し入れていないが、他の従業員との間に秘密保持契約を締結した当時、被告Bら両名は既に取締役であったためにたまたま誓約書を差し入れていないというにすぎず、上記情報の重要さについては一般の従業員以上に知悉していたというべきであるから、このことをもって秘密として管理されていないとはいえない。

このように、営業秘密とする情報に対する秘密管理措置が適切であれば、秘密保持の誓約書等を提出しなかったからといって、非提出者に対する秘密の認識が否定されることはありません。さらに、本事件では、原告会社に所属していたときの被告A，Bの役職も考慮にいれて裁判所は判断しているようです。

なお、本事件では、被告らは各自６２６９万円の損害金を原告に支払え、という判決となっています。

本事件からわかることは、秘密保持の誓約書等の提出の有無にかかわらず、営業秘密とする情報の秘密管理措置の実態を鑑みて、当該情報の秘密管理性が判断されるということです。

すなわち、会社が従業員に対して秘密保持の誓約書等を提出させていたとしても、秘密管理措置が適切でなければ当該情報の秘密管理性は認められません。

http://www.営業秘密ラボ.com/

弁理士による営業秘密関連情報の発信 

営業秘密の不正使用の範囲

営業秘密とする技術情報の不正使用として、例えば営業秘密が図面である場合に、当該図面に基づいて製品を製造するというような直接的な使用（直接使用）は分かり易いと思います。

また、営業秘密を参考として、当該営業秘密とされる技術情報の下位概念となるような製品を製造するような行為や当該技術情報を改良して使用する行為も不正使用（参考使用）と言えるでしょう。

ここで、参考使用の例として、大阪地裁令和２年10月１日判決（事件番号：平２８（ワ）４０２９号）があります（リフォーム事業情報事件）。本事件は、家電小売り業のエディオン（原告）の元従業員（被告Ｐ１）がリフォーム事業に係る営業秘密を転職先である上新電機（被告会社）へ持ち出した事件の民事訴訟です。この事件は刑事事件にもなっており、この元従業員は有罪判決となっています。

本事件では、リフォーム事業に係る複数の営業秘密が不正使用されたと判断されています。その中で、リフォーム事業に用いるシステムの情報も営業秘密（資料３－１～３－９）とされており、裁判所は、当該営業秘密を被告Ｐ１が不正に持ち出し、下記のようにして上新電機による不正使用もあったと判断しました。なお、HORPシステムはエディオンのリフォーム事業に関するシステムであり、JUMPシステムは上新電機のシステムです。

JUMPシステム開発の打合せの過程で被告会社からファンテックに対しHORP関連情報その他原告のHORPシステムに関する具体的な資料ないし情報が提供されたことがないこと，JUMPシステムの開発がそれ以前の被告会社のリフォーム事業の業務フローをおおむね踏襲しつつ，一元的な業務管理及び作業手順の標準化等の観点からリフォーム事業に特化した案件管理システムの開発として進められたものと見られること，作業の組織化，情報共有，進捗管理，顧客情報管理といったシステム導入効果は，市販のリフォーム事業向け案件管理システムでもうたわれていたこと，具体的な入力項目や操作方法といった詳細な事項は，既存のシステムとの連携や，社内の関連部署やメーカー，工事業者等の取引先との連携に関する従前の運用方法からの連続性等を考慮しなければならず，事業者ごとに異なり得ることなどに鑑みると，Ｐ４等被告会社の関係者が参考としたのは，資料３－１～３－９の各情報のうち，家電量販店としてリフォーム事業を展開するための案件管理システムの設計思想その他理念的・抽象的というべき部分が中心であったものと推察される。

上記下線部のように裁判所は、上新電機はエディオンのシステムに関する営業秘密を直接使用したのではなく、参考使用したと判断しているのだと思います。しかも、「案件管理システムの設計思想その他理念的・抽象的というべき部分」、すなわち当該営業秘密の上位概念にあたる部分を参考にした、という裁判所の判断と解されます。

一方で、大阪地裁平成２５年７月１６日判決（事件番号：平成２３年（ワ）第８２２１号）であるＦｕｌｌ　Ｆｕｎｃｔｉｏｎ事件では、リフォーム事業情報事件における不正使用とは異なる判断が裁判所によって行われているようにも思えます。

本事件は、ソースコード（原告ソフトウェア）が営業秘密とされ、被告が原告ソフトウェアを原告退職後も所持していたとのことです。そして、被告による原告ソフトウェアの不正使用について、裁判所は以下のようにして認めませんでした。

（１）原告は，本件争点につき，主張によると，被告は，本件ソースコードそのものを「使用」したものではなく，ソースコードに表現されるロジック（データベース上の情報の選択，処理，出力の各手順）を，被告らにおいて解釈し，被告ソフトウェアの開発にあたって参照したことをもって，「使用」に当たるとし，このような使用行為を可能ならしめるものとして，被告Ｐ１及び被告Ｐ２による，「ロジック」の開示があったものと主張する。

（２）しかし、上記２に説示したとおり，本件において営業秘密として保護されるのは，本件ソースコードそれ自体であるから，例えば，これをそのまま複製した場合や，異なる環境に移植する場合に逐一翻訳したような場合などが「使用」に該当するものというべきである。原告が主張する使用とは，ソースコードの記述そのものとは異なる抽象化，一般化された情報の使用をいうものにすぎず，不正競争防止法２条１項７号にいう「使用」には該当しないと言わざるを得ない。

上記のように裁判所は、営業秘密であるソースコードを「そのまま複製した場合や，異なる環境に移植する場合に逐一翻訳したような場合などが「使用」に該当する」とのように述べ、「ソースコードの記述そのものとは異なる抽象化，一般化された情報の使用」は不正使用ではないと判断しているようです。

このように、「ソースコードの記述そのものとは異なる抽象化，一般化された情報の使用」は不正使用ではないとする判断は、リフォーム事業情報事件とは真逆の判断のようにも思えます。

ここで、営業秘密を「抽象化、一般化」した情報は、凡そ公知の情報であり、そもそもが営業秘密とはなり得ない情報であるとも思われます。このため、リフォーム事業情報事件において被告が不正使用したされる「リフォーム事業を展開するための案件管理システムの設計思想その他理念的・抽象的というべき部分」がどのような情報であるかは不明ですが、仮に公知の情報と言える内容であれば、リフォーム事業情報事件における裁判所の判断は、誤りであるようにも思えます。

このように、営業秘密の上位概念を参考にする場合には、参考にする内容が公知の情報となっている可能性が高いと思われ、そのような使用をも不正使用とすることは適切でないと考えます。

なお、Ｆｕｌｌ　Ｆｕｎｃｔｉｏｎ事件において裁判所は、下記のようにも判断しています。

（３）原告は，原告ソフトウェアがｄｂＭａｇｉｃ，被告ソフトウェアがＶＢ２００８と，全く異なる開発環境で開発されていることから，本件ソースコード自体の複製や機械的翻訳については主張せず，本件仕様書（乙１）に，本件ソースコードの内容と一致する部分が多いことから，被告Ｐ２らにおいて，本件ソースコード自体を参照し，原告ソフトウェアにおけるプログラムの処理方法等を読み取って，これに基づいて被告ソフトウェアを開発した事実が認められる旨を主張する。

しかしながら，前述のとおり，企業の販売，生産等を管理する業務用ソフトウェアにおいて，機能や処理手順において共通する面は多いと考えられるし，原告ソフトウェアの前提となるエコー・システムや原告ソフトウェアの実行環境における操作画面は公にされている。また，被告Ｐ２は，長年原告ソフトウェアの開発に従事しており，その過程で得られた企業の販売等を管理するソフトウェアの内部構造に関する知識や経験自体を，被告ソフトウェアの開発に利用することが禁じられていると解すべき理由は，本件では認められない。

このような裁判所の判断は非常に重要でしょう。

仮に、従業員等が業務の過程で得た一般的な知識や経験自体も営業秘密であり、これらを転職先等で使用することを営業秘密の不正使用であるとすると、従業員にとって転職を躊躇させる一因となります。このため、営業秘密の不正使用の範囲を必要以上に拡大して解釈されることは抑制されるべきと考えます。

また、他社との共同研究開発等において他社から営業秘密を開示された場合に、当該営業秘密から知り得た技術情報を「一般化、抽象化」した情報（参考情報）を使用することが営業秘密の使用とされると、例えば共同研究開発終了後に自社で参考情報を使用した研究・開発を行うことを躊躇する事態になりかねません。

これらの点からも、リフォーム事業情報事件における裁判所の判断よりも、Ｆｕｌｌ　Ｆｕｎｃｔｉｏｎ事件における裁判所の判断の方が適切ではないかと思います。

http://www.営業秘密ラボ.com/

弁理士による営業秘密関連情報の発信 

秘密管理性の判断基準が低い情報（ソースコード）

前回のブログでは、営業秘密における秘密管理性の判断基準を緩和してもよいのではという個人的な意見を述べました。とはいえ、実際には秘密管理性の判断が緩いと思える裁判例も存在します。

・Ｆｕｌｌ　Ｆｕｎｃｔｉｏｎ事件

（大阪地裁平成２５年７月１６日判決　平成２３年（ワ）第８２２１号）

この事件は、原告の元従業員であった被告Ｐ１及び被告Ｐ２が原告の営業秘密である本件ソースコード等を被告会社に対し開示し、被告会社が製造するソフトウェアの開発に使用等したと原告が主張しました。

そして、本件ソースコードに対する原告主張の秘密管理措置は以下のようなものです。

（ア）保管場所

本件ソースコードの保管場所である原告の開発用サーバには，開発担当者のみがアクセスできるようになっており，従業員ごとにＩＤ，パスワードが設定されていた。

（イ）従業員の秘密保持義務

原告の就業規則には秘密保持条項が設けられ（甲２），同就業規則は従業員に周知されていた。

（ウ）原告の情報管理体制

原告は，従業員個人所有のパソコンへのデータコピー禁止，電子メールの監視，ファイルサーバでのデータの一元管理などの措置を執っていた。

（エ）秘密であることの表示について

本件ソースコード自体に秘密であることの表示はされていなかったが，ソフトウェア開発に携わる者であれば，ソースコードを秘密にすることは常識である。

（オ）顧客に対する関係について

原告ソフトウェアの顧客の環境にｄｂＭａｇｉｃの開発環境及び本件ソースコードが保存されることはあるが，その場合，顧客には開示されないパスワード設定がされていた。

　なお，原告ソフトウェアの以前のバージョン（Ｖ８）で，パスワードが設定されないものもあったが，その場合も，大多数の顧客が閲覧可能な状態であったことはない。

上記（エ）で原告自ら主張しているように、本件ソースコード自体に秘密であることの表示はされていませんでした。（オ）に関しては、原告と顧客との関係なので、これが原告と従業員との間における本件ソースコードに対する秘密管理措置となりえるかは微妙なところです。このため、原告は（ア）～（オ）のような秘密管理措置を主張していますが、（ア）と（イ）が本件ソースコードに対する実質的な秘密管理措置とも思われ、そうであれば本件ソースコードに対する秘密管理措置の程度は低いと考えられます。

このような原告主張の秘密管理措置に対して裁判所は、下記のようにソースコードの一般的な認識を示したうえで、ソースコードに対する秘密管理措置を認めました。

一般に，商用ソフトウェアにおいては，コンパイルした実行形式のみを配布したり，ソースコードを顧客の稼働環境に納品しても，これを開示しない措置をとったりすることが多く，原告も，少なくとも原告ソフトウェアのバージョン９以降について，このような措置をとっていたものと認められる。そうして，このような販売形態を取っているソフトウェアの開発においては，通常，開発者にとって，ソースコードは営業秘密に該当すると認識されていると考えられる。

前記１に認定したところによれば，本件ソースコードの管理は必ずしも厳密であったとはいえないが，このようなソフトウェア開発に携わる者の一般的理解として，本件ソースコードを正当な理由なく第三者に開示してはならないことは当然に認識していたものと考えられるから，本件ソースコードについて，その秘密管理性を一応肯定することができる

このように、本事件では、ソースコードは一般的に営業秘密に該当するという原告の主張を認める形で、裁判所は、本件ソースコードの管理は必ずしも厳密ではないとしつつも、本件ソースコードの秘密管理性を認めました。

一方で、本事件は顧客情報についても争われています。顧客情報の秘密管理措置に対して原告は下記のように主張しています。

（ア）保管場所

本件顧客情報は，原告のサーバの販売管理システム上の情報であり，従業員ごとにＩＤ及びパスワードを設定していた。

（イ）従業員の秘密保持義務

原告の就業規則には秘密保持条項が設けられ（甲２），同就業規則は従業員に周知されていた。

（ウ）原告の情報管理体制

原告は，従業員個人所有のパソコンへのデータコピー禁止，電子メールの監視，ファイルサーバでのデータの一元管理などの措置を執っていた。

上記（ア）～（ウ）は、本件ソースコードの秘密管理措置と同じであり、本件顧客情報と本件ソースコードの秘密管理措置との違いは、本件ソースコードの（エ）、（オ）がないことです。これに対して、裁判所は、下記のようにして本件顧客情報の秘密管理性を認めませんでした。

本件全証拠をみても，原告主張にかかる原告の販売管理システムについて，秘密の管理に関する具体的機能，内容，運用方法（どの職種の従業員にいかなる権限を付与しているのか等）を明らかにする的確な証拠はなく，結局，具体的な秘密管理の方法は不明であったといわざるを得ない。

このように、同じような秘密管理措置を行っていても、ソースコードの秘密管理性は認められる一方で、顧客情報の秘密管理性は認められないという裁判所の判断となっています。この理由は、❝開発者にとって，ソースコードは営業秘密に該当すると認識されていると考えられる。❞からのようです。一方で、顧客情報に対しては、営業秘密に該当すると認識はされていないとの裁判所の判断なのでしょう。

なお、本事件では、本件ソースコードの営業秘密性は裁判所において認められたものの、被告による使用は認められず、被告らが本件ソースコードを開示，使用して不正競争行為を行ったとは認定されませんでした。

また、本事件と同様に、ソースコードの一般的な認識として❝ソフトウェアのソースコードは，一般に非公開とされているもの。❞と認定した裁判例として、大阪地裁平成２８年１１月２２日判決（事件番号：平成２５年（ワ）第１１６４２号）もあります。

このように、ソースコードに対しては、❝ソースコードである❞という理由によりその秘密管理性を認めた裁判例があります。これは例外とも思え、Full Function事件では、ソースコードと同様の秘密管理を行っていた顧客情報の秘密管理性は認められていません。

個人的には、積極的に公開しない限り、顧客情報も一般的には秘密とされる情報であると思うのですが、顧客情報の秘密管理措置が認められない理由は判然としません。しかしながら、ソースコードのように❝一般的❞な認識によって秘密管理措置が認められる情報が存在するのであれば、ソースコードと同様に秘密管理措置が認められる情報（例えば顧客情報や非公知の技術情報等）の幅が広げられてもよいのでは無いかと思います。

http://www.営業秘密ラボ.com/

弁理士による営業秘密関連情報の発信