ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

エンジニアリングマネージャーの成果

なんかタイトルを一般化すればするほどブクマがつくことがわかった。これも十分一般的だが。

エンジニアリングマネージャーのしごと本には確かマネージャーの成果について、

  • マネージャーのアウトプット = 自分のチームのアウトプット + 影響を与えた他のチームのアウトプット

とかかれている。

さて、これについての自己評価、あるいは他者評価の難しさについて。

2つに分けて考える。

  1. 自分のチームのアウトプット
  2. 影響を与えた他のチームのアウトプット

まず、1から考える。マネージャーは目標に対する資源分配最適化の役割であるとする。チームのコミュニケーションがうまくいってないものを対話によってうまくいくようにしたり、個人の目標設定を変えたり、役割を変えたり、大小いろいろある。

その場合、ここで書かれてないことであるが、

  • 1-1 マネージャーが存在しなかった場合のチームの成果
  • 1-2 マネージャーがいたことで想定できる最大のチームの成果

現実はこの両者の間にチームのパフォーマンスが落ち着くと思われる。しかし、その期におけるチームの成果が想定通りか想定外かを計測することは難しい。よって評価も難しい。

しかし、例えば営業数値とか、製造の利益とかで出せるチームもあるだろう。内製開発チームにおいてそれはなんだろう。あるいは横断(プラットフォームチーム)だとなおさらなんだろう。

測ろうとすればするほどそれはハックできるわけで、なおさらマネージャーの評価、ないしチームの評価は難しい。

しかし、ただ1つ揺るがない評価は価値提供相手の定性評価である。SRE チームであれば開発チーム、開発チームであればプロダクトマネージャーからフィードバックをもらい、それもなるべく頻度高くもらうことで軌道修正できるようにしたい。

その上で事業を継続できる、投資がもらえる数値も共有して、同じ方向を向けるようにしたい。

難しいねーなんで難しいんだろって話を考えたかったんだけど目標設定が難しいorできてないからだねということがわかったので解決してしまった…。

2 についても同じ方法でフィードバックをもらうべきだろう。

所属組織では360フィードバックという、メンバー同士でフィードバックを送る営みがある。(評価には使わない)

それと同様に、チーム単位のピアフィードバックもすべきだと思うし、これはマネージャーの評価に使ってもいいと思う。

1人のトップマネジメント(VPoE)が各チーム個別あるいはマネージャーの評価ができないならば、評価できる仕組みを作るのがVPoEの仕事なんじゃないの、と思う。

多分、こういう営みそのものがマネージャーのマネジメント業務の理解を深めたり、マネージャのキャリアを作るのに役立つんだと思う。


余談ながら、最近個人でプロのコーチングを受けている。 自分の want to を特定する上で過去のエピソードや好きなワードなど出して深掘りするワークをしたのだが、その中で自分の好きなことに、「少しの労力で大きな成果が出ること」が好き、気持ち良い、という発見があった。

これはソフトウェアの世界でいう UNIX 哲学 Use software leverage to your advantage であるし、組織マネジメントにも同様の要素はあると感じている。

これだけ続いているということは、ソフトウェアの世界、マネジメントの世界、どちらも向いてるのだろうな、と思いつつ、Hazy Double IPA 作って自宅でタップで注いで飲みたいな、とも思う。

リーダーとマネージャの違い

最近見たいくつかのツイートが自分の考えとちょっとズレがあったので考えてみる。

見つけられなかったのだけど、

マネジメントは欠けている要素を増やす、リーダーは目標を決めてチームを前に進める、やることを減らす、なので本来真逆である、みたいなやつ。

こういうのもか。

