B2B2Cなヘルスケアサービスの作り方

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
2016/01/29
Tomohiro Mitsumune
DeSC Healthcare, Inc.
B2B2Cなヘルスケ
アサービスの作り方
1

アジェンダ
⁃ DeSCヘルスケアとは？
⁃ Webサービス
⁃ ネイティブアプリ
2

自己紹介
⁃ @t_mitz
⁃ DeSCヘルスケア株式会社サービス企画開発部
⁃ 前職では新規サービス立ち上げや開発チームのマネージメントに従事
⁃ DeNAではマンガボックスやNBPFの立ち上げに参加
⁃ サーバーサイドエンジニアだったけど最近はiOSとAndroidがメイン
⁃ 齢35にして人生初のフルマラソン完走しました
3

DeSCヘルスケア？
4

DeSCヘルスケア
5

KenCoM
6

Webサービス
7

やったこと
⁃ アプリケーションの一部の設計・実装を担当
⁃ ポータルサイト部分
⁃ CI / CD
⁃ 社内でRailsベースのCI/CD環境が無かった
⁃ 環境の制限でSaaSが利用できないため仕組みを自作
⁃ コードレビューおじさん
⁃ コンポーネント間でのデータ連係があるので設計を重点的に
⁃ Ruby書いた経験が少ない人もいたのでサポート（厳しめに）
8

構成
⁃ ポータルサイト
⁃ Rails4
⁃ データAPI
⁃ Rails4
⁃ grape
9

10
システム全体

セキュリティ
⁃ 要件が非常に厳しい
⁃ 厚生労働省が定めているセキュリティガイドラインに準拠
⁃ データヘルス計画における健康情報の取扱い
⁃ 匿名データの作成・提供に係わるガイドライン
⁃ 医療情報システムの安全管理に関するガイドライン
11

セキュリティ対策
12

データベース構成
⁃ 個人情報とそうでないデータでDBを分割
⁃ セキュリティ対策のため秘匿性が高い個人情報はAPI経由で取得
⁃ データの取得に必要なtokenはJWTで生成しAPIサーバーで検証
⁃ MySQLもSSL接続
13

データベース暗号化
⁃ 個人情報に該当するデータは全て暗号化
⁃ symmetric-encryptionというgemを利用
⁃ http://rocketjob.github.io/symmetric-encryption/
⁃ Railsから透過的にOpenSSLを使ったデータ暗号化
⁃ 環境(dev, test, prod)ごとに異なる設定
⁃ セキュリティ強度を高めるため暗号化に利用するを定期的に更新
- の生成ややIVのマスキング処理をするコマンドラインツールは
gemを自作（非公開）
14

CI / CD
15

ChatOPS
IRC + Jenkins + Github Enterprise + sinatra + capistrano
16

Q. なんでSaaSを使っていないの？
A. オンプレ環境で利用できるSaaSが無かった（当時）
⁃ またAWSやAzureはセキュリティポリシー的に利用不可
17

Q. なんでSlackじゃなくてIRCなの？
A. Slackのアクセス元IPアドレスが固定できないため通
信元の制限がかけられなかったから
⁃ インバウンドな通信を許可するなら経路は限定
⁃ SlackはインフラがAWSなので動的IP
⁃ ダメ元でサポートにメールしてみたけどやっぱりダメでした
⁃ 将来的に固定IPにできるようにしたいけど今は無理、という回答
18

ネイティブアプリ
19

はじめに
⁃ やったこと
⁃ iOSアプリ開発
⁃ Androidアプリ開発（少しだけ）
⁃ はなすこと
⁃ 主にiOS
⁃ 使っているライブラリの紹介
⁃ 開発していて気づいたこと・こまったこと
20

ネイティブアプリの要件
⁃ あくまでメインはWebアプリ
⁃ ネイティブアプリはアドオン的な立ち位置
⁃ 導入先の健保でスマホ未所持な人が利用不可
⁃ 営業先が限定されてしまい機会損失
⁃ ネイティブアプリに期待されること
⁃ プッシュ通知で有資格者に健保からのお知らせ
⁃ バイタルデータを活用した機能
21

プッシュ通知
22

Parse
23

Parse
⁃ プッシュ通知の基盤として利用
⁃ 理由
⁃ コストに対する費用対効果が非常に高い
⁃ 開発コスト・ランニングコスト
⁃ 100万ユーザ/月までは無料
24

