Medley Developer Blog

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

NDBオープンデータをオープン化してみた話

開発本部の平山です。先日、社内勉強会「TechLunch」にて社外に公開できない内容の発表をしてしまいましたので、その代わりとして、厚生労働省が提供する「NDBオープンデータ」をオープン化した話について、ブログを書こうと思います。 

NDBオープンデータとは?

www.mhlw.go.jp

作成の背景

◆ レセプト情報・特定健診等情報データベース(NDB)は、悉皆性が高いレセプト情報、および検査値などの詳細な情報を有する特定健診等情報が含まれており、国民の医療動向を評価するうえで有用なデータだと考えられている。

◆ 2011年度より、医療費適正化計画策定に資する目的以外でのNDBデータの利用が認められたが、NDBデータの機微性の高さに鑑み、利用者に対しては高いレベルのセキュリティ要件を課したうえで、データ提供が行われてきた。

◆ 一方で、多くの研究者が必ずしも詳細な個票データを必要とするわけではないため、多くの人々が使用できるような、あらかじめ定式化された集計データをNDBデータをもとに整備することが重要ではないか、という議論が有識者会議等でなされてきた。

◆ NDBの民間提供に関する議論でも、「レセプト情報等の提供に関するワーキンググループ」からの報告では、汎用性が高く様々なニーズに一定程度応えうる基礎的な集計表を作成し、公表していくことがむしろ適当である、という指摘がみられた。 

作成の目的

◆ 多くの人々がNDBデータに基づいた保健医療に関する知見に接することが出来るよう、NDBデータを用いて基礎的な集計表を作成したうえで、公表する。

◆ NDBデータに基づき、医療の提供実態や特定健診等の結果をわかりやすく示す。

 

要は皆さんが、病院に行った時にもらう明細書に記載されている初診〇〇点、外来診療料〇〇点のようなデータが個人情報が匿名化された状態で収集しその統計データを一般に公開する、といったところでしょうか。


このようなデータがオープンになっていることはとても意義のあることだと思いますし、公開にまでこぎつけた関係者の苦労が想像されます。しかし、このような画期的なデータ提供ではありますが、Excelファイルでの提供となっており、かつ加工がしづらいデータ構造になっているため、データを細かくみてみようとすると非常に手間がかかるという問題があります。

 

NDBオープンデータのオープン化

そこでNDBオープンデータとして公開されているExcelファイルを加工し、DBに格納しBIツール(Redash)から参照させるようにしてみました。

1. データ加工 & DB取り込み

公開サイトにある医科診療行為に関するExcelファイルを取得し、ログテーブルとしてよくあるフォーマットに変換しDBに取り込む。

変換前

f:id:medley_inc:20170721150757p:plain

変換後

*************************** 1. row ***************************
id: 1
practice_category_code: A000
practice_category_name: 初診料
practice_code: 111000110
practice_name: 初診
practice_type: 外来
target: all
revision: 2014
prefecture:
sex:
age:
score: 251700771
created_at: 0000-00-00 00:00:00
updated_at: 0000-00-00 00:00:00
*************************** 2. row ***************************
id: 2
practice_category_code: A000
practice_category_name: 初診料
practice_code: 111000110
practice_name: 初診
practice_type: 外来
target: sex_age
revision: 2014
prefecture:
sex: 男性
age: 0~4歳
score: 13158090
created_at: 0000-00-00 00:00:00
updated_at: 0000-00-00 00:00:00
*************************** 3. row ***************************
id: 3
practice_category_code: A000
practice_category_name: 初診料
practice_code: 111000110
practice_name: 初診
practice_type: 外来
target: sex_age
revision: 2014
prefecture:
sex: 男性
age: 5~9歳
score: 12444947
created_at: 0000-00-00 00:00:00
updated_at: 0000-00-00 00:00:00

2. データの参照

変換したデータを取り込んだDBをRedashから参照。分析したいデータを取得するためのクエリを書いてダッシュボード化。

 ※ お試し環境を構築したので興味のある人はさわってみてください(@gmail.comGoogleアカウントでログインできます)。

 

お試し環境(期間限定) -  http://sandbox.medley.jp/dashboard/ndb

f:id:medley_inc:20170721153210p:plain

f:id:medley_inc:20170726125246p:plain

NDBオープンデータの活用例

以下に簡単なデータ活用のサンプルを載せました。医薬診療行為だけでなく特定健診や薬剤のデータを使うともう少し面白い気付きがあるかもしれません。

いずれにせよ、このように加工可能な形でのデータ提供こそがオープンデータ提供の価値だと思うので、このような仕組みが加速すれば良いなと思います。

0-4歳 男性 診療行為点数

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

90歳以上 男性 診療行為点数

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

