製品バックログの作成

ビジネスの要件を視覚的に表現するDCO（Direct Capture of Objectives）をはじめとするPegaのベストプラクティスを活用して製品バックログを作成します。

Pegaソリューションは、次の2つの基本コンセプトに基づいています。

• 顧客が目標を達成するために組織と行うインタラクションを表すジャーニー、および
• 特定の顧客タイプがその目標を達成するために特定のデリバリーチャネルを通して行うインタラクションを表すMicrojourney™（マイクロジャーニー）。

Minimum Lovable Productを特定することで、ソリューション定義のプロセスを始められます。

Minimum Lovable Productとは顧客を満足させる最もシンプルな道筋です。

このMLPは、1つ以上のマイクロジャーニーで構成されます。

ソリューションを作成するための最初のステップは、ソリューションがサポートするマイクロジャーニーを特定することです。

ソリューションを作成する際には、各ジャーニーに対して次のようなシンプルなプロセスを行います。

• そのジャーニーの顧客の目標から始める
• その目標を達成したいと思っている各ペルソナを特定する
• それらのペルソナがその目標を達成するときに使用するチャネルを特定する
• この情報の有効な組み合わせを示したマトリックスを作成する

ケースタイプバックログに取りかかろうとしている場合、「Work Backlog」タブ（以下を参照）にこの情報が文書化されています。

Pega Infinity™を使用している場合は、マイクロジャーニーと補足情報がすでにこのツールの中に保存されている可能性があります。

たとえば、2つのジャーニーをマイクロジャーニーに分解するとします。

クライアントは、顧客に次のことを行える機能を提供することに主に関心があると言っています。

• 住宅ローンを初めて借りる
• 住宅ローンを借り換える

クライアントと会話する中で、各ジャーニーの適切なペルソナとチャネルのリストが浮かび上がってきました。

プロダクトオーナーや、事業部門の対象分野の専門家となる可能性がある他の人との会話を通して、特定のジャーニーでどのペルソナがどのチャネルを使用するかが分かりました。

以下に示すような、この情報のマトリックスを作成します。各行は、マイクロジャーニーの1つを表しています。

ソリューションを作成するための第2のステップは、特定したマイクロジャーニーに優先順位を付けることです。

マイクロジャーニーの優先順位は、次の3つの属性を考慮して決定します。

• 1つ目は、マイクロジャーニーのビジネス価値です。
  • つまり、特定のチャネルを通してペルソナに顧客の目標を提供することで、ビジネスにもたらされる価値です。
  • この価値は、プロダクトオーナーとの会話の中で特定できる可能性が高いでしょう。
• 2つ目は、マイクロジャーニーの実装で想定される難易度です。
  • この価値は、プロジェクトのリードシステムアーキテクト（LSA）または他の上級技術担当者との会話の中で特定できる可能性が高いでしょう。
• 3つ目は、マイクロジャーニーの実装に必要な推定工数です。
  • この価値も、LSAまたは他の上級技術担当者との会話で特定できる可能性が高いでしょう。

マイクロジャーニーのビジネス価値と、想定される実装の容易さ、つまり難易度と工数を組み合わせを考慮し、マイクロジャーニーの優先順位を決定します。

優先順位を割り当てるときに、マイクロジャーニーは次の4つのグループのいずれかに分類されます。

• 1つ目は、ビジネス価値が高く、実装がとても容易なマイクロジャーニーです。
  • これらのコンポーネントは、通常、最短の期間で最高の価値を提供できるため、最優先となります。
  • そのため、これらのコンポーネントは、最初のMLPリリースに含める最有力候補です。
• 2つ目は、ビジネス価値が高く、実装があまり容易ではないマイクロジャーニーです。
  • これらのコンポーネントの優先順位は、中程度です。1つ目のグループよりは実装が難しいものの、依然として高いビジネス価値をもたらすからです。
  • これらのマイクロジャーニーは最初のMLPリリースには含まれないことが多いものの、一般的にはそのすぐ後のリリースに含まれます。
