これまでに存在しない業務フローは どう作っていくか？ドメインエキスパートやビジネスサイド、 チーム一丸となって取り組むドメインモデリング

【Assured×カケハシ】DXを牽引する先進プロダクト開発に携わるエンジニア達が語るドメインモデリング
https://techplay.jp/event/952464

Transcript

1. これまでに存在しない業務フローは どう作っていくか？ ドメインエキスパートやビジネスサイド、 チーム一丸となって取り組むドメインモデリング 株式会社アシュアード　岩松 竜也
2. 自己紹介 岩松 竜也 いわまつ　たつや 2015.04~ 株式会社ビズリーチ (新卒入社) 　・HRMOS採用の立ち上げ: バックエンドエンジニア 　・新卒採用(リクルーター) 2020.03~ ビジョナル・インキュベーション株式会社 　・Assured の立ち上げ、開発全般、採用 2022.08~ 株式会社アシュアード 　・Assured の開発全般、採用、Tech Blog運営 ※ すべてVisionalグループ 趣味 ・ベース(楽器) ・ゲーム(最近はエルデンリングDLC)
3. 戦術レベルのドメインモデリング (アーキテクチャ、設計、実装) 今日話さないこと
4. 今日話すこと 戦略レベルのドメインモデリング (ドメインエキスパート、ユビキタス言語との向き合い方)
5. 今日話すこと(参考書) https://www.oreilly.co.jp/books/9784814400737/
 ・ドメイン駆動設計の全体がわかりやすく良かった 　・戦術レベルの話もこちらにある ・本書のエッセンスと当てはまる事例を紹介していく
6. ① Assuredとは ②「これまでに存在しない業務フローを作る」とは？ ③ 事例 　・0→1 最初のコアドメインが定まるまで 　・1→10 次のコアドメインを形にするまで ④ まとめ
7. Google や X(旧Twitter) で検索してみよう 「セキュリティチェックシート」 をご存知でしょうか？✋
8. 個人情報漏洩等のセキュリティインシデントが頻繁に発生して いる セキュリティチェックとは
9. セキュリティチェックとは 個人情報漏洩等のセキュリティインシデントが頻繁に発生して いる →クラウドサービスなど、会社間で仕組みを導入する際に どういった情報管理、セキュリティ対策(技術、仕組み) をしているのか確認する商習慣 サービスに データを預けて 大丈夫かな？
10. 個人情報漏洩等のセキュリティインシデントが頻繁に発生して いる →クラウドサービスなど、会社間で仕組みを導入する際に どういった情報管理、セキュリティ対策(技術、仕組み) をしているのか確認する商習慣 → メール、Excel形式で依頼されることが多い セキュリティチェックとは
11. 利用者/事業者 双方の負担が大きく、DXの足かせになっている
12. サービス概要: 信頼性評価 ※SaaSやASP等サービス自体がオープンなネットワークで接続され提供されるものをクラウドサービスとして定義 （≒オンプレ等で提供されていない殆どのWebサービス）
13. ひとつの企業が利用するクラウドサービスも膨大 https://assured.jp/column/shadowit2024-report
 大手企業の半数以上が100以上のクラウドサービスを利用。 1社あたり平均207サービス利用
14. ひとつの企業が利用するクラウドサービスも膨大 https://assured.jp/column/shadowit2024-report
 大手企業の半数以上が100以上のクラウドサービスを利用。 1社あたり平均207サービス利用 管理が大変！😩
