今更解説する動き出すデータドリブン組織のつくりかた 章別攻略編。今回は2章 アジャイル性を完膚なきまでに濃厚で濃密な解説をしていきます。それではいきましょう！

本章は私が章リーダーを担当しました。そのため内容や構成全般は私が全面監修しており、従って私の担当文章量も多めとなっています。ですので他の章と比較して背景や裏話をより手厚く解説していきます。
ちなみに2章の事例紹介のパートは徳谷さん(@roadstar_nb1600)が担当しています。

Lesson 1: 2章はアジャイル性、もとい導入とモニタリングとメンテナンスです

本家からアジャイル性の項目が消え去りました

再掲になりますが、まずはこちらの図をご覧ください。

次に、2023年9月現在の本家Tableau Blueprintのサイトを提示します。

Tableau Blueprintがリリースされた2019年当初は、サイト左側のペインの大項目は最初に提示した図のテーマに沿った項目と一致していました。
しかし、特にアナウンスされることなく改訂が繰り返されてしまい、現在のように大項目としていたカテゴリーではなく、図でいうところのフロー単位(白丸の項目)で左側ペインの項目を構成するようになってしまいました。
これにより、「Tableau Blueprintにおけるアジャイル性とは何か？」という問いに対する回答は閉ざされたわけです。
(いや、リリース当初も何も書いていませんでしたが)

アジャイル性は一旦忘れてください

アジャイル性に限らず、大項目の消滅の事実は執筆中に気付いたわけですが、ここで一番ダメージが大きかったのは2章を担当した私でした。
なんてったってアジャイル性の正解がわからなくなってしまったのですからね。とても困りました。

執筆作業時のエピソードは裏話で赤裸々に語りますが、この話の落とし所がLesson 1のタイトル回収ということになります。
結局のところ、よくわからない状況に陥ったので、一旦アジャイル性というワードに捉われずに、アジャイル性を構成していた導入、モニタリング、メンテナンスの3点の内容に着目して執筆を進めることとしました。
この辺りは著者陣とも議論を多く重ねた部分でもあり、多くの時間も費やしました。

ですので、Lesson 1の内容は本を購入していただいた読者の方々に特に伝えたい内容となります。

Lesson 2: 導入して終わるBIツール導入プロジェクトは失敗する

BIツール導入をゴール設定としているベンダー、企業、組織、人が圧倒的多である事実を認識しなければならない

Tableau Blueprintで書かれている内容で最も共感できる点は、システムやツールの導入を最終着地と捉えていないことにあります。
TableauベンダーのSalesforce社に限らず、システムベンダーやサービスプロバイダーの立場としては、システムやSaaSが売れた時点で(ベンダーのビジネス上のKGIとしての)ゴールとするのは至極当然な話です。
そのため、カスタマーサクセスを持たないベンダーでもない限りは、導入企業、あるいは企業からシステム導入を委託されたITコンサルタントで構成されるプロジェクトチームは導入後の運用保守やユーザーの教育は後回し、運用保守はプロジェクトのスコープ外にするという、いわゆる「やらない意思決定」をしているケースは定石だったりします。
こうした背景の一つに、ユーザー企業側の意識面に問題がある点を強く指摘しておきます。

例えばですが、利用者側による無秩序なBIツール導入によって、BIツール導入によって解消する課題とは別の多くの課題を生み出してしまう、というお話です。

残念ながらこれらに書かれている内容は私が昔BIツールのPdM(プロダクトマネージャー)というベンダーの立場でユーザーと関わっていた際にも抱えていた課題ですし、今もなおBIツールに幻想を抱く企業が痛い目を見ている現状は変わりありません。

非常に嘆かわしい事実ではありますが、今一度BIツール導入の現状は受け入れる覚悟は必要かと思います。

日本企業のオンプレミスという信仰、あるいは呪い

