Chris Sims さんのビジネス価値見積りのゲーム - Global Scrum Gathering

Global Scrum Gathering Day1 で参加した、Chris Sims さんのビジネス価値見積りのワークショップの手順を書いてみます。Chrisさんにブログへの掲載を快諾いただきました。


背景

スクラムでは優先順位付けされたプロダクトバックログが必要だ。優先順位はROIに従うべきだろう。ROIが高いものは優先して顧客に届けたい。ROI = 価値/コスト で、コストはチームメンバーが固定である限りストーリーポイントが相当する。あとはビジネス価値がだせるといい。ビジネス価値といえば、リリースした後に得られる売上のうちその機能に属する部分だとか、その機能によって削減されるであろう手間に関する人件費の推測なんかをして、お金に換算するのが普通だ。しかし、まだ売り上げている訳でもないので、実際にはこの見積りは困難だ。しかも、ビジネス価値は"お金"だけではない。顧客の信頼を得るとか、ブランドを高めるとか、システムが安定化するとか、顧客満足が高まるとか、お金に換算しづらいものもたくさんある。

ステークホルダーの共通認識が重要

ビジネス価値の正確さ、というのはがんばって情報を集めて計算しても、所詮は推測の積み重ねなので、それほど高まっていかない。もちろん推測できなければ予算もとれなかったりするので金額は大事で、とにかく数値を出さなければ前に進めないことも多い。そして、積み上げた数字をステークホルダーに納得してもらう必要がある。

というわけで、じゃあステークホルダー参加で見積もれば、作成とフィードバックと議論を行いながら、順位付けまで全部できるじゃないの、というのがこのワークショップだ。

進め方

ワークショップの写真を十分に撮っていないので、机上で再現した(ほんとにデスクの上)。写真を追って説明してみたい。

順序付け

まずはプロダクトバックログアイテムないし機能の束がある。
Aさん、Bさん、Cさんのなかでこれらのビジネス価値を合意したい。

まず最初のカードを場に出す。
Aさんは、場のカードと、束の一番上のカードでどちらが価値が大きいかを決定する。右が価値が高いほう。

Aさん「カーペットクリーニングも大事だが、トイレを増設しないと、家族が喧嘩になるんだ。だからとても価値が高い。」

Bさんの番。次のカードを出すか、場に出ているカードを一枚動かすか、どちらかを行うことができる。

Bさん「カーペットクリーニングしないとダニとかでて病気になっちゃう。こっちの方が価値が高い」

次はCさんの番。次のカードを出すか、場に出ているカードを一枚動かすか、どちらかを行うことができる。

Cさん「キッチンに新しい機材がほしい。値段も張るし、一番価値がたかい。」

ふたたびAさんの番。2週目以降もルールは同じだ。

Aさん「やっぱりトイレが一番価値が高いと思う。よくお腹痛くなるし。」

Bさんの番

Bさん「プールですよプール。みなさんあこがれの。これは一番価値高いでしょう。」

Cさん「アメリカじゃないんだからプールは必要ないと思う。一番下に持ってく。」

ビジネス価値の見積り

ここまでで相対的な並べ替えはだいたい終わった。ここからビジネス価値を数値で見積もっていく。

まず一番左のカードの左上にマイナス(-)のカードを置く。ここからまた順番をまわしていく。数字のカードを出すか、既存のカードをずらすことができる。数字のカードはフィボナッチ数列で、まず1のカードから始まっている。

Aさん「価値がマイナスのものはなさそうだから、一番左が1かな」

Bさん「プールは価値ないので、(-)と1を右にずらしとく」

Cさん「カーペットクリーニングに対してキッチンの調理機材は倍くらい価値がありそう」

Aさん「トイレはとても価値がある。カーペットクリーニングの3倍くらいには」

Bさん「キッチンの増強とトイレの増強はおんなじくらいの価値だと思うなぁ」

という風に、多面的に議論しながらフィボナッチ数列のカードをだしていく。

