限られたデータで何とかする

データ分析をするすべての人に共通する悩みが、「信頼できるデータが不足している」ということである。データを集めることは簡単だが、果たして有益なデータを集められているか?と言われるとそれは別問題なのである。具体的には

・データの品質に問題がある：欠損値があったり、値が標準化されていない。例えば、1〜5点評価のはずなのに6や0混ざってるレビュー評価。業種の項目に「金融」と「銀行」という重複しつつ、粒度の異なるデータ値が混在する。

・データの網羅度が不十分：上記の品質面は問題ないが、一部の地域に対してしかデータがない。例えばヨーロッパ全体の分析をしたいが、オランダとドイツのデータしかない。

この状況はしょっちゅうあり、データ分析者は、データがないから分析ができない、まずはデータ収集プロジェクトが必要だからです、ビジネスのオペレーションを変えて、プロセスを全社統一して、かち標準化して、かつデータエンジニアを5人採用して、DatawarehouseとSchrduling toolに投資してもらわないといけないから、計1 millionくれと経営陣に頼むことが多々ある。

しかしながら、見返りが不明確なこの投資案件に容易に1 million投資する経営陣はそうそういないし、安易にいいよ!というようであれば経営者とし問題があると言わざるを得ない。

さてでは他に策はないのかというとあるのである。仮にデータ分析プロジェクトの目的外「携帯電話の顧客離反を減らす」であるとして、上記の問題を抱えているのが、「離反理由データ」であるとする。この企業では、顧客が携帯電話の解約を申し込むごとに、解約理由を選択させる。さしずめこんな感じ：

解約理由を以下から選んでください

1.料金が高い

2.サービスに不満がある

3.使用頻度が減った

4.通信状況がよくなう

5.その他（詳細をご記入ください）

よく見るやつである。そしてこれは架空の設定であるし、私は携帯電話会社に務めたことはないが、どの答えが一番回答が多いか当てることができる。答えは1である。それはなぜか。回答者は真面目に答えるために問題と回答項目の中身を読むのに時間を使いたくないから一番上の選択肢を選ぶからである。

さて、このアンケートで集計したデータを分析して、「料金が高いというのが問題だから価格設定を見直しましょう!」とぶち上げるとどうなるか。会社全体が戦略レベルで大いなる間違いをおかし、愚策を連発するのは目に見えている。かつもしも3つある展開地域のそれぞれが異なるアンケート項目を持っていたらどうなるだろう。3社が合併してできた携帯電話会社であったなら容易にありえるシチュエーションである。そうするとその3つの異なるアンケートで集計されたデータのマッピングをしてなんとか3域を網羅するデータを作り上げることになりが、信頼度はさらに落ちるのは目に見えている。

前置きが長くなったが、ソリューションとしては、このアンケート結果データは使わずに、トランザクションデータからカテゴリ値を作り出すのが良い。トランザクションデータは絶対に嘘をつかない。常に正しいのである。それはなぜか。トランザクションデータが間違っていたら、もっと前にもっと大きな問題が起きているはずである。そもそもビジネスが回らないとか、会計監査で指摘されるとか。なのでよっぽどデータ準備の段階でヘマをしていない限りトランザクションデータは絶対に大丈夫なのである。かつKPIに使われる超主要なトランザクションデータ、売上金額や顧客数、注文数というのはデータ分析組織がまず最初に着手するデータだし、それだけ色々な人の目で監視されてるので、どうやっても品質は高いのである。

さてトランザクションデータを使ってカテゴリ値を作るというのはRFM分析と同じ要領である。

https://www.albert2005.co.jp/knowledge/marketing/customer_product_analysis/decyl_rfm

携帯電話の解約日時を起点として、それ以前一年間の通話回数、使用金額などのトランザクションデータを顧客ごとに集計する。使用金額が重要な指標なので、以下のような5ランクのカテゴリを作る

・0〜1000

・1001〜 5000

・5001〜10000

・10001〜50000

・>50001

