valid,invalid

関心を持てる事柄について

半年間、自分を騙しながらアウトプットに積極的になってみた

この半年間はソフトウェアエンジニアとしてのアウトプットに積極的になるよう意識的に行動してみたので振り返ってみます。長くなってしまったので3行でまとめるとこんな感じです。

  • 成長と刺激を求めて OSS contribution や登壇やイベント運営を頑張ってみた
  • 成長したかはわからないが、知り合いが増えたりして刺激を受けることが多くなった
  • これからも続けていくが持続可能なペースにしたい

だいたい2018年上半期の話ですが一部期間外の話もあります。

なぜアウトプットを増やすか

唐突ですが、現職では日常の業務を漫然と続けるだけで成長するフェーズは終わったのかなぁと思っています。新しく何ができるか、何をすべきか、もしくはしなくてよいのか。昨年、転職から2年が経過したときにそんなことをぼんやり考えていました。そのときに書いた記事 (now = ohbarye.hired_at.since 2.years) から意識が高まっている箇所をセルフ引用します。

ドメイン知識以外のところでもっと勝負したいとかいう気持ちがある。

Be the worst の精神を忘れたくない、技術系のコミュニティから刺激を受けたいという思いもある。直近では勉強会やカンファレンスでの登壇や週1~2での副業を積極的にやってみるというのも卑近な方法だろうか。

また、乃木坂太郎氏の『医龍』という漫画が好きなのですが、話中の天才医師浅田の言葉にも刺激を受けました*1

“腕ってやつは、上がってると感じてなきゃダメなんだよ。維持してると思ってんなら、落ち始めてるってことだ。”


上述のお気持ちだと抽象的すぎるので、達成したかったことをもう少し言語化すると以下の2点に集約されます。

成長する

"成長"の定義は「僕が理想とするソフトウェアエンジニア像と現在の自分とギャップが埋まること」。*2

刺激を得る

無限不断努力をできるタイプではないので自分の""やる気スイッチ""を押せる手段が欲しい。*3


やったこと

上述の「成長する」「刺激を得る」が"目的"で、以下は"手段"です。

1. OSS contributionを増やす

実は最近あまりやれていないのですが GitHub を見る限り2018年内だと50本ぐらい pull requests を出したようです。

また、その過程で貢献できるOSSを探せるツール (goofi)を自作したり、このツールに関する発表が出来てよかったです。

しかしこの点についてはまだまだです。継続的に特定のプロダクトに関わっているわけでもなく、小さな修正を重ねても「contribution できたぁ〜」と「だからなんだ…?」の間を意識が行き交っています。もちろんコードを読んだり書いたりする機会が増えているのはポジティブなのですが、contribution を通じてでなくても良いのかもと思ったり。もちろん、contribution するに越したことはないのですが。

2. GitHubのプロフィールを充実させた

「自分や他人が良い/欲しいと思うツールやライブラリを作って公開しているエンジニア」に憧れがあります。なので GitHub のプロフィールを見て「やっていき手かな?」と思う兆候の1つに star が集まっているレポジトリが並んでいること、というのがあります(ohbarye基準*4)。

さて自分のがどうかというと、1年ぐらい前は kpt-bot が10 stars 集めるぐらいだったのがややマシになりました。

ohbarye (Masato Ohba) · GitHub

image

充実させるためには手を動かして何かを作らなければいけないので、とても小さい課題でも解決するツールを書けないか考えたりするようになりました。まぁ、たいてい既存の組み合わせでなんとかなってしまうのですが… それでも作ったものについてまとめたり紹介してフィードバックを貰えるととても刺激になります。

3. 登壇を増やした

プレゼンに関するメモをちまちま更新し、自分のプレゼンは改善されていると自己暗示をかけていかないと不安を抑えられないぐらいには人前で話すのが苦手です。

心の中で「やるぞ!!」と強く決意しても、すこし放っておくだけですぐにやる気が""無""になってしまうのを知っています。

なので会社の GitHub issues で「登壇やっていき表明」というイシューを立ててお気持ちを表明し、2018年度上半期の目標にも設定しました。ohbarye は退路を自ら断ったのだ…。

image

あとは強い人たちが言っている(と勝手に思っている)「勉強会の類は登壇するときぐらいしか行かない」の真似。プレゼン枠があるのにそれを避けて一般参加枠で申し込むのを止めました。

成果としては上半期で10本ぐらい登壇経験を積むことができました。「LTばかりだ」とか「やっている人はもっとやっている」とか、そういうセルフ突っ込みが止むことはないですが、2017年末までは一度もやったことがなかったのに比べるとだいぶ前進したと思ってはいます。

Presentations by Masato Ohba - Speaker Deck

image

得意領域ではない frontend を伸ばすために勉強した JavaScript 周りを JS コミュニティで発表したり、1回もiOS開発やったことないのに iOSDC に登壇したり、だいぶコンフォートゾーンを出たつもりです。

4. イベントを主催した

Quipper Product Meetup

7月に Quipper Product Meetup というイベントを開催し、この運営を担当しました。

StudySapuri Product Meetup を開催しました #sapurimeetup - Quipper Product Team Blog

