Medley Developer Blog

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

Lightning Talks SponsorとしてRubyKaigi 2018に参加してきました

こんにちは!開発本部のエンジニア・後藤です。

メドレーは5/31〜6/2に開催されたRurbyKaigi 2018にLightning Talks Sponsorとして協賛させていただきました(昨年Ruby Sponsorに続き、2年目の協賛です)。

イベント当日は、弊社からCTOの平山、採用・広報の阿部と深澤、エンジニアの田中、宍戸、後藤の6人が参加しました。今回はその様子などをレポートします。

会場の様子

RubyKaigi 2018は仙台国際センターでの開催でした。昨年は広島、一昨年は京都ということで、これで天橋立・宮島・松島の日本三景をめぐる旅が一旦完結になりますね。

f:id:medley_inc:20180605172640j:plain

仙台国際センターは仙台駅から地下鉄東西線で3駅目というアクセスの良い好立地にありながら緑に囲まれた心地よい場所にありました。

メイン会場は1000人収容できる広い会場になっています。各セッション、この会場が埋まるぐらいの盛況ぶりでした。

f:id:medley_inc:20180605172745j:plain

世界地図&日本地図。様々な地域からの参加者がいますね!(rubyistsにmapメソッドをかましてますね。ブロック内容は各参加者がシールを貼って実装。)

f:id:medley_inc:20180605172857j:plain

地図の隣のスポンサーボード覧にメドレーロゴがあることを確認してパシャり。

f:id:medley_inc:20180605173736p:plain

ブースの様子

続いてブースの様子を紹介します。メドレーコーポレートカラーの赤をベースとした以下な感じの仕上がりになりました。

 f:id:medley_inc:20180605173908j:plain フォトスポンサーのラブグラフさんがブースの写真を撮ってくれました!

ノベルティも用意してブースにお越しいただいた方にお配りしていました。ステッカー、うちわ、パンフレットに加えて医療らしさが伝わる絆創膏も用意しました。

f:id:medley_inc:20180605174458j:plain

ブースにはおかげさまで、たくさんの方にお越しいただきました!

f:id:medley_inc:20180605174539j:plain

CTO平山の発表

そして、初日のLightning Talks前のスポンサーのPR枠にて弊社のCTO平山が発表をしました。

f:id:medley_inc:20180606145341p:plain

f:id:medley_inc:20180605175431j:plain

発表では、「医療ヘルスケア分野の課題を解決する」というミッションのもとメドレーが4つの事業を行っていること、また、以前本ブログで紹介しました3本のニュースリリースを含めたこの1年のアップデート内容を中心に紹介させていただきました。

f:id:medley_inc:20180605175456j:plain

公演の途中でのCTO平山からメドレーのことを知っている人?との問いかけで、7・8割の方が挙手をしていたのは感慨深かったです。

当日のスライドはこちらです。 speakerdeck.com

現地での反応

ブース展示、PR枠での発表を通じて以下のような嬉しい反応もいただきました!

ブースでも、2日目以降「1日目のセッション見ましたよー」と話してくださる方も多く、メドレーとそのプロダクトについてRubyistの皆様に知っていただくとても良い機会になっていたと思いました。

セッションの様子

エンジニアはブースでの会社紹介の合間に各自気になったセッションを聴講したりもしました。 感覚ですがmrubyや型、パフォーマンス周りの話題が多かったように思います。まさに2018年現在のRubyを取り巻く環境を表している感じがします。エンジニアとしてこういった技術のセッションを聞けるのは純粋に楽しいですし、日々の開発に活かせそうなネタもあったりと、とても有意義な時間を過ごせました。

f:id:medley_inc:20180605175826j:plain 初日のkeynoteでの1コマ。

Matzさんのkeynoteにもありましたが何事も「塞翁が馬」です。毎年Rubyは死に、そして生まれ変わります(クリスマスに)。Rubyも常に進化していることを肌で感じることのできるセッション群でした。

番外編

さて、メドレー恒例(?)のお参りですが今回は大崎八幡宮に参詣することになりました。