金額は日本円のイメージです。そうすると、あま売上に貢献しないさいしょの2カテゴリーは捨てて、残りの3つにフォーカスしようね、という取捨選択ができる。さてでは残りの3つのカテゴリーに見られる行動パターンはないか、解約を予兆するシグナルはないか。。

探すのである。実際にパターンやシグナルが見つかるかは保証できないが、上述した1 millionの投資を求めて騒ぎ立てるよりはるかにスマートなアプローチである。

ヨーロッパで生き残るすべ

あんまりデータ分析に関係ない投稿が続くが、これはこれでInsightfulなので書いておく。

過去を鑑みての反省点は、急激な組織の変化に伴い、職位が上がり、約20名のメンバーを監督する立場になったことにより、チームマネジメントとステークホルダーマネジメントを以前より、より一層求められることになり、さらに高い水準でそれら2つの点をこなさなくてはならず、未熟な部分が多々あり、失策が重なったということである。順に見ていこう。

チームマネジメントについては、ハイレベルのビジョンの設定に不透明な部分があった。ハイレベルとはレベルが高いという意味ではなく、抽象度が高いという意味である。チームのビジョンが不明確であり、あるいはビジョンと日々のタスクレベルの不整合があったため、結果としてチームの照準が狙った領域に効果的に注がれず、アウトプットの量と質が狙った領域に注ぎきれなかった。

具体的には、ステークホルダーに言われた要件に従って、忠実にデータの加工・抽出・提供する、あるいはビジュアライゼーションツールを使ってレポートを作成する、受け身のデータプロバイダーのメンタリティーを持った技術偏重型の分析者達を、ビジネス課題を理解し、先回りして積極的に分析結果から提案を行う、コンサルティング型の人材・チームへの転換を試みたがうまく行かなかった。

理由としては、リーダーの私が「どうやって提案型・コンサルティング型の仕事の仕方をすべきか」を具体的かつ事例を持って明確に体現できなかったことに尽きる。メンタリティーを変えるには身を持って示さないといけないのだ。例えれば餌の取り方をやって見せて教える親鳥のようなものなのだ。どうやってステークホルダーと会話し、明確な要件になってない潜在的なビジネス課題を見つけ、データ分析からアクション可能なInsightを提案して信頼を得ていくポジティブなサイクルを作れるか。これが私が体現して見せきれなかった部分である。

さてステークホルダーマネジメントについては、これが本投稿の意図になるが、アプローチが慎重すぎた。日本でのコンサルティング業務での経験を元に、ある程度話題・仮説をスライドで作り込んでからステークホルダーとの対話を持とうとしたが、結果としてステークホルダーとの対話の機会が減少・遅延し、機会損失に繋がり、チームの分析者にとっては無駄なスライド作成作業と認識され、反発も招いた。

欧州サッカークラブに移籍した選手がパス偏重のプレースタイルでは評価されないと言うことで、ゴールをなるべく決めてマーケットの評価を得て、ビッグクラブへの移籍を目指すのと非常に似ている。私のアプローチは、ステークホルダーに非礼にならないように極力準備してから話をすべし、あるいは話す時間もなるべく短くするのが忙しいエグゼクティブの立場のステークホルダーに対しては適切な態度であるという認識で臨んでいたが、それは欧州では全く真逆で逆効果であるということがわかったのである。言うは易く行うは難しで、長年日本で染み付いたこの考え方を変えるのは簡単ではないが、いかんせん変えなきゃ生き残れないから変えないかんのである。それゆえ本稿のタイトルとした。

