美味しいコーヒーを提供するためのDeveloper Productivity

コロナ禍とコーヒー生活

コロナ禍で自宅勤務がメインになって以降、コーヒーにハマっている。
アメトーークで紹介されていたコーヒーサーバーをふるさと納税で購入し、近所のお店で焙煎してもらった豆を、自宅で挽いて淹れている。
それまではコーヒーの味の違いなどわからなかったが、やはり日常的に飲んでいると豆の種類・焙煎度・挽き方で味が変わることに気づく。（多分厳密には、もっと他のパラメータもあるんだろうけど、そこまでわかってない）同じ豆で、同じ焙煎でも、挽き方やその他を少し変えただけで味が変わったりして「あれ、昨日と違ってイマイチだな」と思うこともあり難しさと奥深さを感じている。

という前置きがあって本題だが、最近 Developer Productivityの向上というのをメインタスクとして活動している。もう少し詳しく言うと、グループ全体の各開発組織（＝チーム / project）の開発生産性に係る指標を計測し、その計測結果から改善アクションにつなげる、という試みに取り組んでいる。

engineering.mercari.com

ここで目的としている Developer Productivityの向上って、「美味しいコーヒーを飲んでもらう」という顧客体験に対して、「様々な種類の良いコーヒー豆をより多く提供する」ようなものだな、と感じたという話。

コーヒーの作業工程と味への影響

前述したように、コーヒーの味を分解すると、豆の種類・焙煎・挽き方(and more)に分かれる。ここで注目すべきは、豆を製造するという工程と、製造された豆を焙煎する・挽くという加工する工程に分かれることだ。
当然それぞれの工程に別々の担当者がいて、生産者は日本から見た外国（コーヒーベルトと呼ばれている国々が主）の人たちで、加工者は地元のコーヒー屋の店員さんだったり、自分自身だったりして、全然違った人が担っている。

それらの工程を経て、最終的にエンドユーザー（つまり自分）の前にコーヒーが提供され、それが美味しいものだと幸せである、というストーリーになっている。しかし、違う領域の担当者のそれぞれのアウトプットの品質が、最終的な成果物の品質にも影響してしまうのがデリケートなところだ。特に製造者から見たら、豆の質にしかresponsibilityを持てない状況で如何ともし難い問題と言えるかもしれない。

と匂わせて書いてきたので、コーヒー豆の製造者がエンジニアで、加工者がプロダクト（ビジネス）サイドっぽいよね。というのはおそらくしっくりくるだろう。

Developer Productivityの指標