会社とプロダクトのブランドやバリューによる成果ですが、定員120名に対して事前申し込みが400件超えしていた人気イベントを仕切るというのはなかなかのプレッシャーでした。

エンジニアコミュニティで知り合った方なども来訪してくれて「お、こういう風に人が繋がっていくのは楽しいかもしれない」と感じられたのが後続の Engineering Manager Meetup などにも繋がったと思います。

Engineering Manager Meetup

つい先日、Engineering Manager Meetup というイベントを主催しました。動機や感想は以下の記事にまとめています。

Engineering Manager Meetup をやります - valid,invalid

Engineering Manager Meetup #1 をやりました #em_meetup - valid,invalid

テーマがテーマだけに上述したような「ソフトウェアエンジニアの成長や刺激という狙いから少しずれるかも」と企画した当初は思っていたのですが、それは間違いでした。

僕が尊敬する、インターネットで見知っていたようなエンジニアやエンジニアリングマネージャ・CTO・VPofE、影響を受けた本の著者といった、普段生活をしているだけでは絶対に会えないような人たちと出会い、意見を交換したりすることができるようになりました

刺激が欲しいとは言っていたものの刺激が強すぎて"熱"が出てきました。

Meguro.rb

イベントで何回かトークをさせてもらったり懇親した流れで、第19回Meguro.rbのスポンサーを Quipper がやることになりました。

僕が何もしなくてもそうなったかもしれないけど、アウトプットを出すことを通じてこういうチャンスが流れてきたこと、そこに関われたことを嬉しく思います。

5. コミュニティづくり(継続中)

Engineering Manager Meetup の Slack workspace の中でオフ会が生まれたり、色んな方が意見を交換できるようになってきました。

コミュニティやイベント運営について遥かに知見あるカルパスさんからこのようなコメントを貰えて嬉しいです。

僕が参加したイベントの中でも、カルパスさんが主催する Rails Developer Meetup は本当に素晴らしいのでこれからも背中を追っていきたいと思っています*5

その他の細かいアウトプット

Dev.toに記事を書く

仕事で書く機会が減り気味だったので英語の練習がてら書いていました。

Masato Ohba - DEV Profile

dev.to には #showdev という「作ってみた」的な tag があり、これで自作のツールやWebサイトを紹介したり。このブログや Qiita に書くよりも like (いいね) や star が集まりやすいな、という感覚があります。純粋にリーチする数の問題とも違い、英語圏はポジティブフィードバックに前向きな気がする (暴論)

ISUCONに出た

出て惨敗しました

ISUCON8にチーム"sayotan"で参加し、予選落ち (Best Score: 23,553, 最終結果: fail) でした - valid,invalid

Open Processing

ゴールデンウィークの頃は P5.js にハマっていたので Open Processing に登録してお絵かきしたりしていた

ohbarye - OpenProcessing


アウトプットを続けてわかったこと/変わったこと

「勉強会の類は登壇するときぐらいしか行かない」の意味

以下の事柄に価値があるとはもう何万回も言われていることだと思うのですが言葉でなく心で理解しました。

  • 発表するために調べたり手を動かす
  • ポジティブ/ネガティブフィードバックをもらう
  • 同じ関心を持つ人が見つかる
  • そうしたエンジニア同士で質問したり議論したりできる

上記の体験を得るにはやるしかないんだよなぁ…。

「全て」を敢えて差し出した者が、最後には真の「全て」を得る』…*6

ぼっちじゃなくなってきた

konifar さんが アウトプット増やしたらぼっちじゃなくなってきた - Konifar's WIP で書いていることとまんま同じです。3年以上遅れて背中を追っている感覚です。

昔は勉強会やミートアップに参加しても「まぁ、アルコールも飲まないし、懇親会はいいや…」という気持ちでスキップしていました。出るにしても知り合いがいないのでぼっちになるか、たまたま近くにいた人と雑談して終わるだけであまり楽しくなかった。自分の引き出しの少なさや未熟な話術のせいといえばそれまでですが…。

その頃に比べるとだいぶ楽になりました。登壇することで話しかけてもらえるようになり、また、自分のことを知ってもらった状態で会話がスタートするので最初の方の自己紹介プロトコルを省略できたり(できなかったり)。

コミュニティ/イベント運営が好きかもしれない

たまたま携わったイベントが上手くいったからのぼせ上がっているだけなのかもですが、コミュニティ/イベント運営のこと、好き…かもしれない…です。

やる前は「めちゃくちゃ面倒くさそう」で「やっている人に感謝しなきゃ」ぐらいの気持ちだったのですがいざやってみるとやっている側の楽しみもあることに気づきました。

コミュニティやイベントを提供する人の元にこそ人や知見や繋がりが集まってくるのは、勉強会の類で登壇した人が多くを得るのと似ているなぁ、と。

プレゼンはやっぱり苦手

はい。引き続き自分にあったやり方を模索していきます。

これから

折れない心、または自己修復力

筆が乗っているうちに良い話ばかり書いてしまったのですがアウトプットを通じたつらいこともありました。

