この国では犬が

本と芝居とソフトウェア

2021年前半のふりかえり

やったこと

1 冊

目標「月に 1 冊以上技術書を読む(※アジャイルの本など、コードが出てこないものは除く)」について、2021 年前半に読んだ技術書は 1 冊。

1/6。
なるほどね?

アクティブに読みかけの技術書は複数ある。

1 本

目標「月に 1 本以上記事を書く」について、2021 年前半に書いた記事は 1 本。

1/6。
なるほどね……?

引っ越した

引っ越して人と一緒に住み始めた。

翻訳をやることになった

『The Great ScrumMaster』(日本語版は『SCRUMMASTER THE BOOK』)の著者である Zuzana Šochová さんが書いた『The Agile Leader』という本を、会社の人数名と一緒に翻訳している。

greatagileleader.com

わかったこと

生活が変わると、習慣も変わる

引っ越して人と一緒に住み始めたことで、生活習慣が色々と変わった。

直接的ではないものの、結果として、本を読む数がぐっと減った。
具体的には、6 ヶ月で 18 冊しか読んでいない。去年の 42 冊に比べて実に半分以下である。
この数の少なさが、読んだ技術書の少なさ(1 冊)にも響いているし、書いた記事の少なさとも関連があると思う。

翻訳は楽しい。そして、時間がかかる

翻訳は(特に、複数人での翻訳は)想像以上に楽しかった。
そして、想像以上に時間がかかる。

これも、読書や、(翻訳以外の)アウトプットに時間が取れていない一因になっている。

次にやること

本を読んだり、アウトプットするための時間を作る

生活習慣が変わったことで、結果として、本を読んだりアウトプットしたりすることが満足にできていないのが現状だけれど、感覚としては時間が絶対的に足りていないわけでは(今のところ)ない。
なので、新しい生活習慣に合わせてそれらの活動をするための時間を明示的に確保すればおそらくリカバリーできると思う。

具体的には、毎週土曜か日曜のどちらかでまとまった 2 時間を取ることにしようかな。それくらいなら、無理なく、着実に進めていくことができるだろう。
本を読むのか、アウトプットに使うのかは自由で、都度決めることにする。

目標は下げる

翻訳に時間がかかることは簡単には変えられない現実で、そちらをできるだけ優先的に進めたい意向でもあるので、年初に立てた 2 つの数値目標は潔く下方修正することにする。
具体的には以下の通り。

  • 月に 1 冊以上技術書を読む
    • 「2 ヶ月に 1 冊以上技術書を読む」に変更。インプットはできるだけ減らしたくないが、6 ヶ月分のビハインドを取り戻すのは難しいと考えた。
  • 月に 1 本以上記事を書く
    • 「3 ヶ月に 1 本以上記事を書く」に変更。都合あと 2 本書けば達成になる。たぶん年末のふりかえり記事を書くので、それ以外でもう 1 本。

あとは自由

昨年末にも感じたような、自由でも大丈夫な感覚は今のところ続いている。
だから、続ける。

シンプルに実装することと、実装をシンプルにすること(シンプリシティについての断章)

XP の 5 つの価値のうちの 1 つに「シンプリシティ(シンプルさ)」があります。

このシンプリシティについて、気づいたことがあるので記します。要点は以下の 2 つです。

  • XP での開発におけるシンプリシティの実現には、「シンプルに実装すること」と「実装をシンプルにすること」という 2 つの側面がある
  • XP での開発において、シンプルに実装することと、実装をシンプルにすることは車の両輪

シンプルに実装すること

XP での開発におけるシンプリシティの第一の側面は、シンプルに実装すること(implement simply)です。

今取り組んでいる目の前のストーリーの実現にあたって、「もっともシンプルで、うまくいきそうな設計・実装」だけをする。

その判断のために役に立つ原則(経験則)もあります。以下のものです。

  • すべてのテストをパスする。
  • コードの重複がない。
  • すべてのコードについて、プログラマの意図を明確に表現している。
  • 最小限のクラスとメソッドを備えている。

この原則にのっとって、「もっともシンプルで、うまくいきそうな設計・実装」を判断し、それ以上のことをしたくなる誘惑に負けないように、自分を厳しく律します。