開発生産性の話をするときに「生産性（が高いこと）をどうやって測るのか」が議論になることがあり、個人的にも未だに結論は出ていないのだが、最近立てている仮説として、「Deployment Frequency(デプロイ頻度）」をKPIとできるのではないかと考えている。Deployment Frequencyは御存知の通り、Google が提唱する Four Keysと呼ばれる指標のうちの一つだ。Four Keysは Deployment Frequency , Leadtime for Change, MTTR, Failure Rate の4つがあり、それらを俯瞰してみていくことでDeveloper Productivityが可視化されるとされている。

実際、今取り組んでいるタスクにおいてもこれらの指標を可視化するのがこれまでのメインフォーカスになっている。それに対して、「KPIは Deployment Frequencyだ」と言うと、4つのうちから1つに絞りこむように誤解されがちだが、そうではなくて、

  • Developer Productivityの向上という取り組みを、とあるFunctionと捉える
  • Four Keysの指標を Functionに渡すためのInput パラメータと捉える
  • FunctionにInputがあれば、Outputもあり、それが生産性向上の取り組み結果つまりKPIとなる。これを Deployment Frequencyと置く

つまり、Four Keysの指標を以てDeveloper Productivity改善に取り組んだ結果を Deployment Frequency向上に跳ね返ってきたことで測るべきではないか、という仮説だ。これは特に今所属する組織がFocusすべき指標として攻めの Deployment Frequency や Leadtime for Changeと守りの MTTR, Failure Rateであれば攻めの指標をKPIにする方が組織風土に合っているのではないか、という個人的な事情も含んでいる。特に、究極的な数値が「０」のLeadtime for Changeに対して、Deployment Frequencyはそれが「正の数値」なので、「向上」施策で「数値を増やす」ことが直感的にわかりやすいし、会社のカルチャー(Go Bold)にマッチしている気がする。

そして、これをKPIとする穴は、Deployment Frequency向上がDeveloper Productivity向上の最終的な目的ではないということだ。
Developer Productivity向上の最終的な目的はなにか？ずばり Business Growthである。すべては事業が成功するために取り組んでいる。これはとても重要なポイントだ。
しかし、Business Growthが目的だとしても、Business KPIと同じ数値をDeveloper Productivity向上の取り組みのKPIとすることはできない。なぜならそのKPIに対してダイレクトにリーチできないからだ。その間には Product Productivityとでも呼べるものがある。より良いProductを提供するための様々なファクターだ。
toCのProductだったらPMの企画設計力・仮説設定力、Designerのデザイン力、BIの分析力、QAの品質確保レベル、CSが握る顧客満足度、などなどどれも欠かせない要素が絡み合ってProductの成否を左右する。

Developerがどれだけコーヒー豆に風味と香りをつけても、焙煎と挽きの工程次第では顧客の望む美味しさにはならないかもしれない。
一方で、加工工程に一流のバリスタを置いていても、豆そのものの質が悪ければ期待したクオリティにならないのもまた同様だ。
そして何より、製造・加工それぞれがベストを尽くしても、「顧客にとってそれが美味しいと思うものか」はわからない。
加工工程でどう処理するかもわからないし、顧客が何を望むかもわからない。しかし「だから我々Developer はただ『質の良いコーヒー豆を提供すること』にfocusする」というのはたとえ論理的であっても、それがゴールになってはいけない。何故なら我々Developerも顧客に提供したいUXは例えば「ホッとするひととき」であり、それを達成するためのProductは豆ではなく、飲み物としてのコーヒーだからだ。

なんのためにDeveloper Productivityを向上させるのか

Developer Productivity向上という取り組みに対して、

  • Business KPIは本質的には追いたいが、成果が見えない数値であること
  • Technicalな数値(e.g. Deployment Frequency)だけを追いたくはないが、成果が見える数値であること

これらを理解した上ならば、それぞれの数値を扱うのも良いのではないかと思う。

これはEMFMで言われている「物的労働生産性」と「付加価値の労働生産性」の違いだと思う。

www.youtube.com

ここまで考えれば、最終的に我々が目指しているDeveloper Productivityの向上というのは、ただ「コーヒー豆を大量生産する」物量の話では決してない。コードを書いてデプロイすることそれ自体に意味はない。「多くの顧客の”それぞれ”が美味しいと感じるコーヒーを飲んでもらえるようにするために、様々な種類の良いコーヒー豆を提供する」ことを目指すべきだ。できるだけたくさんの種類で、できるだけたくさんの量を、できるだけ早く。
Sortware Engineerであるならば、高い技術力で、多くのコミットを、素早くデプロイ、とかになるのではないだろうか。それによって Productの仮説検証の回数と確率を上げて、Business Growthに至るのが理想的なストーリーである。

子育てで活きる目標設定と期待値調整

そういえば、子育て情報が育休時の生後4ヶ月くらいで止まっていた。

masartz.hatenablog.jp

3歳も無事にすぎてすくすく育っており、せっかくなので、その後のメモを残しておきたい

(前置き) 子供の成長のログ

大体、1歳くらいで歩けるようになる。この頃になると、行動範囲が増えるので、それまでは家の中をうろつくだけでラクだったなぁと今にして思う。
大体、2歳くらいから言葉を喋るようになる。今振り返ると、それまでの意思疎通をどうしてたのかもう思い出せない。喋れなくてもなんとなくわかっていたのは今にして不思議。
1歳半くらいから一言くらいの言葉なら発するようになった気がする、2歳を迎えてようやく「公園、一緒、行く」みたいな文が繋がった時に感動したが、それから会話になるまでがあっという間だった気がする。

うちの子の場合、夜泣きがなくなったのは多分2歳半以降だと思われる。寝たあとに仕事をし直してから、遅れて寝る。というのができるようになったのはこれ以降。それまでは、そもそも寝るのが遅くて23時近くなることも多かった。「寝るのにも体力が必要」というのは逆に自分がこの歳になって、年々睡眠時間が減ってきて感じることでもあるが、まだ小さいこの時点では身についていないのかもしれない。

1歳半頃に夜泣きで起きてから寝かすのに散歩(AM2時）とか、2歳頃に寝かしつけのために外を1時間散歩(22時頃）とか、時期はそこまでピンポイントではないのだが、記憶にあるのはその辺。

(本題) 子育てで意識しているマネジメント方法

前置きメモはこれくらいにして本題はここから。
子育てをしていて、仕事のピープルマネジメントが役に立ったと思うのは「期待値調整と目標設定」だ。
これは普段から日常的に意識して取り入れている。
とにかく子供は、やりたいことを無限にやりたがる。散歩でも、ブロック遊びでも、お風呂でシャンプーの栓をプッシュしつづけるでも、ずーっとやる。これをいきなり制してしまうと大体ギャン泣きになる、けど、こちらとしては止めてほしい（特にシャンプーのプッシュ）。
その時には「あと1回で終わりね」と言ってから、止めるようにしている。目標を共有した上での行動を促す期待値調整だ。
多分1歳になる前くらいから取り組みはじめてたと思う。と言っても子供の期待値など不明瞭なものなので、約束したところで「まだやる！」というのは日常的にある。それでも「じゃあ、あともう1個ね」と折れることも必要で、「もう1個」がN回続くことも当然ある。それじゃ意味ないのでは、とも思われるがどこかの段階で「1個って言ったので終わり」と区切って、強制終了させる。
それで結局ギャン泣きになるんだけど、「それはお前が約束しただろう」と大人側が割り切ることができて、甘やかさずにギャン泣きを受け入れるためにも期待値調整は必要。実際に、初回の「あと1個」ですんなり終わるケースもあるから、それはそれで子供の成長を感じられる。

大人が持つ事情という子供にとって見えない目標

何かを止めさせたい時には、大抵は大人側の事情がある「ご飯を食べさせたい、お風呂に入れたい、寝かせたい」などが筆頭候補。なので、その意図を伝えることも大事なポイントだ。つまり目標設定。「お風呂に入るから、おもちゃはあと1個遊んだらおしまい」と伝える必要がある。「お風呂に入るから」を省くと、おもちゃは止められても結局別の遊びをしたがってもう一戦交えることになるだけである。
おもちゃ遊びの「あと1個」の先に、「別のおもちゃ遊び」があるのか「お風呂」があるのかは子供には想像できないし、子供の目標は往々にして「別のおもちゃ遊び」だったりする。ここで、「あと1個」をちゃんと守れたのに「じゃあ、お風呂入ろう」って言われたら、「それはイヤー！」ってなってしまう。

普段1on1でメンバーの仕事を「これをやりきりましょう」とだけ言っておいて、いざ評価の際に「この達成度だとこれくらいの評価（=実はメンバーはもっと良い評価を期待値していた）ですね」というフィードバックに「思ってたのと違うー！」という状況と似たようなものである。

形骸化しないために

「あとテレビ1話みたらお風呂入ろう」とかが日常会話になって以降、子供も成長して慣れてくる。すると今度は子供側から「1個見たらお風呂入るからテレビ見たい」とか打診するようになってくる。そういう時は大体1個で収まらなくて1個見終わったあとに「もう1個」とか平気で追加リクエストしてくる。ここまで来ると「条件提示すればテレビが見られる」と子供はわかっていて「1個」に意味がなくなっている。単純によく聞かされる「1個」をそのまま発しているだけである。
これをそのまま受け入れてしまうと「目標のための認識合わせ」にならなくなってしまい、やりとりに意味がなくなってしまう。なので、「本当は何個見たいか言いなさい」と問い直すようにしている。すると、「3個」とか真の要求が引き出せるので、キチンと目標のためのすり合わせが行われる。例えすり合わせた結果だとしても結局「あともう1個」となる時もあるけど、それも時に許容し、時に却下し、で賑やかな日常となっている。

簡単だけどまとめ

いずれにしても、「なんのために、何をしてほしいか」を話し合うことは子育てでもマネジメントでも重要である。

と、マネージャーっぽく書いているが、実は最近はマネージャー業は全然していない。ただのプレーヤーとしてやらせてもらっている。それこそ子供が産まれてからピープルマネジメントしていないが、それができている人は本当にすごいと思う。

家でも会社でもこれやってたら、自分のエゴを出すところがどこにもないので、精神的にキツいと思ってしまう。少なくとも絶対疲れる、というか家でやるだけでめっちゃ疲れている。仕事でプレーヤー側でいさせてもらえていること改めて大変感謝である。

Technical Product Managerとしての1年の振り返り

まえがき

アップデートできてませんでしたが、約1年くらいTechnical Product Manager(以降 TPM)のRoleを担当しているので、その振り返りです。 ちなみに今回はRole変更エントリではなく、まだ引続きこのRoleを続ける予定です。

What is TPM

JDが公開されているので、まずはこちらを御覧ください

Why TPM

きっかけは 「TPMの組織を作ろうと思うので来てくれませんか？」と現在 Smartnewwsで活躍する @tairoに誘われ、「TPMってどういう仕事ですか？ というかPMとの違いは？」という俺の問に対して「まさに僕みたいな人のイメージです！」と説明されて、とてもすんなり合点がいき、それならばやってみたいと思ったのがきっかけです。

When,Where TPM

いつからという意味では、冒頭にも書いた通り、現在で1年とちょっと経ったくらい。 どこの領域という点に関しては、過去に記事にもなっていたこのあたりです。

mercan.mercari.com

How TPM

これは社内でも話題に挙がる項目でもあり、社内向けにも説明用ドキュメントが作られたりしているが、一言で表現するとまんま「Technical knowledgeを持ち、それを用いてProductを成功させるProduct Manager」となる。 これだけ書くと、PMの上位互換のように感じるが、それはある意味正しくて、ある意味正しくない。というのも、plain なPMという定義がもはや難しいと思っているからだ。

note.com

上記記事がとても参考になるように、PMに求められるスキルが高度・多様化する中で、何かしらの専門性を持つPMというのは増えているし、今後も増えていくと思う。数あるその方向性の一つの亜種に過ぎないと思っている。エンジニア向けに説明するなら、PMというのが「Software Engineer」と同じくらいplainなものを指していると思うと良さそう。

これだけでたくさんのことが書けてしまうし、議論ができてしまうが、この記事のメインはそこではないので、細かい定義はここまでにしておく。

現状課題

という訳で、仮にもPMの端くれなので、やることはProduct Managementになる。ここが大事で、Project Managementではないということだ。 両者の違いも難しいが、ProductにはLifecyleがあり、それはProjectのように一直線のものではないのが一つ差かなと捉えている。

  1. Product Concept
  2. Product Design
  3. Product Development
  4. Product Delivery
  5. Product Maintenance
  6. Back to Concept(= Step1)

これも様々なフェーズ分けの定義があって、上記は一例だけど、要は開発して終わり、リリースして終わりではない、ということだ。 このサイクルと自身の作業との振り返り比較で言うと、ようやくサイクルを1周できそうかどうかというレベル。この 1年かけてようやく というスピード感と経験の薄さが現状の最も大きな課題と感じている。 もちろん開発やリリースするのに色々な課題がある。リソースがなかったり、逆にブロッカーがあったり、などなど。 とはいえ、その辺を解決しつつ進めることこそが仕事であり、逆に進めることで成果を出すことがProductの改善につながると思う。 本当であれば、1つのCycleとして振り返り、何をやってどうなったから、次にどうするのか、ということがここで述べられるのがベストなのだが、そこまでには至っておらず、現状における成果をこれ以上に書けないのがとても悔しい。

Technical というPrefixに関しては、メルカリにおけるEngineering経験を活かすっていうことはできている部分があると思う。具体的にはコードやアーキテクチャを知っていることでできる設計の部分などだ。一方で、それは汎用的なTechnical knowledgeではなくドメイン知識だと思っていて、他の環境で同じことができるとはまだ思えないのが正直なところ。 これも大きな課題で、 ただのEngineerがPMの真似事しているな と見られてもおかしくないようなことしかできておらず、PMとしての専門性はまだ全然だと思うのは前述のサイクルを回しきれていない点が物語っている。

Individual Contributor との違い

EngineerからPMというRole変更は以下の資料における振り子を振った状態にあると思っている。

speakerdeck.com

まず、どうして振り子を振ったか、という点であるが、PMの良さとして、Productの What（何をするか） にフォーカスできる点が挙げられる。対してEngineerは How(どうやるか) についてフォーカスできる。（もちろん両方とも「フォーカス」であって、それしかやらない訳ではない。）

Backend(サーバーサイド)領域を抽象度を上げて表現すると、「RDBにデータを出し入れしてレスポンスを返す機能」という1つの大きなHowで括ることができるとして、この1括りのHowで解決しなければいけないWhatは山程ある。

おそらくこれを「1括りのHow」とするのに多くの意見があって、

  • 言語の種類やその性質による開発スピード、規模、パフォーマンスなどの違い
  • インフラ設備の違いによるコスト、Availability,Mutabilityなどの違い
  • NetworkやSecurityなど環境によるコストや制約などの違い

など他にも挙げきれないような多くの差異要素があることはもちろん知っているつもりだ。しかし、それらの要素は全て何らかの課題を解決するための手段として存在・提供しているものだ。 それぞれの要素の特徴や差異の意味を全て詳細に把握はできなくとも理解できるのならば、それを1つの大きなHowとして、多くのWhatの解決に向き合うのは良い経験になるのではと思ったのが振り子を振った理由だ。

逆に、自分の中で勉強不足で全くピンと来ていなくて括りの外にあるのが、例えば機械学習分野。RDBからSelectする代わりにそれと同じような感覚で機械学習モデルからデータを引くようになったとして、そのシステムの当たり前さをどれだけ咀嚼できているかは今時点ではさっぱりだ。この不透明さによってWhatにフォーカスできなくなるようなら、それが振り子を戻す時かもしれない。

まぁ、でもここまで書いて、完全に逆もまた然りだなと思った。 「顧客の求めるサービスを提供する」というのを1つのWhatという括りにするなら、それを解決できるHowも山程ある。その山を自身の中に積み上げる目的で、エンジニアとして技術力を磨く、というのも全く成り立つし、とても良い経験になると思う。

EMとの違い

一応、かつてEngineering Managerをやっていたので、それとの比較も書いておく。

個人的な経験だけでもの凄い簡単に言うと、

  • 人のために人にアプローチするのがEngineering Manager
  • Productのために人にアプローチするのが Product Manager

だと感じている。結局どちらも人にアプローチするのは一緒、というのがまず大事なところ。

この時、アプローチに行き詰まった際に、突き詰める先としてEMの場合「あなた」というベクトルに対して突き詰める訳だけど、ここが個人的に難しかったポイントだと思う。 「あなたのことを考えに考えて、○○したいんです」というのは、恩着せがましいというか、おこがましいというか、それってなぜ自分がやらないといけないんだっけ、と思って躊躇うことが多かった。

一方PMの場合は、「Product」へのベクトルを突き詰めれば良い、具体的にはプロダクト開発をしたいためにエンジニアにアプローチして、それが合意されない場合おそらくQCDのどこかに問題があり、それぞれについて突き詰めることになる。 Qualityを上げるのか、Costを下げるのか、Deliveryを遅らせるのか、とかを検討できれば合意できるケースが多いのではないか。もちろん例外もあるだろうし、QCDのどれかがUncontrollableであることも往々にしてあるだろうが・・ それらがControllableであるならば、QCDへのアプローチがReasonableかつLogicalであればあるほどその分だけ合意に近づけやすい。またReasonableかつLogicalにやるっていうのはエンジニア脳を使えて、やりやすくて良い。

そういう意味では、今の環境がQCDがControllableなので、恵まれているのかもしれない。。より厳しい環境でPMをやった上でのEMとの比較が必要かもしれない。

・・・と、ここまで書いて思ったが、QCDというのは実は浅い課題で、深い行き詰まりだとProductのMission/Vision などへの不合意になるのではないか。これらを突き詰めてエンジニアにアプローチする際には、Logicalに、だけでは成功しない。Logicの積み上げだけでVisionには到達しないからだ。むしろある種の熱意を持ってアプローチする必要があり、それは俺のめちゃめちゃ苦手な分野に該当する。PMだからLogicalで簡単というのはおお大きな誤りということになる。

しかも、もしMission/Visionが語れるのならば、EMとしてももっとできることがあったかも、とも振り返れる。多分

  • 人のために人にアプローチするのがEngineering Manager

この前提自体が違っていて、あるべきは『組織のために人にアプローチするのがEngineering Manager』だ。 思い返せば、EM時代もMission/Visionをマトモに考えられたことはなかった。どういう組織（これはEngineering Division全体もそうだし、自チームもそう）にしたい、という明確なモノは持っていなかった。当時、人に翻弄されているように感じたのは、指し示すものがない中で彷徨っていた感があったかもしれない。暗中模索という言葉がまさにしっくり来る。

つまり、結局Roleは変わっても自分の突き当たるべい苦手分野は一緒で、それは克服はできていないのでは、と思い始めてきた。

何が言いたかったか

それなりの理由を持って、TPMに取り組もうと思ったのでその背景整理をしつつ、現状課題というこの1年の整理を書き残すのが当初の目的だったが、Enginner及びEMとの違いを補足で書くつもりが、実は大して違わないし、課題は同じだった、ということを書きながら思ったのが自分自身の収穫になったというオチ。

書いてみたら、小さいもの課題として捉えてた反省が見つかった。いや、小さくはないか、基本的な事で事実自分には足りていないものだが、それよりもっと大きな根本的な課題があるのがわかったという学びか。

おまけ

再掲ですが、ちょうど最近OpenになっているJob Descriptionはこちらです。 ご興味のある方は、カジュアルにでも構わないので、ご連絡ください。

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 に上長を入れること、評価結果を共有するのを上長に協力仰ぐこと、など成果の要所には俺の上長が存在する。これは上長がいるレベルのレイヤのマネジメントタスクが主だったという証拠であり、会社にとってより大きなインパクトを残せなかったのは課題かもしれないし、前回と比べて成長していない部分かもしれない。

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

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

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

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