自分がLinc’wellで提供しているプロダクトを理解するためにやったこと

by bayashi

Slide 1

Slide 1 text

自分がLinc’wellで提供しているプロダクトを理解するためにやったこと  Kei Ogane 

Slide 2

Slide 2 text

自己紹介  大金慧(ばやし) オンライン診療システム提供サービスでバックエンドエンジニア後エンジニアリングマネージャー医療業界はLinc’wellが初めて最近の趣味はSwitch 2の抽選に応募して外れることです

Slide 3

Slide 3 text

会社紹介 

Slide 4

Slide 4 text

オンライン診療システム提供サービス  システム提供  診療 

Slide 5

Slide 5 text

患者さん向けもクリニック向けも 

Slide 6

Slide 6 text

BtoBtoC  患者さんの理解もしなきゃいけないし  クリニックのオペレーションも理解しなきゃいけない 

Slide 7

Slide 7 text

更に難しいところ  オンライン診療の診療科の数は  とても多い 

Slide 8

Slide 8 text

診療科毎の体験の磨き込み  低用量ピルの患者さんと  男性AGAの患者さんだとペルソナが全然違う    全部の診療科の体験を  それぞれ磨き込まなきゃ（白目） 

Slide 9

Slide 9 text

複雑だから強い  中核の業務領域の実装が簡単であれば、競争優位を維持できるのは短い間だけです。  したがって、中核の業務領域は必然的に複雑になります。  ドメイン駆動設計をはじめよう   Vlad Khononov　著、増田亨、綿引琢磨　訳 

Slide 10

Slide 10 text

複雑な4つを理解  - ドメインの理解  - エンドユーザへの理解  - クリニックオペレーションの理解  - 事業の理解 

Slide 11

Slide 11 text

ドメインへの理解 

Slide 12

Slide 12 text

医療ドメインは気にすること多い  自分は医療系のプロダクト開発が Linc’wellが初めて。  気をつけなければいけないポイントが色々あるんだけど、勘所がつかめない  この画面のこの項目、必要無い気がするんで  消しません？  それは絶対に  ダメ 

Slide 13

Slide 13 text

自分で本読んだり  医療情報システム入門 2023  一般社団法人保健医療福祉情報システム工業会 JAHIS 

Slide 14

Slide 14 text

厚労省の資料読んだり  オンライン診療の  適切な実施に関する指針   https://www.mhlw.go.jp/content/12601000/000901835.pdf 

Slide 15

Slide 15 text

みんなで本を読んだりしました  医療健康データの取扱説明書:   IT技術者が知っておくべき要点  情報処理学会 (監修), FAST-HDJ (著, 編集) 

Slide 16

Slide 16 text

なんとなく  勘所は掴めてきた  けど医師免許を持ってるわけじゃないから  最後はドメインエキスパート*に頼る    *Linc’wellでは社内に医師がいて、プロダクト開発チームと一緒にクリニックオペレーションや患者の体験を検討している  これデータ改変していいっすか？  良いわけがない 

Slide 17

Slide 17 text

エンドユーザへの理解 

Slide 18

Slide 18 text

エンドユーザへの理解  自分たちが提供しているプロダクトは一体どんな体験を提供してるのか理解したい  幸いにもBtoBtoCかつ自分が病弱なので、  患者として実際に色々体験できた 

Slide 19

Slide 19 text

患者として体験する  自分が試した診療科  - 肥満症治療  - 花粉症  - 内科  - 皮膚科 

Slide 20

Slide 20 text

患者として体験する  患者として体験して思ったのは、プロダクトの機能がどうこうよりも  - 診察の時のお医者さんの対応  - 次の日にお薬が届く  ということが体験として印象深かった  →目前のプロダクトは体験の一部であることを強く意識する 

Slide 21

Slide 21 text

体験できないものは情報収集するしかない  - インターネットで調べたり社内の有識者に聞いたり  - 入社当初そもそも低用量ピルというものがあんまりわかってなかったので  奥さんに色々聞きました  - 自社プロダクトを患者目線で触ってみたり 

Slide 22

Slide 22 text

プロダクトの触り方  普段はここしか  触ってないけど  患者向けWebアプリ 

Slide 23

Slide 23 text

プロダクトの触り方  広告バナー  LP  患者向けWebアプリ  実際の患者さんは  ここまで含めてサービスとして認識してる 

Slide 24

Slide 24 text