これが「シンプルに実装すること」です。

実装をシンプルにすること

XP での開発におけるシンプリシティのもう一つの側面が、実装をシンプルにすること(simplify implementation)です。

いわゆるリファクタリングですね。

XP では継続的にリファクタリングを行いますが、中でも特にリファクタリングに適したタイミングが 2 つあります。以下の 2 つです。

  • テストファーストで書いたユニットテストがパスしたとき。(レッドからグリーンになったとき)
  • 新たな機能の実装に取り掛かるために、既存のコードを訪れたとき。

どちらも重要ですが、特に 2 つめの機会について意識的であることが重要だと思います。
というのは、1 つめの機会については「レッド→グリーン→リファクター」というフレーズがよく知られており、比較的見落としにくいと思いますが、2 つめの機会については 1 つめに比べるとあまり語られることがないように思えるからです。

2 つめの機会では、前回このコードを訪れたときに十分「シンプルに実装」していたとしても、その実装をさらにシンプルにできる可能性があります。
それは、前回と今回では、前掲の原則にも出てきた「プログラマの意図」が異なるからです。前回は、前回実装しようとしていた機能が「プログラマの意図」でした。今回は、「前回実装しようとしていた機能だけでなく、今まさに実装している機能も加わったとき、それは何なのか?」というのが「プログラマの意図」ということになります。

これが「実装をシンプルにすること」です。

シンプルに実装することと、実装をシンプルにすることは車の両輪

そして、ここがこの記事の核心なのですが、シンプルに実装することと、実装をシンプルにすることは車の両輪だと思います。つまり、どちらか片方だけではバランスを崩し、うまく走ることが難しくなります。

「シンプルに実装すること」は、「実装をシンプルにすること」に依存しています。より正確に言うと、今「シンプルに実装」しようとしている人(便宜的に Alice と呼びます)が、のちに前述の「リファクタリングの 2 つめの機会」に触れる人(便宜的に Bob と呼びます)が「実装をシンプルにしてくれる」に違いない、と信じることに依存しています。

なぜなら、「Bob が(のちの機会に)実装をシンプルにしてくれるに違いない」と信じられなければ、Alice はあらかじめ「Bob が実装に取り掛かるタイミングになったとしても、十分シンプルであり続けられるであろう設計・実装」を想定して作り込みたくなってしまうからです。結果として、「シンプルに実装」することはかなわなくなります。

ひるがえって、「実装をシンプルにすること」もまた、「シンプルに実装すること」に依存しています。Alice が「シンプルに実装」してくれていればこそ、Bob は「実装をシンプルに」することができるからです。

もし Alice が「そのときにシンプルな実装ではなく、先々も十分シンプルであり続けられるであろうと考える設計・実装」をしていたとして、いざ Bob が実装しようとしたときには Alice の想定していたものとは違うものが必要になってしまっていたら、どうなるでしょう。Bob は、まず Alice の過去の想定を読み解き(直接聞いた方がよいとは思いますが)、現時点の最新の知識にもとづいて修正し、それから実装を(その時点での)シンプルなかたちにやり直す必要があります。それでも「実装をシンプルにする」こと自体は可能ではありますが、「Alice の作業がムダになる」「Bob が本来必要のなかった修正作業をするはめになる」という 2 つのムダが生じてしまいます。

だから、AliceBob を信じて常に「シンプルに実装」し、BobAlice が残してくれたシンプルさに報いるため、そして将来そのコードを触る人(それは Bob 自身かもしれないし、Alice かもしれないし、また別の誰かかもしれません)のために必ず「実装をシンプルに」するのです。そうすれば、車の両輪がバランスよく回り、XP による開発がもっともよい価値の流れを生み出すことができます。

2020年のふりかえり

やったこと

68 冊

今年読んだ本は、68 冊で着地。
年始に 50 冊以下にするという目標を立て、7 月に 80 冊までに下方(上方?)修正したが、無事 80 冊以下にすることができた。

と言ってはみたものの、上限の 80 冊に対してずいぶん余裕があることからもわかるように、あまり意識的に努力して数をおさえた、という感覚がない。ふつうに読んでいたらこうなっただけ。

