エンジニアリングマネージャーに技術力は必要か？　現役EMたちが語る、技術とマネジメントの本質

コードが書けないマネージャーについて

織田晃弘氏（以下、織田）：それでは、次のテーマになります。「コードが書けない」「技術が理解できていない」ようなエンジニアリングマネージャーは、もはや「自称エンジニアリングマネージャー」になってしまうんですけれども。（こういう人だと）要は、もうマネジメントはできないんでしょうか？　こちらについて、なにか持論がある方はいらっしゃいますか？　「もうコードが書けないんだったら、やるな」という人も、いらっしゃると思いますし。

竹迫良範氏（以下、竹迫）：最近、スカイマークの会長さんがゴルフを休んで1週間Ruby on Railsの勉強したっていう話が報道されて。その中で「ユーザーアンケートも、スマートフォンで入力できたほうがいいよね」というところも、経営者や会長自らがそういうことに気づいて作っていくということがありました。

最近は、どのユーザー企業でもスマートフォンやデジタルデバイスを使ったプロダクトづくりが必要になってきたので、「そのためになにが必要か？」という経営の打ち手みたいなものや、マネジメントでも「やはりこういうことは、リソースがあったほうがいいね」という「現場で感じる」ことが、マネージャー層以上で必要なのかなと感じます。

織田：実際、このマネジメント業に入ってくる、あるいはマネジメントのタスクが増えてくると、相対してコードを書ける機会もどんどん減っていくケースもあると思います。

いわゆる、マネージャーの手がちょっと空いているとき、あるいは全体のタスクの中の何割かは、自分がプロダクト開発にあたりたいという時には、結局はメンバーが「フルコミットできないなら、入られるだけ困る」とか。あるいは、なまじ理解できるだけに口出しをされてしまって、マネージャーという権力のある立場の人の意見がどうしても逆らえないとか、そういったケースもあると思います。

その中で、「ちゃんとエンジニアに書かせてくださいよ」「マネージャーの人は、あくまでマネジメントに専念してほしい」という意見も、もしかしたらあるかもしれません。その点についてはいかがでしょうか？

及川卓也氏（以下、及川）：これは、コードが書けるかどうかは本質じゃないなと思っています。もちろん、コードは書けないといけないと思いますが、自分たちが開発していることを理解し、ハイレベルなディレクションを与えられるかどうかが本質でしょう。

厳密に言うと、マネジメントとリーダーシップって別とも考えられるんですね。ただ、マネージャーはリーダーシップも持っていなければいけません。技術チームにおけるリーダーシップというのは、そういった技術的なディレクションを与えられるかどうかというところなんですよ。

先ほどのスカイマークの会長の話はすばらしいなと思うんですが、一方、一番面倒くさいのは、昔書いてたコードの話をして「俺が若い頃はこうだった」とか、もしくはちょっとコードをかじってプログラミングがわかる気になって、いろいろ口を出してくる人です。これは確かにコードは書けるかもしれないけど、ディレクションを与えられるレベルでは技術を理解していない典型例なわけですよ。ですから、大事なのは業務上必要な技術がわかること。

今の織田さんの話で言うと、基本的に組織にコミットしている人間は、コードを書く仕事をメインにしてはいけないんですね。だけれども、コードを書いていないと、今私が言ったように、「技術がわかること」は不可能なわけです。だから、コードを書き続けなければいけません。

だからよくやるのは、「いつか誰かがやらなきゃいけないタスクリスト」って、だいたいあるじゃないですか。それに手を挙げてやると。ただ、プライオリティが低いので、自分がやれなかったとしても、メインのエフォートに対しては悪影響を与えないと。そういうやり方をするのがいいんじゃないかと思います。

広木大地氏（以下、広木）：だいたい言われちゃたので（笑）、次のテーマにいきますか。

（一同笑）

エンジニアとの会話から学んでいく

織田：大丈夫ですか？　是澤さんとひらいさん。

ひらいさだあき氏（以下、ひらい）：僕はどちらかというと、現場でのマネジメントをやっていて、今はコードを書いていないんですね。もともと一番得意だったのがサーバサイド分野やフロントエンドだったので、モバイルはそれほど経験がなくて。モバイルのマネジメントをする上でどうしようかと思ったときに、アーキテクチャの部分のインプットはしてみました。