大崎八幡宮の社殿は国宝にも指定されており、安土桃山時代の豪華絢爛な様式の建築でとても雰囲気のある神社でした。

f:id:medley_inc:20180605175920j:plain 参拝する3人。

f:id:medley_inc:20180605175948j:plain 参拝する2人とそれを撮影する2人。

さいごに

昨年に引き続きメドレーのRubyKaigi協賛は2度目になりました。

ブースで会社やプロダクトの説明していると「メドレー知ってます」との声を聞く機会も多く、とても嬉しい限りでした。これまで以上にRuby、医療×ITを盛り上げていければという気持ちを胸に仙台を後にしました。

 f:id:medley_inc:20180605180049j:plain (新幹線から仙台の夕焼けをパシャリ)

お知らせ

弊社では「医療 x ITへの挑戦」に取り組みたいエンジニアのみなさんを心からお待ちしております! 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 www.wantedly.com

開発本部の雰囲気をもっと知りたい方は、こちらからどうぞ。 www.medley.jp

アプリエンジニアがのぞいたReact Native 〜メドレーTechLunch〜

こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「TechLunch」でReact Nativeについて発表しました。

私は普段はSwift、Kotlin/Javaを使ってネイティブアプリを開発しており、React Nativeに触るのは初めてでした。そこで今回は、アプリエンジニアの視点から、実装するための基本的な知識と弊社の実際の開発で使えそうかを検討した結果についてご紹介します。  

なぜReact Nativeを触ってみようと思ったか

オンライン診療アプリ「CLINICS」の開発では、iOS/Androidアプリをそれぞれのネイティブ言語で別々に開発しているため、実装やレビューの際にはプラットフォーム間の仕様の違いを理解する必要があり、なかなか大変だと感じていました。

これらの課題に対してこちらのブログでも紹介したような施策を行って改善を行ってきましたが、ソースを共通化することでより開発効率を向上できないかと思い、クロスプラットフォーム開発についても調べてみることにしました。

その中でも以下の理由から、今回はReact Nativeについて調べてみることにしました。

  • JavaScript(以下JS)・Reactのため、Webエンジニアがネイティブアプリ開発を行う際のハードルを低くすることができそう
  • UIの実装にネイティブUIを使用しているので自然なデザインやインタラクションを作りやすそう
  • ある程度リリースから時間が経って情報が豊富にある

特に弊社では、ネイティブアプリよりWeb開発をメインに行ってきたエンジニアの方が多く、またWebフロントにReactが使われているプロダクトもいくつかあるので、React Nativeを採用することでチームの開発効率の向上だけでなく、開発本部全体でもネイティブアプリ開発の学習コストが低くなるのではないかと考えました。

そこで、以降ではネイティブアプリエンジニアとWebエンジニアそれぞれにとって、開発しやすいかどうかという観点でReact Nativeの開発方法を見ていきたいと思います。

初期設定について

インストール〜アプリ実行

インストールは公式のGetting Startedにもありますが、以下のコマンドで完了です。  

$ brew install node
$ brew install watchman
$ npm install -g react-native-cli

今回、私が触るにあたってはXcodeAndroid Studioのシミュレータ(エミュレータ)で実行しながら開発しましたが、React NativeはXcodeAndroid Studioがインストールされていなくても、Expoというクライアントアプリを実機にインストールすることで画面をプレビューしながら開発することができます。

これなら、Xcodeのダウンロードを待つ必要もありません!(iOSエンジニアでもアップグレードのたびにXcodeのダウンロードを待つのはイライラします)

次に、プロジェクト作成、シミュレータでのアプリ実行は以下のコマンドで実行できます。

ただし、シミュレータ実行前にXcode Command Line ToolsのインストールとAndroid Studioでいくつかの設定(SDKのインストール、AVDの作成、環境変数の設定)が必要です。  

# プロジェクト作成
$ react-native init AwesomeProject
 # アプリ実行(シミュレータ)
$ cd AwesomeProject
$ react-native run-ios or react-native run-android # Androidの場合、emulatorを別途起動してからでないと実行できない

実装してみた感想

UIの実装方法