BIツールに限らず、システム導入の際にオンプレミスを選択する日本企業はとても多いです。Amazon Web Service(AWS)やGoogle Cloud Platform(GCP)などのクラウドサービスが勃興しているにもかかわらず、です。
令和の段階でも未だに自社でデータセンターを用意し、オンプレミス環境の構築、運用をしている事例が後を経ちません。
適切な投資を行った上で業務要件を汲み取り、データや企業の資産、顧客の安全を守るという意味ではオンプレミス環境はある意味正しいと言えます。
しかし、そんなことができる企業は日本にはごく僅かしか存在していません。

• クラウド環境に適さない事業、サービスを行っている日本企業はどれくらい存在するのでしょうか？

• あなたの所属企業が理由もなしにクラウド環境に否定的な場合、正しい意思決定と言えるのでしょうか？

• オンプレミス運用のコストとクラウド運用のコストをどこかで見誤っていないでしょうか？お気付きでないかもしれませんが、人件費はタダでも無尽蔵に湧くものではありません。

今回、2章を執筆するにあたり、AWSやGCP、Microsoft Azureを頑なに選択しない企業に対しての訴求を意識して書かせていただいています。
令和のこのご時世にクラウドサービスに疎い状況にとても強い危機感を読者に抱いてほしいと願っています。

cf. デジタル庁がガバメントクラウドを構築する際の質問状は正直言って日本全体のITレベルの底が知れたきっかけになったと個人的には認識しています。

デジタル庁の取り組みによって、日本のオンプレミスの呪いを払拭し、事例として民間企業に広く伝わることを切に祈っています。

BIツール導入に対して課題設定を見誤ってはいけない

私はこれまで所属してきた企業や個人事業主としてこれまで数十社の企業のシステム導入プロジェクトに携わらせていただきました。
しかし、残念ながら担当プロジェクトの全てが「導入がゴール」なプロジェクトなのでした。
また、BIツールを導入したいユーザー企業と、BIツールを販売したいベンダーとの間を持つITコンサルタントの業務も経験していますが、プロジェクト完遂後の良い話はあまり聞いていません。

これは私の実力不足が祟った側面もあり、大いに反省しているのですが、私以外にも要因はあるのです。

以下、過去のXのポスト。

BIツール導入に限らずですが、システム導入プロジェクトの肝である課題設定を要件定義の段階で見誤ると100％、いや120％の確率で失敗事例に化けます。そう、本当に、簡単に、失敗できます。
だから戦略は大事なのですね。
(戦略については今更解説1章編で解説したので合わせてよろしくお願いします。)

また、戦略と同じくらい重要な兵站のお話もこれまで多く語ってきましたが、2章がまさに兵站に関するネタの宝庫と言っても過言ではありません。
2章は兵站管理であることを意識して読んでみることをおすすめします。

Lesson 3: データの三権分立でデータを蹂躙する

Lesson 2までは今回2章を執筆するにあたっての思いや課題感を暴露させていただきました。
Lesson 3は今更解説1章編で触れたデータの三権分立に対し、詳説していきます。
本文で書きたかった内容や泣く泣くカットした内容も含んでいるので、ディレクターズ・カット版として読んでいただければと思います。

2章(と一部5章)の解説のためにデータの三権分立を用いた

今更解説1章編で起源主張しましたが、データの三権分立の詳説になります。

BIツール導入プロジェクトを成功するためにはどうすれば良いか？という問いに対しては、データの三権分立というフレームワークを示しています。
2章のほぼ全ての内容はデータの三権分立によって示すことが可能な優秀なフレームワークなのです(とてもすごい)。

というのも、2章は導入、モニタリング、メンテナンス、テーマにしているため、そっくりそのまま行政の機能が当てはまります。
また、5章はガバナンスがテーマなので、司法にフォーカスした解説が可能になります。

※前回の補足でも説明しましたが、役割が変化するケースもありますので本文中では必要に応じて三権分立の機能を意識しながら書いています。

DMBOKむずくね？