僕はこれまで以下のような整理をしてきました。(これは最近できたチームでのリーダーとの期待値合わせに利用しました)

  • Manager:
    • 担当メンバーの評価、目標(ミッション)設定
    • 担当メンバーの健康・労働時間管理
    • チームの半年単位での目標設定、戦略策定(採用を含む)
    • チームの結果責任
  • Leader:
    • チームを前に進めるためにリードする
    • チームが前に進めない要素を取り除く
    • 内容例
      • 0->1 のチームビルディング
      • チームが意思決定することをサポートする
        • 決め方を決めるように推進する、観点や選択肢を提示する、問いかけによって気づきを与える、など
      • ステークホルダーとの折衝
      • 開発部内の他のチームとのやりとり

思えば、僕が認識している Manager は所属組織でのロールとしての業務が多いなと。

ここに書いてないが、確かに「チームに不足している要素を(人材育成なり、他のチームに協力依頼するなりして)持ってくる」という動きはしている。

資源配分という意味では「チームの戦略策定や目標設定」もそうだろう。

そしてリーダーがやることを減らす、という意味としては「前に進めない要素を取り除く」にマッチしていそうだ。

そう思うとあんまりズレはなかった気もするが

チームビジョンを策定し、それに向かってメンバーを鼓舞する

これは結構両方に混じるところだなぁと思った。「どこへ向かうのか」はマネージャがやると自分は思っている。「向かう先に対してメンバーを鼓舞する」はリーダーの役割で良いのだけれど。

向かう先を決める能力がチームに備わっていれば、マネージャは欠けている資源を調達する、のみになるかもしれないが、実際は組織の階層構造だとか評価制度などが絡んでこれはパッキリ分けられないのだと思う。同じ権限を持ったマネージャとリーダーがチームにいて、そういう役割分担をすると良さそうだと思った。

開発組織でのマネージャ同士の役割分担がこんなふうにできると便利かもな。リーダー的マネージャとマネージャ的マネージャ。

正しいことを正しく言うのは難しい

人間の感情を配慮し尽くすのは難しい。確率を下げる努力はできても、完璧は無理だろう。

 

正しいことを誤って言ってしまうパターンは以下があるだろうか

- 関係性(信頼)の欠如: なんでお前に言われないといかんの?

- コンテキストの欠如: なんで今言うの?

- 期待値調整の欠如: お前何のためにここにいるの?

- 背景理解の欠如: 実はこういうことがあってですね

 

基本的にフィードバックが求められているときにすることであり、それ以外はしないにこしたことはない。求められてないアドバイスはクソバイスだからだ。

 

しかし、組織の生産性は噛み合わせが悪いと1つのことでも大きく劣化するし、最悪人が辞める。逆に言えば、たった1つのことで改善すると組織の生産性が大きく向上することもある。

 

ボトルネックの特定や、根本原因の見極め、問題の評価、という目線でいろんなことを見るようになった。それがマネジメントの仕事だとも思っていた。

 

それは正しいんだが、いかに正しいフィードバックでも届かなければ意味がないどころかマイナスの効果を引き起こしてしまう。

 

正しいフィードバックを見極める姿勢は続けつつ、次は"正しく届ける"ことを意識したい。

 

おそらく、目指すべきゴールはそんなフィードバックがなくてもチームや個人が自律的に課題を見つけられる世界なんだと思う。チームの中からの目線とチームの外からの目線のギャップをなるべく小さくしていきたい。

 

同じものを、同じように見るようにしていきたい。

SRE とプロダクト開発の EM を兼務して半年経った

3ヶ月前の振り返り

https://blog.chaspy.me/entry/2022/12/24/120000

いろいろキツかったがなんとか走り切れたかな、というそんな感じ。うまくいかない時期もあったが、周囲にサポートしてもらいながら、少しずつ前に進むことはできたと思う。

SRE

ややハードになりそうな状況ではあったが、なんとか乗り越えられたと思う。メンバー1人1人の自立性と技術力のおかげだと思う。

11月に1人、2月に1人入社し、メンバーは7人になったところで採用を止めることができた。これにより採用活動にかけていた時間を使わなくなったのは大きい。

新しく入った2名についても順調に立ち上がっていると判断していて、1on1は細かめにやっているものの、マネージャーというよりはメンターとそれを受け入れるチームが正しく機能していたことが大きいと思う。