資料準備などで追い込まれてストレスになったり、可処分時間がなくなったり、プレゼンで話した内容の理解があいまいで質問にうまく答えられなかったり、滑ったり、主催したイベントを無断キャンセルされたり*7、絶対流行ると思ったアイデアが見向きもされなかったり。

そういう時は結構オチて何もしたくなくなるのですが「半年間はやる」と決めて退路を断ったのでなんとか発破をかけながらやれました。タイトルにある「自分を騙しながら」というのはそういうことです。

自身の力でコントロールできることであれば「ある種の後悔は取り戻すことができる」という気持ちでやっていくしかない。コントロールできないものは割り切る

もしくは、成功体験・良かったときのことをイメージしたり、同じコミュニティで繋がった人を見て受ける刺激で再起したりする。

そういうメンタリティを持ったレジリエンス人材になりたいです。

ペースダウン

上半期はアウトプットするマイルストーンを置きつつ締切駆動×不安駆動でがむしゃらにやったのでちょっと疲れました

短期的には走りながら考える体力が身に付いたというメリットもありますが、少しペースダウンして長期的に持続可能なスタイルを模索したいです。*8


引き続き、エモいポエムはほどほどに、サステイナブルで高レジリエンスにやっていきます。

*1:「漫画に影響された」と書くと途端に信憑性が落ちる類のものごとがあるのは理解していますが、それはそうと『医龍』は本当に面白いので未読の方は是非読んでみてください。

*2:「理想とは何」という話は長くなるので省略します

*3:無論、成長意欲を高く保てて頑張れる人もいるが…少なくとも自分は違う

*4:他にも尖っている言語を書いていたりとか、すごそうなorganizationに入っているとか、いろいろ

*5:その他にも、iOSDC, builderscon あたりの big events はやはり運営の努力と技術が凄いと感じています

*6:STEEL BALL RUN

*7:まぁ、よくあることなんですが、主催側で体験するとまた違ったショック

*8:と言いつつこのブログと並行して CfP を書いている

Meguro.rb#19で『決済のトランザクション管理術』というタイトルでLTをしました

第19回 Meguro.rb に参加し、『決済のトランザクション管理術』というタイトルでLTをしました。

言い足りないことと反省

うーん、5分LTでやる内容じゃなかったかもしれないなぁと思っている。

だいぶ早口でザーッと喋ってようやく決済機能の開発に親しんでいる人に「わかる〜」と言ってもらえる内容だった。が、本当に聞いてほしかった対象はもう少し決済機能の開発経験が浅い方であり、そういう方にはもっと詳細な説明が必要で、そうすると10分は少なくとも必要になってしまう…と葛藤した。

たとえばベースとなったクレジットカード決済のシーケンス図を丁寧に追っていくとか、そもそも決済ゲートウェイって何?みたいな話からするとか。*1

f:id:ohbarye:20180929234239p:plain

葛藤しながら結局早巻きになってしまったのが反省。

Meguro.rb

自分にとっては、色んなところで見知った方々がなんだか多く集まった回だったような気がしていて、終わった後も話し足りないな〜と感じた。

初めて行ったのは第15回でそのときは知らない方だらけで心細かった。それがこの数ヶ月でこんな風に変化したことに思うところがあり、以下のツイートに繋がる。

Quipperによるスポンサー

今回はQuipperによる初めてのMeguro.rbスポンサー回だった。

※スポンサリングの裏側については別の機会で触れそうな気がするのでここでは省略

僕がオーガナイザーの皆さんから声をかけられてスポンサーを買って出たのだが、会場設営・食事準備・司会その他諸々に至るまでQuipper社員の圧倒的当事者意識でサクサクと事が進んでしまった!!

イベントに貢献したのはゲストにトルティーヤを巻いたことぐらいだ


引き続きやっていきます

*1:そのへんの話はサブスクリプションサービスにおけるIn-App Purchase再考では丁寧にやったので興味ある方はそちらを参照

ISUCON8にチーム"sayotan"で参加し、予選落ち (Best Score: 23,553, 最終結果: fail) でした

もう2週間も前のことというのに驚きつつ、ISUCON8に出場して予選敗退した記録。来年に向けたメモ。

チーム編成

メンバーは2人で、両名とも「ふだんやらないことをやりたい」という動機で初参加した。

  • @RyotaKatoh
    • 機械学習エンジニア
    • GoによるWebアプリも書ける
    • Webアプリをチューニングするようなのは「ふだんやらないこと」なのでアプリのコード変更をやることに
  • @ohbarye
    • Webエンジニア
    • Ruby on RailsによるWebアプリ、ReactなどによるSPAがメイン業務
    • Golangやインフラまわりは「ふだんやらないこと」なのでh2oやmariadbを見ることに
      • Golang力は、前日までにTour of Goを流し読みした程度

選択言語はGolang

チーム名 sayotan は参加できなかった第三のメンバー名から。

結果

さきに結果を書くとBest Score: 23,553終結果: fail (fail前 20,304) だった。

f:id:ohbarye:20180929151448p:plain