140023350 胃瘻より流動食点滴注入 都道府県別

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

150086210 角膜移植術 年齡別

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

まとめ

以上、NDBオープンデータをオープン化してみた話について書いてみました。

このように*.go.jp から提供されるデータは一般的にExcelやPDFでのファイル提供が基本で、インターネットサービスのようにAPIのような形で提供されることはありません。せっかく貴重なデータが提供されているにも関わらず、それがITシステムと連動しづらいことで、活用されない状況になっているのはとても残念なことに思います。Code for Americaの事例ではないですが、もっとインターネット系の人材がこのような取り組みに入り込んでいくようになれば、より合理的でスマートな仕組みが加速し、業界全体のIT化も加速するのではないでしょうか。

お知らせ

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

メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

www.medley.jp

デザイン言語システムを入れたらコミュニケーションコストがぐっと下がった話〜メドレーTechLunch〜

ビールが美味しい季節ですね!

最近飲みすぎて嫁に叱られて、飲み会自粛中のデザイナー・マエダです。

メドレーではTechLunchという社内勉強会を実施しているのですが、デザインについて私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「DLSの導入について」です。発表資料は記事の最後をご覧ください。

DLS(デザイン言語システム)とは

DLSとはDesignLanguageSystemの略で、すごい単純にいえばデザインガイドラインみたいにUIに一貫性をもたせるため、配色やレイアウト、タイポグラフィやマージンなどのルールを策定するものです。

私が主に担当しているオンライン診療アプリ「CLINICS」は、iOSAndroid、Webと3つのプラットフォームで運用しているのですが、入社した当初はプラットフォーム毎に違ったUIやルールで開発しており、サービスとして一貫性のあるサービス体験を提供できるとは言えない状況でした。また新たに機能を追加する際、それぞれ違なるデザインをしなければならず、デザイン作業においても負荷がかかっていました。

DLSが必要な理由

CLINICSではプラットフォームごとに異なるUIを提供していたため、一貫したサービス品質をユーザーに提供できていないこと、開発者ごとにUIに対して認識にズレが生じていたことが課題でした。それに伴い開発速度も決して速いとは言えず、どうにか一定の品質を担保しつつ開発スピードも改善できないかと悩んでいたところ、Airbnbの開発者ブログでAirbnb Design Systemという記事を見かけました。

これまでのデザインガイドラインは単にカラーやマージンの定義を取り決めるだけだったのですが、Airbnbではデザイン言語として定義し、他の言語と同じようにチームと共有し、エンジニア・デザイナー同士で理解できる設計を作り上げているといった内容でした。

※参考

medium.com

私がデザイナーとしてサービスデザインに携わる重要な役割のひとつとして、単にデザインをするだけでなくデザインを通してUI設計の制約をつくり、継続的に運用しやすいプロダクトに仕上げることがあると思っています。

DLSを起点として、各プラットフォームの開発者が共通の認識でシステム開発が行えれば、これまで以上にスピーディが開発が行え、一貫性のある体験をユーザーに提供できるプロダクトにできるはずだと考え、CLINICS独自のDLSを開発することにしました。

f:id:dev-medley:20170725121754p:plain
CLINICSのDLSの一部

 

DLSを導入してどうなったか

CLINICSでは、AndroidiOS、webで担当するエンジニアが異なるのですが、DLSを設計しシステムの詳細を共有することで、UIに対しての共通認識が生まれ、一貫した品質を担保できるようになりました。さらにこれまでエンジニアだけでデザインを考えて悩んでいた時間を、コンポーネント設計で組み立てたデザインをDLSで定義したことで、UIに悩むことなく機能ロジックに重点を置いた開発に専念できるようになったのではないかと思います。

デザイン言語でサービス設計の基礎を築けたことで、開発だけに追われていた状況から、より良いサービスを作るためにはどんなUXをユーザーに提供すべきかという声がエンジニアからも頻繁に声が上がりはじめたことも良かった点です。

f:id:dev-medley:20170725122157j:plain
エンジニア陣がUIについて熱い議論を交わしている様子

TechLunchでは、こうした内容について実際に作ったコンポーネント設計なども見せながらお話しました。発表資料はこちら。

speakerdeck.com

まとめ

DLS導入以前は、エンジニアが開発に追われていたということもあり、プラットフォーム毎に議論ができていなかったエンジニアがお互いの担当プラットフォームを意識したコミュニケーションがとれるようになったことは予想外に良かった点です(別に仲が悪かったとかそういうことではなくw)。

さらにDLSでUIの基盤をつくったことで、デザイナーが手を動かさずともコンポーネントの組み合わせを話し合うだけで、エンジニア完結で一貫した品質で機能実装できるようになりました。これにより私も次の施策やプロジェクトに専念できるようになり、効率的に仕事ができるようになりました。