今更解説1章編のネタバレで、DMBOKの話をしました。
本音を言うと、DMBOKの内容に即した戦略からチームビルディング、タスク落とし込みまでを計画すべきです。

Now let's read the DMBOK!!
And take action!!

英語に自信がある方は原典をどうぞ。(原典の方がお安め)

とは…ならない……です…よ…ね。

理由は一度でもDMBOKに目を通した人ならわかりますが、

• 読了するための時間が相当かかる。原典で590頁❗️つらい。

• 全体像の理解も、個別具体の理解も困難である。つらい。

• DMBOKを理解しても、企業や組織の都合で実行は難しい。つらい。

一つ目と二つ目は気合と根性で突破可能なのですけど、三つ目が多くの企業の悩みとなっていると私は考えています。
多くの悩みは、DMBOKを推進したくても社内に推進できる人材が存在していないことになります。
仮に適任者がいたとしても、その方の業務の優先度としてかなり低めに設定されている可能性も高いです。
また、DMBOKを理解している人材を採用しようにも、そもそもそんな人材は世界的に圧倒的に不足しています。

ということで私の肌感覚で恐縮ですが、DMBOKに則ってデータマネジメントを推進すること、それ自体が非常に難易度が高いため理想論になりつつあるのではないのかなと考察しています。。
DMBOKの解説記事や読書会の事例は散見するのですが、DMBOKを適用した組織の事例紹介記事があまり挙がっていないのも、この肌感覚の根拠にもなっています。

DMBOKの考え方は完全に同意するが、実行実現性については懐疑的。
もう少し実行難易度を下げることができないだろうか？

DMBOKを読了した私は、こんな疑問を抱いたわけです。

データの三権分立の真意は、高度な兵站管理を楽にするための役割とタスクの話

そこで考えたのがデータの三権分立というフレームワークということです。

• DMBOKに書かれている個別具体から解像度を下げ、抽象度を高めることで、より実行難易度を下げる効果を狙う。

• 実際に存在するフレームワーク、またはモデルを引用することで、DMBOKの複雑な内容を概要レベルで把握可能な状態にする。

• 企業規模、組織レベル、人材の影響が少ない内容を目指す。

以上を意識した上で設計しています。

↓の絵よりも、

↓の絵の方が、(なんとなくの感覚で)役割分担が簡単だったり、過不足しているタスクが一目で分かりそうな気がしませんか？

特に意識した点は兵站の管理を楽にするように設計していることです。
まともにデータの三権分立を実行しようとすると、異なる機能や職責を持った3人、ないし3部署が必要かと思いがちですが、1章の本文中では必ずしもこの3つの役割を人ないし組織に別々に割り当てる必要はないと説明しています。
例えば、最初は推進者やCoEなどの職責の人が全役割を抱えた上で推進し、徐々に権限委譲しながら役割分担を拡大していく、というやり方でもいいわけです。
必要最低限の人数でデータマネジメントの勘所を押さえた上で、為すべき事を為すという点がデータの三権分立の思想になっているわけです。

もちろん、最初期の段階で三権それぞれを組閣できればかなりアドバンテージです。
しかし、人材不足の昨今で実行するには厳しい現状がありますし、そもそもそこまでチームビルディングできる時点でDMBOKの実行は可能ではないのでしょうか？

パワーバランスは均等に維持しなければ終わりますが、バランスを取ること自体が難しい

今更解説1章編のケーススタディに全てが集約されています。ありとあらゆるデータインシデントは全てデータの三権分立のパワーバランスが崩れた際に発生します。

三すくみ、という言葉があります。

本文中では抑制と均衡(チェック・アンド・バランス)と解説しましたが、データの三権分立の理想は三すくみの状態でお互いに牽制し合う関係を担保することがうまくいく秘訣です。

例えば、

• 行政の勝手な振る舞いに対して、司法は強権を振るってデータを守る。

