外部エンジニアの競合案件・利益相反を管理する方法｜掛け持ちを禁止せず情報流出を防ぐ

業務委託のエンジニアと面談していて「今、別の会社のSaaSも並行して開発しているんです」と聞いた瞬間、ふと不安がよぎった経験はないでしょうか。その「別の会社」が自社と同じ領域だったら——自社の要件定義やソースコード、リリースの時期が、競合に筋抜けてしまうのではないか。そう考え始めると、せっかく確保した優秀な外部人材を手放したくない気持ちと、情報流出への警戒が頭の中でせめぎ合います。

外部エンジニアの活用が当たり前になった今、フリーランスや業務委託のエンジニアが複数社の案件を掛け持ちしているのはごく自然なことです。むしろ掛け持ちを一律に禁止しようとすると、優秀な人材ほど離れていきますし、契約に安易な競業避止を書き込むとフリーランス新法や独占禁止法に抵触するリスクすら生まれます。とはいえ「自由にどうぞ」と放置すれば、自社の機密が競合に流れる懸念は消えません。

難しいのは、法務の専任担当がいない中小企業やスタートアップでは、この「どこまで許容し、どこから危険とみなすか」の線引きを自分で判断しなければならない点です。NDAは結んでいるけれど、それで本当に守れているのか確信が持てない。かといって過剰に詮索すれば人材との信頼関係を損ねる。判断軸がないまま、漠然とした不安だけが残ってしまいます。

この記事では、外部エンジニアの競合案件・利益相反を「掛け持ちの禁止」に頼らずに管理する方法を、発注者の運用・マネジメントの視点で解説します。リスクの正体を「競合度」と「情報機密度」の2軸で見極める判断基準を提示したうえで、面談での確認・情報アクセスの隔離・契約での要所担保・稼働中のモニタリングという4ステップの運用に落とし込みます。契約書1枚で安心するのではなく、再現可能な自社ルールの骨子を持ち帰っていただくことを目指します。

外部エンジニアの競合案件・利益相反とは何か（発注者が押さえる定義）

まず、この記事で扱う「利益相反」が何を指すのかを整理します。言葉の使い方を揃えておかないと、後段のリスク判断がぶれてしまうためです。

「掛け持ち」「競合案件」「利益相反」の違いと関係

3つの言葉は混同されがちですが、発注者の視点では明確に分けて考えると判断がしやすくなります。

• 掛け持ち: 1人のエンジニアが複数社の案件を並行して受けている状態そのもの。フリーランスや業務委託では一般的で、それ自体に問題はありません。
• 競合案件: 掛け持ち先の中に、自社と同じ市場・同じ顧客層を狙うサービスが含まれている状態。掛け持ちのうち、自社にとって警戒が必要になる一部分です。
• 利益相反: 競合案件への関与によって、自社の利益（機密情報・成果物・稼働の優先度）が損なわれうる状態。「競合案件 × 自社の機密情報へのアクセス」が重なったときに初めて顕在化します。

つまり、掛け持ちは合法かつ自然なことであり、それ自体を問題視する必要はありません。警戒すべきは「掛け持ち先に競合がいて、かつその人が自社の機密に触れている」という条件が揃ったときだけです。この前提を押さえると、「掛け持ち＝危険」という過剰反応も、「契約を結んだから大丈夫」という放置も、どちらも適切でないことが見えてきます。

なお、ここでいう利益相反は、会社法が定める取締役の利益相反取引（取締役が自社と取引する際の承認手続きなど）とは別の概念です。検索で「利益相反とは」と調べると会社法・取締役の文脈の解説が多く出てきますが、外部エンジニア活用で問題になるのは契約上・運用上の情報保護の話であり、会社法の承認手続きが直接適用されるわけではありません。

なぜ外部エンジニア活用で利益相反が起きやすいのか

外部エンジニアの活用は、構造的に利益相反が生じやすい条件を含んでいます。理由は大きく2つあります。

1つは、外部エンジニアが業務の性質上、自社の中核情報に深く触れることです。要件定義書、データベース設計、ソースコードのリポジトリ、本番環境に近いステージング——プロダクト開発を任せる以上、機密度の高い情報へのアクセスは避けられません。社内の正社員と同じレベルの情報に、契約期間中だけ触れる人がいる、という状態です。

もう1つは、複数社で同種の作業を並行することの多さです。「SaaSのバックエンドが得意」「決済まわりに強い」といった専門性で選ばれる人ほど、似た領域の案件を複数抱える傾向があります。専門性が高いことと、競合領域に同時に関わっている可能性が高いことは、しばしば表裏一体です。

