Medley Developer Blog

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

RubyKaigi 2019に朝食スポンサーとして協賛します

みなさん、こんにちは。開発本部の平木です。

2017年から、RubyKaigiにスポンサーとして参加していましたが、今年も朝食スポンサーとして協賛することになりました! f:id:medley_inc:20190412183606p:plain

(去年とおととしの参加レポート)

developer.medley.jp

developer.medley.jp

会場である、福岡国際会議場内の1Fにあるレストラン ラコンテさんでビュッフェ形式の朝食を楽しむことができます。

会期中の4/19~20日の8:30 ~ 10:00で開催しています。当日はメドレーメンバーがご案内する予定になっていますので、ぜひお気軽に話かけてください!目印として、メンバーはメドレーパーカーを着用しています。

f:id:medley_inc:20190412183045j:plain

メニューは和洋それぞれ用意があり、福岡ならではのメニューも入っていますので、1日の始まりにぜひおいしい朝食を食べて元気にセッションに臨んでください。

また、スポンサーブース内にもメドレーブースが常設されており、エンジニア4人も行く予定となっていますので、ぜひお立ち寄りいただいて、みなさんと交流できればと思います。

それでは、RubyKaigiという大きなイベントでまた皆様にお会いできるのを楽しみにしています!!

電子処方箋実証事業におけるFHIRの活用と標準化の展望

こんにちは。CLINICS事業部の児玉です。

今回は、メドレーが2018年12月に厚生労働省から受託した「電子処方箋の本格運用に向けた実証事業」で、医療情報標準規格のFHIRを基盤とした電子処方箋管理システムを構築しましたので、その内容についてご紹介します。

FHIRとは

FHIR(Fast Healthcare Interoperability Resources)とは、医療情報交換の国際標準規格であるHL7(Health Level 7)の中で最も新しい規格であり、インターネットテクノロジーをベースとした、シンプルで効率的にシステム間での情報共有を可能にする「次世代の医療情報標準規格」として世界各国で注目されています。

HL7は、世界に30以上の国際支部を有しており、日本では1998年に日本HL7協会が設立されました。そして、現在流通しているHL7規格には、データ交換に利用されるHL7v2と、医用文書の記述に利用されるCDA(Clinical Document Architecture)が存在します。

電子処方箋とは

電子処方箋とは、従来の紙に印刷された処方箋ではなく、医療機関調剤薬局が電子データを用いて処方内容をやりとりする仕組みです。単純にペーパーレス化することだけが目的ではなく、患者個人の服薬履歴を電子的に管理して、重複投薬の適正化を図るといった目的もあります。

実証事業の背景と概略

2016年3月の法令改正で、処方箋の電子的な交付が可能となり、運用ガイドラインも策定されました。しかし、法令改正から数年が経過した現在においても、実運用での課題が払拭できずに、電子処方箋の全国的な普及は進んでおりません。

f:id:medley_inc:20190328142501p:plain
ガイドラインに定められた運用フロー(電子処方せんの運用ガイドラインより転載)

元来、処方箋には医師の記名押印、または署名が必要であると医師法で定められています。現行のガイドラインは、この規則を踏襲して設計されていますので、紙の処方箋の代替としてCDAで記述された静的ファイルを必要とし、記名押印の代替としてHPKIを使用した電子署名が必要となります。

また、クライアント端末で生成された静的ファイルが、インターネットに流通するフローとなっていますので、改ざんの検知を可能とするために電子タイムスタンプを付与する必要があります。

このように複雑化された運用フローが、電子処方箋の普及を阻害する要因の1つであると考えられます。

こうした状況を踏まえ、現行のガイドラインに縛られず、円滑な運用ができる仕組みを検討するために、実際の医療機関調剤薬局を使用したフィールド実験を実施しました。


実証事業概略

  • 実施目的:電子処方箋の運用の仕組みの検討・実証・考察
  • 実施期間:2019年2月4日 - 2019年3月17日
  • 実証エリア:東京都港区
  • 協力施設:2医療機関 / 6薬局
  • 利用実績:64件

電子処方箋管理システムの概要

以下に示すのは、今回の実証事業で開発した評価システムです。本システムは「処方箋管理システム」「医療機関システム」「薬局システム」「PHRアプリ」の4つのシステムから構成されています。

f:id:medley_inc:20190328140004p:plain
システム概観


  • 処方箋管理システム

    医療機関システム、薬局システム及びPHRアプリから接続され、各システムからの処理要求を受けて、処方データと調剤データの返答、作成、編集、及び削除を行う。

  • 医療機関システム

    診療結果としての処方データを処方箋管理システムに登録し、その結果として返される処方箋アクセスコードを患者に共有する。処方箋アクセスコードはQRコードの活用を想定し、QRコードを印字した紙又は電子データを患者に共有する。

