一方で、思ったように進んでないことも発生しています。それは、我々の組織でカバーすべき領域がどこからどこまでなのか、範囲が明確でない点です。

　前述の通り、データドリブンマネジメント推進部門では自らのDXを進めるために自社データの蓄積分析を一元化する、というのをミッションとして掲げています。しかし一方で弊社はお客様向けのB2Bビジネスをしているため、それらの部門からの依頼もあります。データ分析を運用やサービスに使いたいという問い合わせも多く受けます。

　我々に求められているのは、ミッションクリティカルなSoR(System of Records／記録のシステム)なのか、SLO（Service Level Objective／サービスレベル目標）は低くてもいいから分析環境を立ち上げる、というSoI(System of Insight／洞察を得るためのシステム)なのか。我々が現時点でまず目指しているのは後者なので、役割分担を社内で明確に認知してもらいたいところですが、それ以前に我々のシステムの信頼性を上げることの方が先なのか……。正直なところ、葛藤はあります。

　社内の“文化”の違いを乗り越える部分にも時間を要しています。これまではどちらかというと、「困ってるチームからの依頼を受けて、助けてあげる」という“ツール提供と使い方サポート”的な立場でしたが、これからは個別の案件に留まらない水平展開や、業務そのものを変革するような提案につなげないといけません。

　それなのに、依頼元に寄り添い過ぎてしまって、そもそもあまりやる意味が感じられない分析に時間をかけたり、都合のいいデータ分析結果を返してしまったり……という事例がまだまだ残っています。

　即効性が低い基盤構築や人材育成に時間を要していると、周囲からの期待と現実とのギャップに苦しめられることになります。短期的なアウトプットを出しつつ、長期的な取り組みであるということをトップ層にある程度覚悟してもらうために説明を続けるということも、今後は重要な仕事といえそうです。

　本連載では3回に渡ってDXに向けたデータ分析について紹介してきましたが、読者のみなさんに伝えたいのは、まずは「小さなところから試してみよう」ということです。

　データ分析はGAFAだけのものではありません。見様見真似でいいから、まずは始めること、そこに自社のノウハウを載せて業務改革することこそがデジタルトランスフォーメーションです。

　大事なことは、データを「継続的」に貯めてみることです。それだけでいろんな課題が明らかになります。技術的課題、社内ガバナンスの課題、人材育成の課題。環境としてのデータレイクも最初は小さくてもいいです。MySQL でもいいし、生CSVファイルでもいいです。もうちょっと量が増えてくるとElasticsearchやSplunkなんかでもいいでしょう。

　ここまでくるとHadoop/Spark系も視野に入ってきます。オンプレにこだわる必要がなければ、BigQueryやAthenaという手もあります。とはいえ、これらはロックインの危険性があるので、本格採用時にはあらためて精査はしたほうがいいと思いますが……。

　そのデータは定期的に入手可能ですか？メタデータ(ID情報など)は整備されていますか？今後とも回していけそうですか？データが大量になってもいきなり高価になったりしませんか？

　こうした疑問と答えを重ねながら、貯まったデータに対して SQL/R/Python のどれかで試行錯誤ができるようになれば、最初の段階は突破したと思っていいでしょう。

　重要なのは、現場に嫌われても全社最適を優先すると言う覚悟があるか、その一方で適切なタイミングでわかりやすいアウトプットを出す、という両輪が重要です。データ整備も人材育成もある程度時間はかかるので、CDO/CTOといった経営層の覚悟を取り付けることも必須でしょう。

　データが整備されれば、それを使ってやってみたいことがある人は、必ず社内にいるはずです。自社の業務は、自分達が一番良く知っているのですから。是非、危機をチャンスに変えていただきたいと思います。

※掲載している情報は、記事執筆時点のものです。