後半の Q4はリーダーが他のチームに留学したり、AWSのアカウント分割プロジェクトで手戻りが発生したりと不安定気味になったが、それについても留学時期を調整したり、リーダーが作戦変更を素早く意思決定し、段階的に変更を進めたり、開発チームとのインタラクションをコラボレーションモードに変更したりと素早く柔軟な軌道修正ができた点は良かった。

この期はアカウント分割プロジェクトを中心に、開発者との Relation を深く考えることができた期だと思う。これまでも開発者からフィードバックを得る、ということはテーマとして打ち出していたものの、具体的に依頼をいつどのようにしたら良いか、という点で学びが多かったし、その基本的な考え方も整理できた。

成果もかなり出ており、次の期でも引き続きやりたいトピックがたくさん出てきている。

次の期は僕が EM をやって4半期目である。(次の10月でちょうど2年)

僕が当時思い描いていたより遥かに遠いところにきていて、特にこの期はチームが格段に良くなった感覚がある。

僕がマネジメントとして成し遂げたことは数少ないが、意識していたことは、

  • メンバーがハイパフォーマンスを出せる環境

  • Teamとして不足している capability を獲得すること

  • Team としてそれを発見、実行できること

現状はこれが回りつつあり、少なくとも実務面ではマネージャ不要な状態にかなり近づいていると思う。(個人の成長支援として少なからずマネージャに残る役割はあると思っている)

チームがチームをセルフマネジメントしている状態、というのかな。

これには1人1人の技術力だけではなく、ソフトスキルも必要だし、何より同じ方向を向くことが大事で、これについてはビジョンミッションバリューを整理した前任マネージャの功績が大きい。僕はそのレールの上でさらにそこに向かうための改善サイクルを強化するための採用と目標設定を補助したに過ぎない。

引き続き"良い課題を発見する"ことを、SRE チームだけではなく、開発組織全体の技術戦略を通じて与えられるようにしていきたい。

Product Secriry Engineer については来期もう1人取りたい。頑張る。

プロダクト開発

B2Cプロダクトの WebDev のマネジメントをやりはじめた。まだ半年らしい。1年以上前からいる気がします、と言われることもある。よく分からないけど、半年も経てば慣れるもんである。

技術的には WebFrontend を触るようになって0から React を触れたのが良かった。楽しい。実際に軽微な改善、ドッグフーディングで見つけた改善はプロダクションに出した。

Native Team と関わるようになったのも新しい経験だった。どうしても SRE と Native は直接的な関連がなかった。お近づきの印に Jetpack compose の置き換えのリファクタもやらせてもらって、(最後はペアプロでおんぶに抱っこだったがw) 無事1コンポーネント本番に出せた。

インフラや監視面でも(それをしにきたわけではないとはいえ、持ってるスキルセットとして)身近に聞ける人ができた面でも貢献できたと思う。が、それを組織の capability として強化する、みたいなことはできなかった。

3Q でやっていた領域はビジネスの方針転換により縮小することになり、この組織変更には痛みが伴うものとなった。ビジネスの方針変更に対して開発組織はそれに合わせて変更する、それによる痛みは少なからずある、というのは理屈ではわかるが、我々人間、感情の生き物であり、そこはもっとうまくやれたところはあったと思う。(結果としてあの時あの時点では最良の選択をしたと思うが、もっと早く手をつけて回避できなかったのか、ということをたくさん考えた)

PLG チーム

Q4 からは体制変更に伴い、PLG - Product Led Growth チームが立ち上がり、そのチームの担当マネージャーに立候補した。チーム立ち上げのプロポーザル自体は別の EM が行い、まんま引き継いだ感じ。

Growth Enginering, プロダクトをプロダクトによって改善し、仮説検証をデータを元に繰り返していくチームだ。今は Android, Web 開発者が1人ずつと、PM が1人、EM が僕の4人の小さいチームだが、立ち上げは順調で既にいくつかの変更をだし、A/Bテストを行っている。

