ローコード・チャットボットプラットフォームのトレンド

ソフトウェア開発技術やツールが進歩するにつれ、ローコードやノーコード・アプローチへの移行が進んでいる。これは理にかなっている。なぜなら、ローコードやノーコード・アプローチは開発コストと時間を大幅に削減できるため、より多くのソフトウェア・アプリケーションを経済的に作成することが可能になるからだ。

これらのアプローチ、特にノーコードのさらに大きな利点は、ドメインの専門家であるビジネス・ユーザーが、自分のアイデアを他人に説明しなければならないという摩擦なしに、アプリケーションを作成し、改良できるということだ。これにより、高品質の製品を市場に送り出すまでの時間が劇的に短縮される。

ソフトウェア開発がコードなしに向かうのは論理的なことだ。エクセルは、（一般的に）コードなしの成功例として世界で最も優れた例である。多くのアプリケーションをビジネス・ユーザーが構築することができる。生産性の向上を世界にもたらしたエクセルの重要性を誇張することは難しい。

ローコード・プラットフォームの実際

もちろん、ローコードの未来とは、単一のアプリケーション開発フレームワークのことではなく、簡単に利用できるAPIのエコシステムのことだ。Zapierは、これらのAPIをゼロ・コーディングで利用できる方法の一例である。

もちろん、コードなしのソリューションは、上位のコードによるソリューションに比べて保守性や安全性が劣るという問題が生じる可能性もある。エクセルはその一例だ。

また、ローコードだからといって、誰でもすぐに便利なアプリケーションを作れるというわけではないことにも注意しなければならない。比較的洗練されたアプリケーションを作成することができるローコード環境では、アプリケーションの使用者がツール自体のコンセプトや機能をよく理解している必要があるのは確かだ。それは、他の洗練されたソフトウェア・ツールと同じである。

コードなしツールによって、ある種の機能構築の複雑さが、コードでこれらの機能を構築するよりも軽減されるとしても、コードなしツールであっても、複雑な機能を実現するにはある程度の複雑さが伴うという事実を回避する方法はありません。その明確な例が、Unreal Engineのようなチャットボットゲーム開発エンジンで、低レベルのコーディング概念（whileやforループなど）が視覚的に表現されています。これは、直接コーディングするよりも改善されますが、アプリケーションと概念に関する高度な知識が必要です。

つまり、コードがない世界であっても、専門知識は依然として重要なのだ。エクセルはその典型だ。パワーユーザーと一般ユーザーとの間には、達成できることだけではなく、最終結果の保守性においても大きな違いがある。

保守性という点では、コードなしのソリューションがコードベースのソリューションより保守性が低いとは限らないのは事実だ。多くの場合、何が起こっているのかがより明らかなので、コードなしのソリューションの方が望ましい。

しかし、複雑なシステムには多くの依存関係や偶発的な状態があり、開発プロセスやエラー処理にある程度のコントロールをシステムに実装する必要がある。

また、コードなしツールの制限によって、ある機能を作るのが、専門家がコーディングした場合よりもはるかに複雑になることもある。コードで作れば比較的簡単な機能を、コードなしツールでハックする必要が出てくるのだ。問題は、コードなしツールが実装している抽象化レベルが、いくつかのユースケースを構築しにくくしていることだ。エクセルの世界には、このような例がたくさんある。

要するに、ユースケースによって、ローコード、ノーコード、あるいはフルコード化されたソリューションのどれを使うのが良いかが決まるのだ。人生におけるあらゆることと同様に、あるユースケースに対してどのようなアプローチが最良であるかについては、ある程度の判断が必要であるが、ソフトウェア開発ツールのトレンドがローコードまたはノーコードであることは間違いない。

ローコード・ソリューションの進歩は、必ずしもソフトウェア開発者の仕事が減ることを意味しないが、ソフトウェア開発者が最適な効率を達成するために、コードとローコード／ノーコード・プラットフォームを組み合わせて使用する必要があることを意味する。

