サービス開発エンジニアからマネージャになった話

はじめに

こんにちは、レシピ投稿推進室の勝間（@ryo_katsuma）です。 techlifeでの執筆は5年ぶり（！）になります。

さて、そんな私も今年2014年の5月にエンジニアからサービス開発の部署のマネージャに転身しました。 そこで今回のtechlifeブログは、いつもの技術ネタとは少し異なるテーマとして、「クックパッドにおいて、エンジニアからマネージャに転身する」ことが、どういうことなのかを自分自身で振り返り、まとめたいと思います。 エンジニアが自身のキャリアを考える上で、少しでも参考になれば幸いです。

現状

私は、2009年5月に中途入社し、今年で6年目になります。この年数は、エンジニア全体はもちろん、社内全体で見ても古い方になります。 これまで、技術部、HappyAuthor部（現在、私が所属している前身になった部）、新規事業部、プレミアム会員事業部...など、いろんな部署でサービス開発のエンジニアを行ってきました。

今は、クックパッドにレシピをのせてくれるユーザーさん向けのサービス開発を行う「レシピ投稿推進室」という部署のマネージャを行っています。 日々、ユーザーさんが「クックパッドにレシピを投稿してよかった」と思ってもらえるようなサービスや仕組みをメンバーと考えています。 メンバーの数で言うと、自分を除いて10名のメンバーが所属しています。この数は、会社全体で見ても1つの部署としては、メンバー数は多くもなく少なくもなく、平均的な数字になっています。

マネージャへの転身

背景

まず、マネージャというポジションについては、2, 3年ほど前から興味は持っていました。 ただ、明確に「いつまでにこの部署のマネージャとして」という強い思いではなく、 「機会があればいつか挑戦してみたい。」くらいのふわっとした思いでした。 当時はまだ自分事として捉えておらず、まずはエンジニアとしての成果を出すことに集中していました。

一方で、エンジニアとして技術一本で生きていけるかと言われると、それも怪しいと自分自身で考えていました。 特に、2010年辺りからは、業界内でも有名なプロダクトを作ってきたことがあるようなエンジニアもどんどん入社してきて、彼らと技術力だけで競い合っていくのは、難しいと感じていました。 つまり、エンジニアとして技術ではなくサービスを生み出す力を伸ばしていくか、ポジションを変えてマネジメントの力を付けていくか、どちらかに絞る必要が出てくるだろうなと、ここ数年は感じてました。

そんな中、ここ２年ほどは「エンジニアリーダー」としての仕事をいくつかの部署で経験することができていました。 エンジニアに対する、ガッチリとしたマネジメントまで行わないものの、部署のエンジニアのコードレビューを行ったり、部のエンジニア評価を行ったり、いわゆるエンジニアリングに関するマネジメントを統括的に見ていました。

これは、マネージャとエンジニアの間を取り持つポジションにもなるのですが、普段の業務の中でのエンジニア間の雰囲気作りや、部のエンジニアリングの方向性決めなどを行うことも、当時の部署のマネージャに少しつづ評価されはじめました。 実際、自分自身も少しづつこの仕事にやり甲斐を感じ始め、「少なくとも全く向いていないことは無さそうだな」と感じ始めてました。

突然の依頼

そのままマネージャというポジションへの考えをまだ明確に持っていない日が続いていた中、 ある日、現在の部署の前部長に「ウチの部のマネージャになってみない？」という打診を突然受けました。

依頼理由としては、

  • ちょうど年度の変わり目で組織改編が起こり、前部長が新しい部署に移ることが決まっていた
  • 前部長ともエンジニアリーダー関連でよく一緒に仕事で絡んでいて、人なりがお互い分かっていた

などがありますが、「自分が務まるものなのかな…」と、驚いたことは事実でした。

ただ、

  • 依頼がかかった部署が自分が昔所属していた部で、思い入れも強い部署だった
  • 会社の事業を支える「レシピ」を投稿してくれるユーザーさんを向いた部署、ということで特にやり甲斐を感じる部署だった
  • マネージャに限らず、個人の可能性を広げる挑戦は会社が歓迎してくれる姿勢を見せていた

ということもあり、悩んだ結果、このタイミングで依頼を受けることにしました。

選択肢として、当時の部署に残ってサービス開発に専念するという手段も取れましたが、

  • 極端な話としてマネージャになった後でサービス開発エンジニアに戻って再挑戦することは可能（実例）
  • マネージャは後からなりたいと言っても状況によってなれない可能性も高い

ということを考えて、挑戦するならこのタイミング、と判断しました。

インプット

前述の通り、エンジニアリーダーの経験はあるものの、まともにマネージメント行うことは初めてです。 まずは、できるだけインプットを増やした方がいいかと考え、先人の考えを理解するためにもマネージメント系の本をいくつか読みました。

