システムデモ

Base milestones on objective evaluation of working systems.

—Lean-Agile Principle #5

定義、システムデモは、ART上のすべてのチームによって提供された最新のイテレーションの新しいフィーチャーを統合したビューをステークホルダーに提供します。 各デモは進捗状況を客観的に測定し、フィードバックを行う機会を提供します。

システムデモとは何か？

システムデモは、アジャイルリリーストレイン (ART) の最新のイテレーションでチームが提供する新しいフィーチャーを統合したビューをステークホルダーに提供します。 各システムデモはPIの目標に向けた客観的な進捗状況の測定をフィードバックを行う機会と共に提供します。

システムデモは、アジャイルリリーストレインのオペレーションにおいて重要な役割を果たし、ARTの全員が参加します。 これは、イテレーション内における各アジャイルチームの特定の成果物に焦点を当てているチームのイテレーションレビューとは対照的です。 通常イテレーションレビューには、アジャイルチームとそのチームの仕事に関与するステークホルダーのみが参加するからです。

システムデモにおいては、ART上のアジャイルチームは彼らが取り組んできたフィーチャーを、本番に近い環境からデモします。 これは、タスクを確認したりステータスレポートを作成する代わりに、進捗状況の客観的な測定を提供します。 定期的に動作するシステムをデモすることは、欠陥や設計上の問題を早期に特定するのにも役立ち、それらを修正するコストと手間を削減します。 また、それは時間の経過とともに改善するための新しいアイデアも生み出します。

システムデモには、ARTのチームに加えて、ビジネスオーナー、主要なステークホルダー、そしてしばしば顧客が参加します。 このようにして、定期的なケイデンスでプロダクトとソリューションの現在の状態について共通認識を得る機会を作り出します。 システムデモは、問題や機会を早期に特定するための安全なスペースを作り出します。 ステークホルダーに向け、開発中のフィーチャーの潜在的なベネフィットを明確に表現することに特化した時間です。 システムデモ中に提供されたフィードバックは、アジャイルチームの将来のイテレーションの仕事に役立ちます。

システムデモは、ARTのアジャイルチームにもベネフィットをもたらします。 統合されたシステムを示すことで、チームは自分たちの仕事が全体のソリューションにどのように貢献しているかを理解し、最適化することができます。 各アジャイルチームは他のチームの仕事を見ることができ、コラボレーションと知識共有を促進します。 アジャイルチームはデモでステークホルダーから即時のフィードバックを得ることにより、迅速な変更を行い、重要なことに集中することができます。 これはムダな努力を減らします。

複数のARTが関係する大規模なソリューションの場合、このシステムデモはより広範なソリューションデモの一部となります。 ソリューションデモには、すべての関係するARTが参加します。

システムデモはどのくらいの頻度で行われるか？

システムデモは、各イテレーションの終わりに行われます。 それは、イテレーションの終わりにできるだけ近いタイミング、つまり次の日などにて行われます。 統合の遅延は学習を著しく妨げ、進捗状況の誤った理解を生み出します。 これを達成するために、ARTはデモが定期的に実施されるように必要な努力をすることが奨励されています。 システムデモの遅延は、より良い統合実践を行う必要やシステムチームのための追加リソースの必要性など、根底にある問題を示している可能性があります。 これらの課題に迅速に対処することは、ワークフローと成果を大幅に向上させます。

時には、タイムリーな統合とシステムデモは、リーンとアジャイル手法に移行中の組織や、より複雑なサイバーフィジカルソリューションを開発している組織にとってチャレンジとなることがあります。 それは普通におきることであり、スコープや統合の範囲を縮小する理由にはならないはずです。 ARTが成熟するにつれて、ほとんどのチャレンジは消えていくでしょう。 すべてのイテレーションでの完全な統合のコストが高すぎる場合、チームは次のことを検討するべきです。

• 特定のフィーチャーや非機能要件 (NFR) を示すために、ケイパビリティ、コンポーネント、またはサブシステムのサブセットを統合する。
• 物理的またはデジタルプロトタイプを使用して、不足しているまたは高価なコンポーネントの代わりとして部分的に統合する。
• 統合とテストをスピードアップするためにテストダブルを作成する。
• それがより頻繁に行えるようになるまでは、統合の頻度を減らす。（例えば、イテレーション２回ごとに１回の統合）
• システムチームをARTの専任とし、頻繁に統合するために必要なインフラストラクチャとケイパビリティを整備する。

