Engineering × Management

エンジニアがマネジャーになるということ

エンジニアマネジャーという仕事について

こんにちは、ディベロップメントデザインユニットアーキテクト2Gのグループマネジャーをしております小川です。

リクルートライフスタイルでは昨年度あたりからエンジニア採用に特に注力してきております。

まだまだエンジニアがいる会社というイメージがないと思いますが、こういうことやってますということをお伝えしたいのと、エンジニアマネジャーとしてのひとつの事例として共有させていただきます。

自己紹介

受託開発会社でエンジニアとして従事した後、2012年にリクルート(分社後のリクルートライフスタイル)に中途入社しました。 前職では医療系と業務系のシステム構築が主で、技術的にはフロント、バックエンド、インフラと一通り経験してきました。

リクルートに入社後は、ポンパレモール、じゃらんゴルフ、ギャザリー、その他新規事業立上げなどをエンジニアとしておこなってきました。 昨年度までは新規事業企画開発の部署に所属していましたが、2015年4月にアーキテクト2Gというグループのマネジャーに任用されました。

このグループは新規開発とスマートフォンアプリ開発をミッションとしている部署となります。 リクルートライフスタイルでは常に新規事業開発をおこなっているので、エンジニア数も事業数もそれなりの規模になっています。

マネジャーの仕事

マネジャーの仕事をひとことで言うと、『人/事業/組織の成長を結びつける』ことだと思っていて、 そのためには『やりがいのある仕事をつくること』がなにより大切だと捉えています。

人、事業、組織にそれぞれ寄り添いながら情報を引き出して何がうまくマッチするかを 見極めにいくという作業はなかなか骨が折れます。(が、とてもやりがいがあります)

冒頭に昨年度あたりからエンジニア採用に注力していると書きましたが、 組織側の受け入れ体制や、どういう仕事をやってもらうのがよいかということを考えながら実施していくということが多かったです。 最初からうまくいくことの方が珍しいので、小さな失敗をしても方向性を常に修正できるようにココロも体制も準備して進めることで そこまで大きな失敗とかはなかったと思っています。

また、それぞれに寄り添いながらと書きましたが以下のようなことを意識しています。


人:

  • 各人のやりたいことをしっかりと聞き出す
  • 得意な分野だけでなく苦手な分野も含めて共有する
  • 3年後くらいを目安にどういう人材になるかというところを描いて共有する


事業:

  • ビジネスモデルを理解する
  • 事業の方向性を理解する


組織:

  • マネジメント原則というものは書籍などから学ぶ(使う使わないにかぎらず知識はあったほうがよい)
  • 会社の数字(売上、利益など)はしっかりと把握する
  • 会社の方向性をしっかりと理解して自分の言葉で語れるようにする


また特徴的な文化として、リクルートでは『よもやま』という雑談もOKな1on1をおこなうものがあります。 文化としてメンバーひとりひとりに寄り添う習慣があることは非常に良いなと感じています。

仕事をするうえで大切にしていること

判断軸をぶらさずに持つ

関わる人も事業も多いので、良いことも悪いことも数多く起こります。 裁量権が大きい反面、意思決定の責任は非常に大きくなってきます。また決断速度も速さが求めらます。

マネジャーがボトルネックになるわけにはいかないですし、かといって適当にも決定できません。 ぶれない軸として、『ROI(投資対効果)が適切かどうか』で考えるようにしています。

これはマネジャーになる前から考えていたことではありますが、 マネジャーになってからは上長(写真右)からの指導もあり、より一層意識するようになりました。

もっと言うと『費用対効果ではなく投資対効果で捉える』ことが重要だと考えています。 (私的解釈ですが)費用対効果は現在、投資対効果は未来にスコープしているものだと捉えています。

組織/事業/人に対して、しっかりと未来を見据えて判断するという意味でROI(投資対効果)が適切かを見極めたいと心がけて判断しています。
(注:偉そうに書いてしまいましたが、まだまだ全然勉強中です….)


抽象的なことでも可能な限り言語化を試みる(具体例:事業会社ならではのエンジニア像を定義)

私自身、受託開発会社から転職して事業会社のエンジニアとなりましたので『事業会社のエンジニア』が どのように動けばよいのか悩んだという経験があります。 受託開発だと納品するのがゴールですが、事業開発だと構築完了がスタートとなるのでそのギャップには戸惑いました。

その経験もあり、どういったエンジニア像がよいのかということを考えた結果、 プロダクト志向エンジニアという存在であろうということを掲げています。

具体的には、“技術” × “熱意” × “プロダクト理解” = プロダクト志向エンジニア と定義しています。
プロダクトを理解して適切な打ち手を理解し、
それらを実現する手段(技術)をもち、
やり遂げる情熱をもちつづけられるエンジニア こそ、事業会社のエンジニアなのだと語っております。


やらないことを定義する

マネジャーになるタイミングで、サービス開発におけるコードは書かないということを決めました。 ささっと何かを自動化するものを書いたり、個人的な分析用にスクリプトを書いたりはしていますが、 機能開発に書くという行為で関与することはしないようにしています。

これは一長一短あると思います。また、マネジャーの働き方が会社から強制されているわけではないので コードを書くマネジャーが存在できないという意味ではないです。

新規開発などに携わってきたので心残りはありますが、その気持ちをすべてマネジメントに注ぐと決めて業務にあたっています。

あ、コードレビューは積極的にしています!


人材をなにより大切にする

中途採用試験に訪れた際に、人事の方にこのようなことを言われました。

『リクルートは何ひとつ資源を持っていません。私たちには人材が何より大切だと考えています。』

この言葉を聞いた時、すごい会社だなと感じたことを鮮明に覚えています。 そしてマネジャーになってから、さらに身にしみる言葉になりました。

ひとりひとりのことをしっかりと考えて成長プランを練ることの大切さ、 マネジャーとして何が出来るかということを謙虚な気持ちで真摯に立ち向かえる言葉です。

結び(と宣伝)

遡ること3年前。

当時は片手で数えられるくらいしかエンジニアがおらず、これから増やすと面接時に聞いていたものの、 それから2年くらいはあまり増えないという時期がつづk(ゴホンゴホン

時間が飛びまして、昨年度あたりからのエンジニア採用への注力はすごかったです。

うまくいかないことも沢山ありますが、マネジャーの立場から人/事業/組織の成長を裁量権もってコミットできるという仕事はとてもやりがいがあります。 また発展途上の組織なので、自分たちで作っていっているということがモチベーションになっています。

マネジャーになることでエンジニアとしての未来ってどうなるんだろうな、、、って考えたこともありますが、 マネジャーもエンジニアも根本は『課題解決の手段』だと思うので成長は実感できています。

こんな働き方をしているエンジニアもいるのだと、少しでも参考になれば幸いですm(__)m

あ、あとマネジメントに興味があるエンジニアの方たちも絶賛募集中です!

興味ある方は、ぜひ採用ページへどうぞ!

小川 健太郎

(アーキテクト2グループ)

アーキテクト2Gという部署でグループマネジャーをしています。エンジニアとしていい組織を作ることを目標に働いてます。

NEXT