2ヶ月間の育休取得を終えて

2020年1月より2月末までの丸二ヶ月間、育児休暇を取得させていただきました。 この背景にはmerci boxと呼ばれる会社の手厚い福利厚生があることと、実際にそれを用いて育休を取得した先輩パパ達が数多くいたからであり、改めて感謝しています。 ということで、恩の還元の意図も込めて、(前回経過を少し書いていたけど)今回はそのまとめです。

想定読者と前提条件

  • これから育休を取る(あるいは検討している)方(で一応エンジニア)に向けて
  • うちの環境がこうだった(他では違うこともある)前提条件としては、
    • 生後3〜4ヶ月目のできごと(生後すぐは妻の実家に里帰りしていた)
    • 一人目の子供(上の子がいるときっとまた状況は違う気がする)
    • 母乳育児(後述しますが、ミルク育児とは夫のできる活動に差がある)

TL;DR; やってみてどうだったか

  • ちょうど同じ時に育休を取っていた小泉進次郎が言うように、育休は全然休暇じゃないし、むしろ日常の仕事よりしんどかった
  • これまで妻より家事をやってこなかった人はやったほうが良い
  • 育児も仕事と一緒で、経験と慣れが必要
  • 同じく、市場(子供)が刻々と変わるのも仕事と一緒
  • 仕事への向き合い方、キャリア形成の考え方も変わりそう
  • 我が子は何よりも可愛いので幸せである

育児「休暇」ではない

やる前から忙しいだろうと思っていたけど、やってみたら本当に忙しかった。 どこでそう思うかというと、休日がないからだ。労働基準法に則った業務なら1日ごとの営業時間と休日があるが、育児は24時間/365日の作業だ。そういう意味ではwebサービスを運用しているエンジニアは作業をイメージしやすいかもしれない。ただし、そのサービスはActiveなインスタンスが2つあるだけで、それ以上のスケールアウトやバックアップがない。リクエストを捌くロードバランサはないので常にActiveでいる必要がある。
と書くと深刻そうにも読めるが、まぁこれは「夫婦」というサービスが始まったときからその運用は始まっているとも言える。子供という膨大なリクエストを送る顧客を手に入れたという変化だけかもしれない。

子供からのリクエストのトラフィックを捌くために

というわけで、子供からの要求をいかに対応するか、というのが結局のところ育休中に取り組むべきことだと思う。 この辺についてパートナーとよく話し合うこともこのまとまった時間があるからこそできること。 ただし、話し合うためにある程度2人の間での前提条件を合わせる必要があり、そのためにまず一通りの家事ができないといけない。

洗濯を普段やる人と全くやらない人では課題認識が違うので、その状態で「ドラム式乾燥機付き洗濯機」を買うかどうかを議論しても、その結果について双方納得することは多分難しい。 (余談としては、「ドラム式乾燥機付き洗濯機」は絶対に買うべき)

我が家の場合、お互いに一人暮らし経験があり、結婚後も共働きで家事は分担していたため、そこの差はあまりなかった。(俺が料理ができないというのが大きな差) 一方で、子育てに関しては生後3ヶ月まで妻が里帰り育児をしていたというのは大きな差だった。日々のオムツ替えや、3時間起きの授乳・夜中に寝てくれない、などを十分に経験していた妻と週末に少し参加していた俺のギャップは大きかった。

ギャップがある時にどうするかは前述の通り、前提を合わせるために追いつくしかないので、そこは妻を見習って頑張りましょう

育児も仕事と一緒で、経験と慣れが必要

1ヶ月経つくらいまでは、大変だった。 この頃に思っていたのは「2020年に育児はなんて非科学的なんだろう」ってこと。 特に妊娠から出産までの間で「科学の進歩」を感じた人は多いのではないか。 妊娠初期からエコーではクリアに赤ちゃんが見え、妊娠時期ごとのリスク一覧が都度提示され、さらには出生前診断など重い選択を迫られたりもする、、 一方で、産まれてきてからについては、「○○ヶ月頃に (夜泣き|人見知り|黄昏泣き|etcetc)が始まります、(抱っこして|あやして)あげましょう」みたいなことしか書いてない本もある。親という無限の愛の提供者としての踏み絵をさせられてるのではと思うほどだった。

それでも2ヶ月目になるとようやく慣れてきた。それによって考え方も変わる様になった。 例えば、最初はベッドで寝かすしつけをしたかったがうまくいかず、抱っこで寝かせながらモヤモヤした気持ちになっていたが、この頃になると朝寝は妻より自分が抱っこする方がスムーズにいくようになり、うちの子は寝る前にひと泣きするので、泣いたらシメたものとさえ思える様になった。

後半の方が体重が増えて大変だったハズなのだが、むしろ抱っこしてすぐ寝てくれるのがラクだと感じるようになったのは単純に慣れたのだと思う。根性論であり非科学的、と過去の自分にツッコまれればそうかもしれない。ただ、赤ちゃんは既にこの世に解き放たれたており、多種多様な環境で画一的な分析などできないんじゃないか、くらいの反論ができるようになった。大人に「○○すればXXになる」などの画一的なアプローチが当てはまらないように、赤ちゃんもそうであり、それが人間ってものだと思って納得できるようになった。

結果は後からついてくるものというのも仕事っぽいし、結果がでると楽しいものである。

母乳育児の父としての辛さ

特に母乳育児環境下において「結果が出て楽しい」と父親が感じられるまでは一定の時間がかかるのでそこは心して臨んでいただきたい。 授乳は生後間もない育児におけるハイライトであり、実際それによって赤ちゃんは成長するし、育てている実感も得られる(と思う)。赤ちゃんからの信頼も圧倒的である。
父親はそこにコミットできないので、最初は「マイナスをゼロにする作業」しかできないように感じる。夜に泣いたら寝かす、オムツが汚れたら替える、などの繰り返しだ。新生児の体重はみるみる増えていくけど、自分はそれにどんだけ貢献できているんだろうか、、みたいなことを悩まずに、「こうしたら寝てくれる」「お風呂であれすると機嫌が良い」などできることを少しずつ増やしていけると良い。

前提が揃ったところで、議論開始

そんなこんなで、ある程度対等に話せる様になり、「子供からの要求をいかに対応するか」というオペレーションの対応方針検討になる。 とはいえここは変数が多いので、それぞれに何を代入するか次第と言える。例えば

  • 保育園には(いつから)入れる/入れない
  • 子供はいつまでに何人欲しいうちの今何人目
  • 自分がやりたい、相手にやってほしい家事は何か
  • 日々の安定稼働第一か、多少の波風を時に許容しつつリフレッシュするのを目指すか

などがあり、どういう状態を想定してどういうアクションをするかがポイントになる

市場(子供)が刻々と変わるのも仕事と一緒

と、そこまで考えても全然終わりじゃない。というと身も蓋もないけど、子供が成長するのも重要な変数の一つなのだ。例えば、ちょうど今回の育休が終わったタイミングで離乳食が始まった。上記の変数に「子供の食事をどうするか」というものはなかった。何故ならば母乳一択だったからだ。離乳食だと俺でも担当できることになるので、そうしたら育休期間中に話した内容をアップデートする必要があるかもしれない。

市場は逐次変化するし、それによって発生する案件があって、アサインされる人がいて、タスクの整理分担があって、というのも仕事と一緒だ。

本業の仕事への向き合い方、キャリア形成の考え方も変わりそう

育休を取ったことで、本業の仕事への捉え方が変わるかもという部分も感じている。 よく言うワークライフバランスの感覚はもちろんそうだが、それ以外に育休からの復帰というのは「自分が一定期間いなくてもまわる職場を自分の目で確認できる機会」だと感じた。

「どんなにそれまで頑張っていても、自分がいなくなっても仕事はまわる」これは転職を経験すると感じることができる大事な事実だ。ただ、それを実際にこの目で見たことまではなかったが、今回はそれが見られる初めてのケースだった。 見て大丈夫そうなのでじゃあ辞めようとも、見たらダメダメだったのでもっとやらねばとも思わないが、なんというか「やるべきことをしっかりやる」のが大事なのではないか。
やるべきことをやれば、次に休むとき/異動するとき/辞めるときに迷惑をかけずに引き継げる
やるべきことをやれば、次に戻ったとき/移ってきたとき/入社したときに貢献できる

我が子は何よりも可愛いので幸せである

期間中には区が主催する赤ちゃんクラブ(要はママ同士のコミュニケーションイベント)や、生後4ヶ月検診などにも参加できた。 赤ちゃんクラブには30組程度の親子が来ていたが、父親も参加していたのは自分だけだった。これが男性の育休取得率のパーセンテージを体現しているなと感じた。(このイベント自体が生後3,4ヶ月向けなので、生後直後だったらもう少し多いのだろうか)