得点が跳ね上がってから不安定になったのは認識していたものの、最後のベンチマーカ実行で pass していたので再起動試験の結果が発表されるまで自分たちが fail で終わっているとは気づかなかった…。

f:id:ohbarye:20180929151450p:plain

f:id:ohbarye:20180929151453p:plain

経過

主に自分の視点で思い出しつつ書いてみる

  • まずsshでつなぐ
  • RyotaKatoh がtable schemaを出してくれた
  • マシンのスペック(CPU, メモリ)確認したりした
  • とりあえずベンチマーカ実行してみた
    • どのぐらいかかるのかと思ったら1分強で終わった

f:id:ohbarye:20180929151502p:plain

  • top

    • mysqldのほうが頑張っているなーと理解
  • ちゃんとボトルネックを特定しながらやっていくかーと思ったが計測ツールを調べてこなかった情弱ぶる

  • ググりながらmysqlslowdumpを試す
    • 一番時間かかっているやつ、一番ロックしているやつをつぶす
    • indexいくつか増やしたがこの時点ではあまり影響なかった
  • RyotaKatohはコードリーディングしてN+1に気付いたりしていたと思う
  • デプロイの自動化はやらず、git pullで頑張ることにした
    • 2人なので声かけながらやれば大丈夫そう

午前は得点への貢献が特になかった。


午後

  • h2oの設定を見る
    • 静的ファイルの配信はちゃんとh2oがやってくれていた
  • access logをshellで整形
    • 静的ファイルへのアクセスがあまりないのでここは頑張ってもしょうがないかなと理解
    • reports系はそこそこだけど一発がおもそう
      • データをメモリをロードしまくっているが削ったりはできなさそう
      • for updateは要らなさそうなのでけずった
  • RyotaKatohがget_eventのN+1を解消、SQL一発で解決するようにすることでscoreが跳ね上がり、20,000点を超えるようになる
    • しかし性能があがるとテストケースが変わって(?)failするようになる
  • 複数台構成を諦める
    • 午前は複数台に挑戦するつもりだったが、1台で頑張れるところまで頑張れるかー、となった
    • 戦略的にやったわけではないが、結果として/initの罠にはまらなくてよかった
  • ログイン周りのアクセスが多かったのでsha2による暗号化とかを効率化しようとした
    • しかしGolang力が足りず結局revert

f:id:ohbarye:20180929151459p:plain

感想

書き出してみると「8時間近くあったのにこれしかやってないの…?」感がすごい。また、基本的な予習がまったく足りていなかったことを終わってから後悔した。

逆に言えばきちんと対策をして基本的な計測ツールの使い方やボトルネックの特定のしかたを理解したり、戦略的な進行管理ができればもっといけたかもしれない、という希望も持てた。

また、自分が力を発揮できそうなWebアプリ周りを今回はほぼやらなかったのでその辺でどれぐらいできるかも試してみたくなった。

来年もふだんやらないことをやるために出場してみるか〜

余談

f:id:ohbarye:20180929154809j:plain

誰がジュニアを育てるのか -出題編-

過熱する採用市場の盛り上がりにあわせて感じたことについて言語化を試みているが未だ納得解が得られずにいる。書きかけの Scrapbox は随時更新していくとして、現時点での dump をとっておく。

誰がジュニアを育てるのか - ohbarye

主にソフトウェアエンジニア採用の文脈で「誰がジュニアを育てるのか」ということについて。

f:id:ohbarye:20180929013900p:plain *1

「優秀な人間だけを採る」という採用戦略

著名テック企業が自社の採用戦略について語った本が出版されるたびに話題になる中で「優秀な人間だけを採る」というのが採用戦略として認知されるようになってきたのを感じる。Netflixの最強人事戦略Work Rules!あたりが代表的…かどうかは知らないがあくまで自分が読んだ中の代表。世には同じことを謳う書籍や記事がもっとたくさんあるかもしれない。

※「優秀」という言葉を定義するのは難しく、そしてまた常に相対的なものだが、わかりやすくするために「在職者と並べた時に上位50%に入るスキルを持つ人」はその企業にとって「優秀な人」としておく。

この採用戦略はいち企業としての成功を追い求めるうえで圧倒的に正しい*2。人材育成に投資する余裕のないスタートアップであれば尚更そうせざるを得ないというのは誰でも合点がいくところだと思う。

局所的な正しさ

正しい、とはいえ採用市場にて大多数の企業がこの戦略を選択すると、この定義において優秀でない人間を雇用する企業が減る。言い換えれば就職先がなくなる。この定義において優秀でない人間とは、新卒や第二新卒、またはキャリアチェンジして業界に参入するキャリアが浅いエンジニアなどだ。長いので"ジュニア"と呼称することにする*3

優秀であればキャリアに関係なく採用される、というのはわかる。だが「在職者と並べた時に上位50%に入るスキルを持つ」のはごく一握りで9割8分ぐらい*4のジュニアはあてはまらない。

彼/彼女らの就職先がなくならないにしても「優秀な人間だけを採る」戦略をとり、その恩恵を享受するような企業や環境では働けない。そこで起きるのは、優秀な同僚と一緒であれば成長したであろう人の芽が出ずに終わってしまうという問題*5や、優秀な同僚と働きたいのであれば相対的に劣るかもしれない環境の中で自ら成長して優秀にならなければいけないという問題だ。

