AI支援ツールを使用してソフトウェア要件を定義する

Userdoc は、ソフトウェア要件ド​​キュメントの作成を支援する AI 支援サービスです。最近の AI エンジニア サミットで、Userdoc の創設者である Chris Rickard 氏と話をしました。

AI for Dev Tools からの翻訳: Userdoc を使用してソフトウェア要件を作成します。

AI コーディング ツールは現在ソフトウェア開発の標準となっていますが、生成 AI の使用は開発プロセスの他の側面にも広がっています。 Userdoc は、ソフトウェア要件を定義するための AI 支援サービスを開発したスタートアップです。先週サンフランシスコで開催された AI エンジニア サミットで、Userdoc の共同設立者兼主任開発者である Chris Rickard 氏と話をし、Userdoc を作成した当初の意図と、それが開発者にどのように役立つかについて話し合いました。

新しいプロジェクトでは、通常、1 つ以上の「ユーザー ペルソナ」のニーズを満たすためにソフトウェアが実装する機能を決定することが最初のステップになります。

「優れたソフトウェアを構築するための鍵の 1 つは、開発が正しい方向に進んでいることを確認するために正確な要件を定義することです」と Rickard 氏は言います。「私は、AI がこのプロセスを促進し、バグにつながる可能性のある問題や、さらに悪いことに、元の問題を解決しない、またはまったく必要のない大規模なシステム機能を発見するのに役立つ方法に興味があります。」

ユーザードキュメント

Userdoc を使用すると、ユーザーはまずビジネス関連の背景情報をコンテキストとして入力し、AI がユーザーのニーズを理解できるようになります。 Rickard 氏は、Userdoc を使用して配達ドライバーの要件を定義している食料品配達ビジネスの例を示しました。このようなシナリオでは、AI は開発者がシステムを構築するときに、ある程度の「監督」を提供できます。

「この場合、AI はビジネスアナリストのようなものです」とリカード氏は言います。「AI は状況の変化の影響を理解します。」

ChatGPT を使用して要件を直接定義する場合とどう違うのでしょうか?

これらはすべて素晴らしいように聞こえますが、Userdoc の AI 生成ソフトウェア要件は、ChatGPT を直接使用する場合と比べてどのように異なりますか?

リカード氏は、ChatGPT は「情報を捏造する」リスクがあると反論した。彼は、Userdoc は基盤技術として GPT-4 を使用しているが、ビジネス コンテキストが重要であると付け加えました。

「したがって、GPT-4 とやりとりする際には、他のすべての関連情報をコンテキストとしてシステムに提供します」と彼は言いました。

彼は、ChatGPT が同様の機能を実現できることを認めたが、Userdoc と同様の応答を得るには「巨大なプロンプト」を構築する必要があるだろうと述べた。

各 Userdoc プロジェクトには通常、ソフトウェアのさまざまな機能に対応する一連の「ユーザー ストーリー」が含まれています。システムに数百または数千の機能がある場合、状況は非常に複雑になる可能性があります。これは、Userdoc が解決しようとしている問題点の 1 つです。

「ここで解決しようとしている大きな問題の 1 つは、システムに多くの機能がある場合、[開発者] が考慮して覚えておく必要のある詳細がたくさんあることです。ソフトウェアのコストとスケジュールが超過する大きな理由は、人々が事前にそれらの小さな詳細を検討していないことです。」と Rickard 氏は言います。

ユーザードキュメントの使用

新しい Userdoc プロジェクトを作成するには、ウィザードを通じてユーザー情報とさまざまな要件を入力する必要があります。このセットアップ作業は通常、製品オーナー、製品マネージャー、ビジネスアナリストによって行われ、その後、プロジェクトは開発チームに引き渡されます。しかし、Rickard 氏は、Userdoc は開発者を直接支援することもできると述べました。

「機能と要件が定義されると、 [...] プロジェクト管理ツールと統合できます。 Jira、Azure DevOps などに接続し、作業項目のステータス (ToDo、進行中、完了など) と同期して、各機能の詳細を常に確認できます。」

ユーザードキュメントウィザード

Rickard 氏は、場合によっては開発者も要件の決定に関与すると指摘しました。したがって、開発者が Userdoc をどのように使用するかは、特定のビジネス ニーズに基づいて決定する必要があります。プロジェクトに戻った後も、優れた参考資料として役立ちます。

「私たちは、多くの並行プロジェクトを抱える多くの代理店と仕事をしています」と彼は言います。「開発者やデザイナーがプロジェクトの後半に戻ってきたとき、Userdoc を通じて実装する必要がある現在の機能をすぐに理解できます。」

Rickard 氏はまた、Userdoc 内の情報はシステムの「生きたドキュメント」にもなり得ると述べました。

「かなり詳細な要件から始めて、それをビジネスが参照できる唯一のバージョンとして最新の状態に維持すれば、それが [ソフトウェア システム] の正確な情報源になります。」

LangChainを検討する

AIエンジニアリングサミットに参加していたので、Rickard氏がAIエンジニアリングコミュニティで最もホットなツールを使用しているかどうかを知りたかったのです。 Userdoc は GPT-4 を使用しているため、OpenAI モデルと通信するための中間層として LangChain が使用されているかどうかを尋ねました。

「最初の Userdoc プロトタイプでは、LangChain を数週間使用しました」と彼は言います。「しかし、その後、舞台裏で何が起こっているのかをもっと理解したくなり、違いを理解するのに役立ちました。LangChain は間違いなく強力ですが、その強みは、ドキュメントをチャンク化して LLM に送信し、質問するなど、特定のタスクを処理するための便利な方法を提供することにあります。LLM と LangChain を同時に学習していたとき、2 つの境界を区別するのは困難でした。そのため、GPT-4 と対話するための一連のコンポーネントを自分で作成しました。」

ユーザードキュメント拡張機能

Userdoc が長期にわたってソフトウェアのドキュメントのソースとして使用できる場合、顧客支援チャットボット (たとえば、食料品配達サービス用) を提供するためにも使用できますか?

「答えはイエスです」とリカード氏は言う。「主な検討事項は、内部の知識と外部への開示の区別、そして情報セキュリティを守ろうとする人々の意欲です。」

彼は、Userdoc は現在ブートストラップされており、チームを拡大する場合にはソフトウェアのコンプライアンスに取り組みたいと指摘しました。そのため、彼はウェブサイトやアプリ向けの顧客チャットボットを作成するプロセスを繰り返すよりも、むしろこの方向で開発を進めたいと考えました。

「私は、ソフトウェア開発が、ビジネスが当初合意した要件を実際に実装することを保証するという考えを強く信じています」と彼は説明した。「開発者はさまざまな自動テストを使用できるようになり、AIがこの検証プロセスを強化できることを願っています。」