今更解説する動き出すデータドリブン組織のつくりかた 章別攻略編。今回は1章 戦略とチームを解説していきます。それではいきましょう！

歴代ソウルシリーズは一貫して純魔(魔術師ビルド)で攻略しています。作品によっては序盤が辛いのでオススメしません。ダクソ2がクソと呼ばれる由縁

Lesson 1: 戦略に定石はないが正解は必ずある

本文中には表現されていないのですが、データ分析という抽象度の高い大きな括りで何かを行う場合、まずは最初に戦略の策定を行うことを推奨しています。

ただ「データ戦略」と一言で言ってもその内容は千差万別です。特に影響が大きい会社規模や予算、組織のレベルなど様々な要因が複雑に絡むため、戦略策定時にはこうしたリスクへの調整も必要になってきます。

例えば、キーマンとなるデータ人材が存在する企業やCoE(後述)を抱えている企業では、自ら環境構築から運用までゴリゴリ推進する力があるので、要員調達は社内メンバーで賄ってプロジェクト推進が可能となります。

ただ、日本企業の多くはこうしたITに強い企業あるいはITに強い部門を抱えているわけではないので、社外の力を頼ることになります。
大企業の場合、外部コンサル会社やデータ基盤構築専門業者に依頼してプロジェクトを立ち上げます。
中小企業レイヤーは予算や対象規模の都合上、私のような個人で依頼を請け負うデータ人材に業務を委託することもあります。

誰が率先してデータドリブン組織を導くのか？問題

戦略のお話になると、ビジネスや経営に直結するテーマになります。
ということは必然的にデータドリブン組織の推進は経営幹部が主導する必要があります。所謂トップダウンです。
もし、これを読んでいるあなたが戦略立案の可能な経営層の立場であればとても簡単。ビジョナリーあふれる戦略を立案し、データ組織の未来を描いてみてください。

ただ、残念ながらこれを読む読者の大半が経営層ではない方々です。再掲ですが、データドリブン組織の推進を主導するのは経営層の人間です。

もう一度言います。データドリブン組織の推進を主導するのは経営層の人間です。

以上を強く意識して本を読んでいただけるとより理解が深まるかと思います。

ボトムアップでデータドリブン組織を運営するための方法論

では、経営層ではない部課長クラス以下の役職の方々がデータドリブン組織を醸成するにはどうしたらいいのか？という問いに対しては1章の大半にそのヒントを詰め込んでいます。
ということで1章は経営層が戦略を策定していくお話と並行して、経営層を支えるチームや個人としてのあり方を強く説く内容となっています。
(少なくとも私はそう思っています。他の共著者がどう思っているかはわかりません。)

ボトムアップでデータドリブン組織を推進する方法は、

• 経営層に働きかける方法

• やろうと思えば誰でも今から始めることができる方法

• 経験則的に成功する確度の高い方法

あたりを中心に本文中にまとめられています。
業務の難易度としてはそこまで難しい内容にはしていないつもりですので、騙されたと思って実践してみるとよろしいかと思います。

できない理由を考える

基本的にはここまでの内容で語ったことを丁寧に実施していただくだけで問題ないかと思います。
ただ、残念ながら成功保証は一切なく、これらを実践しても失敗することはあります。
私のもとに失敗要因として「データ基盤が整備できない」「上司の理解がない」「現場が反対している」などの相談の声が届きます。
その際に、

• 失敗原因が見つかっても、原因の背景があるはずなので、何が問題なのかを改めて深掘りしてみる。

• 深掘りした結果、人間以外の課題(カネ、モノ)の場合はその課題を解決できそうな人を味方にしてみる。

• 深掘りした結果、ボトルネックになっている要因が個人に該当する場合は余程のことがない限り難しい。なぜならば人間個人の主義思想を変えることになるので、その労力は計り知れないくらい大きいものになる。