スタートラインからビハインドしている者がこうした努力と転職を繰り返すことで初めて求めていた職場にたどり着くことはもちろん不可能ではない…不可能ではないが、厳しい。

誰がジュニアを育てるのか?

前置きが長かったものの、誰がジュニアを育てるのか?それが問題だ。

ジュニアの受け皿になる企業は教育コストを支払うだけ支払って彼/彼女が成長した折に"卒業"されてしまうのか。

教育コストを払いたくない企業が生む"ババ抜き"になってしまわないか。

さらに長期的に見ると、優秀だったエンジニアたちが定年を迎える頃には後輩が誰も育っていない、なんてことにはならないか。中途で問題に気づいて新たな解決策が出てくるか。

まだまだ勉強不足なので自分の観測範囲では納得解が得られていない。もしかすると歴史ある他業界や他職種では既に起こったことなのかもしれない。

引き続き考え続けていく。


「優秀な人間だけを採る」に乗らない

別の観点で、「優秀な人間だけを採る」戦略に乗らないことで得られるメリットも存在するという話。

ジュニアを採用することで一時的に平均的なレベルが低下するがそれを許容してでも得られるものはあるのかもしれない。それまで荒野だったオンボーディングが整備されたり、チームで技術力を向上させる仕組みを作る方向に向かったり、Engineering Manager や Tech Lead を志向する社員にメンターの機会を与えたり。

これらのことはジュニアを採らずともできるものではあるが、より強く必要性を認識させる手っ取り早い手段にはなりそう。


引用

以下、記憶にあって探せたものからの引用

Netflixの人事制度

経営陣が従業員のためにできる最善のことは、一緒に働く同僚にハイパフォーマーだけを採用することだと学んだ。これはテーブルサッカーの台を設置したり、無料で寿司を提供したり、莫大な契約ボーナスやストックオプションを与えたりするよりずっと優れた従業員特典だ。

Work Rules!

採用の質で妥協することは、間違いにほかならない。間違った採用は有毒だ。本人のパフォーマンスが損なわれるだけでなく、周囲のパフォーマンスとモラルと活力を堕落させる。


自分より優秀な人だけを採用する


10 人の新規採用者のうち 9 人が自分より優秀なら、採用はうまくいっている。


たとえば大学生を評価するなら、GPAの点数は考慮すべきかなり重要な要素だと思えるかもしれない。だが、日本からの応募者に関してはそうでもない。日本では大学への入学は主として全国的なテストの結果で決まる。そのため、高校生はそのテストで好成績をあげることに注力し、数年にわたって毎週 15 から 20 時間も塾に通うことが多い。しかし、いったん一流大学に入ってしまうと、成績をまったく気にしない。歴史的に、日本の大学生は塾での鬱々とした時間と「サラリーマン」(過去の日本に特有の年功序列と終身雇用を土台とするキャリアを示す用語)生活の単調さとの狭間で、遊びと自由という最後のあがきにふける。日本の大学の成績は採用データとしては実質的に意味がないが、どこの大学に通っていたかを知ることは、少なくとも新卒者の採用については役に立つ。

クックパッド

日雇い労働者だった赤髪エンジニアがクックパッド技術部長になるまでのストーリーより

その人が入ると、クックパッドのエンジニアの技術力の平均が上がるということを求めてます。


すごくわかりやすく技術力を数字で表わすと……いや、そんな単純じゃないのはわかっていますが、説明のために数字で表わすと、いまのエンジニアの平均値が5だとしますよね。

そこに「いまどうしても人が足りなくて・・・」と、4.5の人を入れる。すると平均は4.83。5と5と4.5。そこにもう一人5を入れても4.87。5に戻らないので、レベルが下がります。

*1:いらすとやより https://www.irasutoya.com/2015/03/blog-post_53.html

*2:なぜ正しいかは上述の本を読むと書いてある

*3:著名テック企業にもジュニアという肩書があるのは知っているがそれは業界全体で見たら優秀層なので例外的とする

*4:要出典

*5:その才覚を見抜くのも採用テクかもしれないが、在職者と並べた時に上位50%に入るスキルを持っていないから入れない、としておく

Engineering Manager Meetup #1 をやりました #em_meetup

Engineering Manager Meetup をやります - valid,invalidで宣言した通り Engineering Manager Meetup #1 をやりました。本記事では感想と振り返りを、イベント運営者と参加者の両視点から忘れないうちに記しておきたいと思います。

connpass.com

本記事の主な想定対象読者はイベントに参加されなかった方です。#em_meetup ハッシュタグ を目にして興味が湧いた方や、Engineering Manager Slack に入っているがイベントには来られなかった方々に""現場の様子""をお伝えするのが目的です。

(参加された方にとっては既知のことばかりかもしれませんが、イベントを追体験したり主催者の思考をのぞき見することで楽しめる可能性があります)

3行で要約すると

