そのデータ連携、ホントにそれでいいの？──データモデル分析の重要性を解説

株式会社カケハシ
技術戦略室　木村 彰宏氏

2021年にカケハシに入社後、サービス・データプラットフォームのアーキテクトを担った後に、技術戦略室にて開発組織全体の技術領域の戦略を推進。データを軸にした設計・開発のキャリアを強みに、カケハシでもデータ連携を含む、様々なアーキテクチャレビューに携わっています。

医療業界全体のバリューチェーン実現を目指す

「日本の医療体験を、しなやかに」というミッションを掲げ、2016年に設立したカケハシ。薬局業務の効率化に寄与する電子薬歴・服薬指導システム「Musubi（ムスビ）」を開発しました。以降、Musubiで得たデータを活用し、薬局と患者に価値あるサービスを次々とリリースしています。

例えば、データドリブン経営を実現するための「Musubi Insight」、患者と薬局のコミュニケーションを醸成するためのおくすり連絡帳アプリ「Pocket Musubi」などが挙げられます。現在はAI技術を使った来局予測や需要予測をベースとした「AI在庫管理」などのプロダクトも開発しています。

カケハシは、今後もプロダクトでよりよい体験を提供し、プロダクトから得たデータを活用して、医療業界全体のバリューチェーンに向けたプロダクト展開で価値提供をしていくといいます。

「実際、データの連携数は年々増加傾向にあります」と、木村氏は語ります。具体的には、境界付けられたコンテキスト内で独立して実行・デプロイされる30のシステムがあります。そのコンテキストを跨ぐシステム間のデータ連携数は135にも上ります。

一方、連携する対象のデータモデリングを行わずに、具体的な連携方法やインフラ構成が検討され、結果的に局所最適につながるような課題があるといいます。

モデルベースでの分割統治手法として、境界づけられたコンテキストという方法論があります。これは、ドメイン駆動設計で取り上げられている手法であり、マイクロサービスアーキテクチャやイベント駆動アーキテクチャなどの分散アーキテクチャの文脈で再フィーチャーされています。

境界づけられたコンテキストは有効な手段でありますが、データ連携するプロダクトがドメインモデルベースで組まれていないと、そのまま使えない場合もあります。また、適切な境界の定義をするための根拠が語られていることは少ない状況です。そのため、現場で適用するには工夫が必要でした。

データ連携は4つに分解して考える

データ連携は「イベント分析」「所有分析」「データフロー分析」「システムコンテキスト分析」の4つに分解して考えていると、木村氏は解説します。

１．イベント分析

データ連携のほとんどは、データを利用したいコンシューマー側からの要望が起点になります。しかし、利用者のデータへの理解が得られていないことが多いようです。

イベント分析は対象データに関連するイベントを列挙することから始めます。イベントから、対象データのライフサイクル(どのように生成され、どう変更されるのか)を分析します。

木村氏は、以下スライドの「注文」データを例に説明を行いました。

分析の過程で「注文キャンセル」イベントにおいて、「注文」データが削除されていることが発覚したとします。しかし、コンシューマーは、キャンセルも含めた過去の注文動向のデータが欲しい場合は「注文」データを連携しても業務を達成できません。業務を達成するには、「注文」のデータモデルを見直すか、「注文キャンセル」イベントの供給をするといった検討が必要になります。

「イベントは対象データの変更理由であり、イベント分析をすることでプロバイダー側が提供するデータモデルを再設計するきっかけを作ります」と、木村氏は解説します。

このように、対象データからイベントを逆算してプロバイダーとコンシューマー間で業務知識を共有し、最適なデータモデルを模索することが重要だと語りました。

2．所有分析

続いては「所有分析」です。そもそも所有とは、データへの書き込み操作を行うサービスがそのデータを所有すること。また、「イベント分析」でのイベントが対象データの書き込み操作の全てだと、木村氏は補足しました。

そして最適な所有を見つけるには、対象データの利用用途と制約を明らかにすることが有効だと語りました。

