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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

調達 スパイス

神戸スパイス カレーリーフ 100g Curry Leaf カリーパッタ Patta スパイス 香辛料 業務用

神戸スパイス コリアンダーパウダー 500g Coriander Powder コリアンダー 粉末 スパイス 香辛料 業務用

調達 excel

Excel 最強の教科書[完全版]――すぐに使えて、一生役立つ「成果を生み出す」超エクセル仕事術

たった1日で即戦力になるExcelの教科書

たった1秒で仕事が片づく Excel自動化の教科書

エンジニアの流動性の高まりとオファー

近頃お会いする方々から採用意欲が以前より高いと感じている。どこかしこもwe are hiring!なう、である。某社においては採用は全方位で、と言い切る創業者も少なくない。

採用意欲は年収にも現れている。某社では4桁は出すとか、4桁には満たないが稼働日が少ないとか条件は様々だ。

付き合いのあったり、面識のあるエンジニアの方も、理由は様々だが市場価値を自ら確かめに出向いたり、条件が合えば新しい職場に移る決断をしているケースが目立ってきた。

もちろん、採用する側としての期待する貢献と応募するエンジニア側が決断する諸条件が折り合えば、エンジニアの流動が決まるわけだ。

もともと、どちらかと言えばいきなり外の組織に移ることを考える前に、まずは組織の中で担当する事業を移ることを考えた方がいいと思っている派である。なぜなら、組織をまたがる異動で（場合によっては）技術転換や求められるロールが変わることに対する自身の環境への適用性を知っておいた方が良いだろうと思いからだ。

組織内であれば、何より待遇が変わることがないので保険としては一番リーズナブルだ。現実逃避的に移転先を探すことは、その活動に掛かる先行コストがエンジニアの思考を拘束しがちだ。ここまで時間を使っていてと思ってしまうと、移りたい理由の本質を棚上げして条件面でエンジニア側から交渉のテーブルを降りてしまう。

これでは後から見れば単に属する組織が変わっただけになってしまうし、最悪は年収も下がってしまう。

そういう意味合いで属する組織を変えるなら、評価基準や条件を持って臨まないと失敗してしまう。失敗をしないためというよりは、情報を集めたり勉強する意味合いで、エンジニアは最初は組織を移るつもりはないと明言し、市場価値を評価してもらうのも一つのやり方だと思う。何より、自己の経歴を振り返りできるし、アピールの仕方も覚えられる。

自分のキャリアをサンプルとすると、プロジェクトマネージャ、マネージャ、事業推進、組織構築、エンジニア育成などが挙げられる。

さて、こんなエンジニアだったらオファーあるのだろうか。

Fire TV Stick

ロジカルに伝えることとストーリーを持って伝えること

今では、もう10年も前のことになってしまうが、某部署に異動していくつかのプロマネをした後がどれも技術的に未経験のソリューションで、若干の助走期間があったがプロジェクトが始まってしまえば助走期間でやったことは大して役に立たなかった。

そうしたソリューションの中で、あるエンジニアが考えた手法があった。ただ、その手法は机上でしかなく、考えた本人も実践でその手法が機能するかどうかは確かめたことがなかった。

一般的なシステム開発手法であるウォーターフォールでの局面間の割り当てから言えば、データ設計などが上流により過ぎている感を覚えるような構成なのだが、これは適用するパッケージの導入と構成の制約も考慮した上での仕立てになってた。

顧客から見れば、システム要件を話す時点で、どうしてデータ項目まで言及するのか戸惑うかもしれなかったが、それはそれで後工程が楽になるのとより早い段階から顧客が当事者意識を持つように作用するため、割といいシナリオだった。

脱線するが、なぜデータ項目を早く始めると顧客の当事者意識が高まるか、その理由を考えてみると良いと思う。

話を戻して。

その手法を考えたエンジニアの拘りが、仕様を確定した後の「ドキュメントを読み物として書く」というのがあって正直、それどうなんだと思っていたし、今でもどうかな、と思う。理由は、ドキュメントは仕様を書くもので機能的である、つまり、ロジカルに書かれて入ればよく、読み物として書かれると全部読まないとわからいということだ。

ドキュメントの観点で言えば、ドキュメントはロジカルに書かれて入れば良い。ドキュメントで扱うユニバース（書くことと書かないことの界面）の定義、ユニバースの中の機能分解と仕様。取り扱う数値が記載されていれば良いのだ。

ただ、そのユニバースに到達するための経緯は後のテストで紐解き直す必要が出てくればリファレンスが必要となるが、それは仕様検討の資料に繋がるので問題はない。

ここのドキュメントを作る目的から言えば上述のとおりでそれで十分である。これではドキュメントが刊行されないとプロジェクト全体を把握しきれない。そのために必要となるのがストーリーを持って伝えるということになる。

システム開発でストーリーを持って伝えれば良いのは、プロジェクト全体のフローである。局面の繋ぎ方、登場人物が出てくるタイミング。キャスティングの台本としてプロジェクト全体をストーリーを持って伝えなければ、ステークホルダーやサードパーティは動いてくれない。それはチームメンバも同じである。

どちらも関わる人が読み、行動するために作成するのは同じであるが、幾重にもストーリー仕立てになっていると、ゼロイチの実装に近いドキュメントは使い勝手が悪くなってしまう。

