Healthtech Meetup vol.1に参加したらネイティブアプリの未来がちょっと見えた話

Healthtech Meetup vol.1に参加してきました。
ヘルスケア系のサービスに取り組むスタートアップのエンジニアが集まるイベントで、システム開発の知見だけではなく幅広いテーマでの発表を聞いてくる事ができました。

connpass.com

Main Session

「継続を支える」ライフログの利用と技術 in FiNCアプリ」

株式会社FiNC 森久太郎さん @qsona

行動変容ステージモデルが特に勉強になりました。使うことで便利になる、といった性質ではないアプリにおいて、どうやってユーザーに寄り添っていくかって難しいです。また、WIPとのことだったので省いたものもありますが、機械学習を使った施策も面白かったです。

AI×創薬の最近の事情

株式会社ディー・エヌ・エー 望月正弘さん

  • AI創薬
    • AIを用いた新薬の開発を行う
      • 論文を読ませる
      • 薬剤投与時の遺伝子発現データを用いる
      • 化合物の構造を学習する
  • Fingerprintを使った機械学習
    • 90年代に発見
    • 化合物の特徴を表現したベクトル
    • IT創薬コンテストで、DeepLearningを用いた学習にも対抗できた

唯一のアカデミックな話でした。内容もさることながら、機械学習に明るくない僕でも引き込まれるような分かりやすい構成でした。バズワードとなったDeepLearningを使ったから結果が出るわけではない、耳が痛い話です。。。

新規サービスでGo, GAEを使ってみた話とその振り返り

DeSCヘルスケア株式会社　鶴田拓也さん@o_tyazuke

speakerdeck.com

  • 採用理由
    • サクッと作ってサクッと潰したい
    • 社内の知見を増やす
    • GAEのStandardEnvironmentでRails使えない
  • 開発の流れ
    • Github
    • CircleCI
      • QAブランチごとにGAEのバージョンを作ってデプロイできるように
    • GAE
  • アナリティクス
    • GAE
    • Datastore
    • BigQuery
    • Data Studio
  • 失敗したこと
    • 歩数は最新のものが届くとは限らない
      • iOSのヘルスケアへの書き込みにラグがあるのが原因
      • 対策: 書き込みを待つ、書き込みイベントを発火させる(ヘルスケアを開く)
    • Goのアンチパターンを踏んだ
      • structにcontextを詰めていた

みんな大好きGo言語の話。GAEの導入に際した生の知見です。業務だと既にAWSの環境が整っているため導入は難しいのですが、聞けば聞くほど惹かれていく。。。
また、構成の話も面白かったです。アナリティクスの話は、稼働しているサービスだからこそ得られる経験ですね。

某サービスのリニューアルでECSを導入したよもやま話

株式会社エス・エム・エス 光宗朋宏さん(@t_mitz)https://twitter.com/t_mitz

speakerdeck.com

  • リファクタリングに合わせて既存サービスにECSを導入
  • 理由
  • 他サービスとの比較
    • Google Kubernetes Engine
      • 当時のIAMの仕様とセキュリティ要件がマッチしなかった
      • AWSのナレッジを蓄積させたかった
    • Kubernetes on AWS
      • 学習コストが高い
      • フルマネージドに寄せて簡単に環境構築したい
  • 構成
    • CircleCI
      • 今はテストの実行のみ
      • docker imageのbuild&pushは時間の関係でやめた
    • CodePipeline
      • Githubのブランチを監視して更新があるとデプロイ
    • Logging
      • awslogs driverでCloudWatch Logsに収集
      • 特に困ってない
      • 本番環境にするときはKibanaにするかも
    • ECS
      • 1サービス１タスク定義
      • １タスクに３つのコンテナ
        • h2o(httpサーバー)
        • rails
        • shoryuken(gem)

打って変わってAWSの話です。普段CircleCIはAndroidのバイナリを生成してくれるサービスという認識だったので、サーバーサイドの話の中で登場するとちょっと新鮮でした。他サービスとの比較検討も、ヘルスケアといったテーマで括る勉強会ならではのものですね。

LT

m3.comを支える巨神の話

エムスリー株式会社 池田貴世志さん(@progrhyme)https://twitter.com/progrhyme

speakerdeck.com

  • 歴史あるサービスを改善し続けている話
  • 問題点
    • 複雑なサービス間通信
    • ビュー要素を再利用できず、各サイトで再実装している
    • API Aggregatorを活用できていない
  • 対策
    • Atlasの導入
      • フロントエンドのHTML生成を担当
      • サービス間連携の標準化を推進
    • DBを直参照していたものをAPI化

大量のユーザーを抱えたサービスの設計と戦い続ける話です。m3.comは名前は知っていたのですが、お恥ずかしながらこんな大規模なサービスだとは知りませんでした……。
抽象度の高い設計思想の話ではなく、１システムをこうしたおかげで改善されたという具体的な話は、なかなか調べただけじゃ引っかからないので来て良かったです。

過去の負債と戦う(テクニック編)