15. サービス概要: サービス台帳 ※https://assured.jp より引用 Assured独自の推奨項目を利用す ることでサービスの重要度の判断が 可能 利用サービスを一元管理
16. サービス概要: 全体像 業務フロー Assuredの 機能 利用検討 利用申請 調査 評価 管理 棚卸し 信頼性評価 サービス台帳 Assured 独自のデータベース 　　　 情報を集約 最新のサービスデータベースと同期 導入可否判断 この領域にも 機能を提供 していますが 今回はスコープ外
17. 同種の業務フローは存在しなかった 新たに業務フローを定義、共感しご利用いただけたことになる
18. 同種の業務フローは存在しなかった 新たに業務フローを定義、共感しご利用いただけたことになる → 今はそう言えるけど、ここまで何をやったのでしょうか？
19. ① Assuredとは ②「これまでに存在しない業務フローを作る」とは？ ③ 事例 　・0→1 最初のコアドメインが定まるまで 　・1→10 次のコアドメインを形にするまで ④ まとめ
20. なにをやってきたのか？ コアドメイン(業務領域)を明らかにしてきた
21. なにをやってきたのか？ コアドメイン(業務領域)を明らかにしてきた
22. コアドメイン(業務領域)とは ※本書では「コアドメイン」=「業務領域」と置き換えられています “業務領域とは、強く関連する ユースケースの集まり” 抜粋: ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov
23. なにをやってきたのか？(具体的には) ※本書では「ドメインエキスパート」=「業務エキスパート」と置き換えられています “業務知識を習得するただ一つの 確実な方法は、業務エキスパート との会話” 抜粋: ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov
24. ドメイン(業務)エキスパートとの会話 🤔
25. 🤔 ドメイン(業務)エキスパートとの会話 どう情報を 引き出すのか？ どんな心構えが 必要か？ → 再現性がありそうな手法(技術)はないものか
26. ① 安易な解に飛びつかない 　(=ネガティブ・ケイパビリティを高める) 良さそうだと感じていること ② 他者へのリスペクトを持つ
27. ネガティブ・ケイパビリティとは “ネガティブ・ケイパビリティ（中 略）とは、「どうにも答えの出な い、どうにも対処しようのない事 態に耐える能力」” 抜粋: ネガティブ・ケイパビリティ　答えの出ない事態に耐える力 帚木 蓬生
28. 自分の理解 ・不確実、不安定な環境下でストレスを受け入れる ドメインモデリングにおけるネガティブ・ケイパビリティ ・「わからない」というストレスを受け入れる能力 逆にネガティブ・ケイパビリティが低い状態だと... ・「わからない」ことを安易に解決しがち ネガティブ・ケイパビリティとは
29. 自分の理解 ・不確実、不安定な環境下でストレスを受け入れる ドメインモデリングにおけるネガティブ・ケイパビリティ ・「わからない」というストレスを受け入れる能力 逆にネガティブ・ケイパビリティが低い状態だと... ・「わからない」ことを安易に解決しがち ネガティブ・ケイパビリティとは
30. 自分の理解 ・不確実、不安定な環境下でストレスを受け入れる ドメインモデリングにおけるネガティブ・ケイパビリティ ・「わからない」というストレスを受け入れる能力 逆にネガティブ・ケイパビリティが低い状態だと... ・「わからない」ことを安易に解決しがち ネガティブ・ケイパビリティとは
31. なぜ？どういうこと？ 0→1、1→10のフェーズごとに、 4つの事例で解説してみる
32. ① Assuredとは ②「これまでに存在しない業務フローを作る」とは？ ③ 事例 　・0→1 最初のコアドメインが定まるまで 　・1→10 次のコアドメインを形にするまで ④ まとめ
33. 身近なところ(ビズリーチ社)から、 セキュリティチェックシートについて 何が起きているのか調査していった なぜかというと... 最初のステップ
34. 当時のビズリーチ社(クラウドサービス提供企業)では年間数百件のSC回答コスト、 マネージャーがほぼ毎日張り付く状態に… → これを解消するだけでもビジネスになるかも？ → これがコアドメイン…ってコト!? 最初のステップ セキュリティチェック（SC） 営業担当者 開発マネージャー ドメインエキスパートはわかりやすく困っていた！
35. 当時のビズリーチ社(クラウドサービス提供企業)では年間数百件のSC回答コスト、 マネージャーがほぼ毎日張り付く状態に… → これを解消するだけでもビジネスになるかも？ → これがコアドメイン…ってコト!? 最初のステップ セキュリティチェック（SC） 営業担当者 開発マネージャー ドメインエキスパートはわかりやすく困っていた！
36. 多分エンジニアはこうしたくなる 🤖 回答効率化ツール を作ればいいのに…
37. 多分エンジニアはこうしたくなる 🤖 回答効率化ツール を作ればいいのに… ちょっと待って！
38. 業務領域(コアドメイン)とは “業務領域の境界を厳密に特定す るこのような取り組みが、常に必 要でしょうか。中核の業務領域で は絶対に必要です。” 抜粋: ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov ※本書では「コアドメイン」=「中核の業務領域」と置き換えられています
39. SCの内容に応じて関係者が増える(みんな困っていた) もうちょっと広く見てみると セキュリティチェック（SC） 営業担当者 開発マネージャー 法務 セキュリティ
40. SCを依頼する側もおり、そちらもみんな困っていた → 困りごともそれぞれ別 もうちょっと広く見てみると SC 営業担当者 開発マネージャー 法務 セキュリティ セキュリティ 担当者 法務 購買・経理 クラウドサービス利用企業 クラウドサービス事業者
41. SCを依頼する側もおり、そちらもみんな困っていた → 困りごともそれぞれ別 もうちょっと深く聞いてみると SC 営業担当者 開発マネージャー 法務 セキュリティ セキュリティ 担当者 法務 購買・経理 クラウドサービス利用企業 クラウドサービス事業者 契約して 大丈夫？ 支払い 大丈夫？ 早く導入 したい 安全？ 早く導入 したい うちは 安全です うちは 安全です 回答が 大変
42. そもそもなぜSCを依頼するのか セキュリティ(監査)のモチベーションが割合として大きいとわかった もうちょっと深く聞いてみると SC 営業担当者 開発マネージャー 法務 セキュリティ セキュリティ 担当者 法務 購買・経理 クラウドサービス利用企業 クラウドサービス事業者 安全？
43. なぜセキュリティ(監査)のモチベーションが大きくなるのか →セキュリティインシデントが経営課題になるから → 単純なコスト削減以上のメリット(経営課題の解決)が見えてきた もうちょっと深く聞いてみると SC 営業担当者 開発マネージャー 法務 セキュリティ セキュリティ 担当者 法務 購買・経理 クラウドサービス利用企業 クラウドサービス事業者 安全？
44. なぜセキュリティ(監査)のモチベーションが大きくなるのか →セキュリティインシデントが経営課題になるから → 単純なコスト削減以上のメリット(経営課題の解決)が見えてきた もうちょっと深く聞いてみると SC 営業担当者 開発マネージャー 法務 セキュリティ セキュリティ 担当者 法務 購買・経理 クラウドサービス利用企業 クラウドサービス事業者 安全？
45. 多くの方がヒアリングを通して多種多様な課題感を話してくださった →そのうえで構造を整理していくには「わからない状態」に耐える必要がある もうちょっと深く聞いてみると SC 営業担当者 開発マネージャー 法務 セキュリティ セキュリティ 担当者 法務 購買・経理 クラウドサービス利用企業 クラウドサービス事業者 契約して 大丈夫？ 支払い 大丈夫？ 早く導入 したい 安全？ 早く導入 したい うちは 安全です うちは 安全です 回答が 大変
46. 多くの方がヒアリングを通して多種多様な課題感を話してくださった →そのうえで構造を整理していくには「わからない状態」に耐える必要がある もうちょっと深く聞いてみると SC 営業担当者 開発マネージャー 法務 セキュリティ セキュリティ 担当者 法務 購買・経理 クラウドサービス利用企業 クラウドサービス事業者 契約して 大丈夫？ 支払い 大丈夫？ 早く導入 したい 安全？ 早く導入 したい うちは 安全です うちは 安全です 回答が 大変
47. 言うは易く行うは難し ② 他者へのリスペクトを持つ ① 安易な解に飛びつかない 　(=ネガティブ・ケイパビリティを高める)
48. ドメインエキスパートとの会話 そもそもドメインエキスパートと 話すとどうなるのか ドメインエキスパート エンジニア
49. ドメインエキスパートとの会話 NIST? ISMS? FedRAMP? SOC? BYOD? ISMAP? CASB? EDR?
 CSIRT? SIEM? ドメインエキスパート エンジニア 自分が無知すぎて びっくりするほど何も話せない！😭