"事実に基づいて意思決定する" Fact based decision making は信頼性領域における SLI/SLO であり、それを事業指標とプロダクト指標で行うこととなんら変わりはない。分析基盤の構築をしながら、高速にサイクルを回して事業指標を改善していくことは僕が最もやりたかったことだった。次の半年はいよいよ成果を出す期である。楽しみだ。

マネジメントの課題

課題は明確である。

  • PM とのコミュニケーション、期待値調整、情報流通

  • 各チームが自立的に改善を繰り返すための組織設計、およびリーダーの育成やアサイン

1つ目については年明けからかなり状況は良くなっており、PM のマネジメントメンバーとの会話はかなり増えた。

みんな優秀でちゃんと話を聞いてくれる、話せばわかる人たちなのがありがたい。じゃあ話せばいいじゃん。話そう。それだけなのである。でもそれだけのことで結構うまくいかなくなるもんである。

2つ目は具体的に現在予定されてる新規プロダクトのリリース後の組織体制の検討がアウトプットになる。この意思決定については早めからありうる未来を考え、メンバーにフィードバックをもらいながら設計し、その設計意図や意思決定については ADR のように残したいと考えている。

3つ目として、技術戦略がある。(システム的な技術課題の解消、組織の技術力向上、ビジネス戦略を見越したシステムならアーキテクチャなど) が、ひとまず次の半年については大玉のリリースおよびチームの再構築によるチームビルディングと安定化が目先大事なので、それが落ち着いてきたら考えたい。

技術戦略

直前で言ったのとは別に、スタディサプリ小中高全体の技術戦略グループがある。このグループもなんと2年だそうだ。よく続いている。尊い。

兼務メンバーで成り立つこのグループは派手さはないものの、地味に成果を出しつつあり、組織としては成熟しつつある。

技術課題を吸い上げて、評価して、計画を立てる。

ただそれだけのことを、1人のリードアーキテクトではなく、ボトムアップでグループで行えるようになっている。これはなかなか凄いことなんじゃないかと思っている。

長年やりたかったシステムアーキテクチャに対するサブグループも立ち上がった。時間はかかったが、着実に良い未来につながる取り組みができていると思う。

自分が担当している DevOps WG も自分たちの様々なことについて、アセスメントを実行してフィードバックを得る、それ自体のサイクルが回っている。

各チームから満遍なく参加してもらっているのはマネージャである自分の唯一の功績である。その多様性により、何気なく持ち込んだら一瞬で課題が解決する、といった良い成果が出ている。このグループの取り組みが SRE チームにも良い影響を与えられており、自分がいて良かったことの1つだと思う。

SRE(2)

BtoB 領域のインフラを何とかしれくれと言われて何とかしにいった。と言っても片手間なので、状況を把握しにいって、方向性を決めて、細々発生するタスクを誰でもできるように標準化したり、意思決定したりする程度。

ちょっとはマシにはなった。

Terraform applyをlocal実行するのドキドキ新鮮だった。

学んだこと

  • 任せた方がいい、だけど丸投げはしない

それはそうなんだけど、でもやっぱり任せた方が結果的には良くなる。でも任せ方は大事で、丁寧に期待値合わせをして任せて、それを最初は結構頻度高く目線合わせとかで会話するとうまく行く。

それはそうということなんだが、やっぱりそうなんだなという感じである。なので、これは続けていきたい。

  • 自分にできないことを自覚し、他者を信頼して、他者を頼る

一時期足りてなかった時期があった。他者を信頼するというのが大事で、今でもちょっと苦手かもしれない。でもうまくいかない時って自分に原因があるので、そういう時はちゃんと内省するってことはできてるので続けたい。

次の半年

  • SRE: チームでチームをマネジメントできるようにする

  • プロダクト開発:

    • 大玉のリリース

    • リリース後の組織設計

    • PM とのコミュニケーション改善

