valid,invalid

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

マネジメントスタイルの選択基準、一貫的スタイルを持つことの困難

Engineering Manager Engineering

マネジメントスタイルは対象となるメンバーだけでなく、時々の状況や幾つかの要因によって変えるべきものだという話です。

本記事は『HIGH OUTPUT MANAGEMENT』を読んだうえで自分の観測範囲と経験に照らし合わせた感想なので、詳細が気になる方は同書の第12章を読むことをおすすめします。

続きを読む

Node学園祭 #nodefest で『貢献できるOSSの見つけ方 -完結編-』という発表をしてきました

OSS Node.js

最後*1のNode学園祭で『How to find "Good First Issues" / 貢献できるOSSの見つけ方 -完結編-』という発表をしてきました。

発表

半年間、自分を騙しながらアウトプットに積極的になってみた - valid,invalid に書いたように今年はこれまでより一層アウトプットを意識した年で、そのアウトプットの少なくない割合を占めた OSS Contribution において遭遇した課題とそれをどのように乗り越えたかを中心に話しました。その過程で作った goofi というアプリケーションの話も盛り込みました。

github.com

資料

所感など

はじめての30分枠

まず30分枠の発表は初めてだったのでまずはそのあたりから。

最初に思ったのは、何よりも流れが大事で、課題設定とその共有に失敗すると30分空振りし続ける羽目になるだろうということ。流れさえちゃんと用意できていれば途中である程度時間をコントロールでき、時間の余裕が落ち着いて話すことに繋がると感じました。これは5分LTや10分だと難しいかなと。

早期練習（しなさい）

ただ、資料を作っただけでは所要時間が読めないのでとにかく練習が大事…そんなことはやる前からわかっていたものの、一回の練習に30分かかるので腰が重いという問題がありました。放って置くとやらないまま直前を迎えそうだったので、初めての通し練習（＋2回目）は同僚に聴衆役をお願いすることにし、予めスケジュールに入れました。

最後の最後にレビューをお願いするのではなく1回目の練習からフィードバックを貰ったおかげで軌道修正が早期に行えて最高でした。このあたりは以下の記事で書いたテクニックです。

quipper.hatenablog.com

Node学園祭について

自分の出番までは完全に精神が終わっていました。

唯一楽しめたのは紀尾井タワー2階のランチというザマです。

面白そうなセッションがいっぱいあったのでこれは本当に勿体なかった。

最後に

資料を作りながらなんとなく今回の発表が今年の集大成のような気がしていました。時期もやり方もばらばらだった自分の過去のアウトプット (pull requests、コード、ブログ、思想、アイデア) を集めているうちに点と点が繋がる感触がありました。

そう思っているとなんと発表練習を聞いた同僚から「全体的にohbaryeさんの今年の全てが詰まっている感じがして他人事ながら勝手に感極まるものがあった」というフィードバックがあり、僕もまた感極まってました。

そんな感極まりループの外でこんなこともありました。

アウトプット疲れも少なからずあるのですが、別ベクトルの活動の点が繋がってくるような体験を経てやはり今は射撃しつつ前進するしかないのだという気持ちを新たにできて良かったです。

今年の残る活動機会は Engineering Manager Meetup #3 ぐらいかと思いますが最後まで走り抜けたいと思います。 ウオーッ

*1:https://twitter.com/yosuke_furukawa/status/1066336557085282304

Engineering Manager Meetup #2 をやりました & 第3回の告知 #em_meetup

Engineering Manager

Engineering Manager Meetup #2 を開催しました。

engineering-manager-meetup.connpass.com

前回は開催直後に熱と勢いだけで6,744字の雑文を書いてしまったので、今回は開催から約2週間経ってクールダウンした状態で振り返り記事を書いてみました。結果なんと5,044字に収まり、約25%の削減に成功です。

@aomoriringoさんにより振る舞われた至高のハム

3行まとめ

  • 第1回に引き続き盛り上がりを見せたことで再現性があるとわかった
  • 回を重ねることやBYOB*1など、主体的参加を促す工夫ができそう
  • 第3回はプレゼンありの形式でやります。2018-12-14(金) connpass ページはこちらです

Engineering Manager Meetup とは?

イベント開催の動機や趣旨については Engineering Manager Meetup をやります - valid,invalid を、第1回のようすについては Engineering Manager Meetup #1 をやりました #em_meetup - valid,invalid をご参照ください。

当日のようす

@beppu01 さんがまとめてくださった togetter や、参加者の皆さんによるブログをシュッと貼っておきます。

togetter.com

書いてくださった皆さん、本当にありがとうございます！（漏れていたら申し訳ありません、お伝えいただければシュッと足します）

OST再考