50. 多分エンジニアはこうしたくなる 🤖
51. 多分エンジニアはこうしたくなる 🤖 PdMが話せば いいのに… ※PdM=プロダクトマネージャー 

52. 多分エンジニアはこうしたくなる 🤖 PdMが話せば いいのに… ※PdM=プロダクトマネージャー 
 ちょっと待って！
53. “業務知識は伝言ゲームの途中で 誤って伝わります。そういう誤っ た情報をもとにして開発すれば 誤ったソフトウェアが生まれま す。” 抜粋: ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov ドメインエキスパートとどう会話するのか
54. “業務エキスパートからソフトウェ ア技術者に業務知識を伝える もっとうまい方法を提案します。 それが同じ言葉です。” 抜粋: ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov ドメインエキスパートとどう会話するのか ※本書では「ユビキタス言語」=「同じ言葉」と置き換えられています
55. 同じ言葉をどう使うか 同じ言葉 なるほどなるほど〜と、こういうイメージをしがち 「みんなで同じ言葉を定義しよう！」 ドメインエキスパート エンジニア
56. “同じ言葉に含まれるのは業務用 語だけです。技術用語を含めて はいけません。シングルトンや ファクトリーパターンが何である かを業務エキスパートに教えよう としないでください。” 抜粋: ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov 同じ言葉をどう使うか
57. 本当に必要だったこと
58. エンジニアが業務領域を学ぶ 本当に必要だったこと
59. つまりこう 実際には我々が同じ言葉を知っていく必要がある ドメインエキスパート エンジニア 同じ言葉
60. 勉強とは ・会話中に必死で言葉を調べる ・質問する ・本を読む ・アウトプットする 理解を整理するため note も書いたりした 言葉の背景を知っていく https://note.com/iwamatsu0430/n/n38e97e346bca

