知人・友人価格で作ってもらったシステム、その「権利関係」を今のうちに確認する

創業したばかりの会社が最初のシステムやウェブサイトを作るとき、多くの経営者が最初に思いつく選択肢は「知り合いのエンジニアに頼む」というものです。大学時代の友人、前職の同僚、起業家仲間の紹介で知り合ったフリーランスエンジニア――理由は様々ですが、見積もりを取って比較検討するよりも先に、「あの人に頼めば安く作ってもらえるかもしれない」という発想が先に立つのは、資金の乏しい創業期にはごく自然な流れです。実際、知人価格で開発してもらえれば、相場よりもかなり安くシステムやウェブサイトを持つことができ、創業期の限られた予算の中では大きな助けになります。

しかし、この「知人・友人への発注」には、通常の開発会社への発注とは異なる特有のリスクが潜んでいます。それは、価格の安さと引き換えに、契約書を交わさない、あるいは交わしても簡易なものに留める、という選択をしがちだという点です。「友人同士なんだから契約書なんて水臭い」「口約束で十分」という空気は、創業期の人間関係の温かさの表れでもありますが、同時に将来のトラブルの火種にもなり得ます。

このガイドでは、知人・友人価格で発注したシステムについて、関係が良好な「今」のうちに確認しておくべき権利関係のポイントを解説します。関係が悪化してから、あるいは相手と連絡が取れなくなってから確認しようとしても手遅れです。だからこそ、まだ良好な関係が続いている今このタイミングこそが、確認のための最後にして最良の機会なのです。

なぜ知人・友人発注は「権利関係」で特につまずきやすいのか

通常、開発会社に外注する場合は、見積書・契約書・仕様書といった書類のやり取りが発注プロセスに組み込まれています。書類を作成する過程で、著作権の帰属や納品物の範囲について、双方が自然と確認し合う機会が生まれます。開発会社側も、こうした契約書のひな形を過去の案件から用意していることが多く、抜け漏れが起きにくい構造になっています。

一方、知人・友人への発注では、こうしたプロセスがまるごと省略されてしまうことが珍しくありません。「とりあえず作ってみるね」という口約束から始まり、完成品ができあがったら報酬を払う、という流れで進んでしまうケースです。この場合、次のような点が曖昧なまま放置されがちです。

• ソースコードの著作権が発注者(会社)側に譲渡されているのか、開発した本人に残っているのか
• ソースコード一式が発注者に納品されているのか、開発者の手元にしかないのか
• 開発に使ったサーバーやドメインの契約が、会社名義になっているのか、開発者個人の名義になっているのか
• 今後の改修や機能追加を、その開発者以外の人間が引き継げる状態になっているのか
• 万が一その開発者と連絡が取れなくなった場合、誰がどう対応すればよいのか

これらはいずれも、通常の外注であれば契約書や納品物の授受を通じて自然に明確化される事柄です。知人・友人発注では、この明確化のプロセスがすっぽり抜け落ちてしまうリスクがあるということを、まず認識しておく必要があります。

著作権は「作った人」に残るのが法律上の原則

日本の著作権法では、プログラムの著作権は、契約で特に取り決めがない限り、それを実際に作成した人(この場合は発注を受けた知人・友人)に帰属するのが原則です。会社側がお金を払ったからといって、自動的に著作権が会社に移るわけではありません。著作権を会社側に移すためには、契約書などで「著作権を発注者に譲渡する」という明確な取り決めが必要です。

これは知人・友人への発注に限った話ではなく、通常の外注取引でも共通する原則ですが、契約書を交わさない知人発注では、この譲渡の取り決め自体が存在しないケースが多く見られます。著作権が開発者本人に残ったままだと、たとえ完成したシステムを日常的に会社が使っていたとしても、法律上はそのシステムの著作権者は開発者本人のまま、という状態が続くことになります。この状態では、たとえば別の開発者に改修を依頼する際に著作権者である本人の許諾が必要になったり、システムを大きく作り変えたいと思っても自由に手を加えられなかったりする可能性があります。著作権と契約書の関係については、ソースコードの著作権は誰のもの？契約書の確認ポイントで詳しく解説していますので、あわせて参照してください。

まず確認すべきこと: 契約書は存在するか