第1回と同じくOST（オープンスペーステクノロジー）でのディスカッションを採用しました。OSTをご存知無い方は OST（オープン・スペース・テクノロジー）｜キーワード｜HUMAN VALUE をご参照ください。

さて、第1回にて同方式を実施した結果が掛け値なしに最高だったわけですが、果たしてその結果に再現性があるのかどうか。その疑問に答えるためにEngineering Manager Meetup第2回もOSTを採用しました。

結論から言うなれば、再現性は有り寄りの有りでした。

「OSTは何について話し合うのかを参加者主導で決めるうえに、ファシリテーションも何もかもが参加者に委ねられています。なのでこの会が有意義なものになるかどうかは皆さん次第です」

この前説を毎度しておりますがこれは本当にその通りで、Engineering Managementやその周辺領域に関心や情熱があり、互いに意見を交わしたりファシリテーションをいとわない方が集まった時点で結果が約束されました。

印象に残った話

Engineering Managerをどう育てるか

@otoyo0122さんがファシリテーターとなったテーマ。こちらに僕も参加しました。

EM.FMでも語られていた話題だったのでpodcastをオススメしつつ、Engineering Managerが何をやっているのか、何が楽しいのかを伝えないことには始まらんなという話をしました。

とはいえ、技術の話をするのと全く同じように語るわけにもいかないよな、という指摘も出ました。特に"失敗談"。ポストモーテムとして語られることにとても価値がある一方、チームやメンバーの話をする場合それを聞いた当事者がどう思うかに気を配る必要があったり。（解決したならまだしも、「ローパフォーマーに困っている」「チームの雰囲気が悪い」みたいな現在進行系の話だと余計にきつそう）

Engineering Managementの話題は人に関わるセンシティブなところがあるので一歩間違えたりすると特定の人を傷つけたりするおそれがある。そのために気後れしている部分も少なからずあるのではないか、という雑談で悩み相談みたいなことができたのも良かった。

また、マネージャとしてのオンボーディングにも話が移り、「あなたは○月✗日からマネージャです、特にトレーニングも支援もないけどがんばりましょう！」みたいなやり方で成功すると思っているとしたら正気でないという突っ込み。社内に先達がいないのならマネージャ研修やコンサルタント・技術顧問登用などを使ってでもEngineering Managerの立ち上がりはしっかりサポートすることが大事。

エンジニアリングマネジメントの勉強法

このセッションに参加された@progrhymeさんのブログから引用します。

このトピックには私を含め5名の人々が集まったのですが、どうやら私のように「エンジニアリングマネジメントを学びたい」という人が多く集まったようです。 どの人もマネージャーになって1年未満ということでした。

勉強法としては以下のような方法が挙げられました:

  • 結論 「EM Meetupに来続ける」

😂

まぁーーーーーー、そうなんですよねぇ…！

僕の周囲もお手本みたいなものがあったわけでも人に教わったわけでもなく、どうにかして「知ってる人に聞いてみたい」という思いでEngineering Manager Meetupを始めたのでした。OSTを選んだのも自分が聞きたいことを知っている（かつ情熱がある）人に聞けるから、です。

おかげで色んな情報が入ってくるようになりはしましたが唯一解の存在しない問題ばかりなので、今でも射撃しつつ前進中です。

お前ら（Engineering Manager）の転職

お前らというか俺たちなのでは…ｗ

このセッションには不参加だったのですが、@aomoriringoさんが書いてくれた模造紙にはすごくわかりが深いワードがならんでいます。

詳しくはEngineering Manager Meetup #2に飛び込んできた。 - どこぞのエンジニアなマネージャーだった人のブログ。をどうぞ。

Engieering Managerもしくはそれに近いポジションでやっている業務が果たしてポータブルスキルなんだろうか〜という話があったが、自分の最近の考えはこんな感じ：

だし、それがポータブルなものになるかどうかは、月並みながら自分次第と捉えている。（が、同じジョブタイトルでもおそらくぜんぜんやっていることが異なる可能性がある…例えばめちゃめちゃ社内政治とかをメインにやっている人とは抱えているものが違う）

「マネージャをやめてプレイヤーに戻りたくて…」と言って門戸を叩く人はいるが「マネジメントをやりたくて！」と言いながら来てくれる人がいない問題。採用をやっている中でもこれはよく聞くところだが、掘り下げると各々が携わっている"マネジメント"にはとてもばらつきがある。そこを見逃すと噛み合わなくなりそうだな〜と思ったり。

その他にもいろいろ触れたいテーマはあるのですが長くなりすぎるのでこのあたりで。

総評・運営反省

