今年の夏頃から会社で4-5人チームのリーダーをやっている。
新卒で入社したころはまさか自分がリーダー的存在になるなんて思っても見なかったが、やってみるとこれはこれでおもしろい。来年になる頃には自分がなんでこの選択をしたのか忘れてしまいそうな気がするので、ここに書き残しておく。
やってみようと思った理由
正直なところ、学生時代から「やっぱエンジニアはコード書いてナンボ」みたいな気持ちでいて、当初はリーダーだとかそういうものには微塵も興味がなかった。Twitterとかを見ていても「マネジメント層になるとコードが書けなくなる」みたいな話もちらほら目にしたり、そういうものを見ると尚更「そんなんやるもんじゃねーな...」と思っていた。
しかし、実際チームでマネジメントをしている人をみている限りでは、マネジメントをしているからコードが書けないだとかそんなことはないどころか、ビジネス的な視点とエンジニアリングの視点がいい具合に混ざり合って、大局的に物事が見えているようにも見えた。そのような事実を目にすると、少しづつ自分の中で「自分が目指すキャリアというのはこれなんじゃないか?」という気持ちが高まってきた。
加えて、社外の人々の話を聞くところでは、国内のベンチャー(メガベンチャー、ミドルベンチャークラス)ではどの企業においてもプロジェクトをマネジメントする層が絶対的に足りていないという話を非常によく聞いた。眉唾ではあるが、聞くところによればいまのベンチャー界隈におけるマネジメント層は年齢的に20代後半から30代前半であることが多く、この世代はサブプライムローン危機による就職の難しさやライブドア・ショックでIT企業に対する良くない印象がついた時期でもあったため、そもそもソフトウェア産業に携わる人間の絶対数が窪んでいるのではないかという話である(要出典)
なるほど、そういうことであればなおさらマネジメントをやったほうがいい。人がやりたがらないことをやることで自分の価値が上がる。そんな理由でマネジメント・キャリアに進んでみることにした。
マネジメントをするエンジニア
マネジメントをするようになったとはいえ普通にコードは書くし、いまだに機能開発のコーディング作業が1日の大半を占める。この部分は以前とあまり変わらないところだと思う。逆に、自分の中で大きく変化があったのは、自分のチーム以外の状況を今まで以上に意識するタイミングが増えたことか。
自分の開発しているプロダクトでは自分のチーム以外にもいくつかのチームが存在している。ビジネスサイドのロードマップだったり開発進捗は毎日変化するため、常に状況を鑑みて他チームのリーダーを話し合いチームリソースの配分であったりリスケジュールを行うことになる。この種の意思決定をするには、チームの開発進捗だけではなく他チームとのリソース調整を考えたり、ビジネスサイドの動きをみつつスケジュールを考え直したり、これはかつてのように1プレイヤーとしてただコードを書くだけでではあまり意識できないところだと感じた。
逆に言えば、一度こういう視点を身につけると今度はメンバとして働く上でも強い。仮に自分がリーダーではないとしても、リーダー的な視点を持って意見や提案をできる。これはやってみないと分からないところだと思う。
マネジメントのおもしろさ
今の会社だからというのもあるかもしれないが、やはりマネジメントは「自分でコントロールしている感」がすごくあり、これはめちゃくちゃにおもしろい。もちろんその分責任も大きいが、自分の意思決定がビジネスにインパクトを与えるというのはまた一味違ったおもしろさがある。
マネジメントというと様々な重圧がありそうな雰囲気もあるが、個人的にはいまが一番多くの人に頼れているようなそんな気がしている。チームのメンバ、ほかチームのリーダー、上長、などなど、1メンバとしてチームで開発をしているとき以上に自分が関わるネットワークが大きくなり繋がるノードが増えたような、そんな感じ。
- 作者:James O. Coplien,Neil B. Harriosn
- 発売日: 2013/08/23
- メディア: Kindle版