極論、「自分勝手」になるのが私のような気使いで周りの顔色をうかがうような人間には必要である。例えば大人数が招集される会議に、私も出てますよ、と集団の一部に属していることをアピールするためだけに参加してはいけない。時間の無駄なばかりか、それで発言しないようであれば意見のないやつとしてマイナス評価になりうる。正しい態度は、自分にメリットになるような効果的な発言をしてその場を有効活用するか、そもそも会議に出ないでもっと自分のやるべきことに時間を使うか、あるいはその会議を主催する側になるのは最もいい。主催する側になるというのはもっとも評価が高い。なぜなら参加者側の人数分だけテコの原理で物事をレバレッジを効かせて効率よく進められるメリットがあるからである。コンサルティングの世界でいうと、コンサルティングサービスを売るために、ポリシーメイキングの段階からコンサルティングファームがロビーイング活動をして、自分に有利なルールをうまく政治家に根回しして作り上げ、「ほら新しいルールができたから業務改善が必要だよ。やり方わからないだろうから教えるよ。」とコンサルティングサービスを顧客企業に売るのと似ている。ルールを作る側に回るのは簡単ではないが、非常に効果的なのだ。一方でルールやスキームに従事する側になってしまっては他人の懐を肥やす使用人になってしまうのでなるべく避けるべきである。もっとも他者への礼節という概念はこれとは別なので、日本ほど極度に礼節をわきまえてはいけないが、ちょっと日本でいうと我儘じゃない?というレベルの強引さでアジェンダをふっかけて、私がリードしますと大々的に宣言するタマが必要なのである。欧州の人はそういった態度を素直に歓迎してくれる。

スタートアップが成熟した組織に移行するときに起きること

スタートアップ企業は華々しくその成長期を謳歌する。右肩上がりの売上、ほぼ無制限の投資、新しいオフィス、毎月大量に入社してくる新しい仲間たち、きらびやかなパーティー。

しかしどれも永久には続かない。パーティーには終わりがあるのだ。否、パーティーは続くかもしれないが続編のパーティーに呼ばれるには異なる資格が求められる。成熟期の組織には、異なる種類の人間が求められるのだ。

それは２部から1部に上がったサッカーのクラブチームに似ている。２部で通用した肉弾戦が1部では通用しなくなる。従って1部に上がると1部の戦い方を知ったプレーヤーは補強されるのはよく聞く話だ。

スタートアップ企業にもそれが起きる。大きくなった組織には、大きな組織の運営を知っている人材が必要となるのだ。もちろん創業以来の中核メンバーの中にはその変革をわたりきれるメンバーもいるが全員ではない。変化についていけず、大きくなった組織では結果が出せず、肩書だけは立派になったもののパフォーマンスが伸び悩むもの。あるいは外部から参画した大組織運営のプロが突然上司になって、いままでのやり方が否定されたように感じ、モチベーションが下がるもの。

外部的には同じ組織でありながら、内部ではなかなか壮大な血の入れ替えが起き、それは一筋縄で行くものではない。創業以来のメンバーが中核から外れる、あるいは組織からいなくなるということは、組織のカルチャー自体の変化を意味する。組織のカルチャーが変わったらもはやその組織は別の組織である。以前のような革新的な組織ではないかもしれない。

一方で経営陣にしてみれば、大きくなった組織を安定化するためには血の入れ替えはやむを得ない。苦渋の決断である。彼らとて昔からの旧知のメンバーは中核に残したいが、そうなると組織は安定しない。

そに企業が株式公開しているのであれば、選択肢はより限られる。株主利益の最大化が第一目標となるため、組織安定化を目指すしかなく、ゆえに大規模な組織の運営に長けた人材を外部から登用し、多少創業以来のメンバーが抜けるとしても大規模化を推し進める。またその変化をなるべく早く実現するためにビジネスコンサルタントを雇い、Business Transformationプロジェクトを大々的にはじめる。なおビジネスコンサルティング会社はそのような変革に豊富な経験があると風聴しながら、本当はほとんど経験がなく、冷や汗物で乗り切って、その経験を元に次のクライアンントに売る機会を狙っている。

兎にも角にも、組織は成熟したときに大組織に移行する。カルチャーはスタートアップの時から変化するかもしれないが、それは必要な変化である。スタートアップのときの自由で楽しい雰囲気が多少失われ、淡白な秩序だった組織に変わるかもしれないが、そういうものなのである。世の中には秩序の少ない、自由な環境が人間もいれば、逆にそれを無秩序で統制が取れていない環境とみなし毛嫌う人間もいる。組織の成熟とともに、そこに属する人々が入れ替わるのは必然なのである。

ツー・イン・ザ・ボックス

Think Hardという本を読んでいる。

