Rails+ReactでSPAなシステムを構築。ヘルスケア・スタートアップを支える技術スタック

ヘルスケア・スタートアップのLinc'well（リンクウェル ）は、ITによってヘルスケア領域を発展させることを目指しています。テクノロジーによりヘルスケアを変革するだけではなく、医療機関の利便性向上などあらゆる人にとっての医療体験の改善も行います。

そんなLinc'wellでは、開発効率向上やサービスの品質向上のため、採用する技術スタックも工夫しています。今回は技術の詳細について、オンライン診療のサービス開発を担当するテックリードの岡野雄起とフロントエンドエンジニアの名取龍一、バックエンドエンジニアの志田和也に語ってもらいました。

テックリード　岡野 雄起（写真右）
前職ではWebマーケティングコンサルティング企業で新規プロダクトの立ち上げを経験。1年ほどフリーランスエンジニアとして働いた後、「社会のインフラになれるサービスを開発したい」「自分たちの力で会社を大きくしていく経験をしたい」との思いからLinc’wellに参画。現在はリードエンジニアとして、主にオンライン診療のサービス開発に関わる。

フロントエンドエンジニア　名取 龍一（写真左）
東京大学を卒業後、数社のスタートアップでフルスタックのWebエンジニアとして勤務。その後フリーランスとしてFinTechのベンチャーに参画。医療ドメインから社会に貢献したいという思いがあり、2020年に Linc’well にジョイン。現在はオンライン診療のフロントエンドを担当している。

バックエンドエンジニア　志田 和也（写真中央）
前職では、保育園向けのICTシステム会社で、iOSアプリ開発やAI系の研究開発に携わる。2020年5月に Linc'well に参画。現在は、バックエンドエンジニアとしてオンライン診療のサービス開発に関わる。

Ruby on Rails + React + AWSによりサービスを提供

――Linc'wellで採用しているバックエンド、フロントエンドの技術は何でしょうか？

岡野：各アプリケーションのバックエンド開発はRuby on Railsで統一しています。将来的に各機能をマイクロサービスとして切り出すフェーズが来ればGo言語の導入なども検討するかもしれませんが、現時点ではサービスや開発組織の規模がそれほど大きくないため、当面はマイクロサービス化などを行わずに開発を進めていく方針です。そのため、他の言語を採用する利点よりも、Ruby on Railsで統一して開発生産性を高め、学習コストを抑える利点のほうが大きいと考えています。

名取：フロントエンドはReactを採用しています。リポジトリの構成として、フロントエンドのモジュールもRuby on Rails内に同居させているリポジトリと、フロントエンドのモジュールを単独で切り出しているリポジトリが混在している状態ですね。

私たち3人が担当しているオンライン診療*というサービスは、後者を採用してSPAな設計にしています。今後は順次、各サービスにおけるバックエンド・フロントエンドのリポジトリを分けていく予定です。オンライン診療では、バックエンド側でGraphQLのエンドポイントを立てており、フロントエンドからApollo経由で情報のやりとりをしています。

*…Linc'wellは、スマートフォンやPCを使ってリモートで予約から受診まですべてが完結するオンライン診療サービスを提供しています。ユーザーは受診後に各種決済方法で支払いを行い、最寄りの薬局または宅配で薬を受け取ることが可能。外出をしなくても、自宅に居ながら医師の診療を受けられます。

――SPAの設計やGraphQLを採用している理由について教えてください。

岡野：オンライン診療は、滑らかなUI・UXを提供することでなるべく多くのユーザーに利用してもらえるサービスにしたいと考え、SPAな設計にしました。

また、GraphQLの導入はAPI開発の効率化やAPIでやりとりするデータの適正化が目的です。バックエンドの技術としてGraphQLを採用したのは2年ほど前なのですが、その頃からWebアプリやLINEミニアプリなど複数のプラットフォームで各種サービスの展開を構想していたため、同一のエンドポイントで複数パターンの用途に使えるGraphQLが適していると考えました。

名取：Reactによる状態管理の仕組みとしては、オンライン診療を含むほとんどのサービスでReact Hooksを用いています。それに加えて、Apolloを使用していることからapollo-link-stateを採用しており、これによってリモート（API）のデータとアプリケーションのローカルステートの両方を管理しています。これらの技術によりサービスで必要な状態管理のユースケースを満たしているため、Reduxは採用していません。

――次はインフラ環境についても伺いたいです。

岡野：インフラはAWSを利用しています。もともと、最初期のフェーズはクラウドベースのPaaSであるHerokuを使っていましたが、医療ドメインを扱うにあたり「医療情報システムの安全管理に関するガイドライン*」を遵守する必要が生じ、Herokuではその要件に柔軟に対応することが難しいとわかりました。そこで、セキュリティ要件のレギュレーションが既に存在していて、かつ提供されているマネージドサービスも豊富なAWSを使うことに決めました。