ということを必ずお話しています。
綺麗事を話しているのは重々理解していますが、この辺りの話は結局兵站の話に帰結します。
兵站に対しては個人で解決することは困難です。
解決しない課題に立ち向かう時間が許容できないのであれば、できる組織に異動をしてみたり、できる企業に転職してみるのが近道だと私は考えています。元も子もないですが。

伝家の宝刀: 他社事例

1章に限らず、拙書では著者陣の所属企業の成功事例を多く紹介しています。
他社事例については賛否両論でして、「たまたまうまくいっただけ」「自社には通用しない」など辛辣な意見を多くいただいています。

たしかにスキルやコミュニティに限って言えばもう少し組織の状況を考慮しないと他社事例だけでは立ちいかなくなるのは理解しています。
しかし、こと戦略とチームに限っては話は別です。上手く利用して自社の戦略に活かすことが可能です。

他社事例を引用する際の魔法の言葉:

この問題提起で物事が進む確率を少しだけ上げることができます。
(逆に、何も起きない場合は素直に転職サイトの登録を始めた方がご自身のキャリアのためになるかと思います)

参考までに導入事例、ケーススタディを載せておきます。
3大クラウドプラットフォーマーの導入事例は数が多いので、自社の条件と似たケースが探し出せますので、説得材料に生きるかと思います。

また、最近ではSaaS ELTやOSSのソリューションのケーススタディも充実してきたので、合わせて参考にするのも良いと思います。

Lesson 2: 課題のサイクルとVisual Analytics

例のVisual Analyticsの図の真意

Tableauに携わる業務を行っている人ならば見たことがある図。

この図はデータ分析という業務やTableauに限った話ではない点を強く強調しておきます。言い換えると課題解決方法は上記のサイクルに基いて行うべき、ということです。

BIツール導入後の失敗事例の原因はVisual Analyticsサイクルの機能不全から生じていると言っても過言ではありません。

Lesson 1で戦略の必要性を説きましたが、Lesson 2では戦略を支える要件定義に着目しています。
Visual Analyticsサイクルの図はデータ分析の要件といっても差し支えないフレームワークなので、この図に即して要件定義を実施するとスムーズです。
また、失敗事例から主な原因を列挙してみると、

• 細かな要件の抜け漏れ、考慮不足 = Taskに課題がある

• データの整備不足 = Get dataに課題がある

• コミュニケーション不全 = Act(share)に課題がある

などが挙げられます。Visual Analyticsサイクルに照らし合わせると、合致する項目が多いことに気付きましたでしょうか。
失敗するポイントはVisual Analyticsサイクルの要所に点在しているので、ポイントを押さえる目的でVisual Analyticsサイクルを利用してみるのも効果的です。

分析課題は誰のための課題か？

本文はビューワーの課題を見つけろ！という表現をしきりに使っています。
Tableau Blueprintのつながりなので、このビューワーというのはTableau ViewerライセンスでいうViewerのことを指すわけですが、もう少し一般化して解説してみます。

実は、この分析課題は誰のための課題か？という命題こそが要件定義で最も必要な要素になります。
逆説的に言えば、誰のために分析をしているのか理解していない状態で分析業務を行うな、と言っているのと同義です。

陥りやすい罠の一つは、経営層やデータアナリストだけのためのデータ分析環境になっているケースです。
BIツールはデータアナリストの作業を爆速に改善しますので、BIツール導入のメリットはあります。
しかし、データアナリストのためだけに莫大な投資を行わないといけないかと言われるとそうではありません。
また、経営層だけにメリットがあっても、現場の社員にメリットどころかデメリットが生じる可能性があります。

デメリットどころか、場合によってはレポーティングファクトリーに陥っているケースも。完全なるアンチパターンです。

本文ではケーススタディを挙げていますが、実際のところ、要件定義で最も難易度が高い命題ですので、要件定義中で一番時間を使って最適な方向性を導き出せるよう備えておいてください。

アウトカム(成果)を意識した動きが求められる