*「QRコード」は株式会社デンソーウェーブの登録商標です。
  • 薬局システム

    訪問してきた患者の本人確認を行った上で、処方箋アクセスコードを受け取り、処方箋管理システムにアクセスし処方データを参照する。処方後は調剤データを処方箋管理システムに格納する。

  • PHRアプリ

    患者がオンライン診療やお薬手帳の機能を利用するためのアプリ。処方箋管理システムへのアクセスが許可され、医療機関システムから受け取った処方箋アクセスコードを元に、調剤結果を参照することを可能にする。


医療機関システムは、メドレーのクラウド電子カルテ「CLINICSカルテ」を利用しましたが、システム連携に関わる部分については、他の電子カルテなどでも活用できるよう、疎に結合した設計を意識しました。

処方箋管理システムは、前述の通りFHIRインターフェイスを基盤として構築しました。これは現行のガイドラインには記載されていない新たな試みです。

HPKIを利用したSSO(Single Sign On)による本人資格確認と、FHIRインターフェイスを利用したクラウドベースでのデータフローを実現することが可能であれば、複雑化の要因となっている静的ファイル、電子署名、タイムスタンプは不要であると考えました。

データ設計

FHIRには「リソース」と呼ばれるデータセットが定められています。リソースは、Patient(患者)、Practitioner(施術者)、Organization(組織)といった粒度で設計されており、リソース単位でのデータ交換が可能です。

FHIRを利用するためには、その目的に応じたリソースの選定と、リソースの下位概念であるフィールドに設定する具体的な値を定義する必要があります。

例えば、日本では人名を記述する際に、漢字氏名とカナ氏名を併記することが一般的ですが、グローバル・スタンダードではありません。このような国の事情に応じて、ローカライズされた記述ルールを定める必要があります。

実証事業で使用したリソース

