「エンジニアリングマネージャーは、なにをすればいいのか？」
そう悩んでいる方も多いのではないでしょうか。2010年代後半になって世の中に認知されはじめたエンジニアリングマネージャーという言葉は、定義があいまいで組織によって役割が異なります。
そのようなエンジニアリングマネージャーに関する知識の体系化を図った本が、『エンジニアのためのマネジメント入門』（技術評論社）です。
この本の著者である佐藤大典さんに、エンジニアリングマネージャーとしての7ルールをうかがいました。
1986年北海道生まれ。現在、スタートアップでVPoEを務める。2010年より、音楽スタートアップ企業でソフトウェア開発や新規事業立ち上げに携わる。その後、大手Eコマース企業にて、マネジメントや組織開発に従事。マネジメントに関する執筆活動や講演活動もおこなっている。
目次
Rule1.解決したい課題はなにかをはじめに考える
まずはじめに、課題はなにかを考えます。上長からの指示などで、しなければならない業務であっても、なにを解決したいのかを自分のなかで納得できるまで聞くようにしていますね。
自分自身でなにかをはじめるときも、必ず課題から考えるようにしています。解決手法にとらわれてしまうと、本質的な課題を解決できなくなってしまうんです。
たとえば経営層からDXを求められて、スクラムを導入することは一つの手段ですよね。スクラムを導入して、なにをしたいのかをしっかりと抑えないと、組織内ですれ違いが起きてしまいます。
プロダクトを開発する際に、顧客の課題を考えてつくるのと同じです。
僕も以前は、手段や手法にとらわれていました。
前職時代、当時のCTOに「なんのためにやるの？」とよく聞かれていたので、ロジカルに答える必要がありました。そこで鍛えてもらった結果、解決したい課題はなにかをはじめに考えるようになりましたね。
Rule2.成果にフォーカスする
解決したい課題を考えた後は、成果にフォーカスします。事業や組織として、どのような成果を得られるのかを考えるようにしています。
それらしい課題ってよく出てくるんですけど、すべてを解決しようとするとリソースをとても使ってしまうんですよね。なので、その課題を解決する必要はあるのか？ と考えなければいけません。
たとえば、技術的負債の話があります。負債がたまりすぎて耐えきれないのであれば、返済する必要はありますが、どのようなケースでも返済しなければならないかというと、そうではありません。
課題についても同じです。すべての課題を解決する必要はありません。費用対効果がいいものをやるようにしようと考えています。
機能を減らすことで成果につながることもあります。使っていないものは削除するんです。すでにあるものを削除するのって結構大変なんですよ。つくることよりもパワーを使います。でも成果にフォーカスするなら、やらなくてはならないときもあります。
Rule3.構造と仕組みをつくる
人に役割をつけると、組織のスケールは難しいと思っています。100人くらいまでの組織なら大丈夫かもしれませんが、そこから先は経験した限りでは壁を感じました。なので、どのような人でも成果が上がるような構造や仕組みをつくって、誰がその役割を担っても高い成果をあげられるように意識しています。
僕がやるべきことは、構造と仕組みをつくることだと思って仕事をしています。優秀な人材が高い成果を上げる属人的な組織ではなく、誰がやっても高い成果が上がる構造や仕組みをつくることが大事です。
「友情・努力・勝利」という少年マンガの定番要素がありますよね。でも僕は、仕事上では信じていません。
友情がなくても、努力しなくても勝利できるような構造をつくるほうが、仕事では効果的だと思っています。ドライな考え方かもしれませんが、誰がやっても勝利できるほうがいいのではないでしょうか。自分自身も含めて、人間の定性的な感覚に頼らないことも意識しています。
自分にバイアスはあるとわかっていても、無意識に選択しがちです。なので、組織に関する意思決定をするとき、事前につくってあるテンプレートに沿って記入をして、自分の考えをまとめるようにしています。支離滅裂なことを書いている場合、自分のやろうとしていることは違うかもしれないと気づけます。
Rule4.信じて委ねる
構造や仕組みがあれば、権限と説明責任を委譲できます。委譲した後が大事で、マネージャーはどうしても心配になってしまうんですよね。でも、そこで口出しをしてはいけません。我慢しています。
マネージャーになった直後の人たちの多くは、「自分ってなんの仕事をしているのかな？」と感じると思うんです。チームや人に任せると、自分自身はほぼなにもしないから不安になるんですよ。
僕も一時期、「周りの人からどう見られているのかな？」と気にした時期がありました。
だからマネージャーになったばかりだと、なにかを決めたがったり、口出ししたくなったりしがちになります。でも、そこはチームや人を信じて、できる限り黙ることが大事です。
任せたら失敗しても受け入れます。もちろん、責任はマネージャーの自分が取ります。なんなら、1回くらい失敗してもらったほうがいいとさえ思っていますね。失敗は次につながる資産になるというスタンスです。
委譲する際には、段階を踏んでいます。いきなりすべてを委譲してしまうと無茶振りや丸投げになってしまうので、チームや人によって任せられる範囲を見極めて、少しずつ委譲するようにしています。
Rule5.仕事の背景をていねいに伝える
Rule1で、「解決したい課題はなにかをはじめに考える」とお話ししました。課題だけを伝えてもわからないので、仕事の背景をていねいに伝えるようにしています。背景がわかっているかどうかで、仕事の質に差が出ると思います。
なぜこれをやる必要があるのか、これをやるとなにが起きるのか、その人にとってどのようないいことがあるのか。こうしたことを伝えます。
課題やその背景を理解して行動できると、マネージャーの想像以上の成果を発揮してくれます。手段だけを伝えた場合、想像以上の成果って出てこないんですよね。課題を解決できるのであれば、手段はなんでもいいと思っています。
伝えるときは、言葉だけで終わらせずにドキュメントとして残すようにしています。話しただけだと忘れてしまうので、後から確認できるようにするのは大事です。
仕事の背景を伝えるときだけではなく、あらゆるケースでドキュメントとして残すようにしていますね。
Rule6.事実を分析して改善する
個人の解釈や意見だけを聞くとそれぞれの視点で話すため、事実と異なる場合があります。なので、事実としてなにが起きているのかを分析することが必要です。
たとえば、「◯◯さんが困っています」と本人ではない別の人から話されても、本当かどうかわからないので、本人に確かめます。本当に困っているのなら、なにに困っているのかを深掘りします。
組織で起こった問題の場合も、まずは事実の確認です。組織に対してなにかのアプローチをして、それがうまくいかなかったとします。そのときには、いろいろな原因が絡み合っているはずです。原因を分析して、課題を発見したら解決するための仕組みをつくります。
実際にあった話で「スクラムをやりたくない」というメンバーがいたので、理由を聞きました。リファクタリングをやりたいとデイリースクラムで共有したところ、「いまはやるべきではない」と言われて、できなくなったからやりたくなくなったとわかりました。
でも、これってスクラムは関係ないですよね。スクラムチームのなかで、どのようにリファクタリングしていくのかが定まっていないから、優先度の認識に違いがあるわけです。結局、スクラムチームとしての認識を揃えていくことで落ち着きました。
なにが起きているのかをしっかり確かめることが大事です。
Rule7.「人」を大事にする
これまでに挙げてきたルールは、人によってはうまくいかないこともあります。ある1人が、組織を変えることも壊すこともできます。
人との連携がうまくできないと、構造や仕組みをいくらつくってもうまくいきません。
人が成長することで、組織の成果につながります。人材に対する投資をすると、リターンが大きく返ってくると信じたいです。
これまでに挙げたルールは、入ってきた人たちが成長するための土台です。成長した人たちが、高い成果をあげられるようになればいいですよね。
その支援をするのがエンジニアリングマネージャーの務めだと思っています。
（取材／文：川崎博則）
関連記事：
『エンジニアのためのマネジメント入門』著者が伝えたいマネジメントの楽しさ