• 立法が考えたデータ設計やデータ構造に対して、行政は利用しやすいデータを強くリクエストする。

• 司法がサボらないように、立法はデータルールを整備して仕事をさせる。

各役割は以上の行動を求められるわけです。
ただし、三すくみに関しては先ほど解説した必ずしもこの3つの役割を人ないし組織に別々に割り当てる必要はないという考え方と真っ向から対立します。
権力一極集中が長期間続く場合はそもそも権力分立している意味が失われるだけでなく、中長期的には不祥事の温床になります。
兵站管理とパワーバランスはトレードオフになる可能性がある、という事を念頭に戦略を練る必要があるわけです。

重ねて言いますが、兵站に余裕がある、すなわち人材や組織が充実している場合は三すくみは容易に設計可能ですが、それができる時点でDMBOKに従った方が本質的なのかもしれません。

Lesson 4: モニタリングは必須です、絶対に外せません！

導入については、今更解説シリーズでは解説しません。
というのも、本で紹介した導入事例は定石中の定石であり、当たり前とも言える手順を踏んでいるからです。
また、これは言い訳に聞こえるかもしれませんが、導入手順の言語化は可能ですが、導入手順をどの企業でも可能なようにする一般化、または汎用化は不可能です。
本文の導入の定石よりも巷に溢れる導入事例の方が有益な情報が潜んでいるかもしれませんので、導入事例について調査、学習することをすすめておきます。

一方、モニタリングとメンテナンスについては別で、本の内容も圧倒的にボリューム不足ですし、導入事例にも漏れているケースがあるので情報収集の難易度が高いです。
こうした事情もあるため、Lesson 4は本に書けなかったモニタリングの解説をさせていただきます。

モニタリングの意味を考えたことありますか？

本文ではモニタリングを大きく二つに分けて解説しました。

• システムモニタリング

• ユーザーモニタリング

前者についてはデータ分析基盤を管理するデータエンジニアやSREといった職種の方々が担当します。
では後者は誰が行うべきか？という問いに対し、私の解はデータアナリストとなります。
データアナリストのチームを持つ場合は特に、ユーザーモニタリングはデータアナリストチームが持つべき行政のお仕事と捉えています。

例えば、レポートやダッシュボードのお話。
データアナリストの活動の結果、成果物としてBIツールで作成したレポートやダッシュボードが日々蓄積されていきます。
これはデータアナリストの業務上、必要なプロセスではあります。
しかし、レポートやダッシュボードは無限に蓄積されて然るべきか？と言われると疑問です。

• 昔は見ていたが、現在誰も見ていないレポート、ダッシュボード

• いつまでも残り続けているテスト用で作ったレポート、ダッシュボード

• 残すべきか判断できない退職者が作成したレポート、ダッシュボード

運用期間が長ければ長いほど、ゾンビプロセスならぬゾンビレポート* が残り続ける状況に陥ります。
一般的にレポート、ダッシュボードを廃棄するコストは運用期間に比例して大きくなります。

* ゾンビレポート: 役目を終えたレポートにも関わらず、BIツール上に残ってしまったレポートのこと。保存領域を逼迫したり、無駄なデータ抽出コストがかかったり、検索に悪影響を及ぼすことがあります。

また、これを書いていた2023年10月18日に以下の事件が報道されました。
モニタリングのテーマとして至極ふさわしいので追加で紹介しておきます。

以上を読んだ上で私見を語ります。
一般的にデータ基盤の構築の有無に関わらず、データ不正利用やデータ漏洩リスクは0ではありません。
そのための対策としてモニタリングを万全にし、不正や持ち出しが発生しないような環境づくりをする必要があるわけです。
この事件で学ぶべき点は多いです。

• 少なくとも10数年前から発生していた犯行であるため、犯行を検知できなかった行政の落ち度は多い。

• システムモニタリングできていれば、漏洩は未然に防げていたのかもしれない。

• ユーザーモニタリングも併用していれば、不審な行動をしているユーザーが事前に検知できたのかもしれない。

