システムデモ

動くソフトウェアこそが進捗の最も重要な尺度です。─アジャイル宣言
テストが済むまで動くといえるものは存在しない……
─SAFeの前提

システムデモの概要

SAFeにおいて、アジャイルリリース列車(ART)の進捗を測定する一番の手段はシステムデモである。これは、ARTが構築している対象のシステムについて、2週間ごとに実施される。システムデモが重要であることはいくら強調しても大げさではない。作業をしている人や、スポンサー、利害関係者、顧客から、直接にARTレベルのフィードバックを得る手段である。直前の反復ですべてのチームが行った作業を完全に統合したこのデモは、価値とベロシティーと進捗を本当の意味で測定する唯一の機会である。

システムデモを効果的に計画し実施するには、チームの側でもいくらかの作業が必要だが、適切なソリューションを構築するために必要な素早いフィードバックを得るにはこの方法しかない。

詳細

システムデモの目的は、アジャイルリリース列車の作業対象である完全なシステムをテストし評価することと、主要な利害関係者(ビジネス責任者、経営スポンサー、他のアジャイルチーム、開発管理、顧客、顧客の代理など)から開発中のソリューションの有効性および使いやすさについてフィードバックを得ることである。このフィードバックは非常に重要である。列車が軌道を外れないようにしたり是正措置を取ったりするために必要なフィードバック(図1)を提供できるのは、彼らだけだからである。

システムデモ反復の終わりごとに行われる。ここで、列車上のすべてのチームが直近の反復で納品した新しいフィーチャーを統合した、全体のビューが示される。ARTはここで、プログラムインクリメント(PI)内における最新のシステムレベルの進捗を、事実をもとに測定することができる。このデモはARTのベロシティーを本当の意味で測定する唯一の機会である。これを実現するために、チームは、ART全体の統合と同期をサポートできるよう、規模の拡大に対応できるエンジニアリングプラクティスを実施しなければならない。

各PIの終わりに、特別なシステムデモが行われる。PIの間に開発されたすべてのフィーチャーを集めたものをデモするため、これはいくらか構造化された公式なイベントとなる。このデモは、通常、検査と適応ワークショップの一部として行われ、その結果が、振り返りやPI進捗のさまざまな測定(予測性の測定など)の入力情報となる。

注:明確になるよう補足すると、システムデモは列車上の全チームの作業を統合したデモである。これは、やはり各反復の終わりにチームがローカルで実施するチームデモの代わりではなく、チームデモに追加して行われる。複数のARTから構成される価値のストリームの場合、システムデモを集約したものとしてソリューションデモが行われる。

システムデモのタイミング

システムデモは、反復の終わりにできるだけ近い時点で開催する。理想的には翌日である。しかし、以下のような複雑な事情によりそれが現実的でない場合もある。

  • 完全な統合作業の成果を使用できるのは、通常、反復の終了時だけである(もちろん全段階を通じて継続的インテグレーションを行うことが目標であるが、常にそれが可能なわけではない)。
  • さらに、新しいインクリメントごとに、デモ環境の拡張や、新しいインタフェース、サードパーティコンポーネント、シミュレーションツールなどが必要になるかもしれない。もちろん、システムチームとアジャイルチームは計画を立ててそれに対処するが、いくつかの項目が後で出てくることは避けられない。

それでも、システムデモは遅くとも次の反復の期間内に行わなければならない。そうでなければチームへのフィードバックが遅くなり、プログラムインクリメントが危険な状態になりかねない。システムデモをいいタイミングで実施できるよう、ARTは必要なあらゆる投資をしなければならない。

統合の工数とフィードバックのバランス

システムデモの目的は、直近に実施した開発から学習し、行動方針を調整することである。しかし、ARTの対象とするものがソフトウェアや、ハードウェア、機械装置、サプライヤーから提供されるコンポーネントなどにまたがる場合、2週間ごとにすべてを統合すると、必要な処理能力が大きすぎたり、処理コストが容認できる範囲を超えたりすることがある。単純に言うと、そのような環境での継続的インテグレーションは、経済的または実際的でない可能性がある。

それでも、統合を行わない、または先延ばしにするのは問題がずっと大きい。学習が著しく妨げられ、間違った安心感やベロシティーの原因になるからである。そのため、完全な統合を行うのが実際的でない場合には、適切なバランスを見つけること、統合とテストの自動化を継続的に進めて今後の統合コストを減らすことが重要である。図2は、統合作業のコスト最適化のU字曲線である。

図2.  統合のコスト最適化のU字曲線

反復ごとに完全な統合をするとコストがかかりすぎる場合には、チームは以下を検討するべきである。

  • システム能力、コンポーネント、サブシステムのサブセットを統合する。
  • 特定のフィーチャー、システム能力、または非機能要求(NFR)を見せられるよう必要な範囲を統合する。
  • プロトタイプやモックアップを利用して統合する。
  • 反復1回おきに統合する。

また、リーンおよびアジャイルな手法に移行しつつあるグループにとっては、頻繁な統合が難しい課題であるのは当然だと覚えておくことも大切である。これはごく普通のことであり、統合の範囲や程度を縮小する言い訳にしてはならない。列車が成熟するにつれてほとんどの課題は解消するはずだが、それにはチームが今すぐ始める必要がある。

プロセスとアジェンダ

アジェンダを決めて時間を固定しておくと、システムデモの処理コストを抑えることができる。システムデモミーティングの流れの例を以下に示す。

  • ビジネスの背景とPI目標を簡単に確認する(5~10分以内)
  • これからデモする個々の新しいフィーチャーを簡単に説明する(5分以内)
  • 個々の新しいフィーチャーをエンドツーエンドのユースケースを使ってデモする(合計20~30分以内)
  • 質問や意見を貰って討論する
  • 現在のリスクと障害を洗い出す
  • 最後に進捗、フィードバック、今後やるべきことをまとめる

出席者

通常は次の関係者が参加する。

以下はシステムデモを成功させるためのヒントである。

  • デモは1時間の時間枠内で行う。これは、主要な利害関係者に2週間ごとに継続的に参加してもらうためには非常に重要である。また、これによってチームのプロ意識やソリューションの準備状況も明らかになる。
  • デモ対象の新しいフィーチャーを持つチームリーダーやプロダクトオーナーの間でデモの責任を共有する。
  • PowerPointのスライドは最小限にして、テストの済んだ動くソリューションだけをデモする。
  • 現在のソリューションが非機能要求に及ぼす影響を話し合う。

さらに知りたい場合

[1] Leffingwell, Dean.Agile Software Requirements:Lean Requirements Practices for Teams, Programs, and the Enterprise.Addison-Wesley, 2011, 第9章。(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[2] Leffingwell, Dean.Scaling Software Agility:Best Practices for Large Enterprises.Addison-Wesley, 2007, 第15章。(邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス、翔泳社、2010)

 

Last update:24 September 2015