*…厚生労働省が発表するガイドライン。医療機関等において実装すべきセキュリティ対策や、医療情報の処理や保管を外部の事業者に委託する場合の責任分界に関する考え方などが記載されている。

志田：WebサーバーはAmazon ECS（on EC2）を、データベースはAmazon RDS（Amazon AuroraのPostgreSQL）を採用しています。基本に忠実な構成にしていますね。また、Linc'wellのサービス本体とは別に、外部の検査会社からAmazon S3経由でデータを受け取っており、それをAWS Lambdaで加工したうえでデータベースに格納する仕組みがあります。

岡野：フロントエンド側のデプロイは、静的なファイルを生成した後にそれをAmazon S3にアップロードして、Amazon CloudFrontと連携させて配信しています。他にはメトリクスやログ確認のためにAmazon CloudWatchを、認証系のためにAmazon Cognitoを採用しています。

日々、改善を続ける開発体制

――より良い開発環境にするために工夫していることはありますか？

岡野：各開発チームがより働きやすい環境にするため、日々地道な改善を続けています。例えば過去には、ソースコードレビューの改善をしました。かつて、レビューをする役割が私に集中しており、属人化している時期がありました。レビューの負荷分散や開発チーム内での知識共有のために、なるべく全員がレビューに携わる仕組みが必要だと考えました。そこで、ソースコードレビューを全体的に整備することにしました。

まずは、レビューのガイドラインを設けて全員の認識を合わせました。レビューのガイドラインの中には「mustなルール（必ず守らなければならないルール）」「shouldなルール（守ってほしいが、個々の判断に任せるルール）」「nice to haveなルール（できたらやろうというルール）」など各種のルールを記載しています。レビューの際に何を注視すべきか、どのような内容のコメントをするかなどを各人が判断しやすくしました。

コードレビュールールの一部を抜粋。レビューにおいて、各エンジニアに心がけてほしいことを記載している。

名取：それから、ソースコードレビューの負荷が特定のメンバーに偏ってしまうことを避けるため、レビューを不特定の誰かに依頼するためのPlease Revue BotというSlack Botを作りました。Botの投稿を見た誰かが自発的にレビューするようになり、負荷分散した運用が徐々にできるようになりました。

――そうした仕組み作りは大切ですね。確かに、特定メンバーだけソースコードレビューの負担が大きくなってしまう、という課題は多くの開発チームが抱えています。

岡野：名取さんが仕組みを整備してくれてから、私にかかっていたレビューの負荷が徐々に軽減されました。ピーク時には常時10本くらいのレビューを抱えていたのですが、あるタイミングで1年ぶりくらいに自分が担当するレビューを完全に消化できました。「これがチームとして仕事をするということか！」と感動しましたね。

名取さんは技術面、組織運営面の両軸で、Linc'wellの開発体制をより良くするための試みを続けてくれています。例えばフロントエンドの技術などに関しても「こういう状態になるのが理想だ」という明確なビジョンを持っており、その方向性になるべく近づけるために技術的な改善をリードしています。

志田：チームにスクラム開発を導入したのも名取さんですね。

岡野：名取さんは過去にスタートアップで働くことを経験しているので、企業や組織の体制を整備していくスキルがとても高いです。たとえ、改善前の環境やチームメンバーに至らない点があっても、優しく微笑んで一緒に改善策を考えてくれて、本当に助かっています。

技術的な知識をキャッチアップするために

――技術情報を得るために利用しているサービスや、参照している情報はありますか？

志田：まず社内の取り組みから話すと、名取さんが各種技術系サイトのフィードが流れるSlackチャンネルを作ってくれています。このチャンネルを起点に情報収集することが多いです。

名取が作成したSlackチャンネル。

岡野：それから、週に1回とか2週に1回くらいのペースで、技術的トピックについて開発メンバー同士でゆるく話す会を設けています。それも名取さん発案だったかな。（取材日の）2～3か月前くらいからやり始めて、徐々に参加人数が増えてきました。

――例えば過去の会ではどのような話題が？

岡野：チーム内で採用して成果が出た技術や今後導入したい技術、最近流行っている技術についてエンジニア同士で話しました。また、開発チームのメンバーに、これまでのキャリアで経験してきたことを共有してもらったこともあります。この会があることで、開発組織の技術力の底上げや、メンバー同士の理解を深めることにつながっているので、すごく良い機会だと思っていますね。

志田：それから個人的にやっていることとしては、技術情報をインプットするために各種技術カンファレンスの動画をよく見ています。例えば、Developers Summit*のセッションを視聴してAWSの新しいマネージドサービスの情報を仕入れたり、各社の導入事例を学ぶことで「自分たちのサービスにもこの技術を取り入れられるかも」とアイデアを得たり。