クリニック  オペレーションへの理解 

Slide 25

Slide 25 text

ある日  あるクリニック向けの機能をリリースする際に、現場の方から修正を求められた  「そこってそんな影響あるかなぁ。ワンクリック増えるだけじゃん」とは思いつつ、言われた通りに直した 

Slide 26

Slide 26 text

後日  現場を見に行くとそこでは  とてもチューニングされた仕事をしていた  高度なオペレーションが組まれていて、  イレギュラーが発生すると影響が大きいことを理解し、自分の感覚で業務影響を捉えてはいけないことを実感     

Slide 27

Slide 27 text

それから  勘所は掴めた気がするけど  現場のオペレーションに影響ある機能は  早めに現場に確認するようにした  これ操作増やしていいですか？  良いわけがない 

Slide 28

Slide 28 text

とはいえ  現場のオペレーションを知っている人も  プロダクトとしてどう解決すればいいかの正解は知ってるわけではないので、言われたものをそのまま作るのは危ない  課題や背景を聞いてもいいですか？  ボタンを右側に配置してください 

Slide 29

Slide 29 text

事業への理解 

Slide 30

Slide 30 text

事業を理解してないとどうなるか  事業を理解出来ていないと  - 開発する機能がこのタイミングで作られる意味がわからない  - 優先順位に納得感がない   - 開発する機能の解決したい課題が腹落ちしない  - もっとこういう機能にしたらいいのに  

Slide 31

Slide 31 text

その結果  - ただ言われた機能を作るだけ  - だけど納得感はなくてやっていて楽しくない     - 事業状況を無視した要求をするだけ  - 事業がクローズされるかもしれないタイミングで大規模リファクタリング要求     に陥る 

Slide 32

Slide 32 text

設計にだって事業の情報は必要  プログラミングとは経営判断の集積である  https://www.furomuda.com/entry/20060118/1137558108  ソースコードの一行一行は、経営判断そのものだ。  どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアシステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。 

Slide 33

Slide 33 text

極端な例  ◯◯の方向に行ったら詰むアーキテクチャにしちゃお  今後の事業は  〇〇の方向で  行こう 

Slide 34

Slide 34 text

事業状況を理解する  自社のビジネスモデルを理解する  事業目標を理解する  事業の会話がされている場に参加する  色んな人から情報収集する 

Slide 35

Slide 35 text

みんなで事業への影響を理解する  ある日チームメンバーから  「自分が開発している機能が事業に役立ってるかわからない」と言われた  自分は「こんなに役立っている機能作ってるのに」と思った  でもよく考えたら知ってる内容が違っていた 

Slide 36

Slide 36 text

スプリントレビューを変更  スプリントレビューはこれまでただ機能のデモをしているだけだった  そこからデモ以外に  - 過去リリースした施策の影響  - 現在追ってるKPI状況の共有  もスプリントレビューでやることにした  みんな自分が作った機能が事業に役立ってることがわかるようになってきた 

Slide 37

Slide 37 text

複雑な4つを理解  - ドメインの理解  - エンドユーザへの理解  - クリニックオペレーションの理解  - 事業の理解 

Slide 38

Slide 38 text

相反するところもあるけれど  4つを理解しながらバランスをとっていく 

Slide 39

Slide 39 text

再掲)複雑さをコードに落とし込んでやっていく  中核の業務領域の実装が簡単であれば、競争優位を維持できるのは短い間だけです。  したがって、中核の業務領域は必然的に複雑になります。  ドメイン駆動設計をはじめよう   Vlad Khononov　著、増田亨、綿引琢磨　訳 

Slide 40

Slide 40 text

アイディア  まえに岩田さんと話したときに、「アイデアというのはなにか？」という話をしたじゃないですか。  宮本（茂）さんのことばですね。   そうです。つまり、宮本さんによれば、「アイデアというのは複数の問題を一気に解決するものである」  糸井      岩田  糸井  第１回アイデアというのはなにか？   | 任天堂の岩田社長が遊びに来たので、  みんなでご飯を食べながら話を聞いたのだ。   | ほぼ日刊イトイ新聞  https://www.1101.com/iwata/2007-08-31.html 

Slide 41

Slide 41 text

４つすべてを理解したら怖いものなし  次やる◯◯って診療科は、予約の概念がないんだ  診療科の  概念が崩れる... 

Slide 42

Slide 42 text

それでもやっていくのである 