この2つが重なるため、外部エンジニア活用では「機密に触れる人が、同種の競合案件にも関わっている」という状況が、正社員雇用よりも起きやすくなります。だからこそ、雇用とは別の管理の発想が必要になります。

掛け持ち自体は禁止できない——フリーランス新法・独禁法という前提

ここで重要な制約があります。発注者の立場で「競合が心配だから掛け持ちを禁止する」と契約に書くことは、原則として適切ではなく、法的なリスクすら伴います。

公正取引委員会は、発注者がフリーランスに課す秘密保持義務・競業避止義務・専属義務について、合理的な範囲を超えて一方的に設定すると独占禁止法上の優越的地位の濫用として問題になりうる、との考え方を示しています（公正取引委員会「人材と競争政策に関する検討会 報告書」、競業避止義務に係る競争政策・独占禁止法上の考え方）。また2024年11月施行のフリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）も、発注者が優越的地位を背景に不当な義務を課すことを規制しています。

要するに、「競合だから一切の掛け持ちを禁止する」といった広範な制限は、無効と判断されたり行政指導の対象になったりするリスクがあります。発注者ができるのは、目的に照らして合理的な範囲——たとえば「自社プロジェクトで知り得た秘密情報を競合に利用しない」という秘密保持の延長線上の限定的な制限です。

このため、本記事は「禁止」を前提とせず、禁止に頼らない運用で利益相反を管理する方向に話を進めます。契約条項そのものをどう書けば無効にならないかという論点は、競業避止・副業禁止条項の書き方で詳しく扱っています。

競合案件・利益相反が招く具体的リスク（何が流出し何を失うか）

「情報が漏れるかもしれない」という不安は漠然としがちです。何が、どう流出して、自社が何を失うのかを具体化しておくと、後段の運用ルールに優先順位をつけられます。

情報・成果物の流出（要件/仕様/ソースコード/設計ノウハウ）

最も直接的なリスクは、自社のために作られた情報や成果物が、競合案件で再利用されることです。具体的には次のようなものが対象になります。

• 要件・仕様: 自社が時間とコストをかけて固めた要件定義や機能仕様。「こういう機能が刺さる」という知見ごと競合に渡る恐れがあります。
• ソースコード・設計ノウハウ: 自社向けに実装したアーキテクチャや独自ロジック。そのまま流用されなくても、「この設計で動く」という解だけが競合に伝わると、開発スピードで差を縮められます。
• データ・顧客情報: テストデータや本番に近いデータに触れた場合、その傾向や規模感が外部に伝わる懸念があります。

経済産業省の「秘密情報の保護ハンドブック」第5章では、他社の秘密情報を意図せず侵害してしまう典型例として、転職者の受け入れや共同開発、取引の中での秘密情報の授受などが挙げられています（経済産業省「秘密情報の保護ハンドブック」第5章 他社の秘密情報に係る紛争への備え）。外部エンジニアの掛け持ちも、これと同じ「人を介した情報の移動」が起きうる構造だと捉えると分かりやすいでしょう。受け手の競合側にとっても、意図せず他社の秘密情報を取り込んでしまう紛争リスクがある——つまり情報流出は双方にとって厄介な問題です。

稼働・優先度の利益相反（競合案件を優先され自社が後回しになる）

利益相反は、情報流出だけではありません。掛け持ち先の案件を優先された結果、自社のスケジュールが後回しにされる、というリソース配分上の問題も含みます。

たとえば競合案件で繁忙期が重なったとき、限られた稼働時間がそちらに割かれれば、自社のリリースが遅れます。さらに、自社と競合のどちらにも同じ機能領域で関わっている場合、「先に他社で実装した機能を、後から自社にも持ち込む」といった順序になり、自社が先行者の優位を取れなくなることもあります。情報が直接漏れていなくても、稼働の優先度を競合に握られること自体が不利益になりうるのです。

立証の難しさ——「漏れたかどうか」を後から証明できない構造的リスク

そして外部エンジニアの利益相反で最も厄介なのは、「実際に漏れたかどうか」を後から証明するのがきわめて難しい点です。

ソースコードや要件は、コピーして持ち出さなくても、頭の中の知識として競合案件に活かされてしまえば痕跡が残りません。「あのとき得た知見を流用したのでは」と疑っても、それを立証して契約違反を問うのは現実的に困難です。営業秘密として不正競争防止法で保護を主張するにも、自社がその情報を秘密として適切に管理していたこと（秘密管理性）の立証が必要になります。

この「事後に証明できない」という構造があるからこそ、利益相反は起きてから対処するのではなく、起きにくい状態を事前に作っておくこと——すなわち予防的な運用が決定的に重要になります。