*…翔泳社主催のソフトウェア開発者向けカンファレンス。著名な開発者が多数登壇し、最新技術の知見や各社の事例などを語る。

それから、各種プログラミング言語やライブラリ、AWSのマネージドサービスの正確な情報を仕入れたい場合には、なるべく公式ドキュメントを参照しています。

岡野：なんだかんだ、公式ドキュメントが最強ですよね。他に個人的にやっていることとしては、著名エンジニアの方々のTwitterアカウントをフォローするくらいですかね。

名取：自分もそうですね。そういったエンジニアの方々はかなり質の高い投稿をしていることが多いので、私もTwitterから得られる情報は大切にしています。

エンジニアに裁量が与えられており、積極的にチャレンジできる環境

――今後、取り組みたい技術的なチャレンジはありますか？

岡野：WebサーバーをAmazon ECS（on EC2）からAmazon ECS（on Fargate）に変えたいです。今はAmazon EC2上に複数のコンテナが乗っている状態なので、AWS Fargateでリソースを分けたいのと、インフラ管理にかかる運用コストを下げたいです。インフラ作業のための工数が割けていないので、時間ができ次第に取り組もうと思っています。

志田：他には、ログや各種データの集計・分析などをより便利に行うための基盤を構築したいです。まずは汎用性高くデータを利用できる環境を作って、必要なときにそれらを活用できる状態にしておきたい。今後、ユーザー数や提携しているクリニックの数も増えていくでしょうから、データ量はもっと多くなります。それらのデータを活用してサービスの価値をさらに向上させられれば、エンジニアリングとしても面白味が増していくはずです。

名取：先日、私が主導してUIコンポーネント開発用のツールであるStorybookを新しく導入しました。現在、エンジニアチーム内だけでStorybookの情報を共有している状態なので、今後さらに仕組みを整備して、デザイナーやプロダクトマネージャー、医師など各ステークホルダーがレビューできる体制にしていくと、多角的な視点を得られやすくなり、プロダクトの質が向上するだろうと考えています。

岡野：それから、私たちのサービスではCapacitorという、Webアプリをクロスプラットフォーム向けに提供するためのフレームワークを用いていますが、iOSアプリやAndroidアプリとしての機能をまだ提供していません。現在は、ネイティブアプリとしてユーザーに使ってもらう利点がなく、Webアプリとしての用途で十分だからです。

ですが、ネイティブアプリとして使う利点もうまく取り入れてリリースできると、ワンソースでクロスプラットフォームなサービスを開発できるので、ユーザーに提供できる価値がより大きくなるだろうと思っています。せっかく、クロスプラットフォーム化できるベースがあるわけですから、有効活用したいです。

――開発組織として今後変えていきたいことはありますか？

名取：エンジニアの採用も、バックエンドを担当するチームとフロントエンドを担当するチームとで、明確に分けようとしています。

岡野：現在は、各エンジニアがバックエンド・フロントエンドの両方をフルスタックでやっていることが多いのですが、複数の技術領域ができる人だけを採用するのはかなりハードルが高いです。人材を確保し組織を拡大するうえで、エンジニアの役割を分けることが大切だと思っています。

名取：その体制を実現するうえでも、インタビューの前半で述べたように、各サービスのフロントエンドとバックエンドのソースコードを完全に分離することは大切ですね。

――Linc'wellにおける開発組織の雰囲気や技術選定の考え方が、中で働くエンジニアに与えるプラスの影響とは何だと思われますか？

岡野：最近は徐々に、各エンジニアが個人的に何かを学ぶだけではなく、チームとしてスキルを研鑽する取り組みができています。先ほどお話しした、技術トピックについてゆるく話す会などはその好例ですね。そうした環境作りができていることはエンジニアのキャリアにとって間違いなくプラスなので、その流れを今後も加速させていきたいです。

志田：それから、各エンジニアに裁量が与えられており、積極的に新しい技術にチャレンジできるという利点もあります。React + Ruby on Railsという組み合わせは今後も大きく変わることはないと思いますが、それ以外には特に制約がなく、各チームに技術選択の方針が委ねられています。自由な環境の中で、サービスをより良くするためのチャレンジがやりやすいのは、すごく良い点だと思いますね。

――技術選択の妥当性さえあれば、個人の意思が尊重されるということですね。

名取：例えば、自分がStorybookを導入して運用方法を考えたことなどは典型的な例だと思います。Linc'wellのようなスタートアップの場合、ゼロの状態のものをイチにする経験をたくさん積めますし、そこから得た知見は確実にエンジニアの力になります。そういった経験をしたエンジニアは間違いなく他の企業でも重宝されるので、Linc'wellでのキャリアはきっとエンジニアにとってプラスになるはずです。

＜Linc'wellはともに働く仲間を募集しています＞
https://engineer.linc-well.com/