こうなった大きな要因の一つは、おそらく通勤がなくなったことだと思う。短い通勤時間(ドアツードアで 30 分)ではあるけれども、されど往復 1 時間。週 5 日、月 20 日で考えると、月に 20 時間、年間 240 時間にもなる。1 冊読むのにかかる時間が平均 4 時間だとすると、これだけで実に 60 冊分だ。なるほど。

ともあれ、冊数は減った。では、もともとの目的に対してはどうだったか。

もっと読むのに時間がかかるような本や、異分野の本を読めるかもしれない。本ではない手段で学ぶ時間を増やせるかもしれない。アウトプットの時間をもっと取れるようになるかもしれない。

これについては、ぼちぼち、といったところ。

『学習する組織』や『世界標準の経営理論』といった、明らかに読むのに時間のかかる本に少し手を出しやすくなった。(どちらも読了はまだ)

今まであまりやってこなかった、家でコードを書く、ということにも少し多めに取り組んだ。(HTML/CSSDartClojure など)

アウトプットについては正直イマイチの感はあるものの、現在の職場に来てからすっかり仕事に満足して書かなくなってしまっていたブログ記事を(ふりかえり以外に)2 本は書いた。

enk.hatenablog.com enk.hatenablog.com

また、こちらは仕事だけど、久々にペアプログラミングについてなかなかいい記事が書けたのは満足度が高い。

tech.uzabase.com

そういえば、(細かいけど)Zenn でも 2 本書いたのだった。

新製品開発

7 月にも書いた新製品の開発を続けている。

前職でも新製品開発には携わったことがあったものの、日の目を見なかった。
今回は無事リリースされ、小さなところからでも世界を変えるために、サービスの開発と提供を続けることができている。

わかったこと

学習は続く

去年のふりかえりで、こういうことを書いていた。

ここ数年で、同じような本を見つけては読みしても、得られるものがどんどん減ってきているのを感じる。
理由はいくつも考えられるけれど、あえて大きく捉えると、「飽和している」のだと思う。

今年冊数を大きく減らしてみたことと関係があるかないかはわからないけれど、今年はそういう感覚がほとんどない。もしかしたら、いわゆる「プラトー」を脱したのかもしれない。

色々と学ぶ中で、今いる会社で大事にされている「ミッション、バリューで経営する」というのがどういうことなのか体感としてわかってきたり、『エクストリームプログラミング』を読み直して色々な再発見をしたり(これには『Clean Agile』の果たした役割も大きかった。ありがとうボブおじさん)。

もう一つ今年発見したのが、アウトプットによって学ぶ、ということ。これは常識の類で、再発見、と言いたいところだけれど、あえて自分に厳しい見方をするなら、アウトプットによって学ぶということを今まではそもそもわかっていなかったのかもしれない、と思う。

逆に言うと、アウトプットがなければ学ばない、ということ。これをわかっていなかった。どこかで、アウトプットは「学んだこと」を外部に出し、「学んだこと」を定着させるものだと思っていた。そうではなく、「アウトプットによって学ぶ」のだ。(ちなみに、このこと自体に、この文章を書きながら今気づいた。これがまさに「アウトプットによって学ぶ」ことの実例だと言えそう)

フェアに言うなら、アウトプットがなくても人は学ぶ。いや、うん、もちろんそうだ。ただ、アウトプットがあると効率が桁違いによくなる。

もちろん、アウトプットにはインプットよりも時間がかかる。だから、すべてのことをアウトプットによって学ぶわけにもいかない。とはいえ、重要なこと、ぜひ学びたいことについては、アウトプットすること。これが基本だということを知った。

今さらなのかもしれないが、これに気づいたのは個人的にとても大きい。これだけで向こう 5 年くらいは食えそうな感じがする。

つながっている感覚

今も取り組んでいる新製品の開発と提供を通じて、少しずつつながっている感覚を感じられるようになってきた。