気づいたら6,000字以上も書きなぐっていたので要約しました。

  • Engineerng Manage(r|ment) に関心と情熱がある人は少なからずおり"需要"があるとわかった
  • 圧倒的当事者意識を持って参加してくださった皆さんが出会って"何か"が生まれた
  • 早速フィードバックを貰えて"情熱"が伝播したので第2回開催を決めた

Engineering Manager Meetup とは?

イベント開催の動機や趣旨については Engineering Manager Meetup をやります - valid,invalid をご参照ください。

当日のようす

当日のようすです。写真上の文字は各テーブルで話し合われていたテーマです。

f:id:ohbarye:20180926231722p:plain f:id:ohbarye:20180926231727p:plain f:id:ohbarye:20180926231733p:plain

OST形式の魔力

今回のイベントではゲストによるトークやプレゼンは抜きでOST(オープンスペーステクノロジー)形式でのセッションを2回行いました。

オープンスペースは「興味関心の拠り所は明確だが誰もその問題について正解や答えを知らない」chaotic な問題に向き合うのに適したディスカッション形式です。*1

オープンスペースとは、各自が喋りたいテーマを持ち寄り、その中からテーマと進行役(セッションオーナー)を選出し、各グループに分かれて自由に発表、議論、雑談などを行うイベント形式です。

セッションオーナーはあくまで進行役、その時間の枠で何をするかを決めるだけで、そのテーマについて必ずしも詳しい必要はありません。

https://www.meetup.com/ja-JP/GraphQL-Tokyo/events/251782724/ より

この形式を選んだ理由は以下です。

  • 「Engineering Manager」というロール自体が不明瞭であったり、付随する周辺課題についても唯一解がないものばかりなので、そんなテーマたちを話し合うために優れた形式だと考えた
  • 参加者同士が関心を持つ事柄について話し合い、共感したり意見を交わし合うことで横の繋がりを生みたかった
  • イベント全体でのインプット・アウトプットの総和を最大化したかった

振り返ってみてもこの形式を選んで良かったと思っていますが、OSTが成功するか否かは何よりも参加者の姿勢に依存するので、圧倒的当事者意識を持って参加してくれた皆さんに改めて感謝です。

オープンスペースのメリットをまとめると

  • 主体的であることにインセンティブがある
    • セッションオーナーになれば自分の聞きたいことが聞ける、話したいことが話せる
    • セッションオーナーだからといって問題に詳しい必要がない
    • 主体的になればなるほど多くを得ることができる
  • 参加者全員に主体的な参加を促すことができる(運営者視点)
    • 話を聞きに来ただけ、という人には向かない
  • プレゼン準備が必要なくて楽 ;-)(運営者視点)

参加した人にのみわかる熱気のようなライブ感にも似た良さがある一方、デメリットを挙げるとすれば

  • 未経験の方に良さが伝わりづらい
    • 参加者の中にはOST未経験の方も少なからずいたのですが、終了後には「この形式初めてやったけどいいですね」というフィードバックをいただきました
  • 発表資料が残るわけではないのでイベント終了後に拡散しづらい(運営者視点)
    • 皆さんの tweet や blog や口コミで広めていただくほかない
  • テーマがなかなか挙がらないこともあるので仕込みはあった方が安心(運営者視点)

という感じです。

いずれ劣らぬテーマたち

以下のテーマについてそれぞれのグループに分かれて30分ずつディスカッションをし、各グループ2分ずつ発表して共有する、という形で進めました。

  • 目標管理・評価制度
  • 『エンジニアリング組織論への招待』について広木さんと語る
  • Engineering manager とは何者
  • 1-on-1のやりかた
  • managerのキャリアパス
  • 採用・ブランディング
  • 給与
  • チームビルディング
  • Engineering Manager の魅力を伝えるには

@cobasparxxx さんの tweet にあるように、全てのテーマが魅力的で参加するグループを選ぶのに本当に、本当に悩みました。。

参加者の感想ツイートもセルフでトゥギャり、参加しなかったグループの雰囲気の一端を味わおうとしました。@dskst9 さんがアップロードしてくれたホワイトボードから"何か"が伝わるかもしれません。

togetter.com

イベント参加者として

「Engineering manager とは何者」→「給与」それぞれのセッションに参加しました。

Engineering manager とは何者

実に本質的な問いすぎて頭がクラクラするのですが、他社における定義や責任範囲を聞くことで改めて多義性・曖昧性があるなぁと実感しました。それでもぼんやりと共通項みたいなものが見えてきており、広木さんの tweet がその辺を絶妙に突いてくれていました。(ちなみに広木さんはこのテーブルにはいなかったw)

給与

インターネットに残せない話が出ました、それだけで大満足です。

書けることの中で興味深かったのは、給与という切り口一つから初めても色んな周辺の問題を議論できるんだな、ということでした。「Engineering Managerは給与を決定する"権限"を持つのか」「"採用"(オファー金額)にどう関わるか」「"評価"への納得感と給与への納得感は一致しない」「"1-on-1" で給与に関する本音を引き出す」などなど。

Engineering Manager の魅力を伝えるには

こちらのセッションには参加できなかったものの実に興味深いテーマでした。

