そして4つめが、WhatもHowも同時に揺れる型です。AIプロジェクトの多くは、ここに属します。生成AIをはじめ、近年大きな変革をもたらしているAIは、ディープラーニングによって大量のデータから傾向を学習し、最ももっともらしい答えを確率的に予測します。そのため入力データのわずかな違いで出力が変わり、統計的なエラーも必ず混ざる。設計図通りに作れば100%思い通りに動くということが、構造上成り立ちません。
プロジェクトの初期段階でWhatが仮説レベルにとどまるのは、アジャイル型が効く左上の象限と同じです。異なるのは、その仮説に対してHowが、技術特性上やってみなければ分からないという点にあります。従来ならすぐ開発に移れたものが、まず検証の段階を踏む必要がある。
さらに厄介なのは、その検証の結果によってWhatが書き換わってしまう事態があり得ることです。精度95%の異常検知システムを目標にしていたところ、検証してみたら85%しか出なかった。このとき「開発を続けるか、失敗と見なして中止するか」の2択に落ちてしまうのは、Whatは動かないものだという前提に立っているからです。本来そこで立てるべき問いは、「85%の精度でも回る業務プロセスは設計できないか」でした。
揺れをなくすのではなく、管理可能にする
WhatとHowが同時に揺れるなら、その揺れを前提にした進め方が要ります。本書ではこれを振動型マネジメントと呼んでいます。
振動とは、WhatとHowのそれぞれについて、探索や検討の過程で思考が行ったり来たりすることです。最初は様々な可能性が考えられて大きく揺れたとしても、適切に管理できれば、それぞれの観点を何度も往復しながら少しずつ振れ幅が小さくなり、やがて着地点が見つかる。目指すのは揺れをなくすことではなく、揺れを管理可能なものに変えることです。
実践できなかった場合の失敗パターンは2つあります。
ひとつは発散です。WhatもHowも自由に揺らしすぎて、どこにも収束しなくなる状態を指します。壮大なビジョンが掲げられ、技術的選択肢もビジネス的選択肢も際限なく広がっていく。いろいろ試してはいるが、どこへ向かっているのか分からない。終わりがなく資料の山だけが積み上がるPoC地獄は、たいていこのパターンです。
もうひとつは固着です。WhatかHowのどちらかを早い段階で固定しすぎて、本来あり得たはずの方向転換の可能性を自ら潰してしまう。精度95%のモデルを作ると決め打ちしたために、85%でも十分に回る業務プロセスへの道が閉ざされてしまうのは、まさにこれにあたります。この業務を完全自動化すると実現可能性の低いゴールを決め打ちし、人とAIの役割分担で十分に価値が出るはずの設計が見えなくなるケースも同じです。
理想的なAIプロジェクトは、発散と固着のあいだにあります。自由すぎてもダメ、固定しすぎてもダメなのです。だからこそ、どこまで揺らし、どこを固定するのかを設計することが要になります。
※ログイン後、コメント入力が可能です。