そうした考え方から言えば、あるエンジニアの拘りは後の運用維持でそのドキュメントを読むことになる担当者の立場では迷惑でしかないし、拘った部分は履き違えていたのだ。

そのソリューションで設計書をどうしたかと言えば、上述どおり機能をロジカルに書いたし、ストーリーを持ってプロジェクトを進行したのであった。

世界一やさしい問題解決の授業―自分で考え、行動する力が身につく

世界一やさしい右脳型問題解決の授業

自分の答えのつくりかた―INDEPENDENT MIND

エンジニアとして大事なことは○○から学んだ

某社の役員と話をしてたら、何となくキャリアの話まで及んで、さらに立ち上げた事業の経緯を赤裸々に聞くことになった。それがまた面白くて自然と前のめりになるような引き込まれ方になっているのに気づいた自分に何か大事なことを聞いているのではないかと問い掛けをしようと思いかけたが、それではその何か大事な話の続きを失ってしまいそうで脇に起きつつ話を続けた。

氏曰く、

「人生で大事なことは○○から学んだ」

のだそうだ。○○と伏せているのは、まあ、大人の事情だということで。

そういったことを思い出して、さて自分はエンジニアとして、何から大事なことを学んだのだろうと問いかけをしてみたが○○を埋められる言葉がさっと出てこない。

何だろうなと思案しつつ、まあ、プロジェクトマネジメントだよな、と。苦笑しつつもエンジニアの専門として選んだ仕事、職種なのだから当然すぎて面白くない。

○○に当たるところは、活動する目的やテーマが当てはまるだろう。だから、自分の場合はプロジェクトマネジメントが当てはまるのだ。

○○を実現するために様々なエンジニアや顧客と関わることになる。関わるということは場を作り、その場に集まってもらって、スポンサーが実現したいことをその場で構築する。構築を介してリレーションが複雑性を増し、深くなっていく。

その場が顧客のやりたいことを実現する場であるということは、その場が顧客を変えていくということではないか。

ここまで思い至った先で辿り着いたのは、顧客を変えていくことをしているのに、自分自身はそのまま変わらないでいられるか、ということだ。

もし、顧客が変わろうとしているのに自分が影響を一方的に与え続けていられるのか。それは間合いを広くとって、実は変わることを避けているのではないかと思うのだ。

顧客が変わろうとしている。その場を（プロジェクトとして）作りながら、自分も変わる。

だから、困難なことが次々と起こったとしても、逃げずにやってこれたのではないか。

もちろん、それは一人でではなく、その場に集まった人がいたから、だが。

そうした場で耳にする言葉が自分を変えてきたのだろう。その意味でも、エンジニアとして大事なことは○○から学んでいるのだろう。

現場にいる限りは。

新・人生に必要な知恵はすべて幼稚園の砂場で学んだ

抜け出そう！デスマあるある

前にも書いたことがあるような気がする（いつも思いつくまま書いているので何を書いたか覚えていない）が、デスマは身体を壊さない程度で自分の閾値をテストする意味でしか経験する意味合いはない。もちろん、デスマなのに超過労働分の手当が支給されないのなら、経営者でもなければやる意味はない。労働者は労働力と引き換えに対価を得ているのだから。

それはさておき、こんなシチュエーションを体感していたら即刻避難した方が良い。

• はっきりしないスコープ
• ロジックのない価格設定
• 提案に意思がない
• 総花的な機能
• 営業の出来るよね

はっきりしないスコープとは、顧客もプロジェクトの目的、目標を伝えられない状態で、提案サイドも提案スコープを決められないことを指している。リミットとなる界面か基準がなければスコープはクリープするだけである。ましてや提案サイドが提案時にスコープのクリーピングにキャップを掛ける意識がないならクリープすること間違いなし、である。

ロジックのない価格設定とは、言い換えれば見積もり根拠を持っているか、である。面白いのが、たとえ工数提供であっても、提供時間を厳密にコントロールして超過したら無慈悲に請求するか（もちろん減額請求には応じない）、業務量の調整で提供時間を超えさせないとデスマにならない。見積もり根拠を持っていないと、価格調整があった場合の条件闘争で交渉できないと思った方が良い。最初の価格と規模から減額した場合の価格に見合うスコープが導き出せないからだ。

提案に意思がないとは、御用聞き営業でなんでもやりますというアレだ。工数提供であればそれも選択肢であるが、そういった提案には業務課題の解決方法や改善を提案されることはない。なぜなら、エンジニアも指示されたように実現をすることに訓練されているからだ。

総花的な機能とは、実現したい業務課題のITによる解決策の提供ではなく、あれこれと使わない機能まで含めて提案していることを指す。使われない機能を作ることにエンジニアが萌えるかといえばそれはない。

営業の出来るよね、は営業が提案する技術、ソリューションを理解していないということだ。つまり、こじれた時に全く頼りにならないのだ。開発責任者が仕切れれば、というケースもあるかもしれないが、仕切れるくらいなら、営業がエンジニアにつけを回すような発言はさせないだろう。そういうことだ。

あなたのプロジェクトにはいくつあるか。

熊とワルツを - リスクを愉しむプロジェクト管理