BIツールに限らず、全社的なシステム構築については明確にアウトカム(本質的な成果)の設計が重要になります。
BIツールにとって成果とは何なのか？こちらもかなり難易度の高い命題です。
実のところ、アウトカムを評価するのはデータ人材ではありません。
2章で詳しく解説しますが、評価者はDACIモデルでいうところの承認者です。
承認者が納得する成果を最大化することがデータ人材のゴールとなるわけです。

本文では一例として小さな成功を積み重ねる事例を紹介しましたが、まさにこれがアウトカムとして機能することの証左になります。
私のおすすめは、声の大きな経営陣を巻き込んだデータ分析の取り組みです。時間はかかり、難易度も高いですがアウトカムとしてはかなり高い位置付けとなりますので、その分高い評価を得ることが可能です。
(私のデータキャリアはむしろこちらの方が多いです。本当におすすめです。)

Lesson 3: データの三権分立はテストに出ます

起源主張しておきます

データの三権分立は私が世界で初めて提唱しました😤(ドヤ顔)。

今回本の執筆の企画時点より前からこの概念を考えていました。
データマネジメントに関する話はデータの三権分立に当てはめて考えると全て説明できると自信を持って宣言できます。

そのため、Tableau Blueprintに加えて後付けで1、2、5章の屋台骨を担う概念として登場させています。

ネタバレ: DMBOKです

という勘のいいガキデータ人材の方々、さすがです。
データの三権分立の基本構造はDMBOKの項目に合わせてデータマネジメントを抽象化したものになります。

独断と偏見でデータの三権分立とDMBOK Wheelの関係を分類してみると、以下のようになります。

• the Legislation / 立法

  • Data Architecture / データアーキテクチャ

  • Data Modeling & Design / データモデルとデータデザイン

  • Reference & Master Data / 参照データとマスタデータ

  • Metadata / メタデータ

• the Administration / 行政

  • Data Storage & Operations / データストレージと運用

  • Data Warehouse & Business Intelligence / データウェアハウスとBI

  • Data Integration & Interoperability / データ統合と相互運用性

  • Document & Content Management / ドキュメントとコンテンツ管理

• the Judicature / 司法

  • Data Quality / データ品質

  • Data Governance / データ統治

  • Data Security / データ保証

補足:
独断と偏見で、と表現している理由は、データの三権分立とDMBOKの関係性は綺麗にカテゴライズされるわけではなく、DMBOKのカテゴリが三権分立の役割とオーバーラップする可能性があるため、上記以外の機能も持ちうる(= ケースバイケースで役割が変化する)、ということです。

ケーススタディ

分かりやすい事例として、データ品質を例に説明します。
データ品質は上記では司法にカテゴライズしましたが、立法や行政がデータ品質について全く関与しないという話ではなく、司法がオーナーシップを担って責任を負うということになります。
では仮に立法や行政がデータ品質のオーナーとなった場合、何が生じるか考えてみましょう。

立法はデータの取り扱いのルールを決める機関です。ですが法令の専門家ではありませんので、法令違反を犯した状態でデータを提供する可能性が出てきます。
この事例は実際の出来事として本文中で紹介したかったのですが、検討の結果特定の企業に対して本で言及することはリスクと判断したためお蔵入りとなりました。

行政は立法が定めたルールに従ってデータを利用する機関です。
立法が定めたルールは、データ品質を担保する役割を担っています。
しかし、行政がルールを無視してデータを取り扱った場合、極めて重大な事故を引き起こすことになります。
現在までに発生したデータインシデントのほとんどが行政の暴走によって引き起こされた事件と説明できます。

司法に関してはデータに関する表立ったインシデントは発生していないように見えます。
その要因としては、

• そもそも司法を担う機関(例えば法務部)が存在しない

• 司法の介入が弱く、立法、行政の権限が強い

• 司法の特性上、詳細情報が報道されにくい

が考えられます。

企業の司法介入は著作物に対して企業の法務部が社外に対して発動するケースが圧倒的に多いです。

努力目標の取り組みであるプライバシーマークの取得の際に社内の個人情報保護委員会などの機関が機能するケースが該当しますが。