VPoE は席空いてるけど能力が追いつくか余力ができないとできないかもしれない、わからない。

とりあえずこの半年はチャレンジしました。お疲れ様でした自分。

mikefarah/yq 便利

github.com

便利。やや癖ある。

2種類あるらしい。ややこしい。

github.com

本記事では前者のほうの使い方メモしておく。


副業で kubernetes manifest をあれこれオラオラするみたいなときに利用した。

でいろいろ記事を書こうと思ったが example は動く形で GitHub に置いておくかとなり

github.com

こちらを書いて満足した。

一括処理をするときに、同じパターンを複数のサービスに展開する時などは環境変数から入れることが多いと思うのでこれを知っておくと便利。

kustomize のリファクタリングとかよくやると思うのでこれまた便利。

最近こういう学んだことメモやってなかったので GitHub に書いていくスタイルでやっていきたい。

new Slack platform でやりたいネタ集

ここ最近 new Slack platform (この呼び方が正しいかは知らない) でいろいろ作って遊んでいる。

api.slack.com

使い心地や特徴、基本的な使い方は日本語記事でもたくさん出ているのでそちらに譲るとして、これまでやってきた今年含め冬休みに実装したいアイデアを記録しておく。

hanakintro

完全に身内のホビーアプリで、決められた問いかけに対して決められた文言を返すのみ。

github.com

いまオススメの店をサジェストする機能があるが、これをユーザが登録できるようにしたい。現状は conf ファイル的なところに静的に書かれているが、非エンジニアにプルリクを送れというのも無理だと思うので。

これは slack の DB と、Link trigger でできそうである。

api.slack.com

特定のリンクを貼って、ワークフロー的な入力画面を出してオススメの店をユーザが登録すると、DB に登録されるようにできそうである。link trigger 自体は使ったことないので本当かはわからん。

抽象化すると、アイデアやネタをユーザが登録し、botがなんらかのアルゴリズムで返却するということができる。これは今回のような趣味の知見共有もだし、業務のトラブルシューティングだったりオンボーディング支援だったりと、集合知の収集と活用というパターンで幅広く使えると考える。

thanks bot

プロトタイプまで作ったが実用化するのは断念した。

github.com

@thanks @mention message と投稿すると、メンションされた人がこれまで感謝された回数を返信する bot である。

結果は DB に保存して、その総数を返信するところまではできた。DB を使ってみたくてやってみた案件。

実用化できない理由は以下。今回は event trigger (今回だと app_mentioned trigger )であるが、

  1. 他の bot へのメンションでも反応してしまう

  2. channel_id を trigger で指定する必要があり、app が動くチャンネルが制限される

いずれも Slack DevRel の瀬良さんからワークアラウンドを紹介いただいたが、

1 についてはまだフィルターしたり、あるいは本家が治るのを待ってもいいのだが

2 はユーザが登録チャネルを増やすのを link trigger でやる、というのをイチイチやるのは面倒である。いつでもどこでも thanks したい。そのため見送った。

ワークスペースグローバルな event trigger が許容されるといいが、まぁベータだしチャネル制限はするよなというのはわかる。内部構造はわからんがグローバルだといろいろ負荷は大きそうだし。

問い合わせ記録bot

自分のチームはチームへのメンションに特定のリアクションをつけ、reacji で特定のチャンネルに流して、それを daily meeting でおさらいして共有したり、新規で反応できてないものへの対応策を決めたらするという営みがある。

ただしこれでは統計量の収集をしたり、中長期での分析をするのに一手間必要になってくる。

そこで該当チャンネルへの message posted event を使い、spreadsheet に追加する bot を実装したい。

spreadsheet じゃなくても DB 保存でもいいのはいいんだが結果のメンバー共有は楽にしたいので。

emoji_changed event でもいいんだが、前述のチャンネル制限の問題がある。こちらは自分のチームはの問い合わせが起きるチャンネルはある程度限定されるものの、どこで発生するかはわからない。

api.slack.com

