Directly Capture Objectives(DCO)
DCOの定義
Directly Capture Objectives(DCO)は、Pega Express™を使用して最初から最後までコラボレーションを行うための手法です。 DCOによりステークホルダー間の調整が促され、ビジネスチームとITチームの間で質の高いエンゲージメントを図れます。 DCOは手順、つまり、コラボレーション、イテレーション、検証の継続的なサイクルに沿って作業を行う手法です。 ビジネスチームとITチームが連携して、Pega Platform™を使って最終的なアプリケーションの形に到達できるよう段階的なモデル化を行います。
DCOでは次の事柄に重点を置きます。
- アプリケーションのデザインと開発
- ビジネス成果を上げる
- 人間中心のデザイン
- ビジネス価値をより短時間で実現するためのイテレーション
Pega Platformには、成果の把握、画面のデザイン、ワークフロー、フィードバックを行うためのビジュアルツールが用意されています。
- DCOとは、 メソッドであり、仕事の進め方でもある、 継続的なサイクル
- 主導するのは、 コラボレーション、イテレーション、バリデーション
DCOの重要性
DCOの手順を使用すると、アプリケーションに対するインサイトを得るために、ステークホルダー間の調整を行いやすくなります。 DCOを使用すれば、誤解が減り、ビジネスや機能の食い違いの発見が遅れるリスクを最小限に抑えることができます。 また、DCOですべてのキーパーソンに最初から参加してもらえるようにすることによって、デリバリーを全体的にスピードアップできます。
DCOでは、時間のかかる要件定義書を作成する必要はありません。 その代わりに、Pega Platform内でアプリケーションを開発するために必要なすべての情報を把握できます。これには、ビジネス上の成果からMicrojourney™を実装するための技術的なコンポーネントに至るまで、さらに次のようなビジネス要件が含まれます。
- バックログ
- エピック
- ユーザーストーリー
以下の項目についてコラボレーション、反復、検証することで、チームメンバー全員が、何を達成しようとしているか、それをどのように達成できるのかを理解します。
- ビジネス成果
- ケースタイプ
- ステージとステップ(ワークフロー)
- ペルソナ
- チャネル
- ユーザーインターフェイス デザイン
- データと統合
- エピック
- バックログ
- ユーザーストーリー
DCOの活用
DCOはPega Expressの配信アプローチで継続的に使用されています。 各フェーズ(発見、準備、開発、導入)でさまざまなアクティビティを行いますが、次の図のように、すべてのイベントでコラボレーション、イテレーション、検証を行います。
ここでは、各フェーズでコラボレーションして行われるさまざまなDCOのイベントを紹介します。
発見:
- ビジョンとビジネス成果の明確化を支援
- アイデアとプロトタイピングを支援
準備:
- アイデアとプロトタイピングを支援
- DCOセッションの実施
開発:
- DCOセッションの実施
- バックログの継続的な改善
- プレイバックとショー&テルのサポート
導入:
- DCOセッションの実施
- プロダクト改善
- ビジネス準備のための知識移転
- 次のMLPの特定
準備フェーズのDCO
準備フェーズを開始する際に、DCOは、MLP(Minimum Lovable Product)を構成するMicrojourneyの構造とデザインを検証するのに役立ちます。 DCOを使ってPega Expressで次の3つの柱を確認し、変換します。
- Microjourneyとケース
- ペルソナとチャネル
- データとインテグレーション
最初のDCOセッションでは、Pegaでドラフトケースタイプを作成することが中心となります。 ケースタイプの定義には、MLPのスコープ内で各Microjourneyの主要ステージとオルタネートステージを設定することが含まれます。 以降のDCOセッションでは、各ステージについて大まかに見ていき、Microjourneyに関連付けられている主要なステップ、ビジネスルール、データ要件を決定します。 準備フェーズの最初のDCOセッションでは、ユーザーアクセスや大まかなセキュリティー要件などのトピックを取り上げます。
DCOセッションが完了した時点で、エンドツーエンドのMicrojourneyの大まかなドラフトサマリーができ上がり、ビジネスチームと共有できます。 ビジネスチームは、期待されるビジネス成果が達成可能かどうかを検証します。 準備フェーズにおけるDCOセッションの目的は、MLPを開発することではなく、大まかなモデルにおけるチームの仮定を確認してMLPスコープの機能の境界を決定することです。
準備フェーズ中にビジネスレビューミーティングを行うために、Pega Platformでケースタイプをプレイバックします。 このセッションでは、ビジネスステークホルダーが、エンドツーエンドのジャーニーとMLPで考慮しなければならないすべての関連シナリオを検討するよう求められます。 ビジネスシナリオには、プロセスを通じて次の両方の種類の経路が含まれている必要があります。
- 「ハッピーパス」(理想的な経路)
- 主な「オルタネートパス」(代替経路)
補足: MLPのスコープを超えたシナリオを含めないように注意してください。
DCOセッション
ビジネスステークホルダーとの間で基本的なケースタイプを合意したら、最初のスプリントに備えて、バックログを作成し、優先順位の高いストーリーを詳細化し始めるために、追加のDCOセッションをスケジュールします。 最終的な成果物は、ユーザーストーリーの詳細化のための計画です。 詳細化のための計画では、スコープ内のケースタイプを仕上げるためのDCOセッションをスケジュールします。
補足: 最初のDCOセッションの主なインプットのソースは、発見フェーズで作成されたものです。 しかし、デザインスプリントが準備フェーズで実行されるようにスケジュールされていることもあります。 その場合、デザインスプリントで得られた出力を、準備フェーズで行われるDCOセッションの材料として使用します。
開発中のDCO
DCOは、プロジェクトの開発フェーズにおいても必要不可欠です。 チームメンバーは、ビジネスチームとの定期的なスプリント内プレイバックの中で、コラボレーション、反復、検証を続けます。 開発フェーズのセッションでは、構成の初期の成果をビジネスチームのメンバーに示します。 これにより、ビジネスチームが開発チームにフィードバックを返し、デリバリー検証のためのガイダンスを示す機会が与えられます。 このセッションは簡潔なもので構いません。 開発チームが結果を共有できるようになったら、すぐにセッションを開始します。
DCOは、Microjourney™内のケースタイプ、データモデル、ビジネスルールの詳細を常に進化させ、優先順位の高いユーザーストーリーのバックログを適切な状態にしておくためにも使用されます。
セッションは、詳細化のための計画に沿ってスケジュールされています。 セッションの形態は、その焦点に応じて変わるかもしれません。 一部のセッションは、ケースタイプ内のステップを明確にし、拡張することがその目的です。 ユーザーエクスペリエンスを洗練させることを目的とするセッションもあります。DCOセッションが、UIデザインや画面フローなど、デザイン思考の他の側面に焦点を当てたミニアイデアワークショップの形態を取ることもあります。
開発フェーズにおけるDCOセッションからの主な出力は、「準備完了」の定義を満たす、洗練されたユーザーストーリーです。 ストーリーには、ユーザーストーリーの情報ニーズをサポートするために、次のようなアーティファクトを含む追加ドキュメントが添付されていることがあります。
- UIとUXのモックアップ
- ビジネスロジックマップ
- ビジネスルール
- セキュリティーマトリクス
- ドキュメントその他
スプリントが進むにつれ、チームはテスト用にアプリケーションの更新をリリースします。 DCOの手順は、MLPのために定義された成果への貢献に応じて、課題のディスカッション、優先順位付け、バックログへの追加を行う課題トリアージプロセスをサポートします。
ヒント: 短時間のセッションを頻繁に行うことで、開発フェーズを通じてフィードバック、イテレーション、検証を確実に行うようにします。 チームは集中し、引き続き前に進むようにしてください。
DCOとApp Studio
Pega Platformには、チームがDCOセッションを最大限に活用できるように、数多くのスタジオと視覚化ツールが用意されています。 Pega Platformでは、開発内容の共有リポジトリを生成することでデリバリーをスピードアップでき、セッション後にドキュメントをアップロードするために何時間も費やす必要がなくなります。
次の画像で、「+」アイコンをクリックすると、App StudioなどのPegaツールがどのようにDCOと連携して要件をPega Platformに迅速に取り込むかを表示できます。
DCOの参加者
DCOのコアチームは、意思決定者(プロダクトオーナー)、ビジネスアーキテクト、システムアーキテクト、テスター、UXデザイナーなど、ビジネスチームの代表者を集めた少人数のチームにする必要があります。 これらのステークホルダーは、ビジネスからテクノロジーまで、さまざまな部署に所属していることに注目してください。 プロジェクトによっては、プロダクトオーナーにビジネススペシャリストのサポートが必要な場合もあります。 また、コアチームに対象分野のエキスパート(SME)を加えることもできます。
チームメンバー全員が全セッションに参加できることが理想的ですが、それができない場合もあります。 トピックによっては、システムアーキテクトを必要としないものもあります。 また、UXデザイナーが必要でない場合もあります。 特定のSMEによるサポートが必要な場合もあります。
DCOの参加者はコアチームに限定されません。 アプリケーションのデザインをサポートするために、ビジネスチームや技術チームのビジネスステークホルダーのアドホックなグループが必要になることもあります。 たとえば、セキュリティーをテーマにしたDCOのセッションでは、ITセキュリティーのスペシャリストに意見を求めることがあります。 同様に、ユーザーエクスペリエンスデザインの一環として、少人数のエンドユーザーを招いてプレイバックレビューを行い、デザインが妥当であるかどうかを確認することもできます。
スプリントの終わりには、ビジネスレディネスチームとトレーニングチームのステークホルダーがショーに参加してデモを行い、プロジェクトチームにフィードバックを提供するとともに、導入フェーズに向けて自らのスキルを高めていくこともあります。
ヒント: 参加率を高めるためには、DCOのスケジュールについてプロダクトオーナーのアグリーメントを得ること、また、重要な参加者が関連セッションに参加できるように十分な告知をすることが必要です。
次の画像で「+」アイコンをクリックすると、プロジェクトチームの各ロールについて詳細が表示されます。
DCOの実践
DCOセッションを最大限に活用するための準備をします。 事前に参加者を招待し、アジェンダを用意し、DCOのアーティファクトを集めるなどの簡単な手順を踏んでおくことで、セッションからより多くの成果を生み出すことができます。 参加者が事前に準備できるように、各セッションの目的を明確にする必要があります。
ビジネスチームの代表者がセッションに向けて準備できるように、その代表者とSMEにDCOのトピックに関する情報をできるだけ多く提供しておきます。 たとえば、ユーザーストーリーと未解決の質問のリストなどを最初に渡します。 これにより、ビジネスチームはセッション前に主題に関連する事項を調べておくことができます。
また、セッションがうまく進行するように、事前にプレゼンテーションやスケッチ、フリップチャートを作成または収集したり、アクティビティを実行したりします。 App Studioを使用してDCOセッションを進める際には、次のような事前の準備が完了していることを確認してください。
- プロセスの実行 - エンドユーザーエクスペリエンスをよく理解し、今後開発すべきものを把握します。
- プレイバック - 状況によっては、DCOセッション参加者へのプレイバックを一時的に変更することを検討します。
1日の大半を占めるような大規模なDCOセッションをスケジュールしたくなるかもしれませんが、 短いセッションを繰り返し実施する方が、参加者が集中できます。 ベストプラクティスによれば、短時間で集中的に行うセッションは参加率が高く、持続性があります。なぜなら、丸一日かかるイベントの場合、チームメンバーが参加し、集中力を維持することが難しいからです。
DCOセッション
優れた会議がすべてそうであるように、DCOセッションも、会議の目的を確認し、参加者に問題と背景を理解してもらうためのアジェンダから始まります。 ビジネスアーキテクトは、プロダクトオーナーとSMEのサポートを受けながらセッションをリードします。 両者が協力し、適切なビジュアルツールを使って、たとえば以下のようなトピックについてディスカッションを行います。
- ユーザーストーリー
- プロセス
- ビジネス要件
コアチームは、システムアーキテクトやユーザーエクスペリエンスデザイナーと協力して、デザインが技術的に実現可能であり、すぐに使える機能を活用していることを確認します。 また、ユーザーを中心に考えたデザインであることも確認します。 テスターは、すべての出力がテスト可能であることを確認することでディスカッションに貢献します。
Pega Platformを活用すれば、ディスカッションの結果を素早く文書化できます。 一部のDCOセッションでは、セッション中に要件をPega Platformに直接取り込むことができます。 これにより、セッション中に要件をプレイバックし、間違った解釈を解消し、食い違いや見落とした要求を特定できます。
セッションによっては、セッション中にディスカッションの内容をホワイトボードに書き出し、フォローアップDCOイベントを準備してユーザーにソリューションのデモを示す方が早いかもしれません。 ユーザーにとっては、ドキュメントに書かれている文章を読むよりも、目で見て確認する方が、アプリケーションに対するフィードバックをしやすくなります。 セッション中に解決すべきすべての論点と、必要なアクションで未対応のものをメモしておきます。 また、フォローアップアクティビティや要求される関連アーティファクトを文書化します。
DCOセッション終了後
ベストプラクティスでは、セッション中にDCOアーティファクト(ユーザーストーリーなど)に対するすべての決定や更新を、Agile WorkbenchやApp Studioに直接適用します。 DCOセッション終了後に出力を確定させる必要があるセッション(プロセスの図やワイヤーフレームなど)では、アーティファクトを更新し、関連するユーザーストーリーにできるだけ早く追加します。 次に、アーティファクトが追加された旨を知らせるメッセージをチームメンバーに送信します。
未解決の問題に答えたり、新しい調査を開始したりするなどのフォローアップアクティビティがあります。 DCOセッションを挟んで行われるすべてのフォローアップアクションを記録して監視し、DCOスケジュールに沿って参加者に情報を渡します。
ヒント: 詳細化のためのスケジュールに変更があった場合はその旨を通知し、ユーザーストーリーの最新バージョンでバックログを更新します。
次の問題に答えて、理解度をチェックしましょう。
このトピックは、下記のモジュールにも含まれています。
If you are having problems with your training, please review the Pega Academy Support FAQs.