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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介岩松竜也いわまつ　たつや 2015.04~ 株式会社ビズリーチ (新卒入社) 　・HRMOS採用の立ち上げ: バックエンドエンジニア　・新卒採用(リクルーター) 2020.03~ ビジョナル・インキュベーション株式会社　・Assured の立ち上げ、開発全般、採用 2022.08~ 株式会社アシュアード　・Assured の開発全般、採用、Tech Blog運営 ※ すべてVisionalグループ趣味・ベース(楽器) ・ゲーム(最近はエルデンリングDLC)

Slide 3

Slide 3 text

戦術レベルのドメインモデリング (アーキテクチャ、設計、実装) 今日話さないこと

Slide 4

Slide 4 text

今日話すこと戦略レベルのドメインモデリング (ドメインエキスパート、ユビキタス言語との向き合い方)

Slide 5

Slide 5 text

今日話すこと(参考書) https://www.oreilly.co.jp/books/9784814400737/  ・ドメイン駆動設計の全体がわかりやすく良かった　・戦術レベルの話もこちらにある・本書のエッセンスと当てはまる事例を紹介していく

Slide 6

Slide 6 text

① Assuredとは ②「これまでに存在しない業務フローを作る」とは？ ③ 事例　・0→1 最初のコアドメインが定まるまで　・1→10 次のコアドメインを形にするまで ④ まとめ

Slide 7

Slide 7 text

Google や X(旧Twitter) で検索してみよう「セキュリティチェックシート」をご存知でしょうか？✋

Slide 8

Slide 8 text

個人情報漏洩等のセキュリティインシデントが頻繁に発生しているセキュリティチェックとは

Slide 9

Slide 9 text

セキュリティチェックとは個人情報漏洩等のセキュリティインシデントが頻繁に発生している →クラウドサービスなど、会社間で仕組みを導入する際にどういった情報管理、セキュリティ対策(技術、仕組み) をしているのか確認する商習慣サービスにデータを預けて大丈夫かな？

Slide 10

Slide 10 text

個人情報漏洩等のセキュリティインシデントが頻繁に発生している →クラウドサービスなど、会社間で仕組みを導入する際にどういった情報管理、セキュリティ対策(技術、仕組み) をしているのか確認する商習慣 → メール、Excel形式で依頼されることが多いセキュリティチェックとは

Slide 11

Slide 11 text

利用者/事業者双方の負担が大きく、DXの足かせになっている

Slide 12

Slide 12 text

サービス概要: 信頼性評価 ※SaaSやASP等サービス自体がオープンなネットワークで接続され提供されるものをクラウドサービスとして定義（≒オンプレ等で提供されていない殆どのWebサービス）

Slide 13

Slide 13 text

ひとつの企業が利用するクラウドサービスも膨大 https://assured.jp/column/shadowit2024-report  大手企業の半数以上が100以上のクラウドサービスを利用。 1社あたり平均207サービス利用

Slide 14

Slide 14 text

ひとつの企業が利用するクラウドサービスも膨大 https://assured.jp/column/shadowit2024-report  大手企業の半数以上が100以上のクラウドサービスを利用。 1社あたり平均207サービス利用管理が大変！😩

Slide 15

Slide 15 text

サービス概要: サービス台帳 ※https://assured.jp より引用 Assured独自の推奨項目を利用することでサービスの重要度の判断が可能利用サービスを一元管理

Slide 16

Slide 16 text

サービス概要: 全体像業務フロー Assuredの機能利用検討利用申請調査評価管理棚卸し信頼性評価サービス台帳 Assured 独自のデータベース　　　情報を集約最新のサービスデータベースと同期導入可否判断この領域にも機能を提供していますが今回はスコープ外

Slide 17

Slide 17 text

同種の業務フローは存在しなかった新たに業務フローを定義、共感しご利用いただけたことになる

Slide 18

Slide 18 text

同種の業務フローは存在しなかった新たに業務フローを定義、共感しご利用いただけたことになる → 今はそう言えるけど、ここまで何をやったのでしょうか？

Slide 19

Slide 19 text

Slide 20

Slide 20 text

なにをやってきたのか？コアドメイン(業務領域)を明らかにしてきた

Slide 21

Slide 21 text

なにをやってきたのか？コアドメイン(業務領域)を明らかにしてきた

Slide 22

Slide 22 text

