ひつじのにっき

mhidakaのにっきです。たまに長文、気が向いたとき更新。

メルペイのエンジニアリングマネージャーとして働いています

今年も一年、おつかれさまでした。

この日記を書いている時点では12月27日です。弊社の暦に従えばあと2営業日ぐらいありますが、すでに仕事を納めたひとも多いので誤差の範疇でしょう。

あなたは誰？

メルペイでAndroidのエンジニアリングマネージャーをしているmhdiakaです。

日記をよんでいるみなさんが観測できる範囲だと技術書典というイベントの主宰やDroidKaigiというカンファレンスのオーガナイザーやKotlinFestのお手伝い、四半期ごとに2～3冊、年に10冊程度の技術書を執筆したり編集したり、たまに寄稿などしています。これだけよむと働いてるのか？って思いますよね。（このあたりの作業は業務時間もつかっているので）働いてます。

最近また技術書をつくりました。今の期間だけ予約してるのでAndroid開発してるひとは見てね

techbooster.booth.pm

エンジニアリングマネージャー振り返り

さて本題です。僕はエンジニアリングマネージャーという役割は組織次第で求められる内容が違うと考えています。なので、この振り返りがエンジニアリングマネージャーという役割を俯瞰的に考える役に立つかわからないなぁ、と感じてます。

でも、年末だし、自分の区切りがいいのでメルペイという新しい組織（このまえ1年目の誕生日を迎えました）のなかでの経験を書いておこうと思います。

具体的な事例とかは書けないのだけどAndroidチームのはじめてのエンジニアリングマネージャーを経験しているので「そういうEMもいるよな」という一形態として何かの参考になれば幸いです。

※この記事は個人の見解であり、所属する組織を代表するものではありません。

なぜEMになったか

ひらたくまとめると「EMがいるほうがエンジニアリングがスムーズで、ちょうど僕が組織にコミュニケーション・働きやすい環境を整備する上での課題を感じ、解決したかった」からです。なので、じゃあやりますと手を上げたのが今年の5～6月あたりです。（直接聞いたわけじゃないけど、EMへは同僚のBackend EMのcocoitiが推してくれたんだとおもう。この流れでよく信頼して任せてくれたなぁ、と今になって感じている）

次の記事に詳しいので興味がある人は読んでください。説明が大変なので詳細は割愛します。

会社のミッションとValues

メルペイはメルカリのグループ企業なんですがミッションは少しちがってます（Valuesは一緒）。 

そもそも僕はソウゾウからの異動だったので会社のミッションに強い共感があって入社したという性質の人間ではなかったんですよね。ソウゾウではエキスパートという役割だった（いまも兼務している）ので社会貢献やコミュニティ・OSSへのコントリビュートの意識が強く感じていたのを覚えてます。実は不良な社員かもしれない。

ミッション：

　信用を創造して、なめらかな社会を創る。

Values：

　Go Bold ー大胆にやろう

　All for One ー 全ては成功のために

　Be Professional ー プロフェッショナルであれ

メルカリという会社ではミッションやValues（行動指針みたいなの）を共有できているかがめちゃくちゃ大事です。組織の中でコミュニケーション、それこそ会議、Slack、会話どこでも使われてるんですよね。

でもメルペイは急成長してて中途の社員もドンドンはいってくる。加速度的な拡大なのでミッションとValuesで会話できるようにならないと目線が合わない。マネージャーとして働く上では死活問題になりつつあった。

最初のマネージャー研修でメルカリ社長の小泉さんに「Valuesはとにかく飽きられるぐらいしつこく使ってほしい」「このマネージャー、またValuesの話してるよって思われるぐらいでちょうどいい」って教えてもらってて、

なんとなくの理解を言語化して繰り返して伝えることを意識して実行してました。Valuesが会社に根付いていることの何が良いかというと、行動の判断基準を形作れるのがすごい。マネージャーが何かを言わなくてもメンバーでプロダクトのために必要なことをValuesに即して考えて、実行できてるシーンを何度も見ては「なるほどなぁ、これが自律する組織か」と妙な関心をしてたのを覚えてる。

