【2021JDSCアドベントカレンダー】法務とエンジニア

アドベントカレンダー日程表

こちら日程表になります。他記事にも飛べますのでぜひご覧くださいませ!
https://note.com/jdsc/n/nfc811d73c70c

はじめに

Tech Blogといえば、エンジニアが色々な技術のことや知識の小ネタを披露する場と知ってはいるのですが、今回社内の要請を受けて、法務からも書かせていただくことになりました。

 最初は「知的財産と知的財産権の違い」(下図みたいなもの)は興味を引いてもらえるかな、とか、

画像1

※引用:社内用勉強会資料「知的財産の基礎知識」より

「データの法的保護」(下図みたいなもの)などもAIの会社としていい感じかな、とか、

画像2

※引用:社内用勉強会資料「データの取扱いについて」より

法務相談や契約・捺印決裁のウェブ化を導入した経緯を書こうかな、とか考えていたんですが、そもそもいつも思ってる「エンジニアが開発を進める事と、契約を作成する仕事って似てると思う!だから、結構分かり合える(はず)!」を伝える場として、書かせていただくことにしました。このTechBlogを管理する人にも、「自分で決めて好きに書いていいですよ」って言われたし。

似てると思ったきっかけ
 IT系の法務として働き始めて15年ほど経ちますが、最初の頃に、あるエンジニアの人から「『どのような条件で、どのような結果を出すべきシステムを開発するのか』という点は、法務の人が契約書を作成するときの『どのような条件で、どのような結果を約束したい契約書を作成するのか』と一緒だよね。」と言われました。
 その時まで単純に、「法務=文系」「エンジニア=理系」くらいの雑な区分をしていたと思うんですが、(そうか、法務は法律を使って契約書を作成して、クライアントからの注文に応えていくけど、エンジニアはコードを利用して同じことをしているんだ。)と意識が変わったのを覚えています。

仕様書や提案書が欲しい
 エンジニアの方が開発を進める時に必要な(はずの)ものとして、リリースするサービスの満たすべき条件や内容を明確化のため、また、後から追加の業務が増加したり、または発注側としては必要な要素が含まれないことを共通で認識するための「仕様書」があると思います。
 私も契約書を作成する際に依頼してきた社内のスタッフに「仕様書ありませんか?まだなければ提案書見せてもらえませんか?」と質問します。

 前述の仕様書や提案書を手に入れたら、それを基に、主体、客体、行為、結果、因果関係の確認をしていきます。といっても、何かすごい情報を聞き出すのではなくて、平たくいうと以下みたいなことを聞いていきます。

・登場人物は誰ですか。
・構成(座組み)はどうなってますか。
・誰が何をするんですか。
・誰に何をしたいんですか。
・対象外なものはありますか。
・どうなりたいんですか。どうしたいんですか。

 上記で大枠を考えて、次に、その行為に違法性はないのかという点を考え、さらに責任や権利がどうなるのかを検討します。

 この辺も、エンジニアの方が開発を進める時に必要な情報を収集し、整理していって開発をしていく手順とそれほど変わらないんじゃないかな、と思っていて、これが整ってないと結構困るっていうのも変わらないんじゃないかと思っています。また、当事者間の関係性から踏まえて「どこまで折れるのか」「どこは引かずに押していくのか」といった(情状的な)考慮は最後の最後になります。情状面が最後の最後というところも、似ている気がしてるこの頃です。

そうはいっても違うところ
 JDSCでも上記の持論を展開した時に、エンジニアの方に言われたのが「でも、プログラムは間違えたら動かないけど、契約書は誤記しても通っちゃうところが違うよね。」と言われました。たしかに。そして「誤記」ではないですが、法律では「解釈」という曖昧な部分がある点も、プログラムを書く作業とは違うのかもしれません。また、法律も開発(技術)も、それぞれが適切に稼働するための専門用語が多数存在しているのは似ている点かと思いますが、逆に専門用語の多さが相互理解の壁になって、「なんか難しいことを言っている」ので「あっちとは相容れられない」となってしまうような気もしています。

とはいえ、一緒に良いサービスを作りたい
 エンジニアも、法務も、「より良いものをリリースして、喜んでもらいたい」という気持ちは一緒だと思います。また、法務としては、「いい感じで作成しておいてね。」と言われて進めてしまった結果、テキストで残ってしまった契約書のせいで、エンジニアの方が後で無理して回収していくようなことがないようにしたい、と強く思っています。

 ですので、データ収集に際しての個人情報保護法上の指摘などは、想像しやすいかもしれませんが、開発が終わってから、「ごめん、これ、法令に則してないから無理だった。作り直しして。」などということにならないよう、各プロジェクトがどのような体制で、どのように行われるのか、また、どのような仕組みを想定しているのか、という点をしつこく聞きいていまして、また、これまでの経験から「こんなネガティブ妄想が出てきちゃったんですけど、ここどうします?」というような検討をエンジニアの方や事業部の方としつつ、契約書を作成していっているところです。

 JDSCでは、法務を巻き込んで実現したい内容を進めていく体制が整っていて、たぶん法務を「近いもの」として認識してくださっていると思います。本当に全力でダメな時は、ダメな理由や代替案を提供しつつ「ダメ」と言いますけど、「うちの法務ってボトルネックなんだよねー」とか「法務がダメしか言わないんだよ…」みたいなことにならないように、日々業務にあたっています。
こんな法務がいるJDSCですが、よろしければ一緒に働いてみませんか?
===

この記事が気に入ったらサポートをしてみませんか?