アート・オブ・アジャイルデベロップメント読書会 8.8 見積もり
===
###### tags: `アートオブアジャイルデベロップメント読書会`

[読書会インデックスページ](https://hackmd.io/qzr55OUxR_aKBNKZjRaxwA?view)


# Discord開始位置

* [connpass募集ページ](https://agiledevs.connpass.com/event/193498/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)
* [discord:2020/12/06](https://discord.com/channels/767540649418686486/774111081634332673/785112149344780289)

# 自己紹介

- ファシリ役
-
- 読み上げ役
-
- タイムキーパー

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

[アートオブアジャイル輪読会はじめの1歩 - Speaker Deck](https://speakerdeck.com/t2kob/atoobuaziyairulun-du-hui-hazimefalse1bu)

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はアジャイル非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1: :+1: :tada:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 参加者アンケート | |
| 20:25-20:35 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:35-21:35 | 60分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
| 21:35-21:40 | 5分 | 次回開催日と読む範囲決めてクローズ | |

# 下に感想などを書いていって下さい。どんな些細なことでもOKです。

# 感想など

## 目安の時間

## 感想・気づき

- 参加者にアンケートを取って、見積りが1番関心のあるものとして投票されたことが面白い。それほど悩むことが多いのだなぁと。:+1::+1::+1::+1:

### 8.8 見積り
- > 3倍にするのが一般的なやり方だ
- そうなんですね！
- 実質ノー根拠でそこまで盛るの勇気入りませんか！？笑:+1::+1::+1::+1::+1:
- 不確実性コーンだと4倍でしたっけ？

### 8.8.1 見積りでうまくいくこと（いかないこと）
- > 理想エンジニアリング日(ストーリーポイントと呼ばれることが多い)
- 相対見積もりの内容とは別のもの？
- 見積もる人毎に理想日は異なるので、理想日を使うのはスプリント0のときだけにしたいかなと考えています。スプリント1以降はストーリーごとの規模で相対的なサイズで比較した見積もりのほうがシンプルで長持ちする印象。『アジャイルな見積もりと計画づくり』でも理想日よりも相対的なサイズ(ストーリーポイント)を推奨していたような気がします。:+1:
- 理想日を見積もりに使う場合、多くのタスクをペアプロで行うことが前提にあってのことかもしれないなと思いました。(スキル差を埋められるため)

### 8.8.2 ベロシティ
- > 見積もりはほとんどの場合、正確であることはないが、不正確なりに**一貫している。**
- 不正確でも良いから一貫した（できるだけ明確な）基準で見積もること。それに対し実際の消化した結果というベロシティで比較することで完了の予測が立てられるようになる、という理解です。
- > ベロシティはチームの作業負荷のバランスをとる極めて効果的な方法だ。うまく回っているXPチームでは、ベロシティは十分安定していて、高い確度でスケジュールを予測することができる
- 個人的な体感として、そのとおりかなと思います。次のスプリント計画時とスプリント終了時の実績の差は+-0~4%に収まっていました。
- ベロシティが計測されていないチーム or 知見がない領域では、かなり感覚的になりそうなので、予測が難しいですね。
- 「ベロシティはフィードバックループを使っている」という捉え方はしたことがなかった。でも、確かに毎週「直近のベロシティ」は補正されるのだからその通りだ
- クリーンアジャイルでも、以下のようにある。結構重要なポイントなのだろう。
> ストーリーポイントとは、正確さと精度の両方を扱う技法であり、非常に細かいフィードバックループを使用して、現実に対する見積りを何度も調整していくものである。

### 8.8.3 ベロシティとイテレーションのタイムボックス
- ちょっとごまかして長時間労働をしたくなったり、話を終わらせて速度を少しでも上げるために、繰り返しの締め切りを滑らせたくなったりすることもあるでしょう。そんなことはしないでください。(DeepL和訳)
- タスクを小さく切って(長くても2日規模)、かつこのプラクティス(残業しない)を実践した時、スプリントあたりの見積もり精度が上がった実感がありました。毎回、ほぼ見積もり通りの成果になる。
- タスクの小ささはズレの少なさに比例しそうですね:+1::+1::+1::+1:
- 一方で、マネージャからはチケットを細かく分けると (工数とかの数値が) 把握しにくいとかクレームが入ってうざい:angry:
- > ベロシティはスケジュールを予測するためであって、生産性を判断するためではないことをおぼえておこう :+1::+1::+1::+1::+1::+1:
- > 機能を測定する代わりに、ビジネスにおけるチームの影響力を測定しよう(投資収益率のような)(P152)
- これは「何を作るか」まで含めて開発者の責任範囲で及ぶ前提でないといけない気がする
- ストーリーポイントは見た目数字なので、生産性を計測する目的で誤用されがちなのはあるあるですね。ポイント数じゃなくS/L/Mみたいなサイズ表記にしちゃう案もあるようですね。:+1::+1::+1::+1:
- 「生産性ではなくチームの健康状態を可視化するためのポイントです」って説明していました:+1:

### 8.8.4　一貫性のある見積りをする方法
- > もし専門家だが見積りをする能力に自信がない場合、肩の力を抜こう。意識しなくてもよい見積りをすることができるようになる。あなたがやろうとしている仕事を想像して、最初に頭に浮かんだ数に決めよう
- > よい見積りをするために、直感に頼ろう。
- どれだけ時間や労力をかけても、正確な見積もりは不可能(未来を見通すことはできない)ので、どこかのタイミングで「えいやっ」と決めるしかないなという印象。ざっくり規模や過去のストーリーのポイント数を比較してこんなものかなと見積もることが多いです。
- ベロシティで計測すれば、ここの見積でバッファを取る必要はない、傾向値のフィードバックがそこを吸収してくれる

- > プログラマは全員、見積もりに参加すべきだ
- 一貫性のある見積もりをするためには一定の基準があるべきで、逆に言えば個人の基準では一貫性がブレるのだと思う。
- また、声の大きい人（意見の強い人）に引きずられないようにする配慮も必要だと思う（例：プランニングポーカー）:+1::+1:

- > ベロシティが自動的に短期的な見積もりにしかるべき量の余裕を持たせ、リスク管理が長期的な見積もりに余裕を持たせる:+1:
- 余裕を持たせる仕組みが組み込まれているということですね。

### 8.8.7 見積もりが難しいとき
- > もしプログラマが技術を理解していないのなら、すぐにスパイクストーリー（技術調査のためのストーリー）を作って先に進もう
- それはそう。なのだけど、P.274では1日あれば充分とされてますが、足りないこと多くないですか？バグの場合もそうですが、調査系ストーリーの見積もりは本当に難しい…:+1::+1::+1:

---------------------

## 疑問・参加者に聞いてみたいこと

### 「見積もり」全般
- みなさんはいまどういう見積もりをしていますか？:+1::+1::+1:
- 実績はどのように集計していますか？:+1:
- 実績時間数の記録、めんどうくさくないですか?
- 見積りと担当者決め、どちらを先に行ってますか？
- そもそも見積もりとはなにか？
- そもそも見積もりはなんのためにやるのか？:+1:
- 皆さんが見積で困っていることって何ですか？:+1:

---------------------

### 8.8.1 見積りでうまくいくこと（いかないこと）
- 見積もりが難しい理由の一つは、プログラマーが自分の時間をどのように使うかをほとんど予測できないからです。8時間の集中力を必要とするタスクは、プログラマーが絶え間ない中断に対処しなければならない場合、2～3日かかる可能性があります。(DeepL和訳):+1:
- 複数プロジェクトという体制は避けられないケースもあると思います。兼任者が含まれる状況での見積もりでの工夫とかで実践していることありますか?
- 2つ掛け持ちなら、0.5+0.5ではなく、0.2をコンテキスト切り替えコスト、稼働は 0.4ずつしか見込まないとか(0.2はジェラルド・ワインバーグの出してる数字)
- ストーリーのポイント数と時間を完全に分離するようにしています。熟練したメンバーであろうが、稼働が半分しか避けないメンバーであろうがポイント数は変動しない(規模)で見積もっています。時間を見積もるときは、直近のベロシティ(1スプリントでこなせるストーリーポイント数の合計の平均)であったり、キャパシティ(1スプリントで稼働できる個々人の時間)から、見積もるようにします。稼働率に関することはキャパシティに反映され、それは自ずとベロシティに現れてきます。:+1::+1::+1: :+1:
- :memo: 1プロジェクトだけど扱う範囲が広すぎて、実施複数案件を抱えている状態になると、常にコンテキストスイッチが発生し続けているような状態になってつらみ……。
- この本では理想エンジニアリング日が紹介されていますが、相対見積の方がポピュラーだと思います。理想エンジニアリング日を使ったことがある人はいますか？:+1::+1::+1::+1::+1:
- (この本は10年前のものなので、単に廃れて行ったプラクティスかも、とは思いつつ)
- ケント・ベックは「だが、今では実時間で見積もるのが私の好みだ」とXP本に書いてますね。（ストーリーポイントによる見積りと対比しつつ）
- この本の12章（P.90） https://www.amazon.co.jp/dp/4274217620/ref=cm_sw_r_tw_dp_x_wtF1FbJJ52CZJ
- 理想エンジニアリング日を使う見積もりと、よくあるWBSの人日見積もはぱっと見似ているように見える。何が違うのか？(これを議論すると理解が深まりそう、という意味の投げかけです)
- みなさん、理想エンジニアリング日の1日は何理想時間でしょうか？:+1::+1::+1:
- 「割り込みに必要な時間量はイテレーションごとに一貫した傾向がある」は本当か？なぜそうなるのか？:+1::+1:

### 8.8.3 ベロシティとイテレーションのタイムボックス
- > ベロシティは生産性を判断するためではない
- 生産性の判断には何を使うのがいいのだろう？:+1::+1:
- 6.8の章にはビジネス価値をつかおう、と書いてあるが皆さんはどうしていますか？:+1::+1:
- > もし チームのベロシティが四半期に1回か2回以上変化しているなら、私はもっと深い問題を探すようにしている。
- もっと深い問題とは例えばどのような問題だろう？:+1::+1::+1::+1:

### 8.8.5 ストーリーの見積り方
- 理想日というのは、タスク担当者の理想日にするのでしょうか？経験の浅いエンジニアがいた場合、そのエンジニアに合わせる？:+1::+1::+1::+1::+1::+1::+1:
- > (P279)　見積もる時には楽観的な値を1つ選ぼう。もし邪魔が入らなくて、チームの誰とでもペアを組むことができて、すべてがうまくいくなら、そのストーリーにどれくらい時間がかかるか？
- と、ある
- :memo: 基準のタスクを決めて、そことの相対評価で見ていく。
- :memo: スクラムで時間にしないのは、量で表すことで人によって値が変わらなくするのが狙い
- :memo: ペアプロ前提っぽい

### 8.8.7　見積りが難しいとき
- > もしプログラマが要件を理解していて、必要な技術の専門家であれば、1分以下でストーリーを見積もることができるはずだ。:thinking_face:
- 皆さんは1つのストーリーの見積もりにどれくらいの時間をかけていますか？:+1::+1::+1:
- :memo: readyじゃないと時間がかかる
- readyとは：何をやるかわかってる状態。何やるかわかってないと見積もれない！
- https://www.ryuzee.com/contents/blog/7099
- :memo: タスクまでわかっているストーリーは割と早いですかね。 一方で見積もった時にポイント差が大きくて実装方針で議論が始まっちゃった場合は結構大変…
- 8.5 の イテレーション計画では 計画に 30分~4時間とあるが、見積もりはこの中の1分、残りはタスクの洗い出しになるのでしょうか。(結構見積もりに時間かけてしまう)
- > どの詳細が重要で、どれが気にしなくて構わないのかを把握する練習をしよう
- 練習するってどういうことだろう？
- ここまで把握できれば作業できるというラインを見極める経験を積むこと？
- バグや新しい技術などの調査系ストーリーにどのくらい見積もっていますか？:+1::+1::+1:
- タイムボックスを設けましょう！というのがP274に書いてありますね
- :memo: スパイクは小さく切りたい。3日は長め
- チーム外のタスクでの待ちが発生する場合、どのように見積もりますか？ストーリーを分割するのが理想だと思うのですが、どうしても分割できない場合など…:+1:

### 8.8.9 ベロシティの改善
- > プログラマを（注意深く）増員する
- 実際体験した人は、増員して生産性が安定するまでどのくらいの期間かかりましたか？:+1::+1::+1:
- プロジェクトの規模にもよると思いますが、ペアプロもまともにしてないと3か月はかかったので、XPを活用するとどのくらい違うのか聞いてみたいです

## ミニエチュードの質問
* ミニエチュードは、このプラクティスに対して気づきを得るための質問です
* 詳細はP76ページを参照してください
* 以下の質問に、回答を継ぎ足していってください

### (このプラクティスを使ったことがなければ)
- 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか？
- これまで経験したものとどう違うか？
- 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか？

### (このプラクティスを使っているなら)
- 自分がやっているプラクティスは、本書に書かれているもの突どんな点が違っているか？(気づいたことだけでいい、理由はいらない)
- 相対見積ではなく、理想エンジニア日(時間)を推奨している点:+1:
- ベロシティを生産性の判断に使ってはいけないという点
- 見積もりは1分で終わることが推奨されているが、実際は5~10分くらかかっているものが多い
- タスクにもよるが見積もり時にコードまで見て実装方針の認識を合わせることがある
- もし書かれているとおりに従うと、何が起こると思うか？
- このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか？(プラクティスが不適切だということを多足噛めるために、お試しでやってみるのは良いことだ)