ツナワタリマイライフ

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

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

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

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

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

こういうのもか。

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

  • 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 お待ちしています)

現場感とマネジメント

マネジメントの技術の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つなので、今すごく前向きな気持ちでいる。