エンジニアが確実に成果を出す技術

チームのエンジニアは多忙である。もちろん、自分も同じ。放っておくとタスクは積み上がる。何も炎上プロジェクトにいるわけではない。

とは言え、自分もアーキテクトもそれぞれ主管のタスクやプロジェクトで結果をコツコツと出している。1人だけあっぷあっぷのエンジニアがいる。

側から見れば、放置しておくと疲弊しそうだし、とは言え、主体的＝裁量でやりたいという希望も持っているので、さてどうするか。

視点を変えれば、あっぷあっぷしなければいい。結果を出せればバックログは減るのであっぷあっぷから足のつま先がつんつんできるくらいになるはずだ。

イニシエーション（成果を出すための最初の儀式）

このエンジニアもそうだが、バックログのタスクを全部やらないといけないという観念から自分を解放しなければならない。これは慣れないととても抵抗感のある行為だ。

それでもやはり、成果を出すためにはこの儀式を執り行わなければならない。

はい、ご唱和。

• 全部やらない
• 全部やれなくても、その結果でも受け入れる
• 出来るものしか出来ない

つまり、自分のリソースは1つで、やれるものしかやれないのだから、諦めろ、欲張るな、ということである。

優先順位をつける（成果を出す対象を決める）

次に終わらせる順番をタスクにつける。順番をつける意思決定をする。同じ順位があってはいけない。順番を付け替えるのは1つ終わったあとだけ。途中でやってはいけない。

• 一番から順につける
• 一番目は差込が入っても劣後させる
• 一番目を終わらせる

時間を見積もる（自分への期待値が高いことにgkbrする）

作業時間を見積もってみる。見積もるためには何が必要か。やろうとしていたタスクの中身を知らないことに気づくのは、そのタスクにやっと手をつけてからわかることだ。

何度もそれは経験してきていることなのに毎回するのはなぜか。

• タスクの成果物を部品に分解する
• 部品を作る情報を洗い出す（調べる）
• 部品を作る工数を経験則から見積もる
• 理想時間（そのタスクだけやったら）を積算する
• カレンダに当てはめる。
• スケジュールをブロックする

遮断する（リソースを集中する）

一番目のタスクをやっているときには、メール、slack、その他のコミュケーションツールを遮断する。どれかに気になって眺め始めると時間を溶かすだけだ。

放っておけ。必要があれば先方から訪ねてくる。

終わらせる（一番目のタスクを）

とにかく終わらせる。話はそれからだ。

洗い出した通りの作業で出来たか。出来なければ作業分解の能力がない。現実をうけいれよ。

見積もった工数で終わったか。終わらないのは自分の能力を高く見ているからだ。現実を直視せよ。

理想時間を当てはめたスケジュールで完了したか。出来ないのは日常の非生産的な時間があることをわかっていないからだ。稼働時間8時間は残業時間を含めて、ではないか。

振り返る

成果が目の前にある。終わっている。今までのやり方では何も終わっていない。これは断言できる。

これで良いのである。

娘の友達(2) (モーニング KC)

娘の友達(1) (モーニング KC)

1人情報システム担当には感謝を

経験から言えば、100人くらいの組織だと情報システムを担当する人は1名いればいい方で、総務や経理担当が兼務をしていたり、たまたまPCに詳しいとかPCが好きな営業部長が兼務していたりする例もある。

感覚的には100名あたり1名の専任の情報システム担当の感覚である。実際、100名も社員がいると1日に数件はPCのトラブルで相談がくる。

『何もしていないのに』

• 複合機で印刷できない
• ネットが繋がらない
• パスワードをロックした

と相談が来る。Windwos  updateでOS側がやらかすこともままあり、一概には言えないが、とにかくトラブる。

 情報システムの環境も組織の規模、大企業、中小企業、零細企業と色々と企業のサイズは違えど、PCと複合機とネットはないと仕事にならない。建設会社なら設計図面があるのでPCは必須だ。

