第03回 #Customer系エンジニア座談会 に登壇しました
2022/03/09 に開催された第03回 Customer系エンジニア座談会に登壇してきたので、話した内容や感想などを書いておこうと思います。
customer-x-engineer.connpass.com
続きを読むマネージャーになりました（9ヶ月ぶり2回目）
（前職）IC→（メルカリ）IC→（メルカリ）EM→（ソウゾウ）IC→（ソウゾウ）EM←いまここ
というわけで、1月からまたEngineering Managerになりました（9ヶ月ぶり2回目）。ソウゾウとしては3人目のEMとなります。
続きを読む2021年を振り返る
明けましておめでとうございます。
今年も振り返りをやっていきます。2021年は例年よりもプライベート・業務両方でアウトプットの多い年になったので、書いた記事の参照多めです。
去年のはこちら。
仕事
3年半ほど在籍したメルカリ日本事業を離れ、4月からメルカリグループで新規事業開発を担う株式会社ソウゾウに異動しました。
ソウゾウは2021年1月に設立した会社で、メルカリShopsというサービスを10月に正式リリースしています。詳細は過去に書いた近況報告をご参照ください。
自分はソフトウェアエンジニアとして、主にCS(Customer Service/Succes)向けの内部ツール開発（CSツール）と、匿名配送サービスであるメルカリ便の開発を行ってきました。
CSツールはメルカリ・メルペイ・ソウゾウ3社のメンバーがかかわるためオペレーション設計が難しく、要件定義から実装チケット作成、開発（バックエンド・BFF・フロントエンド全部）までほぼ全て自分が担当させていただいたので非常に感慨深いです。
3月から7月くらいまでは、0→1の醍醐味と大変さの両方で押しつぶされそうになりそうで、10年の社会人人生の中でもトップクラスに濃厚な日々を過ごせました。
また、開発の傍らエンジニア採用にも携わっておりエンジニア選考ガイドを作成してgithubで公開しました。
“可能な限り具体的に公開する” ことにこだわり、メルカリグループではソウゾウ独自の選考方法となるSystem Design Interviewではサンプル問題まで公開しています。ちなみに、このサンプル問題は私が作りました（地味に大変だった）。
怒涛の忙しさがようやくひと段落したタイミングではありますが、1月からは違う役割を担うことなるのでまだまだ息つく暇がなさそうです*1。
プライベート
体調
4月末から全身に蕁麻疹が出始めて今も継続しています。
全身に軽く蕁麻疹が出てかゆい。なんだこれ
— なおぱー (@naopr) 2021年4月28日
グロいので画像は控えますが、ミミズ腫れのような赤いアザが出てかゆみがひどく眠れないこともしばしば…。
蕁麻疹が出るのは初めてなのですが、食べ物や薬のアレルギーでも気温の変化によるものでもなさそうで、正確な原因はわかっていません。ただ、蕁麻疹が出始めた頃は怒涛の忙しさがちょっとだけ落ち着いて気が緩んだ時期なので、それが原因かなと疑っています。
病院で処方してもらった薬を飲んでいればかゆみは抑えられるので、あとは早く治ってくれるのを祈るばかりです。
運動
仕事の忙しさを言い訳にしてリングフィットをサボりがちだったのですが、11月からそこそこ本気でダイエットを始めたので今ではほぼ毎日プレイしています。
かれこれ1年半以上継続できており、レベルは400を超えました。
1年半の成果です #リングフィットアドベンチャー #RingFitAdventure #NintendoSwitch pic.twitter.com/7g2AzOVz0c
— なおぱー (@naopr) 2021年12月12日
今後も継続していきます！
旅行
6月：妻の誕生日祝いで伊豆へ
ウフフビレッジのドームテントでグランピング
夫婦ともに大好きなシャボテン公園
10月：友人の結婚式で京都へ
OMO5京都三条に泊まり、和装で結婚式参列。酒もやっていき
10月：自分の誕生日祝いで鎌倉へ
KAMAKURA HOTELでプライベートサウナを初体験しつつ鎌倉のおいしいご飯もやっていき
11月：ワーケーションで式根島へ
別エントリを書いたので割愛。
12月：酒造見学で（京都経由で）奈良へ
御宿 野乃京都七条に泊まって食べ歩き
風の森で有名な油長酒造で、新ブランドの水端を醸す享保蔵を見学
最後に
2021年は10年の社会人人生の中で一番忙しい年になりました。超絶怒涛な日々だったので全然記憶がありません。。。これはこれで最高に楽しかったですが、このペースで働き続けるのは大変なので来年はもう少し落ち着いた年にしようと思います。
2022年の目標はこちらです。
2022年の目標は体脂肪率15%を切ることです
— なおぱー (@naopr) 2021年12月31日
*1:詳細はまた別のエントリに書きます
かつてEMをやりたくなかった俺たちへ
これは Engineering Manager Advent Calendar 2021 2日目のエントリです。
簡単に自己紹介すると、今年の3月までメルカリでEM(Engineering Manager)をやっていて、今はメルカリのグループ会社であるソウゾウでIC(Indivisual Contributer)として働いています。バックエンドをメインにフロントエンドも書いており、採用周りもちょっと顔を出したりしています。
さて、このエントリではかつて「EMなんて絶対やりたくない！」と思っていた若かりし自分が抱いていたEMに対するもやもやに対して、IC→EM→ICというキャリアを経たいまの自分が答える、という形式で書いていこうと思います。
EMはやりたくないと思っている方の参考になれば幸いです。
EMって何する人なのかわからない
組織によってEMに求められる役割に違いはありますが、マネージャー経験者の多くが読んでいるであろう『High Output Management』では、マネージャーのアウトプットを以下のように定義しています。
マネージャーのアウトプット = 自分の組織のアウトプット + 自分の影響力が及ぶ隣接諸組織のアウトプット
簡単にいうと、組織の成果を最大化させるということです。
…とここまで書きましたが、全然ピンときてないですよね。わかります。
あなたのEMが普段どんな仕事をしていて、それが自分や自分の属するチームにどんないい影響を与えてくれているかが理解できていないのかもしれません。
もしそうなら、シンプルにEMとのコミュニケーションが足りていません。まずは月に1回ペースでお互いの仕事のことなんかをカジュアルに話す場をセットしてみてはどうでしょうか。そうするとEMがどんなことを考えていて（もしくは考えていなくて）、どんな仕事をしているのかわかってくるはずです。
本来EMからICに対してコミュニケーションをとるのが理想的ですが、EMが忙しすぎたりマネジメントスキルが低く何をしたらいいかわかっていない場合もあるので、ICからもコミュニケーションを取りに行ってみるのをおすすめします。ちょっとハードルが高いかもしれませんが、EMからすると案外ありがたかったりするものです。
EMって何が楽しいの
これは人によるところが大きいと思いますが、自分の場合には楽しいと感じるポイントは3つありました。
- やったことがなく、かつ頑張ればできそうなことにチャレンジしている感覚
- 「チームを成長させる」ために必要な裁量が与えられていること
- 採用にがっつり関わることができる
（1つ目は割愛して）2つ目について説明します。Tech Leadやリードエンジニアと言われるような役割がつくと、思考の高さが自分1人からチーム全体に上がります。そうなると、開発のボトルネックをなくしたり、生産性を上げたり、プロダクト全体の安定性を上げたりといったことを求められるようになるでしょう。
そういったことを続けていると、自身の裁量では対応できないような問題についてEMの判断を仰ぐ場面が出てきます。例えば他チームとの業務分掌や業務フローの適正化であったり、チームへのメンバー受け入れであったり、技術的負債の返済と新規機能開発のバランスであったりします。それらを自分で判断できる裁量がもらえるのはEMとしてやりがいを感じる部分です。
3つ目について詳しい説明は不要かもしれませんが、EMになると多くの場合がっつりエンジニア採用にかかわることになります。書類選考や面接を担当するだけでなく、選考フローや選考基準を作ったりアプローチする人材を選んだりもします。
採用というのはEMにとって最もレバレッジがきく業務の1つであることはもちろん、自分と一緒に働くメンバーを自分で決められるのはエキサイティングです*1。
経営と現場の板挟みになって辛そう
板挟みになることはあります。
組織が大きくなるにつれて経営と現場のコミュニケーションコストが大きくなり、直接的な相互理解が難しくなってきます。そのため、EMの業務の1つとして経営のメッセージを適切に現場に伝え、現場のメッセージを経営に伝えることが求められます。
EMとして辛いというかもどかしさを感じることはありますが、誰かがやらないといけない仕事ですし、現場のメンバーが納得感を持って日々仕事ができるようにするために必要な業務です。ただし、EMのような中間管理職のプロキシを介さずとも、経営と現場で直接的にメッセージをやりとりできる仕組みを会社として設けることは非常に大事だと思っています。
エンジニアとしてのスキルが落ちそう
コードを書く速度は確実に落ちます（キッパリ）。なぜならコードを書く機会が減るからです。
新しい技術トピックを調べたり業務の中でそれを試したりする機会も減るでしょう。
ただ、EMも業務としてメンバーの評価をしたり技術的な意思決定をする場面があるため、ICのときほど技術にdeep diveする時間はなかったとしてもトピックを抑えておく程度の技術的なインプットは必要です。
私がEMになりたての頃はコーディングから離れるのが怖くて毎日コードを書くための時間を確保していましたが、EMとして経験を積んでできることが増えていくにつれて徐々にコードを書く時間は減っていきました。プライベートでコツコツ技術の勉強をするのがあまり得意でないので、チーム内の勉強会に参加したり1on1で詳しいメンバーに知識を教えてもらったりしてなんとかキャッチアップしていました。もちろん、プライベートの時間でコードを書いているEMもいました。
一方で、エンジニアのスキルは最新の技術トピックを知っていたり良い設計ができたりコードを速く書けたりすることだけではありません。
もちろん、そういったスキルを職人的に磨き続け技術的難易度の高い課題を解くことを専門にするキャリアもあります。しかし、ビジネス観点を持ってPMやBizDevと相談しながら開発計画を立てたり、開発プロセスを改善してチームの生産性を上げたりすることもエンジニアのスキルです。
その意味では、EMになったからといってエンジニアとしてのスキルが落ちるわけではなくスキルの幅が広がるという考え方もできます。
…とここまで書きましたがやっぱりコードを書く機会が減るのは自分としてはとても悲しかったです。それもあって今はICに戻りました。
一度EMになったらもうICには戻れなさそう
戻れます。というか戻れました。
1年半のブランクがあったため、開発初期にはLinuxコマンドやらGo言語の仕様やらを思い出すのが大変だったり、さらには今まで触ったことのない技術へのチャレンジやタイトなスケジュールもあいまって頭がパンクしそうでしたし自分のあまりのできなさに落ち込んだりもしました。
しかし、そんな時期も1ヶ月くらいすると慣れて以前と同様にコードを書けるようになっていました。
正直に言うとブランクのある自分がどの程度コードが書けるのか非常に不安だったのですが、思っていたほどのコーディングスキルの衰えは感じませんでした。加えて、PMやCSとのコミュニケーションがスムーズに行えたり、自分から開発仕様を決めるように周りを巻き込みながら推進できたりと、EMをやっていたことによる自身の成長を感じることもできました。
ブランク期間が3年、5年などもっと長かったらこうはいかなかったかもしれませんが、少なくとも1年半程度であれば自分のようなコーディングスキルが決して高くないエンジニアでもICに戻ることはできました。
さいごに
IC→EM→ICというキャリアを経たいまですが、もう一度EMに戻るのも全然アリだなと思っています。
冒頭で書いたとおりEMの役割は組織によって違うので、1度EMをやった組織とまた別の組織でEMをやるのは面白そうだと思うからです。担当するチームやメンバーの成長に少しでも貢献できたり、それによってよいプロダクトがリリースされるのを見るのはICとはまた別のやりがいがあります。
散々ポエムを書きなぐってしまいましたが、ざっくばらんにこのあたりを話してみてもいいよ！という方はぜひmeetyからご連絡ください。
12/3追記：
時期を同じくして弊社のオウンドメディアでも近いことを話しているのでご興味あればこちらもご覧ください。
*1:自分のチームに配属されたエンジニアが微妙だったり、受け入れたくない人を受け入れざるを得なかった経験は誰しもあるのではないでしょうか
『ジェンダーについて大学生が真剣に考えてみた』を読んで考えてみた
きっかけはりっちゃさんのこのツイート。
森さん発言で関心が高まってる今だからこそ、ジェンダーギャップに関心持ったらまず読んで欲しい本。
— りっちゃ (@r1ccha) 2021年2月5日
どれも学術研究やデータに基づいた良書です。
特に、男性で発言しづらいがまず何から学べばいいんだ？と思ってるマネジメントや経営者の方へ。
貼ってる順がおすすめ。 pic.twitter.com/JrNGw1bm4D
最近、D&Iについて興味が出てきて WORK DESIGN(ワークデザイン) を読み始めているのですが、他の本も読んでみたいと思っていたところだったのでポチって読んでみました。
このエントリでは、『ジェンダーについて大学生が真剣に考えてみた』（以下、本書）を読んで自分が考えたことや調べたことを書こうと思います。
続きを読む