つながっている感覚というのが個人的にとても大事で、というのは、個人の生活から、ソフトウェアの開発・運用、ビジネス、そして実社会への(よい)影響まで、すべてがつながっている感覚。
いくつかができていればよいのではなく、すべてができている感覚。これが大事だと個人的に思っている。ということを、昔からなんとなくは思っていたけど、今つながっている感覚を実際に感じられる中で、これが具体的な輪郭を持ってきた。

これを続けたいし、広げたい。個人的にもそういう環境にい続けたいし、みんながそう感じられるようになってほしい。

この感覚への選好は昔からある、個人的なものだけれど、とはいえ最近探求しているいくつかのものごととも関わりがあると思っている。たとえば、XP には「人間性」そして「相互利益」の原則がある。XP は、技術的な成功だけを目指していないし、ビジネスの成功だけを目指してもいない。そして、個人の欲求が満たされることを目指してもいる。リーンの全体最適の考え方やシステム思考も、おそらくこれと大きな関わりがある。

そういう仕方で仕事をしたい。

次にやること

月に 1 冊以上技術書を読む(※アジャイルの本など、コードが出てこないものは除く)

まだまだ学ぶべきこと、学べること、学びたいことがある。日々新しくなるソフトウェア業の仕事をしている限りはずっとそうなんだろうけど、もちろん今もそう。
先日『達人プログラマー』の 20 周年記念版を読んで、技術書の読書ペースがそれほど速くなくなっていることに気づいた。

『達人プログラマー』の「あなたの知識ポートフォリオ」という項目では「月に 1 冊のペースで技術書を読む」ことがすすめられているが、数えてみると、2020 年は 9 冊しか読んでいない。最近は Web 上のリソースなども充実しているとはいえ、体系的なインプットの手段としては、今も本は有用だと考えている。(少なくとも、本好きの自分にとっては)

ここで基本に立ち戻り、月に 1 冊以上技術書を読む。

月に 1 本以上記事を書く

この記事を書いて最大の発見は、「アウトプットによって学ぶ」ということ。今年最大の発見と言ってもいいかもしれない。

さっそくこれを活かす。そのために、月に 1 本記事を書くことにする。書く先はこのブログでもいいし、Qiita や、Zenn でもいいだろう。内容も書評でもいいし、こういうふりかえりでもいいし、技術メモでもいい。とにかく、アウトプットによって学ぶのである以上、学ぶためにアウトプットをする。

あとは自由

あとは自由。

あえてこう書いたのは、ここ数年の実績から考えると上の 2 つを達成するのがそれほど簡単ではないということもあるけれど、自由でも大丈夫そうだな、と思ったというのもある。生活をどうするとか、(技術以外の)〇〇のことを考えるとかするとか、決めない。

上に定めた最低限の 2 つの規律だけあれば、あとはなんとかなる、という謎の楽観がある。その理由の一つは、「わかったこと」のところで書いた、このあたりだろうか。

いくつかができていればよいのではなく、すべてができている感覚。これが大事だと個人的に思っている。ということを、昔からなんとなくは思っていたけど、今つながっている感覚を実際に感じられる中で、これが具体的な輪郭を持ってきた。

3 年前のふりかえりのときには、こういうことを書いていた。

かれこれ 10 年近く前からずっと、最大の課題が「自分がどこに行きたいのかよくわからない」ということで、ごまかしごまかしやってきたものの、いい加減年貢の納め時なのでは、という気がしてきています。
世の中誰もが「自分がどこに行きたいのか」わかってるわけでもないのだとは思うのですが、ずっと引っかかっていることなので、何らかのかたちで折り合いをつけたいと、いう気持ちがあります。

「どこに行きたいのか」(trip のイメージ)と問うても答えはなく、むしろ「どう行きたいのか」(journey のイメージ)と問えばいいのだ、ということがわかってきたのかも。だから、自由でいいんだ、と感じられるようになってきたのかもしれない。

【翻訳】忘れられたプラクティス: バックログ優先順位ゲーム(Backlog Priority Game)

この記事は、Forgotten practices: The Backlog Priority Game (Zuzi Sochova) の翻訳です。