すべてのカードを出し終えて、場所の変更もなくなったら、終了。
相対的にビジネス価値が見積もられ、ステークホルダーの議論も反映したリストが出来上がる。

制約

この議論に参加していない人に議論の内容を伝えることは難しい。
そのかわり、短い時間でできるので、ステークホルダーの代表に参加してもらうのがよいだろう。

謝辞

教えていただいた Chris Sims さんに感謝いたします。
Thank you!! Chris-san!

Global Scrum Gathering Day 2 の基調講演 : 音楽業界BMI社でのアジャイル適用

引き続き Global Scrum Gathering に参加している。

Day2基調講演 : BMI社でのアジャイル適用

Day 2 朝の基調講演は音楽業界の老舗 BMI 社の組織全体でのアジャイル導入事例の話。

音楽業界は大きな変化がきており、アーティストや作曲家はクラウドソースになったり、ストリーミングや権利、イベント運営などいろいろな分野で変化が起きているそうだ。

まず開発でパイロットプロジェクトでのスクラムをやってみたところ、よい結果が出た。そのあと、コードベースを統一したり、スマホ向けのレスポンシブデザイン対応のサイトを作った。

当初DAD(ディシプリンアジャイルデリバリー)を利用して、そのあと自分たち流にアレンジしてプロセスを定義した。

で、そこから Jeff Sutherland の奥さんである Arline さんが Agile 2009で発表していた Scrum in Church (教会の慈善活動へのスクラム適用) にヒントを得て、技術系でない人たちにもスクラムを適用することにしたそうだ。先進的な副社長が「Why not?」と後押ししたらしい。やりながら、財務系のチームの完了の定義(DoD)は予算を予定通り決められたかどうか、なんてふうに変換したらしい。


非エンジニアのスクラムというのは多くの人にとって共通のトピックなのか、質問の列が休憩中の30分間途切れなかった。

昨夜はパーティだった

昨日のエントリの後にパーティに参加したので少し写真を貼っておきたい。

ホテルから道半分を占有して警官付きでパレードしながらバーへ。バーは予想以上に人が多かったのか、飲み物も食事も長い列ができていた(ディナーの設計は超難しいと思う)。


スクラムマスターズナイトをやられている知花さんたちとカフェでワニのフライをつまみ、タバスコ社のスパイシー醤油というお土産に心引かれつつ(買わなかった)。一日目終了。

Ken Rubin 基調講演 "経済合理性のあるスクラム" - Global Scrum Gathering Day 1

Global Scrum Gathering 2014 に来ている。Scrum Gathering Tokyo の実行委員を3回つとめさせていただいたが、本家のScrum Gathering には未参加だったので、雰囲気を知らないといけない、ということで、遅ればせながら、今回初参加した。


冒頭の主催者のセッションによると、今回のカンファレンスは、 これまでで最大の規模になったとのこと。目分量でAgile Conferenceの半分くらい、500-700人くらいの規模ではないかと思う。23カ国から参加者が来ていて86%は米国からだそうだ。5並行セッションで48セッションが行われる。

基調講演 : Ken Rubin "Economically Sensible Scrum (経済合理性のあるスクラム)"

Essential Scrum の Ken Rubin の基調講演。Kenは以前 Scrum Alliance の理事をしていたそうだ。Essential Scrumは、もうすぐ日本で発売される予定だ。

今回はチームレベルのスクラムができている状態で課題になる、その外側の話。チームレベルの開発にスクラム適用がうまくいくと、次は組織に必要な価値との擦り合わせが課題になる。そこには3つの阻害要因があるという。

  • 開発時に、アジャイルの基本原則を無視する、または、間違って適用する
  • アジャイル原則をバリューチェーン全体に適用することに失敗する
  • チームを組み合わせるにあたり、経済的に合理性のある組織構造を作ることに失敗する