それからは話す時もValuesを積極的に使うようにしてます（たまに社外でも使ったり、メンタリングしようとしてしまって良くない）。

正直、自分自身はマネージャーとして何かメンバーに仕事の指示をしたかと言われるとタッチしてない自覚があって、プロジェクトアサインやチーム間の調整とかエンジニアリングの環境を整えることに注力して過ごしてた。

マネージャーとしての気付き

僕からみたメルペイは自由な職場です。裁量を持って良いプロダクト・サービス開発に打ち込める。でも会社が抱える課題はめちゃくちゃあるから順風満帆という意味ではなさそう。他の会社で1年かけておきるような変化が3ヶ月で発生してると思うぐらい活発に動いてる。

とくに組織が大きくなる中で未整備の事柄が目についてしまうことも多くて、例えばマネージャーの数がたりてなかったり（本来マネージャーがケアすべき内容が抜け落ちるのでストレスがかかる）、チームを超えた共同作業に努力を払う必要がある（これはプロジェクトが大きくて関係者が多いことに起因するかもしれないし、初めてというだけで、もっと大きなプロジェクトをやってる側からみると妥当なコストなのかもしれない）。

入社してから数えて2年弱しかたってないんだけど、この組織は常に新しい課題に直面しつつ、前に進んできたので致命的な課題が放置されることはまずないだろう。

メルペイでは仕事を進めるためには、問題をシャットアウトするより、課題解決に一緒に取り組んで価値を最大化するほうが効率的だと感じる（もちろん問題の種類によってはNoというべきものもあるんだけど、マネージャーに持ち込まれる問題の殆どが複雑なもので単純な判断が出来ない事が多い。これは単純な問題はValuesに基づいてちゃっちゃと解決してしまっている事象の裏返しなのだとおもう）。

マネージャーとして何をやったか

働きやすい環境を作るのに腐心していた。会社で進めたのはモバイルエンジニア全員へのiMac Proの導入や開発端末の購入/整備、プロジェクトの初期検討、見積、開発推進、関連するピープルマネジメント。

正直EMをはじめた最初の１～２ヶ月はストレスも大きかったし、うまく回すためのなにかが足りてなかったとおもう。ほとんどの事柄は回りの環境に助けられたことと試行錯誤を通じて手に入れたと感じてる。マネジメントをするのは初めてではなかったのだけど前の職のスキルが生きたかといわれると部分的にしか使えなかった。

そういう中で自分に足りない未知のスキルを手に入れようと思うととにかく経験してすばやく失敗・成功を繰り返すしかない。 

大事なのは「失敗するかもしれないが、こいつは俺のことを助けてくれるやつだ」という信頼だと感じていて、そのためにはマネージメントを手伝いだしてすぐに自分が何を考えているのかという所信表明を社内Wikiに書いたりした（メルカリに所属しているひとだけが見れるので、運良くアクセス権があるなら探してみてもいいかも）。信用貯金は大切だなぁと。

振り返るとAndroidのEMが1人ということもあり社内のほぼすべてのプロジェクトをみている。正直人智を超えている気がするが、やればできた。これは素養があったとみるべきで、普段からイベント運営や執筆などでマルチスレッドで動くくせがあったのでなんとかなったのかもしれない※。

※クオーターの振り返りがまだなのでいま時点でメンバーからの評価は聞いてない。なので本当に自分がよいマネージャーであったかは不明だと書き添えておく（個人的に評価をされる側というのは本当に苦手だがこれは慣れの側面はありそう）。

そのなかでも半年でAndroidチームの開発者数を倍にしたことは良くも悪くも影響があったと感じてて、良い影響は開発プロジェクトの並列化、速度の向上で、単純にやりたいことができるのは良いことだ。一方、短期でのオンボーディングの難しさもそうだし、Non Japanese Speakerも多い（英語も頑張って学習し直している）。さらにAndroid開発で10人を超える規模というのはほとんどの人が経験したことがない未知の世界ではなかろうか。まるでわからないのでいろんな事例を集めた（海外のカンファレンスでは結構事例がシェアされているのでおすすめ）。