最近モダンなアーキテクチャがいくつかあるので、クリーンアーキテクチャやMVVMだったり、メルカリが使っているアーキテクチャについて、「どういう概念のものなのか？」みたいなインプットはしていました。

そうすると、エンジニアが話していることは、だいたい理解できるようになってきて。とはいえ、現場でガリガリコードを書いてるエンジニアのほうが詳しいので、わからないことは素直に聞くようにしています。

なので、エンジニアと会話していて単語がわからないことも正直あったりするので、そういうことがあったら、その場で「これってどういう意味なんですか？」って聞いて教えてもらって、「自分はこういうふうに理解したんだけど、合ってますか？」「合ってますね」みたいな会話をしています。

優秀なエンジニアたちがたくさんいるので、人から学んでいくところも大事なんじゃないかなと思います。

是澤太志氏（以下、是澤）：これはよく話すことですが、リスペクトがあるのが大事だと思っています。チャレンジを止めさせない。チャレンジをさせていく。なので、その支援をちゃんとできるかどうかが大事で、コードを書くのは最後の手段だと。だから「ワーストなプランは、自分が出ていってコードを書くこと」と説明をすることがあります。

エンジニアリングマネージャーをどう評価するか？

織田：ありがとうございます。では、次のテーマです。技術の本質が理解できているかどうか、あるいは、エンジニアに挑戦ができる環境を提供できるかどうか。そんなことができるエンジニアマネージャーを「誰がどう評価するか？」。

エンジニアリングマネージャーがエンジニアを評価するケースはよくあると思いますが、そもそもエンジニアリングマネージャーを目指す、あるいはエンジニアリングマネージャーになった時に、エンジニアリングマネージャー自体は誰がどう評価するのだと思いますか？　私の肌感では、ここはまだ確立されていないのではと思っています。

広木：その「誰がどう評価する」って、「評価できる人が評価する」のかなと思うんですけど、ラインによるのかなと。

あとは、求めているものによるのかな。評価自体。その人に求めているように成長してもらいたいとか、変化してもらいたいということがあるのかなと思います。逆に、このこと自体がテーマになるのって、どんな状況を想定されていますか？

織田：そうですね。正直、「エンジニアリングマネージャーは、人を評価するべきかどうか？」という議論が社内でもあったんですね。「技術に対しての責任を負うのであって、人の評価に対する責任を負うべきかどうか？」みたいなことが、議論としてありました。

逆に、エンジニアリングマネージャーはなにをもって、その評価とされるのか？　もちろん、それは部のラインの上長が評価をするんですが、その部下からの評価はあるのかどうか？

「マネージャーとして優秀である」となったときに、人の評価にコミットをする場合の評価と、人の評価には関与しないかたちで、つまり技術的な責任を負う立場の評価って、「そもそもどういう効果をもって、誰がどう評価するんだっけ？」という議論がありましたね。

広木：なるほど。この会場のみなさんの中で、人の評価・査定を経験したことのある方は、どのぐらいいらっしゃいますか？

（会場挙手）

けっこういらっしゃいますね。たぶんその意見って、あんまりやったことのない人が「評価するって怖いよな」と思ってる話なのかなと思って聞いていました。人に関わることって恨まれるかもしれないし、逆にポジティブに関係を築いていかないといけないかもしれないしで、ちょっとややこしい側面がありそうな気がしてしまいます。

とくにコンピュータに向き合ってなんとかできてたところから、急に人に向き合わなければいけないとなると、怖い人も一定数いるんだろうなって思います。

そうなったときに、「評価することとか評価されることって怖いな」っていう発想自体が、すごく抑圧的に感じています。実際、評価やフィードバックをされたらうれしいし、成長したらうれしいわけじゃないですか。

「技術に対する責任を取れること」と「人に対する責任を取れるということ」の、もしそのどちらかがeasyに見えてどらちかが難しく見えているとしたら、甚だ勘違いだと思っています。それはどちらもある程度難しいし、分割できないようなことなんだろうと思っています。

是澤：たぶん納得感のある評価制度というのは、なかなか仕組み化されていないんじゃないですかね。なので、誰に軸を合わせるかみたいな基準を会社として決めているところもありますし、データドリブンに評価ができるところを理想としているという話も聞きます。