一つ目のアジャイル原則の適用については、Antifragileという本を紹介していた。状況が混乱したときにどのような影響があるかで、3つのレベルに分類すると、Fragile(うまくいかなくなる) - Robust(影響を受ける) - Antifragile(混乱から利益を得る) となる。ウォーターフォールはFragileで、アジャイル原則の適用によってRobustやAntifragileの実現を目指す。

二つ目のバリューチェーンは、複数チームが関わる場合にバリューチェーンを意識するということだ。開発チーム以外にもマーケティングやインフラ、運用チームなどがある場合に、要望が来てからリリースされるまでのサイクルタイムをいかに短くするか、というリーン原則を実現するようにチームを組む。

ここで重要なのは、各チームの稼働率を最大にすることは意味がないということだ。消防署で例えると、稼働率100%の消防署ばかりでは、いざ火事が起きた時に対応ができない。ビジネス要望に即応することと、稼働率を高めることは、稼働率が一定以上になったときに矛盾が生じる。ここでは70%弱くらいで待ち行列の大きさが倍になる例を示していた。開発チームがなかなか要求した仕事をしてくれないのは、だらだらしているのではなく、むしろがんばりすぎていて、稼働率が高すぎるからかもしれない。

三つ目の組織構造については、専門別の部門、地域ごとの部門、コンポーネントごとの部門、フィーチャーチームという4つのパターンを示した後、フィーチャーチームとコンポーネントチームの組み合わせがよいのではないかという結論だった。コンポーネントチームの代表がフィーチャーチームにも属し、花粉を運ぶ役割をもつ、ということだ。

軍隊や消防署のように、長く続く小隊はすでに過去の経験を共有しており、経済合理性がある。

うまくいっているチームが、「スクラムなんだからチームメンバーの変更は受け入れない」といいはじめて、各チームが同じことを言うと、組織全体としてはデッドロックに陥ってしまう。そうではなく、全体のフローの視点で考えようというのが印象的だった。

Coaches Clinic

休み時間にコーチに相談できるCoach's Clinicで、いまちょっと悩んでいることを相談した。
内容は割愛するが、個人的にすごく有益なアドバイスをいただいた。


Chris Sims "How to estimate Business Value"

ビジネス価値を導きだすワークショップ。Agile Conferenceでもやられているようなので、有名なのかもしれない。一般的にビジネス価値といえば金額を想定することが多いが、実際は金額以外の価値がたくさんあり、多面的な価値を考えなければならない。そこで、多様なステークホルダーが集まってさっと相談する。並べ替えと相対見積りを使ってビジネス価値をつけていく。ポイントはこの課程で共通認識ができるということだ。

ここでできた共通認識を外の人に伝えるのは難しいので(見積り結果は伝えられるが、多面的な議論のすべてを伝えるのが難しい)、ステークホルダーに集まってもらう必要がある。

結果として、複数の利害関係をゲームによって調整した結果のビジネス価値つきバックログが作られる。ビジネス価値は変動するものなので、スプリントごとに見積りをやり直す。

ビジネス価値がスプリントとともに変化する例の一つは次の通りだ。出荷可能な単位の機能の価値が300として、そこに3つのバックログ項目が含まれる場合は一つあたり100と考えられる。スプリントが一つ終わって一項目実装が終わると、残り2つ作れば300の価値が実現できるので、残り2項目の価値は100から150に上がる。

この方法が今のチームで使えるかどうか、ちょっと試してみたいと思う。

カンバンの起源の話を社内でこっそり褒められた

先週の社内ハッカソン発表会の後の飲み会で、一部の人(推計一人)にこっそり絶賛されていたというお話を人づてに聞いて、とてもうれしかった。
https://speakerdeck.com/kawaguti/kanban-and-scrum

この話は、日本人にとってはカンバンという単語はいろいろあって混乱するので整理した、という入り口から、実はカンバン方式の基本とKanbanやScrumでの仕事量の調整方法について、どういった制御変数をどのように表現しているかを説明したいと思って作ったものだ。

