#WiDS2021 #WiDSTokyoIBM DATA SCIENTIST TALK#2 データサイエンス系プロジェクトにおける構想策定の重要性 2021/06/04

本セッションのSNS投稿について SNS投稿: 一部OK OK: テキストによる文字のみの投稿 NG: スクリーンショットの画像/動画を含んだ投稿 ハッシュタグ: #WiDS2021 #WiDSTokyoIBM

Agenda 1. 自己紹介 2. ご存じでしたか…? 3. 構想策定とは何ぞや 4. 構想策定で失敗は防げる! 5. 妄想ケーススタディ

!注意!  本発表では、データサイエンス系（AI系）プロジェクトにおける構想策定についてお話します （打ち手として、データサイエンス/AIを活用したPoCを後段で行うことを前提とした話です）  業務改革・組織改革を含む広い意味での構想策定ではありませんので、ご注意ください! （それはそれでものすごく深い話です）  データサイエンス系の構想策定は比較的新しい話で、常にアップデートされています。 これが定石、というわけではありません。こんな話もあるよ、的に気楽に聞いてください。

Agenda 1. 自己紹介 2. ご存じでしたか…? 3. 構想策定とは何ぞや 4. 構想策定で失敗は防げる! 5. 妄想ケーススタディ

Agenda 1. 自己紹介 2. ご存じでしたか…? 3. 構想策定とは何ぞや 4. 構想策定で失敗は防げる! 5. 妄想ケーススタディ

2.ご存じでしたか…? ～3割のAIプロジェクトは失敗すると言われている 3% 31% 36% 19% 6% 3% 0% 1-9% 10-29% 30-49% 50% or more Don’t know N = 1910; Base=Personas 2 and 3 respondents Source: IDC AI StrategiesView, March 2020

2.ご存じでしたか…? ～その理由は概ね”構想策定の不備” 31% 34% 29% 29% 30% 35% 27% 28% 28% 29% 0% Unrealistic expectations Lacked staff with necessary expertise Did not have the necessary data Lack of production ready data pipelines for diverse data sources Lack of an Integrated Development environment from experimentation to production AI technology didn't perform as expected or as promised Results that were too disruptive to current business processes Output that wasn't actionable Lack of follow-up from the business units The business case wasn't well-enough understood Other (please specify) Don't know AIに期待しすぎた データサイエンティスト不足 データが足りなかった データソースが確保できなかった PoCからproductionまで使える分析環境が準備できてなかった 検討した手法で成果が出なかった 業務に組み込めなかった モデルの結果をアクションに落とし込めなかった 事業部からの支援を受けられなかった ビジネスケースをうまいこと作れなかった その他 ﾜｶﾗﾝ N = 1791; Base=Respondents indicated organization's AI projects have failed Source: IDC AI StrategiesView, March 2020

2.ご存じでしたか…? ～プロジェクトが失敗するとどうなるのか? プロジェクトが失敗すると、それまでかけてきたコスト（工数、分析環境コスト等）が水の泡になるだけではなく、プロジェクト要員の疲弊・モ チベーション低下等様々な影響が出ます。多産多死ありきですすめるべきではありません。 要員の疲弊・モチベーション低下 コストが水の泡… PoCは多産多死 だから失敗しても 当然だよね? なぜか多産多死ありき

Agenda 1. 自己紹介 2. ご存じでしたか…? 3. 構想策定とは何ぞや 4. 構想策定で失敗は防げる! 5. 妄想ケーススタディ

3.構想策定とは何ぞや ～構想策定の位置づけ 構想策定とは、PoCの前段階のフェーズで、PoCの計画を立てる作業のことをいいます。 経営の理解とコミットメント 「投資対効果は出るか?」 現場の納得・協力 「現場で負荷なく使えるのか?」 データ・テクノロジー 「実現できるのか?」 構想策定 実現性検証 (PoC) 段階的構築・受入 効果検証 業務検証 本番運用 展開 検討すべき ポイント

3.構想策定とは何ぞや ～構想策定はだれがやるべきか 従来、構想策定は戦略コンサルか業務コンサルの仕事とされてきました。しかし、PoCのタスクが複雑化している現状では、データサイエン ティストが構想策定から参画すべきと考えます 構想策定 実現性検証 (PoC) 段階的構築・受入 効果検証 業務検証 本番運用 展開 従来の 役割分担 （ざっくり） 私の主張 戦コン・業コン データサイエンティスト システムエンジニア 戦コン・業コン データサイエンティスト システムエンジニア

