BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Gil Ziberfeld氏に聞く - アジャイルにおける製品計画とその管理

Gil Ziberfeld氏に聞く - アジャイルにおける製品計画とその管理

ブックマーク

原文(投稿日:2015/05/14)へのリンク

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でどれだけの売上を維持できるか,見積もることが可能です。後は,それぞれの遅延コストを確認すれば,2つを比較することができます。Aによる収益,あるいはBによる維持が分かったら,次は機能Cの実装による影響を確認します。

すべての機能を同じベースラインに乗せてしまえば,それぞれの価値を見積もって,最初にどれを行うか,決めることができます。

CoDメソッドとその類は,コスト見積だけでなく,さまざまな情報の基づく決定を可能にします。

InfoQ: 製品開発にはたくさんの意思決定が関わっていますが,一般的にどのように行われるのか,いくつか例を紹介して頂けますか?意思決定をする上で組織が直面する課題には,どのようなものがあるのでしょう?

Zilberfeld: ちょうど"ROI is Dead"という講演を,先日のACE!カンファレンスで行ったところです。そこでは,プロダクトマネージャが作業を決定する方法について,直感的なものから複雑なシミュレーションに至るまでを紹介しました。私たちが行う意思決定の多くは,PMが提示するポートフォリオのレベルに基づいています。プロダクトマネージャはギャンブラである,と言ってよいでしょう。ですが残念なことに,ギャンブルがうまくいっても製品が成功するとは限りません。同じ会社が2年前にひどい製品をリリースしていて悪い評価を得ていたため,新しい製品を二度と(あるいは一度も)見ようとはしないという理由で,優れた製品が無残な失敗をすることだってあります。

つまり,企業が直面する最大の問題は,複雑性なのです。これは何も新しいものではありません – これまでも常にありました。ですが,新しいアジャイルの世界では,これを無視することが難しいのです。古い製品が新しい製品を駄目にすること,それが複雑性です。不測の事態に見舞われること,それが複雑性です。プロジェクトにとって(時には企業にとっても),致命的なものです。

InfoQ: 製品開発における意思決定を改善するために,どのようなことができるでしょう?複雑性をどうやって扱えばよいのでしょうか?

Zilberfeld: 複雑性を無視してはいけません。そうではなく,必要以上のリスクを負わずに,霧を抜け出す方法を見つけることが重要なのです。ビジネス,開発,運用 – どのレベルにおいても,私たちの知らない部分がある,ということを想定しておかなくてはなりません。その存在を認めれば,それが難しい部分です。仕事のやり方を変えなくてはなりません。

昔から,製品を定義するのはプロダクトマネージャした。その後の数ヶ月を,開発チームが引き継いでいたのです。フィードバックがあるのは,製品リリースの時だけでした。このような作業を,今後も続けることはできません。数ヶ月というサイクルを保持する代わりとして,リスクのない実験を行うことが必要です。製品全体に100万ドルの投資をするのではなく,その問題が10,000ドルで解決できるかどうか,確認することが必要なのです。私たちが正しければ,段階的に仮定を検証し続けることが可能になります。正しくなければ,会社の多くの資金を救うことができた,ということになります。

製品関係者と仕事をする場合,私は彼らに,バックログに対して,証拠を求めるなどの方法で実施する価値を確認するように,強く求めています。証拠がなければ,簡単な実験を計画してユーザのところへ行き,確認します。私たちが正しければ作業を続けますし,間違っていれば計画を変更します。

この記事に星をつける

おすすめ度
スタイル

BT