Engineering Manager Meetup をやります

詳細の確認および参加申し込みは以下のページからお願いします。早速定員になってしまったようなのですが増枠も検討中です。

connpass.com

動機

いちエンジニアリングマネージャとして、エンジニアリングマネージャ・エンジニアリングマネジメントに興味・関心・知見・意見・失敗談・一家言ある方々と話してみたい。

"エンジニアリングマネージャ"の曖昧性

イベント概要欄に書いたとおり、（少なくとも自分が観測しているWebサービス業界隈では）エンジニアリングマネージャ職について統一された定義・見解を見ることはほとんどありません。

エンジニアリングマネージャというポジションは組織が成熟する過程において戦略的または偶発的に発生しており、会社や人それぞれによって思い描く姿やその実態・運用が異なるようです。*1

また、スタートアップ初期においては必要性が認識されることはあまりなく、CTOがその役割を兼ねていることも多いようです。*2

「いわゆるマネージャやテックリードとは何が違うのか？」という問を見るにつけて、プロダクトマネージャという役割が流行り始めた当初の「プロジェクトマネージャと何が違うのか？」と言われていたことを思い出します。

しかしプロダクトマネージャ職は今でこそ product manager conference や product manager meetup が開催されるほどにその専門性と職務内容の認知が高まり、組織ごとの知見や工夫・失敗談を交換する機会も多いものの、エンジニアリングマネージャは未だそれには及ばないと考えています。

そうした機会は少ないながらも、このポジションに就いている方はそれなりにいるようなので、各々の創意工夫や悩み、ドラマがあるのでしょう… 僕はそんな方々のうまくいった成功談、また、それ以上に失敗談も聞いてみたいのです。

---

…という思いを込めた tweet。

Engineering Manager Meetup 存在しないならやってみようかな

— 広島の粗大ゴミ (@ohbarye) 2018年7月20日

---

話すテーマについて

Connpass ページに書いたとおりオープンスペース形式でやりたいと考えています。LTやプレゼンの準備は不要です。その代わり「何を話してみたいか」のタネが大事です。

興味が沸くように、あるいはイメージが湧くように、Connpass に書いたテーマのいくつかについて一言ずつ触れてみたいと思います。

「自分はこんなことを話してみたいな」ということを書きます。（議論の方向性を決定づけないように自分の意見は控えめで）

エンジニアリングマネージャの仕事内容

少なくともコードを全く書かないポジションではなさそうだと思うものの、どのぐらい書いている、あるいは書くことが期待されているのか。オレは毎日書いている…お前らはどうだ…???

エンジニアの上司はコードを書ける人間であるべきか？という問をよく見るが、個人的にはどちらの視点から見るかによって意見が変わりうる。

例えば自らの立場がメンバーだとしたら「マネージャはコードを書けなくても良い」と答える。コードを書けなくても頭の切れるマネージャのもとで働いたときの経験からそう思っている。エンジニアリングや目標設定に関するフィードバックは同僚から貰うこともできる。

だが、もし立場がマネージャであるときは、コードを書ける人間であるよう自分が自分に要請する。前述した自分の元上司ほど頭が切れるわけではないので、メンバーのエンジニアの抱える問題や挑戦をより深く理解するためには一定のエンジニアリングスキルは間違いなくあったほうがよい。

ちなみに『Work Rules!』によると

グーグルの採用の信条は、エンジニアリング部門のマネジャーは最低でも自分のチームのメンバー並みの技術力を備えていなければならないというものだった

エンジニアリングマネージャの仕事、キャリアパス、求められるスキル

この辺は先述の、エンジニアリングマネージャ何する人かという問いの答え次第でもある。

また、エンジニアリングマネージャを続けた先に何があるのか？VP of Engineering なのか CTO なのか分からないが、それがオレたちの望んだ未来なのか...???

テックリードなど他職種との違い

エンジニアリングマネージャからピープルマネジメント除いたらテックリードになる、みたいな会社もあるようです

エンジニアリング組織論

はい

エンジニアリング組織論への招待　?不確実性に向き合う思考と組織のリファクタリング

本の感想を語り合う場所であっても良さそう

給与

エンジニアリングマネージャの給与の話だけでなく、マネジメントするメンバーの給与に関して裁量があるのか、どのように決定しているのか。そのあたりが気になります。

また、各社エンジニアリングマネージャの給与をそれ以外のメンバーに比べて高く設定しているのだろうか？

