話題のソースコード流出事件、報道にちょっと疑問

　筆者は普段、深圳の開発ボードスタートアップ界隈（かいわい）にいて、それに関連する記事を書いている。今回は日本の話だが、編集部からリクエストがあり、かつ筆者自身も書きたいと思った。著名な企業・組織のシステムのソースコードが、共同開発サービスのGitHubにアップされた件である。

　「Twitter」などでの情報を見る限り、かつて多重下請けでプログラムを書いていたエンジニアが、手元のソースをうっかり共同開発サービスのGitHub上に、誰でもソースを見ることができる設定で公開してしまったらしい。三井住友銀行など大企業のものとみられるソースが入っていたことや、アップした理由が「GitHub上のソースを見て年収判断してくれるサービスを使いたかった」「年収判断に至る発端が人気ゲームについてのいさかいだった」という間抜けなものだったこともあって話題になり、様々なメディアは見出しにGitHubやSMBCという単語が入った形で報じている。しかし、両社、特にGitHubはとばっちりもいいところだ。

　GitHubは共同開発を効率的に進めるために権限管理を含めた機能を提供しているサービスだ。もし、無知で生産性に対して理解していない上層部や発注元の指示などでGitHubへのアクセスを制限されるエンジニアが出てきたら、とばっちりの被害はさらに拡大する。そのようなばかげた判断は、未来のために社会全体から追放しなければならない。

　GitHubはソースコードをはじめ品質管理やバグ報告、改善提案などソフトウエアの開発プロセスを複数人で行うためのサービスだ。オープンソース・ソフトウエアのバージョン管理ツールGitをベースに、共同開発に便利な開発フローや権限管理、情報の共有や可視化、プロジェクトの管理機能などが統合されて、様々なソフトウエア開発で使われている。

　ソースコードを誰でも見ることができ、開発プロセスに誰でも参加できるオープンソース・ソフトウエアの開発ではGitHubを無料で利用することができる。非公開で大規模な共同開発を行うためのエンタープライズサービスも提供されている。規約やサービス案内にもそれは書いてあり、ほとんどの利用者はそれを理解している。だからこそ今回の件が話題になったと言える。

　例えば、日本の鉄道の駅や踏切には緊急停止ボタンが見えるところに設置されている。あれを誰かが誤って押してしまったときに、鉄道会社が責任を問われることはないだろうが、話題にはなるかもしれない。今回の事件はそれに少し似ている。

ソフトウエア業界の責任はどの程度か

　自分で考えて書いたソースコードはどこで公開しても勝手だが、依頼されて書いて納品したソースでは、ほとんどの場合、知的財産権は納品先にある。

　当たり前のことだが、発注元にとって受注先からソースコードが漏れることは大問題だ。筆者の現在の職務は国際事業開発だが、職歴で最も長く続いているのは受託開発業務で、前職も現職も受託開発を行っている。筆者が所属した企業では納品したら依頼されたソースはすべてを消すか、修正やアップデートのために保守契約を結んで保管していた。自分たちの効率的な開発のために社内で共有しているソースもあるが、納品時にその部分の知財まで渡さないように、契約を含めていつも気をつけている。

　一方で「保守契約は結ばないけど、何かあったときのために、ベストエフォートで残しておいてよ」といった話はゼロではない。それがちゃんと契約に反映されれば、断る話でもない。一緒に仕事をする相手は大事だし、お互い納得して契約を結んでいるなら、どんな関係でも構わない。

　ソースコードは物理的な「もの」を伴わない知的財産だ。そうした知的財産についての契約は、「どこにあって誰が持っているかが把握しやすい『もの』」に比べて理解しづらいし、適用が曖昧になるところもある。それでも多くのエンジニアがこういうことをある程度は理解しているから、今回のような件が出てくると逆説的に話題になる。今回のような問題は今後も出てくるかもしれないが、ソフトウエアの開発は、しっかりと管理をすればこういう問題が起きない方向に進化してきている。

　仕事全体の責任は何よりも発注側にあるので、今回の件で三井住友銀行などはGitHubとは異なって当事者であり、とばっちりとは言い切れないかもしれない。三井住友銀行と直接、仕事したことはないが、大企業なので受注側とはしっかりした契約を結んで十分なお金を払っているだろうし、履行についてもそれなりにチェックしているだろう。多重下請けの末端なら、発注元にできることはかなり限られてしまうが、後述するようにやれることはもっとあるはずだ。

原因はモラルを売ると金になる構造

　今回の件で一番青くなっているのは問題の案件を受託して実際に該当のコードを納品した企業だろう。当事者との契約関係があれば懲戒などの対策が取れるが、仮に現在、契約がないとすると、「たまたまひどい従業員がいました」という態度を見せることができず、その会社の仕事全体に疑念を持たれてしまう。

　こういうときによく取られる対応は開発者の私生活や開発手法を不当に制限する方法で、短絡的にGitHubの使用をやめさせるなどの馬鹿げた措置だ。ソフトウエアのライセンスをごまかしたり、知的財産やセキュリティーなどへの配慮や教育を下請けに押し付けたりするなど、モラルを売ると金になる構造はどこにもある。だが、従業員個人や立場の弱い下請けに責任を押し付けることでは、こうした構造を変えることはできない。

　ソフトウエア開発という商売は、「モラルを売らないほうが、もっとたくさんのお金を稼げる」と筆者は思っている。そして、こういうことはまさにGitHubのようなシステムをうまく使うことで解決できるはずだ。

　知財や契約の知識は自然に身に付くわけではないので、従業員への教育は行われるべきだ。筆者がこれまで所属した企業では、そうした教育を行ってくれたし、どういうサービスをどう使うべきかを教えてくれた。同僚や先輩方も色々教えてくれたのでとても感謝している。それは知財への知識だけでなく「売ってはダメなものを売ると、結局、得にならない」という精神も含まれる。

　GitHubはむしろライセンスにのっとった開発を安全で効率良く行うためのサービスだ。クローズドな開発にももちろん対応している。オープンでもクローズドでも、きちんと契約を結ぶことは可能だ。GitHubのように「どのような知財がどこで機能しているか」をシステム化しているサービスはたくさんある。知識があっても細かい決まりごとやしきたりをいちいち意識しながら守るのは面倒だが、システムによって面倒を解決している事例は数え切れない。

　今回のソースコード流出は、直接的には知財や契約について無頓着なままソースコードをアップしてしまった個人の問題だ。しかし、それは知財についての教育やシステム化を怠り、下請けや従業員に責任を押し付けてきた社会全体のモラルハザードの問題とも言える。

　ソフトウエア開発は人間らしく理性的に働くことのできる素晴らしい仕事だ。行動規範に「Don’t be Evil」を掲げた会社が世界最大のソフトウエア企業になったのは、偶然ではない。今回の件で、GitHubの有料サービスを使う会社がさらに増えることを期待している。