とあるSIer上がりの人間が、チームマネジメントを経験するまでの変遷 • Tomorrow Will Be A Better Day

Classiアドベントカレンダー18日目です。

ちょうど2年ぐらい前にチーム運営についての記事を書いたのですが、職場も立場も変わったので、ここ数年の自分の振り返ってみようかなと思います(会社のアドベントカレンダーなのに、会社の技術について触れない投稿w)

1.職位の変遷と意識の変遷

前職に入社したときは、しがないスタッフエンジニアだったのですが、職位が上がるにつれ、意識していたこと（&求められること）が変わっていったので、その変遷を書いていってみようかなと思います。

1-1.メンバー期

意識していたこと：「上司や同僚のスキルをひたすら学ぼう」
SIerからB2Cの会社に移り、当時は触る技術の何もかもが新鮮だった時期。
上司や同僚などがIRCなどで発言していることの理解を深めるのに精一杯で、仕事でチャットを使うということも初めてだったこともあり、IRCの発言タイミングも全然わかりませんでした^^;
そんな中、ターミナルのショートカットキーやOSの歴史など、チーム内勉強会などで当時の上司から教えてもらった内容は、すごく面白い話が多かったです。
当時の上司からすると、「こんなこともできないのか」という感想だったと思いますが、自分にとっては「すごい人いるんだなあ」と毎日が刺激的な時期でした。

1-2.リーダー期

意識していたこと：「自分が率先して、技術面で問題解決をしていこう」
お世話になった上司が退社され、自分である程度の技術選定ができるようになった時期。
OSのリプレースを行う際、現行カーネルパラメータなどを調べたりして、「ああ、こんな設定方法あるんだ。
やっぱすごいな、あの人」とか、既存環境の運用においても、まだまだ新しい発見がありました。
この時期に一緒に働いていたメンバーは、あまり部下や上司だとかそういった意識はしておらず、フラットで一緒に悩める相談相手みたいな関係で業務を行っていました。このあたりの時期あたりから、特定の技術本よりは、少しマネジメントよりの本を読むようになりました。
影響としては、エンジニアの椅子を購入する際、ピープルウェアを紹介していた執行役員の方や、トム・デマルコ本を薦めていた技術顧問の方などの影響が大きかったと思います。自分が行ってきた動きと違った悩み（メンバーとの距離感やチーム運営方法など）が出てきたのはこれぐらいの時期だったので、こうしたプロジェクトマネジメント本は、当時の自分が読むにはちょうどよい時期だったのではないかと思います。

1-3.マネージャー期

意識していたこと：「メンバーの働き方をサポートしよう」
私自身に求められる成果について、周囲からの期待が大きく変わってきた時期。

「君は手を動かさずに、メンバーの動きをサポートしてあげて」
「組織課題をチームで解決して欲しい」

このあたりは、私の上司から定期的に言われていたことでした。
場合によっては、技術を使わず、部署間の交通整理を行うことも求められる動きだったので、必然的にMTGの数が増えていきました。
また、メンバーの工数が膨れ上がらないように、問題を先回りして潰しにいくなど、自分のタスクではなくチームのために動くことが大半だった時期でもありました。
「自分がやってみたい」けど、「自分は手を動かさない」という判断をすることが増え、だんだん自分よりもメンバーの方が詳しいことが増えてくるといった危機感の中、組織やメンバーに対して思うこともありつつ、メンバーや他部署の人の前では言葉を選ぶなどといった行動ができるようになりました。

2.メンバーとの交流の中で得た教訓

私はマネージャーとして全く優秀ではなかったのですが、メンバーと交流する中でいくつか経験したことがあったので、どこかで悩める人の参考になればと思い、いくつかの活動における振り返りをしてみようと思います。

2-1. タスクとリスクマネジメント

教訓：ビジネスの合間に生じる、凪のタイミングを見逃さない
残念ながら、私の場合は、組織課題に対して、日々のタスクの方が優先度が高い状態が常態化し、現場とマネジメント側で期待しているタスクが乖離してしまっていました。
そこまで現場がタスクに忙殺されないようにするというのが一番なのですが、ビジネスによっては、集中的に改善の機会ができるタイミングがあるので、そのタイミングを見逃さないことが必要になってきます。
なお、私は、ビジネス上における、凪のタイミングを見つけたときに、そのタイミングで退職するという判断をしてしまいましたが、組織に残る判断をするのであれば、このようなビジネス上の凪のタイミングを見逃さないことが重要だと思います。

2-2. 1on1ミーティング

教訓：課題を解決できる権限とセットで、1on1をやるべき
最初に1on1をやりはじめたときは、「我々のチームと他部署をブリッジするには、こういう活動をしてはどうか？」など、具体的な提案を一緒に考えてあげられました。
ただ、だんだん1on1の回数を重ねていくと、「チーム内で困っていることはないか？」という回答において、「組織の意思決定がぶれています」「人が足りないです」という組織課題について話すことが増え、議論に発展することが増えてしまいました。
また、すぐに解決できる問題がなくなってしまったことにより、前回の1on1と同じ課題について話すことが増えていき、メンバーのヒアリングする機会が形骸化してしまったので、もっとヒアリングの仕方を工夫するなどできたんじゃないかなあと反省しています。
ちなみに、今の職場の同僚は、1年近くも1on1を行っており、すごくうまく回しているので、本当に尊敬しています。

2-3. 技術検証日の設定

教訓：まったく運用できなかった。組織に合わせた文化を作ることが必要
インフラチームは、ASAPのタスクを求められることもあり、そんな中でもメンバーに技術検証やブログ執筆などのセルフブランディングができる時間を設けてあげたいと考えていました。
ただ、当時の組織は、Infrastructure as Codeと組織文化の資料にある、組織構造1-2のような組織で、各サービスに強いメンバーが対応している状況でした。
そのため、チームでタスクを受け持とうとしても、どうしても突発的な相談がその人に集中したりして、結局はその人が対応することになったり、メンバーが技術検証する日であっても、うまくタスクをバトンタッチできない状況が続き、早々に形骸化していきました。
また、メンバーも技術検証やセルフブランディングの必要性を感じていなかった様子だったので、全く空気作りができなかったなあと反省した施策であります。

3.まとめ

いざ書き始めてみると、半年ちょっと前のことも忘れている自分に気づきました。当時の自分への戒めを兼ねて、自分が経験したことを書き残しておきます。