🖊

【ドメイン理解】すべてが初めてのヘルスケア業界への転職後にドメイン理解のために自分で実践したこと

2024/01/29に公開

会計ソフトの会社から、全くの別業界であるヘルスケア業界に転職して最初の3ヶ月で何をしたかを紹介する。

ドメインの分類

ドメインと言ってもいくつかのタイプがある。これまで自分で言語化できていなかったが、以下の分類がとてもしっくりきたので詳細は是非こちらの資料を見てほしい。
https://speakerdeck.com/moeka__c/ensiniahatonoyounitomeinnitaihutekiruka

要は以下の分類があり、それぞれ発揮するシーンが異なる。詳細は上の資料にあるが、抜粋するとこんな感じ。

  • 座学
    • 他人とのコミュニケーションを円滑にする
  • 現場
    • 顧客を知る
  • ビジョン
    • 自社が何を目指すのかを知る

座学を知らないと PdM や経営層、ユーザーの言っている単語・話がわからない。
現場を知らないと顧客が求めていないものを作ってしまう。
ビジョンを知らないと、長期的な目線を失った開発をしてしまう。

「ドメイン理解」と聞くとまずは「現場」を想像してしまっていたが、実は基礎として「座学」もあるし、より抽象度の高い「ビジョン」もある。

これ以降それぞれの分類ごとに何をしたかを紹介する。

座学を知るために

ググる

本当に毎日知らない単語が登場する。自分に直接関係のない話でも耳にしたらとりあえずすぐにググるということを徹底している。
基本的すぎてこれ以上書くことがない。

本を読む

これまで3,4冊本を買った。
バックテックのプロダクトは企業の従業員・企業の管理者(人事部など)・セラピスト(理学療法士)など多くのユーザーが登場する。それぞれ目線の本を買った。

しかし初めてのドメインでどんな本を買えばいいか分からなかった。なので他メンバーの机や棚にある本を(盗み見て)片っ端から買ってみた
あとは Slack で誰かが紹介していた本。

論文を読む

バックテックは医学的根拠に基づいたプロダクトを作っている。そういう背景もあって Slack ではよく論文の紹介がされているので掻い摘んで読んでいる。
「メンタルケアのためのデジタルの使い方(意訳)」的な論文とかは、エンジニアが読んでも結構面白いものが多かった。例えばキーボードの Backspace の入力回数でストレス指数を計測する研究とかあって面白い。

現場を知るために

ユーザーの元へ行く

前述の通りバックテックのプロダクトは多くの登場人物がいる。

  • セラピストの方々を集めたミートアップに参加し、普段の思考を聞いたり、プロダクトフィードバックをもらう
  • ユーザー企業で開催するイベントに行き、エンドユーザーと話したり、セラピストのやっていることを観察

正直ユーザーの元へ行く場合のタイムパフォーマンスはなんとも言えない。ものすごい強烈なインサイトを得るときもあれば、ある程度予想のつく反応をもらうこともある。常にユーザーと対話しているわけではないので、空き時間も発生する。ユーザーと会って満足はしているが、目的やスキームはもっと考えていくべきだった。

ただ間違いなくテンションは上がる!!

顧客を知る

ここでいう顧客とは実際にお金を払ってくれるユーザーのこと。バックテックにおいては企業の人事部や健康保険組合の方々だ。幸いバックテックのプロダクトは三方良しなプロダクトだし、その他のエンドユーザーを忘れていい訳では無いが、やはりスタートアップにとって顧客の声は重要だ。

営業資料を見る

どういう規模の会社に、どういう課題設定で、何を訴求しているのかを見てみる。
自分が作ってる機能をどう伝えているのか。

最近はオンラインでの商談が多いので、その録画を見ることもできる。ありがてー。

顧客メモを作る

プロダクトによるが、顧客ごとの多少のカスタマイズや関係性の歴史はあるものだ。
「〇〇さんのところだけど、今度△△な機能を追加したくて〜」って会話がよく行われているが、その都度背景情報を聞いていたら会話が進まない。

全社ミーティングや企画会議で聞いた顧客ごとのメモを少しずつ貯めていくことで、背景情報を理解しながら特殊な事情に素早く対応できる。
エンジニア視点での提案もできるかもしれない。

ビジョンを知るために

そもそも入社している時点で将来やりたいことや目標、ビジョンを理解・共感していることは前提。

競合を知る

圧倒的な寡占企業ではない限り市場での自社の立ち位置は他社との相対関係で決まることも多いんじゃないかと思う。競合を知ることで自社がすべきことも分かるし、アイディアの刺激にもなる。

開発ロードマップを理解する

ビジョンや全社的な目標が開発チーム向けに実体化したものが開発ロードマップという認識。開発ロードマップはエンジニアに一番直接関わるので「ちょっと知る」レベルではなく、脳にインストールしたい(できてない)。

最後に

上記全てを常に全力でやっているわけではない。数回取り組んだだけのこともあるし、受動的に情報を受け取ってそれをメモってるだけのことも多い。エンジニア10人以上でデザイナーも PdM もいる企業ならドメインを理解しなくてもエンジニアの仕事は進むだろう。言われたものを期間内に作れば十分かもしれない。

ただ、正しいドメイン理解は正しさがあり柔軟そうなソフトウェアを作るというソフトウェア開発にとっても分かりやすいメリットがある。ある程度未来を想像し、データ設計をし、先回りして問題が起きないようにする。そのためにもドメイン知識の獲得はできる範囲で頑張るべきだと思う。

バックテック【ヘルステック系スタートアップの試行錯誤】

Discussion