まだデザインルールに一貫性がないプロジェクトを担当しているデザイナーやエンジニアは、ぜひDLSの導入を検討してみてはいかがでしょうか。
単にデザイン品質だけでなく、チームコミュニケーションも改善されるとおもいます。

より詳しく話を聞きたいかたは、気軽に「話を聞きに行きたい」をクリックしてみてください。ビールを飲みながらデザイン談義をしましょう!(嫁に怒られない程度にw)

 

メドレー開発本部について、もっと詳しく知りたい方はこちらからどうぞ。

www.medley.jp

www.wantedly.com

元フロントエンドエンジニアから見たAndroid開発

今回の内容について

みなさん、こんにちは。開発本部でオンライン診療アプリ「CLINICS」の開発を担当している平木です。

弊社では、インフラ・サーバ・フロントで役割を区切らず、全ての開発メンバーが必要に応じてスキルを広げながら開発に取り組んでいます。 自分も入社前はフロントエンド専門のエンジニアでしたが、入社後はそれに加えてRailsを使ったサーバサイドの開発や、Swiftを使ったiOSアプリ開発、 そして、現在メインにやっているAndroid開発と一通りのプラットフォームや言語を使って開発するようになっています。

エンジニアが自身のスキルを広げる場合、自分の経験や知識を応用して、新しいプラットフォームを理解していくということが多いと思います。

元フロントエンジニアの経験を持っている自分がAndroid開発に関わってみて やりやすかった部分つらかった部分などを書いていこうと思います。同じような立場でこれから開発しようと思う方には少しお役に立てるかもしれません。

やりやすかった部分

Android Studioのありがたさ

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

いきなりIDEの話になっていますが。やはりAndroid Studioのオールインワン感がとても便利です。Webフロントエンドの開発だとIDEといえば WebStormなど使ったことがありましたが、ライブラリを含めた補完周りなどはやっぱりJavaなどでの開発した方がIDEは力を発揮しやすいんではないかと思いました。

とりあえずほとんど設定をいじらなくても、補完やドキュメントの参照ができるのはラクです。またJSなどで変数に変換してもあんまり便利さが湧きませんが、 Javaの場合だと勝手に対応した型もつけてくれたりと至れり尽くせりだと思いました。

ゲッターセッターなども手作業でやると単純作業になりますが、⌘Nで勝手に展開してくれますし、Javaでの開発の冗長な部分をあまり感じないで開発できるのが凄いです。

エミュレータなども自分が使い始めたときは既に起動も高速な感じでしたし、エミュレータの管理などもAndroid Studio内で完結するのであまり迷ったりすることがないです。また初心者に優しいなと思ったのが、Activityなど作るのにテンプレートがちゃんと用意されてるのであまりファイル構成が分かってない初めの頃でもちゃんと画面を作ることができるところです。

ビルドシステムが分かりやすい

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

ご存知Gradleですが、通常の使い方してる分には(あまりGradleでがんばらなければ)、WebPackとかよりも書きやすいよねと思います。もちろん目的が違いますが。

フロントエンド開発でよく陥りがちな「設定ファイルなんだかプログラムなのか分からないくらい作られた」というような設定ファイルにはなりにくいんじゃないかと感じています。

build.gradle で設定した環境変数などもソースからさっと使うことができますし、良く考えられてるなーと思いました。

公式のライブラリであれば、 build.gradle でlintとしてライブラリの更新があることが分かるのも親切です。サードパーティのライブラリもこれがされてるととても嬉しいんですが、 Analyze -> Run Inspection by Name -> Newer Library Versions Available で見てくれるんでガマンしてます。

View部分の作り方がフロントエンドに似ているので取っつきやすい

これはHTML / CSS を書いていた人間からすると大変に敷居が低いと思いました。

使うパーツは最初はどんなものがあるのか分からないのでドキュメント引いたり、 Design タブからパーツを選択したりしてViewを作ってましたが、HTMLを組む感覚でガンガンと作っていけました。

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

基本的にはHTMLタグのなかで style 属性付けていくみたいな感じです。margin とか padding とかも同じですし、textAlign なんかもあるので初期のころは本当に助かりました。

もちろん AppBarLayout とか Toolbar とか Theme などAndroid独自の概念はありますがそういった差分的なものは知識として覚えていけば良いだけなので、フロントエンドに慣れていると大変にView作るのがラクだと感じます。

iOSのStoryBoardは未だにつらい。

ググったときに古めの情報を参考にしても問題が解決できる後方互換性の高さ

