Gil Ziberfeld氏がAgile Eastern Europe 2015カンファレンスで，“New Agile”というテーマのプレゼンテーションを行った。InfoQでは，プロダクトの計画とその実践，#NoEstimatesに対する考え，製品計画に関する議論の価値，製品開発における意思決定の改善方法などについて，Zilberfeld氏にインタビューした。
InfoQ: 企業は，製品を計画してそれを実行するための，よりよい方法を探しています。それに関して，意見を頂けますか？
Zilberfeld: つい最近まで，企業がアジャイルを導入するのはまず開発チームのレベルから，というのが普通でした。スクラムやかんばん，その他のメソッドが私たちに，計画と実践の方法を示してくれたのです。スクラムにはリリースやイテレーション，日々の作業など，計画プロセスが最初から組み込まれています。バーンダウンチャートやタスクボードが状況を可視化してくれるので，十分な解析さえ行えば，有用な情報が手に入ります。例えば，私は以前，毎回のイテレーションで，バックログの60%を定常的にデリバリできるチームの作業をしたことがあります。幸せなことに私たちは，バーンチャートを，チームが一定のペースで作業を進めていることを確認する，ただそのために見ていました。イテレーションに含まれない計画に対して，あまりにも時間を使い過ぎていたのです。
かんばん方式では，かんばんボードを使用します。一見するとシンプルなものです。かんばんの“方針を明示する(Make policies explicit)”原則を適用すれば，作業の流れや，滞っている場所を追跡することができます。累積フローダイアグラム(Cumulative Flow Diagram/CFD)を作成すれば，リードタイムとWIPに基づいた事前計画を立案することができます。いずれにしても，計画を基準として情報収集を行うことになりますが，そのメリットは，プロセスがある程度予測可能になる点にあります。リーンの原則を適用すれば，制約条件の理論や待ち行列の理論が，可視化やボトルネックの顕在化，フローの改善などを通じて，予測可能性を何倍にも向上してくれるでしょう。
その点に気が付いた企業が，今度はその同じ原則を，ポートフォリオにも適用しようと考え始めています。そのためのリリーストレインを提供するのがSAFeです。かんばんを開発チームから，製品チーム全体へとスケールアップするのです。これはまだ，ここ数年で起こり始めたことですから，報告されている結果(成功例も失敗例も)を証拠として，慎重に構えた方が賢明でしょう。関係者の数が増え，プロセスが複雑化すると，予測可能性が低下を始めます。繰り返しますが，プロセスの可視化が予測可能性の向上，延いては改善能力につながるのです。
InfoQ: #NoEstimatesについては，どのようにお考えですか？
Zilberfeld: 最初にその話を聞いたときには，開発者がプロジェクトのコントロールを，スポンサから奪おうとしているのかと思いました。プロジェクトの資金を提供している人たちに対して，プロジェクトをほんの少しでもコントロールすることを許さないのだろうか，と疑問に思ったものです。
もう少し興味を持ってからは，見積(Estimate)は何のためなのか，ということを考えました。その答は，おそらく意外ではないと思いますが – 予測可能性が必要だから，です！ スポンサが見積を欲しがるのは，プロジェクトが最善の意思決定を行う上で，自分たちが役に立っていると信じているからなのです。ですが残念ながら，必ずしもそうではありません。いつの間にか約束と化してしまう見積のような機能不全，あるいは見積インフレーションを別にすれば，必要と思うツールは手に入らないものなのです。
見積を要求するのは簡単ですが，それが役に立つことはほとんどありません。事実として，意思決定は価値ではなく，コストに基づいて行われます。コストによる意思決定に革新性はありません。あるのはリスク軽減です。その意味で見積は新たな，より強力なソリューション開発の可能性に対する制約なのです。
私にとっての#NoEstimates(見積不要)とは，not-just-estimates(見積だけではない)という意味です。見積が意思決定に必要ならば，その他のファクタ，例えば複雑性評価や履歴データなどで，それを補完しなければなりません。もし役に立たない，あるいは信頼できないものならば，多くを投資する必要はありません。そして当然，プロジェクトの価値を考慮条件に加えてください – 時にそれは，コストに関係なく重要なものなのです。
InfoQ: 見積はコストを扱うもので，ご指摘のとおり，製品やサービスが提供する価値を対象とはしていません。製品の計画を行う上で，価値を議論の対象とするために，何かできることはないのでしょうか？
Zilberfeld: 変な話ですね。見積は意思決定のために行うものですが，そこで価値が問われることはまずありません。すでに誰かが適当な優先順位付けを行っている，ということが前提なのです。一方で私は，コスト見積を要求されて，肥大した数字が得られた後も，まだ先へ進んでいるプロジェクトをたくさん見てきました。なぜでしょうか？それだけの価値があったからです。
価値を見積もるというのは，コストと同じ位難しいことです。機能や製品の価値を見積もる手法として，現場では遅延コスト(Cost of Delay/CoD)などの手法が試されています。
例えば，次のような選択肢があると考えてみましょう。
- 機能Aは多く販売することができるので，より多くのお金を稼げます。
- 機能Bは既存のユーザを維持する上で有効です。
- 機能Cは機能をより早く追加する上での，私たちの能力を向上してくれます。
これらはいずれも，実際の通貨で評価することができます。機能Aによってどれだけの売上を期待できるか，機能Bでどれだけの売上を維持できるか，見積もることが可能です。後は，それぞれの遅延コストを確認すれば，２つを比較することができます。Aによる収益，あるいはBによる維持が分かったら，次は機能Cの実装による影響を確認します。
すべての機能を同じベースラインに乗せてしまえば，それぞれの価値を見積もって，最初にどれを行うか，決めることができます。
CoDメソッドとその類は，コスト見積だけでなく，さまざまな情報の基づく決定を可能にします。
InfoQ: 製品開発にはたくさんの意思決定が関わっていますが，一般的にどのように行われるのか，いくつか例を紹介して頂けますか？意思決定をする上で組織が直面する課題には，どのようなものがあるのでしょう？
Zilberfeld: ちょうど"ROI is Dead"という講演を，先日のACE!カンファレンスで行ったところです。そこでは，プロダクトマネージャが作業を決定する方法について，直感的なものから複雑なシミュレーションに至るまでを紹介しました。私たちが行う意思決定の多くは，PMが提示するポートフォリオのレベルに基づいています。プロダクトマネージャはギャンブラである，と言ってよいでしょう。ですが残念なことに，ギャンブルがうまくいっても製品が成功するとは限りません。同じ会社が2年前にひどい製品をリリースしていて悪い評価を得ていたため，新しい製品を二度と(あるいは一度も）見ようとはしないという理由で，優れた製品が無残な失敗をすることだってあります。
つまり，企業が直面する最大の問題は，複雑性なのです。これは何も新しいものではありません – これまでも常にありました。ですが，新しいアジャイルの世界では，これを無視することが難しいのです。古い製品が新しい製品を駄目にすること，それが複雑性です。不測の事態に見舞われること，それが複雑性です。プロジェクトにとって(時には企業にとっても)，致命的なものです。
InfoQ: 製品開発における意思決定を改善するために，どのようなことができるでしょう？複雑性をどうやって扱えばよいのでしょうか？
Zilberfeld: 複雑性を無視してはいけません。そうではなく，必要以上のリスクを負わずに，霧を抜け出す方法を見つけることが重要なのです。ビジネス，開発，運用 – どのレベルにおいても，私たちの知らない部分がある，ということを想定しておかなくてはなりません。その存在を認めれば，それが難しい部分です。仕事のやり方を変えなくてはなりません。
昔から，製品を定義するのはプロダクトマネージャした。その後の数ヶ月を，開発チームが引き継いでいたのです。フィードバックがあるのは，製品リリースの時だけでした。このような作業を，今後も続けることはできません。数ヶ月というサイクルを保持する代わりとして，リスクのない実験を行うことが必要です。製品全体に100万ドルの投資をするのではなく，その問題が10,000ドルで解決できるかどうか，確認することが必要なのです。私たちが正しければ，段階的に仮定を検証し続けることが可能になります。正しくなければ，会社の多くの資金を救うことができた，ということになります。
製品関係者と仕事をする場合，私は彼らに，バックログに対して，証拠を求めるなどの方法で実施する価値を確認するように，強く求めています。証拠がなければ，簡単な実験を計画してユーザのところへ行き，確認します。私たちが正しければ作業を続けますし，間違っていれば計画を変更します。