基本的にはプロダクトを作って、そのアウトプットで定量的に測れて、自分がどこに貢献できたかが見えれば、ちゃんと評価できるはずだと思います。そういったものを仕組み化していくことだったり、見える化にチャレンジしていったり、納得感のある評価をしていくようなことに取り組み、ナレッジを共有していくということを僕たち自身がやらないといけないと感じています。

自己評価を導入するには

織田：なるほど。ありがとうございます。では、まだ議論が尽きないと思いますが、次のテーマに進んでいきたいと思います。

「スペシャリストとして、じゃあエンジニアはどう振る舞うべきか？」というテーマがあるのですが、とくになければ飛ばしたいんですけれども、いかがでしょうか？　どんどん飛ばしていきたいと思うんですけれども……。

広木：Twitterの質問が。

織田：どうぞ。

広木：Twitterから質問が。「40パーセントぐらいはエンジニア自身が評価するのはよいと思いますが、いかがでしょうか？（評価基準を細かく設定。チャレンジを止めさせていないかなど）。あとは、組織への貢献度を経営層が評価」というところなんですけど、「40パーセントを自己評価にしたらいいんじゃないか？」という話ですね。

是澤：握っていればいいんじゃないですかね、そういうやり方も。例えば「これができたらこれぐらいください」みたいな話をしてもいいのかなと思います。僕、若い頃はそういうこともやってましたね。

竹迫：そうですね。ピアレビューとか、そうした仕組みを入れるのも1つのやり方ですよね。というのは、やはりスペシャリストの技術を持った人同士がレビューして、その人はどのぐらいのレベルにあるのか。「仕事で助けてもらった」とかですね。

是澤：シニアが多いところだと、けっこうワークすると思いますね。

竹迫：その場合、たぶん職能とラインマネジメントが違ったりするケースがあるので、そこをちゃんと担保するためのものをハイブリッドで用意することが重要なんでしょうね。

広木：そうですね。評価方法としてセルフマネジメントできるなら、すごくハッピーじゃないですか。おそらくセルフマネジメントできないところからセルフマネジメントできるようになっていくのは、理想的な話です。

この「40パーセント」というのも、おそらく質問者さんが見えているのは「自分は40パーセントぐらいだったら、セルフマネジメントしてもいい」みたいな話だと思っていて。

なので、この度合いは人によって（異なっていて）未熟な方からある程度matureな方までいると思っていて、どのように自分でモチベートして次のことを学んでいっているかの「助走がつけられていない状態の人」を導いてあげるのも、マネージャーの仕事なのかなと思います。

評価される側が評価されたいする人を選ぶ

竹迫：あとは、評価できないと割り切った業界もあります。実はアカデミアの業界は、世界最先端でそれぞれで専門分野を持っているから、その専門分野はその人しか知らないという状況なんですよ。だから、他人が評価できない仕組みになっています。

例えばPhDのように世界初に挑戦して突破した実績があれば、その人は自己管理もできるでしょうということで、評価を諦めている業界も実はあったりします。

ひらい：前職のときのエンジニアの評価制度なんですが、エンジニアにGitHubのドキュメントを書いてもらうようにしていました。その評価面談は、僕と、エンジニアリングマネージャーがいたらエンジニアリングマネージャーと、評価される人が「『この人に評価されたら納得できる』という人を1人選んでください」というかたちにしていました。

その人たちと一緒に面談をするんですが、評価というよりは、お互いにフィードバックすることを目的としています。ドキュメントを書いてもらって、「ここはよかったね」とか「この時、もう少しこうやれたら、よかったよね」ということを、何人かからフィードバックをするという感じでやっていました。

そうすると、評価する人を自分で選んでいることもあって、納得感も高くできたかなと思いますし。終わったあとは「振り返りもできたし、フィードバックももらえてよかった」という声をもらったりできたので、そういった評価者を自分で選べたりするのもいいのかなと思っています。

及川：今ひらいさんが言ったところは、ポイントかなと思います。「評価って何のためにするのかな？」って考えたときに、当然会社なので報酬に連動させるところがありますが、それは結果であって。本来ならば、人の成長のために、自分以外の周りの人からのフィードバックを得るところが目的になることが多いですね。

ですから、半年・1年での定期的な評価はもちろん大事なんだけれども、よく言われているのは、常に周りの人から、とくに上司との定例の1on1で、成長のためのフィードバックを与えるということが大事です。