競合案件のリスクを見極める判断基準（許容範囲の線引き）

ここがこの記事の核心です。掛け持ちを一律に禁止できない以上、発注者に必要なのは「この掛け持ちは許容できるか、警戒すべきか」を案件ごとに判定する物差しです。

リスク判定の2軸（競合度 × 情報機密度）

利益相反のリスクは、次の2つの軸の掛け合わせで決まります。

• 競合度: 相手の掛け持ち先が、自社にとってどれだけ直接の競合か。同じ顧客層・同じ市場を奪い合う直接競合なのか、領域は近いが顧客がかぶらない周辺事業なのか。
• 情報機密度: その人が自社で触れる情報が、どれだけ機密性が高いか。コア要件やソースコード全体に触れるのか、汎用的な一機能だけを切り出して任せるのか。

この2軸でマトリクスを描くと、リスクのグラデーションが見えてきます。

判断のポイントは、「競合だから即アウト」でも「機密に触れるから即アウト」でもなく、両方が高い右上の象限を最優先で避けることです。逆に左下、つまり競合でない掛け持ち先に対して限定的な機能だけを任せるケースは、ほとんど警戒する必要がありません。中間の2象限は、後述する運用（情報の隔離や契約での担保）でリスクを許容範囲まで下げられるかを検討する領域です。

「直接競合」と「周辺・隣接領域」をどう切り分けるか

このマトリクスを使う上で最も悩むのが、競合度の判定です。「同じ業界＝競合」と単純に捉えると、警戒範囲が広がりすぎて優秀な人材を確保できなくなります。

切り分けの目安は、顧客と提供価値がかぶるかどうかです。たとえば自社が中小企業向けの勤怠管理SaaSを開発しているとして、相手の掛け持ち先が次のどれかで判断は変わります。

• 大企業向けの人事評価SaaS: 同じHR領域ですが、顧客層もプロダクトの価値も異なるため、直接競合とは言いにくい周辺領域です。
• 中小企業向けの勤怠管理SaaS: 顧客層もプロダクトもほぼ一致する直接競合です。ここに自社のコア要件を見せるのは避けたい組み合わせです。
• ECサイトの構築案件: 領域がまったく異なり、競合とはみなせません。

実務では、相手の掛け持ち先の社名やサービス名まで聞けないことも多いため、「どんな業界の、どんな顧客層向けの、どんなプロダクトか」というレベルで確認し、自社の競合の定義（誰と顧客を奪い合っているか）と照らして判断します。自社にとっての競合の輪郭をあらかじめ言語化しておくと、面談でこの判定がスムーズになります。

許容しやすいケース・回避すべきケースの具体例

マトリクスを具体例に当てはめると、運用イメージがつかみやすくなります。

許容しやすいケース

• 競合でない企業の案件を掛け持つエンジニアに、自社の汎用的な機能（問い合わせフォーム、管理画面の一部など、自社のコア競争力に直結しない部分）の実装を任せる。
• 直接競合の案件を持つエンジニアでも、自社では設計に関与せず、仕様が確定した単機能の実装だけを限定範囲で任せ、コアのリポジトリや要件定義には触れさせない。

回避すべきケース

• 直接競合のプロダクトを並行開発しているエンジニアに、自社の中核要件の策定やアーキテクチャ設計を任せる。これは前述のマトリクスで最も危険な右上の象限であり、契約や運用でカバーしきれないため、そもそも依頼範囲を変えるか、別の人材を充てる判断が妥当です。

ここで大切なのは、回避すべきケースに当たったとき、必ずしも「その人との契約をやめる」必要はないということです。「コア要件には別の人材を充て、この人には競合とかぶらない部分を任せる」といった依頼範囲の調整で、人材を確保しつつリスクを下げられることもあります。線引きは「人を切る/切らない」ではなく「どの情報に、どの範囲で触れさせるか」で行うのが実務的です。

発注者ができる利益相反の管理方法（運用4ステップ）

判断基準ができたら、次はそれを日々の運用に落とし込みます。契約書1枚に頼るのではなく、参画前・稼働中・契約・申告の4つのレイヤーで多層的に管理するのが基本方針です。

参画前——面談での掛け持ち・競合確認

最初の防波堤は、契約を結ぶ前の面談です。ここで掛け持ち状況と競合の有無を確認しておけば、前述のリスクマトリクスに当てはめて依頼範囲を設計できます。聞きにくいと感じるかもしれませんが、淡々と事実確認として尋ねれば、多くのエンジニアは率直に答えてくれます。確認したい質問の例を挙げます。

