開発者がManagerになる前のひとりごと

それはいつも通りの仕事の日でした。昼食を終えた後、CTOが突然私に言ったのです。「次の半期、Managerをやってみない？」その時の私は平静を装いましたが、実は以前Team Leaderを務めた際に批判を受けた経験がありました。全体的に意外な話でしたが、こうして決まった以上、この機会を掴み取り、同じ過ちを繰り返さないようにしようと決意しました。

役割の変化：コードを書くことからチームを率いることへ

現在の役職はTeam Leaderですが、実際の仕事の大半はPMとのコミュニケーションや技術調査などです。管理業務も少し行っていますが、全体的には技術よりの内容です。

Managerになれば、管理業務は大幅に増えるでしょう。例えば、チームが担当するプロジェクトの推進や完了、メンバー間の連携・コミュニケーション、そして他チームとの協力などです。

注力するポイントも変わります。以前は自分のグループ内の成果物だけを見ていれば良かったのですが、Managerになるとチーム全体の成果物やメンバーの成長に目を配る必要があります。主に技術的な問題を解決することから、人に関する問題を解決することへと軸足が移るのです。

もちろん、まだ正式にManagerとしての仕事を始めたわけではありません。具体的な進捗があれば、また更新したいと思います。

現在の準備

この期間、ずっと《Become an Effective Software Engineering Manager》を読んでいます。

読書以外にも、もう一つ取り組んだことがあります。それは、チームの現状を「スナップショット」として記録することです。

どういうことかと言うと、現在のチームの状況を詳細に書き留めるのです：

• 各メンバーがどのプロジェクトに取り組んでいるか
• プロジェクトの進捗状況
• 技術的負債は何があるか
• チームの雰囲気はどうか
• メンバーの仕事の状態

こうすることで、3ヶ月後に比較できます。私のマネジメントによって本当に物事が良くなったのかどうかを。もし変わっていなければ、それは私の方向性が間違っていたということでしょう。

もう一つの準備として、先延ばし癖を直すことにしました。

例えばブログ執筆ですが、以前は2週間に1本と決めていても、いつも締切の前日になってようやく何を書くか考え始める始末でした。その結果、記事の質は上がらず、自分自身も焦っていました。

これほどの自己管理もできないようでは、どうやってチームを率いていけるでしょうか？

私の不安

準備はいろいろとしましたが、正直なところ、最も心配なのはまた同じ轍を踏むことです。以前批判を受けたのは、マネジメント能力、あるいは報告能力が不足していたからでした。ただ、この期間の経験を経て、そうした不安はありつつも、困難に立ち向かっていくつもりです。

来月の今頃になれば、今日書いたこれらの考えを幼稚だと感じるかもしれません。あるいは、心配していたことが全くの杞憂だったと気づくかもしれませんし、全く予想していなかった課題に直面しているかもしれません。

でも、それでいいのです。この記事はタイムカプセルのようなもので、今の私を記録しています——期待を胸に、そして不安も抱えて。

3ヶ月後に顔を殴られることにならないか、見ものです 😅

To be continued.