ビジネスと生成AI
生成AIの話というと、まずはOpenAIなりBedrockなりの技術名やどう使うかのプロンプトの話が先に出てきて、その後のビジネスの話ってあまり出ないですよね。一方で私は立場柄？職種柄？新しく出てきた技術に対しては、どう組み合わせてビジネスに仕立てるかのお話の方に興味があり、生成AIってどう稼ぐことにつなげられるかなーと考えながら日々生活しております。
今回はAWSの生成AIであるBedrockを題材としたプロダクト開発にプロダクトオーナーとして従事しましたので、生成AIという技術とどう向き合い、どうプロダクトとして仕上げていったのか、ある意味貴重？な企画観点からの考え方をまとめてみようと思います。
ちなみに、今回の開発内容はAWSサミットにてKDDIブースで軽ーーーく紹介されておりますので、興味がある方はこちらも見ていただければ幸いです。
どんなの作ったの
ソリューション営業担当が営業活動で利活用する想定のツールとしての、コンセプト～試作までのPoC開発。具体的には、以下のものを作りました。
- Teams等の会議音声データから文字書き起こし、議事録生成機能
- 入力された課題を元に、次なる打ち手を考える、提案骨子生成機
企画初期状態
本件立ち上げは上層からチーム編成、ざっくり課題、スケジュール感が降りてきた感じでした。
チーム編成
プロダクトオーナー1名、開発3名、UXデザイナー2名で構成。メンバー同士はほぼ初顔合わせでした。
当初課題設定
テーマとして、「生成AIを活用した」「ソリューション営業」における「提案力強化・改善」。
当初のサービス具体イメージとしては、数あるソリューション商材の中からお客様の課題解決に合致した適切なサービス候補を選定したり、サービス料金・利用条件といった確認事項を自動で取得する、といった機能を期待されてました。
スケジュール
2024年4～6月をPoC開発・評価期間に設定。7月以降、開発継続の見極めやプレスリリースを目指すという、比較的リーン開発チックな計画です。
当初POとして考えたこと、感じたこと
生成AI技術への理解不足＆現場課題理解不足なアンチパターン？
私もそこまで生成AIに明るいわけではないですが、大きく疑問だったのがアウトプットイメージそのものでした。これは営業現場ヒアリングを集約するとこうなるのは企画屋としてある程度理解しますが、さてこれができたとき本当に現場の人は使ってくれるのだろうか？と。
まず、生成AI技術は「正解を出すツール」ではないと理解しています。なので、そもそも適切なサービス候補選定に使うのが用途としてあっているか疑問でしたし、それもあって結果を鵜呑みにして営業がそのままお客様に提案する状況を作るのは避けないといけないな、逆にせっかく作ったプロダクトが精度懸念で使えないと評価されてもいけないな、と思ってました。
そして、現場の営業担当は、適切なサービス選定や確認事項取得をどこまで生成AIに任せたいと考えているのか。こちらは若干ひっかかりを感じたくらいでしたが、この疑問を持っておくことが、後のプロダクトビジョンを定める上で重要になったと思います。
そもそも生成AIってどこまで期待していいのだろうか？
本PJは、まず生成AI、とくにBedrockありき、というあまりよろしくない制約含みで企画がスタートしました。少し背景情報の補足ですが、我々KDDIアジャイル開発センターとしては近年生成AI活用に力点を置いていることもあり、他生成AI技術含めて、AWS Bedrockにおいても開発知見・技術力を持って置きたいという狙いがあり、本PJではBedrockを使っていることを押し出せるプロダクトを開発する、という裏制約が含まれていました。
生成AIはたしかに素晴らしい技術だし、今後世の中を変革していく中心技術です。ただ、それを過信するには少なくとも今は早すぎるし、なんでもこの技術で解決できる、というものでもないと思います。当初はそんな背景をもとに、どちらかといえばネガティブに、ある程度生成AIは使っていることを示しつつ、最悪営業DXの文脈で説明したり、UXや今後のイメージ部分をうまく膨らませて生成AI外で飾っていく必要があるのかも、と考えていました。
結論から言えば、今回はいい意味で予想を裏切られ、生成AIの技術の高まりに驚かされることになります。一方で、この当初の構想で考えていた生成AI外を含めてのプロダクト構想は、現生成AIの弱点を補うかたちで効果を発揮できるプロダクトに仕上げられたと自負しております。
チャットボットは作りたくないな
現状の生成AI＝チャットボットのアレ、という固定観念はあまり好きじゃなかったので、ここは変えてやりたいなと野心を持ってました。だって正直、他人とのやり取りでも辟易とするのに自分の領域で出来るはずの仕事までチャットでお伺い立てるの嫌じゃないですか？（笑）
という冗談はともかく、チャットによる生成AI活用は求められるリテラシーレベルが高いと感じておりまして、みんながみんな使える機能ではないだろうな、と思ってます。ですので、チャットベースでない生成AI技術を活用したプロダクト開発にこそ差別化できる付加価値がありそうだなーと思ってました。
ここも今回のケースではよくあてはまって、AWS発想の生成AI=Bedrockという素材を活かせる考え方だったのかな、と思ってます。
課題設定
このPJを受けるにあたり、はじめに上司からの説明がありました。その説明を受けての第一の質問は、「どのくらいこの課題設定に変更余地があるか」でした。上記感じていたことがあっての質問でして、ここで「指定通りの課題設定のソリューションを作れ」というのがFIXだった場合は正直受けられないなーと思ってました。幸い、「Bedrock」で「営業担当の営業活動業務フロー内」の課題解決に資するものであれば多少のピボットOK、の答えを引き出せたのが、ある意味このプロジェクトの勝ち筋を作れた大きな分岐点だったかなと思います。
さて、このPJでは特にプロマネの方法についても定義されていなかったので、まずはPOとしてPM兼務で初期タスクをWBS的に管理しながらキックオフしました。その中で、課題の明確化およびチーム内共有、コミュニケーション手段/対象確認、スケジューリング策定（PJ立ち上げ時の必須確認3項目と個人的に定義してたりする）や、ワーキングアグリーメント策定、利用するアジャイルツール準備等を実施し、約１か月かけてアジャイル体制に移行しています。多少時間はかかってますが、その間に開発Tは環境構築や技術検証、企画サイドでは課題ヒアリング・インタビューの計画・実施が出来ていますので、そんなロスはしてないかなと思います。
課題のヒアリングですが、実際のKDDI所属のソリューション営業の方数名にお声がけし、業務フローに即しての実施内容、課題感を抽出しました。その中で今回、共通の課題として洗い出されたのは「日報」でした。日報とは営業活動する上で、次の手を打つための情報整理であり、上長や同僚への情報共有であり、さらに、過去どのように相手企業とかかわり、契約を受託/失注してきたかを表すまさにノウハウの塊です。ただ、この日報というのは営業活動において時間を食う報告業務でしかなく、営業担当としては少なからぬ苦労をして敢えて残してくれている（のに、評価にはつながらない）ものでした。我々のチームはここにフォーカスすることとしました。
コンセプト策定
以上まではチーム内で協力してインタビューを計画し、共同でWSを開きながら課題を設定していきましたが、コンセプトにおいては一本大きな流れとして作りたかったので、POトップダウンでプロダクトのステートメント、プロダクトビジョン、開発コンセプト、ユーザストーリーマップ、サービスブループリント等々を一気に作り上げ、チーム内で揉む形をとりました。
始めに決めたこれら内容はPoC内で一貫できました。チーム内で方向がブレずにできたのは始めにこれらビジョンを決め、みんなで揉んで納得感を醸成できたからかなと思います。
開発進捗管理
アジャイルスクラムにおいて、プロダクト品質の管理は2面あると考えています。一つは、プロダクトオーナーサイドが行う、プロダクトとしての全体開発像ToBeとAsIsとの把握、もう一つは開発サイドが行う、スプリント内の開発チケットの完遂と開発物としての品質管理です。PJあるあるで避けたいのは、一人のPMがすべてのスケジューリング・タスク管理をすることですので、これを避けるために、このスクラムの基本に則り、チーム内メンバーに強く自律した仕事の実施を徹底することをお願いしました。
過去のQiitaにも書いてきたとおり、POの本質は「決めること」にあると思ってます。その上で、決めなくてもやれること、決めた後にやることについて、POが口を出したり、POが動かないと進まないのではチームである意味がないと考えています。その上で、自律的であることを基本にしたいと考えて、自分自身のタスクについてスケジュール設定したり、開発項目を膨らませてみたりすることを、初めのうちはお願いして実施してもらい、提案が出てくることを歓迎し、感謝してきました。そして最終的には一人一人が同じ課題感のもと、自律的に動くチームになれたかなと感じております。ついこの間ですが、チーム内で「どうやってニーズ調査しようか」という相談をしたところ、あれよあれよと社内アンケートが作られて即日実施に移されたのには感動しました。
レビュー
今回はKDDI社内の営業の方と、インタビューに加えて週一回のレビュー参加のご協力も得られ、フィードバックを経て具体開発項目を調整しました。
まず開発したのは議事録生成機能です。こちらはかなり刺さりました。その理由としては、Bedrockの精度云々ももちろんありますが、一番よかったのは、生成された議事録を再度プロンプトによって修正指示を出せるようにしたところでした。たとえば、初めの議事録生成ではイマイチ論点をおさえてない文章が作成されることがありますが、それに対して追加プロンプトで、結論を箇条書きにする、誰がどの発言をしたかをまとめる、などの要望でまとめなおすことができるようにしました。その結果として、まとめかたは各人でいろいろなスタンスがあり、それを自分で調整していくことが受け入れられたと感じます。
この手応えのもと、次に取り組んだのが、提案骨子生成機能です。こちらは当初与えられた課題にマッチした機能でありながらも、一方で先の記載の通り「本当にこれを望んでいるのか」をうっすら抱えたまま、どうすれば営業担当として欲しいものになるかを考え抜きました。そこで行き着いたのが、これから何をしようか考えている人に、何をしたいかを書かせる＝チャットベースではダメ、という考えと、先ほどの自分で調整することにより結果が得られる、という成功体験にこそ正解があるはずだ、という考えを組み合わせた、次の結論です。つまり、生成するのは正解そのものではなく、正解に至るパーツを集め、営業自身が組み合わせて正解を作るという体験です。
それは実装としては、「課題に合致してそうな商材候補をいくつか列挙する」「課題をもとに次回の打ち合わせアジェンダを作る」といった営業として普段資料作りをする前にやっていることの代理実行を、ボタン選択でやらせることができる、というものに仕上がりました。つまり、提案書そのものを作りに行くのではなく、提案の作成に必要な素材や、提案の骨子を作りに行く形をとったのです。
今回のPoCの重要な気づきとして、従前のひっかかり「どこまで生成AIに任せたいと考えているか」に明確な答えが得られました。それは、「営業担当は資料作りを自動化させたいとは思っていない」ということです。営業のインタビューでも、彼ら/彼女らは、「資料作りに苦労している」とは言っていましたが、その理由としては「情報にリーチできていない」と意見を述べていました。そうなんです、欲しいのは労せず作られた資料ではなく、自分たちで資料を作るための情報であり、生成AIで求めているものも資料そのものではないんですよね。
生成AIでものづくりを考えている人へのヒント
今回のPoCを通して、一部生成AIに特化したものづくりにおける勘所を中心にまとめてみます。もしお題として生成AIでなんか作れや！と無茶振りされた人のヒントになれば。
- 生成AIで正解を作りにいかない。正解は人が作る（判断する）UXを考えるべし
- 本当にすべてをAIに任せたいと思っているか。利用者が楽したいところ、逆に自分でやりたい（やらねばいけないと思っている）ところを探るべし
- 解決すべき課題は少し引いて広く見る。当初のお題はその通り作っても大抵外れている
- いかなるチーム開発もマイクロマネジメントはしないこと。そのためにはプレイヤーの自律を促すべし
- PJ当初のコンセプト策定議論は丁寧にしっかりと。チーム内で納得して方向性を共有できればブレなくすすめられる