新体制になったメドレー開発組織について CTO 2 人に語ってもらいました
はじめに
みなさん、こんにちは。技術広報・エンジニアの平木です。
既に 2 月に発表されていますが、4 月より弊社の経営体制を大幅に変更しました。開発組織について大きく変わった部分として CTO 2 名体制になった点があります。そこで、なぜ CTO を 2 名にしたのかや、これからのメドレーの開発組織についてを CTO になった 2 人にインタビューしました。
インタビュイー紹介
稲本さん
執行役員。人材プラットフォーム(以下、人材 PF)CTO。独立系 SIer でのインフラエンジニアに始まり、インターネット企業での様々なサービスのインフラ構築を経て、音楽配信サービスやインターネットラジオサービスのサーバサイドエンジニアとして従事。2014 年メドレー入社後は創業時から運営しているジョブメドレーのプロダクト開発に従事。その後、同サービスのリードエンジニア、開発責任者を経て、2023 年 4 月より現職。
田中さん
執行役員。医療プラットフォーム(以下、医療 PF)CTO。独立系 SIer でのアプリケーションエンジニアや IT コンサルタントを経て、株式会社サイバーエージェントでサーバサイドエンジニアとしてソーシャルゲームや動画サービスなどの開発立ち上げに従事。2016 年メドレー入社後は CLINICS カルテの立ち上げを経験。その後 CLINICS 開発責任者を経て医療 PF プロダクト横断基盤の立ち上げ・開発責任者を経て 2023 年 4 月より現職。
左から田中さん、稲本さん
CTO を 2 名体制にして開発組織の体制をアップデートした理由
平木: さっそくですが、2023 年 4 月よりお二人がそれぞれ人材 PF と医療 PF の CTO に就任されて、改めて開発組織のアップデートがされましたが、どういった背景でこの体制になったんでしょうか。
田中: 会社全体の組織設計として医療 PF と人材 PF に分かれたというのがまず最初にあったんですが、当初、開発組織は両 PF を横断する形で 1 人の CTO が見ていました。各 PF 内にそれぞれプロダクトがあり開発もプロダクトごとにチームを分けていましたが、それぞれの開発チームが有機的に動きつつも組織全体の小回りの効きやすさなども考えて、こうした体制になっていました。
ただ、時間が経つに連れ段々と開発チームも各 PF 自体 の規模も大きくなってきたので、 1 人の CTO ではマネジメントが難しくなってきました。また医療 PF と人材 PF で共通する開発組織の文化などはありますが、扱っている事業内容の差異から選定技術やプロジェクトの進め方などの違う部分も出てきたので、それぞれの PF で CTO を置いて組織面・技術面の課題に対応しようということになったためです。
稲本: 開発組織の人数としては 100 名を越えているのですが、それだけではなく就業場所の違いやサービスの多様化など、それぞれの PF で特性が違う課題がこれから先も出てくるだろうということで、先を見据えての開発組織のアップデートの一環として CTO 2 名体制にしたというところですね。
平木: これからの組織の変化を見据えた動きだということですね。
新しい開発体制になって変わっていく部分・変わらない部分
平木: 新体制になってまだ日が浅いですが、これから変えていく部分というのはどういったところになっていくんでしょうか。
稲本: 自分達 2 人が持っている色々な役割を分解していって他のメンバーへ役割を委譲していくことですね。CTO が色々持ちすぎると組織のスケールに対しボトルネックになることは目に見えているので。
それ以外には、役割を担ったチームやメンバーが自身で思考し行動しやすい組織にしていくことで、更なるチャレンジがしやすかったりパフォーマンスを発揮しやすい状態にしていけたらと考えています。
平木: なるほど。田中さんは何かありますか。
田中: 「役割の明確化」もその 1 つですが、将来取り組むべき課題に向けて中長期を見据えた開発組織の設計や運営に向き合うフェイズになってきたと感じており、強化していきたいと考えています。
平木: 将来の課題に対して技術・組織なども先手を打っていくイメージですね。
新体制での開発組織のミッション
平木: それでは新体制になって改めて開発組織のミッションとしてはどういったものがありますか。
田中: 会社全体のミッションと基本は一緒ではあります。「医療」という大きい領域の課題に対して、何のために開発をするのかや、その開発をすることによってどういった顧客価値を提供できるのかというところは、ちゃんとミッションに紐付いている部分なので変えずにいきます。
その上で、有効な施策をどれだけ素早くデリバリーできるかというところには今以上に注力していきたいところです。そのためには無駄を省き、やるべき事に集中してより生産性の高い開発を目指します。
プロダクト開発において無駄な機能開発を行なうと、後からそこを削ろうと思っても難しいですし、作った結果誰も幸せにならないということになってしまいます。こうならないためにもスピード感は落とさないで、事業側メンバーと協力しながら適切な要件整理をしたりなど、どうやって顧客へ適切なプロダクトを届けるか?という部分により重きを置いていきたいです。
事業とプロダクト開発の関係性
平木: さて、次に先程のお話にも出てきましたが、事業とプロダクト開発の関係性についてお聞きします。お二人が考えるこの関係性はどのようなものでしょうか。
田中: ここも以前から変わらないスタンスですが、改めて定義するなら「テクノロジーを最大限に使って医療領域の課題を解決する」という関係になります。テクノロジーとメドレーの事業である医療領域の課題解決という 2 つの側面のどれが欠けても、プロダクトとして良いものは生まれないと考えています。
平木: 主に Web のテクノロジーを適材適所で課題解決のために使っていくというスタンスですね。
田中: そうですね。先に来るのはあくまでも、「医療領域の課題解決をする」という部分になるのですが、その手段として必要な技術は全部使っていこうという姿勢です。なので、まずは開発組織のメンバー一人ひとりが、ドメインの理解をするということが始めの一歩です。そうして課題の本質を見極めて解決に必要な手段は何があるのかを考えていく必要が出てきます。
解決のために最適であれば、その技術の新旧や使用実績などを問わず取り入れて開発していくという心構えですね。そのためにはきちんと技術動向を追っていき日頃からユースケースなどを想像しながら、その技術を触ったりする必要も出てきます。
稲本: ドメイン知識とテクノロジーを最大限に駆使し、プロダクト開発を通して価値を届けるというのが我々のミッションなのかなと思います。
稲本さん
平木: 医療領域の未来を変えていくために、技術を最大限に用いたプロダクトドリブンであることが大切ということですね。
田中: メドレーではそれだけじゃない部分も意識していますね。一言で「プロダクト」と言ってもサービスとそれを作る開発者というだけではなく、顧客接点を持つ事業部などのメンバー全ての動きも合わせて「プロダクト」という意識を持っています。
平木: なるほど、プロダクトに関わっている人全員を合わせて「プロダクト」だよということですか。
田中: 例えば開発メンバーが良いプロダクトを提供したとしても、そのプロダクトを使ったユーザーが疑問に思った部分があったとします。そこで問い合わせをしたときに、その体験が良くない場合はやっぱり「プロダクトに関する体験が良くない」という印象になってしまいますよね。これはセールスなど他の領域でも起き得る話ですが、メドレーではそういった部分も含めて「プロダクト開発」という意識を持っているので、他部署だからということではなくトータルでユーザーに価値を感じてもらえるようにしていくということを大切にしています。
平木: 確かにユーザーはそういった関わるもの全部一緒に「プロダクト」と思いますもんね。
稲本: 日々の業務の中で直接ユーザーと対話してくれている方々がたくさんいます。
Our Essentials(以下、OE)で特に好きなものの一つで「信頼を獲得する」というものがあります。OE 自体は主に社内向けのメッセージにはなるんですが、日々の業務の中で他者からの信頼を得ることが出来るような振る舞いや成果を出すこと、その信頼の積み重ねがプロダクト全体にも反映され、結果としてユーザーからも信頼される/価値を感じてもらえるプロダクトの提供につながっているのだと感じています。
プロダクトと技術の関係について
平木: もう少し開発についての話を掘り下げていこうと思います。弊社では現在のところ Ruby や Ruby on Rails(以下 Rails)で作られているプロダクトが大半ではありますが、Go や Node.js などをメインに使っているプロダクトもありますよね。そうした技術選定のときの基本姿勢としてはどういったものがありますか。
田中: 基本として、「それぞれのプロダクトにとって現時点でこの技術で開発するのが、良いことだよね」というのを大切にしています。組織的に知見が多いということもあって、Rails を使っているプロダクトが多いのはそうなんですが、この技術じゃないとダメという縛りがあるわけではないです。Go や Node.js にしても、そのプロダクトに現状最適だという視点で技術選定をしています。
稲本: 今までできなかったことが、新しい技術を使ったら解決するのにという場面も結構あると思います。そういうときに「今使ってないから…」というのではなく、その技術を使ったほうがプロダクトにプラスになると判断したら使っていくようにしています。
田中: ですので、今プロダクトで使っている技術で守っていくというより、個々人でアンテナを張って新しい技術は積極的にキャッチアップしていきながら、チーム内で「これ使うと良さそうだからやっていこう」という感じですね。
平木: 先程も出てきたユーザーに価値提供を素早くするという要素の一つということですね。そうすると、例えば開発者体験を良くするような技術やフローなんかを取り入れるというのも、そうした志向の一部ということになりますか?
田中: そうですね。良いものを早くユーザーに届けるという一側面になります。開発者体験を良くするというのが最終的な目的ではなくて、その結果としてチームの生産性が上がるのなら体験を良くすると良いよねという。プロダクトコードの負債解消とかもそうですが、バランスが確かに難しいのですが、こういったところを疎かにすると結果として顧客への十分な価値提供ができなくなってしまうリスクもあるので、短期と中長期できちんとバランシングしつつ開発に取り組んでいきたいと思っています。
田中さん
平木: 改めてここで現在の開発体制について伺っていければと思います。
田中: 人材 PF も医療 PF もプロダクトに紐付いて複数のチームに分かれていて、チームの人数規模としてみると多少の上下はあるんですが、プロダクトマネージャ(以下、PdM) やデザイナー、エンジニアを合わせて 10 人前後というチームが多いです。
平木: そうしたチーム内で、特にエンジニアはどのような役割分担をしていることが多いですか?
稲本: もちろんチームによっても違ってくるんですが、チームの中に PM と TL を置いて、そのチームの中にメンバーが数人いる形が多いですね。この単位をベースにして toC 向けのプロジェクト、toB 向けのプロジェクトのような感じでチームを分けて開発を行なっています。
田中: メンバー個々人はサーバサイドやフロントエンド、インフラのような得意領域がありそこを考慮した開発をしていっていますが、サーバサイドだけやる人という形ではなく、得意領域と隣り合う領域についても意識し、可能な限り理解してコラボレーションしていこうというやり方を取っています。これによりコミュニケーションコストが下がることで生産性高く、品質向上にも寄与するというのが理由になります。
もちろんプロとして自分の得意分野で力を存分に発揮はしてもらうというのは大前提ですが、その強みを周囲のメンバーに還元しつつ、得意領域以外はそこが得意なメンバーから還元してもらいながら、良いプロダクトを作っていくというのがメドレーの開発組織のスタンスになります。
開発組織の雰囲気やメンバーの働き方について
平木: 今まで開発組織の制度的な側面を中心に聞いてきましたが、組織のソフト面についてお聞きします。メドレーの開発組織の雰囲気ですが、どんな雰囲気だったりしますか?
稲本: 全体的にはわりと和やかな雰囲気は持ちつつも、各自のバリューに対してはストイックな感じかなと思います。
自分たちで決めた期日など守るところはしっかり守ろうという意識を持ちつつ、無理な期日になりそうであればスケジュールやスコープを調整したり、プロジェクトの進め方で上手く行ったこと/行かなかったことを振り返りを通して改善を図ったりするなど、当たり前のことを高い水準でやり遂げていく習慣が根付いていると思います。
コミュニケーションに関しては、非同期コミュニケーションがベースではあります。口頭での相談なんかももちろんしますが、認識がずれないように話したことを issue などに残したりしてます。 雑談みたいなものはミーティングの後半パートにあえて雑談パートを作るなどしていますが、業務中にずっとするようなことはないですね。開発中はそれぞれが集中していることが多いです。
田中: チームごとに違いますが、朝会や夕会などでちゃんとコミュニケーションが取れるようにしているということが多いですね。なので、あんまり他の時間に雑談みたいなものが必要ないという感じです。
平木: 和やかながらも、締めるところは締めるという雰囲気ですね。開発チームの皆さんはどんな働き方をしている人が多いですか?
稲本: これも個々人で違っていますが出社とリモートのハイブリッドな方が多いかと思います。
やはり開発に集中したい場面ではリモートの方が割り込みも少なくなりやすく集中しやすいですし、物事の認識を揃えたり決めていく場合は、ミーティングなどで実際に顔を合わせた方が効率も良いことはあると思いますね。
田中: 自分のバリューを最大化できるように働いていこうというのが基本になっています。
平木: 各自ちゃんと考えてプロダクトに貢献できるようにということですね。そうした働き方の先にキャリアパスがあると思いますが、その観点ではどのようなパスがありますか?
田中: 大きく分けては、マネジメントをメインにするか、テクニカル部分を特化させたスペシャリストとなるかという 2 つになります。役割分担にもちょっと関わりますが、内容としては、例えば PdM を目指していくというのも道としてはありますし、自分の得意領域を最大限に伸ばしてテックリードとして技術をもってプロダクトを引っぱっていくという道なんかもあります。1on1 や評価などでそうした部分は本人と刷り合わせをしていきながら決めていく形になります。
平木: 評価のお話が出てきましたが、どういった観点で評価されますか?
稲本: ベースとしては会社として決めた OE に沿ったものになります。OE を踏まえつつ、業務目標や技術的な目標を立ててそれができたかどうかが基準になりますね。
立てた目標が色々な理由で達成できなかったというケースももちろん出てくると思いますが、内容として自分はどういった部分は頑張ったとか、どういう理由で達成できなかったなどの自分なりの説明ができるかというのを重視しています。
田中: 目標はチームバリューにいかに寄与したかを重視しています。OE に基づきチームとして達成しないといけない目標があってそれをブレイクダウンした上で、自分が寄与できるのはどこかという感じで目標にしてもらいます。一見目に見えにくい動きだったとしても、ちゃんとチームに貢献しているねとなれば、もちろん評価の対象になりますし、逆に例えばいくら頑張って新技術を習得したとなってもチームに貢献してなければ評価はされにくいです。
平木: ありがとうございます。最後にメドレーで開発することの良さを教えてもらえればと思います。
田中: メドレーは長期を見据えて課題に取り組んでいる会社であり、泥臭く地道に積み重ねなければいけないこともすごく多いです。そのため短期で結果が見えづらいこともあるかもしれません。ですが、医療領域でどっしりと腰を据えて長期的に本質を捉えた開発をしているため、技術面だけではなくプロダクトデザインとして何のために、どのようなアプローチが適切か、という思考力や設計能力も身に付きやすいのではないかと思います。
稲本: 長期で課題に取り組むとなると「同じことの繰り返しではないか」と感じる方もいるかもしれませんが、プロダクトが成長すればフェーズも変わりますし、取り組むことにも変化が生じていくので成長や変化を楽しめる人には合っているのではないかと思います。
さいごに
新体制で CTO 2 人にメドレーの開発組織について色々と語ってもらいました。
2 人も話をしていましたが、メドレーでは長期思考・未来志向の考え方をベースに、ユーザーの本質的な課題はなにか、どうすればそれらを解決できるか?という部分にフォーカスを当てて開発をするという志向がとても強いと思います。
そうした環境でじっくりと確実にユーザーに価値を提供できるという仕事だと思いますので、ご興味を持たれた方はぜひカジュアルにお話をさせていただければと思います!