大体失敗するデータ活用プロジェクト😿～POC墓場に埋葬されないように凡人の私達ができること
筆者はJTCでのデータサイエンティストとして、数々のPOCを弔ってきました。
その経験から、ボツになるPOCにはそれなりの理由があり、多くは予見可能であると思うようになりました。
最近データマネジメント寄りの仕事をすることが多くなったので、
忘れないように”データ活用プロジェクト企画の躓き所”を残しておきたいと思います。
データサイエンスプロジェクトやDXプロジェクトの実務担当者、関係者に少しでも気づきがあれば嬉しいです・・・？
0. 筋の良いPOCとは？
データ活用プロジェクトの成否は、「POC企画の筋の良さ」にかかっているといっても過言ではありません。
0-1. なぜPOCが重要なのか？
典型的なデータ活用プロジェクトは、
企画→POC→ビジネス展開、
と進んでいき、進むにつれて投資規模が大きくなっていきます。
このプロセスをデータマイニングの方法論として知られるCRISP-DM（CRoss-Industry Standard Process for Data Mining）に照らすと、
企画：ビジネスの理解・（データの理解）
POC：データの理解・データの準備・モデル作成・評価
ビジネス展開：展開
に当てはまると思います。
POCの目的は、データ活用プロジェクトの期待ROI（費用対効果）を、少ないコストで検証すること、と言えるでしょう。
多くの場合、POCの効果の程はデータ次第であり、データを見てみなければ、効果があるか分からないためです。
少ないコストと言っても、POCではデータ取得したり、モデルを構築したりと、一定のコストが発生します。
やってみなければ分からないからと言って、
闇雲に筋の悪いPOCを乱発していると、一生プロジェクトが成功することはありません。POC墓場という言葉が存在するくらいです。
0-2. 筋の良いPOCには要件がある
筋の良いPOCには要件があります。
ひとことで言えば、
POCのコストに見合う期待効果があって、それなりに実現性ありそう
となります。
具体的には、以下のポイントに尽きると思っています。
1. 解決するに値するビジネス課題が設定できている（期待インパクト）
2. ビジネス課題が実行可能な分析課題に翻訳できている（分析面での実現可能性）
3. ステークホルダーから業務導入の合意が得られる（運用面での実現可能性）
多数のPOC墓場と僅かな成功例を目にしてきましたが、
これらがクリアできていなければPOCは実行するまでもなく失敗し、
成功したPOCではこれらがクリアできていたように思います。
0-3. 最初から要件が満たされていることはない
一方で、解きたい課題が自社にとって先進的であればあるほど、POC企画段階では要件のどれかが足りていない（不明瞭）というジレンマがあります。
そのギャップを埋めるのがデータサイエンスプロジェクトを推進する人間の仕事です。
１～３をそれぞれ単独で解決するのではなく、全体がうまく噛み合うようにそれぞれをうまい具合に調整するのがPOC企画の妙です。
そのためには、データ分析設計の創造性、現場とのコミュニケーションによる一次情報の収集力、現場の意見を真に受けないクリティカルシンキング、キーマンに対する根回し、定量・定性根拠を効果的に使ったストーリーテリング、etcなど、
データサイエンスには直接関係ない能力が求められます。
反対に、POC企画のバッドプラクティスは、リストアップしたPOC案を特に精査せずに、１～３の観点で良さげなものを選ぶことです。
このようなアプローチをとると、一見合理的にも見えるが、面白みのないショボいPOCが選ばれてしまうことが多いように思います。
新規事業企画でも同じような現象を目にしました。。
1. 解決するに値するビジネス課題が設定できている
1-1. 解決したら経済効果が得られるのが良いビジネス課題
ビジネス課題とは何でしょうか？
ここでは、「企業や部門が目標を達成するための障壁（＝できていないこと、改善のポテンシャル）」と定義してみます。
解決したところで、経済的な効果（売上Up、コストDownなど）が得られなければ、それはビジネス課題とは呼べません。
ショボいビジネス課題を選べば、POCは100％成功しません。
正確にいえば、成功したとしても、ショボいことが分かるだけなので、次のステップ（ビジネス展開）に進むことはあり得ません。
また、POCの失敗から学べる知見も、本質的な課題とは関係の薄い、ショボいものになりがちなので、極力ショボいビジネス課題にはかかわらない方がよいです。
ではビジネス課題がショボいかどうかはどのように判断すればよいのでしょうか？
これは、一概には言えず、ステイクホルダーが自分や自部門にどのような期待を抱いているかによります。
設立間もないデータサイエンスチームだと、経営層からの期待が大きく、ちょっとした業務改善を成功させたとしても評価されないかもしれません。
大切なことはステイクホルダーの期待値を理解し、適切にコントロールすることだと思われます。
1-2. 既存の意思決定から逆算して考える
ある程度自分たちが説くべき課題の大きさや対象範囲が分かったして、POCで検証すべき課題をどのように特定するのがよいのでしょうか？
データドリブンではなくイシュードリブンで考えるのが鉄則と考えます。経験上、対象ビジネスで行われている意思決定を洗い出したうえで、
現状の意思決定がどのようなデータや根拠に基づき行われているのか
その意思決定がどんなコスト、売上に関連しているのか
新たなデータソースやデータ分析手法を導入することで改善できる余地がありそうなのか
などを考えていくと、筋の良い課題を見つけられることが多いように思います。
筋が良さそうな課題が見つかったら、POCを本格的にスタートさせる前に、課題の重要性をサポートする根拠を集めておくとなおよいです。例えば、
簡単な集計で期待損失額を概算しておく
現場のヒアリングを通じて現状の意思決定の惨状を確認しておく
などです。
これは自分やチームのためでもあります。自分達が課題の確からしさを信じられないと、挫折してしまうので・・・
2. ビジネス課題が実行可能な分析課題に翻訳できている
分析課題とは何でしょうか？
例えば以下のようなものを指します。データ分析の設計と言っても良いかもしれません。
どんなデータに対して
どんな数理手法を使うのか（クロス集計、教師あり学習、教師なし学習、強化学習、数理的最適化）
そのアウトプットをどのようにビジネスの決定に反映するか（業務シミュレーション）
データ分析では、教師あり学習、教師なし学習、強化学習などの広がりがありますが、個人的には「教師あり学習」を適用することが多かったです。
理由は、予測の成否が評価しやすく、ゆえに、予測精度向上によるビジネスインパクトが評価しやすいためです。
教師あり学習をビジネス適用する場合、以下のポイントが設計できている必要があります。
2-1. 目的変数（予測の対象）は何か？
2-2. 説明変数（予測の根拠に使うデータ）は何か？
2-3. 予測結果に基づきどのように判断基準を変更するか？
特に3点目が重要で、この観点が抜けていると、
精度がよさそうな機械学習モデルが出来たけど、
結局これって何の役に立つんでしたっけ・・・？
となりがちです。
2-1. 目的変数（予測の対象）は何か？
意思決定に直結し、かつ、取得済み（or取得可能な）データで検証可能なものを選ぶ必要があります。
データが無ければこれから取得するということも考えられますが、
企業の成熟度によってはデータ取得に大き目の投資や業務負荷が発生する場合もあります。
特に重要なデータは何でしょうか？
前述した教師あり学習の場合を考えます。
典型的なユースケースとしては、以下のようなものが考えられます。
何等かの指標（目的変数）を、判断根拠となるデータ（説明変数）を使って予測します。
予測精度の改善により、ビジネス意思決定の精度を高めます。
この場合、予測対象データ（目的変数）がないと、予測精度や意思決定の評価ができないため、プロジェクトが詰んでしまいます。
ですので、予測対象に関連するデータの有無は早期に確認する必要があります。
一方、判断根拠（説明変数）に関連するデータは、いくつか欠けていても、致命傷にはならないことが多いです。
2-1-1. 不完全なデータの扱い
理想は意思決定に直結する目的変数のデータが完全に取得できることですが、部分的にしか満たされていなくても工夫の余地があります。
例えば、在庫最適化のために需要予測したい場合を考えます。
需要とは、受注（実現した案件）と失注（実現しなかった案件）の合計です。
ですので、需要を予測するには、受注だけでなく失注の情報も必要になります。
しかし、契約につながらない失注の方は記録されていない場面というのが多々あります。
この場合、プロジェクトは詰んでいるのでしょうか？
需要予測というのは、在庫最適化のための手段です。
ですので、在庫最適化という観点では、需要の総量を予測するのではなく、在庫切れになるかどうか（YesかNoの二値分類）を予測し、
在庫切れリスクが高い場合には、在庫を補充するようにする、という業務ルールを適用することで、業務改善に貢献できるかもしれません。
このように、ビジネス課題という目的に対して、データ分析課題の設計方法には柔軟性があることが、
データ飼う帳プロジェクトの難しさであり、データサイエンティストの腕の見せ所と言えるかもしれません。
2-1-2. 回帰→分類への変換
回帰問題（数値の予測）ではなく、分類問題（ラベルの予測）として捉えなおすことで、
結果を解釈しやすくしたり、評価しやすくしたりできる場合があります。
具体例は2-1-1で紹介した、需要予測の事例が当てはまります。
2-1-3. 会社目線と担当者目線のGAPを狙う
例えば、会社目線だと利益を最大化したいのに、営業目線だと売上を最大化するようなインセンティブが働いていることがあります。
この場合、目的変数に「利益」に関連したものを選ぶことで、利益改善インパクトを狙える可能性があります。
最近よく耳にするRevOpsとかもこれに近い話だと思います。
2-2. 説明変数（予測の根拠に使うデータ）は何か？
既存業務では利用できていなかった情報を活用できると、既存業務をオーバーパフォームできるかもしれません。
逆に、そのようなアイディアが無い場合、機械学習モデルを導入したところで、大した効果は得られないかもしれません。
この場合は、2-1-3で取り上げたように、目的変数を会社のKGIに直結するものに捉えなおす努力をした方が、業務改善のインパクトが大きい印象があります。
2-3. 予測結果に基づきどのように意思決定基準を変更するか？
予測結果と意思決定基準のロジックは、ビジネス課題と橋渡しをする重要な要素であり、抜け漏れがちです。
このロジックが分かりやすく・合理的であれば、POCの結果はビジネス部門にとっても受け入れられやすいです。
予測結果に基づきどのような意思決定がなされ、
その結果どの程度の改善効果が得られるのか、
を定量的に示すシミュレーションができるのが理想的です。
対象とする課題によっては、ビジネス部門と密に連携してシミュレーションロジックの信頼度を高める必要あります。
3. ステークホルダーから業務導入の合意が得られる
3-1. キーマンを特定する
業務改革を推進する際は、会社の文化に応じて影響力のあるキーマンを特定し、その方と事前に合意を取っておくことが重要です。
影響力のある方が関心を持つ領域であれば、POCへの協力を得やすく、成功した際に業務導入へとつなげやすくなります。
一方で、権限を持つ方が乗り気でない施策を無理に推し進めると、期待した成果を得られない可能性があります。
人は、自身が気乗りしないことを、上層部からの指示がない限り自主的に進めることは少ないものです。
そのため、影響力を持つ方が関心を示しそうなビジネス課題を選定し、その方の視点から見ても利益があると感じられる提案を行うことが重要です。
3-2. （余談）オイシックスに見る期待値調整の妙
余談ですが、以前オイシックスの勉強会で聞いた話が非常に印象的でした。
経営層の期待値を巧みにコントロールする手法が見事であり、このような立ち振る舞いを見習いたいと感じました。
当時、同社ではデータ分析組織を立ち上げたばかりで、経営層から大きな期待を寄せられていました。
しかし、データ基盤への投資を進めるには、まずデータサイエンスプロジェクトの成果を証明する必要があったといいます。
そこで、最初に取り組んだのが需要予測プロジェクトでした（詳細は以下の記事）。
現場の担当者と密にコミュニケーションを取りながら、実現可能性が高く、かつニーズの大きい課題であることを確認したうえで進められました。
業務導入のPOCを実施する前に、手元で予測モデルを構築し、需要予測によるビジネス効果を試算していた点も興味深い点です。
この段階では、その取り組みについて経営層には共有していませんでした。
そして、業務導入POCを行い、需要予測の効果を立証。
その結果をもとに経営層へアピールし、データ基盤への投資が確定したそうです。
いいなと思ったら応援しよう！