個人的には"マネージャ"と付く名前の役職にならないと給与が頭打ちになるような会社は嫌だという思いがあります。

自分が新卒入社したSIerで、エンジニアリングスキルを伸ばすよりもプロジェクトマネジメントスキルを伸ばした方が評価されるような状況にて悩んだ経験から強くそう思っています。

ちなみに U.S. 全体で$108,849 per yearが推定平均給与 by Indeed (8/13時点)

https://www.indeed.com/jobs?q=Engineering+Manager&l=United+States

Indeed Japan だと給与どころか募集があまり多くなく、推定平均給与の記載もない

https://jp.indeed.com/%E6%B1%82%E4%BA%BA?q=Engineering+Manager&l=Japan

エンジニア採用

会社によっては採用もやるようだ。

自分も採用活動に関わっているが、エンジニアリングマネージャだからやっているとか、エンジニアリングマネージャだから採用権限があるわけではない。

そういえば、マネージャに採用権限を与えるのはアンチパターンだと『Work Rules!』にはある。

採用に関する権限をマネジャーに手放してもらう必要がある。前もって言っておかねばならないが、グーグルが新たに雇うマネジャーはこれを嫌う！　マネジャーは自分のチームを選抜したがるものだ。ところが、意欲に満ちたマネジャーでさえ、人材発掘の作業が長引くと採用基準をゆるめてしまう。

---

マネジャーに採用決定を任せると、チームのメンバーに対して彼らの権力が大きくなりすぎてしまう

評価、育成、1-on-1

1-on-1 のやり方や研修関連の情報はそれなりに見かけるし、参考になる書籍もある。

評価は結構ナイーブな話題なのでオンラインで公開するのが難しい側面も含んでいると思う。

ネガティブフィードバックをどうするか。パフォーマンスの低い社員の扱い。解雇の権限（日本だとまず無さそうではあるが…）

また、エンジニアリングマネージャにメンバーの給与を決定する裁量があるのかどうか。

許可より謝罪　権限とか承認とか

功利主義的に考えたとき承認制は本当に効用が費用を上回るのか？

意味ある承認、会社や法的に義務付けられた承認があるのも勿論知っていますが、世の中の89%ぐらいの承認って無意味ではないのだろうか。残り11%で失敗したときのリスクがでかすぎるというなら払うべきコストだと思うが…。承認業務が比較的少ない現状でもそんなことを考えている。

またまた『Work Rules!』を持ち出すと「マネージャは部下に権限を与えまくって、不安になるぐらいでちょうどいい」という話が良かった。

人々がマイクロマネジメントに走るのは、組織のパフォーマンスに関する不安を緩和するためだ。つまり、他人の行動を絶えず監督し管理していると気が楽になるのだ──これは、本質的には彼らの自信のなさを表しているにすぎない。そうすることで、マイクロマネジャーは自分が管理をしている（役立っている）という幻想に浸れる。もうひとつの動機は、スタッフの能力に対する信頼の欠如だ。マイクロマネジャーは仲間が『やります』と言っても、彼らが職務を見事にやり遂げる、あるいは責任を果たすとは考えないのだ

---

書き始めたら一言触れる程度では終わらなかったうえにあまり unobtrusive にもならなかったので、わりと話したいことがある気がしています。

ということで改めて応募お待ちしています。

connpass.com

---

Slack group も用意しました。“コミュニティのSlack廃れがち“問題はあると思うので何か面白いアイデアが欲しいところ

https://join.slack.com/t/engineering-manager/shared_invite/enQtNDEyMjM2NzY3OTY4LWY5NjgwMzVhMGM0MDUwZDE5OTgxNjE3MTQxMjc5NGM0YjRmMGQ4ZDYwYzVmNjdlZmRkMzAxZDQ1NWYyM2ViMWY

参考

ちょうど読んでいる最中なので引用元が Work Rules! ばかりになってしまった

ワーク・ルールズ！―君の生き方とリーダーシップを変える

*1:要出典

*2:要出典

会社ブログでは固有の文脈・ユースケースにフォーカスした話を読みたい

いつもお世話になっている TechRacho の以下の記事を読んでいて気になったこと、思ったこと。

TechRacho（自社技術ブログ）に関連したあれこれ、2年毎日更新してみて感じたこと