いくつか例に挙げると

など。 まずは、有名な名著を中心に、さらっとエッセンスを学べるものを数多く読んでいました。 ただ、これらの本も何も自分が動いていない状態で読むのと、動いたことがある状態で読むので 受け取り方が大きく変わるので、今あらためて読みなおしているところです。

また、実際に期の変わる前にメンバーとの面談を行いました。その中で

  • 今後どんなタイプのエンジニア/ディレクタになっていきたいか
  • どんな挑戦をしてみたいと考えているか

などの質問を行いました。 部の目標に向けた挑戦を行うことはもちろんですが、それ以外についてメンバーそれぞれがどういうところを目指して挑戦すべきか、それについて私がどういう手助けができるかを理解しておこうと考えました。

業務

実際にマネージャ業務を開始してからは、次のようなことを行いました。

  • 部全体の目標とKPI設定
  • 目標に向けた施策の遂行
  • 部内での定期的な進捗確認
  • 他の部のマネージャや、担当執行役との定期的な共有
  • エンジニア採用のために人事部への協力
  • 全社横断的な課題について、解決策の提案
  • ...etc

こう見ると、実際の部の業務以外のことの項目が多いことが分かります。 クックパッドもそれなりの規模の会社なので、他部署との連携を中心に組織的な課題への取り組みに時間を割くことは マネージャとしてある意味仕方がないのかもしれません。

自分なりに気をかけたこと

マネジメントという業務に対してはまだまだ経験もテクニックもないので、部内でできることも少ないのが事実です。 そんな中で、自分の中で強く信じられることは、特に注意して行動することを心がけていました。

やったことがないことに挑戦する機会を作る

よほど意識をしない限り、自分たちは慣れた手段、慣れたことをずっと行いがちです。 ただ、今までと同じようなことだけをやっても、個人も組織も新しい挑戦を行わないので成長に繋がることはありません。

なので、「個人として今までやったことがないことをやってみて、その結果として部の目標を達成できることは何なのか」を 考えるようにしていました。 たとえば、ここでは期初の面談で話していた「実は挑戦してみたい」と考えているものをできるだけ実際に挑戦してもらい、結果として目標数字に繋がる形を目指してもらうことにしました。（例：個人開発でしか触ったことがなかったAndroidアプリ開発を業務で行う）

新しい分野の挑戦は、本人の能力の幅を広げる機会になり、結果として組織内外においてその人の市場価値を高めることになるので、積極的に勧めていました。

結果、他の部署から「最近xxさん、いい感じだよね」のような声が上がってくることもありましたが、 マネージャとしては、社内からメンバーが褒められるような声を聞くのが嬉しいものです。

情報を積極的に伝える

マネージャ間で共有されるような社内の情報は、できるだけ早くメンバーに共有するようにしています。 自分自身の経験でもありますが、上から情報がなかなか降りてこないことがあると、 会社で何が起きているか不明瞭になり、組織に不信感を覚えることにつながり得ることになると考えています。

なので、

  • 自分が得ている情報は人事やインサイダーに関わる情報以外は極力全部口頭で伝える
  • 社員だけではなく、パートスタッフにも伝える

ということを意識してきました。

実際、共有する情報は全てが全て、実際に必要となる有益な情報ではないことが多いです。 ただ、そこは情報を受け取る側が取捨選択してもらえばよくて、 情報を咀嚼する中で会社がやってることに興味感心を持ってくれることが出てきて、 業務にも活きるものも出てくるかなと考えています。

これについては、定量的にも定性的にもいい評価はできていませんが、「もうやめてください」という声が部内から出てくるまで今後も続けようと思っています。

自分で手を動かすべきか、動かさないべきか

エンジニアからマネージャになった人ならではの話ですが、「自分で手を動かした方がいいのか、そうでないのか」という話について。

エンジニアは、良くも悪くも自分でいざとなったら全て１人で解決できてしまうものです。 ましてやマネージャは意思決定者でもあるので、自分でやることを決めて形にするまでノンストップで実現できてしまいます。

一方、いろんな本や文献を見ても、基本的に「マネージャはマネージメントに徹するべき」と言及しているものが多いです。 社内の前職でマネージメント経験者のエンジニアと話しても「勝間さん、自分でコード書くのはやめたほうがいいですよ」と言われることがありました。

そこまで言うなら、もう自分でコードを書かない方がいいのかな。。と思いつつも半信半疑。「自分はプレイングマネージャを極めたい！」と意固地になるつもりも別にないですが、実際に試して納得しないと気が済まない性格なので、自分自身でどういうメリット・デメリットがあるのか理解するまで試すことにしました。

サービス開発も自分で拾う

最初は、サービス開発も自分で拾うようにしていました。

  • アプリ開発は他のエンジニアが開発
  • Webは自分が開発