社内のTechTalkでもやってみて、一部の人には刺さったらしい。
DevSumi 2013 の OpenJamでもやって、結構、人も集まってくれて、楽しんでもらえたのではないかと思う。
この話は昨年の Agile Conference の OpenJamでやって、何人かに面白い話だと言ってもらった。

タスクボードはもちろん一つのツールでしかないが、これで見えることはたくさんある。一番大事なのは、自分たちで自分たちをマネージメントするための情報を作りだし、議論を行っていくということではないかと思う。手間も少しかかるし、外の人には見えにくいのかもしれないが、中の人にすら自分たちのおかれた状況が見えていないような危ない状況よりは、ずっといいと思っている。

もっともっと尖った話を Agile Roots Conference で原田さんと牛尾さんがやってくれるみたいなので、すごく楽しみだ。平鍋さんは基調講演のようだし、日本人の登壇者が沢山いるみたいなので、この機会に海外カンファレンス初挑戦、というのも、いいきっかけではないかと思う。

アンチパターンに必要な2つの要素を学んだ。

父はまとまった本を読むタイプではなかったけど、歴史の本とかを乱読する人だったので、買ったやつをお勧めされたり、勝手に借りたりして読んだ。

その中にノストラダムスの大予言てきなやつが一冊あった気がする。あ、ちがうところで借りたのかも。

そこには救世主思想のような話があり、未来に神様が人のかたちで降りてくるという伝説があるのだけど、そのまえにそれを騙った「アンテXXX」なる人が現れて、人々を騙して、世界を破滅に導く、とあったように、おぼろげに覚えている。

今にして思うと「一見正しそうだけど、うまく行かない話」に怒りを覚えるのは人間の共通した感情なのだろう。人は騙されるのが大嫌いだ。誰かが騙したわけじゃなくて、勝手に勘違いしたとしても、何かを責めないと心が収まらないことすらある。
パターンランゲージはうまく行く方法を記述するものだけど、途中からアンチパターンというものも提案されるようになった。本来はうまく行かない方法なんて価値がないから書かない、というのが基本スタンスなので、「うまくいかない」だけの記述をなんでやるんだろう、と思っていた(あんまし興味がなかった)。

二つの要素

アンチパターンというのは、「一見うまく行くように見えるけど実際はうまくいかない方法」だそうだ。そして「なぜ一見うまくいくように見えるのか?」「代替として使うべき、うまく行く方法(パターン)はなにか?」までを書くのだそうだ。

"A well formulated AntiPattern also tells you why the bad solution looks attractive(e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead."
http://c2.com/cgi/wiki?AntiPattern

うまく行かない方法だけを書いても、アンチパターンとしての価値が出てこない。
その横に「あー、ちょっと変えてこっち使えばいいのに! (志村後ろ後ろ)」といえるパターンがあることがアンチパターンの成立要件だと勝手に理解した。

チームのフェイルオーバーアーキテクチャ

誰かが辞めるって決まってから引き継ぎを始めるか(コールドスタンバイ)、常に同期をとっておいて退職や新規受入に備えるコストを払っておくか(ミラーリング)、どっちを選択するかは、その事象の発生頻度と求められる復旧時間によるのだろう。雇用の流動性が高まって人が入れ替わりやすい労働環境、変化が激しく稼働を止めるコストが高いことを想定すると、より後者を選択するインテンティブが高まるとおもう。時間もお金も(実は稼働実績も)ないのでまずはコールドスタンバイ、というケースはよくあると思うけど、慣れていたり技術の熟成で楽になっていたり一回痛い目をみていたりすると後者を選択しやすそうだ。

システムのフェイルオーバーアーキテクチャの考え方でチームを考えてみると、気づきがあったりする。もちろん人はものではないので、単純に模倣すべきものではないと思うけど、それを考えると個性が生かせないというものでもないように思う。ポリシーAとポリシーBをうまく混ぜると単独でやった時より全体のリスクはあまり増えず、リターンが多いというケースはよくある。