また、事例も紹介されました。薬局向けの管理画面サービスです。当初は、既在するモノリスな管理画面サービスにて、「通数上限」を所有し、ストリーミングでデータ連携を検討していたといいます。

しかし木村氏は、このようなデータ連携に対する疑問とともに、改めて分析を行いました。

その結果、当初とは異なりSMSサービスが通数上限を所有することとし、管理画面サービスとのパスは解除。管理画面フロントエンドからSMS送信サービスへAPI通信をするアーキテクチャ構成に刷新されました。所有分析について、木村氏は次のように述べています。

「各サービスを運用するチームが異なっている場合は、サービスを横断した議論に発展しない場合もあります。そのためデータ連携以前に、チームおよびサービスを横断して所有分析することは重要です」（木村氏）

3．データフロー分析

続いては、「データフロー分析」です。まずは、それぞれのデータにおける連携、通信方式のフロー図を作成していきます。大きく分けると3つ、「API」「RDS」「イベントストリーミング」があり、データの特徴や利用状況に合わせて選択していくのです。

木村氏は、それぞれの通信方法における、データフロー図の事例も示しました。以下スライドはイベントストリーミングのケーススタディです。

このように一つひとつのデータの連携方式が整理、フロー化できたら、次のステップは一つにまとめる俯瞰図の作成です。俯瞰図を作成する意図や理由を、木村氏は次のように語りました。

「抽象度を一つ上げて俯瞰することで、全体的な依存関係や連携方式を確認することができ、改善につながります」（木村氏）

4．システムコンテキスト分析

最後のステップでは、ケーススタディ1のデータフロー俯瞰図を元に、ビジネス観点での関心事やチーム体制といった視点を追加し、システムアーキテクチャとの整合性を図っています。こちらでも、木村氏は具体的な事例を元に解説を行いました。

ビジネス観点・技術観点でデータフロー俯瞰図を精査する過程で、顧客エンゲージメントとチャネルコンテキストの定義を行っているのです。

そして、実際にビジネスや業務を進めていくことを想定した上で、現在のデータフローやコンテキストが最適かどうかを精査していきます。ここでは、コンテキスト統合に伴ってコンテキスト内のデータ連携方法を見直す例と、チームの相互運用性を考慮してコンテキスト間のデータ連携を1本化する例を示しました。

精査が済んだデータフロー俯瞰図を踏まえた上で、コンテキストの単位を決定していきます。さらに、コンテキスト間の関係性、ならびに、モデル（アクター）の関係性を明らかにした上記スライドのようなシステムコンテキスト図も作成します。

これにより、アクターとシステム、システムとシステムの関係性を技術に依存しない平易な表現で示していきました。

計画・設計段階から伴奏することで全体の整合性を図る

カケハシはこれまで、基本的にプロダクト中心に向き合っているストリームアラインドチームが軸となり、SDLC（Software Development Life Cycle／ソフトウェア開発ライフサイクル）を回してきました。また、SDLCの過程の中で部分的に、プラットフォームチームがレビューを行う体制でした。

データ連携を始めとしたアーキテクチャ設計において、ストリームアラインドチーム内で設計活動を閉じると、全体最適な設計につながらない場合があり、データ連携件数が右肩上がりする状況の中で、進め方を見直す必要がありました。

そこで、2024年に発足した技術戦略室が、計画・設計段階からストリームアラインドチームと伴走することで、全体の整合性を図り、先の課題解決を目指したのです。さらに木村氏は、今後取り組みたいことを次のように述べ、セッションを締めました。

「ビジネス・技術的観点でのTO BEのシステムコンテキストの方針策定、リアーキテクチャによる品質改善を推進していきます。また、アーキテクチャガイドラインの策定など、実装も手がけていきたいと考えています」（木村氏）

ドメインエキスパートにチーム一丸で取り組むドメインモデリング

株式会社アシュアード
Assured事業部　岩松 竜也氏

続いて登壇したのは、Assuredの岩松竜也氏です。岩松氏はグループ会社であるビズリーチに新卒で入社して以降、主にバックエンドエンジニアとしてキャリアを積んできました。現在はインフラからフロントエンド、さらにはテックブログの運営など、様々な領域で活躍しています。