• 3つ目は、ビジネス価値が低く、実装がとても容易なマイクロジャーニーです。
  • これらのマイクロジャーニーではもたらされるビジネス価値が低いため、優先度は低くなります。
  • しかし、実装に必要なリソースが少なくてすみ、ビジネス価値の低さを補える可能性があるため、これらのマイクロジャーニーは一般的によく実装されます。
• 最後は、ビジネス価値が低く、実装があまり容易でないマイクロジャーニーです。
  • これらのマイクロジャーニーは高い実装コストをかけることに見合ったビジネス価値がないため、一般的には実装されません。

マイクロジャーニーを使用してソリューションを定義する最後のステップは、マイクロジャーニーをMLPリリースにグループ化することです。

最初のMLPリリースは、通常はビジネス価値が高く、実装がとても容易なマイクロジャーニーで構成されます。

このグループのマイクロジャーニーを目標リリース日よりも前にすべて実装できた場合、リリースに別のマイクロジャーニーを追加するのではなく、すぐにデプロイしてください。目的は、真の価値をできるだけ早く提供することです。最大の価値をもたらすのは、価値が高く、実装が容易なマイクロジャーニーです。

目標リリース日を過ぎても優先度の高いマイクロジャーニーのすべてを実装する作業が続く場合は、優先順位を付けたマイクロジャーニーリストの一番上から順に、持ち時間の中で実装できるマイクロジャーニーをできるだけ多く入れて、MLP1の内容を定義します。

MLP1に入らなかった優先度の高いマイクロジャーニーは後続のリリースに含めることができます。最初のリリースのすぐ後かもしれません。

シンプルなソリューションにするために、通常、マイクロジャーニーはPegaで直接実装可能です。製品バックログは、スコープの小さいプロジェクトでは一般的には必要ありません。

しかし、その他のプロジェクトでは、デリバリーチームが使用できるようにマイクロジャーニーをプロジェクトバックログに変換する必要があります。

一般的に、プロジェクトが次の場合には製品バックログが必要です。

• 複数回のリリースでデプロイされる
• 厳しい規制のある組織向けである

こうしたタイプのプロジェクトでは、そのような作業を整理するのが非常に複雑なので、バックログが必要です。ビジネスニーズを文書化して優先順位を付け、たくさんのリリースやチームにわたる作業を管理し、監査の規制に対応するために裏付けとなるアーティファクトを提供するといった、あらゆることを行うには、シンプルなソリューションの実装に使用するプロトタイプ駆動型のアプローチで提供できるものよりも多くの段取りが必要です。製品バックログは、このような複雑なプロジェクトのニーズに対するスクラムの解決策です。

製品バックログを作成するための最初のステップは、MLP1向けの製品とリリースをAgile Studioで作成することです。

こうすることで、そのリリースのデフォルトのバックログも作成されます。

次の例ではAgile Studioを使用していますが、PegaはJIRAやTeam Foundation Serverなどの他のアジャイルプロジェクト管理ツールと連携して、ソリューションのデリバリーを管理できます。

これで、製品バックログを作成できました。次のステップは、Agile WorkbenchとAgile Studioにジャーニーを保存することです。

Agile Workbenchでは、ジャーニーはトップレベルの機能として保存されます。なぜ「トップレベル」かというと、機能をネストできるためです。ジャーニーは、その階層の一番上に置かれます。

Agile Studioでは、先ほど作成した製品の中のゴール（目標）としてジャーニーを保存します。

両方のツールでジャーニーを保存したら、次はマイクロジャーニーを保存します。

Agile Workbenchでは、マイクロジャーニーは第2レベルの機能として保存されます。つまり、親のジャーニーである第1レベルの機能の子になります。

Agile Studioスタジオでは、親のジャーニーであるゴール（目標）の下のエピックとして各マイクロジャーニーを保存します。