コアドメイン(業務領域)とは ※本書では「コアドメイン」=「業務領域」と置き換えられています “業務領域とは、強く関連するユースケースの集まり” 抜粋: ドメイン駆動設計をはじめようソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov

Slide 23

Slide 23 text

なにをやってきたのか？(具体的には) ※本書では「ドメインエキスパート」=「業務エキスパート」と置き換えられています “業務知識を習得するただ一つの確実な方法は、業務エキスパートとの会話” 抜粋: ドメイン駆動設計をはじめようソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov

Slide 24

Slide 24 text

ドメイン(業務)エキスパートとの会話 🤔

Slide 25

Slide 25 text

🤔 ドメイン(業務)エキスパートとの会話どう情報を引き出すのか？どんな心構えが必要か？ → 再現性がありそうな手法(技術)はないものか

Slide 26

Slide 26 text

① 安易な解に飛びつかない　(=ネガティブ・ケイパビリティを高める) 良さそうだと感じていること ② 他者へのリスペクトを持つ

Slide 27

Slide 27 text

ネガティブ・ケイパビリティとは “ネガティブ・ケイパビリティ（中略）とは、「どうにも答えの出ない、どうにも対処しようのない事態に耐える能力」” 抜粋: ネガティブ・ケイパビリティ　答えの出ない事態に耐える力帚木蓬生

Slide 28

Slide 28 text

自分の理解・不確実、不安定な環境下でストレスを受け入れるドメインモデリングにおけるネガティブ・ケイパビリティ・「わからない」というストレスを受け入れる能力逆にネガティブ・ケイパビリティが低い状態だと... ・「わからない」ことを安易に解決しがちネガティブ・ケイパビリティとは

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

なぜ？どういうこと？ 0→1、1→10のフェーズごとに、 4つの事例で解説してみる

Slide 32

Slide 32 text

Slide 33

Slide 33 text

身近なところ(ビズリーチ社)から、セキュリティチェックシートについて何が起きているのか調査していったなぜかというと... 最初のステップ

Slide 34

Slide 34 text

当時のビズリーチ社(クラウドサービス提供企業)では年間数百件のSC回答コスト、マネージャーがほぼ毎日張り付く状態に… → これを解消するだけでもビジネスになるかも？ → これがコアドメイン…ってコト!? 最初のステップセキュリティチェック（SC）営業担当者開発マネージャードメインエキスパートはわかりやすく困っていた！

Slide 35

Slide 35 text

Slide 36

Slide 36 text

多分エンジニアはこうしたくなる 🤖 回答効率化ツールを作ればいいのに…

Slide 37

Slide 37 text

多分エンジニアはこうしたくなる 🤖 回答効率化ツールを作ればいいのに… ちょっと待って！

Slide 38

Slide 38 text

業務領域(コアドメイン)とは “業務領域の境界を厳密に特定するこのような取り組みが、常に必要でしょうか。中核の業務領域では絶対に必要です。” 抜粋: ドメイン駆動設計をはじめようソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov ※本書では「コアドメイン」=「中核の業務領域」と置き換えられています

Slide 39

Slide 39 text

SCの内容に応じて関係者が増える(みんな困っていた) もうちょっと広く見てみるとセキュリティチェック（SC）営業担当者開発マネージャー法務セキュリティ

Slide 40

Slide 40 text

SCを依頼する側もおり、そちらもみんな困っていた → 困りごともそれぞれ別もうちょっと広く見てみると SC 営業担当者開発マネージャー法務セキュリティセキュリティ担当者法務購買・経理クラウドサービス利用企業クラウドサービス事業者

Slide 41

Slide 41 text

SCを依頼する側もおり、そちらもみんな困っていた → 困りごともそれぞれ別もうちょっと深く聞いてみると SC 営業担当者開発マネージャー法務セキュリティセキュリティ担当者法務購買・経理クラウドサービス利用企業クラウドサービス事業者契約して大丈夫？支払い大丈夫？早く導入したい安全？早く導入したいうちは安全ですうちは安全です回答が大変

Slide 42

Slide 42 text

そもそもなぜSCを依頼するのかセキュリティ(監査)のモチベーションが割合として大きいとわかったもうちょっと深く聞いてみると SC 営業担当者開発マネージャー法務セキュリティセキュリティ担当者法務購買・経理クラウドサービス利用企業クラウドサービス事業者安全？

Slide 43

Slide 43 text