ここ数年フロントエンドの技術的な流れが早すぎるというのは一般的に良く言われていますが、良い意味でAndroidは古い情報もちゃんと使えるというのはとても助かりました。

一番古いので2011年くらいの情報だったら使えました。(もちろん廃止されてる…というのも多いのですが)

初めのうちは フロントエンドだとこうやるけどAndroidではどうするんだろう というような疑問が多いと思うのですが、特にViewに関わるような問題などは古い記述でも問題なく使える後方互換性の高さのおかげで「ググったように書いたのに、今は使えない…」というストレスからかなり開放されます。

つらかった部分

ライブラリや画像を気軽に入れにくい

これついては、フロントエンドのJSなどでも別に気軽にさくさくとライブラリを入れていたわけではないですが、いざ入れようとするとAndroid(というよりもネイティブアプリ全般か)の場合全てAPKの容量増加という自体に直結するので中々気をつかいます。

さすがにゲームでもないのに容量重いアプリにするとそもそもダウンロードしてもらえるかどうかも怪しくなります。パッケージする画像なども多用するような仕様にしないようにしています。

あと最初のころにビルドできずに困るわ…と思って必死に対応を調べた 64K 参照制限 も一回設定してしまえば何てことはないんですが、割と初見殺しだと思います。

また実際にプロダクション用にビルドするとなるとフロントエンドでもおなじみのソースの難読化をするのですがその際にライブラリのなかで難読化しちゃいけないなどの指定をしないと余裕で動かなくなります。

ということで各ライブラリを使うときにはProGuardの設定をしないといけないのですが、これも気軽にライブラリ使おうと中々ならない理由でした。

バッググラウンドプロパティ関連の貧弱さ

良い点のところでHTML / CSS とViewの作りが似ているので幸せと書いたんですが、1つだけ許せないことがありまして、それが バックグラウンドプロパティ関連のプロパティの貧弱さ というものです。

どういうことかというと…例えばこんな感じのラベル作るとします。

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

HTML / CSSだったら楽勝だと思います。

<span class="radius">診察待ち</span>
.radius {
  border-radius: 12px;
  padding: 4px 12px;
  background-color: #89C8BA;
  color: #FFFFFF;
}

しかしAndroidの場合は

<TextView
    android:id="@+id/upcoming_list_status"
    android:textSize="14sp"
    android:layout_width="100dp"
    android:layout_height="wrap_content"
    android:textAlignment="center"
    android:background="@drawable/label_status_upcoming"
    android:textColor="#FFFFFF"
    android:text="診察待ち" />

とテキスト作ったうえで、 background の指定先のベクターアセットを作ってやらないといけません。 このアセットが paddingbackground-color など指定されているというものになります。

<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item>
        <shape android:shape="rectangle">
            <stroke android:width="1dp" android:color="@color/label_status_upcoming" />
            <corners android:bottomLeftRadius="12dp" android:bottomRightRadius="12dp" android:topLeftRadius="12dp" android:topRightRadius="12dp" />
            <solid android:color="@color/label_status_upcoming" />
            <padding android:left="12dp" android:right="12dp" android:top="2dp" android:bottom="2dp" />
        </shape>
    </item>
</selector>

とても面倒です。

リストがつらい

配列になっているデータを取り出してリストとして表示するという状況、良くあると思います。 フロントエンドなら <ul/> で囲んだなかの <li/> にデータを forEach() やら map() やら使って作っていくのが常道ですが、Androidは手順が多いので面倒です。

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

このようなお知らせのリストを作るのに…

public class NotificationItemHelper {
    private String message;
    private String link;
    private String patientName;

    public NotificationItemHelper(String message, String link, String patientName) {
        this.message = message;
        this.link = link;
        this.patientName = patientName;
    }

    public String getMessage() {
        return message;
    }

    public String getLink() {
        return link;
    }

    public String getPatientName() {
        return patientName;
    }
}

リストに表示するためのクラスを作ってあげて、

public class NotificationListAdapter extends ArrayAdapter<NotificationItemHelper> {

    private int layoutResource;

    public NotificationListAdapter(Context context, int resource, List<NotificationItemHelper> objects) {
        super(context, resource, objects);
        this.layoutResource = resource;
    }

    @NonNull
    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
        View view = convertView;

        if (view == null) {
            LayoutInflater layoutInflater = LayoutInflater.from(getContext());
            view = layoutInflater.inflate(layoutResource, null);
        }

        NotificationItemHelper notificationItemHelper = getItem(position);

        if (notificationItemHelper != null) {
            TextView message = (TextView) view.findViewById(R.id.notification_list_message);
            TextView patientName = (TextView) view.findViewById(R.id.notification_list_patient_name);

            if (message != null) {
                message.setText(notificationItemHelper.getMessage());
            }

            if (patientName != null) {
                patientName.setText(notificationItemHelper.getPatientName());
            }
        }