https://www.amazon.co.jp/HARD-THINGS-%E3%83%99%E3%83%B3%E3%83%BB%E3%83%9B%E3%83%AD%E3%82%A6%E3%82%A3%E3%83%83%E3%83%84/dp/4822250857

シリコンバレーで最も注目されるベンチャーキャピタル(VC)、アンドリーセン・ホロウィッツが、自身の体験を元に、ベンチャー企業経営におけるHard Thing(しんどい体験)を赤裸々に綴った本である。自分で嫌というほどベンチャー企業の経営に伴う痛みを経験した上でベンチャーキャピタルをやっているのだから、それはVCの成功率も上がるものだろう。

この本に描かれていることは、私が経験したことと非常に類似した現象が多く、感動すら覚える。一方で、私が経験したことは、唯一無二の事象ではなく、企業がスタートアップ状態から発展・成熟する上で、ほぼ必ず経験する過程であるようなので、その過程の一つ一つの痛みを経験しておくというのは、好ましくはないが、貴重な経験ということになる。願わくばその課題一つ一つのソリューションでも引っ提げられれば引く手あまたのコンサルタントになれるのだが現実にはそんな簡単なものではない。一個人で解決できるような生易しい課題ではないのだ。

興味深かった記述がひとつの役職にふたりを据える（ツー・イン・ザ・ボックス）である。以下抜粋:

傑出したふたりの社員がいて、論理的にはどちらも組織図の同じ役職に適合しているようなとき、あなたはどうするだろうか。たとえば、エンジニアリングを率いる世界レベルのアーキテクトがいるが、組織規模を次のレベルへ引き上げるための経験はない。もうひとりは傑出した戦略的な人物だが、技術にはあまり長けていない。あなたはふたりとも会社に置いておきたいが、ポジションはひとつしかない。 そこであなたは、「ツー・イン・ザ・ボックス」という名案を思いつき、わずかな経営的負債を抱える。短期的な利益は明らかだ。両方の社員を引きとめておける。どちらも育成する必要がない。なぜなら理論的にふたりは互いの成長を助け合うので、スキルの相違はただちに埋められる。しかし残念ながら、あなたは非常に高い利子を払うことになる。

第一に、あなたがツー・イン・ザ・ボックスを採用することによって、エンジニア一人ひとりの仕事はより難しくなる。あるエンジニアが判断を仰ぐとき、どちらのボスのところへ行けばよいだろうか。ひとりのボスが何かを決めた場合、もうひとりのボスはその決定を覆せるか。ミーティングが必要になる複雑な問題が生じたときは、両方のエンジニアリング部長のスケジュールを調整するのか。組織の目標は誰が決めるのか。実際、何度もミーティングを開く必要があるような目標を決められるのだろうか。 しかも、あなたは誰が最終責任を持つのかをあいまいにしてしまった。スケジュールに遅れが出たら、誰が責任を持つのか。エンジニアリング部門のパフォーマンスに競争力がなくなったら、誰が責任を取るのか。運用部長がスケジュール管理の責任を持ち、技術部長がパフォーマンスの責任を持っているなら、運用部長がエンジニアたちの尻を叩いてスケジュールを守り、その代わりにパフォーマンスを落としたら何が起きるのか。社員のパフォーマンスが落ちたときには、あなたはどうそのことを知るのか。 いずれの場合にも本当に大きい代償は、時間とともに、事態は悪化していく傾向にあることだ。ごく短期的には、ミーティングを増やす、あるいは仕事を明確に切り分けることで、影響を減らせるかもしれない。しかし、忙しくなるにつれ、かつては明確だった境界線がぼやけ始め、組織は退化していく。ついには、あなたが苦しい決断を下し、リーダーをひとりにして負債を一括返済しない限り、エンジニアリング部門は永久に腐ったままになる。

長々掲載したが、非常に散見される例なのである。成熟しきった組織だけに身を置いていると信じがたい現象かもしれないが、スタートアップというのは「全員野球」状態で、みんなが全部の仕事をやる。そのためみんながみんなの仕事を知っている。同列の同僚も少ないので、人事の施策は個人別にカスタマイズすれば良い。