バックログの優先順位付けは、多くの企業にとってアジャイルの受容におけるもっとも難しい部分の一つです。では、それを正しく行う方法は何でしょうか? 推奨事項や、何らかの手法があるのでしょうか。それとも、プロダクトオーナーが決めればそれで十分なのでしょうか? こういった質問や、似たような質問がよく出てきます。

バックログの優先順位付けについて、最もよくあるシナリオは次のような主張から始まります。「要件の優先順位は常に定めてきたし、今までそれなりにうまくいってるのに、どうして何かを変える必要があるっていうんだ?」 ところが、そのプラクティスをよく見て理解しようとしてみると、現実は通常、まったく調和の取れたものではないことがわかります。チームは個々の機能のビジネス価値の理解度が非常に低く、いずれにせよ全部終わらせる必要があることを理由に、たいていは自由な順序で取り組みます。ビジネスが興味を持っているのは、予定通りリリースが行われるかどうかだけです。そういうわけで、アジャイルを始めたら、ユーザーストーリーは3種類の優先度を持つことになります。全機能の 60% は優先度「1」、必ず含める必要のある機能という意味です。約 30% は優先度「2」、これもまた必要な機能です。残り 10% が優先度「3」、これもほとんどの場合は含めるべき機能です。もしかすると、「優先順位付け(prioritization)」という言葉は間違っていて、「並び替え」という言葉を使うほうがよいのかもしれません。とはいえ、どんな表現であっても誤解されることはあるので、問題の原因を名前に押し付けるわけにはいきません。このような機能不全のプロダクトオーナーの影響下にあるチームには、うまくやるためのいくつかの選択肢があります。一つは、ギャップを乗り越えて、失われたビジネスのコンテキストをできるだけ速く把握しようとする「プロダクトオーナー代理」の役割を置くことです。もう一つは、プロダクトオーナーを押し返して、次のスプリントの優先順位を決めることはプロダクトオーナーの責任であり、決めてくれないのならアルファベット順に取り組むだけだと単に伝えることです。

バックログをこのようなやり方で並べ、チームの実際のベロシティに基づく太くて赤いラインを引いてプロダクトオーナーに示し返せば、どの機能が次のリリースに含められ(ラインより上)、どの機能が含められそうにないか(ラインより下)を可視化することができ、たいていはプロダクトオーナーを優先順位付けのプロセスに立ち戻らせることができます。このような状況は、プロダクトオーナーが行動を起こし、実際の優先順位と機能性の変更を検討し始めるのに十分な強さのプレッシャーを生み出すのです。「相対重み付けゲーム(Relative Weight Game)」をプレイする時が来ました。

あなたは、プロダクト企業の一員だとします

その場合、優先順位付けの鍵はシンプルです。ビジネス価値と、そのコストに着目するのです。コスト対価値の比率が大きければ、その機能に投資します。小さければ、改善のためのアクションを取るか、バックログからその機能を削除します。

このアプローチをサポートするのが、以下の手法です。目新しいものではありませんすが、やり方を知っているチームは多くはありません。この手法は、アジャイルチームでユーザーストーリーの見積もりによく使われる相対ポイント見積もりと同じ原則にのっとり、相対的な重みにもとづいています。考え方はシンプルです。アジャイル手法の力のほとんどはチームワークに由来するので、プロダクトチームを作ることから始めます。プロダクトオーナーは実際には一人でこのゲームをプレイすることもできますが、その場合、他の人たちの視点を欠くことになります。議論の欠如によって予期しない問題に遭遇したり、ビジネス価値の重要な側面を見逃すことになるおそれがあります。チームの構成は、プロダクトや企業の構造、役割によって異なるかもしれません。ある程度のカスタマイズが可能なパッケージ製品を作っている企業の場合、プロダクトオーナーは通常、ビジネスアナリスト、UX デザイナー、ソフトウェアアーキテクト、マネージャといった人たちを巻き込むことになるでしょう。ある時点で、コンサルタントや顧客の代表者にも議論に加わってもらうかもしれません。ユーザーストーリーの優先順位についての決定は、それでもプロダクトオーナーに委ねられています。とはいえ、そういった人びとによる議論はたいてい非常に価値あるものとなりますし、プロダクトオーナーが一人で優先順位を決めた場合よりもずっと質の高い決定を下すことが可能になります。

