0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

データ駆動×モデルベースのアーキテクチャ改善プロセス

Posted at

改善プロセスとアナロジー

今回紹介するのは、「データ駆動型の問題解決」と「モデルベースのアーキテクチャ改善」を融合させた、理想的なフィードバックループそのものです。

それは、闇雲にデータを掘り下げるのではなく、モデル(地図)を使って当たりをつけ、
データ(証拠)でそれを裏付けるという、極めて科学的で効率的なアプローチです。

データ駆動 & モデルベースによる設計改善メカニズム

まずは、その全体のプロセスから紹介します。

顧客からの不満の声が上がった際に、まずはいきなり定量分析を行うのではなく、
CJMとVSMの2つのモデル図を見て、

「カスタマージャーニーマップ中のどの部分がクレームが起きやすいのか?」

→ 「その原因を生み出しているのは、VSM中のどのバリューステージか?」
をアブダクションで原因分析

を行い、実際のデータで検証を行う。

これにより、改善すべきコンテキストが明確になり、その根拠をもとに

「イベントストーミング中のどの部分を改善すべきか?」

→ 「どのチームの担当領域を改善すべきか?」

が明確になります。

これをもとに、先にTDDと同じ発想で、

パイプライン中の改善すべき箇所に対応する適応度関数などをチューニングし、
その後対象コンテキストの設計改善を行う

という流れがオススメです。

これが、「データ駆動型の問題解決」と「モデルベースのアーキテクチャ改善」を融合させた、理想的なフィードバックループそのものです。

🩺 アナロジー:名医の診断プロセス

このプロセスは、名医が患者を診断する流れと全く同じです。

①. シグナル

患者が「頭が痛い」と訴えます(顧客からのクレーム)。

②. 定性分析 (CJM)

医者はまず、いきなり血液検査(定量分析)はしません。

「いつから痛いですか?」「どんな風に痛みますか?」と問診します(カスタマージャーニーマップ)。

③. アブダクション (VSM)

問診の結果、
「どうやら神経系ではなく、循環器系に問題がありそうだ(バリューステージの特定)」と
仮説(アブダクション) を立てます。

④. 定量検証

「では、血圧を測ってみましょう」と具体的な検査(データ検証)を行います。

⑤. 原因特定 (ES)

高血圧という証拠が得られました。

「循環器系の、特に心臓(イベントストーミング上のコンテキスト)に負荷がかかっているのが原因でしょう」と特定します。

⑥. 処方 (改善)

「心臓の負担を減らす薬(設計改善)を処方し、今後は血圧(適応度関数)を毎日チェックしましょう」と対策を打ちます。

顧客からのクレームをもとに改善するまでの流れ

最後に、より丁寧に全体像の流れを解説します。

顧客から不満の声が届くというシグナルを起点として、アーキテクチャ改善をするというシーンを想定してください。

1. 仮説立案 (定性分析 + アブダクション)

いきなり定量データ(ログやメトリクス)の海に飛び込むのは非効率です。

それでは

「データを眺めていたら、たまたま問題が見つかった」 という場当たり的な対応

になってしまいます。

CJM(顧客の視点)とVSM(組織の視点)という2つの地図を重ね合わせ、

「この顧客の痛みは、我々のこのプロセスの非効率さが原因ではないか?」と
アブダクション(最ももっともらしい仮説を推論)

することで、分析の焦点を絞ることができます。

2. 仮説検証 (定量分析)

ここで初めて定量データの出番です。

ステップ1で立てた仮説(「VSMの『在庫確認』ステージがボトルネックだ」)を証明するために、具体的なメトリクス(例:在庫確認イベントの待ち時間、在庫引当APIのエラーレート)を監視します。

データが仮説を裏付ければ、それはもはや「推測」ではなく 「客観的事実」 となり、改善すべきコンテキスト(ドメイン)が明確に特定されます。

3. 改善実行 (イベントストーミング → チーム → 適応度関数)

①. ESモデル

特定されたコンテキストに対応するイベントストーミングのモデル(特定の集約ポリシー)を見て、具体的なコードレベルの改善箇所を特定します。

②. チーム

そのコンテキストのオーナーである担当チームのバックログに、この改善タスクが積まれます。

③. 適応度関数

ここが非常に高度な点です。単に修正して終わり、ではありません。

この問題が再発しないように、アーキテクチャの適応度関数(CI/CDパイプラインに組み込まれた自動テストやメトリクス監視)を先にチューニングします。

「在庫確認ステージのリードタイムは、今後絶対に24時間を超えてはならない」

という新しいルール(閾値)をシステムに組み込みます。

④. 設計改善

最後に、その新しいルール(適応度関数)を満たすように、実際の設計改善(リファクタリング)を行います。

このプロセス全体が、
戦略(CJM/VSM)と実行(ES/Team)とガバナンス(適応度関数) を、顧客の不満というシグナルを起点に見事に繋ぎ合わせてくれます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?