モデリング実践で見えた 分析モデルと業務モデルの特性

# モデリングの実践と苦悩 〜かとじゅんさんと探る成功の鍵〜
18:50 「モデリング実践で見えた分析モデルと業務モデルの特性」 前原 宗太朗（レバテック株式会社）

# 概要
事業企画の方からの依頼を受けてモデリングを実践してみたら、分析観点と業務観点のモデリングの特性の違いがわかり、関係者のメンタルモデルが見えてきたお話

Transcript

1. モデリング実践で見えた 分析モデルと業務モデルの特性 レバテック開発部 ビジネスサポートグループ 前原 宗太朗
2. |　© 2024 Levtech Co., Ltd. 2 レバテック開発部 前原 宗太朗 SOTARO MAEHARA 2022年6月にレバテックに入社し、マイクロサービスの開発を行う。 現在は特定領域の問題を解消するドメインチームで開発を行っています。 趣味はLoLのe-sports観戦。# DFMWIN
3. |　© 2024 Levtech Co., Ltd. 3 事業企画の方から依頼を受けてモデリングを実践してみたら 分析観点と業務観点のモデリングの特性の違いがわかり 関係者のメンタルモデルが見えてきた 今日話すこと
4. |　© 2024 Levtech Co., Ltd. 4 マイクロサービスの保守・運用をしていた私たち プラットフォームエンジニアチームとして、ストリームアラインドチームの 手助けをしてました ある日の出来事 導入 マイクロサービス の提供 サービスの利用 要求の 取りまとめ 開発依頼 私たち （プラットフォームチーム） ビジネスサポートチーム （ストリームアラインドチーム） 営業 事業企画
5. |　© 2024 Levtech Co., Ltd. 5 ある日の出来事 導入 今日から君たちは 案件領域のエキスパートになるのだ 詳細は「いつ Platform Engineeringを始めるべきか？〜レバテックのケーススタディ〜 Platform Engineering Kaigi 2024」を見てね！ https://speakerdeck.com/leveragestech/ituplatform-engineeringwoshi-merubekika-rebatetukunokesusutadei-platform-engineering-kaigi-2024
6. |　© 2024 Levtech Co., Ltd. 6 特定領域の問題を扱うドメインチームとして活動することに そして、業務のキャッチアップも含め改善タスクの一つを請け負うことに ある日の出来事 導入 サービスの利用 要求の 取りまとめ 開発依頼 私たち ビジネスサポートチーム 案件ドメインユニット ビジネスサポートチーム （ストリームアラインドチーム） 営業 事業企画 さよなら〜 合流！！
7. |　© 2024 Levtech Co., Ltd. 7 「案件」という概念は、企業が「案件」を提案し フリーランスが「案件」にお申し込みする。というもの 案件とは 導入 案件 案件提案 申し込み
8. |　© 2024 Levtech Co., Ltd. 8 1. 企業からレバテックに依頼して発生する 2. レバテックから状況をお伺いして発生する 案件の発生経緯を分析するために カラムを新設したいという事業企画からの依頼 案件の発生パターン 導入 PJが立ち上がったの で人が欲しい 最近の状況いかがで しょうか？
9. |　© 2024 Levtech Co., Ltd. 9 現存する案件ステータス変更履歴テーブルに流入経路マスタを新たに定義して カラムを追加して記録するようにする 依頼内容 モデリング実践 追加するマスタの定義 流入経路マスタ 企業から（電話・メール） 企業から（推薦ツール） レバテックから（電話） レバテックから（メール） レバテックから（訪問） その他 案件 名前 ... 案件ステータス変更履歴 変更日時 流入経路 New!!
10. |　© 2024 Levtech Co., Ltd. 10 依頼内容 モデリング実践 この時に論点になっていたのは、マスタを発生主体（企業 or レバテック）で分けるのか 我々が入る前は、入力のしやすさを考慮して、左の案が採用されそうでした 案2の方が良さそうと思ったものの、そもそもの疑問として。。。 発生主体 企業から レバから その他 発生ツール 電話 メール 推薦ツール 訪問 流入経路マスタ 企業から（電話・メール） 企業から（推薦ツール） レバテックから（電話） レバテックから（メール） レバテックから（訪問） その他 案1 一つのマスタとして定義 案2 発生の主体とツールを分ける
11. |　© 2024 Levtech Co., Ltd. 11 「案件を開始するぞー」ってなった時に、元となった活動を選択させるって業務として不 自然じゃないか？ そもそも「電話した」「電話を受けた」などの記録は、時間軸として別なので、異なるモデ ルとして定義するべきなのでは？ 疑問 モデリング実践 架電 案件発生 過去 未来
12. |　© 2024 Levtech Co., Ltd. 12 話を聞くと活動履歴というテーブルがあるらしい 営業さんが何かしらの活動した記録を残すためのテーブル すでに「電話した」「電話を受けた」などを記録するための項目が存在する このテーブルを拡張して、開始イベントと紐づければいいのではないか？ 活動履歴と言われるもの モデリング実践
13. |　© 2024 Levtech Co., Ltd. 13 活動履歴テーブルは「何でも」テーブル ここに追加するのはまた新たな負債を生んでしまう気がする 別の案件活動として定義し直し、移行させることを検討 業務のフローの変更も提案したが、様々な事情により頓挫（後述します） 活動履歴テーブルを見てみる モデリング実践
14. |　© 2024 Levtech Co., Ltd. 14 発生主体がレバテックのものと発生主体が企業のものは同じテーブルとして扱ってい いのか？ • 目的が違う • アクターが違う • 記録すべき情報も違う サブタイプとして扱うようにする さらなる疑問 モデリング実践
15. |　© 2024 Levtech Co., Ltd. 15 時間軸が異なる業務を異なるモデルとして分離 持つべき情報が異なるモデルをサブタイプに分離 最終的に モデリング実践 案件 名前 ... 案件ステータス変更履歴 変更日時 案件活動ID New! 案件活動 活動タイプ 活動日時 ユーザーID インバウンド案件活動 活動詳細 活動内容 … アウトバウンド案件活動 活動詳細 活動内容 … ※ この時はサブタイプとして扱ってしまったが、そもそも別のモデルとして扱ってよかったと思います インバウンドって活動じゃないじゃん w New! New!
16. |　© 2024 Levtech Co., Ltd. 16 • 良かったこと 異なる概念が別のモデルに分離されたことにより、モデルが業務の内容を表すようになった モデリングを通して業務への理解が深まった • 悪かったこと 本当にモデリングがあっているかがわからない 既存のモデルに引きずられてしまった その結果どうだったか モデリング実践
17. |　© 2024 Levtech Co., Ltd. 17 タスクを進めるにあたってどこか引っかかる部分があった • カラムを追加してくださいという具体的な依頼 • データの綺麗さよりも入力のしやすさを気にする（トレードオフの関係ではないはず） • 入力のしやすさなどに言及をしても響かなかったり 拭いきれない違和感 モデリング実践
18. |　© 2024 Levtech Co., Ltd. 18 急成長した反面、技術的負債の蓄積 その結果、改善のスピード < 要望の上がるスピード 手をつけられない改善タスクが増えた 改善要望が叶えられなくとも、営業としては目標を達成しないといけない システムで叶えられないところは独自で頑張るしかない 活動履歴も社内システムで直接入力しているわけではなく、スプシ で管理して一括投入する運用を行っている 話を聞くと 要望のスピードに 改修が追いつかない システムでできないこ とは我々で解決 ※ 今は業務委託の方にイネイブリングしてもらいながら 爆速改善しています
19. |　© 2024 Levtech Co., Ltd. 19 基幹システムは活動のためのシステムと経営管理のシ ステムに区分される 在庫管理でいうところの • 在庫数を現場で管理する • 適正在庫数を算出する つまり事業計画を立てる人と業務を遂行する人では、 見てる観点が異なり、モデルの関心ごとも異なる 時を同じくして勉強会にて 杉本 啓. データモデリングでドメインを駆動する ──分散／疎結合な 基幹系システムに向けて . 株式会社技術評論社 .
20. |　© 2024 Levtech Co., Ltd. 20 • 依頼を出すのは計画を立てる人 必然的に分析観点の依頼になる どういう切り口で分析するのか • 実際に入力するのは業務を遂行する人 現場の人たちが残すのは、実際の行動 業務に即しているかが大事な観点 分析視点と業務視点の違い
21. |　© 2024 Levtech Co., Ltd. 21 • 依頼者はクエリを書くことができデータベースに関する知識も多少備えている • 現行のシステムはUIとDBのモデルがほぼ1対1で紐づく • 社内システムにはレポート機能と呼ばれる内製のBIツールがある テーブルにカラムを追加して、分析するイメージが湧きやすい 依頼者の特性
22. |　© 2024 Levtech Co., Ltd. 22 観点の違い × 依頼者の特性により、分析観点の強い要望がきやすく 事業インパクトが高いので必然的に優先度高くなる 結果として
23. |　© 2024 Levtech Co., Ltd. 23 • データの綺麗さよりも入力のしやすさを気にする（トレードオフの関係ではないのにな） →UIとDBのモデルがほぼ1対1で紐づくというメンタルモデル • 入力のしやすさなどの言及をしても響かなかったり →履行管理はSSの方がメリットがあるため、システムで改善する発想がなかった • カラムを追加してくださいという具体的な依頼 →分析観点の強い依頼が優先度高く挙げられる 拭いきれぬ違和感の正体
24. |　© 2024 Levtech Co., Ltd. 24 拭いきれぬ違和感の正体 情報 レバテック開発部 全社横断データ戦略室 計画 事業企画 立案 営業 遂行・記録
25. |　© 2024 Levtech Co., Ltd. 25 拭いきれぬ違和感の正体 情報 レバテック開発部 全社横断データ戦略室 計画 事業企画 遂行 立案 営業 情報 分析モデル=入力すべきものとしての共通認識
26. |　© 2024 Levtech Co., Ltd. 26 今我々に必要なのは 分析観点と業務観点のモデリングの特性の違いとその構造を知り、伝えること 事実 情報 レバテック開発部 全社横断データ戦略室 解釈 計画 事業企画 遂行・記録 立案 営業
27. |　© 2024 Levtech Co., Ltd. 27 事業企画の方から依頼を受けてモデリングを実践してみたら 分析観点と業務観点のモデリングの特性の違いがわかり 関係者のメンタルモデルが見えてきた まとめ