リソース 説明
Patient 患者
Practitioner 施術者(処方医/薬剤師)
PractitionerRole 施術者役割
Organization 組織(医療機関調剤薬局
MedicationRequest 投薬要求
MedicationDispense 調剤実施
Coverage 保険

FHIRを使用した所感

FHIRの改版はon-Goingで行われています。実証事業のための開発を始めた頃は、STU3(Standard for Trial Use 3)が公式バージョンでした。しかし、あるとき急にFHIRのホームページが接続不安定になり困っていたところ、翌日にはR4(Release 4)に更新されていたということもありました。

このように、日進月歩のFHIRをプロダクトに組み込むには、タイミングの見極めと、アップデートに追従する「覚悟」を決めることが大切だと思います。

f:id:medley_inc:20190328210514p:plain
2018年12月27日にR4がCurrent Versionになりました

FHIRの利点は、従来のHL7規格と比較した実装容易性にあると考えます。REST(REpresentational State Transfer)のように、Webサービスでは一般的に普及している概念を標準として取り込んでいるため、実装者は特別な知識を習得する必要がありません。また、FHIRを実装するためのオープンソースライブラリが豊富に提供されており、これらを活用することによって、本当に必要な処理に注力して開発することが可能となります。

臨床概念モデルとしての観点では、CDAのベースとなっているHL7v3-RIM(Reference Information Model)と比較すると、クラス、継承のようなオブジェクト指向の概念が廃止されています。あらゆる臨床概念をモデリング可能とすることを目指したRIMと比べると、さすがに表現可能な範囲は狭まると思われますが、網羅性は実用域のレベルには達しているのではないでしょうか。

また、1:1のシステム連携におけるデータ交換では、すでに稼働しているv2インターフェイスを、無理してFHIRに置き換える必要は無いと思います。用途に応じて、既存の規格と共存していくのが大切であると考えます。

実運用へ向けての課題

FHIRリソースは、臨床概念としてユニバーサルに利用可能なものを中心に構成されています。保険情報のような各国の医療制度に応じて異なるものや、調剤技法に対する「一包化」や「粉砕」などの細かな指示情報に関しては、ある程度アドホックマッピングするしかありませんでした。実装者によるマッピングのブレが生じないようにするためには、指標となるガイドラインの策定が必要になります。

また、リソースにマッピングする医薬品や用法のマスターコードについては、厚生労働省標準マスターの利用が望まれます。しかしながら、満遍なく普及しているとは言い難い状況ですので、標準マスター利用の推奨も併せてガイドラインに明記することが必要です。

ガイドラインは、メドレー1社で策定することが可能なものではなく、医療情報システムの開発に関わる多くの開発者にFHIRを利用していただき、実装方法についての議論を交わす必要があります。しかし、現時点での日本国内におけるFHIRの活用事例は、残念ながらほとんど見られません。

次にご紹介するのは、FHIRを使用した簡単なコードのサンプルと、ローカル環境でFHIR Serverを簡易的に動かす方法です。実装者の方がFHIRに触れるきっかけになればと思って書きましたので、ご参考にしていただけますと幸いです。

FHIRの実装サンプル

FHIRを理解するためには、実際にコードを書いて動かしてみるのが一番だと思います。ここでは、ローカル環境でFHIR Serverを起動して、リソースを登録する簡単なプログラムを書いてみました。(オープンソースの恩恵を最大限に享受しています。)

実行環境

FHIR Server

DockerコンテナでFHIR Serverを起動します。簡単に動かせるように、DockerHubに公開されているHAPI-FHIRのコンテナイメージを利用します。

HAPI-FHIRとは、カナダのトロントにある医療研究機関のUHN(University Health Network)が立ち上げたプロジェクトで、FHIRのオープンソースライブラリを提供することを目的に活動しています。

Dockerコンテナイメージの取得

$ docker pull petersonjared/hapi-fhir
$ docker run -d -p 8080:8080 --name=fhir petersonjared/hapi-fhir:dstu3
$ docker exec -it fhir /docker-entrypoint.sh java -jar /usr/local/jetty/start.jar

Dockerをインストールするのが面倒な人は、HAPI-FHIRがグローバルに公開しているテストサーバーを利用することも可能です。ただし、世界中の人がテストに利用しているサーバーですので、機微な個人情報は登録しないよう注意が必要です。

FHIR Client

FHIR Clientは、Rubyで動かします。以下のGemを利用します。

$ gem install fhir_client
$ gem install fhir_models

Rubyのコードです。Patientリソースを作成してFHIR Serverに登録します。

patient.rb

require 'fhir_client'

client = FHIR::Client.new("http://localhost:8080/baseDstu3")
FHIR::Model.client = client
    
patient = FHIR::Patient.new

# 患者ID
identifier = FHIR::Identifier.new
identifier.value = '12345678'
patient.identifier = identifier
    
# 患者氏名
human_name = FHIR::HumanName.new
human_name.family = 'Kodama'
human_name.given = 'Yoshinori'
patient.name.push(human_name)

# 性別
patient.gender = 'male'

patient.create
puts patient.id

上記のコードを実行すると、FHIR ServerにPatientリソースが登録されます。ここでリソースを一意に特定するリソースIDが採番されます。今回は 19953 が採番されました。(puts patient.idで確認)

このリソースIDを利用して、FHIR ServerにHTTPリクエストを送ります。

$ curl http://localhost:8080/baseDstu3/Patient/19953

そうすると、先ほど登録したリソースがJSON形式で取得できます。

{
  "resourceType": "Patient",
  "id": "19953",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2019-03-21T09:12:44.660+00:00"
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><div class=\"hapiHeaderText\">Yoshinori <b>KODAMA </b></div><table class=\"hapiPropertyTable\"><tbody><tr><td>Identifier</td><td>12345678</td></tr></tbody></table></div>"
  },
  "identifier": [
    {
      "value": "12345678"
    }
  ],
  "name": [
    {
      "family": "Kodama",
      "given": [
        "Yoshinori"
      ]
    }
  ],
  "gender": "male"
}

もちろん、患者IDなど利用して検索することも可能です。

$ curl http://localhost:8080/baseDstu3/Patient?identifier=12345678

さいごに

今回の実証事業では、FHIRのインターフェイスを活用することにより、シンプルなアーキテクチャとシームレスなフローで、迅速に処方箋管理システムの構築ができ、電子処方箋の運用評価を行うことができました。本実証事業の最終成果報告書は厚生労働省のサイトに公開されていますので、詳細について興味のある方はこちらをご参照ください。

www.mhlw.go.jp

メドレーは、実証事業で得られた知見を可能な限りオープンにして電子処方箋の普及推進に取り組むことはもちろん、インターネットを活用したオープンな技術の普及活動に積極的に取り組み、医療機関と患者の双方にとってより良い医療の実現を目指してまいります。

お知らせ

今回の電子処方箋実証事業の成果と、システム開発に活用したFHIRについて共有するイベントを、以下のとおり4月23日(火)に開催します。お時間ある方はぜひご参加ください。

techplay.jp

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

www.medley.jp

フロントエンドエンジニアがUI設計〜実装で考えていること

おはこんばんちは、開発本部エンジニアの大岡です。

先日、TechLunchという社内勉強会で「フロントエンジニアがUI設計〜実装で考えていること」という内容で発表しました。UI設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。

UI設計

UI設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独でUI設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。

とその前に、他人とUIについて話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。

  • 普通はそうする
  • 直感的にわかる
  • 使いやすい
  • わかりやすい

これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。今回何ヶ所か使っていますが実際UIについて話すときは使わないように心がけています

デザイナーから画面仕様をもらう場合

デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。

  • なぜこの課題がうまれたのか
  • 解決したい課題の本質はなんなのか
  • 他の解決策はないのか
  • この機能を追加してしまうことにより他に影響がでてしまわないか
  • 追加ではなく他の機能を落とすことにより解決できないのか
  • そもそも必要なのか

など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。

  • 似たようなコンポーネントがあったら統一できないか
  • より使いやすくできないのか
  • 操作感が他と明らかに違わないか
  • 操作に対して予想した動きになっているか
  • 表示されている情報に意味があるのか

など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。

手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめるように努力してます。

自分でUI設計をする場合

「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。

それらを踏まえ、すでに実装済みのUIで似たようなものがあれば似たように作ります。理由としては既にユーザが学習済みのUIのため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。

似たようなUIがなく新たに作らなければならないときは以下を意識しています。

  • 表示する情報の精査
  • 表示する情報はリストなのか詳細表示なのか
  • 表示する情報に対しての操作はどんなものがあるのか
  • 操作に対してのレスポンス・納得感はどうすれば得られるのか
  • エラー表示をどうするのか
  • 表示する情報が多すぎて収まり切らない場合どうするのか
  • 表示する情報がない場合どうするのか
  • 画面サイズ毎に適切に表示できるか
  • 状態(クリックやホバーなど)を表現できてるか
  • リストの場合デフォルトの順番は適切なのか

などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑

実装

細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。

  • 何も考えずにコピペしない
    • 修正が大変になるので一箇所になるべくまとめる
  • 用途にあったコンポーネントを使う
    • 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも
  • コンポーネント間の関係が疎になるようにする
    • 密接な関係だと気を使い合わなくてはならず修正が大変
  • コンポーネントを作成する際に無理に汎用性をもたせない
    • 修正が困難になり逆に汎用性がなくなる場合が多い
  • Reduxに管理させるステートの粒度は適切か
  • なんでもかんでもReduxに状態を管理させてしまっていないか
  • 無駄な再レンダリングをしていないか
  • 無駄な通信をしていないか
  • 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか
  • 関数や変数は適切な命名で適切な場所に書かれているか
  • マジックナンバーを使ってしまっていないか
    • 使ってると修正大変
  • なるべく簡単に書けないか
  • エラー・例外時の動きは適切か

など細かいことを言い出したらキリがないですが、こんなこと意識してます。

よりよいものを届けるために

いろいろと書きましたがUI設計から実装完了まではなるべく早く終わらせようと意識しています。1サイクルを

  1. UI設計
  2. 実装
  3. 触る
  4. フィードバック

とした場合に、このサイクルをリリースまでに多く回すことによってより多くの気づきが得られるからです。基本的には一回作ってうまくいくことは希かと思っているからです。

ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。

フロントエンドのUIやパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。

初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し一人でも多くの人に触ってもらい気付ける回数を増やすことは大事なことだと思っています。

さいごに

あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。

 

▼メドレーで働くクリエイターたちのストーリーはこちら

www.medley.jp

改めてBigQueryのPartitioned tablesと戯れた話

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQueryのPartitioned tableについて発表しましたので、その話について書きたいと思います。

なぜ今Partitioned table?

ある案件でユーザーの操作ログを扱う必要があり、データ保管先にBigQueryを利用しようと考えていました。その際に、「以前はβ版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。

なぜ分割テーブルを使おうと思ったのか

ユーザーの行動/操作ログの確認についてはAPIサーバーのアクセスログで、ある程度その目的を果たすことができていました。

しかし、APIアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ(通知の取得ログなどをはじめとする各種データ参照など)を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。

ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しくPartitioned tableに保存することにしました。

また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。

分割テーブルの各種方法について

まずひとくちに「分割テーブル(Partitioned table)」と言っても、BigQueryではいくつかの実現方法があります。

  • 「取り込み時間で分割」されたテーブル
  • 「特定のカラムに基づいて分割」されたテーブル
  • 「時間ベースの命名方法を使用して分割」したテーブル

前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列としてDATE型またはTIMESTAMP型を指定することで利用することができます。

こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス(スキャン対象データ量の限定、高速化)が可能になります。

注意点として公式ドキュメントにもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシーSQLを利用することができないため、標準SQLを利用する必要があります。

クエリキャッシュ

分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。

そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約(例外)があります。

今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ(パーティション)がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。

そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。(ストリーミングバッファが付いているかどうかは、WebUIのテーブル情報の詳細タブから確認できます)

f:id:medley_inc:20190315130255p:plain

データ移行

前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。

  • access_yyyymm」的なテーブルから、移行用のデータを取得
  • 必要なデータを付与
  • 移行先のテーブルにデータをinsert

とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。

やってみた

まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ...

「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」

と、怒られてしまいました。

分割テーブルの制限としてストリーミングインサートは、過去7日までしか書き込むことができないようでした。・・・と!発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて公式ドキュメント(パーティショニング オプションの比較)見てみると、過去1年まで扱えるようになっている!?ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。

