注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
ユースケースとは、特定のユーザー向けにプラットフォーム上で新たな機能を提供するための限定的なチームによる期間限定の努力です。
ユースケースは、「ソースシステムXを統合する」や「ML技術Yを適用する」ではありません。代わりに、ユースケースは、途中の実装の詳細ではなく、ユーザーに提供する必要がある機能に焦点を当てます。開発作業をユースケースとして枠付けることで、プロジェクトの価値提案に直面するようになります。この新機能によって誰の仕事が改善されるのか?そして、成功したかどうかを知るために何を測定すべきか?
ユースケースを構築する途中で、Foundryの多くの累積的な機能を解放します。たとえば:
ユースケースとその結果をガイドとして持つことで、Foundry全体での特定の実装の複雑さに入り込んでも、現実世界の価値につながり続けます。
Foundryでユースケースを開発する技術は、成果の機能要件を分解し、各コンポーネントの実装パターンを選択することに関連しています。
以下に説明するソリューション設計プロセスは、この課題へのアプローチです。ユースケース要件をインターフェースの実装とデータの豊富さについての決定を導く形式に絞り込むことに焦点を当てています。これらの決定は、ユースケースAPIとして機能し、パイプライン実装の詳細をエンドユーザーのインタラクションから抽象化するオントロジーデザインに影響を与えます。
このように、ソリューション設計フレームワークは、以下の画像に示すような全体的なアプローチを奨励します:
ソリューション設計を、ユースケースデータの変換、構造化、およびインタラクション周りのバケットに分けることで、開発プロセスを純粋にユーザー中心の要件からプラットフォーム中心のコンポーネントに転換します。このフレームワークを用いて、以下を見ることができます:
開発の複雑さとビジネス要件への厳格な遵守との間のトレードオフを判断することもできます。ソリューション設計フレームワークを通じて作業を進めることで、優先順位を再評価することが可能になります。
例えば、元々のビジネス要件が特定のチャートを描画し、特定のフォーム入力を含めることを要求しているとします。これには、奇妙なオントロジーの設定と、Slateでの大規模な開発努力が必要かもしれません。しかし、代わりにこれらの機能的に等価な視覚化とアクション(機能要件を満たす)を作成した場合、フロントエンド開発への投資を1/10に抑え、オントロジーのデータ構造をきれいに保つことができます。
次のセクションでは、ユースケースの説明をキャプチャし、これらの機能要件を抽出する方法を見ていきます。