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なヘルスケアサービスの作り方

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (17)

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

Ähnlich wie B2B2Cなヘルスケアサービスの作り方 (20)

Mehr von Tomohiro MITSUMUNE

Mehr von Tomohiro MITSUMUNE (7)

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