経済的には、より多くのアプリケーションを開発することが経済的に可能になることを意味し、そのため開発者はより多くのプロジェクトに特化した作業や、世界全体に向けてより多くの消費可能なAPIを構築することに専念することになるだろう。

要約すると、私たちは、常にコーディングの何らかの要素の役割があると信じており、したがって、最終的なゴールはノー・コードではなくロー・コードになると考えている。ローコード環境は、開発者が同じフレームワーク上に構築された機能を補完するカスタム機能を、コードツールなしで簡単に追加できるように設計されています。これは、プロのビジネス・ユーザーがソフトウェアの大部分を開発でき、開発者がプロフェッショナルなソフトウェア開発プラクティスを課し、ソフトウェアにカスタム機能を提供できる、最高の環境です。

低コードのチャットボット開発プラットフォーム

ローコードとノーコードのトレンドは、チャットボット開発技術にも当てはまる。この分野で提供される機能は比較的限られているが、すでに多くのコードなしプラットフォームが存在する。

特にマーケティング分野では、ボットは主に情報を提供し、ユーザーとの対話は限られています。

チャットボットの分野では、カスタム開発の必要性を過小評価する傾向があり、そのため、複雑なボットをビジネスユーザーが構築できるノーコード開発ツールを、顧客体験を大きく犠牲にすることなく作成することが可能なはずだと信じられている。

目の前の仕事を過小評価するのは人間の本性だ。私たちが立てる計画のほとんどは、現実を単純化したものだ。その計画を実行に移そうとすると、先見の明がなかったり、まったく予測できなかったりして、予想外のことが起こる。

いったんソフトウェアに取りかかれば、どんなに優れた仕様書であっても、開発プロセスを通じて新たな事実が明るみに出れば、ユースケースやコードの書き方の変更は避けられない。

チャットボットは、プログラムロジックやカスタムグラフィックインターフェースを必要とする複雑な機能を必要とする場合がよくあります。例えば、チャットボットがスコアやユーザーとのインタラクションを追跡する必要があったり、ウェブページとインタラクションする必要があったり、カスタムトリビアボットのためにユーザーがトリビアデータを入力するためのシンプルな画面を提供する必要があったりします。チャットボットは、ユーザーがフローのどこにいるかによって、コンテキストを管理し、リセットする必要があるかもしれません。このようなことは、特にchatbots を構築した経験のない人にとっては、最初は必ずしも明らかではありませんが、これらのことはユーザーエクスペリエンスに大きな違いをもたらします。

要約すると

このブログでは、生産性の高いノーコード環境の例としてExcelについて幅広く述べてきたが、実際にはExcelは、開発者がコードを書いたり、コードと統合したりするための豊富な機能を備えたローコード環境である。ソフトウェアに含まれるテンプレートや機能の数にかかわらず、特定のユースケースを満たすためのカスタマイズの必要性は常に存在する。

最終的にトレードオフとなるのは、開発効率とユーザー・エクスペリエンスの質、そしてプロジェクトの投資収益率という、重なり合う要因の間である。

ノーコード・フレームワークの課題は、質の高いユーザー体験を生み出すために必要なすべてを提供することだ。課題は、コードなしプラットフォームで構築するのが難しい10％が、エンドユーザーにとってすべての違いを生むかもしれないということだ。chatbots の世界では、コードなしですべてを構築できるかもしれないという幻想は強力だ。

私たちの見解では、トレンドは常に、ビジネスユーザーが自分で作成できる機能の範囲が常に拡大し続ける、コードなし、ではなく、より良い低コードのチャットボット開発プラットフォームを作成することです。このブログでは、ビジネスユーザーが自分でソフトウェアを作成できるようにすることで得られる創造性と経済性のメリットについて説明しました。

また、 chatbots の 構築を含め、すべてのソフトウェア開発のある側面は、開発者がコードを通じて提供する必要があり、これは開発者にとってできるだけ簡単である必要がある。ロー・コードがノー・コードに完全に取って代わられることはないだろうが、プロのビジネス・ユーザーとソフトウェア開発者という2つの主要な顧客にサービスを提供する上で、ロー・コードはますます良くなっていく必要がある。