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

研修中に爆睡して学んだ 1on1 で「待つ」ことの大事さ(How I learned the importance of patience in one-on-one MTGs from sleeping)

(English follows)

前置き

この記事は Engineering Manager vol.2 Advent Calendar 2018 6日目の記事です。

メルカリで Engineering Manager をしている masartzです。
今日は、先日自身が体験したことから得た、1on1の学びについて書いてみようと思います。

1on1コーチングの研修

メルカリでは、急拡大する組織に対応するため、Managerなどの中間層の教育・育成も急務となっております。Managerとしては、HR部門のサポートもあり研修プログラム等も受講する機会が与えられます。

先日 「1on1コーチング」のための時間があり、外部のプロコーチの方を相手に「コーチングを受ける側」の立場から勉強しようという機会でした。

当日、会議室に着き、挨拶と自己紹介を済ませ、いよいよ本題です。

コーチ:「最近の課題はありますか?」
masartz:「(もちろんない訳ないので、)あります」
コーチ:「例えばどんな課題ですか?」
masartz:「Aとか、Bとか、あるいはCとか、、(他にもたくさんある。。)」
コーチ:「なるほど、そうですよね。その中で敢えてこの場で話したいものはありますか?」
masartz:「うーん・・・」

ここで、とても困ってしまいました。失礼ながら赤の他人にいきなり話したい話題でもない。 俺としても日々悩みながら、周りと相談しながら進めていくべき事で、パッと答えが出るとか期待してないし、期待しちゃいけないとも思っているからです。

そんなようなニュアンスは伝え、「じゃあ、もっとたわいのないことでも、なんでも良いですが、どうですか?」と話題を振り直してもらいましたが、どうしても「この場を有意義に使えるような、何か適当な話題を探さなければ」という思いが頭から離れず、ウンウン唸るばかりでした。

実はこの日とても体調が悪く自分でも、頭回ってないなー、と思っていました。

さすがにラチがあかないので「ゴメンなさい、体調悪くて本当に頭が回らないです」と正直にお伝えしました。その後も、ストレッチをしてみましょう、とかなんとかきっかけを探そうとしてくれたのですが、最終的に「今、仕事関係なく本当に何をしても良いなら何したいですか?」と問われたので、答えました。

「正直、、寝たいです。。」

その返事は、ビックリするもので

「わかりました、じゃあ寝てみましょう!」

でした。

徹夜プロジェクトでよくやる、会議室の椅子を繋ぎ合わせた簡易ベットをその場で用意していただき、本当に寝ることになりました。その際に、「あとで起こしますね」と言っていただいたので、5分か10分仮眠したら起こしてくれるのかなと思って、試しに寝てみることにしました。

その後、起こされた時は研修時間の終了5分前でした。
90分の枠を用意していただいて、最初の30分が最初の話題探しの時間、なんとその後60分近く寝ていたそうです、、

「無理にアクションしても得られるものはない、まぁこういう時もありますよ」と全く意に介さない笑顔で場を絞めてくださったプロコーチの方には申し訳無さと共に、大きな勉強をさせていただいた感謝がありました。

この件から学んだこと

一種のコミュニケーション研修でしたが、そんな状況だったのでコミュニケーションした上でなにかを得たっていうものはぶっちゃけなにもありません(当たり前)。

しかし、この異常とも言える機会は、1on1において 相手の状況が好転するまで極限まで待つ という事の究極のベンチマークだったなと思います。 これはこれまで自分がメンバーとの1on1の場において、 その場をいかに充実させるか 、っていう事を考え、苦心していた身として完全に真逆のアプローチでした。
あそこまでのベンチマークを取る事はなかなかできません。60分寝かせて、MTGを無価値のまま終わらせる事を許容できるのが本当にすごいし、俺が外部の人間として顧客企業で研修する立場なら絶対途中で起こすだろうと思いました。

それ以降の自分の1on1スタイル

前述の通り、自分の1on1の課題はいくつもあります

  • 業務の細かい連絡や確認など、自分から話す・伝える時間が多い
    • 典型的に気をつけなければいけない事例の一つ、1on1の主役はあくまでメンバーです
  • メンバーへの効果的な話のフリができない
    • せいぜい「最近どう?」からの雑談レベルに終始してしまう
  • メンバーからの話題を引き出す力が弱い
    • 引き出そうとしても「うーん、特にないです」という返答をよくもらう

ダメなあるある典型例ではないでしょうか。
だからこそなお頑張って充実させようと思うと、より自分の話す時間が増えてという無限ループですね

なので、この件以降に決めた事としては

例え相手が寝る事だって受け入れる、もし寝て起きたらスッキリした頭で「そういえばこの前こんな事を考えて・・」とでも話を切り出してくれたら最高