なぜセキュリティ(監査)のモチベーションが大きくなるのか →セキュリティインシデントが経営課題になるから → 単純なコスト削減以上のメリット(経営課題の解決)が見えてきたもうちょっと深く聞いてみると SC 営業担当者開発マネージャー法務セキュリティセキュリティ担当者法務購買・経理クラウドサービス利用企業クラウドサービス事業者安全？

Slide 44

Slide 44 text

Slide 45

Slide 45 text

多くの方がヒアリングを通して多種多様な課題感を話してくださった →そのうえで構造を整理していくには「わからない状態」に耐える必要があるもうちょっと深く聞いてみると SC 営業担当者開発マネージャー法務セキュリティセキュリティ担当者法務購買・経理クラウドサービス利用企業クラウドサービス事業者契約して大丈夫？支払い大丈夫？早く導入したい安全？早く導入したいうちは安全ですうちは安全です回答が大変

Slide 46

Slide 46 text

Slide 47

Slide 47 text

言うは易く行うは難し ② 他者へのリスペクトを持つ ① 安易な解に飛びつかない　(=ネガティブ・ケイパビリティを高める)

Slide 48

Slide 48 text

ドメインエキスパートとの会話そもそもドメインエキスパートと話すとどうなるのかドメインエキスパートエンジニア

Slide 49

Slide 49 text

ドメインエキスパートとの会話 NIST? ISMS? FedRAMP? SOC? BYOD? ISMAP? CASB? EDR?  CSIRT? SIEM? ドメインエキスパートエンジニア自分が無知すぎてびっくりするほど何も話せない！😭

Slide 50

Slide 50 text

多分エンジニアはこうしたくなる 🤖

Slide 51

Slide 51 text

多分エンジニアはこうしたくなる 🤖 PdMが話せばいいのに… ※PdM=プロダクトマネージャー  

Slide 52

Slide 52 text

多分エンジニアはこうしたくなる 🤖 PdMが話せばいいのに… ※PdM=プロダクトマネージャー   ちょっと待って！

Slide 53

Slide 53 text

“業務知識は伝言ゲームの途中で誤って伝わります。そういう誤った情報をもとにして開発すれば誤ったソフトウェアが生まれます。” 抜粋: ドメイン駆動設計をはじめようソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov ドメインエキスパートとどう会話するのか

Slide 54

Slide 54 text

“業務エキスパートからソフトウェア技術者に業務知識を伝えるもっとうまい方法を提案します。それが同じ言葉です。” 抜粋: ドメイン駆動設計をはじめようソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov ドメインエキスパートとどう会話するのか ※本書では「ユビキタス言語」=「同じ言葉」と置き換えられています

Slide 55

Slide 55 text

同じ言葉をどう使うか同じ言葉なるほどなるほど〜と、こういうイメージをしがち「みんなで同じ言葉を定義しよう！」ドメインエキスパートエンジニア

Slide 56

Slide 56 text

“同じ言葉に含まれるのは業務用語だけです。技術用語を含めてはいけません。シングルトンやファクトリーパターンが何であるかを業務エキスパートに教えようとしないでください。” 抜粋: ドメイン駆動設計をはじめようソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov 同じ言葉をどう使うか

Slide 57

Slide 57 text

本当に必要だったこと

Slide 58

Slide 58 text

エンジニアが業務領域を学ぶ本当に必要だったこと

Slide 59

Slide 59 text

つまりこう実際には我々が同じ言葉を知っていく必要があるドメインエキスパートエンジニア同じ言葉

Slide 60

Slide 60 text

勉強とは・会話中に必死で言葉を調べる・質問する・本を読む・アウトプットする理解を整理するため note も書いたりした言葉の背景を知っていく https://note.com/iwamatsu0430/n/n38e97e346bca 

Slide 61

Slide 61 text

言葉の背景を知っていく勉強していくと、言葉の背景もなんとなくわかってくる・どんな文脈で使われるのか・どんな位置づけにあるのか・嬉しいものか、そうでないのか →どんなことを考えるんだろうか？ → ドメインエキスパートに関心を持つ

Slide 62

Slide 62 text

Slide 63

Slide 63 text

ドメインエキスパートに関心を持つ ② 他者へのリスペクトを持つ ① 安易な解に飛びつかない　(=ネガティブ・ケイパビリティを高める)

Slide 64

Slide 64 text