なぜなら図面のデータが大きいのでUSBメモリでデータをやりとする現場があるからだ。発注元が大手で情報セキュリティに気を使っていれば、クラウド上でやり取りすることもあるだろうが、下請けに行けばUSBメモリで渡される。会社ごとにフォルダをつくり、そこに保存してあればましで、メールの受信ホルダのままだってあるかもしれない。

組織の規模が小さければ情報システムの使い方を教育することはないだろうし（ツールの使い方を教えるくらい）、ましてや情報セキュリティに金を払って何かをするなんて経営者にとって動機がない。

ウイルス対策ソフトをいれておくくらいだ。

www.sankei.com

元勤務先のパソコン内のデータを全て消去したとして、

少なくとも自宅か外からインターネット経由で会社のネットワークに入り、『PC』に接続してデータを削除したと読める。

組織をやっていくには引っ張るリーダーシップ（ワンマン）なところが必要で、そうでもしなければ食べさせていけないという使命感を勝手に持っているから、お金を産まない業務は劣後する。

資金繰りや経理は必然だからまだましだが、OAはそれこそインフラレベルの話でトラブると文句しか言われない。

少しでも便利にしようとしても如何せん経営者にインセンティブがないからIT投資なんて次元が違う話だ。系列の孫会社くらいだと一番上の会社から監査がやってきて、あれこれとワザと指摘をさせ、親会社がいうからという物言いで予算を無理やり確保する荒技もあるくらいだ。

そういったこともなけれ単なる金食い虫にしか見えない経営者がいても不思議ではない。ただ、人を置くということは、そこに業務があるということであり、組織にとってないがしろにできるものではない。

それでもそこにリソースを割きたくないのであれば、BPOをするのが経営者の事業継続のリスクマネジメントではないか。

それさえも出せないかもしれないが。報酬で報えないのであれば、日頃から感謝を伝え、大事に接しないと。

ひとり情シス

評価で真意を伝えるために

プロジェクトマネージャやマネージャをやっていると楽しいことばかりではなくて、結果的に判断を間違えてズルズルと現状を受けれている状態を続けて、どうしようもなくなることもある。

特に、チームメンバのアサイメントについてはそれは、他のメンバに悪影響を与えるからよくない。

それが自分判断でアサイメントしたケースなら早々に判断を自分でやらなければならない。プロマネやマネージャが連れてきたメンバが期待どおりに機能しないとき、周囲のメンバはとても言いにくい。機能してないぞ、と言えるくらいの関係ができれいれば良いのであるが、メンバは過剰な配慮をしがちだ。

メンバはなぜ過剰な配慮をしようとするかその仕組みを知らないと、それを改善することもできないし、今の環境づくりは足らない観点があるということを気づくこともできない。

自分の場合、余計な衝突を回避しようと振る舞いがちである。これはどうしてかを自分に詰めていくと、衝突による説明やその場の収集などの面倒ごとを自分で作りたくないからである。

実際のところ、余計な衝突を回避しつつも、意見を言える関係も作れているので何が何でも、言いにくいことを言い、オフセットもなしに衝突する必要はないとも思っている。

評価を伝えたり、契約の継続の可否を話す際に、過剰な配慮や余計な衝突を回避しようとする現象が起きやすい。

それは、評価する方、つまり、プロマネやマネージャが批判や低い評価をする根拠となる事実を集めきれていないからである。同じように褒める根拠も集めきれていないとそうした振る舞いをする。

どちらにしても、批評をするのか褒めるのかのどちらであっても、どうしてそう思うのか、判断したのかその背景の説明が必要となる。さらに、それを自分がそう思うに至った同じ経験を示さなければ、批評も褒めることも真意からであると伝わらない。それは具体性、リアリティがないからである。

実際、薄っぺらい言葉で評価してくるマネージャの説明に一度も納得をしたことはなかった。このように言語化する前に、すでに自分で経験してたわけだ。

デザイン思考が世界を変える〔アップデート版〕: イノベーションを導く新しい考え方

この世界の片隅に 絵コンテ[最長版]下巻

チームアップの場で行きたいお店、飲みたいお酒

