Solution Demo

プルイベントの目標は単純であった。開発組織を実体のあるイベントに集中させることで、物理的にデモをするという目標に向かって学習サイクルを完了させるよう設計されていた。

– Dantar P. Oosterwal

ソリューションデモの概要

ソリューションデモは、価値のストリームのプログラムインクリメントサイクルにおける頂点のイベントである。このイベントで、複数のアジャイルリリース列車のすべての開発作業(サプライヤーや関連する他の価値のストリームの貢献分も含む)の結果が、顧客やその他の利害関係者に対して明らかにされる。これは、完全に統合の済んだソリューションレベルのデモにとってもっとも重要なときであり、客観的な評価と利害関係者や顧客のフィードバックを得られるときである。また、直近のPIが完了したことを祝うときでもある。

これはまた、価値のストリームの過程の中で、もっとも重要な学習点でもある。ここでの結果が企業のポートフォリオの主要要素に関する今後の行動を決めることになる。

詳細

ソリューションデモは価値のストリームソリューションのライフサイクルにおける主要イベントである。リズムをベースとするこのイベントのタイミングで、重要な利害関係者が集まって、客観的な証拠をもとに、今回のプログラムインクリメントでのソリューションの進捗を確認する。このイベントで、開発チームは、ソリューションの新しいシステム能力をデモし、それが 非機能要求を満たしていること、全体として目的に適合していることを示す。主要利害関係者(一般にソリューション管理アーキテクト/エンジニア、可能であれば顧客を含む)は、このイベントに参加し、フィードバックや意見を直接伝える。

このイベントが重要であることはいくら強調しても大げさではない。これは注目のイベントであり、近い将来の価値のストリームやポートフォリオに対する投資判断の前兆となる。進捗を本当の意味で測定する唯一のものであり、価値のストリームへの投資のリスクを軽減する主要なものである。

「プル」イベントとしてのソリューションデモ

このページ先頭の引用から推測できるように、ソリューションデモは、目的のはっきりした、必須で注目の「プル」イベントである。ソリューションのさまざまな側面をまとめてプルし、意図した目的に合う、統合とテストの済んだソリューションを、アジャイルリリース列車サプライヤーが作成していることを確認できる。これにより、開発中のソリューションの統合/テスト/評価を加速することができる(これらは放置するとソリューションのライフサイクルの中で手遅れになるまで延期されがちである)。

ポートフォリオのコンテキストでは、企業がもっと大規模なプルイベントを実施し、複数のソリューションをまとめて成果を「ロードショー」として示すこともある(参考文献[1]にその例が挙げられている)。そこでは、上級管理者や利害関係者やポートフォリオ受託者が、より広いポートフォリオのコンテキストで進捗を確認し、取り組みを継続するか中止するか、価値のストリームに対する予算投資を変更するかの意思決定を行う。

概要

準備

このような重要なイベントには準備が必要である。この準備は、たいてい、PI計画前/後ミーティングで始まるが、このミーティングでは直近のシステムデモの結果が入手できる。デモの主催者にとって、これらの結果が、具体的にどのシステム能力やソリューションの他のどの部分のデモができるかの情報源となる。さらに、ソリューションデモの出席者が多くない場合でも(範囲を考慮すると通常はほとんどの開発チームメンバーが出席できない)、準備は重要である。出席するのは価値のストリームにとって重要な人であり、準備やタイミング、発表方法、プロ意識に注意を払うことで、気持ちよく参加してもらえる。これが結果に影響することすらある。

出席者

ソリューションデモには、通常、以下のような人が出席する。

イベントのアジェンダ

典型的なこのイベントは次のような流れで行われる。

  • PIの開始時に合意した価値のストリームのPI目標を振り返る(10分)
  • それぞれの目標とシステム能力をエンドツーエンドのユースケースを使ってデモする(合計30~60分)
  • 達成できたビジネス価値を目標ごとに特定する
  • 質問や意見を貰って討論する
  • 最後に進捗、フィードバック、実施項目をまとめる