そしてコアドメイン(評価)が生まれました ※SaaSやASP等サービス自体がオープンなネットワークで接続され提供されるものをクラウドサービスとして定義（≒オンプレ等で提供されていない殆どのWebサービス）

Slide 65

Slide 65 text

Slide 66

Slide 66 text

台帳という機能ドメインエキスパートと会話し、プロダクト(評価)を作った → さらに必要な機能を仮説立て、台帳という機能を作っていった

Slide 67

Slide 67 text

台帳という機能 (再掲) https://assured.jp/column/shadowit2024-report  大手企業の半数以上が100以上のクラウドサービスを利用。 1社あたり平均207サービス利用

Slide 68

Slide 68 text

台帳という機能 (再掲) https://assured.jp/column/shadowit2024-report  大手企業の半数以上が100以上のクラウドサービスを利用。 1社あたり平均207サービス利用管理が大変！😩

Slide 69

Slide 69 text

何を評価すべきか取捨選択し、効率的にリスクを管理できる状態を作ればユーザーにとって嬉しいのでは！台帳という機能

Slide 70

Slide 70 text

会話する力が成長した…！？活用を促進するための調査として、ヒアリングを重ねる → 「同じ言葉」の語彙が増えている！話がわかる！

Slide 71

Slide 71 text

会話する力が成長した…！？活用を促進するための調査として、ヒアリングを重ねる → 「同じ言葉」の語彙が増えている！話がわかる！

Slide 72

Slide 72 text

多分慣れてきた人はこうしたくなる 🤖

Slide 73

Slide 73 text

多分慣れてきた人はこうしたくなる 🤖 あ、わかります！ XXXですよね！

Slide 74

Slide 74 text

多分慣れてきた人はこうしたくなる 🤖 あ、わかります！ XXXですよね！つまりXXXなんですよね？

Slide 75

Slide 75 text

多分慣れてきた人はこうしたくなる 🤖 あ、わかります！ XXXですよね！つまりXXXなんですよね？ちょっと待って！

Slide 76

Slide 76 text

勝手に抽象化してない？多分慣れてきた人はこうしたくなる

Slide 77

Slide 77 text

“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 ※ 「ドメイン駆動設計をはじめようソフトウェアの実装と事業戦略を結びつける実践技法」でも引用

Slide 78

Slide 78 text

正しく抽象化(モデリング)しよう “抽象化する目的は、曖昧にすることではなく、絶対的に正確な新しい意味レベルを作り出すことである。” 抜粋: The Humble Programmer Edsger W. Dijkstra https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html ※ 「ドメイン駆動設計をはじめようソフトウェアの実装と事業戦略を結びつける実践技法」でも引用

Slide 79

Slide 79 text

正しく抽象化(モデリング)しよう・そのドメインエキスパートの業務全てを知っているわけではない・境界づけられたコンテキスト(区切られた文脈)が変われば　同じ意味でないかもしれない・時間が経てば境界づけられたコンテキスト(区切られた文脈)も　変わるかもしれない → 正しく抽象化するためには知ったかぶりしない方が良い

Slide 80

Slide 80 text

Slide 81

Slide 81 text

なぜそう言いたくなるのか？限られた時間でより多くの情報を引き出すことを目的とするならば「なぜそうなんですか？」「それはどういった意味ですか？」など、より深堀りする方向に持っていけるはず

Slide 82

Slide 82 text

自分の場合自分が無知と思われることに耐えられないから発していた → 無知を受け入れることが重要(無知の知) なぜそう言いたくなるのか？

Slide 83

Slide 83 text

なぜそう言いたくなるのか？ ② 他者へのリスペクトを持つ ① 安易な解に飛びつかない　(=ネガティブ・ケイパビリティを高める)

Slide 84

Slide 84 text

台帳という箱を使ってもらうにはヒアリングを通して、以下の課題がわかってきたセキュリティ担当者の業務フロー ① 課題認識 ② 計画・ルール整備 ③ 情報収集 ④ データ成形・管理 ⑤ サービス選定・資産管理に問題意識がある・定期調査の必要性を会社として理解している・ルールに基づく判断を行うための必要情報の収集が出来ている・情報ベース、事業判断ベースに応じたリスク評価ルールが整備できている・定期調査の頻度/年間計画がある・必要情報が変更された場合に通達が来る仕組みが整えられている・各種サービスの管理状況を一元化して管理している台帳がある・ルールに応じてリスク評価をするべきサービスを適切に選定して調査が可能な状態台帳にデータを設定するのが手間台帳でサービスを取捨選択できない

