三井住友銀行やNECといった大手企業のシステムのソースコードが流出していたことが判明し、大きな話題となっています。なぜこのような事態が発生してしまったのでしょうか。今回のメルマガ『冷泉彰彦のプリンストン通信』では著者で米国在住作家の冷泉彰彦さんが、今回のケースは、日本のソフトウェア業界が抱える構造的な問題が顕在化したものであると指摘。さらに同業界がそのような体制となってしまった根本的原因を考察しています。
ソースコード流出と日本のソフトウェア業界の闇
問題が明るみに出たのは、三井住友銀行（SMBC）が1月29日に行った発表です。同行によれば、同行のバンキング・システムに関連するソースコードが「外部のWebサイト上」に勝手に公開されていたというのでした。そのサイトとは「GitHub」（ギットハブ）というプラットフォームです。
ちなみに、その後に判明したところでは、SMBCだけでなく、NTTデータ・ジェトロニクス（昔の日本オリベッティ）、NECなどのデータも流出が確認されていました。
この「GitHub」というのは、基本的にはプロ用の有償サービスで、ソフトウェアを開発する際に、メンバーがコードを共有しながらバージョン管理、つまり「これが最新バージョン」だが「その前のものはこれ」といったマネジメントをしながらプロジェクトを作り上げて行くツールです。
当然ですが、この有償サービスは非公開ですし、反対に強力なセキュリティに守られています。
ちなみに、この「GitHub」はサンフランシスコをベースとしたベンチャーで2008年にスタートしていますが、2018年にはMS（マイクロソフト）の傘下になっています。
これはMSがビジネスチャンスを感じて買ったというのではなく、そもそもMSが同社のヘビーユーザーであったことから取り込んだもののようです。
ということで、「GitHub」というのは怪しいサイトでもなんでもない、と言いますか、むしろ世界的に必要とされるビジネスインフラであるわけですが、問題は、無料のサービスとして「ペーストビン」的なことをやっている点で、今回の事件では、ここが舞台になりました。
どういうことかというのは、「ペーストビン」（一般名詞です）というのは、プログラマが構想やソースコードの断片などを「プレーンなテキスト」として一般公開することができるからです。
これもお断りしておきますが、悪いことではありません。原因不明のエラーやループが出た時に、ネット民の知恵を求めるということはあるからです。
勿論、個人情報やセキュリティに脆弱性を招くようなデータの公開は違法ですが、そうでなければ普及している行為というわけです。
この「ペーストビン」的な使い方として「ソフトウェア人材のスキル」を見るために、その人の書いたソースコードをアップさせるということがあります。つまり採用選考の段階で、自分の「作品」をそこにアップして見せるという使い方です。
ネットの世界には「ペーストビン」的なサービスは色々あるわけですが、例えば企業の採用担当者としては、あまり怪しいサイトにアクセスするのは抵抗があるわけで、MS傘下の「GitHub」なら安心なので、そこにアップしてくれという運用になることが多いようです。
要するに自分のエンジニアのスキルをアピールするには、そこに自分がプライベートで書いたコードをアップして、その「作品」を評価してもらうということになるわけですが、今回の事件はそうではなくて、エンジニアが業務で書いたもの、しかもその本物をアップしてしまったということのようです。
そのエンジニアらしき人物が、「さぶれ」というハンドリングネーム（現在は削除）でツイートしていた内容（魚拓を参照）によれば、訳も分からずに「現在あるコードをチェックせずに全てアップした」ということのようです。
同じ書き込みによれば「なんかgitにコードをアップすると、それから推定年収を計算してくれるサイトがありまして」ということですから、自分のコーディングのスキルをチェックしてもらって転職のストラテジの参考にしようとした、そんな理解がされています。
この問題ですが、単に悪意のある人物が機密情報を漏洩したというような単純な事件ではないと考えるべきです。そうではなくて、今回のケースは次のような問題を提起していると考えられます。
1つ目は、経済的な視点です。一部の情報によればこの漏洩したエンジニアの処遇は「40代、勤続20年で年収は300万」だったそうです。
仮にそうであれば、モラルとモチベーションを期待するのは難しいと言えます。それどころか、今回のケースとしては「モラルが低く、低年収ということで恨みを抱いて悪意で漏洩した」のではなく、「恐らく、本物のソースコードをアップすることの違法性、危険性などのリテラシーに欠けていた」という可能性すら匂わせています。悪意がないから「まだまし」ではなく、事態はもっと深刻ということです。
ということは、日本を代表するようなメガバンクや、テック企業においても、システム開発は外注し、またその外注先が孫請けに投げて、もしかしたら更にひ孫ぐらいのところに投げた結果、非常に年収の低い、従って倫理リテラシーも、業界のフレームワークも何もまるで分からずにプログラムだけを書いているようなエンジニアに仕事をさせている、そんな構造があるということです。
そのように、中間に様々な組織が絡んでおり、それぞれの組織が間接部門を含む人を養って行かねばならない中では、そのレベルのエンジニアを雇うぐらいの予算しか残らない、そのようなコスト構造があるということです。
これは大変に危険なことです。もう一度、繰り返しますが、悪意をもって発注元にダメージを与えようというのではなく、「公開することがどんなインパクトを与えるのか、全く分かっていない」レベルというのは、究極のリスクだということです。
つまり、コスト構造に誤りがあることで、業務体制の全体が高リスクになっているということです。
2つ目は、今度はこのエンジニアの視点に立ってみることにします。20年間勤続してきたというのですから、恐らくコーディングが苦手ではないのでしょう。そして経験を重ねることで組織の中での信用もあったのだと思います。
それでも、セキュリティに関するリテラシーを獲得できなかったとすれば、そのような学習をするチャンスがなかった、あるいは多少はあったがちゃんとしたリテラシーがなくても作業は回せるような環境でずっとやらされてきたという可能性があります。
仮の話ですが、作業の中で「オリジナルの発注先を知らされずに」いたとか、「システムの全体像も知らされず」にサブシステムの継ぎ足しなどをやっていただけという可能性もあるかもしれません。
また作業については、ちゃんと専用環境の中でしか作業は出来ないとか、しっかりログを取られてセキュリティが破られそうな挙動があればワーニングやエラーになる、ましてソースコードを持ち出すことはできないといった、当然に取られているべき体制が取られていなかったということもあると思います。
この点に関しては1つ目の問題と同じであり、末端のソフトハウスのレベルでは、そんな「まともなセキュリティの管理」ができるような値段で仕事を受けていないということだったのかもしれません。
仮にそうだとすると、人材とか組織といった観点から考えた場合に、この漏洩を起こした人物や、その人物が直接的に属していた企業については、責められないものを感じます。
では、一体どうしてこうした体制になってしまったのでしょうか？
これは、一部の問題ではなく、日本のテック業界全体の問題と言えます。そして、問題点を要約すると非常に簡単な一つの問題にたどり着くのです。それは、
「コンピュータ・ソフトウェアの技術者は、専門的に過ぎるので、まず管理職候補にはしない。従って大企業の年功序列の人事制度には入れない。そして、コンピュータ・ソフトウェアの技術についても専門的過ぎるので、一般の管理職が直接管理監督することはしたくないし、できない」
という恐るべき考え方を前提として、
「コンピュータ・ソフトウェアの開発実務は、大企業の中では行わないし、従って、コンピュータ・ソフトウェアのエンジニアは、中小の外部組織に分離する」
ということを行ってきたからです。そのためソフトウェア開発のエンジニアは、プログラマーという呼称とともに、社会的地位も給与水準も低いままに留め置かれました。
というよりも、バブル崩壊とかデフレ経済という名前で呼ばれる「日本企業の国際競争力喪失」に伴って、そのコストは徹底的に叩かれてきたのです。
その結果として、ソフトウェア開発のエンジニアというのは、降りてきた仕様を元に、受け身の作業に終始するということの繰り返しとなり、また劣化した要件定義、そしてユーザーの無知による横暴によって発生する不完全な要件定義と、その朝令暮改的な変更に翻弄されつつ、価格決定権もないままに劣悪な環境に追いやられるということが進みました。
そうして、仕事の質、価格、人材の全体が負のスパイラルに入って行ったのです。今回の事件は、恐らくは1978年前後に始まるこうした長いマイナスの歴史の延長に起きたと言えます。（メルマガ『冷泉彰彦のプリンストン通信』より一部抜粋）
image by: Shutterstock.com