ソフトウエアがあらゆるビジネスの土台になる時代。テクノロジーの担い手たるエンジニアに、多くのビジネスチャンスが広がっているのは間違いない。

一方でその分だけ、トラブルに巻き込まれるリスクが大きくなっているとも言えるだろう。自分の身や、心血注いだプロダクトやコードを守るための「自衛力」の必要性も高まっている。

そこで今回は、本誌連載中のIQ170メンサ会員（※）IT弁護士・河瀬季さんに、今エンジニアが身に付けるべき「自衛力」としての法律知識を聞いた。

河瀬さんはもともとITエンジニア、IT起業家としてキャリアをスタートし、その後、弁護士に転身。培ったIT知識を生かして、現在は企業や個人エンジニアの顧問弁護士などを務めている。

自身の経験から「エンジニアと法律知識は相性がいい」と話す河瀬さん。インタビュー後半では河瀬さんのキャリアにも触れ、法律や契約などに苦手意識を持つ人の背中を押すアドバイスをもらった。

※メンサ…人口上位2%のIQ（知能指数） を持つ人たちが参加する国際グループ

トラブルの原因は「結局何を作るのか」が不明確なこと

いくつかありますが、類型的に多いのは、いわゆるIT企業や個人エンジニアの方の顧問弁護士としての仕事です。

企業や個人が関わるシステム開発の契約書や、サービスをリリースする際の利用規約周りをチェックすること、発生した紛争の解決を目指すことなどがわれわれの役割になります。

契約書というのは極めて抽象的なアルゴリズムです。その契約書が今後発生するトラブルに十分耐えられるものなのかを判断するには、より具体的にどんな問題が起こり得るのかをイメージできないといけません。

例えば、私は自分で不動産を買ったことがないので、不動産を買ったり家を建ててもらったりする際にどんなトラブルが、どの程度の危険度で起こり得るのかについて、具体的なイメージを持っていません。

一方でITに関しては、9歳でプログラミングを始め、19歳からは仕事として携わってきました。ゆえに、そのあたりのことが具体的にイメージできる強みがあります。

世の中に数あるサービス、プロダクトの中でも、ITシステムは少し特殊なものだと思います。そもそもが目に見えないですし、手で触れられない。発注側・受注側の双方とも完成形を100%イメージできないままに、プロジェクトが進むことも多いですよね。実際、そのことが原因で多くのトラブルが発生してもいます。

そうした意味では、開発プロセスが具体的にイメージできる専門性が特に必要な領域と言えますし、私の経歴が生きていると思っています。

議事録やSlack上のやりとりの記録でも、身は守れる

新聞で報じられるような大きなシステム開発周りの事件から、個人レベルの事件まで、スケールの大小はさまざまですが、いつも法律的に問題になる最大のテーマは「結局、何を作るはずだったの？」ということ。受託案件においてよくあるトラブルです。

アジャイルと言うと聞こえはいいですが、先ほども触れたように、システム開発は「何を作るのか」に関して発注側・受注側とも極めて不明確なイメージしかないままにスタートするケースが多いです。開発が進み、だんだんと具体化されていくにつれて、お互いの認識の齟齬が明らかになり、トラブルに発展することになります。

私は弁護士に転身する以前、友人の経営する開発会社の技術責任者を務めていたことがあります。その時にも、クライアント企業から「要件通りのものが納品されない」と言われて、延々とタダ働きさせられるといったトラブルが発生していました。

伝統的なウォーターフォール型の発想で言えば、事前に要件定義をして固めておくという話になります。ですが、現実問題として、作り始める前段階できっちりと固めるのが難しいケースはありますよね。法人ではもちろん、個人事業主のエンジニアだとなおさらでしょう。

そういう場合、例えば議事録を取っているかどうかといった話が、後で重要になってきます。

個人の方とお話をしていると、「あらかじめ要件定義書を作ることなどできないし、契約書も作れない。そうであるがゆえに、万が一揉めたら、もうどうしようもない」と言う人がいます。

けれども本来は、契約書や要件定義書が明確に存在する状態としない状態という、二元的な発想をする必要はありません。この間にはアナログ的に、いろいろな段階があると思うのです。

例えば、要件定義として明確なものはないけれど、数週間に一回の頻度でミーティングをやっている。そこで決定された事項は必ず相手に送っていて、承諾があったとまではいかなくても、「ここは違う」というツッコミは特に受けていない、とか。

あるいは、Slack上で日々こんな会話をしている、コードをGitHub上に公開していて、それを定期的に確認してもらっている、といったことでも構いません。

そうしたさまざまなやりとりの記録の積み重ねが、万が一揉めてしまった場合に重要になってくる。「契約書や要件定義書をしっかり作ることができないんだから、もう仕方がない」というのは、必ずしもそうとは限らないということです。