        return view;
    }
}

それをViewに表示させるためのAdapterというものを作り、

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/upcoming_list"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:paddingStart="@dimen/spacing_small"
    android:paddingEnd="@dimen/spacing_small"
    android:orientation="horizontal">

    <LinearLayout
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_weight="1"
        android:paddingTop="@dimen/spacing_small"
        android:paddingBottom="@dimen/spacing_small"
        android:orientation="vertical">

        <TextView
            android:id="@+id/notification_list_message"
            style="@style/TextBoldStyle"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:layout_marginBottom="@dimen/spacing_xsmall" />

        <TextView
            android:id="@+id/notification_list_patient_name"
            style="@style/TextNormalStyle"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:layout_marginBottom="@dimen/spacing_xsmall"
            android:textColor="@color/text_color_secondary" />
    </LinearLayout>

    <ImageView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="end|center_vertical"
        android:src="@drawable/ic_keyboard_arrow_right_black_24dp" />
</LinearLayout>

実際のリストの内容をxmlで作ってあげて、

<ListView
    android:id="@+id/notification_list"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

リストのラッパーを指定して

List<NotificationItemHelper> notificationItemList = new ArrayList<>();
ListView notificationListView = findViewById(R.id.notification_list);
List<NotificationResponse> notifications = notificationsResponse.getNotificationResponses();
for (Notification notification : notifications) {
    NotificationItemHelper item = new NotificationItemHelper(
            notification.getMessage(),
            notification.getLink(),
            notification.getPatientName());
    notificationItemList.add(item);
}

NotificationListAdapter notificationListAdapter = new NotificationListAdapter(this, R.layout.notification_layout, notificationItemList);
notificationListView.setAdapter(notificationListAdapter);

ここまでやってようやくリストが表示されます。未だに面倒だなーと思います。

最後に

色々と細かい例を上げましたが、いかがでしょうか。

今回は書いてませんが、ライブラリもJSとは考え方違って面白いなあと思うものがあります。特にViewパーツを簡単に選んだり、イベントを書くことができるButterKnifeやバリデーションライブラリのAndroid SaripaarのようにJavaアノテーションを付けるだけで簡単に使える部分などはJavaに触れてこなかった身としては新鮮でした。

全体的な印象としてはプラットフォーム特有のクセなどはもちろんありますが、フロントエンドエンジニアでもかなり取り組みやすいのではないかと感じています。何よりAndroid実機で自分が作ったものが動いてるのを見るとブラウザで自分が作ったサイトが動いているというのとは一味違った達成感があります。

もちろん開発していく内に、たとえばJSにはないスレッドの概念が立ち塞がったりAndroid特有のライフサイクルに悩まされたりもしますが、公式のドキュメントも充実していますし、Stack Overflowなど見て解決することがかなり多いです。

これを読んでAndroid開発やってみようと思っていただけたら良いなと思います。 もっといろいろ知りたいという方は「話を聞いてみたい」ボタンを押してもらえれば!

お知らせ

メドレーでは一緒に働くエンジニア・デザイナーを募集しています。

www.wantedly.com

www.medley.jp

WebPushAPIを用いたブラウザでのプッシュ通知開発 〜メドレーTechLunch〜

※本投稿はオフィシャルブログから転載したものです。元記事はこちら。

info.medley.jp

 

開発本部の宮内です。

先日、社内勉強会「TechLunch」にてWebPushAPIについての発表を行いましたので、その紹介をさせていただきたいと思います。

WebPushAPIとは?

一般的にプロダクトにおいて、スマートフォンアプリのような「プッシュ通知」を導入しようと思った場合、いままでは専用のアプリケーションを開発する必要がありました。

しかし、プッシュ通知に関するAPIW3Cで標準化が進み(まだドラフト状態とはいえ)、Google Chromeのバージョン42、Mozilla Firefoxのバージョン44に、WebPushAPIが導入され、元来あるWebアプリケーションに簡単にプッシュ通知を取り込むことが可能になりました。
詳しくは ウェブアプリへのプッシュ通知の追加 Using the Push APIや、WEB+DB PRESS Vol.97 などを読むとより理解が深まるので興味ある方はぜひ読んでみてください。

TechLunchでやったこと

TechLunchでは、自分が実際に実装したWebPushAPIのサンプルコードを元に、動作を示しながら挙動を開発本部の全員で追っていきました。

speakerdeck.com

具体的な手順などもスライドにありますが、公開したものだけだとちょっと分かりにくいかもですね。ごめんなさい。

もっと詳しく聞きたいなって人がいたら、気軽にここらへんにある「話を聞きに行きたい」ボタンを押下してみてください。