クラウドサービスのセキュリティチェックを一気通貫で一元管理

アシュアードは、ビズリーチを運営するVisionalグループの100％出資企業として、社内の新規事業が独立するかたちで、2022年に設立されました。セキュリティ評価プラットフォーム「Assured」は、専門知識を有するセキュリティ評価チームがクラウドサービスのセキュリティ対策状況を調査し、その評価結果をデータベース化したプラットフォームサービスを提供しています。

近年、クラウドサービスを利用する企業が増えるにつれ、個人情報の漏洩などのセキュリティインシデントが頻繁に発生するようになりました。そこでクラウドを利用する企業は、利用するクラウドサービスのセキュリティ対策や、情報管理などを確認することが求められるようになってきました。

これを「セキュリティチェック」、具体的な確認項目が記載されたものを「セキュリティチェックシート」と呼びます。

だがクラウドを利用したいと考えている事業者側は、実際、どのような質問をして、評価を行えば正しいセキュリティチェックとなり得るのか、判断が難しい状況にありました。セキュリティの専門人材の不足も含め、セキュリティチェックの対応も難しく、事業を進める上での足かせとなっていたのです。

一方、クラウドサービスを提供する側においても、セキュリティチェックシートはいわゆる共通フォーマットのような画一的なシートが存在していなかったため、各社とはメールやExcel、Wordでやり取りをしていました。それらが双方にとって構造的に非効率的であることは、明白でした。

このような状況を解決しようと立ち上げたのが、Assuredです。クラウドサービスの利用企業と、クラウドサービス事業者の間に入り、セキュリティ評価結果を可視化するためのプラットフォームを作っています。

バラバラであったフォーマットを統一し、セキュリティの専門人材を抱えているため、いわゆるセキュリティチェックの第三者機関としての役割を担っています。

岩松氏は、クラウドを利用する企業数のデータも示しました。大手企業においては、半数以上が100社以上のクラウドサービスを利用しており、1社あたり、平均207社のサービスを利用していることが分かりました。いかにセキュリティチェックスキームが大きな負担となっていたのかが伝わってきます。

また現在、Assuredでは調査・評価サービスに加え、利用開始後の各クラウドサービスの管理状況を一元管理できる「サービス台帳」も提供しています。

Assuredのコアドメインである「評価」が生まれた背景

一方で、Assuredが提供しているサービス、業務フローは、これまで存在していませんでした。どのように生み出していったのか、まさに生み出していく過程がドメインモデリングであり、「コアドメイン（業務領域）を明らかにしてきました」と、岩松氏は述べました。

また、「業務領域」とは強く関連するユースケースの集まりであり、確実に業務知識を習得するただ一つの方法は、「ドメインエキスパートとの会話です」と、説明を続けました。

なお、本セッションで岩松氏が述べた内容は、以下スライドの参考書『ドメイン駆動設計をはじめよう』をベースとしたものです。

「ドメイン駆動設計の全体が分かりやすく解説してあり、おすすめです」（岩松氏）

ドメインエキスパートとの会話においては、画一的なノウハウがないことが、実際に岩松氏がAssuredを立ち上げる際に感じていた課題でもあったといいます。

そこで岩松氏は、再現性がありそうな手法（技術）を考察。そして、「良さそうだと感じていること」を示したのが、以下スライドの2点です。

ネガティブ・ケイパビリティとは、「どうにも答えの出ない、どうにも対処しようのない事態に耐える能力」だと、岩松氏は言います。さらに一段ブレイクダウンし、自分なりの理解に落とし込んでいきました。

その結果、ネガティブ・ケイパビリティとは「不確実、不安定な環境下でストレスを受け入れる」ことであり、ドメインモデリングにおけるネガティブ・ケイパビリティは、「分からない」というストレスを受け入れる能力だとまとめました。

そして逆に、ネガティブ・ケイパビリティが低い状態だと「分からない」ことを安易に解決しがちであると、理解することとしたといいます。