前回の“”経験者“”がテーブルのファシリテーション等でリードしたり、BYOB (Bring Your Own Beer) スタイルで「飲み食いしたいものは各自持参」としたことで参加者がイベントを作っている感じが出ていたように見えました（途中の買い出しとかは文化祭ぽかった）。おかげでこのイベントでなら開示して大丈夫だという“”心理的安全性“”が醸成され、前回を上回るような“”"熱い“”"テーマが多数産まれたのかもしれません。

BYOBの結果、人よりかなり多くお金を出してくださった方もいたと思うのですがそのあたりが曖昧な感じになってしまったのは反省です。この場を借りてお礼申し上げます🙇

また、やっぱりOSTのあとに懇親会があると良いですね。そして懇親会があるならやはり金曜開催が良い！

オフ会のすすめ

上述の通り、"Engineering Managementやその周辺領域に関心や情熱がある"方さえ集えばいくらでも本イベントの再現はできます。なので、「OST良かった」ないし「参加したかったけど行けなかった」という方はぜひイベント外でもオフ会をやってみてほしいですね！

第3回はプレゼン形式

初回・2回と続いてOSTをやったのですが第3回はプレゼン形式を試してみます。

engineering-manager-meetup.connpass.com

形式は違えどOSTのときと変わらない主体的参加をしてくれる方々が集まってくれることを期待します。主体的参加のイメージ：

  • 発表内容・テーマについて登壇者にフィードバックを行う（イベント内外問わず）
  • 発表内容・テーマについて参加者同士で議論する
  • 発表内容・テーマについて考えた内容をTwitterやブログに公開する

こうした行動を起こすことでイベント全体での学びが最大化されれば良いなという思いがあります。さらに盛り上げていくぞ！ウォーッ

*1:Bring Your Own Beerの略。好きな飲食物を好きなだけ、参加者に用意いただくスタイル

エンジニアのチーム構成・組織構成の潮流、プロジェクトに付くかプロダクトに付くか

Engineering

海外と日本でのソフトウェア開発職の文化を振り返ってみた – reyabe – Medium を読んだ。

全体としてとても面白く読ませていただいた中で、特に気になるところがあったのでそれに関する所感を書いてみる。「エンジニアのチーム構成・組織構成」というパートだ。

ちなみに、どちらが良い悪いみたいな話でもなければ同記事に対する異論反論でもない、ということは初めに強調しておきます。

ヨーロッパの開発チーム構成

同記事の「エンジニアのチーム構成・組織構成」に以下のようにある。

それに対し、ヨーロッパの開発チームはよりプロジェクト・プロダクトを実現するための一時的なタスクフォースという意識の方が強いと思います。あるプロジェクトが完了して次に進む際にメンバーがシャッフルするのも普通で、場合によってはプロジェクトではなくタスク単位で、あるタスクをこなすスキルを持つエンジニアが必要であればその人が一時的にチームに加わるという移動の仕方もあります。

「おおー、それでうまく回る…のか？」というのが第一印象だった。

というのも、プロジェクトベースで開発するこのスタイルは僕が受託開発をやっていたときや、現職でかつて採っていたスタイルだが、デメリットを強く感じるようになり止めたものだったからだ。*1

プロジェクトベースの開発のデメリット

プロジェクトベースの開発のデメリットに関する私見。初めに書いた通り、良い悪いを論じたいわけではなく、こうしたデメリットをどう扱うのかが気になっている、という記事なのでメリットについては省略する。

長期的観点の不足

一般的に言えば、プロジェクトベースでの開発はリリース以降に起きることに対する長期的な観点が不足しがちになる。プロジェクトを終わらせることがチームの達成すべき目標であり、それ以外を優先するインセンティブが低くなるからだ。

長期的な観点の例は、運用・(技術的|プロダクト)負債・アーキテクチャなど、製品が継続的に改善・成長しつづけるためには避けて通れないが、初期開発のタイミングではある意味"ごまかし"がきくところ。*2

DevOpsを実践する現職においては、開発したものの運用は自分たちで行っているために起きにくい問題ではあった。

しかし前職のSIerで案件・プロジェクトベースで働いていたときは納品第一でいっときの完成を迎えたものの、運用において取り返しのつかないコストを払う羽目になった例も幾つか見た。

「短期的には安くつくが、長期的には高くつく」問題にどう対処しているのか気になるところ。

余談だが、システム開発における"外注"も短期的には安くつく（かもしれない）が長期的には高くつく可能性の高いものだと個人的に思っている…。このあたりは『エンジニアリング組織論への招待』にもより詳しい説明があるので深掘りしたい方はどうぞ。

適切な契約の交渉と納品物のクオリティを監督する能力が、社内に存在しない場合、仮に一時的に満足のいく関係を築けたとしても、長期的には、蓄積された取引コストを引き受けることになります。

もう一点余談だが、長期的観点という名目でのオーバーエンジニアリングは同記事中での指摘と繋がるものがあるかもしれない。