その30組の中で、我が子がダントツで可愛かった。
育児に疲れた時こそ、(コロナが落ち着いたら)是非イベントごとに参加すると良い(予防接種・生後検診・行政が主催する取り組みなど)。 我が子はどこで会う誰よりも可愛いので、それを感じるたびにリフレッシュされる。

まとめると、結構先々まで適用していけるのではないかという考え方を整理できた経験だったと思う。
ここまでできたのは、まとまった時間があり、それだけに集中できたのが大きい。週末だけの育児ではできることもここまで増えなかったし、それによって考えが変わることもなかったのではないかと思う。

貴重な時間を一緒に過ごしてくれた妻と我が子に感謝の2ヶ月でした。

育休取得後2週間経っての経過報告

2020年1月の頭から2月末まで、2ヶ月の育休を取得しています。子供視点で言うと、生後3ヶ月からの2ヶ月間になる。ちょうど2週間が経過し、4分の1が消化された。
また話題の小泉進次郎大臣が「生後2ヶ月の間の通算2週間」を取得予定らしいので、小泉進次郎が消化できるのがこれくらいということになる。

ネントレするためのリズムある生活よりも優先したもの

出産前からジーナ式などの本を読み導入を検討していたけど、実際には出産直後は妻が里帰りしていたため、その間のやり方はお任せしていました。それでも大体の授乳時間とお風呂・入眠の時間等は決まってはいた。 とはいえ、12時間寝てくれるなんてことはなくて、夜中に最低1回は起きる。 夜中1回というのは、一般的に決して多くなくむしろ普通。決して悪いものじゃない前提で、こういう12時間睡眠とかを目指した固定リズム制を導入するかどうか。

これを考えた時に思ったのは、「実際これやるのって、1日中家にいる前提だよな、、」ということ。 何時に授乳させ、その後何時間寝かせる。というのが本に書いてあるんだけど、安定的に授乳させられる環境と、ベッドに寝かせて昼寝させられる環境は家以外にない。 逆にでかけてしまうと、授乳室がある場所にいるタイミングに左右されるし、抱っこ紐の中で寝かす・起こすを制御することはできない。

と考えた時に、一旦この2週間はネントレ系のことは考えすぎないようにしようと思った。なぜなら、この期間には以下のようなイベントがあって、

  • ちょうど俺の誕生日だったこともあり、孫を連れて実家に顔出し
  • (育休始まったばかりなのに)俺が連続して数日予定があり、再度妻が実家に帰省
  • 両親への内祝いを兼ねて、家族で温泉旅行
  • 友達と会ってランチ
  • 子供の銀行口座を作ってあげたり、新しいベビーカーの試乗に行く
  • 親を招いて、初節句(雛祭り)の飾り付け

この不規則かつ非日常な出来事のために、むしろ1日家にいる方が圧倒的に少なかった。

特に親と彼らの孫を会わせてあげようと思うと、どうしても生活リズムは不規則になる。移動を考えた時間の授乳になるし、お昼寝も移動中に抱っこで寝かせる運用になる。代わりに一緒にいる間にたくさん抱っこさせてあげられるようになる。
ただ、やっぱりこれらは優先してやって良かったなと思う。リズム作りなどは、(もちろん早い方が良いのかもしれないけど)あとででもできることではある。一方で、すくすく育つ孫と数多く会わせられる期間は限られるので代えがたいものだし、温泉旅行など孫ができる前に行くことは相当な期間なかったので、良い孝行ができのではないかと勝手に思っている。

これからやれそうなこと

とはいえ、この後どうするかで言うと、いくつかトライしたいことがある。 大前提として前述のネントレもそうだが、なるべく負担の少ないライフスタイルを構築したいというのはある。それは特に一人で育児を続ける妻のためでもある。 子供向けの施策は子供自体が成長して変化する、かつ不確実性が高いので、その周りへのアプローチの方が良いんじゃないかという気がしている。

  • キッズラインお試し
    • 家事に困ったときに、どのタイプの家事ならアウトソースしたいか見定める
  • ベビーカーで行けるランチ場所を見つけておく
    • 妻が1人で行けて、昼をラクできるところを見つける
  • 俺ができる料理の品目を増やす
    • できない家事の代表格。この期に改善したい
  • 週末の料理作り置き準備
    • こっちの料理はメインが俺じゃないが、平日妻一人で料理タスクが難しくなるだろう想定のもと

どれも今時点では困っていないことだけど、育休終わったら絶対大変になるだろうな、っていうところ。 この辺の仮説検証を一緒にできるのが育休期間のメリットかなと思っている。また経過か結果でこの辺の進捗を書こうと思います。

pm conf2019 参加レポートと知識の体系化がまだ出来てない話

2019/11/12,13で開催されていた PM conf に参加してきたのでそのレポートですが、既に結構時間経ってしまったので、参加してから感じた自分の知識の体系化への課題の所感も合わせてです。

PM confとは

今年で4回目となる(らしい)Product Manager向けのカンファレンス。規模は年を追うごとに拡大していっている。 今年は1000人以上は来ていたんじゃないだろうか。

カンファレンスのセッションの種類とその市場の成熟度

いきなり大枠から入るが、全体で見ると 市場の成熟度 みたいなものが満ちるのにまだ余地があるように感じた。 これはEngineering Manager界隈にも同じような感想を持っていたので、そこに通じるものがあったのだと思う。

例えば、プログラム言語のイベント/カンファレンスだと、セッション内容に以下のようなフェーズがあると思っている

  1. そのプログラム言語を触ってみた系
  2. そのプログラム言語のライブラリを書いてみた系
  3. そのプログラム言語のフレームワークを作ってみた/使ってみた系
  4. そのプログラム言語でサービスを運用してみた系

徐々に言語への理解が深まり、体系立ったものが身につき、それが業務に活きるというようなストーリーになる。どの辺のセッションが多いかで、その言語や市場が流行っているのかがなんとなく掴めるのではと思う。

これに当てはめてみると、今回のカンファレンスで多いのはフェーズ1か2のイメージに近い「やってみた」系のセッションだったように感じた。 上記のフェーズ分けの整理があらかじめできていた訳ではないが、聞いてみておもしろいと感じたのは、フェーズ3,4系のセッションであり、自分が求めていたのはその辺だったのだなと後になってから腑に落ちた。

フェーズ4の運用面で最も学びがあったのはシリコンバレーで9年PMをしているこちらのセッション

2019.pmconf.jp

残念ながら資料非公開なのでキーポイントをいくつか並べると

  • Think Big
    • 大きな市場を獲りにいくことを意識しているか
    • ちなみに、これをメルカリ風に言うと Go Bold になる
  • Data Driven
    • 直感ではなく、分析能力が求められる
  • 小さく上手く失敗する
    • 逆に失敗がない人はチャレンジをしていないとみなされる
  • Why にfocusする
    • Why と問い詰めることは相手の人格否定でもなんでもなく、本質を見極めること

あたりで、これを述べられるのは完全に、やってきた年数が違う、経験の差という話な気もする。だからこそ貴重なセッションだったし、個人的なベストはこれだった。

もう一つ、こちらは フレームワークの情報がたっぷり詰まっている

www.slideshare.net

実際のカンファレンスの展示物制作を例にフレームワークの使い方を説明しており、理論と実践がとてもきれいまとめられた内容になっている。推敲を重ねた結果、詰め込めるだけ詰め込んだという力作っぷりが感じられる。聞いていて引き込まれる内容だった。

Engineering Manager界隈の体系知識

話は少し変わるが、最近のEM関連のコミュニティで以下のようなイメージの会話を見ることがある。

  • Aさん: こんな形式で1on1をやってみました!
    • Bさん: すごい工夫されていますね、参考になります
  • Cさん: 皆さんどうやってメンバーを評価していますか?
    • Dさん: うちでは○○でやっています
      • Cさん: なるほど、試してみます

これらのやりとりで気になるポイントは コンテキストの共有がない(少ない)のに、会話が成立している ということだ。 1on1も評価もプラクティスだし、背景には何か目的(課題)があるハズだ。それ次第によってアプローチは変わるし、他の事例が良いかそうでないかは判断ができない。 またその上段にはフレームワークと呼ばれるようなものがあり、どのフレームワークからのアプローチなのか次第で期待するものも変わる。

例えば、以前に書いた

masartz.hatenablog.jp

この記事などは、「コーチング」の分野に属するものであり、それについてノウハウが欲しい人には有用情報かもしれない(もしそうだったら嬉しい)。一方で「ティーチング」をした方が効果的なメンバーがいる場合、多分ほとんど役に立たない情報になるのではないか。

その意味では、前述の4段階のフェーズに分類してみると、フェーズ2のあたりでオレオレライブラリをいくつか公開してみたという内容に近く、一方それを体系立てて使える設計はまだできていないというのが自分の現状と感じる。
そうして自分自身を振り返ってみると、どういう背景やコンテキストというのが認識・共有が不十分なまま発信していたし、この学びがどういう知識体系の血肉になるのかがわかってなかったなぁという学びがある。

