こんにちは、リンクアンドモチベーションのデータチームの野見です。
僕はこれまで、機械学習を活用したPJTのPoC、実導入に関わってきました。なかでもヘルススコアは社内初の機械学習PJTでしたが、今では組織の新たな文化・スタンダードとして社内に定着してきています。
今回は、そのヘルススコアPJTの取り組みを振り返りつつ、PoCの先にある壁が何であるか、また、その壁を乗り越えるために必要だったスキルについてまとめてみます。
PoCの次の壁：「PoC貧乏」「PoC死」
データサイエンティストにとってPoCはやりがいでもあり、時として大きな壁でもあると思います。「PoC止まりの壁」という言葉もあるように、PJTがPoC段階を突破しないことは珍しくないです。
では、なんとかPoCを乗り越えたとして、必ず実導入が決まるかというと、そうではありません。
- 一向に導入計画が進まない
- 何に使うか、どう使うかが決まっていなかった
- PoCで全てのリソースや予算を使い切ってしまう
など、PoC後のプロセスで停滞してしまう「PoC貧乏」という現象や、最終的にはお蔵入りになる「PoC死(ぽっくし)」という現象が起きています。
機械学習を使ったヘルススコアについても、PoCには成功したものの、それから「どんな方法で誰に活用してもらうか」が決まっておらず、停滞した期間がありました。せっかくのチャンスを逃さず活かしたい、これまでの努力を水の泡にしたくない、という思いから試行錯誤を行いました。
役に立った武器①：プロダクトマネジメント
AIや機械学習による成果物は、世の中や社内にとって、（一見）なくても困らないものであることが多いと思います。だからこそこだわりたかったのが、プロダクトマネジメントです。
大きくやったことは2つで、「プロダクトを描くこと」「関係者をまとめチーム化すること」です。
プロダクトを描く
最初は、リーンキャンバスを描きました。PoC直後はそもそも機械学習モデルしか存在しなかったので、それを使って価値につなげるシステムを定義するためです。
（例：リーンキャンバスはスタートアップのマネージメント手法として注目を浴びている『Runnnig Lean』の著者アッシュ・マウリャ氏が提案した、ビジネスモデルを9つの要素に分けて考えるフレームワーク。）
BizMake Media「リーンキャンバス（Lean Canvas）とは？ テンプレートや事例、書き方などを紹介！」より
ヘルススコアは、LTVを最大化し顧客に満足・成功していただくために、顧客が自社サービスを継続利用してくれるかどうかを数値化したただの指標です。これをビジネスの意思決定に活用してもらうための「サービス」あるいは「プロダクト」と考え、「ヘルススコアダッシュボード」と名付けました。具体的には、あらためて自社のビジネス上の問題を設定した上で、
- 問題の解決のために重要な役割を担うペルソナを設定
- ペルソナごとに課題を設定
- ペルソナの課題を解決するための価値を設定
といった流れで、どのような価値・機能が必要かを決定していきます。
関係者をまとめチーム化する
また、PoCと大きく異なるのは、関係者の多様化です。一緒に開発してくれるエンジニアや、機械学習モデルをさらに磨いてくれるデータサイエンティストだけでなく、開発に協力してくれる社内ユーザ、事業責任者等を、同じ理想や目的に向かって協力しあえる仲間にするために工夫が必要でした。
特に、今回のヘルススコアダッシュボードは、経費申請システムのような、ユーザにとって「活用できないと不利益を被るから絶対に嫌だ」という類いのものではなかった分、当初は社内でも活用する必要性を感じづらいという声をもらっていました。
そこで「プロダクトを描く」で明確にしたペルソナにとっての価値を、それぞれのペルソナに話し、協働の約束を取り付けていきました。ヘルススコアダッシュボードを通して何を実現したいのかという理想について明確に共通認識をとり、高い熱量で一緒に取り組んでくださるよう工夫したつもりです。（社内ユーザであるビジネス部門の皆さんが本当に素敵な方で、とても助かりました…ありがとうございます。）
役に立った武器②：UXデザイン
（一見）なくても困らないものだからこそ、UXにもこだわりたいと思いました。プロダクトマネジメントと領域的な被りもあり、厳密に切り離せる話ではないのですが、実践してみたスキルを以下にまとめます。
ユーザーストーリー
検証に協力してもらうユーザとの対話を元にユーザーストーリーを列挙し、ブラッシュアップしていきました。
デジタルクロス「「無駄なものを作らない」がアジャイル開発の目的【第3回】」より
正直、今回のシステムのUIはダッシュボードのような想定なので、ユーザストーリの列挙に対しては最初は「やりすぎかな」と思っていたのですが、やってみると、「これまで活用したことがない指標を元にPDCAを回すことの苦労」を擬似的に感じることができ、
現在はここはまだまだ拘れるなと思っている部分で、さらなる改善を行っている最中です。
小さく磨き込むこと
ここまでで、理想のプロダクトにするための土台ができました。ここからは描いた理想に向けて、実際にプロダクトを磨き込むフェーズです。ここでの工夫は、完成形をいきなり全部作るのではなく、一部の部署の方々に、MVPを用いて機能の価値の確認と磨き込みにご協力いただくことでした。ここで十分に「使いにくいところ」や「このフローだと現場では回らないよ」などの意見を頂けたことで、全部署に展開しても大きな混乱にならないようにすることができたと思います。
最後に：必要だったのは役割をデータサイエンティストにとどめないこと
当初はデータサイエンスの力一本で勝負していて、特に上記2つはほぼ勉強も意識もしていなかったのですが、その頃はまさに「PoC死」しかけていました。開発したものを使ってもらえないことに落ち込んだこともありましたが、この二つのスキルを勉強したことで、しっかり価値をうみ、届けることができてきたと感じています。
こうして振り返ってみると、根本では自分の役割意識の変化が重要だったと思います。データサイエンティストとは、本来単なる「PoC屋さん」ではなく、「人間の力とデータの力を組み合わせ、問題の解決や願望の実現を行う人」なのではないかと感じています。そう思わせて下さったデータチームの仲間、そして、社内ユーザの皆さんに本当に感謝です。ありがとうございます。これからも全員で新たな文化を作っていきます。
最後まで読んでいただきありがとうございました。
