英国コーンウォールで開催された第５回の‘Agile on the Beach’カンファレンスで，InfoQは，ProdUX Labs創設者のMelissa Perri氏と話す機会を得た。‘Continuous Product Improvement’と題した講演をカンファレンスで行った氏は，その講演の中で，継続的インテグレーションと継続的デプロイメントが技術的プラクティスとして広く実施されている現状において，継続的製品開発(continuous product development)が主流にならないのはなぜか，という問題を提起している。
InfoQ: Melissaさん，今日はお時間を頂いてありがとうございます。読者に簡単な自己紹介をお願いします。‘Agile on the Beach’でのプレゼンテーションの内容についても概略を説明して頂けますか？
Perri: ありがとうございます。大好きなInfoQで話ができるのはとても嬉しいです！私はプロダクト管理者でUXコンサルタント，そしてコーチもしています。コーチとしては，プロダクトマネージャを対象として，優れた製品を生み出すために必要なスキルを教えています。コンサルタントとしては，“開発が可能か”ではなく，“開発するべきか”という問いに対して，チームが答を出せるための支援をしています。
ソフトウェアをどうやって(how)開発するかについては，以前から議論されてきました。 カンファレンスでも会議でも，あらゆる場所で。スプリント計画やコードベースが議論され，プルリクエストを送るとほぼ同時に機能が提供されています。しかしながら，“どうやって(how)”を考えるあまり，“なぜ(why)”と問うことが忘れられているのではないでしょうか。なぜこれを開発するのか？新たな機能や製品を開発する上で，これは根本的な疑問です。私は，生徒やクライアントが，“なぜ”を問うことを忘れないようにしたいのです。
Agile on the Beachで私は，継続的製品改善(Continuous Product Improvement )について話しました。 これは，チームが科学的手法で自らの製品を向上させることを支援する，私の方法なのです。その中心にあるのはプロダクト・カタ(Product Kata)，つまり，継続的改善を実現するToyotaのカタ方式です。このプラクティスは，会社全体の仕事について，その仕事のやり方を改善するものです。CEOから用務員に至るまで全員が，会社をいかにして前進させるか，共通の目標を達成できるか，その方法を見つけだすのです。Toyotaの成功の秘訣はここにあります。私はこの概念を，製品開発の管理に適応してきました。
InfoQ: 今日の講演でも‘継続的製品改善’について議論されていましたが，その中で，継続的インテグレーションと継続的デリバリの遍在性を考えた時，これが同じように主流になっていないのはなぜなのか，という問いかけがありました。あなた自身は，この疑問の答は何だと思いますか？
Perri: 継続的インテグレーションや，あるいは継続的デリバリなどのプロセスを用いた開発改善については，これまで長く議論されてきました。この点が大きな違いだと思います。先程述べたように，私たちは製品開発というパズルの１ピースをこれまで無視していたのです。それはプロダクトマネージャ，あるいはプロダクトオーナという役割がまったく誤解されていたためだと，私は考えています。
多くの企業はこの役割について，要件を決定し，ユーザストーリを割り当てて，仕様に従った開発が行われることを保証するための存在だと見なしています。おそらくは1,2回のA/Bテストも行うでしょう。そこまで先進的ならば，の話ですが。これらの機能もこの役割の重要な部分には違いありませんが，全体像が欠けています。
プロダクトマネージャはファシリテータ(進行者)なのです。ファシリテータは，自分自身でアイデアを出すのではありません。そうではなく，チームが問題を解決する上で，正しい方向に進むように支援するのです。プロダクトマネージャは彼らのビジネスのために，最高の製品機会(product opportunity)を見出す責任があります。
これが継続的製品改善のすべてです。機能を最適化する方法を決定し，新たな製品ラインを立ち上げ，自らが主導権を持つことによって企業の目標に到達する，それを可能にするのが継続的製品改善です。このような活動をすれば，チームは製品に対して，よりオーナーシップを感じるようになります。開発に熱意を持つことができるのです。
機能リリースの成功に関わるものとして，私たちは，開発を改善する方法について絶えず話し合っています。改善の成果は明確で，進捗を直接目で確認することができますから，何も難しいことはありません。必要なのは一歩下がって見ることです。そうすれば，誰も使わない機能を数多く実現することの無意味さが理解できるはずです。
InfoQ: ‘プロダクト・カタ’の話も出ましたが，このプロセスの導入と，そこから得られるメリットについて説明をお願いします。
Perri: 分かりました。プロダクト・カタは，製品の改善と共通目標へのチームの方向付けをシステマティックに進めるプロセスです。
まず必要なのが，マネジメントによるある程度のサポートです。彼らが企業あるいはその製品のビジョンを設定するか，あるいはチームの作業の目標を設定します。“わが社は新規顧客を目指してエンタープライズ市場に進出する。下半期の間に，少なくとも10件の企業顧客を獲得したい”，といった具合です。
目標は非常に高いところに置かれるのが普通です。野心的で，どうやったら到達できるのか，100%の自信はありません。ですから達成可能な，もっと小さな目標，いわゆる“目標条件(Target Condition)”にブレークダウンする必要があります。企業目標に対する最初の目標条件は，例えば“ベータテスタとして１件の企業顧客と契約する”というようなものです。これならば比較的早く達成できますから，それを目指して努力することも難しくありません。
自分たちの向かう方向をチームが理解できたならば，次にはプロダクト・カタを開始します。プロダクト・カタは，目標条件の達成に向けて一歩を踏む出すたびに自問自答する，一連の質問です。
1. 現在の状態は何か？
2. 現在取り組んでいる障害は何か？
3. どのような行動が可能か？
4. 成功をどのように判断するのか？
これらのステップを一通り確認して行動したならば，自分たちの進捗を評価し，そこから“何を学んだか”を自問します。この結果を次の活動に利用するのです。目標条件に到達したならば，次の目標条件を設定します。最終目標を達成するまで，これを繰り返すのです。目標条件を達成できなければ，達成できるまで行動と学習を繰り返します。
より詳細な例と説明については，私のブログで以下の記事を調べてください: http://melissaperri.com/2015/07/22/the-product-kata/
InfoQ: 継続的製品改善のアプローチを用いるには，行動計画と成功基準の確立が不可欠だ，ということは分かりました。これらに関して，何かアドバイスはありますか？
Perri: プロダクト・カタを実行して一般的によいと言われる製品を作るには，基準が極めて重要です。ですが，私の知る限りでは，成功の判断基準をまったく準備していない企業や，方法の間違っている企業がほとんどです。“来年中に２つの新機能をリリースする”というような目標は，その典型的な例です。新機能を２つリリースするのは誰にでもできます。よい機能かどうかというのは，それとは別の話です。
判断基準はアウトプットではなく，最終的な結果に基づくことが重要です。すべての基準を見直して，“この目標はビジネスのためか，それとも顧客のためなのか”を問い直してください。その問いに対して行動可能な違いを見出せないならば，成功基準を変える必要があります。メトリックは定量的でも定性的でも構いません。その両方をうまく織り交ぜることが望まれます。
優れた基準として重要なもうひとつのポイントは，それが実行可能であるということです。悪い例としては，“アプリのダウンロード数”のようなものがあります。この目標のために実行できることは多くありません。ダウンロード数は通常，アプリを欲しい人がいなくなるまで増えるものだからです。基準が”ビューからダウンロードへのコンバージョンを毎月X%増加させること”というものであれば，これを実現するために何が可能かを，すぐに試すことができるはずです。
InfoQ: 継続的製品改善を実践する上で，最大の課題は何だと思われますか？
Perri: 最初のうちは適切な行動計画を作り上げて，それを評価するのに苦労するかも知れません。優れた行動計画を作る方法を学ぶには，練習が必要です。よりよい方法が何なのかを知るためには，過去の行動を分析し，それを反映できることが必要です。ですからプロダクト・カタはスタンドアップと同じように，繰り返し行わなくてはなりません。
チームに対する投資も必要です。それがなければ，彼らの協力は得られないでしょう。私がコーチしたあるチームでは，最初の活動を“アップデートを実行したらキャンディを１個もらう”というものにしました。本当にです。ですが，彼らはそのプロセスに納得していませんでした。それが命令されたものだったからです。最終的には態度を変えて，この作業方法を楽しむことができたのですが，それまでに長い時間が掛かってしまいました。素晴らしい活動をしたいのであれば，チームが進んで実施できるようなものにしなくてはなりません。それが最大の課題です。
InfoQ: 今日は時間を頂いて，本当にありがとうございました。他に何か，InfoQ読者に伝えておきたいことがありますか？
Perri: この方法は，基礎となるビジネスがすでに存在している場合，既存製品の改善や新製品の開発には非常に優れたものだと思っています。ただし，スクラッチからスタートアップを開発するのには向いていないでしょう。新たなプロセスを導入する前に，自分自身の状況を理解しておく必要があります。最良の選択を行うには，それが唯一の方法なのです。ですから私としては，まずは試してみて欲しいと思っています。もし何らかの支援や実施例が必要ならば，ぜひ私に連絡してください！
Perri氏のAgile on the Bearchでの講演“Continuous Product Improvement”の様子は，同カンファレンスのYouTubeチャネルにあるビデオ録画で見ることができる。