開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2019/09/05

PoCを乗り越えたAIプロジェクトが「本番開発」で失敗する理由

連載:AI失敗学

これまでの連載では、AIのPoCとITのシステム開発の違いについて述べてきた。PoCのあとにはシステム開発が待っていることを理解しなければAIプロジェクトを本当の意味で成功に導けるとは言いがたい。そこで今回は、PoCを乗り越えながらも、本番のシステム開発フェーズに入って失敗した例をもとに、AI導入という目標は同じであるものの、仕事の進め方が変わることを提示したい。

合同会社ハイロード・コンサルティング 坂井 尚行

合同会社ハイロード・コンサルティング 坂井 尚行

東京大学大学院 にて理論物理を学び、2006年 後期博士課程中退。2006年、金融フロント専門のIT企業、シンプレクス [当時上場]入社。2010年、インターネット広告代理店、オプト[当時上場] 。大手競合が6ヶ月かけたが未完の案件に携わり、システム・ 人間関係を2ヶ月で実装させる。2015年、パーソナル人工知能を活用するSENSYにて、「AI利き酒師」をエンジニアとして開発し、日経新聞にも掲載。2017年、学習型人工知能をBtoBに応用するSOINNにて、 上場企業を中心に、AI導入のコンサルティング業務を行う。2017年6月、Google DeepMind 同様、汎用人工知能の実現を目指す「ドワンゴ 人工知能研究所」より業務委託を開始。2018年、ペット保険会社にて、AI導入のコンサルティング業務を行う。2018年11月、自然言語処理の大手企業にて新組織立ち上げとAI導入のコンサルティングの行う業務委託を開始。

画像
AIプロジェクトはPoCを乗り越えても失敗するケースが後を絶たない
(Photo/Getty Images)

企業:Amazon Goの登場に危機意識を持った小売企業

関連記事
 小売業は歴史的にITと関係が深い。1970年代後半から1980年代にPOSレジシステムは急速に普及し、在庫管理、発注管理などと関係してきた。2000年以降はECによって消費者の行動を変化させた。

 最近ではさまざまなAIベンダーが小売向け AI ソリューションをそろえてきている。典型的なものとして、店内の顧客導線の可視化、不審者・万引きの検出、需要予測、商品棚の欠品の検知、店員のシフトの最適化などがある。

 今回取り上げるA社は小売業を営んでいる企業だ。店舗だけでなく、ECやデジタルマーケティングなど、テクノロジーの活用にも力を入れていることで知られている。近年ではオムニチャネルに早くから取り組んでいた。

 A社の経営層は2018年のAmazon Goの登場で危機意識を持った。EC最大手のアマゾンが実店舗のビジネスを手掛けることによって、産業構造が変化する可能性に気づいたのである。

 そこで自社が生き残るため、AIやIoTによる自動化が必要として「イノベーション推進室」を立ち上げ、複数のAIベンダーやIoTベンダーとPoCを実施していたのである。

概要:失敗したAI開発プロジェクトの概要

 その中の1つのAIプロジェクトで、企画の経験が豊富だったB氏が選ばれた。さらにAIベンダーには若く優秀なデータサイエンティストを多く抱えていることで知られているC社が選ばれた。担当者はデータ分析一本でやってきたD氏であった。

 PoCの報告会では、アルゴリズムの選定理由を上手に説明しており、精度を改善するのに粘り強く仮説検証のループを回していた。PoCは多少の山と谷があったものの、比較的スムーズに進み、好評を博した。

 続いて実際に活用するためにシステム開発のフェーズへと進んだ。A社では、これまでの企画から開発の流れの通り、情報システム部門(以下、情シス)に任せることになった。

 情シスからはE氏がアサインされた。SIer出身でプロジェクト管理の経験があった。B社の担当はD氏が継続した。D氏はデータサイエンティストではあるものの、システム開発は初めての経験だった。PoCから実運用に進むことはそれほど多くなかったが、D氏はA社との関係が良好だったためである。

画像
体制の変化

 システム開発のキックオフミーティングが開催された。以前からD氏は企画のC氏と利用目的を話していた。その話を前提に簡単なシステムの利用イメージと体制図と粗いスケジュールを提示した。

 その際、情シスのE氏は、主要な機能一覧、作業一覧、リスク一覧など、プロジェクト計画書でよくある項目について質問した。この点はD氏は利用イメージから推測して回答した。しかし、E氏が運用上起こりうる代替フローやリカバリー方法について質問したものの、D氏は「持ち帰り回答する」としか言えなかった。

 D氏はB社社内のPM(プロジェクトマネジメント)経験者に相談しながら仕事を進めた。E氏と相談しながら進めようとしたが、E氏はベンダー教育をするにはB社の単価が高すぎると思っていたため、協力を得られなかった。

 多くの会議でE氏からの質問を持ち帰ることが多かった。PoCでは「AIの先生」という立場を得たD氏だったが、システム開発では立場が逆転していった。E氏の意見が通りやすい状況になり、追加要望を受けざるを得なくなり、開発PJは当初の見積りよりも工数が膨らんでしまった。

問題の分析:いったい何が問題だったのか?

 上記プロジェクトの経緯を要約すると以下のようになる。

  1. PoCはつつがなく終了した
  2. 開発フェーズでAIベンダー側はシステム開発の経験がないD氏をアサインし続け、発注側はシステム開発経験が豊富なE氏が加わった
  3. システム開発でよく使われる論点についてE氏が質問したが、D氏は答えられなかった
  4. 専門家としての立場を失い、E氏の要望を受けることになった

 端的に言えば、D氏の知識と経験が不足していたことが原因なのだが、その背景にはAIのPoCとシステム開発の考え方の違いがあったと考えられる。

画像
AI PoC とシステム開発の相違

 これまでの連載では何度かPoCとそれを本番のシステム開発に適用する場合の違いを述べてきたが、今回は方針、品質のアプローチ、提出する文書の3点から考えてみよう。

【次ページ】よくある間違いとは?

AI・人工知能・機械学習 ジャンルのセミナー

AI・人工知能・機械学習 ジャンルのトピックス

AI・人工知能・機械学習 ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!