株式会社エス・エム・エス 岡田数馬さん(@okazu_dm)https://twitter.com/okazu_dm

speakerdeck.com

  • 改善すべき点(負債)の改善には普段の備えが重要
  • 負債は普段はぼんやりしているもの
    • 特定する必要がある
  • 改善活動を支えるツール
    • New Relic
      • アプリケーションをリアルタイムで監視してくれるサービス
      • 重いEndPointや大量のQueryを探し出してくれる
      • クエリ発行数を60%に
    • Cloud Forecast
      • JVMの負荷も見られる
      • キャパシティプランニング、インフラコストを1-2割減

まさに「推測するな、計測せよ」に則った話です。ネイティブのアプリだと、端末の内部処理をここまで細かく特定している話ってあんまり聞かないような……？
また、ツール群を使って見つけたボトルネックの解消にいたるまでのフローも聞いてみたいです。

iOSでのバックグラウンド歩数同期

株式会社DeNAライフサイエンス 馬場南実さん

  • やりたいこと
    • バックグラウンドで歩数を計測したい
  • バックグラウンド処理
    • androidだと簡単だが、iOSだと制限が厳しい
    • 音楽の再生
      • 再生し続ければ処理を続けられる(無音を再生し続ける！)
    • 位置情報更新を受け取る
      • 地図アプリは閉じてても案内してくれる
    • 電池消耗の課題
  • background fetch
    • iOSの任意のタイミングで呼ばれるタイマー
    • 呼ばれたタイミングで必要な処理を行う
      • 歩数取得
      • ゴールに到達したか
      • push通知表示
    • 呼ばれる頻度は不定期
  • サーバーからのpush通知
    • background fetchの補助
    • 通知を受信したタイミングでバックグラウンド処理
    • ユーザーへの表示はされない サイレントプッシュ

ネイティブアプリの話ということもあってか、１番実感しながら聞けたセッションでした。iOSつらいという話は聞いてはいたのですが、まさかここまでAPIが塞がれているとは。。。無論敵わない点はありますが、Androidの豊富なAPIを当たり前に思ってはいけないですね。
また、バックグラウンド処理をめぐる血の滲むような努力は涙無しには聞けません。無音で音楽流しっぱなしはだいぶ賭けに出たやり方ですね……。

メディカルノート開発/インフラのあゆみ

株式会社メディカルノート 河本穣さん(@k12u)https://twitter.com/k12u

speakerdeck.com

  • 気をつけているところ
    • なるべくマネージドサービス
    • IAAC(infra as code)
    • SSM parameter store
    • packer + ansible
    • Terraform workspace
  • 進化の軌跡
    1. シングルインスタンス
      • admin作業でサイトが落ちる
    2. adminインスタンスの分離
    3. ELB化
    4. CDNフルキャッシュ化
      • HTMLコンテンツごとキャッシュ
      • 今はサーバーレスで配信
  • Infrastructure as Code
    • AMIプロビジョニング
      • packer/ansible/CI
      • アプリケーションや環境に依存しないもの
      • rootで動かすもの
    • プロジェクト環境構築
      • プロジェクト環境のセットアップ
      • ネットワーク
      • サーバー構成
    • インスタンス起動時/デプロイ時
      • ライブラリインストール
      • 依存性解決
  • チャレンジしやすいプロジェクトでは積極的に
    • 一方、駄目なものは駄目と言えることが大事
  • チーム
    • 設計レビュー
    • 実装後レビュー
    • 毎週のKPT確認
    • 運用と開発のチームが 半歩はみ出す
      • 非効率性は境界部分に発生しがち
  • おまけ
    • サービス名を絵文字で表現できるようにすると楽

チーム運営の話が特に勉強になりました。半歩はみ出そうとすること、そして半歩はみ出されることの両方を良しとする文化形成は壁の多そうな取り組みです。
また、サービス名を絵文字で表現する、というのも当日Twitterで話題になりました。名前はかっこいいけどスペルに気を使わなきゃいけなかったり、もしくは略称ばかりでこれなんだっけシステムが続出したりするような事案が発生しがちなので、ビジュアルで認知できるのは強みですね。

まとめ

先日病院のお世話になったこともあり、個人的に非常に関心の高い分野のミートアップでした。健康に取り組む人々をどう支援していくか、という戦略的な面から具体的なシステムの面まで、よくここまで散らばったなと思うくらい幅広いテーマの発表でした。
また、個人的にはネイティブアプリ開発のモチベーションが上がった会でもありました。普段開発しているアプリは、webブラウザよりも優れた体験を与えることを目的にしたものが多かったです。PWAなどを代表とするWeb技術群も流行ってきて、ネイティブアプリって今後どうなってしまうんだろう、という不安も抱えていました。一方、ライフログという観点で見ると、そこにネイティブアプリの優位性があるのかなと感じました。AndroidにはFitAPIもあるし、さらにFitbitなどAPIを提供してくれている外部デバイスと組み合わせることもできます。
ちょっと感度を上げながら新しいサービスを眺めていってみたいです。