ソフトウエアプロダクトが事業のコアとなる中で、どんな企業にとってもエンジニア採用は必須事項となっている。加えて、自社で働くエンジニアを定着させる工夫も欠かせない。
「今の環境では成長できない」「やりがいが得られない」……そうしたマンネリ感を与えてしまう組織では、貴重な人材が流出することにもつながりかねないのだ。
そこで、営業DXサービス『Sansan』や名刺アプリ『Eight』などを手掛けるSansanが2022年2月28日に主催したイベント「エムスリー山崎氏とSansan西場が語る『エンジニアのチャレンジをどうマネジメントするか』」の内容を紹介したい。
このイベントでは、同社のVPoEを務める西場正浩さんと、医療従事者向けの情報サイト『m3.com』を運営するエムスリーの山崎聡さんが、エンジニアがやりがいを感じられる、「技術的に挑戦できる組織」をいかにつくっていくかについて議論を交わした。
本記事ではその内容の一部を、参加者からのQ&Aも交えてレポートする。
※記事の内容は、全てイベント開催時点の肩書に基づいています
エムスリー株式会社 執行役員 CTO／VPoP
山崎 聡さん（@yamamuteking）
※イベント開催時点では執行役員VPoE／PdM
大学院博士課程中退後、ベンチャー企業、フリーランスを経て、2006年、臨床研究を手掛けるメビックスに入社。09年、メビックスのエムスリーグループ入り以降、エムスリーグループ内で主にプロダクトマネジメントを担当する。18年からエムスリーの執行役員。20年4月からはエンジニアリンググループに加えて、ネイティブアプリ企画部門のマルチデバイスプラットフォームグループと全プロダクトのデザインを推進するデザイングループも統括。20年10月より初代CDO（最高デジタル責任者）に就任。22年4月より現職
Sansan株式会社 VPoE ／技術本部 研究開発部 部長
西場正浩さん（@m_nishiba）
大手銀行で数理モデル開発に従事。その後医療系IT企業でエンジニアや事業責任者、採用人事などを幅広く務める。2021年にSansan株式会社へ入社。技術本部研究開発部でマネジメント業務に当たり、現在はVPoEとしてエンジニア組織の整備と強化を担う
西場：山崎さんは、エムスリーのVPoEとして約100人のエンジニアをまとめる立場にいますよね。（※）VPoEとしては、どのようなことがミッションだと考えていますか？
※2022年4月よりVPoEを卒業し、CTOに就任
山崎：そもそも、エムスリーがVPoEを導入したのが2017年のことなのですが、導入に至った背景から説明したいと思います。
直接のきっかけは、組織のスケールに伴う問題です。私が2009年にエムスリーにジョインした時のエンジニア数は約20人、そして2016年にエンジニアリンググループのマネジメントに関わり始めた時点で50人くらいと、まだ少人数でした。そのエンジニアの数では、ビジネスのスケールに到底追い付けない状態だったんです。
それで、経営陣から「エンジニアを増やせば、もっとビジネスを拡大できるのでは」という要望があり、その課題を解決するのがVPoEとしての役割の第一でした。つまり、エンジニアリングと経営を接続するということです。
西場：それは成功しましたか？
山崎：失敗もありました。当時、エンジニアリングと経営を接続して250億円くらいの収益があったあるセグメントを、400億円にしようという目標を立てました。これは経営陣には受けがよかったけれども、一部のエンジニアには刺さりきらなかったようで、「そのために何をしたらいいか分からない」と、むしろ辞めてしまう人が出てしまった。苦い経験として記憶に残っています。
西場：なるほど。そこから今日のテーマである「チャレンジマネジメント」という話題に入っていきたいと思うのですが、山崎さんはVPoEとしてどのようにエンジニアのチャレンジをマネジメントされているのでしょう。
山崎：VPoEとして何を目指すかといえば、日本、世界の医療を前進させるために、エンジニアリングの組織をいかにスケールするかということです。もっと直接的には優秀なエンジニアを採用して、離れないようにリテンションしていく。そのために最も重要なのは、そうしたエンジニアの組織が「いかに経営に接続しているか」という点です。
これが先程の話題とつながるのですが、経営陣が「エンジニアを増やせば利益が上がる」という仮説を持ってきたときに、それを検証して、エンジニアのチャレンジにちゃんとつながるよう組み立てることができるか。それがVPoEとして最も重要なことだと思います。
西場：それでいうとエムスリーでは、具体的にどのようなチャレンジをされてきたのでしょう。
山崎：会社としてのチャレンジでいえば、新規事業やプロダクトの開発、技術負債の返却、オンプレミスからクラウドへの移行などいろいろあるのですが、チャレンジというのは最終的には一人一人個別のものなんですよね。それをちゃんとマネージできるかというところがポイントです。
西場：僕がエムスリーで働いていて感じたのは、常に一つ上のチャレンジが目の前にあるということです。それは、チャレンジマネジメントが上手くいっていたということですよね。
ところで、例えばそのマネジャーが、テックリードタイプかマネジメントタイプかによって、チャレンジマネジメントの仕方は変わってくると思うのですが、いかがでしょう。
山崎：それは重要な観点ですね。チャレンジマネジメントには複数の観点があって、一人ですべてをこなせるとはとても思えません。
例えば、私はチャレンジの大きな方向性を考えることは得意ですが、そのチャレンジを行動レベルに分解して個人にアサインしていくことは、正直苦手なんですよ。だからこそ、マネジメントチーム自体を複数人で構成して、チャレンジの設定や、その人のWillと合うような伝え方など、それぞれ得意な人が担当するような仕組みにしています。
西場：たしかに、チャレンジといってもいろいろですからね。Sansanは売り上げにつながっているメインのプロダクトを持ちながら、新しいプロダクトも開発している。技術的な裁量もあるので、それぞれのフェーズにおいて多様なチャレンジがあることが魅力的だと感じます。
逆にいえば、そうした多様なチャレンジを個人にマッチングさせることの難しさがありますよね。
山崎：そもそもチャレンジが足りない会社からは、人が去ってしまいます。つまり、社外にチャレンジの機会を求めて転職してしまうことになる。エムスリーでも、かつてそういうことがありました。だから、マネジメントチームとしては先回りして、組織としてチャレンジを用意しておく必要があります。
ただ、これではまだ半分で、そのチャレンジを管理する、システム化するということが後半の課題となります。
そこでエムスリーでは、エンジニアリングチームのリーダーにチャレンジの管理表を作ってもらうことにしました。スプレッドシートの縦にメンバー、横にチャレンジを記入した表で管理し始めてから、だいぶ上手くいくようになりました。
西場：そうしたチャレンジは、チームリーダーが考えているんですか？
山崎：リーダーによりケースバイケースですね。私が考えた案を各リーダーに分解してもらうこともあれば、エンジニア自身がチャレンジを考える場合もあります。それぞれの強みと弱みを補い合うのがいい方法だと考えています。
西場：結局、みんな一律に同じチャレンジを設定するのは無理ですよね。僕もSansanで研究開発部の部長をしているのですが、やはりメンバーは一人一人やりたいことが違うので、1on1でのディスカッションをしながらそれぞれのチャレンジを設定していくことが非常に大事だと感じました。
山崎：その通りです。先程、チャレンジをスプレッドシートで管理していると言いましたが、これを知っているのはチームリーダーまでです。結局は1on1でやっていくしかないというか、いわゆるOKR（Objectives and Key Results）のような感じで、分解していくしかないですね。
西場：たしかに、会社の目標があって個人の目標があるという階層構造ではあるのですが、その目標の中に自分たちがどう貢献できるのかを見いだすのが、チャレンジの大きな役割だと思います。
トークセッションの後半は視聴者からの質問に答えた。多くの質問が寄せられ、Q&Aコーナーへの回答は1時間にも及んだ。その一部を抜粋してお届けする。
質問：チームの中にパフォーマンスが出ないメンバーがいる場合は、どのようにしていますか。何かサポートをしているのでしょうか。
山崎：パフォーマンスを上げようとするよりは、まず、その人のパフォーマンスが出ていない理由を考えた方がいいですね。状況によっては、その人自身にアプローチするよりも、チームを異動する方が良いこともあります。
VPoEの役割は、エンジニアリングのアウトプットを収益につなげることです。ですから、理想的には無理矢理に誘導することなく、会社の期待するパフォーマンスを発揮してもらいたい。そのための仕組みをつくることがチャレンジマネジメントだと考えています。
西場：もう少し現場目線からお答えすると、本人とマネジャーとの認識を合わせることが大切だと思います。もしかしたら、本人はパフォーマンスが出ていると思っているかもしれない。そういう認識の齟齬がないように、ヒアリングをするといいのではないでしょうか。
質問：どのようなエンジニアが「優秀」だと思いますか？
西場：自分の強みを理解している人は優秀だと感じます。さまざまな強みを持っている方はいますが、その強みが何かというよりは、自分の強みを生かして仕事をするということが大事かな、と。技術的な面であれ、マネジメント的な面であれ、最終的に組織に貢献しているということが大事です。
山崎：当たり前ですが、「50種類のCPUに対してすべてマシン語で書けます」みたいな圧倒的な技術を持ったエンジニアは優秀ですよね。この質問の意図は実はそういうことではなく、「どんなエンジニアが評価されますか」ということだと理解しました。
そう捉えると、西場さんもおっしゃっているように、「会社の成長に資するエンジニア」は評価されます。もっと言うと、その目標を自分自身でWillをかなえつつ、楽しみながら達成してしまうような人は優秀だと思います。
質問：サービスに関わるエンジニアの場合、通常業務の開発ではチャレンジする機会が少なくなりそうですが、どのようにしてチャレンジを創出してますか。
山崎：サービスに関わっていても、チャレンジはたくさんありますよね。例えば私は電子カルテのチームを担当していましたが、一人でも多くのユーザーに使ってもらうというのは立派なチャレンジです。
だから、そのサポート用のサービスやツールを開発することも立派なチャレンジで、そのように考えればチャレンジというのは工夫次第でいくらでも生み出せるのではないでしょうか。
西場：そうですよね。技術的な側面でも、サービスの新しい機能やバックエンドの部分ならば新しい技術が使えそうなのであればどんどん導入すればいいと思うんです。だから、先端の開発などでなくても、技術的なチャレンジを見つけ出すことはかなりできると思います。
山崎：ただ、それには前提条件があって、エンジニアの裁量がある程度認められている組織である、ということが必要です。事業サイドの指示にしたがって、行き過ぎた工数管理の中で作業するだけだったら難しい。
だから、そういう裁量を作ることもVPoEの重要な仕事の一つだと思います。エンジニアのアウトプットを事業貢献に結びつけ、その対価としてエンジニアの自由度を上げる。それが私の目指しているところです。
西場：そうですね。僕も今VPoEとして、現場の裁量をさらに増やしていくということをミッションにしています。チャレンジの重要な役割は、そうやってエンジニアが自分の判断で意思決定できる状況を増やしていくことだと思います。
質問：マネジメントができるようになるためには、普段からどのようなことに気を配って仕事をするのがいいでしょうか？
西場：マネジメントというのは、やはり組織の成果をいかに大きくするかということです。その手段として、ピープルマネジメントやプロダクトマネジメント、技術マネジメントがある。ですから、「成果」というところに気を配っていくといいのではないでしょうか。
山崎：マネジメントは「管理」ではなく、「経営」そのものですよね。だから、マネジメントができるようになるというのは、経営ができるようになることです。もちろん、経営というのは利益を上げることだけではありません。利益はそこそこで、みんなが楽しく働ける場所をつくるのも経営です。
そういう意味では、最低限、エンジニアが楽しみながら、生き生きと仕事をしているということは重要な指標になると思います。今の時代に、搾取型のマネジメントでは組織は存続できませんから。
文／高田秀樹
NEW!
NEW!
タグ