問題はスタートアップが大きくなって来たとき。急激な成長により従業員数は１００倍増、通常業務に忙しくてプロセス・ルールの整備は追いつかない。同列に複数の同じ能力を持った人が出てきて、どちらも失いたくない。かと言ってどちらかを上か下にすると不満を持って辞めるだろう。なので同列のちょっと違うタイトルで、同じ報酬と権限を与える。その二人は満足かもしれないが、部下のメンバーたちは両者の合意を取らないといけないので、意思決定の遅れ、クオリティーの低下、それに伴うメンバーの士気低下、結果的に二人のdirector/managerの対立を引き起こし、最終的社内に混乱を残したままにどちらかが会社を去るという結果を招く。
ソリューションとしては、組織が巨大化する前に人事ルールをちゃんと整備して、フェアで透明性の高い人事評価が可能な環境を整えておくこと、という至極全うで普通のことなんだけど、それができないんだよね。

組織文化の構築

組織文化の構築はすごく難しい。私も小規模ながらチームを司るマネジャーの身。そして急激な環境の変化から、恥ずかしながら少なくない退職者を出してしまったことがある。

中でも最も痛かったのは、マネジャーの喪失。４人いたマネジャーが全員退職あるいは社内移籍。

さらにはプランBとして期待していた若手のリーダー候補が転職。つまり幹部候補が全員いなくなってしまった。

残るはマネジメント志望のないエンジニア勢ばかり。さてこの劣勢からどうやって状況を改善していくか。

参考になりそうなのがGoodpatch（グッドパッチ） 成長の壁の乗り越え方の事例である。

https://business.nikkei.com/atcl/seminar/19nv/120500136/062800788/

以下抜粋:

いきなり全社の組織風土を変えるのは難しいと考え、マネジャーに「小さなチームの中だけでも何でも言える環境にしてほしい」と伝えた。

　マネジャーは「こんなチームにしていきたい」と目指す方向を示しつつ、メンバーと積極的にコミュニケーションを図った。相変わらず離職者は多かったものの、社内の空気は少しずつ良くなっていった。

人事を任された柳沢和徹（かずゆき）経営企画室長が真っ先に取り組んだのは、退職が決まっている社員へのインタビューだった。「退職理由や会社の駄目なところを聞いた。本音かは分からないが、組織崩壊の原因らしき片鱗は見えた」。圧倒的なコミュニケーション不足だ。

そこで18年からさまざまな仕組みを導入した。まず1つ目が全社総会のリニューアルだ。従来はオフィス内で実施していたが、しゃれた雰囲気の会場でセレモニー感を打ち出したイベントに変更。社員のモチベーションを高めるため、MVPを大々的に表彰した。

　2つ目に、従業員同士の交流を目的とした、毎月の社内イベント「ピザパッチ」の内容を刷新した。参加者が減り、盛り上がりに欠けていたからだ。

　単にピザと飲み物を並べて、「よかったら来て」では集まらない。そこで参加したくなる仕掛けを用意した。たこ焼き大会や豪華ゲストと土屋社長のトークセッション、「株主に聞く、グッドパッチに出資した理由」、流しそうめん大会など、趣向を凝らした。さらに毎回、参加率と満足度を測定し、参加者からのフィードバックを受けて内容の改善につなげた。

組織崩壊状態から脱するのに最大の鍵となったのは、バリューの再構築だ。機が熟したと考えた土屋社長は、社員に再構築を提案。有志メンバーを募り、プロジェクトを始動した。全社ワークショップも開始し、議論と検討を重ね、5つのバリューをつくり上げた。

　これを絵に描いた餅にしてはいけないと浸透にも力を注いだ。マネジャー向け研修などを実施したほか、毎月全社員が集まる機会に浸透度合いを必ずチェックした。

「バリューは抽象的な概念なので、可視化することが大事だと考えた」（経営企画室PR／PXグループの高野葉子氏）からだ。努力の結果、浸透度は半年ほどで目標の80％に到達した。

つまりは