感想ツイートに並ぶ「エンジニアリングマネージャも人間である」がヒットしている様子を見るに、皆さんはふだん人間と思われていなくて辛い思いをしている可能性が濃厚になってきました。

こうした雰囲気が続くとエンジニアリングマネージャを誰もやりたがらなくなってしまう。だからこそ楽しさも伝えていったほうが良いはずだという流れから、何やらこのイベントをきっかけにすごい"戦闘潮流-ムーブメント-"が生まれそうです。

f:id:ohbarye:20180926105637p:plain

イベント運営者として

まずは終わってほっとしました。

イベント運営の知見がないために至らないところが多々あったかと思いますが、 圧倒的当事者意識のある皆さんのおかげでなんとかなったところが多分にあると思います。

特に@dskst9 さんを始めとしたアスクル社の皆さんは会場提供のみならず受付・設営・ホワイトボードや文房具の準備など本当にありがとうございます。セッションが始まった瞬間に何も言わずとも皆さんがホワイトボードを活用し始めたのを見て勝利を確信しました。

第2回

濃度の高い方々(第1回に参加してさっそく第2回を望む方と、今回参加できなかった方)だけで相当数集まることがわかったので第2回も企画します。ご期待ください。

余談

イベント関連の知見、というかメモみたいなものを貼っておきます。

参加者数

  • 申し込み 76名
  • キャンセル 35名
  • 実際の参加者 27名

connpass の統計ページで見ると、公開直後と増枠のタイミングで波ができています。

f:id:ohbarye:20180926111001p:plain

(イベントでの集客のコツはこまめな増枠で波を作ること、というのを広木さんから聞いた。あと少しで定員という状況を作ると申し込みしたくなる心理)

当日のキャンセルが22名ぐらいあってドキドキしたが初心に帰って"濃度"を意識しました。

事前の仕込み

大きく2つやってみました。

Engineering Manager Slack

Engineering Manager Slack を作って事前に参加者同士の繋がりを作ろうとしました。

これはかなり良かったと思っていて、おかげでイベント参加前からすでに"エンジンが暖まっている"人々を集めることに成功しました。「この人たちが参加してくれるなら無限に安心だ」という心持ちになりました。(まぁ、そのうちの何名かは参加できなかったのですが…次回に期待!)

イベント会場にて「Slackでお見かけした○○さんですね?」みたいな会話が偶発的に生まれたときの「あ、"オフ会"…!?」という感動的瞬間もありました。

一方でSlackに参加されずに来場された方もいたと思うのでそうした方々から見た時に内輪っぽい感じになるというか、"クラスのLINEグループに自分だけ招待されてない"時みたいな気持ちになってほしくはなかったのでSlack上で起きた会話を前提とした進め方は極力避けました。(もし出てしまっていたらすみません)

また、有志4人による先行オフ会が行われたのも非常に良かったです。そのときの異常な""濃度""はそのままイベントにも引き継がれました。

Topic bucket

当日話すテーマが挙がらなかったときのために Topic bucket sheet を用意して事前に書き込んでもらおうとしました。

こちらはいまいちで、内容を見れば分かる通りなのですが僕がSlackの雑談の中でちょくちょく上がっていたトピックを転記したのがほとんどです。これは単純にあまり集まらなかったからです。

雑談の中で諸々出てきていたので「ネタはあった」「しかし書き込まれなかった」というのが実態だと思い、書き込むハードルがやや高かった or 導線が悪かったと反省してます。

横の繋がりをつくる

もともと予定にはなかったのですが、終了間際に参加者の皆さんにSNSアカウントや名刺を交換する時間を設けました。

人間だと思われていない者たちが抱えている孤独を分かち合ったからこそ生まれた"何か"があった、そしてこれから生まれる"何か"があると信じます。(何か言っているようで何も言っていない文)

その他の反省と改善点

  • ohbaryeの会場到着が18:57と開始3分前で余裕がなかった
    • テーブル割りとかを事前にチェックしておけばよかった
  • 司会進行・タイムキーパーあたりを同時にやるとけっこうきつい
  • 途中参加した方に対するフォローがなかった
    • それぞれのグループにぬるっと紛れ込んでもらうほかなかった
  • 飲食物の提供がなかった(個人のイベントなので省エネでやった)
    • 食べながらの議論は難しいので食料は無くても良かったが、よく喋るイベントなので飲み物は用意しても良かった
  • スライドを投影していたohbaryeのPCの電源が途中で落ちた
    • いろいろ慌ててしまったが参加者の方の機転で助かった
  • 各セッションのアウトプットを良い感じに共有できる仕組みがほしい
    • 2分間の発表でも伝わるものはあったが、それをストック情報にしたい
    • 口頭で「ブログや tweet で今日の input / output を教えてください!」と呼びかけてはみたがスマートではない
  • イベント運営に気を揉んだために100%ディスカッションに集中できなかった
    • セッションオーナーへの立候補も自重し、ある意味""サーヴァント""していた
    • イベント片手に回しながらセッションオーナーも余裕を持ってできるぐらいになりたい
  • ohbaryeが名刺を切らしてしまった
  • OSTのあとに懇親会をやりたい(めっちゃ盛り上がりそう)