お知らせ

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

メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

www.wantedly.com

www.wantedly.com

www.medley.jp

React.js入門について発表しました

※本投稿はMEDLEYオフィシャルブログから転載したものです。元記事はこちら。

info.medley.jp

開発本部の楊です。医療介護の求人サイト「ジョブメドレー」の開発を担当しております。うるさい5歳のこどもと一緒に遊ぶのが大好きです。

ジョブメドレーの求人機関向け管理画面はReact.jsを利用し開発しています。
他プロダクトを担当するメンバのなかにはReact.jsについて詳しくない人もいる為、TechLunch(開発本部内で定期的に開催している社内技術勉強会)でReact.js入門について話しました。

React.jsとは

などなど、様々な特徴があります。

 

 

TechLunchでの発表内容

React.jsはUIを構築するためのライブラリなのでデータフローを管理する仕組みは提供していません。
開発の際にはデータフロー管理のために、Flux/Immutable.jsなどの考え方や技術要素を必要とします。
今回のTechLunchの発表ではFlux/Immutable.jsについても簡単に触れつつ発表しました。

目次はこちら。

  • React.js
  • Flux
  • Immutable.js

詳細はこちらをご覧ください。

まとめ

  • 全てはComponent、シンプルに保つことを意識する
  • 小さくComponentを作り、組み立てることによりUIを構築する
  • Fluxと併用しデータフローを意識する
  • Immutable.js 便利

最後に

React.jsは比較的新しい技術で、仮想DOMの使用によりブラウザのレンダリングが早いなどの利点が多々あります。
必要に応じて新しめの技術も取り入れながら、ジョブメドレーをよりよいプロダクトにしていきたいと思っています。

お知らせ

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

今後ともメドレーを、よろしくお願いいたします! www.wantedly.com www.wantedly.com www.medley.jp

島根県松江市でお試し勤務してきました

※本投稿はMEDLEYオフィシャルブログから転載したものです。元記事はこちら。

info.medley.jp

こんにちは、平山です。しれっと公式ブログ初登場です。 

5月10日から5月13日まで、総務省「お試しサテライトオフィス」事業を利用して島根県松江市で3泊4日のお試し勤務をしてきました。そうです、Rubyの聖地といわれるあの松江市です。

オンライン診療アプリCLINICSがRuby bizグランプリで受賞したことをきっかけに、松江市からお試しサテライトオフィスの提案をうけていましたが、ちょうど別件で松江に行く用事ができたので、せっかくならばお試し勤務をしてみようということで開発本部の3名で松江まで行ってきました。

DAY1 - 松江テルサ別館でお試し勤務

羽田空港から出雲空港まで1時間半のフライト、出雲空港から松江市街まで40分の空港連絡バスでの移動、東京から約2-3時間で松江市に到着しました。思ったより近いんですね。

1日目は松江駅前にある「松江テルサ別館」でのお試し勤務。

f:id:medley_inc:20170516171143j:plain

お試しオフィスの隣にはエンジニアの交流拠点「松江オープンソースラボ」があり、Rubyの神さまMatzさん(の看板)が我々を迎えてくれました。

f:id:medley_inc:20170516171155j:plain

オープンソースラボの自販機の売上の一部はRubyアソシエーションの支援金になるようです。さすがRuby City MATSUE ですね。

f:id:medley_inc:20170516171309j:plain

f:id:medley_inc:20170516171253j:plain

お昼は「八雲庵」で出雲そば 。独特の食べ方で食べるそばはとてもおいしく、また庭の池には立派な鯉が泳いでいたりとたいへん風情のあるお店でした。そばを食べている時に池の鯉がどこかから飛んできた鷹に連れ去られるのを見て、松江はすごいところだなと思いました。 

f:id:medley_inc:20170516171325j:plain

f:id:medley_inc:20170516171338j:plain

お昼のあとはお試し勤務を本格的に開始(上: お試し勤務前の記念写真)。机、椅子、スタンディングデスク、Bluetoothスピーカー、ビデオ会議用カメラなど、オフィス設備はいずれも本格的なものが用意されていて、仕事をするのにまったく不自由がない環境でした(下:せっかくなので本社にいるメンバーとビデオ会議)。

f:id:medley_inc:20170516123923j:plain

f:id:medley_inc:20170516123922j:plain

1日目は移動で疲れたこともあり、仕事を早めに切り上げ「根っこや」で夜ご飯&飲み。島根の地酒の「王祿の渓(にごり)」は色々な飲み方が楽しめ、美味しくいただきました。

DAY2 - 古民家風オフィスでお試し勤務

2日目は国宝松江城近くに建つ趣のある「古民家風オフィス」でのお試し勤務。

