開発について最初から知っておきたかったことChatbots

エリックはチャットボット開発会社を経営している。特にカスタマーサービスやマーケティング分野の大企業にチャットボットソリューションを提供している。

エリックは、chatbots への売り込みのコンバージョン率が非常に高いので、ビジネスは非常にうまくいっていると一方では話してくれた。これはおそらく、彼がこの分野でいち早く市場に参入したことを反映しているのだろう。

同時に彼は、質の高いchatbots を効率的に構築するための適切なツールを見つけるのに苦労していた。

最初にChatfuelやMotion.aiのようなノーコード・プラットフォームを見つけたとき、彼はこれらのツールが自分の問題を解決してくれると楽観的に考えていた。しかし、ボットのプロトタイプを作成するのには適していたものの、すぐに問題に直面した。

多くのボットはコードでしか表現できない方法でカスタマイズする必要があり、これらのプラットフォームはコーディングをサポートしていなかった。クライアントのレガシーシステムと統合する必要があるボットもあったが、これも不可能だった。

これらの問題が解決できたとしても、すべてのロジックとデータが、自分がコントロールできないサードパーティのシステム上に存在することには抵抗があった。彼のクライアントは、セキュリティ上の理由から、ボットを自社でホスティングすることを主張することが多かった。

そこで彼は、マイクロソフトのボットフレームワークを使ってボットをゼロからコーディングし、可能な限り低コストの国の開発者を起用することにした。このように予測可能性を高めることで、別の問題が発生した。

彼はコードとデータの所有権を持ち、ボットを必要な程度にカスタマイズすることができるようになったが、結果は散々だった。

彼は、すべてのボットにロールベースのセキュリティ、サブスクリプション、ブロードキャスト、ループ内の人間など、多くの共通機能があることにすぐに気づいた。

また、開発者によって機能のコーディング方法が異なり、全体的なアーキテクチャが場当たり的に進化していたため、開発リスクも不必要に高くなっていた。一部の開発者はこの問題を認識し、共通機能のための再利用可能なライブラリを作成し始めたが、これらのライブラリは、彼がビジネスを構築したいと思うような高品質のライブラリとは言い難かった。特に必要とされる機能が複雑な場合、それらのライブラリにはそれなりのリスクや不要な依存関係があった。彼がその品質を検証することは難しく、ましてや構築されたものすべてが十分に高い水準にあるという確信を顧客に与えることはできなかった。

彼は、独自のプラットフォームを構築するというアイデアも少し考えたが、それはやり過ぎのように思えた。このようなことをすれば、不必要な開発費とメンテナンス費用が発生し、また、クライアントが好むような市場標準のフレームワークが出現した場合、販売上の問題が発生する可能性がある。時間の問題だった。

彼の考えでは、この問題はインターネットの黎明期にウェブ開発者が直面した問題と似ていた。当時はワードプレスのようなコンテンツ管理ツールがなかったため、ウェブサイトは毎回ゼロからコーディングする必要があった。そのため、開発コストの増加や、コードやアウトプットの品質のばらつきなど、現在彼がボットを作成する際に直面しているのと同じ問題が生じていた。

エリックがBotpress.ioをオンラインで見つけたとき、Botpress が彼の問題を解決してくれる可能性があると認識するのに時間はかからなかった。彼は、理論的にはモジュラー・アーキテクチャーが気に入り、ボット用のCMSに相当するものを構築することに意味があると考えた。彼はそれが必要だと信じていた。それはパズルに欠けているピースかもしれないが、彼はまずいくつかの質問に答える必要があった。

まず、ソリューションが堅牢で、安全で、信頼できるものであることを確認する必要があった。

第二に、彼が必要と特定したすべての共通重要機能が、フレームワークを通じて利用可能であることを確認する必要があった。

第三に、彼の代理店にとって経済的なメリットがあるかどうかを確認する必要があった。

自分自身が実践的で技術的な人間であることから、彼は実際にシステムをテストすることによって、最初の2つの質問を個人的に検証することにした。彼は、Botpress コミュニティに参加し、オープンソース版を使ってビデオチュートリアルのいくつかをこなした。

このソフトを使っている開発者のコミュニティがすでに大きく活発だったことは、このソフトが実戦テスト済みであることを意味し、それは良いことだった。