各イテレーションのシステムデモに加えて、ARTは最終的なPIシステムデモを開催し、PIで開発されたすべてのフィーチャーを示します。 このイベントはインスペクト＆アダプト (I&A) イベントの重要な部分です。

システムデモには誰が参加するか？

ARTのすべてのメンバーは、可能な限りシステムデモに参加します。 さらに、多様なステークホルダーからのフィードバックは、ARTを効果的に導く上で重要な役割を果たします。 

通常、出席者には以下のような人物が含まれます。

• デモの運営を担当するプロダクトマネージャーとプロダクトオーナー
• 通常ステージング環境でデモの設定を手伝うシステムチームの一員または複数のメンバー
• ビジネスオーナー、エグザクティブスポンサー、顧客、および顧客代理人
• システムアーキテクト、IT運用、および他の開発チームからの参加者
• 可能な限りARTアジャイルチームのメンバーが参加

参加者は進行を観察するだけでなく、貴重な気づきを積極的に提供します。

ビジネスオーナーとプロダクトマネージャーは、仕事が顧客とビジネスのニーズをどれだけ満たしているかを共有します。 アジャイルチームのチームメンバーは技術的な提案を行い、さらなる改善の機会を強調し、顧客バリューを高めるためにチーム間のコラボレーションを促進する方法を提供します。 システムチームのメンバー、システムアーキテクト、およびIT運用担当者は、ソリューションのベクトル合わせが喫緊のおよび戦略的な技術目標と包括的な視点で一致していることを確認します。

どのようにシステムデモをファシリテートするか？

RTEは通常、ARTの他のメンバーが積極的に参加するシステムデモをファシリテートします。 ARTに参加している誰でも仕事の成果を発表できます。 複数のチームからのチームメンバーは、統合された機能を一緒にデモするためにしばしば協力します。

システムデモは、時が経つにつれて進化していきますが、最初のアジェンダの例を次に示します。

オープニング - 簡単な導入から始めて、システムデモのコンテキストを提供する。

フィーチャーのライブデモ - PIオブジェクティブと期待されるビジネスおよび顧客ベネフィットとの関連を強調する。

質問とフィードバック - ディスカッションのためのスペースを作る。

リスクと阻害要因を特定する - 提起されたリスクと阻害要因に対処するための次のステップに合意する。

結論 - システムデモからのアクションを要約する。 残りのPIの計画を簡単にレビューする。

システムデモを1時間以内に抑えることで、参加者の関与を維持するのに役立ちます。 それは、最近のART全体の仕事によるビジネスと顧客へのベネフィットを示すのに十分な時間です。 そして、強い影響力のあるフィードバックを得るための集中した参加を促します。

本番に近い環境から直接実際にテストされた機能を示すことで、広範な準備やプレゼンテーションに頼るよりも、デモがより本物で焦点を絞ったものになります。 システムによるインパクトを示すデモンストレーションを取り入れることで、ソリューションのバリューと効果を参加者にさらに強調することができます。

システムデモの成功に向けて、下記に追加のヒントを示します。

• スライドではなく、実際に動作するフィーチャーを見せる。
• システムアーキテクチャがどのように発展しているか、そしてNFRがどのように適用されているかを示す。
• イベントの前にARTとステークホルダーにデモする項目の概要を提示する。

システムデモから学んだことをどのように適用するか？

システムデモの目標は、すべてのARTメンバーが最新の開発経験から学び、必要に応じて今後のアクションを調整することです。 システムデモは迅速なフィードバックを提供し、そしてそれに対し適切にアクションを取る必要があります。

チームまたは複数のチームがシステムデモで特定のフィードバックを受け取ると、SAFeの次のようなイベントがそれに対しての行動を支援します。 チームレトロスペクティブは、パフォーマンスを評価し、システムデモのフィードバックを議論して改善点を特定し、アクションプランを作成する機会を提供します。 イテレーションプランニング中における前回のシステムデモからのフィードバックは、次のイテレーションにおける優先順位決定に役立ち、それにより新しいストーリーを作成する必要が出てくるかもしれません。

ARTシンクは、RTE、スクラムマスター/チームコーチ、プロダクトマネジメント、およびプロダクトオーナーがシステムデモからのフィードバックを議論し、必要なアクションに整合するための重要な機会です。 ARTバックログリファインメントとPIプランニングは、複数のチームに影響を与えるフィードバックのための新しいフィーチャーを作成する機会を提供します。

システムデモからのフィードバックと取られたアクションは、ARTの継続的な改善の過程における重要なステップです。

---

参考資料

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.