エンジニアの情報漏洩リスクとブログエントリ

これを読んだのは昨日の朝で、タイトルを見たときからいつ消えるかと思っていたけど昨日の夜には削除されていたようだ。

でも、しっかりと魚拓されている。

みずほ銀行の炎上プロジェクトに支援に行ってきた話|問題編

お詫びエントリにも書かれているように大分批判の声があったようだ。プロファイルを読まずに固有名詞を出すようなエントリを書くなら個人事業主かな、と思ったらそれは間違いだった。SIerのエンジニアではないか。

そこそこのSIerならセキュリティ教育を行なっているだろうし、自分の感覚としては、顧客側でセキュリティ教育を行なっているはずなので業務に関わることは、事前に承認プロセスが通らないと公表できないものだ。

エンジニアがネットにプロジェクトのことを勝手に書いてはいけない理由をおさらいしておこう。

1つは技術情報の漏洩である。自社の技術情報に特許性があったとして、それが漏れてしまっては困る。だから、自社業務に掛かる情報はそうしたケースに触れていないか専門家若しくは責任者の承認プロセずがなされる。

2つ目は受託の場合、顧客の情報が漏洩してしまっては顧客との契約でペナルティを課せられてしまう。最悪、取引停止、違約金問題になりかねない。顧客の事例発表の場合、多くが顧客に事例を話させるのは、そこの調整を顧客に任せたいからである。

多くの組織では、こうした情報漏洩を起こすと就業規則に則り、懲戒処分になる。そこまでを考えて、何を話し、何を話さないかを決めておかなければならない。

もちろん、契約で（個人サイトというメディアの）媒体を使いコンテンツとして公表することを文書で合意していれば問題はない。

まあ、相手は法務の専門家が出てくるかもしれないが。

魚拓を改めて見ると、内容としては金融プロジェクトあるあるが書いてある。金融プロジェクトに携わるエンジニアの苦労話という見方もできる。そういうところはよかったのだ。でも解決策が提示されているわけではないが。

自分が書くとしたら、行名は色に、あと、赤い用紙もぼかすだろう。なんでもそうだが、そのままを書く必要はないのだ。特徴だけ伝わえればいいのだ。

そんなことを色々と考えて、配慮していると面倒になる。だから、プラクティスとして概念を伝えるようになってしまうか、全くシチュエーションを設定し直して創作することになる。

実はエンジニアがブログを書くことの最大の意味は、体験した経験知を言語や図式に概念化するプロセスを得る機会を自分で作れるということなのだ。さらに言えば、シチュエーションを再設定することまで手を出すと、ケーススタディを繰り返して体験できることまでできる。そこで考え直したときに、もっと最適化された（でも試行されていない）新しいパターンを想像できるのだ。

成功するシステム開発は裁判に学べ! ~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック