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

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 つのムダが生じてしまいます。

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

2020年のふりかえり

やったこと

68 冊

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

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

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

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

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

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

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

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

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

enk.hatenablog.com enk.hatenablog.com

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

tech.uzabase.com

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

• kubectlでGKEにつなごうと思ったら"error executing access token command"
• DbUnitのTIMESTAMP型のカラムに正確な日時を渡す

新製品開発

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:上記ページには魔法見積もりについての説明はなかったので、他のページを参照した

2020 年前半のふりかえり

ふと思い立ったので、2020 年前半をふりかえってみる。

やったこと

42 冊

読書メーターの記録によると、2020 年前半に読んだ本は 42 冊。
もともと 2020 年は読書数の上限を 50 冊までにするという目標を立てていたのだけれど、達成できそうにない。（超えてしまいそう）

6 月に会社の制度を利用して一週間の休暇を取ったとき、一気に 8 冊読んでしまうなど、消化が激しかった。
本の誘惑には抗いがたい。

新製品開発

この半年は新製品の開発に関わっていた。
事業開発・デザイナーのメンバーと組んで、高い技術力を持った開発チームの中で、既存のマイクロサービス群も活用しながら、とはいえほぼ一から Web サービスを組み上げる仕事。

システムシンキング

昨年はデザインシンキング、ロジカルシンキング、そしてアートシンキングと、さまざまな思考のあり方に触れる年だった。
そして今年になって、システムシンキングに出会った。

まず読んだのが、ドネラ・メドウズの『世界はシステムで動く』。

世界はシステムで動く ―― いま起きていることの本質をつかむ考え方

そして今、ピーター・センゲの『学習する組織』を読んでいる。

学習する組織 ― システム思考で未来を創造する

リモートワーク

対面でのコミュニケーションと常時ペアプログラミングを旨としている弊チーム も、この社会状況下なので現在は 100% リモートで仕事をしている。

とはいえ、基本的な仕事の仕方は変えていない。テキストではなく音声（とビデオ）によるコミュニケーション、常時（リモート）ペアプログラミング。
前述の新製品も、そうやって開発した。案外、できるものだ。

リモートワークにあたって投資は惜しまなかった。
マイク付きイヤフォン、大きな 4K モニタ、ラップトップ用スタンド、高品質なオフィスチェア、高品質なネット回線。

Apple EarPods with 3.5 mm Headphone Plug

Dell 4Kモニター 27インチ U2720QM(3年間無輝点交換保証付/広視野角/HDR/IPS非光沢/フリッカーフリー/USB Type-C,DP,HDMI/高さ調整/回転)

Twelve South Curve Stand for MacBook デスクトップスタンド ホワイト

オカムラ オフィスチェア コーラル ハイバック 固定肘 ブラック CQ45BW-FSH1

これは、正解だったと思う。
ちなみに、オフィスチェアはオフィスバスターズで送料含め 35000 円ほどで購入した。（それ以外は新品）

ソーシャルディスタンスと演劇

演劇をやっているのだけれど、従来の舞台における演劇は（残念ながら）三密の条件を満たしてしまっている。
劇場（稽古場を含む）は閉鎖され、ここ数ヶ月ずっとリモートでの稽古のやり方を模索してきた。

今月になって条件付き（人数制限・定期的な換気）で稽古場は開いたものの、行政の方針（所属しているのが府中市の市民劇団なので）もあって、今年の本公演は既にキャンセルが決まっている。
とはいえ、劇団員たちは頼もしく、リモートで、あるいは三密を慎重に避けながらどうすれば活動や制作ができるか、考え、試している。

わかったこと

スペースを開けることはできている

目標の年間 50 冊（以下）に対して半年で 42 冊も読んでしまったのは困った事態ではあるが、例年の年間 100 冊ペースに比べると、多少ペースを落とすことには成功している。
その分何をやっているかというと、Web 上の技術リソースに本格的に取り組んだり、気軽に読めそうな本はなるべく控えて、歯ごたえのありそうな本に取り組んでいる。
理想には届かないまでも、少しずつ行動の変化が起きている。

自分をラーニングゾーンに置き続けられている

今回の新製品開発は、技術的にも、事業内容的にも、ワクワクする内容で、半年間のほとんどの時間、自分をコンフォートゾーンでもパニックゾーンでもなく、ラーニングゾーンに置き続けることができたと思う。
製品と、チームとともに自分も成長して、製品・チームに還元していく、ほとんど理想的な状態だったんじゃないか。（もちろん、すべてが快適というわけでも理想通りというわけでもなかったけれど、ふりかえって俯瞰してみるとそう感じられるということ）