長々6,700字も書きましたがとにかく楽しかったので優勝です。

はてなブックマーク側でタイトルやサムネイルが残念だったときの修正方法

具体例

f:id:ohbarye:20180902231427p:plain

f:id:ohbarye:20180902231456p:plain

あとは、サムネイルを貼り忘れたり意図しない画像がサムネイルになったりして困ることもよくある。

修正方法

http://b.hatena.ne.jp/entry/s/:url のページに行く。

この次がめちゃくちゃわかりにくいのだが、記事タイトルの枠の右上にマウスを持っていく。すると「適切な情報に変更」という tooltip と編集アイコンが現れる。

f:id:ohbarye:20180902231710p:plain

クリックすると以下のモーダルが現れるのでタイトルを修正することができる。

なお、この操作はブックマークをしたユーザーであれば誰でも行えるようだ。

f:id:ohbarye:20180902231902p:plain

サムネイルを更新したい場合はブログ記事を更新したのち、このモーダルの左下にある「情報を更新する」をクリックする。数分から数十分で最新の情報を取得してくれる。

なお、この操作はブックマーク先のページのオーナーでないと行えない、らしい。(オーナーという概念をよくわかっていないが)ログインしているユーザーのはてなブログでないと行えないようだ。

#iOSDC で『サブスクリプションサービスにおけるIn-App Purchase再考』という発表をしてきました

iOSDC 2018 に参加しています。また、3日目の9/1に『サブスクリプションサービスにおけるIn-App Purchase再考』という発表をしました。

iosdc.jp

発表

資料

サーバサイドエンジニアとして In-App Purchase (IAP) とその他の決済手段を開発・運用してきた経験をもとに IAP を考えなおす、という内容です。

今回は比較する軸を「決済ゲートウェイ」としました。

決済ゲートウェイとしての機能・性能・サービス・サポート面においてAppStoreを選ぶことにはどのようなメリット・デメリットがあるのか。また、IAPを選択する前、運用する中ではどのようなことを考慮しなければいけないのか。これらの観点について考えてみました。

15分で63枚というボリュームになってしまったので発表では以下を省略しました。気になる方は資料でご確認ください。

  • 開発〜テストまわりの比較
  • 運用における加盟店サポートの比較

反応

気になったのでセルフまとめ

togetter.com

反応見たところ明らかな間違いもなかった…はず。そのうえで共感ありつつ聴衆の埒外からの知見も共有できたみたいで良かったです。感想を呟いてフィードバックをいただけるのは本当にありがたいです。

準備について

3回ほど通しで練習してみた経緯が以下です

23分→18分→15分

かなり巻いたのに23分かかった初回で絶望し、内容を削ることを決めました。とはいえ調査したことや大事な補足を削ってしまうと資料価値が薄れると思ったので、Google Slides の機能でスライドを残したまま非表示にするようにしました。

発表にあたって挑戦してみたこと

朝イチの発表、大学の薄暗い大教室、100人近い聴衆が各々のPCを見つめて待機している… という状況で自分の出番を待つのが耐えきれませんでした。なのでトークの頭で話そうと思っていたアイスブレイク的な話題を開始前にしました。

具体的には発表で使った Logicool Spotlight をデモ的に紹介し、「おお〜」という声が一斉に上がったのは嬉しかったです。

これを使うことで壇上を自由に動いたダイナミックなトークができた(かもしれない)。持っててよかった Logicool Spotlight。

iOSDC

全体を通じてトークテーマの幅が広く、新しいものを取り入れたり新しい人を取り込んだりすることに非常に好意的であるという印象を受けました。

自分も iOS のことやコミュニティのことはまったくわかっていなかったのですが、勢いで申し込んだCFPが通ったのでけっこう驚きました。

相互コミュニケーションを推奨/実践しててすごい

発表者にフィードバックを促すように運営の方が仰っており、実際に参加者の方がそのように動いているのに感銘を受けました。

自分も発表に対していくつも質問をいただいたり、発表後に用意された Ask The Speaker テーブルに追加の質問・議論をしたい方が訪れたり、非常に双方向的なコミュニケーションができて良かったです。(発表前に登壇者に向けてスタッフから「質問を受けたら必ず復唱をお願いします」という気遣いがあったのも Good)

ホスピタリティがすごい

参加者が過ごしやすい環境が揃っていました。

  • ノベルティがすごい
  • ランチがすごい
  • コーヒー提供がすごい
  • Wifi、電源の充実がすごい

出る前はアウェイだろうな〜と思っていましたが開催者の長谷川さんからもフォローいただけてそこからも"ホスピタリティ"を感じました。

自分がイベントを開催するときにも参考にしたいことが沢山あった。

会場がすごい

疲れたときに座れる場所があってすごい

理工キャンパスがかっこいい

緒方恵美さんがすごい

緒方恵美さんがすごい

www.youtube.com


ということで、開催前はけっこうナーバスになっていたものの発表/参加して良かったな〜という気持ちになりました。運営の皆さん本当にお疲れ様です。