医療ビッグデータを活かした事業を幅広く展開しているJMDCには、魅力的な経歴や豊富な経験を持ったメンバーが所属しています。今回は、Pep Upのバックエンドチームでテックリードを務める野田さんにインタビューを実施しました。複雑なデータを扱いながら、事業スケールをエンジニアリングの側から支えてきた野田さんに、JMDCで開発に携わる魅力を聞きました。
＜プロフィール＞
野田 実（のだ みのる）プロダクト開発部 ユーザープラットフォームグループ バックエンドチーム テックリード
新卒でSEとしてのキャリアをスタートし、その後スタートアップの一人目エンジニアを経験。ヘルスケア業界に興味を持ち、2018年7月にJMDCに入社。PHRサービス「Pep Up」の開発に携わり、現在はバックエンドエンジニアチームのテックリードとして従事。
Pep Upのバックエンドが注力する3つのポイント
――ご経歴を含めた自己紹介をお願いします。
2018年7月にバックエンドエンジニアとしてJMDCに入社しました。新卒では大手企業のシステム子会社のSE、その後はスタートアップで一人目エンジニアを経験しました。前職で市場調査をした際にヘルスケア業界が伸びていることを知り、興味を持ちJMDCに応募しました。当時のCTOの方がGREE社出身でWeb開発への造詣が深いことや、面談いただいたエンジニアの方がGitHubのパーカーで登場するなど、テックかつカジュアルな印象を感じて入社しました。
――現在開発に携わっているプロダクトと、開発体制について教えて下さい。
PHRサービス（※）「Pep Up（ペップアップ）」の開発に携わっています。
Pep Upは個人の健康や医療データを一元化して、健康を促進する活動に繋げてもらうPHRサービスで、元々は「JMDCが長年蓄積してきた医療ビッグデータを活用して個人向けWebサービスを作ろう」という構想のもと、JMDCの子会社で作っていたサービスです。その会社をJMDCが吸収合併しサービスとして引き継ぎ、現在に至ります。ですので、toB向けのサービスが多いJMDCの中では珍しいBtoBtoCのビジネスモデルで、健康保険組合（以下、健保）を経由して、健保加入者の方々がユーザーとなっており、現在約400万人のユーザーIDを発行しています。（2023年1月の取材当時の数値）
加入している健康保険組合の通知を受け取ったり、JMDCが配信するヘルスケア関連の情報をチェックしたりできるのが特徴です。
※パーソナルヘルスレコード。個人の健康や医療データを一元管理して、健康を促進する活動につなげてもらうWebサービスのこと。
体制は企画チームと開発チームに分かれており、エンジニアは14名、うちバックエンドは7名で開発しています。Ruby on Railsで作られたWebアプリケーションをメインに、新機能の追加や保守を行っており、また一部の機能はRuby on Railsに強い受託開発の会社に開発をお願いしています。
私自身は入社から2年ほどはメンバーとしてコードを書いていましたが、第二新卒の方のメンターの経験等を経て、現在はテックリードとしてバックエンド全体を見ています。またテクニカルマネジメントの他に、メンバーとの1on1など一部ピープルマネジメントも担当しています。業務範囲が広がる中でコード以外のことを考える機会も増えましたが、コードを書かずにいるとエンジニアとしての直感が鈍ると考えているので合間を縫ってコードも書いています。また開発はもちろんのこと、企画チームとのコミュニケーションやJMDCが保有する個人情報、健康診断データ、レセプト（※）データを扱うチームとの調整や、それら基幹データとの連携部分の開発などにも携わっています
※レセプトとは、医療機関が保険者に提出する月ごとの診療報酬明細書のこと。
▼Pep Upの立ち上げからグロースまでの軌跡についての記事もございますので、ぜひご覧ください。
――Pep Upの開発で使っている言語や技術について教えていただけますか。
Pep Upは2015年に生まれたRails製のモノリシックなアプリケーションです。近年開発している機能ではGraphQL Rubyを導入し、スキーマをフロントエンドとの責任分界点として開発するなどモダンなスタックも取り入れています。技術選定のスタンスとしては、最新技術に飛びつくのではなく、自分たちの課題を解決してくれる技術を取り入れることを重視しています。
――Pep Upの開発ならではのポイント・特徴はどんなところでしょうか。
レセプトのデータや健康診断のデータ、健保様からお預かりしている個人情報を、当社の基幹システムに格納しています。これはクラウドではなくオンプレミスのデータセンターで保有しています。そのデータの中からPep Upで利用可能となった使えるデータをAWSヘ連携するワークロードがあるのですが、そこは面白いところですね。
オンプレミスにあるNetezzaというデータウェアハウスに、データが格納されています。そこから必要なデータを抽出してCSVにし、Pep UpのAmazon S3にアップロードして置いています。さらにデータベースへのロードをAWS Glueでやっています。
この時に気を付けなければいけないのが、扱うデータが要配慮個人情報を含む個人情報であるということです。ネットワークの経路が適切か、不必要なデータをアップロードしていないかなど、インフラ面からもアプリケーション面からもセキュリティを強く意識したワークロードとなっています。
また、BtoBtoCのサービスである点も特徴ではないでしょうか。Pep Upにはユーザーが使う画面と、JMDCのカスタマーサクセスが使う画面、健保様が使う画面があります。これだけでも複雑ですが、さらに保健指導の仕組みも持っており、その指導員が使う画面もあるのです。カスタマーサクセス、健保様、指導員は個人情報を扱うので、IP制限をかけて特定の場所でしかアクセスできないようにするなど、セキュリティ面を意識しています。同時に、カスタマーサクセスの業務としては個人情報を扱わないものもあり、それらの業務では利便性を優先して制限を緩和しています。セキュリティと利便性のバランスをとって権限を設計するのはおもしろくもあり、難しいポイントでもあります。
――そのなかでも近年、特に注力している開発はどういった部分でしょうか。
ユーザー体験（UX）向上に寄与する施策や健保様のDX化を進める施策です。
前者の例の一つとして、「ウォーキングラリー」というイベントをPep Up内で開催しています。歩数目標を達成するとポイントがもらえたり、チーム対抗で上位になるとポイントがもらえたりします。歩くことを楽しくすることでより歩いてもらい、より健康になるための行動変容を目指す取り組みです。
後者の例としては、従来紙で行っていたユーザーから健保様への申請がWebでできる機能です。健保様の事務作業のコスト削減・効率化に貢献しています。
またパフォーマンスの改善にも取り組んでいます。ローンチして7年が経ち、大型の健保様にも導入いただけるようになりサービスがスケールした結果、パフォーマンスの問題が顕在化しました。Pep Upはこれからもスケールしていくアプリケーションなので、さらなるスケールに耐えられるようアーキテクチャの見直しなどを行なっているところです。
――そうすると、マイクロサービスアーキテクチャへのリプレイスなども視野に入れているのでしょうか。
マイクロサービスアーキテクチャへのリプレイスは一時期検討していましたが、現状の課題を解決するにはオーバーエンジニアリングと判断し、現時点でのリプレイスは考えていません。
モノリスを中心に、モノリスの周辺に必要に応じてアウトポストを配置するシタデルアーキテクチャの考え方でパフォーマンス問題への対応を行っています。
非同期処理のバックエンドとしてRailsではデファクトスタンダードであるSidekiqを利用していますが、一つのジョブが長時間実行している時にデプロイするとジョブが最初からやり直しになる問題がありました。サービスのスケールにつれて特定のジョブが長時間実行されるようになりデプロイへの影響が無視できなくなったので、解決策としてAWS Fargate上でメインの処理を実行するよう変更し問題を解決することができました。
またメールサービスをMailchimpからSendGridへ移行しています。メールの開封などのイベントをWebhookで収集する必要があるのですが、スケール後の移行なので最初から莫大なリクエスト数となることが予想されました。そのためイベントはAmazon S3に保存することに決定し、Amazon API Gateway、AWS Lambda、Amazon Kinesis を利用したサーバーレスアーキテクチャにて構築しました。構築当初からユーザー数は増加し続けていますが、特に問題は起きていません。
――技術選定のポイントはどういったところに置いているのでしょうか。
現状の課題を解決するために適切な技術を取り入れることを意識しています。その上で、メンバーは自由に技術選定や提案ができる環境です。
最先端の技術に飛びつくというよりは、コミュニティである程度知見が溜まった技術を導入するスタンスです。
エンジニアは課題解決が仕事なので技術を取り入れることそのものを目的にするのではなく、課題解決ができる技術を選定することを大切に考えています。。目的と手段を取り違えることなく、自分たちの課題を解決してくれる技術を的確に取り入れる。これを当たり前に大事にしている人が多いです。そういう意味で健全な開発文化だと思います。
4月からスクラムを導入
――2022年4月から、スクラムでの開発をスタートしたと伺いました。
そうですね。コロナ禍でリモートワークになって2年経ち、コミュニケーション不足が課題でした。開発チーム周辺の体制変更もあり、2022年4月からスクラムのプラクティスを取り入れた開発を導入しています。デイリースクラムによってコミュニケーションの機会が補完されたと感じています。
また個人的には、スクラムで開発の型ができたことで、以前よりチームとして開発できていてスケールしやすい体制になっているなと感じています。以前はどうしても古参のエンジニアに業務が集中することがありましたが、スクラムで開発することによってチームで分散できるようになりました。スプリントレビューが十分に開催されてないなどまだまだ改善できることもあるので、レトロスペクティブを行い改善を積み重ねチームの練度をあげていきたいです。
――パフォーマンス改善のための改修にも注力していると仰っていましたが、機能開発と技術的負債解消のバランスについても、スクラムで決められているのでしょうか。
そうですね。それぞれ何％という基準がしっかり決まっているわけではありませんが、スプリントプランニングで話し合って決めています。パフォーマンスが出ないと最終的にはビジネスに影響が出るわけなので、理由が明らかになっていれば改修に時間をかけることも理解されますし、機能開発が何がなんでも優先のような体制ではありません。皆で今ある課題とバランスを考えることで、納得した判断ができています。
開発チームの雰囲気
――テックな印象を抱いて入社された野田さんですが、実際に入社されて開発チームの雰囲気について改めてどんなことを感じましたか。
基本的に皆さん温和な方が多くて、仲がいいと感じています。部長の小原さんが音頭を取って食事に誘ってくれたり、先日はチームビルディングの一環として部署でバーベキューを開催しました。そのバーベキューを楽しみにしているメンバーも多かったです。そういう意味では、エンジニアおよびユーザープラットフォーム開発部のメンバーは関係性が良好で、仕事もしやすい人が多いと思います。
また、技術的にはやはり「強い」エンジニアが多くて刺激になっています。フロントエンドのテックリードの八杉さんと同じプロジェクトになったときに、スキルが高い方だと単純に驚きましたし、部長の小原さんもピープルマネジメントやプロダクトマネジメントが非常に強く、日々すごいと思いながら働いています。そういう人たちと開発できる心強さと、自分の学びにもなるところは、Pep Upの開発チームのいいところですね。
▼部長の小原さんとフロントエンドのテックリード、八杉さんの記事もございますので、ぜひご覧ください。
――野田さんが感じている、JMDCにおける開発の面白さややりがいを教えてください。
エンジニア的な面白みでいうとパフォーマンス改善です。パフォーマンス改善はある程度スケールしないと取り組めない課題で、数億件オーダーのデータを扱うからこそ発生する問題に相対できるのは面白いです。エンジニアリング的に解決して、ユーザーが使いやすいシステムにしていくやりがいがあると思います。
また、現在取り組んでいる最中ですが、これまでバックエンドは個人の力に頼ってきたところが大きく、チーム力で課題解決できる仕組みを整備する必要があります。コードレビューのガイドラインをしっかり作る、コードメトリクスを計測し技術的負債を可視化するといった、足回りを整えるのも面白いと感じています。そういう問題意識をもって向き合えることは面白いですね。
それから組織文化的なことですと、エンジニアの裁量が大きく割と自由にやらせてもらえる印象があります。具体的な仕様の決定は企画メンバーと話す必要がありますが、意見を無碍にされることはないですし、場合によっては要件を決めるところから入れるのでそこも面白いポイントかなと思います。
先ほどもお話したように、技術選定も自由に提案できるので、社内の標準化基盤やリーダーが決めたアーキテクチャに従わなければいけないことはありません。各エンジニアがオーナーシップを持ち、「こういうアーキテクチャがいいのでは」と考え、詳しいメンバーにフィードバックをもらいながら、最後まで責任を持って作る。そういう一連のフローを経験できるのは働く魅力かもしれないですね。
――メンバーが提案したことを受け止める場やコミュニケーションも保障されているイメージでしょうか。
そうですね。バックエンドもフロントエンドもそれぞれ週次で定例ミーティングを開催していて、設計実装方針のざっくばらんな相談を行っています。またファンクションを横断する技術トピックについて議題があればミーティングを開催してアーキテクチャの相談・議論を行っています。先ほどの通り、みんなコミュニケーションがとりやすく、否定する方もいないので、やりやすいです。
――最後に、今後のPep Upのバックエンドが取り組んでいく目標や展望を教えてください。
一つは、先ほどからお話ししているパフォーマンス改善のための取り組みです。スケールする前に作ったコード・アーキテクチャを改修して、スケールできるように変えていきます。
二つ目に、今まで個人の力に頼ってやってきたのでチーム力でやっていく仕組みを作っていきたいです。Pep Up特有のドメイン知識を記したコーディングガイドラインを策定し、日が浅いメンバーも素早くキャッチアップできる体制を整えていきます。
三つ目に、先述した保健指導事業とPep Up事業は、現在ビジネス的には分かれているのですが、コードベース上は同居している状態です。マイクロサービスまではいきませんがサービスを分割してそれぞれ独立してデプロイできるアーキテクチャにしていきたいです。
最後までご覧いただきありがとうございました。
もし少しでも弊社にご興味をお持ちいただけましたら、こちらの採用ピッチ資料をぜひ一度ご覧ください。
