注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
ユースケースとは、専任チームが期限を設けて取り組み、ユーザーに向けてプラットフォーム上で新しい機能を提供する活動です。
ユースケースは、「ソースシステム X を統合する」や「ML 手法 Y を適用する」といったものではありません。ユースケースは、実現に至るまでの実装の詳細ではなく、ユーザーに提供する必要がある機能に焦点を当てます。開発作業をユースケースとして捉えることで、プロジェクトがどのような価値を提供するのかに、最初から向き合うことになります。この新しい機能によって、誰の業務が改善されるのでしょうか。また、成功したかどうかを判断するために、何を測定できるでしょうか。
ユースケースを構築する過程では、Foundry の機能を組み合わせることで相乗効果を生む、次のような多くの機能を活用できるようになります。
ユースケースとその成果を指針とすることで、Foundry 全体で個々の実装の複雑さに踏み込んでも、実世界での価値とのつながりを保てます。
Foundry でユースケースを開発するには、成果に必要な機能要件を分解し、コンポーネントごとに実装パターンを選択します。
以下で説明するソリューション設計プロセスは、この課題に対するアプローチです。ユースケースの要件を、インターフェースの実装やデータの拡充に関する判断に役立つ形式に整理することに重点を置いています。これらの判断は、さらにオントロジーの設計の指針となります。オントロジーはユースケースの API として機能し、パイプラインの実装の詳細をエンドユーザーのインタラクションから抽象化します。
このように、ソリューション設計フレームワークは、下の画像に示す包括的なアプローチを促します。

ソリューション設計を、ユースケースのデータの加工、構造化、データとのインタラクションという区分に分けることで、開発プロセスの軸を、ユーザーだけを中心とした要件から、プラットフォームを中心としたコンポーネントへと移せます。このフレームワークを使うことで、次の点を検討できます。
また、開発の複雑さとビジネス要件の厳格な遵守とのトレードオフも評価できます。ソリューション設計フレームワークに沿って検討を進めることで、優先順位を再評価できるようになります。
たとえば、当初のビジネス要件が、特定のチャートを表示し、特定のフォーム入力を含めることだとします。この要件を満たすには、変則的なオントロジー設定と、Slate での多大な開発作業が必要になる場合があります。代わりに、機能的に同等の可視化とアクションを作成する(機能要件を満たす)なら、フロントエンド開発への投資を10分の1に抑えて Workshop を使用でき、より整理されたオントロジーのデータ構造を保持できます。
次のセクションでは、ユースケースの説明を記録し、これらの機能要件を整理する方法を取り上げます。