普段から顧客データを取り扱っている企業なら殊更、行政が担う業務を意識をした上でシステムモニタリングだけでなく、ユーザーモニタリングにも力を入れてインシデントを0に近づける努力を示さないといけません。

データアナリストは真剣にモニタリングに向き合うべし

では、モニタリングを推進するためにはどうすればいいのか？というお話です。
この内容は本文では泣く泣くカットした内容となります。

単純な話、データを見てインサイトを与える職責であるデータアナリストがもっと積極的にモニタリングの取り組みに参戦していただくのがベストであると私は考えています。
理由は単純で、モニタリングに関してはデータアナリストがプロだからです。

しかし、現実問題としてデータアナリストが「BIツールを利用しているかいないか」「レポートを見るべき人が見ているか」「不要な閲覧権限を与えていないか」などという業務をしている姿は本当にレアです。
データアナリストがかなり成熟しきっている(と私が勝手に思っている)所属企業ですら、私が着任して警鐘を鳴らすまでは誰もユーザーモニタリングなどしていませんでした(以下参照)。

後述するROIのお話にも関連しますが、モニタリングをしないということはデータアナリスト自身に必ず跳ね返ってくる課題となります。
少なくとも、自分たちが使用しているデータ分析環境やBIツールに対してはモニタリングは自分ごとと捉えて積極的に業務に組み込んでおいてください。

モニタリングは司法の業務ではなく、行政の業務として捉えてください

ここまで解説を読んだ方は以下の疑問を抱いた方はいるでしょう。
(実際に著者陣からも多くの指摘をいただいた内容でもあります)

不正や問題を検知して評価するのが司法の業務なのだから、モニタリングは行政ではなく司法の業務ではないのか？

結論から言うとモニタリングは行政の業務です。
理由は三権分立を考えるとシンプルでして、司法は行政の業務をチェックする役割がありますが、行政の業務の証拠(エビデンス)を司法が担うのはおかしな話です。

行政は自分たちが悪いことをしていないことを証明するためのエビデンスとして、モニタリング情報を用意する義務があります。
司法は行政から提供されたモニタリング情報をチェックします。
もし、行政からモニタリング情報が提供されない場合は、司法は行政に対し業務を是正してモニタリング環境を整備しなさいと命令することができます。モニタリング環境がないと行政が悪いことをしているのか否かの評価ができないからです。

Lesson 5: メンテナンスの詳細は5章です

Lesson 5はメンテナンスのお話なのですが、本の構成上の関係で本文中の具体的な解説は2章ではなく5章に記載させていただきました。
ですので、Lesson 5は概要レベルの解説に留め、詳細レベルは今更解説5章編にパスすることとします。

システムメンテナンスを舐めている人向けのお説教

私と働いたことがある方や、私とBIツールについて語った方ならわかると思いますが、基本的にあらゆるIT環境は常に最新にすべきであると100万回は説明しています。
原理原則、システムメンテナンスをやらない理由は一切ないし、やらない企業、組織は時代に取り残されると強い言葉で表明しています。

とある情シス部門担当者👨‍💼「いやいやでもでもまって、あらきさんの理想は理解しているつもりです。しかしですねぇ、我々は他にも業務を抱えているわけでして、メンテナンスに時間をかける余裕なんてないわけなのです。ましてや今Tableau Serverのアップデートなんかしたら障害だらけで大変じゃないですか。我々の事情も考えてくださいy」

実際問題、こうした意識の情シスに対して説得するコストは莫大ではありますが、敢えて説得する場合は以下の例えを使っています。

• 自動車は定期的に車検をする義務があります。なぜでしょうか？

• 航空機は離陸前に国家資格を持った航空整備士の整備を受けます。なぜでしょうか？

• ビルなどの建築物は消防点検、エレベーター点検など多岐に渡る点検を年に数回実施する義務があります。なぜでしょうか？

