ケースデザイン

準備フェーズにおけるケースデザインアクティビティの最初のステップは、ケースタイプバックログ（Case Type Backlog）を確認し、Microjourney^™ごとにケースタイプを作成して、MLP（Minimum Lovable Product）の優先順位を設定することです。 これは、開発計画に意味があるかどうかを確認するために重要です。

ケースデザインアクティビティの目的は、以下のとおりです。

• 開発フェーズに備えて、基盤となるケースタイプとケースタイプ間の関連性を作成する
• プロダクトオーナーと一緒にMicrojourneyの機能範囲を検証する
• ケースデザインで最初からベストプラクティスが適用されていることを確認する

目的の直接把握（DCO）セッションでビジネスアーキテクト、システムアーキテクト、およびプロダクトオーナーが協力し、ケースタイプをステージとステップにモデリングします。 このアクティビティでは、ケースタイプをコンポーネントパーツに分解します。

プロダクトオーナーとステップやステージについて合意したら、さらに話し合いを進めて、ケースタイプに関係するペルソナや、処理の完了までに必要となるデータオブジェクトについて定義します。 DCOセッションの最後には、プロダクトオーナーが検証するケースタイプが視覚的に表現されています。

ケースデザインのベストプラクティスを最初から導入するため、システムアーキテクト（SA）はDCOセッションでケースタイプの技術的な設計面をリードします。

SAは、ケースの設計において次のことが考慮されていることを確認します。

• ワークフロー
• ペルソナとチャネル
• データ
• 再利用
• 拡張

次の画像で「+」アイコンをクリックすると、ケースデザインのステージやステップが表示されます。

ステージとステップの組み合わせで、ケースのワークフローが決まります。 ほとんどのビジネスでは、いくつかの作業が組み合わせて行われます。

• ある作業は連続して行われます。
• ある作業は並行して行われます。
• ある作業はオプションで、特定の条件下でのみ適用されます。  

プロジェクト開始時には、作業タイプの違いがケースデザインに影響します。 プロダクトオーナーとのワークショップで得た知見をもとに、リードシステムアーキテクト（LSA）が技術的なベストプラクティスを検討します。 必要に応じて、追加のケースタイプが作成されることもあります（たとえば、子ケースを使って並行作業にするなど）。

ケースデザインについてもう一つ考慮する必要があるのは、作業の配分で、これはプロジェクトの早い段階で話し合っておきます。 作業の配分では、ケースタイプにリンクされるペルソナに向けて作業を送信する方法を定義します。 作業配分モデルを定義するには、ビジネスのオペレーションモデルを理解する必要があります。

作業の配分には2つのモデルがあります。

• プッシュ型モデル：プッシュ型モデルでは、システムマネージャーまたはチームマネージャーが手動で適切なユーザーに作業を割り当てます。
• プル型モデル：プル型モデルでは、一連のビジネスルールに基づいて自動的にユーザーに作業が割り当てられます。

Pega Express^™のアプローチでは、ペルソナはケースタイプのステージに関連付けられ、ケースのペルソナのインタラクションを表現します。 また、ペルソナは、そのペルソナがどのようにアプリケーションにアクセスするかを示すチャネルにも関連付けられます（例、メールやセルフサービスのウェブページを利用するなど）。 

Pega Platformではペルソナとチャネルを関連付けることができるため、チャネル固有のユーザーインターフェイス（UI）やプロセスに対応し、特定の状況に適したユーザーエクスペリエンスを実現できます。

準備フェーズで実行されるDCOセッションの一部として、プロダクトオーナーとビジネスアーキテクト（BA）は、ペルソナをステージにマッピングし、ケースタイプの範囲内でビジネスシナリオがカバーされるようにします。 ここで行われるディスカッションでは、特定のチャネルのペルソナによって形成できるインタラクションタイプを理解しておくことが重要です。 たとえば、セルフサービス型のチャネルでは請求を作成できるが、メールではできない、などです。 

ペルソナおよびチャネル別セキュリティー

データとプロセスの両方に対するアクセス権もケースタイプで定義されます。 以下のような場合には、アクセス権によりケースタイプの設計が影響を受ける可能性があります。

• 特定のチャネルから作業やデータを除外する
• 作業をケースタイプの中で異なるステージに分割する
• 全く新しいケースタイプを作成する  

セキュリティー要件に基づき、SAはセキュリティーニーズを満たすケースタイプの設計を決定する必要があります。

プロジェクト開始時にデータ需要に対応した設計を行うため、ケースタイプにリンクするデータオブジェクトについて高いレベルの理解が必要です。 

各データオブジェクトについて、システムアーキテクトは以下のことを理解している必要があります。

• 可用性と適時性
• リテンションとアーカイブ 

データの可用性とは、データのソースに言及しています。 一部のデータは外部システムから入手できる場合があります。 ユーザーは他のデータを直接収集できる場合もありますが、データによっては利用できないものもあり、ケース進行中に作成する必要があります。 データの適時性とは、他システムからどれだけすばやくデータを収集できるか、またどれだけ頻繁にデータが変更されるか、を意味しています。

データプライバシー要件についての意識が高まる中で、クライアントのデータの保持ルールは、ケースデザインに関連するデータモデリングアクティビティに直接影響します。 これらのルールを事前に特定するため、SAによるケースタイプの設計では、ケース内のデータ管理を最適化しておく必要があります。 

例：銀行業のワークフローでは、銀行情報は必要になるまで保持しないよう、ケースのできるだけ最後のタイミングで収集することが考えられます。 加えて、データを保持する業務上正当な理由がなくなった時点で、銀行詳細情報を削除する自動ステップをワークフローに含める必要があるかもしれません。

プロジェクト開始時に、他のケースタイプや後のMLPに役立つと思われるケースタイプの重要な領域を特定します。 これによりSAは、ケースタイプ全体、またはケースタイプの一部（特定のプロセス、データ、ユーザーインターフェイスなど）の再利用に対応するため、準備中のケースデザインアクティビティをガイドする情報を入手できます。 ベストプラクティスは、ビジネス部門と技術部門の共通点を見つけることです。 そして、その共通点を複数のケースタイプで使用するルールやコンポーネントとして規定し、設計します。

拡張できるケースタイプを設計するには、頻度やボリュームを考慮します。 また、ペルソナとケースタイプのインタラクションも考慮します。 

異なるチームメンバーが拡張できるケースタイプを設計するには、以下を行います。

• プロダクトオーナーとBAがワークフローを確認し、ケースタイプに導入する自動化のレベルを決定します。  
• システムアーキテクトは、ケースタイプでのデータアクセスと保存のメカニズムを考慮します。

頻繁に生成されるケースや大量に生成されるケースでは、最短時間で最高のスループットを実現できるよう、ストレートスルー処理が可能なケースデザインに集中します。   

ケースボリュームを認識することで、最初の設計ミーティングにおいてケースタイプでのデータの需要について検討できます。 この認識により、最初のケースモデリングで必要な変更が強調され、データアクセスを効率化また簡素化して、インターフェイスや応答時間に過度な負担がかからないようにできます。 

準備フェーズでは、これらの側面をユーザーストーリーとして記録し、プロジェクト中にさらに詳細にするためにバックログに追加します。 

次の問題に答えて、理解度をチェックしましょう。