一部界隈で盛り上がっている『データ分析』ですが、実際の仕事上のプロジェクトでは難しい課題に直面するケースが多々あります。一見カッコ良く見えがちなデータサイエンスの実態はどのようなものなのでしょうか。
今回は、長年エンジニア、アナリストとしてデータ分析プロジェクトに属してきた経験を元に、よくありがちなプロジェクト失敗例をまとめていきたいと思います。本記事では、基本的に受託における業務を想定しています。自社サービスへの組み込みという文脈については述べていません。
もくじ
はじめに
いくつの解析プロジェクトに携わってきたか覚えていませんが、多種多様な業界に対して「データ」に関連した土俵でアプローチしてきました。基本的に起きる問題はいつも同じです。特に昨今ではありがちな問題をまとめました。
外部の企業に、いわゆる「AI」関連やデータに関連するお仕事を依頼しようとしている方、データ分析を事業に据えている企業への就職を検討している方はさらっと読んでおくと良いかもしれません。
それでは見ていきましょう！
1. 目的のないプロジェクト
昨今のデータサイエンスブームで特に増加したのが本ケースです。そもそもプロジェクトが立ち上がる理由は、何か課題解決する必要があったり、達成すべき目標があってはじめてスタートします。しかし、話題の「データ活用」を自社でも取り入れてみたいと考え、特に課題を持たずにプロジェクトが立ち上がることがあります。
自社でも何かできることがないか考えることは、とても良いことです。ただ、何のためにデータ活用を進めるのかについてはよく検討する必要があります。売り上げを上げたいのか、内部工数を削減したいのか、会社の意思決定に役立てたいのか、目的によってすべきことが大きく変わってきます。
データは神様ではありません。目的が欠落したデータ活用が、あなたの企業の売り上げを150%向上させたり、内部工数を大きく削減したり、意思決定を任せれるようなことは絶対ありません。ましてやAIといった概念性の高いものがすべてを解決するわけがありません。
なぜデータを解析するのか、という問いに向き合って目的を定めた上で最適な手段であるのかどうかを考えなければなりません。
データが勝手にすべてを改善するなんて幻想は捨てましょう！
2. 抽象度の高いテーマでプロジェクトがはじまる
プロジェクトの開始時点で既に失敗が見えているのがこのケースです。中身のないプロジェクトなんてうまくいくわけもありませんが、残念ながらよくあることです。
この業界では技術レベルに落とし込まれたテーマもあれば、メディアウケが良いだけのテーマもあります。例えば、『スーパーウルトラAI構築』といった名称は、先入観に取り込まれてなんとなく課題解決してくれそうな印象を与えます。
重要なのはこのシステムまたはプロジェクトが実際に技術ベースで何をもたらすかです。明確なテーマがなければ、プロジェクト終盤に必ずトラブルが起こり、想定していたものとはかけ離れた結果に辿り着きます。要件定義を十二分に行い、綺麗な看板がついた中身のないプロジェクトにならないようにしましょう。
開発フェーズに入った時に実現不可能と分かるのは既に手遅れです。プロジェクト後半でボロが出てしまいます。
技術レベルで結局何をするのか、を明確にしておくことが重要です。
3. 不可能なことをできる前提でプロジェクトがスタートする
データ関連に限らず、出来ないことを出来ることとして話を進めるのは勿論危険です。よくある事例としては、一般的には出来る範囲の事であったが、クライアントの保持データやシステム環境によって不可能であると途中で分かってしまうケースです。
非常に当たり前のことですが、プロジェクトスタート時に隅々までクライアントの状況を確認しておく必要があります。詰めが甘いと終盤フェーズで出来ないことが発覚し、方略やゴール設定を変更せざるを得ない状況に陥ります。
なんとなく出来そうだからと始めてしまってはいけません。プロジェクトの序盤から終盤まで課題となる部分はないか洗い出し、一つ一つ実現性を確認するべきです。一つの些細な確認漏れで序盤に出来ると嘘を付いていたとクライアントに判断され、信頼が失墜した例も知っています。実現性が99%では不十分なのです。
なんとなく出来そうを作らずに、実現性を100%にすることが重要。
4. プロジェクトチームにエンジニアがいない
想像しただけで震え上がります。前項の「不可能なことをできる前提でプロジェクトがスタートする」原因の一つでもありますが、実装する予定のエンジニアがいないと失敗の確度が異常に高まります。
エンジニアを開発フェーズで調達すれば問題ない考えのマネージャーもいますが、この場合は内部で後々揉めることになります。実装できない設計や無理なスケジュール感など、様々な問題が発生します。
実際に実装する予定のエンジニアがプロジェクト序盤からいる状態が理想的です。言わずもがなそのエンジニアは実装経験がある方が良いです。実装段階でのトラブルは避けるためにも、事前にチーム構築を怠らずに、見切り発車しないようにしましょう。
チームメンバー構成は絶対に手を抜いてはいけない。
5. データの閲覧権限をクライアントが所持していない
データ解析のプロジェクトではデータがあることが必須ですが、プロジェクト開始直後にデータの閲覧権限がクライアントにないケースがあります。自社サービスを運営している企業でもデータは外部の企業に預けていたり、グループ会社の権限下にある場合があります。データがあることを前提に進めるのは危険です。
特にECサイトは外部サービスを活用して作成しているケースもあるので、過去データが消失されていたり、行動ログまで取得する機能がないためデータがなく、実現可能領域が狭くなってしまいます。データの有無でプロジェクトを途中で断念せざるを得なくなるのは避けたいところです。
グループ会社でデータを管理しているケースは企業や事業部の政治的な抗争に巻き込まれる可能性が高く、各所にデータの閲覧権限を求める動きが必要になってきます。事前に閲覧可能かどうか筋道を立てるか、クライアント側に確認してもらうことはとても重要です。
データはあっても閲覧権限や分析のためにデータを拝受できるか要チェック。
6. 特に有用なデータがない
今までデータ関連に目を向けてこなかった企業にはよくあることで、まともなデータ管理をしてない上に、必要なデータの蓄積も怠っているケースです。この場合にはデータ収集の仕組みを検討し、設計するフェーズからスタートするので、本来のゴール達成まで果てしない時間が経過します。
データの閲覧権限をいただき、目的を達成する方法をデータベースを触りながら見つけてプレゼンさせていただく機会が多々ありました。現存のデータで実現が難しい場合は、必要なデータを洗い出しそれらを収集できるシステムを検討していました。もしくは本来の目的を達成する方法を別途考えていました。
昨今ではデータへの関心が高まっているので、サービスや事業を設計する段階で、既に将来のデータ活用を考えている企業も増えてきています。とても良い動きだと思っています。
データ収集から始めると時間がかかるので必ずチェックしましょう。
7. 基盤システムの権限が外部にある
5つ目の「データの閲覧権限をクライアントが所持していない」ことと類似していますが、基盤のシステムを管理している部署やチームがどこにあるか把握しなければなりません。
既存のシステムとの連携が必要である場合には、担当者と密にコンタクトを取る必要があります。その担当者が外部の企業にいるととても手間がかかります。プロジェクト開始時に、関係者は誰なのか、どこに所属しているのか明確に整理しておくことが重要です。
権限所持者がいればプロジェクトは円滑に進みます。
8. 実は既に分析体制が整っている
分析チームや解析体制を整えたいというお話もあります。しかし実際にはかなり高水準でデータ分析から施策検討がなされていて、十分なデータ活用ができていることもあります。
このケースの問題点はクライアントが自社の分析体制をよく理解できていない点です。データ活用ができていない悩みを抱えている方ほど、自社で素晴らしいデータ活用が行われていることを知らないだけである場合が多いです。
ヒアリングの段階で、本当にデータ活用がなされておらず、解析チームが存在していないのかを確認しましょう。クライアントは『解析チームは存在しているけど、何やっているか分からないし、もっと質の高い分析をしたい』といったことを言うかもしれません。その場合は実際にそのチームにヒアリングさせてもらいましょう。既に十分な運用が実現しているかもしれませんし、チームの内部に本当の課題があるかもしれません。
現状が分からないことで、後に不要なリソースが生まれてしまうかもしれません。
9. いつの間にかKPIが変わっている
2~3年にかけての中長期プロジェクトでは、しっかりマイルストーンを抑えておく必要があります。特に分析関連ではすぐに効果が出ないプロジェクトが多いと思います。途中でクライアントに関係ないKPIを要求されたりしないように擦り合わせを怠らずに進捗を出していく必要があります。
特にクライアント側の担当者が変更になった際に、新しい担当者との認識のすれ違いでこういった問題は起きやすいので、イベントがあった際には前担当者への入念な確認と引き継ぎも含めてチェックしましょう。
従来の目的と変更がある際には、柔軟に対応することもまた一つ大切な仕事の一つです。技術側との実現性の確認をして推し進めていきましょう。
本来のプロジェクトの目的を忘れずに長期間走り続けましょう。
10. 運用面での問題をデータで解決しようとする
本記事で何度も言ってきましたが、データはすべてを解決するわけではありません。課題の原因は運用面にあるケースもあります。システムを導入すれば万事解決ではありません。機械学習のように難解なシステムほど運用に慎重にならなくてはなりませんし、現状より厄介かもしれません。
プロジェクト完遂がゴールではありません。プロジェクトで構築した成果物を運用し続け結果を出し続けなければなりません。運用者の立場になって考えた時に、最適な方略は本当にデータを用いた方法なのでしょうか。運用チームの体制やルール作りの方が最適な場合もあるのです。
身近で手軽な方法が100倍の効果を出すこともあります。
まとめ
10つのよくある失敗をまとめてきました。ここで載せていない重要ポイントも数多く存在します。その一つ一つに注意を払うことも重要ですが、慌てずにプロジェクト開始時に整理しておけばイレギュラーな問題など起きません。
また、一方でもっともっとデータ活用が進むと良いなと思っています。まだまだ眠っている貴重なデータは多いはずです。外部企業にデータ活用の相談を考えている方も、そういった企業への就職を考えている方も、ぜひ挑戦してみてください。
楽しいと思いますし、できることが大幅に広がりますよ！