そのため現状の reacji 運用を続け、流されるチャンネルでのみ動くようにする。

気になりとしては reaji がついたメッセージだけをフィルターできるかどうかぐらいである。(スレッドに回答サマリーをメンバーが登録している)

message post のデータでフィルターできなくとも、まぁ最悪 emoji ついてるかどうかをファンクション側でフィルターすればいいからなんとかなるかなと思っている。

これは抽象化すると、特定のチャンネルのメッセージを分析可能にする(シートに転送する)という処理になる。native に会話されてるチャンネルでやってもいいかもしれないし、今回のように reacji を活用すれば特定のコンテキストを人間が収集し、それを分析できるようになる。これも活用可能性は広いアイデアだと考える。

display name 変えたら戻す君

所属会社での slack workspace では slack display name と github id と google エイリアスを一致させるという規約がある。yaml でグループが一元管理され、それが CI で同期される。

そのため display name を変えると CI が落ちる。

display name なんて user preference な値をキーにするなよというのはごもっともであるが、これによって ID の強制ができるので、ID のみでコミュニケーションができる。

現状の慣習だと休み予定などのステータスを display name で表現する組織が多いように思う。組織も大きくなってきており、周知だけでなんとかするのも難しくなってきた。

実装だが、残念ながら profile change 相当の event trigger はこの platform でサポートされていない。しかし意地でもマネージド環境で動かしたい。そのため、schedule trigger で定期的に動かしつつ、直近プロフィールを変えたユーザがなんかを api でとってくるか、display name がリポジトリにある yaml 定義と異なるユーザを見つけてきて、強制的に修正しつつ DM で通知する、という機構を作るのかなと思っている。

本当はプロフィール変更イベントをキャッチして戻すというふうにできればより簡単にできるだろう。ただ現状の影響が大きいので実装してしまおうと思う。

このパターンはある静的なパターン(yamlなど)との一貫性を矯正するということになる。が、event 稼働でなくスケジュールというところがラグがあってイケてないよなぁ。プロフィールになんらかの規約を持たせたくて、さらにそれを強制化したいみたいなユースケースがあれば同じパターンとして適用できるかもしれない。

まとめ

今後もアイデア集めと実装を進めたい。slack new platform も deno も typescript も開発体験が良くて気に入っている。

これまでの経験から以下がまなびかな

  • event trigger はチャンネル特定に絞るパターンに使うほうがよい

  • DB は bot のみがアクセスする前提で考えたほうがいい。保存されたデータをより広く使わせたい場合は別の場所に保存したほうが良い

わかっていないこととしては、

  • チームで開発する方法。各自 dev 用トリガーを作って貰えばそれでいいか

  - それはそうと dev trigger は使ったら削除しないと登録しっぱなしだと反応してエラー通知が来てうざいことに気づいた

というわけで happy coding!

その後は会社のブログで書くかも。

入社してから4年半

前回

blog.chaspy.me

2022年12月20日で Quipper に入社してから4年半が経ちました。

アウトプット

登壇はなし。ブログが2本でした。

blog.studysapuri.jp

blog.studysapuri.jp

何をしていたのか

このエントリで書いた通り、専門である SRE と異なる領域に範囲を広げたのが大きな意思決定だった。

blog.chaspy.me

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 プロダクトの中でそれを分業して価値を届ける、ということをマネジメントすることの難しさに直面している。 「難しい」と言っても、組織マネジメントの基本に立ち返ってやってやれないことはないと思うので下期はここの課題発見と対処に集中したい。

実装して技術力を上げる、ということは別の場所で行おうと思う。

今後のキャリア

しばらくは今の組織でマネジメントの経験を積むが、その後どうするかはアイデアが浮かんでいない。 自分自身のライフステージの変化もあるので、ゆっくり考えていきたい。

ありがたいことにこのツイートでいくらか反応をいただけたので真のカジュアル面談(所属組織の採用目的ではない)できるの楽しみにしている。

(引き続き若干名できると思うので DM お待ちしています)