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

Slide 1

Slide 1 text

コトに向かうチームビルディング〜健康診断のDXを目指して〜技術統括部プロダクト開発部 DXソリューション開発グループ飯沼遼

Slide 2

Slide 2 text

飯沼遼 / @mizuki_r 所属: 技術統括部プロダクト開発部 DXソリューション開発グループグループリーダー兼フロントエンドエンジニア経歴: 2011/04 株式会社モバイルファクトリー 2018/10 弁護士ドットコム株式会社 2022/05 株式会社ディー・エヌ・エー 2

Slide 3

Slide 3 text

健康診断をきっかけに15kgのダイエットに成功 ● コロナ禍中の運動不足 ○ 何もしてなくても心拍数120 ○ 息が切れる ● 体重80kg → 65kg ○ 毎日のウォーキング ○ 2022年には10kmマラソン ● 健康は大事 3

Slide 4

Slide 4 text

Agenda 僕たちの向き合う「こと」 ● 健康診断のもたらす価値 ● 診断結果を活用し、健やかな生活を 4 立ちはだかる「壁」を乗り越える ● 膨大な知識量、関係性を制する ● 問題と解決の認識を合意する「こと」に向かう組織を作る ● 具体的な成果物で合意する ● スクラムで「こと」に向かう

Slide 5

Slide 5 text

5 僕たちの向き合う「こと」

Slide 6

Slide 6 text

健康診断のもたらす価値前提として、健康診断とはどのようなものなのかを解説します 6

Slide 7

Slide 7 text

健康診断の概要 ● 病気の予防・早期発見を目的に行われる総合的な検査プログラム ● 年に一度、指定の検査を内包する健康診断の受診が事業者・学校には義務付けられている ○ 法定健診と一般的に呼ばれる ○ 厚生労働省より、労働安全衛生法第66条に定められる ● 特定の身体状態を検査する診察のことを検診と呼ぶ ○ 例: がん検診、メタボ検診、等 ● 人間ドックは法定検診の内容に検診をかけ合わせたものが多い ○ より広くリスクを診断できる 7

Slide 8

Slide 8 text

健康診断がもたらす価値 ● 定期的に自身の健康状態を確認できる ○ 相対的に体質や体調の変化を計測している ○ 生活習慣の見直しのトリガー ● 施設や検査の内容に応じてリスクの高い病気を早期に発見できる ○ がん、糖尿病など ● 診断結果が怪しい場合は速やかに病院にかかる ○ これまで通りの生活を続けたいなら ○ 毎週ラーメン食べたい 8

Slide 9

Slide 9 text

診断結果を活用し、健やかな生活を 9

Slide 10

Slide 10 text

健康診断の結果の再利用性 ● 2年前の健康診断の結果って覚えてます？ ● 良くなった項目はなんですか？ ● 悪くなった項目はなんですか？ ● 体重何kg増えました？ 10

Slide 11

Slide 11 text

健康診断の結果の再利用性 - 僕の場合 ● 気づいたら5kg増えていた ● 体重すらまともに計測していない ● なんなら、診断結果の紙がどこにあるかわからない 11

Slide 12

Slide 12 text

健康診断の結果を受診者に還元したい ● 健診結果をより身近なところに ○ デジタル空間上に配置して、アクセス性を上げる ○ 相対的な変化を見れるようにする ● 情報を連携し、再利用する ○ スマートウォッチ、ヘルスケア系のアプリ ○ 他の医療機関、研究所など 12

Slide 13

Slide 13 text

健康診断の結果を受診者に還元したい ● 健診結果をより身近なところに ○ デジタル空間上に配置して、アクセス性を上げる ○ 相対的な変化を見れるようにする ● 情報を連携し、再利用する ○ スマートウォッチ、ヘルスケア系のアプリ ○ 他の医療機関、研究所など 13 日々の生活の中で、健康状態を意識できるように。社会全体として、健やかな生活を送れる環境を。

Slide 14

Slide 14 text

健康診断の結果を受診者に還元したい ● 健診結果をより身近なところに ○ デジタル空間上に配置して、アクセス性を上げる ○ 相対的な変化を見れるようにする ● 情報を連携し、再利用する ○ スマートウォッチ、ヘルスケア系のアプリ ○ 他の医療機関、研究所など 14 日々の生活の中で、健康状態を意識できるように。社会全体として、健やかな生活を送れる環境を。 → ぼくらの目指す「こと」

Slide 15

Slide 15 text

15 立ちはだかる「壁」を超える

Slide 16

Slide 16 text

膨大な知識量、関係性を制する 16

Slide 17

Slide 17 text

オペレーションが非常に煩雑 17 ● 申し込みは電話やWeb、FAX ● 健診内容の相談、日程調整などをコールセンターが担当 ● 様々な医療機器との連携 ● 結果は紙で郵送

Slide 18

Slide 18 text

健康診断を取り巻く環境が複雑 18

Slide 19

Slide 19 text