新年度のチームのキックオフやメンバの歓送迎会やプロジェクト完了で労いたいと思うことはままある。お酒を飲むというよりは、そういったチームアップの場では美味しいものを食べて、笑い、次もこのチームでやっていこうと思ってくれれば（思わなくても美味しかったと感じてもうだけで十分）それでもいい。

仕事の場から少しばかり離れて、飲み食いをするのはガードが下がるからオフィスとは違う顔を上手に引き出してくれるメンバがいたりすると新しい発見があったりするので興味深い。

だからこそ、お店選びでは大手のチェーン店は避けたい。別に高級なお店に行きたいわけではなく、美味しい料理と美味しい飲み物、お酒もそうだしノンアルもそうだ。

飲み物の中で日本酒の扱いがひどい所は避けたい。メニューで日本酒（冷や、熱燗）しか載っていないところでの日本酒のチョイスはありえない。

食べ物もチェーン店を避けたいのは、値段相応だからだ。安酒を飲みたいなら家飲みをすれば言い訳で、外で飲み食いするならそこでなければ食べられない、飲めない酒の銘柄に出会いたい。

では、自分の好みのお店の引き出しをどう作っておくか。

• グルメアプリ（実名登録かレーティング操作のないアプリ）を入れておく
• （作る系）グルメ雑誌の取材先のお店で合いそうなお店をアプリに入れておく
• ランチに行ったお店をアプリに入れておく

お店選びは結局、口コミか自腹を切って勉強代を払うしかない。スクリーニングでどのようなフィルタを掛けるかはその人次第であるが。

自戒しておきたいのは、こうした自分の偏向性のある考え方を押し付けて店探しをして欲しいというのはお門違いである。誰かが買って出てくれたのであれば、そのお店では会話を楽しんだり、少量嗜む程度にすればいい。肝心なのはチームアップにつながるか、なのだから。

【お歳暮】よなよなエール ビールギフト 4種 飲み比べ [ 350ml×10本 ] [ギフト包装済] エールビール クラフトビール 人気4種詰め合わせ

チェックシートで情報漏洩

お仕事を長くやっていると周囲を巻き込むことは多々あるが、巻き込まれることもある。お互い様であるし、巻き込まれは自分の専門性をそれなりに認知を受けたことの証左であるから、ある意味まずまずなのかもしれない。

その観点で言えば、都合のよりリソースであるという認識はそうした専門性を認知される前の方が高く、おじさんになると減っていく。おじさんがニコニコと手が足らなかったら気兼ねなく呼んでねというのは頼られることの機会創出であることはここだけにしておきたい。

そうした巻き込まれ仕事の中に取引先からのチェックシートを見て欲しいというときがある。これが割と意味不明なものが多い。

例えば、次のチェックリストはとても馬鹿げていることがわかるだろうか。

１）情報セキュリティ

　以下の設問すべて、貴社の行なっている情報セキュリティの対策をご回答ください。

A）取得しているセキュリティの認証をご記入ください。

　　①ISO27001　②プライバシマーク

　：

Z）従業員にセキュリティの研修を実施しているかご記入ください。　

　　①はい　②いいえ

端的に言えば、A)で認証を受けていると回答すれば、Z）は聞く必要はない。なぜなら、ISO27001でもプライバシマークでもマネジメントシステムとして教育を要求しているからである。

認証を取得しているのに教育を行なっていなければ外部審査で指摘されるし、ひどければ認証は継続されない。仮にやっていないのにやっていると虚偽なエビデンスを出していれば、日々の事業でインシデントを多発しているだろうし、第一、情報リテラシが低いからコンタクトしてきた営業やエンジニアの様子でお察しである。

さらに、次の質問をするということは、チェックシートを送ってきた組織で設問の装置があると言っているようなものだ。

L）IPS/IDSを導入している。

　：

P）Webフィルタリングを導入している。

それに、チェックシートを送ってきた組織がIT企業なら、そこのエンジニアはフィルタリングをかけられて、ネット上の技術情報やWebサービスにアクセスできなかったり、新しいサービスは逆にガバガバだったりするのだろうなと思ったりしなくもない。

