ミスが許されない領域にAIを溶け込ませるプロダクトマネジメントの裏側
このnoteは、2024年12月5日にpmoconfで登壇させていただいた内容を再編したものです。
イベントの登壇テーマとしては、少し早くてニッチかもしれないと思ったのですが、登壇のスライドは本日時点で1万回以上見ていただいており、思いの外関心を持っていただけたのではないかと思っております。
登壇の動画もアップされておりますので、もし良ければご覧ください
概要
私がLayerXで開発に携わっているバックオフィスAI SaaS「バクラク」では、「AIによって業務自体をなくす」という信念の元、開発を行なっています。
これは、2040年までに約20%にもなる日本の労働受給ギャップを技術によって解決するためです。 一方、AI機能の開発は容易ではありません。生成AIを始めとする技術革新により、デモ開発までの速度は驚くほど向上しましたが、顧客が価値を感じられる機能に至るまでは大きなギャップが存在します。
例えば、バックオフィス業務はミスなく完遂することが求められる一方、AIの精度が100%にはなりません。この相性の悪さがバックオフィスにおけるAIの実装を阻んでおり、従来の機能開発とは異なる、AIならではの留意点を生んでいます。
本稿では、私たちがこれまで1万社以上の顧客にAIの力を届けるため、試行錯誤しながら実践してきた開発の裏側をご紹介します。
私たちLayerXがバクラク」というAI SaaSを開発・提供する理由
LayerXは「すべての経済活動を、デジタル化する」というミッションを掲げているのですが、この背景には、大きな社会課題があります。
それは、これから確実にやってくる日本の労働供給力と労働需要の大きなギャップです。
2040年には、1100万人分もの労働力が足りなくなることはほぼ確実となっています。なぜなら、16年後の日本人の労働人口は既に現在の出生数からほとんど確定的でありながら、海外からの大規模な労働力の確保ということは、日本の現状から考えるとあまり現実的ではありません。
既にいくつかの産業では人手不足が深刻化していますが、上記のグラフの通り、労働力不足はまだ始まったばかりで、これから急速に深刻化していきます。
この労働需給ギャップを埋めるためには、日本中で労働生産性を上げる以外、ほとんど解決策はありません。そして、20%というかなり高い生産性向上が必要となっています。
では、どのようにして労働生産性を上げるのか。私たちは、AIの力で「業務そのものを無くして生産性を上げる」こと、そして、そのAIの力を誰もが簡単に使えるようにすることと考え、、私たちは「バクラク」というAI SaaSを開発・提供しております。
では何故バックオフィス領域に向けたSaaSなのか。
一つはバックオフィス業務がない企業というのは存在しません。日本の労働生産性を上げる必要があると考えると、日本中の企業に必ず存在する業務の労働生産性を上げることは、ニッチな領域の労働生産性を上げるよりも、この課題に対しては有効です。
もう一つ、バックオフィス業務、非常に非常に大変です。
普段のお仕事の中で中々具体的な姿が見えにくいところもあるかと思いますが、バックオフィスに携わる方々は、多くの制約の中で複雑な業務をされています。そして、「ミスなくやり切る」ということが求められるので、非常に神経を使う仕事でもあります。
私たちは、こういったバックオフィス業務の手間や心理的な負担を無くしていこうと、バクラクを通じて様々なAI機能を提供してきました。
バックオフィス業務の中で、非常に多くのアナログな手間が発生します。こういった手間をAIにどんどん担ってもらおう、というのがバクラクでやっていることになります。
「ミスが許されない領域」でAIの力を活かすことの難しさ
バックオフィス業務 x AIとの難しさは、この大いなる矛盾にあります。
間違えられない業務と、精度が100%にはならないAI。
経理の方など、お金の処理は絶対に間違えないという気概で業務をされています。
間違えられないならルールベースでやれば？
そういった領域に向けてプロダクトを開発するならば、AIではなく、ルールベースで全部やれば良いじゃないかという考えもあります。
ただそれは、誤解を恐れずに言うと、無理があると思っています。
前述の通り、バックオフィス業務は複雑です。
対応しなくてはならないルールや法律が複雑で、業種・業態によっても業務は異なる。
個々の会社ごとの事情や考えによっても業務は異なる。
こういった複雑さに対してルールベースで対応しようとすると、無限にルールを増やしていくしかない。そうするとどうなるか。
システムがどんどん複雑化していって開発も大変になる、使う人もどんどん複雑になるシステムについていけなくなります。こういった複雑さを、一部システム化しながら人が頑張って吸収することで現在は業務が成り立っています。
しかし、いよいよ人の頑張りでは吸収しきれません。何故なら、人がどんどん減っていく、なのに労働需要は減らないからです。
この複雑さを吸収する、というのは、AIが持つものすごい特性の一つです。
人がこの複雑さを吸収しているが、ここをAIが引き受けてもらおう、ということを考えています。
さて、ルールベースだけでは無理だ、でも「間違えられない業務と、精度が100%にはならないAI」という、この大いなる矛盾をどう解決しようか、ということが課題になってきます。
この解決策の一つとなる、次に紹介するような考え方は、ご存知の方も多いかなと思います。
人だけではなく、AIだけでもなく
人とAIによって高い精度と生産性を両立させる
人も間違えます、AIも間違えます。
ただ、AIと人の掛け算が、色々なタスクにおいて、より精度が高く、生産性も高めることができます。この点については非常に多くの研究も実証もされてきています。
ですので、これを実際にどうプロダクトとして実現するのか、ということが私たちプロダクト開発に携わる人たちが考えることです。
プロダクトで具現化すること、概念としてはこのように考えてます。
もちろん最初から高い精度のAIを開発する、という前提の話ですが、それでもAIは間違う場合がある、なので、それを前提としたUIやUXをユーザーに提供する、ということが一つ。
もう一つは、AI機能は作ってリリースしたら完成、ということはありません。AIが間違った場合はそれをAIにフィードバックして、どんどん精度を上げていく、ということです。
具体例をバクラクのAI-OCRでご説明します。
AI-OCRは簡単に言うと、書類の内容、日付や金額や支払先といった情報をAIが読み取って、システムに自動的に入力してくれるという機能です。
例えば請求書は、その処理にミスが許されない書類の一つです
この請求書というのは、実はフォーマットがかなり自由、同じような値がたくさん入ってたりします。
例えば「金額」一つとっても、合計金額、明細ごとの金額、税抜金額、税込金額とたくさんあります。
この中から、この請求書を処理しようとしている人が必要な金額だけをピンポイントで選択しなければいけません。
その難しいことを人間は自然にやってるのですが、AIにとっては非常に高度な処理となります。
この課題を、バクラクのAI-OCRはどう解決してるか。
詳細は、先日出させていただいた、こちらのリリース文を参照していただきたいのですが、簡単に説明させていただきますと、
まず、請求書にあるたくさんの情報をAIが読み取って意味を理解します。これは合計金額、これは明細の金額、これは税込金額という形で候補を作ります。
この候補の中から、今この人が必要な情報はこれだなと推薦します。
それがあっていれば、ユーザーは何もする必要がありません。
間違ってる場合は、ユーザーが候補の中から別の情報を選択するので、AIがそれを学習して、精度を上げることができます。
AIが自動的に入力してくれるため、書類を見ながら人が入力しなくて良い。
自動で入力された値が間違っていても、修正の手間が非常に低い。
修正されたことをAIが学習し、次回以降より高い精度で自動入力することができる。
精度を上げるための特別な作業をユーザーが何かやるのではなく、普通にプロダクトを使用している中で精度を自然と上げていくことができる。
このループをプロダクトで実現することが、「ミスが許されない領域にAIを溶け込ませる」の具体化ということになります。
プロダクトマネージャーとしての過ちや悩みなど
ここまでは、バクラクでやっているAIプロダクト開発の事例をご紹介してきました。
LayerXは、AIに関して非常に多くの知見、経験がある組織です。そんな環境に身を置いていると、正しい方法でスムーズに開発できそうと思っていただけるかと思います。
ですが私個人としては、めちゃくちゃ悩みながら、やりがちな失敗をやってしまったりしながら、プロダクト開発をしています。
ここから少し、私自身が関わった実例を織り交ぜながら、アンチパターンを共有したいと思います。
何からやったらいいか分からない
AIを前提に考える理由については前述の通り明確なのですが、「実際何やる？」となった時にめちゃくちゃ悩みます。
A
Iのポテンシャルがあり過ぎる故に、結局今何をやると一番良いの？がよく分からなくなったり、やることをどう決めたらいいの？が分からなくなったりして、悩んでるだけでどんどん時間が過ぎていってしまった時期がありました。
この問題の解決策ですが、やることを決めるためには軸が必要で、欠かせないものが、プロダクトビジョンだと思います。
バクラクの場合だと「AIで業務を無くす」というものがあるので、じゃあ具体どんな業務をどう無くしていけば良いのかという考えの軸は定めることができます。
動くものとリリースできるものは違う
これは、ポイントが二つあります。
一つ目のポイント：精度と基準
本当に現在のAIは性能がすごいので、あるシチュエーションにおいて理想的な動きをするものというのは、めちゃくちゃ早く実装してミニマムな検証がすぐにできます。
ただ、通常のプログラムとAIの違いとして、通常のプログラムは、作った通りに動きます。
AIはそうではありません。前述の通り、精度100%になりません。
では、精度がどこまでいったらリリースして良いのでしょうか。そもそもその基準はどうやって決めれば良いのでしょうか。
基準がなければリリース後の改善もやれません。
二つ目のポイント：体験設計
業務に即した体験設計の作り込みはとても大事です。
裏でどれだけ賢いAIが動いていても、プロダクトの体験が全然業務に即してなかったり、使いづらかったりするものはリリースできません。
こういうことができそうだね、ということが分かるまでの時間は非常に短時間で可能になりましたが、本当にプロダクトとして提供できるようにするまでの時間は、従来のプロダクト開発より長いと思います。
なので、それをちゃんと開発計画には織り込む必要があります。それがない場合、ある時から「全然進んでない」「根本から考え直さないといけないのでは」といった負のループに嵌ります。
そこにデータはあるんか？
これは冷静に考えると「それはそうでしょう」なのですが、「この企画は良さそうだ！」とテンション上がって検討進めている時に、データの必要性を置き去りにしがちです。
これから溜めていかないと、データ存在しないのに、最初から十分なデータが溜まってる前提でUXを考えてしまう、とかはやりがちなパターンです。
もちろん「データがないからやらない」だと、これから始めるプロダクトでは、できることが無くなります。
なので、データがない段階でどういう体験を提供しながらデータを溜めていけばよいのかまで考えているかや、正しいデータを作っていくことまで覚悟を持って体制を作るとか、そういったっことが必要です。
特に私は「体制を１から作る」は大切かつ難易度高いと思っています。
精度改善を見越していない
これは、データの話と重なるところもあります。
AIにおける精度改善の重要さは、事例紹介で書かせていただいた通りなのですが、にも関わらず、精度改善を見越さないまま作ることだけを考えてしまうのはアンチパターンです。
AI系のプロダクト・機能は改善こそが肝になることが多く、データで学習しながら常に精度を改善していく試行錯誤が続きます。
一方で、何かの機能開発をしてリリースした後には、必ず「次はこれをやろう」となります。
じゃあ、改善は誰がやるねん・・・
自動的に改善できる仕組みが作れているか、改善する体制も見越しているか、そういったことまで初期から考えてないと、リリースした後で大変なことになります。
既存機能開発と並列すると優先度難しい。
次も体制作りの話です。
バクラクは基本プロダクトごとにチームを分けて開発しています。
同じチーム内で、お客様の顕在化した課題を解決する開発をしながら、潜在的な課題をAIで解決する開発の検討を並行することは、非常に難しいです。
顕在化した課題の重要さが明確な中で、潜在的な課題へのリソースの割き方に悩み続けることになるからです。
また、同じチームでやろうとすると、既存機能の延長線で考えてしまうということもより起こりやすくなります。
さらに、先ほどの改善のところでは話したように、開発したいものは次々とあるので、手離れの良い機能を開発したいバイアスがかかりやすくもなります。
なので私たちは、私も所属してるAI-UXを開発するチームを分けて作り、既存のプロダクトごとの開発チームとは連携しながらも別で動くという形を取っています。
この辺のチーム作りの最適解というのは、タイミングによっても変わってくると思いますので、中々うまく進まない場合は、体制・チームの役割から見直すと良いでしょう。
企画と開発を分ける
「何を作るか探索して決めるのはPdM」はAIプロダクトの開発においてはアンチパターンだったなと思います。
AIプロダクトの開発というのは、
お客様の課題を知ること
ドメイン特有の課題を知ること
AIだから解けるかつ重要な課題を特定すること
そしてAIの力を正しく理解した上で、どう作るかを考えること
何をどう作るかということを同時並行的に考えながら、この辺のことが渾然一体で進んでいきます。
最初、私は一人で色々考えたり、検証してたりしたけど全然進みませんでした。
今は、機械学習エンジニア、ソフトウェアエンジニアと一緒に、多くのヒアリングをしながら課題の見つけにいったり、どう解決しようかということを一緒に考えながら進めています。
他にもたくさんあるのですが、ここでまとめたいと思います。
左側、こういう悩みを今も持ったり、アンチパターンを実際に踏んだりしてきました。
そして、それを経てやったことが右側です。
まずドメイン理解。
結局何をやるべきかを、エンジニアと一緒になって、ドメインにディープダイブ、そこで仕事をしている人にディープダイブして考えるということ。
そしてチーム作り。
やるべきことを、良い形でプロダクトにして、なおかつどんどん良いものにしていけるようなチーム作りです。
最後に
最後に少しだけ、このAI時代における難しさやプロダクトマネージャーとしてのやりがいなど、私の想いのようなものを話させていただきましたが、noteでは割愛させていただきます。
もし、最後まで内容を・・・という奇特な方は、上に貼ったYoutubeをご覧いただけますと甚だ幸いです。
最後までご覧いただきましてありがとうございます。
もし、今回noteに書いたような内容に興味がある方がいらっしゃいましたら、ぜひお話ししましょう。
こちらもぜひ、併せてご覧ください。