プロダクトオーナーはなお、このプロセスのキーパーソンです。プロダクトオーナーはミーティングを主催し、議論をファシリテートします。意思決定、全体的な機能性、ひいてはプロダクト全体の成功に責任を負うのです。ユーザーエクスペリエンスの専門家の役割は、企業ではしばしば過小評価されています。しかし、そのような専門家はプロダクトの成功にとって必要不可欠です。ビジネス価値に対する彼らの視点は、最終的なプロダクトのほとんどに欠けているものかもしれません。そのような専門家たちは、プロダクトオーナーがビジネス価値を保ちながら機能をシンプルにするのに役立ちます。そういったチームに求められる次の役割としてあげられるのは、ビジネスアナリストです。その役割自体は、かなり論争の的になっています。多くの場合、ROI とのつながりがなく、すべての潜在顧客の要求を満たすために機能をできる限り拡張しようとするからです。特に、誰もが自分の役割に固執し、コンピテンシーが役割ごとに正式に分けられているような形式ばった環境ではこれが顕著です。この場合、プロダクトオーナーは抽象度の高いビジョンと戦略を持ち、個々のユーザーストーリーの詳細には関与しません。一方、ビジネスアナリストは、顧客との関係や環境の詳細に通じていないのです。そのため、それらの人たちを集めて共通の目的を持つ単一のチームを作ることは実際よいアイデアであり、それ自体かなり有効になりえます。他の役割としては、ソフトウェアアーキテクトがあげられます。ソフトウェアアーキテクトは、プロダクトオーナーが技術的なリスクを取らずにすむようにできます。たとえば、チームがこれから必要になる技術の経験がないとき、課題に対するスパイクを打ってプロトタイプを構築したり、リスクを解消するために一つのユーザーストーリーを届けることが賢明かもしれません。結局のところ、可能な限り顧客と接し、技術的な観点から意味があるだけではなく、ビジネス上の理由からも投資に値する解決策を提案することはアーキテクトの役割です。このグループのメンバーは、ここで言及した役割に限りません。価値ある意見を出してくれそうな人であれば、誰でも招待してください。

ビジネス価値の見積もり: 相対重み付けゲーム

プロダクトチームができたら、ビジネス価値を見積もるためのポイントを用いて、ゲームを始めることができます。ポイント見積もりのプロセスにおいて議論は最も重要な部分なので、ビジネス価値見積もりのゲームにおいても同様です。あなたはチームとして、バックログに含まれるすべてのユーザーストーリーに対して 2 つの独立した値を見積もることになります(なお、バックログが議論を方向付けます)。チームはさまざまな種類のメンバーで構成されているので、すべての異なる側面が考慮されます。最初に見積もる値は、「ベネフィット」です。その機能の価値にどれほどの重み付けをするか、ということを意味します。2 つ目の値は、「ペナルティ」で、そのユーザーストーリーを実装しなかった場合の損失の重さを表しています。それぞれの見積もり値は、同じ種類のもの同士、相対的な値です。通常は、いずれも 0 から 100 までの範囲の値で見積もります。たとえば、あるユーザーストーリーがマーケットにおけるどのプレイヤーもが持っている機能を表していて、ゆえに実装が期待されているなら、0 に近いとても低いベネフィット値と、100 に近いペナルティ値を与えられるかもしれません。逆に、あるユーザーストーリーが競合他社に対する差別化要因となり、かつユーザーにとって本当に重要なものであれば、そのような機能が実装されるとは誰も予期していないわけなので、ベネフィット値は 100 に近く、ペナルティ値は 0 になるかもしれません。キーとなるストーリーはベネフィットもペナルティも 100 になるかもしれませんが、ほとんどの機能には中間の値が与えられるはずです。ベネフィットとペナルティは互いに独立していることを忘れないでください。値を得るためにプランニングポーカーや魔法見積もり(Magic Estimations)を行うこともできますが、よい見積もりを得るにあたっては、数字はあくまで議論の脇役にすぎないことを覚えておいてください。早く結果を得るために議論を省略してはいけません。ビジネスの視点が必要なので、顧客の立場から見積もりを見るようにしましょう。これは普段やっていることとあまり変わらないと思うかもしれませんが、ベネフィットとペナルティという 2 つの異なる見方をする必要があることで、重要な側面を決して見落とさずにすみます。企業による優先順位付けのほとんどは直観だけで行われていて、ベネフィットの方のみを考慮し、ペナルティについては目立って明らかな場合にのみ検討するのが普通です。

