この項で説明する準備ステップを支援するには、会話設計エクスペリエンス(CDX)ワークショップに参加することを検討してください。CDXワークショップでは、プロジェクト・チームの担当者と意図したユーザー・グループの担当者をまとめて、ユースケースとデジタル・アシスタントが人格、声、言語、態度に関してどのようにすべきかについて話し合います。

CDXワークショップは、デジタル・アシスタント・プロジェクトの次の基本的な側面を支援します。

• デジタル・アシスタントで解決する問題と、対応するユースケースを特定します。
• ターゲット・オーディエンスを特定し、音声、トーン、教育的および文化的背景の観点からそのオーディエンスに適したボット・ペルソナを開発します。
• 既存のユーザー・ジャーニーを体験し、デジタル・アシスタントで改善できる場所と方法を特定します。
• さまざまなチャネルの機能を念頭に置いて、ユーザーにリーチするための最適なチャネルを特定します。
• ボットとユーザーの間のダイアログをモデル化します。
• 会話をサポートするために必要なデータがあるバックエンド・システムを識別します。

このようなワークショップは、自分で実行することも、Oracleの担当者が行うこともできます。

デジタル・アシスタントは、Webアプリケーションやモバイル・アプリケーションを置き換えるのではなく、それらを補完します。デジタル・アシスタントの構築を開始する前に、「なぜ」と自問してください。デジタル・アシスタントを構築するのはなぜですか。また、そのメリットは何ですか。デジタル・アシスタントを構築すべきではないと言っているのではありません。むしろ、ユース・ケースがわかりやすいデジタル・アシスタントを構築していることを確認したいと考えています。

デジタル・アシスタントのわかりやすい点は、使いやすさです。アプリケーション・インタフェースとのユーザー・インタラクションに自然言語会話を使用すること、およびユーザー・メッセージから情報を抽出する機能です。これにより、ユーザーに表示されるプロンプト数が全体的に減少します。

数年前、モバイル・アプリケーション開発が学習すべき新しいスキルであったとき、Oracleユーザー・エクスペリエンス・チームは、モバイル・タスクに3分以上かかることを推奨しました。デジタル・アシスタントに対応する推奨事項はありません。しかし、私たちの経験に基づいて、おそらく60秒の近所で、それは十分に下回るべきであると確信しています。

そのため、デジタル・アシスタントのユースケースを定義する際は、タスクを完了するために必要なユーザー・インタラクションの量に注意してください。相互作用が非常に長いことがわかった場合、ユースケースはデジタル・アシスタントに適していないか、対話の短縮を検討する必要があります。たとえば、構造化データ入力フォームを会話に組み込むなどします。

一般的な推奨事項として、大きすぎたり複雑すぎたりしないユース・ケースを見つけてください(さらに、より大きなユースケースを小さいユースケースに分割します)。特に、作成するデジタル・アシスタントが初めての場合、「単純」はすでに複雑すぎる可能性があります。

達成したいことは何でも、目標を立てる必要があります。デジタル・アシスタントにとっては、企業にも利益をもたらす現実的な目標を設定することが重要です。たとえば、Webアプリケーションを会話型チャネルに移動することは、Webアプリケーションを現実的なデジタル・アシスタントのユースケースに分類でき、デジタル・アシスタントがWebアプリケーションよりも適切に機能しないかぎり、適切な目標ではない可能性があります。ほとんどの場合、「...から...」へのプロジェクトの移動は失敗します。ユーザーや開発チームは、移動元のアプリケーションの機能と外観をコピーするだけです。

成功は測らなければならない。たとえば、デジタル・アシスタントはセルフサービスを自動化するスマートな方法であるため、真のメリットを得ることができます。ただし、メリットがあるかどうかを適切に評価するには、各デジタル・アシスタントのユース・ケースで成功の意味と測定方法を定義する必要があります。基準の例を次に示します。

• 「図書館からの本の受講依頼の60%をデジタル・アシスタントが解決して、図書館員のワークロードを削減したいと考えています。」

• 「パスワードのリセットやアクセスおよび認可リクエストなど、現在のIT運用の70%は、デジタル・アシスタントで処理する必要があります。」

• 「新しい不動産を購入するためのすべての顧客からの問い合わせは、当社の不動産代理店がオンサイト訪問数を30%増やすことができるように、デジタルアシスタントによって事前に認定され、転送される必要があります。」

• 「経費デジタル・アシスタントは、従業員による経費精算書の提出から会社による経費の払戻までの時間を3日に短縮する必要があります。」

会話型ユース・ケースでは、ボットが処理する必要があるタスクを定義します。ただし、ドメイン内には、デジタル・アシスタントで処理しないが認識する必要がある合理的で関連するユース・ケースがある場合があります。

