もし、開発チームのデリバリパフォーマンスが十分ではないと感じているなら、リリースした新機能や改善に対する顧客の反応を計測し、その評価結果をビジネス組織全体に対して可視化することをおすすめする。それが結果的に、デリバリパフォーマンスの向上につながると考えているからだ。
私は常々、組織を変化させるために断行されるトップダウン的な「仕組み」の変更は、即効性はあるものの、期待した効果を得にくいように感じている。そういった力技では関係者間にコンフリクトを起こしたり、始まる前から形骸化したりすることも多い。それよりも、仕組みが自然に変わっていく流れを生み出すことを考える。その流れを生み出す起点となる何かを、私は「仕掛け」と呼んでいる。
上述した「リリースに対する顧客体験の可視化」は、デリバリパフォーマンス向上に至る流れを組織内に作り出す仕掛けとして効果を期待できる。下図は、そのストーリーを描いている。
リリースに対する顧客体験を可視化する
まず最初に言っておくと、ソフトウェアプロダクトのデリバリパフォーマンスとして計測するデプロイ頻度（deployment frequency）といったメトリクスが示す値は、あくまでも結果であり、それを改善すること自体は目的ではない。デリバリパフォーマンスのメトリクスを改善すればビジネスパフォーマンス（組織パフォーマンス）が高くなるわけではなく、ビジネスパフォーマンスが高い組織はデリバリパフォーマンスのメトリクスが良い値を示している、と考えるべきだろう。
では、ビジネスパフォーマンスに対し、開発チームが寄与できることとは何だろうか。それは、プロダクトを顧客体験に優れ、顧客価値がより高いものになるよう洗練させ続けることだろう。これを本質として押さえておかないと、デリバリパフォーマンスのメトリクスが向上しても、ビジネスパフォーマンスが上がることはない。
そういう視点から、仕掛けとして「リリースに対する顧客体験の可視化」を選択した。プロダクトに変更を加える主な目的は、より優れた体験を顧客に提供することにある。したがって、リリース後の可視化によって明らかにされるその結果は、組織のプロダクト開発プロセスのあり方について強い影響力を持つと考えられる。その影響力によって、プロセスに変化を生じさせようというのが、今回の仕掛けの狙いだ。
ここでやることは、プロダクトに加えた変更が、顧客に想定通りの効果をもたらしたのかをリリースの度に計測することだ。計測するメトリクスは例えば、コンバージョン率、新機能の利用率、アクティブユーザー数、新規ユーザー数などだ。いずれにしても、計測結果を評価し、ビジネス組織全体に共有する。対象とするのは、リリースに含まれる全ての変更のうちの一つで構わない。
何を計測してどう評価するかは、リリースの内容次第だが、取り組みやすい方法を選択すべきだろう。はじめから力を入れ過ぎると導入障壁が上がる。簡単な方法ではじめ、回を重ねて効果を感じていくうちに、徐々に厳密にしていく方が上手くいく。
プッシュ型の問題に気づく
リリースサイクルの中にこのような顧客体験の可視化を組み込んでいる組織は、実はそれほど多くないように感じている。そのような組織は、プロダクトに加えた変更が想定通りの体験を顧客に提供できているかについて、楽観視しているということだろう。
しかし実際には、想定通りの結果とならなっていないことが多い。顧客体験を計測するメトリクスを可視化するということは、リリースの結果を客観的な事実として目の当たりにするということだ。
そんな体験を何度か繰り返せば、ビジネス組織全体の考え方に変化が起こりはじめる。自分たちが作り出す新機能や改善が、顧客に対して想定通りの体験や価値を提供できるのか、今までのように強い自信が持てなくなってくる。
これまでは、競合プロダクトと競い合うように、追加機能や改善のアイデアを企画してきた。バックログは常に、未着手のアイテムが山積み状態だ。とにかく早くリリースしたい。だから、様々な変更を詰め込んだアップデートを計画し、開発チームは常にフル回転で、期日までにリリースすることで手一杯になっている……
結果の計測と可視化というプロセスを導入することは、このような「プッシュ型」のプロダクト開発スタイルに疑問を持つきっかけを与えるのだ。よく言われるように、顧客にとって必要なものが何であるかは顧客自身にも答えられない。それを、プロダクトの作り手側が正しく言い当てることができると信じる方が、そもそも無謀だということは明らかだ。
プル型に変わっていく
組織にこのような意識の変化が生まれると、世界が一変する。組織のプロダクト開発スタイルが、プッシュ型からプル型に移行し始めるからだ。
顧客にとって必要なものが何であるかは顧客自身にも答えられないのだから、試してみてそこから学ぶしかない。プル型の組織はこのように、まず顧客に関する仮説（hypothesis about the customer）を立て、それを検証する方法を考え、そために必要最小限の機能が何であるかを導き出す。build-mesure-learn とは逆の、learn-mesure-build の順で計画を立てる。
そうすれば、無駄なものを作ってしまう時間の浪費を避け、必要とされるものを少しずつ積み上げていくことに時間を費やせるようになる。このような開発手法は、「仮説駆動型開発（hypothesis-driven development）」と呼ばれることもある。
そう、「リリースに対する顧客体験の可視化」という仕掛けは、ここでより計画性を持った形でプロダクト開発プロセスのフィードバックループの中に組み込まれていくのだ。
バッチサイズが小さくなる
プル型のプロダクト開発スタイルは、組織の意識をバッチサイズ削減に向かわせる。まだ仮説段階でしかない「顧客が必要としていると思われるもの」を数多く生み出したり、フル機能で作り上げることは、ムダになりかねないからだ。
また、計測・評価プロセスの精度と効率を上げたいという欲求も、更なるバッチサイズ削減へのモチベーションを高める。大きなバッチでは、評価対象となるアイテムが複数であったり、一個あたりのアイテムが大きすぎて、評価しづらいからだ。
デリバリパフォーマンスが向上する
いよいよ、デリバリパフォーマンスが向上をはじめる。そもそもデリバリパフォーマンスを測定する代表的なメトリクスであるデプロイ頻度は、ソフトウェアでは測定しづらい概念であるバッチサイズの代替メトリクスだからだ。
ソフトウェアの場合は目に見える商品が存在しないため、バッチサイズを測定してその結果を伝えるということが難しい。そのため、我々は「バッチサイズ」の代わりに「デプロイ頻度」を測定基準とすることに決めた。
「『LeanとDevOpsの科学』p.23」
バッチサイズ削減による効果としては、二点が挙げられる。開発に要する全体の工数を削減することと、マルチタスクの並列度を緩和することだ。前者によって開発期間が短くなることは容易に想像がつく。後者は、タスク切り替えによるオーバーヘッドを削減するだけでなく、ワークアイテムごとのリードタイムに含まれるタスクの待ち時間（wait time）を削減し、開発チームのフロー効率（flow efficiency）を改善する。
このようにして、最終的に、デプロイ頻度を高く押し上げる仕組みができあがる。
最後に
重要なことは、仕掛けによって組織に起こる変化が、仕組みという形だけでなく、意識や文化にまで及ぶということだ。むしろ、組織における意識・文化の変化こそが、硬直化した仕組みを変化させる原動力になると言って良いだろう。
もちろん、仕掛けだけ置けばあとは想定通りの仕組みができあがるほど、組織を変化させることは容易ではない。理想とする仕組みに向かうよう、マネージャー自身が組織の変化を促していく必要があることは言うまでもない。