権利関係を確認する最初のステップは非常にシンプルです。「その開発について交わした契約書、あるいはそれに準ずる書面が存在するか」を確認することです。メールやチャットツールでのやり取りも、内容次第では契約の成立を示す証拠になり得ますので、正式な契約書がなくても、当時のやり取りを遡って確認してみてください。

確認した結果、次のいずれかの状態に当てはまることが多いはずです。

自社がどの状態に当てはまるかによって、次に取るべき対応の緊急度が変わってきます。表の下に行くほど、対応の優先度は高くなります。

ソースコード一式は手元にあるか

契約書の有無と並んで確認すべきなのが、ソースコード一式が実際に発注者側の手元にあるかどうかです。契約書上は著作権が譲渡されていたとしても、開発に使ったソースコード自体が開発者個人のパソコンやアカウントにしか存在しない、という状態は珍しくありません。

特に注意したいのが、ソースコードの管理に使われるGitHub等のバージョン管理サービスのアカウントです。開発を担当した知人・友人が、自分個人のアカウントでリポジトリ(ソースコードを保管する場所)を作成し、そこで開発を進めているケースが非常に多く見られます。この場合、そのリポジトリへのアクセス権限が発注者側の会社に一切与えられていないと、万が一その人と連絡が取れなくなった際に、ソースコードそのものにアクセスできなくなるという事態が起こり得ます。

確認すべきポイントは次の3点です。

1. ソースコードがどこに(どのサービスの、どのアカウントに)保管されているか
2. そのアカウントまたはリポジトリに、会社側の誰かがアクセスできる権限を持っているか
3. 最新版のソースコード一式を、会社側でもダウンロード・保管できる状態になっているか

この3点がすべて確認できていれば、少なくともソースコードへのアクセスという点では大きな不安はありません。逆に、いずれか1つでも確認できない場合は、早めに開発者本人に相談し、アクセス権限の付与やソースコード一式の受け渡しをお願いすることをお勧めします。

サーバー・ドメインの契約名義も忘れずに確認する

システムの権利関係というと、多くの人はソースコードの著作権にばかり意識が向きがちですが、実際にはサーバーやドメインの契約名義という、また別の確認事項があります。知人・友人に開発を依頼した際、その人が使い慣れたサービスでサーバーを契約し、そのまま自分個人のクレジットカードで支払いを続けている、というケースが少なくありません。

この場合、表面上はシステムが問題なく稼働していたとしても、実際の契約者はあくまで開発者個人であり、会社はその契約に対して何の権限も持っていないという状態になります。契約者本人の意向次第で、いつでもサーバーが停止される可能性がある、という構造的なリスクを抱えたまま日常の業務が回っている、と言い換えることもできます。

サーバー・ドメインの契約名義を確認する際は、次の質問を開発者本人に投げかけてみるとよいでしょう。

• 「このサーバーの契約者名義は誰になっていますか」
• 「支払いは誰のクレジットカードから行われていますか」
• 「管理画面へのログイン情報は、会社側でも把握できていますか」

これらの質問は、決して相手を疑っているというニュアンスで伝える必要はありません。「会社としてきちんと管理体制を整えたいので、確認させてほしい」という前向きな理由で伝えれば、良好な関係を保ったまま自然に確認を進められるはずです。

「関係が良好な今」だからこそ確認しやすい理由

このガイドのタイトルにもある通り、権利関係の確認は「関係が良好な今」のうちに行うことを強くお勧めします。理由は単純で、人間関係というものは、ビジネス上の些細なすれ違いや、双方の状況の変化によって、いつ変わってしまうか分からないからです。

知人・友人への発注では、報酬額や納期について明確な取り決めがないまま進んでしまうことも多く、後になって「思っていたより手間がかかった」「対価が見合っていなかった」といった不満が双方に蓄積し、関係がぎくしゃくしてしまうケースも見られます。あるいは、開発者本人が転職や独立、引っ越しといったライフイベントを経て、徐々に連絡が取りづらくなっていくというケースも珍しくありません。

こうした変化が起きる前、つまり気軽に「ちょっと確認させて」と言い出せる今のタイミングであれば、権利関係の確認は決して重い話ではありません。むしろ、開発者本人にとっても「ちゃんと引き渡しの体制を整えてくれている」という安心材料になり、双方にとってプラスに働くことがほとんどです。逆に、関係が悪化してから、あるいは連絡が取れなくなってから確認しようとすると、著作権の譲渡やソースコードの引き渡しといった具体的な対応を依頼すること自体が、非常にハードルの高い交渉になってしまいます。

