GitHubでの業務ソースコード流出 背景にIT業界の二極化と多重下請け構造
45歳のプログラマーの男が仕事で書いたコードを年収判定のためGitHubに上げて、複数企業の業務で使われていたコードの一部が流出した。GitHubは本来、公開して構わないオープンソース等のコードを共有する場で、年収判定サイトは、コミュニティでの活動を評価に結びつけようというコンセプトだった。しかし男は業務として開発した商業機密として保護すべき顧客のソースコードを不当に持ち出して、自分の年収を判定してもらうために丸ごと公開してしまった。
GAFAはじめネット企業を中心に、自社サービスを構成する部品で汎用的に使えるコードをGitHubなどを通じてオープンソースとして公開する動きが広がっている。一方で伝統的なシステム開発では、ソースコードは委託した業務の重要な成果物、秘匿すべき商業機密として組織内で管理することが一般的で、開発環境からはGitHubなどのサイトにアクセスできないよう遮断している場合が多い。転職市場に於いて書いたコードなどの成果物を直接確認する動きが広がる中で、何とか市場で評価されて自分の年収を上げようと、焦りと軽い気持ちから、持ち出した顧客のコードを公開してしまったようだ。
もう20年くらい前になるが、学生時代に1年ちょっと重層的な下請け構造の中に入って金融系のシステム案件に携わったことがある。手伝っていた会社をベンダーの下請けにパートナーとして紹介したところ、客がついたにも関わらず着手する前に会社が買収されて案件が宙に浮いてしまった。紹介した手前あまり迷惑をかけたくなかったし、ここはひとつ自分が責任を取るべきだと考えて、自分が設計レビューから入って代わりになる開発ベンダー探し、それでも足りないエンジニアやデザイナーに友達を誘ったり何でもやってプロジェクトを立て直した。そこでちょっと金融SEの真似事をやって、SESの方々のお世話にもなったし、下請けSEの悲哀らしきものを経験した。
当時つくっていたのは法人IBと連動してXMLで書かれた請求書を受け付けて、入出金予定をカレンダーに表示しIBから支払処理を行う、今風にいうとFinTechっぽくもある法人向けシステムだった。当時まだ過渡期でオープン系の品質管理プロセスは存在せず、問答無用でレガシー系の品質管理手法が適用された。
当時まだEJBは出たばかりでServletを生で書いていた。どう考えてもマルチスレッドのJava ServletにCOBOLやRPGのバッチに適用していた手法が通用する訳がない。「状態遷移のパスを全て埋めるんだ」って怒鳴られても「このServletの品質で最もヤバいのはthread safeじゃないコードが混ざる部分で、フロー制御の状態遷移を追おうにもメインループはコードの外側だし、コードカバレッジは全然上がらないぞ」と違和感を持って何度か具申もしたものの、ルールはルールだといわれてどうにもならないので、言われた通りひたすら謎のExcelをそれっぽく埋めていく仕事もやった。そのベンダーでオープン系向けの品質管理手法が確立したのは、その数年後のことらしい。JUnitやAOPは産声を上げていたが普及する前で、コードのあちこちでログを吐き出す手探りの原始的なprintfデバッグだった。
わたしは本来、上流工程でコードを書く必要はなかったはずが、どうやってXMLをパースしていいのか分からないとか、DBコネクションプールって何？みたいな初歩的なところで躓くプログラマーもいて、彼らが自走できるところまで、ちょくちょくサンプルコードを書いては渡していた。当時は雑誌を参考にしたが、今だったらQiitaやStackoverflowといった開発者向け掲示板で探したかも知れない。SOAPなんて素敵なものはまだ普及していなかったので、Himalaya上でCOBOL CGIで書かれた対向システムとの電文は全てHTTP固定長だった。テストのために対向のHimalayaの謎コンソールを開き、こんな訳分からんシステムもあるのかと驚いたものだ。
当時まだベンダーの金融SEはHTTPセッションと汎用機のチャネルの違いを理解しておらず、HTTPがステートレスに動いていることも理解していない方が仕様書を書いてたので、かなり手を入れる必要があった。縷々ご説明して仕様書をこっちで直しても、さっぱり理解してもらえない。それどころか怒られる。たまたま技術開発部門から事業部に異動したばかりで、休日フリーソフトを書くのが趣味で受賞歴もある課長補佐（いまになって振り返ると、とんでもない天の恵みではないか）が仲裁に入ってくれて、コイツのいってることはだいたい正しいから面子は捨てて話を聞きなさいと取りなしてくれたお陰で、だいぶ仕事が前に進むようになった。
この奇妙なデスマプロジェクトは、ちょっとしたボタンの掛け違いから唐突な終焉を迎えた。連日の無理が功を奏してサービスは無事カットオーバーし、顧客収容のテストを実施していた大学卒業直後の春、わたしは連日の無理が祟って風邪を引いて熱を出し、それでも仕事が心配で珍しく自宅から作業した。その日ちょうど利用者からのファイルの受付に使っていたFTPdに深刻な脆弱性が見付かり、まだ直ったバージョンがリリースされる前だったけれども基盤エンジニアが見つけてCVSのcurrent branchからpatchを拾って差し替え用のパッケージをつくってくれた。わたしは社長に連絡して緊急メンテを具申しようにも連絡が取れず、ベンダーと直接調整してゼロデイ対応の緊急保守を実施したのだが、これが社長の逆鱗に触れてしまった。自分を頭越しに元請けとPP差替するとは何事だ、金融システムの常識がないというのである。
今にして思えばゼロデイといってもインターネットに開いたポートはなく、IP-VPNでテスト中の顧客としか繋がっていなかったので、定期保守に組み込んでおけば十分だった。それまでには脆弱性修正済のバージョンがリリースされていただろう。そもそもリリース前のcurrent branchにあるpatchを本番系システムにテストもせずに組み込むのが正しいかというと微妙ではあった。ネット系のシステムをやっていた自分の常識を、金融系にそのまま当てはめてはいけなかった。とはいえこの件で信頼関係が壊れてしまってから横目で見ていたパワハラの標的となってしまい、こっちにしてみればハンズオンでプロジェクトをリカバリしたのに納得がいかず、リリースまで約束通りお手伝いさせえていただいたので今月いっぱいで引き上げさせていただきますといって私は撤退した。
そんなこんなで学生時代の金融SE生活からは1年近くで足抜けできたが、この件を機にソフトウェア産業とは何か、どうして重層的な下請け構造となっているのか、人の時間を人月で切り売りしていたら自己研鑽の時間を取れないではないか、元請けが技術を分かっていればだいぶ生産性が上がるはずなのに、どうしてここまで技術を知らずに指図できるんだろうか？と不思議に感じて考え続けるようになった。手を動かす下請けが技術を分かって提案しても、そう簡単には通らない。一方でプロジェクト管理ばかりに忙殺されて技術習得の機会がない元請けは技術習得の機会がない。現場で手を動かしている人間が、もっと勉強する余裕を与えられれば生産性を上げられるのに、人月商売で現場に張り付けられて自己研鑽の機会はない。これでは誰も得しない仕組みとなってしまっている。
技術なんてコロコロ変わるのだから、仕事を続ける限りは学び続ける必要がある。人月単位で切り売りして、ずっとフロントに立っていたら、どうやって成長すればいいんだろう？帰って自宅で触れる技術なんて限られている。成長のために勉強する時間は業務時間の中に組み込んで成長し続けられる仕組みにすべきだ。勉強が必要なのは、売れ残った束の間の休息だけでなく、先頭で手を動かしている人こそ新技術習得のレバレッジが大きいはずだ。ところが貰い手があるエンジニアは出涸らしになるまでインプットなしに働かされて、売れ残った人に何とか市場価値をつけようと四苦八苦するのでは、いつまでたっても生産性は上がらない。
仕事での新しいチャレンジを通じて成長する機会をつくるには、下のレベルに合わせて古くさい技術を使って、指揮命令権がどうとか、人月単価分みっちり働かせようとするよりも、不確実性を飲み込んで新しいことに取り組んで生産性を上げるべきだ。だが新しいやり方を試してみることは不確実で計画通りには行かないし、仮に上手くいったとて工数が大幅に削減されてしまうと仕事が減るし、失敗してやり直すことになれば大幅に工数が突き抜けて赤字になってしまう。
受発注関係の人月単価で契約する限り、古臭い技術に固執して、優秀なエンジニアが出涸らしになるまで現場に張り付けた方が、確実に計画を遂行して利益を上げられるのかも知れない。しかしこんなことを続けていたら、技術革新でどんどん生産性を上げていく米国や中国にボロ負けしてしまう。商慣行のためだけに古い技術に固執したままでは、成果は上がらないしプログラマーの給料も低いまま留め置かれて、IT投資のROIは低いままで市場は広がらない。結果として国そのものが負けてしまう、デジタル敗戦の背景には、こうした現状維持の圧力もあるのだろう。
重層的な下請け構造自体は日本社会で広く一般に見られることで、自動車をはじめとした製造業では上手く機能している。しかしながら製造業の下請けと、ソフトウェア産業との下請け構造で最も大きく違うのは、前者が部品などの製品のサプライチェーンであるのに対して、後者が人月単価で要員そのものを取引している点である。部品を売買している分には、生産性や品質向上の恩恵は下請け企業が受けることができて、生産性が高く歩留まりを上げた企業が生き残る。しかし労働力そのものを売買するソフトウェア産業の下請け構造では、生産性が上がるとその分だけ工数と売上は減ってしまうことから、生産性や品質を高める新技術に挑戦するよりも、生産性は低くても、計画通りに大量の要員を提供できる企業が生き残ることが考えられる。
わたしが金融SEを経験した20年前と今とでは開発標準もコンプライアンスも大きく変貌を遂げたが、根っこの問題は変わっていないように感じる。重層的な下請け構造、手を動かしていないが故に技術に詳しいとは限らないベンダー、仕事を通じて技術を習得したところで自己研鑽の余裕がない下請け。年収診断のためGitHubにコードを上げたプログラマー氏の給料は本人のツイートによると年収300万くらいだったらしい。業務で書いたコードを手元に置くだけでなく、そのままネットに公開してしまうくらいだから、決して優秀なプログラマーではなかったのかも知れない。
とはいえ20年近くも同じ業界で働いて、伴侶や家族を養えない給料しかもらえない社会をマトモといえるだろうか。経験20年でSE初級ということはないだろうから、件のプログラマーに対しても人月単価100万以上は支払われていたのではないか。重層的な下請け構造さえなければ販管費や社会保険料を差し引いたとして、もうちょっと真っ当な処遇を提供できたのではないか。ネットで自由にQiitaやStackoverflowの使える環境で、GitHub Enterpriseを使ってコード管理していれば、.gitignoreの使い方くらいちゃんと覚え、こんなポカミスで仕事を失う馬鹿はやらなかったはずだ。
今回の事件があろうがなかろうが、厳しい現場や官公庁をはじめとした多くの職場で、はQiitaもGitHubも掲示板やアップローダーとしてフィルタリングされている。今回の事件を受けて、もっと厳しくフィルタリングをかけるべきか、コードの持ち出しを統制するためにDLMを入れるなり、入退室管理に金属探知機を入れるべきかとか方々で議論が始まるのだろうか。しかし結局のところ、このような事件が起きた背景は重層的な下請け構造や、マトモに生活して所帯を持つことができない待遇、このご時世にGitひとつマトモに使えない環境にプログラマーを塩漬けしてきたツケに他ならない。
日本は1990年代以降、外圧を受けて金融自由化はじめ流動性を前提とする方向に社会を作り替えようとしてきた。しかしながら雇用に限って判例法理を上書きできない中途半端な状況が続き、就職氷河期世代をはじめとした後からやってきた若者たちに負担を皺寄せすることで他世代の雇用を維持してきた。コードを漏洩させたプログラマーの待遇は、自己責任と切り捨てられるものではなく、そうした社会的背景を理解する必要があるだろう。
現場で手を動かすエンジニア達を苦しめる重層的な下請け構造は、結局のところ雇用を維持しつつ発注者が業務の繁閑を調整できるように適応した結果である。しばしば問題とされるベンダーロックインにしても、ベンダーが背負う雇用維持の義務を考えたら当然の知恵だ。人間を軽視して表層的なコンプライアンスばかり重視した結果、人が育たず、機密保持をはじめとしたルールを守ろうという最低限のロイヤリティさえ維持できない職場環境をつくってしまった。顧客企業としてはちゃんとした人月単価を払っても、ひとりひとりの担い手の待遇まで具体的に知ることはできない。それが商慣行だといえばそれまでだが、今後もそんなことで大丈夫なのだろうか。
顧客からコードを勝手に持ち出して公開することが許されざることはいうまでもないが、技術の変遷をはじめとした時代の趨勢から目を背け、エンジニアを古い技術に塩漬けし続け、彼らの生活に無関心で居続けたならば、似たような問題は繰り返す虞がある。データ漏洩を統制する手法は諸々あるといっても実際の情報システムは複雑な上、システム開発のためにはOS上で強い権限を付与せざるを得ない場合もある。情報漏洩などの事故を防ぐ最後の砦は何よりも本人の意志と倫理観だ。まずは今の生活を失いたくないと感じられる待遇や、これまでの実績を商業機密を保護しつつポートフォリオとして求職に使える仕組み、技術習得や学んだ技術の適用といった成長の機会を提供することが、さらなる事故を防ぐ上で一丁目一番地となるのではないか。
この記事が気に入ったらサポートをしてみませんか？