続いて、実際にAssuredのサービスが生まれるまでの過程と、これまで伝えてきたことを重ねていきました。まずはゼロイチ、最初のコアドメインが定まるまでのフェーズです。

そこで岩松氏は、自社の状況だけを見て「同業務ならびに、課題を解決することがコアドメインなのではないか」と考えます。しかし、そこで調査を終えずにセキュリティチェック業務に携わっているメンバーに目を広げてみました。

するとまさに、サービス提供側では法務やセキュリティ担当など、クラウドサービス利用企業側でも、「セキュリティ担当者や同じく法務などが困っている」という構図が見えてきました。

さらにヒアリングを行うと、困りごとはそれぞれ、理由も含めて異なることも分かったのです。その中で、割合としてセキュリティ監査のモチベーションが大きいことも判明してきました。

セキュリティに関するインシデントが発生すると、企業のイメージの毀損につながったり、重大な賠償に発展したりする可能性があるからです。つまり、セキュリティ監査は経営課題になりがちだという、本質的な課題が見えてきたのです。

最初に目に付く課題だけを解決しようとすると「回答効率化ツールを作ればいいのに」と考えがちですが、業務領域の境界を厳密に特定することで、求められる解決方法が異なることがわかりました。

もう一つ、ドメインエキスパートの会話について気付いたことがありました。それぞれのドメインエキスパートと話すと、専門領域の知識や語彙が足りず、びっくりするほど会話に参加できなかったのです。

エンジニアあるあるではありますが、開発エンジニアではなくプロダクトマネージャーが話せばいいのに、と考えがちです。しかしここでも、参考書が手本となりました。

「業務知識は伝言ゲームの途中で誤って伝わります。そういう誤った情報を元にして開発すれば、誤ったソフトウェアが生まれます」（『ドメイン駆動設計をはじめよう』より抜粋）

つまり、みんなが同じ言葉で会話をするように定義すべきだというのです。まさに、ユビキタス言語そのもの。また、同じ言葉については、次のような定義があることも語りました。

つまり課題解決に必要だったことは、エンジニアが業務領域を学ぶこと。その上で、同じ言葉を使ってドメインエキスパートと会話する、ということであると結論付けました。

そして学ぶ、勉強するということは、会話中に必死で言葉を調べたり、質問したり、本を読んだり、アウトプットすることだと、岩松氏は続けました。

そうして勉強を続けていくと、言葉の裏にある背景や使われる文脈などを理解していくとともに、ドメインエキスパートに関心を持つようになっていくのだと、岩松氏は強調します。まさに「他者へのリスペクト」です。

このような過程を経て、Assuredのコアドメインである「評価」は生まれたのです。

機能追加フェーズ──サービス台帳が生まれた背景

続いて語られたのは、プロダクトのグロースフェーズが生まれた背景です。先に開発した評価プロダクトを、いかに成長させていったのか。岩松氏は、「サービス台帳」が開発されるまでの過程を紹介しました。

ゼロイチフェーズと同じくドメインエキスパートとの会話を重ねた結果、グロースフェーズではすでに勉強していたため、以前とは異なり会話がスムーズであったり、ドメインエキスパートのいっていることが理解できたりするような状態にありました。

ただ、このようなフェーズでも「注意が必要だ」と、岩松氏は言います。

「『あ、分かります。〇〇ですよね』といった具合に、自分の中のみで理解し、抽象化してしまうからです」（岩松氏）

ここでも岩松氏は、参考書からの一文を紹介しました。正しく抽象化（モデリング）するためには、知ったかぶりをしないこと。むしろ「どういった意味ですか？」「なぜ、そうなんですか？」というように深堀りすることが大事だと述べ、安易な解に飛びつかないことが大事だと繰り返しました。

台帳を使ってもらうために、「台帳にデータを設定するのが手間」「台帳でサービスを取捨選択できない」という課題を解決する必要性も見えてきました。

このような課題解決の際にも、「インポート機能を作ればいいのに」といった安易な解決策や、「リソースがない」といった言動をしがちだと、岩松氏は指摘しました。そして、ここでも参考書の一文を示しました。