61. 言葉の背景を知っていく 勉強していくと、言葉の背景もなんとなくわかってくる ・どんな文脈で使われるのか ・どんな位置づけにあるのか ・嬉しいものか、そうでないのか →どんなことを考えるんだろうか？ → ドメインエキスパートに関心を持つ
62. 言葉の背景を知っていく 勉強していくと、言葉の背景もなんとなくわかってくる ・どんな文脈で使われるのか ・どんな位置づけにあるのか ・嬉しいものか、そうでないのか →どんなことを考えるんだろうか？ → ドメインエキスパートに関心を持つ
63. ドメインエキスパートに関心を持つ ② 他者へのリスペクトを持つ ① 安易な解に飛びつかない 　(=ネガティブ・ケイパビリティを高める)
64. そしてコアドメイン(評価)が生まれました ※SaaSやASP等サービス自体がオープンなネットワークで接続され提供されるものをクラウドサービスとして定義 （≒オンプレ等で提供されていない殆どのWebサービス）
65. ① Assuredとは ②「これまでに存在しない業務フローを作る」とは？ ③ 事例 　・0→1 最初のコアドメインが定まるまで 　・1→10 次のコアドメインを形にするまで ④ まとめ
66. 台帳という機能 ドメインエキスパートと会話し、プロダクト(評価)を作った → さらに必要な機能を仮説立て、台帳という機能を作っていった
67. 台帳という機能 (再掲) https://assured.jp/column/shadowit2024-report
 大手企業の半数以上が100以上のクラウドサービスを利用。 1社あたり平均207サービス利用
68. 台帳という機能 (再掲) https://assured.jp/column/shadowit2024-report
 大手企業の半数以上が100以上のクラウドサービスを利用。 1社あたり平均207サービス利用 管理が大変！😩