これだけ見てくれる人が増えたらちょっとは採用応募が増えるかなと期待しているのですが、アクセス増のわりには増えないですねー。TechRachoはわかるけど、BPSのことはよく知らないしなー、なのかしら。あるいは、コンテンツ配信だけだと、どんな技術者がいて、どんな開発をしているのかわからない、なのかしら。それとも両方？

おー、そういうものか…と驚きもあり、最近の自分の考えを補強するものでもあった。（確証バイアス）

---

TechRacho とは運営趣旨がだいぶ異なるものの、弊社もQuipper product team blogをやっている*1。PVは TechRacho にはまだまだ及ばない。

ブログのおかげで採用大成功していますと喧伝するほどではないし、そもそもブログ単体に採用への直接的貢献を求めていない*2けれども、以下のような事例が増えてきた。（定性的意見）

1. 面接時に「ブログで知りました」「ブログ読んで応募しようと思いました」と言ってくれる
2. 最近入社された方が「ブログも入社を決める一因となった」と言ってくれる

2の方の意見からいくつかピックアップして要約する：（N=2）

• 普通は見ることができない社内のやりとりを見られることで、どんな雰囲気で仕事をしているのかがイメージできて親近感が持てた
• 情報発信をしている企業は結構あるので、どちらかというと量より質が大事
• 採用ページや Job Description はどうしても抽象的な話になるので実務ベースの話の方が参考になる

現時点では全くもって定量的ではないのだけど、採用を目的の一つに置くような会社ブログでは会社固有の事情や文脈やユースケースにフォーカスした方が良さそうだと考えている。というか自分ならそういうブログが読みたい。

---

以下は会社ブログに限らない話：

内容の"質"が高いことは大事だが、技術単体に関する話はたいてい公式のドキュメントを読めば良く、ものによってはすぐに陳腐化してしまう。

だからこそ、ある文脈でなぜそれを選んだか・どうやって抱えている問題を解決したか・またはなぜそのやり方で解決できなかったか・これからどうしていくか等々を語ることや、その実践のログを通じて発信者（会社・個人）の思考様式を外部から評価できることに価値があると考える。

「ユースケースや文脈抜きでの技術選択や評価を盲信するな」という意見にも通じる。

*1:同blogの趣旨については なぜこのブログは「エンジニアブログ」ではなく「プロダクトチームのブログ」なのか - Quipper Product Team Blogを参照

*2:AIDCAメンタルモデルによる Attention（注目）→Interest（興味）→Desire（欲望）辺りは期待している

必要なときだけ Polyfill.io のCDN から polyfill を読み込むようにする

以下のような script tag を HTML の最初の script tag として埋め込む。

<script>
(
  function(doc){
    if([].find&&window.fetch)return;

    var firstScript = doc.getElementsByTagName('script')[0];
    var scriptToInsert = doc.createElement('script');
    scriptToInsert.src='https://cdn.polyfill.io/v2/polyfill.min.js?features=Array.prototype.find,fetch';
    firstScript.parentNode.insertBefore(scriptToInsert, firstScript);
  }(document)
)
</script>

無名関数の1行目で polyfill が必要かどうかを判定する。

必要であれば、cdn.polyfill.io から polyfill を得るための script tag を document に埋め込む。

doc.getElementsByTagName('script')[0] より前に insert しているのは polyfill が読み込まれる前に script が実行されるのを防ぐため。

---

Polyfill.io については https://polyfill.io/v2/docs/api を参照

gem install することなく Slim, Haml, Pug を HTML に変換する

Rails の view を React で書き直したときに使った脱 Slim のやり方

各種 gem を install して手元でコマンド叩いてもできるけど面倒くさい場合に使える

結論

converter - How can I convert html.slim files to html or html.erb? - Stack Overflow この回答どおり、CodePen に Slim などを貼り付け、コンパイルされた結果を参照すれば良い

詳細（Slim の例）

StackOverflow で記載されていることに特に付け加えることはないが…以下のやり方でコンパイルされた HTML が見られる

1. CodePen で新しいプロジェクトを作る
2. HTML 入力欄の歯車をクリックし、 HTML Preprocessor として Slim を選ぶ
3. 変換したい Slim を入力する
4. HTML 入力欄の逆三角をクリックし、View Uncompiled Slim を選択

余談

HTML2slim は HTML -> Slim の単一方向のみ

CodePen でなくても出来るとは思う

「○○の経験したこと無いくせに」と経験者が語ることについて