React NativeではReact同様UIの各パーツをコンポーネントと呼び、それらを配置することでUIを実装していきます。違いはWebのHTMLの代わりにNativeのUIを描画するためのコンポーネントとして使う点です。

見た目やレイアウトはCSSと似たような形式で記述します。React Nativeで使えるスタイルのプロパティは各コンポーネントで異なりますが、例えば、Viewコンポーネントに設定できるプロパティには以下のようなものがあります。

Webで使われているものと全く同じというわけではないですが、flex、margin、borderなどの使い慣れているCSSのプロパティ名で設定できるので、Webエンジニアにとっては実装のハードルが下がるのではないかと思いました。ただ、普段CSSを触っていないネイティブアプリエンジニアにとっては学習コストがかかると思います。

また一度ビルドすれば、JSによる修正内容をビルドなしでシミュレータに反映することができるので、View周りの調整は効率的にできそうでした。

 

// js/components/home.js

 const renderItem = ({ item, index }) => (

   <View style={styles.row}>

     <Text style={styles.title}>

       {parseInt(index, 10) + 1}

       {". "}

       {item.title}

     </Text>

     <Text style={styles.description}>{item.description}</Text>

   </View>

 );

const styles = StyleSheet.create({

 row: {

   borderBottomWidth: 1,

   borderColor: "#ccc",

   padding: 10,

 },

 title: {

   fontSize: 15,

   fontWeight: "600",

 },

 description: {

   marginTop: 5,

   fontSize: 14,

 },

});

ただ、OSごとにデザインを合わせる方針にしない限りは、コードも別々になるところがわりと多くなりそうだと感じました。

例えば、TabBar(iOS)とDrawerLayout(Android)、DatePicker(iOS)とTimePicker(Android)、ProgressView(iOS)とProgressBar(Android)などはReact Nativeでは別コンポーネントとして提供されていて、APIも違っていました。

画面遷移

画面遷移(プッシュ、モーダル、タブ遷移など)のためにAPIとして公式で提供されているのはiOSのみでAndroidは別途、実装するか、サードパーティのライブラリを使用する必要があります。

わたしが使ってみたreact-native-navigationはモーダル、プッシュなどの遷移がネイティブAPIベースで実装されているので、ネイティブ言語で実装した場合と比べて違和感なく実装することができました。

下記のような形でプッシュやモーダル表示での遷移ができます。特定の画面に戻る機能については開発中であったり、機能的な制約は少しありそうです。そういう細かいところはネイティブ言語でやった方が自由が効くので、良いなと思います。

それでも、iOSAndroidでは複数画面の管理や遷移についての考え方が違い、Androidを初めて開発した時に同じことを実現するのが難しかった覚えがあるので、共通の方法で実現できるのは便利でした。特にWebだとあまり画面間の遷移について考えることはないと思うので、共通化されているとネイティブアプリ開発の学習コストが下がると思います。  

this.props.navigator.push({ // プッシュ

 screen: 'example.PushedScreen',

 title: 'Pushed Screen'

});
 
this.props.navigator.pop({ // 前の画面に戻る

 animated: true,

 animationType: 'fade',

});

 

this.props.navigator.showModal({ // モーダル

 screen: "example.ModalScreen",

 title: "Modal",

 animationType: 'slide-up'

});

ネットワーク周り

ネットワーク経由でデータを取得して、モデルに変換し、アプリ内で使うというよくある操作を行うにはFetch APIを利用します。Fetch APIはJSで提供されているPromiseベースのAPIです。例えば、以下のような形でJSONを返すAPIからデータを取得し、receiveHelthNews関数にオブジェクトに変換した配列を渡すことができます。JSのAPIなのでWebエンジニアにとっては使いやすいのではないかと思います。

ネイティブ言語でそれぞれ実装する場合は、URLSession(iOS)とHttpURLConnection(Android)、あるいは各プラットフォーム向けに提供されているサードパーティのライブラリなどを使うと思いますが、当然、APIは異なるのでそれぞれの実装方法を把握しないといけなくなります。それに比べると学習コストは低くなりそうです。

// js/actions/index.js

