【プロの鉄則】派遣・請負・準委任の違いとは？ITエンジニアが知っておきたい契約・著作権の基本について

「このコード、勝手にコピーして使っても大丈夫？」「自分は派遣なのか請負なのか、正直よく分かっていない」——エンジニアとして働き始めると、こうした法律に関わる疑問に不意に直面します。法律は難しいだけの堅苦しいルールではなく、いわば「社会という巨大なシステムの仕様書」です。

この記事では、資格試験のための丸暗記ではなく、エンジニアが実務で実際につまずきやすいポイントに絞って、契約形態・著作権・オープンソースライセンスの基本をわかりやすく解説します。

なぜエンジニアに「法務リテラシー」が必要なのか

知らなかったでは済まされない、契約・著作権トラブル

「技術力さえあれば法律の知識はいらない」と考えるエンジニアは少なくありません。しかし、業務で使うオープンソースのライセンス条件を知らずに製品に組み込んでしまったり、自分の契約形態を理解しないまま指示系統の曖昧な現場で働いてしまったりすると、本人が気づかないうちにトラブルの当事者になってしまうことがあります。法律の知識がないことは、技術力とは別の場所で、思わぬリスクを引き受けてしまう原因になるのです。

法律は「社会という巨大なシステムの仕様書」

法律と聞くと、堅苦しく難しいものだと身構えてしまうかもしれません。しかし、法律は「こういう場合はこう扱う」というルールを定めたものという意味で、社会という巨大なシステムを動かすための仕様書のようなものだと考えると、エンジニアにとってはむしろ理解しやすい存在です。仕様書を読まずにシステムを触ると思わぬバグを引き起こすように、法律という仕様書を知らずに働くと、思わぬトラブルを引き起こしてしまいます。

自分がどの契約形態で働いているかを理解する

派遣・請負・準委任の違いと、それぞれの指揮命令権

エンジニアの働き方には、主に「派遣」「請負」「準委任（SES契約はこの形態が多い）」という契約形態があります。この3つの大きな違いは「誰が指揮命令をするか」と「何に対して責任を負うか」です。

• 派遣：派遣先の会社から直接指示を受けて働く。指揮命令権は派遣先にある
• 請負：成果物の完成に対して責任を負う。仕事の進め方は基本的に自社の裁量に委ねられ、発注先から直接の指揮命令を受けることは想定されていない
• 準委任：成果物の完成ではなく、業務の遂行そのものに対して責任を負う。請負と同様、発注先から直接の指揮命令を受けることは想定されていない

自分がどの契約形態で働いているかを理解していないと、「本来は指揮命令を受けるはずのない相手から直接指示を受けている（いわゆる偽装請負の状態）」といった問題に気づけません。まずは自分の契約形態を確認し、その契約でどこまでの指示を受けるのが適切なのかを把握しておくことが大切です。

NDA（秘密保持契約）で何を守る必要があるのか

エンジニアとして働き始める際、多くの場合はNDA（秘密保持契約）にサインします。NDAは、業務で知り得た会社の技術情報や顧客情報などを、契約期間中はもちろん、退職後も含めて外部に漏らさないことを約束する契約です。

具体的には、SNSでの業務内容の投稿、転職時の職務経歴書への詳細すぎる記載、前職で使っていたソースコードの一部を新しい職場で流用することなどが、意図せずNDA違反にあたる可能性があります。「秘密保持契約にサインした」という事実だけでなく、「具体的に何を、いつまで守る約束をしたのか」を意識しておくことが重要です。

自分が書いたコードの著作権は誰のものか

著作権は「創作した瞬間」に発生する

著作権は、特許のように出願・登録の手続きを必要とせず、プログラムを書いた（創作した）瞬間に自動的に発生します。この仕組みを「無方式主義」と呼びます。つまり、誰かが書いたコードは、何も手続きをしていなくても、書いた時点でその人（または後述する条件のもとで所属先の会社）に著作権が存在していることになります。