①組織内のコミュニケーションを改善し、問題点がトップに滞りなくフィードバックされる場・プロセスを設ける

②メンバーが評価されていることを感じられる月次の表彰の場や、Teamsの一体感を高めるイベントを設ける

③バリュー・ビジョンをチーム一体となって作り上げ、その過程にメンバーを巻き込むことで、ビジョンを共有する。決してトップだけで決めたトップダウンのビジョンであってはならない。

③はリーダーシップ研修でも触れられることが多いこと。しかし抽象的な概念なので、いまいち自分自身が理解できないでいた。うちでいうなら

「Get Our Foundation Strong」というGoalに対し、「じゃあそれが実現できたのはどういう状態?」というのを箇条書きで書き出していくべきである。その過程にメンバーが携わることで、ビジョンが共有され、中長期的に何をすればいいか皆がわかっていくはずである。

キーポイントは具体的かつ簡潔なビジョンであること。例えば「KPIが定義され、全ての社内のレポーティングがそれ従っている」　

悪い例は「Profitabilityの改善にデータで貢献する」これだと何を実現したら成功なのかわからない。Success Criteriaが設定できない。

OKRによるゴール設定

データ分析に関わらず、プロジェクト・タスクの優先順位付けは非常に大事であるとともに、大変難しい。とくにCentralized型のデータ分析チームが、複数のステークホルダー、業務部門からタスクの依頼を受ける形式だと難易度が高まる。

理由としては、単一部門からの依頼のみであれば、その部門長と優先順位付けの会話を持って、ビジネスの優先順位に従ってデータ分析プロジェクトの優先順位付けをすれば良いからである。

しかしながら、複数の業務部門から依頼を受け付ける場合はそうはいかない。その場合のソリューションとしては、プロジェクト毎に期待されるReveue、Costの額を算出し、何とか部門AとBから来る異なる性質の複数プロジェクトを金額ベースで比較する、あるいは全社戦略とその優先順位を鑑みて、トップダウン形式で優先順位を付ける方法がある。私の経験上は後者の全社戦略からの優先順位付け作戦がシンプルかつ説明容易性にすぐれているのでオススメである。もっとも全社戦略がないからこのやり方が出来ないという場面も多々あったりする。

さて、優先順位付けのやり方を決めたら、次は（順番は逆でも良い）プロジェクトそのもののリストアップだ。但し、プロジェクトリストは確実に膨大、30-50になってしまうので、カテゴリ分けが必要になる。OKRがソリューションになる。

OKRは、マーケティングの祖であるPeter Druckerが1954年に開発し、John DoerrがIntelにて学び、かつその後Googleの最初の大きな投資会社として目標設定の指導に携わった結果、

「Googleの目標設定手法」として有名になった。やり方としては

• O=Objective、目標
• KR=Key Result、Oを実現するために必要な手段、指標

を設定する。OとKRは1:Nの関係になる。例えば

• O:データ分析チームを、単純なデータ抽出チームからもっとビジネスバリューの高いアドバイザー業務が可能なチームに変革する
• KR1:アドバイザー業務に必要なプレゼン能力を高めるための研修をアナリストに実施
• KR2:プレゼンテーションのテンプレートを刷新
• KR3:当四半期中に3回以上、ディレクター以上の役職のステークホルダーにプレゼンを実施する

という形である。

しかしながら、OKRを設定するだけでは確実に絵に描いた餅である。データ分析チームの時間と労力が確実にOKRが設定されたプロジェクトに費やされるためには、定期的なOKRの進捗度の確認と、作業レベルへのOKRの紐づけが必要である。

進捗度の確認に関しては、週次ないし二週次のチーム会議でチームメンバーが確実に優先順位付けされたプロジェクトに時間と労力を費やしていることを確認する。

また「作業レベルへのOKRの紐づけ」のついては、JiraのEpicにKRを紐づけが、TaskないしStoryをEpicにぶら下げる。そうするとO→KR→Epic→Taskで1:N、1:1、1:Nの関係が出来上がる。これによりOKRで設定した目標に従ってメンバー全員が作業をしているか確認可能になる。ちなみにJiraの標準機能にOKRの設定は存在しないので、カスタムフィールドを作る必要がある。

