▶平日 毎朝7時に公式LINE@で新着記事を配信しています。友達申請はこちらから！
▶ICCの動画コンテンツも充実! Youtubeチャネルの登録はこちらから！
「イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント」【F17-1C】セッションの書き起し記事をいよいよ公開！10回シリーズ(その8)は、エンジニアリングマネージャーの役割について、主にメルカリの事例を基に議論しました。プロダクトマネージャーとエンジニアリングマネージャーは何が違うのでしょうか？是非御覧ください。
ICCサミットは新産業のトップリーダー600名以上が集結する日本最大級のイノベーション・カンファレンスです。次回 ICCサミット FUKUOKA 2018は2018年2月20日〜22日 福岡市での開催を予定しております。参加登録は公式ページをご覧ください。
▼
【登壇者情報】
2017年2月21〜23日開催
ICCカンファレンス FUKUOKA 2017
Session 1C
イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント
（スピーカー）
岩田 和宏
JapanTaxi株式会社
取締役CTO
柄沢 聡太郎
株式会社メルカリ
執行役員CTO（※2017年4月より執行役員VP of Engineering）
平山 宗介
株式会社メドレー
取締役CTO
山崎 大輔
Supership株式会社
取締役 CTO室室長
（モデレーター）
松岡 剛志
株式会社レクター
代表取締役
▲
▶「革新的なプロダクトを生み出す開発マネジメント」の配信済み記事一覧
連載を最初から読みたい方はこちら
最初の記事
【新】イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント【F17-1C #1】
1つ前の記事
エンジニアリングマネージャーをいつ、どのように採用するのか？【F17-1C #7】
本編
▶︎編集注：前のPartに引き続き「エンジニアリングマネージャーはいつから必要なのか」というテーマを設定して議論しています。
平山 （エンジニアリングマネージャーについて議論を進めていましたが）そもそもエンジニアリングマネージャーを、どのように定義していらっしゃいますか。
エンジニアリングマネージャーは何をする人？
平山 弊社ではあくまで事業部制で、プロダクトを統括するプロダクトマネージャーを置いています。エンジニアは事業部組織の一部ではありますが、そこにエンジニアリングマネージャーをつけてハイブリットな体制にしています。
エンジニアリングマネージャーを立てることで、底上げというか、組織としての教育というか、そういったことを担保するためにリーダーシップを発揮してもらっているんです。
そういった意味で、皆さんはエンジニアリングマネージャーをどう位置づけておられるのでしょうか。
プロダクトマネージャーもエンジニアリングマネージャーもいるというのは、どういう感じなのかなと。
山崎 弊社もそうなのですが、弊社ではエンジニアが60人くらいいるにもかかわらず、エンジニアリングマネージャーというのは存在しないんですよ。
プロダクトマネージャーがすごく大きな権限を持っていて、エンジニアリングマネージャーも兼ねている感じなのです。
そういう背景もあり、エンジニアの方からは（マネジメントに）上がってこないので、皆さんはどうされているかはすごく知りたいですね。
メルカリさんではどうなさっていますか?
そのエンジニアリングマネージャーというのは、何をしてくれる人なのですか?
エンジニアリング的な組織課題はエンジニアにしか分からない
柄沢 チーム構成の点では、他社とあまり変わらないですね。
弊社でも事業部制で、基本的にプロダクトがあってプロダクトマネージャーがいて、そこにエンジニアや、企画する人や、デザイナーなどがいるというチームが幾つかあるので、エンジニアの階層がそういう風にある訳ではありません。
そういう意味では皆さんとチーム構成は同じなのですが、エンジニアリングマネージャーが何を担っているかというと、基本的には平山さんがおっしゃったような「底上げ」というか、教育面や、採用や、あとはエンジニアリングの技術評価などです。
それから組織課題の解決ですね。
僕はそういう人は必要だと思っています。
マネージャーは、基本的には部下とどんどん1 on 1などをし、情報を集め、必要な情報を横に展開していく人だと思うんですよ。
エンジニアの話を聞いて、エンジニアリング的な組織課題であるということを認知できるのは、やはりエンジニアなんですよね。
ですから、そうやって現場のエンジニアの話をしっかり聞いて、上がってきたものがそのチームの中で解決できるものなのか、あるいはそのチームを超えないと解決できない問題なのかということを判断できる人が必要で、そういうことをエンジニアリングマネージャーに任せているという感じです。
岩田 プロジェクトマネージャーとの関わり方というのは、決まっているのですか？
柄沢 関わり方というのは？
岩田 各プロジェクトに（プロジェクトマネージャーが）1名ずついるみたいに、きっちり決められているのですか？
柄沢 今の段階ですと、1対1のような感じにはなっていないですね。
現在は、分野別に何人かいます。
iOSとAndroidのそれぞれにエンジニアリングマネージャーがいて、サーバサイドに2人いてという感じになっていますね。
岩田 弊社の場合は、技術基盤チームのようなものがあって、そこにAndroidのスペシャリスト、iOSスペシャリストがいます。プロジェクトを横串にまたいで評価したり見たりしています。
柄沢 技術的な、テクニカルな横断組織のようなものと、少し文脈が違うと思うんですよ。
山崎 組織運営が上手く回るための。
柄沢 そうそう。
岩田 そうですね。
技術評価とも言えるかもしれませんね。
スキル面はエンジニアリングマネージャーにしか評価できない
平山 では、事業部で評価をしている訳ではなくて、基本的にはエンジニアリングだけで評価されているのですか？
柄沢 いえ、基本的には事業部、プロダクトごとのチームでの貢献を評価しています。
ただ、エンジニアに関しては、エンジニアリングマネージャーまたはプリンシパルエンジニアという経験豊富なエンジニアが技術面の評価をして、四半期毎の評価については、両方を揃えた情報で総合評価をするという風にしています。
そうではないと、正直なところ、ミッションに対する貢献度は測れるけれども、スキルは測れませんので。
ですから、エンジニアリングマネージャーがきちんとそこを見るという風にはしていますね。
平山 なるほど。だから、エンジニアだけその評価が一つ多いのですね。
山崎 なるほど。
松岡 エンジニアだけ多くしているのですね。
デザイナーなどの他のスペシャリティについては、特にスキル評価はしないのですか?
柄沢 それは悩ましい問題で、デザイナーもスキル評価をしなければという話はしているのですが、たまたまそれを担っている人がいないのです。
でも、実質リーダー格のメンバーがいるので、ヒアリングして評価に反映させるということはしています。
基本的に、職種で見た時のエンジニア人数は、カスタマーサポートの次に多く、エンジニアのスキルといってもすごく沢山の領域がありますからね。
山崎 そうですね。
柄沢 ですから、そこはきちんと評価できる人がいないとダメだよねということがあるし、それぞれ出て来る課題が全く違うというのもあるので、それはエンジニアリングマネージャーがしっかり集約していこうということになっています。
領域が広がるほどエンジニアリングマネージャーが必要になる
松岡 話を元に戻すと、エンジニアリングマネージャーは、いつから必要なのでしたっけ?
それとも、要らない?
平山 僕が意識しているのは、あくまでも時間というか人数ですね。
20人いたら1人のマネージャーでは無理なので。
やはり8人（に1人）くらいかな。
岩田 一般的に、（1人のマネージャーで）目が行き届くのは、6人と言いますよね。
平山 マネージャーが部下をきちんと引き上げなければならないので、そういった意味で、引き上げられる可能性というのは、やはり1桁台だと思ってしまいます。
先ほど開発本部で20人くらいの組織になったという話をしましたが、まさにマネージャーが必要になるタイミングになってきたので、最近立てました。
柄沢 Googleの話を聞くと、そこは「何人以下」とするのではなくて、「何人以上」にしなさいという風になっているんですよね。
組織の成長に応じて人数を絞ると階層が増え続けるので、沢山見ることのできる能力のある人をそこに入れろといったように。
山崎 そういう話ですよね。
柄沢 少し話がそれましたけれども。
松岡 ありがとうございます。
エンジニアリングマネージャーは、技術というよりは、評価をする・組織課題を見つける人だと定義した際に、そういう人というのは一般的に考えると6人とか10人とか20人とか、そういう数字を超えてから必要になってくるものなので、それまでは正直なところ要らないよということですよね。
山崎 領域が広がれば広がるほど、そういう人が必要なのでしょうね。
皆がやっていることが割と明確な場合には、評価も簡単だということは、今少し感じましたね。
弊社では一個のシステムしか作ってこなかったので、領域はあまり広がっていませんね。
一方で、JapanTaxiさんの場合は、ハードウエア的な話もあれば、決済の話もあるし、Androidであるかどうか話もあるし、サーバサイトもあるじゃないですか。
そういう感じではないので、そこは少し感じましたね。
なぜ弊社にマネージャーがいないのか、すごく不思議だったのですが、何となく腑に落ちました。
松岡 ありがとうございました。
山崎 すみません、自分の話でしたが。
(続)
次の記事を読みたい方はこちら
続きは エンジニアの採用では何を重視すべきか？ をご覧ください。
▶平日 毎朝7時に公式LINE@で新着記事を配信しています。友達申請はこちらから！
▶ICCの動画コンテンツも充実! ICCのYoutubeチャネルの登録はこちらから！
編集チーム：小林 雅／榎戸 貴史／戸田 秀成／横井 一隆／立花 美幸／Froese 祥子
【編集部コメント】
エンジニアやデザイナーなどには、彼らの技術を評価できる人は必要で、他の総合職など各個別職種には特に必要はないのか？と考えると意外と深い問題だと思います。マーケターは、マーケターからそのスキルを評価された方がいいのでは？などと考えてしまいます。（横井）
他にも多く記事がございますので、TOPページからぜひご覧ください。
更新情報はFacebookページのフォローをお願い致します。
