コトに向かうチームビルディング〜健康診断のDXを目指して〜 【DeNA TechCon 2023】

youtube：https://youtu.be/Q-A2-CHtNgE

概要：
2022年から健康診断における業務を改善するためのプロダクトを開発しています。
定期で受診する健康診断や人間ドックは身近なメディカル領域である反面、その裏にある知識や手続きは非常に複雑です。
業務をソフトウェアに委譲していくためには開発者・チームにもそのドメイン知識の理解が求められます。このセッションではスクラム開発などのプラクティスを通じてこの複雑な業務ドメインにどのように取り組んでいるかを紹介します。

メディカル領域に限らず、複雑な業務ドメインに立ち向かう組織開発の一例として参考になれば幸いです。

◆ チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2023 公式サイト
https://techcon2023.dena.dev/

Transcript

1. コトに向かうチームビルディング 〜健康診断のDXを目指して〜 技術統括部 プロダクト開発部 DXソリューション開発グループ 飯沼 遼
2. 飯沼 遼 / @mizuki_r 所属: 技術統括部 プロダクト開発部 DXソリューション開発グループ グループリーダー 兼 フロントエンドエンジニア 経歴: 2011/04 株式会社モバイルファクトリー 2018/10 弁護士ドットコム株式会社 2022/05 株式会社ディー・エヌ・エー 2
3. 健康診断をきっかけに15kgのダイエットに成功 • コロナ禍中の運動不足 ◦ 何もしてなくても心拍数120 ◦ 息が切れる • 体重80kg → 65kg ◦ 毎日のウォーキング ◦ 2022年には10kmマラソン • 健康は大事 3
4. Agenda 僕たちの向き合う「こと」 • 健康診断のもたらす価値 • 診断結果を活用し、健やかな生活を 4 立ちはだかる「壁」を乗り越える • 膨大な知識量、関係性を制する • 問題と解決の認識を合意する 「こと」に向かう組織を作る • 具体的な成果物で合意する • スクラムで「こと」に向かう
5. 5 僕たちの向き合う「こと」
6. 健康診断のもたらす価値 前提として、健康診断とはどのようなものなのかを解説します 6
7. 健康診断の概要 • 病気の予防・早期発見を目的に行われる総合的な検査プログラム • 年に一度、指定の検査を内包する健康診断の受診が事業者・学校には義務付けられている ◦ 法定健診と一般的に呼ばれる ◦ 厚生労働省より、労働安全衛生法第66条に定められる • 特定の身体状態を検査する診察のことを検診と呼ぶ ◦ 例: がん検診、メタボ検診、等 • 人間ドックは法定検診の内容に検診をかけ合わせたものが多い ◦ より広くリスクを診断できる 7
8. 健康診断がもたらす価値 • 定期的に自身の健康状態を確認できる ◦ 相対的に体質や体調の変化を計測している ◦ 生活習慣の見直しのトリガー • 施設や検査の内容に応じてリスクの高い病気を早期に発見できる ◦ がん、糖尿病など • 診断結果が怪しい場合は速やかに病院にかかる ◦ これまで通りの生活を続けたいなら ◦ 毎週ラーメン食べたい 8
9. 診断結果を活用し、健やかな生活を 9
10. 健康診断の結果の再利用性 • 2年前の健康診断の結果って覚えてます？ • 良くなった項目はなんですか？ • 悪くなった項目はなんですか？ • 体重何kg増えました？ 10
11. 健康診断の結果の再利用性 - 僕の場合 • 気づいたら5kg増えていた • 体重すらまともに計測していない • なんなら、診断結果の紙がどこにあるかわからない 11
12. 健康診断の結果を受診者に還元したい • 健診結果をより身近なところに ◦ デジタル空間上に配置して、アクセス性を上げる ◦ 相対的な変化を見れるようにする • 情報を連携し、再利用する ◦ スマートウォッチ、ヘルスケア系のアプリ ◦ 他の医療機関、研究所など 12
13. 健康診断の結果を受診者に還元したい • 健診結果をより身近なところに ◦ デジタル空間上に配置して、アクセス性を上げる ◦ 相対的な変化を見れるようにする • 情報を連携し、再利用する ◦ スマートウォッチ、ヘルスケア系のアプリ ◦ 他の医療機関、研究所など 13 日々の生活の中で、健康状態を意識できるように。 社会全体として、健やかな生活を送れる環境を。
14. 健康診断の結果を受診者に還元したい • 健診結果をより身近なところに ◦ デジタル空間上に配置して、アクセス性を上げる ◦ 相対的な変化を見れるようにする • 情報を連携し、再利用する ◦ スマートウォッチ、ヘルスケア系のアプリ ◦ 他の医療機関、研究所など 14 日々の生活の中で、健康状態を意識できるように。 社会全体として、健やかな生活を送れる環境を。 → ぼくらの目指す「こと」
15. 15 立ちはだかる「壁」を超える
16. 膨大な知識量、関係性を制する 16
17. オペレーションが非常に煩雑 17 • 申し込みは電話やWeb、FAX • 健診内容の相談、日程調整などをコールセンターが担当 • 様々な医療機器との連携 • 結果は紙で郵送
18. 健康診断を取り巻く環境が複雑 18
19. 論点がすりあわなくなる • 一つのキーワードを複数のコンテキストで共有することになる ◦ 受診者目線での「予約」 ◦ コールセンター目線での「予約」 • 同じキーワードについて語っているつもりが、認識が合わなくなる ◦ 受診者からは「直前の変更を受け付けない」 ◦ コールセンターでは「常に変更ができる」 • 認識の漏れ、勘違いが起きやすくなる ◦ 脳内キャッシュに乗り切らない ◦ 記憶違いを起こしやすい 19
20. 情報と関係を可視化して、コンテキストを明文化する • モデリングによる、関係性・データフローの可視化 ◦ ユースケース図 ◦ ロバストネス図 ◦ ER図 • コンテキスト・スコープを絞って議論できる ◦ 脳内シミュレーションだと人によって認識が変わる • 考慮すべき項目・概念・関係性を網羅的に確認できる 20
21. 問題と解決の認識を合意する 21
22. 課題を抱えている人 vs 課題を解決したい人 • 課題を抱えている人と、解決する人が別の組織 ◦ 問題提起: 健診施設、医療法人 ◦ 解決提起: ぼくたち • 言葉はすべての意図を表現しきれない ◦ これ（人力でやってるので）簡単です ◦ これ（システム化できるので）簡単です • 業務の流れをすべて言語化出来ているわけではない ◦ 予約の電話を受けて、相談に乗って、日時を選んで、内容を伝える ◦ その間のトークスクリプトがすべてドキュメント化されているわけではない 22 どうしても認識に齟齬が生じる
23. 健康診断領域における特有の用語 • 健診 vs 検診 ◦ どちらも「けんしん」 ◦ 前者は健康診断、後者はがん検診など • 使ってるシステム由来の独自概念 ◦ 受付 ▪ 窓口での受付とは別に、システムで行う受付がある ▪ 前日にシステムの受付をやることもあるため、ユースケースが異なる ◦ 契約 ▪ 書面上でかわされる契約と、システム上で管理しているデータとしての契約 ▪ 「この契約って署名ありますよね？」「ないです」「えっ」 23
24. 言葉ではなく、イメージをすり合わせる • 要求の方向性を示す ◦ ユーザーストーリーマップ ◦ プロダクト要求仕様書 • 解決の方向性を示す ◦ 画面遷移図 ◦ ワイヤーフレーム ◦ モックアップ • 月に一度、レビュー会の実施 ◦ 運用者と開発者の間で実際に動きを見て確認 24
25. 言葉ではなく、イメージをすり合わせる 25 抽象的なイメージから、 具体的なソフトウェアとして動作イメージを伝える • 要求の方向性を示す ◦ ユーザーストーリーマップ ◦ プロダクト要求仕様書 • 解決の方向性を示す ◦ 画面遷移図 ◦ ワイヤーフレーム ◦ モックアップ • 月に一度、レビュー会の実施 ◦ 運用者と開発者の間で実際に動きを見て確認
26. 言葉ではなく、イメージをすり合わせる 26 抽象的なイメージから、 具体的なソフトウェアとして動作イメージを伝える → 自身が操作するイメージを持って、具体的に問題を指摘できる • 要求の方向性を示す ◦ ユーザーストーリーマップ ◦ プロダクト要求仕様書 • 解決の方向性を示す ◦ 画面遷移図 ◦ ワイヤーフレーム ◦ モックアップ • 月に一度、レビュー会の実施 ◦ 運用者と開発者の間で実際に動きを見て確認
27. 27 「こと」に向き合うための組織
28. 具体的な成果物で合意する 28
29. 漠然とした認識のままでは擦り合わない • 言葉の認識のギャップがある • 多くの要素と関係性を同時に考慮しきれない • 持ってるメンタルモデルが人によって違う 29
30. 漠然とした認識のままでは擦り合わない • 言葉の認識のギャップがある • 多くの要素と関係性を同時に考慮しきれない • 持ってるメンタルモデルが人によって違う 30 → より具体的な表現で認識を揃える必要がある
31. ツールを使って認識を具体化する • モデリング手法 ◦ ユースケース図 ◦ ロバストネス図 ◦ ER図 • ドキュメント ◦ ユーザーストーリーマップ ◦ 要求仕様書 ◦ 画面遷移図 • モックアップ 31 フェーズによって具体度を上げて、 認識の齟齬を正していく
32. インタラクションを確かめる • 資料を使った議論 ◦ 何について話しているのか、という認識を合わせる ◦ どういう結果を求めているのか、を書き出す • モックアップのレビュー会 ◦ 動きを見ることで、実際の業務をイメージできる ◦ 要求や認識の不足を足し算で把握することができる 32 資料によって、内容の指示がより具体的になる
33. インタラクションを確かめる • 資料を使った議論 ◦ 何について話しているのか、という認識を合わせる ◦ どういう結果を求めているのか、を書き出す • モックアップのレビュー会 ◦ 動きを見ることで、実際の業務をイメージできる ◦ 要求や認識の不足を足し算で把握することができる 33 資料によって、内容の指示がより具体的になる → 具体的な成果物で合意する
34. インタラクションを確かめる • 資料を使った議論 ◦ 何について話しているのか、という認識を合わせる ◦ どういう結果を求めているのか、を書き出す • モックアップのレビュー会 ◦ 動きを見ることで、実際の業務をイメージできる ◦ 要求や認識の不足を足し算で把握することができる 34 資料によって、内容の指示がより具体的になる → 具体的な成果物で合意する → 本質的な開発事項を見定めることができる
35. スクラムで「こと」に向かう 35
36. 可視化と合意形成の方法 • 可視化の方法 ◦ 現場の課題を可視化する → モデリング ◦ 課題解決の手段を可視化する → モックアップ • 合意形成の方法 ◦ 資料を使った議論やレビューを通してのインタラクション 36
37. 可視化と合意形成の方法 • 可視化の方法 ◦ 現場の課題を可視化する → モデリング ◦ 課題解決の手段を可視化する → モックアップ • 合意形成の方法 ◦ 資料を使った議論やレビューを通してのインタラクション 37 あくまで独立した方法論。 どのように組織として運用しているか？
38. 可視化と合意形成の方法 • 可視化の方法 ◦ 現場の課題を可視化する → モデリング ◦ 課題解決の手段を可視化する → モックアップ • 合意形成の方法 ◦ 資料を使った議論やレビューを通してのインタラクション 38 あくまで独立した方法論。 どのように組織として運用しているか？ → スクラムです
39. スクラム • 出典: Scrum Guides • スクラムを土台に、役割やイベントの定義をカスタマイズし運用している 39 チームのスクラムプレイブックの抜粋
40. スクラムによる可視化と明文化 • チームの進捗、成果物の可視化 ◦ スプリントゴール → なにを目指すか ◦ スプリントバックログ → なにに取り組むか ◦ インクリメント → 何を具体化したか • 議論・参入ポイントの明文化 ◦ スプリントレビュー → 成果物の確認、議論 ◦ スプリントプランニング（1部） → 次に何を目指すか ◦ スプリントプランニング（2部） → 次に何を実装するか 40 イベント・成果物を明確に定義し、 関係者を巻き込みやすい体制を構築
41. スプリントレビューとモックアップのレビュー • 月末のレビュー会 ◦ 社外を含むステークホルダーにモックアップの現状を共有、議論する • 2週間に1度のスプリントレビュー ◦ レビュー会に向けて、モックアップの開発進捗を共有、議論する • 2週間に1度のスプリントプランニング ◦ 月末のレビュー会に向けて、スプリントでは何を目指して動くのかを共有 ◦ 開発チームでどう実現するかを議論、方法論と対応事項を決定 41
42. 目的ドリブン開発 • スプリントプランニング（1部）では、次のスプリントレビューまでの期待を示す ◦ 具体的な指示はせず、方針・意図を説明する ◦ 開発チームから、実装を検討する上での質問を行う • スプリントプランニング（2部）では、開発チームが方法論と実現性を提案する ◦ 実際に設計・計画してどこまで実現できそうか ◦ 次回のスプリントレビューでどんなプレゼンができそうか共有する 42 方法論は開発チームに任せ、 あくまで方針のみをハンドルする
43. 目的ドリブン開発 • スプリントプランニング（1部）では、次のスプリントレビューまでの期待を示す ◦ 具体的な指示はせず、方針・意図を説明する ◦ 開発チームから、実装を検討する上での質問を行う • スプリントプランニング（2部）では、開発チームが方法論と実現性を提案する ◦ 実際に設計・計画してどこまで実現できそうか ◦ 次回のスプリントレビューでどんなプレゼンができそうか共有する 43 方法論は開発チームに任せ、 あくまで方針のみをハンドルする → ゴールイメージを元に自律的にチームが動けるように
44. 「こと」に向かう自律的なチーム • メンバーが「こと」を共通認識として持っている ◦ ゴール・方針を理解した上で、今何をすべきかをチームで判断できる • 方法論を提案し続け、固執しない ◦ ゴールに向けて最適な手段を現在地から検討できる ◦ ときには「今あるもの」を壊しても前に進む • 「誰が言ったか」ではなく「何を言ったか」で判断する ◦ ゴールに対して、フラットに手段を考える ◦ 根拠に基づいて議論する • 経験則はチームの知識として積んでいく ◦ 学びをチームに還元し、運用ルールに組み込んでいく • 意思疎通におけるルールを明確にする ◦ 正確な意思疎通を行うために必要なことをチームで考える 44