確認の切り出し方: 角を立てない伝え方の例

権利関係の確認を切り出す際、「契約書がなかったので不安です」とストレートに伝えると、相手によっては「信頼されていないのか」と受け取ってしまう可能性もあります。角を立てずに切り出すための言い回しの例をいくつか紹介します。

「そういえば、あのシステムのソースコードって、今どこに保管されてる? 会社としてちゃんと管理体制を整えたくて、確認させてもらえると助かる」

「創業したばかりの頃は勢いで進めちゃったから、今のうちに契約関係をきちんと整理しておきたいんだけど、簡単な確認だけさせてもらえる?」

「最近、うちの会社もIT周りの管理をちゃんとしようって話になっていて、当時お願いしたシステムについても、著作権の扱いだけ確認させてもらえたら」

いずれの言い回しも、相手を疑っているのではなく、会社として当たり前の管理体制を整えたいという前向きな文脈で伝えている点が共通しています。この伝え方であれば、良好な関係を損なわずに、必要な情報を確認できる可能性が高くなります。

確認した結果、権利関係が曖昧だと分かったらどうするか

確認の結果、著作権の譲渡が明記されていない、あるいはソースコードへのアクセス権限が会社側にない、といった状態が判明した場合、次のステップとして簡易な合意書を後から取り交わすという対応が考えられます。すでに納品・稼働しているシステムについて、改めて「著作権を発注者に譲渡する」「ソースコード一式を発注者に引き渡す」という内容の書面を、今からでも作成することは十分可能です。

このとき重要なのは、金額の再交渉のような重い話にしないことです。当初の対価はすでに支払い済みであることを前提に、「権利関係を明文化するための書面を、念のため今から交わしておきたい」という趣旨で相談すれば、多くの場合は快く応じてもらえるはずです。書面のひな形については、ソースコードの著作権は誰のもの？契約書の確認ポイントで紹介されている確認ポイントを参考に、簡易なものから作成してみてください。

もし相手との調整が難航する、あるいは既に連絡が取りづらい状況にある場合は、無理に自分たちだけで解決しようとせず、弁護士など専門家への相談も選択肢に入れてください。特に、そのシステムが事業の根幹に関わる重要なものである場合は、早めに専門家の見解を仰ぐことをお勧めします。

継続性のリスク: 「その人しか分からない」システムになっていないか

権利関係と並んで確認しておきたいのが、そのシステムの継続性です。知人・友人が個人の裁量で開発を進めた場合、設計書や仕様書といったドキュメントが整備されておらず、「作った本人しか中身が分からない」システムになっていることが少なくありません。これは属人化の一種であり、開発者本人が何らかの理由で対応できなくなった場合、誰も改修や不具合対応ができなくなるという深刻なリスクにつながります。

継続性の観点から確認しておきたいのは、次のような点です。

• システムの構成や使用している技術について、簡単な説明書きが残っているか
• 不具合が起きた際、その開発者以外の誰かが対応できる体制があるか
• 万が一その開発者に連絡が取れなくなった場合の代替手段を検討したことがあるか

これらの確認は、権利関係の確認と同時に進めておくと効率的です。権利関係(法律上・契約上の話)と継続性(実務上、誰が対応できるかという話)は、性質の異なる問題ですが、どちらも「その人がいなくなったらどうなるか」という同じ問いに行き着く点で密接に関連しています。

「うちでしか直せません」と言われる前に

知人・友人への発注に限らず、開発を1人の担当者に依存させてしまうと、いずれ「このシステムは、あの人にしか分からない」という状態に行き着きます。この状態が進行すると、たとえ悪意がなくても、事実上その人にシステムの改修・保守を独占されてしまう構造ができあがります。こうした状況に実際に直面した場合の対処法については、「うちでしか直せません」と言われたときの対処法で扱っている考え方も参考になります。

知人・友人発注の場合、相手が善意で協力してくれているケースがほとんどなので、「独占されている」という感覚を持ちにくいかもしれません。しかし、権利関係と継続性が曖昧なまま放置されている状態は、相手の意図とは関係なく、構造としては同じリスクを抱えていることに変わりありません。だからこそ、良好な関係が続いている今のうちに、権利関係を明確にし、継続性を担保する準備を進めておくことが重要なのです。

