企業：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とシステム開発の考え方の違いがあったと考えられる。


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

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