Sign up for free

This page is intended for users in Japan(English). Go to the page for users in United States.

Linc'well を支える技術

こんにちは。Linc'wellでエンジニアをしている関と申します。最近の趣味はどうぶつの森です。

この記事ではLinc'wellに興味をもっていただけたエンジニアの方のために、Linc'wellが使っている技術をお伝えします。

また、それだけでは面白くないので個々のプロダクトの概要と、どんな用途にその技術を使っているのか、今後の展望などについても解説してみます。スキルセットや技術に対する Will が合うかもそうですし、我々の技術に対する価値観などもお伝えできれば幸いです。

どんな技術を使っているか

はじめに、全体像をパッとお伝えするために採用資料とかでよくある技術のアイコン表をのっけてみます。



使っている技術に関してはこの表の通りなのですが、具体的にどんな用途に使っているのかがイメージできなかったり、最近のフロントエンドな方はjQueryのアイコンを見て警戒しているかもしれません。

よくこういった採用資料ではちょっとした用途に使っているだけでもアイコンを載せてしまう採用資料技術アイコン詐欺が横行するものですが、それで期待値のミスマッチが起きてはいけません。

なので、どんなプロダクトがあって、それぞれでどんな技術をどんな用途に使っているかを書いていこうと思います。

Linc'well は小さい会社ながらもプロダクトの数は多く、次のようなものを開発しています。

  • CLINIC FOR 予約システム
  • CLINIC FOR YOU
  • Sui+ & sai+

その他にも iPad の問診アプリ、LINEからの予約サービスなどなど色んなものがあります。

それでは、それぞれのプロダクトでどんな技術をどうやって使っているのか紹介していきます。

CLINIC FOR 予約システム

https://reservation.clinicfor.life/select_clinic


Linc'wellがプロデュースするクリニックのCLINIC FORのための予約システムです。

患者さんに予約を取ったり問診を入力していただくための画面と、クリニックの医療事務さんに受付管理をしていただくための画面があります。

このプロダクトは Ruby on Rails と フロントエンドは Slim というテンプレートエンジンと Coffeescript で作られています。

また、後述するプロダクトも全て同じくですがインフラはAWS上に構築されています。一部OCRなどの活用でGCPを使っていたりもしますが、基本的にはAWSです。

基本的にはRailsベースで開発されてきましたが、近々フロントエンド部分をReactに乗り換えるプロジェクトを実施予定です。ちなみにこちらを移行する目的としては、このWebシステムとは別にモバイルアプリを開発したためバックエンドのAPI とフロントエンドを分離することが都合がいいこと & Web予約システム側のフロントエンドの開発効率を上げることです。

LINE bot

またクリニックの予約ですがLINEからも行うことができます。


Web 版と比較して大分ライトに予約を取ったり、変更したりができるようになっています。

オンライン診療

また、つい最近ですが、オンライン診療を行うための機能も加わりました。

こちらは基本的に上述の技術スタック(Rails)で組まれていて、ビデオチャットの部分は tokbox という WebRTC のサービスを使って作られています。

Clinic For You

前述の予約システムのモバイルアプリ版です。近日リリース予定です!

Web版同様に予約ができるなどもそうですが、クレジットカードを登録しておけば受診した時に後払いできるようにしたり、お薬手帳として使えたり、将来的には血液検査の結果が見られるようになるなどモバイルアプリ独自の機能も追加していく予定です。

このアプリケーションはフロントエンドは Capacitor + Ionic + React の構成で作られていて、バックエンドは graphql-ruby の GraphQL API として作られています。

結構珍しい採用だと思うので補足しておくと、 Capacitor + Ionic は Web based な技術でアプリを開発できる hybrid app platform です。要するにWebの技術で一度コードを書けば Android や iOS で動くアプリがビルドできるようになるもので、ionic 自身も Write once, run anywhere
を謳っています。 React Native や Flutter などとどう違うのかという話ですが、これらは Native Cross platoform に分類され、実際に iOS や Android のランタイムで動くのに対し、hybrid では WebView を使って動きます。

それだけ聞くと「Native Cross platform の方が速そうだし、ネイティブ固有の機能に制限なさそう…」と感じますが、主なメリットとしては次のようなものです。

Web のものとしてもビルドが容易なため
-
開発も Web と変わらない体験でできるため DX (というよりは環境構築が楽?)が良い
- Webの技術に多少慣れている人なら開発に参画しやすい
- Web版とコードの共有ができる

  • Native Cross と違うのは Web のものと全く同じコードを使って書けることです
    • 今回のケースだとすでに Web の予約システムがあり、ユースケースが同じなUIがいくつか存在するので、それらに対しては明確なメリットとなります
    • (焦って共通化してもかえって開発遅くなったり負債化するので一概にメリットとは言いづらいですが…)

とまあWebも含めたクロスプラットフォーム開発できるというのは魅力ですが、やはり冒険的な選択だとは思うので、開発していく中での辛みとか制約の知見が溜まったら発信していきたいなとは思います。実際マイナーな技術なのでリソースが少なくてすでに辛かった経験ちょいちょいあります。

バックエンドは graphql-ruby を使った GraphQL サーバーになっています。なぜGraphQLなのか、その魅力を語ろうとするとそれだけで一つの記事になるので控えますが、スキーマ定義が柔軟になったり、エコシステムが整っている(主にスキーマ駆動の型定義、キャッシュ、useFetch系の自動生成あたりが好きです)ことからフロントエンドのDXの改善は如実に感じています。

こちらのAPIが動く時に参照しているDBはWeb版のものと一緒で Rails の Active Record を通してアクセスしているわけですが、今は Web版のController は別で存在しているので、徐々にこちらの GraphQL API に一本化していく予定です。

Sui+ & sai+

医療の一歩手前に医学の知識を取り入れることによって、自分の体をコントロールし(我々はこれをアクティブコントロールと表現しています)。また、一部商品は医薬品であり医師の処方が必要であるためオンライン診療のシステムも開発しています。

https://sui.clinicfor.life/

https://sai.clinicfor.life/

フロントエンドは Next.js + TS で動いていて、SSRではなくSSGを使っています。
FMPの向上をしたかったので事前にレンダリングする手法を取りたく、ただECという性質上SSR用のプロセスを用意するメリットがないためSSGとして作りました。

また、こちら予定としては Golang + gqlgen の GraphQL API と Next.js で開発していく予定だったのですが、いろいろあってブランドサイトの静的な部分だけ Next.js で開発して、機能面は EC Force というサービスで動かしています。いろいろの部分は余裕と社内の許可が降りたらまた別途書こうかなと思います。なので結果的には結構贅沢な作りになってしまった感はあります。

今後オンライン診療の体験向上がキーとなった時に改めて作り込むときが来るかもしれない、来ないかもしれない。そんな感じです。

おわりに

駆け足でしたがLinc'wellが使っている技術について紹介しました。
正直ビジネス的にはシステムのスケーラビリティが必要ないし(今のところ物理的なクリニックが主なので)、技術的な課題が大きいわけではないのでエッジの効いた技術を積極的に採用する理由はないのですが、ある程度遊びも忘れずに選ベているのかなと思います。

それでは、お読みいただきありがとうございました。

株式会社Linc'well (リンクウェル)'s job postings
4 Likes
4 Likes

Weekly ranking

Show other rankings
If this story triggered your interest, go ahead and visit them to learn more