そのフィードバックや評価を何を軸に考えるかというと、2つあります。1つはやはり能力。その能力のところには、技術的な能力と、EMだったならば、技術以外の人や組織に対してどう貢献できるかという能力があります。

それともう1つは、「能力をしっかり発揮して、事業や製品開発に貢献してるか？」というアウトプットの部分。この2つの部分で評価して、かつ、フィードバックをしていくということが大事だと思います。

AIマネージャーは実現するか？

織田：では、せっかく評価の話に触れたので、「もしもマネージャーがAIになったら？」というテーマがあるので、こちらにちょっとだけ触れさせていただきます。

竹迫：「EM.FM」で少しお話しした内容ですが、まさに「上司はわかってくれない」ということが、けっこうあると思います。僕は、初音ミクみたいなのが上司になればいいなと思っていまして。そうすると、古い大企業でも、ちゃんとエンジニアにすごく優しい言葉でフィードバックしてくれるみたいな。

是澤：僕自身、マネージャーは自分をクビにするのが仕事だと思っているんですよ。なので、AIが（マネージャーに）なったら、自分をクビにして新しい領域に突っ込めるので、データドリブンに進めてAIが意思決定をしていく、サジェストしていく未来はあるかなと個人的に思っています。

竹迫：あとは、実は政治家もバーチャルな人のほうがいいんじゃないかと思っています。集団で意思決定して政策に関与していくみたいなことは、10年前ぐらいから実験的にやられたりします。そういうことがなにかあってもいいのかなと、仮説として挙げてみました。

及川：私は、技術のマネジメントを完全AI化するのは無理だと思っています。よくAIや機械によって人の仕事が奪われるという（議論になる）ときに「どんな仕事が奪われるか？」というと、やはりある程度共通パターン化しているところであり、「人との関与があるクリエイティブなところは、機械に奪われない」ということが言われています。

例えば、業種や職種で30年間同じことをやっているというのは、今の状況でもあるわけで。そのマネジメントをAIが取り代わるということもあるかもしれませんが、我々が生きてる技術の世界は1年おきにやることが変わってきていると言っても過言ではありません。そのため、人に対してどのように指導するか、フィードバックを与えるかに対してAIがなにかサジェストをすることはあったとしても、完全に取り代わられることはないんじゃないかと思います。

織田：ありがとうございました。やはりこのメンバーが集まると議論が尽きなくて、ふだんから集まったりするときはいつも時間が足りず、今日も時間がきてしまいました。

拙い部分もあったかと思いますが、最後に少しだけ、登壇者のみなさんからの告知だけさせていただければと思います。では、及川さん。

及川：3月6日に、汐留にある私が顧問を務めているクライス＆カンパニーという会社で、こういったイベントをやります。

タイトル（『CTO／VP of Eになれるエンジニアとなれないエンジニアとは？~あなたはこの先どこを目指しますか？~』）が刺激的ですが、別に全員が全員CTOやVPoEを目指す必要があるわけではないものの、やはりマネジメントキャリアの代表例として、どんなかたちのキャリアがあるのか、どんな組織にするのが良いのか。そんなことを議論する予定です。もしマネジメントキャリアに興味がある方は、「将来的にそういうのもあるかな？」ということを考える材料になればいいかなと思います。もしご興味ある方はご参加いただければうれしいです。よろしくお願いします。

織田：では、広木さん、お願いいたします。

広木：僕はシンプルです。17時ぐらいからのセッションで、「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」のラスト3冊の技術書（部門）としてノミネートされております。ぜひ参加して、ご投票いただけるとうれしいです。よろしくお願いします。

織田：最後に私から。エンジニアのコミュニティ向けに、会場を提供したりスタッフを提供したり、支援制度を会社で持っております。最大200名入れます。場所は銀座です。

「NIFcLounge」という造語になりますが、こちらでググっていただけると、冒頭に弊社のプレスリリースがございます。そこに申し込みフォームがありまして、そのフォームから必要な要件などを入力して申し込みができますので、ぜひご検討いただけたらなと思います。非営利を目的とした勉強会やセミナー・カンファレンスであれば、無償で受付させていただいております。

では、お時間がきてしまいました。パネラーのみなさまにご質問等もあると思いますので、「Ask the Speaker」や会場で見かけた際にお声がけいただけたらと思います。

では、以上で終わりたいと思います。ありがとうございました。

（会場拍手）