最終的に

前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCSにインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。

作業当初はデータ移行を行う手段としてEmbulkを利用することも検討していました。Embulkさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。

あとから気になったので、Embulkのプラグインであるembulk-output-bigqueryを調べてみると、やはりストリーミングインサートは実装しておらず、またGCS経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも...という気持ちで今はいっぱいです ( ꒪⌓꒪)

まとめ

今更ながらBigQueryのPartitioned table周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面でBigQueryを利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。

今回のデータ移行を行った後あたりにClustered Table(beta)のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。

また、TechLunchでの発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは?と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDBはより適した用途のように思いますので、こちらも今後検証していきたいと思います。



JAWS DAYS 2019にメドレーがランチサポーターとして協賛しました

こんにちは。開発本部エンジニアの平木です。

去る2019/02/23(土)に開催されたJAWS-UG(AWS User Group – Japan)主催の全国規模での交流イベントであるJAWS DAYS 2019にメドレーが‌ランチサポーターとして協賛させていただきましたので、当日の様子などをお伝えしていきます。

f:id:medley_inc:20190228122657j:plain

会場の様子

自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場のTOC五反田メッセはイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国からAWSユーザが集まるイベントの規模の大きさが伺えました。

f:id:medley_inc:20190228122724j:plain

公式発表で1,900人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。

f:id:medley_inc:20190228122752j:plain

セッションもバラエティに富んだラインナップで見たいものが若干カブってしまっていた位で、大変有意義なものでした。

またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、JAWS-UG公式Twitterに負けず劣らず、アマゾンウェブサービス公式Twitterでイベントの様子をTweetしていたのは、さすがだなと思わされました。

メドレーのスポンサー活動

さて、そんな活気に包まれていたJAWS DAYS 2019での弊社のスポンサーとしての取り組みについてですが、今回は‌ランチサポーターとして協賛させていただきました

企業サポーターブース

まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。

f:id:medley_inc:20190228122821j:plain

パンフレットを置かせていただいていたのは、会場内で2番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。

f:id:medley_inc:20190228122855j:plain

f:id:medley_inc:20190228122904j:plain

ランチセッション

そして、ランチサポーターとしてランチセッションで弊社の田中がAWSマネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウと題したセッションでお話させていただきました。

f:id:medley_inc:20190228123004j:plain

メドレーで運営しているサービスであるCLINICSカルテをAWSを使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWSの各サービスをどのように使っているか?というお話をさせていただきました。

f:id:medley_inc:20190228123035j:plain

詳細としては

  • 医療情報システムを構成する際に準拠しなければならない3省3ガイドラインの抜粋
  • CLINICSカルテでガイドラインがシステム構成に影響を与えた部分
    • 日本国内法の適用が及ぶ場所へのシステムの設置
    • ユーザである医療機関の使用するアプリ側でTLSクライアント認証を実施
    • ユーザアカウント毎の権限管理と各種操作ログの管理
  • AWS東京リージョンへの移行や、システム構成をAWSの各サービス(ECSfargateNLBなど)を使いながらTLSクライアントに対応していった話 セキュリティを強固にするためにAWSサービス群をどのように使用しているかの話

といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。

f:id:medley_inc:20190228123114j:plain
セッションが終わって一安心した田中

最後に

イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました!

メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽にお問い合わせいただければと思います。

デザイナーがブラックボックスを作らないためにできること

 

f:id:medley_inc:20190221150235p:plain

 こんにちは。昨年末にクリエイターズストーリーが公開され顔面が白日のもとにさらされ『イケメンじゃなくね?イケメンつーか犯罪者顔じゃん!』と影口たたかれてないか不安な日々をおくる開発本部のガラスのハートことイケメン担当デザイナーの小山です。
 
さて今回は先月末におこなった社内の勉強会の内容をご紹介させていただきます。
 

 
デザインのプロセスは、時代とともに明らかになりつつあり、個人主導より参加型のデザインワークが主流になりつつあります。例えばサービスデザインはステークホルダーと課題を協議しながら解決策を見出していきます。視点は異なりますが、デザインスプリントも各参加者の視点や思考を総動員して短期でプロダクト(解決策)を作り出す手法です。
 
関係者が参加したデザインプロセスにより出来たデザインを製品レベルへ品質を高めるため、デザイナーの手によってブラッシュアップされていきます。この段階から本格的にデザイナーの感覚由来の思考が組み込まれ、プロダクトが洗練されていきます。
 
ですが、思考が組み込まれると、周囲とは別世界の領域として扱われている感覚になることがあります。どういう思考プロセスを経て、デザインされたのか周囲は触れることができません。それゆえに、周囲はデザインにおいての思考プロセスはデザイナー頼みになりやすく、作業依頼の最後の決まり文句として『いい感じに!』という言葉を掛けがちです
 