と考えるようにしました。

具体的に1on1の途中でネタ切れしたら、
「じゃあこのままお互い自分の仕事でもして、なんか思いついたら話してー、なんも思いつかなければそれでも良いよ」
と言いつつ一緒に過ごす、などのアクションをするよう心がけています。

もちろんこの件をグローバルメンバー含めたチーム全員にも伝えようと思い、この記事も日英で書いています。

まとめ

1on1の方法論に限りませんが、対極的な考え方・やり方から思考の幅を広げるのは様々な場面で有用です。 それが難しいのは、対極的な考え・行動を自分自身ではなかなかできない(だからこそ対極にある)からです。 今回、プロコーチという非常に思考の幅の広い方の助けを得て、そのような事を学べたのは非常に良い機会でした。

宣伝告知

さて、メルカリではまさに様々な思考を持ったEngineering Managerを探しています。 俺のポジションも絶賛募集中であり、研修中に寝るやつより働ける!と思う方からのご応募お待ちしております。

mercari.workable.com

メルカリのこれからを担うMicroservicesのPlatform部分を作る大事な仕事です。 どうぞよろしくお願いいたします!

明日は fukuo33 さんです、どうぞお楽しみに!


Introduction

This article is the 6th edition of Engineering Manager vol.2 Advent Calendar 2018.

Hi, I'm masartz and I am an Engineering Manager at Mercari. Today, I’d to write about a great learning opportunity I had recently.

One-on-One Coaching Training

At Mercari, educating mid-level members like managers has become a high priority because our organization is growing so quickly. As part of these efforts, managers like myself are given opportunities to take training courses organized by the HR department.

The other day, I was scheduled to take part in a training session called One-on-One Coaching. From what I had heard before the session, a professional coach, who was an external contractor, would be teaching me all about coaching.

On the day itself, I entered the MTG room on time, we greeted each other, did quick self introductions and then moved to the main topic of the training.

Coach: So, what topics would you like to discuss with me? How can I help you?
masartz: Of course I thought about it before coming, and I have a few things...
Coach: For example?
masartz: Well, there is the issue A, B, and C. And actually I have more as well, but...
Coach: I see. Which of those do you want to discuss now?
masartz: Umm...

I was in trouble at this point. I realized I couldn’t really discuss any of these topics effectively with a stranger. The topics were things I was worried about and had been discussing with my colleagues to try to resolve. Even worse, they were not things I could get definitive answers about, and I shouldn’t expect to.

I told him what I was thinking and he said that it was no problem. He suggested we we just talk casually for the rest of the session.

But this idea bothered me too because I was thinking that I had to make good use of this training. I couldn’t just waste this opportunity with a professional coach. I had to come up with a good topic for us to discuss.

Honestly speaking, I was not feeling well that day. My physical condition was poor and I couldn’t really think clearly.

By this point, the conversation had basically stopped since I had take so much time to think about what to do. So I finally told him the truth as politely as I could, that I wasn’t feeling well and I couldn’t think clearly. I felt terrible and apologized.

First he recommended that I stretch or grab a coffee or something to refresh. I knew none of those things would work and I still didn’t know what to do. Finally, he asked an unexpected question.

Coach: If you could do anything right now, anything at all, what do you want to do?
Masartz: Actually, I really want to take a nap.
Coach: Got it. That’s what you should do then.

Of course I was really surprised. But he didn’t miss a beat and started building a bed for me by pushing some chairs together. It was something I hadn’t seen in a long time, not since when I first started working many years ago.

Despite some reluctance, I followed his instructions and got comfortable. He said he would wake me up later. I figured I could take a quick 10-minute nap and then we would restart the training session.

When he woke me up I saw there were only 5 minutes left in the session. I started to do the math: it was scheduled to be a 90-minute MTG, we had spent about 30 minutes introducing ourselves and trying to find a topic to discuss, so that means I had slept for almost an hour! I apologized again.

Coach: No problem at all. We can't get anything done by forcing it to happen.

He didn’t look upset at all. He just looked really sincere about his message. All I could do was say sorry once again and then I thanked him for teaching me this lesson.

What I Learned

This was supposed to be communication training, but I didn’t do any real communication since I was asleep most of the time. However, I think this strange situation was the greatest lesson I could learn about waiting for people until they are ready. How important it is to wait until the person I’m meeting with is ready to discuss something, being patient until they are feeling well enough physically and mentally to talk.

This is completely opposite from the way I had been thinking about one-on-ones. I was always asking myself how can we use this time efficiently. How can I make it exciting? How can I make it useful?

Most people don’t have the patience to wait until the right time. That’s why the coach allowing me to sleep was so surprising. He was ready to accept having a MTG with no real value to happen and not be bothered by it at all.