フレームワークをさらに俯瞰的に捉えて学ぶ

というような話を先日 @hirokidaichi と話していたのだが、その後に公開された記事がこちら

qiita.com

個人的に完全に俺のための記事だー、ということで勝手にアンサーソングを貰った気持ちになって読みました。 これは各フレームワークをさらにカテゴライズして関連づけているため、職種をまたいで俯瞰的に見える素晴らしい記事になっている。 Engineering ManagerやProduct Managerと言う単語そのもの(しかも各社ごとに定義が違う)に囚われるのではなく、どのような知識を持ち、何に取り組むかが大事なことであると思う。

イベントについて、登壇者による発表資料公開について

話は戻して、PM Confのイベント自体についての雑感

過去の情報を聞くと、発表資料が公開されないケースもあるらしかった。 そのせいもあってか、今回も多くの参加者がメモ代わりにスライド毎に写メしていて、それがとてもとても気になってしまった。 カンファレンスにどのように参加するかについては過去にもblogで書いたので、そちらも見ていただきたい。

SREcon19 Asia/Pacific 参加レポート - masartz->log(type=>'hatenablog')
 (カンファレンス参加とレポーティング の項)

多くの人をメモ取る作業から解放するためにも、登壇者の方には資料を公開していただきたいし、それを発表の冒頭で宣言してただきたい。なかにはConfidentialな内容の発表もあると思うので例外は当然あると思うが、今回は2日間ずっとそれが目立った。 撮る人が気になってしまうのは単純に個人の気持ちの問題だが、実際に写メる手によって視界が遮るのは物理的な問題だと思うので避けられるなら避けたい。 かくいう自分も要所のスライドを写メったりはする。即時にTweetしたい、みたいな欲求もあると思うので、完全に禁止とかまでする必要はないが基本は聞いて「理解する」ことに集中できるようになると良いと思う。

また、これも以前触れた通り、各セッションの内容を詳細にレポートする必要もないと思う。大事なのはアクションであり、各セッションから得られる具体的なNext Action は(セッションの質ではなく、聞く側のキャパ的に)多くない。逆にそれだけ得られれば十分ではないかと思う。

まとめ

再掲になってしまうが、
抱えている問題は何で、そのためにどういった体系知識(フレームワーク)が必要であり、何を身につけ・どうやって解決するか、
書くのは簡単だが、これは2020年以降も自分の課題です。

Engineering Managerをやっていた間の振り返りとまとめ

TL;DR;

Engineering Managerを降りることになりましたので、振り返りとまとめです。
※会社は辞めませんので、退職エントリではございません(別チームへの異動です)

時系列

  • 2017/10頃: SREのチーム内において会社のReport Line上にはプロットされないリーダー的なポジションをやりはじめる
    • この時はまだManagerではない。採用や評価に対するResponsibilityがないのがマネージャとリーダーの簡単な違い
  • 2018/04: SREのEngineering Managerに登用される
    • 当時 Microservices PlatformはReport Line上はまだSRE内に包含されていた気がする
    • どこかのタイミングで Report Lineとしても独立して、2チームを兼任する形で引き続き担当していた
  • 2018/10: 2チーム兼任からMicroservices Platform専任になる
  • 2019/08: Engineering Managerを降りる
    • 今回はココの話

マネジメントっぽいことだと2年弱。正式登用からだと1年4ヶ月。チームを絞ってからは10ヶ月。と、振り返ってみると大して長くない経験だったかもしれない。。

Engineering Managerやってる間の主なできごと

メルカリのMicroservices化が本格開始

それまでのMonolithic ArchitectureからMicroservicesに切り出し、Migrationしていくという意思決定がなされたのがちょうどマネージャに登用されたタイミングと一緒。この会社の大きな意思決定を推し進めるところからがMicroservices Platformのスタートだった

北海道地震

SRE側で大きな出来事は2018年9月に起きた北海道地震。データセンターの状況とサービスの継続を考えるまさに劇的な非日常だった。 その後のDisaster RecoveryやBCPと言った文脈にも繋がっていった。

チームの拡大と挫折

SRE/Microservices Platformそれぞれの活動軸があったが、自身のリソース配分としては大体四半期単位で2018/04-06はMicroservices Platformの初期推進が主だった一方、07-09はSRE業務や地震対応が逼迫していた。この間に両方のチームメンバーは合わせて20人位になっていた。2つの異なる軸を管掌しつつ、20人を担当するというのはさすがに無理だった。。
なので、この時ギブアップ宣言をして、SREの担当を外してもらった。SRE/Microservices Platformのどっちを取るかというのは悩んだが、mixiの時の経験と後悔から、サービスとして伸び盛りの時期にアーキテクチャ移行を行うという挑戦をどうしてもしたかった。なのでそれに最もコミットできるMicroservices Platform側を選んだ。

メルペイリリース

2019年2月にメルペイがリリースされた。メルカリと違い、メルペイは最初からMicroservices Architecutreを採用しており、徐々にMigrationされるメルカリと異なり、Platformにとって多くのMicroservicesつまり顧客が一気にリリースされた。その準備のために直前はチーム全体でフルコミットするなどしていた。

振り返り

過去のマネジメント経験を活かせたこと

自分以上の技術スキルの人のマネージャになる

自分より技術力が高く優秀な人が多く、技術的にリードするというようなことは全く必要なかった。これについて悩む人もいるかもしれないが、個人的には全くそれはなかった。ただ、技術力のキャッチアップは今回は失敗した。

まずやってもらう

↑の件とも絡むけど、基本的にやりたいようにやってもらって、それについてフィードバックするというのが理想だと思っていた。まず何か言うから始めていたらResponsibilityやOwnershipを持ってもらえない。これはタスク単位だけでなくチーム運営とかに対しても同様のスタンスでいたのだが、それが故に至らぬ部分もあったことが学びのパートに繋がる

意思決定を素早くする

これはかつての上司から学んだこと。どれだけ多く意思決定をするかがマネージャのパフォーマンスだと思っている。上長に「これどうしましょう?」と相談した事はたくさんあったけど、「どうやって決めたら良いでしょう?」というつもりで聞いていた。最初から答えの判断を仰ぐつもりで相談したことは少なかったと思う。

今回新しく経験して学んだこと

技術力キャッチアップとマネジメント作業のバランス

2チーム兼任時代はSREのOnCall対応も行っていた。これは現場感を保つためにとても良い作業だったが、マネジメントにかけられるパワーが割かれるという側面もあった。チームの拡大と共にマネジメント作業がパンクしたせいもあり、その時にOnCallから外れる決断をした。マネージャがどこまで現場で手を動かすかについては様々な議論があるが、この時に限っては手放すのが正解というかそれしか選択肢はなかった。
一方で、Microservices Platform専任になってからは、現場の作業をキャッチアップできていないという課題が起きた。それが起きてから振り返ってみると、OnCallなどで少しでも現場感覚を養っておけばという反省がある。特にMicroservices Platformのアーキテクチャについては元々経験があるなどのアドバンテージもなかったので、キャッチアップがより必要な状況で以前よりそれを怠れば、ギャップは危険域に達するというのは自然な話だ。 課題に対する危機意識はあったし、OnCallへjoinする予定は検討していたのだが、EMを降りるという意思決定を先にすることになったのは、見込みが甘かったのもまた反省要因であろう。

当たり前に自分がメンバーに求められること

元々自分自身マネージャに対する期待値が低かった事もあり、基本的に皆何も求めてないだろうというスタンスでいた。何かあれば言ってくるだろう、もっと言うと何かあっても言ってこないパターンだってあるだろう。 「俺らはお前の仕事なんか知らんけど、とりあえず俺らに害がないようにいい感じにやっておけ」 が期待値だと思っていた。
ただ、今回はマネージャとして動きやチームに対してなど色々な意見を聞かれたり求められたりした。そんなに求められることに慣れていなくて戸惑ったというのが正直な感想。今にして振り返れば、最初の時にマネージャに何を期待しているのか?を認識合わせしておけば良かったなと反省する。これによって数ヶ月分のパフォーマンスを変えられたかなと思う。

良かったできごと

採用活動

