LIFULLにおけるエンジニアリングマネージャーとは何かを考えてみた
見出し画像

LIFULLにおけるエンジニアリングマネージャーとは何かを考えてみた

先日、とあるマネージャーと話していて、LIFULLにおけるエンジニアリングマネージャーってどのようなものか。という話になりました。

LIFULLエンジニア全体では目指す姿として前回の記事でも紹介した LIFULLエンジニア像 というものがあります。

しかし、エンジニアリングマネージャーには、エンジニア像のような言葉がありませんでした。良い機会だと思いましたので、過去に社外向けの登壇でエンジニアマネジメントに関して話したものも利用して(一部修正)、この内容にも触れながら、改めて整理してみました。

(以下スライドの7-13ページ)

なお、エンジニアリングマネージャーの仕事はLIFULL内でも多岐にわたるのですが、その中でもどんな階層であろうとエンジニアリングマネージャーであれば、各人の領域でやってほしいことを組織全体の観点から書いています。なお、本記事ではエンジニアリングマネージャーに必要なスキルセットなどの話はしません。


まず、マネージャーの役割とは一体何なのか?

社内で何人かのエンジニアリングマネージャーにヒアリングしてみたところ、以下のような意見が出ました。(「マネージャーの役割を一言でいうとなんですか?」と聞いたのでエンジニアに寄っていない回答です)

・メンバーが自信を持って仕事できるようにする
・お金を管理する
・決まった方向に向かってきちんと方針にずれないように導いていく
・意思を示して引っ張る
・プロジェクトを成功させる

つまり、人によって表現は異なっており統一された言葉はない、というところだと思います。

前提としてLIFULLの組織長には、リーダーでありマネージャーであることが求められています。ここで言うリーダー・マネージャーを簡単に説明すると以下のようなものです。

リーダー → 課題を設定し(ビジョンを描き)、語り、先頭に立って走る人
マネージャー → 仕事を分担、進捗管理し、課題を解決する(成果をあげる)人

また、経営の神様と呼ばれている、P.F.ドラッガーは以下のように言っています。

「組織に成果をあげさせるための道具、機能、機関」
「人にかかわるものである。その機能は人が共同して成果をあげることを可能とし、強みを発揮させ、弱みを無意味なものにすることである。」 by P.F.ドラッガー

私は(そして、あえてシンプルな言い方をすると)『ヒト・モノ・カネを使って成果を最大化する』というのがマネジメントの仕事だと思っており、それをスペシャリティのあるエンジニアの領域で行うのがエンジニアリングマネージャーの役割だと思っています。


エンジニアリングマネージャーが最大化する成果とは

エンジニアリングマネージャーが最大化すべき『成果』とは、『短期・長期問わず価値創造が価値獲得(事業価値)として結び付けられること』だと考えています。

画像1

※上記の図の部分は延岡健太郎先生執筆の『MOT[技術経営] 入門』を参考に書いています

ものづくりを付加価値や利益に結びつけるには価値創造価値獲得の2つの要因が必要で、価値創造、価値獲得はそれぞれ、以下のようなものです。

価値創造・・・プロダクト開発や開発プロセス整備
 └ 技術・商品価値創造:プロダクトの開発やR&D、優れた技術
 └ 価値創造プロセス:優れたQCDやオペレーション効率的な製品開発

価値獲得・・・事業価値を創造すること(企業としての付加価値・利益をあげること)
  ※売上や利益、ユーザー満足度、などの事業として狙う成果と言えると理解しています

私はこの構造は理解しやすかったのでこちらをベースに考えを発展させていきました。

如何にプロダクト開発チームやエンジニアたちが素晴らしいものを作った(価値創造した)としても、最終的には事業成果(価値獲得)につながらないと事業が存続していきません。
そこを結びつけるように設計・行動・説明する ことがエンジニアリングマネージャーにとって大切だと考えています。
※上記の図の中央にある縦の矢印の部分

その理由は、エンジニアの活動が他職種からの見えにくいが故に生まれがち「価値創造が価値獲得(≒事業成果)に寄与しているのか?」という問いに答えていく責任がエンジニアリングマネージャーにはある、と考えているからです。

エンジニアはより良いプロダクトの開発を目指し多岐に渡る活動をします。プログラミング、インフラ構築、CI/CD環境の整備、セキュリティ強化、テスト記述、リファクタリング、等です。(その他にもたくさんの活動をするのはご存知かと思います)

一方でそれらの活動は価値獲得と結びついていることが明確にわかるものばかりとは限らないのです。

結びつきが明確にわからないことによって「該当職務に従事しているエンジニアが評価されにくい」「組織としてその領域に投資されにくい」等の問題が発生してしまいます。