当然、ミッションに共感して入社してきた人たちには転職を良いものと感じて欲しいので、そのための努力はたくさん払った。自分自身も優秀なひとたちと一緒に働くことはいつになってもワクワクする。今後効率化や新しいテクノロジーの導入など僕では成し遂げられないことがチームワークによって実現できると思うと最高に面白い。

幸いにしてチームを支えてくれる組織的な支援もあり（これは急ピッチで整備された良い点だ）、技術組織ではCTOのsowawa, VPoEのhidek、ほかのEMsが一緒になってエンジニアリングを考えてくれてる（階層化が発生していないフラットな組織を維持している）。

追伸１：蛇足だけどメルペイにはマネージャー合宿や開発合宿、全員でオフサイトするという文化があるんだけど福利厚生だと感じるぐらいには面白い。

追伸２：余談だけど人の頭のなかにはオンメモリでWorkする容量の上限があって並行作業が多いとドンドン抜け落ちる。とくに僕の場合、コーディングとマネジメントは食い合わせが悪くてコンテキストスイッチのコストが高いのでコードは書いていない（書くEMもいる）。

2019年の自分

ここまでEMの話を書いていて、ちゃぶ台をひっくりがえすようで申し訳ないが、2019年1月からはエンジニアリングマネージャーというロールからは一旦離れて、もともとのエキスパートチームという社会貢献と社内開発のバランスをとった役割にもどります。

これはいくつか理由があるんだけど、ひとつめは最初から期限を切って、パフォーマンスを最大化しようと決めていたこと。ふたつめは新しい課題にうまく対応できるEMが入社してくれたから。

ひとつめは、エキスパートの業務とエンジニアリングマネージャーを兼務している状況は長く続けるのは難しいだろうなという視点があった。二足のわらじの状態を長くしててどちらも全力で打ち込めましたかと言われたとき、他のタスクが目に入っていると、どちらも100%というのは難しい（IT業界での0.5人月を信じてはいけないというはなしはよく聞くと思う）今回は期間のほうを短く設定して、どっちも最大限頑張って課題を解決しようという意識でのエンジニアリングマネージャーでした。これは受け入れてもらえたし、必要なことは出来たと思う。

ふたつめは、メルペイ・メルカリはどんどん変わっていく組織だということ。自分が在籍してる短い期間でもめちゃくちゃ変化している。みんなそれを楽しみながら過ごしてる。そういう組織だとEMが解決するべき課題もどんどんかわっていくので今回は新しいAndroid EMのひとがこの問題を解くのに適任だと感じただけ（そっちのほうが効率的ならチームが100%機能するためにサポートしようという状況。この行動は別にマネージャーというロールがなくてもできることなので）。

余談

この日記を読んでメルペイ・メルカリのEMに挑戦してみたい、話を聞いてみたいという人がいれば採用もしているので探してみてもいいかもしれない。優秀で面白い人達がいるので仕事が合うかどうかをじっくり見てほしい。そういうのじゃなくてお前の話に興味があるから聞きたいとかあれば一緒にランチにでもいきましょう。

エンジニアリングマネージャーというロールは僕にとっては面白かったし、メルペイではエンジニアと不可逆の役割でもない（ただの役割なので必要に応じて行ったり来たりするものだという認識がある）。エンジニアリングを良くしていくための一つの手段なでしかない。マネージャーというロールでは直接コードは書かないけど課題解決のために組織をこえて色んな人とも話す機会も持てたし、解決できる問題の種類も増えたとおもう。

全然、別の話では、いつだったか忘れたけどCTOのsowawaと1on1してると雑談のなかで経営とかちゃんと勉強しても良いかもねーって話題があったのでその頃から経営学べるといいかもなーと考えたり、社内でもDroidKaigiもあるのでそっちも手がかかるよねー、と声かけしてサポートしてもらったりもあるし、出展がたのしすぎてか技術書典6、やっていきましょう！みたいな声も聞こえてきている。人生なかなか飽きないなぁ、というかんじ。