SRE/Microservices Platformそれぞれで多くの人を採用させてもらったが、特にMicroservices Platformの採用は時系列で振り返ってもおもしろかった。

  • 2018/04
    • マネージャになったこの時点でメンバーは4人、俺が直接採用に関わって入った人はまだいなかった。
  • 2018/07
    • 社内の別チームから異動という形で最初にチームを拡大する機会が訪れた
    • マネジメント観点で見ればSkill Transferを伴ったケースで、それに対する不安もあったが、「見知った社内メンバーすら受け入れられないなら外部からの採用なんかできないだろう」と思ってチャレンジしてみた
  • 2018/08
    • 初の外部からの採用。俺にとっては採用フローに関わってから初のケースだったのでやはり緊張した事を覚えている
    • 外国人ながらネイティブレベルの日本語を話すスキルの持ち主だが、それでもカルチャーマッチなど心配な点はあったが、「稀有なJapanese Speakerな人すら受け入れられないなら、Non Japanese Speakerな人なんか採用できないだろう」と思ってチャレンジしてみた。
  • 2018/10
    • 福岡在住の方で、初のリモートケースの採用
    • 実は全社的にリモートワークの前例はなかった。なので、その事例を作るために会社に提案するところから始まった
    • 基本的にリモートワーク導入時に課題となるのは、時差・物理的距離・物理的環境などが異なりそれがパフォーマンスを発揮してもらうのに影響してしまうケースがある、というあたりだ
    • それに対してこのケースでは福岡のBranch Officeでの勤務が可能だったので、
      • 時差: 日本国内なのでない
      • 物理的距離: 六本木オフィスから福岡オフィスはその気になれば3時間で行ける
      • 物理的環境: Branch Officeであるためファシリティや福利厚生は同じものを提供できる
    • であるため、それらの条件はほぼ取っ払えた。この状況で福岡オフィスで働き、六本木オフィスのメンバーと一緒にパフォーマンスを発揮してもらえれば、それによって『リモートワーク』が成功したという事例が作れる。全社視点で見て、リモートワークという取組を検証するのにこれほどリスクが少なく、パイロット案件として相応しいケースはない。逆にこれがクリアできなければ海外でWork From Homeする敏腕エンジニアを採用する、など到底できない。という点を推して採択してもらった。
  • 2019/02
    • 初のNon Japanese Speakerの採用
    • もうここまで来ると、「Non Japanese Speakerチャレンジしなくてどうする」だし、実はチームとしては発足時からSlackとドキュメントを全部英語にするのをメンバー達自身で徹底していた
    • MTGを英語化するというチャレンジにフォーカスできたのは、そのような環境を予め作り上げてくれていたおかげだ

振り返れば、どれも なケースばかりで似たようなパターンはなかった。採用の度に新しいチャレンジをさせてもらったし、その度にチームのダイバーシティを拡大できたとも思っている。採用した数で言ったら他のチームより少ないと思うけど、 採用によってチームのパフォーマンスを伸ばせたか で言ったら他のチームに負けてないと自信を持って言える。

チームが自律していたこと

学んだことの項から、メンバーの依存度が高いように読み取れるかもしれないが、実際はとても自律したチームだった。リクエストされる内容で、個人的な本音ベースで言えば面倒だったり、共感できなかったりで困った事ももちろんあったけど、マネージャとして考えてやった方が良いだろうなと思える事がほとんどだったので、やるべきだと思ったし、やって良かったとも思う。彼らのそういうリクエストは「自分たちでチームを改善していく」というアクションから来ているので、その志の高さがなにより受け甲斐があったポイントだ。

なんで降りるの?

いくつかあるけど、まぁ端的に言えば 力不足 が主な要因。『力』をもう少し分解すると

  • 技術的キャッチアップ
  • Proactiveなアクション

あたりになる。

技術的キャッチアップに関しては、EMが現場メンバーと同等(あるいはそれ以上)の技術力を有するというのは至難の技だ。少なくとも俺にとっては。 となると、どの程度劣っていることが許容範囲内なのか?おそらく「メンバーの技術力を見極め評価すること」「時に技術的な意思決定やメンバーフォローができること」だと思っている。 評価に関してはメンバーからも不十分であるというフィードバックを貰えた。ちなみにこのようなフィードバックをメンバーから貰える透明性と公平性も良かったと思っている。
後からのキャッチアップが難しい分、目標の認識合わせを厚めにするなどアプローチする時期を変えることで改善できた部分もあったが、完全に要求を満たすことはできなかった。やはり元々イチBackend Engineerの自分にとってContainerを始めとしたインフラの先端を掴むには時間と努力が足りなかった。

Proactiveなアクションは、例えばチームのロードマップを立てるみたいな先手を打つことだ。さらにここにCompany Valueでもある Go Bold という接頭語が付いてくる。そもそも自分にBoldっぽさがない事は自覚としてあるし、先手を打つような潜在的なニーズ・リクエストに応えるより、顕在化したIssueに応える方が得意かつ志向するタイプであるため、こういう動きはどうしても鈍くなる。
まぁロードマップそのものを作るのを求められている訳ではなくて、その成果をチームとして出せれば良い。誰がロードマップを作るのがチームにとって良いかで言うと、最高のTech Leadをおいて他にはいないのでそのための環境をどこまで整えられるかが俺のミッションだと思っていたが、そのアクションが不十分だったということだと思っている。
ちなみに、遅れさせてしまったが最終的にTech Leadがロードマップを導き出してくれたので、チームとしてはそれを元に前進できるようになったのは今後の良い話だ。

他にも理由はあるが、ポジティブなものとしては、俺より優秀なマネージャを採用できたから、というのももちろんある。
メンバー採用は前述の通り楽しみと成功体験があったが、マネージャ採用に関してはずっと叶わず、それが故に自分で抱えきれなくなってギブアップする(結果、兼任を止める)という事態を起こしてしまったのも課題だったが、最後はどうにか最低限の形は作れたと思う。

TIPS

今回のManager在籍期間でトライしたTipsをいくつか残しておく

1on1 docsの公開範囲

もちろんメンバーと1on1をやるので、MTG noteを作るのだが、メルカリではGoogle Docsを用いる事が多い。 その公開範囲はもちろん絞られるべきで、何も考えなければ 俺 + メンバーの2人のみの範囲になるのが自然である。なのだけれど、それに加えて俺の上長も必ず公開範囲に含めるようにしていた。
1on1とはマネージャとメンバーの信頼関係の積み上げ資料でもあり、メンバーの成長の助けにもなるべきものだ。メンバーが成長するために、彼らはマネージャに、あるいは会社に様々な事をリクエストできる。それに応えるのがマネージャの仕事だ。メンバー自身の悩みや課題を書いたり、会社への疑問やリクエストを書くこともある。もしこれらが適切に扱われない場合、メンバーはどうすれば良いか?クローズドなドキュメントで処理されていると、メンバーが何もできずに行き詰まってしまうので、それを避けるためにエスカレーション先を提供したかったというのが意図だ。

メンバーと初めて1on1するときにdocsの一番最初のアジェンダにはいつも以下のように書いていた。

閲覧権限は @XXX(上長の名前) にも付与してあるので、何かあればエスカレーションしてください

加えて、口頭で

もし俺と1on1をしていて、「こいつダメだ」と思ったら、この1on1 docsをエビデンスとして使いつつ、上長にアラートしに行ってください。

と補足していた。メンバーから見て、マネージャとの1on1というのは、そこが会社とのインタフェースでもあるので、フォールバック先を提供するのは会社というSystemのReliabilityのためには必要な事だ。

過去のBlog Postで書いた内容

Blogに書いておくと、こういう時にTipですと言ってスッと出せるのが良いところ

考えを言語化してアウトプットすること

メンバーと日々コミュニケーションしていく上で、バックグラウンドを共有しないと話せば話すほど認識がズレていくという課題があった。定期的に1on1していても、やはり踏み込んだ会話をしていくと、それぞれの考え方があるんだなぁ、というのを何度も感じた。例えば、評価フィードバックの時に『○○はGo Boldで良かった』と伝えても、なぜ・どのように・どれくらいそれが評価されるのか?とか、もっと突き詰めると『そもそもGo Boldって何なのか』みたいな話になったりする。
またそういうのって、別に誰か一人じゃないので、何度も言うことになる。となればDRYの原則に沿うのがエンジニアとしてすべきことなので、それもあってメルカリのValueの自分なりの解釈のようなエントリも書いたりした。

特にこの「何度も言う事を書く」っていうのは意識したことで、メンバーそれぞれに微妙に違う情報を伝達するリスクを防ぐ目的でもある。(むしろ、同じ情報を提供したとしても人によってそれぞれ解釈が違うものである)
ドキュメント化については、正直苦手でもあり、費用対効果を軽視していたが、Microservices Platformチームの文化としてドキュメントをしっかり書く事が効率的かつ合理的だと学んだこともあり、こうしてブログを書くことなどは意識してやってみたことだ。
またマネージャをやると、どうしてもコードを書いていた時に比べてアウトプットが減る感覚に陥る、というか事実減ると思う。やはりエンジニアとしてアウトプットしたくなるが、そこでコード以外のアウトプット方法として考えたのがドキュメント(=ブログ)だった。アウトプットしてモチベーションを保ったり、フィードバックを貰ったりという効果があるのはコードもドキュメントも変わらなかったのはやってみた良い気づきだ。

自分のマイナス評価結果をメンバーに共有した