もともとは個人で受託開発したり、SESとして働いていたりしたエンジニアが、キャリアのどこかでビジネスサイドへと乗り出すタイミングがありますよね。

例えば、それまでは個人として企業からシステム開発を請け負ってきたけれども、法人化して、対等な関係の共同事業に発展させたいと考えている、など。こうしたシチュエーションでも、トラブルは発生しやすいです。

そして、その多くは著作権に関するものです。

コードを書いて納品して、お金をもらい、著作権を譲渡した。その時点で、開発したエンジニアにプロダクトに関する権利は一切なくなってしまいます。その後、プロダクトが大成功を収めて、月に1000万円の利益を生み出したとしても、実入りは納品した際に受け取った「手間賃」と、せいぜい保守運用の月10万円だけ。「こんなはずじゃなかった」となるのは、よくある話です。

契約書のない状態は、エンジニアにとって不利

基本的に、コードに関する著作権は、書いた時点では書いたエンジニア本人にあります。ですが、明文化された譲渡の合意がなければその人に著作権があり続けるかと言えば、必ずしもそうとは言えません。

例えば、実際に私が弁護を担当したトラブルでこんな案件がありました。共同開発系の案件で、私のクライアントが設立間もないベンチャー企業、相手側が事業会社。「非常に安いお金をもらってコードを書いていたが、ソースコードに関する著作権を譲渡した覚えはない」というのがクライアントの社長の主張でした。

結局、この裁判は私たちが負けてしまいました。著作権譲渡に関する明確な契約書はたしかになかったのですが、毎月企業側から何らかの指示がきて、それに対してコードを書いて納品しているという関係性。かつ、プロダクトを第三者にライセンスアウトする契約が行われており、それをクライアント側の社長が知ってもいた。

こういった状況を踏まえると、契約書上で明確に示してはいなくても、著作権譲渡の合意はあったという判断になったのです。

つまりこういう話は、契約書がないことが基本的にはエンジニアにとっての不利になるんです。契約書で決められた通りになるというよりは、決まっていないから法律の原則通りになる。それを曲げたければ契約書が必要、ということですね。

エンジニアにとって一番大事な権利は、やはり著作権だと思います。基本姿勢として「何も決まっていない状態は自分にとって不利である」という発想で動いた方がいいでしょう。

そもそも難しい契約書以外無効ということはありません。自然言語で「著作権をください」だっていいんです。

全然アリです。むしろ、テンプレ通りの契約書はあまり役に立たないケースが多いです。

システム開発に関してインターネット上によくある契約書を見ると、「契約不適合責任は～」などと、法律の教科書通りのポイントはいろいろ決まっていますが、肝心の「何を作って」「いくらもらう」というところは「別途合意の上定める」としか書いていないことが多い。

それならもっと単純に、要件定義と金額が明示してあり、それにお互いがサインしているという方がはるかに実効性が高い。著作権に関しても同じで、「別途合意の上定める」と書いてある10ページの契約書より、A4のエクセルに「僕」、あるいは「あなたに」と書いてある方がよっぽど明確です。

著作権、ライセンスに関することは、会社員でも最低限知っておいた方がいいでしょう。特にオープンソースのライセンス周りは、個人でなんとなく使う場合とはアンテナの張り方を変える必要があります。

自分の判断で勝手にオープンソースを使って開発し、あとで作り直しを迫られたとなると、会社に大きな損害を与えることになる。最悪の場合は損害賠償にも発展し得ますから。

また、会社と個人の関係が永続的ではないことを踏まえると、会社との間の著作権についての考え方（自分が書いたコードの著作権がどちらにあるか）は、会社員の方も意識しておいた方がいい。具体的には、就業規則や退職時の覚書などとの付き合い方、ということになるかと思います。

19歳で稼げるIT経営者に。だが天才を前に転身を決意

大元までさかのぼれば、小学3年でプログラミングを始めた時、ということになるでしょう。父親に「ファミコンを買ってくれ」と頼んだら、「ファミコンはダメだが、パソコンなら」と言われて。買い与えられたパソコンでBASICをいじり始めたのが最初です。

当時のパソコン雑誌には読者が投稿したゲームのソースが載っていたので、何も分からずにそれを打ち込み、実行するとエラーが出るから「どこで打ち間違ったんだろう」というところから。

でも、所詮は素人の作ったゲームでバランスも悪いから、だんだんと自分で改造したくなるじゃないですか。シューティングゲームの残機を増やしたいし、当たり判定を小さくしたい。「マリオ」のジャンプ力も伸ばしたい。ということをやっていくうちに、なんとなく自分でも書けるようになっていました。