「○○の経験したこと無いくせに」

「○○したことないからわからないんだよ」

という言説を見聞きしたり、この論旨で「論破してやったわ」みたいなの Twitter で見るたびげんなりしてしまう。

「恋愛したこと無いくせにラブストーリーとかｗｗｗｗ」っていうのはわからんでもないがこの理論だと尾田栄一郎は元海賊だし冨樫義博は一回死んでるし宮沢賢治にいたってはNASAより先に宇宙行ってる

— まつくｳﾞｧ＠MONOつくりの会 (@matsu_kuva) January 16, 2012

こういう反論でも良いと思うけどちょっと論旨がずれそうだ。

トラブルを避けるためにちゃんと理解してもらいたいのは、相似する、もしくは全く同じ経験をした人間が自分と同じことを知ったり学んだり思ったりするわけではないということ。自分の個別的な経験・思考を、一般的な事例や法則へと置き換えてしまうのは過度な一般化だ。

学校で一斉授業をうけていたこととその結果を思い出してくれるとだいぶわかりやすいと思うのだが…自分の観測範囲では、人生にとっての一大イベントと当人が考えるような事象については驚くほど多くの人が他人に追体験を要求しがち。

...という自分の信念を補強する、それっぽい箴言を集めてみる（確証バイアス）

愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避けるため、他人の経験から学ぶのを好む。

オットー・フォン・ビスマルク https://ja.wikiquote.org/wiki/%E3%82%AA%E3%83%83%E3%83%88%E3%83%BC%E3%83%BB%E3%83%95%E3%82%A9%E3%83%B3%E3%83%BB%E3%83%93%E3%82%B9%E3%83%9E%E3%83%AB%E3%82%AF

---

シーザーを理解するためにはシーザーとなる必要はない。 →「追体験できること」は、理解の明証性のために重要であるが、それは意味解明のための絶対条件ではない。

マックス・ヴェーバー ウェーバー「社会学の基礎概念」

⌘+shift+d で"開いているすべてのタブをブックマークとして新しいフォルダに保存する" on Google Chrome

登壇のために Google Chrome 上で開いているタブをすべて閉じて片付けたいが後で一発で戻したい。そんなときに ⌘+shift+d が使える

support.google.com で見つけた。

---

単純に閉じて再起動すれば？ => Google Slides で発表するのでブラウザを立ち上げたままにしたい

Safari などの別ブラウザ使えば？ => 普段使いが Chrome なので登壇時も慣れているブラウザを使いたい

「Quipperが実践する、定量データに基づく意思決定と開発」という話を Rails Developer Meetup 2018 Day 3 extreme でしてきました

してきました。

techplay.jp

スライド

データ周りや意思決定の話は専門ではないのであまり主語を大きくして叩かれないようにわりと渋めのタイトルにしました。ちょっと局所的すぎたかもしれません。

トーク

20分のトークは初めてだったので勝手がわからず86枚もスライドを作ってしまいました。直前の脳内練習では18分に収まったものの本番では20分30秒ぐらいになってしまったので練習が足りんなぁ〜と思いました。

質問も ama でいただけていたのに時間内で回答できなかった…ので先ほど web で回答しました。

.@strviola いただいたご質問「BtoBのサービスで「リリース後に価値を測る」方法が知りたいです (自分がBtoBにいるので)」に回答しました！遅くなってすみません 🙏https://t.co/kmpcI6FoG0#railsdm #rdm2018b

— 広島の粗大ゴミ (@ohbarye) July 14, 2018

.@yensaki いただいたご質問「コストかけてテストを実施するというのはどうやって合意を取りましたか？」に回答しました！遅くなってすみません 🙏https://t.co/kmpcI6FoG0#railsdm #rdm2018b

— 広島の粗大ゴミ (@ohbarye) July 14, 2018

このように非同期で質問に回答できる仕組みもすばらしい！！

RailsDMについて

実は今回が初参加でした。

とにかく言いたいのが、あれだけのすごいイベントに無料で参加できてしまって本当に良いんですか〜〜

トークが豪華なのは言うまでもなく、ランチもコーヒーもディナーも付いてきて長丁場でも参加できる優しさがありました。オンライン配信とか別会場で同時開催とか、個人の頑張りでできる域を超えている〜〜

来週の StudySapuri Product Meetup も規模はぜんぜん違いますが来場者に満足いただけるよう負けずに頑張ります。

techplay.jp