四半期ごとに行われる会社の評価結果でマイナス評価を受けた際にそれをメンバーに共有した。これは会社にとっても非常にセンシティブな項目であり、気軽に真似しないでいただきたい。この共有ために気をつけたポイントはいくつもある。

まず背景として何故共有しようと思ったか?
一つは、こういうパフォーマンスだとこういうマイナス評価になる、だから皆はそうならないように気をつけてくれ。と反面教師の意味で伝えるため。
もう一つは、このマイナス評価はメンバーからのフィードバックも反映された結果となっている。つまり皆のフィードバックが評価システムの中で正しく扱われている。だから次の時も正直なフィードバックを書いてくれ。という事を伝えるためだ。
何故そこまでして伝えるか?
メンバーから見て、自分自身の評価者である人の評価を厳しく書くことは非常に勇気のいることだ。報復されて逆に自分自身の評価を下げられるのでは、と考える人がいてもおかしくない。なので書いてくれたメンバーには報いる必要があるし、書いてくれた成果がある事を知ってもらう事が重要だと考えたためだ。

これを実行するために具体的に気をつけたことは以下である。

  • 俺の評価者に事前に相談し、共有することを了承してもらう
    • 基本であり、全てはここから。俺の上長に対して共有の許可を貰った
  • 共有現場には評価者にも同席してもらい、補足説明もしてもらう
    • 評価内容が正しく伝わらないのは評価システムで最も避けなければならないことだ。そのために評価内容を正しく伝えられる人、つまり評価者が同席する必要がある
    • 逆に言うと、被評価者である俺自身が客観的に評価内容を伝えることなどできるハズがない。良くて通信簿の見せ合いっこになるだけだし、最悪の場合、評価者を悪者にすることもできてしまう
  • 公開範囲はメンバーにのみ限定し、その場以外ではその情報にアクセスできないようにする
    • あとから情報が独り歩きするのは要らない副作用やリスクしかおきない。同じく評価内容が正しく伝わらなくなる可能性がある。そのためドキュメントをシェアするのではなく、評価画面をその場でスクリーンシェアするのみに絞る
  • 評価内容のみ共有し、等級や給料などの情報は見せない
    • あくまでメンバーからのフィードバックの扱われ方を焦点にしているためである

それなりにインパクトのある情報であったと思うがメンバーは真摯に受け止めてくれたし、その次の機会の際に、遠慮して厳しい点を書かないようなメンバーがいなかったことが本当に素晴らしかった。Be A Proなメンバーに恵まれたと思う。
なので、全てのケースでこれが効果的であるとは思わないし、全ての評価結果がオープンであるべきとも思わない。周りの人の理解と協力があって成立した良いケースだったという意味でTIPsレベルの情報だ。

まとめ

チームが最高だった!みたいのを(思ってても)言わないのは、チーム自体はこれからも続いていくので、俺が俺の時間軸で結論づけるものではないかと思う。
やってる時は辛いことが多かったけど、終わってみれば楽しかったかなと思える経験でした。

振り返ってみればそこまで長い時間ではなかったことと、もう一つ「メンバーの1段上のマネージャ」の役割・成果しか出してない、というのがポイントかと思う。
1on1 docs に上長を入れること、評価結果を共有するのを上長に協力仰ぐこと、など成果の要所には俺の上長が存在する。これは上長がいるレベルのレイヤのマネジメントタスクが主だったという証拠であり、会社にとってより大きなインパクトを残せなかったのは課題かもしれないし、前回と比べて成長していない部分かもしれない。

体調的では、これまでストレスは胃に来るタイプだったのだが、今回のマネージャ期間においては色々趣向をこらしてきた。去年の夏にはメニエール病に片足突っ込んで、めまいで起き上がれないような事態になった。これは初めての経験だった。また、これはマネージャ業がどこまで関連しているか不明だが、膵臓の一部パラメータが異常値を計測したため、アルコールの摂取を医者に止められることになった。これによって実は、酒が今後一生飲めなくなった、というのが最近の出来事だったりする。(色々検査して命に別状ないので、当面はすこぶる元気です)

一方(良い方の話で)個人的事情もあり、マネージャ交代というのは前々から考えていた。そもそもマネージャに登用された際に宣言した目標が『俺よりスゴいマネージャを連れてくる』だった。実際の結果は元々のその予定とはタイミングと引き継ぎ期間が異なった事もあり、宣言内容をやや強引に実現する形になってしまった。

最初に宣言したことをちゃんと果たせなかったので、「マネージャ作業」というこのプロジェクトを振り返るなら残念ながら『失敗』だったと結論づけるしかない。 ただし、俺のプロジェクトが失敗したことと、メンバーが成長しチームが成果を出したことは違う話であり、それはその成功要因が俺にあるわけではなく、メンバー達自身にあるためである。

ちなみに次はそこそこ違うことをする予定ですがそれについては結果が出た時にエントリを書けたら良いなと思っています。
※【再掲】会社は辞めませんので、退職エントリではございません

SREcon19 Asia/Pacific 参加レポート

2週間ほど前にSREcon19 Asia/Pacific に行ってきました。何気に海外カンファレンス初参加。というわけで出張レポートです。

会社への提出レポートも兼ねているため、旅行的成分は少なめでお送りします。

カンファレンス概要

発表資料は現時点でもすでにProgramページに添付されていっている。 動画に関してもいずれ公開される予定のハズだ。

セッション内容

