ソリューション設計

機能要件を定義すると、ユースケースで実装する必要があるコンポーネントを抽出するための材料が得られます。これにより、要件を満たすために何を提供する必要があるかを理解でき、実装の選択肢を評価する際に扱いやすい小さな単位に分けられます。

機能要件からコンポーネントを抽出する

ソリューション設計プロセスの次のステップでは、機能要件を Foundry で実装できるコンポーネントにマッピングし、その設定の選択肢を比較検討します。このステップはユースケースによって異なりますが、次のコンポーネントは幅広く役立ちます。

• オブジェクトモデル： コア、派生、ユースケースのオブジェクトタイプとそのリンクタイプを特定するオブジェクトモデルの概略図です。
• ライフサイクル図： ユーザーがオブジェクトを変更するために実行するアクションを示す状態遷移図です。
• エンリッチメント： 意思決定の入力に必要な情報を提供するためのデータエンリッチメントの一覧です。
• インターフェースに対する期待： インターフェースとその目的を整理したものです。

これらのコンポーネントは機能要件から抽出できます。たとえば、次のようになります。

航路運用アナリスト（ユーザーの種類）が、担当する航路のアラート受信トレイ（インターフェース）を確認し、優先度、フライトと航路の詳細、組織への影響（意思決定の入力）に基づいてアラートをトリアージ（意思決定）し、各アラートを再割り当て、解決、またはエスカレーション（アクション）します。

• アラート受信トレイ： 新しいアラートを確認するための独立したインターフェースが必要です。
• 担当する航路： 航路、ユーザー、およびそれらの関係を表す概念がデータ内に必要です。
• アラートをトリアージ： さまざまな状態を遷移でき、現在の担当者を表すオブジェクトが必要です。また、何らかの方法でアラートを生成する必要もあります。
• 優先度、フライトと航路の詳細、組織への影響： フライト、航空会社、航空機などに基づく、航路に関連した追加データが必要です。また、アラートの優先度と組織への影響という概念を反映するエンリッチメントも必要です。
• 再割り当て、解決、またはエスカレーション： Alert オブジェクトタイプの完全な状態遷移を定義するアクションが必要です。

ほかの機能要件についてもこのプロセスを繰り返すと、次のコンポーネントが得られます。

• オブジェクトモデル
• ライフサイクル図
• エンリッチメント
• インターフェースに対する期待と目的

オブジェクトモデル

この図は、機能要件に含まれる概念を取り込んだオブジェクトモデルを表しています。円はオブジェクトタイプを表し、円を結ぶ線はリンクタイプを表します。詳細度に応じて、各オブジェクトタイプの主キープロパティと、各リンクタイプのカーディナリティ（1:1、1:N、または N:N)）を特定することを検討します。

色によって、オントロジーのコアとなるオブジェクトタイプ（信頼できる情報源から取得したデータの粒度に直接対応するもの）と、派生オブジェクトタイプ（エンリッチメントとして作成する必要があるもの）を識別しやすくなります。また、ユースケースの業務ワークフローを通じて積極的に編集されるユースケースオブジェクトタイプも色で識別できます。

この例では、ソースシステムまでさかのぼると、Flights、Aircraft、Airlines、Airports に関するデータの正式な記録システムを特定できます。パイプラインでは、これらの概念を反映したコアオントロジーを作成できます。

ただし、「航路」に関するデータを持つソースシステムはありません。トランスフォームの区間では、オントロジーに航路の概念を反映するために、航路ごとに1行を持つデータセットを導出します。

ユースケースの業務面では、組織を反映したデータモデルが必要となるため、チームと従業員のオブジェクトタイプを用意します。また、アラート用の「チケット」オブジェクトタイプや、コメントとアップロードされたファイルを記録するための関連オブジェクトタイプなど、標準的な構成要素となるオブジェクトタイプも必要です。

ライフサイクル図

この簡略化した図では、アラートチケットオブジェクトが取り得る状態と、状態間の遷移を引き起こすアクションを示しています。ユースケースが進むにつれて、各アクションで記録されるメタデータや、アクションが利用可能になる条件と実行できるユーザーを定義する検証も含めるように、追跡内容をさらに詳細化できます。

エンリッチメント