別の見方をすると、たくさんの対策をしているかを尋ねている組織でセキュリティインシデントがあった場合、多重の対策は実は意味がないことの証明のようなもので、それと同じようなことを求めるのはおかしな話である。

あと、こうした対策を確認するということは、問い合わせを行なっている組織と同じセキュリティレベルかを確認する目的がある。つまり、チェックシートで対策の手の内をバラしているようなものである。

それはさておき、チェックシートで聞いたことに意味がなさそうな形ばかりの回答を確認するような組織はあとあとめんどくさい人が出てきそうでこわいこわい。

タニタ はかり スケール 料理 洗える 2kg 0.1g ホワイト KJ-212 WH

帰る前のリーダの雑談の有用性について

帰り際で急いでいるときに声を掛けられると、どうしたのと耳を貸しつつも、ちょっと用事があるから手短にとなるケースもあるが、そうでもなければ雑談をするにはちょうどいい時間帯なのではないかと思う。

先だっても、そう言えばあのCxOのコメントの真意を聞いてみたら実は○○の意味合いだったとか、slackで良さそうだと局所的に話題になっていたツールはどうかだとか、そうしたツールをちょこっと使っての感想を組織内向けのチャネルで発信してはどうかとか、ツールの評価をチームの活動に位置付けた方がニーズのあるエンジニアに届きやすいのではないかとか話がつながる。

夕方が良いのは、日中の仕事は様々なステークホルダーとのある意味パブリックな時間だったり、集中して作業をしていた案件をリリースするなど、区切りをつけられた後になるだから。

もともと相互で共通の課題を日中に進展があれば、記憶から溢れてしまう前に伝えておきたいという心理的な背景はとても同意できるものだと思う。

この時間帯の雑談は、ネガティブな件もチーム課題でも業務課題でも、話しながらキーワード的なものから、課題の設定自体など理解のベースラインを揃えるのにちょうど良い印象がある。

なんとなはなく、リーダのポジションの夕会というか半夜会なのかもしれない。ついつい話し始めて、話題が次々と繋がってしまうとあっという間に30分くらい経ってしまうのは玉に瑕だが、それ以上の価値はあるからやむなし、という感じで帰途につく。

Nintendo Switch 本体 (ニンテンドースイッチ) Joy-Con(L) ネオンブルー/(R) ネオンレッド(バッテリー持続時間が長くなったモデル)

Nintendo Switch Lite グレー

ランチとエンジニアの生産性

「エンジニアの生産性を測るのは難しいですね」

と隣でランチを食べているエンジニアが話を振ってくる。

『一般的にLOCのイメージだけど』と前置きして『同じ機能で1000行のコードと10行のコードとどっちが生産性が高いんですかね』と質問を被せてくる。

そんなものは決まっているじゃないか、と答える。

同じ機能なら、1000行のコードはリリースした瞬間、いや書いているときから（10行のコードと比較して）保守性がない。存在する瞬間から負債でしかない。

「じゃあ、どうしてLOCなんですかね」

「計測できるものがLOCと工数しかないからだよ」

 まあ、LOCさえ計測していることはないのだが。なにせ、開発環境がお利口になって自動的にコードを補完するので業務ロジックの部分は少ない。でもコードとしては色々と情報を持っている。分離できないそれをどう測るのか。

第一、計測してどう使うのか。月間1700stepが多いのか少ないのか。少なければ生産性は悪いのか。

少なければ少ないLOCの方がマシだ。できたら作らないことが一番だ。これの考え方を否定するエンジニアはいないと思うのだが。

新しい指標として（それほどでもないが）価値があるかどうかという考え方がある。これは使われる機能のことであるが、これもまた計測できない。

「1000行のLOCでも使われていれば価値があることになりますね」

使うかどうかを稼働している時間と定義してしまうとそれも間違ったデータを稼働としてしまいかねない。1000行と10行のLOCと同じになる。

保守性が高いということは可読性も期待でき、結果、残すドキュメントも少なくすることができるはずだ。

あらかた食べ終え、テーブルでチャージして席を後にする。

生産性―――マッキンゼーが組織と人材に求め続けるもの