69. 何を評価すべきか取捨選択し、 効率的にリスクを管理できる状態を作れば ユーザーにとって嬉しいのでは！ 台帳という機能
70. 会話する力が成長した…！？ 活用を促進するための調査として、ヒアリングを重ねる → 「同じ言葉」の語彙が増えている！話がわかる！
71. 会話する力が成長した…！？ 活用を促進するための調査として、ヒアリングを重ねる → 「同じ言葉」の語彙が増えている！話がわかる！
72. 多分慣れてきた人はこうしたくなる 🤖
73. 多分慣れてきた人はこうしたくなる 🤖 あ、わかります！ XXXですよね！
74. 多分慣れてきた人はこうしたくなる 🤖 あ、わかります！ XXXですよね！ つまりXXXなんで すよね？
75. 多分慣れてきた人はこうしたくなる 🤖 あ、わかります！ XXXですよね！ つまりXXXなんで すよね？ ちょっと待って！
76. 勝手に抽象化してない？ 多分慣れてきた人はこうしたくなる
77. “the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.” 抜粋: The Humble Programmer Edsger W. Dijkstra 正しく抽象化(モデリング)しよう https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html ※ 「ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法」でも引用
78. 正しく抽象化(モデリング)しよう “抽象化する目的は、曖昧にする ことではなく、絶対的に正確な新 しい意味レベルを作り出すことで ある。” 抜粋: The Humble Programmer Edsger W. Dijkstra https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html ※ 「ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法」でも引用
79. 正しく抽象化(モデリング)しよう ・そのドメインエキスパートの業務全てを知っているわけではない ・境界づけられたコンテキスト(区切られた文脈)が変われば 　同じ意味でないかもしれない ・時間が経てば境界づけられたコンテキスト(区切られた文脈)も 　変わるかもしれない → 正しく抽象化するためには知ったかぶりしない方が良い
80. 正しく抽象化(モデリング)しよう ・そのドメインエキスパートの業務全てを知っているわけではない ・境界づけられたコンテキスト(区切られた文脈)が変われば 　同じ意味でないかもしれない ・時間が経てば境界づけられたコンテキスト(区切られた文脈)も 　変わるかもしれない → 正しく抽象化するためには知ったかぶりしない方が良い
81. なぜそう言いたくなるのか？ 限られた時間でより多くの情報を引き出すことを目的とするならば 「なぜそうなんですか？」「それはどういった意味ですか？」など、 より深堀りする方向に持っていけるはず
82. 自分の場合 自分が無知と思われることに耐えられないから発していた → 無知を受け入れることが重要(無知の知) なぜそう言いたくなるのか？
83. なぜそう言いたくなるのか？ ② 他者へのリスペクトを持つ ① 安易な解に飛びつかない 　(=ネガティブ・ケイパビリティを高める)
84. 台帳という箱を使ってもらうには ヒアリングを通して、以下の課題がわかってきた セキュリティ担当者の業務フロー ① 課題認識 ② 計画・ ルール整備 ③ 情報収集 ④ データ成形・ 管理 ⑤ サービス選定 ・資産管理に問題意識がある ・定期調査の必要性を会社として理解し ている ・ルールに基づく判断を行うための必要 情報の収集が出来ている ・情報ベース、事業判断ベースに応じた リスク評価ルールが整備できている ・定期調査の頻度/年間計画がある ・必要情報が変更された場合に通達が 来る仕組みが整えられている ・各種サービスの管理状況を一元化して 管理している台帳がある ・ルールに応じてリスク評価をするべき サービスを適切に選定して調査が可能 な状態 台帳にデータを 設定するのが手間 台帳でサービスを 取捨選択できない
85. ロボットくんは言わされているだけです 🤖
86. ロボットくんは言わされているだけです 🤖 インポート機能を 作ればいいのに… リッチなフィルタ 機能を作れば いいのに…
87. ロボットくんは言わされているだけです 🤖 インポート機能を 作ればいいのに… リッチなフィルタ 機能を作れば いいのに… リソースがない😇
88. ドメインモデリングは技術者だけのものではない “中核の業務領域は技術的なもの とは限りません。アルゴリズムあ るいはその他のソフトウェア技術 を使わずに事業課題を解決する こともあります。” 抜粋: ドメイン駆動設計をはじめよう ソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov
89. ドメインモデリングは技術者だけのものではない 台帳利用を促進するプロジェクトは職種横断 Biz Dev Security
90. ドメインモデリングは技術者だけのものではない セキュリティ担当者の業務フロー ① 課題認識 ② 計画・ ルール整備 ③ 情報収集 ④ データ成形・ 管理 ⑤ サービス選定 台帳にデータを 設定するのが手間 台帳でサービスを 取捨選択できない
91. ドメインモデリングは技術者だけのものではない セキュリティ担当者の業務フロー ① 課題認識 ② 計画・ ルール整備 ③ 情報収集 ④ データ成形・ 管理 ⑤ サービス選定 台帳にデータを 設定するのが手間 台帳でサービスを 取捨選択できない Assuredにデータを入れる インポート作業を代行、 機能の案内やフォローアップ Biz Dev
92. ドメインモデリングは技術者だけのものではない セキュリティ担当者の業務フロー ① 課題認識 ② 計画・ ルール整備 ③ 情報収集 ④ データ成形・ 管理 ⑤ サービス選定 台帳にデータを 設定するのが手間 台帳でサービスを 取捨選択できない Assuredにデータを入れる インポート作業を代行、 機能の案内やフォローアップ 要評価サービスの特定 対象を選定するための推奨管理項目 + 重要度判定用Excelを配布 Biz Dev Biz Security
93. ドメインモデリングは技術者だけのものではない セキュリティ担当者の業務フロー ① 課題認識 ② 計画・ ルール整備 ③ 情報収集 ④ データ成形・ 管理 ⑤ サービス選定 台帳にデータを 設定するのが手間 台帳でサービスを 取捨選択できない Assuredにデータを入れる インポート作業を代行、 機能の案内やフォローアップ 要評価サービスの特定 対象を選定するための推奨管理項目 + 重要度判定用Excelを配布 Biz Dev Biz Security チームの力で理想的なフローが実現した🙌 ※ 後々、システムによるフローも実現していきました
94. ・ゴール、解決したいことが擦り合っていた ・各々の役割で出来ることから総合的な解決策を考えた それはなぜ？ → 各々の役割を信頼していた(背中を預けあった) なぜできたのか？
95. ・ゴール、解決したいことが擦り合っていた ・各々の役割で出来ることから総合的な解決策を考えた それはなぜ？ → 各々の役割を信頼していた(背中を預けあった) なぜできたのか？
96. なぜできたのか？ ② 他者(チーム)へのリスペクトを持つ ① 安易な解に飛びつかない 　(=ネガティブ・ケイパビリティを高める)
97. ① Assuredとは ②「これまでに存在しない業務フローを作る」とは？ ③ 事例 　・0→1 最初のコアドメインが定まるまで 　・1→10 次のコアドメインを形にするまで ④ まとめ
98. ドメインエキスパート、ユビキタス言語との向き合い方 他者から得られる情報を最大化するために ネガティブ・ケイパビリティを高め、 他者をリスペクトする。
99. ドメインエキスパート、ユビキタス言語との向き合い方 他者から得られる情報を最大化するために ネガティブ・ケイパビリティを高め、 他者をリスペクトする。 → チーム、ドメインエキスパートとの関係が強化され、 ドメインモデリングが進んできた
100. ドメインエキスパート、ユビキタス言語との向き合い方 他者から得られる情報を最大化するために ネガティブ・ケイパビリティを高め、 他者をリスペクトする。 → チーム、ドメインエキスパートとの関係が強化され、 ドメインモデリングが進んできた 結局は人とどう向き合うか 

101. まとめ Assuredでは、台帳を軸としたセキュリティ評価が根付いてきている👏👏👏
102. しかし、やることはまだまだたくさんある 「万物は流転する」 だから... まとめ

103. セキュリティ市場という大海原で、共に波を起こす仲間を募集中です。
104. We are hiring! YouTube (PIVOT) note Tech Blog Assured を知るコンテンツをたくさん用意しています！ ご興味が出てきましたら、ぜひご覧ください 󰢛
105. ご清聴ありがとうございました