情報銀行の台頭に危機感を持ったネット銀行

　A社は、巨大資本を持つBグループの傘下のネット専業銀行だ。Bグループの本業は金融ではないため、優秀な人材を他社から引き抜いて、A社の経営を任せた。巨大グループの中にあってもA社は、独自戦略を自由に打ち出せる立場だった。

　こうした立場を生かしたA社は、2000年代には預金商品だけでなく、さまざまな商品やサービスを提供してきた。ビジネス的視点だけでなく、新技術にも精通したメンバーがいたため、コアな機能は自前で実装できる強みを持っていたのである。

　A社の経営陣は近年、強い危機感を持っていた。さまざまな巨大IT企業が決済機能を持ち、その情報を活用する「情報銀行」を目指しているからだ。A社はデータ活用によるサービスの提供を重要プロジェクトと位置づけ、施策を練った。しかし、2000年代に構築したシステムはレガシー化し、機能を追加しようにも期待されるようなスピードで開発できていない。IT部門は発言力を失いはじめていた。

　そのような中、CIOの肝煎りで「AIプロジェクト」がスタートする。A社の顧客で「口座は持っているが株や債券、NISAなどの商品を購入している」のは20％程度だ。AIプロジェクトが成功すれば、クロスセルによる客単価の向上が期待できた。銀行口座の入出金履歴から、他の金融商品／サービスをレコマンドしようという戦略である。

　プロジェクトの責任者にはC氏が就任した。C氏は複数のAI企業にコンタクトすると同時に、レコマンドサービス（技術）を提供する企業にも声をかけて情報を収集した。その結果、技術力が高いと評判のD社を選定した。

　D社の担当者であるE氏からは「弊社は技術力に自信があるが、プロジェクト管理はそれほど得意ではない」と“予防線”を張られたが、C氏はプロジェクト管理に自信があったので、問題なしとした。そのうえで以下の取り決めを行った。

1. 3カ月を一区切りとしてサイクルを回すことが多いため、アジャイルプロジェクト管理とする。
2. アジャイルプロジェクト管理に際してはタスクを洗い出し、定期的にイテレーション（反復型開発）タスクのスコープと進捗を管理する。

　最初の中間報告では、データ分析の結果が報告された。月間の入出金の総額や回数から（子供の進学や結婚などの）ライフイベントが割り出せるのではといった仮説だ。中間報告にはAの業務担当からも好意的なフィードバックを得られたためC氏はタスクを決め、E氏と相談してデータ分析の優先順位を決定した。

「やってみなきゃわからない」にイライラ

　1回目のイテレーションの最終報告では、「タスクは想定どおりに実施されたが、AIのアルゴリズムを適用した結果は芳しくない」だった。C氏は「タスクを実行したが、想定より精度がよくないのはなぜか」と聞いたところ、「やってみないとわからないから検証した。この時点で性能を問うのは早すぎる」とE氏から返された。そのためC氏は2回目のイテレーション前に「得られたタスクをより細かく分解してほしい。タスクの粒度を細かくすることで、プロジェクトの精度を向上させたい」と要望を出した。

　しかし、2回目の中間報告でも精度は若干向上しただけで、成果は芳しいものではなかった。ここらへんでC氏はイライラする。1回目の最終報告時と同様に「タスクを実行したが、想定より精度がよくないのはなぜか」と聞いたところ、「やってみないとわからないから検証した。タスクの内容には合意したはずだ」とE氏から返された。そのためC氏はマイクロマネジメントを進めようとしたが、E氏は「会社間でマイクロマネジメントはやりすぎだ」と反対された。

　次第にC氏とE氏は対立を深めるようになっていった。5回目のPoC（実証実験）の結果は、業務担当者が納得したが、C氏は導入前に実地検証を半年間行うことを強固に主張した。結局、AはD社に発注せず、別の会社に発注したのである。

AIプロジェクトの不確実性が理解できない

　一体、上記のケースは何が問題だったのか。整理すると以下のようになる。

1. イテレーションを設定した
2. タスクを管理してスコープの調整をした
3. 結果が芳しくなかった
4. マイクロマネジメントをしようとした

　1と2はよいだろう。問題は3と4だ。専門外の分野で思うような結果が得られないとき、その原因を探るのは難しい。特にAIのPoCプロジェクトは「やってみないとわからない」ため、アジャイルなプロジェクト管理を採用することが多い。

　たとえば、アジャイル開発の1つであてるスクラム開発は、要望をプロダクトバックログとして、開発タスクをスプリントバックログとして管理する。ビジネス側の要求に対しては、一定期間内で実行可能な計画を、スプリント計画ミーティングですり合わせるという手法をとる。


　ただし、これは通常のソフトウェア開発を前提にしているものだ。ビジネス側の不確実性は、ユーザーやマーケットのニーズに由来する。一方、テクノロジー側の不確実性は、作業工数の見積りが難しいことと、作業ミスに由来する。さらにAIのPoCプロジェクトには、テクノロジー側に新たな不確実性が混入する。

　たとえば、AIの場合、データの傾向と分布はどのようになっているかわからないし、どの項目が精度向上に効くかわからない。データを増やせば精度が上がるとも限らないし、アルゴリズムの選定は一筋縄ではいかない。複数のアルゴリズムを組み合わせて使うこともあれば、「エンド ツー エンド」で一気通貫するものを使うこともある。アルゴリズムを選定した後はパラメータのチューニングが必要である。つまり、複数の“打ち手”があり、何が“ヒット”するかわからないのだ。

　そのような状況でAIの導入は、問題を要素に分解し、実験計画を立てて実行し、定期的に計画を見直すことが求められる。最初に仮説を立てられない場合は、データを見て情報を収集することから始める。そしてその仮説はリスト化するだけでなく、見落としがないように体系化しなければならない。勘と興味で実行するのではなく、問題を切り分けられるところや重要なところから実行する必要がある。

　もちろん、利用可能か判断する成果指標として精度も重要だ。途中の過程を評価できなくては、プロジェクトがうまくいっているかどうかわからない。仮説のスジが悪いのか、顧客のデータ収集が遅いのか、担当者の作業効率が悪いのか、公平に判断できる軸が必要だ。AIのPoCプロジェクトで管理する対象はタスクだけでなく、仮説もまた重要なのである。

【次ページ】90年代に学ぶ「変化」と「プロジェクト管理」