DevSumi2019で「エンジニアリングマネージャー・パネルディスカッション」を聞いてきた
どうも。afroscriptです。
DevSumi2019参加中です。 Day1、1コマ目のレポートをつらつらと書いておきます。(雑メモレベルです）
参加したのはこちらのセッション↓
感想
技術を軸にするということを除けば、わりと一般的なマネジメントで重要なことと変わらないな、という印象でした。下記の点で。
- 人を介して事業やサービスにコミットするのがマネジメント
- 組織が小さい頃はサービスの成果に向けてマネジメントするが、組織が大きくなると非効率な部分が出てくるので、だんだん人や組織そのものに向けてのアクションが増えてくる
- 評価は、絶対的なものはなく、なんだかんだ試行錯誤し続けるもの
違うなと思ったのはやはり、技術への理解がベースとして絶対的に必要な点。まぁ、他の職種をマネジメントするとしても、プレイヤーがやっていることを理解しているというのはもちろん大事なのですが、営業のマネジメントをするより、技術は常に変化し続け、また様々な専門領域があるので、スペシャリストであるメンバーへのリスペクトと学ぶ姿勢は、より大事なんだなと思いました。
登壇者紹介
- モデレーター：
- 織田さん
- パネラー：
- 及川さん@takoratta
- 竹迫さん@takesako
- 広木さん@hiroki_daichi
- ひらいさん@sada_h
- 是澤さん@sak0620
スペシャリストとマネージャーは何が違うのか？
及川さん
- 技術を軸として社会、会社に貢献するというのは変わらない
- ただし、マネージャーだとそこに人が挟まる。人を介して貢献するというのがマネージャー。
是澤さん
- スペシャリスト：技術を高めて貢献する
- マネジメント：人の可能性を信じて伸ばす
広木さん
- スペシャリスト：コンピューテーションなコントリビューター。
- マネジメント：組織で成果を出す人。
- 自身ももともとスペシャリスト志向だったが、成果を求めるためにアーキテクティングもしてかなきゃというところから、だんだんとコンピューティングの視点だけでなく、組織の視点・マネジメントも必要だと思うようになり、そちらへ範囲が広がっていった
- 成果を求めるならコンピューターも人も扱っていかなければならないので、そんなに遠い領域ではないと考えている
ひらいさん
- チームで働くスペシャリストが最大限成果を発揮するのがマネジメント
竹迫さん
- スペシャリストはHowの専門家
- マネージャーは人に任せることが大事
大企業におけるEMとスタートアップにおけるEMの違いとは？
是澤さん：
- スタートアップにはEMがいないケースが多い（CTOやPMが兼任してたり）
ひらいさん：
- 前職のGoodPatchでは入社したときにはエンジニアが30人程度だったが、やめるとき100数十人いた。
- エンジニアの人数が少ないと、エンジニア、デザイナーがチーム内に一緒にいて、それを統括してマネジメントする人がいた。
- スタートアップのEMでは、他の職種もマネジメントしないといけない、が発生する
竹迫さん：
- スタートアップのEM、組織の規模が大きくなってくると成長痛がある
是澤さん：
- マネジメントの仕事は、サービスの初期はプロダクトの成果にコミットすることだが、人が増えてくると、1人1人を幸せにするといった形で、成果の方向性が人に向いていく
- 今はメルカリにVPoEとしては、メルカリに入ってくる人を幸せにしていきたいという思いがある
広木さん：
- 企業が成長してくると、生産性が落ちてくる。スタートアップの場合は、それが誤差くらいで済む。
- チームが大きくなってくるとその誤差が大きくなり、対処しなければならないが、その差をなくしていくのがマネージャーの仕事だととらえている。
- 「幸せにする」という表現は近いものだと思う。例えば、チームが大きくなると、事業やサービスの一部をやってるだけに感じてしまい、仕事がつまらなくなるような人も出てくる。それを取り除いていくという点では、その人が幸せに仕事をするということに繋がる
及川さん：
- スタートアップと大企業をひとくくりにするのは難しい
- 例えば、メルカリを大企業と捉えることもできるが、本当の大企業は数千人やそれ以上いる
- そして、そういった大企業にはほとんどの場合EMはいない。技術がわかるマネージャーがいない。大企業は、そういう人を入れていかなきゃいけない
- リクルートは、そういう意味での大企業に入るだろうが、竹迫さんをCTOに迎えて変わってきてる。こういう取り組みが大事。
竹迫さん：
- 大企業になると、いろんなフェーズの違う事業が同時に進んでいく。各フェーズでどうすべきかを知ってるのは重要
コードが書けないEMはマネジメントできない？
竹迫さん：
及川さん：
- コードが書けるかどうかは本質ではない
- 技術を理解しているかが重要。
- 今自分たちがやっている技術を分かった上で、リーダシップを発揮してくれるのが大事
- でも、コードが書けないと技術が分かるというのが難しい。そういう意味でコードは書けないといけない
- また、コードは書けるけど、技術が分からないのは一番困るパターン
ひらいさん：
- 今は自身もコードを書いてない。モバイルチームのマネジメントしてるが、モバイルはあまり得意な領域ではない。
- アーキテクチャのinputをするなどはした。（その辺はもともと分かるし）とはいえ現場でガリガリ書いてる人の方が詳しいので、そこは素直に聞く
- 自分の知らないことは、現場の優秀なエンジニアに学んでいくことが大事
是澤さん：
- 「リスペクト」をもつことはなにより大事
- その上で、「チャレンジ」を後押しできることが大事
- 自分がコード書いてしまうのは、EMにとってワーストな選択
EMは誰がどう評価する？：
広木さん：
- 評価できる人が評価する
- これまでコンピューターに向き合ってた人たちが、人に向き合って評価するというのを怖がる人もいると思うが、それはよくない
- 人に向き合うのも、コンピュータに向き合うのもどちらも一定数難しいもの
是澤さん：
- なかなか仕組み化はされてないものなのでは？
- 属人的になっている企業もあるし、データドリブンに評価してる企業もある
- 「EMは誰がどう評価する？」は、常に考えて見出していかなければならないもの
ひろきさん：
- 前職のときの評価制度：自身の成果をGitHubのドキュメントに書く。それを元に、EMと、この人に評価されたら納得できるって人を自分で選んで、その2人にフィードバックをもらう
及川さん：
- 定期的な評価も大事だが、リアルタイムのフィードバックが大事。EMとの1on1など。
もしもマネージャーがAIになったら？
是澤さん：
- マネージャーは自分をクビにできるのがゴールだと思ってる
- データドリブンにしてAIが評価していくって未来もあるんじゃないかな
及川さん：
- マネージャーをAIにすることは無理だと思ってる
- 同じことを30年やってるような仕事ならできそうだが、技術の世界は刻一刻と変化しているので、エンジニアの評価をAI化するのは無理だと思ってる
