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

Transcript

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

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

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

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

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

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

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

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

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

11. ドメインへの理解

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

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

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

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

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

17. エンドユーザへの 理解

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

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

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

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

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

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

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

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

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

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

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

29. 事業への理解

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

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

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

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

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

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

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

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

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

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

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

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

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