• 現在、他社の案件を並行して受けていますか。差し支えない範囲で、どんな業界・どんなプロダクトか教えていただけますか。
• 今後、新たに競合領域の案件を受ける可能性はありますか。その場合、事前に共有いただくことは可能ですか。
• 過去に、複数のクライアントで似た領域の開発をした際、情報の取り扱いをどう区別していましたか。

最後の質問は、相手の情報管理に対する意識を測るのに有効です。「区別を意識している」と答える人は、利益相反のリスクをそもそも理解しており、安心して任せやすい傾向があります。この面談での確認は、相手を疑うためではなく、お互いが安心して長く協働するための前提合わせだ、というスタンスで臨むのがコツです。

稼働中——情報アクセスの最小化と環境隔離

参画後は、「触れられる情報を必要最小限にする」ことが最も効果的なリスク低減策です。情報に触れられなければ、流出も起きようがありません。技術的な隔離は、契約上の約束よりも確実に効きます。

• リポジトリ権限の限定: 全コードへのアクセスを与えず、担当する範囲のリポジトリ・ディレクトリにのみ権限を付与する。コアロジックは別リポジトリに分離しておく。
• 環境の分離: 本番データや顧客情報に触れる必要がない作業では、マスキングしたテストデータやステージング環境のみを使わせる。
• 共有範囲の限定: 要件定義や事業計画など、実装に直接必要のない上流の情報は、必要な部分だけを切り出して共有する。プロジェクト全体の戦略が見える資料は共有範囲から外す。

ここで一点、注意があります。情報アクセスを管理しようとするあまり、業務の進め方を細かく指示・命令しすぎると、業務委託の前提が崩れ偽装請負と指摘されるリスクが生じます。あくまで「触れられる情報の範囲を制御する」ことと、「作業の指揮命令をする」ことは別物として切り分け、後者には踏み込まないよう運用設計してください。

契約での担保——秘密保持・限定的な競業避止・申告義務

技術的な隔離を補完するのが契約です。ただし前述のとおり、広範な掛け持ち禁止は無効・行政指導のリスクがあるため、合理的な範囲に限定して定めます。発注者として契約で押さえておきたいのは次の要素です。

• 秘密保持: 自社プロジェクトで知り得た情報を、他案件で利用・開示しないこと。利益相反対策の中核です。
• 限定的な競業避止: 「一切の競合案件を禁止」ではなく、「自社の秘密情報を競合のために利用しない」という、秘密保持の延長線上に絞った形にする。
• 申告義務: 後述する、競合領域の新規案件に参画する際に事前共有する取り決め。

これらの条項を「無効にならない合理的な範囲」でどう文言化するかは、専門的な判断が必要です。秘密保持契約（NDA）の条項を結ぶ際の押さえどころはフリーランスエンジニアとのNDA締結ガイド、フリーランス新法で無効にならない競業避止条項の具体的な書き方は競業避止・副業禁止条項の書き方でそれぞれ詳しく解説しています。本記事は、それらの条項を「結んだ後にどう運用するか」に焦点を当てています。

申告ルール——新規案件参画時の自己申告と発注者の判断フロー

契約・隔離を補う最後のレイヤーが、稼働中の申告ルールです。参画時点では競合がいなくても、契約期間中に新しい競合案件を受ける可能性はあります。この変化を把握する仕組みがないと、せっかくの初期チェックが形骸化します。

運用としては、「自社と競合する可能性のある領域の新規案件に参画する際は、事前に一言共有してほしい」という軽い申告ルールを契約や口頭の合意で設けておきます。共有を受けたら、発注者は前述のリスクマトリクスに当てはめて、(1) そのまま継続、(2) 依頼範囲やアクセス権の調整、(3) 個別に相談、のいずれかを判断します。

ポイントは、申告を「許可制」ではなく「共有制」にすることです。「許可がなければ受けてはいけない」とすると、相手の職業の自由を制約しすぎて独禁法上の懸念が生じます。あくまで「教えてもらえれば、自社側で情報の触れ方を調整する」という発注者側の運用に寄せると、法的にも人材との関係上も無理がありません。

利益相反が疑われたときの対応と、信頼関係を壊さない伝え方

予防に努めても、「もしかして競合に情報が流れているのでは」と疑念が生じる場面はありえます。ここでの対応を誤ると、関係が壊れたり、逆に放置して被害が広がったりします。冷静な手順と、信頼を保つ伝え方の両方が必要です。

利益相反が疑われたときの段階的対応フロー

疑念が生じたら、いきなり契約違反を問うのではなく、段階を踏みます。

