(この記事は Livesense - 関 Advent Calendar 2017 掲載のために書かれています)
2017年の春からリブセンスのエンジニア組織改善に関わり、同年夏頃からエンジニア職能の全社リーダを任されることになった能登と申します。社内的には Livesense Engineer Leader という名前の役割なのですが、実質 VP of Engineering の仕事をしており、社内にエンジニアリング・マネージャを増やすことも重要な「おしごと」になっています。
エンジニアリング・マネージャは、主にエンジニアの評価・育成・メンタリングや組織面の問題解決を行う役割ですが、正直言って目指そうとする人は少ないです。エンジニアになろうとする人は技術が大好きか、人とのコミュニケーションをわずらわしいと思うことが多いので、自然なことだと思います。自分も昔はそういう人間でしたし、いまだに内向的な性格は変わらないままです。
ただ、ピープル・マネジメントの部分を、エンジニアリングを理解しない人に任せようとすると
- ビジネスの論理が先行し、エンジニアリングの論理がないがしろにされる
- エンジニアのキャリア形成やモチベーション (≒ 技術の楽しさ) が理解されない
という問題が発生しがちです。
非エンジニアにこういったことを理解してもらうより、エンジニアがピープル・マネジメントをするほうが一般的に容易です。言い方を変えると、非エンジニアにエンジニアの権益を代表してもらうより、エンジニア自身が代表した方がうまく機能しやすいのです。したがってエンジニア、あるいはエンジニアリングをしっかり経験した人がエンジニアリング・マネージャになったほうがよいとされます。
ここで言うエンジニアリング・マネジメントとは
ちなみに、誤解されないようにまとめておくと、ここで言うマネジメントとは
- 人を管理・コントロールする
というより
- 性善説に基いて信頼して仕事を任せられるメンバーを集める
- その人たちがエンジニアリングに集中できるようあらゆる問題解決を行う
- 問題を感じる時、声を上げられるように心理的安全性を確保する
- 仕事の成果と、メンバーの成長を重ね合わせられるよう目標設定/評価する
- 他部門、他職種の人との調整・対話を行う/促進する
- ここにあげたようなことを自然と実現できるような仕組みづくり、意思決定をする
などを指します。どちらかというと「サーヴァント」と呼ばれるような役割が多くて、それを通して得た知見を元に意思決定をしていきます。
この役割の捉え方は、技術面の責任者 = テクニカル・リード/アーキテクトや、プロダクト面の責任者 = プロダクト・マネージャとの分担として存在するものです。実はもうひとつ、組織のマネージャとして「どんな状況でもなんとかする、結果を出す」という役割もあったりしますが、その有効な実現手段として上記の「サーヴァント」の役割を果たすという側面もあります。
エンジニアリング・マネージャはコードを書く時間がとれない問題
さて、ある程度の規模のメンバーを対象とするとなるとエンジニアリング・マネージャ専業とならざるを得なくなり、プロダクト・コードを書く、技術の問題に取り組むという時間がなくなるのが問題です。
私はエンジニアリング・マネージャとして 10 年くらいこの問題と付き合って来ましたが、今日は現時点での結論を紹介したいと思います。
いちばん重要なのは、
「一線でコードを書く人の気持ちを忘れない、そういった人たちへのリスペクトを忘れない」
ということです。
アンチパターンなのですが、マネジメントを目指す人には、技術について挫折した人が一定いるのも確かです。そういった人は、得てして「技術は重要ではない」と言いがちです。マネジメントを任された人は組織上一定の権限を与えられています。そういった状況で自分が苦手なことの価値を下げるような判断もできてしまいます。つまり、技術より自分の論理を先行させてしまうということです。
多階層の下請け構造に支えられた受託開発の世界では、技術を武器にするより、一時的に集めたメンバー全員が使える無難な技術で納品までたどり着かせるということが重要ですし、永続的に維持される信頼関係に基づいたチームを作る必要もありません。日本で今なおソフトウェア分野のエンジニアが多く存在する受託開発の世界でのマネジメントと、自社プロダクト企業で先に説明した「サーヴァント」中心とするマネジメントでは目指すものが異なります。
何のためにマネジメントの役割を担うか? それはプロダクト実現の中核を担うエンジニアが働きやすい環境を作るためです。エンジニアが苦手なコミュニケーションと、組織づくりを代理して行うのです。そこでの主役はマネージャではなくエンジニアであり、技術はエンジニアの重要な武器です。そのエンジニアや技術を損なうような悪は決してなさない。それをきちんと担保することができれば、マネージャ本人がコードを書いているか、技術の問題に取り組んでいるかは本質的な問題にはならないはずです。
むしろ、マネージャ本人がコードを書いているべきという言い方は、その行為が「この人はコードを書く人の気持ちを忘れていないはずだ」ということを示す実例だからではないでしょうか。
もちろん、「自己組織化」というキーワードがあるように、自分たちの問題を自分たちで発見し、解決していくようなチームづくりも可能だと思います。そうすると、定常的なものについては自分がタッチせず、より例外的・変則的な事象のみ対応するというマネジメントも可能になってきます。そのようなチームづくりを通して自分の時間を確保してコードを書くというのも一つの手です。
コードを書いていないという罪悪感を払拭する
自分は長く「自分がコードを書いていない」という罪悪感を感じながら、エンジニアリング・マネージャ (あるいはエンジニア人事、エンジニアリング・アドバイザー) をし続けてきました。罪悪感というのは人の心をむしばみます。いつも何か悪いことをしている気持ちが拭いきれない。後ろめたい。。。自己肯定感を著しく損なってきました。
ただ、ある時、気づきました。
「自分はコードを書くことより、エンジニアひとりひとりと向き合いながら、エンジニアが働きやすい組織を作る方が好きだ」
ということに。そして、それは上記の「コードを書く人の気持ちを忘れない」を守る限り悪ではない、ということに。
そういう風に、肯定的にエンジニアリング・マネージャのしごとを捉える人が、社内外問わず、日本に増えてくれることを祈っています。そうすると多数派を占めるエンジニアのみなさんにとっても、自分が苦手なことをしてくれる人が増えてより働きやすくなると思いますよ!