3.構想策定とは何ぞや ～構想策定の中身 下記のプロセスで実際の構想策定をすすめます 実行計画策定・ トライアル 打ち手の検討 打ち手の評価 現状把握・データ調査 現状、どんな課題があるのか 対象となる設備・業務は何か データはどこに存在するのか データはモデル作成に十分な データか 優先順位が高い課題は何か それぞれの課題に対してどのよ うな打ち手が考えられるか （i.e.どのようなアルゴリズムが 適用できるのか） どの程度ビジネス効果が見込 めるか 現状の技術で、どの程度実 現可能性が見込めるか 業務に組み込みは可能か PoCを実施対象を検討する PoCの計画案をつくる 構想策定 ビジネス効果:5億円/年 実現可能性:高 〇 ビジネス効果:0.1億円/年 実現可能性:高 × ビジネス効果:50億円/年 実現可能性:現状低い × ?

3.構想策定とは何ぞや ～データサイエンティストこそ、構想策定を AIプロジェクトでは構想策定フェーズのタスクのうち半分以上がデータサイエンスの知見が必要です 実行計画策定・ トライアル 打ち手の検討 打ち手の評価 現状把握・データ調査 現状、どんな課題があるのか 対象となる設備・業務は何か データはどこに存在するのか データはモデル作成に十分な データか 優先順位が高い課題は何か それぞれの課題に対してどの ような打ち手が考えられるか （i.e.どのようなアルゴリズム が適用できるのか） どの程度ビジネス効果が見込 めるか 現状の技術で、どの程度実 現可能性が見込めるか 業務に組み込みは可能か PoCを実施対象を検討する PoCの計画案をつくる ビジネス効果:5億円/年 実現可能性:高 〇 ビジネス効果:0.1億円/年 実現可能性:高 × ビジネス効果:50億円/年 実現可能性:現状低い × ? 構想策定

Agenda 1. 自己紹介 2. ご存じでしたか…? 3. 構想策定とは何ぞや 4. 構想策定で失敗は防げる! 5. 妄想ケーススタディ

4.構想策定で失敗は防げる! ～よくある失敗例 AIプロジェクトでよくある失敗例は下記の通りです。これらは、構想策定を十分にやりきれば防げる失敗です データサイエンティ ストがいないんだ もん!50人イケ イケのデータサイエ ンティストさえいれ ば! その50人、本当に必要ですか。 本当に97%じゃないと失敗ですか。 （なんで97%なんですか?） 精度82%って失 敗じゃない? 97%はないと厳し いよね? データが足りな かった。。。 PoCの前段階でデータが十分か どうか確認しましょう ケースその① データ不足 ケースその② データサイエンティスト不足 ケースその③ 精度が期待値未達

4.構想策定で失敗は防げる! ～ケースその①:データ不足 PoCになってはじめてデータを触るというのでは遅すぎます。構想策定の段階で、データを確認して目星をつけておくべきです データが足りな かった。。。 ここでデータは確認しましょう プレ分析として、軽い分析をするのもgood!

データサイエンティ ストがいないんだ もん!50人イケ イケのデータサイエ ンティストさえいれ ば! 4.構想策定で失敗は防げる! ～ケースその②:データサイエンティスト不足 人のアサインはプロジェクト成否を左右する重要な要因です。構想策定で検討して、実現不可能な計画にならないようにしましょう 打ち手に優先順位・評価をきちんとつけましょう （どうしても人数必要なら）教育・採用も計画に盛り込みましょう

精度82%って失 敗じゃない? 97%はないと厳し いよね? 4.構想策定で失敗は防げる! ～ケースその③:精度が期待値未達 その業務に、どの程度の精度が必要とされているのかを構想策定段階で見極めておきましょう どの程度の精度で、どの程度ビジネス効果見込みがあるのか検証して PoC前にコンセンサスをとっておきましょう

Agenda 1. 自己紹介 2. ご存じでしたか…? 3. 構想策定とは何ぞや 4. 構想策定で失敗は防げる! 5. 妄想ケーススタディ

データがそもそもど のテーブルにあるの かも、各項目の意 味もわからない 5.妄想ケーススタディ ～株式会社 ほっこりネットワークの例 下記のようなケーススタディを考えてみましょう IT系だし、データちゃんと 整備されていると思ったん だけど。。  株式会社 ほっこりネットワークはIT黎明期から活動し ている古参の情報通信企業である  もともとネットワーク事業単体だったが、合併等を繰り返 して法人向け＆コンシューマ向け各種サービス等、多 数の事業を抱えるようになった  現在、ほっこりネットワーク社内では大規模予算のもと AI活用を進めているが、不振のネットワーク事業につい てまずテコ入れが求められている ⇒社内のデータを活用して離反予測モデルを構築したい もうPoC開始しちゃったん だけど、ぜんぜんデータ加 工が終わらないってベンダ ーが言ってる。。 ネットワーク事業担当の声 ケーススタディ

