Medley Developer Blog

株式会社メドレーのエンジニア・デザイナーによるブログです

ElastiCache for Redis 運用小話 〜メドレー・TechLunch〜

こんにちは、開発本部の後藤です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。

ジョブメドレーでは各種キャッシュや sidekiq のqueue等にElastiCache for Redisを利用しています。

先日、メドレーで定期開催している社内勉強会TechLunchにて、ジョブメドレーでのElastiCache for Redisの運用周りのネタや知見について発表しました。本記事では、その中から抜粋してメモリ周りの話について紹介します。

キー削除周りの仕様について

キャッシュとしてElastiCache for Redisを利用していく上でまず把握しておきたいのが、キーの削除周りの仕様です。

Redis本家のExpiration/Eviction

ExpirationについてはRedisではキーにTTLを設定することで有効期限を設定することができ、こちら に記載のロジックで削除処理を実施してくれます。

Evictionについては Redis本家の実装では以下のような仕様になっています。Redis本家ドキュメントはこちら

  • used_memory(アプリが利用しているメモリ量)がmaxmemory値を超え始めたらEvictionが発火し始める
    • maxmemoryredis.conf 指定か CONFIG SETコマンドで設定できる
  • maxmemoryに到達したらどのように振る舞うべきかをmaxmemory-policyで指定
    • noeviction: 容量が必要なオペレーションではevitせず、エラーとなる
    • allkeys-lru: 常にLRUアルゴリズムで削除対象選定
    • volatile-lru: TTLが設定されたキー内でLRUアルゴリズムで削除対象選定
    • allkeys-random: 常にランダムに削除対象選定して削除
    • volatile-random: TTLが設定されたキー内でランダムに削除対象選定
    • volatile-ttl: TTLが設定されたキー内でTTL

また、ElastiCache for Redis ではまだ3系列までしか使えませんが、4系列では新たにLFUも選択肢に入ってくるようです。

Redis本家のEvictionの動作仕様としては以下のイメージです。

https://github.com/antirez/redis/blob/3.2.10/src/server.c#L3343-L3357

ElastiCache for Redis ではmaxmemoryは編集できず、その代わりに後述する reserved-memoryreserved-memory-percent)を設定するとEvictionが発火するメモリ量の閾値が変わることから上記周りの実装はAWS側で手を入れていそうです。

ElastiCache for Redis でのEviction

ElastiCache for Redis では以下のようにRedis本家にはないreserved-memoryという概念があるので注意が必要です。

  • maxmemoryインスタンスタイプによって固定値に設定されている
  • maxmemory変更できない
    • 代わりに reserved-memory or reserved-memory-percent を設定してEviction発火メモリ量を設定できる
    • maxmemory - reserved-memory < used_memory でEvictionが発火する
  • 古めのインスタンス(2017年3月16日以前作成)では reserved-memory がパラメータとして利用できるが、reserved-memory のデフォルト値は0byte
    • reserved-memory-percent のデフォルト値は25%
  • この周辺のAWS公式ドキュメントはこちら

ジョブメドレーでは単一のElastiCache for Redisインスタンスで運用対象を減らす戦略を取っています(Redis本家では用途別に分けて適切にチューニングすることを推奨しているため、将来的にはこの構成は変わるかもしれません)。そのため、キャッシュ利用のキーには必ずTTLを設定し、Eviction policyはvolatile-lruとしています。 そして、少し余裕をもたせて reserved-memory を設定、Evictions メトリクスの監視をしています。

メモリ利用量をSQLで分析する

現在稼働している本番環境上でどのパターンのキーがどの程度のメモリを使っているかを把握したくなる場面に出くわした方もいらっしゃるのではないでしょうか。

ElastiCache for Redis では簡単にRDBスナップショットを取得することができます。このデータをうまく使えば直接本番稼動のインスタンスを触りにいくことなく、手元で安心して分析作業が実施できます。

この分析作業に便利なのが redis-rdb-tools です。このツールはRDBファイルの内容をもとにキーごとのbyte値を以下のようなCSVに出力することができます(size_in_bytesは理論値)。

$ rdb -c memory dump.rdb > memory.csv;
$ cat memory.csv

database,type,key,size_in_bytes,encoding,num_elements,len_largest_element
0,list,lizards,241,quicklist,5,19
2,hash,baloon,138,ziplist,3,11

このcsvを以下のようにSQLite等のデータベースに突っ込むことで手元でSQLを使ってメモリ統計の分析ができるようになります。

$ rdb -c memory dump.rdb > memory.csv;
$ sqlite3 memory.db
sqlite> create table memory(database int,type varchar(128),key varchar(128),size_in_bytes int,encoding varchar(128),num_elements int,len_largest_element varchar(128));
sqlite>.mode csv memory
sqlite>.import memory.csv memory

ざっくりとした分析の流れは

  1. 本番環境のdaily backup RDB取得
  2. redis-rdb-toolscsv出力
  3. csvsqlitecsv formatでimport
  4. SQLで分析

のようになります。データベースにインポートさえ出来てしまえば以下のように様々な分析が可能になります。

sqlite> select sum(size_in_bytes) from memory where key like '%cells%';
XXXXX
sqlite> select count(*) from memory where key like '%cells%';
XXXXX

注意点としては実際に本番稼動しているメモリ量を取得しているわけではないので実測値と値がずれてくることです(感覚的には理論値は実測値の1/2ぐらいでした)。こちらの詳細の推定ロジックが気になる方は実装を確認いただければと思います。

ジョブメドレーではこの手法を使って分析することでアプリロジックを修正して不要なメモリ利用の改善等に役立てています。

まとめ