今後、知人・友人に発注する場合の予防策

すでに知人・友人へ発注してしまったシステムの確認と並行して、今後同様の発注を行う際の予防策も考えておくとよいでしょう。ポイントは、知人・友人であっても、通常の外注取引と同じレベルの書面を最低限交わすという原則を、最初から決めておくことです。

具体的には、簡易なものでも構わないので、次の3点だけは書面(メールでの合意でも構いません)に残しておくことをお勧めします。

• 著作権は発注者(会社)に譲渡される旨の一文
• 納品物としてソースコード一式を発注者に引き渡す旨の一文
• 報酬の金額と支払い時期

この3点さえ押さえておけば、たとえ簡易な書面であっても、後々のトラブルを大きく減らすことができます。「友人だから契約書はいらない」という発想を、「友人だからこそ、後々気まずくならないように最低限の書面を交わしておく」という発想に切り替えることが、長期的には双方にとって望ましい関係を保つことにつながります。

対価が「知人価格」だったことの副次的な注意点

知人・友人への発注では、対価そのものが相場よりも大幅に安く設定されていることも多くあります。これは創業期の資金繰りにとって大きな助けになる一方、副次的な注意点も存在します。それは、対価が安い分、開発者側の優先順位が下がりがちだという点です。

正規の対価を払って発注した開発会社であれば、契約上の義務として一定の対応が期待できますが、知人価格・友人価格での発注の場合、開発者本人の本業や他の案件が優先され、改修や不具合対応が後回しにされてしまう可能性があります。これは契約書の有無とは別の、実務上のリスクとして認識しておく必要があります。

このリスクへの対処法としては、日頃からのコミュニケーションを大切にすることに加えて、前述の継続性の確認、つまり「その人以外にも対応できる体制」を並行して整えておくことが有効です。知人・友人への発注そのものを否定する必要はありませんが、対価の安さの裏にあるこうした構造的な特徴は、頭の片隅に置いておいてください。

知人発注に限らない: フリーランスへの発注でも同じ構造は起こる

ここまで「知人・友人」という関係性に焦点を当てて説明してきましたが、同じ構造は、クラウドソーシングサービスなどで知り合ったフリーランスへの発注でも起こり得ます。個人間のやり取りが中心となり、契約書の締結が省略されがちな発注形態全般に共通するリスクだと理解しておくと、より広い視野で自社の状況を点検できます。

クラウドソーシングサービス経由の発注であれば、サービス自体が簡易な契約テンプレートや取引の記録機能を提供していることが多く、知人・友人への直接発注に比べればまだ記録が残りやすい傾向があります。とはいえ、著作権の譲渡条項が契約に明記されているかどうかは別問題であり、サービスを介しているからといって安心はできません。発注先が知人であってもフリーランスであっても、確認すべきポイントは基本的に同じです。著作権の帰属、ソースコードの所在、継続性の3点を、発注の形態にかかわらず一律にチェックする習慣を持っておくことをお勧めします。

権利関係の確認を怠った場合に起こり得る、具体的なシナリオ

権利関係が曖昧なまま放置された場合、実際にどのような事態に発展し得るのか、いくつかの典型的なシナリオを紹介します。

創業時に知人のエンジニアに頼んで作ってもらった顧客管理システムを、5年間ずっと使い続けていた。ある日、機能追加をお願いしようとしたところ、その知人とは半年前から連絡が取れなくなっていることに気づいた。ソースコードは知人個人のアカウントにしか保管されておらず、会社側にはアクセス権限がない。結局、既存のシステムを一から作り直すことになり、当初の開発費用を大きく上回るコストがかかった。

独立した知人にウェブサイト制作を依頼し、対価は相場よりかなり安く抑えられた。数年後、事業拡大に伴いサイトの大幅リニューアルを検討したところ、著作権が発注者側に譲渡されていないことが判明。知人本人からは快く著作権譲渡に応じてもらえたものの、念のため専門家に確認したところ、当初の契約書に譲渡条項がなかったことで、法的には長期間曖昧な状態が続いていたことが分かった。

これらのシナリオに共通するのは、契約した当初は何の問題もなく、数年経ってから初めて権利関係の曖昧さが表面化するという点です。表面化するタイミングは、機能追加やリニューアルなど、事業が前向きに動き出そうとする瞬間であることが多く、その意味でも、事業の成長を妨げる要因になり得ます。