機能要件とオブジェクトモデリングの作業を通じて、オブジェクトレベルとプロパティレベルのエンリッチメントを特定できます。オブジェクトレベルのエンリッチメントは、ソースデータに必ずしも反映されていない、新しく導出された概念です。これらは、航路オブジェクトタイプのような外部の概念に対応する場合もあれば、アラートチケットのような業務やユースケースに固有の概念である場合もあります。

プロパティレベルのエンリッチメントは、組織のルールを適用したり、より細かい粒度のデータを集計したり、モデルを実行したりすることで、既存のオブジェクトタイプに新しいデータを追加します。この例では、各アラートチケットの優先度と、組織への影響の推定値を反映する必要があります。

インターフェースに対する期待と目的

機能要件全体を通じて、ユーザーが持つさまざまな目的と、それぞれに対応するインタラクションへの期待を特定できます。目的と期待を特定することで、実際の実装と対応するツールの一覧を作成できます。

この例では、次のようになります。

• 業務ユーザーは、必要なアラートだけを確認でき、重要なコンテキストがすべてすぐに利用できる、ガイド付きの独立した操作環境を期待しています。目的は、直接アクションを実行することです。
• アナリストは、自分の割り当て済みおよび調査中のアラートをすべてすばやく確認でき、アドホックなデータ探索や分析に簡単に移行でき、調査の経緯を記述できる場所を期待しています。目的は、分析と文書化です。
• 経営層のユーザーは、業務プロセスの有効性を示し、時間の経過に伴う変化を強調表示するダッシュボード表示を期待しています。目的は、理解することです。

実装の選択肢

ユースケースの構成要素を整理したら、次は各要素の実装方法を決めます。上の図は、一般的な構成要素に対するデフォルトの選択肢を見つけるのに役立ちます。

たとえば、前述のインターフェースに求められる要件は、次のように分けられます。

スタンドアロンの受信トレイアプリケーションは、Workshop プロジェクトとして実装します。多くのインタラクションは1件のチケットに関するものなので、個々のチケットの Object View では、意思決定に必要なコンテキストと、適切なアクションへの容易なアクセスの両方を、統一されたビューで提供する必要があります。経営層向けのダッシュボードは、Quiver テンプレートから始めることもできます。レビューと監督のプロセスが改善されるにつれて、このテンプレートは別の Workshop モジュールへと発展し、定期的な追跡と承認のために、ユースケースのオブジェクトタイプが追加されることもあります。ほとんどの場合、Carbon ワークスペースを使うと、検索や探索に必要なオブジェクトタイプのサブセットとカスタムインターフェースをまとめ、想定されるすべての種類のユーザーに、洗練された、統一性があり利用しやすい体験を提供できます。

これらの選択肢についての検討事項の詳細は、パイプライン、オントロジー、アプリビルドのドキュメントに記載されています。以下では、実装上の判断がこれらのセクションにまたがる領域に焦点を当てます。

その代表的な例が、特定したエンリッチメントをどこに実装するかという判断です。

エンリッチメントを実装する

Route オブジェクトタイプのエンリッチメントと、各ルートについて把握したいメトリクスの例を考えます。平均飛行時間、到着の遅延が30分を超えた件数、飛行時間のばらつきを表す指標です。

1つの方法は、アプリケーション内でこれらを算出することです。たとえば、Flights オブジェクトタイプを出発空港と到着空港でグループ化したピボットテーブルを作成し、平均飛行時間を計算できます。最初に遅延が30分を超えたフライトに絞り込めば、同様にピボットテーブルで、ルートごとの遅延したフライトの件数を表示できます。

この方法にはいくつかの欠点があります。メトリクスは特定のインターフェース内で計算されるため、再利用できません。また、ページの読み込み時に評価する必要があるため、パフォーマンスが比較的低下する場合があります。さらに、メトリクスは一時的なものなので、その後の絞り込みや分析には使用できません。この方法の利点は、計算が動的に行われるため、アクションによって新しい値が追加されたり、値が更新されたりすると、その変更を即座に反映してメトリクスが更新されることです。

単純化しすぎた目安かもしれませんが、エンリッチメントが、ユーザーがアクションを通じて変更できるデータに依存しない場合は、データレイヤーでエンリッチメントを作成します。