ジョブメドレーのプロダクト開発サイクルについてまとめて聞いてみた
こんにちは、メドレーで人材プラットフォーム本部を統括している石崎です。
カジュアル面談などで「メドレーのプロダクト開発はどういう体制・流れでおこなっているのか」という質問をよくいただくので、開発サイクルの様子をまとめて note で公開することにしました。
話を聞いたのは人材プラットフォーム本部CTOの稲本さんです。
ジョブメドレーのプロダクト構成
──はじめに、稲本さんはメドレーでどんな仕事をしているんですか？
メドレーには人材プラットフォーム事業と医療プラットフォーム事業があります。私は人材プラットフォーム事業の開発責任者で、主に医療・福祉に特化したダイレクトリクルーティングサービス「ジョブメドレー」に関する開発をおこなっています。
──ジョブメドレーのプロダクト構成を教えてください。
基本的にはモノリシックなアプリケーションです。1つのソースコードで、求職者向けの「ジョブメドレー」、事業者向けの「採用管理画面」、社内向けの「管理画面」を管理しています。
バックエンドは Ruby on Rails、インフラは AWS で動いていて一部 GCP を使っています。動的な表現が多い画面のフロントは React + TypeScript を使っています。
──人材系だと SFA や CRM などで外部のサービスを使っている会社もありますが、すべて自社開発ですよね。
はい。ジョブメドレーは基本的に自社開発です。
メール配信では SendGrid を使ったり、SMS 配信でも外部サービスを使ったりしていますが、それらの機能を社内向けの管理画面を通して操作できる仕組みを作っています。
プロダクト開発の組織体制
──どのような体制でプロダクト開発をおこなっているんでしょうか。
組織図だとこんな感じです。
人材プラットフォーム本部にジョブメドレー事業部があるのですが、それと並列でプロダクト開発室があります。この中にエンジニアが所属する開発グループ、デザイナーのデザイングループ、プロダクトマネジャーが所属する企画グループがあります。
さらに隣の横断組織として、マーケティング室と事業企画室（なんでも屋チーム）があります。プロダクト開発の定例 MTG には、マーケやなんでも屋メンバーも参加しているので、このあたりまで含んで一緒にプロダクト成長に取り組んでいるイメージです。
開発グループは2022年からユニット体制を導入していて、クォーターごとに開発グループを Growth Unit と Customer Unit の2つに分けています。Growth Unit は主に仕事を探している求職者の利便性を高める施策に取り組んでいてい、Customer Unit は求人を掲載する顧客がつかう採用管理システムの改善がメインとなります。
──エンジニアの役割はフロントとバックエンドなどに分かれているんですか？
意図的にフロントとバックエンドに分けず、プロダクト全体に携わってもらうようにしています。
専門のチームを作るよりも、フロントもバックエンドもお互いの仕事の領域を相互に理解できるほうが、コミュニケーションコストも下がりますし大事なことだと思うんです。
──では特定の領域に特化したスペシャリストはあまり採用していない？
いえ、特定の領域に強い人の採用はしていますよ。でも「この領域しかやりたくない」というマインドの人はミスマッチになる可能性が高いので、正直にお伝えするようにしています。
プロダクト開発サイクル
──開発サイクルはどのように進めているのでしょうか。
前提として、メドレーは事業部ごとに事業部長とプロダクト責任者がいる二頭体制をとっていて、両者が対等の立場で事業をどう成長させていくかを話し合っています。また、ジョブメドレーにはそもそもなぜこのサービスが存在するのか、を記した「プロダクトプリンシプル」があります。
そのうえで、まずは次年度の予算策定をするタイミングで、プロダクト責任者が年間でやることを大まかに定めます。それを補助線として、クォーターごとに取り組む開発プロジェクトを、各ユニットや事業部長と相談しながらロードマップを決めていきます。事前にもらっている開発要望の優先度を整理しながら行う感じです。1つのクォーターが終わったら振り返りをして、また次のクォーターでやるべきことを決め、キックオフと懇親会をおこなう、という流れですね。
プロダクト開発全体の定例 MTG は毎週月曜におこなっています。各プロジェクトがロードマップどおりに進捗しているか確認したり、要件定義を確認してディスカッションしたり、意思決定が必要なものを決めています。何がなぜ決まったかが不透明にならないように、ドキュメントに残す運用にしています。
これに加えて、各プロジェクトが定例や朝会をそれぞれ実施しています。長期 → 年 → 四半期 → 週 → 日 と各単位でリズムをつくって開発サイクルをまわしています。
実際に、1つ1つの個々の施策を動かしていくときには、データドリブンで求職者と事業者に対する価値提供を優先して進めます。ただ、中には社内の効率化を図る施策もありますので、そういったときには、事業部長に意見やフィードバックをもらいながら進め方を決めていきます。
──やらなきゃいけないことってたくさんあると思うんですが、その中で「やる・やらない」の判断はどうしてますか？
仕事には “重要度はそこそこだけど早くやったほうが良いこと” と、“とても重要だけどすぐには効かないこと” がありますよね。例えば KPI がビハインドしているときには、早く効きそうな施策をやっていくことが多いです。
いっぽう、それだけだと短期かつ細かい改善施策ばかりになってしまうので、先々の事業成長のために今やっておくべきことも、必ず1つ以上は動かすようにしています。
──例えば、求職者や顧客と接している部門から「どうしてもこれをやってほしい」というお願いが差し込まれることはないですか？
あんまりないですね。営業やキャリアサポートやカスタマーサクセスなどの事業部門とは普段からコミュニケーションをとっているので、もらった意見を PM とクォーターに1回見直しながら、今やるべきことかを相談しています。
ここでの「やる・やらない」の判断基準は、“ユーザー・カスタマーのためになる施策かどうか” が大きいです。社内の業務効率化のみを図る施策は「今はやらない」という判断になりがちですが、社内の効率化を図った結果、求職者や顧客にも価値として提供できることであれば優先的に検討します。そのあたりのバランス感覚は大事にしていますね。
──なるほど。KPI の予算がエンジニアの目標になることもあるんですか？
予算とエンジニアの目標設定はあまり連動させないようにしていますね。
予算と目標設定を連動させると、“とにかく短期で売上が大きくなるような施策をやったもん勝ち” みたいな状況になってしまいかねないと思っています。それはエンジニアが本当に果たすべきことと乖離があると言いますか……。長期でプロダクトを成長させることを阻害しかねないなと。
結果として、目指している予算を達成することは大事なんですけど、1つ1つのプロジェクトを進めるうえでは “なぜ、なにを、いつまでに、だれが、どこで、どうやって”、ユーザーへ価値を提供できるか や、“計画通りに開発を進めるための工夫ができているか” などが大事かなと思っています。
──開発を進める中で、求職者や顧客の話を聞くことはあるんですか？
どちらもあります。求職者へのインタビューは半年に1回のペースで実施していて、実際にジョブメドレーを使って転職・就職した方に話を聞いています。顧客へのインタビューは営業に同行しておこなっています。
メドレーの特徴
──いろいろなインターネットサービス企業がある中で、稲本さんが思うメドレーの特徴って何でしょう。
プロダクト開発のプロセスそのものは、他社とそんなに変わらないかなと思います。一方で他社よりメドレーが優れているなと思う点は、情報がちゃんと蓄積されていることや、オンボーディングに対して情報が整理されていることですかね。
ジョブメドレーは10年以上の長い歴史を持つプロダクトですが、蓄積してきた情報をしっかり整理しているからこそ、必要な情報の解像度を上げやすい。これは今の開発チームの強みです。メドレーに入社した人が、早期にストレスなくキャッチアップできる土壌を作っています。
──オンボーディングプログラムみたいなものはあるんですか？
プログラムと呼べるほど体系化したものではないですが、ジョブメドレーに関わるうえでの基礎知識をベースに、入社した人のこれまでの経験を踏まえて1〜3ヶ月で任せる業務の内容を明確にしています。
あとは、入社した人の「こんなことがしたい」という期待値と、私の「こんなことをしてほしい」という期待値の調整を、月単位でしっかりやっていくことも大切にしています。
プロダクトチームの働き方
──プロダクト開発室はどんな働き方をしているんですか？
ジョブメドレーの開発は月曜・金曜が出社、そのほかは出社・リモートを選択可能にしています。
──フルリモートではないんですね。
同期的なコミュニケーション・非同期的なコミュニケーション、どちらも大事だと考えています。それぞれをうまく使い分けられるように、出社する日とリモートの日を設けています。
業務に没頭する時間を作って、しっかり集中してアウトプットを作ることも大切ですが、対面で同期的なコミュニケーションをとることも、同じサービスに関わっている他部署がなにをやっているか把握することも大事だと考えているので。
──業務に没頭するようなリモートの日でも、オンラインでコミュニケーションを取るような場を設けていたりするんですか？
そうですね。大きいプロジェクトのときには1日30分くらいの雑談タイムを作っています。あとは最近入社した人も多いので、お互いのスキルの強み弱みを可視化して、会話しながら相互理解を深めたり、チームとして強化すべき部分を洗い出したりすることもあります。
例えば、お互いに得意としているスキルやドメイン知識を可視化して、偏りがあれば新たに理解を深めやすい業務へ取り掛かったり、得意な人を見えるようにしてフォローを出来るようにしています。
現在取り掛かっている業務と予定を可視化してお互いに取り組んでいることを非同期でも理解できるようにしたり、
リアーキテクト方針を見えるようにしたりすることで担当者が考えていることを他の人が理解しやすいようにしています。
方針や設計については、あくまで途中経過のものにはなるので、ラフに内容を整理し論点の整理や方針が決定したら最終的にはドキュメントに落とし込んでいく、ということをしています。
──プロダクト開発室にはどんな雰囲気の人が多いですか？
平均年齢は27〜30歳ですが、大人な人が多いですね。これは地に足を着けて、成果に向けて着実に仕事をしてくれそうな人が入社してくれているからだと思います。
「技術の探求にしか興味がない」って人だと、どうしてもプロダクトとして果たすことのベクトルと合わなくなって、お互い苦しい状況になってしまうので。“技術をもって何をしたいか”のベクトルが合っている人に入社してもらっています。
──ほかに在籍メンバーに共通していることはありますか？
メドレーの“社会課題を解決する”というミッションに共感してくれていることと、良い意味で技術を手段と捉えて仕事に取り組んでいることですね。前職で医療ヘルスケアに関わったことが無い人も多くいます。
メドレーに入社して「自分が世に出したものが誰かの課題を解決していると実感しやすい」「納得感を持って取り組みやすい」という声もよく聞きます。
──なるほど。採用面接をしていると「前の職場は、みんなが思い思いのことを言うから開発の方向性がバラバラで、プロジェクトが進みづらかった」という話も聞きます。メドレーはどうでしょう。
ジョブメドレーではユニット単位でやるべきことがある程度決まっているのと、企画を考える PM が俯瞰的に物事を考えてチームをまとめられる人なので、そういったことは解消できているんじゃないでしょうか。
あとはマーケティング室など非エンジニアでも BigQuery を頻繁に活用していて、データドリブンで物事を判断することが多いため、割とみんなが同じ方向を目指しやすいのかなと思います。
これから挑戦したいこと
──これからアップデートしていきたいことは何ですか？
人材プラットフォーム事業全体としては、医療従事者の採用課題以外のところにも対応していきたいです。昨年から「ジョブメドレーアカデミー」というオンライン研修サービスがはじまっていますし、今後も新たな機能・サービスを提供していきます。
個人としては、自分以外のメンバーが判断・意思決定できる範囲を明確にしていきたいと思っています。プロダクト開発室のメンバーが、どんどんプロダクトを牽引していけるようにしていきたい。
そのためにも一人ひとりが成長できる機会を作りつつ、今後の事業拡大の軸となるメンバーを増やしていくことが私のミッションだと思っています。
──稲本さんは具体的にどんな人に判断や意思決定を任せたいと思いますか？
精神的なところで言うと前向きに取り組む人。「この人になら任せても大丈夫そう」と思えるくらい、プロダクト全体にコミットしてくれる人ですね。
でも初対面ではわからない部分もあるので、一緒に働いてみて理解していけたらと思います。
──例えば何かのスキルを持っていることなどは、あまり重要ではない？
プロダクトの成長を担ってもらうことになるので、実現するためのスキルは勿論重要ですが、物事を多面的に捉えられる──多くの求職者や事業者のためになること、定量的・定性的にロジカルに考えられることも同様に重要だと考えています。
今回ご紹介したプロダクト開発の体制やサイクルは完成しているものではなく、今後もどんどんアップデートしていくことになると思います。大事なのは、チームとして同じ方向を向いて納得感を持ちながら、ちゃんとユーザー・カスタマーが使ってくれるサービスを提供することに変わりはありません。
「ここって具体的にはどうなってるんですか？」「こういう場合はどうしてますか？」など、もっと突っ込んだ話も聞いてみたい方は、ぜひ一度お話しましょう。
※写真は感染対策に配慮しながら撮影しています。