イライラとアジャイルな組織を目指して

週次でミーティングを持っている。いわゆる進捗会議ではなく、プロジェクトの付帯的な活動やその他の活動の状況を聞く。ああ、活動状況を聞いているのだから進捗会議と同じではないか。ただ、違うのはマネージャからの周知のようなものは極力しない。そういったものはchatツールで済ませてしまう。そのほうがログが残るのでメンバが忘れていても遡れて良い。何より、メンバを集めて1時間使うなら、メンバが使った方が良い。

ある回で、シニアのエンジニアが今日は2件話したいと言った。ちょっと言い方がいつもと違うな、と感じた。自分の意見を持っているし実力もあるエンジニアだが、周りに合わせる柔軟性も持っている。そのエンジニアが、である。

実は、その回の前日にそのエンジニアが他組織と某案件で場を持つことを知っていた。更に言えば、前日にその他組織の担当と会話をしていて、担当が案件をどう考えているかを知っていた。まあ、人が悪いという人もいるかもしれないが、マネージャとは清濁を合わせ飲む混んでおくものであるし、情報源を捕まえておくのが仕事だ。

話を戻して、普段とは違った印象を持ったエンジニアは冒頭からイライラとしている様子が伺える。もともと、話のファシリティはもう少し技術を身につけると更に良くなると思っているが、それはまた別の話だ。それでイラつているから話を始めると2つあったどっちの話から始めようとするのか分別せずに話し始めるので、どちらから話すのか、どんな内容なのかと問いかけるとイライラは更に募るのがわかる。

1件は某案件の進捗、2件めは他組織との新たな仕組みを作りたいという。

1件目の進捗なら（任せているので）いらないというと、イライラに不機嫌を重ねる。これは何かあると思って少し聞いてみると、様々な制約条件や前提条件の中で厳しいスケジュールでやっているので無茶な段取りで進めざるを得ないと。

どうしてそうなったかを聞くと準備期間に別のタスクを振っていたのがだだかぶりしていたからだとイライラ度も最高潮を迎えた。

プロジェクトや活動にはゴール設定が必要だ。それに向かって仕事をするからだ。でも、限られたリソースでできることとできないことがある。それと、自分が考えられる段取りの組み方や進め方は過去の成功体験の焼き直しでしかない。それを知っていれば、行き詰まったとき、周りのメンバとブレストをするのが打開策となることが多い。

ブレストでなくても、コーヒーでも飲みながら雑談しながら話すだけでキーワードを拾えることが少なくない。つまり、一人で悶々とイライラしながら自家発電するより、周りを巻き込んでしまう方が生産的なのだ。たとえ仕事を分担しているとしても、そのためにチームがある。

あるものはなんでも使う。

確かにエンジニアは難しい活動を担当している。だからこそ、周りのリソースを少しずつ借りて進めた方が良いのだ。それは中堅や若手のエンジニアに難しい活動をするときのリニアでリアルな仕事のやり方を教えることになるのだから。

その回は終わる時間の5分前に他のメンバに出てもらい、1on1の形で諭すように話しかける。イライラしている原因に自分（そのエンジニア自身）も含まれていること、それを踏まえた上で、自分の感情と切り離してことを見ないと視覚が狭くなり、イライラするループに陥ってしまうこと。

多分、届かないのだろうけれど、それを伝えるのもマネージャの仕事である。

DIAMONDハーバード･ビジネス･レビュー 2018年07月号 ［雑誌］

調達 誰からも「気がきく」と言われる45の習慣

誰からも「気がきく」と言われる45の習慣

育成への期待は半分で気長に

中堅になりたてのエンジニアがまとめた資料を見る機会があった。レビューというようなものではなく「できた資料を確認してください」程度のもの。できれば、そんなこともしないで次工程に回してしまいたいが、どうも気がかりなことがあったので時間をとることに。

気がかりなこととは、同じように作成してもらった資料を見て、アレコレと聞いてみたら資料上での判断が曖昧だったり、裏付けがなかったことがあった。資料の性格上、それは拙い。いや、エンジニアが手掛ける成果に曖昧さがあってはいけないだろう、と思った。

その資料を作成する際に、ごく稀に国内のエンジニアだと知らないだろうという情報が紛れ込んでいる場合がある。今は便利な時代でインターネットがあるから国外のことでも（ネットにアップされていれば）どうにかこうにかたどり着くことができる。

言い換えれば、製品のホワイトペーパーのappendixを探し続けるようなものだ。そこまで到達しなければ、まとめた資料の信憑性はなくなってしまう。エンジニアとしてそこまで調べ、裏付けを取らなければならない。もし、そこをわからないままで資料を作ってしまうと、その報告を受けた人は裏付けがあやふやな資料の情報を鵜呑みにしてしまう。将来、鵜呑みにしてしまったことがトラブルを引き起こしかねないとは言い切れない。だから、資料を見たのだが。

「資料のN番目の調査結果は」
「これこれです」
「そう、それ。えっと、この点は調べた」
「そこまで調べてません」
「そーか。でも、この点まで調べないと根拠にならないよ」
「…」
「調べた方がいいんじゃなかな」
「はい」
「こっちのこれは」
「初めて見たものがありました」

「へー、なに。うーん、それ何」
「よくわかりません」
「それでその評価なんだ」
「…」
「こっちのこれの資料の調査は実はわかりません、とは言えないじゃん。もう少し調べないとさ」
「調べたんですがそれが見当たらなくて」

「そーか、でも調べて調査した根拠はとっておかないと」
「…」
「調査が曖昧なままで結果を渡してしまったら、その調査をもらった人は間違って判断してしまうからね。根拠を持っておこうね。それでも間違っていたら訂正すればいいからさ。でも、曖昧なままで渡してしまうとあとで説明に困るからさ」

これをきっかけにこの仕事の観点を覚えてくれればいい経験になると思うのだが。まあ、育成への期待は半分で気長に。

蚊がいなくなるスプレー 蚊取り 12時間持続 200日分 無香料 (防除用医薬部外品)

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

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

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

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

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