「作るものはもう決まってます」技術ドリブンの生成AI 短期PoC案件でUXデザイナーがどう関わったか？
はじめに
こんにちは。KDDIアジャイル開発センター(KAG)のサービスデザイナー・よねみちです。
本記事では、KAGとKDDIで共同実施した生成AIチャットボットPoCプロジェクトで、UXデザイナーチームがどう関わっていたかについて記載します。
エンジニアリングを含めたプロジェクト全体の成果についてもまもなく外部報告を予定しておりますのでお待ちください…!! (発表後、追記します!)[12/21追記] 本件のプレスリリースを発表しました！
自己紹介
KDDIアジャイル開発センターのサービスデザイナーです。
本記事のような生成AIを活用したサービスのUXデザインの他、新規事業創出・DXなどをテーマにしたデザインスプリント、ワークショップ設計・運営などを行なっています。
KAGの生成AIに関する取り組みについて
KAGでは"KAG Generative AI Lab"を立ち上げ、生成AI活用の推進や、実践的な技術、知見、ノウハウの獲得を進めています。
KAGでは社内の生成AIに関する理解の向上、技術力向上を目的とし、これらを短期的に集中して行うために 今年5月よりKAG Generative AI Labをつくり活動を進めてきました。
また、既存プロダクトへの生成AI導入も行っています。
「Microsoft Teams」と「anycommu（エニコミュ）」の2つの既存プロダクトを対象に生成AIを導入し価値検証を行いました
本プロジェクトも上記Lab.の一環として、商用化を見据えた知見獲得を目的に始動しました。
プロジェクト参画！ 当時の状況
プロジェクトのキックオフ当時、デザイナーは不在でした。社内での相談が発展し徐々にプロジェクト化したという背景があったようです。また、そもそも、私がKAGに中途入社して初めて担当したプロジェクトだったのですが、キックオフ日は私の入社直前でした 笑
参考：KAGのデザインプロセスについて
このnoteの事例では、社内では若干特殊なプロセスを踏みましたので、参考までにKAGの一般的なデザインプロセスをラフにご紹介します。
主なデザインプロセスの流れ
中長期目標の定義
リサーチと課題分析
体験とビジネスの設計
ソリューション開発
評価・フィードバック
いわゆるHCDプロセスやデザイン思考プロセスに忠実に進めています。個々の案件によって具体的なプロセスは流動的ですが、数日のワークショップで1~3だけ行うこともあれば「デザインスプリント」としてプロトタイプを作り進めることも、PoCや商用開発としてスクラムチームを組んで進めることもあります。
共通して言えるのは、目標や課題の定義からデザイナーが入っていくことです。お客様やプロダクトオーナーの「こうしたい」という要望を素直に叶えるだけでは、彼らの真の目標を達成できないことが往々にしてあるからです。
当時を振り返る
今回は入社早々ということもありタイミングが合わず、一般的なKAGのデザインプロセスに乗りませんでしたが、結果として、私がチームに参画した時はこんな状況でした
期間はfix済み。約2ヶ月でPoC完了するため納期と知見獲得が最優先
プロダクトは社内独自の文書・データを取り込んだ生成AIチャットボットであること。UIはOSSをベースに作る。
UX、UIの優先度はほぼ最下層。必要最低限だけやりたい(by PO/スクラムマスター)
ユーザーの課題感はざっくりホワイトボードに書き出してある
作るモノや使う技術は決まっていて、UX/UIは最低限でOK… さて、じゃあデザイナーとしてどこに価値を出していこうか、そもそもわずか2ヶ月でどうしようか、という感じ。
一般的なサービスデザインのプロセスはWHAT→HOWの順番で検討する(もちろん、両者を行ったり来たりすることは必要)と理解していますが、本件のプロセスは完全にHOW→WHATでした。
WHAT：我々はどんなサービスを実現するのか、提供価値や体験を定める
HOW：我々はどうやってサービスを実現するのか、具体的な技術やプロダクトを定める
UXデザイナーとしてどう関わることにしたか
とにかく短納期でプロダクトを作った上でアウトカムを得ること。そのためにやるべきことを考えた結果、以下の3つの軸を持ちました。
状況を見える化し、チームがUXの観点を持って判断できるようにする
UX設計は注力ポイントから外す。特に、成果物を作って満足することだけはしない
UX設計の代わりに、ユーザー評価にはしっかり時間をかける
1.状況を見える化し、チームがUXの観点を持って判断できるようにする
プロジェクトに参画してまず感じたのは、①日程がタイトなためシビアにスコープを見定めないといけないことと、②情報が散らばっていること、③プロダクトが体験として成立するのか心配なこと の大きく3つでした。
そこで、状況や議論、設計物をしっかり見える化し、チームが適切な判断を下せるような仕組みづくりを重視することにしました。特に、チームメンバーが自然とUXの観点を持って機能の必要性や抜け漏れ、優先度を議論できるようにユーザーストーリーマッピングを軸に進めるようにしました。
また、細かい話ですが検討中の内容も基本的に全てmiroに情報を置き、非同期でも「miroを見ろ」である程度の進捗がわかるようにしました。
2.UX設計は注力ポイントから外す。特に、成果物を作って満足することだけはしない
デザイナーとしてはちょっと悲しいですがUX設計は割り切りました。そもそものプロジェクトが課題解決というよりも知見獲得でしたのでそこにフォーカスするべきと判断。ユーザーストーリーマッピングなどで見えてきた必須機能のうち、体験として成立しない部分のみピンポイントで設計しプロダクトに反映する形をとりました。
また、成果物を作ることが目的にならないように、成果物の取捨選択は慎重に行いました。(ペルソナとかカスタマージャーニーとか構造化シナリオとか定番アイテムを作ると安心しますけどね)
限られた時間を有効活用するために「それって次に何に繋がるの？」という問いを持ち続けて進めていきました。
3.UX設計の代わりに、ユーザー評価にはしっかり時間をかける
PoC終了後に活かせる知見を獲得することを目的に、ここにはとことん時間を使うことにしました。「なぜこの仕様でいいのか」「なぜこの機能が必要か」… など、これから商用化開発する上で直面するであろう「なぜ」に答えられるよう、ユーザーの思考や利用背景を捉え「〜だから」という理由を探る定性評価を重点的に行うようにしました。
プロジェクト成果
詳細は書きませんが、結果としてプロダクト開発とユーザー評価をもって目的としていた知見獲得を十分に行うことができました。
「どう関わることにしたか」に関連するアウトプットをかいつまんで紹介します。
プロダクト
機能も画面もほぼほぼOSS(ChatBot UI)そのまま。でも最低限の機能削除/追加と、濃紺と水色をマテリアルデザインに取り入れ「パッと見のKAGっぽさ」は死守しました。素敵なUIデザインを速攻で作ってくれたつむらさん本当にありがとう。
ユーザーストーリーマップ
狙い通り、UXとプロダクトバックログの結びつけやチームの議論活性化に大きく活躍しました。具体的には、このマップをベースに付箋で書き込みながら議論を繰り返し、本当に必要な機能とあったらいいな機能を仕分けることで注力ポイントをチームとして認識を合わせて進めることができました。
マインドマップ
今回はユーザー評価から逆算し、ペルソナではなくマインドマップを作りました。意図として、評価会の被験者をリクルーティングする要件決めと仮説出しができれば十分だったためです。(ペルソナを設計してその人にマッチする機能を考えても、結局開発できなければ意味がないので。。)
このマップは2軸4象限で定義しています。各々の属性で異なる課題を持っていることや、プロダクトへの反応が異なることを仮説として立てており、ユーザー評価の検証ポイントとしました。
ユーザー評価の結果
合計6人の想定ユーザーに対しユーザーリサーチ、コンセプト受容性調査、ユーザビリティテストを複合したユーザーテスト&デプスインタビューを組みました。準備、実査、分析どの断面を取ってもほんと〜〜に時間かけました。。
評価計画書と結果を見たプロダクトオーナーからは「まるで研究みたい」と評していただき、論理的にかつ熱量持って取り組んだことが伝わった様子で安心しました。
画像の付箋一つひとつがテストで得られた知見です。取得した情報量が伝わると嬉しいです。
学び
ユーザーストーリーマッピングの意義は議論の土台としUXとバックログを繋ぐこと
このフレームワークで図式化することで、POやエンジニアも自然とユーザー体験全体を俯瞰して議論できる。結果、機能の過不足や優先度を適切に判断できる。成果物がどんなアウトカムに繋がるか、次のアクションに繋がるか考える意識
私自身、とりあえず手を動かしたくなるタイプでしたので貴重な経験となりました。成果物の意義や位置付けを理解しチームに説明する力が増したように感じます。ユーザーテストは時間がかかるけどやっぱり超大事
テストで得られた気づきや学びが今、チームの手元に溢れかえっているくらいです。ユーザーに会ってこそのUXデザイン/人間中心デザインであることを再確認するプロジェクトでした。議論をオープンにし、チームで認識を合わせ続けることが成功の鍵
振り返ると、このnoteの内容を含めて、議論を全員が見える場に広げてスクラムチームで細かく目線を合わせていたことがプロジェクトを推進しやすくした大きな要因だったと感じます。特に、トレードオフスライダーなどのプロジェクトの要綱をまとめたインセプションデッキと先述のユーザーストーリーマップは事あるごとに全員で見返していました。
目線が合うように仕向けてくれたスクラムマスターの偉大さに心から感謝です。
終わりに
本プロジェクトの事例を通して、技術ドリブンの案件でも方向性が固まった後の途中参画でも、デザイナーとしてチームやプロダクトのためにやれることが山ほどあると示せたと思います。
技術ドリブンの案件こそ「作ったものの使われない」闇に触れやすくなります。その闇からチームを守り、あるべき姿に導いていくのはUXデザイナーならではのやりがいになる。私はこのプロジェクトでそう確信しました…!!
一方で、今回、いわば邪道な「技術ドリブン」のプロセスを進めてみたことで、課題解決の本流はやはり標準プロセスの通りに「課題ドリブン」で進めることだと認識を深めました。課題ドリブンでプロジェクトのスタートが切れるように組織にもフィードバックしていこうと思います。
これからもKAGでは、集約した知見を活かしてイケてる生成AIプロダクトを作っていきます。お楽しみに…!!!
(最後に、KAGとKAG Generative AI Labの宣伝です)
#KAG #KDDIアジャイル開発センター
#UX #デザイナー #生成AI #アジャイル
この記事が気に入ったらサポートをしてみませんか？