こうした周囲が踏み込みづらい距離感が生まれてしまうのは仕方のないことだと思っています。
原因は、デザイナーの感覚由来の思考プロセスが共有されない状態=ブラックボックス化にあります。またデザイナーが自発的にブラックボックスをオープンにして、周囲の目に留まる環境を用意できていない点も原因としてあります。
目に留まる環境ではないため、周囲はアウトプットだけしか注目できず『いい感じに!』以外の言葉を掛けようがありません。
 
デザイナーは、色や形を論理的な思考と感情的な思考の掛け合わせでアウトプットします。目では見えにくいプロセスに突入するので、周囲からは抽象的で曖昧な領域と思われがちです。
今回は、これまでの経験の中で最もその『曖昧な領域と思われがち』だと感じている余白について、デザイナーの視点でご紹介*し、ブラックボックスの中身を少しお見せしたいと思います。
 
*個人的見解なので世のデザイナー全員に当てはまる訳ではないことをご理解いただければ幸いです。
 

 
余白について
 
みなさん、余白の言葉の意味はご存知ですか? 辞書では  “文字などに書いた紙面の何も記されないままで残っている部分”と記されています。字面としては言い得ているのですが、デザイナー視点ではこれがてではありません

f:id:keisukekoyama:20190221220602p:plain


もちろん”何も記されていない”が余白の前提なのですが、なぜそれが必要か?が重要です。

まずは余白の機能から説明します。余白には最も伝えたいメッセージを視覚的に浮き彫らせ、理解を促す効果があります。多種多様で氾濫した情報から希望したものを抜き出すプロセスを、見ている人に強いるのではなく、デザインが肩代わりします。
 
昨今の日本のデザインは、見ている人の情報に対しての許容量が増え、膨大な量を詰め込んでも理解してもらえる場面が多々あります。
ただスタミナが必要です。スポーツをするのと同じように情報に触れるだけで人はスタミナを消費します。そして、人間であればスタミナには限りがあります。
 
デザインは、その限りあるスタミナを情報の探索に使うのではなく、本来の目的に沿った行動に運用できるような仕組みに整備します。その手段の1つとして余白があります。
 
f:id:keisukekoyama:20190221220641p:plain
 
余白は目的ではなく情報を届けるための1つ手段です。
届けたい情報がどういう文脈であるべきなのか、そことセットで考えなくては余白や目的が破綻します。このプロセスが抜けおちた状態でプロジェクトが成功してしまうとブラックボックス化が進みます。
そうすると周囲の参加が難しい状況になり、『なんだかわからないけど良いだろう…』という状況に陥ります。いつまで経ってもデザインの思考プロセスは理解されないままの状態が続くでしょう。そのために余白を意味あるものとして文脈が必要となります。
 

f:id:keisukekoyama:20190221220659p:plainApple Store 表参道店 店内 Photo by wongwt

 
f:id:keisukekoyama:20190221220716p:plain
ヨドバシカメラの店内   Photo by chesterbr
 
文脈は明快であるべきです。その例としてAppleStoreとヨドバシカメラがあります。AppleStoreは電化製品を扱う店舗の部類としては、延べ床面積に対しての商品数が極端に少ないお店。電化製品としてではなく、利用者の人生に大きな影響を与える重要なプロダクトになり得るものを提供しているプライドが伺えます。高級ブランドに近い売りかたですね。
 
ヨドバシカメラは様々なメーカーの商品を一度にそして大量に伝達するために、より多くの商品を陳列します。世の中には商品が多くありその全てをありのままに伝達しスタッフのアドバイスを受けながら最適解を導き出す戦略です。
この2つの店舗の場合、それぞれ余白はどうあるべきなのかその機能や意味が見出せます。
 
AppleStoreは通路を広くとり、商品を最も強調させるために机以外のノイズを限りなく削ぎ落とし、空間デザインにおいても余白を有効活用しています。物理的な余白を意図的に作ることで、商品に人の視線や意識が集まりやすくなり、より魅力が伝わる設計がなされています。
 
一方、ヨドバシカメラは様々なメーカーの商品を多く陳列することで横断して比較でき、自分にあった商品を見つけられる購入体験を実現します。そのために狭いスペースの中に如何に商品を詰め込められるかを念頭に設計しているように見えます。そこに余白はどこにもなく情報の洪水が押し寄せているように感じられます。
 
ですが、余白はしっかりあります。それは人の頭の中です。
ヨドバシカメラは種別ごとに商品をしっかりまとめ、近しい情報であれば同じ見栄えのポップで整理し、遠くからでもどこにあるか商品がわかりやすいように陳列の技術を駆使し、来店する人のスタミナの消費量を軽減しています。
 
