はじめに みなさん、こんにちは。技術広報・エンジニアの平木です。 既に 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 人も話をしていましたが、メドレーでは長期思考・未来志向の考え方をベースに、ユーザーの本質的な課題はなにか、どうすればそれらを解決できるか?という部分にフォーカスを当てて開発をするという志向がとても強いと思います。 そうした環境でじっくりと確実にユーザーに価値を提供できるという仕事だと思いますので、ご興味を持たれた方はぜひカジュアルにお話をさせていただければと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。技術広報・エンジニアの平木です。 既に 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 人も話をしていましたが、メドレーでは長期思考・未来志向の考え方をベースに、ユーザーの本質的な課題はなにか、どうすればそれらを解決できるか?という部分にフォーカスを当てて開発をするという志向がとても強いと思います。 そうした環境でじっくりと確実にユーザーに価値を提供できるという仕事だと思いますので、ご興味を持たれた方はぜひカジュアルにお話をさせていただければと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。技術広報・エンジニアの平木です。 既に 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 人も話をしていましたが、メドレーでは長期思考・未来志向の考え方をベースに、ユーザーの本質的な課題はなにか、どうすればそれらを解決できるか?という部分にフォーカスを当てて開発をするという志向がとても強いと思います。 そうした環境でじっくりと確実にユーザーに価値を提供できるという仕事だと思いますので、ご興味を持たれた方はぜひカジュアルにお話をさせていただければと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。技術広報・エンジニアの平木です。 既に 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 人も話をしていましたが、メドレーでは長期思考・未来志向の考え方をベースに、ユーザーの本質的な課題はなにか、どうすればそれらを解決できるか?という部分にフォーカスを当てて開発をするという志向がとても強いと思います。 そうした環境でじっくりと確実にユーザーに価値を提供できるという仕事だと思いますので、ご興味を持たれた方はぜひカジュアルにお話をさせていただければと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療プラットフォーム第一本部プロダクト開発室所属エンジニアの髙橋です。 普段の業務では、 医療 SaaS プラットフォーム CLINICS の医療機関向けアプリケーション（以下、CLINICS）の開発を担当しています。 CLINICS では、昨年 10 月頃から React コードベースのリアーキテクチャに取り組んでいます。 その取り組みの 1 つとして、非同期状態管理に関連する実装を Tanstack Query を使って刷新しています。 この記事では、CLINICS における Tanstack Query の活用方法を導入背景と狙いを含めて紹介します。 目次 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Tanstack Query について Tanstack Query を活用したフロントエンドアーキテクチャ Resource Operation の実装 ディレクトリ構成 cache.ts queries.ts mutations.ts ViewModel の実装 ディレクトリ構成 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 狙い 1：Tanstack Query の導入による開発体験の向上 狙い 2：シンプルなレイヤー分割による学習容易性の向上 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 まとめ さいごに Tanstack Query について Tanstack Query は、Web アプリケーションのサーバ状態の取得、キャッシュ、同期、更新を簡単に行うことができるライブラリです。 1 類似ライブラリには SWR、Apollo Client、RTK Query 等が挙げられます。 2 私たちは、機能性・ドキュメントの充実度・コミュニティの将来性を総合的に判断した結果、Tanstack Query(React Query)を採用して React コードベースの再構築を進めています。 導入背景の詳細は、後のセクションで詳しく紹介します。 Tanstack Query を活用したフロントエンドアーキテクチャ それでは本題の Tanstack Query を活用したフロントエンドアーキテクチャについて紹介します。 始めに、アーキテクチャの全体像を示した次の図をご覧ください。 まず注目して頂きたいポイントは、Backend と View の間にある Resource Operation です。 Resource Operation は Tanstack Query を主軸に実装されているレイヤーです。 役割を大きく分類すると次の 2 つが挙げられます。 非同期状態管理に関連する実装の集約 Backend で扱うデータ(OpenAPI スキーマ)と View で扱うデータ(ViewModel)の相互変換 全体像を把握するために、左右のレイヤーにも注目してください。 右の Backend は CLINICS では Ruby on Rails で実装された REST API を提供するモノリシックなサーバです。 API で扱うスキーマは OpenAPI を使って定義しています。 OpenAPI スキーマは、 committee-rails を使ったレスポンス検証と、 openapi-generator を使った API クライアントコードの自動生成に活用しています。 左の View は CLINICS では React で実装されたコンポーネントになります。 View では Backend の OpenAPI スキーマを直接参照することを避け、 ViewModel と呼ばれるフロントエンドで定義したモデル 3 のみを参照する設計としています。 Resource Operation は View と Backend の境界レイヤーとして非同期状態管理とデータの相互変換を行うシンプルなレイヤーとなっています。 続いて、上記の運用のための実装詳細を紹介します。 Resource Operation の実装 ディレクトリ構成 Resource Operation レイヤーでは、リソースごとに非同期状態管理とデータの相互変換の処理をまとめています。 ディレクトリツリーで Resource Operation レイヤー全体を表現すると次のようになります。 src/resourceOperations ├── resourceTagName # 例： todo │ ├── cache.ts │ ├── mutations.ts │ └── queries.ts └── resourceGroupTagName # 例： systemSettings（リソースに階層がある場合） └── resourceTagName # 例： organization（リソースグループ配下のリソース） ├── cache.ts ├── mutations.ts └── queries.ts ディレクトリ名の resourceTagName と resourceGroupTagName は OpenAPI スキーマでエンドポイントごとに割り振られている tag を元に命名しています。 ディレクトリごとに 次の 3 つのファイルを定義しています。 ファイル 役割 cache.ts Query Key の定義、キャッシュ操作のためのカスタムフックの定義 queries.ts useQuery をラップしたカスタムフックの定義、API Request/Response の整形 mutations.ts useMutation をラップしたカスタムフックの定義、API Request の整形 cache.ts cache.ts は次のように実装しています。 // ① Query Key // queries.ts がある場合に必要に応じて宣言 export const todoKeys = { all: [ "todo" ] as const , list : () => [... todoKeys . all , "list" ] as const , paginateList : ( page ?: number ) => [... todoKeys . list (), { page }] as const , detail : ( id : string ) => [... todoKeys . all , "detail" , id ] as const , }; // ② キャッシュ操作のためのカスタムフック // mutations.ts がある場合に必要に応じて宣言 export function useTodoCache () { const queryClient = useQueryClient (); return useMemo ( () => ({ invalidateList : () => queryClient . invalidateQueries ( todoKeys . list ()), invalidateDetail : ( id : string ) => queryClient . invalidateQueries ( todoKeys . detail ( id )), }), [ queryClient ] ); } ① Query Key は、 useQuery の queryKey オプションに与える値を定義した定数です。これは後述の queries.ts で利用します。 実装は Tanstack Query メンテナの Dominik さんのブログで紹介されている Query Key factories パターンを使っています。 ディレクトリ名を all の値とすることで、大規模なアプリケーションにおいてもキーの衝突を防ぐことが可能です。 ② キャッシュ操作のためのカスタムフックでは QueryClient を利用したキャッシュ操作をまとめています。これは後述の mutations.ts で利用します。 CLINICS では 楽観的更新 をしない方針としているため、 invalidateQueries を実行する関数群のみを定義しています。 queries.ts queries.ts は次のように実装しています。 import { type Todo } from "@/viewModels/todo" ; import { todoApi , type GetTodoDetailRequest } from "@/api/generated" ; // ③ queryFn export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); return data . todoList ; }, getTodoDetail : async ( request : GetTodoDetailRequest ): Promise &#x3C; Todo > => { const { data } = await todoApi . getTodoDetail ( request ); return data . todo ; }, }; // ④ Request Selector export const request = { getTodoDetail : ( id : string | undefined ): GetTodoDetailRequest => { if ( id === undefined ) { // `enabled: false` となる条件の引数が与えられた場合例外とすることで、 // queryFn 内の型の整合性を保つ throw new InvalidRequestParameterError ( "Required parameter id was undefined when calling request.getTodoDetail." ); } return { id , }; }, }; ③ queryFn は、API へのリクエストを責務とした関数群です。 ここで使用している ApiClient や Request の型は openapi-generator から生成しています。 queryFn の戻り値の型は、後述の ViewModel で定義した型を明示 しています。 このようにフロントエンド側でサーバステートの型を別途定義することで、フロントエンドとバックエンドを分業して実装する際に開発しやすくなるメリットがあります。 省略していますが、レスポンスに応じたエラーの throw もここで行います。 ④ Request Selector は View から受け取った値をリクエストパラメータへマッピングすることを責務とした関数群です。 useQuery の条件付き実行を制御する enabled オプションで false となる条件を例外とすることで、queryFn 内で 型ガードをしなくて良い設計としています。 これらを使って View とのインターフェースとなる useQuery ラッパーを定義します。 // ⑤ Base Query // API Response を整形せずに返す export type UseTodoDetailQueryProps &#x3C; QueryResult > = { id : string | undefined ; select ?: ( data : Todo ) => QueryResult ; }; export function useTodoDetailQuery &#x3C; QueryResult = Todo >( props : UseTodoDetailQueryProps &#x3C; QueryResult > ) { return useQuery ({ queryKey: todoKeys . detail ( props . id ), queryFn : () => { return query . getTodoDetail ( request . getTodoDetail ( props . id )); }, enabled: !! props . id , select: props . select , useErrorBoundary: true , }); } import { selectTodoForm } from "@/viewModels/todo/todoForm" ; // ⑥ Selector Query // API Response を View で参照したいフォーマットに整形して返す export function useInitialTodoFormQuery () { // Base Query に select オプションを与える return useTodoDetailQuery ({ select: selectTodoForm , // selectTodoForm は Todo を TodoForm に変換する ViewModel Selector（後述） }); } useQuery ラッパーは、⑤ Base Query と ⑥ Selector Query に分けて定義しています。 CLINICS では同じデータソースに対して画面ごとに異なるフォーマットで表示することが多くあります。 Selector Query で 任意のフォーマットに整形することで、画面ごとに最適化されたデータの取得をスケーラブルに実現しています。 4 加えて、この手法では Selector にドメインロジックが凝集されるため、 Selector を重点的にテストすることで品質を担保しやすい メリットがあります。 Query のエラー制御は useErrorBoundary オプションを使って Error Boundary を表示する方針としています。 mutations.ts mutations.ts は次のように実装しています。 import { type TodoForm } from "@/viewModels/todo/todoForm" ; import { todoApi , type PostTodoRequest } "@/api/generated" ; // ⑦ mutationFn export const mutation = { createTodo : ( request : PostTodoRequest ) => { return todoApi . postTodo ( request ); }, }; // ⑧ Request Selector // ViewModel から API Request へ変換する export const request = { createTodo : ( todoForm : TodoForm ): PostTodoRequest => { return { PostTodoRequest : { todo : { title : todoForm . title , description : todoForm . description , status : todoForm . status , favorite : todoForm . favorite === "true" ? true : false , }, }, }; }, }; // ⑨ Custom Mutation export function useCreateTodoMutation () { const { invalidateList } = useTodoCache (); return useMutation ({ mutationFn : ( todoForm : TodoForm ) => { return mutation . createTodo ( request . createTodo ( todoForm )); }, onSuccess : () => { return invalidateList (); }, }); } 基本的な構成は queries.ts と同じです。 mutations.ts でも queries.ts と同様に ⑧ Request Selector を定義します。 Request Selector には、データ整形を扱うためドメインロジックが集まりやすいです。 そのため、入出力、境界値、例外のテストを積極的に書いて品質の担保に繋げています。 Mutation のエラーは画面ごとに UI でフィードバックするため、コンポーネント側で制御しています。 Resource Operation レイヤーに関する実装の紹介は以上です。 ViewModel の実装 ViewModel とは、View(React Component) で扱うデータのスキーマと型です。 Resource Operation の実装では、API Response を ViewModel に整形して View に提供することを紹介しました。 全体の理解を深めるため、ViewModel の実装も紹介します。 ディレクトリ構成 ViewModel は関心を分離するため Resource Operation とは別のディレクトリに定義しています。 src/viewModels └── todo ├── todo.ts # サーバステート ├── todoForm.test.ts # フロントエンドに閉じたスキーマのテスト ├── todoForm.ts # フロントエンドに閉じたスキーマ └── todoSearchCondition.ts # フロントエンドに閉じた型 ViewModel で定義するスキーマ・型は大きく分けて 3 つに分類されます。 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 サーバステート サーバステートは、 API Response として期待するデータのスキーマ及び型です。 前述の queries.ts 内の ③ queryFn で使用します。 zod を使って次のように実装しています。 // src/viewModels/todo/todo.ts // enum は View で &#x3C;option value={todoStatus.enum.ready} /> のように使用する export const todoStatus = z . enum ([ "ready" , "doing" , "done" ]); // ⑩ サーバステートのスキーマ // 開発中のみ ③ queryFn 内で API Response を parse することで、スキーマの不整合を検出するための補助輪として使用する export const todo = z . object ({ id: z . string (), title: z . string (), description: z . string (). nullable (), status: todoStatus , favorite: z . boolean (), }); // ⑪ サーバステートの型 // ③ queryFn の戻り値の型として使用する export type Todo = z . infer &#x3C; typeof todo >; ⑩ サーバステートのスキーマは、⑪ サーバステートの型の生成と開発時のスキーマ検証に使用しています。 開発時のみ API Response を検証することで、⑩ サーバステートのスキーマと Open API スキーマの整合性を確認しています。 // src/resourceOperations/todo/queries.ts import { todo , type Todo } from "@/viewModels/todo" ; export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); // 開発時、APIとの結合タイミングで検証してフロントエンドとバックエンドでスキーマの齟齬がないことを確認する // 検証が済んだら parse 処理を外す return data . todoList . map (( x ) => todo . parse ( x )); }, }; 例外として、 外部サービスから取得したデータに関しては常にサーバステートのスキーマを使って検証 しています。 例えば、外部サービスの仕様として長さが 1 以上の配列が返ってくると決まっていて、フロントエンド側もその仕様に基づいた処理を実装している場合、 z.array().min(1) のスキーマで常に検証します。 ネットワークに近い箇所で不正なデータを検出することで、例外発生時の調査を容易にするメリットがあると考えています。 フロントエンドに閉じたスキーマ フロントエンドに閉じたスキーマは、そのほとんどがフォームのバリデーションスキーマです。 こちらも zod を使って定義しています。 // src/viewModels/todo/todoForm.ts import { type Todo , todo } from "./todo" ; // フロントエンドに閉じたスキーマ // フォームのスキーマは react-hook-form と連携して使用する（省略） export const todoForm = z . object ({ title: z . string () . min ( 1 , "入力してください" ) . max ( 200 , "200字以内で入力してください" ), description: z . string (). max ( 500 , "500字以内で入力してください" ), status: todo . shape . status , favorite: z . union ([ z . literal ( "true" ), z . literal ( "false" )]), }); export type TodoForm = z . infer &#x3C; typeof todoForm >; // ⑫ ViewModel Selector // サーバステートからフロントエンドに閉じたスキーマへ変換する // 前述の queries.ts 内 ⑥ Selector Query で使用する export function selectTodoForm ( todo : Todo ): TodoForm { return { title: todo . title , description: todo . description ?? "" , status: todo . status , favorite: todo . favorite ? "true" : "false" , }; } フロントエンドに閉じたスキーマは、必ずサーバステートを元に生成する運用としています。 そのために、フロントエンドに閉じたスキーマを宣言した直下に、サーバステートからフロントエンドに閉じたスキーマへ変換する ⑫ ViewModel Selector を定義します。 null の 空文字への変換や時間データのフォーマットのような、 サーバステート と View で使う値の差分吸収はこのセレクタ内で行います。 このように、 ViewModel レイヤーでは他のレイヤーと依存しないようにドメインロジックを表現 しています。 ドメインロジックを Tanstack Query に依存しないことで、今後技術基盤を刷新する場合でも影響を最小限に留めることを狙いとしています。 フロントエンドに閉じた型 依存関係を整えるため、Resource Operation と View から参照するフロントエンドに閉じた型は viewModels 配下に宣言しています。 // src/viewModels/todo/todoSearchParams.ts export type TodoSearchCondition = { sort ?: "created_at_asc" | "created_at_desc" ; }; ViewModel に関する実装の紹介は以上です。 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 Tanstack Query を導入する以前の CLINICS の非同期処理周辺のコードベースではいくつかの課題がありました。 開発体験の課題 非同期処理のためのミニマムな基盤フックを独自に実装していた 5 ことにより、開発体験の観点で次のような課題がありました。 新しい要件（ポーリング・無限読み込み等）が発生した際に、最初に担当する開発者が都度機能拡張する必要がある テストが実装されていなかったため変更時に品質確認の負担が大きい 学習容易性の課題 上述の基盤フックにドキュメントがなかったため、学習容易性の観点で次のような課題がありました。 基盤フックにドキュメントがなく、新規メンバーの学習コストが高い 様々な実装手法が混在することで、実装時に迷いが生じている 可読性の課題 CLINICS は開発開始から約 7 年以上が経過しています。 その中でもフロントエンドは技術トレンドの変化が早いため、様々なライブラリやパターンを使って実装されています。 特に近年から漸進的に導入した React を使った実装については、明確な設計が確立されていませんでした。 これらの背景からチームで安定したアウトプットを出すことが困難で、可読性の観点で次のような課題がありました。 画面によってフックや関数の粒度、定義場所が違うことでコードリーディングの負荷が高い コードレビュー時のレビュワーの負担が大きい テスト容易性の課題 多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、テスト容易性の観点で次のような課題がありました。 テストが実装しづらい テストカバレッジが低い CLINICS はオンライン診療・電子カルテ等の医療機関業務を支える機能を提供する SaaS プラットフォームです。 今後長きに渡って多くの医療機関の方々に CLINICS を利用して頂くためには、 コードを読みやすく、変更しやすく、維持しやすい状態に保ち続けること が重要です。 前の章で紹介したアーキテクチャは 持続可能な開発を目指して 設計しました。 具体的には、 開発体験・学習容易性・可読性・テスト容易性を向上することを狙い としています。 狙い 1：Tanstack Query の導入による開発体験の向上 背景で説明したとおり、Tanstack Query 導入以前は独自実装したフックを使って非同期処理を実装していました。 Tanstack Query を導入したきっかけは、チーム内での雑談の中で、独自実装のフックが使いづらいという声が挙がったことです。 そこで、独自実装のフック自体の質を高めるか、質の高いライブラリを導入するかを議論した結果、次の理由でライブラリを導入する決定をしました。 極力自分たちでコードを書かずに非同期処理・状態管理の実装を実現したい 実装に困ったときにドキュメントを読めば解決する環境にしたい CLINICS では技術的な背景 6 から Tanstack Query と SWR が候補に上がりましたが、 select オプションや invalidateQueries の Partial Query Matching 等の機能性と、ドキュメントの充実度合いの観点から Tanstack Query を採用しました。 Tanstack Query を採用したことで、 非同期処理のためのコードの記述量が大幅に削減 されたほか、データの特性に応じて Query ごとにキャッシュの時間を調整することが可能となり開発体験が大幅に向上しました。 狙い 2：シンプルなレイヤー分割による学習容易性の向上 CLINICS では、事業の拡大にともないコードベースに関わるエンジニアが増え続けています。 実装の進め方はプロジェクトによって最適な形式を選択しています。 バックエンドからフロントエンドまで一気通貫で実装 技術領域に分けて分業 このように多くのエンジニアが様々な形で関わる環境では、コードベースの学習容易性を高め、実装からコードレビューの完了までをスムーズに行えることが重要です。 前の章で紹介したアーキテクチャは、 レイヤー分割をシンプルにすることでコードベースに慣れるまでの時間を最小限にする ことを意識しています。 加えて、 実装パターンを定形化することで、コードベースに馴染みがなくても迷いなく実装できる ほか、関数の粒度が統一されることで、コードレビューの負荷軽減にも繋がっています。 レイヤー分割の粒度や実装パターンについては、次の記事を参考にさせて頂きました。 フロントエンドアーキテクチャの話: Resource Set の紹介 ほかにも CLINICS では学習容易性の向上の取り組みとして、 新しいライブラリやアーキテクチャを導入した際は勉強会を開催 してライブラリの基本的な使い方や頻出の実装パターンに関する知見を共有しています。 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 アーキテクチャを刷新する以前は、多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、可読性やテスト容易性に支障をきたしていました。 CLINICS のフロントエンドには、医療システムに関する複雑なドメインロジックが多いため、 シンプルでテストしやすいコードベース を作っていくことがとりわけ重要だと考えています。 この課題は、ドメインロジックが集まる傾向にある queries.ts、 mutations.ts の Request Selector や ViewModel Selector の実装を定型化し、純粋関数で表現することにより解決しました。 まとめ Tanstack Query を使ったフロントエンドアーキテクチャの実例を紹介しました。 Resource Operation レイヤーに Tanstack Query の実装を定型化して集約しています。 レイヤー分割をシンプルにし、実装を定型化することで、開発組織のスケールに対応しています。 useQuery の select オプションを使い、スケーラブルにデータ変換処理を記述しています。 データ変換処理にはドメインロジックが集まりやすいため、なるべく小さい粒度の純粋関数で表現することで、可読性・テスト容易性の向上を狙っています。 この記事の内容が Tanstack Query の導入を考えている方の参考になれば幸いです。 さいごに CLINICS では、機能開発と並行してフロントエンド基盤を改善する取り組みも実施しています。 Redux から Tanstack Query への移行 UI ライブラリの Mithril から React への移行 7 デザインシステムの構築とプロダクトへの反映 このような取り組みに興味がある方は次のリンクから是非ご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp Footnotes Overview | TanStack Query Docs ↩ Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router | TanStack Query Docs ↩ この記事で紹介している ViewModel は View レイヤー専用のモデルを表す概念です。 MVVM アーキテクチャの ViewModel とは異なります。 ↩ Tanstack Query におけるデータ変換手法の詳細は React Query Data Transformations | TkDodo’s blog で紹介されています。 ↩ Tanstack Query 導入以前の非同期処理は useAsync React Hook - useHooks をカスタマイズしたフックを使って実装していました。 ↩ CLINICS では 一部の実装箇所で Redux を使用していますが、 RTK Query は今回採用するライブラリの候補から除外しました。これは、現在使用している Redux のバージョンが低く、レガシーな周辺ライブラリも複数使用している背景で Redux Toolkit への移行に相当な工数を必要とするためです。 ↩ 2023 年 3 月現在、 CLINICS のフロントエンドの 約 50% は、 Mithril と Redux で構成されています。開発体験の向上のため、 React への完全移行を目指して日々改善を続けています。 ↩

こんにちは。医療プラットフォーム第一本部プロダクト開発室所属エンジニアの髙橋です。 普段の業務では、 医療 SaaS プラットフォーム CLINICS の医療機関向けアプリケーション（以下、CLINICS）の開発を担当しています。 CLINICS では、昨年 10 月頃から React コードベースのリアーキテクチャに取り組んでいます。 その取り組みの 1 つとして、非同期状態管理に関連する実装を Tanstack Query を使って刷新しています。 この記事では、CLINICS における Tanstack Query の活用方法を導入背景と狙いを含めて紹介します。 目次 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Tanstack Query について Tanstack Query を活用したフロントエンドアーキテクチャ Resource Operation の実装 ディレクトリ構成 cache.ts queries.ts mutations.ts ViewModel の実装 ディレクトリ構成 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 狙い 1：Tanstack Query の導入による開発体験の向上 狙い 2：シンプルなレイヤー分割による学習容易性の向上 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 まとめ さいごに Tanstack Query について Tanstack Query は、Web アプリケーションのサーバ状態の取得、キャッシュ、同期、更新を簡単に行うことができるライブラリです。 1 類似ライブラリには SWR、Apollo Client、RTK Query 等が挙げられます。 2 私たちは、機能性・ドキュメントの充実度・コミュニティの将来性を総合的に判断した結果、Tanstack Query(React Query)を採用して React コードベースの再構築を進めています。 導入背景の詳細は、後のセクションで詳しく紹介します。 Tanstack Query を活用したフロントエンドアーキテクチャ それでは本題の Tanstack Query を活用したフロントエンドアーキテクチャについて紹介します。 始めに、アーキテクチャの全体像を示した次の図をご覧ください。 まず注目して頂きたいポイントは、Backend と View の間にある Resource Operation です。 Resource Operation は Tanstack Query を主軸に実装されているレイヤーです。 役割を大きく分類すると次の 2 つが挙げられます。 非同期状態管理に関連する実装の集約 Backend で扱うデータ(OpenAPI スキーマ)と View で扱うデータ(ViewModel)の相互変換 全体像を把握するために、左右のレイヤーにも注目してください。 右の Backend は CLINICS では Ruby on Rails で実装された REST API を提供するモノリシックなサーバです。 API で扱うスキーマは OpenAPI を使って定義しています。 OpenAPI スキーマは、 committee-rails を使ったレスポンス検証と、 openapi-generator を使った API クライアントコードの自動生成に活用しています。 左の View は CLINICS では React で実装されたコンポーネントになります。 View では Backend の OpenAPI スキーマを直接参照することを避け、 ViewModel と呼ばれるフロントエンドで定義したモデル 3 のみを参照する設計としています。 Resource Operation は View と Backend の境界レイヤーとして非同期状態管理とデータの相互変換を行うシンプルなレイヤーとなっています。 続いて、上記の運用のための実装詳細を紹介します。 Resource Operation の実装 ディレクトリ構成 Resource Operation レイヤーでは、リソースごとに非同期状態管理とデータの相互変換の処理をまとめています。 ディレクトリツリーで Resource Operation レイヤー全体を表現すると次のようになります。 src/resourceOperations ├── resourceTagName # 例： todo │ ├── cache.ts │ ├── mutations.ts │ └── queries.ts └── resourceGroupTagName # 例： systemSettings（リソースに階層がある場合） └── resourceTagName # 例： organization（リソースグループ配下のリソース） ├── cache.ts ├── mutations.ts └── queries.ts ディレクトリ名の resourceTagName と resourceGroupTagName は OpenAPI スキーマでエンドポイントごとに割り振られている tag を元に命名しています。 ディレクトリごとに 次の 3 つのファイルを定義しています。 ファイル 役割 cache.ts Query Key の定義、キャッシュ操作のためのカスタムフックの定義 queries.ts useQuery をラップしたカスタムフックの定義、API Request/Response の整形 mutations.ts useMutation をラップしたカスタムフックの定義、API Request の整形 cache.ts cache.ts は次のように実装しています。 // ① Query Key // queries.ts がある場合に必要に応じて宣言 export const todoKeys = { all: [ "todo" ] as const , list : () => [... todoKeys . all , "list" ] as const , paginateList : ( page ?: number ) => [... todoKeys . list (), { page }] as const , detail : ( id : string ) => [... todoKeys . all , "detail" , id ] as const , }; // ② キャッシュ操作のためのカスタムフック // mutations.ts がある場合に必要に応じて宣言 export function useTodoCache () { const queryClient = useQueryClient (); return useMemo ( () => ({ invalidateList : () => queryClient . invalidateQueries ( todoKeys . list ()), invalidateDetail : ( id : string ) => queryClient . invalidateQueries ( todoKeys . detail ( id )), }), [ queryClient ] ); } ① Query Key は、 useQuery の queryKey オプションに与える値を定義した定数です。これは後述の queries.ts で利用します。 実装は Tanstack Query メンテナの Dominik さんのブログで紹介されている Query Key factories パターンを使っています。 ディレクトリ名を all の値とすることで、大規模なアプリケーションにおいてもキーの衝突を防ぐことが可能です。 ② キャッシュ操作のためのカスタムフックでは QueryClient を利用したキャッシュ操作をまとめています。これは後述の mutations.ts で利用します。 CLINICS では 楽観的更新 をしない方針としているため、 invalidateQueries を実行する関数群のみを定義しています。 queries.ts queries.ts は次のように実装しています。 import { type Todo } from "@/viewModels/todo" ; import { todoApi , type GetTodoDetailRequest } from "@/api/generated" ; // ③ queryFn export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); return data . todoList ; }, getTodoDetail : async ( request : GetTodoDetailRequest ): Promise &#x3C; Todo > => { const { data } = await todoApi . getTodoDetail ( request ); return data . todo ; }, }; // ④ Request Selector export const request = { getTodoDetail : ( id : string | undefined ): GetTodoDetailRequest => { if ( id === undefined ) { // `enabled: false` となる条件の引数が与えられた場合例外とすることで、 // queryFn 内の型の整合性を保つ throw new InvalidRequestParameterError ( "Required parameter id was undefined when calling request.getTodoDetail." ); } return { id , }; }, }; ③ queryFn は、API へのリクエストを責務とした関数群です。 ここで使用している ApiClient や Request の型は openapi-generator から生成しています。 queryFn の戻り値の型は、後述の ViewModel で定義した型を明示 しています。 このようにフロントエンド側でサーバステートの型を別途定義することで、フロントエンドとバックエンドを分業して実装する際に開発しやすくなるメリットがあります。 省略していますが、レスポンスに応じたエラーの throw もここで行います。 ④ Request Selector は View から受け取った値をリクエストパラメータへマッピングすることを責務とした関数群です。 useQuery の条件付き実行を制御する enabled オプションで false となる条件を例外とすることで、queryFn 内で 型ガードをしなくて良い設計としています。 これらを使って View とのインターフェースとなる useQuery ラッパーを定義します。 // ⑤ Base Query // API Response を整形せずに返す export type UseTodoDetailQueryProps &#x3C; QueryResult > = { id : string | undefined ; select ?: ( data : Todo ) => QueryResult ; }; export function useTodoDetailQuery &#x3C; QueryResult = Todo >( props : UseTodoDetailQueryProps &#x3C; QueryResult > ) { return useQuery ({ queryKey: todoKeys . detail ( props . id ), queryFn : () => { return query . getTodoDetail ( request . getTodoDetail ( props . id )); }, enabled: !! props . id , select: props . select , useErrorBoundary: true , }); } import { selectTodoForm } from "@/viewModels/todo/todoForm" ; // ⑥ Selector Query // API Response を View で参照したいフォーマットに整形して返す export function useInitialTodoFormQuery () { // Base Query に select オプションを与える return useTodoDetailQuery ({ select: selectTodoForm , // selectTodoForm は Todo を TodoForm に変換する ViewModel Selector（後述） }); } useQuery ラッパーは、⑤ Base Query と ⑥ Selector Query に分けて定義しています。 CLINICS では同じデータソースに対して画面ごとに異なるフォーマットで表示することが多くあります。 Selector Query で 任意のフォーマットに整形することで、画面ごとに最適化されたデータの取得をスケーラブルに実現しています。 4 加えて、この手法では Selector にドメインロジックが凝集されるため、 Selector を重点的にテストすることで品質を担保しやすい メリットがあります。 Query のエラー制御は useErrorBoundary オプションを使って Error Boundary を表示する方針としています。 mutations.ts mutations.ts は次のように実装しています。 import { type TodoForm } from "@/viewModels/todo/todoForm" ; import { todoApi , type PostTodoRequest } "@/api/generated" ; // ⑦ mutationFn export const mutation = { createTodo : ( request : PostTodoRequest ) => { return todoApi . postTodo ( request ); }, }; // ⑧ Request Selector // ViewModel から API Request へ変換する export const request = { createTodo : ( todoForm : TodoForm ): PostTodoRequest => { return { PostTodoRequest : { todo : { title : todoForm . title , description : todoForm . description , status : todoForm . status , favorite : todoForm . favorite === "true" ? true : false , }, }, }; }, }; // ⑨ Custom Mutation export function useCreateTodoMutation () { const { invalidateList } = useTodoCache (); return useMutation ({ mutationFn : ( todoForm : TodoForm ) => { return mutation . createTodo ( request . createTodo ( todoForm )); }, onSuccess : () => { return invalidateList (); }, }); } 基本的な構成は queries.ts と同じです。 mutations.ts でも queries.ts と同様に ⑧ Request Selector を定義します。 Request Selector には、データ整形を扱うためドメインロジックが集まりやすいです。 そのため、入出力、境界値、例外のテストを積極的に書いて品質の担保に繋げています。 Mutation のエラーは画面ごとに UI でフィードバックするため、コンポーネント側で制御しています。 Resource Operation レイヤーに関する実装の紹介は以上です。 ViewModel の実装 ViewModel とは、View(React Component) で扱うデータのスキーマと型です。 Resource Operation の実装では、API Response を ViewModel に整形して View に提供することを紹介しました。 全体の理解を深めるため、ViewModel の実装も紹介します。 ディレクトリ構成 ViewModel は関心を分離するため Resource Operation とは別のディレクトリに定義しています。 src/viewModels └── todo ├── todo.ts # サーバステート ├── todoForm.test.ts # フロントエンドに閉じたスキーマのテスト ├── todoForm.ts # フロントエンドに閉じたスキーマ └── todoSearchCondition.ts # フロントエンドに閉じた型 ViewModel で定義するスキーマ・型は大きく分けて 3 つに分類されます。 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 サーバステート サーバステートは、 API Response として期待するデータのスキーマ及び型です。 前述の queries.ts 内の ③ queryFn で使用します。 zod を使って次のように実装しています。 // src/viewModels/todo/todo.ts // enum は View で &#x3C;option value={todoStatus.enum.ready} /> のように使用する export const todoStatus = z . enum ([ "ready" , "doing" , "done" ]); // ⑩ サーバステートのスキーマ // 開発中のみ ③ queryFn 内で API Response を parse することで、スキーマの不整合を検出するための補助輪として使用する export const todo = z . object ({ id: z . string (), title: z . string (), description: z . string (). nullable (), status: todoStatus , favorite: z . boolean (), }); // ⑪ サーバステートの型 // ③ queryFn の戻り値の型として使用する export type Todo = z . infer &#x3C; typeof todo >; ⑩ サーバステートのスキーマは、⑪ サーバステートの型の生成と開発時のスキーマ検証に使用しています。 開発時のみ API Response を検証することで、⑩ サーバステートのスキーマと Open API スキーマの整合性を確認しています。 // src/resourceOperations/todo/queries.ts import { todo , type Todo } from "@/viewModels/todo" ; export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); // 開発時、APIとの結合タイミングで検証してフロントエンドとバックエンドでスキーマの齟齬がないことを確認する // 検証が済んだら parse 処理を外す return data . todoList . map (( x ) => todo . parse ( x )); }, }; 例外として、 外部サービスから取得したデータに関しては常にサーバステートのスキーマを使って検証 しています。 例えば、外部サービスの仕様として長さが 1 以上の配列が返ってくると決まっていて、フロントエンド側もその仕様に基づいた処理を実装している場合、 z.array().min(1) のスキーマで常に検証します。 ネットワークに近い箇所で不正なデータを検出することで、例外発生時の調査を容易にするメリットがあると考えています。 フロントエンドに閉じたスキーマ フロントエンドに閉じたスキーマは、そのほとんどがフォームのバリデーションスキーマです。 こちらも zod を使って定義しています。 // src/viewModels/todo/todoForm.ts import { type Todo , todo } from "./todo" ; // フロントエンドに閉じたスキーマ // フォームのスキーマは react-hook-form と連携して使用する（省略） export const todoForm = z . object ({ title: z . string () . min ( 1 , "入力してください" ) . max ( 200 , "200字以内で入力してください" ), description: z . string (). max ( 500 , "500字以内で入力してください" ), status: todo . shape . status , favorite: z . union ([ z . literal ( "true" ), z . literal ( "false" )]), }); export type TodoForm = z . infer &#x3C; typeof todoForm >; // ⑫ ViewModel Selector // サーバステートからフロントエンドに閉じたスキーマへ変換する // 前述の queries.ts 内 ⑥ Selector Query で使用する export function selectTodoForm ( todo : Todo ): TodoForm { return { title: todo . title , description: todo . description ?? "" , status: todo . status , favorite: todo . favorite ? "true" : "false" , }; } フロントエンドに閉じたスキーマは、必ずサーバステートを元に生成する運用としています。 そのために、フロントエンドに閉じたスキーマを宣言した直下に、サーバステートからフロントエンドに閉じたスキーマへ変換する ⑫ ViewModel Selector を定義します。 null の 空文字への変換や時間データのフォーマットのような、 サーバステート と View で使う値の差分吸収はこのセレクタ内で行います。 このように、 ViewModel レイヤーでは他のレイヤーと依存しないようにドメインロジックを表現 しています。 ドメインロジックを Tanstack Query に依存しないことで、今後技術基盤を刷新する場合でも影響を最小限に留めることを狙いとしています。 フロントエンドに閉じた型 依存関係を整えるため、Resource Operation と View から参照するフロントエンドに閉じた型は viewModels 配下に宣言しています。 // src/viewModels/todo/todoSearchParams.ts export type TodoSearchCondition = { sort ?: "created_at_asc" | "created_at_desc" ; }; ViewModel に関する実装の紹介は以上です。 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 Tanstack Query を導入する以前の CLINICS の非同期処理周辺のコードベースではいくつかの課題がありました。 開発体験の課題 非同期処理のためのミニマムな基盤フックを独自に実装していた 5 ことにより、開発体験の観点で次のような課題がありました。 新しい要件（ポーリング・無限読み込み等）が発生した際に、最初に担当する開発者が都度機能拡張する必要がある テストが実装されていなかったため変更時に品質確認の負担が大きい 学習容易性の課題 上述の基盤フックにドキュメントがなかったため、学習容易性の観点で次のような課題がありました。 基盤フックにドキュメントがなく、新規メンバーの学習コストが高い 様々な実装手法が混在することで、実装時に迷いが生じている 可読性の課題 CLINICS は開発開始から約 7 年以上が経過しています。 その中でもフロントエンドは技術トレンドの変化が早いため、様々なライブラリやパターンを使って実装されています。 特に近年から漸進的に導入した React を使った実装については、明確な設計が確立されていませんでした。 これらの背景からチームで安定したアウトプットを出すことが困難で、可読性の観点で次のような課題がありました。 画面によってフックや関数の粒度、定義場所が違うことでコードリーディングの負荷が高い コードレビュー時のレビュワーの負担が大きい テスト容易性の課題 多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、テスト容易性の観点で次のような課題がありました。 テストが実装しづらい テストカバレッジが低い CLINICS はオンライン診療・電子カルテ等の医療機関業務を支える機能を提供する SaaS プラットフォームです。 今後長きに渡って多くの医療機関の方々に CLINICS を利用して頂くためには、 コードを読みやすく、変更しやすく、維持しやすい状態に保ち続けること が重要です。 前の章で紹介したアーキテクチャは 持続可能な開発を目指して 設計しました。 具体的には、 開発体験・学習容易性・可読性・テスト容易性を向上することを狙い としています。 狙い 1：Tanstack Query の導入による開発体験の向上 背景で説明したとおり、Tanstack Query 導入以前は独自実装したフックを使って非同期処理を実装していました。 Tanstack Query を導入したきっかけは、チーム内での雑談の中で、独自実装のフックが使いづらいという声が挙がったことです。 そこで、独自実装のフック自体の質を高めるか、質の高いライブラリを導入するかを議論した結果、次の理由でライブラリを導入する決定をしました。 極力自分たちでコードを書かずに非同期処理・状態管理の実装を実現したい 実装に困ったときにドキュメントを読めば解決する環境にしたい CLINICS では技術的な背景 6 から Tanstack Query と SWR が候補に上がりましたが、 select オプションや invalidateQueries の Partial Query Matching 等の機能性と、ドキュメントの充実度合いの観点から Tanstack Query を採用しました。 Tanstack Query を採用したことで、 非同期処理のためのコードの記述量が大幅に削減 されたほか、データの特性に応じて Query ごとにキャッシュの時間を調整することが可能となり開発体験が大幅に向上しました。 狙い 2：シンプルなレイヤー分割による学習容易性の向上 CLINICS では、事業の拡大にともないコードベースに関わるエンジニアが増え続けています。 実装の進め方はプロジェクトによって最適な形式を選択しています。 バックエンドからフロントエンドまで一気通貫で実装 技術領域に分けて分業 このように多くのエンジニアが様々な形で関わる環境では、コードベースの学習容易性を高め、実装からコードレビューの完了までをスムーズに行えることが重要です。 前の章で紹介したアーキテクチャは、 レイヤー分割をシンプルにすることでコードベースに慣れるまでの時間を最小限にする ことを意識しています。 加えて、 実装パターンを定形化することで、コードベースに馴染みがなくても迷いなく実装できる ほか、関数の粒度が統一されることで、コードレビューの負荷軽減にも繋がっています。 レイヤー分割の粒度や実装パターンについては、次の記事を参考にさせて頂きました。 フロントエンドアーキテクチャの話: Resource Set の紹介 ほかにも CLINICS では学習容易性の向上の取り組みとして、 新しいライブラリやアーキテクチャを導入した際は勉強会を開催 してライブラリの基本的な使い方や頻出の実装パターンに関する知見を共有しています。 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 アーキテクチャを刷新する以前は、多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、可読性やテスト容易性に支障をきたしていました。 CLINICS のフロントエンドには、医療システムに関する複雑なドメインロジックが多いため、 シンプルでテストしやすいコードベース を作っていくことがとりわけ重要だと考えています。 この課題は、ドメインロジックが集まる傾向にある queries.ts、 mutations.ts の Request Selector や ViewModel Selector の実装を定型化し、純粋関数で表現することにより解決しました。 まとめ Tanstack Query を使ったフロントエンドアーキテクチャの実例を紹介しました。 Resource Operation レイヤーに Tanstack Query の実装を定型化して集約しています。 レイヤー分割をシンプルにし、実装を定型化することで、開発組織のスケールに対応しています。 useQuery の select オプションを使い、スケーラブルにデータ変換処理を記述しています。 データ変換処理にはドメインロジックが集まりやすいため、なるべく小さい粒度の純粋関数で表現することで、可読性・テスト容易性の向上を狙っています。 この記事の内容が Tanstack Query の導入を考えている方の参考になれば幸いです。 さいごに CLINICS では、機能開発と並行してフロントエンド基盤を改善する取り組みも実施しています。 Redux から Tanstack Query への移行 UI ライブラリの Mithril から React への移行 7 デザインシステムの構築とプロダクトへの反映 このような取り組みに興味がある方は次のリンクから是非ご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp Footnotes Overview | TanStack Query Docs ↩ Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router | TanStack Query Docs ↩ この記事で紹介している ViewModel は View レイヤー専用のモデルを表す概念です。 MVVM アーキテクチャの ViewModel とは異なります。 ↩ Tanstack Query におけるデータ変換手法の詳細は React Query Data Transformations | TkDodo’s blog で紹介されています。 ↩ Tanstack Query 導入以前の非同期処理は useAsync React Hook - useHooks をカスタマイズしたフックを使って実装していました。 ↩ CLINICS では 一部の実装箇所で Redux を使用していますが、 RTK Query は今回採用するライブラリの候補から除外しました。これは、現在使用している Redux のバージョンが低く、レガシーな周辺ライブラリも複数使用している背景で Redux Toolkit への移行に相当な工数を必要とするためです。 ↩ 2023 年 3 月現在、 CLINICS のフロントエンドの 約 50% は、 Mithril と Redux で構成されています。開発体験の向上のため、 React への完全移行を目指して日々改善を続けています。 ↩

こんにちは。医療プラットフォーム第一本部プロダクト開発室所属エンジニアの髙橋です。 普段の業務では、 医療 SaaS プラットフォーム CLINICS の医療機関向けアプリケーション（以下、CLINICS）の開発を担当しています。 CLINICS では、昨年 10 月頃から React コードベースのリアーキテクチャに取り組んでいます。 その取り組みの 1 つとして、非同期状態管理に関連する実装を Tanstack Query を使って刷新しています。 この記事では、CLINICS における Tanstack Query の活用方法を導入背景と狙いを含めて紹介します。 目次 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Tanstack Query について Tanstack Query を活用したフロントエンドアーキテクチャ Resource Operation の実装 ディレクトリ構成 cache.ts queries.ts mutations.ts ViewModel の実装 ディレクトリ構成 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 狙い 1：Tanstack Query の導入による開発体験の向上 狙い 2：シンプルなレイヤー分割による学習容易性の向上 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 まとめ さいごに Tanstack Query について Tanstack Query は、Web アプリケーションのサーバ状態の取得、キャッシュ、同期、更新を簡単に行うことができるライブラリです。 1 類似ライブラリには SWR、Apollo Client、RTK Query 等が挙げられます。 2 私たちは、機能性・ドキュメントの充実度・コミュニティの将来性を総合的に判断した結果、Tanstack Query(React Query)を採用して React コードベースの再構築を進めています。 導入背景の詳細は、後のセクションで詳しく紹介します。 Tanstack Query を活用したフロントエンドアーキテクチャ それでは本題の Tanstack Query を活用したフロントエンドアーキテクチャについて紹介します。 始めに、アーキテクチャの全体像を示した次の図をご覧ください。 まず注目して頂きたいポイントは、Backend と View の間にある Resource Operation です。 Resource Operation は Tanstack Query を主軸に実装されているレイヤーです。 役割を大きく分類すると次の 2 つが挙げられます。 非同期状態管理に関連する実装の集約 Backend で扱うデータ(OpenAPI スキーマ)と View で扱うデータ(ViewModel)の相互変換 全体像を把握するために、左右のレイヤーにも注目してください。 右の Backend は CLINICS では Ruby on Rails で実装された REST API を提供するモノリシックなサーバです。 API で扱うスキーマは OpenAPI を使って定義しています。 OpenAPI スキーマは、 committee-rails を使ったレスポンス検証と、 openapi-generator を使った API クライアントコードの自動生成に活用しています。 左の View は CLINICS では React で実装されたコンポーネントになります。 View では Backend の OpenAPI スキーマを直接参照することを避け、 ViewModel と呼ばれるフロントエンドで定義したモデル 3 のみを参照する設計としています。 Resource Operation は View と Backend の境界レイヤーとして非同期状態管理とデータの相互変換を行うシンプルなレイヤーとなっています。 続いて、上記の運用のための実装詳細を紹介します。 Resource Operation の実装 ディレクトリ構成 Resource Operation レイヤーでは、リソースごとに非同期状態管理とデータの相互変換の処理をまとめています。 ディレクトリツリーで Resource Operation レイヤー全体を表現すると次のようになります。 src/resourceOperations ├── resourceTagName # 例： todo │ ├── cache.ts │ ├── mutations.ts │ └── queries.ts └── resourceGroupTagName # 例： systemSettings（リソースに階層がある場合） └── resourceTagName # 例： organization（リソースグループ配下のリソース） ├── cache.ts ├── mutations.ts └── queries.ts ディレクトリ名の resourceTagName と resourceGroupTagName は OpenAPI スキーマでエンドポイントごとに割り振られている tag を元に命名しています。 ディレクトリごとに 次の 3 つのファイルを定義しています。 ファイル 役割 cache.ts Query Key の定義、キャッシュ操作のためのカスタムフックの定義 queries.ts useQuery をラップしたカスタムフックの定義、API Request/Response の整形 mutations.ts useMutation をラップしたカスタムフックの定義、API Request の整形 cache.ts cache.ts は次のように実装しています。 // ① Query Key // queries.ts がある場合に必要に応じて宣言 export const todoKeys = { all: [ "todo" ] as const , list : () => [... todoKeys . all , "list" ] as const , paginateList : ( page ?: number ) => [... todoKeys . list (), { page }] as const , detail : ( id : string ) => [... todoKeys . all , "detail" , id ] as const , }; // ② キャッシュ操作のためのカスタムフック // mutations.ts がある場合に必要に応じて宣言 export function useTodoCache () { const queryClient = useQueryClient (); return useMemo ( () => ({ invalidateList : () => queryClient . invalidateQueries ( todoKeys . list ()), invalidateDetail : ( id : string ) => queryClient . invalidateQueries ( todoKeys . detail ( id )), }), [ queryClient ] ); } ① Query Key は、 useQuery の queryKey オプションに与える値を定義した定数です。これは後述の queries.ts で利用します。 実装は Tanstack Query メンテナの Dominik さんのブログで紹介されている Query Key factories パターンを使っています。 ディレクトリ名を all の値とすることで、大規模なアプリケーションにおいてもキーの衝突を防ぐことが可能です。 ② キャッシュ操作のためのカスタムフックでは QueryClient を利用したキャッシュ操作をまとめています。これは後述の mutations.ts で利用します。 CLINICS では 楽観的更新 をしない方針としているため、 invalidateQueries を実行する関数群のみを定義しています。 queries.ts queries.ts は次のように実装しています。 import { type Todo } from "@/viewModels/todo" ; import { todoApi , type GetTodoDetailRequest } from "@/api/generated" ; // ③ queryFn export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); return data . todoList ; }, getTodoDetail : async ( request : GetTodoDetailRequest ): Promise &#x3C; Todo > => { const { data } = await todoApi . getTodoDetail ( request ); return data . todo ; }, }; // ④ Request Selector export const request = { getTodoDetail : ( id : string | undefined ): GetTodoDetailRequest => { if ( id === undefined ) { // `enabled: false` となる条件の引数が与えられた場合例外とすることで、 // queryFn 内の型の整合性を保つ throw new InvalidRequestParameterError ( "Required parameter id was undefined when calling request.getTodoDetail." ); } return { id , }; }, }; ③ queryFn は、API へのリクエストを責務とした関数群です。 ここで使用している ApiClient や Request の型は openapi-generator から生成しています。 queryFn の戻り値の型は、後述の ViewModel で定義した型を明示 しています。 このようにフロントエンド側でサーバステートの型を別途定義することで、フロントエンドとバックエンドを分業して実装する際に開発しやすくなるメリットがあります。 省略していますが、レスポンスに応じたエラーの throw もここで行います。 ④ Request Selector は View から受け取った値をリクエストパラメータへマッピングすることを責務とした関数群です。 useQuery の条件付き実行を制御する enabled オプションで false となる条件を例外とすることで、queryFn 内で 型ガードをしなくて良い設計としています。 これらを使って View とのインターフェースとなる useQuery ラッパーを定義します。 // ⑤ Base Query // API Response を整形せずに返す export type UseTodoDetailQueryProps &#x3C; QueryResult > = { id : string | undefined ; select ?: ( data : Todo ) => QueryResult ; }; export function useTodoDetailQuery &#x3C; QueryResult = Todo >( props : UseTodoDetailQueryProps &#x3C; QueryResult > ) { return useQuery ({ queryKey: todoKeys . detail ( props . id ), queryFn : () => { return query . getTodoDetail ( request . getTodoDetail ( props . id )); }, enabled: !! props . id , select: props . select , useErrorBoundary: true , }); } import { selectTodoForm } from "@/viewModels/todo/todoForm" ; // ⑥ Selector Query // API Response を View で参照したいフォーマットに整形して返す export function useInitialTodoFormQuery () { // Base Query に select オプションを与える return useTodoDetailQuery ({ select: selectTodoForm , // selectTodoForm は Todo を TodoForm に変換する ViewModel Selector（後述） }); } useQuery ラッパーは、⑤ Base Query と ⑥ Selector Query に分けて定義しています。 CLINICS では同じデータソースに対して画面ごとに異なるフォーマットで表示することが多くあります。 Selector Query で 任意のフォーマットに整形することで、画面ごとに最適化されたデータの取得をスケーラブルに実現しています。 4 加えて、この手法では Selector にドメインロジックが凝集されるため、 Selector を重点的にテストすることで品質を担保しやすい メリットがあります。 Query のエラー制御は useErrorBoundary オプションを使って Error Boundary を表示する方針としています。 mutations.ts mutations.ts は次のように実装しています。 import { type TodoForm } from "@/viewModels/todo/todoForm" ; import { todoApi , type PostTodoRequest } "@/api/generated" ; // ⑦ mutationFn export const mutation = { createTodo : ( request : PostTodoRequest ) => { return todoApi . postTodo ( request ); }, }; // ⑧ Request Selector // ViewModel から API Request へ変換する export const request = { createTodo : ( todoForm : TodoForm ): PostTodoRequest => { return { PostTodoRequest : { todo : { title : todoForm . title , description : todoForm . description , status : todoForm . status , favorite : todoForm . favorite === "true" ? true : false , }, }, }; }, }; // ⑨ Custom Mutation export function useCreateTodoMutation () { const { invalidateList } = useTodoCache (); return useMutation ({ mutationFn : ( todoForm : TodoForm ) => { return mutation . createTodo ( request . createTodo ( todoForm )); }, onSuccess : () => { return invalidateList (); }, }); } 基本的な構成は queries.ts と同じです。 mutations.ts でも queries.ts と同様に ⑧ Request Selector を定義します。 Request Selector には、データ整形を扱うためドメインロジックが集まりやすいです。 そのため、入出力、境界値、例外のテストを積極的に書いて品質の担保に繋げています。 Mutation のエラーは画面ごとに UI でフィードバックするため、コンポーネント側で制御しています。 Resource Operation レイヤーに関する実装の紹介は以上です。 ViewModel の実装 ViewModel とは、View(React Component) で扱うデータのスキーマと型です。 Resource Operation の実装では、API Response を ViewModel に整形して View に提供することを紹介しました。 全体の理解を深めるため、ViewModel の実装も紹介します。 ディレクトリ構成 ViewModel は関心を分離するため Resource Operation とは別のディレクトリに定義しています。 src/viewModels └── todo ├── todo.ts # サーバステート ├── todoForm.test.ts # フロントエンドに閉じたスキーマのテスト ├── todoForm.ts # フロントエンドに閉じたスキーマ └── todoSearchCondition.ts # フロントエンドに閉じた型 ViewModel で定義するスキーマ・型は大きく分けて 3 つに分類されます。 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 サーバステート サーバステートは、 API Response として期待するデータのスキーマ及び型です。 前述の queries.ts 内の ③ queryFn で使用します。 zod を使って次のように実装しています。 // src/viewModels/todo/todo.ts // enum は View で &#x3C;option value={todoStatus.enum.ready} /> のように使用する export const todoStatus = z . enum ([ "ready" , "doing" , "done" ]); // ⑩ サーバステートのスキーマ // 開発中のみ ③ queryFn 内で API Response を parse することで、スキーマの不整合を検出するための補助輪として使用する export const todo = z . object ({ id: z . string (), title: z . string (), description: z . string (). nullable (), status: todoStatus , favorite: z . boolean (), }); // ⑪ サーバステートの型 // ③ queryFn の戻り値の型として使用する export type Todo = z . infer &#x3C; typeof todo >; ⑩ サーバステートのスキーマは、⑪ サーバステートの型の生成と開発時のスキーマ検証に使用しています。 開発時のみ API Response を検証することで、⑩ サーバステートのスキーマと Open API スキーマの整合性を確認しています。 // src/resourceOperations/todo/queries.ts import { todo , type Todo } from "@/viewModels/todo" ; export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); // 開発時、APIとの結合タイミングで検証してフロントエンドとバックエンドでスキーマの齟齬がないことを確認する // 検証が済んだら parse 処理を外す return data . todoList . map (( x ) => todo . parse ( x )); }, }; 例外として、 外部サービスから取得したデータに関しては常にサーバステートのスキーマを使って検証 しています。 例えば、外部サービスの仕様として長さが 1 以上の配列が返ってくると決まっていて、フロントエンド側もその仕様に基づいた処理を実装している場合、 z.array().min(1) のスキーマで常に検証します。 ネットワークに近い箇所で不正なデータを検出することで、例外発生時の調査を容易にするメリットがあると考えています。 フロントエンドに閉じたスキーマ フロントエンドに閉じたスキーマは、そのほとんどがフォームのバリデーションスキーマです。 こちらも zod を使って定義しています。 // src/viewModels/todo/todoForm.ts import { type Todo , todo } from "./todo" ; // フロントエンドに閉じたスキーマ // フォームのスキーマは react-hook-form と連携して使用する（省略） export const todoForm = z . object ({ title: z . string () . min ( 1 , "入力してください" ) . max ( 200 , "200字以内で入力してください" ), description: z . string (). max ( 500 , "500字以内で入力してください" ), status: todo . shape . status , favorite: z . union ([ z . literal ( "true" ), z . literal ( "false" )]), }); export type TodoForm = z . infer &#x3C; typeof todoForm >; // ⑫ ViewModel Selector // サーバステートからフロントエンドに閉じたスキーマへ変換する // 前述の queries.ts 内 ⑥ Selector Query で使用する export function selectTodoForm ( todo : Todo ): TodoForm { return { title: todo . title , description: todo . description ?? "" , status: todo . status , favorite: todo . favorite ? "true" : "false" , }; } フロントエンドに閉じたスキーマは、必ずサーバステートを元に生成する運用としています。 そのために、フロントエンドに閉じたスキーマを宣言した直下に、サーバステートからフロントエンドに閉じたスキーマへ変換する ⑫ ViewModel Selector を定義します。 null の 空文字への変換や時間データのフォーマットのような、 サーバステート と View で使う値の差分吸収はこのセレクタ内で行います。 このように、 ViewModel レイヤーでは他のレイヤーと依存しないようにドメインロジックを表現 しています。 ドメインロジックを Tanstack Query に依存しないことで、今後技術基盤を刷新する場合でも影響を最小限に留めることを狙いとしています。 フロントエンドに閉じた型 依存関係を整えるため、Resource Operation と View から参照するフロントエンドに閉じた型は viewModels 配下に宣言しています。 // src/viewModels/todo/todoSearchParams.ts export type TodoSearchCondition = { sort ?: "created_at_asc" | "created_at_desc" ; }; ViewModel に関する実装の紹介は以上です。 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 Tanstack Query を導入する以前の CLINICS の非同期処理周辺のコードベースではいくつかの課題がありました。 開発体験の課題 非同期処理のためのミニマムな基盤フックを独自に実装していた 5 ことにより、開発体験の観点で次のような課題がありました。 新しい要件（ポーリング・無限読み込み等）が発生した際に、最初に担当する開発者が都度機能拡張する必要がある テストが実装されていなかったため変更時に品質確認の負担が大きい 学習容易性の課題 上述の基盤フックにドキュメントがなかったため、学習容易性の観点で次のような課題がありました。 基盤フックにドキュメントがなく、新規メンバーの学習コストが高い 様々な実装手法が混在することで、実装時に迷いが生じている 可読性の課題 CLINICS は開発開始から約 7 年以上が経過しています。 その中でもフロントエンドは技術トレンドの変化が早いため、様々なライブラリやパターンを使って実装されています。 特に近年から漸進的に導入した React を使った実装については、明確な設計が確立されていませんでした。 これらの背景からチームで安定したアウトプットを出すことが困難で、可読性の観点で次のような課題がありました。 画面によってフックや関数の粒度、定義場所が違うことでコードリーディングの負荷が高い コードレビュー時のレビュワーの負担が大きい テスト容易性の課題 多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、テスト容易性の観点で次のような課題がありました。 テストが実装しづらい テストカバレッジが低い CLINICS はオンライン診療・電子カルテ等の医療機関業務を支える機能を提供する SaaS プラットフォームです。 今後長きに渡って多くの医療機関の方々に CLINICS を利用して頂くためには、 コードを読みやすく、変更しやすく、維持しやすい状態に保ち続けること が重要です。 前の章で紹介したアーキテクチャは 持続可能な開発を目指して 設計しました。 具体的には、 開発体験・学習容易性・可読性・テスト容易性を向上することを狙い としています。 狙い 1：Tanstack Query の導入による開発体験の向上 背景で説明したとおり、Tanstack Query 導入以前は独自実装したフックを使って非同期処理を実装していました。 Tanstack Query を導入したきっかけは、チーム内での雑談の中で、独自実装のフックが使いづらいという声が挙がったことです。 そこで、独自実装のフック自体の質を高めるか、質の高いライブラリを導入するかを議論した結果、次の理由でライブラリを導入する決定をしました。 極力自分たちでコードを書かずに非同期処理・状態管理の実装を実現したい 実装に困ったときにドキュメントを読めば解決する環境にしたい CLINICS では技術的な背景 6 から Tanstack Query と SWR が候補に上がりましたが、 select オプションや invalidateQueries の Partial Query Matching 等の機能性と、ドキュメントの充実度合いの観点から Tanstack Query を採用しました。 Tanstack Query を採用したことで、 非同期処理のためのコードの記述量が大幅に削減 されたほか、データの特性に応じて Query ごとにキャッシュの時間を調整することが可能となり開発体験が大幅に向上しました。 狙い 2：シンプルなレイヤー分割による学習容易性の向上 CLINICS では、事業の拡大にともないコードベースに関わるエンジニアが増え続けています。 実装の進め方はプロジェクトによって最適な形式を選択しています。 バックエンドからフロントエンドまで一気通貫で実装 技術領域に分けて分業 このように多くのエンジニアが様々な形で関わる環境では、コードベースの学習容易性を高め、実装からコードレビューの完了までをスムーズに行えることが重要です。 前の章で紹介したアーキテクチャは、 レイヤー分割をシンプルにすることでコードベースに慣れるまでの時間を最小限にする ことを意識しています。 加えて、 実装パターンを定形化することで、コードベースに馴染みがなくても迷いなく実装できる ほか、関数の粒度が統一されることで、コードレビューの負荷軽減にも繋がっています。 レイヤー分割の粒度や実装パターンについては、次の記事を参考にさせて頂きました。 フロントエンドアーキテクチャの話: Resource Set の紹介 ほかにも CLINICS では学習容易性の向上の取り組みとして、 新しいライブラリやアーキテクチャを導入した際は勉強会を開催 してライブラリの基本的な使い方や頻出の実装パターンに関する知見を共有しています。 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 アーキテクチャを刷新する以前は、多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、可読性やテスト容易性に支障をきたしていました。 CLINICS のフロントエンドには、医療システムに関する複雑なドメインロジックが多いため、 シンプルでテストしやすいコードベース を作っていくことがとりわけ重要だと考えています。 この課題は、ドメインロジックが集まる傾向にある queries.ts、 mutations.ts の Request Selector や ViewModel Selector の実装を定型化し、純粋関数で表現することにより解決しました。 まとめ Tanstack Query を使ったフロントエンドアーキテクチャの実例を紹介しました。 Resource Operation レイヤーに Tanstack Query の実装を定型化して集約しています。 レイヤー分割をシンプルにし、実装を定型化することで、開発組織のスケールに対応しています。 useQuery の select オプションを使い、スケーラブルにデータ変換処理を記述しています。 データ変換処理にはドメインロジックが集まりやすいため、なるべく小さい粒度の純粋関数で表現することで、可読性・テスト容易性の向上を狙っています。 この記事の内容が Tanstack Query の導入を考えている方の参考になれば幸いです。 さいごに CLINICS では、機能開発と並行してフロントエンド基盤を改善する取り組みも実施しています。 Redux から Tanstack Query への移行 UI ライブラリの Mithril から React への移行 7 デザインシステムの構築とプロダクトへの反映 このような取り組みに興味がある方は次のリンクから是非ご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp Footnotes Overview | TanStack Query Docs ↩ Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router | TanStack Query Docs ↩ この記事で紹介している ViewModel は View レイヤー専用のモデルを表す概念です。 MVVM アーキテクチャの ViewModel とは異なります。 ↩ Tanstack Query におけるデータ変換手法の詳細は React Query Data Transformations | TkDodo’s blog で紹介されています。 ↩ Tanstack Query 導入以前の非同期処理は useAsync React Hook - useHooks をカスタマイズしたフックを使って実装していました。 ↩ CLINICS では 一部の実装箇所で Redux を使用していますが、 RTK Query は今回採用するライブラリの候補から除外しました。これは、現在使用している Redux のバージョンが低く、レガシーな周辺ライブラリも複数使用している背景で Redux Toolkit への移行に相当な工数を必要とするためです。 ↩ 2023 年 3 月現在、 CLINICS のフロントエンドの 約 50% は、 Mithril と Redux で構成されています。開発体験の向上のため、 React への完全移行を目指して日々改善を続けています。 ↩

こんにちは。医療プラットフォーム第一本部プロダクト開発室所属エンジニアの髙橋です。 普段の業務では、 医療 SaaS プラットフォーム CLINICS の医療機関向けアプリケーション（以下、CLINICS）の開発を担当しています。 CLINICS では、昨年 10 月頃から React コードベースのリアーキテクチャに取り組んでいます。 その取り組みの 1 つとして、非同期状態管理に関連する実装を Tanstack Query を使って刷新しています。 この記事では、CLINICS における Tanstack Query の活用方法を導入背景と狙いを含めて紹介します。 目次 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Tanstack Query について Tanstack Query を活用したフロントエンドアーキテクチャ Resource Operation の実装 ディレクトリ構成 cache.ts queries.ts mutations.ts ViewModel の実装 ディレクトリ構成 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 狙い 1：Tanstack Query の導入による開発体験の向上 狙い 2：シンプルなレイヤー分割による学習容易性の向上 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 まとめ さいごに Tanstack Query について Tanstack Query は、Web アプリケーションのサーバ状態の取得、キャッシュ、同期、更新を簡単に行うことができるライブラリです。 1 類似ライブラリには SWR、Apollo Client、RTK Query 等が挙げられます。 2 私たちは、機能性・ドキュメントの充実度・コミュニティの将来性を総合的に判断した結果、Tanstack Query(React Query)を採用して React コードベースの再構築を進めています。 導入背景の詳細は、後のセクションで詳しく紹介します。 Tanstack Query を活用したフロントエンドアーキテクチャ それでは本題の Tanstack Query を活用したフロントエンドアーキテクチャについて紹介します。 始めに、アーキテクチャの全体像を示した次の図をご覧ください。 まず注目して頂きたいポイントは、Backend と View の間にある Resource Operation です。 Resource Operation は Tanstack Query を主軸に実装されているレイヤーです。 役割を大きく分類すると次の 2 つが挙げられます。 非同期状態管理に関連する実装の集約 Backend で扱うデータ(OpenAPI スキーマ)と View で扱うデータ(ViewModel)の相互変換 全体像を把握するために、左右のレイヤーにも注目してください。 右の Backend は CLINICS では Ruby on Rails で実装された REST API を提供するモノリシックなサーバです。 API で扱うスキーマは OpenAPI を使って定義しています。 OpenAPI スキーマは、 committee-rails を使ったレスポンス検証と、 openapi-generator を使った API クライアントコードの自動生成に活用しています。 左の View は CLINICS では React で実装されたコンポーネントになります。 View では Backend の OpenAPI スキーマを直接参照することを避け、 ViewModel と呼ばれるフロントエンドで定義したモデル 3 のみを参照する設計としています。 Resource Operation は View と Backend の境界レイヤーとして非同期状態管理とデータの相互変換を行うシンプルなレイヤーとなっています。 続いて、上記の運用のための実装詳細を紹介します。 Resource Operation の実装 ディレクトリ構成 Resource Operation レイヤーでは、リソースごとに非同期状態管理とデータの相互変換の処理をまとめています。 ディレクトリツリーで Resource Operation レイヤー全体を表現すると次のようになります。 src/resourceOperations ├── resourceTagName # 例： todo │ ├── cache.ts │ ├── mutations.ts │ └── queries.ts └── resourceGroupTagName # 例： systemSettings（リソースに階層がある場合） └── resourceTagName # 例： organization（リソースグループ配下のリソース） ├── cache.ts ├── mutations.ts └── queries.ts ディレクトリ名の resourceTagName と resourceGroupTagName は OpenAPI スキーマでエンドポイントごとに割り振られている tag を元に命名しています。 ディレクトリごとに 次の 3 つのファイルを定義しています。 ファイル 役割 cache.ts Query Key の定義、キャッシュ操作のためのカスタムフックの定義 queries.ts useQuery をラップしたカスタムフックの定義、API Request/Response の整形 mutations.ts useMutation をラップしたカスタムフックの定義、API Request の整形 cache.ts cache.ts は次のように実装しています。 // ① Query Key // queries.ts がある場合に必要に応じて宣言 export const todoKeys = { all: [ "todo" ] as const , list : () => [... todoKeys . all , "list" ] as const , paginateList : ( page ?: number ) => [... todoKeys . list (), { page }] as const , detail : ( id : string ) => [... todoKeys . all , "detail" , id ] as const , }; // ② キャッシュ操作のためのカスタムフック // mutations.ts がある場合に必要に応じて宣言 export function useTodoCache () { const queryClient = useQueryClient (); return useMemo ( () => ({ invalidateList : () => queryClient . invalidateQueries ( todoKeys . list ()), invalidateDetail : ( id : string ) => queryClient . invalidateQueries ( todoKeys . detail ( id )), }), [ queryClient ] ); } ① Query Key は、 useQuery の queryKey オプションに与える値を定義した定数です。これは後述の queries.ts で利用します。 実装は Tanstack Query メンテナの Dominik さんのブログで紹介されている Query Key factories パターンを使っています。 ディレクトリ名を all の値とすることで、大規模なアプリケーションにおいてもキーの衝突を防ぐことが可能です。 ② キャッシュ操作のためのカスタムフックでは QueryClient を利用したキャッシュ操作をまとめています。これは後述の mutations.ts で利用します。 CLINICS では 楽観的更新 をしない方針としているため、 invalidateQueries を実行する関数群のみを定義しています。 queries.ts queries.ts は次のように実装しています。 import { type Todo } from "@/viewModels/todo" ; import { todoApi , type GetTodoDetailRequest } from "@/api/generated" ; // ③ queryFn export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); return data . todoList ; }, getTodoDetail : async ( request : GetTodoDetailRequest ): Promise &#x3C; Todo > => { const { data } = await todoApi . getTodoDetail ( request ); return data . todo ; }, }; // ④ Request Selector export const request = { getTodoDetail : ( id : string | undefined ): GetTodoDetailRequest => { if ( id === undefined ) { // `enabled: false` となる条件の引数が与えられた場合例外とすることで、 // queryFn 内の型の整合性を保つ throw new InvalidRequestParameterError ( "Required parameter id was undefined when calling request.getTodoDetail." ); } return { id , }; }, }; ③ queryFn は、API へのリクエストを責務とした関数群です。 ここで使用している ApiClient や Request の型は openapi-generator から生成しています。 queryFn の戻り値の型は、後述の ViewModel で定義した型を明示 しています。 このようにフロントエンド側でサーバステートの型を別途定義することで、フロントエンドとバックエンドを分業して実装する際に開発しやすくなるメリットがあります。 省略していますが、レスポンスに応じたエラーの throw もここで行います。 ④ Request Selector は View から受け取った値をリクエストパラメータへマッピングすることを責務とした関数群です。 useQuery の条件付き実行を制御する enabled オプションで false となる条件を例外とすることで、queryFn 内で 型ガードをしなくて良い設計としています。 これらを使って View とのインターフェースとなる useQuery ラッパーを定義します。 // ⑤ Base Query // API Response を整形せずに返す export type UseTodoDetailQueryProps &#x3C; QueryResult > = { id : string | undefined ; select ?: ( data : Todo ) => QueryResult ; }; export function useTodoDetailQuery &#x3C; QueryResult = Todo >( props : UseTodoDetailQueryProps &#x3C; QueryResult > ) { return useQuery ({ queryKey: todoKeys . detail ( props . id ), queryFn : () => { return query . getTodoDetail ( request . getTodoDetail ( props . id )); }, enabled: !! props . id , select: props . select , useErrorBoundary: true , }); } import { selectTodoForm } from "@/viewModels/todo/todoForm" ; // ⑥ Selector Query // API Response を View で参照したいフォーマットに整形して返す export function useInitialTodoFormQuery () { // Base Query に select オプションを与える return useTodoDetailQuery ({ select: selectTodoForm , // selectTodoForm は Todo を TodoForm に変換する ViewModel Selector（後述） }); } useQuery ラッパーは、⑤ Base Query と ⑥ Selector Query に分けて定義しています。 CLINICS では同じデータソースに対して画面ごとに異なるフォーマットで表示することが多くあります。 Selector Query で 任意のフォーマットに整形することで、画面ごとに最適化されたデータの取得をスケーラブルに実現しています。 4 加えて、この手法では Selector にドメインロジックが凝集されるため、 Selector を重点的にテストすることで品質を担保しやすい メリットがあります。 Query のエラー制御は useErrorBoundary オプションを使って Error Boundary を表示する方針としています。 mutations.ts mutations.ts は次のように実装しています。 import { type TodoForm } from "@/viewModels/todo/todoForm" ; import { todoApi , type PostTodoRequest } "@/api/generated" ; // ⑦ mutationFn export const mutation = { createTodo : ( request : PostTodoRequest ) => { return todoApi . postTodo ( request ); }, }; // ⑧ Request Selector // ViewModel から API Request へ変換する export const request = { createTodo : ( todoForm : TodoForm ): PostTodoRequest => { return { PostTodoRequest : { todo : { title : todoForm . title , description : todoForm . description , status : todoForm . status , favorite : todoForm . favorite === "true" ? true : false , }, }, }; }, }; // ⑨ Custom Mutation export function useCreateTodoMutation () { const { invalidateList } = useTodoCache (); return useMutation ({ mutationFn : ( todoForm : TodoForm ) => { return mutation . createTodo ( request . createTodo ( todoForm )); }, onSuccess : () => { return invalidateList (); }, }); } 基本的な構成は queries.ts と同じです。 mutations.ts でも queries.ts と同様に ⑧ Request Selector を定義します。 Request Selector には、データ整形を扱うためドメインロジックが集まりやすいです。 そのため、入出力、境界値、例外のテストを積極的に書いて品質の担保に繋げています。 Mutation のエラーは画面ごとに UI でフィードバックするため、コンポーネント側で制御しています。 Resource Operation レイヤーに関する実装の紹介は以上です。 ViewModel の実装 ViewModel とは、View(React Component) で扱うデータのスキーマと型です。 Resource Operation の実装では、API Response を ViewModel に整形して View に提供することを紹介しました。 全体の理解を深めるため、ViewModel の実装も紹介します。 ディレクトリ構成 ViewModel は関心を分離するため Resource Operation とは別のディレクトリに定義しています。 src/viewModels └── todo ├── todo.ts # サーバステート ├── todoForm.test.ts # フロントエンドに閉じたスキーマのテスト ├── todoForm.ts # フロントエンドに閉じたスキーマ └── todoSearchCondition.ts # フロントエンドに閉じた型 ViewModel で定義するスキーマ・型は大きく分けて 3 つに分類されます。 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 サーバステート サーバステートは、 API Response として期待するデータのスキーマ及び型です。 前述の queries.ts 内の ③ queryFn で使用します。 zod を使って次のように実装しています。 // src/viewModels/todo/todo.ts // enum は View で &#x3C;option value={todoStatus.enum.ready} /> のように使用する export const todoStatus = z . enum ([ "ready" , "doing" , "done" ]); // ⑩ サーバステートのスキーマ // 開発中のみ ③ queryFn 内で API Response を parse することで、スキーマの不整合を検出するための補助輪として使用する export const todo = z . object ({ id: z . string (), title: z . string (), description: z . string (). nullable (), status: todoStatus , favorite: z . boolean (), }); // ⑪ サーバステートの型 // ③ queryFn の戻り値の型として使用する export type Todo = z . infer &#x3C; typeof todo >; ⑩ サーバステートのスキーマは、⑪ サーバステートの型の生成と開発時のスキーマ検証に使用しています。 開発時のみ API Response を検証することで、⑩ サーバステートのスキーマと Open API スキーマの整合性を確認しています。 // src/resourceOperations/todo/queries.ts import { todo , type Todo } from "@/viewModels/todo" ; export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); // 開発時、APIとの結合タイミングで検証してフロントエンドとバックエンドでスキーマの齟齬がないことを確認する // 検証が済んだら parse 処理を外す return data . todoList . map (( x ) => todo . parse ( x )); }, }; 例外として、 外部サービスから取得したデータに関しては常にサーバステートのスキーマを使って検証 しています。 例えば、外部サービスの仕様として長さが 1 以上の配列が返ってくると決まっていて、フロントエンド側もその仕様に基づいた処理を実装している場合、 z.array().min(1) のスキーマで常に検証します。 ネットワークに近い箇所で不正なデータを検出することで、例外発生時の調査を容易にするメリットがあると考えています。 フロントエンドに閉じたスキーマ フロントエンドに閉じたスキーマは、そのほとんどがフォームのバリデーションスキーマです。 こちらも zod を使って定義しています。 // src/viewModels/todo/todoForm.ts import { type Todo , todo } from "./todo" ; // フロントエンドに閉じたスキーマ // フォームのスキーマは react-hook-form と連携して使用する（省略） export const todoForm = z . object ({ title: z . string () . min ( 1 , "入力してください" ) . max ( 200 , "200字以内で入力してください" ), description: z . string (). max ( 500 , "500字以内で入力してください" ), status: todo . shape . status , favorite: z . union ([ z . literal ( "true" ), z . literal ( "false" )]), }); export type TodoForm = z . infer &#x3C; typeof todoForm >; // ⑫ ViewModel Selector // サーバステートからフロントエンドに閉じたスキーマへ変換する // 前述の queries.ts 内 ⑥ Selector Query で使用する export function selectTodoForm ( todo : Todo ): TodoForm { return { title: todo . title , description: todo . description ?? "" , status: todo . status , favorite: todo . favorite ? "true" : "false" , }; } フロントエンドに閉じたスキーマは、必ずサーバステートを元に生成する運用としています。 そのために、フロントエンドに閉じたスキーマを宣言した直下に、サーバステートからフロントエンドに閉じたスキーマへ変換する ⑫ ViewModel Selector を定義します。 null の 空文字への変換や時間データのフォーマットのような、 サーバステート と View で使う値の差分吸収はこのセレクタ内で行います。 このように、 ViewModel レイヤーでは他のレイヤーと依存しないようにドメインロジックを表現 しています。 ドメインロジックを Tanstack Query に依存しないことで、今後技術基盤を刷新する場合でも影響を最小限に留めることを狙いとしています。 フロントエンドに閉じた型 依存関係を整えるため、Resource Operation と View から参照するフロントエンドに閉じた型は viewModels 配下に宣言しています。 // src/viewModels/todo/todoSearchParams.ts export type TodoSearchCondition = { sort ?: "created_at_asc" | "created_at_desc" ; }; ViewModel に関する実装の紹介は以上です。 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 Tanstack Query を導入する以前の CLINICS の非同期処理周辺のコードベースではいくつかの課題がありました。 開発体験の課題 非同期処理のためのミニマムな基盤フックを独自に実装していた 5 ことにより、開発体験の観点で次のような課題がありました。 新しい要件（ポーリング・無限読み込み等）が発生した際に、最初に担当する開発者が都度機能拡張する必要がある テストが実装されていなかったため変更時に品質確認の負担が大きい 学習容易性の課題 上述の基盤フックにドキュメントがなかったため、学習容易性の観点で次のような課題がありました。 基盤フックにドキュメントがなく、新規メンバーの学習コストが高い 様々な実装手法が混在することで、実装時に迷いが生じている 可読性の課題 CLINICS は開発開始から約 7 年以上が経過しています。 その中でもフロントエンドは技術トレンドの変化が早いため、様々なライブラリやパターンを使って実装されています。 特に近年から漸進的に導入した React を使った実装については、明確な設計が確立されていませんでした。 これらの背景からチームで安定したアウトプットを出すことが困難で、可読性の観点で次のような課題がありました。 画面によってフックや関数の粒度、定義場所が違うことでコードリーディングの負荷が高い コードレビュー時のレビュワーの負担が大きい テスト容易性の課題 多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、テスト容易性の観点で次のような課題がありました。 テストが実装しづらい テストカバレッジが低い CLINICS はオンライン診療・電子カルテ等の医療機関業務を支える機能を提供する SaaS プラットフォームです。 今後長きに渡って多くの医療機関の方々に CLINICS を利用して頂くためには、 コードを読みやすく、変更しやすく、維持しやすい状態に保ち続けること が重要です。 前の章で紹介したアーキテクチャは 持続可能な開発を目指して 設計しました。 具体的には、 開発体験・学習容易性・可読性・テスト容易性を向上することを狙い としています。 狙い 1：Tanstack Query の導入による開発体験の向上 背景で説明したとおり、Tanstack Query 導入以前は独自実装したフックを使って非同期処理を実装していました。 Tanstack Query を導入したきっかけは、チーム内での雑談の中で、独自実装のフックが使いづらいという声が挙がったことです。 そこで、独自実装のフック自体の質を高めるか、質の高いライブラリを導入するかを議論した結果、次の理由でライブラリを導入する決定をしました。 極力自分たちでコードを書かずに非同期処理・状態管理の実装を実現したい 実装に困ったときにドキュメントを読めば解決する環境にしたい CLINICS では技術的な背景 6 から Tanstack Query と SWR が候補に上がりましたが、 select オプションや invalidateQueries の Partial Query Matching 等の機能性と、ドキュメントの充実度合いの観点から Tanstack Query を採用しました。 Tanstack Query を採用したことで、 非同期処理のためのコードの記述量が大幅に削減 されたほか、データの特性に応じて Query ごとにキャッシュの時間を調整することが可能となり開発体験が大幅に向上しました。 狙い 2：シンプルなレイヤー分割による学習容易性の向上 CLINICS では、事業の拡大にともないコードベースに関わるエンジニアが増え続けています。 実装の進め方はプロジェクトによって最適な形式を選択しています。 バックエンドからフロントエンドまで一気通貫で実装 技術領域に分けて分業 このように多くのエンジニアが様々な形で関わる環境では、コードベースの学習容易性を高め、実装からコードレビューの完了までをスムーズに行えることが重要です。 前の章で紹介したアーキテクチャは、 レイヤー分割をシンプルにすることでコードベースに慣れるまでの時間を最小限にする ことを意識しています。 加えて、 実装パターンを定形化することで、コードベースに馴染みがなくても迷いなく実装できる ほか、関数の粒度が統一されることで、コードレビューの負荷軽減にも繋がっています。 レイヤー分割の粒度や実装パターンについては、次の記事を参考にさせて頂きました。 フロントエンドアーキテクチャの話: Resource Set の紹介 ほかにも CLINICS では学習容易性の向上の取り組みとして、 新しいライブラリやアーキテクチャを導入した際は勉強会を開催 してライブラリの基本的な使い方や頻出の実装パターンに関する知見を共有しています。 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 アーキテクチャを刷新する以前は、多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、可読性やテスト容易性に支障をきたしていました。 CLINICS のフロントエンドには、医療システムに関する複雑なドメインロジックが多いため、 シンプルでテストしやすいコードベース を作っていくことがとりわけ重要だと考えています。 この課題は、ドメインロジックが集まる傾向にある queries.ts、 mutations.ts の Request Selector や ViewModel Selector の実装を定型化し、純粋関数で表現することにより解決しました。 まとめ Tanstack Query を使ったフロントエンドアーキテクチャの実例を紹介しました。 Resource Operation レイヤーに Tanstack Query の実装を定型化して集約しています。 レイヤー分割をシンプルにし、実装を定型化することで、開発組織のスケールに対応しています。 useQuery の select オプションを使い、スケーラブルにデータ変換処理を記述しています。 データ変換処理にはドメインロジックが集まりやすいため、なるべく小さい粒度の純粋関数で表現することで、可読性・テスト容易性の向上を狙っています。 この記事の内容が Tanstack Query の導入を考えている方の参考になれば幸いです。 さいごに CLINICS では、機能開発と並行してフロントエンド基盤を改善する取り組みも実施しています。 Redux から Tanstack Query への移行 UI ライブラリの Mithril から React への移行 7 デザインシステムの構築とプロダクトへの反映 このような取り組みに興味がある方は次のリンクから是非ご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp Footnotes Overview | TanStack Query Docs ↩ Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router | TanStack Query Docs ↩ この記事で紹介している ViewModel は View レイヤー専用のモデルを表す概念です。 MVVM アーキテクチャの ViewModel とは異なります。 ↩ Tanstack Query におけるデータ変換手法の詳細は React Query Data Transformations | TkDodo’s blog で紹介されています。 ↩ Tanstack Query 導入以前の非同期処理は useAsync React Hook - useHooks をカスタマイズしたフックを使って実装していました。 ↩ CLINICS では 一部の実装箇所で Redux を使用していますが、 RTK Query は今回採用するライブラリの候補から除外しました。これは、現在使用している Redux のバージョンが低く、レガシーな周辺ライブラリも複数使用している背景で Redux Toolkit への移行に相当な工数を必要とするためです。 ↩ 2023 年 3 月現在、 CLINICS のフロントエンドの 約 50% は、 Mithril と Redux で構成されています。開発体験の向上のため、 React への完全移行を目指して日々改善を続けています。 ↩

こんにちは。医療プラットフォーム第一本部プロダクト開発室所属エンジニアの髙橋です。 普段の業務では、 医療 SaaS プラットフォーム CLINICS の医療機関向けアプリケーション（以下、CLINICS）の開発を担当しています。 CLINICS では、昨年 10 月頃から React コードベースのリアーキテクチャに取り組んでいます。 その取り組みの 1 つとして、非同期状態管理に関連する実装を Tanstack Query を使って刷新しています。 この記事では、CLINICS における Tanstack Query の活用方法を導入背景と狙いを含めて紹介します。 目次 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Tanstack Query について Tanstack Query を活用したフロントエンドアーキテクチャ Resource Operation の実装 ディレクトリ構成 cache.ts queries.ts mutations.ts ViewModel の実装 ディレクトリ構成 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 狙い 1：Tanstack Query の導入による開発体験の向上 狙い 2：シンプルなレイヤー分割による学習容易性の向上 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 まとめ さいごに Tanstack Query について Tanstack Query は、Web アプリケーションのサーバ状態の取得、キャッシュ、同期、更新を簡単に行うことができるライブラリです。 1 類似ライブラリには SWR、Apollo Client、RTK Query 等が挙げられます。 2 私たちは、機能性・ドキュメントの充実度・コミュニティの将来性を総合的に判断した結果、Tanstack Query(React Query)を採用して React コードベースの再構築を進めています。 導入背景の詳細は、後のセクションで詳しく紹介します。 Tanstack Query を活用したフロントエンドアーキテクチャ それでは本題の Tanstack Query を活用したフロントエンドアーキテクチャについて紹介します。 始めに、アーキテクチャの全体像を示した次の図をご覧ください。 まず注目して頂きたいポイントは、Backend と View の間にある Resource Operation です。 Resource Operation は Tanstack Query を主軸に実装されているレイヤーです。 役割を大きく分類すると次の 2 つが挙げられます。 非同期状態管理に関連する実装の集約 Backend で扱うデータ(OpenAPI スキーマ)と View で扱うデータ(ViewModel)の相互変換 全体像を把握するために、左右のレイヤーにも注目してください。 右の Backend は CLINICS では Ruby on Rails で実装された REST API を提供するモノリシックなサーバです。 API で扱うスキーマは OpenAPI を使って定義しています。 OpenAPI スキーマは、 committee-rails を使ったレスポンス検証と、 openapi-generator を使った API クライアントコードの自動生成に活用しています。 左の View は CLINICS では React で実装されたコンポーネントになります。 View では Backend の OpenAPI スキーマを直接参照することを避け、 ViewModel と呼ばれるフロントエンドで定義したモデル 3 のみを参照する設計としています。 Resource Operation は View と Backend の境界レイヤーとして非同期状態管理とデータの相互変換を行うシンプルなレイヤーとなっています。 続いて、上記の運用のための実装詳細を紹介します。 Resource Operation の実装 ディレクトリ構成 Resource Operation レイヤーでは、リソースごとに非同期状態管理とデータの相互変換の処理をまとめています。 ディレクトリツリーで Resource Operation レイヤー全体を表現すると次のようになります。 src/resourceOperations ├── resourceTagName # 例： todo │ ├── cache.ts │ ├── mutations.ts │ └── queries.ts └── resourceGroupTagName # 例： systemSettings（リソースに階層がある場合） └── resourceTagName # 例： organization（リソースグループ配下のリソース） ├── cache.ts ├── mutations.ts └── queries.ts ディレクトリ名の resourceTagName と resourceGroupTagName は OpenAPI スキーマでエンドポイントごとに割り振られている tag を元に命名しています。 ディレクトリごとに 次の 3 つのファイルを定義しています。 ファイル 役割 cache.ts Query Key の定義、キャッシュ操作のためのカスタムフックの定義 queries.ts useQuery をラップしたカスタムフックの定義、API Request/Response の整形 mutations.ts useMutation をラップしたカスタムフックの定義、API Request の整形 cache.ts cache.ts は次のように実装しています。 // ① Query Key // queries.ts がある場合に必要に応じて宣言 export const todoKeys = { all: [ "todo" ] as const , list : () => [... todoKeys . all , "list" ] as const , paginateList : ( page ?: number ) => [... todoKeys . list (), { page }] as const , detail : ( id : string ) => [... todoKeys . all , "detail" , id ] as const , }; // ② キャッシュ操作のためのカスタムフック // mutations.ts がある場合に必要に応じて宣言 export function useTodoCache () { const queryClient = useQueryClient (); return useMemo ( () => ({ invalidateList : () => queryClient . invalidateQueries ( todoKeys . list ()), invalidateDetail : ( id : string ) => queryClient . invalidateQueries ( todoKeys . detail ( id )), }), [ queryClient ] ); } ① Query Key は、 useQuery の queryKey オプションに与える値を定義した定数です。これは後述の queries.ts で利用します。 実装は Tanstack Query メンテナの Dominik さんのブログで紹介されている Query Key factories パターンを使っています。 ディレクトリ名を all の値とすることで、大規模なアプリケーションにおいてもキーの衝突を防ぐことが可能です。 ② キャッシュ操作のためのカスタムフックでは QueryClient を利用したキャッシュ操作をまとめています。これは後述の mutations.ts で利用します。 CLINICS では 楽観的更新 をしない方針としているため、 invalidateQueries を実行する関数群のみを定義しています。 queries.ts queries.ts は次のように実装しています。 import { type Todo } from "@/viewModels/todo" ; import { todoApi , type GetTodoDetailRequest } from "@/api/generated" ; // ③ queryFn export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); return data . todoList ; }, getTodoDetail : async ( request : GetTodoDetailRequest ): Promise &#x3C; Todo > => { const { data } = await todoApi . getTodoDetail ( request ); return data . todo ; }, }; // ④ Request Selector export const request = { getTodoDetail : ( id : string | undefined ): GetTodoDetailRequest => { if ( id === undefined ) { // `enabled: false` となる条件の引数が与えられた場合例外とすることで、 // queryFn 内の型の整合性を保つ throw new InvalidRequestParameterError ( "Required parameter id was undefined when calling request.getTodoDetail." ); } return { id , }; }, }; ③ queryFn は、API へのリクエストを責務とした関数群です。 ここで使用している ApiClient や Request の型は openapi-generator から生成しています。 queryFn の戻り値の型は、後述の ViewModel で定義した型を明示 しています。 このようにフロントエンド側でサーバステートの型を別途定義することで、フロントエンドとバックエンドを分業して実装する際に開発しやすくなるメリットがあります。 省略していますが、レスポンスに応じたエラーの throw もここで行います。 ④ Request Selector は View から受け取った値をリクエストパラメータへマッピングすることを責務とした関数群です。 useQuery の条件付き実行を制御する enabled オプションで false となる条件を例外とすることで、queryFn 内で 型ガードをしなくて良い設計としています。 これらを使って View とのインターフェースとなる useQuery ラッパーを定義します。 // ⑤ Base Query // API Response を整形せずに返す export type UseTodoDetailQueryProps &#x3C; QueryResult > = { id : string | undefined ; select ?: ( data : Todo ) => QueryResult ; }; export function useTodoDetailQuery &#x3C; QueryResult = Todo >( props : UseTodoDetailQueryProps &#x3C; QueryResult > ) { return useQuery ({ queryKey: todoKeys . detail ( props . id ), queryFn : () => { return query . getTodoDetail ( request . getTodoDetail ( props . id )); }, enabled: !! props . id , select: props . select , useErrorBoundary: true , }); } import { selectTodoForm } from "@/viewModels/todo/todoForm" ; // ⑥ Selector Query // API Response を View で参照したいフォーマットに整形して返す export function useInitialTodoFormQuery () { // Base Query に select オプションを与える return useTodoDetailQuery ({ select: selectTodoForm , // selectTodoForm は Todo を TodoForm に変換する ViewModel Selector（後述） }); } useQuery ラッパーは、⑤ Base Query と ⑥ Selector Query に分けて定義しています。 CLINICS では同じデータソースに対して画面ごとに異なるフォーマットで表示することが多くあります。 Selector Query で 任意のフォーマットに整形することで、画面ごとに最適化されたデータの取得をスケーラブルに実現しています。 4 加えて、この手法では Selector にドメインロジックが凝集されるため、 Selector を重点的にテストすることで品質を担保しやすい メリットがあります。 Query のエラー制御は useErrorBoundary オプションを使って Error Boundary を表示する方針としています。 mutations.ts mutations.ts は次のように実装しています。 import { type TodoForm } from "@/viewModels/todo/todoForm" ; import { todoApi , type PostTodoRequest } "@/api/generated" ; // ⑦ mutationFn export const mutation = { createTodo : ( request : PostTodoRequest ) => { return todoApi . postTodo ( request ); }, }; // ⑧ Request Selector // ViewModel から API Request へ変換する export const request = { createTodo : ( todoForm : TodoForm ): PostTodoRequest => { return { PostTodoRequest : { todo : { title : todoForm . title , description : todoForm . description , status : todoForm . status , favorite : todoForm . favorite === "true" ? true : false , }, }, }; }, }; // ⑨ Custom Mutation export function useCreateTodoMutation () { const { invalidateList } = useTodoCache (); return useMutation ({ mutationFn : ( todoForm : TodoForm ) => { return mutation . createTodo ( request . createTodo ( todoForm )); }, onSuccess : () => { return invalidateList (); }, }); } 基本的な構成は queries.ts と同じです。 mutations.ts でも queries.ts と同様に ⑧ Request Selector を定義します。 Request Selector には、データ整形を扱うためドメインロジックが集まりやすいです。 そのため、入出力、境界値、例外のテストを積極的に書いて品質の担保に繋げています。 Mutation のエラーは画面ごとに UI でフィードバックするため、コンポーネント側で制御しています。 Resource Operation レイヤーに関する実装の紹介は以上です。 ViewModel の実装 ViewModel とは、View(React Component) で扱うデータのスキーマと型です。 Resource Operation の実装では、API Response を ViewModel に整形して View に提供することを紹介しました。 全体の理解を深めるため、ViewModel の実装も紹介します。 ディレクトリ構成 ViewModel は関心を分離するため Resource Operation とは別のディレクトリに定義しています。 src/viewModels └── todo ├── todo.ts # サーバステート ├── todoForm.test.ts # フロントエンドに閉じたスキーマのテスト ├── todoForm.ts # フロントエンドに閉じたスキーマ └── todoSearchCondition.ts # フロントエンドに閉じた型 ViewModel で定義するスキーマ・型は大きく分けて 3 つに分類されます。 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 サーバステート サーバステートは、 API Response として期待するデータのスキーマ及び型です。 前述の queries.ts 内の ③ queryFn で使用します。 zod を使って次のように実装しています。 // src/viewModels/todo/todo.ts // enum は View で &#x3C;option value={todoStatus.enum.ready} /> のように使用する export const todoStatus = z . enum ([ "ready" , "doing" , "done" ]); // ⑩ サーバステートのスキーマ // 開発中のみ ③ queryFn 内で API Response を parse することで、スキーマの不整合を検出するための補助輪として使用する export const todo = z . object ({ id: z . string (), title: z . string (), description: z . string (). nullable (), status: todoStatus , favorite: z . boolean (), }); // ⑪ サーバステートの型 // ③ queryFn の戻り値の型として使用する export type Todo = z . infer &#x3C; typeof todo >; ⑩ サーバステートのスキーマは、⑪ サーバステートの型の生成と開発時のスキーマ検証に使用しています。 開発時のみ API Response を検証することで、⑩ サーバステートのスキーマと Open API スキーマの整合性を確認しています。 // src/resourceOperations/todo/queries.ts import { todo , type Todo } from "@/viewModels/todo" ; export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); // 開発時、APIとの結合タイミングで検証してフロントエンドとバックエンドでスキーマの齟齬がないことを確認する // 検証が済んだら parse 処理を外す return data . todoList . map (( x ) => todo . parse ( x )); }, }; 例外として、 外部サービスから取得したデータに関しては常にサーバステートのスキーマを使って検証 しています。 例えば、外部サービスの仕様として長さが 1 以上の配列が返ってくると決まっていて、フロントエンド側もその仕様に基づいた処理を実装している場合、 z.array().min(1) のスキーマで常に検証します。 ネットワークに近い箇所で不正なデータを検出することで、例外発生時の調査を容易にするメリットがあると考えています。 フロントエンドに閉じたスキーマ フロントエンドに閉じたスキーマは、そのほとんどがフォームのバリデーションスキーマです。 こちらも zod を使って定義しています。 // src/viewModels/todo/todoForm.ts import { type Todo , todo } from "./todo" ; // フロントエンドに閉じたスキーマ // フォームのスキーマは react-hook-form と連携して使用する（省略） export const todoForm = z . object ({ title: z . string () . min ( 1 , "入力してください" ) . max ( 200 , "200字以内で入力してください" ), description: z . string (). max ( 500 , "500字以内で入力してください" ), status: todo . shape . status , favorite: z . union ([ z . literal ( "true" ), z . literal ( "false" )]), }); export type TodoForm = z . infer &#x3C; typeof todoForm >; // ⑫ ViewModel Selector // サーバステートからフロントエンドに閉じたスキーマへ変換する // 前述の queries.ts 内 ⑥ Selector Query で使用する export function selectTodoForm ( todo : Todo ): TodoForm { return { title: todo . title , description: todo . description ?? "" , status: todo . status , favorite: todo . favorite ? "true" : "false" , }; } フロントエンドに閉じたスキーマは、必ずサーバステートを元に生成する運用としています。 そのために、フロントエンドに閉じたスキーマを宣言した直下に、サーバステートからフロントエンドに閉じたスキーマへ変換する ⑫ ViewModel Selector を定義します。 null の 空文字への変換や時間データのフォーマットのような、 サーバステート と View で使う値の差分吸収はこのセレクタ内で行います。 このように、 ViewModel レイヤーでは他のレイヤーと依存しないようにドメインロジックを表現 しています。 ドメインロジックを Tanstack Query に依存しないことで、今後技術基盤を刷新する場合でも影響を最小限に留めることを狙いとしています。 フロントエンドに閉じた型 依存関係を整えるため、Resource Operation と View から参照するフロントエンドに閉じた型は viewModels 配下に宣言しています。 // src/viewModels/todo/todoSearchParams.ts export type TodoSearchCondition = { sort ?: "created_at_asc" | "created_at_desc" ; }; ViewModel に関する実装の紹介は以上です。 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 Tanstack Query を導入する以前の CLINICS の非同期処理周辺のコードベースではいくつかの課題がありました。 開発体験の課題 非同期処理のためのミニマムな基盤フックを独自に実装していた 5 ことにより、開発体験の観点で次のような課題がありました。 新しい要件（ポーリング・無限読み込み等）が発生した際に、最初に担当する開発者が都度機能拡張する必要がある テストが実装されていなかったため変更時に品質確認の負担が大きい 学習容易性の課題 上述の基盤フックにドキュメントがなかったため、学習容易性の観点で次のような課題がありました。 基盤フックにドキュメントがなく、新規メンバーの学習コストが高い 様々な実装手法が混在することで、実装時に迷いが生じている 可読性の課題 CLINICS は開発開始から約 7 年以上が経過しています。 その中でもフロントエンドは技術トレンドの変化が早いため、様々なライブラリやパターンを使って実装されています。 特に近年から漸進的に導入した React を使った実装については、明確な設計が確立されていませんでした。 これらの背景からチームで安定したアウトプットを出すことが困難で、可読性の観点で次のような課題がありました。 画面によってフックや関数の粒度、定義場所が違うことでコードリーディングの負荷が高い コードレビュー時のレビュワーの負担が大きい テスト容易性の課題 多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、テスト容易性の観点で次のような課題がありました。 テストが実装しづらい テストカバレッジが低い CLINICS はオンライン診療・電子カルテ等の医療機関業務を支える機能を提供する SaaS プラットフォームです。 今後長きに渡って多くの医療機関の方々に CLINICS を利用して頂くためには、 コードを読みやすく、変更しやすく、維持しやすい状態に保ち続けること が重要です。 前の章で紹介したアーキテクチャは 持続可能な開発を目指して 設計しました。 具体的には、 開発体験・学習容易性・可読性・テスト容易性を向上することを狙い としています。 狙い 1：Tanstack Query の導入による開発体験の向上 背景で説明したとおり、Tanstack Query 導入以前は独自実装したフックを使って非同期処理を実装していました。 Tanstack Query を導入したきっかけは、チーム内での雑談の中で、独自実装のフックが使いづらいという声が挙がったことです。 そこで、独自実装のフック自体の質を高めるか、質の高いライブラリを導入するかを議論した結果、次の理由でライブラリを導入する決定をしました。 極力自分たちでコードを書かずに非同期処理・状態管理の実装を実現したい 実装に困ったときにドキュメントを読めば解決する環境にしたい CLINICS では技術的な背景 6 から Tanstack Query と SWR が候補に上がりましたが、 select オプションや invalidateQueries の Partial Query Matching 等の機能性と、ドキュメントの充実度合いの観点から Tanstack Query を採用しました。 Tanstack Query を採用したことで、 非同期処理のためのコードの記述量が大幅に削減 されたほか、データの特性に応じて Query ごとにキャッシュの時間を調整することが可能となり開発体験が大幅に向上しました。 狙い 2：シンプルなレイヤー分割による学習容易性の向上 CLINICS では、事業の拡大にともないコードベースに関わるエンジニアが増え続けています。 実装の進め方はプロジェクトによって最適な形式を選択しています。 バックエンドからフロントエンドまで一気通貫で実装 技術領域に分けて分業 このように多くのエンジニアが様々な形で関わる環境では、コードベースの学習容易性を高め、実装からコードレビューの完了までをスムーズに行えることが重要です。 前の章で紹介したアーキテクチャは、 レイヤー分割をシンプルにすることでコードベースに慣れるまでの時間を最小限にする ことを意識しています。 加えて、 実装パターンを定形化することで、コードベースに馴染みがなくても迷いなく実装できる ほか、関数の粒度が統一されることで、コードレビューの負荷軽減にも繋がっています。 レイヤー分割の粒度や実装パターンについては、次の記事を参考にさせて頂きました。 フロントエンドアーキテクチャの話: Resource Set の紹介 ほかにも CLINICS では学習容易性の向上の取り組みとして、 新しいライブラリやアーキテクチャを導入した際は勉強会を開催 してライブラリの基本的な使い方や頻出の実装パターンに関する知見を共有しています。 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 アーキテクチャを刷新する以前は、多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、可読性やテスト容易性に支障をきたしていました。 CLINICS のフロントエンドには、医療システムに関する複雑なドメインロジックが多いため、 シンプルでテストしやすいコードベース を作っていくことがとりわけ重要だと考えています。 この課題は、ドメインロジックが集まる傾向にある queries.ts、 mutations.ts の Request Selector や ViewModel Selector の実装を定型化し、純粋関数で表現することにより解決しました。 まとめ Tanstack Query を使ったフロントエンドアーキテクチャの実例を紹介しました。 Resource Operation レイヤーに Tanstack Query の実装を定型化して集約しています。 レイヤー分割をシンプルにし、実装を定型化することで、開発組織のスケールに対応しています。 useQuery の select オプションを使い、スケーラブルにデータ変換処理を記述しています。 データ変換処理にはドメインロジックが集まりやすいため、なるべく小さい粒度の純粋関数で表現することで、可読性・テスト容易性の向上を狙っています。 この記事の内容が Tanstack Query の導入を考えている方の参考になれば幸いです。 さいごに CLINICS では、機能開発と並行してフロントエンド基盤を改善する取り組みも実施しています。 Redux から Tanstack Query への移行 UI ライブラリの Mithril から React への移行 7 デザインシステムの構築とプロダクトへの反映 このような取り組みに興味がある方は次のリンクから是非ご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp Footnotes Overview | TanStack Query Docs ↩ Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router | TanStack Query Docs ↩ この記事で紹介している ViewModel は View レイヤー専用のモデルを表す概念です。 MVVM アーキテクチャの ViewModel とは異なります。 ↩ Tanstack Query におけるデータ変換手法の詳細は React Query Data Transformations | TkDodo’s blog で紹介されています。 ↩ Tanstack Query 導入以前の非同期処理は useAsync React Hook - useHooks をカスタマイズしたフックを使って実装していました。 ↩ CLINICS では 一部の実装箇所で Redux を使用していますが、 RTK Query は今回採用するライブラリの候補から除外しました。これは、現在使用している Redux のバージョンが低く、レガシーな周辺ライブラリも複数使用している背景で Redux Toolkit への移行に相当な工数を必要とするためです。 ↩ 2023 年 3 月現在、 CLINICS のフロントエンドの 約 50% は、 Mithril と Redux で構成されています。開発体験の向上のため、 React への完全移行を目指して日々改善を続けています。 ↩

こんにちは。医療プラットフォーム第一本部プロダクト開発室所属エンジニアの髙橋です。 普段の業務では、 医療 SaaS プラットフォーム CLINICS の医療機関向けアプリケーション（以下、CLINICS）の開発を担当しています。 CLINICS では、昨年 10 月頃から React コードベースのリアーキテクチャに取り組んでいます。 その取り組みの 1 つとして、非同期状態管理に関連する実装を Tanstack Query を使って刷新しています。 この記事では、CLINICS における Tanstack Query の活用方法を導入背景と狙いを含めて紹介します。 目次 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Tanstack Query について Tanstack Query を活用したフロントエンドアーキテクチャ Resource Operation の実装 ディレクトリ構成 cache.ts queries.ts mutations.ts ViewModel の実装 ディレクトリ構成 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 狙い 1：Tanstack Query の導入による開発体験の向上 狙い 2：シンプルなレイヤー分割による学習容易性の向上 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 まとめ さいごに Tanstack Query について Tanstack Query は、Web アプリケーションのサーバ状態の取得、キャッシュ、同期、更新を簡単に行うことができるライブラリです。 1 類似ライブラリには SWR、Apollo Client、RTK Query 等が挙げられます。 2 私たちは、機能性・ドキュメントの充実度・コミュニティの将来性を総合的に判断した結果、Tanstack Query(React Query)を採用して React コードベースの再構築を進めています。 導入背景の詳細は、後のセクションで詳しく紹介します。 Tanstack Query を活用したフロントエンドアーキテクチャ それでは本題の Tanstack Query を活用したフロントエンドアーキテクチャについて紹介します。 始めに、アーキテクチャの全体像を示した次の図をご覧ください。 まず注目して頂きたいポイントは、Backend と View の間にある Resource Operation です。 Resource Operation は Tanstack Query を主軸に実装されているレイヤーです。 役割を大きく分類すると次の 2 つが挙げられます。 非同期状態管理に関連する実装の集約 Backend で扱うデータ(OpenAPI スキーマ)と View で扱うデータ(ViewModel)の相互変換 全体像を把握するために、左右のレイヤーにも注目してください。 右の Backend は CLINICS では Ruby on Rails で実装された REST API を提供するモノリシックなサーバです。 API で扱うスキーマは OpenAPI を使って定義しています。 OpenAPI スキーマは、 committee-rails を使ったレスポンス検証と、 openapi-generator を使った API クライアントコードの自動生成に活用しています。 左の View は CLINICS では React で実装されたコンポーネントになります。 View では Backend の OpenAPI スキーマを直接参照することを避け、 ViewModel と呼ばれるフロントエンドで定義したモデル 3 のみを参照する設計としています。 Resource Operation は View と Backend の境界レイヤーとして非同期状態管理とデータの相互変換を行うシンプルなレイヤーとなっています。 続いて、上記の運用のための実装詳細を紹介します。 Resource Operation の実装 ディレクトリ構成 Resource Operation レイヤーでは、リソースごとに非同期状態管理とデータの相互変換の処理をまとめています。 ディレクトリツリーで Resource Operation レイヤー全体を表現すると次のようになります。 src/resourceOperations ├── resourceTagName # 例： todo │ ├── cache.ts │ ├── mutations.ts │ └── queries.ts └── resourceGroupTagName # 例： systemSettings（リソースに階層がある場合） └── resourceTagName # 例： organization（リソースグループ配下のリソース） ├── cache.ts ├── mutations.ts └── queries.ts ディレクトリ名の resourceTagName と resourceGroupTagName は OpenAPI スキーマでエンドポイントごとに割り振られている tag を元に命名しています。 ディレクトリごとに 次の 3 つのファイルを定義しています。 ファイル 役割 cache.ts Query Key の定義、キャッシュ操作のためのカスタムフックの定義 queries.ts useQuery をラップしたカスタムフックの定義、API Request/Response の整形 mutations.ts useMutation をラップしたカスタムフックの定義、API Request の整形 cache.ts cache.ts は次のように実装しています。 // ① Query Key // queries.ts がある場合に必要に応じて宣言 export const todoKeys = { all: [ "todo" ] as const , list : () => [... todoKeys . all , "list" ] as const , paginateList : ( page ?: number ) => [... todoKeys . list (), { page }] as const , detail : ( id : string ) => [... todoKeys . all , "detail" , id ] as const , }; // ② キャッシュ操作のためのカスタムフック // mutations.ts がある場合に必要に応じて宣言 export function useTodoCache () { const queryClient = useQueryClient (); return useMemo ( () => ({ invalidateList : () => queryClient . invalidateQueries ( todoKeys . list ()), invalidateDetail : ( id : string ) => queryClient . invalidateQueries ( todoKeys . detail ( id )), }), [ queryClient ] ); } ① Query Key は、 useQuery の queryKey オプションに与える値を定義した定数です。これは後述の queries.ts で利用します。 実装は Tanstack Query メンテナの Dominik さんのブログで紹介されている Query Key factories パターンを使っています。 ディレクトリ名を all の値とすることで、大規模なアプリケーションにおいてもキーの衝突を防ぐことが可能です。 ② キャッシュ操作のためのカスタムフックでは QueryClient を利用したキャッシュ操作をまとめています。これは後述の mutations.ts で利用します。 CLINICS では 楽観的更新 をしない方針としているため、 invalidateQueries を実行する関数群のみを定義しています。 queries.ts queries.ts は次のように実装しています。 import { type Todo } from "@/viewModels/todo" ; import { todoApi , type GetTodoDetailRequest } from "@/api/generated" ; // ③ queryFn export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); return data . todoList ; }, getTodoDetail : async ( request : GetTodoDetailRequest ): Promise &#x3C; Todo > => { const { data } = await todoApi . getTodoDetail ( request ); return data . todo ; }, }; // ④ Request Selector export const request = { getTodoDetail : ( id : string | undefined ): GetTodoDetailRequest => { if ( id === undefined ) { // `enabled: false` となる条件の引数が与えられた場合例外とすることで、 // queryFn 内の型の整合性を保つ throw new InvalidRequestParameterError ( "Required parameter id was undefined when calling request.getTodoDetail." ); } return { id , }; }, }; ③ queryFn は、API へのリクエストを責務とした関数群です。 ここで使用している ApiClient や Request の型は openapi-generator から生成しています。 queryFn の戻り値の型は、後述の ViewModel で定義した型を明示 しています。 このようにフロントエンド側でサーバステートの型を別途定義することで、フロントエンドとバックエンドを分業して実装する際に開発しやすくなるメリットがあります。 省略していますが、レスポンスに応じたエラーの throw もここで行います。 ④ Request Selector は View から受け取った値をリクエストパラメータへマッピングすることを責務とした関数群です。 useQuery の条件付き実行を制御する enabled オプションで false となる条件を例外とすることで、queryFn 内で 型ガードをしなくて良い設計としています。 これらを使って View とのインターフェースとなる useQuery ラッパーを定義します。 // ⑤ Base Query // API Response を整形せずに返す export type UseTodoDetailQueryProps &#x3C; QueryResult > = { id : string | undefined ; select ?: ( data : Todo ) => QueryResult ; }; export function useTodoDetailQuery &#x3C; QueryResult = Todo >( props : UseTodoDetailQueryProps &#x3C; QueryResult > ) { return useQuery ({ queryKey: todoKeys . detail ( props . id ), queryFn : () => { return query . getTodoDetail ( request . getTodoDetail ( props . id )); }, enabled: !! props . id , select: props . select , useErrorBoundary: true , }); } import { selectTodoForm } from "@/viewModels/todo/todoForm" ; // ⑥ Selector Query // API Response を View で参照したいフォーマットに整形して返す export function useInitialTodoFormQuery () { // Base Query に select オプションを与える return useTodoDetailQuery ({ select: selectTodoForm , // selectTodoForm は Todo を TodoForm に変換する ViewModel Selector（後述） }); } useQuery ラッパーは、⑤ Base Query と ⑥ Selector Query に分けて定義しています。 CLINICS では同じデータソースに対して画面ごとに異なるフォーマットで表示することが多くあります。 Selector Query で 任意のフォーマットに整形することで、画面ごとに最適化されたデータの取得をスケーラブルに実現しています。 4 加えて、この手法では Selector にドメインロジックが凝集されるため、 Selector を重点的にテストすることで品質を担保しやすい メリットがあります。 Query のエラー制御は useErrorBoundary オプションを使って Error Boundary を表示する方針としています。 mutations.ts mutations.ts は次のように実装しています。 import { type TodoForm } from "@/viewModels/todo/todoForm" ; import { todoApi , type PostTodoRequest } "@/api/generated" ; // ⑦ mutationFn export const mutation = { createTodo : ( request : PostTodoRequest ) => { return todoApi . postTodo ( request ); }, }; // ⑧ Request Selector // ViewModel から API Request へ変換する export const request = { createTodo : ( todoForm : TodoForm ): PostTodoRequest => { return { PostTodoRequest : { todo : { title : todoForm . title , description : todoForm . description , status : todoForm . status , favorite : todoForm . favorite === "true" ? true : false , }, }, }; }, }; // ⑨ Custom Mutation export function useCreateTodoMutation () { const { invalidateList } = useTodoCache (); return useMutation ({ mutationFn : ( todoForm : TodoForm ) => { return mutation . createTodo ( request . createTodo ( todoForm )); }, onSuccess : () => { return invalidateList (); }, }); } 基本的な構成は queries.ts と同じです。 mutations.ts でも queries.ts と同様に ⑧ Request Selector を定義します。 Request Selector には、データ整形を扱うためドメインロジックが集まりやすいです。 そのため、入出力、境界値、例外のテストを積極的に書いて品質の担保に繋げています。 Mutation のエラーは画面ごとに UI でフィードバックするため、コンポーネント側で制御しています。 Resource Operation レイヤーに関する実装の紹介は以上です。 ViewModel の実装 ViewModel とは、View(React Component) で扱うデータのスキーマと型です。 Resource Operation の実装では、API Response を ViewModel に整形して View に提供することを紹介しました。 全体の理解を深めるため、ViewModel の実装も紹介します。 ディレクトリ構成 ViewModel は関心を分離するため Resource Operation とは別のディレクトリに定義しています。 src/viewModels └── todo ├── todo.ts # サーバステート ├── todoForm.test.ts # フロントエンドに閉じたスキーマのテスト ├── todoForm.ts # フロントエンドに閉じたスキーマ └── todoSearchCondition.ts # フロントエンドに閉じた型 ViewModel で定義するスキーマ・型は大きく分けて 3 つに分類されます。 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 サーバステート サーバステートは、 API Response として期待するデータのスキーマ及び型です。 前述の queries.ts 内の ③ queryFn で使用します。 zod を使って次のように実装しています。 // src/viewModels/todo/todo.ts // enum は View で &#x3C;option value={todoStatus.enum.ready} /> のように使用する export const todoStatus = z . enum ([ "ready" , "doing" , "done" ]); // ⑩ サーバステートのスキーマ // 開発中のみ ③ queryFn 内で API Response を parse することで、スキーマの不整合を検出するための補助輪として使用する export const todo = z . object ({ id: z . string (), title: z . string (), description: z . string (). nullable (), status: todoStatus , favorite: z . boolean (), }); // ⑪ サーバステートの型 // ③ queryFn の戻り値の型として使用する export type Todo = z . infer &#x3C; typeof todo >; ⑩ サーバステートのスキーマは、⑪ サーバステートの型の生成と開発時のスキーマ検証に使用しています。 開発時のみ API Response を検証することで、⑩ サーバステートのスキーマと Open API スキーマの整合性を確認しています。 // src/resourceOperations/todo/queries.ts import { todo , type Todo } from "@/viewModels/todo" ; export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); // 開発時、APIとの結合タイミングで検証してフロントエンドとバックエンドでスキーマの齟齬がないことを確認する // 検証が済んだら parse 処理を外す return data . todoList . map (( x ) => todo . parse ( x )); }, }; 例外として、 外部サービスから取得したデータに関しては常にサーバステートのスキーマを使って検証 しています。 例えば、外部サービスの仕様として長さが 1 以上の配列が返ってくると決まっていて、フロントエンド側もその仕様に基づいた処理を実装している場合、 z.array().min(1) のスキーマで常に検証します。 ネットワークに近い箇所で不正なデータを検出することで、例外発生時の調査を容易にするメリットがあると考えています。 フロントエンドに閉じたスキーマ フロントエンドに閉じたスキーマは、そのほとんどがフォームのバリデーションスキーマです。 こちらも zod を使って定義しています。 // src/viewModels/todo/todoForm.ts import { type Todo , todo } from "./todo" ; // フロントエンドに閉じたスキーマ // フォームのスキーマは react-hook-form と連携して使用する（省略） export const todoForm = z . object ({ title: z . string () . min ( 1 , "入力してください" ) . max ( 200 , "200字以内で入力してください" ), description: z . string (). max ( 500 , "500字以内で入力してください" ), status: todo . shape . status , favorite: z . union ([ z . literal ( "true" ), z . literal ( "false" )]), }); export type TodoForm = z . infer &#x3C; typeof todoForm >; // ⑫ ViewModel Selector // サーバステートからフロントエンドに閉じたスキーマへ変換する // 前述の queries.ts 内 ⑥ Selector Query で使用する export function selectTodoForm ( todo : Todo ): TodoForm { return { title: todo . title , description: todo . description ?? "" , status: todo . status , favorite: todo . favorite ? "true" : "false" , }; } フロントエンドに閉じたスキーマは、必ずサーバステートを元に生成する運用としています。 そのために、フロントエンドに閉じたスキーマを宣言した直下に、サーバステートからフロントエンドに閉じたスキーマへ変換する ⑫ ViewModel Selector を定義します。 null の 空文字への変換や時間データのフォーマットのような、 サーバステート と View で使う値の差分吸収はこのセレクタ内で行います。 このように、 ViewModel レイヤーでは他のレイヤーと依存しないようにドメインロジックを表現 しています。 ドメインロジックを Tanstack Query に依存しないことで、今後技術基盤を刷新する場合でも影響を最小限に留めることを狙いとしています。 フロントエンドに閉じた型 依存関係を整えるため、Resource Operation と View から参照するフロントエンドに閉じた型は viewModels 配下に宣言しています。 // src/viewModels/todo/todoSearchParams.ts export type TodoSearchCondition = { sort ?: "created_at_asc" | "created_at_desc" ; }; ViewModel に関する実装の紹介は以上です。 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 Tanstack Query を導入する以前の CLINICS の非同期処理周辺のコードベースではいくつかの課題がありました。 開発体験の課題 非同期処理のためのミニマムな基盤フックを独自に実装していた 5 ことにより、開発体験の観点で次のような課題がありました。 新しい要件（ポーリング・無限読み込み等）が発生した際に、最初に担当する開発者が都度機能拡張する必要がある テストが実装されていなかったため変更時に品質確認の負担が大きい 学習容易性の課題 上述の基盤フックにドキュメントがなかったため、学習容易性の観点で次のような課題がありました。 基盤フックにドキュメントがなく、新規メンバーの学習コストが高い 様々な実装手法が混在することで、実装時に迷いが生じている 可読性の課題 CLINICS は開発開始から約 7 年以上が経過しています。 その中でもフロントエンドは技術トレンドの変化が早いため、様々なライブラリやパターンを使って実装されています。 特に近年から漸進的に導入した React を使った実装については、明確な設計が確立されていませんでした。 これらの背景からチームで安定したアウトプットを出すことが困難で、可読性の観点で次のような課題がありました。 画面によってフックや関数の粒度、定義場所が違うことでコードリーディングの負荷が高い コードレビュー時のレビュワーの負担が大きい テスト容易性の課題 多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、テスト容易性の観点で次のような課題がありました。 テストが実装しづらい テストカバレッジが低い CLINICS はオンライン診療・電子カルテ等の医療機関業務を支える機能を提供する SaaS プラットフォームです。 今後長きに渡って多くの医療機関の方々に CLINICS を利用して頂くためには、 コードを読みやすく、変更しやすく、維持しやすい状態に保ち続けること が重要です。 前の章で紹介したアーキテクチャは 持続可能な開発を目指して 設計しました。 具体的には、 開発体験・学習容易性・可読性・テスト容易性を向上することを狙い としています。 狙い 1：Tanstack Query の導入による開発体験の向上 背景で説明したとおり、Tanstack Query 導入以前は独自実装したフックを使って非同期処理を実装していました。 Tanstack Query を導入したきっかけは、チーム内での雑談の中で、独自実装のフックが使いづらいという声が挙がったことです。 そこで、独自実装のフック自体の質を高めるか、質の高いライブラリを導入するかを議論した結果、次の理由でライブラリを導入する決定をしました。 極力自分たちでコードを書かずに非同期処理・状態管理の実装を実現したい 実装に困ったときにドキュメントを読めば解決する環境にしたい CLINICS では技術的な背景 6 から Tanstack Query と SWR が候補に上がりましたが、 select オプションや invalidateQueries の Partial Query Matching 等の機能性と、ドキュメントの充実度合いの観点から Tanstack Query を採用しました。 Tanstack Query を採用したことで、 非同期処理のためのコードの記述量が大幅に削減 されたほか、データの特性に応じて Query ごとにキャッシュの時間を調整することが可能となり開発体験が大幅に向上しました。 狙い 2：シンプルなレイヤー分割による学習容易性の向上 CLINICS では、事業の拡大にともないコードベースに関わるエンジニアが増え続けています。 実装の進め方はプロジェクトによって最適な形式を選択しています。 バックエンドからフロントエンドまで一気通貫で実装 技術領域に分けて分業 このように多くのエンジニアが様々な形で関わる環境では、コードベースの学習容易性を高め、実装からコードレビューの完了までをスムーズに行えることが重要です。 前の章で紹介したアーキテクチャは、 レイヤー分割をシンプルにすることでコードベースに慣れるまでの時間を最小限にする ことを意識しています。 加えて、 実装パターンを定形化することで、コードベースに馴染みがなくても迷いなく実装できる ほか、関数の粒度が統一されることで、コードレビューの負荷軽減にも繋がっています。 レイヤー分割の粒度や実装パターンについては、次の記事を参考にさせて頂きました。 フロントエンドアーキテクチャの話: Resource Set の紹介 ほかにも CLINICS では学習容易性の向上の取り組みとして、 新しいライブラリやアーキテクチャを導入した際は勉強会を開催 してライブラリの基本的な使い方や頻出の実装パターンに関する知見を共有しています。 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 アーキテクチャを刷新する以前は、多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、可読性やテスト容易性に支障をきたしていました。 CLINICS のフロントエンドには、医療システムに関する複雑なドメインロジックが多いため、 シンプルでテストしやすいコードベース を作っていくことがとりわけ重要だと考えています。 この課題は、ドメインロジックが集まる傾向にある queries.ts、 mutations.ts の Request Selector や ViewModel Selector の実装を定型化し、純粋関数で表現することにより解決しました。 まとめ Tanstack Query を使ったフロントエンドアーキテクチャの実例を紹介しました。 Resource Operation レイヤーに Tanstack Query の実装を定型化して集約しています。 レイヤー分割をシンプルにし、実装を定型化することで、開発組織のスケールに対応しています。 useQuery の select オプションを使い、スケーラブルにデータ変換処理を記述しています。 データ変換処理にはドメインロジックが集まりやすいため、なるべく小さい粒度の純粋関数で表現することで、可読性・テスト容易性の向上を狙っています。 この記事の内容が Tanstack Query の導入を考えている方の参考になれば幸いです。 さいごに CLINICS では、機能開発と並行してフロントエンド基盤を改善する取り組みも実施しています。 Redux から Tanstack Query への移行 UI ライブラリの Mithril から React への移行 7 デザインシステムの構築とプロダクトへの反映 このような取り組みに興味がある方は次のリンクから是非ご連絡ください。 https://www.medley.jp/jobs/ Footnotes Overview | TanStack Query Docs ↩ Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router | TanStack Query Docs ↩ この記事で紹介している ViewModel は View レイヤー専用のモデルを表す概念です。 MVVM アーキテクチャの ViewModel とは異なります。 ↩ Tanstack Query におけるデータ変換手法の詳細は React Query Data Transformations | TkDodo’s blog で紹介されています。 ↩ Tanstack Query 導入以前の非同期処理は useAsync React Hook - useHooks をカスタマイズしたフックを使って実装していました。 ↩ CLINICS では 一部の実装箇所で Redux を使用していますが、 RTK Query は今回採用するライブラリの候補から除外しました。これは、現在使用している Redux のバージョンが低く、レガシーな周辺ライブラリも複数使用している背景で Redux Toolkit への移行に相当な工数を必要とするためです。 ↩ 2023 年 3 月現在、 CLINICS のフロントエンドの 約 50% は、 Mithril と Redux で構成されています。開発体験の向上のため、 React への完全移行を目指して日々改善を続けています。 ↩

こんにちは。医療プラットフォーム第一本部プロダクト開発室所属エンジニアの髙橋です。 普段の業務では、 医療 SaaS プラットフォーム CLINICS の医療機関向けアプリケーション（以下、CLINICS）の開発を担当しています。 CLINICS では、昨年 10 月頃から React コードベースのリアーキテクチャに取り組んでいます。 その取り組みの 1 つとして、非同期状態管理に関連する実装を Tanstack Query を使って刷新しています。 この記事では、CLINICS における Tanstack Query の活用方法を導入背景と狙いを含めて紹介します。 目次 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Tanstack Query について Tanstack Query を活用したフロントエンドアーキテクチャ Resource Operation の実装 ディレクトリ構成 cache.ts queries.ts mutations.ts ViewModel の実装 ディレクトリ構成 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 狙い 1：Tanstack Query の導入による開発体験の向上 狙い 2：シンプルなレイヤー分割による学習容易性の向上 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 まとめ さいごに Tanstack Query について Tanstack Query は、Web アプリケーションのサーバ状態の取得、キャッシュ、同期、更新を簡単に行うことができるライブラリです。 1 類似ライブラリには SWR、Apollo Client、RTK Query 等が挙げられます。 2 私たちは、機能性・ドキュメントの充実度・コミュニティの将来性を総合的に判断した結果、Tanstack Query(React Query)を採用して React コードベースの再構築を進めています。 導入背景の詳細は、後のセクションで詳しく紹介します。 Tanstack Query を活用したフロントエンドアーキテクチャ それでは本題の Tanstack Query を活用したフロントエンドアーキテクチャについて紹介します。 始めに、アーキテクチャの全体像を示した次の図をご覧ください。 まず注目して頂きたいポイントは、Backend と View の間にある Resource Operation です。 Resource Operation は Tanstack Query を主軸に実装されているレイヤーです。 役割を大きく分類すると次の 2 つが挙げられます。 非同期状態管理に関連する実装の集約 Backend で扱うデータ(OpenAPI スキーマ)と View で扱うデータ(ViewModel)の相互変換 全体像を把握するために、左右のレイヤーにも注目してください。 右の Backend は CLINICS では Ruby on Rails で実装された REST API を提供するモノリシックなサーバです。 API で扱うスキーマは OpenAPI を使って定義しています。 OpenAPI スキーマは、 committee-rails を使ったレスポンス検証と、 openapi-generator を使った API クライアントコードの自動生成に活用しています。 左の View は CLINICS では React で実装されたコンポーネントになります。 View では Backend の OpenAPI スキーマを直接参照することを避け、 ViewModel と呼ばれるフロントエンドで定義したモデル 3 のみを参照する設計としています。 Resource Operation は View と Backend の境界レイヤーとして非同期状態管理とデータの相互変換を行うシンプルなレイヤーとなっています。 続いて、上記の運用のための実装詳細を紹介します。 Resource Operation の実装 ディレクトリ構成 Resource Operation レイヤーでは、リソースごとに非同期状態管理とデータの相互変換の処理をまとめています。 ディレクトリツリーで Resource Operation レイヤー全体を表現すると次のようになります。 src/resourceOperations ├── resourceTagName # 例： todo │ ├── cache.ts │ ├── mutations.ts │ └── queries.ts └── resourceGroupTagName # 例： systemSettings（リソースに階層がある場合） └── resourceTagName # 例： organization（リソースグループ配下のリソース） ├── cache.ts ├── mutations.ts └── queries.ts ディレクトリ名の resourceTagName と resourceGroupTagName は OpenAPI スキーマでエンドポイントごとに割り振られている tag を元に命名しています。 ディレクトリごとに 次の 3 つのファイルを定義しています。 ファイル 役割 cache.ts Query Key の定義、キャッシュ操作のためのカスタムフックの定義 queries.ts useQuery をラップしたカスタムフックの定義、API Request/Response の整形 mutations.ts useMutation をラップしたカスタムフックの定義、API Request の整形 cache.ts cache.ts は次のように実装しています。 // ① Query Key // queries.ts がある場合に必要に応じて宣言 export const todoKeys = { all: [ "todo" ] as const , list : () => [... todoKeys . all , "list" ] as const , paginateList : ( page ?: number ) => [... todoKeys . list (), { page }] as const , detail : ( id : string ) => [... todoKeys . all , "detail" , id ] as const , }; // ② キャッシュ操作のためのカスタムフック // mutations.ts がある場合に必要に応じて宣言 export function useTodoCache () { const queryClient = useQueryClient (); return useMemo ( () => ({ invalidateList : () => queryClient . invalidateQueries ( todoKeys . list ()), invalidateDetail : ( id : string ) => queryClient . invalidateQueries ( todoKeys . detail ( id )), }), [ queryClient ] ); } ① Query Key は、 useQuery の queryKey オプションに与える値を定義した定数です。これは後述の queries.ts で利用します。 実装は Tanstack Query メンテナの Dominik さんのブログで紹介されている Query Key factories パターンを使っています。 ディレクトリ名を all の値とすることで、大規模なアプリケーションにおいてもキーの衝突を防ぐことが可能です。 ② キャッシュ操作のためのカスタムフックでは QueryClient を利用したキャッシュ操作をまとめています。これは後述の mutations.ts で利用します。 CLINICS では 楽観的更新 をしない方針としているため、 invalidateQueries を実行する関数群のみを定義しています。 queries.ts queries.ts は次のように実装しています。 import { type Todo } from "@/viewModels/todo" ; import { todoApi , type GetTodoDetailRequest } from "@/api/generated" ; // ③ queryFn export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); return data . todoList ; }, getTodoDetail : async ( request : GetTodoDetailRequest ): Promise &#x3C; Todo > => { const { data } = await todoApi . getTodoDetail ( request ); return data . todo ; }, }; // ④ Request Selector export const request = { getTodoDetail : ( id : string | undefined ): GetTodoDetailRequest => { if ( id === undefined ) { // `enabled: false` となる条件の引数が与えられた場合例外とすることで、 // queryFn 内の型の整合性を保つ throw new InvalidRequestParameterError ( "Required parameter id was undefined when calling request.getTodoDetail." ); } return { id , }; }, }; ③ queryFn は、API へのリクエストを責務とした関数群です。 ここで使用している ApiClient や Request の型は openapi-generator から生成しています。 queryFn の戻り値の型は、後述の ViewModel で定義した型を明示 しています。 このようにフロントエンド側でサーバステートの型を別途定義することで、フロントエンドとバックエンドを分業して実装する際に開発しやすくなるメリットがあります。 省略していますが、レスポンスに応じたエラーの throw もここで行います。 ④ Request Selector は View から受け取った値をリクエストパラメータへマッピングすることを責務とした関数群です。 useQuery の条件付き実行を制御する enabled オプションで false となる条件を例外とすることで、queryFn 内で 型ガードをしなくて良い設計としています。 これらを使って View とのインターフェースとなる useQuery ラッパーを定義します。 // ⑤ Base Query // API Response を整形せずに返す export type UseTodoDetailQueryProps &#x3C; QueryResult > = { id : string | undefined ; select ?: ( data : Todo ) => QueryResult ; }; export function useTodoDetailQuery &#x3C; QueryResult = Todo >( props : UseTodoDetailQueryProps &#x3C; QueryResult > ) { return useQuery ({ queryKey: todoKeys . detail ( props . id ), queryFn : () => { return query . getTodoDetail ( request . getTodoDetail ( props . id )); }, enabled: !! props . id , select: props . select , useErrorBoundary: true , }); } import { selectTodoForm } from "@/viewModels/todo/todoForm" ; // ⑥ Selector Query // API Response を View で参照したいフォーマットに整形して返す export function useInitialTodoFormQuery () { // Base Query に select オプションを与える return useTodoDetailQuery ({ select: selectTodoForm , // selectTodoForm は Todo を TodoForm に変換する ViewModel Selector（後述） }); } useQuery ラッパーは、⑤ Base Query と ⑥ Selector Query に分けて定義しています。 CLINICS では同じデータソースに対して画面ごとに異なるフォーマットで表示することが多くあります。 Selector Query で 任意のフォーマットに整形することで、画面ごとに最適化されたデータの取得をスケーラブルに実現しています。 4 加えて、この手法では Selector にドメインロジックが凝集されるため、 Selector を重点的にテストすることで品質を担保しやすい メリットがあります。 Query のエラー制御は useErrorBoundary オプションを使って Error Boundary を表示する方針としています。 mutations.ts mutations.ts は次のように実装しています。 import { type TodoForm } from "@/viewModels/todo/todoForm" ; import { todoApi , type PostTodoRequest } "@/api/generated" ; // ⑦ mutationFn export const mutation = { createTodo : ( request : PostTodoRequest ) => { return todoApi . postTodo ( request ); }, }; // ⑧ Request Selector // ViewModel から API Request へ変換する export const request = { createTodo : ( todoForm : TodoForm ): PostTodoRequest => { return { PostTodoRequest : { todo : { title : todoForm . title , description : todoForm . description , status : todoForm . status , favorite : todoForm . favorite === "true" ? true : false , }, }, }; }, }; // ⑨ Custom Mutation export function useCreateTodoMutation () { const { invalidateList } = useTodoCache (); return useMutation ({ mutationFn : ( todoForm : TodoForm ) => { return mutation . createTodo ( request . createTodo ( todoForm )); }, onSuccess : () => { return invalidateList (); }, }); } 基本的な構成は queries.ts と同じです。 mutations.ts でも queries.ts と同様に ⑧ Request Selector を定義します。 Request Selector には、データ整形を扱うためドメインロジックが集まりやすいです。 そのため、入出力、境界値、例外のテストを積極的に書いて品質の担保に繋げています。 Mutation のエラーは画面ごとに UI でフィードバックするため、コンポーネント側で制御しています。 Resource Operation レイヤーに関する実装の紹介は以上です。 ViewModel の実装 ViewModel とは、View(React Component) で扱うデータのスキーマと型です。 Resource Operation の実装では、API Response を ViewModel に整形して View に提供することを紹介しました。 全体の理解を深めるため、ViewModel の実装も紹介します。 ディレクトリ構成 ViewModel は関心を分離するため Resource Operation とは別のディレクトリに定義しています。 src/viewModels └── todo ├── todo.ts # サーバステート ├── todoForm.test.ts # フロントエンドに閉じたスキーマのテスト ├── todoForm.ts # フロントエンドに閉じたスキーマ └── todoSearchCondition.ts # フロントエンドに閉じた型 ViewModel で定義するスキーマ・型は大きく分けて 3 つに分類されます。 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 サーバステート サーバステートは、 API Response として期待するデータのスキーマ及び型です。 前述の queries.ts 内の ③ queryFn で使用します。 zod を使って次のように実装しています。 // src/viewModels/todo/todo.ts // enum は View で &#x3C;option value={todoStatus.enum.ready} /> のように使用する export const todoStatus = z . enum ([ "ready" , "doing" , "done" ]); // ⑩ サーバステートのスキーマ // 開発中のみ ③ queryFn 内で API Response を parse することで、スキーマの不整合を検出するための補助輪として使用する export const todo = z . object ({ id: z . string (), title: z . string (), description: z . string (). nullable (), status: todoStatus , favorite: z . boolean (), }); // ⑪ サーバステートの型 // ③ queryFn の戻り値の型として使用する export type Todo = z . infer &#x3C; typeof todo >; ⑩ サーバステートのスキーマは、⑪ サーバステートの型の生成と開発時のスキーマ検証に使用しています。 開発時のみ API Response を検証することで、⑩ サーバステートのスキーマと Open API スキーマの整合性を確認しています。 // src/resourceOperations/todo/queries.ts import { todo , type Todo } from "@/viewModels/todo" ; export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); // 開発時、APIとの結合タイミングで検証してフロントエンドとバックエンドでスキーマの齟齬がないことを確認する // 検証が済んだら parse 処理を外す return data . todoList . map (( x ) => todo . parse ( x )); }, }; 例外として、 外部サービスから取得したデータに関しては常にサーバステートのスキーマを使って検証 しています。 例えば、外部サービスの仕様として長さが 1 以上の配列が返ってくると決まっていて、フロントエンド側もその仕様に基づいた処理を実装している場合、 z.array().min(1) のスキーマで常に検証します。 ネットワークに近い箇所で不正なデータを検出することで、例外発生時の調査を容易にするメリットがあると考えています。 フロントエンドに閉じたスキーマ フロントエンドに閉じたスキーマは、そのほとんどがフォームのバリデーションスキーマです。 こちらも zod を使って定義しています。 // src/viewModels/todo/todoForm.ts import { type Todo , todo } from "./todo" ; // フロントエンドに閉じたスキーマ // フォームのスキーマは react-hook-form と連携して使用する（省略） export const todoForm = z . object ({ title: z . string () . min ( 1 , "入力してください" ) . max ( 200 , "200字以内で入力してください" ), description: z . string (). max ( 500 , "500字以内で入力してください" ), status: todo . shape . status , favorite: z . union ([ z . literal ( "true" ), z . literal ( "false" )]), }); export type TodoForm = z . infer &#x3C; typeof todoForm >; // ⑫ ViewModel Selector // サーバステートからフロントエンドに閉じたスキーマへ変換する // 前述の queries.ts 内 ⑥ Selector Query で使用する export function selectTodoForm ( todo : Todo ): TodoForm { return { title: todo . title , description: todo . description ?? "" , status: todo . status , favorite: todo . favorite ? "true" : "false" , }; } フロントエンドに閉じたスキーマは、必ずサーバステートを元に生成する運用としています。 そのために、フロントエンドに閉じたスキーマを宣言した直下に、サーバステートからフロントエンドに閉じたスキーマへ変換する ⑫ ViewModel Selector を定義します。 null の 空文字への変換や時間データのフォーマットのような、 サーバステート と View で使う値の差分吸収はこのセレクタ内で行います。 このように、 ViewModel レイヤーでは他のレイヤーと依存しないようにドメインロジックを表現 しています。 ドメインロジックを Tanstack Query に依存しないことで、今後技術基盤を刷新する場合でも影響を最小限に留めることを狙いとしています。 フロントエンドに閉じた型 依存関係を整えるため、Resource Operation と View から参照するフロントエンドに閉じた型は viewModels 配下に宣言しています。 // src/viewModels/todo/todoSearchParams.ts export type TodoSearchCondition = { sort ?: "created_at_asc" | "created_at_desc" ; }; ViewModel に関する実装の紹介は以上です。 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 Tanstack Query を導入する以前の CLINICS の非同期処理周辺のコードベースではいくつかの課題がありました。 開発体験の課題 非同期処理のためのミニマムな基盤フックを独自に実装していた 5 ことにより、開発体験の観点で次のような課題がありました。 新しい要件（ポーリング・無限読み込み等）が発生した際に、最初に担当する開発者が都度機能拡張する必要がある テストが実装されていなかったため変更時に品質確認の負担が大きい 学習容易性の課題 上述の基盤フックにドキュメントがなかったため、学習容易性の観点で次のような課題がありました。 基盤フックにドキュメントがなく、新規メンバーの学習コストが高い 様々な実装手法が混在することで、実装時に迷いが生じている 可読性の課題 CLINICS は開発開始から約 7 年以上が経過しています。 その中でもフロントエンドは技術トレンドの変化が早いため、様々なライブラリやパターンを使って実装されています。 特に近年から漸進的に導入した React を使った実装については、明確な設計が確立されていませんでした。 これらの背景からチームで安定したアウトプットを出すことが困難で、可読性の観点で次のような課題がありました。 画面によってフックや関数の粒度、定義場所が違うことでコードリーディングの負荷が高い コードレビュー時のレビュワーの負担が大きい テスト容易性の課題 多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、テスト容易性の観点で次のような課題がありました。 テストが実装しづらい テストカバレッジが低い CLINICS はオンライン診療・電子カルテ等の医療機関業務を支える機能を提供する SaaS プラットフォームです。 今後長きに渡って多くの医療機関の方々に CLINICS を利用して頂くためには、 コードを読みやすく、変更しやすく、維持しやすい状態に保ち続けること が重要です。 前の章で紹介したアーキテクチャは 持続可能な開発を目指して 設計しました。 具体的には、 開発体験・学習容易性・可読性・テスト容易性を向上することを狙い としています。 狙い 1：Tanstack Query の導入による開発体験の向上 背景で説明したとおり、Tanstack Query 導入以前は独自実装したフックを使って非同期処理を実装していました。 Tanstack Query を導入したきっかけは、チーム内での雑談の中で、独自実装のフックが使いづらいという声が挙がったことです。 そこで、独自実装のフック自体の質を高めるか、質の高いライブラリを導入するかを議論した結果、次の理由でライブラリを導入する決定をしました。 極力自分たちでコードを書かずに非同期処理・状態管理の実装を実現したい 実装に困ったときにドキュメントを読めば解決する環境にしたい CLINICS では技術的な背景 6 から Tanstack Query と SWR が候補に上がりましたが、 select オプションや invalidateQueries の Partial Query Matching 等の機能性と、ドキュメントの充実度合いの観点から Tanstack Query を採用しました。 Tanstack Query を採用したことで、 非同期処理のためのコードの記述量が大幅に削減 されたほか、データの特性に応じて Query ごとにキャッシュの時間を調整することが可能となり開発体験が大幅に向上しました。 狙い 2：シンプルなレイヤー分割による学習容易性の向上 CLINICS では、事業の拡大にともないコードベースに関わるエンジニアが増え続けています。 実装の進め方はプロジェクトによって最適な形式を選択しています。 バックエンドからフロントエンドまで一気通貫で実装 技術領域に分けて分業 このように多くのエンジニアが様々な形で関わる環境では、コードベースの学習容易性を高め、実装からコードレビューの完了までをスムーズに行えることが重要です。 前の章で紹介したアーキテクチャは、 レイヤー分割をシンプルにすることでコードベースに慣れるまでの時間を最小限にする ことを意識しています。 加えて、 実装パターンを定形化することで、コードベースに馴染みがなくても迷いなく実装できる ほか、関数の粒度が統一されることで、コードレビューの負荷軽減にも繋がっています。 レイヤー分割の粒度や実装パターンについては、次の記事を参考にさせて頂きました。 フロントエンドアーキテクチャの話: Resource Set の紹介 ほかにも CLINICS では学習容易性の向上の取り組みとして、 新しいライブラリやアーキテクチャを導入した際は勉強会を開催 してライブラリの基本的な使い方や頻出の実装パターンに関する知見を共有しています。 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 アーキテクチャを刷新する以前は、多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、可読性やテスト容易性に支障をきたしていました。 CLINICS のフロントエンドには、医療システムに関する複雑なドメインロジックが多いため、 シンプルでテストしやすいコードベース を作っていくことがとりわけ重要だと考えています。 この課題は、ドメインロジックが集まる傾向にある queries.ts、 mutations.ts の Request Selector や ViewModel Selector の実装を定型化し、純粋関数で表現することにより解決しました。 まとめ Tanstack Query を使ったフロントエンドアーキテクチャの実例を紹介しました。 Resource Operation レイヤーに Tanstack Query の実装を定型化して集約しています。 レイヤー分割をシンプルにし、実装を定型化することで、開発組織のスケールに対応しています。 useQuery の select オプションを使い、スケーラブルにデータ変換処理を記述しています。 データ変換処理にはドメインロジックが集まりやすいため、なるべく小さい粒度の純粋関数で表現することで、可読性・テスト容易性の向上を狙っています。 この記事の内容が Tanstack Query の導入を考えている方の参考になれば幸いです。 さいごに CLINICS では、機能開発と並行してフロントエンド基盤を改善する取り組みも実施しています。 Redux から Tanstack Query への移行 UI ライブラリの Mithril から React への移行 7 デザインシステムの構築とプロダクトへの反映 このような取り組みに興味がある方は次のリンクから是非ご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp Footnotes Overview | TanStack Query Docs ↩ Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router | TanStack Query Docs ↩ この記事で紹介している ViewModel は View レイヤー専用のモデルを表す概念です。 MVVM アーキテクチャの ViewModel とは異なります。 ↩ Tanstack Query におけるデータ変換手法の詳細は React Query Data Transformations | TkDodo’s blog で紹介されています。 ↩ Tanstack Query 導入以前の非同期処理は useAsync React Hook - useHooks をカスタマイズしたフックを使って実装していました。 ↩ CLINICS では 一部の実装箇所で Redux を使用していますが、 RTK Query は今回採用するライブラリの候補から除外しました。これは、現在使用している Redux のバージョンが低く、レガシーな周辺ライブラリも複数使用している背景で Redux Toolkit への移行に相当な工数を必要とするためです。 ↩ 2023 年 3 月現在、 CLINICS のフロントエンドの 約 50% は、 Mithril と Redux で構成されています。開発体験の向上のため、 React への完全移行を目指して日々改善を続けています。 ↩

こんにちは。医療プラットフォーム第一本部プロダクト開発室所属エンジニアの髙橋です。 普段の業務では、 医療 SaaS プラットフォーム CLINICS の医療機関向けアプリケーション（以下、CLINICS）の開発を担当しています。 CLINICS では、昨年 10 月頃から React コードベースのリアーキテクチャに取り組んでいます。 その取り組みの 1 つとして、非同期状態管理に関連する実装を Tanstack Query を使って刷新しています。 この記事では、CLINICS における Tanstack Query の活用方法を導入背景と狙いを含めて紹介します。 目次 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Tanstack Query について Tanstack Query を活用したフロントエンドアーキテクチャ Resource Operation の実装 ディレクトリ構成 cache.ts queries.ts mutations.ts ViewModel の実装 ディレクトリ構成 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 狙い 1：Tanstack Query の導入による開発体験の向上 狙い 2：シンプルなレイヤー分割による学習容易性の向上 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 まとめ さいごに Tanstack Query について Tanstack Query は、Web アプリケーションのサーバ状態の取得、キャッシュ、同期、更新を簡単に行うことができるライブラリです。 1 類似ライブラリには SWR、Apollo Client、RTK Query 等が挙げられます。 2 私たちは、機能性・ドキュメントの充実度・コミュニティの将来性を総合的に判断した結果、Tanstack Query(React Query)を採用して React コードベースの再構築を進めています。 導入背景の詳細は、後のセクションで詳しく紹介します。 Tanstack Query を活用したフロントエンドアーキテクチャ それでは本題の Tanstack Query を活用したフロントエンドアーキテクチャについて紹介します。 始めに、アーキテクチャの全体像を示した次の図をご覧ください。 まず注目して頂きたいポイントは、Backend と View の間にある Resource Operation です。 Resource Operation は Tanstack Query を主軸に実装されているレイヤーです。 役割を大きく分類すると次の 2 つが挙げられます。 非同期状態管理に関連する実装の集約 Backend で扱うデータ(OpenAPI スキーマ)と View で扱うデータ(ViewModel)の相互変換 全体像を把握するために、左右のレイヤーにも注目してください。 右の Backend は CLINICS では Ruby on Rails で実装された REST API を提供するモノリシックなサーバです。 API で扱うスキーマは OpenAPI を使って定義しています。 OpenAPI スキーマは、 committee-rails を使ったレスポンス検証と、 openapi-generator を使った API クライアントコードの自動生成に活用しています。 左の View は CLINICS では React で実装されたコンポーネントになります。 View では Backend の OpenAPI スキーマを直接参照することを避け、 ViewModel と呼ばれるフロントエンドで定義したモデル 3 のみを参照する設計としています。 Resource Operation は View と Backend の境界レイヤーとして非同期状態管理とデータの相互変換を行うシンプルなレイヤーとなっています。 続いて、上記の運用のための実装詳細を紹介します。 Resource Operation の実装 ディレクトリ構成 Resource Operation レイヤーでは、リソースごとに非同期状態管理とデータの相互変換の処理をまとめています。 ディレクトリツリーで Resource Operation レイヤー全体を表現すると次のようになります。 src/resourceOperations ├── resourceTagName # 例： todo │ ├── cache.ts │ ├── mutations.ts │ └── queries.ts └── resourceGroupTagName # 例： systemSettings（リソースに階層がある場合） └── resourceTagName # 例： organization（リソースグループ配下のリソース） ├── cache.ts ├── mutations.ts └── queries.ts ディレクトリ名の resourceTagName と resourceGroupTagName は OpenAPI スキーマでエンドポイントごとに割り振られている tag を元に命名しています。 ディレクトリごとに 次の 3 つのファイルを定義しています。 ファイル 役割 cache.ts Query Key の定義、キャッシュ操作のためのカスタムフックの定義 queries.ts useQuery をラップしたカスタムフックの定義、API Request/Response の整形 mutations.ts useMutation をラップしたカスタムフックの定義、API Request の整形 cache.ts cache.ts は次のように実装しています。 // ① Query Key // queries.ts がある場合に必要に応じて宣言 export const todoKeys = { all: [ "todo" ] as const , list : () => [... todoKeys . all , "list" ] as const , paginateList : ( page ?: number ) => [... todoKeys . list (), { page }] as const , detail : ( id : string ) => [... todoKeys . all , "detail" , id ] as const , }; // ② キャッシュ操作のためのカスタムフック // mutations.ts がある場合に必要に応じて宣言 export function useTodoCache () { const queryClient = useQueryClient (); return useMemo ( () => ({ invalidateList : () => queryClient . invalidateQueries ( todoKeys . list ()), invalidateDetail : ( id : string ) => queryClient . invalidateQueries ( todoKeys . detail ( id )), }), [ queryClient ] ); } ① Query Key は、 useQuery の queryKey オプションに与える値を定義した定数です。これは後述の queries.ts で利用します。 実装は Tanstack Query メンテナの Dominik さんのブログで紹介されている Query Key factories パターンを使っています。 ディレクトリ名を all の値とすることで、大規模なアプリケーションにおいてもキーの衝突を防ぐことが可能です。 ② キャッシュ操作のためのカスタムフックでは QueryClient を利用したキャッシュ操作をまとめています。これは後述の mutations.ts で利用します。 CLINICS では 楽観的更新 をしない方針としているため、 invalidateQueries を実行する関数群のみを定義しています。 queries.ts queries.ts は次のように実装しています。 import { type Todo } from "@/viewModels/todo" ; import { todoApi , type GetTodoDetailRequest } from "@/api/generated" ; // ③ queryFn export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); return data . todoList ; }, getTodoDetail : async ( request : GetTodoDetailRequest ): Promise &#x3C; Todo > => { const { data } = await todoApi . getTodoDetail ( request ); return data . todo ; }, }; // ④ Request Selector export const request = { getTodoDetail : ( id : string | undefined ): GetTodoDetailRequest => { if ( id === undefined ) { // `enabled: false` となる条件の引数が与えられた場合例外とすることで、 // queryFn 内の型の整合性を保つ throw new InvalidRequestParameterError ( "Required parameter id was undefined when calling request.getTodoDetail." ); } return { id , }; }, }; ③ queryFn は、API へのリクエストを責務とした関数群です。 ここで使用している ApiClient や Request の型は openapi-generator から生成しています。 queryFn の戻り値の型は、後述の ViewModel で定義した型を明示 しています。 このようにフロントエンド側でサーバステートの型を別途定義することで、フロントエンドとバックエンドを分業して実装する際に開発しやすくなるメリットがあります。 省略していますが、レスポンスに応じたエラーの throw もここで行います。 ④ Request Selector は View から受け取った値をリクエストパラメータへマッピングすることを責務とした関数群です。 useQuery の条件付き実行を制御する enabled オプションで false となる条件を例外とすることで、queryFn 内で 型ガードをしなくて良い設計としています。 これらを使って View とのインターフェースとなる useQuery ラッパーを定義します。 // ⑤ Base Query // API Response を整形せずに返す export type UseTodoDetailQueryProps &#x3C; QueryResult > = { id : string | undefined ; select ?: ( data : Todo ) => QueryResult ; }; export function useTodoDetailQuery &#x3C; QueryResult = Todo >( props : UseTodoDetailQueryProps &#x3C; QueryResult > ) { return useQuery ({ queryKey: todoKeys . detail ( props . id ), queryFn : () => { return query . getTodoDetail ( request . getTodoDetail ( props . id )); }, enabled: !! props . id , select: props . select , useErrorBoundary: true , }); } import { selectTodoForm } from "@/viewModels/todo/todoForm" ; // ⑥ Selector Query // API Response を View で参照したいフォーマットに整形して返す export function useInitialTodoFormQuery () { // Base Query に select オプションを与える return useTodoDetailQuery ({ select: selectTodoForm , // selectTodoForm は Todo を TodoForm に変換する ViewModel Selector（後述） }); } useQuery ラッパーは、⑤ Base Query と ⑥ Selector Query に分けて定義しています。 CLINICS では同じデータソースに対して画面ごとに異なるフォーマットで表示することが多くあります。 Selector Query で 任意のフォーマットに整形することで、画面ごとに最適化されたデータの取得をスケーラブルに実現しています。 4 加えて、この手法では Selector にドメインロジックが凝集されるため、 Selector を重点的にテストすることで品質を担保しやすい メリットがあります。 Query のエラー制御は useErrorBoundary オプションを使って Error Boundary を表示する方針としています。 mutations.ts mutations.ts は次のように実装しています。 import { type TodoForm } from "@/viewModels/todo/todoForm" ; import { todoApi , type PostTodoRequest } "@/api/generated" ; // ⑦ mutationFn export const mutation = { createTodo : ( request : PostTodoRequest ) => { return todoApi . postTodo ( request ); }, }; // ⑧ Request Selector // ViewModel から API Request へ変換する export const request = { createTodo : ( todoForm : TodoForm ): PostTodoRequest => { return { PostTodoRequest : { todo : { title : todoForm . title , description : todoForm . description , status : todoForm . status , favorite : todoForm . favorite === "true" ? true : false , }, }, }; }, }; // ⑨ Custom Mutation export function useCreateTodoMutation () { const { invalidateList } = useTodoCache (); return useMutation ({ mutationFn : ( todoForm : TodoForm ) => { return mutation . createTodo ( request . createTodo ( todoForm )); }, onSuccess : () => { return invalidateList (); }, }); } 基本的な構成は queries.ts と同じです。 mutations.ts でも queries.ts と同様に ⑧ Request Selector を定義します。 Request Selector には、データ整形を扱うためドメインロジックが集まりやすいです。 そのため、入出力、境界値、例外のテストを積極的に書いて品質の担保に繋げています。 Mutation のエラーは画面ごとに UI でフィードバックするため、コンポーネント側で制御しています。 Resource Operation レイヤーに関する実装の紹介は以上です。 ViewModel の実装 ViewModel とは、View(React Component) で扱うデータのスキーマと型です。 Resource Operation の実装では、API Response を ViewModel に整形して View に提供することを紹介しました。 全体の理解を深めるため、ViewModel の実装も紹介します。 ディレクトリ構成 ViewModel は関心を分離するため Resource Operation とは別のディレクトリに定義しています。 src/viewModels └── todo ├── todo.ts # サーバステート ├── todoForm.test.ts # フロントエンドに閉じたスキーマのテスト ├── todoForm.ts # フロントエンドに閉じたスキーマ └── todoSearchCondition.ts # フロントエンドに閉じた型 ViewModel で定義するスキーマ・型は大きく分けて 3 つに分類されます。 サーバステート フロントエンドに閉じたスキーマ フロントエンドに閉じた型 サーバステート サーバステートは、 API Response として期待するデータのスキーマ及び型です。 前述の queries.ts 内の ③ queryFn で使用します。 zod を使って次のように実装しています。 // src/viewModels/todo/todo.ts // enum は View で &#x3C;option value={todoStatus.enum.ready} /> のように使用する export const todoStatus = z . enum ([ "ready" , "doing" , "done" ]); // ⑩ サーバステートのスキーマ // 開発中のみ ③ queryFn 内で API Response を parse することで、スキーマの不整合を検出するための補助輪として使用する export const todo = z . object ({ id: z . string (), title: z . string (), description: z . string (). nullable (), status: todoStatus , favorite: z . boolean (), }); // ⑪ サーバステートの型 // ③ queryFn の戻り値の型として使用する export type Todo = z . infer &#x3C; typeof todo >; ⑩ サーバステートのスキーマは、⑪ サーバステートの型の生成と開発時のスキーマ検証に使用しています。 開発時のみ API Response を検証することで、⑩ サーバステートのスキーマと Open API スキーマの整合性を確認しています。 // src/resourceOperations/todo/queries.ts import { todo , type Todo } from "@/viewModels/todo" ; export const query = { getTodoList : async (): Promise &#x3C; Todo []> => { const { data } = await todoApi . getTodoList (); // 開発時、APIとの結合タイミングで検証してフロントエンドとバックエンドでスキーマの齟齬がないことを確認する // 検証が済んだら parse 処理を外す return data . todoList . map (( x ) => todo . parse ( x )); }, }; 例外として、 外部サービスから取得したデータに関しては常にサーバステートのスキーマを使って検証 しています。 例えば、外部サービスの仕様として長さが 1 以上の配列が返ってくると決まっていて、フロントエンド側もその仕様に基づいた処理を実装している場合、 z.array().min(1) のスキーマで常に検証します。 ネットワークに近い箇所で不正なデータを検出することで、例外発生時の調査を容易にするメリットがあると考えています。 フロントエンドに閉じたスキーマ フロントエンドに閉じたスキーマは、そのほとんどがフォームのバリデーションスキーマです。 こちらも zod を使って定義しています。 // src/viewModels/todo/todoForm.ts import { type Todo , todo } from "./todo" ; // フロントエンドに閉じたスキーマ // フォームのスキーマは react-hook-form と連携して使用する（省略） export const todoForm = z . object ({ title: z . string () . min ( 1 , "入力してください" ) . max ( 200 , "200字以内で入力してください" ), description: z . string (). max ( 500 , "500字以内で入力してください" ), status: todo . shape . status , favorite: z . union ([ z . literal ( "true" ), z . literal ( "false" )]), }); export type TodoForm = z . infer &#x3C; typeof todoForm >; // ⑫ ViewModel Selector // サーバステートからフロントエンドに閉じたスキーマへ変換する // 前述の queries.ts 内 ⑥ Selector Query で使用する export function selectTodoForm ( todo : Todo ): TodoForm { return { title: todo . title , description: todo . description ?? "" , status: todo . status , favorite: todo . favorite ? "true" : "false" , }; } フロントエンドに閉じたスキーマは、必ずサーバステートを元に生成する運用としています。 そのために、フロントエンドに閉じたスキーマを宣言した直下に、サーバステートからフロントエンドに閉じたスキーマへ変換する ⑫ ViewModel Selector を定義します。 null の 空文字への変換や時間データのフォーマットのような、 サーバステート と View で使う値の差分吸収はこのセレクタ内で行います。 このように、 ViewModel レイヤーでは他のレイヤーと依存しないようにドメインロジックを表現 しています。 ドメインロジックを Tanstack Query に依存しないことで、今後技術基盤を刷新する場合でも影響を最小限に留めることを狙いとしています。 フロントエンドに閉じた型 依存関係を整えるため、Resource Operation と View から参照するフロントエンドに閉じた型は viewModels 配下に宣言しています。 // src/viewModels/todo/todoSearchParams.ts export type TodoSearchCondition = { sort ?: "created_at_asc" | "created_at_desc" ; }; ViewModel に関する実装の紹介は以上です。 Tanstack Query 導入の背景とアーキテクチャの狙い 背景：コード品質の課題 Tanstack Query を導入する以前の CLINICS の非同期処理周辺のコードベースではいくつかの課題がありました。 開発体験の課題 非同期処理のためのミニマムな基盤フックを独自に実装していた 5 ことにより、開発体験の観点で次のような課題がありました。 新しい要件（ポーリング・無限読み込み等）が発生した際に、最初に担当する開発者が都度機能拡張する必要がある テストが実装されていなかったため変更時に品質確認の負担が大きい 学習容易性の課題 上述の基盤フックにドキュメントがなかったため、学習容易性の観点で次のような課題がありました。 基盤フックにドキュメントがなく、新規メンバーの学習コストが高い 様々な実装手法が混在することで、実装時に迷いが生じている 可読性の課題 CLINICS は開発開始から約 7 年以上が経過しています。 その中でもフロントエンドは技術トレンドの変化が早いため、様々なライブラリやパターンを使って実装されています。 特に近年から漸進的に導入した React を使った実装については、明確な設計が確立されていませんでした。 これらの背景からチームで安定したアウトプットを出すことが困難で、可読性の観点で次のような課題がありました。 画面によってフックや関数の粒度、定義場所が違うことでコードリーディングの負荷が高い コードレビュー時のレビュワーの負担が大きい テスト容易性の課題 多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、テスト容易性の観点で次のような課題がありました。 テストが実装しづらい テストカバレッジが低い CLINICS はオンライン診療・電子カルテ等の医療機関業務を支える機能を提供する SaaS プラットフォームです。 今後長きに渡って多くの医療機関の方々に CLINICS を利用して頂くためには、 コードを読みやすく、変更しやすく、維持しやすい状態に保ち続けること が重要です。 前の章で紹介したアーキテクチャは 持続可能な開発を目指して 設計しました。 具体的には、 開発体験・学習容易性・可読性・テスト容易性を向上することを狙い としています。 狙い 1：Tanstack Query の導入による開発体験の向上 背景で説明したとおり、Tanstack Query 導入以前は独自実装したフックを使って非同期処理を実装していました。 Tanstack Query を導入したきっかけは、チーム内での雑談の中で、独自実装のフックが使いづらいという声が挙がったことです。 そこで、独自実装のフック自体の質を高めるか、質の高いライブラリを導入するかを議論した結果、次の理由でライブラリを導入する決定をしました。 極力自分たちでコードを書かずに非同期処理・状態管理の実装を実現したい 実装に困ったときにドキュメントを読めば解決する環境にしたい CLINICS では技術的な背景 6 から Tanstack Query と SWR が候補に上がりましたが、 select オプションや invalidateQueries の Partial Query Matching 等の機能性と、ドキュメントの充実度合いの観点から Tanstack Query を採用しました。 Tanstack Query を採用したことで、 非同期処理のためのコードの記述量が大幅に削減 されたほか、データの特性に応じて Query ごとにキャッシュの時間を調整することが可能となり開発体験が大幅に向上しました。 狙い 2：シンプルなレイヤー分割による学習容易性の向上 CLINICS では、事業の拡大にともないコードベースに関わるエンジニアが増え続けています。 実装の進め方はプロジェクトによって最適な形式を選択しています。 バックエンドからフロントエンドまで一気通貫で実装 技術領域に分けて分業 このように多くのエンジニアが様々な形で関わる環境では、コードベースの学習容易性を高め、実装からコードレビューの完了までをスムーズに行えることが重要です。 前の章で紹介したアーキテクチャは、 レイヤー分割をシンプルにすることでコードベースに慣れるまでの時間を最小限にする ことを意識しています。 加えて、 実装パターンを定形化することで、コードベースに馴染みがなくても迷いなく実装できる ほか、関数の粒度が統一されることで、コードレビューの負荷軽減にも繋がっています。 レイヤー分割の粒度や実装パターンについては、次の記事を参考にさせて頂きました。 フロントエンドアーキテクチャの話: Resource Set の紹介 ほかにも CLINICS では学習容易性の向上の取り組みとして、 新しいライブラリやアーキテクチャを導入した際は勉強会を開催 してライブラリの基本的な使い方や頻出の実装パターンに関する知見を共有しています。 狙い 3：ドメインロジックを純粋関数で表現することによる可読性・テスト容易性の向上 アーキテクチャを刷新する以前は、多くのドメインロジックがコンポーネントやカスタムフック内に混在していることで、可読性やテスト容易性に支障をきたしていました。 CLINICS のフロントエンドには、医療システムに関する複雑なドメインロジックが多いため、 シンプルでテストしやすいコードベース を作っていくことがとりわけ重要だと考えています。 この課題は、ドメインロジックが集まる傾向にある queries.ts、 mutations.ts の Request Selector や ViewModel Selector の実装を定型化し、純粋関数で表現することにより解決しました。 まとめ Tanstack Query を使ったフロントエンドアーキテクチャの実例を紹介しました。 Resource Operation レイヤーに Tanstack Query の実装を定型化して集約しています。 レイヤー分割をシンプルにし、実装を定型化することで、開発組織のスケールに対応しています。 useQuery の select オプションを使い、スケーラブルにデータ変換処理を記述しています。 データ変換処理にはドメインロジックが集まりやすいため、なるべく小さい粒度の純粋関数で表現することで、可読性・テスト容易性の向上を狙っています。 この記事の内容が Tanstack Query の導入を考えている方の参考になれば幸いです。 さいごに CLINICS では、機能開発と並行してフロントエンド基盤を改善する取り組みも実施しています。 Redux から Tanstack Query への移行 UI ライブラリの Mithril から React への移行 7 デザインシステムの構築とプロダクトへの反映 このような取り組みに興味がある方は次のリンクから是非ご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp Footnotes Overview | TanStack Query Docs ↩ Comparison | React Query vs SWR vs Apollo vs RTK Query vs React Router | TanStack Query Docs ↩ この記事で紹介している ViewModel は View レイヤー専用のモデルを表す概念です。 MVVM アーキテクチャの ViewModel とは異なります。 ↩ Tanstack Query におけるデータ変換手法の詳細は React Query Data Transformations | TkDodo’s blog で紹介されています。 ↩ Tanstack Query 導入以前の非同期処理は useAsync React Hook - useHooks をカスタマイズしたフックを使って実装していました。 ↩ CLINICS では 一部の実装箇所で Redux を使用していますが、 RTK Query は今回採用するライブラリの候補から除外しました。これは、現在使用している Redux のバージョンが低く、レガシーな周辺ライブラリも複数使用している背景で Redux Toolkit への移行に相当な工数を必要とするためです。 ↩ 2023 年 3 月現在、 CLINICS のフロントエンドの 約 50% は、 Mithril と Redux で構成されています。開発体験の向上のため、 React への完全移行を目指して日々改善を続けています。 ↩

はじめに みなさん、こんにちは。エンジニアの新居です。今回は医療介護求人サイトの ジョブメドレー 開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いていこうと思います。 インタビュイー紹介 堀内さん 2021 年入社。人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 堀内さん メドレーに入社した理由 新居 : まずはじめに、堀内さんはどういう経緯でメドレーに入社したのでしたっけ？ 堀内 : 以前のインタビュー（ 21 年新卒入社エンジニアと座談会で振り返る新卒研修 ）の時にもお話したのですが、就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。特に､ ビジネス側と開発側の距離が近い 部分に惹かれ､総合的にメドレーが良さそうだと考えて入社しました。 新居 : 入社前の印象と実際働きだしてからで、ズレなどはありましたか？ 堀内 : そんなにギャップはなくて、社風とか人間関係みたいなところは入社前のイメージ通りでした。入社前に何回か会社見学をさせてもらったり、その時の社員と複数回面談をセッティングしてもらったりして、そこでイメージをすり合わせできたことが大きかったですね。 新居 : 何人くらいの社員と会ったのですか？ 堀内 : 6 ~ 7 人です。色々なポジションや性格の人達と話ができたので、安心して入社することができました。 新卒研修の開発 OJT ではどんなことをやっていたか？ 新居 : 堀内さんは新卒研修の開発 OJT のタイミングでジョブメドレー開発チームに仮配属されたのですよね。当時はどういうことをやってたのですか？ 堀内 : まずはジョブメドレーのドメイン知識をしっかり吸収していこうということで、業界や業務自体の理解を進めました。 その後、求職者と事業者のサポート業務を行う社内オペレーターが利用する画面の拡張タスクに取り組みました。 技術スタックは Next.js / React / TypeScript / GraphQL といったシステムで、個人的にあまり触れてこなかった領域だったので、技術のキャッチアップもしつつ丁寧に対応していきました。 また、開発 OJT よりも前の研修で輪読会も経験したのですが、その時に学んだ Cookie や Session まわりの知識が役に立ったり、座学で学んだことがこうやって実践で活きてくるんだな、ということを実感 できてとても良い経験になりました。 今までとは比べ物にならないくらい大規模なシステムだったので、プレッシャーも大きかったのですが、チームの人達と相談したり、細かいレビュー・サポートがあったおかげで、しっかり成果を出すことができたと思います。 新居 : 良い OJT ですね！堀内さん自身の努力があったのは勿論ですが、チームに新しいメンバーを迎え入れて成長をサポートする環境が整っていたのも良かったんでしょうね。 ちなみに開発 OJT の中で大変だったこととかはありますか？ 堀内 : そうですね、やはり大規模な既存コードの把握・理解が大変でした。社内オペレーターが使う画面とジョブメドレー本体はそれぞれ別システムとして連携しているので、ジョブメドレー本体のコードや仕組みの理解も必要です。 大変だった分、 システムの全体像を理解するのに大いに役立った ので、今思い返すと良い経験だったなあと思います。 色々な経験を積めた求人カード改修プロジェクト 新居 : では、新卒研修を終えてから 1 年以上経っていて、入社 2 年目の終わりに差し掛かっている現在ですが、直近で堀内さんがリードを務めていた、ジョブメドレーの求人カード改修プロジェクトについて話を聞いていきたいと思います。まずは、このプロジェクトの概要について、教えてもらえますか？ 求人カード改修プロジェクトとは？ 堀内 : それでは､プロジェクト説明に先立ちまして､まず、ジョブメドレーの「求人カード」について簡単に説明します。 ジョブメドレーで求人を検索すると､検索結果が並ぶ画面が出てきます。我々が「求人カード」と呼んでいるのは、この検索結果画面上に表示される、求人情報のことになります。 検索結果画面の求人カードでは、給与や大まかな業務内容、応募要件、職場の住所などが分かる形になっていますが、求職者の方々がより便利に使っていただけるよう、情報の出し方を見直すことが今回のプロジェクト内容です。 もう少し詳しくお話すると､採用決定率の改善を目的に､どのような改善を実施すべきか検討しています｡ 求職者にとって欲しい情報が手に入りやすくなるということは、その分、応募に繋がりやすくなると言い換えることもできますので､改修による効果については、継続的に検証し､効果の有無を明らかにしたいと考えています｡ 新居 : なるほど。端的に言うと、ジョブメドレーにおける求人情報検索の体験を更に良くする為のプロジェクトということですね。 プロジェクトのはじまり 新居 : 今回のプロジェクトをどのようなメンバーと何をどのように行っていったのか、チーム構成から教えてください。 堀内 : チーム構成としては、自分を含めたエンジニアが 2 人いて、その他は、デザイナー、マーケター、プロダクトマネージャー（以下、PdM）がそれぞれ 1 人ずつプロジェクトにアサインされました。 プロジェクトのきっかけとしては、求職者体験を更に良くする為の企画の一つとしてマーケターと PdM が企画したところから始まり、その後、エンジニアとマーケター間で､細かい具体的な要件まで落とし込んで、プロジェクト化に至りました。 仕様についてメンバー間で徹底議論 堀内 : 要件まで落とし込んだ後は、具体的にそれらをどうやって実装するかを検討しました。特に UI の仕様については、デザイナーを中心にかなり長い時間をかけて詰めていきました 。 新居 : 確かに、情報の出し方によっては、かえって、求職者体験を悪化させてしまう可能性がありそうですね…。 堀内 : はい。使い勝手の良い UI にする為に、デザイナーがまず Figma でモックアップを作り、プロジェクトが始まった最初の週からデイリーの夕会などで、UI に関して徹底的にプロジェクトメンバー間で議論をしていました。 その時、特にメンバー全員が気を付けていたのは、実際に求職者が新しい一覧画面を使う時に、価値を感じてもらえるかどうかです。メドレーの Our Essentials の一つとして、 長期のカスタマー価値を追求 という項目があります｡「全ての利用者にとって価値のある施策であること」､「利用者の片方だけを見て、もう片方を無視することがあってはならない」ということで、事業者側の求人情報を多く載せるだけではなく、求職者にとっての使い勝手も向上しているか？などを徹底的にチェックしていました。 使い勝手をチェックするにあたって、ジョブメドレーのメインユーザーの年齢層などが予め分かっていたので、その方達にとって使いやすいかどうかを判断軸として、考えていました。 デザイナーが完成させた UI でも、でき上がったモックアップをメンバーそれぞれの視点で触ってみると､改善点が出る場面がありました。そういった場合には、こういう UI にしてみたらどうか？などとそれぞれが意見し、良さそうな案についてはデザイナーがそれらの提案を取り込んだり､改良したりして、UI の仕様を詰めていきました。 技術面について 新居 : UI を実装に落とし込む際、技術面で工夫した点や気を付けていたポイントなどはありますか？ 堀内 : 今回のプロジェクトでは、求人カードのデザインを大幅に変更する為､事前の影響範囲の洗い出しを徹底するよう注意していました｡例えば、一覧画面における求人情報の出力量がかなり増えることで、1 ページあたりの読み込み処理に時間がかかってしまうことが予想された為､コンテンツの遅延読み込みやキャッシュの利用によりチューニングを行っています｡また､デザイン変更が多くのページにわたって発生する為､リリース後の不具合を起こさないような対策を複数行っています｡ 担当したプロジェクトのリード 新居 : 今回のプロジェクトでは、エンジニアとして開発をしつつ、堀内さんがプロジェクトのリードを任されていたと聞いています。リードとしては、どんな動きをプロジェクトの中でされていたのでしょうか？ 堀内 : まずは、最初にプロジェクト全体の大まかなスケジュールを引き、PdM と確認しました。次に、タスク分解をしてメンバーへのアサインを行ったり、プロジェクトのタスクのなかで不確実性を極力少なくする為に、自分達だけではコントロールできなさそうな部分を洗い出したりしました。洗い出したアンコントローラブルな部分は企画者と共に関係各所へ連絡・調整をしてもらうようお願いしていました。 新居 : なるほど。開発スケジュールの出し方など、その辺りで工夫した点などはありますか？ 堀内 : スケジュールの共有方法については、視覚的に分かりやすいように、 FigJam を使って、ガントチャートのような形式で、ボードを作成しました。 メンバー毎にレーンを振り分けて、誰がいつまでに何をしなければいけないのかを夕会で確認していました。また、スケジュールのボードは常に、 第三者が見ても進捗状況が直ぐに分かるような状態にしておく よう努めました。 スケジュールボード スケジューリングで特に意識していたことは、不確実な部分を早めに洗い出すことでした。タスク分解をしていく中で、どこが自分達だけではコントロールできなさそうな部分なのかを把握することから始めていました。 現状の仕様や実装がどうなっているのかなどは直ぐに確認できるので、そういったところから、なるべく不確実な部分を減らしていき、最終的に各タスクの工数を算出するにあたって、不確実性の高さに応じて、バッファを設定しました。 新居 : 少し手を動かせば確認できるようなところは直ぐに確認して、なるべく解像度が高い状態にもっていく進め方は確かに良さそうですね！工数を見積もるにあたって、解像度が低い状態だと、見積もりの精度が低くなってしまいますからね。 堀内 : また、タスクは GitHub Issue を発行して管理していたのですが、切り出す粒度はなるべく細かくしていました。Issue の粒度が荒くなってしまうと、それに比例して手戻りリスクが高くなってしまうので、目安としては、長くても 2 日以内には完了できる粒度で切り出していました。 結果、今回のプロジェクトにおいては、ほとんど手戻りすることなく、ほぼ全ての期間において、オンスケジュールで進めることができました。 A/B テストの導入（効果検証の仕組み化） 新居 : オンスケで進められていたのは素晴らしいですね！開発者として実装することと、リードとしてプロジェクトを管理することの他、堀内さんが今回のプロジェクトで担当していた役割などはありますか？ 堀内 : 今回のプロジェクトでは、効果検証を行う為の仕組みとして、A/B テストを本格的に導入する目標がありました。なぜ A/B テストを導入するのか？ A/B テストで何をしたいのか？を明確にして、A/B テストの設計から導入､分析までを行いました。 統計的な分析手法の選択から実際のテスト環境の開発みたいなところまで一気通貫で、PdM、マーケター、エンジニアを巻き込んで行いました。 A/B テストで大事なのは、論理的な仮説を立ててそれを検証し、その結果からより効果があると判断できた施策を導入していく、というサイクルだと考えています｡とはいえ、有意差が出たからといって必ずしも導入したほうが良いというわけではありません｡その時の経営面のメリット・デメリットを考慮し､これまでの経験にもとづいた判断も加えて、より効果の高い施策を継続的に導入できるようにする、というのが今回の目標です｡ 今回のプロジェクトを皮切りに、他のプロジェクトでも同じように A/B テストの仕組みを使える状態にしたい。そういった横展開や汎用性みたいなところも、プロジェクト当初からセットで考えていました。 新居 : とても興味深い取り組みですね！実際、どのように仕組み化を進めていくのでしょうか？ 堀内 : A/B テストに必要な知見をドキュメント化して、それを見るだけで、エンジニアのサポートを受けつつ誰でも A/B テストが実施できるようにしていく取り組みや､スプレッドシートにデータを入力すれば、簡単に結果が判るような仕組み化を進行中です｡ 機能のリリース時は､その結果に応じて結局、どうすれば良いのか？といった指針も Issue やドキュメントに記載しております｡ 実装や設計面における悩み 新居 : 実装や設計面において、今回のプロジェクトで悩んだようなところはありましたか？ 堀内 : はい。自分自身の力量の問題で、ドメイン知識や技術力などが不足していたことから、ジョブメドレーのコードの中で今までの慣習を受け継ぎつつ、良い感じに使い回しができるコードをどう上手く書いていくか、という点について悩んでいました。 新居 : なるほど…。ジョブメドレー自体が 10 年以上の歴史があるサービスなので、そこに手を入れていくのは確かに難しい部分もありそうですね。その悩みに対しては、どう対策をされていたのでしょう？ 堀内 : そうですね。今の自分の知見だけで設計と実装を進めてしまうと手戻りが発生してしまう恐れがあったので、まずはドメイン知識が豊富な、同じチーム内のベテラン社員に設計レビューをお願いしました。そこで、ジョブメドレーのインフラ構成におけるキャッシュ戦略や､保守性を高める為の実装の切り出し方など、壁打ちで相談させてもらっていました。 その先輩社員との設計レビュー以外にも、普段から行ってもらっている 1on1 ミーティングを通じて、自分のメンターと相談させてもらい、どういう設計だったら使いやすいのか、などを様々な視点から検討しました｡ 新居 : なるべく手戻りが発生しないようにする為に、 設計段階で身近にいるエンジニアを巻き込んで進めていった のですね。直ぐに相談できる相手がいるのは心強いですね。 学びになった点 新居 : 今回のプロジェクトを通じて、特に学びになった点を教えていただけますか？ 堀内 : 技術的な面とプロジェクトの進め方の面でそれぞれ学びがありました。 技術的な面で言うと、 保守性が高く、今後、運用しやすいコードとはどういうものなのかというのを、今回の実装を通じて体得できた ところだと思っています。 プロジェクトの進め方の面では、過去のプロジェクトのドキュメントを参考に、そこに書かれていた知見を活かしながら、プロジェクトを進めていったので、ノウハウのようなところが学べたかと思っています。 新卒研修・開発実践のリードとの違い 新居 : 堀内さんは、新卒研修の一環で行われた開発実践の期間中、新卒同士のチーム開発でもリードを務めていたと思います。今回のプロジェクトを通じて経験されたリードとの違いについて教えてください。 堀内 : プロジェクトの規模や影響範囲の違いなどから、研修時よりも多くの関係者との調整が必要でした｡全員と情報を共有・連携しつつ､プロジェクトを進める必要があった点が一番大きな違いでした。 また、開発実践のプロジェクトはあくまで社内向けシステムを構築するものだったので、会社の売上について意識することはありませんでしたが、今回のプロジェクトでは、施策によって応募率が下がった場合に売上に悪影響を及ぼす可能性がありましたので、開発部署以外への影響を意識して管理する必要があったことも大きいポイントだったと思っています。 ジョブメドレーの開発におけるやりがい 新居 : ここまで直近で担当されていたプロジェクトについて聞いてきましたが、ジョブメドレーの開発をしていて、特にやりがいを感じる場面について、教えてもらえますか？ 堀内 : やはり､利用してくださっている求職者や事業者の方々に向けて､新規機能開発や機能改修を行う工程です｡目的と照らし合わせて仕様面から妥協せずに考え抜き、リリースするまでの過程にやりがいを感じています｡ユーザー数がとても多いだけに､良い機能をリリースできたときの反響も大きく､非常に楽しいです｡ 勿論、エンジニアとして技術力を上げていくことも貪欲に今後もやっていかなければならない部分だと思っていますが、企画として案件があがってきた段階で、それをなぜ作るのか？なぜそれで効果が出ると思っているのか？などと考えることが、企画職だけでなく､エンジニアにとっても大事だと考えています｡ リリースした後には、実際に効果が出たのか出なかったのか、なぜ効果が出たのか､出なかったのか？などの効果検証を行った上で、PdM を中心にエンジニア以外のメンバーも交えて振り返り、次の施策に活かしていくといった、 PDCA サイクルを回していっている開発スタイルに楽しさを感じています 。 これは、自分の入社時にやりたいこととしてあげていた、エンジニアリング面だけではなくビジネス面についても多くの経験を積みたい、というところにリンクしていて、今在籍しているジョブメドレーの開発チームでは、企画やマーケティングを行う人達とエンジニアがとても近い距離にいることで、様々な知見を得られつつアウトプットできる､とても学びになる環境だと感じています。 ジョブメドレー開発チームにおける 1 日の流れ 新居 : 現在のジョブメドレー開発チームは、Growth Unit（求職者の利便性を高める施策を行うチーム）と Customer Unit（求人を掲載する事業者が使う採用管理システムの改善施策を行うチーム）の 2 つに分かれているんですよね。堀内さんが所属しているのは、Growth Unit の方ですが、参加されているミーティングなど、1 日の流れについて教えてください。 堀内 : まず、勤務開始の 10:00 頃には Slack に投稿する形で、その日のタスクや参加予定のミーティングなどについて、開発用 channel で共有します。 現在の自分のスケジュールでは、午前中は特に定常的なミーティングはありません。但し、アサインされるプロジェクトによっては、午前中に「朝会」としてプロジェクトメンバー同士が集まって、進捗共有などを行っています。 お昼過ぎの 14:30 からは､ 30 分程度､Growth Unit のエンジニアだけで集まるミーティングがあります。この場では、各自の進捗状況や抱えている不安・不明点などを共有します｡今何に困っているのかを共有するだけでなく､ 困りごとに対し､各々が知恵を出し合って、問題解決までのリードタイムを短くする ことができる貴重な場となっています｡ 18:00 からは「夕会」として、PdM とデザイナーも含めた Growth Unit 全体のミーティングがあります。そこで各自、「今日やったこと」や担当 Issue のリリース目処などを共有しています。この場では、エンジニア以外のメンバーも参加しているので、そこまで技術的に突っ込んだ話まではしません。 さらに、終業前にはまたエンジニアだけで集まり、FigJam を使って付箋を貼っていく形で、 各自が技術的トピックや、特定のドメインについて聞きたいことなどを持ち寄り、ざっくばらんに雑談形式で話す 「技術共有会」を行っています。 技術共有会の雰囲気 ミーティングの場以外は黙々と開発を進めていきますが、聞きたいことや相談したいことが出てきたら都度、開発用のスレッドに投稿しています。 新居 : なるほど。質問や相談はしやすい感じですか？ 堀内 : はい。勿論、自分で調べられることはなるべく調べて、自己解決するのが基本ではありますが、あまり調査に時間をかけ過ぎて全然進まないような事態に陥っても良くないので、それらを皆、前提として意識した上で、聞くべき時は躊躇なく聞ける雰囲気があります。 新居 : ミーティングの種類としては、先ほどあげてもらったもの以外にありますか？ 堀内 : あとは、週一で行われている「プロダクト定例」と隔週で行ってもらっている「1on1 ミーティング」があります。 プロダクト定例は、比較的規模の大きいミーティングで、我々、プロダクト開発室以外のメンバーの他、マーケティング室や事業企画室のメンバーも含めて、大体いつも 40 名前後の人数で参加しています。 この場では、現在追っている KPI だったり、ジョブメドレーで動いている全てのプロジェクト状況が共有されます。そこで共有される KPI の数字によって、次に着手すべき Issue にも影響してくるので、この場で共有される情報をしっかりとインプットして、今後の心構えとすることにしています。 直近で担当したプロジェクトの話でもちらっと出てきましたが、1on1 ミーティングは担当メンターと行なっています。普段の仕事の相談から、自分のキャリアに関するような相談をしており、メンターさんの経験なども教えていただきながら、勉強させていただいています。 1on1 ミーティングの意義としては、そういった仕事の他、 プライベートのことも含めて、何でも相談ができる場 としてあるのですが、1on1 を通じて、メンターさんとの信頼関係も築けるので、チームビルディングの一つとしても機能しています。 ジョブメドレー開発チームで一緒に働きたいと思う人はどんな人？ 新居 : 堀内さんがジョブメドレー開発チームで一緒に働きたいと思う人はどんな人でしょうか？ 堀内 : 今の環境で働いてて良かったなあと思うことは、 人間関係が良好であること です｡もちろん馴れ合いの中での業務というわけではなく､各々が しっかりと仕事に対して責任を持ちつつ､チーム内で生じた違和感は遠慮なく指摘し合い受けとめる という､良い意味で心理的安全性のある環境でプロダクト開発に集中して取り組めることです。 このような環境で、課題に対して長期的な視点で本質を捉え、目的を設定し､ボトムアップで解決策の立案から改善までを主導すること、さらには仕組み化まで行うことが好きな方､またはそれらをやってみたい方が合っているのではないか､と思います。 自分もそのような人間になりたいと思いながら、日々仕事に取り組んでいます。 さいごに ジョブメドレー開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いてきましたが、いかがだったでしょうか？ こんなチームでプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は医療介護求人サイトの ジョブメドレー 開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いていこうと思います。 インタビュイー紹介 堀内さん 2021 年入社。人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 堀内さん メドレーに入社した理由 新居 : まずはじめに、堀内さんはどういう経緯でメドレーに入社したのでしたっけ？ 堀内 : 以前のインタビュー（ 21 年新卒入社エンジニアと座談会で振り返る新卒研修 ）の時にもお話したのですが、就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。特に､ ビジネス側と開発側の距離が近い 部分に惹かれ､総合的にメドレーが良さそうだと考えて入社しました。 新居 : 入社前の印象と実際働きだしてからで、ズレなどはありましたか？ 堀内 : そんなにギャップはなくて、社風とか人間関係みたいなところは入社前のイメージ通りでした。入社前に何回か会社見学をさせてもらったり、その時の社員と複数回面談をセッティングしてもらったりして、そこでイメージをすり合わせできたことが大きかったですね。 新居 : 何人くらいの社員と会ったのですか？ 堀内 : 6 ~ 7 人です。色々なポジションや性格の人達と話ができたので、安心して入社することができました。 新卒研修の開発 OJT ではどんなことをやっていたか？ 新居 : 堀内さんは新卒研修の開発 OJT のタイミングでジョブメドレー開発チームに仮配属されたのですよね。当時はどういうことをやってたのですか？ 堀内 : まずはジョブメドレーのドメイン知識をしっかり吸収していこうということで、業界や業務自体の理解を進めました。 その後、求職者と事業者のサポート業務を行う社内オペレーターが利用する画面の拡張タスクに取り組みました。 技術スタックは Next.js / React / TypeScript / GraphQL といったシステムで、個人的にあまり触れてこなかった領域だったので、技術のキャッチアップもしつつ丁寧に対応していきました。 また、開発 OJT よりも前の研修で輪読会も経験したのですが、その時に学んだ Cookie や Session まわりの知識が役に立ったり、座学で学んだことがこうやって実践で活きてくるんだな、ということを実感 できてとても良い経験になりました。 今までとは比べ物にならないくらい大規模なシステムだったので、プレッシャーも大きかったのですが、チームの人達と相談したり、細かいレビュー・サポートがあったおかげで、しっかり成果を出すことができたと思います。 新居 : 良い OJT ですね！堀内さん自身の努力があったのは勿論ですが、チームに新しいメンバーを迎え入れて成長をサポートする環境が整っていたのも良かったんでしょうね。 ちなみに開発 OJT の中で大変だったこととかはありますか？ 堀内 : そうですね、やはり大規模な既存コードの把握・理解が大変でした。社内オペレーターが使う画面とジョブメドレー本体はそれぞれ別システムとして連携しているので、ジョブメドレー本体のコードや仕組みの理解も必要です。 大変だった分、 システムの全体像を理解するのに大いに役立った ので、今思い返すと良い経験だったなあと思います。 色々な経験を積めた求人カード改修プロジェクト 新居 : では、新卒研修を終えてから 1 年以上経っていて、入社 2 年目の終わりに差し掛かっている現在ですが、直近で堀内さんがリードを務めていた、ジョブメドレーの求人カード改修プロジェクトについて話を聞いていきたいと思います。まずは、このプロジェクトの概要について、教えてもらえますか？ 求人カード改修プロジェクトとは？ 堀内 : それでは､プロジェクト説明に先立ちまして､まず、ジョブメドレーの「求人カード」について簡単に説明します。 ジョブメドレーで求人を検索すると､検索結果が並ぶ画面が出てきます。我々が「求人カード」と呼んでいるのは、この検索結果画面上に表示される、求人情報のことになります。 検索結果画面の求人カードでは、給与や大まかな業務内容、応募要件、職場の住所などが分かる形になっていますが、求職者の方々がより便利に使っていただけるよう、情報の出し方を見直すことが今回のプロジェクト内容です。 もう少し詳しくお話すると､採用決定率の改善を目的に､どのような改善を実施すべきか検討しています｡ 求職者にとって欲しい情報が手に入りやすくなるということは、その分、応募に繋がりやすくなると言い換えることもできますので､改修による効果については、継続的に検証し､効果の有無を明らかにしたいと考えています｡ 新居 : なるほど。端的に言うと、ジョブメドレーにおける求人情報検索の体験を更に良くする為のプロジェクトということですね。 プロジェクトのはじまり 新居 : 今回のプロジェクトをどのようなメンバーと何をどのように行っていったのか、チーム構成から教えてください。 堀内 : チーム構成としては、自分を含めたエンジニアが 2 人いて、その他は、デザイナー、マーケター、プロダクトマネージャー（以下、PdM）がそれぞれ 1 人ずつプロジェクトにアサインされました。 プロジェクトのきっかけとしては、求職者体験を更に良くする為の企画の一つとしてマーケターと PdM が企画したところから始まり、その後、エンジニアとマーケター間で､細かい具体的な要件まで落とし込んで、プロジェクト化に至りました。 仕様についてメンバー間で徹底議論 堀内 : 要件まで落とし込んだ後は、具体的にそれらをどうやって実装するかを検討しました。特に UI の仕様については、デザイナーを中心にかなり長い時間をかけて詰めていきました 。 新居 : 確かに、情報の出し方によっては、かえって、求職者体験を悪化させてしまう可能性がありそうですね…。 堀内 : はい。使い勝手の良い UI にする為に、デザイナーがまず Figma でモックアップを作り、プロジェクトが始まった最初の週からデイリーの夕会などで、UI に関して徹底的にプロジェクトメンバー間で議論をしていました。 その時、特にメンバー全員が気を付けていたのは、実際に求職者が新しい一覧画面を使う時に、価値を感じてもらえるかどうかです。メドレーの Our Essentials の一つとして、 長期のカスタマー価値を追求 という項目があります｡「全ての利用者にとって価値のある施策であること」､「利用者の片方だけを見て、もう片方を無視することがあってはならない」ということで、事業者側の求人情報を多く載せるだけではなく、求職者にとっての使い勝手も向上しているか？などを徹底的にチェックしていました。 使い勝手をチェックするにあたって、ジョブメドレーのメインユーザーの年齢層などが予め分かっていたので、その方達にとって使いやすいかどうかを判断軸として、考えていました。 デザイナーが完成させた UI でも、でき上がったモックアップをメンバーそれぞれの視点で触ってみると､改善点が出る場面がありました。そういった場合には、こういう UI にしてみたらどうか？などとそれぞれが意見し、良さそうな案についてはデザイナーがそれらの提案を取り込んだり､改良したりして、UI の仕様を詰めていきました。 技術面について 新居 : UI を実装に落とし込む際、技術面で工夫した点や気を付けていたポイントなどはありますか？ 堀内 : 今回のプロジェクトでは、求人カードのデザインを大幅に変更する為､事前の影響範囲の洗い出しを徹底するよう注意していました｡例えば、一覧画面における求人情報の出力量がかなり増えることで、1 ページあたりの読み込み処理に時間がかかってしまうことが予想された為､コンテンツの遅延読み込みやキャッシュの利用によりチューニングを行っています｡また､デザイン変更が多くのページにわたって発生する為､リリース後の不具合を起こさないような対策を複数行っています｡ 担当したプロジェクトのリード 新居 : 今回のプロジェクトでは、エンジニアとして開発をしつつ、堀内さんがプロジェクトのリードを任されていたと聞いています。リードとしては、どんな動きをプロジェクトの中でされていたのでしょうか？ 堀内 : まずは、最初にプロジェクト全体の大まかなスケジュールを引き、PdM と確認しました。次に、タスク分解をしてメンバーへのアサインを行ったり、プロジェクトのタスクのなかで不確実性を極力少なくする為に、自分達だけではコントロールできなさそうな部分を洗い出したりしました。洗い出したアンコントローラブルな部分は企画者と共に関係各所へ連絡・調整をしてもらうようお願いしていました。 新居 : なるほど。開発スケジュールの出し方など、その辺りで工夫した点などはありますか？ 堀内 : スケジュールの共有方法については、視覚的に分かりやすいように、 FigJam を使って、ガントチャートのような形式で、ボードを作成しました。 メンバー毎にレーンを振り分けて、誰がいつまでに何をしなければいけないのかを夕会で確認していました。また、スケジュールのボードは常に、 第三者が見ても進捗状況が直ぐに分かるような状態にしておく よう努めました。 スケジュールボード スケジューリングで特に意識していたことは、不確実な部分を早めに洗い出すことでした。タスク分解をしていく中で、どこが自分達だけではコントロールできなさそうな部分なのかを把握することから始めていました。 現状の仕様や実装がどうなっているのかなどは直ぐに確認できるので、そういったところから、なるべく不確実な部分を減らしていき、最終的に各タスクの工数を算出するにあたって、不確実性の高さに応じて、バッファを設定しました。 新居 : 少し手を動かせば確認できるようなところは直ぐに確認して、なるべく解像度が高い状態にもっていく進め方は確かに良さそうですね！工数を見積もるにあたって、解像度が低い状態だと、見積もりの精度が低くなってしまいますからね。 堀内 : また、タスクは GitHub Issue を発行して管理していたのですが、切り出す粒度はなるべく細かくしていました。Issue の粒度が荒くなってしまうと、それに比例して手戻りリスクが高くなってしまうので、目安としては、長くても 2 日以内には完了できる粒度で切り出していました。 結果、今回のプロジェクトにおいては、ほとんど手戻りすることなく、ほぼ全ての期間において、オンスケジュールで進めることができました。 A/B テストの導入（効果検証の仕組み化） 新居 : オンスケで進められていたのは素晴らしいですね！開発者として実装することと、リードとしてプロジェクトを管理することの他、堀内さんが今回のプロジェクトで担当していた役割などはありますか？ 堀内 : 今回のプロジェクトでは、効果検証を行う為の仕組みとして、A/B テストを本格的に導入する目標がありました。なぜ A/B テストを導入するのか？ A/B テストで何をしたいのか？を明確にして、A/B テストの設計から導入､分析までを行いました。 統計的な分析手法の選択から実際のテスト環境の開発みたいなところまで一気通貫で、PdM、マーケター、エンジニアを巻き込んで行いました。 A/B テストで大事なのは、論理的な仮説を立ててそれを検証し、その結果からより効果があると判断できた施策を導入していく、というサイクルだと考えています｡とはいえ、有意差が出たからといって必ずしも導入したほうが良いというわけではありません｡その時の経営面のメリット・デメリットを考慮し､これまでの経験にもとづいた判断も加えて、より効果の高い施策を継続的に導入できるようにする、というのが今回の目標です｡ 今回のプロジェクトを皮切りに、他のプロジェクトでも同じように A/B テストの仕組みを使える状態にしたい。そういった横展開や汎用性みたいなところも、プロジェクト当初からセットで考えていました。 新居 : とても興味深い取り組みですね！実際、どのように仕組み化を進めていくのでしょうか？ 堀内 : A/B テストに必要な知見をドキュメント化して、それを見るだけで、エンジニアのサポートを受けつつ誰でも A/B テストが実施できるようにしていく取り組みや､スプレッドシートにデータを入力すれば、簡単に結果が判るような仕組み化を進行中です｡ 機能のリリース時は､その結果に応じて結局、どうすれば良いのか？といった指針も Issue やドキュメントに記載しております｡ 実装や設計面における悩み 新居 : 実装や設計面において、今回のプロジェクトで悩んだようなところはありましたか？ 堀内 : はい。自分自身の力量の問題で、ドメイン知識や技術力などが不足していたことから、ジョブメドレーのコードの中で今までの慣習を受け継ぎつつ、良い感じに使い回しができるコードをどう上手く書いていくか、という点について悩んでいました。 新居 : なるほど…。ジョブメドレー自体が 10 年以上の歴史があるサービスなので、そこに手を入れていくのは確かに難しい部分もありそうですね。その悩みに対しては、どう対策をされていたのでしょう？ 堀内 : そうですね。今の自分の知見だけで設計と実装を進めてしまうと手戻りが発生してしまう恐れがあったので、まずはドメイン知識が豊富な、同じチーム内のベテラン社員に設計レビューをお願いしました。そこで、ジョブメドレーのインフラ構成におけるキャッシュ戦略や､保守性を高める為の実装の切り出し方など、壁打ちで相談させてもらっていました。 その先輩社員との設計レビュー以外にも、普段から行ってもらっている 1on1 ミーティングを通じて、自分のメンターと相談させてもらい、どういう設計だったら使いやすいのか、などを様々な視点から検討しました｡ 新居 : なるべく手戻りが発生しないようにする為に、 設計段階で身近にいるエンジニアを巻き込んで進めていった のですね。直ぐに相談できる相手がいるのは心強いですね。 学びになった点 新居 : 今回のプロジェクトを通じて、特に学びになった点を教えていただけますか？ 堀内 : 技術的な面とプロジェクトの進め方の面でそれぞれ学びがありました。 技術的な面で言うと、 保守性が高く、今後、運用しやすいコードとはどういうものなのかというのを、今回の実装を通じて体得できた ところだと思っています。 プロジェクトの進め方の面では、過去のプロジェクトのドキュメントを参考に、そこに書かれていた知見を活かしながら、プロジェクトを進めていったので、ノウハウのようなところが学べたかと思っています。 新卒研修・開発実践のリードとの違い 新居 : 堀内さんは、新卒研修の一環で行われた開発実践の期間中、新卒同士のチーム開発でもリードを務めていたと思います。今回のプロジェクトを通じて経験されたリードとの違いについて教えてください。 堀内 : プロジェクトの規模や影響範囲の違いなどから、研修時よりも多くの関係者との調整が必要でした｡全員と情報を共有・連携しつつ､プロジェクトを進める必要があった点が一番大きな違いでした。 また、開発実践のプロジェクトはあくまで社内向けシステムを構築するものだったので、会社の売上について意識することはありませんでしたが、今回のプロジェクトでは、施策によって応募率が下がった場合に売上に悪影響を及ぼす可能性がありましたので、開発部署以外への影響を意識して管理する必要があったことも大きいポイントだったと思っています。 ジョブメドレーの開発におけるやりがい 新居 : ここまで直近で担当されていたプロジェクトについて聞いてきましたが、ジョブメドレーの開発をしていて、特にやりがいを感じる場面について、教えてもらえますか？ 堀内 : やはり､利用してくださっている求職者や事業者の方々に向けて､新規機能開発や機能改修を行う工程です｡目的と照らし合わせて仕様面から妥協せずに考え抜き、リリースするまでの過程にやりがいを感じています｡ユーザー数がとても多いだけに､良い機能をリリースできたときの反響も大きく､非常に楽しいです｡ 勿論、エンジニアとして技術力を上げていくことも貪欲に今後もやっていかなければならない部分だと思っていますが、企画として案件があがってきた段階で、それをなぜ作るのか？なぜそれで効果が出ると思っているのか？などと考えることが、企画職だけでなく､エンジニアにとっても大事だと考えています｡ リリースした後には、実際に効果が出たのか出なかったのか、なぜ効果が出たのか､出なかったのか？などの効果検証を行った上で、PdM を中心にエンジニア以外のメンバーも交えて振り返り、次の施策に活かしていくといった、 PDCA サイクルを回していっている開発スタイルに楽しさを感じています 。 これは、自分の入社時にやりたいこととしてあげていた、エンジニアリング面だけではなくビジネス面についても多くの経験を積みたい、というところにリンクしていて、今在籍しているジョブメドレーの開発チームでは、企画やマーケティングを行う人達とエンジニアがとても近い距離にいることで、様々な知見を得られつつアウトプットできる､とても学びになる環境だと感じています。 ジョブメドレー開発チームにおける 1 日の流れ 新居 : 現在のジョブメドレー開発チームは、Growth Unit（求職者の利便性を高める施策を行うチーム）と Customer Unit（求人を掲載する事業者が使う採用管理システムの改善施策を行うチーム）の 2 つに分かれているんですよね。堀内さんが所属しているのは、Growth Unit の方ですが、参加されているミーティングなど、1 日の流れについて教えてください。 堀内 : まず、勤務開始の 10:00 頃には Slack に投稿する形で、その日のタスクや参加予定のミーティングなどについて、開発用 channel で共有します。 現在の自分のスケジュールでは、午前中は特に定常的なミーティングはありません。但し、アサインされるプロジェクトによっては、午前中に「朝会」としてプロジェクトメンバー同士が集まって、進捗共有などを行っています。 お昼過ぎの 14:30 からは､ 30 分程度､Growth Unit のエンジニアだけで集まるミーティングがあります。この場では、各自の進捗状況や抱えている不安・不明点などを共有します｡今何に困っているのかを共有するだけでなく､ 困りごとに対し､各々が知恵を出し合って、問題解決までのリードタイムを短くする ことができる貴重な場となっています｡ 18:00 からは「夕会」として、PdM とデザイナーも含めた Growth Unit 全体のミーティングがあります。そこで各自、「今日やったこと」や担当 Issue のリリース目処などを共有しています。この場では、エンジニア以外のメンバーも参加しているので、そこまで技術的に突っ込んだ話まではしません。 さらに、終業前にはまたエンジニアだけで集まり、FigJam を使って付箋を貼っていく形で、 各自が技術的トピックや、特定のドメインについて聞きたいことなどを持ち寄り、ざっくばらんに雑談形式で話す 「技術共有会」を行っています。 技術共有会の雰囲気 ミーティングの場以外は黙々と開発を進めていきますが、聞きたいことや相談したいことが出てきたら都度、開発用のスレッドに投稿しています。 新居 : なるほど。質問や相談はしやすい感じですか？ 堀内 : はい。勿論、自分で調べられることはなるべく調べて、自己解決するのが基本ではありますが、あまり調査に時間をかけ過ぎて全然進まないような事態に陥っても良くないので、それらを皆、前提として意識した上で、聞くべき時は躊躇なく聞ける雰囲気があります。 新居 : ミーティングの種類としては、先ほどあげてもらったもの以外にありますか？ 堀内 : あとは、週一で行われている「プロダクト定例」と隔週で行ってもらっている「1on1 ミーティング」があります。 プロダクト定例は、比較的規模の大きいミーティングで、我々、プロダクト開発室以外のメンバーの他、マーケティング室や事業企画室のメンバーも含めて、大体いつも 40 名前後の人数で参加しています。 この場では、現在追っている KPI だったり、ジョブメドレーで動いている全てのプロジェクト状況が共有されます。そこで共有される KPI の数字によって、次に着手すべき Issue にも影響してくるので、この場で共有される情報をしっかりとインプットして、今後の心構えとすることにしています。 直近で担当したプロジェクトの話でもちらっと出てきましたが、1on1 ミーティングは担当メンターと行なっています。普段の仕事の相談から、自分のキャリアに関するような相談をしており、メンターさんの経験なども教えていただきながら、勉強させていただいています。 1on1 ミーティングの意義としては、そういった仕事の他、 プライベートのことも含めて、何でも相談ができる場 としてあるのですが、1on1 を通じて、メンターさんとの信頼関係も築けるので、チームビルディングの一つとしても機能しています。 ジョブメドレー開発チームで一緒に働きたいと思う人はどんな人？ 新居 : 堀内さんがジョブメドレー開発チームで一緒に働きたいと思う人はどんな人でしょうか？ 堀内 : 今の環境で働いてて良かったなあと思うことは、 人間関係が良好であること です｡もちろん馴れ合いの中での業務というわけではなく､各々が しっかりと仕事に対して責任を持ちつつ､チーム内で生じた違和感は遠慮なく指摘し合い受けとめる という､良い意味で心理的安全性のある環境でプロダクト開発に集中して取り組めることです。 このような環境で、課題に対して長期的な視点で本質を捉え、目的を設定し､ボトムアップで解決策の立案から改善までを主導すること、さらには仕組み化まで行うことが好きな方､またはそれらをやってみたい方が合っているのではないか､と思います。 自分もそのような人間になりたいと思いながら、日々仕事に取り組んでいます。 さいごに ジョブメドレー開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いてきましたが、いかがだったでしょうか？ こんなチームでプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は医療介護求人サイトの ジョブメドレー 開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いていこうと思います。 インタビュイー紹介 堀内さん 2021 年入社。人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 堀内さん メドレーに入社した理由 新居 : まずはじめに、堀内さんはどういう経緯でメドレーに入社したのでしたっけ？ 堀内 : 以前のインタビュー（ 21 年新卒入社エンジニアと座談会で振り返る新卒研修 ）の時にもお話したのですが、就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。特に､ ビジネス側と開発側の距離が近い 部分に惹かれ､総合的にメドレーが良さそうだと考えて入社しました。 新居 : 入社前の印象と実際働きだしてからで、ズレなどはありましたか？ 堀内 : そんなにギャップはなくて、社風とか人間関係みたいなところは入社前のイメージ通りでした。入社前に何回か会社見学をさせてもらったり、その時の社員と複数回面談をセッティングしてもらったりして、そこでイメージをすり合わせできたことが大きかったですね。 新居 : 何人くらいの社員と会ったのですか？ 堀内 : 6 ~ 7 人です。色々なポジションや性格の人達と話ができたので、安心して入社することができました。 新卒研修の開発 OJT ではどんなことをやっていたか？ 新居 : 堀内さんは新卒研修の開発 OJT のタイミングでジョブメドレー開発チームに仮配属されたのですよね。当時はどういうことをやってたのですか？ 堀内 : まずはジョブメドレーのドメイン知識をしっかり吸収していこうということで、業界や業務自体の理解を進めました。 その後、求職者と事業者のサポート業務を行う社内オペレーターが利用する画面の拡張タスクに取り組みました。 技術スタックは Next.js / React / TypeScript / GraphQL といったシステムで、個人的にあまり触れてこなかった領域だったので、技術のキャッチアップもしつつ丁寧に対応していきました。 また、開発 OJT よりも前の研修で輪読会も経験したのですが、その時に学んだ Cookie や Session まわりの知識が役に立ったり、座学で学んだことがこうやって実践で活きてくるんだな、ということを実感 できてとても良い経験になりました。 今までとは比べ物にならないくらい大規模なシステムだったので、プレッシャーも大きかったのですが、チームの人達と相談したり、細かいレビュー・サポートがあったおかげで、しっかり成果を出すことができたと思います。 新居 : 良い OJT ですね！堀内さん自身の努力があったのは勿論ですが、チームに新しいメンバーを迎え入れて成長をサポートする環境が整っていたのも良かったんでしょうね。 ちなみに開発 OJT の中で大変だったこととかはありますか？ 堀内 : そうですね、やはり大規模な既存コードの把握・理解が大変でした。社内オペレーターが使う画面とジョブメドレー本体はそれぞれ別システムとして連携しているので、ジョブメドレー本体のコードや仕組みの理解も必要です。 大変だった分、 システムの全体像を理解するのに大いに役立った ので、今思い返すと良い経験だったなあと思います。 色々な経験を積めた求人カード改修プロジェクト 新居 : では、新卒研修を終えてから 1 年以上経っていて、入社 2 年目の終わりに差し掛かっている現在ですが、直近で堀内さんがリードを務めていた、ジョブメドレーの求人カード改修プロジェクトについて話を聞いていきたいと思います。まずは、このプロジェクトの概要について、教えてもらえますか？ 求人カード改修プロジェクトとは？ 堀内 : それでは､プロジェクト説明に先立ちまして､まず、ジョブメドレーの「求人カード」について簡単に説明します。 ジョブメドレーで求人を検索すると､検索結果が並ぶ画面が出てきます。我々が「求人カード」と呼んでいるのは、この検索結果画面上に表示される、求人情報のことになります。 検索結果画面の求人カードでは、給与や大まかな業務内容、応募要件、職場の住所などが分かる形になっていますが、求職者の方々がより便利に使っていただけるよう、情報の出し方を見直すことが今回のプロジェクト内容です。 もう少し詳しくお話すると､採用決定率の改善を目的に､どのような改善を実施すべきか検討しています｡ 求職者にとって欲しい情報が手に入りやすくなるということは、その分、応募に繋がりやすくなると言い換えることもできますので､改修による効果については、継続的に検証し､効果の有無を明らかにしたいと考えています｡ 新居 : なるほど。端的に言うと、ジョブメドレーにおける求人情報検索の体験を更に良くする為のプロジェクトということですね。 プロジェクトのはじまり 新居 : 今回のプロジェクトをどのようなメンバーと何をどのように行っていったのか、チーム構成から教えてください。 堀内 : チーム構成としては、自分を含めたエンジニアが 2 人いて、その他は、デザイナー、マーケター、プロダクトマネージャー（以下、PdM）がそれぞれ 1 人ずつプロジェクトにアサインされました。 プロジェクトのきっかけとしては、求職者体験を更に良くする為の企画の一つとしてマーケターと PdM が企画したところから始まり、その後、エンジニアとマーケター間で､細かい具体的な要件まで落とし込んで、プロジェクト化に至りました。 仕様についてメンバー間で徹底議論 堀内 : 要件まで落とし込んだ後は、具体的にそれらをどうやって実装するかを検討しました。特に UI の仕様については、デザイナーを中心にかなり長い時間をかけて詰めていきました 。 新居 : 確かに、情報の出し方によっては、かえって、求職者体験を悪化させてしまう可能性がありそうですね…。 堀内 : はい。使い勝手の良い UI にする為に、デザイナーがまず Figma でモックアップを作り、プロジェクトが始まった最初の週からデイリーの夕会などで、UI に関して徹底的にプロジェクトメンバー間で議論をしていました。 その時、特にメンバー全員が気を付けていたのは、実際に求職者が新しい一覧画面を使う時に、価値を感じてもらえるかどうかです。メドレーの Our Essentials の一つとして、 長期のカスタマー価値を追求 という項目があります｡「全ての利用者にとって価値のある施策であること」､「利用者の片方だけを見て、もう片方を無視することがあってはならない」ということで、事業者側の求人情報を多く載せるだけではなく、求職者にとっての使い勝手も向上しているか？などを徹底的にチェックしていました。 使い勝手をチェックするにあたって、ジョブメドレーのメインユーザーの年齢層などが予め分かっていたので、その方達にとって使いやすいかどうかを判断軸として、考えていました。 デザイナーが完成させた UI でも、でき上がったモックアップをメンバーそれぞれの視点で触ってみると､改善点が出る場面がありました。そういった場合には、こういう UI にしてみたらどうか？などとそれぞれが意見し、良さそうな案についてはデザイナーがそれらの提案を取り込んだり､改良したりして、UI の仕様を詰めていきました。 技術面について 新居 : UI を実装に落とし込む際、技術面で工夫した点や気を付けていたポイントなどはありますか？ 堀内 : 今回のプロジェクトでは、求人カードのデザインを大幅に変更する為､事前の影響範囲の洗い出しを徹底するよう注意していました｡例えば、一覧画面における求人情報の出力量がかなり増えることで、1 ページあたりの読み込み処理に時間がかかってしまうことが予想された為､コンテンツの遅延読み込みやキャッシュの利用によりチューニングを行っています｡また､デザイン変更が多くのページにわたって発生する為､リリース後の不具合を起こさないような対策を複数行っています｡ 担当したプロジェクトのリード 新居 : 今回のプロジェクトでは、エンジニアとして開発をしつつ、堀内さんがプロジェクトのリードを任されていたと聞いています。リードとしては、どんな動きをプロジェクトの中でされていたのでしょうか？ 堀内 : まずは、最初にプロジェクト全体の大まかなスケジュールを引き、PdM と確認しました。次に、タスク分解をしてメンバーへのアサインを行ったり、プロジェクトのタスクのなかで不確実性を極力少なくする為に、自分達だけではコントロールできなさそうな部分を洗い出したりしました。洗い出したアンコントローラブルな部分は企画者と共に関係各所へ連絡・調整をしてもらうようお願いしていました。 新居 : なるほど。開発スケジュールの出し方など、その辺りで工夫した点などはありますか？ 堀内 : スケジュールの共有方法については、視覚的に分かりやすいように、 FigJam を使って、ガントチャートのような形式で、ボードを作成しました。 メンバー毎にレーンを振り分けて、誰がいつまでに何をしなければいけないのかを夕会で確認していました。また、スケジュールのボードは常に、 第三者が見ても進捗状況が直ぐに分かるような状態にしておく よう努めました。 スケジュールボード スケジューリングで特に意識していたことは、不確実な部分を早めに洗い出すことでした。タスク分解をしていく中で、どこが自分達だけではコントロールできなさそうな部分なのかを把握することから始めていました。 現状の仕様や実装がどうなっているのかなどは直ぐに確認できるので、そういったところから、なるべく不確実な部分を減らしていき、最終的に各タスクの工数を算出するにあたって、不確実性の高さに応じて、バッファを設定しました。 新居 : 少し手を動かせば確認できるようなところは直ぐに確認して、なるべく解像度が高い状態にもっていく進め方は確かに良さそうですね！工数を見積もるにあたって、解像度が低い状態だと、見積もりの精度が低くなってしまいますからね。 堀内 : また、タスクは GitHub Issue を発行して管理していたのですが、切り出す粒度はなるべく細かくしていました。Issue の粒度が荒くなってしまうと、それに比例して手戻りリスクが高くなってしまうので、目安としては、長くても 2 日以内には完了できる粒度で切り出していました。 結果、今回のプロジェクトにおいては、ほとんど手戻りすることなく、ほぼ全ての期間において、オンスケジュールで進めることができました。 A/B テストの導入（効果検証の仕組み化） 新居 : オンスケで進められていたのは素晴らしいですね！開発者として実装することと、リードとしてプロジェクトを管理することの他、堀内さんが今回のプロジェクトで担当していた役割などはありますか？ 堀内 : 今回のプロジェクトでは、効果検証を行う為の仕組みとして、A/B テストを本格的に導入する目標がありました。なぜ A/B テストを導入するのか？ A/B テストで何をしたいのか？を明確にして、A/B テストの設計から導入､分析までを行いました。 統計的な分析手法の選択から実際のテスト環境の開発みたいなところまで一気通貫で、PdM、マーケター、エンジニアを巻き込んで行いました。 A/B テストで大事なのは、論理的な仮説を立ててそれを検証し、その結果からより効果があると判断できた施策を導入していく、というサイクルだと考えています｡とはいえ、有意差が出たからといって必ずしも導入したほうが良いというわけではありません｡その時の経営面のメリット・デメリットを考慮し､これまでの経験にもとづいた判断も加えて、より効果の高い施策を継続的に導入できるようにする、というのが今回の目標です｡ 今回のプロジェクトを皮切りに、他のプロジェクトでも同じように A/B テストの仕組みを使える状態にしたい。そういった横展開や汎用性みたいなところも、プロジェクト当初からセットで考えていました。 新居 : とても興味深い取り組みですね！実際、どのように仕組み化を進めていくのでしょうか？ 堀内 : A/B テストに必要な知見をドキュメント化して、それを見るだけで、エンジニアのサポートを受けつつ誰でも A/B テストが実施できるようにしていく取り組みや､スプレッドシートにデータを入力すれば、簡単に結果が判るような仕組み化を進行中です｡ 機能のリリース時は､その結果に応じて結局、どうすれば良いのか？といった指針も Issue やドキュメントに記載しております｡ 実装や設計面における悩み 新居 : 実装や設計面において、今回のプロジェクトで悩んだようなところはありましたか？ 堀内 : はい。自分自身の力量の問題で、ドメイン知識や技術力などが不足していたことから、ジョブメドレーのコードの中で今までの慣習を受け継ぎつつ、良い感じに使い回しができるコードをどう上手く書いていくか、という点について悩んでいました。 新居 : なるほど…。ジョブメドレー自体が 10 年以上の歴史があるサービスなので、そこに手を入れていくのは確かに難しい部分もありそうですね。その悩みに対しては、どう対策をされていたのでしょう？ 堀内 : そうですね。今の自分の知見だけで設計と実装を進めてしまうと手戻りが発生してしまう恐れがあったので、まずはドメイン知識が豊富な、同じチーム内のベテラン社員に設計レビューをお願いしました。そこで、ジョブメドレーのインフラ構成におけるキャッシュ戦略や､保守性を高める為の実装の切り出し方など、壁打ちで相談させてもらっていました。 その先輩社員との設計レビュー以外にも、普段から行ってもらっている 1on1 ミーティングを通じて、自分のメンターと相談させてもらい、どういう設計だったら使いやすいのか、などを様々な視点から検討しました｡ 新居 : なるべく手戻りが発生しないようにする為に、 設計段階で身近にいるエンジニアを巻き込んで進めていった のですね。直ぐに相談できる相手がいるのは心強いですね。 学びになった点 新居 : 今回のプロジェクトを通じて、特に学びになった点を教えていただけますか？ 堀内 : 技術的な面とプロジェクトの進め方の面でそれぞれ学びがありました。 技術的な面で言うと、 保守性が高く、今後、運用しやすいコードとはどういうものなのかというのを、今回の実装を通じて体得できた ところだと思っています。 プロジェクトの進め方の面では、過去のプロジェクトのドキュメントを参考に、そこに書かれていた知見を活かしながら、プロジェクトを進めていったので、ノウハウのようなところが学べたかと思っています。 新卒研修・開発実践のリードとの違い 新居 : 堀内さんは、新卒研修の一環で行われた開発実践の期間中、新卒同士のチーム開発でもリードを務めていたと思います。今回のプロジェクトを通じて経験されたリードとの違いについて教えてください。 堀内 : プロジェクトの規模や影響範囲の違いなどから、研修時よりも多くの関係者との調整が必要でした｡全員と情報を共有・連携しつつ､プロジェクトを進める必要があった点が一番大きな違いでした。 また、開発実践のプロジェクトはあくまで社内向けシステムを構築するものだったので、会社の売上について意識することはありませんでしたが、今回のプロジェクトでは、施策によって応募率が下がった場合に売上に悪影響を及ぼす可能性がありましたので、開発部署以外への影響を意識して管理する必要があったことも大きいポイントだったと思っています。 ジョブメドレーの開発におけるやりがい 新居 : ここまで直近で担当されていたプロジェクトについて聞いてきましたが、ジョブメドレーの開発をしていて、特にやりがいを感じる場面について、教えてもらえますか？ 堀内 : やはり､利用してくださっている求職者や事業者の方々に向けて､新規機能開発や機能改修を行う工程です｡目的と照らし合わせて仕様面から妥協せずに考え抜き、リリースするまでの過程にやりがいを感じています｡ユーザー数がとても多いだけに､良い機能をリリースできたときの反響も大きく､非常に楽しいです｡ 勿論、エンジニアとして技術力を上げていくことも貪欲に今後もやっていかなければならない部分だと思っていますが、企画として案件があがってきた段階で、それをなぜ作るのか？なぜそれで効果が出ると思っているのか？などと考えることが、企画職だけでなく､エンジニアにとっても大事だと考えています｡ リリースした後には、実際に効果が出たのか出なかったのか、なぜ効果が出たのか､出なかったのか？などの効果検証を行った上で、PdM を中心にエンジニア以外のメンバーも交えて振り返り、次の施策に活かしていくといった、 PDCA サイクルを回していっている開発スタイルに楽しさを感じています 。 これは、自分の入社時にやりたいこととしてあげていた、エンジニアリング面だけではなくビジネス面についても多くの経験を積みたい、というところにリンクしていて、今在籍しているジョブメドレーの開発チームでは、企画やマーケティングを行う人達とエンジニアがとても近い距離にいることで、様々な知見を得られつつアウトプットできる､とても学びになる環境だと感じています。 ジョブメドレー開発チームにおける 1 日の流れ 新居 : 現在のジョブメドレー開発チームは、Growth Unit（求職者の利便性を高める施策を行うチーム）と Customer Unit（求人を掲載する事業者が使う採用管理システムの改善施策を行うチーム）の 2 つに分かれているんですよね。堀内さんが所属しているのは、Growth Unit の方ですが、参加されているミーティングなど、1 日の流れについて教えてください。 堀内 : まず、勤務開始の 10:00 頃には Slack に投稿する形で、その日のタスクや参加予定のミーティングなどについて、開発用 channel で共有します。 現在の自分のスケジュールでは、午前中は特に定常的なミーティングはありません。但し、アサインされるプロジェクトによっては、午前中に「朝会」としてプロジェクトメンバー同士が集まって、進捗共有などを行っています。 お昼過ぎの 14:30 からは､ 30 分程度､Growth Unit のエンジニアだけで集まるミーティングがあります。この場では、各自の進捗状況や抱えている不安・不明点などを共有します｡今何に困っているのかを共有するだけでなく､ 困りごとに対し､各々が知恵を出し合って、問題解決までのリードタイムを短くする ことができる貴重な場となっています｡ 18:00 からは「夕会」として、PdM とデザイナーも含めた Growth Unit 全体のミーティングがあります。そこで各自、「今日やったこと」や担当 Issue のリリース目処などを共有しています。この場では、エンジニア以外のメンバーも参加しているので、そこまで技術的に突っ込んだ話まではしません。 さらに、終業前にはまたエンジニアだけで集まり、FigJam を使って付箋を貼っていく形で、 各自が技術的トピックや、特定のドメインについて聞きたいことなどを持ち寄り、ざっくばらんに雑談形式で話す 「技術共有会」を行っています。 技術共有会の雰囲気 ミーティングの場以外は黙々と開発を進めていきますが、聞きたいことや相談したいことが出てきたら都度、開発用のスレッドに投稿しています。 新居 : なるほど。質問や相談はしやすい感じですか？ 堀内 : はい。勿論、自分で調べられることはなるべく調べて、自己解決するのが基本ではありますが、あまり調査に時間をかけ過ぎて全然進まないような事態に陥っても良くないので、それらを皆、前提として意識した上で、聞くべき時は躊躇なく聞ける雰囲気があります。 新居 : ミーティングの種類としては、先ほどあげてもらったもの以外にありますか？ 堀内 : あとは、週一で行われている「プロダクト定例」と隔週で行ってもらっている「1on1 ミーティング」があります。 プロダクト定例は、比較的規模の大きいミーティングで、我々、プロダクト開発室以外のメンバーの他、マーケティング室や事業企画室のメンバーも含めて、大体いつも 40 名前後の人数で参加しています。 この場では、現在追っている KPI だったり、ジョブメドレーで動いている全てのプロジェクト状況が共有されます。そこで共有される KPI の数字によって、次に着手すべき Issue にも影響してくるので、この場で共有される情報をしっかりとインプットして、今後の心構えとすることにしています。 直近で担当したプロジェクトの話でもちらっと出てきましたが、1on1 ミーティングは担当メンターと行なっています。普段の仕事の相談から、自分のキャリアに関するような相談をしており、メンターさんの経験なども教えていただきながら、勉強させていただいています。 1on1 ミーティングの意義としては、そういった仕事の他、 プライベートのことも含めて、何でも相談ができる場 としてあるのですが、1on1 を通じて、メンターさんとの信頼関係も築けるので、チームビルディングの一つとしても機能しています。 ジョブメドレー開発チームで一緒に働きたいと思う人はどんな人？ 新居 : 堀内さんがジョブメドレー開発チームで一緒に働きたいと思う人はどんな人でしょうか？ 堀内 : 今の環境で働いてて良かったなあと思うことは、 人間関係が良好であること です｡もちろん馴れ合いの中での業務というわけではなく､各々が しっかりと仕事に対して責任を持ちつつ､チーム内で生じた違和感は遠慮なく指摘し合い受けとめる という､良い意味で心理的安全性のある環境でプロダクト開発に集中して取り組めることです。 このような環境で、課題に対して長期的な視点で本質を捉え、目的を設定し､ボトムアップで解決策の立案から改善までを主導すること、さらには仕組み化まで行うことが好きな方､またはそれらをやってみたい方が合っているのではないか､と思います。 自分もそのような人間になりたいと思いながら、日々仕事に取り組んでいます。 さいごに ジョブメドレー開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いてきましたが、いかがだったでしょうか？ こんなチームでプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! https://www.medley.jp/jobs/

はじめに みなさん、こんにちは。エンジニアの新居です。今回は医療介護求人サイトの ジョブメドレー 開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いていこうと思います。 インタビュイー紹介 堀内さん 2021 年入社。人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 堀内さん メドレーに入社した理由 新居 : まずはじめに、堀内さんはどういう経緯でメドレーに入社したのでしたっけ？ 堀内 : 以前のインタビュー（ 21 年新卒入社エンジニアと座談会で振り返る新卒研修 ）の時にもお話したのですが、就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。特に､ ビジネス側と開発側の距離が近い 部分に惹かれ､総合的にメドレーが良さそうだと考えて入社しました。 新居 : 入社前の印象と実際働きだしてからで、ズレなどはありましたか？ 堀内 : そんなにギャップはなくて、社風とか人間関係みたいなところは入社前のイメージ通りでした。入社前に何回か会社見学をさせてもらったり、その時の社員と複数回面談をセッティングしてもらったりして、そこでイメージをすり合わせできたことが大きかったですね。 新居 : 何人くらいの社員と会ったのですか？ 堀内 : 6 ~ 7 人です。色々なポジションや性格の人達と話ができたので、安心して入社することができました。 新卒研修の開発 OJT ではどんなことをやっていたか？ 新居 : 堀内さんは新卒研修の開発 OJT のタイミングでジョブメドレー開発チームに仮配属されたのですよね。当時はどういうことをやってたのですか？ 堀内 : まずはジョブメドレーのドメイン知識をしっかり吸収していこうということで、業界や業務自体の理解を進めました。 その後、求職者と事業者のサポート業務を行う社内オペレーターが利用する画面の拡張タスクに取り組みました。 技術スタックは Next.js / React / TypeScript / GraphQL といったシステムで、個人的にあまり触れてこなかった領域だったので、技術のキャッチアップもしつつ丁寧に対応していきました。 また、開発 OJT よりも前の研修で輪読会も経験したのですが、その時に学んだ Cookie や Session まわりの知識が役に立ったり、座学で学んだことがこうやって実践で活きてくるんだな、ということを実感 できてとても良い経験になりました。 今までとは比べ物にならないくらい大規模なシステムだったので、プレッシャーも大きかったのですが、チームの人達と相談したり、細かいレビュー・サポートがあったおかげで、しっかり成果を出すことができたと思います。 新居 : 良い OJT ですね！堀内さん自身の努力があったのは勿論ですが、チームに新しいメンバーを迎え入れて成長をサポートする環境が整っていたのも良かったんでしょうね。 ちなみに開発 OJT の中で大変だったこととかはありますか？ 堀内 : そうですね、やはり大規模な既存コードの把握・理解が大変でした。社内オペレーターが使う画面とジョブメドレー本体はそれぞれ別システムとして連携しているので、ジョブメドレー本体のコードや仕組みの理解も必要です。 大変だった分、 システムの全体像を理解するのに大いに役立った ので、今思い返すと良い経験だったなあと思います。 色々な経験を積めた求人カード改修プロジェクト 新居 : では、新卒研修を終えてから 1 年以上経っていて、入社 2 年目の終わりに差し掛かっている現在ですが、直近で堀内さんがリードを務めていた、ジョブメドレーの求人カード改修プロジェクトについて話を聞いていきたいと思います。まずは、このプロジェクトの概要について、教えてもらえますか？ 求人カード改修プロジェクトとは？ 堀内 : それでは､プロジェクト説明に先立ちまして､まず、ジョブメドレーの「求人カード」について簡単に説明します。 ジョブメドレーで求人を検索すると､検索結果が並ぶ画面が出てきます。我々が「求人カード」と呼んでいるのは、この検索結果画面上に表示される、求人情報のことになります。 検索結果画面の求人カードでは、給与や大まかな業務内容、応募要件、職場の住所などが分かる形になっていますが、求職者の方々がより便利に使っていただけるよう、情報の出し方を見直すことが今回のプロジェクト内容です。 もう少し詳しくお話すると､採用決定率の改善を目的に､どのような改善を実施すべきか検討しています｡ 求職者にとって欲しい情報が手に入りやすくなるということは、その分、応募に繋がりやすくなると言い換えることもできますので､改修による効果については、継続的に検証し､効果の有無を明らかにしたいと考えています｡ 新居 : なるほど。端的に言うと、ジョブメドレーにおける求人情報検索の体験を更に良くする為のプロジェクトということですね。 プロジェクトのはじまり 新居 : 今回のプロジェクトをどのようなメンバーと何をどのように行っていったのか、チーム構成から教えてください。 堀内 : チーム構成としては、自分を含めたエンジニアが 2 人いて、その他は、デザイナー、マーケター、プロダクトマネージャー（以下、PdM）がそれぞれ 1 人ずつプロジェクトにアサインされました。 プロジェクトのきっかけとしては、求職者体験を更に良くする為の企画の一つとしてマーケターと PdM が企画したところから始まり、その後、エンジニアとマーケター間で､細かい具体的な要件まで落とし込んで、プロジェクト化に至りました。 仕様についてメンバー間で徹底議論 堀内 : 要件まで落とし込んだ後は、具体的にそれらをどうやって実装するかを検討しました。特に UI の仕様については、デザイナーを中心にかなり長い時間をかけて詰めていきました 。 新居 : 確かに、情報の出し方によっては、かえって、求職者体験を悪化させてしまう可能性がありそうですね…。 堀内 : はい。使い勝手の良い UI にする為に、デザイナーがまず Figma でモックアップを作り、プロジェクトが始まった最初の週からデイリーの夕会などで、UI に関して徹底的にプロジェクトメンバー間で議論をしていました。 その時、特にメンバー全員が気を付けていたのは、実際に求職者が新しい一覧画面を使う時に、価値を感じてもらえるかどうかです。メドレーの Our Essentials の一つとして、 長期のカスタマー価値を追求 という項目があります｡「全ての利用者にとって価値のある施策であること」､「利用者の片方だけを見て、もう片方を無視することがあってはならない」ということで、事業者側の求人情報を多く載せるだけではなく、求職者にとっての使い勝手も向上しているか？などを徹底的にチェックしていました。 使い勝手をチェックするにあたって、ジョブメドレーのメインユーザーの年齢層などが予め分かっていたので、その方達にとって使いやすいかどうかを判断軸として、考えていました。 デザイナーが完成させた UI でも、でき上がったモックアップをメンバーそれぞれの視点で触ってみると､改善点が出る場面がありました。そういった場合には、こういう UI にしてみたらどうか？などとそれぞれが意見し、良さそうな案についてはデザイナーがそれらの提案を取り込んだり､改良したりして、UI の仕様を詰めていきました。 技術面について 新居 : UI を実装に落とし込む際、技術面で工夫した点や気を付けていたポイントなどはありますか？ 堀内 : 今回のプロジェクトでは、求人カードのデザインを大幅に変更する為､事前の影響範囲の洗い出しを徹底するよう注意していました｡例えば、一覧画面における求人情報の出力量がかなり増えることで、1 ページあたりの読み込み処理に時間がかかってしまうことが予想された為､コンテンツの遅延読み込みやキャッシュの利用によりチューニングを行っています｡また､デザイン変更が多くのページにわたって発生する為､リリース後の不具合を起こさないような対策を複数行っています｡ 担当したプロジェクトのリード 新居 : 今回のプロジェクトでは、エンジニアとして開発をしつつ、堀内さんがプロジェクトのリードを任されていたと聞いています。リードとしては、どんな動きをプロジェクトの中でされていたのでしょうか？ 堀内 : まずは、最初にプロジェクト全体の大まかなスケジュールを引き、PdM と確認しました。次に、タスク分解をしてメンバーへのアサインを行ったり、プロジェクトのタスクのなかで不確実性を極力少なくする為に、自分達だけではコントロールできなさそうな部分を洗い出したりしました。洗い出したアンコントローラブルな部分は企画者と共に関係各所へ連絡・調整をしてもらうようお願いしていました。 新居 : なるほど。開発スケジュールの出し方など、その辺りで工夫した点などはありますか？ 堀内 : スケジュールの共有方法については、視覚的に分かりやすいように、 FigJam を使って、ガントチャートのような形式で、ボードを作成しました。 メンバー毎にレーンを振り分けて、誰がいつまでに何をしなければいけないのかを夕会で確認していました。また、スケジュールのボードは常に、 第三者が見ても進捗状況が直ぐに分かるような状態にしておく よう努めました。 スケジュールボード スケジューリングで特に意識していたことは、不確実な部分を早めに洗い出すことでした。タスク分解をしていく中で、どこが自分達だけではコントロールできなさそうな部分なのかを把握することから始めていました。 現状の仕様や実装がどうなっているのかなどは直ぐに確認できるので、そういったところから、なるべく不確実な部分を減らしていき、最終的に各タスクの工数を算出するにあたって、不確実性の高さに応じて、バッファを設定しました。 新居 : 少し手を動かせば確認できるようなところは直ぐに確認して、なるべく解像度が高い状態にもっていく進め方は確かに良さそうですね！工数を見積もるにあたって、解像度が低い状態だと、見積もりの精度が低くなってしまいますからね。 堀内 : また、タスクは GitHub Issue を発行して管理していたのですが、切り出す粒度はなるべく細かくしていました。Issue の粒度が荒くなってしまうと、それに比例して手戻りリスクが高くなってしまうので、目安としては、長くても 2 日以内には完了できる粒度で切り出していました。 結果、今回のプロジェクトにおいては、ほとんど手戻りすることなく、ほぼ全ての期間において、オンスケジュールで進めることができました。 A/B テストの導入（効果検証の仕組み化） 新居 : オンスケで進められていたのは素晴らしいですね！開発者として実装することと、リードとしてプロジェクトを管理することの他、堀内さんが今回のプロジェクトで担当していた役割などはありますか？ 堀内 : 今回のプロジェクトでは、効果検証を行う為の仕組みとして、A/B テストを本格的に導入する目標がありました。なぜ A/B テストを導入するのか？ A/B テストで何をしたいのか？を明確にして、A/B テストの設計から導入､分析までを行いました。 統計的な分析手法の選択から実際のテスト環境の開発みたいなところまで一気通貫で、PdM、マーケター、エンジニアを巻き込んで行いました。 A/B テストで大事なのは、論理的な仮説を立ててそれを検証し、その結果からより効果があると判断できた施策を導入していく、というサイクルだと考えています｡とはいえ、有意差が出たからといって必ずしも導入したほうが良いというわけではありません｡その時の経営面のメリット・デメリットを考慮し､これまでの経験にもとづいた判断も加えて、より効果の高い施策を継続的に導入できるようにする、というのが今回の目標です｡ 今回のプロジェクトを皮切りに、他のプロジェクトでも同じように A/B テストの仕組みを使える状態にしたい。そういった横展開や汎用性みたいなところも、プロジェクト当初からセットで考えていました。 新居 : とても興味深い取り組みですね！実際、どのように仕組み化を進めていくのでしょうか？ 堀内 : A/B テストに必要な知見をドキュメント化して、それを見るだけで、エンジニアのサポートを受けつつ誰でも A/B テストが実施できるようにしていく取り組みや､スプレッドシートにデータを入力すれば、簡単に結果が判るような仕組み化を進行中です｡ 機能のリリース時は､その結果に応じて結局、どうすれば良いのか？といった指針も Issue やドキュメントに記載しております｡ 実装や設計面における悩み 新居 : 実装や設計面において、今回のプロジェクトで悩んだようなところはありましたか？ 堀内 : はい。自分自身の力量の問題で、ドメイン知識や技術力などが不足していたことから、ジョブメドレーのコードの中で今までの慣習を受け継ぎつつ、良い感じに使い回しができるコードをどう上手く書いていくか、という点について悩んでいました。 新居 : なるほど…。ジョブメドレー自体が 10 年以上の歴史があるサービスなので、そこに手を入れていくのは確かに難しい部分もありそうですね。その悩みに対しては、どう対策をされていたのでしょう？ 堀内 : そうですね。今の自分の知見だけで設計と実装を進めてしまうと手戻りが発生してしまう恐れがあったので、まずはドメイン知識が豊富な、同じチーム内のベテラン社員に設計レビューをお願いしました。そこで、ジョブメドレーのインフラ構成におけるキャッシュ戦略や､保守性を高める為の実装の切り出し方など、壁打ちで相談させてもらっていました。 その先輩社員との設計レビュー以外にも、普段から行ってもらっている 1on1 ミーティングを通じて、自分のメンターと相談させてもらい、どういう設計だったら使いやすいのか、などを様々な視点から検討しました｡ 新居 : なるべく手戻りが発生しないようにする為に、 設計段階で身近にいるエンジニアを巻き込んで進めていった のですね。直ぐに相談できる相手がいるのは心強いですね。 学びになった点 新居 : 今回のプロジェクトを通じて、特に学びになった点を教えていただけますか？ 堀内 : 技術的な面とプロジェクトの進め方の面でそれぞれ学びがありました。 技術的な面で言うと、 保守性が高く、今後、運用しやすいコードとはどういうものなのかというのを、今回の実装を通じて体得できた ところだと思っています。 プロジェクトの進め方の面では、過去のプロジェクトのドキュメントを参考に、そこに書かれていた知見を活かしながら、プロジェクトを進めていったので、ノウハウのようなところが学べたかと思っています。 新卒研修・開発実践のリードとの違い 新居 : 堀内さんは、新卒研修の一環で行われた開発実践の期間中、新卒同士のチーム開発でもリードを務めていたと思います。今回のプロジェクトを通じて経験されたリードとの違いについて教えてください。 堀内 : プロジェクトの規模や影響範囲の違いなどから、研修時よりも多くの関係者との調整が必要でした｡全員と情報を共有・連携しつつ､プロジェクトを進める必要があった点が一番大きな違いでした。 また、開発実践のプロジェクトはあくまで社内向けシステムを構築するものだったので、会社の売上について意識することはありませんでしたが、今回のプロジェクトでは、施策によって応募率が下がった場合に売上に悪影響を及ぼす可能性がありましたので、開発部署以外への影響を意識して管理する必要があったことも大きいポイントだったと思っています。 ジョブメドレーの開発におけるやりがい 新居 : ここまで直近で担当されていたプロジェクトについて聞いてきましたが、ジョブメドレーの開発をしていて、特にやりがいを感じる場面について、教えてもらえますか？ 堀内 : やはり､利用してくださっている求職者や事業者の方々に向けて､新規機能開発や機能改修を行う工程です｡目的と照らし合わせて仕様面から妥協せずに考え抜き、リリースするまでの過程にやりがいを感じています｡ユーザー数がとても多いだけに､良い機能をリリースできたときの反響も大きく､非常に楽しいです｡ 勿論、エンジニアとして技術力を上げていくことも貪欲に今後もやっていかなければならない部分だと思っていますが、企画として案件があがってきた段階で、それをなぜ作るのか？なぜそれで効果が出ると思っているのか？などと考えることが、企画職だけでなく､エンジニアにとっても大事だと考えています｡ リリースした後には、実際に効果が出たのか出なかったのか、なぜ効果が出たのか､出なかったのか？などの効果検証を行った上で、PdM を中心にエンジニア以外のメンバーも交えて振り返り、次の施策に活かしていくといった、 PDCA サイクルを回していっている開発スタイルに楽しさを感じています 。 これは、自分の入社時にやりたいこととしてあげていた、エンジニアリング面だけではなくビジネス面についても多くの経験を積みたい、というところにリンクしていて、今在籍しているジョブメドレーの開発チームでは、企画やマーケティングを行う人達とエンジニアがとても近い距離にいることで、様々な知見を得られつつアウトプットできる､とても学びになる環境だと感じています。 ジョブメドレー開発チームにおける 1 日の流れ 新居 : 現在のジョブメドレー開発チームは、Growth Unit（求職者の利便性を高める施策を行うチーム）と Customer Unit（求人を掲載する事業者が使う採用管理システムの改善施策を行うチーム）の 2 つに分かれているんですよね。堀内さんが所属しているのは、Growth Unit の方ですが、参加されているミーティングなど、1 日の流れについて教えてください。 堀内 : まず、勤務開始の 10:00 頃には Slack に投稿する形で、その日のタスクや参加予定のミーティングなどについて、開発用 channel で共有します。 現在の自分のスケジュールでは、午前中は特に定常的なミーティングはありません。但し、アサインされるプロジェクトによっては、午前中に「朝会」としてプロジェクトメンバー同士が集まって、進捗共有などを行っています。 お昼過ぎの 14:30 からは､ 30 分程度､Growth Unit のエンジニアだけで集まるミーティングがあります。この場では、各自の進捗状況や抱えている不安・不明点などを共有します｡今何に困っているのかを共有するだけでなく､ 困りごとに対し､各々が知恵を出し合って、問題解決までのリードタイムを短くする ことができる貴重な場となっています｡ 18:00 からは「夕会」として、PdM とデザイナーも含めた Growth Unit 全体のミーティングがあります。そこで各自、「今日やったこと」や担当 Issue のリリース目処などを共有しています。この場では、エンジニア以外のメンバーも参加しているので、そこまで技術的に突っ込んだ話まではしません。 さらに、終業前にはまたエンジニアだけで集まり、FigJam を使って付箋を貼っていく形で、 各自が技術的トピックや、特定のドメインについて聞きたいことなどを持ち寄り、ざっくばらんに雑談形式で話す 「技術共有会」を行っています。 技術共有会の雰囲気 ミーティングの場以外は黙々と開発を進めていきますが、聞きたいことや相談したいことが出てきたら都度、開発用のスレッドに投稿しています。 新居 : なるほど。質問や相談はしやすい感じですか？ 堀内 : はい。勿論、自分で調べられることはなるべく調べて、自己解決するのが基本ではありますが、あまり調査に時間をかけ過ぎて全然進まないような事態に陥っても良くないので、それらを皆、前提として意識した上で、聞くべき時は躊躇なく聞ける雰囲気があります。 新居 : ミーティングの種類としては、先ほどあげてもらったもの以外にありますか？ 堀内 : あとは、週一で行われている「プロダクト定例」と隔週で行ってもらっている「1on1 ミーティング」があります。 プロダクト定例は、比較的規模の大きいミーティングで、我々、プロダクト開発室以外のメンバーの他、マーケティング室や事業企画室のメンバーも含めて、大体いつも 40 名前後の人数で参加しています。 この場では、現在追っている KPI だったり、ジョブメドレーで動いている全てのプロジェクト状況が共有されます。そこで共有される KPI の数字によって、次に着手すべき Issue にも影響してくるので、この場で共有される情報をしっかりとインプットして、今後の心構えとすることにしています。 直近で担当したプロジェクトの話でもちらっと出てきましたが、1on1 ミーティングは担当メンターと行なっています。普段の仕事の相談から、自分のキャリアに関するような相談をしており、メンターさんの経験なども教えていただきながら、勉強させていただいています。 1on1 ミーティングの意義としては、そういった仕事の他、 プライベートのことも含めて、何でも相談ができる場 としてあるのですが、1on1 を通じて、メンターさんとの信頼関係も築けるので、チームビルディングの一つとしても機能しています。 ジョブメドレー開発チームで一緒に働きたいと思う人はどんな人？ 新居 : 堀内さんがジョブメドレー開発チームで一緒に働きたいと思う人はどんな人でしょうか？ 堀内 : 今の環境で働いてて良かったなあと思うことは、 人間関係が良好であること です｡もちろん馴れ合いの中での業務というわけではなく､各々が しっかりと仕事に対して責任を持ちつつ､チーム内で生じた違和感は遠慮なく指摘し合い受けとめる という､良い意味で心理的安全性のある環境でプロダクト開発に集中して取り組めることです。 このような環境で、課題に対して長期的な視点で本質を捉え、目的を設定し､ボトムアップで解決策の立案から改善までを主導すること、さらには仕組み化まで行うことが好きな方､またはそれらをやってみたい方が合っているのではないか､と思います。 自分もそのような人間になりたいと思いながら、日々仕事に取り組んでいます。 さいごに ジョブメドレー開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いてきましたが、いかがだったでしょうか？ こんなチームでプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は医療介護求人サイトの ジョブメドレー 開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いていこうと思います。 インタビュイー紹介 堀内さん 2021 年入社。人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 堀内さん メドレーに入社した理由 新居 : まずはじめに、堀内さんはどういう経緯でメドレーに入社したのでしたっけ？ 堀内 : 以前のインタビュー（ 21 年新卒入社エンジニアと座談会で振り返る新卒研修 ）の時にもお話したのですが、就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。特に､ ビジネス側と開発側の距離が近い 部分に惹かれ､総合的にメドレーが良さそうだと考えて入社しました。 新居 : 入社前の印象と実際働きだしてからで、ズレなどはありましたか？ 堀内 : そんなにギャップはなくて、社風とか人間関係みたいなところは入社前のイメージ通りでした。入社前に何回か会社見学をさせてもらったり、その時の社員と複数回面談をセッティングしてもらったりして、そこでイメージをすり合わせできたことが大きかったですね。 新居 : 何人くらいの社員と会ったのですか？ 堀内 : 6 ~ 7 人です。色々なポジションや性格の人達と話ができたので、安心して入社することができました。 新卒研修の開発 OJT ではどんなことをやっていたか？ 新居 : 堀内さんは新卒研修の開発 OJT のタイミングでジョブメドレー開発チームに仮配属されたのですよね。当時はどういうことをやってたのですか？ 堀内 : まずはジョブメドレーのドメイン知識をしっかり吸収していこうということで、業界や業務自体の理解を進めました。 その後、求職者と事業者のサポート業務を行う社内オペレーターが利用する画面の拡張タスクに取り組みました。 技術スタックは Next.js / React / TypeScript / GraphQL といったシステムで、個人的にあまり触れてこなかった領域だったので、技術のキャッチアップもしつつ丁寧に対応していきました。 また、開発 OJT よりも前の研修で輪読会も経験したのですが、その時に学んだ Cookie や Session まわりの知識が役に立ったり、座学で学んだことがこうやって実践で活きてくるんだな、ということを実感 できてとても良い経験になりました。 今までとは比べ物にならないくらい大規模なシステムだったので、プレッシャーも大きかったのですが、チームの人達と相談したり、細かいレビュー・サポートがあったおかげで、しっかり成果を出すことができたと思います。 新居 : 良い OJT ですね！堀内さん自身の努力があったのは勿論ですが、チームに新しいメンバーを迎え入れて成長をサポートする環境が整っていたのも良かったんでしょうね。 ちなみに開発 OJT の中で大変だったこととかはありますか？ 堀内 : そうですね、やはり大規模な既存コードの把握・理解が大変でした。社内オペレーターが使う画面とジョブメドレー本体はそれぞれ別システムとして連携しているので、ジョブメドレー本体のコードや仕組みの理解も必要です。 大変だった分、 システムの全体像を理解するのに大いに役立った ので、今思い返すと良い経験だったなあと思います。 色々な経験を積めた求人カード改修プロジェクト 新居 : では、新卒研修を終えてから 1 年以上経っていて、入社 2 年目の終わりに差し掛かっている現在ですが、直近で堀内さんがリードを務めていた、ジョブメドレーの求人カード改修プロジェクトについて話を聞いていきたいと思います。まずは、このプロジェクトの概要について、教えてもらえますか？ 求人カード改修プロジェクトとは？ 堀内 : それでは､プロジェクト説明に先立ちまして､まず、ジョブメドレーの「求人カード」について簡単に説明します。 ジョブメドレーで求人を検索すると､検索結果が並ぶ画面が出てきます。我々が「求人カード」と呼んでいるのは、この検索結果画面上に表示される、求人情報のことになります。 検索結果画面の求人カードでは、給与や大まかな業務内容、応募要件、職場の住所などが分かる形になっていますが、求職者の方々がより便利に使っていただけるよう、情報の出し方を見直すことが今回のプロジェクト内容です。 もう少し詳しくお話すると､採用決定率の改善を目的に､どのような改善を実施すべきか検討しています｡ 求職者にとって欲しい情報が手に入りやすくなるということは、その分、応募に繋がりやすくなると言い換えることもできますので､改修による効果については、継続的に検証し､効果の有無を明らかにしたいと考えています｡ 新居 : なるほど。端的に言うと、ジョブメドレーにおける求人情報検索の体験を更に良くする為のプロジェクトということですね。 プロジェクトのはじまり 新居 : 今回のプロジェクトをどのようなメンバーと何をどのように行っていったのか、チーム構成から教えてください。 堀内 : チーム構成としては、自分を含めたエンジニアが 2 人いて、その他は、デザイナー、マーケター、プロダクトマネージャー（以下、PdM）がそれぞれ 1 人ずつプロジェクトにアサインされました。 プロジェクトのきっかけとしては、求職者体験を更に良くする為の企画の一つとしてマーケターと PdM が企画したところから始まり、その後、エンジニアとマーケター間で､細かい具体的な要件まで落とし込んで、プロジェクト化に至りました。 仕様についてメンバー間で徹底議論 堀内 : 要件まで落とし込んだ後は、具体的にそれらをどうやって実装するかを検討しました。特に UI の仕様については、デザイナーを中心にかなり長い時間をかけて詰めていきました 。 新居 : 確かに、情報の出し方によっては、かえって、求職者体験を悪化させてしまう可能性がありそうですね…。 堀内 : はい。使い勝手の良い UI にする為に、デザイナーがまず Figma でモックアップを作り、プロジェクトが始まった最初の週からデイリーの夕会などで、UI に関して徹底的にプロジェクトメンバー間で議論をしていました。 その時、特にメンバー全員が気を付けていたのは、実際に求職者が新しい一覧画面を使う時に、価値を感じてもらえるかどうかです。メドレーの Our Essentials の一つとして、 長期のカスタマー価値を追求 という項目があります｡「全ての利用者にとって価値のある施策であること」､「利用者の片方だけを見て、もう片方を無視することがあってはならない」ということで、事業者側の求人情報を多く載せるだけではなく、求職者にとっての使い勝手も向上しているか？などを徹底的にチェックしていました。 使い勝手をチェックするにあたって、ジョブメドレーのメインユーザーの年齢層などが予め分かっていたので、その方達にとって使いやすいかどうかを判断軸として、考えていました。 デザイナーが完成させた UI でも、でき上がったモックアップをメンバーそれぞれの視点で触ってみると､改善点が出る場面がありました。そういった場合には、こういう UI にしてみたらどうか？などとそれぞれが意見し、良さそうな案についてはデザイナーがそれらの提案を取り込んだり､改良したりして、UI の仕様を詰めていきました。 技術面について 新居 : UI を実装に落とし込む際、技術面で工夫した点や気を付けていたポイントなどはありますか？ 堀内 : 今回のプロジェクトでは、求人カードのデザインを大幅に変更する為､事前の影響範囲の洗い出しを徹底するよう注意していました｡例えば、一覧画面における求人情報の出力量がかなり増えることで、1 ページあたりの読み込み処理に時間がかかってしまうことが予想された為､コンテンツの遅延読み込みやキャッシュの利用によりチューニングを行っています｡また､デザイン変更が多くのページにわたって発生する為､リリース後の不具合を起こさないような対策を複数行っています｡ 担当したプロジェクトのリード 新居 : 今回のプロジェクトでは、エンジニアとして開発をしつつ、堀内さんがプロジェクトのリードを任されていたと聞いています。リードとしては、どんな動きをプロジェクトの中でされていたのでしょうか？ 堀内 : まずは、最初にプロジェクト全体の大まかなスケジュールを引き、PdM と確認しました。次に、タスク分解をしてメンバーへのアサインを行ったり、プロジェクトのタスクのなかで不確実性を極力少なくする為に、自分達だけではコントロールできなさそうな部分を洗い出したりしました。洗い出したアンコントローラブルな部分は企画者と共に関係各所へ連絡・調整をしてもらうようお願いしていました。 新居 : なるほど。開発スケジュールの出し方など、その辺りで工夫した点などはありますか？ 堀内 : スケジュールの共有方法については、視覚的に分かりやすいように、 FigJam を使って、ガントチャートのような形式で、ボードを作成しました。 メンバー毎にレーンを振り分けて、誰がいつまでに何をしなければいけないのかを夕会で確認していました。また、スケジュールのボードは常に、 第三者が見ても進捗状況が直ぐに分かるような状態にしておく よう努めました。 スケジュールボード スケジューリングで特に意識していたことは、不確実な部分を早めに洗い出すことでした。タスク分解をしていく中で、どこが自分達だけではコントロールできなさそうな部分なのかを把握することから始めていました。 現状の仕様や実装がどうなっているのかなどは直ぐに確認できるので、そういったところから、なるべく不確実な部分を減らしていき、最終的に各タスクの工数を算出するにあたって、不確実性の高さに応じて、バッファを設定しました。 新居 : 少し手を動かせば確認できるようなところは直ぐに確認して、なるべく解像度が高い状態にもっていく進め方は確かに良さそうですね！工数を見積もるにあたって、解像度が低い状態だと、見積もりの精度が低くなってしまいますからね。 堀内 : また、タスクは GitHub Issue を発行して管理していたのですが、切り出す粒度はなるべく細かくしていました。Issue の粒度が荒くなってしまうと、それに比例して手戻りリスクが高くなってしまうので、目安としては、長くても 2 日以内には完了できる粒度で切り出していました。 結果、今回のプロジェクトにおいては、ほとんど手戻りすることなく、ほぼ全ての期間において、オンスケジュールで進めることができました。 A/B テストの導入（効果検証の仕組み化） 新居 : オンスケで進められていたのは素晴らしいですね！開発者として実装することと、リードとしてプロジェクトを管理することの他、堀内さんが今回のプロジェクトで担当していた役割などはありますか？ 堀内 : 今回のプロジェクトでは、効果検証を行う為の仕組みとして、A/B テストを本格的に導入する目標がありました。なぜ A/B テストを導入するのか？ A/B テストで何をしたいのか？を明確にして、A/B テストの設計から導入､分析までを行いました。 統計的な分析手法の選択から実際のテスト環境の開発みたいなところまで一気通貫で、PdM、マーケター、エンジニアを巻き込んで行いました。 A/B テストで大事なのは、論理的な仮説を立ててそれを検証し、その結果からより効果があると判断できた施策を導入していく、というサイクルだと考えています｡とはいえ、有意差が出たからといって必ずしも導入したほうが良いというわけではありません｡その時の経営面のメリット・デメリットを考慮し､これまでの経験にもとづいた判断も加えて、より効果の高い施策を継続的に導入できるようにする、というのが今回の目標です｡ 今回のプロジェクトを皮切りに、他のプロジェクトでも同じように A/B テストの仕組みを使える状態にしたい。そういった横展開や汎用性みたいなところも、プロジェクト当初からセットで考えていました。 新居 : とても興味深い取り組みですね！実際、どのように仕組み化を進めていくのでしょうか？ 堀内 : A/B テストに必要な知見をドキュメント化して、それを見るだけで、エンジニアのサポートを受けつつ誰でも A/B テストが実施できるようにしていく取り組みや､スプレッドシートにデータを入力すれば、簡単に結果が判るような仕組み化を進行中です｡ 機能のリリース時は､その結果に応じて結局、どうすれば良いのか？といった指針も Issue やドキュメントに記載しております｡ 実装や設計面における悩み 新居 : 実装や設計面において、今回のプロジェクトで悩んだようなところはありましたか？ 堀内 : はい。自分自身の力量の問題で、ドメイン知識や技術力などが不足していたことから、ジョブメドレーのコードの中で今までの慣習を受け継ぎつつ、良い感じに使い回しができるコードをどう上手く書いていくか、という点について悩んでいました。 新居 : なるほど…。ジョブメドレー自体が 10 年以上の歴史があるサービスなので、そこに手を入れていくのは確かに難しい部分もありそうですね。その悩みに対しては、どう対策をされていたのでしょう？ 堀内 : そうですね。今の自分の知見だけで設計と実装を進めてしまうと手戻りが発生してしまう恐れがあったので、まずはドメイン知識が豊富な、同じチーム内のベテラン社員に設計レビューをお願いしました。そこで、ジョブメドレーのインフラ構成におけるキャッシュ戦略や､保守性を高める為の実装の切り出し方など、壁打ちで相談させてもらっていました。 その先輩社員との設計レビュー以外にも、普段から行ってもらっている 1on1 ミーティングを通じて、自分のメンターと相談させてもらい、どういう設計だったら使いやすいのか、などを様々な視点から検討しました｡ 新居 : なるべく手戻りが発生しないようにする為に、 設計段階で身近にいるエンジニアを巻き込んで進めていった のですね。直ぐに相談できる相手がいるのは心強いですね。 学びになった点 新居 : 今回のプロジェクトを通じて、特に学びになった点を教えていただけますか？ 堀内 : 技術的な面とプロジェクトの進め方の面でそれぞれ学びがありました。 技術的な面で言うと、 保守性が高く、今後、運用しやすいコードとはどういうものなのかというのを、今回の実装を通じて体得できた ところだと思っています。 プロジェクトの進め方の面では、過去のプロジェクトのドキュメントを参考に、そこに書かれていた知見を活かしながら、プロジェクトを進めていったので、ノウハウのようなところが学べたかと思っています。 新卒研修・開発実践のリードとの違い 新居 : 堀内さんは、新卒研修の一環で行われた開発実践の期間中、新卒同士のチーム開発でもリードを務めていたと思います。今回のプロジェクトを通じて経験されたリードとの違いについて教えてください。 堀内 : プロジェクトの規模や影響範囲の違いなどから、研修時よりも多くの関係者との調整が必要でした｡全員と情報を共有・連携しつつ､プロジェクトを進める必要があった点が一番大きな違いでした。 また、開発実践のプロジェクトはあくまで社内向けシステムを構築するものだったので、会社の売上について意識することはありませんでしたが、今回のプロジェクトでは、施策によって応募率が下がった場合に売上に悪影響を及ぼす可能性がありましたので、開発部署以外への影響を意識して管理する必要があったことも大きいポイントだったと思っています。 ジョブメドレーの開発におけるやりがい 新居 : ここまで直近で担当されていたプロジェクトについて聞いてきましたが、ジョブメドレーの開発をしていて、特にやりがいを感じる場面について、教えてもらえますか？ 堀内 : やはり､利用してくださっている求職者や事業者の方々に向けて､新規機能開発や機能改修を行う工程です｡目的と照らし合わせて仕様面から妥協せずに考え抜き、リリースするまでの過程にやりがいを感じています｡ユーザー数がとても多いだけに､良い機能をリリースできたときの反響も大きく､非常に楽しいです｡ 勿論、エンジニアとして技術力を上げていくことも貪欲に今後もやっていかなければならない部分だと思っていますが、企画として案件があがってきた段階で、それをなぜ作るのか？なぜそれで効果が出ると思っているのか？などと考えることが、企画職だけでなく､エンジニアにとっても大事だと考えています｡ リリースした後には、実際に効果が出たのか出なかったのか、なぜ効果が出たのか､出なかったのか？などの効果検証を行った上で、PdM を中心にエンジニア以外のメンバーも交えて振り返り、次の施策に活かしていくといった、 PDCA サイクルを回していっている開発スタイルに楽しさを感じています 。 これは、自分の入社時にやりたいこととしてあげていた、エンジニアリング面だけではなくビジネス面についても多くの経験を積みたい、というところにリンクしていて、今在籍しているジョブメドレーの開発チームでは、企画やマーケティングを行う人達とエンジニアがとても近い距離にいることで、様々な知見を得られつつアウトプットできる､とても学びになる環境だと感じています。 ジョブメドレー開発チームにおける 1 日の流れ 新居 : 現在のジョブメドレー開発チームは、Growth Unit（求職者の利便性を高める施策を行うチーム）と Customer Unit（求人を掲載する事業者が使う採用管理システムの改善施策を行うチーム）の 2 つに分かれているんですよね。堀内さんが所属しているのは、Growth Unit の方ですが、参加されているミーティングなど、1 日の流れについて教えてください。 堀内 : まず、勤務開始の 10:00 頃には Slack に投稿する形で、その日のタスクや参加予定のミーティングなどについて、開発用 channel で共有します。 現在の自分のスケジュールでは、午前中は特に定常的なミーティングはありません。但し、アサインされるプロジェクトによっては、午前中に「朝会」としてプロジェクトメンバー同士が集まって、進捗共有などを行っています。 お昼過ぎの 14:30 からは､ 30 分程度､Growth Unit のエンジニアだけで集まるミーティングがあります。この場では、各自の進捗状況や抱えている不安・不明点などを共有します｡今何に困っているのかを共有するだけでなく､ 困りごとに対し､各々が知恵を出し合って、問題解決までのリードタイムを短くする ことができる貴重な場となっています｡ 18:00 からは「夕会」として、PdM とデザイナーも含めた Growth Unit 全体のミーティングがあります。そこで各自、「今日やったこと」や担当 Issue のリリース目処などを共有しています。この場では、エンジニア以外のメンバーも参加しているので、そこまで技術的に突っ込んだ話まではしません。 さらに、終業前にはまたエンジニアだけで集まり、FigJam を使って付箋を貼っていく形で、 各自が技術的トピックや、特定のドメインについて聞きたいことなどを持ち寄り、ざっくばらんに雑談形式で話す 「技術共有会」を行っています。 技術共有会の雰囲気 ミーティングの場以外は黙々と開発を進めていきますが、聞きたいことや相談したいことが出てきたら都度、開発用のスレッドに投稿しています。 新居 : なるほど。質問や相談はしやすい感じですか？ 堀内 : はい。勿論、自分で調べられることはなるべく調べて、自己解決するのが基本ではありますが、あまり調査に時間をかけ過ぎて全然進まないような事態に陥っても良くないので、それらを皆、前提として意識した上で、聞くべき時は躊躇なく聞ける雰囲気があります。 新居 : ミーティングの種類としては、先ほどあげてもらったもの以外にありますか？ 堀内 : あとは、週一で行われている「プロダクト定例」と隔週で行ってもらっている「1on1 ミーティング」があります。 プロダクト定例は、比較的規模の大きいミーティングで、我々、プロダクト開発室以外のメンバーの他、マーケティング室や事業企画室のメンバーも含めて、大体いつも 40 名前後の人数で参加しています。 この場では、現在追っている KPI だったり、ジョブメドレーで動いている全てのプロジェクト状況が共有されます。そこで共有される KPI の数字によって、次に着手すべき Issue にも影響してくるので、この場で共有される情報をしっかりとインプットして、今後の心構えとすることにしています。 直近で担当したプロジェクトの話でもちらっと出てきましたが、1on1 ミーティングは担当メンターと行なっています。普段の仕事の相談から、自分のキャリアに関するような相談をしており、メンターさんの経験なども教えていただきながら、勉強させていただいています。 1on1 ミーティングの意義としては、そういった仕事の他、 プライベートのことも含めて、何でも相談ができる場 としてあるのですが、1on1 を通じて、メンターさんとの信頼関係も築けるので、チームビルディングの一つとしても機能しています。 ジョブメドレー開発チームで一緒に働きたいと思う人はどんな人？ 新居 : 堀内さんがジョブメドレー開発チームで一緒に働きたいと思う人はどんな人でしょうか？ 堀内 : 今の環境で働いてて良かったなあと思うことは、 人間関係が良好であること です｡もちろん馴れ合いの中での業務というわけではなく､各々が しっかりと仕事に対して責任を持ちつつ､チーム内で生じた違和感は遠慮なく指摘し合い受けとめる という､良い意味で心理的安全性のある環境でプロダクト開発に集中して取り組めることです。 このような環境で、課題に対して長期的な視点で本質を捉え、目的を設定し､ボトムアップで解決策の立案から改善までを主導すること、さらには仕組み化まで行うことが好きな方､またはそれらをやってみたい方が合っているのではないか､と思います。 自分もそのような人間になりたいと思いながら、日々仕事に取り組んでいます。 さいごに ジョブメドレー開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いてきましたが、いかがだったでしょうか？ こんなチームでプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は医療介護求人サイトの ジョブメドレー 開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いていこうと思います。 インタビュイー紹介 堀内さん 2021 年入社。人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 堀内さん メドレーに入社した理由 新居 : まずはじめに、堀内さんはどういう経緯でメドレーに入社したのでしたっけ？ 堀内 : 以前のインタビュー（ 21 年新卒入社エンジニアと座談会で振り返る新卒研修 ）の時にもお話したのですが、就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。特に､ ビジネス側と開発側の距離が近い 部分に惹かれ､総合的にメドレーが良さそうだと考えて入社しました。 新居 : 入社前の印象と実際働きだしてからで、ズレなどはありましたか？ 堀内 : そんなにギャップはなくて、社風とか人間関係みたいなところは入社前のイメージ通りでした。入社前に何回か会社見学をさせてもらったり、その時の社員と複数回面談をセッティングしてもらったりして、そこでイメージをすり合わせできたことが大きかったですね。 新居 : 何人くらいの社員と会ったのですか？ 堀内 : 6 ~ 7 人です。色々なポジションや性格の人達と話ができたので、安心して入社することができました。 新卒研修の開発 OJT ではどんなことをやっていたか？ 新居 : 堀内さんは新卒研修の開発 OJT のタイミングでジョブメドレー開発チームに仮配属されたのですよね。当時はどういうことをやってたのですか？ 堀内 : まずはジョブメドレーのドメイン知識をしっかり吸収していこうということで、業界や業務自体の理解を進めました。 その後、求職者と事業者のサポート業務を行う社内オペレーターが利用する画面の拡張タスクに取り組みました。 技術スタックは Next.js / React / TypeScript / GraphQL といったシステムで、個人的にあまり触れてこなかった領域だったので、技術のキャッチアップもしつつ丁寧に対応していきました。 また、開発 OJT よりも前の研修で輪読会も経験したのですが、その時に学んだ Cookie や Session まわりの知識が役に立ったり、座学で学んだことがこうやって実践で活きてくるんだな、ということを実感 できてとても良い経験になりました。 今までとは比べ物にならないくらい大規模なシステムだったので、プレッシャーも大きかったのですが、チームの人達と相談したり、細かいレビュー・サポートがあったおかげで、しっかり成果を出すことができたと思います。 新居 : 良い OJT ですね！堀内さん自身の努力があったのは勿論ですが、チームに新しいメンバーを迎え入れて成長をサポートする環境が整っていたのも良かったんでしょうね。 ちなみに開発 OJT の中で大変だったこととかはありますか？ 堀内 : そうですね、やはり大規模な既存コードの把握・理解が大変でした。社内オペレーターが使う画面とジョブメドレー本体はそれぞれ別システムとして連携しているので、ジョブメドレー本体のコードや仕組みの理解も必要です。 大変だった分、 システムの全体像を理解するのに大いに役立った ので、今思い返すと良い経験だったなあと思います。 色々な経験を積めた求人カード改修プロジェクト 新居 : では、新卒研修を終えてから 1 年以上経っていて、入社 2 年目の終わりに差し掛かっている現在ですが、直近で堀内さんがリードを務めていた、ジョブメドレーの求人カード改修プロジェクトについて話を聞いていきたいと思います。まずは、このプロジェクトの概要について、教えてもらえますか？ 求人カード改修プロジェクトとは？ 堀内 : それでは､プロジェクト説明に先立ちまして､まず、ジョブメドレーの「求人カード」について簡単に説明します。 ジョブメドレーで求人を検索すると､検索結果が並ぶ画面が出てきます。我々が「求人カード」と呼んでいるのは、この検索結果画面上に表示される、求人情報のことになります。 検索結果画面の求人カードでは、給与や大まかな業務内容、応募要件、職場の住所などが分かる形になっていますが、求職者の方々がより便利に使っていただけるよう、情報の出し方を見直すことが今回のプロジェクト内容です。 もう少し詳しくお話すると､採用決定率の改善を目的に､どのような改善を実施すべきか検討しています｡ 求職者にとって欲しい情報が手に入りやすくなるということは、その分、応募に繋がりやすくなると言い換えることもできますので､改修による効果については、継続的に検証し､効果の有無を明らかにしたいと考えています｡ 新居 : なるほど。端的に言うと、ジョブメドレーにおける求人情報検索の体験を更に良くする為のプロジェクトということですね。 プロジェクトのはじまり 新居 : 今回のプロジェクトをどのようなメンバーと何をどのように行っていったのか、チーム構成から教えてください。 堀内 : チーム構成としては、自分を含めたエンジニアが 2 人いて、その他は、デザイナー、マーケター、プロダクトマネージャー（以下、PdM）がそれぞれ 1 人ずつプロジェクトにアサインされました。 プロジェクトのきっかけとしては、求職者体験を更に良くする為の企画の一つとしてマーケターと PdM が企画したところから始まり、その後、エンジニアとマーケター間で､細かい具体的な要件まで落とし込んで、プロジェクト化に至りました。 仕様についてメンバー間で徹底議論 堀内 : 要件まで落とし込んだ後は、具体的にそれらをどうやって実装するかを検討しました。特に UI の仕様については、デザイナーを中心にかなり長い時間をかけて詰めていきました 。 新居 : 確かに、情報の出し方によっては、かえって、求職者体験を悪化させてしまう可能性がありそうですね…。 堀内 : はい。使い勝手の良い UI にする為に、デザイナーがまず Figma でモックアップを作り、プロジェクトが始まった最初の週からデイリーの夕会などで、UI に関して徹底的にプロジェクトメンバー間で議論をしていました。 その時、特にメンバー全員が気を付けていたのは、実際に求職者が新しい一覧画面を使う時に、価値を感じてもらえるかどうかです。メドレーの Our Essentials の一つとして、 長期のカスタマー価値を追求 という項目があります｡「全ての利用者にとって価値のある施策であること」､「利用者の片方だけを見て、もう片方を無視することがあってはならない」ということで、事業者側の求人情報を多く載せるだけではなく、求職者にとっての使い勝手も向上しているか？などを徹底的にチェックしていました。 使い勝手をチェックするにあたって、ジョブメドレーのメインユーザーの年齢層などが予め分かっていたので、その方達にとって使いやすいかどうかを判断軸として、考えていました。 デザイナーが完成させた UI でも、でき上がったモックアップをメンバーそれぞれの視点で触ってみると､改善点が出る場面がありました。そういった場合には、こういう UI にしてみたらどうか？などとそれぞれが意見し、良さそうな案についてはデザイナーがそれらの提案を取り込んだり､改良したりして、UI の仕様を詰めていきました。 技術面について 新居 : UI を実装に落とし込む際、技術面で工夫した点や気を付けていたポイントなどはありますか？ 堀内 : 今回のプロジェクトでは、求人カードのデザインを大幅に変更する為､事前の影響範囲の洗い出しを徹底するよう注意していました｡例えば、一覧画面における求人情報の出力量がかなり増えることで、1 ページあたりの読み込み処理に時間がかかってしまうことが予想された為､コンテンツの遅延読み込みやキャッシュの利用によりチューニングを行っています｡また､デザイン変更が多くのページにわたって発生する為､リリース後の不具合を起こさないような対策を複数行っています｡ 担当したプロジェクトのリード 新居 : 今回のプロジェクトでは、エンジニアとして開発をしつつ、堀内さんがプロジェクトのリードを任されていたと聞いています。リードとしては、どんな動きをプロジェクトの中でされていたのでしょうか？ 堀内 : まずは、最初にプロジェクト全体の大まかなスケジュールを引き、PdM と確認しました。次に、タスク分解をしてメンバーへのアサインを行ったり、プロジェクトのタスクのなかで不確実性を極力少なくする為に、自分達だけではコントロールできなさそうな部分を洗い出したりしました。洗い出したアンコントローラブルな部分は企画者と共に関係各所へ連絡・調整をしてもらうようお願いしていました。 新居 : なるほど。開発スケジュールの出し方など、その辺りで工夫した点などはありますか？ 堀内 : スケジュールの共有方法については、視覚的に分かりやすいように、 FigJam を使って、ガントチャートのような形式で、ボードを作成しました。 メンバー毎にレーンを振り分けて、誰がいつまでに何をしなければいけないのかを夕会で確認していました。また、スケジュールのボードは常に、 第三者が見ても進捗状況が直ぐに分かるような状態にしておく よう努めました。 スケジュールボード スケジューリングで特に意識していたことは、不確実な部分を早めに洗い出すことでした。タスク分解をしていく中で、どこが自分達だけではコントロールできなさそうな部分なのかを把握することから始めていました。 現状の仕様や実装がどうなっているのかなどは直ぐに確認できるので、そういったところから、なるべく不確実な部分を減らしていき、最終的に各タスクの工数を算出するにあたって、不確実性の高さに応じて、バッファを設定しました。 新居 : 少し手を動かせば確認できるようなところは直ぐに確認して、なるべく解像度が高い状態にもっていく進め方は確かに良さそうですね！工数を見積もるにあたって、解像度が低い状態だと、見積もりの精度が低くなってしまいますからね。 堀内 : また、タスクは GitHub Issue を発行して管理していたのですが、切り出す粒度はなるべく細かくしていました。Issue の粒度が荒くなってしまうと、それに比例して手戻りリスクが高くなってしまうので、目安としては、長くても 2 日以内には完了できる粒度で切り出していました。 結果、今回のプロジェクトにおいては、ほとんど手戻りすることなく、ほぼ全ての期間において、オンスケジュールで進めることができました。 A/B テストの導入（効果検証の仕組み化） 新居 : オンスケで進められていたのは素晴らしいですね！開発者として実装することと、リードとしてプロジェクトを管理することの他、堀内さんが今回のプロジェクトで担当していた役割などはありますか？ 堀内 : 今回のプロジェクトでは、効果検証を行う為の仕組みとして、A/B テストを本格的に導入する目標がありました。なぜ A/B テストを導入するのか？ A/B テストで何をしたいのか？を明確にして、A/B テストの設計から導入､分析までを行いました。 統計的な分析手法の選択から実際のテスト環境の開発みたいなところまで一気通貫で、PdM、マーケター、エンジニアを巻き込んで行いました。 A/B テストで大事なのは、論理的な仮説を立ててそれを検証し、その結果からより効果があると判断できた施策を導入していく、というサイクルだと考えています｡とはいえ、有意差が出たからといって必ずしも導入したほうが良いというわけではありません｡その時の経営面のメリット・デメリットを考慮し､これまでの経験にもとづいた判断も加えて、より効果の高い施策を継続的に導入できるようにする、というのが今回の目標です｡ 今回のプロジェクトを皮切りに、他のプロジェクトでも同じように A/B テストの仕組みを使える状態にしたい。そういった横展開や汎用性みたいなところも、プロジェクト当初からセットで考えていました。 新居 : とても興味深い取り組みですね！実際、どのように仕組み化を進めていくのでしょうか？ 堀内 : A/B テストに必要な知見をドキュメント化して、それを見るだけで、エンジニアのサポートを受けつつ誰でも A/B テストが実施できるようにしていく取り組みや､スプレッドシートにデータを入力すれば、簡単に結果が判るような仕組み化を進行中です｡ 機能のリリース時は､その結果に応じて結局、どうすれば良いのか？といった指針も Issue やドキュメントに記載しております｡ 実装や設計面における悩み 新居 : 実装や設計面において、今回のプロジェクトで悩んだようなところはありましたか？ 堀内 : はい。自分自身の力量の問題で、ドメイン知識や技術力などが不足していたことから、ジョブメドレーのコードの中で今までの慣習を受け継ぎつつ、良い感じに使い回しができるコードをどう上手く書いていくか、という点について悩んでいました。 新居 : なるほど…。ジョブメドレー自体が 10 年以上の歴史があるサービスなので、そこに手を入れていくのは確かに難しい部分もありそうですね。その悩みに対しては、どう対策をされていたのでしょう？ 堀内 : そうですね。今の自分の知見だけで設計と実装を進めてしまうと手戻りが発生してしまう恐れがあったので、まずはドメイン知識が豊富な、同じチーム内のベテラン社員に設計レビューをお願いしました。そこで、ジョブメドレーのインフラ構成におけるキャッシュ戦略や､保守性を高める為の実装の切り出し方など、壁打ちで相談させてもらっていました。 その先輩社員との設計レビュー以外にも、普段から行ってもらっている 1on1 ミーティングを通じて、自分のメンターと相談させてもらい、どういう設計だったら使いやすいのか、などを様々な視点から検討しました｡ 新居 : なるべく手戻りが発生しないようにする為に、 設計段階で身近にいるエンジニアを巻き込んで進めていった のですね。直ぐに相談できる相手がいるのは心強いですね。 学びになった点 新居 : 今回のプロジェクトを通じて、特に学びになった点を教えていただけますか？ 堀内 : 技術的な面とプロジェクトの進め方の面でそれぞれ学びがありました。 技術的な面で言うと、 保守性が高く、今後、運用しやすいコードとはどういうものなのかというのを、今回の実装を通じて体得できた ところだと思っています。 プロジェクトの進め方の面では、過去のプロジェクトのドキュメントを参考に、そこに書かれていた知見を活かしながら、プロジェクトを進めていったので、ノウハウのようなところが学べたかと思っています。 新卒研修・開発実践のリードとの違い 新居 : 堀内さんは、新卒研修の一環で行われた開発実践の期間中、新卒同士のチーム開発でもリードを務めていたと思います。今回のプロジェクトを通じて経験されたリードとの違いについて教えてください。 堀内 : プロジェクトの規模や影響範囲の違いなどから、研修時よりも多くの関係者との調整が必要でした｡全員と情報を共有・連携しつつ､プロジェクトを進める必要があった点が一番大きな違いでした。 また、開発実践のプロジェクトはあくまで社内向けシステムを構築するものだったので、会社の売上について意識することはありませんでしたが、今回のプロジェクトでは、施策によって応募率が下がった場合に売上に悪影響を及ぼす可能性がありましたので、開発部署以外への影響を意識して管理する必要があったことも大きいポイントだったと思っています。 ジョブメドレーの開発におけるやりがい 新居 : ここまで直近で担当されていたプロジェクトについて聞いてきましたが、ジョブメドレーの開発をしていて、特にやりがいを感じる場面について、教えてもらえますか？ 堀内 : やはり､利用してくださっている求職者や事業者の方々に向けて､新規機能開発や機能改修を行う工程です｡目的と照らし合わせて仕様面から妥協せずに考え抜き、リリースするまでの過程にやりがいを感じています｡ユーザー数がとても多いだけに､良い機能をリリースできたときの反響も大きく､非常に楽しいです｡ 勿論、エンジニアとして技術力を上げていくことも貪欲に今後もやっていかなければならない部分だと思っていますが、企画として案件があがってきた段階で、それをなぜ作るのか？なぜそれで効果が出ると思っているのか？などと考えることが、企画職だけでなく､エンジニアにとっても大事だと考えています｡ リリースした後には、実際に効果が出たのか出なかったのか、なぜ効果が出たのか､出なかったのか？などの効果検証を行った上で、PdM を中心にエンジニア以外のメンバーも交えて振り返り、次の施策に活かしていくといった、 PDCA サイクルを回していっている開発スタイルに楽しさを感じています 。 これは、自分の入社時にやりたいこととしてあげていた、エンジニアリング面だけではなくビジネス面についても多くの経験を積みたい、というところにリンクしていて、今在籍しているジョブメドレーの開発チームでは、企画やマーケティングを行う人達とエンジニアがとても近い距離にいることで、様々な知見を得られつつアウトプットできる､とても学びになる環境だと感じています。 ジョブメドレー開発チームにおける 1 日の流れ 新居 : 現在のジョブメドレー開発チームは、Growth Unit（求職者の利便性を高める施策を行うチーム）と Customer Unit（求人を掲載する事業者が使う採用管理システムの改善施策を行うチーム）の 2 つに分かれているんですよね。堀内さんが所属しているのは、Growth Unit の方ですが、参加されているミーティングなど、1 日の流れについて教えてください。 堀内 : まず、勤務開始の 10:00 頃には Slack に投稿する形で、その日のタスクや参加予定のミーティングなどについて、開発用 channel で共有します。 現在の自分のスケジュールでは、午前中は特に定常的なミーティングはありません。但し、アサインされるプロジェクトによっては、午前中に「朝会」としてプロジェクトメンバー同士が集まって、進捗共有などを行っています。 お昼過ぎの 14:30 からは､ 30 分程度､Growth Unit のエンジニアだけで集まるミーティングがあります。この場では、各自の進捗状況や抱えている不安・不明点などを共有します｡今何に困っているのかを共有するだけでなく､ 困りごとに対し､各々が知恵を出し合って、問題解決までのリードタイムを短くする ことができる貴重な場となっています｡ 18:00 からは「夕会」として、PdM とデザイナーも含めた Growth Unit 全体のミーティングがあります。そこで各自、「今日やったこと」や担当 Issue のリリース目処などを共有しています。この場では、エンジニア以外のメンバーも参加しているので、そこまで技術的に突っ込んだ話まではしません。 さらに、終業前にはまたエンジニアだけで集まり、FigJam を使って付箋を貼っていく形で、 各自が技術的トピックや、特定のドメインについて聞きたいことなどを持ち寄り、ざっくばらんに雑談形式で話す 「技術共有会」を行っています。 技術共有会の雰囲気 ミーティングの場以外は黙々と開発を進めていきますが、聞きたいことや相談したいことが出てきたら都度、開発用のスレッドに投稿しています。 新居 : なるほど。質問や相談はしやすい感じですか？ 堀内 : はい。勿論、自分で調べられることはなるべく調べて、自己解決するのが基本ではありますが、あまり調査に時間をかけ過ぎて全然進まないような事態に陥っても良くないので、それらを皆、前提として意識した上で、聞くべき時は躊躇なく聞ける雰囲気があります。 新居 : ミーティングの種類としては、先ほどあげてもらったもの以外にありますか？ 堀内 : あとは、週一で行われている「プロダクト定例」と隔週で行ってもらっている「1on1 ミーティング」があります。 プロダクト定例は、比較的規模の大きいミーティングで、我々、プロダクト開発室以外のメンバーの他、マーケティング室や事業企画室のメンバーも含めて、大体いつも 40 名前後の人数で参加しています。 この場では、現在追っている KPI だったり、ジョブメドレーで動いている全てのプロジェクト状況が共有されます。そこで共有される KPI の数字によって、次に着手すべき Issue にも影響してくるので、この場で共有される情報をしっかりとインプットして、今後の心構えとすることにしています。 直近で担当したプロジェクトの話でもちらっと出てきましたが、1on1 ミーティングは担当メンターと行なっています。普段の仕事の相談から、自分のキャリアに関するような相談をしており、メンターさんの経験なども教えていただきながら、勉強させていただいています。 1on1 ミーティングの意義としては、そういった仕事の他、 プライベートのことも含めて、何でも相談ができる場 としてあるのですが、1on1 を通じて、メンターさんとの信頼関係も築けるので、チームビルディングの一つとしても機能しています。 ジョブメドレー開発チームで一緒に働きたいと思う人はどんな人？ 新居 : 堀内さんがジョブメドレー開発チームで一緒に働きたいと思う人はどんな人でしょうか？ 堀内 : 今の環境で働いてて良かったなあと思うことは、 人間関係が良好であること です｡もちろん馴れ合いの中での業務というわけではなく､各々が しっかりと仕事に対して責任を持ちつつ､チーム内で生じた違和感は遠慮なく指摘し合い受けとめる という､良い意味で心理的安全性のある環境でプロダクト開発に集中して取り組めることです。 このような環境で、課題に対して長期的な視点で本質を捉え、目的を設定し､ボトムアップで解決策の立案から改善までを主導すること、さらには仕組み化まで行うことが好きな方､またはそれらをやってみたい方が合っているのではないか､と思います。 自分もそのような人間になりたいと思いながら、日々仕事に取り組んでいます。 さいごに ジョブメドレー開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いてきましたが、いかがだったでしょうか？ こんなチームでプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は医療介護求人サイトの ジョブメドレー 開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いていこうと思います。 インタビュイー紹介 堀内さん 2021 年入社。人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 堀内さん メドレーに入社した理由 新居 : まずはじめに、堀内さんはどういう経緯でメドレーに入社したのでしたっけ？ 堀内 : 以前のインタビュー（ 21 年新卒入社エンジニアと座談会で振り返る新卒研修 ）の時にもお話したのですが、就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。特に､ ビジネス側と開発側の距離が近い 部分に惹かれ､総合的にメドレーが良さそうだと考えて入社しました。 新居 : 入社前の印象と実際働きだしてからで、ズレなどはありましたか？ 堀内 : そんなにギャップはなくて、社風とか人間関係みたいなところは入社前のイメージ通りでした。入社前に何回か会社見学をさせてもらったり、その時の社員と複数回面談をセッティングしてもらったりして、そこでイメージをすり合わせできたことが大きかったですね。 新居 : 何人くらいの社員と会ったのですか？ 堀内 : 6 ~ 7 人です。色々なポジションや性格の人達と話ができたので、安心して入社することができました。 新卒研修の開発 OJT ではどんなことをやっていたか？ 新居 : 堀内さんは新卒研修の開発 OJT のタイミングでジョブメドレー開発チームに仮配属されたのですよね。当時はどういうことをやってたのですか？ 堀内 : まずはジョブメドレーのドメイン知識をしっかり吸収していこうということで、業界や業務自体の理解を進めました。 その後、求職者と事業者のサポート業務を行う社内オペレーターが利用する画面の拡張タスクに取り組みました。 技術スタックは Next.js / React / TypeScript / GraphQL といったシステムで、個人的にあまり触れてこなかった領域だったので、技術のキャッチアップもしつつ丁寧に対応していきました。 また、開発 OJT よりも前の研修で輪読会も経験したのですが、その時に学んだ Cookie や Session まわりの知識が役に立ったり、座学で学んだことがこうやって実践で活きてくるんだな、ということを実感 できてとても良い経験になりました。 今までとは比べ物にならないくらい大規模なシステムだったので、プレッシャーも大きかったのですが、チームの人達と相談したり、細かいレビュー・サポートがあったおかげで、しっかり成果を出すことができたと思います。 新居 : 良い OJT ですね！堀内さん自身の努力があったのは勿論ですが、チームに新しいメンバーを迎え入れて成長をサポートする環境が整っていたのも良かったんでしょうね。 ちなみに開発 OJT の中で大変だったこととかはありますか？ 堀内 : そうですね、やはり大規模な既存コードの把握・理解が大変でした。社内オペレーターが使う画面とジョブメドレー本体はそれぞれ別システムとして連携しているので、ジョブメドレー本体のコードや仕組みの理解も必要です。 大変だった分、 システムの全体像を理解するのに大いに役立った ので、今思い返すと良い経験だったなあと思います。 色々な経験を積めた求人カード改修プロジェクト 新居 : では、新卒研修を終えてから 1 年以上経っていて、入社 2 年目の終わりに差し掛かっている現在ですが、直近で堀内さんがリードを務めていた、ジョブメドレーの求人カード改修プロジェクトについて話を聞いていきたいと思います。まずは、このプロジェクトの概要について、教えてもらえますか？ 求人カード改修プロジェクトとは？ 堀内 : それでは､プロジェクト説明に先立ちまして､まず、ジョブメドレーの「求人カード」について簡単に説明します。 ジョブメドレーで求人を検索すると､検索結果が並ぶ画面が出てきます。我々が「求人カード」と呼んでいるのは、この検索結果画面上に表示される、求人情報のことになります。 検索結果画面の求人カードでは、給与や大まかな業務内容、応募要件、職場の住所などが分かる形になっていますが、求職者の方々がより便利に使っていただけるよう、情報の出し方を見直すことが今回のプロジェクト内容です。 もう少し詳しくお話すると､採用決定率の改善を目的に､どのような改善を実施すべきか検討しています｡ 求職者にとって欲しい情報が手に入りやすくなるということは、その分、応募に繋がりやすくなると言い換えることもできますので､改修による効果については、継続的に検証し､効果の有無を明らかにしたいと考えています｡ 新居 : なるほど。端的に言うと、ジョブメドレーにおける求人情報検索の体験を更に良くする為のプロジェクトということですね。 プロジェクトのはじまり 新居 : 今回のプロジェクトをどのようなメンバーと何をどのように行っていったのか、チーム構成から教えてください。 堀内 : チーム構成としては、自分を含めたエンジニアが 2 人いて、その他は、デザイナー、マーケター、プロダクトマネージャー（以下、PdM）がそれぞれ 1 人ずつプロジェクトにアサインされました。 プロジェクトのきっかけとしては、求職者体験を更に良くする為の企画の一つとしてマーケターと PdM が企画したところから始まり、その後、エンジニアとマーケター間で､細かい具体的な要件まで落とし込んで、プロジェクト化に至りました。 仕様についてメンバー間で徹底議論 堀内 : 要件まで落とし込んだ後は、具体的にそれらをどうやって実装するかを検討しました。特に UI の仕様については、デザイナーを中心にかなり長い時間をかけて詰めていきました 。 新居 : 確かに、情報の出し方によっては、かえって、求職者体験を悪化させてしまう可能性がありそうですね…。 堀内 : はい。使い勝手の良い UI にする為に、デザイナーがまず Figma でモックアップを作り、プロジェクトが始まった最初の週からデイリーの夕会などで、UI に関して徹底的にプロジェクトメンバー間で議論をしていました。 その時、特にメンバー全員が気を付けていたのは、実際に求職者が新しい一覧画面を使う時に、価値を感じてもらえるかどうかです。メドレーの Our Essentials の一つとして、 長期のカスタマー価値を追求 という項目があります｡「全ての利用者にとって価値のある施策であること」､「利用者の片方だけを見て、もう片方を無視することがあってはならない」ということで、事業者側の求人情報を多く載せるだけではなく、求職者にとっての使い勝手も向上しているか？などを徹底的にチェックしていました。 使い勝手をチェックするにあたって、ジョブメドレーのメインユーザーの年齢層などが予め分かっていたので、その方達にとって使いやすいかどうかを判断軸として、考えていました。 デザイナーが完成させた UI でも、でき上がったモックアップをメンバーそれぞれの視点で触ってみると､改善点が出る場面がありました。そういった場合には、こういう UI にしてみたらどうか？などとそれぞれが意見し、良さそうな案についてはデザイナーがそれらの提案を取り込んだり､改良したりして、UI の仕様を詰めていきました。 技術面について 新居 : UI を実装に落とし込む際、技術面で工夫した点や気を付けていたポイントなどはありますか？ 堀内 : 今回のプロジェクトでは、求人カードのデザインを大幅に変更する為､事前の影響範囲の洗い出しを徹底するよう注意していました｡例えば、一覧画面における求人情報の出力量がかなり増えることで、1 ページあたりの読み込み処理に時間がかかってしまうことが予想された為､コンテンツの遅延読み込みやキャッシュの利用によりチューニングを行っています｡また､デザイン変更が多くのページにわたって発生する為､リリース後の不具合を起こさないような対策を複数行っています｡ 担当したプロジェクトのリード 新居 : 今回のプロジェクトでは、エンジニアとして開発をしつつ、堀内さんがプロジェクトのリードを任されていたと聞いています。リードとしては、どんな動きをプロジェクトの中でされていたのでしょうか？ 堀内 : まずは、最初にプロジェクト全体の大まかなスケジュールを引き、PdM と確認しました。次に、タスク分解をしてメンバーへのアサインを行ったり、プロジェクトのタスクのなかで不確実性を極力少なくする為に、自分達だけではコントロールできなさそうな部分を洗い出したりしました。洗い出したアンコントローラブルな部分は企画者と共に関係各所へ連絡・調整をしてもらうようお願いしていました。 新居 : なるほど。開発スケジュールの出し方など、その辺りで工夫した点などはありますか？ 堀内 : スケジュールの共有方法については、視覚的に分かりやすいように、 FigJam を使って、ガントチャートのような形式で、ボードを作成しました。 メンバー毎にレーンを振り分けて、誰がいつまでに何をしなければいけないのかを夕会で確認していました。また、スケジュールのボードは常に、 第三者が見ても進捗状況が直ぐに分かるような状態にしておく よう努めました。 スケジュールボード スケジューリングで特に意識していたことは、不確実な部分を早めに洗い出すことでした。タスク分解をしていく中で、どこが自分達だけではコントロールできなさそうな部分なのかを把握することから始めていました。 現状の仕様や実装がどうなっているのかなどは直ぐに確認できるので、そういったところから、なるべく不確実な部分を減らしていき、最終的に各タスクの工数を算出するにあたって、不確実性の高さに応じて、バッファを設定しました。 新居 : 少し手を動かせば確認できるようなところは直ぐに確認して、なるべく解像度が高い状態にもっていく進め方は確かに良さそうですね！工数を見積もるにあたって、解像度が低い状態だと、見積もりの精度が低くなってしまいますからね。 堀内 : また、タスクは GitHub Issue を発行して管理していたのですが、切り出す粒度はなるべく細かくしていました。Issue の粒度が荒くなってしまうと、それに比例して手戻りリスクが高くなってしまうので、目安としては、長くても 2 日以内には完了できる粒度で切り出していました。 結果、今回のプロジェクトにおいては、ほとんど手戻りすることなく、ほぼ全ての期間において、オンスケジュールで進めることができました。 A/B テストの導入（効果検証の仕組み化） 新居 : オンスケで進められていたのは素晴らしいですね！開発者として実装することと、リードとしてプロジェクトを管理することの他、堀内さんが今回のプロジェクトで担当していた役割などはありますか？ 堀内 : 今回のプロジェクトでは、効果検証を行う為の仕組みとして、A/B テストを本格的に導入する目標がありました。なぜ A/B テストを導入するのか？ A/B テストで何をしたいのか？を明確にして、A/B テストの設計から導入､分析までを行いました。 統計的な分析手法の選択から実際のテスト環境の開発みたいなところまで一気通貫で、PdM、マーケター、エンジニアを巻き込んで行いました。 A/B テストで大事なのは、論理的な仮説を立ててそれを検証し、その結果からより効果があると判断できた施策を導入していく、というサイクルだと考えています｡とはいえ、有意差が出たからといって必ずしも導入したほうが良いというわけではありません｡その時の経営面のメリット・デメリットを考慮し､これまでの経験にもとづいた判断も加えて、より効果の高い施策を継続的に導入できるようにする、というのが今回の目標です｡ 今回のプロジェクトを皮切りに、他のプロジェクトでも同じように A/B テストの仕組みを使える状態にしたい。そういった横展開や汎用性みたいなところも、プロジェクト当初からセットで考えていました。 新居 : とても興味深い取り組みですね！実際、どのように仕組み化を進めていくのでしょうか？ 堀内 : A/B テストに必要な知見をドキュメント化して、それを見るだけで、エンジニアのサポートを受けつつ誰でも A/B テストが実施できるようにしていく取り組みや､スプレッドシートにデータを入力すれば、簡単に結果が判るような仕組み化を進行中です｡ 機能のリリース時は､その結果に応じて結局、どうすれば良いのか？といった指針も Issue やドキュメントに記載しております｡ 実装や設計面における悩み 新居 : 実装や設計面において、今回のプロジェクトで悩んだようなところはありましたか？ 堀内 : はい。自分自身の力量の問題で、ドメイン知識や技術力などが不足していたことから、ジョブメドレーのコードの中で今までの慣習を受け継ぎつつ、良い感じに使い回しができるコードをどう上手く書いていくか、という点について悩んでいました。 新居 : なるほど…。ジョブメドレー自体が 10 年以上の歴史があるサービスなので、そこに手を入れていくのは確かに難しい部分もありそうですね。その悩みに対しては、どう対策をされていたのでしょう？ 堀内 : そうですね。今の自分の知見だけで設計と実装を進めてしまうと手戻りが発生してしまう恐れがあったので、まずはドメイン知識が豊富な、同じチーム内のベテラン社員に設計レビューをお願いしました。そこで、ジョブメドレーのインフラ構成におけるキャッシュ戦略や､保守性を高める為の実装の切り出し方など、壁打ちで相談させてもらっていました。 その先輩社員との設計レビュー以外にも、普段から行ってもらっている 1on1 ミーティングを通じて、自分のメンターと相談させてもらい、どういう設計だったら使いやすいのか、などを様々な視点から検討しました｡ 新居 : なるべく手戻りが発生しないようにする為に、 設計段階で身近にいるエンジニアを巻き込んで進めていった のですね。直ぐに相談できる相手がいるのは心強いですね。 学びになった点 新居 : 今回のプロジェクトを通じて、特に学びになった点を教えていただけますか？ 堀内 : 技術的な面とプロジェクトの進め方の面でそれぞれ学びがありました。 技術的な面で言うと、 保守性が高く、今後、運用しやすいコードとはどういうものなのかというのを、今回の実装を通じて体得できた ところだと思っています。 プロジェクトの進め方の面では、過去のプロジェクトのドキュメントを参考に、そこに書かれていた知見を活かしながら、プロジェクトを進めていったので、ノウハウのようなところが学べたかと思っています。 新卒研修・開発実践のリードとの違い 新居 : 堀内さんは、新卒研修の一環で行われた開発実践の期間中、新卒同士のチーム開発でもリードを務めていたと思います。今回のプロジェクトを通じて経験されたリードとの違いについて教えてください。 堀内 : プロジェクトの規模や影響範囲の違いなどから、研修時よりも多くの関係者との調整が必要でした｡全員と情報を共有・連携しつつ､プロジェクトを進める必要があった点が一番大きな違いでした。 また、開発実践のプロジェクトはあくまで社内向けシステムを構築するものだったので、会社の売上について意識することはありませんでしたが、今回のプロジェクトでは、施策によって応募率が下がった場合に売上に悪影響を及ぼす可能性がありましたので、開発部署以外への影響を意識して管理する必要があったことも大きいポイントだったと思っています。 ジョブメドレーの開発におけるやりがい 新居 : ここまで直近で担当されていたプロジェクトについて聞いてきましたが、ジョブメドレーの開発をしていて、特にやりがいを感じる場面について、教えてもらえますか？ 堀内 : やはり､利用してくださっている求職者や事業者の方々に向けて､新規機能開発や機能改修を行う工程です｡目的と照らし合わせて仕様面から妥協せずに考え抜き、リリースするまでの過程にやりがいを感じています｡ユーザー数がとても多いだけに､良い機能をリリースできたときの反響も大きく､非常に楽しいです｡ 勿論、エンジニアとして技術力を上げていくことも貪欲に今後もやっていかなければならない部分だと思っていますが、企画として案件があがってきた段階で、それをなぜ作るのか？なぜそれで効果が出ると思っているのか？などと考えることが、企画職だけでなく､エンジニアにとっても大事だと考えています｡ リリースした後には、実際に効果が出たのか出なかったのか、なぜ効果が出たのか､出なかったのか？などの効果検証を行った上で、PdM を中心にエンジニア以外のメンバーも交えて振り返り、次の施策に活かしていくといった、 PDCA サイクルを回していっている開発スタイルに楽しさを感じています 。 これは、自分の入社時にやりたいこととしてあげていた、エンジニアリング面だけではなくビジネス面についても多くの経験を積みたい、というところにリンクしていて、今在籍しているジョブメドレーの開発チームでは、企画やマーケティングを行う人達とエンジニアがとても近い距離にいることで、様々な知見を得られつつアウトプットできる､とても学びになる環境だと感じています。 ジョブメドレー開発チームにおける 1 日の流れ 新居 : 現在のジョブメドレー開発チームは、Growth Unit（求職者の利便性を高める施策を行うチーム）と Customer Unit（求人を掲載する事業者が使う採用管理システムの改善施策を行うチーム）の 2 つに分かれているんですよね。堀内さんが所属しているのは、Growth Unit の方ですが、参加されているミーティングなど、1 日の流れについて教えてください。 堀内 : まず、勤務開始の 10:00 頃には Slack に投稿する形で、その日のタスクや参加予定のミーティングなどについて、開発用 channel で共有します。 現在の自分のスケジュールでは、午前中は特に定常的なミーティングはありません。但し、アサインされるプロジェクトによっては、午前中に「朝会」としてプロジェクトメンバー同士が集まって、進捗共有などを行っています。 お昼過ぎの 14:30 からは､ 30 分程度､Growth Unit のエンジニアだけで集まるミーティングがあります。この場では、各自の進捗状況や抱えている不安・不明点などを共有します｡今何に困っているのかを共有するだけでなく､ 困りごとに対し､各々が知恵を出し合って、問題解決までのリードタイムを短くする ことができる貴重な場となっています｡ 18:00 からは「夕会」として、PdM とデザイナーも含めた Growth Unit 全体のミーティングがあります。そこで各自、「今日やったこと」や担当 Issue のリリース目処などを共有しています。この場では、エンジニア以外のメンバーも参加しているので、そこまで技術的に突っ込んだ話まではしません。 さらに、終業前にはまたエンジニアだけで集まり、FigJam を使って付箋を貼っていく形で、 各自が技術的トピックや、特定のドメインについて聞きたいことなどを持ち寄り、ざっくばらんに雑談形式で話す 「技術共有会」を行っています。 技術共有会の雰囲気 ミーティングの場以外は黙々と開発を進めていきますが、聞きたいことや相談したいことが出てきたら都度、開発用のスレッドに投稿しています。 新居 : なるほど。質問や相談はしやすい感じですか？ 堀内 : はい。勿論、自分で調べられることはなるべく調べて、自己解決するのが基本ではありますが、あまり調査に時間をかけ過ぎて全然進まないような事態に陥っても良くないので、それらを皆、前提として意識した上で、聞くべき時は躊躇なく聞ける雰囲気があります。 新居 : ミーティングの種類としては、先ほどあげてもらったもの以外にありますか？ 堀内 : あとは、週一で行われている「プロダクト定例」と隔週で行ってもらっている「1on1 ミーティング」があります。 プロダクト定例は、比較的規模の大きいミーティングで、我々、プロダクト開発室以外のメンバーの他、マーケティング室や事業企画室のメンバーも含めて、大体いつも 40 名前後の人数で参加しています。 この場では、現在追っている KPI だったり、ジョブメドレーで動いている全てのプロジェクト状況が共有されます。そこで共有される KPI の数字によって、次に着手すべき Issue にも影響してくるので、この場で共有される情報をしっかりとインプットして、今後の心構えとすることにしています。 直近で担当したプロジェクトの話でもちらっと出てきましたが、1on1 ミーティングは担当メンターと行なっています。普段の仕事の相談から、自分のキャリアに関するような相談をしており、メンターさんの経験なども教えていただきながら、勉強させていただいています。 1on1 ミーティングの意義としては、そういった仕事の他、 プライベートのことも含めて、何でも相談ができる場 としてあるのですが、1on1 を通じて、メンターさんとの信頼関係も築けるので、チームビルディングの一つとしても機能しています。 ジョブメドレー開発チームで一緒に働きたいと思う人はどんな人？ 新居 : 堀内さんがジョブメドレー開発チームで一緒に働きたいと思う人はどんな人でしょうか？ 堀内 : 今の環境で働いてて良かったなあと思うことは、 人間関係が良好であること です｡もちろん馴れ合いの中での業務というわけではなく､各々が しっかりと仕事に対して責任を持ちつつ､チーム内で生じた違和感は遠慮なく指摘し合い受けとめる という､良い意味で心理的安全性のある環境でプロダクト開発に集中して取り組めることです。 このような環境で、課題に対して長期的な視点で本質を捉え、目的を設定し､ボトムアップで解決策の立案から改善までを主導すること、さらには仕組み化まで行うことが好きな方､またはそれらをやってみたい方が合っているのではないか､と思います。 自分もそのような人間になりたいと思いながら、日々仕事に取り組んでいます。 さいごに ジョブメドレー開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いてきましたが、いかがだったでしょうか？ こんなチームでプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの新居です。今回は医療介護求人サイトの ジョブメドレー 開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いていこうと思います。 インタビュイー紹介 堀内さん 2021 年入社。人材プラットフォーム本部 プロダクト開発室 第一開発グループ所属。ジョブメドレーの開発を担当。現在は求職者側の UI/UX 改善などの開発に携わる。 堀内さん メドレーに入社した理由 新居 : まずはじめに、堀内さんはどういう経緯でメドレーに入社したのでしたっけ？ 堀内 : 以前のインタビュー（ 21 年新卒入社エンジニアと座談会で振り返る新卒研修 ）の時にもお話したのですが、就活の軸として、自分が成長できそうか・風通しが良いか・合理的な社風かなどを軸として探していました。特に､ ビジネス側と開発側の距離が近い 部分に惹かれ､総合的にメドレーが良さそうだと考えて入社しました。 新居 : 入社前の印象と実際働きだしてからで、ズレなどはありましたか？ 堀内 : そんなにギャップはなくて、社風とか人間関係みたいなところは入社前のイメージ通りでした。入社前に何回か会社見学をさせてもらったり、その時の社員と複数回面談をセッティングしてもらったりして、そこでイメージをすり合わせできたことが大きかったですね。 新居 : 何人くらいの社員と会ったのですか？ 堀内 : 6 ~ 7 人です。色々なポジションや性格の人達と話ができたので、安心して入社することができました。 新卒研修の開発 OJT ではどんなことをやっていたか？ 新居 : 堀内さんは新卒研修の開発 OJT のタイミングでジョブメドレー開発チームに仮配属されたのですよね。当時はどういうことをやってたのですか？ 堀内 : まずはジョブメドレーのドメイン知識をしっかり吸収していこうということで、業界や業務自体の理解を進めました。 その後、求職者と事業者のサポート業務を行う社内オペレーターが利用する画面の拡張タスクに取り組みました。 技術スタックは Next.js / React / TypeScript / GraphQL といったシステムで、個人的にあまり触れてこなかった領域だったので、技術のキャッチアップもしつつ丁寧に対応していきました。 また、開発 OJT よりも前の研修で輪読会も経験したのですが、その時に学んだ Cookie や Session まわりの知識が役に立ったり、座学で学んだことがこうやって実践で活きてくるんだな、ということを実感 できてとても良い経験になりました。 今までとは比べ物にならないくらい大規模なシステムだったので、プレッシャーも大きかったのですが、チームの人達と相談したり、細かいレビュー・サポートがあったおかげで、しっかり成果を出すことができたと思います。 新居 : 良い OJT ですね！堀内さん自身の努力があったのは勿論ですが、チームに新しいメンバーを迎え入れて成長をサポートする環境が整っていたのも良かったんでしょうね。 ちなみに開発 OJT の中で大変だったこととかはありますか？ 堀内 : そうですね、やはり大規模な既存コードの把握・理解が大変でした。社内オペレーターが使う画面とジョブメドレー本体はそれぞれ別システムとして連携しているので、ジョブメドレー本体のコードや仕組みの理解も必要です。 大変だった分、 システムの全体像を理解するのに大いに役立った ので、今思い返すと良い経験だったなあと思います。 色々な経験を積めた求人カード改修プロジェクト 新居 : では、新卒研修を終えてから 1 年以上経っていて、入社 2 年目の終わりに差し掛かっている現在ですが、直近で堀内さんがリードを務めていた、ジョブメドレーの求人カード改修プロジェクトについて話を聞いていきたいと思います。まずは、このプロジェクトの概要について、教えてもらえますか？ 求人カード改修プロジェクトとは？ 堀内 : それでは､プロジェクト説明に先立ちまして､まず、ジョブメドレーの「求人カード」について簡単に説明します。 ジョブメドレーで求人を検索すると､検索結果が並ぶ画面が出てきます。我々が「求人カード」と呼んでいるのは、この検索結果画面上に表示される、求人情報のことになります。 検索結果画面の求人カードでは、給与や大まかな業務内容、応募要件、職場の住所などが分かる形になっていますが、求職者の方々がより便利に使っていただけるよう、情報の出し方を見直すことが今回のプロジェクト内容です。 もう少し詳しくお話すると､採用決定率の改善を目的に､どのような改善を実施すべきか検討しています｡ 求職者にとって欲しい情報が手に入りやすくなるということは、その分、応募に繋がりやすくなると言い換えることもできますので､改修による効果については、継続的に検証し､効果の有無を明らかにしたいと考えています｡ 新居 : なるほど。端的に言うと、ジョブメドレーにおける求人情報検索の体験を更に良くする為のプロジェクトということですね。 プロジェクトのはじまり 新居 : 今回のプロジェクトをどのようなメンバーと何をどのように行っていったのか、チーム構成から教えてください。 堀内 : チーム構成としては、自分を含めたエンジニアが 2 人いて、その他は、デザイナー、マーケター、プロダクトマネージャー（以下、PdM）がそれぞれ 1 人ずつプロジェクトにアサインされました。 プロジェクトのきっかけとしては、求職者体験を更に良くする為の企画の一つとしてマーケターと PdM が企画したところから始まり、その後、エンジニアとマーケター間で､細かい具体的な要件まで落とし込んで、プロジェクト化に至りました。 仕様についてメンバー間で徹底議論 堀内 : 要件まで落とし込んだ後は、具体的にそれらをどうやって実装するかを検討しました。特に UI の仕様については、デザイナーを中心にかなり長い時間をかけて詰めていきました 。 新居 : 確かに、情報の出し方によっては、かえって、求職者体験を悪化させてしまう可能性がありそうですね…。 堀内 : はい。使い勝手の良い UI にする為に、デザイナーがまず Figma でモックアップを作り、プロジェクトが始まった最初の週からデイリーの夕会などで、UI に関して徹底的にプロジェクトメンバー間で議論をしていました。 その時、特にメンバー全員が気を付けていたのは、実際に求職者が新しい一覧画面を使う時に、価値を感じてもらえるかどうかです。メドレーの Our Essentials の一つとして、 長期のカスタマー価値を追求 という項目があります｡「全ての利用者にとって価値のある施策であること」､「利用者の片方だけを見て、もう片方を無視することがあってはならない」ということで、事業者側の求人情報を多く載せるだけではなく、求職者にとっての使い勝手も向上しているか？などを徹底的にチェックしていました。 使い勝手をチェックするにあたって、ジョブメドレーのメインユーザーの年齢層などが予め分かっていたので、その方達にとって使いやすいかどうかを判断軸として、考えていました。 デザイナーが完成させた UI でも、でき上がったモックアップをメンバーそれぞれの視点で触ってみると､改善点が出る場面がありました。そういった場合には、こういう UI にしてみたらどうか？などとそれぞれが意見し、良さそうな案についてはデザイナーがそれらの提案を取り込んだり､改良したりして、UI の仕様を詰めていきました。 技術面について 新居 : UI を実装に落とし込む際、技術面で工夫した点や気を付けていたポイントなどはありますか？ 堀内 : 今回のプロジェクトでは、求人カードのデザインを大幅に変更する為､事前の影響範囲の洗い出しを徹底するよう注意していました｡例えば、一覧画面における求人情報の出力量がかなり増えることで、1 ページあたりの読み込み処理に時間がかかってしまうことが予想された為､コンテンツの遅延読み込みやキャッシュの利用によりチューニングを行っています｡また､デザイン変更が多くのページにわたって発生する為､リリース後の不具合を起こさないような対策を複数行っています｡ 担当したプロジェクトのリード 新居 : 今回のプロジェクトでは、エンジニアとして開発をしつつ、堀内さんがプロジェクトのリードを任されていたと聞いています。リードとしては、どんな動きをプロジェクトの中でされていたのでしょうか？ 堀内 : まずは、最初にプロジェクト全体の大まかなスケジュールを引き、PdM と確認しました。次に、タスク分解をしてメンバーへのアサインを行ったり、プロジェクトのタスクのなかで不確実性を極力少なくする為に、自分達だけではコントロールできなさそうな部分を洗い出したりしました。洗い出したアンコントローラブルな部分は企画者と共に関係各所へ連絡・調整をしてもらうようお願いしていました。 新居 : なるほど。開発スケジュールの出し方など、その辺りで工夫した点などはありますか？ 堀内 : スケジュールの共有方法については、視覚的に分かりやすいように、 FigJam を使って、ガントチャートのような形式で、ボードを作成しました。 メンバー毎にレーンを振り分けて、誰がいつまでに何をしなければいけないのかを夕会で確認していました。また、スケジュールのボードは常に、 第三者が見ても進捗状況が直ぐに分かるような状態にしておく よう努めました。 スケジュールボード スケジューリングで特に意識していたことは、不確実な部分を早めに洗い出すことでした。タスク分解をしていく中で、どこが自分達だけではコントロールできなさそうな部分なのかを把握することから始めていました。 現状の仕様や実装がどうなっているのかなどは直ぐに確認できるので、そういったところから、なるべく不確実な部分を減らしていき、最終的に各タスクの工数を算出するにあたって、不確実性の高さに応じて、バッファを設定しました。 新居 : 少し手を動かせば確認できるようなところは直ぐに確認して、なるべく解像度が高い状態にもっていく進め方は確かに良さそうですね！工数を見積もるにあたって、解像度が低い状態だと、見積もりの精度が低くなってしまいますからね。 堀内 : また、タスクは GitHub Issue を発行して管理していたのですが、切り出す粒度はなるべく細かくしていました。Issue の粒度が荒くなってしまうと、それに比例して手戻りリスクが高くなってしまうので、目安としては、長くても 2 日以内には完了できる粒度で切り出していました。 結果、今回のプロジェクトにおいては、ほとんど手戻りすることなく、ほぼ全ての期間において、オンスケジュールで進めることができました。 A/B テストの導入（効果検証の仕組み化） 新居 : オンスケで進められていたのは素晴らしいですね！開発者として実装することと、リードとしてプロジェクトを管理することの他、堀内さんが今回のプロジェクトで担当していた役割などはありますか？ 堀内 : 今回のプロジェクトでは、効果検証を行う為の仕組みとして、A/B テストを本格的に導入する目標がありました。なぜ A/B テストを導入するのか？ A/B テストで何をしたいのか？を明確にして、A/B テストの設計から導入､分析までを行いました。 統計的な分析手法の選択から実際のテスト環境の開発みたいなところまで一気通貫で、PdM、マーケター、エンジニアを巻き込んで行いました。 A/B テストで大事なのは、論理的な仮説を立ててそれを検証し、その結果からより効果があると判断できた施策を導入していく、というサイクルだと考えています｡とはいえ、有意差が出たからといって必ずしも導入したほうが良いというわけではありません｡その時の経営面のメリット・デメリットを考慮し､これまでの経験にもとづいた判断も加えて、より効果の高い施策を継続的に導入できるようにする、というのが今回の目標です｡ 今回のプロジェクトを皮切りに、他のプロジェクトでも同じように A/B テストの仕組みを使える状態にしたい。そういった横展開や汎用性みたいなところも、プロジェクト当初からセットで考えていました。 新居 : とても興味深い取り組みですね！実際、どのように仕組み化を進めていくのでしょうか？ 堀内 : A/B テストに必要な知見をドキュメント化して、それを見るだけで、エンジニアのサポートを受けつつ誰でも A/B テストが実施できるようにしていく取り組みや､スプレッドシートにデータを入力すれば、簡単に結果が判るような仕組み化を進行中です｡ 機能のリリース時は､その結果に応じて結局、どうすれば良いのか？といった指針も Issue やドキュメントに記載しております｡ 実装や設計面における悩み 新居 : 実装や設計面において、今回のプロジェクトで悩んだようなところはありましたか？ 堀内 : はい。自分自身の力量の問題で、ドメイン知識や技術力などが不足していたことから、ジョブメドレーのコードの中で今までの慣習を受け継ぎつつ、良い感じに使い回しができるコードをどう上手く書いていくか、という点について悩んでいました。 新居 : なるほど…。ジョブメドレー自体が 10 年以上の歴史があるサービスなので、そこに手を入れていくのは確かに難しい部分もありそうですね。その悩みに対しては、どう対策をされていたのでしょう？ 堀内 : そうですね。今の自分の知見だけで設計と実装を進めてしまうと手戻りが発生してしまう恐れがあったので、まずはドメイン知識が豊富な、同じチーム内のベテラン社員に設計レビューをお願いしました。そこで、ジョブメドレーのインフラ構成におけるキャッシュ戦略や､保守性を高める為の実装の切り出し方など、壁打ちで相談させてもらっていました。 その先輩社員との設計レビュー以外にも、普段から行ってもらっている 1on1 ミーティングを通じて、自分のメンターと相談させてもらい、どういう設計だったら使いやすいのか、などを様々な視点から検討しました｡ 新居 : なるべく手戻りが発生しないようにする為に、 設計段階で身近にいるエンジニアを巻き込んで進めていった のですね。直ぐに相談できる相手がいるのは心強いですね。 学びになった点 新居 : 今回のプロジェクトを通じて、特に学びになった点を教えていただけますか？ 堀内 : 技術的な面とプロジェクトの進め方の面でそれぞれ学びがありました。 技術的な面で言うと、 保守性が高く、今後、運用しやすいコードとはどういうものなのかというのを、今回の実装を通じて体得できた ところだと思っています。 プロジェクトの進め方の面では、過去のプロジェクトのドキュメントを参考に、そこに書かれていた知見を活かしながら、プロジェクトを進めていったので、ノウハウのようなところが学べたかと思っています。 新卒研修・開発実践のリードとの違い 新居 : 堀内さんは、新卒研修の一環で行われた開発実践の期間中、新卒同士のチーム開発でもリードを務めていたと思います。今回のプロジェクトを通じて経験されたリードとの違いについて教えてください。 堀内 : プロジェクトの規模や影響範囲の違いなどから、研修時よりも多くの関係者との調整が必要でした｡全員と情報を共有・連携しつつ､プロジェクトを進める必要があった点が一番大きな違いでした。 また、開発実践のプロジェクトはあくまで社内向けシステムを構築するものだったので、会社の売上について意識することはありませんでしたが、今回のプロジェクトでは、施策によって応募率が下がった場合に売上に悪影響を及ぼす可能性がありましたので、開発部署以外への影響を意識して管理する必要があったことも大きいポイントだったと思っています。 ジョブメドレーの開発におけるやりがい 新居 : ここまで直近で担当されていたプロジェクトについて聞いてきましたが、ジョブメドレーの開発をしていて、特にやりがいを感じる場面について、教えてもらえますか？ 堀内 : やはり､利用してくださっている求職者や事業者の方々に向けて､新規機能開発や機能改修を行う工程です｡目的と照らし合わせて仕様面から妥協せずに考え抜き、リリースするまでの過程にやりがいを感じています｡ユーザー数がとても多いだけに､良い機能をリリースできたときの反響も大きく､非常に楽しいです｡ 勿論、エンジニアとして技術力を上げていくことも貪欲に今後もやっていかなければならない部分だと思っていますが、企画として案件があがってきた段階で、それをなぜ作るのか？なぜそれで効果が出ると思っているのか？などと考えることが、企画職だけでなく､エンジニアにとっても大事だと考えています｡ リリースした後には、実際に効果が出たのか出なかったのか、なぜ効果が出たのか､出なかったのか？などの効果検証を行った上で、PdM を中心にエンジニア以外のメンバーも交えて振り返り、次の施策に活かしていくといった、 PDCA サイクルを回していっている開発スタイルに楽しさを感じています 。 これは、自分の入社時にやりたいこととしてあげていた、エンジニアリング面だけではなくビジネス面についても多くの経験を積みたい、というところにリンクしていて、今在籍しているジョブメドレーの開発チームでは、企画やマーケティングを行う人達とエンジニアがとても近い距離にいることで、様々な知見を得られつつアウトプットできる､とても学びになる環境だと感じています。 ジョブメドレー開発チームにおける 1 日の流れ 新居 : 現在のジョブメドレー開発チームは、Growth Unit（求職者の利便性を高める施策を行うチーム）と Customer Unit（求人を掲載する事業者が使う採用管理システムの改善施策を行うチーム）の 2 つに分かれているんですよね。堀内さんが所属しているのは、Growth Unit の方ですが、参加されているミーティングなど、1 日の流れについて教えてください。 堀内 : まず、勤務開始の 10:00 頃には Slack に投稿する形で、その日のタスクや参加予定のミーティングなどについて、開発用 channel で共有します。 現在の自分のスケジュールでは、午前中は特に定常的なミーティングはありません。但し、アサインされるプロジェクトによっては、午前中に「朝会」としてプロジェクトメンバー同士が集まって、進捗共有などを行っています。 お昼過ぎの 14:30 からは､ 30 分程度､Growth Unit のエンジニアだけで集まるミーティングがあります。この場では、各自の進捗状況や抱えている不安・不明点などを共有します｡今何に困っているのかを共有するだけでなく､ 困りごとに対し､各々が知恵を出し合って、問題解決までのリードタイムを短くする ことができる貴重な場となっています｡ 18:00 からは「夕会」として、PdM とデザイナーも含めた Growth Unit 全体のミーティングがあります。そこで各自、「今日やったこと」や担当 Issue のリリース目処などを共有しています。この場では、エンジニア以外のメンバーも参加しているので、そこまで技術的に突っ込んだ話まではしません。 さらに、終業前にはまたエンジニアだけで集まり、FigJam を使って付箋を貼っていく形で、 各自が技術的トピックや、特定のドメインについて聞きたいことなどを持ち寄り、ざっくばらんに雑談形式で話す 「技術共有会」を行っています。 技術共有会の雰囲気 ミーティングの場以外は黙々と開発を進めていきますが、聞きたいことや相談したいことが出てきたら都度、開発用のスレッドに投稿しています。 新居 : なるほど。質問や相談はしやすい感じですか？ 堀内 : はい。勿論、自分で調べられることはなるべく調べて、自己解決するのが基本ではありますが、あまり調査に時間をかけ過ぎて全然進まないような事態に陥っても良くないので、それらを皆、前提として意識した上で、聞くべき時は躊躇なく聞ける雰囲気があります。 新居 : ミーティングの種類としては、先ほどあげてもらったもの以外にありますか？ 堀内 : あとは、週一で行われている「プロダクト定例」と隔週で行ってもらっている「1on1 ミーティング」があります。 プロダクト定例は、比較的規模の大きいミーティングで、我々、プロダクト開発室以外のメンバーの他、マーケティング室や事業企画室のメンバーも含めて、大体いつも 40 名前後の人数で参加しています。 この場では、現在追っている KPI だったり、ジョブメドレーで動いている全てのプロジェクト状況が共有されます。そこで共有される KPI の数字によって、次に着手すべき Issue にも影響してくるので、この場で共有される情報をしっかりとインプットして、今後の心構えとすることにしています。 直近で担当したプロジェクトの話でもちらっと出てきましたが、1on1 ミーティングは担当メンターと行なっています。普段の仕事の相談から、自分のキャリアに関するような相談をしており、メンターさんの経験なども教えていただきながら、勉強させていただいています。 1on1 ミーティングの意義としては、そういった仕事の他、 プライベートのことも含めて、何でも相談ができる場 としてあるのですが、1on1 を通じて、メンターさんとの信頼関係も築けるので、チームビルディングの一つとしても機能しています。 ジョブメドレー開発チームで一緒に働きたいと思う人はどんな人？ 新居 : 堀内さんがジョブメドレー開発チームで一緒に働きたいと思う人はどんな人でしょうか？ 堀内 : 今の環境で働いてて良かったなあと思うことは、 人間関係が良好であること です｡もちろん馴れ合いの中での業務というわけではなく､各々が しっかりと仕事に対して責任を持ちつつ､チーム内で生じた違和感は遠慮なく指摘し合い受けとめる という､良い意味で心理的安全性のある環境でプロダクト開発に集中して取り組めることです。 このような環境で、課題に対して長期的な視点で本質を捉え、目的を設定し､ボトムアップで解決策の立案から改善までを主導すること、さらには仕組み化まで行うことが好きな方､またはそれらをやってみたい方が合っているのではないか､と思います。 自分もそのような人間になりたいと思いながら、日々仕事に取り組んでいます。 さいごに ジョブメドレー開発チームに所属している堀内さんに、2 年目の成長と活躍というテーマで話を聞いてきましたが、いかがだったでしょうか？ こんなチームでプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp