今日は少しだけ概念の紹介です。
海外ではメジャーだけど、日本ではまだまだ記事が少なくて、やっとこの頃MFでデータ分析やられている方が少しNoteを書き起こされたSingle Source of Truth（SSoT/SSOT）について。
Reduxをお使いの方はReduxのprincipleの一つにうたわれていて、フロント作るときにreactとのstateの持ち合い。。。
って話は今回のメインではありませんw 興味ある方は以下のReduxのSSoT部分でも読んでみてくださいw
Single Source of Truth（SSoT）って何？
”唯一の信頼できる情報”と日本語では訳されることになるのでしょうか？いまいちわかるような、わからないような。
talendのHPには以下のようにあります。
Single source of truth (SSOT) is a concept used to ensure that everyone in an organization bases business decisions on the same data.
https://www.talend.com/resources/single-source-truth/
mulesoft (API management toolとかやってる会社です, SFに買収されてます）の記事だと以下の感じ。
A single source of truth (SSOT) is the practice of aggregating the data from many systems within an organization to a single location. A SSOT is not a system, tool, or strategy, but rather a state of being for a company’s data in that it can all be found via a single reference point.
https://www.mulesoft.com/resources/esb/what-is-single-source-of-truth-ssot
共通してうたわれている要素やその要約としては以下でしょうか。
Single Source of Truth（SSoT）が実現できると何がいいのか？
シンプルにセクション跨ぎでも、同一のデータに基づいて話ができることが最大のメリットだと思います。
分析をしていると、たいていの場合で各システムごとの結果を確認することが一般的ですが、当然セクションが違えばみているデータが違ったりもします。なぜなら、企業内には複数のシステムが走っているから。。
複数のシステムを跨いだ事象について、１つのデータがあることは、分析を進めるにおいて非常に重要です。
なぜSingle Source of Truthという概念が浸透しないのか？
なぜなんでしょうね？w
正直よくわからないですが、実際に作ってみようと思うと結構大変だってのは容易に想像できます。実際問題各セクションのシステム置き換えやSaaSの活用すら進んでいない企業が多いのであれば、そもそもSSoTという概念の必要性が認識されないのも肯けます。
大変そうだなぁってのは以下のMFさんの記事でもわかるかもです。そもそものデータ設計を見直す（というか統合できるようにラッパー概念を持たせる）必要がありますもんね。
よくありそうな課題
- 設計できる人がいない
- それぞれのシステム間でuniqe idが統一されていない（CRMではA社は1111だったとしても、会計ソフトになると1234になってて、読みかえが必要）
- なんだかんだ完全を目指すと人のデータが辛そう（自社従業員は従業員IDがあるけど、得意先の人とかだとIDないし、hubspotにあるデータだと追えない物多い）
- とりあえず目下やることは目の前の業務！！
２つ目と３つ目以外はなんかどうでもいいこと書いてる気がしますね汗
SSoTが達成できれば全て解決するのか？
いや、全くもってそんなことはないと思ってます。
SSoTは分析などをすることを簡易化・加速させてくれはしますが、実際その後のアクションに移すには20年来問題と言われる意思決定プロセスが待っています。。
ただ、現場が早く発見できるようになれば、その分だけ意思決定が遅くてもカバーできるのでしょうが、グローバルでコンペティターが早期発見・早期意思決定している中だと、発見速度だけ早くしても勝てないっすもんね。。まぁあくまでコンペティターがどこの誰かによりけりな話ではありますが。
まとめ
いろんな情報にアンテナ張って、自社でできるレベルからでも実現していくこと（何より動き出させること）が重要ですよね。
計画に時間をかけすぎず、try-errorを繰り返せる分野では繰り返す速度を高めることが基本的な事業戦略なのかな、と思ってます。