Lesson 4: CoEの存在

CoEとは？

端的にCoEと検索すると、類語が多くてとても悩みます。
ということで正しく用語を理解するためにみんな大好きWikipediaさんから引用しましょう。

本文中では、横断的組織ないし部署、研究拠点と表現しています。

CoEが果たすべき役割とは？

お手本通りの解説をすると、以下の役割が挙げられます。

📝ナレッジストック、ナレッジシェアリング
組織や部署を横断して知見や技術といった情報を集約します。
暗黙知も言語化し、情報として取り扱うこともあります。
また、集めた情報は一元集約されているため、容易に共有することもできます。これもCoEの役割といえます。

🗓️ビジネス戦略立案と推進
横断組織なので、企業内部や経営そのものの戦略に関与する機会が多いです。
DX推進やデータドリブン組織といったキーワードで戦略を立て、実行推進部隊として機能します。

🛠️業務プロセスの構築、あるいは改善
ビジネス戦略をマクロ的視点と捉えると、横断的に組織や部門が抱える業務の改善や効率化を図るミクロ的な要素もあります。

💪イノベーションの担い手
先端技術やITを駆使した課題解決プロセスを用いることが多いので、企業や組織のイノベーターとして機能します。

🤝社員へのサポート
導入ツールやサービスの導き手としてリーダーシップを発揮しなければならないため、必然的に社員サポートやヘルプデスクの役割も担うことがあります。

💬フィードバック
以上の取り組みは全てデータとして蓄積し、分析し、評価します。
必要に応じて公開し、有益な情報を提供することになります。

本文では、以上の内容にほぼ則した事例を紹介しています。
特に、データ分析におけるCoEの実例集となっていてより具体性を高めている構造となっています。

正直な話、CoEは必要なのか？

ここまででCoEについて解説したわけなのですが、この問いについて個人の見解を表明しておきます。

結論から言うと、ケースバイケースで見極めが必要になるので二元論で語ることはできません。

以下釈明。
正論としてはCoEを設置する方が良いですが、安易にCoEを信じてしまうのも危険です。
いわゆるCoEのPros/Consについてもう少し議論する必要があります。

• 例えば、社員数が1万人の会社組織に対してCoEは必要でしょうか？

• 例えば、社員数10人の会社ではどうか？

• 例えば、製造業の会社ではどうか？

• 例えば、官公庁ではどうか？

• …

禅問答的になってしまうのでこれ以上は言及を避けますが、言いたいこととしてはあなたの組織にCoEが必要だと思った要素を洗い出しておくこと。そして、なぜCoEが必要なのかを言語化しておくこと。
いわゆる、So What? / Why So?の繰り返しなのです。これもLesson 2のVisual Analyticsの図とアウトカムを意識した動きという点が重要になってきます。
簡単に答えを出すことはできませんが、CoEの必要性について検討の余地はあります。

Lesson Final: データスチュワード

タイトル回収になりますが、以上長々と書いた内容を個人で実践可能な存在というのがデータスチュワードになります。
現実的に見てもデータ人材が満ち足りている日本の企業は数えるほどしかありません。
当然ながら、トップダウンでデータドリブンを推進できる力のある経営層も限られていますし、ボトムアップで経営層にデータドリブンの重要性を説得できる人材も限定されます。
圧倒的にデータ人材が足りていません。兵站が不足している状態で満足に戦略の達成はできません。

Amazonレビューにも指摘がある通り、理想を言うだけでは何も現実の課題を解決することはできません。
しかし、拙書を読んでいただいた方の中からデータスチュワートが生まれ、増えていけば話は別です。
データスチュワートが増えれば戦略レイヤーにも介入できるCoEとして機能することだって可能なわけです。

簡単な道ではありませんが、1章で書かれた内容を私も実践し続けることで、理想の実現の証明になればと日々邁進している次第です。

次回予告

次回は2章の解説編をお送りします。

裏話