データ分析チームの組織論

企業の規模が大きくなるにつれ、データ分析チームの規模も大きくなるのが世の常である。データがシステムから来て、自動化されたETLプロセスとレポーティングツールによって、自動的に処理が進むからと言って、データ分析者の頭数を増やさないでいいということではないのである。それらのツールを維持することすら結構な頭数がいるものであり、ましてや日々増大するステークホルダーという名の社内顧客の増大し続ける要件を捌きつつ、かちよりビジネスバリューの高い提案を増やし続けようとすると、データ分析者の質量ともに改善し続けることが必要である。これがなかなかデータの世界以外の人には理解されないので頭がいたいところではある。

さて、当初はわずか5人程度のデータ分析チームがあれよあれよ 100人規模になるとどうなるか。適切な役割分担を決めないと、社内政治が勃発し、顧客の奪い合いや、データやレポートという名の島の縄張り争いが発生する。デロイト時代に日本の大企業の業務改善、組織変革というのをよくやったが、今思うとああ日本の大企業も色々歴史を経てあのような社内政治が頻発する状態に陥ったのねと、スター・ウォーズ4を見たあとにスター・ウォーズ1.2.3を見たのと同じような読後感を覚えるのである。

ではそのような望まないカオスを避けるべき処方箋はないものか。そこでデータ分析チーム組織論の登場である。マッキンゼーなどのコンサルテョング会社が、新しい商機とみていろいろ記事を出していることからも、非常に世の中のニーズが高い分野であることは間違いない。

https://www.mckinsey.com/industries/financial-services/our-insights/building-an-effective-analytics-organization

この記事に書いていることは概ね正しい。まず、Centralized /Decentralizedの度合いは企業の成長のフェーズ毎に変わるものであり、普遍的に通用するベストなフォーメーションはないのである。

また、データガバナンスを中央集権化すべきというのも正しい。各部門にfedrratedにデータガバナンスをおいてしまっては、各都道府県ごとに異なる交通ルールを設定してもいいよ、

と言っているようなものである。各都道府県ごとに信号の赤青黄色の意味や色すら異なったら、とんでもないことになる。

しかし、データアーキテクチャを各部門ごとに設定するというのは間違いである。恐らくこの調査が成熟した大企業のデータにまつわる現状を調べたためにこういう結果になったと思われるが、それらの企業は数年あるいは数十年来の歴史の中で、Advanced Analyticsがない時代からエクセルベースのレポーティング部隊が細々と各部門に存在し、今名称を変えてデータ分析チームとして、エクセルの成れの果てのデータベースを部門ごとに持っているからであろう。だからといってこれをベストプラクティスとするのは間違いである。データアーキテクチャも中央集権化すべきである。日本の都道府県毎に異なる住民票データベースとそれに伴う県をまたぐ引っ越しの際の申請作業の煩雑さを鑑みれば中央集権化したデータベースが正しいのが明白である。

そうなるとデータアーキテクチャのおもりをするData Engineerが中央集権化すべきこともおのずと自然に決まってくる。ちなみにちょっとつっこむと、Data Meshの考えに則り、中央組織の中で、Salesなどのドメイン毎に担当する別のチームを設け、Sales担当のData Engineer達が中央でSalesのデータをおもりするのが正解である。

さて一番難しいのがData AnalystsあるいはDataScientistsである。結論は、データの意味定義やオペレーションを調査し、データウェアハウス内の名寄せやビジネスロジックの統一化を担当するData Analystは中央において、そのデータ処理の結果出てきたきれいに統一化されたデータを「消費」してデータ分析を行うBusiness Analystが部門側に配置されるのが正解である。もっとも現実問題、キャリアの志向などを考慮すると、こぼ形をそっくりそのまま当てはめるのはなかなか困難である。なぜならデータ分析者はみんなビジネスにインパクトを与えられる仕事をしたいのであり、従って上述のData Analyatの役割を進んで担ってくれる人はあんまりいないのである。