「ああ、マリオがあの動きをするのは、X軸とY軸にそれぞれ速度を持っていて、Y軸に関しては加速度を足すという発想があるんだ」などと、作る過程では、二次関数や微分積分といったその後の授業で習う内容を知らぬ間に実践していましたね。そのことに気付いたのは、だいぶ後になってからですが。

小学生のころはあらゆる意味で話は合わなかったですね。受験をして入った先（筑波大学附属駒場中学校・高等学校）がわりと自分に近い人間が多い学校だったので、そこでようやく孤独感から解消されたような感じです。

ちなみに、うちのパソコン部（通称、パ研）は優秀な人が多かったんですよ。自分の代の部長は現在、ウォンテッドリーのCTOを務める川崎禎紀。一つ下がPreferred Networks代表の西川徹です。賢くて変わった人ばかりいて、刺激的で楽しい学生生活でした。

ただ、部活に熱中し過ぎた結果、大学受験には失敗するんですけどね。当時の自分は「人間、大事なのは学歴ではなくて、ビジネスにおける戦闘力だ」みたいなことを言って粋がって、19歳の頃から早々に働き始めました。

最初に請け負ったのは、親の知り合いの病院のホームページを作る仕事でした。10万円もらったのですが、当時からすれば大金ですよ。その後は主にフリーランスでサーバサイドエンジニアとして働いて、なんやかんやで仕事が増えていき、おそらくは東大卒の新卒より、はるかに収入を確保できるようになっていました。

25、26歳になって、純粋にエンジニアリングだけ、経営者としてだけで殴り合おうと思うと、どうしても勝てない天才がいると思うようになったんです。

それこそ、コーディングという点では西川くんは天才だと思いますし、上の世代ですが、堀江貴文さんは在学中にライブドアを作っているわけで。

エンジニア、あるいは経営者のままだったら、どちらにしても、おそらくは日本で500人に一人くらいの存在にしかなれないだろう、と。でも、ITとビジネス、それにさらに勉強を掛け合わせれば、500の三乗で、おそらくは日本だとユニークな存在になれるのではないかと考えたんです。

ただ、二十代中盤以降から勉強して、それをサクッと仕事に使える分野というのは、実はあまりないんですよ。医者は卒業するのに単純に6年かかるし、受験数学を思い出すところからと考えれば、それ以上。その点、弁護士は3年でなれるし、大学院に入る時点では特に法律のことを聞かれない。だから入りやすいんです。

というのがリアルなストーリー。なので、正直に話すと弁護士を志したことにはあまりドラマ性がないんですよね……。

エンジニアと法律知識は本来、相性がいい

冒頭にも触れたように、法律はアルゴリズムなのでエンジニアにとって学びやすい分野のはずなんですよ。自分がすんなり転身できたのにも、間違いなくそういう側面があると思います。

結局、法律の勉強の何が難しいかと言えば、一つはロジックがややこしいこと、もう一つは言語が読みにくいこと。でも、いくら読みにくいと言っても、Pythonよりは日本語に近い。

アルゴリズムがややこしいと言っても、エンジニアは日頃からもっとややこしいアルゴリズムでものを書いているはずなので。

プログラミングに没頭するという意味ではないですが、新しいテクノロジーを理解するために技術に触れる、ということは今でもあります。むしろそこは、ITを専門とする弁護士をやる上で欠かせません。

というのも、ITで事業を興そうという人がわざわざわれわれのところに相談に来るということは、それがまだ世の中に出ていないものである可能性が高いわけです。

ですから私自身、例えばブロックチェーンなども、今のようにメディアに取り上げられるずっと前から触っていました。最近だと、日本の弁護士としてVTuber案件に最初に触ったのも私じゃないでしょうか。

そういう新しい概念やサービスを理解していくプロセスは、この仕事をやっていて楽しいところの一つです。

ITに関して、弁護士が提供できるサービスをいかに洗練させるか、です。

多くの人が弁護士に対して持つイメージは、「分からないことを相談したら教えてくれる」とか「契約書を書いてとお願いしたら書いてくれる」といったものではないでしょうか。

ですが、それらはIBM的に表現するなら「プロダクト」でしかない。それをどう「ソリューション」にするのかということに今、一番多くの時間と頭を使っています。

単純な製造業からソリューションビジネスへの移行。この時代にその視点が重要になるのは、おそらくはエンジニアも弁護士も一緒かもしれないですね。

取材・文／鈴木陸夫　撮影／赤松洋太　編集／河西ことみ（編集部）

書籍情報

本書では元ITエンジニアの弁護士がトピックを厳選し、Q&A形式で最低限押さえておくべきポイントを解説。

「著作権」「開発契約」「労働関係」そして「契約書のチェックポイント」、転ばぬ先の法律知識をコンパクトに一冊で知ることができます。

＞＞Amazon