5.妄想ケーススタディ ～株式会社 ほっこりネットワークの例 PoCの前に、下記の観点をチェックしてPoCに足るデータかどうか確認する必要があります 一旦データがそ ろうまでPoC 開始は待とう データサイエンティストによる データ確認・プレ分析 データを持つ部署とのネゴ・ データ担当者のアサイン確認 データ加工・分析 環境の確保 データの事前チェックをデータ担当者とデータサイエンティストが連携しながら実施することが重要です え、加工?どう みても2か月か かるんじゃない すか この＊＊フラグが合併で仕様 が変わっているのが致命的だ から20XX年以降のデータを 使うしかないですよね。この部 署マスターの値が20YY以降 で変わってるんですけど、え、 前後の変換マスタがどこにある かわからない?そりゃまいったな すぐ探してくださいよそもそも 顧客情報はTable X、売り上げ情 報はTable Yに入ってます。注意と してはTable Xは20XX以降は Table X’になっているので売り上げ 情報の期間を見てXかX’に紐づけま す。ちなみにYの売上合計粒度が 20YY年に代わっていて、20YY以 前は事業本部単位、以降は営業 部単位になっているので部署マスタ を期間に分けて紐づける必要があり ますねちなみにどういう粒度で集計し ますか、え、きまってない?そもそも 必要なソフトウェ ア・環境等はデー タサイエンティスト にチェックさせる

50か所それぞれに データサイエンティ ストを置くのよ 5.妄想ケーススタディ ～株式会社 ニコニコインシュアランスの例 下記のようなケーススタディを考えてみましょう 今年度中に成果を出さ ないといけないから、全営 業所でPoCをやるわ  株式会社 ニコニコインシュアランスは中堅の保険会社 である  全国50か所に営業支店があり、それぞれでAI活用を すすめたいと考えている  ニコニコインシュアランスのDX担当は、トップからの指令 を受けてDX推進を進めており、本年度中に成果を出 すことを求められている ⇒DX推進のため、データサイエンティストを追加すること を検討している 50か所それぞれで、モデ ルを作りこむんだからそれ だけデータサイエンティスト 必要でしょ? DX担当の声 ケーススタディ

5.妄想ケーススタディ ～株式会社 ニコニコインシュアランスの例 データサイエンティストを多数かかえずとも成果を出す方法はあります まずは5人ででき るところやって成 果を出そうかしら “成果”の再定義 今期中に 成果を… 成果とは 何ぞや? モデル・基盤共通化（コンテナ化） 優先順位付け・絞り込み 離反率 まずはここだけ注力 （パレートの法則） そのほか、段階的PoC実施、AutoML系ツールの導入等、検討すべきポイントはたくさんあります

AIは高いんだし、 高い精度出しても らわないと。97% とかね? 5.妄想ケーススタディ ～株式会社 お弁当太郎の例 下記のようなケーススタディを考えてみましょう とりあえず御贔屓さんに 松コースをすすめてるんだ けど、厳しいんだよね。。 10社に1社ぐらいかな。。 営業担当は数名しかい ないから、アタックできるの は月に100件が限界か な。。 営業担当の声  株式会社 お弁当太郎では、B2B（企業向け）に 弁当の定期購入サービスを提供している  お弁当プランには松コース、竹コース、梅コースがある  営業担当は、プランをアップグレードしてくれそうなお客さ んに対し、営業をかけているが、担当が数名のため、ア タックできる客数には限界がある ⇒営業業務を効率化するために、機械学習で アップグレードしてくれる客の予測を行いたい ケーススタディ

5.妄想ケーススタディ ～株式会社 お弁当太郎の例 実際の業務（ここでは営業可能な件数）を踏まえると、効果を十分に訴求できるケースがある ID 氏名 … 確率 00001 中山出版株式会社 95% 00002 YAMAHATA株式会社 95% 00003 株式会社四崎商事 90% … 00100 Inoue & Co. 85% … 00500 高柳運送株式会社 70% 今までの業務の 9倍効率的!  アップグレード確率が70%以上の場合アップグレードする と仮定  顧客500件のうち410件が実際にアップグレード ⇒精度82% ID 氏名 … 確率 00001 中山出版株式会社 95% 00002 YAMAHATA株式会社 95% 00003 株式会社四崎商事 90% … 00100 Inoue & Co. 85% 精度82%って 失敗じゃない?  アタックできる件数の最大の100件に絞り込み  100件のうち95件が実際にアップグレード ⇒精度95% 件数 絞り込み

【参考】必要な精度とは? 必要な精度は、現状の業務要件によってケースバイケースで決まることが多い 現状、担当者が目視で行う検査 を画像検査で代用したい 後工程で検査する工程がなく、こ この検査に欠陥があると不良品 流出してしまう 担当者以上の精度が求められる （9X%等） 検査担当者が離任することが決ま っており、現状目視で行う検査を 画像検査で代用したい 後工程でもチェックはできるが、工 数に限りがあるので明らかな不良 は検知したい 精度は相談できるかもしれない… ケース ① ケース ②

さいごに ～Do’s and Don’ts 失敗から学びましょう 構想策定をコンサル任せにするのはやめましょう。「PoCから」参画するのは避けましょう 「ラクをするため」の技術・説得のテクニックを積極的に取り込みましょう

ご清聴ありがとうございました! #WiDS2021 #WiDSTokyoIBM