エンジニアの仕事には『やりたいことをやらせない』もある
人事関連の方から相談したいと話があり、指定のお時間に場を持つことになった。話を伺うと、組織内のelearnigの見直しを考えらているらしい。
これまでの経験から言えば、elearningのコンテンツで面白いと思ったり、興味を持つようなものはなに一つなかった。セキュリティ、契約関連の法令、ハラスメント、労働法関連などいわゆるコンプライアンス関連ばかりが更新され、所属する全ての社員が受けさせられる。背景には、年1回は教育を行うと自ら決めているからで、それを主管部門が行なっている。
何れにしても、面白くない。
話を聞いていて、話の流れがおかしいなと思った。それは、こんなことを聞いたからである。
- 各部門内で行なっている教育のコンテンツがある。それを全体で教育したら良いのではないか
- 共有するにあたり、新しいプラットフォームを考えている
- 例えばA社のものが候補になる
こちらからの違和感を伝える。
- 各部門で行なっているのは、事業特性があるからである
- そもそも他部門のコンテンツに興味を持つだろうか
- 現時点では部門内に閉じているのであるから知りようがない
- 他部門のコンテンツを知りたいとニーズがあることを確かめたのか
大事なことは、知らないものを欲しいとは思わない。知っているもので、自分が関心を持っているものだけである。
こうしたニーズをマネージャに聞いてはいけない。欲しいかと言えば、あった方がいいと答えるのが定石だ。マネージャの担当部門内で教育コンテンツが回っていればいらないと答えるだろう。
エンジニア目線で言えば、必要なときに求めるのであって、棚で埃をかぶっているようなコンテンツに目は行かない。新しいもの、自分の知らないものはネットで調べてしまう。組織内を検索するのは、組織の中のことだけである。もし情報を身近なところから得たいと思えば、知っている人を探す。
人事の人も元は、教育の機会の再創出を狙ったのだろうが、それがいつの間にか、システムの導入に変わってしまっている。これは今の仕組みの問題点の原因を掴みきれていないからだと思っている。
そこをクリアした上で、なにをするかを小さく始めないと使われないシステムを導入することになってしまう。
エンジニアの仕事には、やりたいことをやらせない助言もあるのだと思う。
退職エントリーまとめ（2019年1月〜3月）
2019年版の退職エントリのまとめ。はてブで退職エントリで検索した結果を1月から四半期ごとに括ったものである。本来は1年分にしようかと思ったが、4月の年度替りでそこそこの件数が多いと感じたので、自分の閲覧性から四半期としている。
退職エントリを書いて公開した後に削除もしくは非公開にしているエントリがそこそこ見受けられる。 エントリが表示されないにも削除したぽいものや503でで返ってくるケースもある。退職理由も様々であるが、公開後の措置も様々だ。
なお、月の括りは明示的にわかるものと、多分そうかなでまとめているので退職月が違うかもしれないがその点はご了承の上でご覧いただければ。
3月 やはり、3月が多い。日本の年度意識を感じる。
N社
F社
内定辞退。
研究職から専業作家さんへ。
廃業。
alibabaの中の人の。
某NTT系退職エントリー。
辞めて別採用で入り直したケース。
githbubだ
noteのブログも増えたな。
主夫になるのね。
庭師になるのですなー
1日付で退職するのは珍しい。
2月 2月も少ない。
辞めた時期は未記載。
1月 1月は年末に辞めましたとか、してました系が多い。
増田を入れるのはどうなんだろうか。こだわりはないけど。
FromとToのみとシンプル。
退職『され』エントリは新しい。
シンプル。
退職月は不明。
『2018年退職しました』退職エントリまとめはこちら。
調達 キーパー技研(KeePer技研) コーティング専門店のホイールクリーナー 300mL I-05
キーパー技研(KeePer技研) コーティング専門店のホイールクリーナー 300mL I-05
- 出版社/メーカー: キーパー
- 発売日: 2014/04/30
- メディア: Automotive
- この商品を含むブログを見る
たたき台はスゴイ
- 実現したいイメージ
- 構成のイラスト
- ざっくりしたスケジュール
- マインドマップ
どのような表現でもいいからたたき台をつくる。
たたき台とはゼロをイチにする作業を始めた証である。それはさておき、なぜたたき台が爆速で仕事を進められるか。それは、そのたたき台を見せる相手の主導権を握りつつ意思疎通をできるからである。
たたき台を見せれば、そのたたき台をベースにどう進めればいいか自分で方向性を考えることができる。
たたき台を見せられる機会が多いとついついあれこれと自分の考えを言いたくなる。この感覚、つい言いたくなるというところが大事なのである。
ある意味、たたき台の最大の目的は、見せた相手にあれこれと言わせることだ、と言っても良い。
だから、たたき台は早く見せたほうがいい。見せる相手がその人自身で同じテーマを考え始めたら、考え出して導き出した方向性を修正するのは難しくなる。
でも。
こちらが先にたたき台を見せて、言いたいことを言わせれば方向性はたたき台を作ったエンジニアの方向性に向く。たたき台を見た人はその方向性の延長線上で考えを言い始める。つまり、本筋はたたき台で変わらず、枝葉末節で変わってくるだけである。
大事なことなのでもう一度のべるが、たたき台を見せる相手に時間を与えて、自分が受け取ったタスクのたたき台を考えさせてはいけない。考え始める前にたたき台を見せるのである。
たたき台は、言われて作ってはいけない。言われる前にたたき台として先に出す。
- 先手を打てるので考えている分、優位性がある
- イメージをすりこめる
- あらあらだとしても自分で何かしら考えているのでざっくりと説明できる
- 話の主導権を握れる
- 次をどうするかも決めらる
- 進め方、スケジュールも掌握できる
率先して見せる、たたき台にはメリットしかない。
逆に言えば、言われてたたき台を作るとこれを全部持っていかれる。ツラミしか思い浮かばない。
だから、たたき台はスゴイのである。そのスゴイたたき台の主導権を手放してはいけない。
他者と働く──「わかりあえなさ」から始める組織論 (NewsPicksパブリッシング)
- 作者: 宇田川元一
- 出版社/メーカー: NewsPicksパブリッシング
- 発売日: 2019/10/04
- メディア: 単行本
- この商品を含むブログを見る
リモワとオンサイトでの見える風景
フルリモートで働きたいというエンジニアをチラチラとTLで見かけるようになった、というか、いるよね的なものも含め。
フルリモートではない社員の環境整備の観点からも、業務上の条件や労働環境（主にネットワークやOA環境）に支障を排除して整備しておく方が働き方の柔軟性を備えるので、未だ整備途中であればそのような組織もそちらの方向に進んで欲しいものだ。
リモワの風景
リモワは最小限のコミュニケーションに絞り込める。周囲のノイズからも遮断できるから集中して仕事をできる環境を手に入れられる。ただし、子育てや介護がリモワの理由の場合はそうもいかないかもしれない。
コミュニケーションは、非同期にコントロールできる。必要ならslackでmentionを投げておけばいいのである。もともとメールも非同期なのだから、思想的には変わりない。
実際、リモートで仕事をしてみると通勤の時間は不要になるし、割り込まれる機会が減るので集中作業を意図的にする場合に有効である。しかし、次の問題を内在していることは押さえておいた方が良い。
- 自律を自分に課しているという自覚を持てるか
言い方を変えれば、その日の成果を自分で立てた計画に沿ってアウトプットできるかといことである。
これは別にオンサイトでも自分の進捗を出すことには変わりはないのだが、自分の振る舞いを見ている目は自分の目しかないことを少しだけ意識した方が良い。
あと、見えているだけでも1つのコミュニケーションだと思っている。それがなくなるからそれを意識的に自分から行わなければ影が薄くなってしまう。
コミュニケーションをコントロールできる一方で新たなコミュニケーションコストを自ら支払わなければならないのかもしれない。
オンサイト側からの景色
オフィスの、オンサイト側からの景色は、側にいれば様々な反応、表情、声、行動などからその人の情報を知ることができる。本人は言い出せていないが困っていそうだ、など気づけることもある。
物理で側にいるわけで、声をかけやすいということは、反応をすぐに期待できるということでもある。
タスクはチケットを取ってから出来上がるまでの間、どうかと聴きやすい。それはやはり側にいて視界に入るからである。
人は認識しているものに対してとても視認する生き物だと思っている。逆に視界に入らなければ関心が薄れていく。
これをチームでやってしまうと非常にまずいことになる。仕事の独立性が高いと自分の担当業務に関心を向けるのでその傾向は強くなる。
リモワのメンバがいても、ペアで仕事する文化であれば、その心配事はしなくて良い気がする。慣れるまでは違和感があるかもしれない。
『いい人』なエンジニアを採用しないために
持論として、採用の軸を持っていないチームメンバは、エンジニアの採用に関与してはいけない。一方、採用はチーム全員で関与すべきであるし、しなければならない。
チームのエンジニアは全員採用に関わらなければならない理由
突然、明日から採用したエンジニアが入社することになったと告げられ、そのエンジニアは『あなた』と仕事をすると言われたらどう思うか。
どんなエンジニアか全くわからないし、最悪そりが合わないかもしれないし、意思決定や振る舞いがずれているかもしれない。意思決定や振る舞いが自分と合わない場合、ほぼ日中の全てを業務として、側で過ごすことは想像以上にストレスフルである。
結局、入社後に同じ業務につくエンジニアが採用プロセスのトレースをするのである。であれば、採用プロセスの頭から関与すべきなのである。
採用する側の責任
採用するポジション、想定する業務のイメージを持っていないと、迂闊に採用してから採用されたエンジニアがキャリアで悩んでしまうだろうし、同僚としてのチームもまた困る。
やりがちなのは、今困っている業務や技術をリソース的に解決するために採用してしまうことだ。それは当たり前だと思ったら違うと言わざるを得ない。
ではその困っている業務が解決した後、採用されたエンジニアはどうするのか。属する予定の組織でそのさきのキャリアを開けそうか。
今の問題と将来のキャリアを採用時に話さなければならない。そこでイメージを採用候補者が持てれば、多分大丈夫なはずだ。
採用プロセスでのサンクコスト
採用での問題はここである。
チームのエンジニアを採用するとき、何十人も採用候補者と会っていると、だんだんとサンクコストを感じて、いい人だから採用してはとと思いがちになる。特に、思考的に基準を持てないエンジニアはその傾向がある。
サンクコストについては、どうしてそう思ってしまうかその原因を推測すると、何十人も採用候補者と会っていていると相当の時間を費やす。夕方、採用候補者の都合や業務の都合があれば、夜8時から面談したいとスタートすることもある。チームのメンバによっては、家族の予定（お迎え、子守など）を調整したりすることもあるかもしれない。
そういったことが積み重なると、思考に軸を持っていない、criteria baseで意思決定をすることに慣れていないとメンタル的にも体力的にも疲れて妥協をし始めるのである。
妥協し始めるときには、採用のリーダーシップを持つエンジニアが意思決定すればだいたい同じように思うから自分は関与しなくてもいいとか言い始めたら、すでにサンクコストを感じているので、どうしてチームで採用しているかをリマインドが必要である。
いい人は沢山いるが欲しいエンジニアはまずいない
繰り返すが『いい人』を採用したいのではない。いい人ならいくらでもいる。TVで容疑者の印象を近所の人に尋ねるとだいたいがいい人である。いい人はいくらでもいる。
でもチームで成果を出してくれるポジションに採用したいエンジニアはそうそういない。
それでも、折れてはいけない。技術的負債より人的負債は大き過ぎる。
