医療ビッグデータを活かした事業を幅広く展開しているJMDCには、魅力的な経歴や豊富な経験を持ったメンバーが所属しています。今回は、「Pep Up（ペップアップ）」のフロントエンドチームでテックリードを務める八杉さんにインタビューを実施しました。JMDCでの開発の面白さは、医療健康というドメインをはじめ、技術やチーム、開発体験などにあるようです。
＜プロフィール＞
八杉 耕平（やすぎ こうへい）プロダクト開発部 ユーザープラットフォームグループ フロントエンドチーム テックリード
大学を卒業後、地方のISP企業を経て、2017年12月にヘルスデータ・プラットフォーム株式会社（当時JMDCの子会社）に入社。入社当初からPep Upのフロントエンドエンジニアとして携わり、現在はフロントエンドチームのテックリードを務める。
PHRサービス「Pep Up」のフロント開発とは
――八杉さんのJMDC以前のご経歴も含めて自己紹介をお願いします。
新卒で地方のISP事業者に入社し、Web制作部門で主にWebフロントエンドを担当しました。PHP製の自社CMSを使ったWebサイト制作や、AngularJSとCordovaによるハイブリッドアプリ案件などを受託で開発していました。3年半勤めた後、上司の退職を機に私も退職し、東京で転職活動をしました。数社からオファーをいただいた中で一番高く評価していただいたのが、当時はまだJMDCの子会社だったヘルスデータ・プラットフォーム株式会社（以下HDP、2018年にJMDCに統合）でした。医療費の最適化という社会貢献に技術を通じて携われることに魅力を感じましたし、面接やその後の懇親会を通じてお話しする中で、メンバーの技術力や人柄にも惹かれて2017年の12月に入社しました。
入社当時から今まで、PHRサービスPep Upのフロントエンドに携わっており、現在はフロントエンドチームのテックリードを務めています。
▼HDPがPep Upを立ち上げ・グロースまでした軌跡についての記事もございますので、ぜひご覧ください。
――転職の際、業界や事業内容など、具体的に基準とされたことはありましたか。
技術力を高められる環境を求めて、特に業界や事業内容は絞らずに見ていました。ただ、前職では重厚な機能要件の受託開発が多く、「この機能は本当に必要なのだろうか？」「このアプリはどれくらいの方に使ってもらえるんだろうか」と感じながら開発していることもあったため、次はもっとユーザーとの距離が近くて、多くの人に使ってもらえるプロダクトに携わりたいという想いはありました。
そういった意味でもJMDCは、医療や健康という誰にとっても関わりのある領域で、自分の能力を活かして社会貢献できるところにやりがいを感じられそうだと思って選びました。
――八杉さんが入社してから開発に関わられてきたPep Upとは、どんなプロダクトでしょうか。
Pep Upは個人の健康や医療データを一元化して、健康を促進する活動に繋げてもらうPHRサービスで、元々は「JMDCが長年蓄積してきた医療ビッグデータを活用して個人向けWebサービスを作ろう」という構想のもと、JMDCの子会社で作っていたサービスです。その会社をJMDCが吸収合併しサービスとして引き継ぎ、現在に至ります。ですので、toB向けのサービスが多いJMDCの中では珍しいBtoBtoCのビジネスモデルで、健康保険組合（以下、健保）を経由して、健保加入者の方々がユーザーとなっており、現在約400万人のユーザーIDを発行しています。（2022年12月の取材当時の数値）
加入している健康保険組合の通知を受け取ったり、JMDCが配信するヘルスケア関連の情報をチェックしたりできるのが特徴です。
※パーソナルヘルスレコード。個人の健康や医療データを一元管理して、健康を促進する活動につなげてもらうWebサービスのこと。
――Pep Upの開発体制について教えてください。
Pep Upの開発チームには16名が所属しており、私の所属するフロントエンドチームが4名で、その他にバックエンドとSRE、アプリのチームがいます。
Pep Upは、Ruby on Rails製のWebアプリとReact Native製のモバイルアプリからなります。Webアプリには健保加入者向けの画面のほか、いくつかの管理画面も含まれます。
フロントエンドのコードベースはRailsのリポジトリに間借りする形で同居していて、yarn workspacesを使ったmonorepoになっています。Reactを使っていますがSPAやnext.jsではなく、Rails view上にコンポーネントをマウントする構成で、最近はGraphQLを取り入れて開発しています。
フロントエンドは私が入社してから徐々にモダン化に取り組み、現在の形になりました。
漸進的なアプローチでモダン化を推進
――フロントエンドのモダン化の経緯について伺えますか。
私が入社した当時は、CoffeeScriptでjQueryを書いてAsset Pipelineでビルドする、当時としては典型的なRailsのフロントエンド構成でした。開発開始から3年分の負債が相応に溜まっていて、特にCSSのコード負債は手強い状態でした。過去にデザインのリニューアルを試みた跡があり、しかもそれが古いコードを !important で上書きする形で追加されていたため、狙ったスタイルを当てるのが非常に難しくなっていました。
どこから直していこうかと考えた結果、一度フロントエンドの古いコードベースを捨てて新しくやり直す必要があると判断しました。ただ、まるごと作り直すのではなく、既存のコード資産を活かしながら少しずつモダンな構成に移行していくことを選びました。新しく実装する画面から、徐々にReactとTypeScriptで書いていくことにしたんです。当時は正社員のエンジニアが私を含めて3人しかいませんでしたし、既に稼働しているサービスを止めることもできないため、このような漸進的なアプローチを取りました。CoffeeScriptとjQueryの古いページは今もいくつか残っていますが、大半のページはReactに移行してきました。
――八杉さんがモダン化を任されて、Reactの導入など技術も提案したということでしょうか。
そうですね。業務委託を含め、当時のメンバーはバックエンドやインフラにはめっぽう強かったですが、フロントエンドが得意なメンバーは私が初めてで。基本的には、私がやりたいように自由にやらせてもらっていました。
――技術選定の際、何を基準にされているのでしょうか。
技術トレンドをウォッチしつつ、ベストプラクティスに従うことを心がけています。それから、新しい技術を導入する際はまずは小さく試してみる。たとえば管理画面の一部などで試しに運用してみて、ちゃんとワークするか確かめてから普及させていくことが多いです。そうしていろいろ試していると、異なる流儀のコードが混在することになったりもするのですが、並行運用して比較しつつ、その中で一番実用に堪えるものを残せば良いかなというスタンスです。
ユーザー画面のほかに管理画面がいくつかありコードベース自体はそれなりに大規模ですが、開発チームの規模は大きくないため、今のところはリポジトリを分割したりせずモジュラーモノリスを指向しています。
――その他、Pep Upの開発技術における特徴は何かありますか。
今のアーキテクチャは結局のところRailsのMPAなのですが、React Routerと組み合わせることでSPAのように開発できる構成になっています。Rails Wayで作られたアプリケーションの漸進的移行先としては、悪くない構成なのではないかと思います。ただし、やはりどうしてもRailsの遅さがボトルネックになるので、アーキテクチャのさらなる改善は今後の課題です。
チームのコミュニケーション
――開発組織の雰囲気やコミュニケーション、働き方を教えてください。
ユーザープラットフォーム開発部は若いメンバーとシニアなメンバーが満遍なく在籍していて、お互いにリスペクトを持って仕事しています。
エンジニアは基本的にリモートワークです。デイリースクラムで毎日お互いの状況を確認しているほか、部内のメンバーで雑談する会を週2回設けてコミュニケーションを促進しています。また、エンジニアはほとんどのメンバーがSlackの分報を活用していて、困ったときにつぶやくと誰かが拾ってくれるなんてことも多いです。個人情報を取り扱う際や、対面が必要な業務の際は出社することもあり、私自身は2ヶ月に1回程度出社しています。
Slackのグルメチャンネルで参加者を募ってご飯を食べに行くこともありますし、ゲーム好きなメンバーは業務後にオンラインで集まってゲームしていたりもします。
――新しく入社された方は、どのように組織にキャッチアップしていくのでしょうか。
新しいメンバーには必ずメンターが一人ついて、業務に馴染めるようにサポートする体制になっています。最初は高めの頻度で1on1を実施して、疑問や要望を素早く吸い上げられるようにしています。メンターのサポートのもとでまずは軽めのタスクに取り組んでもらい、慣れてきたら徐々に難しめのタスクや複雑な開発課題にも挑戦してもらっています。
――企画チームとのコミュニケーションについてはいかがですか。
Pep Upの活動報告の定例会を月一で開催し、毎月のアップデートを共有しています。デイリースクラムに企画のメンバーも参加しているので、業務や開発の優先度についてはそこでやり取りすることが多いですね。
リモートワークで部署も違うので、なかなか対面で話す機会は少ないのですが、先日、とある目標を達成したことを記念して、企画と開発のメンバーみんなで会社に集まってお祝いしたときは盛り上がりました。
JMDCの開発現場の魅力とやりがい
――JMDCだからこそ感じる、開発の魅力ややりがいはありますか。
医療や健康という誰にとっても関わりのあるドメインに向き合える点です。医療費の最適化は大きな社会課題ですし、その課題に技術を通して貢献できることがモチベーションになっています。特にPep Upは約400万IDとPHRサービスとしては規模の大きいプロダクトで、多くの方に使っていただいているので責任とやりがいを感じます。自分自身もユーザーであるため、実際にプロダクトを触りながら改善していくことができる点もおもしろいと思います。
――Pep Up以外のプロダクトの開発に携わることもあるのでしょうか。
現在、部内で開発を行っている新規プロダクトが2つあります。
一つは新たなtoC向けサービスで、仮説検証フェーズですが、React NativeとバックエンドにGoを採用して開発を進めています。Pep Upとの間で適宜技術情報の交換も行っていますし、お互いにいつでもコントリビュートできる状態です。
もう一つは、まだ開発には着手していないものの、個人の行動変容を促すようなプロダクトを企画しています。
また、社内にはその他にもReactを使ったプロダクトがいくつかあります。私は2年前にPep Up for WORKという企業向けのプロダクトの立ち上げメンバーに抜擢されて、一時的にPep Upを離れて新規立ち上げに注力していました。社内にフロントエンドエンジニアが少ないこともあって、その他のプロダクトからフロントエンドの技術相談を受けることもあります。
このように、他のプロダクトに関わることは少なくありません。ゆくゆくは、フロントエンドのイネイブリングチームみたいなものを作って社内を横断した最適化にも取り組んでいけたらと思っています。
▼Pep Up for WORKの立ち上げ秘話がわかる記事もございますので、ぜひご覧ください。
――新規プロダクトの開発は、八杉さんにとってどのような経験になりましたか？
それまで既存プロダクトに長く携わっていたため、新規プロダクトの立ち上げは新鮮でした。仮説検証の結果、せっかく作った機能が結局要らなくなるという経験もしましたし、早期に作り込みすぎないことや、あとで捨てられるように設計することの大切さを学びました。
技術的にはGraphQLを導入してReactのSPAとして作りました。GraphQLには大きな手応えを感じたので、Pep Up for WORKをローンチしてPep Upチームに戻ったあとPep Upにも導入しました。SPAの特徴や課題も把握できましたし、実りの多い経験になりました。
今後の展望
――八杉さんご自身が、Pep Upの開発のモチベーションとしているものは何でしょうか。
開発体験を向上させるのが好きなんです。レガシー改善やリファクタを喜んでやるタイプで、ベストプラクティスの収集と実践が趣味です。Pep UpはRailsのMPAなので、SPAやJSのSSRフレームワークとはまた違った課題があり、そこにもおもしろさを感じます。
――今後のPep Upの開発において見すえている挑戦や目標について伺えますか。
ユーザー体験と開発体験を両立する開発体制を整えていきたいです。そのためにはReactの思想を実践し、Suspenseのような新しい機能を使いこなすのが最善だと考えています。MPA由来の初回読み込みの遅さについても抜本的な解決に取り組んでいけたらと思っています。
また最近、新たにデザイナーの方がジョインしてくれたので、デザインルールの整備やサイトの動線設計のリデザインといったUI/UX改善も進めていきたいです。
――最後に、今後ジョインする方に期待することや、こういった志向性を持っているとJMDCの開発現場に合いそう、というイメージがあれば教えてください。
まずはWeb技術が好きで、特にReactを使ったベストプラクティスを追求したい方。Pep Upチームに関して言うと、現状はRailsありきのアーキテクチャなので、Railsとうまく共存する方法を考えたり、あるいは脱Railsの戦略を考えたりといったアーキテクチャレベルの課題解決を楽しめる方にも向いていると思います。
Pep Up以外にも社内にフロントエンドエンジニアの活躍の場は多くあるので、医療や健康ドメインにご興味をお持ちの方はもちろん、ご興味がなくてもぜひ一度カジュアルにお話しを聞きに来ていただけたら嬉しいです！
最後までご覧いただきありがとうございました。
もし少しでも弊社にご興味をお持ちいただけましたら、こちらの採用ピッチ資料をぜひ一度ご覧ください。