今、システム思考

『学習する組織』は最初に入った会社で事業所（支社）の方針として掲げられていて、興味は持ったものの、あまり深入りすることはなかった。（システム思考とは何か、といったことを理解するまでには至らなかった）
なので、『学習する組織』とは 10 年越しの出会いということになる。

とはいえ、不思議と「あの時読んでおけば……」といった感覚はない。今出会うべくして出会った、という感じがしている。

昨年末のふりかえりでこんなことを書いた。

全体として、大きなもの、根源的なもののことを考えていきたい。
（中略）
動きながら、大きなものを捉えられないか。
さまざまなものごとの根本にある、理のようなものに、少しでも近づけないか。

システム思考こそが答えだ、と言うつもりはないけれど、少なくとも一つのヒントであることには違いない。

システム思考では、システムの全体を捉えて、レバレッジの大きな介入ポイントを探す。
この「システムの全体」、あるいは「レバレッジの大きな介入ポイント」は、昨年末に書いていた「さまざまなものごとの根本にある、理のようなもの」に何らか通じる部分があるように感じている。

リモートワークに向いている

数カ月間リモートワークをしてみて、どうやら自分はリモートワークに向いているようだ、ということがわかってきた。

あくまで自己評価だが、

• サボることなく、しっかりアウトプットを出す（出そうとする）。
• 過剰に働きすぎることなく、休むときは休んでメリハリをつける。
• オンサイトで働いていたときよりも、少し厚め（冗長気味）に情報共有をして、コンテキストが落ちにくくする。

といったことが自然にできている（と思う）。

もっとも、開発はペアでやっているので、最初の 2 つについては個人の能力ではないのかもしれない。

一番大きな発見だったのがむしろメンタル面というか、生活面というかのところ。

チームの中には、リモートワークになってから物足りない、寂しい、といった感覚を持って、ストレスを感じている人が結構いるようだった。
僕の場合、もちろんその人たちの感覚を否定するものではないけれど、個人的には、そう感じたことがない。

こう書いてみて、まったくないというのもちょっと極端というか、人としてどこかおかしいのではないか、という不安もよぎるが、実際にそうなのだから仕方ない。

つまり、リモートワークになったことでストレスを感じたり、パフォーマンスが大きく落ちたり、ということが今のところ特にない。（肩こりなどの問題は一時的に生じたが、設備投資で解消した。リモートペアプロにはストレスを感じることがあるが、リモートワークに起因するというよりは、リモートペアプロの「やり方」に起因するストレスだと思う）

これはある意味恵まれているということで、だからこそ、リモートワークでストレスを感じている人たちへの思いやりを忘れないようにしたい、とも思う。

演劇もやってやれないことはない

現在、従来の形での演劇はとても難しい。
それでも、いろいろなやり方を模索して、少しずつ慣れてきたり、道筋が見えてきたりしつつある。

もちろん感染拡大の防止が最優先事項ではあるので、そこに反しないやり方で、演劇を続けられたらと思う。

次にやること

全体として、ここ半年の厳しい社会状況の中で、なんとかうまくやっていくことができている。
その理由は色々あるにせよ、一番大きいのは「運がよかった」ことだとしか言いようがないようにも思う。

システム思考を学んで、もっと個人（自分や、その周り）ではなく、社会や世界というシステム全体のことを優先的に考えたほうがいいのではないか？　という思考が芽生えつつあるのを感じている。
だが、まだ社会貢献活動に自分の多くの時間を使おう、といった風には思えていない。なぜなのかは、わかるような、わからないような。

なんというか、そうなるときには自然にそうなるという気はしている。
それまでは、恵まれたものを、せめて無駄にしないようにしっかり活用していきたい。

読書数上限については、目標修正。
50 冊は間もなく超えてしまい、その後一切本を読まないというわけにもいかないので、今年の上限を 80 冊とする。
これはとりあえずの目標（「50 冊」はそういう感覚だった）ではなく、必達と考える。そのために定期的に冊数を確認し、超えそうなペースなら具体的な対策を取る。

開発した新製品には今後も関わるので、そこでしっかり成果を出す。
技術面から、セールスと顧客の成功に最大限貢献する。そのために何ができるか、視野を広く持って考え、実行し続ける。

演劇も続ける。ただし、これは安全第一で。