複数のソリューションのデモをまとめて行う場合には、この日はさらに興味深いものになる。よく見られる形式は科学博覧会のようなもので、それぞれのソリューションが1つの場所を割り当てられて進捗をデモし、利害関係者が質問をしたりフィードバックを返せるようにする。上記のアジェンダに沿って、各ソリューションに1時間の枠が与えられ、特有の利害関係者に対して成果物のデモをできるが、その他に、どのソリューションも常にデモができるようになっている。他のソリューションのメンバーやその他の利害関係者は、それぞれのソリューションの場所に出向いて、形式ばらないデモをしてもらったり、非公式のフィードバックを返すことができる。

指針

ソリューションデモを成功させる1つの正しい方法というのは存在しないが、気にかけておくとよいヒントを以下に紹介する。

  • デモの時間枠は1~2時間にする。主要な利害関係者に参加してもらうにはこれが重要である。また、プロ意識やソリューションの準備状態もこれによって示すことができる。
  • 主任エンジニアと、デモ対象の新しいシステム能力を担当するチームメンバーとの間で、デモの責任を共有する。
  • PowerPointのスライドは最小限にして、テストの済んだ動くシステム能力だけをデモする。
  • ソリューションのNFRsソリューションの意図に現在のPIがどう影響するかを議論する。
  • ソリューションコンテキストの中でデモを行う(下記参照)。

ソリューションコンテキストの中でのソリューションのデモ

ソリューションコンテキストとの結合度はソリューションによって異なるため、最後の項目は特に重要である。ソリューションが環境にほとんど依存していない場合には、隔離された状態でソリューションをデモするので十分かもしれない。しかし、ソリューションがソリューションコンテキストに強く依存している場合には(たとえば複数のシステムからなるシステムの場合など)、隔離されたやり方は不適切であり、誤解を招く恐れさえある。その場合、ソリューションのデモは、ソリューションコンテキストを忠実に表す環境で行うべきである。定期的にそれを行うのが現実的でない場合、開発チームはソリューションコンテキストとの統合を行うリズムを計画するべきである。しかしそうしてしまうと、非常に低い統合の頻度でしか本当の学習が行われない。

ソリューションデモの戦略、投資、タイミング

大規模システムは統合が困難な場合がある。ソリューションインクリメントのデモを定期的に行うには、一般的にチームは統合とテストとそれを支えるインフラに投資しなければならない。それを行ったとしても統合やテストの範囲が100%に満たないこともあり、早期のうちは統合ポイントごとに変える必要があるかもしれない。その助けとなるよう、チームでは、可視化、環境のエミュレーション、モック、スタブ、無駄なものを省いたテストスイートなどを利用することができる。また、統合とデモの工数やサポート環境に費やす時間を、PI計画時に明示的に割り当てる必要があるかもしれない。

タイミングについて言うと、ソリューションデモはPI内の最後のシステムデモの後、いくらかの時間をあけて行うことがある。しかしその場合、フィードバックループに遅れが生じて、リスクが増え、価値のストリームのベロシティーが低下する。この時間差を縮めるためのヒントを以下に示す。

  • PIのスコープの一部だけをデモするよう計画する。部分デモを行うには、構成管理を使用できるようにする必要があるかもしれない。
  • Leave room in the 革新と計画の反復の中に、この高レベルの統合のための余裕を取っておく。
  • 統合とテストの担当領域が広がったARTは、他の列車のサブシステム/システム能力の領域と重なる部分が増える可能性がある。そのため、個々のシステムデモでも完全に統合されたソリューションデモに似たものを提供できる。

最後に付け加えると、ソリューション自体が統合とテストをサポートしやすいよう設計されていて、結果としてデモの処理コストを大きく下げることができる場合もある。ソフトウェアに標準のインタフェースがあり、APIとコンテナが厳密に定義されていると、チームが問題や矛盾を早期に発見するのに役立ち、サブシステム群のエンドツーエンドの統合とテストが容易になる。


Learn More

[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.

Last update: 23 October 2015