業務で作ったプログラムは基本的に会社に帰属する（職務著作）

「自分が書いたコードなら、著作権も自分のものでは」と思うかもしれませんが、会社の業務として、会社の指示のもとで作成したプログラムの著作権は、契約や就業規則に別段の定めがない限り、原則として会社に帰属します。これを「職務著作」と呼びます。

副業やポートフォリオ用に個人的に開発したコードと、業務として開発したコードとでは、著作権の扱いが異なる可能性があるという点は、意識しておく必要があります。特に、業務で得た知見をもとに個人開発を行う場合や、退職後に前職のコードを流用する場合は、著作権と先ほどのNDAの両方に注意が必要です。

オープンソースを使うときに知っておきたいライセンスの基本

MIT・Apache・GPLなど代表的なライセンスの違い

オープンソースのライブラリやフレームワークには、それぞれ「ライセンス」というルールが定められています。代表的なものに次のようなものがあります。

• MITライセンス：改変・再配布・商用利用ともに自由度が高く、ライセンス表示の記載程度の条件で利用できる
• Apacheライセンス：MITと同様に自由度が高いが、特許に関する取り決めなど、より詳細な条件が定められている
• GPLライセンス：ソースコードを組み込んだ自分のソフトウェアも、同じくGPLで公開する義務が生じる場合がある（コピーレフト）という、他のライセンスより制約が強い特徴を持つ

これらのライセンスの違いを理解しないまま、GPLライセンスのコードを自社の非公開の製品に組み込んでしまうと、意図せずライセンス違反を引き起こすことがあります。

「商用利用可」だけで判断しない注意点

ライセンスを確認する際、「商用利用可」という一言だけで安心してしまいがちですが、実際には「著作権表示の保持」「変更箇所の明示」「同一ライセンスでの再配布」など、ライセンスごとに細かい条件が定められています。ライブラリを採用する前には、ライセンス条文全体、少なくとも公式ドキュメントに書かれた利用条件のサマリーには目を通す習慣をつけておきましょう。

この法務リテラシーが、エンジニアとしての信頼につながる

契約形態の違い、NDAの基本、著作権の帰属、オープンソースライセンスの注意点——ここまで見てきた内容は、どれも専門の法律家でなくても、エンジニアが自分の身を守るために知っておくべき基礎知識です。

法律の知識は、エンジニアの仕事を制限するものではなく、むしろ「知らずにトラブルに巻き込まれる」というリスクを避け、専門職としての信頼を築くための土台になります。より体系的な知的財産権の分類や、個人情報保護法、ISO・JISといった標準化の知識まで押さえておきたい場合は、姉妹記事「著作権と特許ってどう違う？IT初心者のためのiパス法務まるわかり講座」もあわせて確認してみてください。

Q&A｜エンジニアの法務リテラシーに関するよくある質問

エンジニアに法律の知識が必要なのはなぜですか？

オープンソースのライセンス違反や、契約形態を理解しないまま働くことによるトラブルなど、技術力とは別の場所で思わぬリスクを引き受けてしまう可能性があるためです。

派遣・請負・準委任の違いは何ですか？

主な違いは「誰が指揮命令をするか」です。派遣は派遣先が指揮命令を行いますが、請負・準委任では発注先からの直接の指揮命令は想定されていません。

業務で書いたプログラムの著作権は誰のものですか？

契約や就業規則に別段の定めがない限り、業務として作成したプログラムの著作権は原則として会社に帰属します（職務著作）。

オープンソースのライセンスで気をつけることは何ですか？

MIT・Apache・GPLなどライセンスごとに条件が異なります。「商用利用可」という言葉だけで判断せず、著作権表示や再配布時の条件などを確認する必要があります。

体系的な法律知識をもっと詳しく知りたいです

知的財産権の分類や個人情報保護法、ISO・JISなどの標準化については、姉妹記事「著作権と特許ってどう違う？IT初心者のためのiパス法務まるわかり講座」で解説しています。