1st day

  • Use Interview Skills of Accident Investigators to Learn More about Incidents
    • 面接で使う質問力を用いてIncidentの原因究明に活かそうという話
    • 面接 -> Incidentという展開だけでなく、Managerの1on1にも通じる、あるいは使える話だった
    • Open Questionで相手から引き出すように心がける、などの話も盛り込まれていた
    • Templateを用意するのは面接のクオリティを担保したり、運用コストを下げるのに効果的だが、ポイントとしては Don't follow template の点もあったり工夫が見られた
  • Leading without Managing: Becoming an SRE Technical Leader
    • 結論から言うと、今回聞いた中で個人的なベストはこれ。Individual Contributorも、Tech Leadも、Engineeering Managerも皆見てほしい
    • Engineer Career Ladderの紹介もあり、その区分けが影響力によって上がっていくというのは弊社と一緒。その 影響力 をより具体的なケースで述べている
    • Task Drivenから始まり、Project Drivenになり、周りを巻き込みながら成果を大きくしていくのはしっくりくる
    • そうやって成果を出した Tech Leaderこそが 「They can change process」というのがカッコ良い
    • Be the someone in "Someone should"(= 皆が「誰かがやるべき」と思う【誰か】になる のが意味のある仕事であるというのは勇気づけられる言葉だ
  • The Bloomberg Story: Building SRE Teams in an "Immeasurable" Organisation
    • メルカリのMicroservices化にコミットしている人には見てほしい内容
    • 3年で500人以上のSRE組織にしていった話
    • メルカリと同様、Centralizedな体制で始まり、現状は半分がFeature開発チームにEmbeddedしている模様
    • 当然Centralizedな良さもあり、Infraが安定していることなどはその一要素、その通りだと思う
    • 組織拡大の過程にはInternal Transferもあったようで、これもメルカリが狙う形と同じ
    • ただしSRE mindset はとても重要だし、それもあって外部採用もできてくる
  • Retrospectives for Humans (a Crash Course)
    • ある意味日本ではそうそう聞けない「世界各国における英語の解釈の違い」について
    • 対立構造を生まない、とか断定系の表現はしない、とか言語が違っても気をつけることは一緒
    • また、SRE本にもあるPost Mortemのポイントとして「人間が頑張る」対応策はNGの話もあった
    • さらに「ヒューマンエラーは問題の根本原因にはならない」と断定しているのは素晴らしかった
    • おもしろかったのはJokeの使い方の例があったこと。この辺は日本ではないかもしれない
    • まとめると、コミュニケーションの問題は万国共通であり、この規模のカンファレンスでも取り上げられるほど大きな課題なのも万国共通なのだなぁ、ということ。
    • 特にメルカリはGlobal Tech Companyを目指す中で様々な課題に直面しているけど、きっとどこの会社でもある、あるいは乗り越えてきた課題なのだろうと思わされる内容だった
  • Releasing the World's Largest Python Site Every 7 Minutes
    • Instagramのデプロイの話
    • とても歴史的経緯が感じられる良いコンテンツだった
    • まず、おそらくInstagramモノリスリポジトリであるということ、アーキテクチャもオーソドックスなデザインであり、Djangoのアプリを本番にrsyncして、symlink切り替えてデプロイしている、ちなみに金曜日は安全のためにリリースしない、みたいな感じっぽい。それだけ聞くとInstagramもどこにでもあるwebサービスと変わらないのだなと思わされる
    • それがFacebookの後ろ盾を経て、大規模かつスピーディーに行われているというのが凄さ
    • 驚くべきことにステージング環境がなく、開発されたものは本番にcanaryリリースされて検証される。その目的がtrunk(master branch)を壊さない事。そのため、開発用のブランチでコードレビューが通ったものからcanaryリリース対象になる模様
    • モノリスのメリット/デメリットをそれぞれ考慮して対応し、かつそれができているというのが最もおもしろかったポイントだ。今メルカリはMicroservicesを選択し、自分もそれに向かって挑戦しているが、やはり答えは一つではないなとも思わされた。Miicroservices化は否定しないし、これからも推進していきたいがこれはこれで多くの学びがあった。

2nd day

  • Critical Path Analysis—Prioritizing What Matters
    • アジア版Uberとも言うべきGrabのサービスにおけるクリティカルポイントを考えた開発について
    • お金をやりとりするサービスで、お金が直接絡む機能とそうじゃない機能で重要度が違う、というのが一つのポイントだったように思う。そしてそれはメルカリもそうだな、と通じる部分を感じたのが印象的。
    • 逆に言うと、捨てるポイントを明確にするのも重要。
    • 「Developer focus to feature」というのは本当に同意で、Platform Teamもそれを目指している
    • Graceful Degradationの項目で、静的データはCaching効かせやすいみたいな話もあって、そうだよね~感が満載
  • Cross Continent Infrastructure Scaling at Instagram
    • こちらもInstagramの話。アジアのイベントなのに、データのBackup for DRに大陸をまたぐ話をヨーロッパとアメリカ大陸が舞台なのはちょっとおもしろかった
    • Cassandraの運用の話で、複数のDCにデータを持った冗長構成、でもヨーロッパでは2拠点しかないので、レイテンシを考えて東海岸も同じRegionとして扱う、とかスケールデカすぎ
    • 1日目のデプロイの話はスタートアップっぽさが残る話だったが、こっちはガチのGlobal Scaleだったのでそこそこギャップがあった。ので、登壇後の発表者を捕まえて聞いてみた話は後述
  • How to Champion SRE Investment to Different Levels of Leadership
    • What,Whyはあえて置いて、HowにFocusした内容だった
    • Individual Contributorの人に見てほしいかも
    • とてもインタラクティブな部分を重視していて、最後にセッションの内容をクイズ形式でおさらいするなどの取り組みがおもしろかった
  • Distributed Sys Teams
    • Fastlyにおけるリモートワークが超いい感じだぜ!っていう話
    • 「it's easier said than done」と途中で出てくるのだが、聞いていて「いやー、これすごいけどホントにできてるの?どうやって?問題起きてないの?」と思わざるを得なかった
    • 個人ごとのパフォーマンスのための非同期性を活かしつつ、チームワークとしての同期性(チャットよりビデオ、時には雑談だけのビデオコミュニケーションも)を意識しながらやる、っていうのは確かに大事な事だが言うより難しい
    • これを実現するために大事なことは、集合チームと一部のリモートチームみたいな構図だとうまくいかなくて、どうしても集合チームが主体になりがち。それは力関係の問題ではなく、雑談してる中でやる事が決まって、みたいな流れで物事を進んでしまうことが自然にある。それを意識的に避けないと成功しないと思う
    • Platform Team も1人だけ離れたオフィスで働いていて、上記のようなリモートから見たサプライズな動きがないように気をつけている。具体的には議論はissueを作ることから始めているので、知らなかった話というのは基本的にないハズ。issueの進捗が雑談の議論を元に進むかもしれないが、それもissueを見ていればキャッチアップ可能なハズだ。
    • あるいは、マネージャーとしてはリモート側の声はよく聞くようにしていて、先日もチーム全体の定例MTGの頻度を減らして業務効率を上げる取組をしてみたが、チームとしての一体感に対して懸念が上がってきたのがリモート側が早かったので、定例の頻度を少し戻すというのは即時に判断した。
    • いずれにしても、Fastlyの状態はすぐには実現できなくて、そのためにはまずマイノリティリモートチームを作ってワークさせないといけない。大体のケースがここで失敗して、その先に進まないっていうクエストなんじゃないかと思うので、難しいけど良い話だった

3rd day

  • Lightning Talks
    • ここは Platform Teamとして一つのハイライトであり、@dtan4 による発表を見るのがメインミッションだった
    • 10人以上のLT発表者から事前にスライドを集め、1枚15秒で自動ページ送りする形式で固定、発表者間に特に区切りのスライドはないので、ドラが鳴ることもなくどんどん進んでいくLTだった
    • そこまで自由が効かない状況で、Platform Teamがこれまでなぜ/どうやって取り組んだかをコンパクトにまとめて発表していたのがステキだった

speakerdeck.com

  • Ethics in SRE
    • これが大トリのセッション
    • これに関しては、わかったことじゃなくて「わからなかったこと」の話
    • 正直倫理という話題について、ネイティブスピーカーの人が息切れしながら話す英語を聞き取り・理解するのは俺の今の語学力では不可能だった。完敗。
    • 後述するが、はっきり言って理解できなかったセッションもあり、最後のこれもその一つ。もちろん事前に予想していたことだが、この「わからない」という学びは大きかった

その他聞いたセッション

セッション内容以外について

ダイバーシティ

会場に女性参加者の数が多いことに驚いた。各社必ずいるし、集団を成しているところもある。日本でSREやインフラのイベントをした時、一体どれだけ集まるだろうか・・ 具体的な数値で、Googleの人と話しをした時、シドニーオフィスでは100人以上のSREがいて、うち20%は女性だそうだ。結構驚きの数値だと思う。

セッションへの参加率

YAPCのAsia以外だとセッション聞かずにコード書いているだけの人とかいるようだが、フロアをウロウロしている人は少なかった気がする。ただ、そもそもの参加率として3日目とかは空席多いなとは思ったので、徐々にドロップアウトしているようには感じられた。 その辺は参加費も影響しているのかもしれないが、さすがにそれなりの額を出しているだけあって

  • そもそも会場が豪華。日本で言うなら、ビックサイトか国際フォーラム的なところ。
  • セッション切り替えのたびに各席に水が補充される
  • フロアではコーヒー飲み放題 + 軽食
  • ランチ・懇親会もしっかりしたものが提供された

あたりは流石だなと思った。電源タップの数が少ないくらいしか不満はなかった。あと、会場がクソ寒かった。

発表のうまさと話のスピード

やはり発表に慣れている人はゆっくりしたスピードで聞き取りやすかった。一方で、慣れてない訳ではないのだろうけど、かなり本気で喋る人のはさすがに聞き取れなかった。。特に技術系の話であれば、スライド内にコードが載せられて雰囲気が掴める、とかも期待できるが今回は特に技術系トークではなく、組織だったり考え方を聞くようなセッションをずっと回っていた。その系統だと抽象表現のスライドのパターンも多く、50分のセッションの開始5分で、「こりゃ無理だ」と思ったものがあったのも事実だ。 一方で、特徴的におもしろかったのは初日のInstragramの人で、おもいっきり原稿を顔の前に持っていって読んでいた。あそこまで潔い判断もできるのか、というのは驚きだった。

カンファレンス参加とレポーティング

少し上で参加費について触れたが、それ以外にもフライトチケット・ホテル等の費用があってカンファレンスに参加してきた。その費用についてはすべて会社が負担してくれた。これには素直に感謝しており、それには応える必要があると思っている。その手段としてこういうカンファレンスレポートがある訳だが、実際どういう項目を書くべきか?

個人的には、セッションのメモをひたすら取っただけのレポートは意味がないと思っている。今や大体のカンファレンスが、資料は発表者が公開するか、あるいはカンファレンスページにリンクされ確認できるし、セッション内容を録画した動画すらも公開される(今回のSREconもそう)。それだけの一次情報に容易にアクセスできる中で、第三者のメモにどれだけ意味があるか。。速報レベルで公開するか、発表者以上に資料に対して補足が述べられるくらいのアドバンテージが必要になると思う。

では何を書くか?個人的に得られた経験をそのまま書くのが良いと思う。特に現地に行ってしかできない経験をしてくるべきで、他の参加者と話す、コネクションを作る、イベントの内容ではなくその場から感じた事を伝える、などかと思う。 例えば感じたこととして前述のダイバーシティの件など、メルカリとして目指すところについて他社と乖離があるのを伝えるのは必要だと思ったので書いたし、他の日本人の方でもセッショントークをしている方がいたというのも「遠くでやってるイベント」じゃないというのを伝える意味では書き残しておくべきかと思う。

という思いは持っていたのだが、ちょうどGoogleの人と話した時にどうしてるのか聞いてみた。 基本的な考えは同じで、参加者全員で一つのGoogle Docsを共有していて、セッション内容などはセッションごとに各人が情報を書き足していく運用らしい。それも内容のメモというよりは、それを見てどう思ったかを各自が書いているようだ。

Shared Docsはなるほどな、と思いつつ基本的な考え方がマッチしていたのは個人的に嬉しかった。

Discussionした情報アレコレ

マレーシア在住のエンジニアの方々

こちらが参加者パスに「We are hiring」のシールを貼っていたおかげで話しかけてもらえた。 採用しているよ、と言ったのだが「どこのオフィス?」「東京だよ」「あー、そう、OK、ありがと」みたいな感じでかわされてしまった。多分シンガポールオフィスの企業を狙っているのかなぁという印象で、まぁ開催現場ということもあるがAsia/Pacificの中心は東京よりもシンガポールにやはりなりつつあるのかも、と少し考えたりした。

カリフォルニアのGoogle SRE

Youtube Adsをやっている人。それだけで数千人のエンジニアがいるっぽい。 GoogleのSREは、開発チームが自チームのheadcountを消費してアサインされている。 開発チームとしては、開発するためにSWE(SoftWare Engineer)を増やすか、信頼性のためにSREを雇うかを選択する形になる。
という話は以前にも聞いていて、休憩時間で話してこの辺の話題で終わってしまったのが残念。 ここでも英語力の壁に阻まれて、まだ聞いたことない部分に踏み込めなかったのが惜しかった。

Instagram の発表者

2日目のセッションの発表者。 初日のセッションがInstagramのスタートアップ的側面を強く残した内容になっていたのに対し、とてもスタートアップに所属していたエンジニアがやるのとは大きく毛色の違うスケーラビリティの話をしていたので、「スキルセット違うと思うけど、スケールに関することはやっぱりFacebookエンジニアがやるの?」と聞いてみたらそうらしい。先のGoogleの例とは違い、Instagramから見てFacebookはセントラルなインフラ部門っぽく見えてるようで、必要に応じてサポートしてもらえるようだ。Googleのように、headcount使って来てもらうというよりは、所属はお互い違うままで連携しているっぽいことを話していた。 この辺りも各企業ごとに文化や仕組みが違うので、正解は一つじゃないなぁというのを再確認できた。

まとめ

一言で述べるなら「全く知らなかった新しい発見はなく、それが良かった」となる。 もちろん各社の人と話して得られた気づきはある。一方で、セッション内容でいうと、自分たちができていること/できていないけどやりたいこと、がほとんどのように感じられた。もちろんできていないのだけれど、だからこそ今のやり方を続ける事は案外間違ってないなと確認することができた。

もう一つは英語力で、やはり聞き取れなかったセッションは悔やまれる。日常においてメンバーと英語でコミュニケーションすることも英語学習のモチベーションの一つだが、貴重なカンファレンスの機会に逃さずそれを聞きたい、というのは次回参加までの目標になった。 アジア開催は時差もほとんどなく移動も長くないし、行きやすくて良かった。SREcon自体は各Regionで行われているが、とりあえず来年のAsia/Pacificにはまた参加したいなと思えた。

チーム内Reviewを導入して、チームの自律性が高まった話

チーム内Peer Reviewを導入した話です。と言うと、チーム外Peer Reviewがあるのか?という疑問が湧くと思うので、まずその前提から。

メルカリは四半期ごとの評価タイミングでPeer Reviewを全社で実施している。

  • 各メンバーが任意の3人を指名する
  • 指名されたメンバーはValue軸に則って、Reviewを書く
  • 内容は本人及び上長に開示され、評価の参考情報として使われる

簡単に説明するとこんな感じ、割とよくある評価システムだ。まずは自分がイチ個人としてこのPeer Reviewをどのように扱っているかを説明する

打ち上げ花火、下から見るか?横から見るか?

任意3人の対象に基本的に制限はない。席が隣の人から、その気になれば社長を選択することも可能だ。 この時、Reviewで何を聞くか、ということにもなるが、自分の中では「影響力のベンチマーク」として使っている。 前職のVOYAGE GROUPでもCCFB(Creed Competency FeedBack) と呼ばれる同様の制度があった。この時は5人まで選べたので、その時に選んだ例が以下。

  1. 自部署(子会社)のリードエンジニア
  2. 自部署(子会社)のCOO
  3. 他部署(別の子会社)のリードエンジニア
  4. VOYAGE GROUPのCTO
  5. VOYAGE GROUPのCEO

これは自分からの業務範囲(=距離)が近い順にSortしている。ここで期待するのは、「どこまでの人から具体的なFeedbackが返ってくるか、逆にどこのFeedbackから曖昧になるか」の境界を見つけることだ。 具体的なFeedbackが返ってくるということは、自分が業務でその人に対して何かしらの影響を与えられていた(=仕事していた)ということだと捉えて、成果を測っている。前述メンバーとの距離を図で表しながら各人に聞いた狙いを整理するとこんな感じ。

f:id:masartz:20190606011358j:plain

  • 自部署(子会社)のリードエンジニア
    • エンジニアとしての自分のアウトプットができている
  • 自部署(子会社)のCOO
    • 自分のアウトプットが事業成果に繋がっている
  • 他部署(別の子会社)のリードエンジニア
    • グループ内の他の部署にまで自分のアウトプットが波及している
  • VOYAGE GROUPのCTO
    • グループ全体で見て、エンジニアとしての自分の成果が出せている
  • VOYAGE GROUPのCEO
    • グループ全体で見て、自分の成果が事業貢献に繋がっている

ちなみにこんな偉そうな事を聞いているが、実際は各所から具体的なFeedbackが来た!みたいな理想ケースではなくって、「自分の成果も全然まだまだだなぁー」と思わせるありがたいお返事をいただきました。

ただ、このように必ずしも良い評価だけでなく、それ以外の評価が来ることを求めて良いのが、参考情報として扱われることの最大のメリットだ。

Platformにとって顧客はDeveloper

メルカリに話を戻すと、今所属しているMicroservices Platform Teamは基盤構築のチームだ。 この時、社内のDeveloperは同僚でもあり、顧客でもある。Peer Reviewはその顧客の声を聴く貴重な機会といえる。

前述の「影響力ベンチマーク」を当てはめると例えば以下のように分類してReview相手を選ぶこともできる

  • 自分たちのPlatformをヘビーユースしてくれるDeveloper
  • 自分たちのPlatformを使いはじめたばかりのDeveloper
  • まだ自分たちのPlatformを提供しきれていないDeveloper

分類方法はこれに限らないが、いずれにしても顧客の声を大事にしてほしいと思っていて、 そのためメンバーには「Peer Reviewはチーム内のメンバーではなく、チーム外から選ぼう」と依頼してきた。 結果として、チーム外のDeveloperからありがたいFeedbackを実際いただけたので、良かったと思っている。

一方で、メンバーからは「チーム外から聞く意図はわかるし、実際のFeedbackも嬉しい。しかし、同じチームメンバーが自分の仕事をどう見ているかも知りたい」という意見もでてきた。 Platform Teamの各メンバーの良いところは、お互いをリスペクトし合ったFeedbackができることで、やはりタッグを組んで仕事をしているのでFeedbackの内容の濃さは一番だった。なので、その意見を聞きたい気持ちもよくわかる、ということで、Peer Reviewにチームメンバーを混ぜるのを許容していた時期もあった。しかし、これはもはや限られた3人枠をチーム内外で奪い合う方がもったいない。そこで「チーム内Review」を独自実装し、チーム内からのReviewはこの独自の仕組みで集める、その分本来の全社Peer Reviewはチーム外からのFeedbackを貰う、というように棲み分けするのを試してみることにした。

Release CycleとFeedback Cycleの同期

このチーム内Review、実はまだ2回しかやっていないのだけど、既に2パターンのやり方を試している

  1. 四半期単位でチーム内から任意の3人選んで、Feedbackを貰う
  2. Release単位で 同Release メンバー同士でFeedbackをし合う

1つ目はシンプルで図にすると、こんな感じ。Review相手を選ぶリクエストの矢印は簡易的にTech Lead, Bさん、Eさんの3人分のみ表現している。

f:id:hossy0108:20190605073217j:plain

チームのメンバー間でフラットにReviewする形とした。基本的には全社Peer Reviewのスキームをそのままチーム内のスコープで実現しただけだ。Engineering Manager(= masartz)が輪に入っていないのは、Managerとしてのオフィシャルな評価があるので、俺からのFeedbackはその時伝えられるからだ。

一方、2つ目のやり方の背景を少し補足するのに、先日開催した Mercari Meetup for Microservices Platform #2 でTech Leadが発表していた素晴らしい資料を先に紹介したい。

この説明にあるように、現在は6weekのリリースサイクルでProjectを回している。会社組織的には1つのPlatform Teamの中で都度ミニチーム(下記で言う、Release1,2,3それぞれ)が組成されるイメージだ。

f:id:hossy0108:20190605073239j:plain

各Release Teamには Release Leadを任命していて、そのReleaseのOwnershipとResponsibilityをTech Leadから委譲されている。Tech LeadはそれをしながらPlatform Team全体のアウトプットにコミットしている。

このミニチームを6週間単位で運営し、成果を出して解散する。次の6週間はまた別のチームが組成され、Release Leadも変わる運用だ。例えば、次はEさんとCさんのペアでチーム組成され、EさんがRelease Leadを担うチームになるかもしれない。

Peer Reviewに戻ると、各Releaseチーム内(例えばCさんとAさん)でReviewするのを基本とし、Tech LeadはRelease ReadとReviewしあう形にしている。(この図も簡易的に一部の矢印は省略している)

実際どうだったか?

チーム内の独自実装について

全社Peer Reviewは四半期末に実施され、自己評価の記入などと合わせてやや忙しくなる。そこにチーム内Reviewの記入タスクまで積んでしまうとメンバーにとって過負荷になってしまうので、ちょっとだけ時期を前倒して実施して負荷分散している。それもあってか、チーム内外それぞれのPeer Reviewを皆しっかりと書いてくれている。特にチーム内ReviewのFeedbackは受けた側の満足度がとても高いため、この取組を継続したいと言ってくれている。

四半期単位とRelease単位の実施時期について

1つ目のやり方でやると実施時期は四半期単位になる。それは全社的に見れば最短期間だが、チーム内で見ると2回分Releaseが回っている。つまり、1つ前のReleaseの時の事を思い出しながら書くことになるのでどうしても内容が薄まりがちになってしまう。また、必ず書いてもらうようにしている「もっと良くしたほうが良い点」が受け手に伝わって改善に取り組むまでにラグができてしまう。という経緯でRelease サイクルと同期している形にしてみたが、そちらの方がしっくり来ているようだ。

マネージャー視点での感想

予期していなかった成果として、俺がFeedbackしたい内容と同じことをメンバー自身が感じ、それをチーム内Reviewで伝えてくれていたりする。これが本当に嬉しい。例として、メンバーAからメンバーBへの課題をマネージャーが吸い上げる必要もなければ、マネージャーが思う事をわざわざマネージャー自身で伝えなくても代わりにメンバーAが伝えてくれる。それによって、チーム内のお互いの信頼感とリスペクトが高まっていく好循環が生まれている。チームが自律的にお互いを補完しあっているのは「チーム」という単位でのセルフマネジメントができているとも言え、マネージャーとして感謝しかない。チーム内Reviewの仕組み改善も、「2パターン目のRelease単位でやってみよう」というのはメンバーからの提案であり、正直俺は1つ目のパターンの方が良いと思いつつ試してみたら思った以上に好感触だったので、「じゃあ、2パターン目で行こう」とコロッと方針転換できたりした。

まとめ

いくつか話題があったが、まとめるとどれもFeedback Cycleの話である。

  • 個人として、前職のPeer Review 指名方法や、他チームのDeveloperのReviewを貰う狙いの件
    • 自分との距離間を元にして改善点を見つけ、それを次に活かすということ
  • マネージャーとして、メンバーにどういうReviewを受けてもらうかの試行サイクルの件
    • 受け手としての感想をメンバーから貰い、書き手をどう見つけていくかに活かすということ
  • チームとして、チーム内ReviewによってFeedbackを交換する件
    • マネージャーから見て、メンバーが自律的に改善しあうということ
    • また、それをするためにFeedbackの仕組み(チーム内Reviewの実施時期)すらも自分たちで改善するということ

ということで、とにかくトライアンドエラーで改善していって成果を出すという話でした。

メルカリのValueの自分なりの解釈

この前の評価の時期に整理した内容。少し遅くなってしまったが書いてみた。 評価について、特にメルカリでは360度評価的に近いPeer Reviewも実施している。その際にもValueに基づいてFeedBackするのがベースになっており、Valueについて改めて考える機会と言える。
というわけで自分なりのValueの考え方を整理してみた。

3つのValue

おさらいだけど、メルカリのValueは以下の3つ

  • Go Bold(大胆にやろう)
  • All for One(全ては成功のために)
  • Be Professional(プロフェッショナルであれ)

実はこれ以上の説明はない。各Valueについて敢えて細かく具体的な整理をしないのは経営の意図したものだ。 各人が各Valueはどういうものなのか考え・議論し、体現していくことによって会社のアウトプットに繋がる。 というわけで自分なりに考えてみるが、自分の中でのポイントは
「それぞれのValueの関連性はじゃんけんみたいなものである」
ということだ。

Go Bold or not ?

たまに聞かれる事として、「GoBoldかどうかの定義が欲しい、でないと他人にGoBoldか否かを伝えられない」とかがある。 これに対しては、各Valueはそれ単体で Yes/No という見方をするものではないと思っている。 もし各Valueの定義がありそれに沿って伝えるのであれば、例えば「あなたはGoBoldじゃない」という使い方をするということになる。しかし、それを伝えたとしてその人のためになるか?そうは思わない。是正という形でその人のアクションが狭まるだけである。 じゃんけんみたいと言ったのは、

  • Go Boldが過ぎれば Too Boldに
  • All for Oneが過ぎれば 主体性のなさに
  • Be Professionalが過ぎれば 固執した動きに

それぞれ繋がってしまう脆弱さが各Valueにはある。 Go Boldと言って無茶な事をするのは良くない。良くない事をどう計るかで言うと、「それはAll for Oneなのか?」という軸になる。大胆な行動は成功のために行うべきでそれを見過ごしてしまわないように「All for Oneを意識しましょう」と伝えられる。

「GoBoldじゃない」
と言って相手の行動を制限するのではなく、
「All for Oneを意識しましょう」
と言ってBoldさをより良く伸ばしてあげる方が相手のためになるハズである。

All for One

All for Oneを意識しすぎると、主体性がなくなったり、思考停止してしまいがちである。「(成功のために|皆のために)これを (している|しなければならない) んだ!」という考えや行動は一見立派だが、それが偏りすぎると相手への強い押し付けになったり、あるいは自身のアクションが凝り固まってしまう。 そんな時にBe Professionalを意識すると、「この仕事は本当に依頼すべきなのか?自分でもっとできることはないのか?」だったり、「自分が持っているこのタスクは実は捨てられるのではないか?」という気付きだったりが生まれると思う。

Be Professional

Be Professionalはエンジニアとしてやはり頭に入ってきやすい。だからこそ日々考えていく必要がある。 誰しもクラス設計について延々と悩んだり、テストカバレッジをひたすら上げまくる、ということをやったことがあるはず。アーキテクチャの拡張性や保守性を考えれば考える程設計に悩み、テストを増やし、というアクションに走りがちである。そしてきっと多くの人が、それでも考慮しきれない変更ケースや未知のバグにぶち当たったと思う。結局完璧なものなど作れないのは仕方なく、それを追い求めるのはToo Professionalだと思う。
そんな時に「もっとGo Boldに」と言ってもらえることで、開発はあくまで手段であること、リスクテイクの判断、そして何よりビジネスやお客様の重要性を思い出せるようになる。

ループではなく、スパイラル

こんな感じで話はGo Boldに戻ってくる。これは無限ループではなく、スパイラルである。 これらを繰り返しながら「新たな価値を生み出す世界的なマーケットプレイスを作る」というミッションに取り組んでいくのがValueの意味だと思う。

もっと明確に定義すべきではないか?の話に戻ると、そもそも多様な人材がいる中で、各人にとって基準が違うのは当たり前で、エンジニアがやる開発ひとつとってもPMから見たらBe Professionalになるかもしれないし、同じものを他のエンジニアが見た時に技術的にもっとGo Boldにできるのではと見えるかもしれない。どちらも正しいし、どちらを伝えるのもその人のためになるだろうと思っている。

上記はあくまで個人的の見解です

なんか会社に書かされていると思われそうな内容だけど、上記全て個人の見解で、本音ベースで言うなら本当に良くできてるなーと思う。 他の人も言っていたが、メルカリのValueを参考にする、というかValueを考えるとメルカリっぽくなってしまう会社は実際にあるらしいが、それも無理もないだろうと思うくらい良くできていると思う。実際俺が将来どこかの会社に行く時には、このValueと比較して会社を選ぶだろうなと思う。

まとめ

そんなValueを経営陣は本気で議論していて、変わる可能性すらあり得る。それすらもまたGo Boldだし、All for Oneで、Be Professionalに変えていくのだろう。

さて、外部に向けてこんな記事を書いてみたが、これがValueに沿ってどう捉えられるのかもまた興味深い。人によって意見は違うだろうが、その意見もまた俺のためになるものだと思う。

最後に、こんな感じでValueについて議論し合えるEngineering Managerを大募集しているので、ぜひよろしくお願いします。

mercari.workable.com

Meetupもやります!まだ参加募集中なので、ご興味のある方は是非お申込みください! connpass.com