情報の整理をすることで、探す労力を利用者に強いることなく、無意識のうちに理解できるスイッチが入るように設計しています。ヨドバシカメラの場合は物理的な余白をとるのではなく、意識下に余白を作り出している高度な設計をしています。
 
文脈を設計し伝えるべき情報を効率良く届けるために、余白は様々な手段があります。2つの事例をあげましたが、ここには物理的な余白、そして意識的な余白があります。
 
主にUIデザインする個人的な意見ですが、余白の真の意味は、利用する側の頭の中の情報を整理し、スタミナ消費を軽減し意思決定のアクションを促せる『余地』を作ることにあると思っています。
 

 
と、自分なりの余白の考えをお話しました。普段の業務の中でデザイナーの立場として、こうした話をする機会はなかなかありませんしかし考え話すことでデザインに周囲が参加できる素地を作らなければ、いつまで経っても、「いい感じにつくって」の状態から逃れられません。
 
デザイナーの役目として作ることは大前提。しかし、単に手を動かして作るだけでは意図を理解されにくいため、対話を通して思考プロセスを共有しないとその後の改善はその場限りになります。これはデザインに限りません。
事業編成による人事異動や事業規模の拡大など大きな変化のなかでも作り続けれるようにするために、余すところなく言語化し共有することが大事だと思います
 
メドレーには凡事徹底9箇条という仕事の質を高める指標があり、全社員がそれを意識しています。その指標の1つに『ドキュメントドリブン』というものがあります。全てを記録し共有できる状態にし無駄な取り組みをしないというものです。またドキュメントドリブンやドキュメントそのものの意味は、次の人にバトンを渡すことでもあると思っています。
 
言語化されたデザインの思考プロセスは、デザイナー以外にバトンとして次に繋ぐことで、本当にプロダクトが良いものになるのか、検証と改善を継続できるようにする道しるべにもなります。
 
幸運にもブラックボックスを開けて周囲を巻き込むはたくさんあります。冒頭の手法以外にもライブデザイニングという手法があります。これはデザイナーのデザイン業務や思考プロセスを公開しながら進めていくものです。詳しくはこちら
 
弊社のデザイナーはプロダクト毎に、一人専任でデザインを任されています。それだけに重要な仕事を任される面白さはあるものの、デザイナーの感覚由来の思考プロセスで解決策が生まれやすい状況とも言えます。
 
デザインはデザイナーだけのものではないので、チームならチームに組織なら組織に思考のプロセスを明らかにすることで、新しい発見や解決策が生み出せるかもしれません。その機会をデザイナーから作り出し、より良い事業推進に貢献できたらと思います。
 
最後まで読んでいただきありがとうございます。
 

お知らせ

メドレーでは医療業界に存在する課題にITを駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。

皆さまからのご応募お待ちしております。

www.medley.jp

2019年、今年も開発本部キックオフ合宿に行ってきました!@河口湖

こんにちは、開発本部の日下です。
インターンを経て新卒としてメドレーに入り、エンジニアとしては2年目となりました。
現在は医療介護の求人サイト「ジョブメドレー」の開発をしております。
 
先日、恒例となった年始の開発本部キックオフ合宿を河口湖で行ってきましたので、詳細をレポートします。 

キックオフを年始に行う意義

メドレーの開発本部では毎年年始に開発本部全体でキックオフ合宿を行っています。
合宿を年始に実施する意義昨年もまとめましたが、再掲すると次の二つになります。

親睦を深める

一つ目はチームビルディングにあります。
 
合宿ではアクティビティやバーベキュー、キックオフプレゼンなど、みんなで一つの場所で同じ時間を共有するイベントを行っています。
同じ時間を共有することで、より一体感をもち、連携の取りやすい関係性を醸成することを目的としています。
 
実際、より長い時間を共有することで、普段知ることのできない仲間の一面を見ることができるなど、よりお互いの理解を深める事ができる時間が過ごせます。

f:id:medley_inc:20190208133854j:plain

今年の方向性を共有する

二つ目は今年一年の開発本部としての方向性の共有にあります。
 
普段開発していると、全体のことを考える時間はなかなか取りづらいかと思います。
そこでメドレーでは普段の業務から一旦離れた場所で、開発部全体としてどういった動き方をしていくのかという認識を作る機会を作っています
 
これが合宿を年始に行う理由にもなっています。

合宿先・アクティビティの紹介

合宿先の紹介

合宿先は昨年と同じ河口湖カントリーコテージbanさんにお世話になることにしました。
昨年よりメンバーが増えたため、昨年より少し大きなコテージを借りての実施となりました。
 
コテージも夜景も美しく、とても満足のいく環境でした。

f:id:medley_inc:20190208133927j:plain

ワカサギ釣り

合宿ではリフレッシュを兼ねたアクティビティを行っており、今年はワカサギ釣りでした
 