Slide 85

Slide 85 text

ロボットくんは言わされているだけです 🤖

Slide 86

Slide 86 text

ロボットくんは言わされているだけです 🤖 インポート機能を作ればいいのに… リッチなフィルタ機能を作ればいいのに…

Slide 87

Slide 87 text

ロボットくんは言わされているだけです 🤖 インポート機能を作ればいいのに… リッチなフィルタ機能を作ればいいのに… リソースがない😇

Slide 88

Slide 88 text

ドメインモデリングは技術者だけのものではない “中核の業務領域は技術的なものとは限りません。アルゴリズムあるいはその他のソフトウェア技術を使わずに事業課題を解決することもあります。” 抜粋: ドメイン駆動設計をはじめようソフトウェアの実装と事業戦略を結びつける実践技法 Vlad Khononov

Slide 89

Slide 89 text

ドメインモデリングは技術者だけのものではない台帳利用を促進するプロジェクトは職種横断 Biz Dev Security

Slide 90

Slide 90 text

ドメインモデリングは技術者だけのものではないセキュリティ担当者の業務フロー ① 課題認識 ② 計画・ルール整備 ③ 情報収集 ④ データ成形・管理 ⑤ サービス選定台帳にデータを設定するのが手間台帳でサービスを取捨選択できない

Slide 91

Slide 91 text

ドメインモデリングは技術者だけのものではないセキュリティ担当者の業務フロー ① 課題認識 ② 計画・ルール整備 ③ 情報収集 ④ データ成形・管理 ⑤ サービス選定台帳にデータを設定するのが手間台帳でサービスを取捨選択できない Assuredにデータを入れるインポート作業を代行、機能の案内やフォローアップ Biz Dev

Slide 92

Slide 92 text

ドメインモデリングは技術者だけのものではないセキュリティ担当者の業務フロー ① 課題認識 ② 計画・ルール整備 ③ 情報収集 ④ データ成形・管理 ⑤ サービス選定台帳にデータを設定するのが手間台帳でサービスを取捨選択できない Assuredにデータを入れるインポート作業を代行、機能の案内やフォローアップ要評価サービスの特定対象を選定するための推奨管理項目 + 重要度判定用Excelを配布 Biz Dev Biz Security

Slide 93

Slide 93 text

Slide 94

Slide 94 text

・ゴール、解決したいことが擦り合っていた・各々の役割で出来ることから総合的な解決策を考えたそれはなぜ？ → 各々の役割を信頼していた(背中を預けあった) なぜできたのか？

Slide 95

Slide 95 text

Slide 96

Slide 96 text

なぜできたのか？ ② 他者(チーム)へのリスペクトを持つ ① 安易な解に飛びつかない　(=ネガティブ・ケイパビリティを高める)

Slide 97

Slide 97 text

Slide 98

Slide 98 text

ドメインエキスパート、ユビキタス言語との向き合い方他者から得られる情報を最大化するためにネガティブ・ケイパビリティを高め、他者をリスペクトする。

Slide 99

Slide 99 text

ドメインエキスパート、ユビキタス言語との向き合い方他者から得られる情報を最大化するためにネガティブ・ケイパビリティを高め、他者をリスペクトする。 → チーム、ドメインエキスパートとの関係が強化され、ドメインモデリングが進んできた

Slide 100

Slide 100 text

ドメインエキスパート、ユビキタス言語との向き合い方他者から得られる情報を最大化するためにネガティブ・ケイパビリティを高め、他者をリスペクトする。 → チーム、ドメインエキスパートとの関係が強化され、ドメインモデリングが進んできた結局は人とどう向き合うか  

Slide 101

Slide 101 text

まとめ Assuredでは、台帳を軸としたセキュリティ評価が根付いてきている👏👏👏

Slide 102

Slide 102 text

しかし、やることはまだまだたくさんある「万物は流転する」だから... まとめ 

Slide 103

Slide 103 text

セキュリティ市場という大海原で、共に波を起こす仲間を募集中です。

Slide 104

Slide 104 text

We are hiring! YouTube (PIVOT) note Tech Blog Assured を知るコンテンツをたくさん用意しています！ご興味が出てきましたら、ぜひご覧ください 󰢛

Slide 105

Slide 105 text

ご清聴ありがとうございました