f:id:medley_inc:20170516172409j:plain

f:id:medley_inc:20170518224844j:plain

f:id:medley_inc:20170516124207j:plain

f:id:medley_inc:20170518224938j:plain

f:id:medley_inc:20170518225051j:plain

オフィスの設備は1日目と同じものが用意され、加えて今回はひとりひとりにデスクがあり、とても快適に仕事をすることができました。

f:id:medley_inc:20170516124312j:plain

この日のお昼は「西洋軒」で洋食を食べました。古い佇まいながらも小綺麗なお店でポークカツレツがおいしかったです。

f:id:medley_inc:20170516171916j:plain

f:id:medley_inc:20170516172314j:plain

f:id:medley_inc:20170516172542j:plain

また、せっかく松江城の近くにきたということで、休憩時間を利用して松江城を散策しました。国宝松江城はとても立派でした(下: メドレーの人文字をやろうとしてイタい感じになっているおじさんたちの図)。

f:id:medley_inc:20170516172646j:plain

f:id:medley_inc:20170518225152j:plain

仕事が終わった後には、オフィス近くにある「おつまみ研究所松江殿町ラボ」で軽く立ち飲み。地元クリエイターが内装やパッケージのデザインをしているようで、クリエイティブ感満載の居心地のよいお店でした。立ち飲みでは飲み足りないということで、2日目はこのまま夜の街に繰り出しました。

DAY3 - ゆめっくす北陵でお試し勤務

3日目は市街地から少し離れた「ゆめっくす北陵」でお試し勤務。

f:id:medley_inc:20170516172839j:plain

f:id:medley_inc:20170516172830j:plain

f:id:medley_inc:20170516172820j:plain

ゆめっくす北陵は松江市街地から少し離れた「テクノアークしまね」という研究開発施設があつまる場所の近くにあります。緑に囲まれた静かな環境にあり開発に専念できる環境です。

f:id:medley_inc:20170518225634j:plain

こちらでも1日目、2日目と同様に充実したオフィス設備が用意されていました。今までのオフィスと比較して市街地から離れた場所にあったということもあり、とても静かな環境でよりいっそう仕事に集中することができました。

f:id:medley_inc:20170516172857j:plain

お昼ごはんは「お食事処ふの」で松江市民のソウルフードといわれているカツライス。ボリュームが多いわりにさっぱりと食べられました。

f:id:medley_inc:20170516173018j:plain

その後は松江出張の目的でもあった打ち合わせと会食を無事に終わらせ、松江のバー「大正倶楽部」でしっぽりと飲んで最後の夜を楽しみました。

DAY4 - プロジェクト成功祈願

松江お試し勤務の最終日は土曜日ということもあり、業務はせずにプロジェクトの成功祈願をしてきました。島根半島の東と西に位置する美保神社出雲大社の両方にお参りすることを「えびすだいこく両参り」といい、両参りをすることで願いが成就すると言われているようです。また、出雲大社主祭神オオクニヌシは医療の神様ともいわれ、医療ITベンチャーであるメドレーが祈願をしない理由はありません。

f:id:medley_inc:20170516130322j:plain

f:id:medley_inc:20170516173129j:plain

f:id:medley_inc:20170518225924j:plain

f:id:medley_inc:20170518230028j:plain

f:id:medley_inc:20170518230044j:plain

まずは美保神社での参拝。巫女舞を近くでみるのは初めてで貴重な体験でしたが、厳かな雰囲気の中で商売繁盛とプロジェクトの成功を祈願しました。

f:id:medley_inc:20170516173505j:plain

f:id:medley_inc:20170518230223j:plain

f:id:medley_inc:20170516133037j:plain

美保神社から出雲大社への移動の途中では「SUP (Stand Up Paddle)」というアクティビティを体験しました。SUPは大きめのサーフボードのようなものに立って乗りパドルで漕ぐというウォータースポーツで、最近流行ってきているようです。当然のように室内で過ごすことが得意な我々にとって、ウォータースポーツはなじみの無いものでしたが、初心者でも丁寧にレクチャーしてくれて存分に楽しむことができました。

f:id:medley_inc:20170516133426j:plain

f:id:medley_inc:20170518230357j:plain

f:id:medley_inc:20170518230532j:plain

f:id:medley_inc:20170518230442j:plain

そして出雲大社に到着。最近メディアで取り上げられることが多く、縁結びの神様がいるということで女性観光客が多く来ていました。建築物の歴史の深さと職人のこだわりを感じながら、こちらでもプロジェクトの成功を祈願し、無事に両参りを終えることができました。

まとめ