会話を持つことは人間にとってネイティブなスキルであり、会話を行うために特別なトレーニングは必要ありません。デジタル・アシスタントの場合、適切な会話の原則(そうでなければ当然のことと思われる)を特定し、それらをボット会話デザインに組み込む必要があります。会話の考え方を具体化しない場合は、デジタル・アシスタントをコマンドラインまたはWebアプリケーションとして変装して作成し、デジタル・アシスタントを非常に優れた会話機能を使用しないというリスクが生じます。

では、どのように会話の考え方を決めるのでしょうか。次に、オプションをいくつか示します:

• デジタル・アシスタントの定義に役立つ会話デザイン・エクスペリエンス(CDX)ワークショップに参加してください。

  ワークショップでは、二人の人が椅子に座る練習をします。(デジタル・アシスタントの会話をシミュレートすると、非言語的な手がかりがなくなるため、後ろ向きに戻ることができます。)1人はデジタル・アシスタント、もう1人はユーザーです。彼らにユース・ケースを提供し、会話がどのように発展し、どのように進行し、どこで立ち往生するかを確認します。会話がスタックした場合は、2人が会話を再開できる状態にどのように解決するかを確認します。会話のノートを取り、スティッキー・ノートに置き、それらをウォールに追加してグループと話し合います。

• パブやレストランに行って、一緒にいる人や友達を観察しましょう。食べ物や飲み物を注文するのを見てはいけません。

  • メニューに食事の数を記載して、何人の人が食事を注文しますか?食事の名前はメニューに書いてあるので何人ですか?食事の食材を言うと何人の人が注文しますか?「私にとって同じ」と言って、何人の人が前の人の命令を参照しますか?

  • バーテンダーやウェイターは、どのようにあなたの注文を確認または確認しますか(もしそうなら)。

  • バーテンダーやウェイターは、騒々しい環境のために注文を理解しなかった場合、何をしますか?

  • バーテンダーやウェイターはもっと注文することを奨励していますか?もしそうなら、彼はどうやってそれをするのか。

  • バーテンダーやウェイターはどのようにあなたの注文をサポートしていますか?

  • バーテンダーやウェイターは、食べ物や飲み物を楽しんでいる間、どのように行っているかを尋ねますか?もしそうなら、なぜそうしていると思いますか?

詳細に注意し、メモを取ることもできます。あなたが気づき、注意するものはすべて、会話スタイルと実践です。

レストランの従業員はレストラン自体を代表し、通常はレストランが最初に印象を与える。レストランのスタッフが専門であればあるほど、顧客対応のトレーニングを受けている可能性が高くなります。彼らはやるべきことやややらないことを学び、困難な顧客にどのように対処するかを学びました。心理学は飲食販売と顧客返品と何の関係があると思いますか?

デジタル・アシスタントとの類似点を見ると、会話の設計が重要な理由がわかります。

デジタル・アシスタントのペルソナは、会話デザイナおよびボット・メッセージ・ライターに、一貫性のあるユーザー・ボット・エクスペリエンスを構築するためのより具体的で表現的なフレームワークを提供します。デジタル・アシスタントとユーザーの間のエンゲージメントを作成する際、「この状況を<DIGITAL_ASSISTANT_NAME>でどのように処理するか」を尋ねる場合があります。

デジタル・アシスタントは人間ではありませんが、人間の特徴を持つことができます。そのため、デジタル・アシスタントのペルソナを定義する際、アバターとブランドや会社を表す名前を作成するだけでなく、開発チームがユーザー・インタラクションやメッセージを設計する際に使用できる手すりとして機能する背景も作成します。背景には、デジタル・アシスタントが実在の人物(名前、年齢、訪問した学校、その人が生まれた地域)であれば、知りたいことがすべて含まれる必要があります。人が現在住んでいる地域、趣味、婚姻区分、音楽、食べ物や映画が好き、彼女が持っているユーモア、彼女が話すアクセントなど.

世界中の様々な国のユーザーからアクセスするデジタル・アシスタントを設計する場合は、文化的および地域の違いを考慮する必要があります。デジタル・アシスタントは、どこからアクセスしても同じペルソナである必要がありますが、地域的および文化的な専門分野に適応することは問題ありません(場合によっては必要になります)。しかし、デジタル・アシスタントはサービスを提供し、すべてを喜ばせるために存在することに注意してください。

デジタル・アシスタントは自ら構築しない。これには、バックエンド統合、システム管理、プログラミングなど、多様なスキル・セットが必要です。また、ボットに固有のロール(会話デザイナ、会話メッセージ・ライターおよびモデル・デザイナ)も必要です。後者の3つは、必ずしもチームでの常勤ポジションに代表される必要はありませんが、ポジションに配属されたポジションは、そのロールのエキスパートになる必要があります。