という領域で分けていましたが、 結局目の前の開発を行うことだけに集中しすぎて、部で進行させている施策全体を俯瞰して見れなくなってきました。

また、他の業務に忙殺されて、開発業務を気合だけで進めるようにするものの、結局時間がかかってしまい、改善も後手後手で勧めづらい状態になり、やり方を変更せざるをえないことになりました。（そういえば、最終的にはObjective-C勉強してアプリの開発にも手を出していたこともありました！）

溢れているタスクだけ拾う

メインの開発を拾っても、なかなかうまく回らないと自分で思ったので、 部内で、優先度の観点で溢れているIssueの対応を行うようにしました。 つまり、メインのサービス開発以外の改善系のタスクだけを拾うようにしました。

結果としては、

  • メインの開発を拾っていたときと比べると、以前より全体を俯瞰することはできるようになった
  • 一方で、現状を改善させることにやはり集中しすぎて、メンバーとのコミュニケーションがおろそかになった

ということがありました。

「やはり開発は控えて自分がやるべきことに時間をかけるべき。」と判断し、 人事に協力を依頼して、学生アルバイトのエンジニアを採用し、細かな改善系のタスクも依頼するようにしました。 また、メンバーともできるかぎり定期面談を行い1-1でじっくりコミュニケーションを取れるように工夫しました。

こうして振り返ってみても、「自分もできるから」ということを理由に開発に手を伸ばすことは、 避けたほうがやはり良さそうです。（先人の考えは正しかったですね。。） これ以降は自分に余力があるときのみ、それもメインの開発以外のものだけに絞って手を伸ばすように意識を変えました。 プレイングマネージャを目指すよりも、部のメンバーたちで成果を上げることを目指すほうがいいチームになりそうです。

マネージャになって良かったこと、辛かったこと

マネージャになることで、実際のところ何が良くて何が悪いのでしょうか。 細かいことを言うといろいろありますが、大きいと考えていることをそれぞれ１つづつ挙げようと思います。

自分の責任で実現したい世界を実現できる

「自分はこういう世界を実現したい」と描くものは、目的とその内容がメンバーに理解されれば、 あとは細かな進め方をを相談することで、実現することが基本的に可能になります。 仮に、既存のサービスの中で変なしがらみでおかしくなっているようなことも、 自分が責任を持つことで健全なものに変更することができます。

たとえば、クックパッドのアカウント登録と、レシピ投稿に必要なキッチン開設はずっとフローが分かれていましたが、 「そもそも分かれている合理的な理由は無いよね？」ということをメンバーと相談・協力して、全プラットフォームでフローを統合しました。

もちろん、意思決定者の発案で進めることになるので、成果が出ると担当したメンバーの成果、失敗するとマネージャの責任、というように考えるべきだと思っています。言い換えると、自分の責任で、実現したいと考える世界は実現することは可能になります。

意思決定の難しさ

良いことと表裏一体ですが、正しい（とされる）意思決定を行うことはマネージャの業務の中で最も難しいと思います。 意思決定を行う中では、その決定するための判断材料が不十分な場合でも、 その場で判断・即決して意思決定しないといけないケースも多くあります。

正直、自分が不慣れな分野で意思決定を行うこともあるので、その決定内容の結果に対して不安に思うことも多いです。 「本当にこれでいいのだろうか、逆の選択肢の方が本当はうまくいくんじゃないだろうか。」など、 意思決定をした後もいろいろな考えが頭に浮かぶことも。

ただ、ここ最近は「正しい意思決定だったかどうかは、未来にならないと絶対にわからない」 「むしろ、結果に影響を及ぼす原因が数多く絡み合っている中で、一つの意思決定がどの程度結果を左右したのか、分からないケースが大半。」という考えに至るようになったことで、意思決定に対するストレスも最近は少し減りました。

ちなみに、

は、このあたりの考えについてよくまとまった１冊になっているので、おすすめです。

まとめ

エンジニアからマネージャになるまで、なってから感じたこと、考えたこと、実践したことなどについて 述べてきました。いろいろなトピックを出しましたが、ここで伝えたいことは 「エンジニアはみんなマネージャになろう！」と勧める話ではもちろんありません。 「マネージメントを業務では行っていない人たち」に向けた「マネージメントの世界」の片鱗を 伝えるための話です。

確実に言えることは、エンジニアをやるだけでは体験できない世界をマネージャになることで見ることができます。 その中では、自分の中で確実に変化が起きることになりますが、その変化を楽しめる、面白がれそうな人は トライをしてみるのがいいと思います。

社内のエンジニアはもちろん、社外のエンジニアの方にとっても、 この記事が将来のキャリアを考える上で、何らかの判断材料の１つになれば、幸いです。