• では、ITシステムはバージョンアップ、セキュリティアップデートなど、数々のメンテナンスを行う必要があるのですが、それを実施しない大義名分は一体何なのでしょうか？

今一度、自分の行動を翻ってよく考えてみてください。

馬車ではなく新幹線、新幹線ではなくロケット、ロケットではなくどこでもドア

DATA Saberの取り組みで、馬車ではなく新幹線という教えがあります。

簡単に説明すると、依頼者が馬車に乗って目的地に移動したいと依頼された場合、移動手段としては馬車より新幹線の方が早いので、新幹線を提案した方がいいよねというお話です。
上記の動画はデータ分析に関しての例え話なのですが、そっくりそのままシステムメンテナンスのお話に転用できます。

ITシステムはこの例え話で言うと馬車と新幹線のことを指します。
メンテナンスをすることで、速度が向上しますし、馬車が新幹線に、新幹線がロケットに進化して更なる恩恵を受けることが可能になります。
逆に何もしないといつまで経っても馬車のままになりますし、最悪馬車が壊れて目的地に移動できなくなります。

本音を言うと、5章は2章の後の方が本の構成上都合がよかった

この話は裏話でも良かった気がしますが本編に載せます。
Tableau Blueprintの図の構成上、本の章立てが決まったのですが、2章のメンテナンスの項目を考えると5章の内容が一番近しい内容、かつ5章で詳細を解説しているので2章と5章の距離は近い方が都合が良かったと個人的には思っていました。
ですので、2章と5章はセットで読むとso goodです。

Lesson Final: ROI論者との戰い

ここまでの長文、本当に本当にお疲れ様でした。
本文と合わせてBIツールの導入、モニタリング、メンテナンスのお膳立ての助けになればと切に願い、執筆した次第です。

しかし、これだけの文章を綴っても実際のところ、ROIに関して追及され、結局最後はカネや見えない謎の力でねじ伏せられて導入が見送りになった経験、ありませんか？
他社のデータ人材の方やイベントの懇親会参加者からの相談やお困りごとでダントツ一位のお悩みとして、決済者や意思決定者からROIに追求されて困窮している旨を伺っています。

一応、本文中にROIをBIツール選定の指標にしないことを明言していますが、そもそもの話、ROI論者の領域でこの手のシステム導入の議論をすること自体が不毛であるため、別の方法で回避するしかありません。

そもそもROIとは一体何なのでしょうか？

BIツールの話で言うと、利益ってどう捉えればいいのでしょうか？
どちらかと言うとBIツールは直接利益を生み出すためのツールではなくて、作業効率を上げるツールです。
人件費を抑える役割を担っていると捉えてみるとROIとは別軸で生産性(労働生産性)という話になるのであまりおすすめしません。

生産性を担保するために、レポートやダッシュボードを増やしまくるか、従業員数(ここではBIツールを使える社員)を減らさないと値は上がらない式になります。

……ROIの計算よりも筋が悪い結果になりそうですね。

やはりこの話は何度シミュレーションしても逃げろとしか結論が出なさそうです。

もうひとつ言えるとしたらROI論者が経営層や上層部の人間だった場合は、そもそも就くべき相手を間違えた可能性の方が高い気がします。
あくまで私の経験則なのですが。
この場合、いくら兵站を整えても戦略や意思決定が破綻していることになるので、今更解説1章と同様、できる組織に異動をしてみたり、できる企業に転職してみるのが近道なのかもしれません。
(しかし、1章の状況とはまるで異なり、例えるならば日本の一番長い日の読了後の感覚に似ていると思います。)

十数年、ROI論者と戦ってきた身として、結論に逃げる選択は非常に忍びないですが、もし、良い解決方法がありましたらぜひ議論したいです。

次回予告

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

裏話

※書く時間が確保できなかったので、一旦無料で解放します。後ほど追記します🙇

Tableau Blueprintの構成と本の章立ての構成の関係図