そもそも運用は？

これは単純な疑問で、そもそも開発したものの運用はどのように扱われるのか気になる。

受託開発における保守案件のようなプロジェクトが始まり、nヶ月単位でまた解散と集合を繰り返すのだろうか？

ビジネスとの分断

プロジェクトが発生するまでの流れを超大雑把に考え、

起案・企画 → 見積・予算確保 → 開発開始

という流れになるとすると、開発者が参加するのはどこからか。最右端の開発開始からだとすると、すでに作ること・作るものが決定してしまっていたりしないだろうか。

その場合、開発開始〜開発中にプロジェクトの根本的な欠陥に気づいたり、見積・予算の不確実性に振り回されたりしたときに「やることは決まってしまっているので覆せない」みたいなことが起きないだろうか。

そうしたなかでビジネスサイド（という言い方はあまり好きではないが）とエンジニアリングチームのパワーバランス（という言い方もあまり好きではないが）において前者が強すぎる事に対し、エンジニアリングチームから不満があがったりするかもしれない。

話が飛躍するかもしれないが、職能別にチームを区切ることで、開発者をテンポラリな労働力と捉える"外注感"や職能間の対立構造を生みやすいというのが個人の経験としてはある。

合わせて読みたい：

「開発チーム」で本当に大丈夫か考える - Speaker Deck

個人的観測範囲での潮流

個人的観測範囲においては、事業会社で製品開発しているところはプロジェクトベースをやめてメンバーを長期的に固定した職能横断型チームを作る方にシフトする潮流があると感じている。（それだけに上記記事の内容に意外性を感じた次第）*3

ざっくり言うならばタイトルの通りプロジェクトに付くかプロダクトに付くか、というのが一番の違いとも言える。

現職では上記のような問題（＋その他の幾つかの問題）に対処するため、特定のプロダクトの特定の機能・サービスについては個別のチームを設けることにした。このチームの中にWeb engineer, Designer, Product owner, iOS/Android Engineer, Data analystなど各々の専門性を持つメンバーを集め、長期的にプロダクトや機能を磨き込み、ビジネス上の目標を達成することを目指す、という形だ。

チームに対する帰属意識は高い一方で「何をするために集まっているのか」を中心に据えているため、記事中にある「日本の開発チーム」（以下に引用）とはやや趣が異なるかもしれない。

日本の開発チームはより参加しているメンバーによってアイデンティティを持つ団体になっている印象を受けました。何をするために集まっているのかより誰が集まっているのかの意識の方が高い気がします。チームの人と飲みに行ったり、チームビルディングのアクティビティーがあったり、社員旅行で基本チームメンバーとしか行動しなかったり、よりチームというユニットが中心になっている事が色々なところから伝わってきます。日本は元から上下関係を大切にする文化もあり、チームに関してもメンバーを育てる・メンバーの面倒を見る・チームの先輩から学ぶという意識が強いと感じました。

とはいえプロジェクトベースの開発とは異なるのは明らかだ。「ひとまとまりで動くことで意思決定の質と速度を最適化できるチームの最小単位」*4による開発は、SquadやTribeといった概念を用いて説明されるSpotifyモデルにも当てはまる。

これについてはWantedly社の記事などが大変参考になる。

SquadとOKR - 開発チームが無駄なく高い成果を出すために大事にしていること | Wantedly Engineer Blog

full-stack agile - Team Organisation: Squads, Chapters, Tribes & Guilds

また、近年隆盛を見せるMicroservicesの実践に伴うチームのマイクロ化においても達成したい組織・チーム構造はSpotifyモデルと似通ったものがあるのではないかと思う。

「これらはヨーロッパでなくアメリカでは？」という突っ込みがありそうだが、紹介した記事のタイトルでも「海外と日本でのソフトウェア開発職の文化」と二分してたので、まぁそこは大目に…。

所感なのでオチもないが、プロジェクトベースでも上述のような問題をうまく解決する手法があれば知りたく、もしくは上述のデメリットをプロジェクトベースでの開発に帰するのは誤りだといった指摘も歓迎です。「うちはこうしているよ」話も更に大歓迎です

*1:全てが同時多発的に頻発していたわけではなく、ぼんやりと感じつつあったものが爆発する前に舵を切った

*2:もちろんプロジェクト終了後に変更や運用が発生しない製品については関係のないことだ

*3:これに対する課題もあるのは承知の上 https://daipresents.com/2017/cross-functional-team/

*4:https://www.wantedly.com/companies/wantedly/post_articles/134301 より

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

この半年間はソフトウェアエンジニアとしてのアウトプットに積極的になるよう意識的に行動してみたので振り返ってみます。長くなってしまったので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をしました

Ruby

第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) でした

ISUCON

もう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