キャリア Vol.1102

コロナ直撃でも開発を加速できた理由は? 時価総額3兆円のシステムを支える、エムスリーのレジリエンス

山崎さん 西場さん 中村さん

東証一部上場で時価総額は3兆円と、飛ぶ鳥を落とす勢いで成長を続ける医療系ベンチャー・エムスリー。新型コロナウイルスの直撃を受けてもその勢いは衰えるどころか増すばかりだ。遠隔医療相談サービス『AskDoctors』のネイティブアプリ化をはじめ、コロナ関連の新機能リリースや新施策を連発している。

エンジニアの仕事とリモートワークとの相性は元来悪くないが、エムスリーではコロナ以前、全社的にリモートワークは原則禁止だった。にもかかわらずしなやかに対応できたのは、同社エンジニアリングチームのレジリエンスの高さの証明と言えるだろう。

その源泉はどこにあるのか。VPoEの山崎聡さんと、西場正浩さん(エンジニアリンググループグループリーダー兼コンシューマープロダクトグループリーダー)、中村奏子さん(エンジニアリンググループプロダクトマネジャー)の3名にそれぞれの立場から語ってもらった。

プロフィール画像
プロフィール画像

エムスリー株式会社 エンジニアリンググループ 執行役員 VPoE 山崎聡さん(@yamamuteking大学院博士中退後、ベンチャー企業、フリーランスを経て、2006年、臨床研究を手がけるメビックスに入社。09年、メビックスのエムスリーグループ入り以降、エムスリーグループ内で主にプロダクトマネジメントを担当する。12年にグループ会社であるシィ・エム・エス取締役に就任。15年にデジカルを共同創業、17年にVPoEとなり、18年からエムスリーの執行役員。現在はプロダクトマネジャーとして自ら新規プロダクトに関わりつつ、執行役員 VPoEとして、エムスリーグループを横断してプロダクト志向の開発プロセスおよび組織化を推進。20年4月からはエンジニアリンググループに加えて、ネイティブアプリ企画部門のマルチデバイスプラットフォームグループと全プロダクトのデザインを推進するデザイングループも統括

プロフィール画像
プロフィール画像

エンジニアリンググループグループリーダー
兼 コンシューマープロダクトグループリーダー
西場正浩さん(@m_nishiba17年、エムスリーに入社。現在はAI・機械学習チームのリーダーを努めながら、プロダクトマネジャーとして複数のプロダクト開発に従事。『AskDoctors』といったコンシューマー向けのサービスを開発するエンジニアチームの担当グループリーダーも務める

プロフィール画像
プロフィール画像

エンジニアリンググループプロダクトマネジャー 中村奏子さん日本最大級のポータルサイトを運営するIT企業にて複数プロダクトのプロダクトマネジメントを経験した後、19年5月エムスリーに転職。現在は、『AskDoctors』をはじめコンシューマ領域でのプロダクトマネジメントを担当。既存プロダクトだけでなく、新規プロダクトの立ち上げにも挑戦中


1事業あたりエンジニア平均4〜5人。機動力重視のスモールチーム

ーーエンジニアリンググループの組織構成から教えてください。

山崎:弊社は医療従事者向けニュースサイト『m3.com』を主力サービスに、製薬プロモーションサービス『MR君』、コンシューマー向けの遠隔医療相談サービス『AskDoctors』など、事業数で20以上、サービスで数えれば50以上の開発・運営をしています。

しかし、インターネット事業を中心にやっているエムスリー本体だけでいうと、社員はまだ約450人。1事業あたりの平均人数は20〜25人と決して多くなく、ベンチャー企業が20個集まってできたような会社です。

エンジニアに関しても同様で、エンジニアバックグラウンドのプロダクトマネジャーを含めてもまだ90人。エンジニアリンググループは全部で16のチームに分かれているので、1チームあたりのエンジニア平均人数は4〜5人です。ですから、各チームが裁量を持ってそれぞれの事業を進めていくのが基本的な考え方。

組織図的には16チームの上にマネジメントチームがありますが、これもトップダウンで指示を出して動かすというよりは、現場が動きやすいようサポートするのが役割です。例えばあるチームで「人が足りないから採用したい」という話が出たら、それをサポートして一緒に採用活動を行うといった動き方をします。

ーー16チームはプロダクトごとに分かれているということですか?

山崎:詳しくは私がTech Blogに書いた記事があるのでそちらを参照いただくのがいいかと思いますが、16チームのうち事業付きは8チーム。残りの8チームはエンジニアリングならではの全事業を支える横断チームです。

横断チームには、エンジニアリングではおなじみのSREチームや、認証基盤やメール関係の基盤をメンテナンスする基盤チーム、品質管理を推進するQAチーム、西場がリーダーを務めるAI・機械学習チームなどがあります。

エムスリー組織図

山崎:特徴的なのは、ネイティブアプリ開発などのマルチデバイスに対応する役割が、横断チームの方に置かれていることですね。

他社さんですと各事業チームにアプリエンジニアが配置される傾向にあると思うのですが、先ほども申し上げたように、弊社のエンジニアは全部合わせても90人、マルチデバイスに対応するためのエンジニアは10人弱しかいません。

そのため、各チームに分散配置するのではなく、マルチデバイスチームという一つのチームとして、事業チームと協力してアプリを作っています。今回の『AskDoctors』のコロナ対応・アプリ開発でも、一方では西場が事業チーム側のグループリーダーとしてそちらのチームを動かし、他方、私と中村はマルチデバイスチームを動かして、両者が連携して開発に当たりました。

このように目的別のチームを多数構成することによって、個人の裁量やチームとしての機動性を確保することを強く意識しています。

これは後ほど詳しく触れることになるかと思いますが、こうした組織編成も関係して、メンバー1人1人が普段から主体性高く働いてくれていることに、私たちの組織としての強みがあります。今回のリモート開発が円滑に進んだ大きな要因もここにあると考えています。

「能動的にコロナの解決を目指す」ことを新たなミッションに

ーー今回の新型コロナウイルスの問題にはどのように対応したのですか?

山崎:私たちは今回のコロナ以前、リモートワークについては比較的慎重に取り組んでいました。どんな働き方、組織マネジメントの仕方にもメリット・デメリットがありますが、どれを選ぶのかは、コーポレートミッションを達成するのに一番寄与するのはどれかという観点で決めるべきですよね。

「インターネットを活用し健康で楽しく長生きする人を一人でも増やし、不必要な医療コストを一円でも減らす」というミッション達成のためには、物理的に集まってチーム一丸になって対処するのがいいだろうというのが、それまでの私たちの考え方でした。

しかし、コロナ時代に突入したことで、前提となる環境条件が変わってくる。私たちはまず、リモートワークについての考え方の整理から始めました。結論から言うと、レベル1〜5の5段階の対応を設定しました。

レベル3は「リモート勤務をするには上長の許可が必要である」、レベル4は「原則リモートで、出勤するには上長の許可がいる」、レベル5は「出勤してはならない」などと定めて、その時点でどういう対応をするのがミッション達成にもっとも資するのか、議論しやすくする土台をつくりました。これが2月頃の話です。

3月に入り、実際にはレベル3からスタートしました。基礎疾患を持っている社員や、家族に高齢者や基礎疾患を持った方のいる社員を素早く把握し、すぐにリモートの許可を与えました。結果的にはこれがいいスモールスタートになったと思います。

レベル3の段階で一部のリスクの高い人だけをリモート勤務としたことがテストケースとなり、緊急事態宣言が発令され、レベル4に引き上げて以降も、大きな混乱なく業務を推進していくことができました。

もっとも、話をエンジニアリンググループにフォーカスすると、もともと夜間リリースや障害対応などで例外的に自宅からリモートで作業することはあったので、許可さえ出せばできることは分かっていました。

中村:現場のプロダクトマネジャーとしても、段階的にレベルが引き上げられるだろうということは予想が付いていたので、心の準備をしながら、「リモートになってもパフォーマンスを落とさずに対応しなければ」という意識でいました。

中村さん

山崎:今回もう一つ大きかったと思うのは、レベル4への引き上げと時を同じくして、代表である谷村から、このCOVID-19に対して私たちエムスリーのスタッフがどういう姿勢で臨むべきかというメールが全社員に送られたことです。

その中には、従来のコーポレートミッション達成に向けて引き続き努力するのはもちろん、「COVID-19で感染する人を一人でも減らし、感染で重症化した人を一人でも多く救う」ことを新たなミッションに加え、その達成のために能動的に取り組んでいこうと呼びかける一節がありました。

このメッセージにより、COVID-19に対して私たち自身が成果を出すというスタンスが明確になり、リモート環境という、ある意味で不安定な状況の中で、引き続き成果を出すことにこだわっていこうという意識が一人一人に醸成されたように思います。

マネジメントのオーバーヘッドもメンバーの自主性がカバー

ーー皆さんが揃って関わったという『AskDoctors』のアプリ開発プロジェクトは、不慣れなリモート環境に変わって、実際のところどうだったのでしょうか?

中村:基本的にスムーズだったと思っています。開発を開始したのは3月末くらいで、スタートしてすぐにリモート環境になりましたが、リモートだからできないということは特になかったです。チームメンバーは「フルリモートで全部できて自信になった」と言っていました。

山崎:『AskDoctors』アプリの開発は6スプリント12週間のプロジェクト。正直スケジュール通りに間に合うかどうかは微妙なラインだったと思うのですが、リモートになってもほとんど生産性は下がらず、見事に完成まで漕ぎ着けることができました。

ーーでは、リモートかどうかは特に関係がなかったということですか?

山崎:リモートになることのマイナス面ももちろんありますが、一方でプラスに働くこともあると思っていて、プラス分とマイナス分が相殺されて変わらなかった、あるいは若干プラスが勝ったかなという印象です。

エムスリーは役職階層が極めてフラットで、役員を含めても基本的には4階層しかなく、役員のすぐ下にエンジニアリンググループのリーダーがいて、その下に各チームのリーダー、その下にメンバーという構造になっています。

私は役員兼グループリーダーなので、直接コミュニケーションを取るのは主にチームリーダーです。ですからチームリーダーの様子はよく分かるのですが、リモートになると、その下にいるメンバーの様子はどうしても分かりにくくなります。

物理的に出社している状況では、チームリーダーとコミュニケーションをとる際にもメンバーがいる前で話すので、その会話をメンバーも聞いていてくれたり、逆に質問してくれたりということが自然と起こります。

それがリモートになると、基本的にはZoomでリーダーと一対一、あるいはリーダーだけを集めて話すことになるので、メンバーの様子は分かりにくくなって、おそらくは20〜30%のマネジメントのオーバーヘッドがあるのではないかと。

山崎さん

山崎:一方で、エンジニアはフロー状態に入れることが非常に重要な仕事なので、作業に割り込まれないで集中できるメリットは大きいですし、単純に通勤時間がなくなるとか、睡眠が長く取れてコンディションが良くなるといったプラス要素もあった気がします。

西場:僕はチームビルティング的なところは結構苦戦しましたね。僕が『AskDoctors』の事業責任者になったのはこの4月からだったので、チームの中で何が起こっているのか、みんなが何をやっているのかをすべて把握する前にリモートに突入しました。

先ほど「ベンチャー企業が集まってできたような組織」という紹介があったように、うちは本当にチームごとに文化から何からすべてが違うんですよ。そのため、新たにチームを立ち上げる際には、お互いのパーソナリティーを知るとかコミュニケーションのプロトコルをすり合わせるといった作業が非常に重要になる。

普段であればそのためにみんなで一緒にランチへ行って……とやるんですが、それが出来ない状況だったので。

ーーそこはどうやって解決を?

西場:Slack上でチームラーニングという形で自己紹介をし合ったところからうまく回り始めました。「私はこんな働き方が好き」「こういうことをされると腹が立つ」といった、チームでスムーズに仕事を進める上で知る必要があることを共有していきました。

ただ、それ以上に大きかったのは、一人一人が前向きなコミュニケーションを取ろうとしてくれたこと。僕が分かっていないことがあるのを前提に話してくれていたので、すれ違いを未然に防げていた部分があったと思います。自主的に考えてそういう動き方ができる人が多いことには、リーダーとして普段からすごく助けられていますね。

チームごとに文化はバラバラ。ゆえに協力意識が生まれる”パラドクス”

山崎:確かにエムスリーのリーダークラスには多様性があり、コミュニケーションスタイルはリーダーによってバラバラです。というのも、こういう条件に合っていないとリーダーとして認めない、みたいなことを定めていないからです。

もちろん組織としての行動規範はあるし、その点で長けている人がリーダーに上がるわけですが、リーダーシップの取り方は人それぞれでいいという考え方です。

サーバントな人もいれば、ゴリゴリ引っ張っていくタイプの人もいる。大事なのはコーポレートミッションを達成することであり、そこに向かっているのであれば、それぞれが得意なやり方でやってくれて構わないだろう、と。

そういう意味では、チームの立ち上げのフェーズでリモートになると、確かにやりづらさは生じるかもしれないですね。

ーーチームごとに文化やリーダーシップスタイルがまちまちな状況は、チーム間の連携の難しさにつながらないですか? 例えばマルチデバイスチームとコンシューマーチームの連携には問題は生じなかったですか?

中村:マルチデバイスチームとコンシューマーチームに関しては、いまのところはうまくいっていないと感じることはないですね。

西場:いま「みんな違うと大変じゃないですか?」と仰いましたけど、実際は逆だと思うんですよ。

むしろみんなが違うことを実感しているからこそ、例えば特別プロジェクトのような感じでいろんなチームから人が集まると、今までのやり方でやりたいというよりは、「このメンバーでこのプロダクトを良くするためにはどうしたらいいか」という観点で自然と考えられる。

働き方も締め切りに対する考え方も、サービスレベルで全部違う。なおかつ、チーム間の移動も多いので、「違う中でどうするか」と考えるのが、僕らにとっては当たり前になっているのだと思います。

ーーみんなが同じであるとか、何か一つの正解があるという前提に立つと、なかなかお互いの違いを受け入れられない。でも、そもそも違うものだという認識に立てば、その中でどうするかという発想になるわけですね。

西場:そうなんです。だからリモートになって困ったことがあまり思い浮かばなくて……。ほかに難しくなったことと言えば、山崎さんをいじりにくくなったことくらいですかね(笑)

先ほど、社内の役職レベルが4階層しかないという話をしましたが、うちの組織は本当にフラットなんです。例えば山崎さんは経営会議のメンバーだけれど、新卒で入った普通のエンジニアと机を並べて座っている。外から見ると違いに気が付かなくて、たまにインターン生とかから驚かれるくらいで。

僕もよく、みんなの前で山崎さんをいじるんですよ。例えばAIチームでランチに行くとなったときに、山崎さんが「俺も」と言って手を挙げたら、「いや、誘ってないし」みたいな感じで。それもあえて大声でやる。そうすると山崎さんも積極的に乗っかってきてくれます。そうやって話し掛けやすい雰囲気を意識的につくってくれているんです。

でも、こういうやりとりをSlack上でするのはちょっとやりづらいなと思いました。「誘ってないし」と文章で書くのもどうかという気がするし(笑)

西場さん

山崎:でも、このフラットさはかなり重要だと思います。それが最初の話につながってくる。リモートワークになると、どうしたってメンバーの自主性が重要になるじゃないですか。指示待ちだと生産性は落ちますから。

じゃあ、リモートワークにおけるメンバーの自主性はどういうところから来るのかと言えば、やっぱり普段から自主的に、率先して仕事をしていることがものを言うわけですよね。

弊社の場合は、組織のフラットさがそれを促しているところもある気がします。組織のフラットさと小さいチーム、明確なミッション。こうしたものが合わさって、リモート下、コロナ下でも一人一人がそれぞれの問題解決に対してベストなパフォーマンスを発揮してくれている。それが今回の最大のポイントだったと思いますね。

全体効率を犠牲にしてでも主体性を重んじるOSS的精神

ーースピーディーに開発することを考えたら、当然、指示待ちエンジニアは少ない方がいい。そうすると、組織はフラットな方がいいだろうし、小さいチームがいいように思えますが、実際はそれとは逆の組織も存在していますよね。それはなぜだと思いますか?

西場:それを選択するのが難しいということじゃないでしょうか。想像してみてください。仮にも一部上場企業の経営会議メンバーが、僕が主催する勉強会に準備から来て、乾杯の音頭を取ってくれるんですよ。そんな執行役員、あんまりいないですよね? でも、それをやらないとフラットな組織なんてできないんです。

「フラットな組織」と口で言うのは簡単。おそらくは組織デザインもそれなりにはできる。圧倒的に難しいのは、実際にそれが回る環境をつくることです。

僕が見る限り、うちの組織では本当に多くの人がそのための努力をしていますよ。いちメンバーが執行役員をいじるというのもその一つ。各々の主体性を大切にするフラットな組織をやる上では、それなりの運用コストを払う必要があるということじゃないでしょうか。

山崎:別にうちのやり方だけが正解ということじゃないんです。要は、「伽藍とバザール」の話だと思っていて。トップダウンの綺麗なマネジメントスタイルを確立すれば、一見効率よく水が流れているように思える。でも流れている水の量、つまりはアウトプットを考えると、雑に蛇口をひねってドバドバと水を流した方が大きいこともあるかもしれない。

主体性を重んじるスタイルを選ぶことにもリスクはあります。OSS開発でも同じようなプルリクエストを2回書いてしまうということがあるように、複数人が同じ作業をしてしまったということは当然起こり得る。

ですが、全体効率を優先して統制しようとすると、主体性は損なわれる。ですから、そのバランスをどう考えるかという話なのではないでしょうか。

山崎さん

山崎:たった90人のエンジニアで時価総額3兆円企業を支えるようなシステムを作り、保守していくには、やはりトップダウンですべてを管理するのは不可能というのが私たちの考え方です。ですから、多少の重複があったとしても、それぞれがそれぞれの判断でチャレンジしていく。

ある種、OSS的な精神に則っているのがエムスリーのスタイルと言えるかもしれません。これには、エムスリーのエンジニアリングチームがもともと、OSSコミュニティーで有名な人が中心となって立ち上げられた経緯も関係していると思います。

ーー組織に息づいたOSSの精神が、エムスリーで働く一人一人の主体性の源泉であり、不測の事態にも対応できるレジリエンスの源泉にもなっているんですね。

山崎:でも、実際カオスですからね、うちは(笑)。言語に関する考え方を見れば誰もがそう思うんじゃないかな。グループ全体で一つの言語に絞った方が効率はいいですよね。一つの言語さえマスターすればいいわけだから。

でも、うちはその逆です。まったく統一しない。16チームそれぞれ違いますし、チーム内でも複数言語を使うから、全体で10以上の言語を使っていると思います。そうやって現場判断で技術を選んだ方が、問題解決の生産性は高いと考えているからです。

「プロジェクトやチームをスイッチするときに困るじゃないか」という指摘は当然考えられますが、そこで「いや、困らないです」という人だけ採用しているとも言えます。

新しい言語は3カ月も勉強すればマスターできる。プログラミング言語はどれも本質的にそこまで大きく変わらないですから。そもそもそういうマインドセットを持った人たちばかりが集まっている。そういう組織なんだと思います。今後も多様性や変化を楽しめる人たちと一緒にプロダクトを開発しながら、日本、世界の医療を少しでも前進させたいですね。

取材・文/鈴木陸夫 編集/河西ことみ(編集部)

この記事が気に入ったらいいね!しよう

エンジニアtypeの最新情報をお届けします

RELATED POSTSあわせて読みたい

RECOMMENDED POSTSあなたにオススメ

JOB BOARD編集部おすすめ求人

アスクル株式会社_求人情報ページ
エンジニア転職フェア@Web開催 ITエンジニアを求める優良企業とオンラインで話せる!
記事検索

サイトマップ



記事ランキング

寿命が縮まる、人生が変わる…8時間耐久でインフラ技術競い合うISUCONの魅力とは?過去優勝者・主催者に聞く

寿命が縮まる、人生が変わる…8時間耐久でインフラ技術競い合う...

SIerって本当にヤバいの? ひろゆきが語る、業界ごと沈まないためのキャリア戦略

SIerって本当にヤバいの? ひろゆきが語る、業界ごと沈まな...

英文メールでよく見る「略語」の意味は?アメリカ&シンガポール企業で働くエンジニアが解説

英文メールでよく見る「略語」の意味は?アメリカ&シンガポール...

【hey佐藤裕介】天才と呼ばれた男が、20代で経験した挫折から学んだこと「若手エンジニアは“つよくてニューゲーム”状態をつくれ」

【hey佐藤裕介】天才と呼ばれた男が、20代で経験した挫折か...

データサイエンティストに必要なスキル・仕事内容・勉強法を網羅的に解説

データサイエンティストに必要なスキル・仕事内容・勉強法を網羅...

「type転職エージェント」無料転職サポートのご案内