スキルを使用して、大規模なユースケースを多くの小さなユースケースに分割できます。スキルは、デジタル・アシスタントの他のユーザーとともに構成される個々のデジタル・アシスタントです。機械学習を使用して、デジタル・アシスタントは、ユーザー・メッセージのコンテンツに基づいて、リクエストの転送先となるスキルを決定します。

大規模なユース・ケースを複数のスキルにパーティション化すると、デジタル・アシスタントの機能を段階的に増やし、開発を容易にし、懸念事項を明確に分離できます。

すべての新しいリリースと同様に、デジタル・アシスタントの最初のリリースは最適なバージョンではありません。最初にクロールする方法を学習する必要がある幼児のように、次にどのように歩くか、そして最終的にどのように走るかを学びます。

• デザインで考えなかったような状況を体験してください。

• 人間としてログに記録されたメッセージがわかりますが、デジタル・アシスタントは正しくありませんでした。

  簡単だと思っていた会話に苦労しているユーザーを確認します。

• 会話を放棄したユーザーに通知します。

成功を測定する方法が必要なため、デジタル・アシスタントを改善する計画も必要です。このような計画には、デジタル・アシスタントのモニター、新機能およびバグ修正の追加、および新しいバージョンのリリース頻度が含まれます。

Oracle Digital Assistantには、スキルおよびデジタル・アシスタントのパフォーマンス・インジケータをレポートする分析機能であるインサイトが含まれており、これにより、ボットがタスクにマップできなかった会話パスおよびメッセージの破損を検出できます。また、デジタル・アシスタントを使用すると、ユーザーがダウンタイムが発生することなく、新しいバージョンのデジタル・アシスタントを再デプロイできます。

失敗の苦味は、デジタル・アシスタントができることを過剰に販売することからも生じます。デジタル・アシスタント・プロジェクトから始めると、期待を現実的に管理できます。ボットは最終的にうまく機能し、設定した成功目標を達成しますが、最初のバージョンには含まれません。

ボットを操作する際のユーザーの注目度は無限ではありません。まもなく、デジタル・アシスタントで他に何ができるか、どのようにひび割れるかをテストするという考え方から、ユーザーは歩み寄ることがあります。したがって、ビジネス関連の機能設計を超えて、デジタル・アシスタントを構築したビジネスの領域にない機能が必要です。

少人数での話し合いは、デジタル・アシスタントの一般的な要件です。ユーザーは、ボットが人間であるかどうか、デートに出かけたいかどうか、天気はどうなっているか、共有する良い冗談を知っているかどうかなどを尋ねることができます。デジタル・アシスタントは、これらの問合せに完全に回答する必要はありませんが、最も一般的な問合せを処理できる必要があります。

たとえば、天気を尋ねると、花を販売するデジタル・アシスタントは「データ・センターに窓がありませんが、天気は花を注文するのに十分だと言われています。だから、花の注文を手伝ってあげましょう。"小さなお話のおかげで、デジタル・アシスタントはリクエストを理解し、ユーザーがボットの目的を思い出すように処理します。スモール・トークは、適切に処理されていれば、ユーザーとボットにとって双方にとって有利な状況です。

• ☑軸のシャープ化に十分な時間を費やしましたか?
• ☑ ステークホルダーとプロジェクト・チーム・メンバーと一緒にCDXワークショップを実行します。
• ☑デジタル・アシスタントに適したユースケースを特定します。
• ☑ デジタル・アシスタントのドメイン内ではあるが範囲外であるユースケースを特定します。
• ☑デジタル・アシスタントの成功の意味と、それをユース・ケースでどのように測定できるかを定義します。
• ☑ 大きなユースケースを小さなユースケースに分割します。
• ☑ ユースケースごとに、必要な会話を特定します。
• ☑ 成功の目標と指標を定義します。会話の成功はどのように測定しますか?会話におけるビジネス価値はどこにあるのか。
• ☑ 会話デザイナー、NLPトレーナー、製品管理、Oracle Digital Assistant開発者、バックエンド統合開発者など、チームに適切なスキルがあるかどうかを確認します。
• ☑ ボット・ペルソナを定義します。
• ☑ ボットの背景を記述します。
• ☑ 小さなお話やよくある質問の処理方法を検討します。
• ☑ 失敗に対処するための計画を準備します。

• Oracle TechExchangeの記事: デジタル・アシスタントを複数のスキルに分割する方法の決定
• チュートリアル: Oracle Digital Assistant Insightsの使用