export function fetchHelthNews() {

 return dispatch =>

   fetch(constructHealthNewsUrl())

     .then(response => response.json())

     .then(json => dispatch(receiveHelthNews(json.articles)))

     .catch((error) => {

       console.log(error);

     });

}

ネイティブアプリ特有の機能について

その他のアプリ開発でよく使うネイティブアプリ特有の機能を実装する方法は以下のようになります。多くの機能がサードパーティのライブラリに依存しているので、各言語のバージョンアップ時の対応が少し心配ではありますが、よく使う機能については実現することができます。

  • Push通知:AndroidはハンドリングするAPIが公式で提供されていないのでサードパーティのライブラリを使う
  • カメラ、キーチェーンアクセス/ユーザデフォルト:公式のAPIは提供されていないのでサードパーティのライブラリを使う
  • 位置情報の取得:公式APIが提供されている
  • ディープリンク:アプリ起動時にハンドリングを行うAPIは提供されている。ユニバーサルリンクやIntentFilterの設定は各プラットフォームで個別に必要になる

リリースはどうやるか

アーカイブやストア配布についてはネイティブアプリの配布と同じプロセスになります。

各プラットフォームで証明書等の設定を行い、XcodeAndroid Studio、あるいはCLIでコマンドを実行して、ipa / apkファイルを作成し、各Storeにアップロードする必要があります。  

CIはBitriseなどが使えます。Bitriseでビルドを試してみましたが、React Nativeのリポジトリと接続したときにできるデフォルトのワークフローを使えば、同時に2プラットフォームのアーカイブが作成できて便利でした。  

あと、まだ試せてはいないのですがCodePushを使えば、審査に提出することなしに既存のアプリを変更することもできるらしいので、非常に便利だと思いました。    

どんな場合にReact Nativeを採用できそうか?

React Nativeで開発することで、Web開発者の視点で見るとプラットフォームのネイティブ言語で開発するよりも、だいぶ学習コストが下がるのではないかと思いました。またサードパーティのライブラリを使えば、機能的に大きな問題となるようなことはなさそうでした。ただ、画面遷移のライブラリがそうだったように、もしやりたいことができないという場合は、妥協しないといけない部分が出てきそうだと思いました。

一方、アプリエンジニアにとっては、慣れるまではかなり開発速度が下がりそうなのでデメリットも大きいかなと思いました。ReactとJS、またReduxなども新たに理解しつつ開発していたので結構ハードルが高いと感じました。開発環境もビルドが通ってるうちは、View周りの調整がすぐに確認できて良かったのですが、ランタイムエラーになるなどで、シミュレータがリロードできなくなった場合に再度ビルドし直すということがよく起こり、常に快適に開発できるというわけではありませんでした。

運用面でみると一通りアプリ開発に必要そうなツールは揃っているし(クラッシュ監視、CI、テスト配信、リリース)、Code Pushなど便利なツールもあるので利点が多いと思いました。

結論としては、Webエンジニアが社内に多かったり、開発チームにReact、JSが得意なメンバーがいるなら、実際の開発でも使えるかなと思いました。ただ、アプリエンジニアにとってはかなりストレスがたまるプロジェクトになりそうだと感じました。

まとめ

自分の現状で考えると、アプリは得意だけどJSやReactにそこまで詳しくないので、もし直近のプロジェクトで難易度もそこそこ高いようであれば、正直あんまり使いたくないなあという気持ちがあります。ただ、技術の幅を広げるとか、組織全体のポータビリティなどの観点で考えると利点が結構あるのかなと思います。チャンスがあればぜひ、チャレンジしてみたいです。

わたしはどちらかというと技術や開発ツールの新しさよりも、ユーザとの接点のところで新しいことや面白いことを追求したいと思っていますが、開発効率や品質の向上のために最適なものを選択できるように、今後も新しいツールのキャッチアップは積極的に行っていきたいと思っています。

お知らせ

メドレーは、5/31-6/2に開催されるRubyKaigi 2018にLTスポンサーとして協賛します。ブースも構えておりますので、イベントにお越しになる方は、ぜひブースにも遊びにいらしてください!

rubykaigi.org

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