Before this training, if the roles had been reversed, and I was the external consultant, I would have definitely woken him up.

My One-on-One MTG Style

As I said, I have often questioned myself about how to have the perfect one-on-one meetings, and I have identified some key issues.

  • Issue: Spending too much time on topics from my agenda (announcements, reviewing old topics, etc.)
    • This is one of the most common problems. It’s easy for managers, including me to forget that one-on-ones should be led by the team member, not themselves.
  • Issue: Not being able to ask the right questions
    • When I couldn’t think of what questions to ask, I would just ask how they had been lately. I thought just having a casual chat was not a productive use of the time.
  • Issue: Not being able to figure out what topic to discuss
    • Usually, when asking the team member what topic they would like to talk about they would just say everything was OK. I felt this was not really an acceptable answer.

I’m pretty sure I’m not the only one who thought this way about one-on-one meetings. I knew it was a problem before, but my fixes always led to me talking more. I was stuck in a negative cycle. But following my session with the professional coach, my thinking about one-on-ones has changed completely.

The meetings are now totally dependent on the team member. It’s completely their time and they can use it any way they like, up to and including sleeping if they want. I can accept it without hesitation.

Of course it would be great if they think of something they want to talk about when they wake up and are thinking more clearly, but that’s not the point. When they don’t have any specific topic to discuss (and don’t need a nap), I now suggest working on our own tasks for a while in the meeting room together. And if something comes up in the course of their work, we can talk about it.

This change has come as a bit of a surprise to my team members, so I wanted to write this article to explain the background and reasons behind it. And I wanted to make sure everyone understood it clearly so I wrote it in both Japanese and English.

Conclusion

It’s useful to expand your mind by considering the opposite way of thinking. This applies to to any situation, not only one-on-one meetings. This can be difficult because we can’t think of the opposite point of view easily by ourselves. In this case I could learn a really unusual and helpful way of thinking from a professional coach who has a lot of experience in a specific area. And for that I feel very grateful and lucky.

At Mercari, we are making a lot of effort to hire a wide variety of Engineering Managers. We are even recruiting for my position) right now. If you think you can create more value than someone who just sleeps during meetings, please apply!

mercari.workable.com

This specific position has the important mission of creating the platform we need as we migrate from monolith architecture to Microservices.

fukuo33 will be writing more about this tomorrow topic. See you tomorrow!

*English edited by my amazing colleague JohnVS. Thank you very much!

Zapier を使って、SlackリアクションでTodolistを作るようにした

これまでのタスクの管理方法

最近、お仕事のRoleが若干変わり、コードを書く量が減った代わりに、「○○の件、確認お願いします」などの色んな方面の依頼や調整タスクを拾う事が増えました。
業務のメインツールは言わずもがなのSlackなので、基本的に仕事はSlackから降ってきます。
色んなチャンネルでPostされる依頼タスクを管理するには脳内メモリではオーバーフローすることもしばしばで、 手元のメモ帳にタスクリストを書いたり、依頼Post のPermalinkを拾って自分宛のDMに転送Postするなどしていました。

改善してみようと思ったきっかけ

少し前に特定のリアクションをトリガーにして動くbotを社内の方が作っていたのを見て、似たような事できると思ってZapierでやってみました。

リアクションされたコメントを自動翻訳するSlack BotをZapierで作った

またZapierについては以下のBlogが詳しいです。
社内でかなり導入されていて、今回の以外にも色々使えて便利。

tech.mercari.com

やること

Zapierで 2 step 組むだけ、以上!

って、書くと味気ないけど、ホントにこれだけで

  • New Reaction Added
  • Send Private Channel Message

のActionを設定するだけです。それぞれ以下のようなイメージです。

New Reaction Added

f:id:masartz:20180523175735p:plain

Reaction にはトリガーとなるリアクションの種類を指定する。
User での絞込もできるので、ここに自分を設定すると同じリアクション使う人がいても、それは拾わなくて済むので今回は設定する方が吉。

Send Private Channel Message

f:id:masartz:20180523181837p:plain

Channel は Post先のチャンネル名。まんま文字通りでしかない。
Message Text には Step1で拾った情報から、Message Permalink を設定する。
ちなみにこのStep2 のアクションは Private Channel である必要はなく、Public ChannelでもDMでも良いと思います。

やってみた結果

f:id:masartz:20180523175806p:plain

元の投稿にリアクションをつけます。

f:id:masartz:20180523181326p:plain

PermalinkがPostされるので、Slackの仕様で自動的に中身が展開されて一目瞭然です。 ここから流れを追いたい時には、Permalinkから元チャンネルにジャンプして確認可能です。

まとめ

1アクションでタスクリストを作れるようになりましたっ!