企業の規模が大きくなるにつれ、データ分析チームの規模も大きくなるのが世の常である。データがシステムから来て、自動化されたETLプロセスとレポーティングツールによって、自動的に処理が進むからと言って、データ分析者の頭数を増やさないでいいということではないのである。それらのツールを維持することすら結構な頭数がいるものであり、ましてや日々増大するステークホルダーという名の社内顧客の増大し続ける要件を捌きつつ、かちよりビジネスバリューの高い提案を増やし続けようとすると、データ分析者の質量ともに改善し続けることが必要である。これがなかなかデータの世界以外の人には理解されないので頭がいたいところではある。
さて、当初はわずか5人程度のデータ分析チームがあれよあれよ 100人規模になるとどうなるか。適切な役割分担を決めないと、社内政治が勃発し、顧客の奪い合いや、データやレポートという名の島の縄張り争いが発生する。デロイト時代に日本の大企業の業務改善、組織変革というのをよくやったが、今思うとああ日本の大企業も色々歴史を経てあのような社内政治が頻発する状態に陥ったのねと、スター・ウォーズ4を見たあとにスター・ウォーズ1.2.3を見たのと同じような読後感を覚えるのである。
ではそのような望まないカオスを避けるべき処方箋はないものか。そこでデータ分析チーム組織論の登場である。マッキンゼーなどのコンサルテョング会社が、新しい商機とみていろいろ記事を出していることからも、非常に世の中のニーズが高い分野であることは間違いない。
この記事に書いていることは概ね正しい。まず、Centralized /Decentralizedの度合いは企業の成長のフェーズ毎に変わるものであり、普遍的に通用するベストなフォーメーションはないのである。
また、データガバナンスを中央集権化すべきというのも正しい。各部門にfedrratedにデータガバナンスをおいてしまっては、各都道府県ごとに異なる交通ルールを設定してもいいよ、
と言っているようなものである。各都道府県ごとに信号の赤青黄色の意味や色すら異なったら、とんでもないことになる。
しかし、データアーキテクチャを各部門ごとに設定するというのは間違いである。恐らくこの調査が成熟した大企業のデータにまつわる現状を調べたためにこういう結果になったと思われるが、それらの企業は数年あるいは数十年来の歴史の中で、Advanced Analyticsがない時代からエクセルベースのレポーティング部隊が細々と各部門に存在し、今名称を変えてデータ分析チームとして、エクセルの成れの果てのデータベースを部門ごとに持っているからであろう。だからといってこれをベストプラクティスとするのは間違いである。データアーキテクチャも中央集権化すべきである。日本の都道府県毎に異なる住民票データベースとそれに伴う県をまたぐ引っ越しの際の申請作業の煩雑さを鑑みれば中央集権化したデータベースが正しいのが明白である。
そうなるとデータアーキテクチャのおもりをするData Engineerが中央集権化すべきこともおのずと自然に決まってくる。ちなみにちょっとつっこむと、Data Meshの考えに則り、中央組織の中で、Salesなどのドメイン毎に担当する別のチームを設け、Sales担当のData Engineer達が中央でSalesのデータをおもりするのが正解である。
さて一番難しいのがData AnalystsあるいはDataScientistsである。結論は、データの意味定義やオペレーションを調査し、データウェアハウス内の名寄せやビジネスロジックの統一化を担当するData Analystは中央において、そのデータ処理の結果出てきたきれいに統一化されたデータを「消費」してデータ分析を行うBusiness Analystが部門側に配置されるのが正解である。もっとも現実問題、キャリアの志向などを考慮すると、こぼ形をそっくりそのまま当てはめるのはなかなか困難である。なぜならデータ分析者はみんなビジネスにインパクトを与えられる仕事をしたいのであり、従って上述のData Analyatの役割を進んで担ってくれる人はあんまりいないのである。