Parseのメリット・デメリット
⁃ メリット
⁃ 組み込みが簡単
⁃ 管理画面の素晴らしい出来
⁃ 豊富なAPI
⁃ デメリット
⁃ 複雑なことはできないためビジネスロジックに合わないとつらい
⁃ 簡単に使えすぎてオペミスの発生確率が高そう
25

突然のshutdown
26

バイタルデータの活用
27

HealthKit
⁃ ヘルスケアに関するさまざまな項目を管理
⁃ iOS端末がヘルスケアデータの入れ物になるイメージ
⁃ 自動取得できるデータもあるが大半は別途入力が必要
⁃ HKStatisticsCollectionQueryを利用
⁃ ある期間内で指定したインターバルでデータ集計するAPI
⁃ 歩数グラフ作成に使っている
28

HealthKitでこまったこと
⁃ エラーが発生したときのデバッグ
⁃ compltionHandlerはprivateスレッドでバックグラウンド動作
⁃ closureのclosureとかで動いていたりするのでCrashlyticsで追う
のつらい。。。
⁃ 対応方法
⁃ 無駄にメモリを使わないようにいろんなところを最適化
29

iOS開発あれこれ
30

アプリ審査
⁃ HealthKitの利用
⁃ 利用用途をアプリ内で明記、が理由で数回リジェクト
⁃ レビュワーが変わる度に指摘
⁃ 細かい指摘をされるので審査依頼時に補足メッセージを添えると良い
31

Swiftのバージョンアップ
⁃ Swift2.0で動いています
⁃ 1.1時代に開発スタート
⁃ 開発始めてすぐ1.2が出る
⁃ 実装自体もまだ小さかったのでMigrationはたいしたことなかった
⁃ WWDC2015でSwift2 + Xcode7発表
⁃ CocoaのAPIまわりはそれほど壊れなかった
⁃ Cocoapodでインストールしてるライブラリが大変
32

利用しているライブラリ
⁃ Alamoﬁre
⁃ AlamoﬁreImage
⁃ Realm
⁃ SwiftyJSON
⁃ Charts
33

Alamoﬁre
⁃ 1.3 → 2.0.X → 3.1.0 とバージョンアップ
⁃ 2.0からSwift 2に対応
⁃ 下位互換性の無いインターフェース変更が入った
⁃ 3.0はresponse serializationの改善をするためのリリース
⁃ 2.0をベースによりシンプルに
⁃ NSURLSessionを自前のものに差し替えたりできる
⁃ サーバーAPIをcallする処理が多かったの涙目で修正
34

AlamofireImage
⁃ Webから画像をダウンロード・キャッシュ
⁃ SDWebImageの代替ライブラリ
⁃ Alamofireのアドオンとして動作
Q. なんでSDWebImageを使ってないのか？
A. Pure Swiftで書かれたライブラリで統一したかったから
⁃ 画像fetchするベンチマーク結果はほぼ変わらなかった
⁃ Kingfisherも候補だったがAlamofireを導入済だったのでこちらに
35

Realm
⁃ 0.95でConﬁgurationまわりの変更
⁃ Realm Javaと似た感じに
⁃ 0.96でNULLサポート
⁃ try catchのエラーハンドリングをやらないとエラー
⁃ エラーハンドリング対応のマイグレーションがめんどくさかった
⁃ Realmインスタンスを生成するところ全てで書く必要がある
36

Charts
⁃ MPAndroidChartをiOS向けにportされたグラフライブラリ
⁃ iOSとAndroidで同じグラフが作れてべんり
⁃ githubではios-chartsという名前
⁃ 問題点
⁃ APIインターフェースの一部に互換性がない
⁃ 公式ドキュメントがAndroidのみ
⁃ ソースコードがドキュメント 😇
37

38

まとめ
39

まとめ
⁃ Webアプリ
⁃ セキュリティ対応は大変
⁃ セキュリティ要件を満たしてくれるgemあるので活用
⁃ ネイティブアプリ
⁃ 巨人の肩の上に立つ
⁃ Swiftライブラリは最新版を使いましょう
40

ご静聴ありがとうございました
41

B2B2Cなヘルスケアサービスの作り方

More Related Content

What's hot

Viewers also liked

Similar to B2B2Cなヘルスケアサービスの作り方

More from Tomohiro MITSUMUNE

B2B2Cなヘルスケアサービスの作り方