1. 事実確認: まず本人に、掛け持ち状況や懸念している点を直接確認します。誤解や思い込みであることも多く、ここで解消するケースが大半です。
2. 影響範囲の特定: 仮に競合案件への関与が事実だった場合、その人が自社で触れていた情報の機密度と、競合との重なり具合を確認します。前述のマトリクスで「どの象限か」を改めて評価する作業です。
3. アクセス制限・契約に基づく対応: 影響が大きいと判断した場合は、該当する情報へのアクセス権を見直し、依頼範囲を調整します。実害や契約違反が明確な場合に限り、秘密保持条項に基づく対応を検討します。

重要なのは、立証が難しいリスクである以上、「疑い」の段階では懲罰的な対応に走らず、まず情報の触れ方を制御する方向で被害の拡大を止めることです。

信頼を壊さずに掛け持ち状況を確認するコミュニケーション

確認の場で相手を「疑っている」という前提で詰めると、たとえ潔白でも信頼関係は大きく傷つきます。優秀な人材ほど、信用されていないと感じれば離れていきます。

伝え方の工夫としては、「あなたを疑っている」のではなく「自社の情報管理上、確認が必要なルールになっている」という、仕組みの話として切り出すのが有効です。たとえば「うちは外部の方と協働する際に、競合領域の案件状況を一度確認させていただくことにしていて」と、個人への疑念ではなく社内ルールとして提示すれば、相手も事務的に応じやすくなります。面談時に申告ルールを最初に説明しておけば、稼働中の確認も「最初に合意したあれですね」と自然に進められます。

「管理しすぎ」で優秀な人材を失わないためのバランス

最後に、管理の強度そのものについてです。利益相反を恐れるあまり、掛け持ちを根掘り葉掘り詮索したり、過剰なアクセス制限で業務を動きにくくしたりすると、優秀な外部人材ほど「この発注者とは仕事がしづらい」と離れていきます。これは情報流出とは別種の、しかし確実な損失です。

バランスの目安は、禁止や監視ではなく、情報設計でリスクを下げるという発想に立つことです。掛け持ち自体を制限するのではなく、「触れる情報を最小化し、競合とかぶる領域では依頼範囲を調整する」という設計でリスクの大半は抑えられます。人を縛るのではなく情報を設計する——この発想に立てば、優秀な人材を確保しながら、情報流出のリスクを許容範囲に収める両立が可能になります。

競合案件・利益相反リスクを抑えながら外部エンジニアを活用する体制づくり

ここまでは個別案件の管理を見てきました。最後に、発注のたびに同じ不安を繰り返さないための、組織としての仕組み化の視点を示します。

利益相反チェックを発注プロセスに組み込む

個人の判断や記憶に頼った管理は、担当者が変わると失われ、案件ごとに品質がぶれます。利益相反のチェックを、発注の標準プロセスに組み込んでしまうのが確実です。

具体的には、外部エンジニアに発注する際の手順に、「掛け持ち・競合状況の確認」「触れる情報の機密度の整理」「依頼範囲とアクセス権の決定」「申告ルールの説明」という4点をチェックリスト化して埋め込みます。本記事のリスクマトリクスと運用4ステップは、そのままチェックリストの骨子として使えます。プロセス化しておけば、法務の専任がいなくても、誰が発注しても一定水準のリスク管理が担保されます。

素性・稼働状況が見える形で発注する（人材活用基盤の活用）

利益相反リスクの根っこには、「相手の掛け持ち状況や素性が見えにくい」という情報の非対称があります。直接の知人やリファラル経由でない外部エンジニアの場合、相手が今どんな案件に関わっているか、どんな実績があるかを発注者が把握しづらく、それが不安を増幅させます。

この非対称を構造的に下げる方法のひとつが、エンジニアの実績・稼働状況がある程度可視化された人材活用基盤を通じて発注することです。誰がどんな専門性で、どんな稼働状況にあるかが見える状態で発注できれば、参画前の面談確認も精度が上がり、競合度の判定もしやすくなります。情報設計でリスクを下げるという本記事の発想は、個別の運用だけでなく、「そもそもどういう経路で発注するか」という体制の選択にも延長できます。

外部エンジニアの活用は、リスクを正しく見極めて管理すれば、自社の開発力を大きく押し上げてくれる選択肢です。掛け持ちを恐れて禁止に走るのでも、不安なまま放置するのでもなく、「競合度 × 情報機密度」でリスクを切り分け、面談・情報隔離・契約・申告の多層で管理する——その骨子を発注プロセスに組み込めば、優秀な人材の確保と情報流出の防止は十分に両立できます。まずは自社にとっての「競合の輪郭」と「守るべき機密の範囲」を言語化するところから、ルールづくりを始めてみてください。