ElastiCache for Redis のメモリ周りを中心とした運用ネタについて紹介しました。

ElastiCache for Redis はとても便利でシュッと設定してそれなりの規模でもなんとなく運用できてしまう手軽さがありますが、油断していると思わぬ落とし穴にはまることもあります。

本記事がみなさまのElastiCache for Redis運用ライフの一助になれば幸いです。

また、ジョブメドレーをはじめ、メドレーの開発にご興味ある方は、ぜひご連絡ください。 www.medley.jp

メドレーがLTスポンサーを務めるRubyKaigi2018にもお邪魔する予定(たまにブースに立っています)ので、そちらでもお会いしましょう。 rubykaigi.org

電子カルテシステム開発の難しさを解決するためのフルマネージドサービスの活用

4月末に新たにリリースしたクラウド電子カルテCLINICSカルテ」の開発を担当している田中です。

電子カルテという医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしています。前回はCLINICSカルテのデザインについてマエダが紹介しましたが、今回はエンジニアから見た苦悩と葛藤についてお話します。

苦労した点としては、医療事務の業務そのものの複雑さやそれに伴うアプリケーション開発の複雑さはもちろんのこと、電子カルテ開発の特徴として関連省庁のガイドラインの準拠やレセプトソフト(医療会計専用のシステム)のシステム管理など、多岐にわたり対応が必要なことが挙げられます。

ガイドラインへの対応に関するお話は細かくなってしまうので、大まかな内容として、今回は主にレセプトシステムとして連携しているORCAのシステム管理方法についてお伝えさせていただければと思います(ORCAに関する説明は後述します)。

ガイドラインへの対応

電子カルテのように医療情報を扱う際に遵守する必要があるガイドラインとして3省4ガイドライン厚生労働省経済産業省総務省の3省が出している4つのガイドライン)があります。

CLINICSカルテの開発を進めるにあたり、このガイドラインがシステム設計や運用に大きな影響を及ぼすため、まずはガイドラインを読み込み整理するところから始めました。

システム、アプリケーションともに対応すべきことは多かったのですが、システム構成に特に影響が大きかったのは以下の2点となります。

  • サービス提供に用いるシステム、アプリケーションを日本国内法の適用が及ぶ場所に設置すること
  • クライアント証明書を利用した TLS クライアント認証を実施すること

CLINICSカルテは弊社で既に運用しているオンライン診療アプリ「CLINICS」と連携させる前提であったため、ガイドラインに即したシステム構成としていくために、まずCLINICSのシステムをHerokuからAWSに移行することから始まりました。

また、クライアント認証を行うためにAWSの構成を色々と検討し、Nginxとも日々格闘したりしました。。。

これらの対応内容に関連するブログも過去に書いていますので、興味がある方はぜひご参考にしてください。

developer.medley.jp developer.medley.jp developer.medley.jp

ORCAサーバの管理方法

CLINICSカルテは、日本医師会ORCA管理機構株式会社が提供する医療会計ソフトである「ORCA」を組み込んだ「ORCA内包型」のクラウド電子カルテです。

参考: ORCAとは

医療現場IT化を推進する日本医師会が会員等のために提供しているレセプトソフト(診療報酬の請求業務を行うための医療会計ソフト)。2002 年にオープンソースとして公開され、現在、診療所を中心に17,000 を超える全国の医療機関に導入されています。

医療情報ネットワーク推進委員会にて「医師会総合情報ネットワーク構想」(1997年 情報化検討委員会)を構成するツールの一つとして認められた日本医師会の研究事業プロジェクト「ORCAプロジェクト」が開発、提供を開始したものです。

www.orca.med.or.jp

CLINICSカルテはおおまかに以下のような構成となっており、Ruby on Railsで稼働しているカルテアプリケーションと医療機関ごとのORCAサーバがあり、その間をORCAが提供しているAPIで接続しています。

(下図は一例として上げているもので台数や詳細な構成は実際のシステムとは異なります) f:id:medley_inc:20180521152610p:plain

このORCAサーバですが、医療機関ごとに1つのEC2インスタンス構成となっており、利用する医療機関が増える度にEC2インスタンスが増えるため、導入医療機関が増えるほど構築も運用もつらくなっていきます。このあたりを出来るだけ自動化したお話が今回のメインテーマです。

(これよりももっと楽ができる構成にしようと色々検討もしたのですが、システムの特殊性などの諸事情があり、結果EC2インスタンス単位で管理する構成になっています)

ORCAサーバー関連で主に使用したAWSサービス

f:id:medley_inc:20180521152646p:plain AMI作成やインスタンス作成などのビルド系はCodeBuild、パッチ適用やコマンド実行などのインスタンス管理はSystems Manager脆弱性チェックなどのセキュリティ関連にはGuard Dutyといったサービスを主に利用しています。

次に、インスタンス構築に関してもう少し具体的に説明します。

ORCAサーバのインスタンス構築

ORCAサーバ用AMI(ゴールデンイメージ)作成

ビルドの実行はCodeBuildで行っています。AMIのビルドにはPackerを使用しており、ビルド完了時に作成されたAMIのIDをパラメータストアに登録しています。このAMI IDをインスタンス作成時に参照します。

f:id:medley_inc:20180521152801p:plain

参考までに、CodeBuildで使用しているbuildspec.yamlは以下のようになります(説明箇所など、一部実際とは異なります)。