ベネフィット値とペナルティ値がわかったら、それらの見積もりを合計してビジネス価値(BV)を算出します。

ベネフィット + ペナルティ = ビジネス価値(BV)

その数値は 0 から 200 の間になります。これで終わりにして、ビジネス価値に応じてバックログの優先順位付けをすることもできます。しかし、多くの場合では、もう少しゲームを続ける必要があります。各ユーザーストーリーのビジネス価値/コスト比を比べるために、チームにストーリーの複雑さを見積もってもらうのです。その計算結果が、バックログアイテムの優先度になります。

優先度 = ビジネス価値(BV) / 複雑さ

ビジネス価値に対するコストが低い「クイックウィン」がバックログの一番上に行き、範囲が広く難しい機能ながら価値は限定的なものが一番下に行くことがわかります。なお、これらは単なる数字にすぎないので、結果が気に入らない場合は変えても構いません。ただし、よりよく見て、議論の内容をもう一度思い出すことを検討するとよいかもしれません。すると多くの場合、ベネフィットとペナルティが独立した値として正確には見積もられていなかったことに気づくでしょう。もっとよくあるのは、ビジネス価値/コスト比を改善するためにユーザーストーリーをより小さなストーリーに分割する必要性に気づくことです。ビジネス価値と複雑さが機能性の全体にわたって均等に分布していることなどないからです。価値を届けられるけれども、実装はそれほど難しくなさそうな要素があることに気づくでしょう。一方で、限られたビジネス価値しかないけれども、機能実装の足手まといになる要素もあるでしょう。たとえば、あらかじめ定義されたフィルタを用いてデータをチャートに描けば、ユーザーの要求を満たすのに十分かもしれませんが、顧客がフィルタを作れるようにするのは難しいかもしれません。いくつかの調査によると、成功したプロジェクトの約 60% は一度も使われたことがないか、ほとんど使われていないということを忘れないでください。機能を削るのは難しいことですが、優先順位付けのプロセスに顧客を巻き込み、機能のコストを説明すれば、顧客はすぐに賛成してくれるかもしれません。

相対重み付けゲーム(Relative Weight Game)はアジャイルコミュニティでもあまり知られていませんが、プロダクト指向の開発においてとてもよい結果をもたらします。さらには、簡単に、楽しくプレイすることもできるのです。

この記事は、2013 年 5 月 の Agile Record No14 に掲載されました。

魔法見積もり(Magic Estimation)

はじめに

バックログ優先順位ゲーム(Backlog Priority Game)」について説明するこの記事を読んでいて、「魔法見積もり(Magic Estimation)」という手法に出会った。

agile-scrum.com

You can play Planning Poker or do Magic Estimations to get the values, but remember that, to get good estimates, the numbers are just a side effect of the discussion, ...
(値を得るために、プランニングポーカーや魔法見積もりをすることができる。ただし、よい見積もりを得るためには、数字はあくまで議論の脇役にすぎないことを覚えておくこと...)

魔法見積もり、むやみにワクワクする響きだな……!? と思ってちょっと調べてみた。*1

魔法見積もり(Magic Estimation)

Magic Estimation を説明するいくつかのページを読んでみたところ、少しずつ違いがあったものの、共通していたのは以下のようなこと。

  • たくさんのバックログ・アイテム(a.k.a. ストーリー)をすばやく見積もる方法。
  • 予め、想定されるストーリーポイント(「Tシャツサイズ」のようなものでもよい)の枠を作っておく。「1、2、3、5」など。
  • チーム全員で一斉に、アイテムをその大きさにしたがって並べ替える(それぞれのポイントの枠に入れる)。
  • 並べ替えの前半は会話を禁止し、黙って行う。のちに議論して、並べ替えを完了させる。

