便利。やや癖ある。
2種類あるらしい。ややこしい。
本記事では前者のほうの使い方メモしておく。
副業で kubernetes manifest をあれこれオラオラするみたいなときに利用した。
でいろいろ記事を書こうと思ったが example は動く形で GitHub に置いておくかとなり
こちらを書いて満足した。
一括処理をするときに、同じパターンを複数のサービスに展開する時などは環境変数から入れることが多いと思うのでこれを知っておくと便利。
kustomize のリファクタリングとかよくやると思うのでこれまた便利。
最近こういう学んだことメモやってなかったので GitHub に書いていくスタイルでやっていきたい。
ここ最近 new Slack platform (この呼び方が正しいかは知らない) でいろいろ作って遊んでいる。
使い心地や特徴、基本的な使い方は日本語記事でもたくさん出ているのでそちらに譲るとして、これまでやってきた今年含め冬休みに実装したいアイデアを記録しておく。
完全に身内のホビーアプリで、決められた問いかけに対して決められた文言を返すのみ。
いまオススメの店をサジェストする機能があるが、これをユーザが登録できるようにしたい。現状は conf ファイル的なところに静的に書かれているが、非エンジニアにプルリクを送れというのも無理だと思うので。
これは slack の DB と、Link trigger でできそうである。
特定のリンクを貼って、ワークフロー的な入力画面を出してオススメの店をユーザが登録すると、DB に登録されるようにできそうである。link trigger 自体は使ったことないので本当かはわからん。
抽象化すると、アイデアやネタをユーザが登録し、botがなんらかのアルゴリズムで返却するということができる。これは今回のような趣味の知見共有もだし、業務のトラブルシューティングだったりオンボーディング支援だったりと、集合知の収集と活用というパターンで幅広く使えると考える。
プロトタイプまで作ったが実用化するのは断念した。
@thanks @mention message と投稿すると、メンションされた人がこれまで感謝された回数を返信する bot である。
結果は DB に保存して、その総数を返信するところまではできた。DB を使ってみたくてやってみた案件。
実用化できない理由は以下。今回は event trigger (今回だと app_mentioned trigger )であるが、
他の bot へのメンションでも反応してしまう
channel_id を trigger で指定する必要があり、app が動くチャンネルが制限される
いずれも Slack DevRel の瀬良さんからワークアラウンドを紹介いただいたが、
こちらでご報告いただいた問題、まだ直ってはいないのですが、回避策を整理して記事にいたしました。もしまだご興味おありでしたらぜひお試しください。 https://t.co/P7fBM9MIJQ #SlackDevJP #Deno
— Kazuhiro Sera (瀬良) (@seratch_ja) 2022年12月21日
なお、今の挙動が正で filter で自分のアプリのメンションかどうかを判定する必要がある場合、先ほどお示ししたようにトリガーを設定するワークフローを別で作って、そっちで https://t.co/D5qh1quaZ2 を呼び出した上で trigger を生成すれば filter.statement に ID を埋めることが可能です。
— Kazuhiro Sera (瀬良) (@seratch_ja) 2022年12月4日
1 についてはまだフィルターしたり、あるいは本家が治るのを待ってもいいのだが
2 はユーザが登録チャネルを増やすのを link trigger でやる、というのをイチイチやるのは面倒である。いつでもどこでも thanks したい。そのため見送った。
ワークスペースグローバルな event trigger が許容されるといいが、まぁベータだしチャネル制限はするよなというのはわかる。内部構造はわからんがグローバルだといろいろ負荷は大きそうだし。
自分のチームはチームへのメンションに特定のリアクションをつけ、reacji で特定のチャンネルに流して、それを daily meeting でおさらいして共有したり、新規で反応できてないものへの対応策を決めたらするという営みがある。
ただしこれでは統計量の収集をしたり、中長期での分析をするのに一手間必要になってくる。
そこで該当チャンネルへの message posted event を使い、spreadsheet に追加する bot を実装したい。
spreadsheet じゃなくても DB 保存でもいいのはいいんだが結果のメンバー共有は楽にしたいので。
emoji_changed event でもいいんだが、前述のチャンネル制限の問題がある。こちらは自分のチームはの問い合わせが起きるチャンネルはある程度限定されるものの、どこで発生するかはわからない。
そのため現状の reacji 運用を続け、流されるチャンネルでのみ動くようにする。
気になりとしては reaji がついたメッセージだけをフィルターできるかどうかぐらいである。(スレッドに回答サマリーをメンバーが登録している)
message post のデータでフィルターできなくとも、まぁ最悪 emoji ついてるかどうかをファンクション側でフィルターすればいいからなんとかなるかなと思っている。
これは抽象化すると、特定のチャンネルのメッセージを分析可能にする(シートに転送する)という処理になる。native に会話されてるチャンネルでやってもいいかもしれないし、今回のように reacji を活用すれば特定のコンテキストを人間が収集し、それを分析できるようになる。これも活用可能性は広いアイデアだと考える。
所属会社での 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 trigger は使ったら削除しないと登録しっぱなしだと反応してエラー通知が来てうざいことに気づいた
というわけで happy coding!
その後は会社のブログで書くかも。
前回
2022年12月20日で Quipper に入社してから4年半が経ちました。
登壇はなし。ブログが2本でした。
このエントリで書いた通り、専門である SRE と異なる領域に範囲を広げたのが大きな意思決定だった。
9月に入りはじめてから4ヶ月。期初のマネジメント（組織戦略策定、メンバーミッション策定）と新メンバーとの関係構築はできたと思う。 また、SRE との兼務という点も、SRE メンバーへの権限移譲と、関わるメンバーとの期待値調整を丁寧にすることでできている。
当初の狙いとしては、「ビジネスにエンジニアリングで貢献する」ための洞察を得ること、より直接的に貢献すること。副次的には自分の（Web Frontend / Bakcned）技術力も向上できればいいと思っていた。WebDev と SRE の両方を見ることで、双方にポジティブなフィードバックを与えることでより開発組織全体を良い方向に動かしたいと思っていた。 そしてロールは Engineering Manager であり、マネジメントを第一義に行うべきなので、実装は行わない（ただしより評価を正しいらしく行うことを目的として、緊急性のない実装はチャレンジしたい）という心持ちだった。
これについて、正しかったと思いつつ、「実装できるかも」という考えは甘さがあったと思う。 1つは僕個人のスキルの問題で、学びながらやる、というオーバーヘッドをチームにかけることはチームのアウトプット総量を増やすという役割上、避けた方がいいと思った。 もう1つは組織の状況の問題で、職能横断型チームで構成している現状の組織ではマネジメントで解決すべき問題が思ったより山ほどあった。まずそちらをやるべきである。
この半年間、「マネジメント」と呼ばれる領域の仕事の難易度が1段階あがり、新しい経験ができている。 それぞれの組織ごとに振り返ってみる。
マネジメントの方針は大きく変えていない。メンバーが自律的に動けるような目標設定やチーム戦略を決定し、失敗も成功も含めほとんどをチームにお任せする方針である。これが最もメンバー・チームがパフォーマンスを出せると判断している。 その上でマネージャとしてはチームがより前に進めるような 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 お待ちしています）
マネジメントの技術の1つとして、現場にいなくてもマネジメントをする方法があることを知った。 この記事で言いたい"マネジメント”と指すものを具体的に言うとメンバーの状況把握や評価の情報集め、チームの状態を把握する、問題を把握する、みたいなところを指す。
こういったものを知るには、自分が直接「現場」（＝チームのミーティングや作業に立ち会うなど）に行って直接収集する方法と、他者を通じて収集する方法がある。 後者は、メンバー1人ずつと 1on1 で話すことでもいいし、別のマネージャから見えているものをヒアリングする、別のメンバーから聞く、などの方法がある。
マネージャはなんらかの意思決定者・責任者であることが多く、放っておいても多方面から話がきやすい構造になっているのでミーティングが増えやすいというものがある。 そういう状況を考慮すると、チームを前に進めるために常に自分がいなければいない状況をなるべく少なくするほうが利口だと思うだろう。
1on1 では驚くほど多くのことを知ることができるな、というのが今複数チームをマネジメントをしていて思ったことだった。 ましてや僕は今片方のチームでは"落下傘マネージャ" = そのチームにメンバーとしての期間を経ずにいきなりマネージャになった身であり、現場の情報を把握する数少ない、確かな情報源の1つであった。
でも、ここで、1on1 でわかるから十分だな、と一瞬なりそうになったのだが、やっぱりそれでは良くないな、と思い直すことになった。
1つは、1on1 の時間の使い方について。 このような使い方だと「マネージャの情報収集のため」が第1目的になる。さらに現場にいないのであれば報告する情報量も増え、メンバーにとっては下手すると「業務報告」の場になりかねない。 別にそういうマネジメントスタイルが良くないわけではない。1on1 を頻度高くやっているのであればそれでもいいのかもしれない。 僕の場合は複数チームのマネージャをやっていることでミーティングの時間が物理限界になっていることもあり、1on1 は直属のメンバーでも基本的には隔週としている。 隔週の1on1で業務報告で終わるのはイマイチだと僕は思う。1on1 はメンバーのための時間である。
マネジメントや 1on1 への期待値を話した時、あるメンバーから「業務の共有よりは技術の深い話をしたい」ということを言ってもらった。 1on1 への期待値は人によって違って良いのだが、業務報告よりは〜という需要はあるのだな、と思い、1on1 に情報収集を頼りすぎてはダメだ、と思った。
もう1つは、必ずしも全ての人が 1on1 で正しい情報を届けられるとは限らないということ。 「業務報告」スタイルを取っていたとして、その情報が過不足ないかどうかはわからない。 戦略策定や組織課題の把握、人事評価のインプットに足りうる情報が揃うのかどうか、それを正しく言語化できるのかどうか、そもそも伝えてくれるかどうか、というのは人による。
現場にいるからこそできる 1on1 での会話というものもある。 実際僕はチームのスクラムセレモニーだったり、チームミーティングのほとんどに出るようにしている。（細かい技術的な会話はもちろんメンバーに任せているが） そこで見えるもの、あった出来事をもとに会話を深めて行けるように思う。
現場に出るにも、頻度高く1on1するのも、どちらも同じ「時間の割り当て」 = マネジメントであるから、どの選択をするかそれ自体からマネージャの仕事であり技術である。 今のところ僕はそれをどちらかに極端に振らず、出るミーティング、出ないミーティングの期待値を合わせながら、1on1 を適切な間隔で行うことで、1ヶ月と少し経った今なんとかやっていけていると思う。
いよいよ残るは「技術」である。エンジニアリングマネージャなのだから、ピープルマネジメントは上記のようにできたとして、エンジニアリングをマネジメントするには技術に習熟する必要がある。 期初のマネジメント(9月〜プロダクトの背景、組織の状況把握 / 10月〜戦略策定、メンバーとの関係構築 / 11月〜 ミッション策定)を経て、ようやくソースコードを読み始めることができてきた。 技術課題を正しく理解し、正しく解決できるようにするには伸びしろしかない。別の分野を深く知ることは今回チャレンジしたかったことの1つなので、今すごく前向きな気持ちでいる。
妻の意向で FP さんに相談する過程で、今の会社にいつまでいますか、とか、年収のピークはどのぐらいですか、と問われることで、あらためて自分のキャリアが自分あるいは家庭のライフプランの大きな変数なんだな、ということがわかった。
先のことはわからない、の一辺倒ではダメで、そこそこの不確実性の低減をした上でローンとかいうリスクを取る、ということをしなければならんのだなぁ、と。
で、今のキャリアを考えるに、エンジニアリングマネージャー、所属組織でいうところのミドルマネージャーというか、その次、となるとさらに上のマネジメントをやるか、プレイヤーに戻るか、が大きな2択としてある。
エンジニアリングの世界に身を置くなら、どこかのタイミングでプレイヤーに戻ることはあると思うし、そうしたいと思う。
今のところマネジメントという新しい領域を学ぶのが楽しいので、しばらくは続けたいし、マネージャーオブマネージャーだとか VPoE だとか CTO だとかのポジションはそもそも機会を得られる人が少ないのでやれるならやってみたいと思っている。
ソフトウェアエンジニアリングを出発点に持ちつつ、いつかは経営やってみたいなと思っている。なぜなら一番潰しが効くから…。それに、経営がうまくいかないとエンジニアリングをやることもできないから。
こういうのは多分発信した方がうまくいく。マネジメントをはじめてまだ1年。最低2年はやると決めた。そしていま新たに Web Dev のほうも兼務した。寿命がさらに1年伸びた。1年で、どういう世界なのかだいたいわかった。そこそこやれる術も手に入れた。そろそろその次を見据えて行動したり、その上での仕事をデザインしたい。
次の1on1で上司に、次のポジションに対する自分の能力/Capabilityのdiffはなにか、それを埋めるためには何をすればいいかの話をしようと思う。自分でもだいたいわかっている。
---
嵐のような毎日を送っている。最初はとても不安だったが、この1ヶ月なんとかやれている(と思う)。やってやれないことはない、そうやってチャレンジしてみて、それをみんなが受け入れてくれたことに感謝している。
次へ、もなにも今の半年走り切れるかどうかもあやしい。知らないことばかり、やること、やらないといけないこと、山ほどある。だけれど、与えられた責務はバッチリ果たしながら、次への種も蒔いていきたい。ようやくそう思えたので、元気です。あとやっぱり生き急いでるな。
ここ最近ずっとやらないことについて考えている。
期待値調整といえばそれまでだが、やらないことに向き合ったことにより、やることにフォーカスできた、というのとはちょっと違う感想を持った。
自分がやらないことは、誰かがやることである可能性が高い。もちろん、自分もやらないし、誰もやらないということもあろうが、やらない"コト"に対して、じゃああなたがやらないならそれはどうするの？ということに向き合ったというか。
そして、やることとやらないことを発信するだけでもまだダメで、「なぜそう思うのか」まで付加しないと納得感は得られない。資料を準備して、話してみて、個別にフィードバックをもらって、なるほどそう思うのか、そう伝わるのか、ということがわかって、さらにブラッシュアップして文字通りの"期待値調整"が完了する。
「やること」を言うだけではダメで、それってどういうふうに、どの範囲で、何のためにやるんですか？の説明が足りてないと混乱を招く。 「やらないこと」を言うだけではダメだ、そのやらないことは誰にどういう形で期待するのかを明確にしないと不信感をもたらす。
「暗黙のやらない」よりはマシだが、やらない宣言に加えて、やらないことをどう「Manage（なんとかする）」しようとしているんですか、というところまで期待値を説明しないといけないんだなということがわかった。
なった。10月から。
ちょうど1年前、元々所属していた SRE Team の EM になった。1年間、SRE Team のマネジメントをしつつ、SRE Team が活躍できる機会を提供し続けられるように、どちらかというとユーザーでもある開発チーム、あるいは開発部全体のことに目を向けていた。開発チームがチャレンジングなことをしようとすればするほど、SRE Team もよりチャレンジングな課題に挑戦できるはず。現状と未来、両方を見つめてやれることをやってきた。
SRE Team は開発チームが作るシステムが安定稼働できるよう、開発チーム自体のシステムの Controlability を高めることや、それに関連する開発者生産性を高めることをミッションにしている。
つまり、ユーザは開発者である。Platform もプロダクトとして考えると、ユーザのことをよく知る必要があるし、ユーザーからフィードバックを得る必要がある。今その Capability をチームとして得られるよう、サーベイやペアプロなどあらゆる方法を試し、獲得しつつある。
僕自身、所属組織の開発者の立場になったことがない、ということがずっと引っかかっていた。一時期は開発チームへ留学をしたいと言ったこともあった（結果的に自身の決断で当時はそれを選択しなかった）。ユーザの立場になったことがない状態でユーザが望むものが本当に作れるのか。目隠し状態で挑んでいるような、そんな気持ちに定期的になっていた。
だから、実際に自分が飛び込んでしまう、という方法を、兼務という形で取ることにした。自分で希望した。たまたまポジションが同じタイミングで空いた。
...というストーリーに SRE Team の立場から言うことはできるが、実際はもっとパーソナルなところから出発した。自分のキャリアをこの1年考えていた。
僕はいつも次どこにいくか、しか考えないようにしている。10年後どうする、20年後どうする、と言ってもうまく描けないし、そうやって間を埋めて計画的に動けるならいいけれど、明確な次があってそのために必要なことにフォーカスする、あとはどういう選択肢が出てくるかはわからんし、その時考えればいい、という考えだ。
SRE Team のメンバーだった時は、所属会社のキャリアパス的にも Engineering Manager か Senior Software Engineer の2択で、どちらもなれたらいいなと思いつつ、興味があったのは EM のほうだった。3年半やって、EM になった。はて、その次は。
そういった中、たまたま所属会社で「キャリア申告/キャリア面談」という制度があることを知った。案内のメールが来て、軽い気持ちで書いてみて、軽い気持ちで「面談を希望する」というチェックボックスにチェックをした。その後設定された面談が僕の今回のキャリアを決めた。
この面談は意図的に直属の上長ではない、斜めの関係の方がアサインされる。まったく別の領域の、上長相当の方だった。その方はかつての同僚から良い評判として名前を聞いたことある方だった。
1時間の面談。事前に相談内容をドキュメントにまとめておいたのが功を奏して、事前に読み込んできてくれていて、短い時間ながらも単刀直入に結論をアドバイスしてくれた。「プロダクト開発の EM を経験したほうがいい」ということだった。
次のキャリアといっても行き先はいろいろある。マネジメント方向で部長・開発部門責任者(Director, VPoE)の方向、THE ENGINEER/MANAGER PENDULUM にあるように、振り子のようにメンバーに戻る方向。あるいは身を置く場所・領域を変えるという方向。
僕個人の立場に立った視点と、所属会社における立ち位置という視点の両方でアドバイスをくださり、それはとても納得感のあるものだった。
SRE や Security といった横断領域に比べて、世の中には圧倒的に事業会社が多い。事業に（より今より直接的に）貢献するという経験があるかないかは大きい。
そして僕自身、ずっとやりたかったことは ビジネスにエンジニアリングで貢献する ことだった。もちろん SRE だって貢献している。しかし、そこの感覚の遠さというのがずっと僕自身の引っ掛かりだった。それを得ることは、SRE だろうとプロダクト開発だろうと、企業組織で生きる中で大きな経験になると思った。
...ということで"他人のアドバイスは全部実践する"で生きてる僕としては「はい！やります！」となり、金曜にした面談の翌週火曜に直属の上長にキャリア面談を申し込み、内容の共有と、そういうポジションはないか、と相談したら、10月から空くかも、となり、その領域のマネージャと相談し、やることになった。
面談したのは7月後半。8月の前半にはやる方向で固まり、8月後半には体制面含めマネージャたちと相談しながら準備し、9月に社内の関連メンバーに内示をした。
トントン拍子だね、とも見える。自分でももう少し批判的な意見があるかと思ったが、上長、マネージャ、メンバーみんな（懸念が0ではもちろんないにせよ）基本スタンスとしては応援してくれた。
「兼務」という言葉にポジティブ成分とネガティブ成分、どちらが強いかというと、どちらかというとネガティブを感じる人が多いんではないか。僕もそう思う。というのも、時間は有限、身体は1つ、コンテキストスイッチに人類は弱い、となると兼務するとパフォーマンスは落ちそうだ、と考えるのは自然だ。
そんなことはわかってる、何度も自問した。ただ、やってできないこともなさそう、ぐらいには勝機もあった。というのも、もともと担当チームのことはチームに任せるマネジメントスタイルで、僕自身は別のことをやっていたので、身体の予算的には賄えるのはでないか、と。
これは半分正解で、半分間違いだった。1つのチームを見て、自分が他のことをやっている状態と、複数のチームをみる状態というのは違う。明確にマネジメントのスタイルを変えないといけないことに9月終わりにギリギリ気づいた。エンジニアのマネジメントキャリアパスでいうところの 5章 チームの管理 から 6章 複数チームの管理 にステージが変わる。
今まで以上に「何をやらないか」の期待値調整をすることが求められる。幸い、新しく担当するチーム含め、チームの運営自体はマネージャがいなくても回るようになっているし、メンバー皆優秀で信頼できる人たちばかりだ。そういう状況で、EM として何をやって、何をやらないか、その戦略をこれまで以上に考えるいい機会になった。
SRE Team については一部の業務やミーティングなどを Team Lead を立ててお任せする方針を立てて、可処分時間が少ない中、自分がボトルネックにならないように調整した。 新しいチームも近いスタンスで関わる期待値を言語化、すり合わせをしていく予定だ。
この話を別のマネージャと話した時、「純粋なマネジメントというスキルを学ぶ機会になりそう」というコメントをもらってなるほどなと思った。もちろん会話可能・評価可能にするためには Web 開発のスキルも一通り抑えるつもりではあるものの、そのスキルを発揮しにいくわけではない。まさに今考えているようなことを考えざるを得ない状況になったわけだ。
なぜだかマネージャというロールに暗黙の期待値の高さみたいなものがあるような気がする。僕自身も自分の上長に対してあると思う。マネージャはロールである、といいつつも、実際は評価者被評価者という利害関係がある。そして責任者でもあるわけなので、それはそれなりに期待値があるよな、というのもわかる。
ただ、実際にその立場になってみると、頭では理解しながらも不安がある。しかし不安など言っても責任もある。そんなことは言ってられない。やってやろうという気概もある。ここで何食わぬ顔で一見普通に取り組んでしまうと、マネージャはやはり超人なのである、到底やれる気がしない、などと思われるのも不本意でもあり、表現に悩ましい。
一見わかりづらいマネージャの仕事、酸いも甘いも発信していくしかないのだ。
ポジティブな話で締めよう。
SRE Team の状況はとても Exciting である。人数自体を一定に保ったまま、環境の変化に対応し、「Team としての Capability」を確実に向上できていると考えている。これはチームのパフォーマンスが上がり続けていることに他ならない。「個人の実力」を最大限に活かし、イノベーションを起こしてもらいながら、チームとして発揮する価値の総体を大きくしていく、そういったマネジメントの醍醐味みたいなことがどんどんできていくのがとても楽しいし、嬉しく思う。
新しく入るチームは元々担当 EM がいなかったこともあり、自律的に動けており、こちらも個々人のプロフェッショナルな部分を発揮しつつ、全員がチームへのリーダーシップ・フォロワーシップを発揮する、ということができていて、（チーム内のことについては）本当に何もすることがないな、という状況で驚いている。
新しく入る開発領域は、内部で3チームに分かれていて、そのうちの1チームを担当することになる。EM としてはこの3チーム全体のことを考える必要がある。また、ビジネスの状況としても新規開発に対する投資も今後予定されており、それに対して既存の課題をどう解決しながら前に進んでいくのか、まさにビジネスに対してのエンジニアリングの貢献を考えざるを得ない状況にある。もう1名の EM とは得意不得意がいい感じにバラけており（多分）協力しながらより良い世界を作っていきたい。
というわけでマネージャ2年生、まだまだやれることがあるので頑張ります。飲みに誘ってください。