「ドメインモデリングは技術者だけのものではありません」と語り、実際にAssuredのサービスでは、ビジネス、開発、セキュリティなど、様々な部門のメンバーが協力することで、先の課題を解決していることを示しました。その結果として、「チーム力で理想のフローが実現した」と続けます。

岩松氏は、他者（チーム）へのリスペクトがあり、メンバーのことを信頼していたからこそ、同プロジェクトが成功に至った。結局は、「人とどう向き合うかが重要である」と、強調。最後に次のように述べ、セッションを終えました。

「チーム、ドメインエキスパートとの関係が強化されたことで、ドメインモデリングが進んでいきました。しかし、こちらもやることはまだまだたくさんありますし、万物は流転します。今後も取り組みを継続していきます」（岩松氏）

【Q＆A】参加者からの質問に登壇者が回答

セッション後は、イベント参加者からの質問に登壇者が回答しました。抜粋して紹介します。

Q．管理画面側で複数の通数や通数上限を獲得するための、マイクロサービスにおけるベストプラクティスは？

木村：ベストプラクティスはあるかもしれませんが、プロダクトにより異なると考えられるため、その都度分析する必要があるでしょう。カケハシではSMSサービスで通数を記録しており、今後は従量課金業務なども、SMS送信サービスに凝集したいと考えています。

Q．RDS連携はスキーマの変更時の影響が大きいと思いますが、負債にならないためのTipsは？

木村：RDS連携に限ったことではありませんが、データなどの変更が生じた場合でも、波及しない仕組みを作ることが重要です。例えばカケハシでは、Databricksのメダリオンアーキテクチャでデータを管理していますが、アプリケーションから渡ってきた生データは、まずブロンズレイヤーに置いておきます。

その後、クレンジングなどを施し汎用化したものをシルバーレイヤーに移動し、利用者には、このシルバーレイヤーのデータ参照を推奨しています。

Q．データ連携4つの分析は毎回行うべきか？

木村：4つの分析で重要なことは、課題を整理し、解像度を上げ、蓋然性の高いアーキテクチャを設計することです。そのため、あえて“設計”ではなく、“分析”という言葉を使っています。そしてこの4つの分析手法は、私が年間30〜40案件のデータ連携レビューを行った経験から生まれたものでもあります。

イベントをしっかり理解して解像度が高ければ、端折ってもいいでしょう。ただ、影響度が高い機能であったり、チーム、サービスをまたいだりするようなテーマの場合は、石橋を叩いて渡るという観点でも、実行した方が良いと思います。ステークホルダーへのファクトにもなります。

Q．ドメインエキスパートとの会話について、チームで取り組んでいる際の流れは？

岩松：時間の取れる人からヒアリングを行っていき、その割合を徐々に増やしていきます。一方で、情報はメンバー全員に知っておいてほしいので、議事録などを作成し、共有するようにしています。

Q．技術領域の言語はユビキタス言語にしないと、エンジニア側でやりたいことが伝わらないケースもあるのではないのでしょうか？

岩松：原則として、ドメインエキスパートがやりたいことは、技術領域とは関係ありません。一方で、おっしゃるようにエンジニア側が悩ましいときもあるでしょう。木村さんが語っていたように、情報や関係性を整理することで、次第にドメインエキスパートが使う言葉に置き換わっていくと考えています。

Q．学び方について

木村：興味を掘り下げていくことが基本ですが、それだけだと偏ってしまうので、『O'Reilly Online Learning』や、Mediumの有料コンテンツを定期購読として、海外の最新記事をなんとなく眺めたりしています。その他にも、本屋にいって新刊をチェックしています。

岩松：誰かが勧めてくれた書評などを参考に、自分に関係があると思ったテーマが書かれた書籍を読むようにしています。ネガティブ・ケイパビリティもまさにその一冊です。またオーディオブックを利用して、耳で聴くようにもしています。

Assured サービス情報
https://assured.jp/

Assured 採用情報
https://careers.assured.jp/

Assured Tech Blog
https://tech.assured.jp/

アーカイブ動画