以上、松江市でのお試し勤務の様子でした。落ち着いた環境で勤務ができたことで、仕事もはかどり良い機会となりました 。島根に対しては、東京から遠そう、市内の交通の便が悪そう、ネットワークがつながらなさそう、曇りが多そう、というネガティブな印象を失礼ながら持っていましたが、インターネットの恩恵を受けることできる環境は十分にあるので、エンジニアとして仕事をする分には大きく困ることは無いように思いました。

また、松江市には情報工学の専門課程がある大学や高専があったり、街をあげてITエンジニアの教育に力をいれていたりと、教育の機会が十分に提供されつつあり、エンジニア採用という観点からも、サテライトオフィスの選択肢は十分検討する価値はあるなと思いました。

オフラインでメリハリを付けて効率的にチームで仕事をしていきたいというのが自分の基本スタンスなのですが、今回のお試し勤務をふまえて、サテライトオフィスを前提とした現実的で効率的な働き方というものも模索していきたいと思います。

さいごに

今回のお試し勤務は松江市役所の福田さんのコーディネートのもと実現しました。ホスピタリティと仕事力がとても高い方で、福田さんのおかげで今回のお試し勤務を不自由なく終えることができました。IT企業誘致やUIターン支援などを担当されている方なので、興味のある方は福田さんに連絡してみるとよいと思います(6月9日にはお試しサテライトオフィス説明会もあるようです)。もちろん平山宛に連絡いだければお繋げします。

福田さんをはじめ今回お世話になった方々、本当にありがとうございました!

 

ということで、メドレーは今回のお試し勤務のように働き方についても議論できるフェーズです。そんな初期フェーズの会社で泥臭く一緒にコミットしていける人を絶賛募集しています。興味のあるエンジニア・デザイナーの方はご連絡ください! 

www.wantedly.com

www.wantedly.com

www.wantedly.com

www.medley.jp

 

Webアプリケーションの遅い処理を特定する話

※本投稿はMEDLEYオフィシャルブログから転載したものです。元記事はこちら。

info.medley.jp

こんにちは、開発本部で「ジョブメドレー」の開発を担当している稲本です。

先日、社内で行っているTechLunchという勉強会で「Webアプリケーションの遅い処理を特定する話」という話をしました。

タイトルの意味する範囲が広めなので概要を記載すると以下の通りです。

  • NewRelicから処理速度を見ていく
  • ChromeDeveloperTools処理速度を見ていく
  • RoR関連のプロファイラから処理速度を見ていく

上記の様にClientからServer, Applicationまでプロファイリングを行い遅い処理を特定していく流れの話をしました。

なぜこの話をしようと思ったのか

弊社ではフロントエンドエンジニア、サーバサイドエンジニアなどのポジションが明確には分かれておらず、どのバックグラウンドを持った人間も両方開発に携わる方針のため、エンジニア同士が、お互いの得意分野を補い合いながら、各々業務や学習を通して理解を深めるようにしています。

ただ「ジョブメドレー」チームでは、現状パフォーマンス対策に関しては得意な人が対応する傾向にあります。

そのため得意では無い人へも、どのように調べていけば良いかを共有し、少しでもエンジニア間の知識のギャップを小さくできればと思いフロントエンド〜サーバサイドまでのプロファイリングというテーマで発表しました。

話した内容

先述の取り話した内容は以下の通りです

  • NewRelicから処理速度を見ていく
  • ChromeDeveloperTools処理速度を見ていく
  • RoR関連のプロファイラから処理速度を見ていく

NewRelicの項ChromeDeveloperToolsの項では、ユーザーがBrowserを介してサービスを表示するまでの間に、どのような処理にどれぐらいの時間がかかっているか、それを見る方法について説明しました。

RoR関連のプロファイラの項では、サーバーアプリケーションで実行する処理の速度の調査方法について説明しました。

※発表資料はこちら

まとめ

今回、TechLunchで各種プロファイリング方法について紹介しました。

  • ブラウザを経由したパフォーマンスはNewRelic, ChromeDeveloperToolsなどで見ることが出来る
  • アプリケーションのパフォーマンスはrack-mini-profiler, peek/rblineprof, stackprof
  • 正しく問題を把握することで誤った解決方法を選択してしまうリスクを回避できる

ということについて話をしていきました。
個々のツールの使い方については、調べれば良質な文書が沢山ある中で、実運用上どのように調べれば良いのかにフォーカスし、その一例を紹介出来たのではないかと思います。

今回は触れていませんが、これに限らずサーバーリソースから見るボトルネックの調査方法や、負荷試験方法などについてもどこかで触れて行ければ良いなと考えています。

最後に

メドレーではエンジニアを積極採用しています! ご応募お待ちしています。

www.wantedly.com

www.wantedly.com

www.wantedly.com

www.medley.jp