論点がすりあわなくなる ● 一つのキーワードを複数のコンテキストで共有することになる ○ 受診者目線での「予約」 ○ コールセンター目線での「予約」 ● 同じキーワードについて語っているつもりが、認識が合わなくなる ○ 受診者からは「直前の変更を受け付けない」 ○ コールセンターでは「常に変更ができる」 ● 認識の漏れ、勘違いが起きやすくなる ○ 脳内キャッシュに乗り切らない ○ 記憶違いを起こしやすい 19

Slide 20

Slide 20 text

情報と関係を可視化して、コンテキストを明文化する ● モデリングによる、関係性・データフローの可視化 ○ ユースケース図 ○ ロバストネス図 ○ ER図 ● コンテキスト・スコープを絞って議論できる ○ 脳内シミュレーションだと人によって認識が変わる ● 考慮すべき項目・概念・関係性を網羅的に確認できる 20

Slide 21

Slide 21 text

問題と解決の認識を合意する 21

Slide 22

Slide 22 text

課題を抱えている人 vs 課題を解決したい人 ● 課題を抱えている人と、解決する人が別の組織 ○ 問題提起: 健診施設、医療法人 ○ 解決提起: ぼくたち ● 言葉はすべての意図を表現しきれない ○ これ（人力でやってるので）簡単です ○ これ（システム化できるので）簡単です ● 業務の流れをすべて言語化出来ているわけではない ○ 予約の電話を受けて、相談に乗って、日時を選んで、内容を伝える ○ その間のトークスクリプトがすべてドキュメント化されているわけではない 22 どうしても認識に齟齬が生じる

Slide 23

Slide 23 text

健康診断領域における特有の用語 ● 健診 vs 検診 ○ どちらも「けんしん」 ○ 前者は健康診断、後者はがん検診など ● 使ってるシステム由来の独自概念 ○ 受付 ■ 窓口での受付とは別に、システムで行う受付がある ■ 前日にシステムの受付をやることもあるため、ユースケースが異なる ○ 契約 ■ 書面上でかわされる契約と、システム上で管理しているデータとしての契約 ■ 「この契約って署名ありますよね？」「ないです」「えっ」 23

Slide 24

Slide 24 text

言葉ではなく、イメージをすり合わせる ● 要求の方向性を示す ○ ユーザーストーリーマップ ○ プロダクト要求仕様書 ● 解決の方向性を示す ○ 画面遷移図 ○ ワイヤーフレーム ○ モックアップ ● 月に一度、レビュー会の実施 ○ 運用者と開発者の間で実際に動きを見て確認 24

Slide 25

Slide 25 text

言葉ではなく、イメージをすり合わせる 25 抽象的なイメージから、具体的なソフトウェアとして動作イメージを伝える ● 要求の方向性を示す ○ ユーザーストーリーマップ ○ プロダクト要求仕様書 ● 解決の方向性を示す ○ 画面遷移図 ○ ワイヤーフレーム ○ モックアップ ● 月に一度、レビュー会の実施 ○ 運用者と開発者の間で実際に動きを見て確認

Slide 26

Slide 26 text

言葉ではなく、イメージをすり合わせる 26 抽象的なイメージから、具体的なソフトウェアとして動作イメージを伝える → 自身が操作するイメージを持って、具体的に問題を指摘できる ● 要求の方向性を示す ○ ユーザーストーリーマップ ○ プロダクト要求仕様書 ● 解決の方向性を示す ○ 画面遷移図 ○ ワイヤーフレーム ○ モックアップ ● 月に一度、レビュー会の実施 ○ 運用者と開発者の間で実際に動きを見て確認

Slide 27

Slide 27 text

27 「こと」に向き合うための組織

Slide 28

Slide 28 text

具体的な成果物で合意する 28

Slide 29

Slide 29 text

漠然とした認識のままでは擦り合わない ● 言葉の認識のギャップがある ● 多くの要素と関係性を同時に考慮しきれない ● 持ってるメンタルモデルが人によって違う 29

Slide 30

Slide 30 text

漠然とした認識のままでは擦り合わない ● 言葉の認識のギャップがある ● 多くの要素と関係性を同時に考慮しきれない ● 持ってるメンタルモデルが人によって違う 30 → より具体的な表現で認識を揃える必要がある

Slide 31

Slide 31 text

ツールを使って認識を具体化する ● モデリング手法 ○ ユースケース図 ○ ロバストネス図 ○ ER図 ● ドキュメント ○ ユーザーストーリーマップ ○ 要求仕様書 ○ 画面遷移図 ● モックアップ 31 フェーズによって具体度を上げて、認識の齟齬を正していく

Slide 32

Slide 32 text

インタラクションを確かめる ● 資料を使った議論 ○ 何について話しているのか、という認識を合わせる ○ どういう結果を求めているのか、を書き出す ● モックアップのレビュー会 ○ 動きを見ることで、実際の業務をイメージできる ○ 要求や認識の不足を足し算で把握することができる 32 資料によって、内容の指示がより具体的になる

Slide 33

Slide 33 text