開発以外の業務委託でも同じ視点は応用できる

このガイドではシステム開発を中心に解説してきましたが、知人・友人への業務委託全般において、同じ視点は応用できます。例えば、知人にロゴやデザインを制作してもらった場合の著作権の扱い、知人にライティングを依頼した記事の著作権の扱いなど、成果物が発生する業務委託であれば、基本的な考え方は共通しています。

創業期は、システム開発以外にも様々な業務を知人・友人に頼ることが多いはずです。この機会に、システム開発に限らず、これまで知人・友人に依頼した成果物について、権利関係が明確になっているかを一通り棚卸ししてみることをお勧めします。10人未満というこの段階であれば、棚卸しの対象もまだ限られており、無理なく取り組める範囲に収まるはずです。

対価を後払いで調整するという選択肢もある

権利関係が曖昧だった場合の対処として、著作権の譲渡やソースコードの引き渡しをお願いする際に、当初の対価が相場よりもかなり安かったことを踏まえて、追加の対価を支払うという選択肢も考えられます。知人・友人価格での発注は、多くの場合、通常の相場よりも大幅に安い金額で行われています。数年後に改めて権利関係を明確にする際、当初の対価との差額の一部を追加で支払うことで、双方にとって納得感のある形に着地させるという進め方です。

この方法は、法律上必須というわけではありませんが、実務上は有効な手段です。特に、開発者本人が独立してフリーランスや法人として活動するようになっていた場合、「当時は知人価格だったが、今は正規の対価で権利関係を整理させてほしい」という提案は、相手にとっても納得しやすいものになりやすく、良好な関係を保ちながら権利関係を整理する後押しになります。金額の目安に迷う場合は、同種の開発案件の一般的な相場を調べた上で、当初支払った金額との差額を目安に検討するとよいでしょう。

権利関係の確認を、事業計画の中に位置づける

権利関係の確認は、単なる法務上の手続きというだけでなく、会社の事業計画そのものにも関わる重要な作業です。例えば、将来的に外部からの資金調達(融資や出資)を検討している場合、投資家や金融機関から、事業の根幹を支えるシステムの権利関係について確認を求められる場面が出てきます。この際、権利関係が曖昧なままだと、資金調達のプロセスそのものが滞ってしまう可能性があります。

また、将来的に会社を売却する、あるいは事業譲渡を行うという選択肢を検討する場合も同様です。買い手側は、譲渡対象となる事業が保有する資産(システムを含む)の権利関係を必ず精査します。この段階になって初めて権利関係の曖昧さが発覚すると、交渉自体が難航したり、譲渡価格に影響が出たりする可能性があります。

10人未満という創業間もない段階では、資金調達や事業譲渡はまだ遠い未来の話に感じられるかもしれません。しかし、権利関係の整理は、事業が大きくなればなるほど対応が難しくなる性質のものです。将来の選択肢を狭めないためにも、今のうちに整理しておく価値は十分にあります。

まとめ: 良好な関係のうちに、権利関係を「見える化」する

知人・友人価格でシステムを作ってもらうという選択は、創業期の限られた予算の中では合理的な判断であり、それ自体は何ら問題ありません。しかし、契約書を交わさない、あるいは簡易な書面で済ませてしまうことが多いこの発注形態には、著作権の帰属、ソースコードの所在、サーバー・ドメインの契約名義といった権利関係が曖昧なまま放置されるリスクが特有のものとして存在します。

このガイドで紹介した確認事項は、いずれも今すぐ、しかも当事者同士の良好な関係を保ったまま進められるものばかりです。契約書は存在するか、ソースコード一式は手元にあるか、サーバー・ドメインの名義は誰か。この3点をまず確認し、曖昧な点が見つかれば、今のうちに簡易な合意書を交わしておく。この一手間が、数年後に関係が変化したり、開発者本人と連絡が取れなくなったりした際の、会社としての備えになります。

関係が良好な今この瞬間こそが、最も角を立てずに、最もスムーズに確認を進められるタイミングです。ぜひ今日、当時発注した相手に「そういえば」の一言から、確認の会話を始めてみてください。自社の状況を客観的に把握したい場合はひとり情シス危険度診断を、より詳しいチェック形式で進めたい場合はチェックリスト集もあわせてご活用ください。