このプロセスの最後のステップは、ここまでに特定したマイクロジャーニーを実装するユーザーストーリーを作成することです。

これらのストーリーは、通常はAgile Workbenchで作成されます。

Agile Workbenchで作成されたユーザーストーリーは、自動的にAgile Studioにリアルタイムで同期されます。その反対も同様です。ユーザーストーリーに関しては、Agile WorkbenchとAgile Studioは常に同期されます。

ユーザーストーリーを収集する準備ができました。ではどのように取りかかればいいでしょうか。

Pegaのジャーニー中心のデリバリー手法では、ユーザーストーリーの収集と詳細化を行う際に推奨される方法は、Direct Capture of Objectives（DCO）の使用です。

DCOとは、業務部門とIT部門が協力してビジネス成果を達成する方法を改善しながら、そのビジネス成果を直接、視覚的に収集する機能を表します。

その中では、業務部門とIT部門が一緒に、機能やユーザーストーリーについて話し合い、議論の最中やその直後に、その機能の初期バージョンをPegaで直接作成します。

DCOとは、Pegaアプリケーションの一部として要件を保存することだけを意味するものではありません。

DCOはストーリーを詳細化するテクニックであり、より優れたソリューションをより早く提供できるようになります。

これは、Pega Platform™を活用して反復しながらソリューションを段階的に開発できるモデル駆動型アプローチです。

DCOは、組織のロードマップを念頭に置きながら、一度に1つずつのマイクロジャーニーでビジネス価値を提供することに焦点を当てるという考え方でもあります。

DCOは非常に多くの役割の人が貢献できる、共同作業が中心のプロセスです。

プロジェクトチームでは、次の人が活躍します。

• プロダクトオーナーは、主に各ストーリーについて情報提供し、その優先順位を決定します。
• ビジネスアーキテクトは、各ストーリーの文書化と、通常はDCOセッションの進行役を担当します。
• システムアーキテクトは、ストーリーを適切に実装できるように、各ストーリーのビジネスニーズを把握します。

組織の他の部門では、次の人が活躍します。

• 対象分野の専門家は、自身がよく知るビジネスプロセスについての具体的な詳細など、いくつかのストーリーに関する追加情報を提供します。
• テストリードは、テストチームが適切なテキストシナリオを作成できるように、各ストーリーをビジネスと技術の両面から把握します。
• ITアーキテクトは、各ストーリーを組織のITエコシステムに統合しなければならない状況に関係した背景情報とリスク分析を提供します。

DCOとは、ある時点のことを指すものではありません。プロジェクトの開始時からソリューションのリリースまでの期間に頻繁に使用するテクニックです。

準備フェーズ（プロジェクトの開始時に生じる活動）では、DCOを用いて、2スプリント分のユーザーストーリーを詳細化します。そうすると、デリバリーチームがプロジェクトの開始時点からすぐに全力でたくさんの作業を進められます。

開発フェーズでは、引き続きDCOを用いて、後続のスプリントで実装するユーザーストーリーを詳細化します。

また、DCOを用いて、現在のリリースで行った作業についてのフィードバックを収集することもできます。

DCOはツールではありません。しかし、DCOにはPegaのエコシステムのさまざまなツールが対応しています。

App Studioを利用すると、ソリューションのビジョンを実行可能なモデルとして開発できます。最初のDCOセッションで、クライアントは自身が説明しているソリューションのフレームワークを目にし、その中でソリューションが、最初からすぐに操作できるアプリケーションとして形になっているところを確認できます。

Integration Designerではデータのニーズと、そのデータの統合ポイントのステータスを明確かつ簡単に特定できます。また、ビジネスエンティティのデータタイプ、それらを表示するデータビュー、そのシステムオブレコードを定義してレポートを作成できます。

Agile Workbenchでは、レビューやデモを行ったときにストーリー、バグ、フィードバックをPegaのStudioに直接収集できます。新しいストーリーはAgile Studioなどのアジャイルプロジェクト管理ツールに自動的に同期されます。

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