ワカサギ釣りと言われると氷に穴を開けて糸を垂らすイメージが強く、極寒の中で行うのではと思われる方もいるかもしれません。
今回お世話になっマリンハウスmomoさんのプランでは、提供されたドーム型の船の中で釣ることができたため非常に快適でした。
(先日の週間メドレーで着ていたライフジャケットは、このドーム型の船に乗るためのアイテムでした。)

f:id:medley_inc:20190208134010j:plain

 
ワカサギは群れで移動する魚らしく、ちょうど群れが来たときはまさにフィーバータイム。釣り糸を垂れるとすぐにかかるので、とても楽しめました。

f:id:medley_inc:20190208134024j:plain

5匹一気に釣り上げ喜ぶCTO

釣りが得意なメンバーはバケツ満杯に釣れるなど、釣果は上々。当初釣れた数を数える予定でしたが、あまりにも多すぎたため途中で数えるのをやめてしましました。

f:id:medley_inc:20190208134051j:plain

袋いっぱいのワカサギ。多すぎて2袋に分けたうちの一つです。

釣れた魚は合宿先に持ち帰り、唐揚げにしたり串焼きにしたと、食事でも楽しめるとても良いアクティビティでした。

f:id:medley_inc:20190208134120j:plain

一気に焼くために串に刺されるワカサギ
くさみもなく、とても美味しかったです。

2019年の開発本部キックオフ!

アクティビティのあとはコテージに移り、お風呂やバーベキューの準備をしながらお酒を少し入れたタイミングで、2019年キックオフプレゼンをCTO・平山が行いました。

f:id:medley_inc:20190208134432j:plain

 
まずは昨年の振り返りから。昨年も各プロダクト大きな変化がありました。
 
JobMedleyはユーザ数が順調に伸び、テレビでCMをするほどの規模に成長CLINICSカルテのリリース、介護のほんねのリニューアル、MEDLEYは医師向け機能の強化をするなど、プロダクトを大きく成長させました。
 
また会社としては、医療ヘルスケア分野における技術のオープン化、および情報活用を推進すること目的としたMEDLEY DRIVEという大型プロジェクトを開始しました。
他にもセキュリティ強化を目的としてISMSとISMSクラウドを取得するなど、攻める一方で守りの面も強化された一年でした。
 
次に開発本部の2019年について。
 
目指すべき未来を示しつつ、なぜ?どうやって?といった基本的な考え方を共有することで、メンバーの中に納得感ができたキックオフになりました。

f:id:medley_inc:20190208134505j:plain

 
個人的には昨年から関わるプロダクトが増えたため、これまで感じてきたプロダクトの成長を振り返ることができました。
また今年はどういったことができるか考える良い時間になりました。
 
平山のプロダクト・事業・会社に対する熱い思いはメドレー平山の中央突破にも詳細に書かれていますので、ぜひご覧ください。

バーベキュー

恒例のキックオフ後のバーベキューもみんなでワイワイしながらの実施となりました。
 
今年は人数が昨年同月比1.5倍ほどになったのもあり、昨年より賑やかな会となりました。

f:id:medley_inc:20190208134558j:plain

f:id:medley_inc:20190208134604j:plain

今年は自前の燻製器を運び込んだ猛者も

f:id:medley_inc:20190208134610j:plain

恒例となっているバーベキュー

食べて飲んで寛いで、プロダクトや組織への思いなどお酒を交えつつ談笑し、夜遅くまで楽しい時間を過ごしました。

まとめと感想

メドレー開発本部合宿の様子はいかがだっだでしょうか?少しでもその様子が伝わっていれば幸いです。
 
今年の合宿も、メンバー同士が物理的に近い状態で同じ体験をする時間を通じ、相互理解を深めたり共通認識を持つことのできる良い機会となりました。
 
昨年よりいろいろな人が増えたおかげで、バラエティの富んだ時間を過ごすことができたのは良い発見でした。
また人が増えたものの雰囲気としては昨年と変わらず進められたことは、組織としてのメドレーらしさのようなものが醸成されている証ではないかと感じています
 
個人的にもプロダクト的にも昨年は一昨年に比べて変化の激しく楽しい年だったように思います。
今年はより変化のある一年になりそうということもわかり、今から期待に胸を膨らませています。
 
改めてこういった時間を開発本部としてとるタイミングがあるのは良いことだと、再度認識することのできた時間となりました。
 

最後に

最後に、今回の合宿の企画運営を行って頂いた新居さん、忙しい中本当にありがとうございました!

f:id:medley_inc:20190208134755j:plain

また来年も合宿しましょう!
メドレーでは、このようなチームで新しい医療体験を提供するプロダクトを一緒に創るディレクターやエンジニア、デザイナーを募集しています。
 
ご興味ある方は、お気軽に話を聞きにお越しください!!