魔法見積もり、何だろうって思ってたけど、やったことあるやつだった。

最近やった魔法見積もり

これまでにいくつかのチームでいくつかのバリエーションを試したことがある(いずれもいい感じに機能した)んだけど、直近チームでやったときの様子を紹介してみる。

様子

  • リモートで行なった。
  • チーム 4 名がビデオ通話をつないだ状態で、オンラインホワイトボードツールの Miro を開く。
  • 候補となるストーリーポイントの枠(1、2、3)を作る。
  • 見積もりたいすべてのストーリーの付箋(37 枚)をボードに適当に並べる。
  • 各自が思い思いに付箋を枠に入れていく。
  • このときは、「前半は会話禁止」というルールは特に設けなかった。適宜喋りながら(「あれ、これ2じゃなくて1じゃないっすかね〜」「なんで?」「〇〇だから」「たしかに」「じゃあこれも?」……)進めた。
  • 15 分くらいですべてのストーリーにポイントがついた。

何が起きたのか?

今回、37 件ものストーリーを一気に見積もることになって、そのときちょっと時間もおしていたので、効率よくやりたい思いがあり、魔法見積もりをやることになった。(そのときはまだ「魔法見積もり」という名前を知らなかったけど :))

結果、うまく情報交換(ストーリーについて知っていることや、気づいたことの共有)もしながら、かなり妥当性の高い見積もりを出せたと思う。

たぶん、1 件ずつプランニングポーカーでやっていても、ほぼ同じ結果になった。でも、プランニングポーカーでやっていたら、たぶん 2 倍以上の時間がかかっていたと思う。経験上ストーリー 1 件の見積もりに平均 1 分程度はかかるので、37 件だと 37 分。15 分の 2 倍以上だ。

目論見通り、アウトプットの質を落とさずに、効率よく見積もることができた。

なぜうまくいったのか?

今回特にうまく行った理由(だと思うこと)を箇条書きにしてみる。

  • 予めストーリーが洗練されていた。チームみんなでストーリー出しをやったあと、一つ一つ見て確認していく時間を取った。不明瞭なストーリーは書き直したり、分割したりした。ここで全員の認識が揃った。(これに 30 分くらいかかった)
  • 予めストーリーの大きさがおおむね揃っていた。チームの慣習として、ストーリーポイントは最大 3 ポイントまでにしている。それ以上の大きさの場合は分割する。その習慣があったので、ストーリーを出す時点でおおむね 1〜3 ポイントの大きさになっていた。
  • チームの人数が比較的少なかった。4 人だから、会話を禁止せずに喋りながらでもスムーズにやれたと思う。もっと大人数だと、「前半は会話禁止」というルールをちゃんと適用したほうがいいかも。

その他の補足情報

  • 各ポイントのリファレンスとなるストーリーを予め 1 つずつ定めておくという方法もある。チームで各ポイントの大きさのコンセンサスがまだ確立していないときは、この方がいいかもしれない。
  • 予めポイントの枠を定めるのではなく、まず並べてみて、そのあと各ポイントの境界線を引くという方法もある(「親和見積もり(Affinity Estimation)」というらしい)。
  • 私たちのチームではみんなで適当にワイワイやったが、慣れていないチームでは正式なファシリテーターがいた方がいいかもしれない。スクラムの場合、スクラムマスターがその役割にちょうどいい。
  • いずれにせよ、チームとプロダクト・プロジェクトの現在の状況に応じてプラクティスを調整することが大事。

まとめ

魔法見積もりはシンプルで、たくさんのバックログ・アイテム(a.k.a. ストーリー)をすばやく見積もることができるすぐれた方法だと思う。 うまくいくと本当に魔法のようにあっという間にストーリーポイントが決まるので、なかなかいいネーミングだと思う。

あと、「魔法見積もりやりましょう」って言うとなんかかっこいい。これからも必要に応じてやっていきたい。

参考文献

こちらの記事の説明が簡潔でわかりやすかった。
本記事だけで物足りない場合はあわせて読んでみてください。

www.wibas.com

*1:上記ページには魔法見積もりについての説明はなかったので、他のページを参照した