彼は当初、Botpress がオープンソースであるため、顧客が（多くの場合、当然ながら）セキュリティ・リスクとみなすのではないかと懸念していた。しかし、彼は、Botpress 、セキュリティの問題に対処するために、オープンソース版とは別に管理されたエンタープライズ版があることを知った。

もちろん、オープンソース版は無料で使えるという利点があり、多くの場合、企業ユースケース以外のボット開発には理想的だった。それは、コンポーネントとアプローチが多くの異なる開発者によって多用され、検証されたことを意味する。

彼のクライアントの多くは、オンプレミスでチャットボットをホストし、セキュリティと商業上の理由からデータを管理することを要求しており、Botpress 、これをサポートした。加えて、Botpress 、コードの完全なカスタマイズや社内システムとの統合が可能であった。これは、彼が「ノーコード」プラットフォームで抱えていた当初の問題点であった。

彼が望んでいた機能のほとんどは利用可能だった。ロールベースのセキュリティ、マルチユーザー管理、ボット配備後の管理用ユーザーインターフェースなどだ。足りないものはモジュールとして簡単に追加できた。

実際、モジュラー・アーキテクチャーとシステムのグラフィカル・インターフェースによって、どこに何が配置されているのかが非常にわかりやすくなっている。つまり、プロジェクトの途中で新しい開発者に切り替わったり、長いインターバルの後に誰かがコードを引き継ぐことになっても、該当者がスピードアップするのに時間はかからないということだ。ここまでは良かった。

経済学的な問題も明らかに重要だった。Botpress 、開発費全体を削減できるだろうか？利益率は厳しかった。彼が期待していたのは、Botpress のようなフレームワークを使うことで開発コストを削減し、同時に品質と機能を向上させることだった。

彼の期待は正しかったことがわかった。Botpress を運営するコストは、自分でいくつかの機能を構築するコストに比べればほんのわずかだったし、品質もプロプライエタリなソリューションより優れていた。

フレームワーク・アプローチの隠れた利点は、チャットボットのUIと機能に多くの時間を費やすことができ、それによって最終的な顧客体験を大幅に改善できることだった。

彼は、市場に出回っているchatbots の多くがそれほど優れていないことを観察していた。業界として、チャットボットメーカーは顧客の期待を裏切っているとさえ言える。

これは、企業がchatbots 、その結果に確信が持てないため、開発に相応の資金を割く用意がなかったからだと言える。

もう一つの論点は、chatbots の開発プロセスはこれまで非常に非効率的だったということだ。というのも、チャットボットメーカーはchatbots を開発するための効率的なツールを持っていなかったため、開発コストの多くが本質的にインフラに集中していたからだ。

Botpress のようなフレームワークの登場は、より多くの開発予算がユーザー・エクスペリエンスに費やされるようになり、chatbots の質を大幅に向上させる可能性を秘めていた。

念のため言っておくが、エリックは実在の人物ではなく、 chatbots でできることについての問題、要求、関心について私たちに連絡してきた代理店オーナーの何人かを合成したものである。様々な形で、彼らは「クライアントのためにchatbots を開発することについて、最初に知っておきたかったこと」のバージョンを共有した。

主な問題点をまとめると、次のようになる：

• 優れたchatbots を構築するには、コードとデータにアクセスする必要がある。
• 開発者はビジネスロジックをカスタマイズし、社内システムと統合する必要がある。開発者なしに優れたchatbots 。
• 多くの企業クライアントは、セキュリティ上の懸念があるため、チャットボットを構内で実行したいと考えています。また、ロールベースのセキュリティやユーザー管理など、使用するソフトウェアと同じものを求めている。
• 機関が選択するフレームワークは、すぐに幅広い共通機能を提供するものでなければならない。
• どの代理店（または開発会社）にとっても、社内用に独自のチャットボットフレームワークを構築することは、独自のデータベースをゼロから構築すること以上に意味がありません。それは不経済であり、大規模なメンテナンスコストを発生させるだけでなく、彼らの顧客は、非中核的なインフラを自分たちで構築しようとするよりも、目的のために構築された、確立され、よく理解されたインフラ製品を使用することを好む可能性が高い。
• より多くの開発費をインフラよりもユーザー・エクスペリエンスに回せるよう、業界はフレームワークを必要としている。