しかしこれは価値創造価値獲得に繋がること、つまり、現在エンジニアチームが行っている(特にわかりにくい)施策が、短期的(時には中・長期的に)見たときにも売上や利益に繋がる、という話や構造を説明できることで上記の問題を解消できると考えています。

例えば、Webページの表示速度が高速化することは事業の成果につながる(もちろん業種によりますが)ということは、過去に Amazonの調査結果 などが広く知られ、最近だと Googleの調査結果 により更に認知される様になったと感じています。
それによりエンジニアと他職種の間で共通言語ができ、高速化の取り組みが歓迎・評価されることが多くなりました。

またテストを書く、リファクタリングして技術的負債を返済する、なども価値獲得への結びつきがわかりにくいものの一つでしょう。ここは近年様々な可視化指標が生まれ、価値創造と価値獲得のつながりを説明しやすくなりつつあります(とは言えこのあたりは非常に難しいところですね)

このように、価値創造→価値獲得への結びつきがわかりにくいもの(例えば、セキュリティやQA/QCなども)は多々ありますが、エンジニアリングマネージャーは専門領域の知見を持っているからこそ、その領域に関わっているエンジニアたちが出した成果(価値創造)を如何に価値獲得に繋がるかを設計し説明する、繋がりがわかりにくければ繋がるためのパーツを埋めていくことが大切です。(感覚で理解していることを言語化、構造化するということですね)

また、価値創造→価値獲得の方向だけでなく、外部との結節点になることで価値獲得につながるようなニーズ(顧客や他部門)を収集してエンジニアリングのチームに伝え、価値創造に活かせるようにする(価値獲得→価値創造)、というのも重要な仕事の一つです。

個社ごとの状況があるので一概には言えませんが、LIFULLにおいて「うちの会社は技術(人員含む)の投資に対して理解がない」と声が聞こえるならば、それはCTOである私やエンジニアリングマネージャーが上記の役割(価値創造と価値獲得を繋げられていない)を果たせていなかった部分があるなと反省すべき点になると考えています。(幸いながらその声が聞こえてくることは少ないですが)


価値創造と価値獲得のループを回し続ける

画像3

前述の「価値創造から価値獲得へ転換」という部分を継続的にできるようにする、つまりその仕組みを作っていくこともエンジニアリングマネージャーとしての大切な仕事だと思っています。

「仕組みを作る」ということにフォーカスしている理由は、属人的になりすぎないようにすることが、組織が競争力を育んで行く上で重要だと考えているためです。
注意として「属人的である」ことは否定していません。むしろ、組織が最高のパフォーマンスを発揮する(≒各個人が最大のパフォーマンスを発揮し合う)ためには、各個人が誇る能力、言わば属人的な能力を最大限発揮して成果を出すことが大切だと思っています。ただし、組織においての根幹や基本的な部分はその人がいなくなったから回らないということを避けるために、属人化をなくし最低限の仕組化をしておくこともマネージャーとしての責務だと感じています。

また、仕組化を推進するためには「感覚で理解していることの言語化」も大切だと考えています。

画像3

『言語化して説明せずとも理解される組織』が一番いいとは思いますが、それは『説明せずとも理解してくれる誰か」もしくは『説明せずとも理解される誰か』に依存している組織なのではないかと近年は考えています。仮に経営陣やエンジニアリングマネージャーが入れ替わったとしても理解されるように可視化などを進め仕組化しておくのがいいのだろうなと思っています。

おわりに

本記事ではLIFULLにおいてエンジニアリングマネージャーがどんな存在であるべきと考えるかを書いてみました。今回は一つの側面にのみ触れたので、他のやることには触れていませんが、採用や組織づくり、プロジェクトのマネジメントなども『短期・長期問わず価値創造が価値獲得(事業価値)として結び付け続ける』という成果を最大化していくために必要に応じたバランスでやっています。

この話は、もともとCTOとしてのあり方について考えていたときの頭の中の整理に近くて、『価値創造する集団』を何と定めるかによって、CTOのスコープにもエンジニアリングマネージャーのスコープにもなるなと考えたものになります。(例えば『価値創造する集団』を会社全体のエンジニアリングチームと考えれば、それを如何に価値獲得につながるかはCTOが考えることですし、『価値創造する集団』をと10名程度でプロダクト開発をチームと定義すればエンジニアリングマネージャーが上記フレームに当てはめて考える、等)

また、今回はエンジニアリングマネージャーの個別のスキルやふるまいの話はしていませんが、今後そのような話も整理していければ良いなと思います。

Twitterはこちら(たまにまともな話もつぶやきます) 
 https://twitter.com/nagasawatsubasa

お読みいただきありがとうございました。

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
ありがとうございます!うれしいです!
株式会社LIFULL Chief Technology Officer。