インタラクションを確かめる ● 資料を使った議論 ○ 何について話しているのか、という認識を合わせる ○ どういう結果を求めているのか、を書き出す ● モックアップのレビュー会 ○ 動きを見ることで、実際の業務をイメージできる ○ 要求や認識の不足を足し算で把握することができる 33 資料によって、内容の指示がより具体的になる → 具体的な成果物で合意する

Slide 34

Slide 34 text

インタラクションを確かめる ● 資料を使った議論 ○ 何について話しているのか、という認識を合わせる ○ どういう結果を求めているのか、を書き出す ● モックアップのレビュー会 ○ 動きを見ることで、実際の業務をイメージできる ○ 要求や認識の不足を足し算で把握することができる 34 資料によって、内容の指示がより具体的になる → 具体的な成果物で合意する → 本質的な開発事項を見定めることができる

Slide 35

Slide 35 text

スクラムで「こと」に向かう 35

Slide 36

Slide 36 text

可視化と合意形成の方法 ● 可視化の方法 ○ 現場の課題を可視化する → モデリング ○ 課題解決の手段を可視化する → モックアップ ● 合意形成の方法 ○ 資料を使った議論やレビューを通してのインタラクション 36

Slide 37

Slide 37 text

可視化と合意形成の方法 ● 可視化の方法 ○ 現場の課題を可視化する → モデリング ○ 課題解決の手段を可視化する → モックアップ ● 合意形成の方法 ○ 資料を使った議論やレビューを通してのインタラクション 37 あくまで独立した方法論。どのように組織として運用しているか？

Slide 38

Slide 38 text

可視化と合意形成の方法 ● 可視化の方法 ○ 現場の課題を可視化する → モデリング ○ 課題解決の手段を可視化する → モックアップ ● 合意形成の方法 ○ 資料を使った議論やレビューを通してのインタラクション 38 あくまで独立した方法論。どのように組織として運用しているか？ → スクラムです

Slide 39

Slide 39 text

スクラム ● 出典: Scrum Guides ● スクラムを土台に、役割やイベントの定義をカスタマイズし運用している 39 チームのスクラムプレイブックの抜粋

Slide 40

Slide 40 text

スクラムによる可視化と明文化 ● チームの進捗、成果物の可視化 ○ スプリントゴール → なにを目指すか ○ スプリントバックログ → なにに取り組むか ○ インクリメント → 何を具体化したか ● 議論・参入ポイントの明文化 ○ スプリントレビュー → 成果物の確認、議論 ○ スプリントプランニング（1部） → 次に何を目指すか ○ スプリントプランニング（2部） → 次に何を実装するか 40 イベント・成果物を明確に定義し、関係者を巻き込みやすい体制を構築

Slide 41

Slide 41 text

スプリントレビューとモックアップのレビュー ● 月末のレビュー会 ○ 社外を含むステークホルダーにモックアップの現状を共有、議論する ● 2週間に1度のスプリントレビュー ○ レビュー会に向けて、モックアップの開発進捗を共有、議論する ● 2週間に1度のスプリントプランニング ○ 月末のレビュー会に向けて、スプリントでは何を目指して動くのかを共有 ○ 開発チームでどう実現するかを議論、方法論と対応事項を決定 41

Slide 42

Slide 42 text

目的ドリブン開発 ● スプリントプランニング（1部）では、次のスプリントレビューまでの期待を示す ○ 具体的な指示はせず、方針・意図を説明する ○ 開発チームから、実装を検討する上での質問を行う ● スプリントプランニング（2部）では、開発チームが方法論と実現性を提案する ○ 実際に設計・計画してどこまで実現できそうか ○ 次回のスプリントレビューでどんなプレゼンができそうか共有する 42 方法論は開発チームに任せ、あくまで方針のみをハンドルする

Slide 43

Slide 43 text

目的ドリブン開発 ● スプリントプランニング（1部）では、次のスプリントレビューまでの期待を示す ○ 具体的な指示はせず、方針・意図を説明する ○ 開発チームから、実装を検討する上での質問を行う ● スプリントプランニング（2部）では、開発チームが方法論と実現性を提案する ○ 実際に設計・計画してどこまで実現できそうか ○ 次回のスプリントレビューでどんなプレゼンができそうか共有する 43 方法論は開発チームに任せ、あくまで方針のみをハンドルする → ゴールイメージを元に自律的にチームが動けるように

Slide 44

Slide 44 text

「こと」に向かう自律的なチーム ● メンバーが「こと」を共通認識として持っている ○ ゴール・方針を理解した上で、今何をすべきかをチームで判断できる ● 方法論を提案し続け、固執しない ○ ゴールに向けて最適な手段を現在地から検討できる ○ ときには「今あるもの」を壊しても前に進む ● 「誰が言ったか」ではなく「何を言ったか」で判断する ○ ゴールに対して、フラットに手段を考える ○ 根拠に基づいて議論する ● 経験則はチームの知識として積んでいく ○ 学びをチームに還元し、運用ルールに組み込んでいく ● 意思疎通におけるルールを明確にする ○ 正確な意思疎通を行うために必要なことをチームで考える 44