前回
2022年12月20日で Quipper に入社してから4年半が経ちました。
アウトプット
登壇はなし。ブログが2本でした。
何をしていたのか
このエントリで書いた通り、専門である SRE と異なる領域に範囲を広げたのが大きな意思決定だった。
9月に入りはじめてから4ヶ月。期初のマネジメント（組織戦略策定、メンバーミッション策定）と新メンバーとの関係構築はできたと思う。 また、SRE との兼務という点も、SRE メンバーへの権限移譲と、関わるメンバーとの期待値調整を丁寧にすることでできている。
当初の狙いとしては、「ビジネスにエンジニアリングで貢献する」ための洞察を得ること、より直接的に貢献すること。副次的には自分の（Web Frontend / Bakcned）技術力も向上できればいいと思っていた。WebDev と SRE の両方を見ることで、双方にポジティブなフィードバックを与えることでより開発組織全体を良い方向に動かしたいと思っていた。 そしてロールは Engineering Manager であり、マネジメントを第一義に行うべきなので、実装は行わない（ただしより評価を正しいらしく行うことを目的として、緊急性のない実装はチャレンジしたい）という心持ちだった。
これについて、正しかったと思いつつ、「実装できるかも」という考えは甘さがあったと思う。 1つは僕個人のスキルの問題で、学びながらやる、というオーバーヘッドをチームにかけることはチームのアウトプット総量を増やすという役割上、避けた方がいいと思った。 もう1つは組織の状況の問題で、職能横断型チームで構成している現状の組織ではマネジメントで解決すべき問題が思ったより山ほどあった。まずそちらをやるべきである。
この半年間、「マネジメント」と呼ばれる領域の仕事の難易度が1段階あがり、新しい経験ができている。 それぞれの組織ごとに振り返ってみる。
SRE チームのマネジメント
マネジメントの方針は大きく変えていない。メンバーが自律的に動けるような目標設定やチーム戦略を決定し、失敗も成功も含めほとんどをチームにお任せする方針である。これが最もメンバー・チームがパフォーマンスを出せると判断している。 その上でマネージャとしてはチームがより前に進めるような Insights を定量・定量問わず提供することと、チャレンジを後押しする声かけをすることを心がけている。また、自律的に動けるような方針 - 基本方針と例外時にどうするか - を明文化することも意識してやるようになった。
もちろん、チームが前に進める上で障壁となる、主に組織上の問題はすぐにキャッチして迅速に解決するようにしている。例えば SRE と開発組織間の依頼のフローや基準の整備（Team API）であったり、セキュリティ組織とのやりとりでオーバーヘッドが大きいやりとりを直接フィードバックして改善してもらうことだったり。開発組織に閉じず、全社レベルで必要なフィードバックを必要な場所へ正しく届けるということはマネージャーになって（そしてリクルートに移籍して）最も意識して行動していることの1つだ。経理システムだろうが人事システムだろうがなんだろうが素早く正しくフィードバックする技術と、その姿勢を見せるということはできていると思う。
今回新しいチャレンジとしては、兼務をすることによって、SRE チームにかけられる物理的な可所分時間が少なくなるため、チームリーダーに「チームの意思決定をサポートすること」を明確にお願いし、移譲した。これまでも僕しかできないことではなかったものの、暗黙的に僕がロールとして持っていたことをやらないことを宣言した。採用活動の一部フェーズも丸ごとお任せすることにした。時間が取れない人間が関わり続けることで逆にチームにマイナスの影響を与える業務を、適切な人物に移譲できたことはうまくいったことだったと思う。
これについては兼務のタイミングでメンバーから懸念を表明してもらえたことが大きなきっかけとなった。「起きるかもしれないこと」を事前に手を打って起きなくする、ということはシステムにおける Site Reliability Engineering として最も重要なことで、ことマネジメントにおいては最悪組織崩壊という大きすぎるリスクとなる。これを事前に対処することは僕一人ではできなかった。フィードバックをくれたメンバーにも、ロールを引き受けてくれたメンバーにも、そして高いパフォーマンスを発揮してくれているメンバー全員に感謝したい。
ありがたいごとに採用もうまく行っており、SRE チームとしては headcount が充足した。これは素晴らしいことだ。 今後僕がやらないといけない仕事は2、3年後という中長期を見越した組織のデザインをしなければならないと思っている。（やっとそれができるような状態になったとも言える）
開発チームのマネジメント
前述した通り、マネージャとしての「最低限の仕事」はできたものの、今の自己採点としては40点で赤点である。期末に向けて挽回したい。
開発チームのマネージャとしては、開発ロードマップが達成されていることが期待としてある。 そして僕が入った FY2022/Q3 はそれが達成できてないことがしばしばあった。 この原因の詳細の言及は避けるが、マネジメントで解決されるべき問題だと判断しており、前述したような「問題が発生する前に打ち手を打って回避する」ということができなかった。（問題が起きてアラートが上がってから打ち手を打つのは当たり前であり、最悪という感じ）
何を言っても言い訳なのでこれは反省を続けているのだが、（入ったばかりとか関係ない） あえて一般化すると職能横断型・大規模組織のマネジメントの難易度が高い、という風に捉えてる。
PM（Business Planner, Product Manager）、TPM、Designer、Developer(Web, iOS, Android)、CS、QA といういろんな専門ロールがいて、（担当する）BtoC プロダクトの中でそれを分業して価値を届ける、ということをマネジメントすることの難しさに直面している。 「難しい」と言っても、組織マネジメントの基本に立ち返ってやってやれないことはないと思うので下期はここの課題発見と対処に集中したい。
実装して技術力を上げる、ということは別の場所で行おうと思う。
今後のキャリア
しばらくは今の組織でマネジメントの経験を積むが、その後どうするかはアイデアが浮かんでいない。 自分自身のライフステージの変化もあるので、ゆっくり考えていきたい。
ありがたいことにこのツイートでいくらか反応をいただけたので真のカジュアル面談（所属組織の採用目的ではない）できるの楽しみにしている。
カジュアルにお話ししてあげてもいいよ〜という方いらしたらお願いします！関心とか一筆書きました。これでビビッときたら！https://t.co/7Zrq782Ete https://t.co/ldc1xgctQ1
— Takeshi Kondo (@chaspy_) 2022年12月18日
（引き続き若干名できると思うので DM お待ちしています）