phases:
  pre_build:
     ## 説明 
     * packerとjqをビルド用コンテナにインストール
      
     commands:
        - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip
        - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq

  build:
     ## 説明 
     * 処理に必要なAWS credential情報を取得&設定(後のaws cli使う用)
     * packerビルド実行、AMI作成
     * packerビルド結果から作成されたAMI IDを取得
     * AMI IDをパラメータストアに登録
          
     commands:
      - curl -qL -o aws_credentials.json http://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json
      - aws configure set region $AWS_REGION
      - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json`
      - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json`
      - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json`
      - ../packer build -machine-readable bin/packer.json | tee packer.log
      - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt
      - ORCA_AMI_ID=`cat ami.txt`
      - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite

 

ORCAサーバ用EC2インスタンス作成

医療機関用のアカウントを新規追加する場合、社内用の管理ツールでまず医療機関の基本情報を登録します。その後、ORCAインスタンス設定に必要なパラメータ(医療機関を識別するIDなど)を設定し、インスタンス作成のビルド処理を実行します。

CodeBuildがゴールデンイメージ用のAMIをベースにORCAインスタンスを構築します。ORCAインスタンスは起動時に各種設定処理を行います(cloud-init) f:id:medley_inc:20180521152838p:plain

なお、インスタンス起動時に行っている処理として主に以下のようなことを行っています。

  • 該当インスタンスの内部IPをPrivate DNSに登録
  • ORCAのセットアップ/プログラム/マスタ更新
  • Postgresのバックアップ設定
  • MackerelやSystems Manager等の各種Agentインストール、設定

ORCAサーバ運用

構築が完了し稼働した後も、ORCA自体のアップデートやパッチの適用など様々な運用が発生します。それらをどのように行っているか、まだ改善中ではありますが一部ご紹介します。

インスタンスに対する各種操作の実行

ORCAのアップデートなど、定期的に行う操作に必要なコマンドをdocumentとして登録し、RunCommandで特定インスタンスまたは複数インスタンスに一括実行できるようにしています。

ORCAアプリケーションの死活監視

ORCAアプリケーション自体構成が複雑で、いくつものミドルウェアと連携して動いています。これらの各種プロセス/ログ監視は行った上で、APIとして正しく稼働しているかを確認するための死活監視をMackerelのカスタムメトリクスとして登録し、一定数以上失敗した場合は各種プロセスを再起動し、それでも正常に動かない場合はMackerelからSlackに通知させています。

セキュリティチェック

CloudTrailVPCフローログなどをもとに、GuardDutyで定期的にチェックし脆弱性が見つかった場合はSlackに通知させるようにしています。その他、セキュリティパッチ適用などもパッチマネージャーを利用し自動化させています。

まとめ

電子カルテのシステムは検査や画像データなどを取り扱う外部システムと連携したいという需要もあります。そのような連携も視野に入れるとデータ標準化の問題などもあり難しい分野ではありますが、CLINICSカルテとして日々進化していくためにも、フルマネージドサービスなど活用できるところは積極的に活用し、集中すべき問題を解決していきたいと思います。

また、電子カルテのシステムとしての性質上、絶対に落とさないシステム運用が必要です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機能面の強化や日々のモニタリングなど地道なことも含め、もっともっと取り組んでいく必要があります。

まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICSカルテでは医療業務を効率化し、医療プラットフォームとなるべく進化していきたいという構想を持っています。(CLINICSカルテが目指す医療のプラットフォームとは?という話は、こちらで詳しく書かれています)

www.wantedly.com

CLINICSカルテは、まずは多くの医療機関に使ってもらうものではありますが、将来的には、患者さんと医療機関をつなぎ、診療や検査データなどをやりとりするプラットフォームとなる予定です。こうした新しい医療のプロダクトに興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 www.medley.jp

電子カルテの経験から、複雑なプロダクトデザインのアプローチを考える

こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド電子カルテCLINICSカルテ」のデザインを担当しているマエダです。

この電子カルテは、医療情報という複雑かつ独特なデータを扱うため、これまで自分自身が取り組んで来たようなWebサービスとは違ったデザインのアプローチが必要でした。

今回は、そんなデザイナーの苦悩と葛藤についてお話します。医療に限らず、複雑な業務フローの業界でデザインに悩む人のお役に立てれば嬉しいです。

デザインに取り掛かる前の準備

CLINICSカルテは「日医標準レセプトソフト(ORCA)」を完全内包しているカルテなのですが、医療にかなり詳しい人でないと、「レセプトソフトって?」というところから疑問ですよね。

自分も同様で、レセプト?オーダー?DO処方?...など医療の用語がわからない状態だったので、医療知識の理解や業務フローなどを知るところからプロジェクトに入り始めました。

デザイン業務を行う前に、医療事務の書籍を読んだり、医療事務がどのようにレセプト業務を行っているのかを学ぶことで、どのようなUIが適しているかなど掴んでいきました。

ちなみに、皆さんが医療機関で受診した時に診療費の一部負担して支払われると思いますが(よく「3割負担」など聞くこともあるかもしれません)残りの診療費については、 加入している医療保険の保険者(健康保険組合など)が支払います。

この診療費の請求のために発行する明細を診療報酬明細書(レセプト) といい、レセプトを作成し診療報酬を請求する業務のことをレセプト業務と言います。

そのレセプトを作成するための専用システムを「レセプトソフト」と言いますが、数あるレセプトソフトの中でも、日本医師会がオープンにして提供している「日医標準レセプトソフト(ORCA)」を、CLINICSカルテは内包しています。

f:id:medley_inc:20180516184514p:plain

実際にORCAを使ってみると、レセプト業務を知らない初心者には難易度が高い操作性に戸惑い、ウェブデザイン歴14年のマエダも機能ひとつひとつ理解するのに苦しめられました。

Webサービスの管理ツールの利用に慣れていると、操作順序だったりボタンをクリックした後の挙動についてある程度予測できるのですが、ORCAはぜんぜん予測できない...。

そんなときに大活躍したのが、超大作1400ページ程もあるORCAの操作マニュアル。人生でこんなに読み込んだマニュアルはないと断言できるほど、カルテをデザインした際に大変重宝しました。

最初は操作に非常に大変でしたが、業務フローを理解したうえで、操作に慣れてくるとORCAのUIが請求業務をする上で理にかなっていることも理解できて、UIの奥深さにあらためて気付かされました。

ORCAは実際にダウンロードして試してみることができるので、興味のある方はぜひ触ってみてはいかがでしょうか。

また、医療機関にカルテ入力〜会計処理までのフローのヒアリングなども行い、カルテのデザインをする上での前提知識を蓄えたり、既存カルテの課題なども整理することで、CLINICSカルテをどのようなデザインにしていくか、徐々にUI方針を固めていきました。

ようやくデザインへのアプローチのお話

さて、ここまできてやっとデザインについての話です。

昨今のWebデザインはワイヤーを引いて、モックをSketch等のデザインツールで制作し、動作検証するためにプロトタイピングツールで触れるようにした後、システム実装に取り掛かるというのが一般的だと思います。しかし、カルテは画面ごとに細かい機能がたくさんあり、それぞれの機能についてデザインして、プロトタイピングして....という一連の作業を行うとデザイン業務だけで恐ろしいほどの工数がかかるのが目にみえてました。

そこで私は、デザインに取り掛かるアプローチを普段と変えてみることにしました。

デザインするけどデザインツールは使わない

カルテはほぼコーディングだけでデザインしました。俗にいうインブラウザコーディングというやつでしょうか。

これによりワイヤー→デザインツール→プロトタイピングという、一連の工程を大幅に短縮して開発することができました。

f:id:medley_inc:20180516184701p:plain

カルテが動作する開発環境のほかにUIデザイン用の環境があります。UIデザインの環境でコーディングしたHTML/CSSファイルを開発環境に移植することができるため、エンジニアはUI実装する手間も大幅に削減でき、システム開発に専念することができたのもよかった点です。

またインタラクションもCSSで制御するようにしたため、動作の部分もデザイナー自身の思い描いたイメージに合うように調整できたので、制限もあるプロトタイピングツールを使うよりも実際の挙動に近いかたちで検証できたこともメリットでした。

ちなみに以前にマエダが書いた記事としてCLINICSアプリでデザイン言語システムを導入した事をお伝えしましたが、CLINICSカルテのUIは絶賛改善中のため、まだ導入はしていません。ある程度UI設計の軸が固まった段階で改めて整理したいとおもっています。

f:id:medley_inc:20180516184720j:plain

UIの方針を定義することの重要性

私自身これまでWebサービスをいくつも手がけてきましたが、カルテのデザインほどUIに悩まされた経験はありませんでした。

これまで見てきた電子カルテは機能毎にいくつものポップアップが表示されたり、深い階層を辿ったりするため、かなり独自のUIになっているように思えました。さらに、医療機関によって個別にカスタマイズされていることが多く、裏をかえせばUIのあるべき姿の方針が開発側ではなく、ユーザである医療機関側に委ねられているように思えました。実際に医療機関ヒアリングをしても、UIへのこだわりを持っている方が多い印象を受けました。

こうなると、電子カルテを使っている医師は職場を変わる度に新しい電子カルテの使い方を学びなおすということになります。また、医療機関間で情報連携しようと思った時も、データの保管形式などにバラツキが出てしまいます。

そこでCLINICSカルテでは、開発者側がUI方針をしっかり定義し一貫性をもった操作性を提供することが診療効率の改善にもつながると考え、UI開発を重要視しています。
カスタマイズに慣れている医療機関からすると、こうしてプロダクト側からUIを提示されることは珍しいことだと思います。しかしカスタマイズをしない分、UIの良し悪しが導入の判断を左右するという自負を持ちながら、どのようなUIが最適なのかを日々模索し続けています。

見た目的には問題なくても、触ってみるとクリック数が多くなってしまったり、適切な導線設計をしたつもりが逆にユーザーを迷わせる導線になってしまったりと、機能ひとつとっても「作る→検証→改善」の工程を幾度となく繰り返しながら、使い勝手向上と機能の両立を目指しています。右脳と左脳が行き来するため脳内キャッチボールが発生し、疲弊することもしばしばありましたが、その分想いの強いプロダクトとしてリリースできたことはデザイナーをしていてもなかなか巡り合うことのできない貴重な経験を得られたと思っています。

f:id:medley_inc:20180516184733j:plain

上流工程としてだけでなく運用フェーズのデザインの重要性

プロダクトに携わるデザイナーの役割がどんどん幅広くなってきている昨今、広範囲でプロダクトに携わらないと、本質を捉えたデザインができず、プロダクトの方向に迷いが生じてしまうことになるので、全体像を理解したうえでデザインにどう落とし込んで行くかが重要になってきます。

デザイナーは上流工程だけでなく、システムがどういう設計で成り立っているのか踏まえ、実運用も理解することで、今後の改善やアイデアに活かせると思います。

どこが課題でどれを優先して開発するかなどもデザインする上で重要で、それも踏まえて企画検討することがプロダクトとして良いものにできるかどうかに影響します。

上流だけでは結局のところ表面的な部分だけの品質を重視してしまいがちですが、全体像を捉えることがプロダクト品質を底上げするようにしていくことの大切さを、このプロダクト開発に携わることで学ばせてもらっています。

まとめ

すでに実際にご利用いただいてる医療機関もあり、実運用からのフィードバックを経て日々進化しているCLINICSカルテ。まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICSカルテでは医療業務の課題解決をしていきます。

実際にCLINICSカルテを利用する方は医療機関の方に限られてしまうのですが、興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。

www.medley.jp

次回はCLINICSカルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください!

医療ITの未来に向けて取り組むこと

こんにちは、平山です。メドレーのプロダクト開発全般を管掌しています。先日4/29 (日)に虎ノ門ヒルズフォーラムで開催されたCLINICS SUMMIT 2018と合わせて、3本のニュースリリースをだしました。

これらのニュースリリースはひとつのストーリーにもとづいているのですが、それぞれを読んだだけではメッセージが伝わりづらいと思いますので、このブログで補足させて頂きます。 

ニュースリリース

www.medley.jp

www.medley.jp

www.medley.jp

オンライン診療システムのいま

まず背景として我々が提供しているプロダクト「CLINICS」について振り返るところから話を進めます。

f:id:medley_inc:20180501111913p:plain

オンライン診療システムCLINICSは、2015年8月に厚生労働省から示された遠隔診療に関する通知をうけて、2016年2月にプロダクトをローンチしたところからはじまりました。

ローンチ当初はネイティブアプリもなくウェブアプリケーションのみで、オンライン診療の肝となるビデオチャット機能も外部サービスで代替するなど、わかりやすいMVP (Minimum Viable Product) からスタートしました。その後、様々な医療機関で利用頂き、多くの医療機関スタッフの皆様からの叱咤激励をうけながら、プロダクトやオペレーションを磨き進化を続けて参りました。

その結果として、現在では契約医療機関は800を超え、1ヶ月に100回以上ものオンライン診療を実施するような医療機関もでてきました。また平成30年度の診療報酬改定ではオンライン診療料が新設され、オンライン診療というものが正式に医療の現場で認められるようになってきています。

f:id:dev-medley:20180427172532p:plain

 

しかし、オンライン診療システムの進化の中で常につきまとう課題がありました。それは電子カルテや医事会計システムなど医療機関の中心で使われるシステムとの連携です。 

オンライン診療から電子カルテ

医療現場の業務において中心で使われるシステムはオンライン診療システムではなく、一般的には電子カルテや医事会計システムとなります。

オンライン診療システムは、予約、問診、診察、会計、薬または処方せんの配送、これら一連の業務を対面・オンラインに限らずにワンストップで処理できるという思想で開発を進めてきました。しかし、実際の現場においては、オンライン診療システムでの業務と電子カルテシステムでの業務を連携させるために人手を介在させる必要があり、オンライン診療システムをいれると現場オペレーションが増えてしまうといった課題がありました。

このオンライン診療システムにつきまとう課題を解決するため、昨年より電子カルテに関する調査を進めてきました。他社電子カルテシステムとの連携など様々な選択肢があったなか、この調査を経て現状の電子カルテをとりまく課題と将来の可能性を感じ、電子カルテを内製で開発しオンライン診療システムを電子カルテシステムに進化させるという結論に至りました。

 

f:id:dev-medley:20180501101005p:plain

 

おりしも2017年は3省4ガイドラインの改定 (医療情報システムの安全管理に関するガイドライン第5版) や、日本医師会ORCA管理機構による日レセクラウドAPI拡張 (HAORI)の提供開始などの動きがあり、医療業界においてもクラウド化の波が確実にきていることを感じました。これが電子カルテ開発の背景です。 

患者とつながる電子カルテ「CLINICSカルテ」

開発した電子カルテシステム「CLINICSカルテ」は、医事会計ソフトであるORCAを会計エンジンとして組み込んだORCA内包型のクラウド電子カルテとなります。

医療機関のスタッフは予約から受付、患者管理、診察、オーダリング、会計、請求といった、ひととおりの業務をウェブブラウザだけあれば行うことができます。またオンライン診療の機能が搭載されているため、患者がアプリから予約しチェックインした情報をもとに、医療機関スタッフが患者情報を登録し、そのままオンライン診療を実施し、会計まで進めるということも可能となります*1

まさに患者とつながる電子カルテということを実現したプロダクトとなります。

f:id:dev-medley:20180430230423p:plain

もちろんセキュリティ統制の強化についても昨年から本格的に取り組んできておりまして、3省4ガイドラインへの準拠は当然のことながら、第3者認証機関による認証取得に向けても動いています (TRUSTe取得完了ISMS取得作業中)。  

医療ITの課題とアプローチ

しかし、CLINICSカルテをはじめとしたクラウド電子カルテが普及するには時間がかかると考えています。

クラウドサービスに慣れた若い世代が開業し、システム導入の意思決定をするための世代交代に一定以上の時間が必要であるというのはもちろんですが、それ以上に医療情報システム関連技術の標準化が遅れていることや、ローカルネットワークを前提とする院内システムのエコシステムができあがっているためです。これにより、ウェブ系の新興プレイヤーが参入することが難しくなり、結果として医療業界全体がテクノロジーの進化の恩恵をうけづらくなっているように感じます。

この現状をふまえ、我々はCLINICSカルテの公開とあわせて、医療ITの世界をオープンにし、様々な新興プレイヤーが参入しやすい土壌をつくることについてもコミットしていきたいと考えています。その思いがORCA APIオープンソース公開」ブロックチェーンを活用した電子処方せん管理方式に関する特許出願」という2つのニュースリリースにあらわれています。 

ORCA APIオープンソース公開

ORCA APIORCA*2が提供するAPIRubyから利用するためのライブラリです。ORCA APIオープンソースとして公開することで、ORCAと接続するウェブアプリケーションの開発が促進されることを期待するものです。

github.com 

ブロックチェーンを活用した電子処方せん管理方式に関する特許出願

電子処方せんに関してはすでに実装ガイドが作成され指針が示されていますが、この中で認められているように、実装ガイドに基づいて電子処方せんシステムを実装しても実運用で使うにはいくつかの課題が残ります。また、それらの課題を解決するために今後の方向性についての議論も行われているようですが、なかなか前に進む気配が見られません。

それに対する我々からのひとつの考えを示してみたのが今回の特許出願となります (我々が独占的に利用するといった意図の特許出願ではありません)。

名称 電子処方せん管理方法、電子処方せん管理システム、及びプログラム
内容 処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラム
概要 ASPサーバを用いずとも、実運用が可能な電子処方せんを実現するもの

 

この2つは現状の医療ITに存在している課題に対してアプローチしたものになりますが、これ以外にも検査結果データの標準化やHPKIのオープン化と促進 (特定プラットフォーム依存性の排除)、SS-MIXの促進など、標準化という観点で医療ITの世界には取り組むべき課題が多くあります。

標準化においてはトップダウンによるアプローチが理想だと思いますが、トップダウンでの標準化には時間がかかり、テクノロジーの進化の時間軸との間にギャップが発生しがちです。我々は今回のORCA APIや電子処方せんブロックチェーンでのアプローチのように、トップダウンでの標準化の動きを待つだけでなく、テクノロジーを活用したボトムアップの技術提案も積極的に行っていきたいと考えています。

その結果として、技術の標準化が進み、新興プレイヤーが増え、医療機関間の連携も円滑になり、地域医療構想のような動きも加速され、医療現場のIT化が進み、医療従事者が診療により専念できる環境がつくられる。

そのような世界の実現にむけて我々は取り組んでいくという意思を明確にするために、今回のニュースリリースを公開させて頂きました。

 

f:id:dev-medley:20180501101035p:plain

医療ITの未来に向けて

toppa.medley.jp

以前このブログでも書いたとおり、インターネット業界で活躍してきたような、高い能力をもちプロダクトにこだわりをもって開発をしてきたような人が圧倒的に少ないことが、医療ITにおける課題であると私は思っています。

若く優秀なクリエイターたちが医療ITの世界に参加し、様々な取り組みをすることで、業界内の循環が進み、結果として業界の進化にもつながるものと考えています。まずは我々が積極的に技術をオープンにしていくことで、その流れの起点をつくっていきたいと思います。 

メドレーは「医療ヘルスケア分野の課題を解決する」というミッションのもと、医療ITの世界における標準化の課題に対しても積極的にアプローチしていきます。

さいごに

メドレーではこのような医療業界に存在する課題に取り組んでいきたいメンバーをデザイナー・エンジニアを中心に全職種絶賛募集中です。皆さまからのご応募お待ちしております。

 

www.medley.jp

 

 

*1:もちろんオンライン診療を実施するための基準を満たしていることが前提です

*2:正確にはORCAプロジェクトが提供している日医標準レセプトソフト

小さく始めるDesign System ~メドレーTechLunch~

こんにちは、開発本部の舘野です。

先日、メドレーで定期開催している社内勉強会「TechLunch」にて、Design Systemについて発表しました。医療介護の求人サイト「ジョブメドレー」において、Design Systemを「小さく始める」手法で導入を進めているので、そのプロセスについて紹介させていただこうと思います。

Design Systemとは何か

Design Systemとは、SalesforceLightning Design SystemIBMCarbon Design Systemなどが代表的な例として挙げられると思いますが、平たく言ってしまうとプロダクト独自のBootstrapとなるものです。

UI開発の領域では、これまでスタイルガイドを作ることでデザイナーとエンジニア間の共通言語とし、プロダクトのUIの一貫性を保つように努めることが一般的かと思いますが、Design Systemではスタイルガイドだけでなくデザインの原則やUIコンポーネントCSSやJSなども含めてプロダクトのインターフェースに関わる全てを、1つのプロダクトとする考え方です。

Design Systemはスタイルガイドと明確にどこが違うのかについて言及しているウェブ上の記事の多くは、Nathan Curtis氏の「A Design System isn’t a Project. It’s a Product, Serving Products.」という言葉を引用して、その差異を示しています。

スタイルガイドがプロダクトにおけるプロジェクト以上の存在ではないのに対して、Design Systemはプロダクトに対してUIのエコシステムを提供するプロダクトである、ということがDesign Systemの基幹となる考え方だと思います。

ジョブメドレーにおけるDesign System

TechLunchで発表したスライドはこちら。 speakerdeck.com

今回Design Systemを段階的に導入しているのは、医療介護の求人サイト「ジョブメドレー」です。

ジョブメドレーのインターフェースが今後より一層色々な形でユーザに使われる場面が増えていくことが想定される中で、プロダクトのUIの一貫性や生産性を担保し続けていくためには、スタイルガイドを作るだけでなくDesign Systemによってより包括的にプロダクトのUI開発に対する取り組み方を変える必要があるのではと考えていました。

とはいえ最初からプロダクトのUI全てをDesign Systemに置き換えるというのは変化が大き過ぎるし、Design Systemがうまく機能せずに失敗する場合も考慮しておく必要があったので、導入がうまくいかないければすぐにやめられるように以下の点を導入前に決めていました。

  • 最初から一気に色々やらない
  • まずは一部だけ導入してみる
  • 上手くいく部分といかない部分を検証する
  • Design Systemの改善と段階導入を繰り返す

Design SystemはプロダクトにUIのエコシステムを提供するプロダクトなので、一定期間で作って終わりではなく継続して改善を繰り返していくという点では、このような進め方が適切と考えました。

実際のところ、現在のジョブメドレーでは一部分だけジョブメドレーのDesign Systemとしてnpm化したモジュールから提供するようにしています。

npm化してDesign Systemから提供するようにしたのは、以下の3つのみです。

  • jmds-tools

    • sass mixinやfunctionを提供するユーティリティモジュール
  • jmds-tokens

    • design tokens(デザイン上の値を信頼できる唯一の情報源として1つの場所で定義されるもの)
  • jmds-flex

    • flexboxユーティリティ

プロダクトのUIとして見ると、flexboxのユーティリティクラスをDesign systemから提供するようになっただけです。

ただ、今は全体のごく一部がDesign Systemから提供されていますが、Design Systemに移行できるUIコンポーネントを選定して段階的にnpm化をしていくことで、プロダクトのUIコンポーネントの多くがDesign Systemから提供されている状態にすることが可能だと思います。

単純にnpm化することが目的ではなく、npm化したDesign Systemをプロダクトチームでメンテナンスしていくことで、より一貫性のあるUIをジョブメドレーのプロダクトに提供していくことが目的です。

まとめ

今回は、TechLunchで発表したジョブメドレーにおけるDesign Systemの取り組みについて紹介させていただきました。

今回紹介したDesign Systemが今後デザイナー、エンジニア、プロダクトマネージャーと協力しながら、ジョブメドレーのプロダクトのUIを支える強固な土台へと成長させられるように取り組んでいこうと思います。

お知らせ

メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。

ちょっと興味があるという方も、ぜひお気軽にご連絡ください!

www.medley.jp

メドレーが協賛させていただいた「MANABIYA」に行って来ました!

皆さんこんにちは。開発本部の日下です。普段はオンライン診療アプリ「CLINICS」およびオンライン医療事典「MEDLEY」の開発を担当しています。(昨年、新卒で昨年メドレーに入ったのでエンジニア歴は1年弱。ベテランが多いメドレーのエンジニアチームで奮闘しています)

先日開催されたエンジニア特化型Q&Aサイト「teratailさんのイベント、MANABIYAにメドレーがスポンサーとして協力させていただきました。 エンジニアの平木と参加しましたので、イベント当日の様子をレポートします。

MANABIYAとは

teratailはご存知の方も多いかもしれませんが、MANABIYAというイベントをご存じない方もいるかもしれません。 MANABIYAは今回が初開催のイベントで、”疑問” を日本中から集め、カンファレンスを通じて解決策を見出し、”知恵” を生み出すことを目的とし、秋葉原から近い3331 Arts Chiyodaにて2日間に渡って開催されました。

全体の雰囲気

f:id:medley_inc:20180411115536p:plain 全体的に初開催とは思えないほど人が多く、一部のセッションでは教室が満杯になり、入場制限がかかるほどでした。また、speakerとして豪華なメンバー面々が数多く集まっており、最初から最後まで、参加したすべてのセッションで立ち見が出てるほど盛況だったのがとても印象的でした。

また、イベントの名前にもなっているように、学び舎というイメージがぴったりのコンセプトで統一されているのも特徴的でした。 会場自体も元々中学校だったものを利用したアートギャラリーを使用しており、教室や階段など、元を活かした作りになっていたのでイベントの雰囲気ととてもマッチしていました。

f:id:medley_inc:20180411160342p:plain

f:id:medley_inc:20180411115957j:plain
元々教室だったところでセッションが行われました

セッション

セッションはWeb、インフラ、DB、プログラミングから、AI、IoT等の最近話題になっている分野まで幅広く開かれていました。

我々が参加した2日目はプログラミング、Web、IoTのセッションが主に開催されていました。

メドレーのプロダクトはすべてWebサービスとして提供されていることもあり、私は、Web関連のセッションを中心に、時間が空いたら他の分野のセッションもふらっと覗き見るような形で参加しました。

エンジニアとして成長する上で必要な戦略の話や、Service WorkerやWeb Paymentsなど最近環境が整ってきた技術をプロダクトに組み込んでみた話など、幅広く見ることができました。

f:id:medley_inc:20180411120051j:plain
入場制限状態でやっと入れたものの立ち見の方の後ろから見ることに

f:id:medley_inc:20180411120136j:plain
運良く前の方の席が取れましたが、こちらも立ち見の方がたくさんいらっしゃいました

個人的に古川氏による「Web Application 2018 From Performance Perspective」は特に勉強になったセッションでした。 Webサイトのパフォーマンスに関してのエッセンスを詰めたようなセッションで、その歴史と共に、その時々のベストプラクティス、そしてその時代のバイブルをまとめ、今どういった背景でどういった対策をするべきか、その指針となるような話聞くことができました。

f:id:medley_inc:20180411120434p:plain
サイトパフォーマンスの歴史の概要を説明していただきました

特に、Web側はSPAとして動いているCLINICSを開発しているため、 Server rendered pages are not optional という言葉の意味が衝撃的で、帰る途中からずっとそのあたりのことを考えてしまうほどでした。 Speaker Deckにスライドが上がっていますので、気になる方はそちらをご参照ください。

speakerdeck.com

Webアプリケーションのパフォーマンスに関することは個人的に気になっていたものの、どこから手を付けてよいのかわからず理解があまり進んでない分野だったため、必要な知識を40分という短い時間で把握することができたのは非常にありがたかったです。

まさにイベントの趣旨である”気になっていること”、「回答」を知りたいがなかなか ”知る機会がなかったこと” という ”疑問” を、カンファレンスを通じて解決策を見出し、”知恵” を生み出す体験ができたのではないかと思っています。

f:id:medley_inc:20180411120233j:plain
リアル版teratailも登場

まとめ

大規模かつ幅広い分野を取り扱っており、自分の専門や興味のある分野以外も同時に開催されたため、気軽に参加することができるイベントでした。 初めてエンジニアリングに触れて1年弱が経ち、その間に業務などを通じて学んできた過程で言語化できていなかったことが思っていた以上にあったことを、このイベントを通じて改めて知ることができました。

こういった大規模なイベントは初参加だったのですが、多くのことが知れたのでとても良かったです。 次回開催される際は、また行ってみようと思っています。

イベントでメドレーのことを知りご興味持っていただいた方は、お気軽にご連絡ください! どんなエンジニア・デザイナーが働いているか、どんなことをやっているか等、ぜひHPをご覧ください。 www.medley.jp www.wantedly.com

「サイトの会員登録増加」に効果が出た施策の話

こんにちは。開発本部で医療介護の求人サイト「ジョブメドレー」の開発を担当している田村です。 メドレー開発本部で行われている勉強会「TechLunch」で、ジョブメドレーについて「求人サイトでやって良かった会員登録施策」というタイトルでお話させていただきました。インターネットで検索するとこういう内容はたくさん出てきますが、そのうちの一つとして、参考にしていただければ幸いです。

背景

医療介護の求人サイト「ジョブメドレー」は、創業当初(2009年)にリリースし会社と共に進化し続けてきたメドレーで最も歴史のあるサービスです。リリース開始から9年ほど経ちますが、個人・事業所にとって使いやすく愛されるサービスとなるよう、日々改善を続けています。その中でも、サービスの成長に重要な要素の1つである「ユーザの獲得」に向けた施策は、とても大切にしています。昨年に実施した中で「サイトの会員登録増加に効果が出た施策」について、社内の他サービスにとってもノウハウとなればと、少しだけ紹介させていただきしました。

ABテストによる改善

まずはじめに、既存のサイト内で改善できる点を洗い出して優先順位を付けて費用対効果が高そうなものから着手しました。実際に以下の2つをABテストを行い改善しました。

  • LPの改善
    • デザイン変更
    • 入力フォームの変更
  • 会員登録バナーの変更

LPの改善

BEFORE / AFTERの変更点

  • ユーザの満足度や求人の特徴を強調
  • メリハリを付け、より直感的にわかりやすく
  • 職種をイメージしやすいビジュアルに変更

BEFORE / AFTERの変更点

  • 全ての入力項目のある長い1ステップ形式から入力項目を短く分割して5ステップ形式に変更
  • ユーザがゴールイメージができるように現在のステップを表示
  • 入力しやすいように各項目を大きく表示
  • 各ステップへの移動がしやすいようにスクロールしなくても「つぎへ」「もどる」ボタンが押せるようなボタン配置
  • サクサク入力できるように各ステップへの移動でページ遷移をさせない

どのくらい効果があったのか

ビジュアルや訴求内容のブラッシュアップ、そしてユーザビリティを改善したことで会員登録数が約1.2倍という結果になりました。1.2倍で少ないと思うかもしれませんが、サイトの規模が大きくなるほど、ちょっとした改善を積み上げていくことが重要だと考えています。

会員登録バナーの変更

BEFORE / AFTERの変更点

  • ユーザがイメージしやすい訴求内容に
  • 訴求内容を絞り、ユーザが内容をすぐ把握できるようにビジュアルを追加
  • サイトの配色に合ったバナーデザイン

どのくらい効果があったのか

バナーの訴求内容とデザインを変更したことで、CVRが約2倍という結果になりました。訴求内容を多く見せることも大事ですが、ユーザがバナーを見て内容をすぐに理解できることを重視しています。

ユーザの行動を分析して施策を立てる

ジョブメドレーには、会員登録をしていないユーザが気になった求人を保存しておくことができる「キープ機能」があります。求人の保存期限は2週間でこの期間内に会員登録をすると保存期限の上限がなくなり、気になった求人をずっと保存しておくことができます。

施策のきっかけは、ある調査でユーザが積極的にキープ機能を活用していることがわかったことです。このキープ機能を利用しているユーザに保存期間に関する会員登録のメリットを提示すれば、会員登録してくれるのでは?という仮説を持ち、施策を実施することになりました。

BEFORE / AFTERの変更点

  • キープボタンをクリックした際、モーダルを表示
  • 保存期間は2週間で会員登録すると期間を越えて利用できます!と表記
  • 会員登録ボタンを設置

どのくらい効果があったのか

具体的な数値は公表できませんが、リリース当初の会員登録数と比較すると、最近ではおよそ10倍程度の結果となりました。ユーザにしてほしい行動・適切な導線改善などから見えてくる施策があるので、積極的にユーザの行動を分析し施策を立てて実行することが重要だと言えます。

まとめ

いかがでしたでしょうか。今回ご紹介した内容の他にも、ジョブメドレーでは、様々な改善を日々続けています。こうした取り組みを通じて、ABテストでちょっとした改善を積み上げていくこと、ユーザの行動を分析し施策を立てて実行すること、そして地道な改善を積み上げていくことがサービスの成長には不可欠だと実感しています。こうした地道な取り組みに励むエンジニアの方は少なくないと思いますが、私たちが実施している施策事例が、皆様の参考となれば幸いです。

今後も「ジョブメドレー」を会社と共に成長し続けるサービスにしていきたいと思い、日々奮闘していきたいと思います。

お知らせ

メドレーでは、医療介護の求人サイト「ジョブメドレー」の他にも、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。

ちょっと興味があるという方も、ぜひお気軽にご連絡ください!

www.medley.jp