アート・オブ・アジャイルデベロップメント読書会 8.6 ゆとり
===
###### tags: `アートオブアジャイルデベロップメント読書会`

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

# Discord開始位置

* [connpass募集ページ](https://agiledevs.connpass.com/event/203497/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)
* [discord:2021/02/14](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です。

# 感想など

## 目安の時間

## 感想・気づき
### 8.ゆとり
- コードを張り詰めているとすぐ抜けてしまうという比喩は何かで使えそう　
- オリジナルだとゆとりは「slack」で、意味的には「たるみ」とかが直訳っぽいです:+1:
- https://ejje.weblio.jp/content/slack
- トム・デマルコの本で「ゆとりの法則」があるんですが、まさに表紙にSlackと書いてありますね
- https://www.amazon.co.jp/dp/4822281116/

### 8.6.1 どれくらいゆとりが必要か？
> そのベロシティで可能なストーリー数以上にストーリーにサインアップするのをやめよう。こうするとベロシティは最も低い値に落ち着いて、チームにとって十分なゆとりを盛り込めるようになる。
- 自分のチームでは累計ベロシティの平均を目指すことでゆとりを出そうとしたけれど、あまりゆとりがでた実感がなかった。一度最も低いベロシティに安定させると良かったのかなと感じた。
- 自分のチームだと、POからのExpressタスクが減らなかったので、その平均値をゆとりにする対応してみたりした。
- うちのチームだと、ゆとりという話を全くしてないので、これを今回認識できたのは大きかた。

### 8.6.2 ゆとりの導入方法

> 技術的負債を修正するときには、現在の仕事がもっとやりやすくなるように修正することを重視しよう。現在取り組んでいるストーリーとは無関係な技術的負債を探しに行ってはいけない。
- 気になってしまい、無関係な技術的負債をやってしまうことはあるなと思った。:+1::+1:
- 開発者でゆとりの時間に何を費やすか会話しています。例えば、手動で行っているE2Eテストを拡充していくなど。
- > 私が技術的負債に気づくのはたいてい、ペアプログラミングでナビゲートしているときだ
- 処理の流れを追ってるときなど全体を俯瞰しながら把握しようとするときに見つけることが多い気がする
- 逆に課題をこなす思考になってると視野が狭くなって気づけなくなってるかもしれない
- 「技術的な負債をタスクに積んでおけば、緊急時に差し替えられる」というのを聞いて、「毎イテレーションに改善タスクを積もう」と言う言葉の「裏の意味」と言える重要性を感じた。
- 私のチームでは「ゆとり」に該当するユーザーストーリーを毎スプリント最初から組み込んでいます。例えば計画外の問い合わせなどがあれば、このユーザーストーリーからタスクの作業時間を切り出して対応していくイメージです。
- また、2週間スプリントを実施していて、スプリントレビュー、スプリントレトロスペクティブ、スプリントプランニングが同日に行われています。このため、これらスクラムイベントを行う日をゆとり時間にあてて、勉強やリファクタリング、E2Eテスト拡充に充てていることが多いです。:+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/810487897010077706)

> イテレーションの最後の1日か2日は何も仕事を入れないことだろう
- 逆に1日の中で1〜2時間確保してやりましょう、としたときに上手くいかなかったですね（結局食いつぶしてしまった）:+1::+1::+1::+1::+1::+1::+1:

### 8.6.3 勉強時間

- ここの節を読んでいて、Learning Sessionを取り入れたことを思い出した。1日1時間をチーム全員でモブ勉强に充てるようにして、仕事が立て込んでいる時は飛ばしていたりしたけど、あれも1つのゆとりだったと思う。:+1::+1::+1::+1::+1:
- [仕事をよりクリエイティブにするための「Learning Session」ノススメ \- LINE ENGINEERING](https://engineering.linecorp.com/ja/blog/recommend-learning-session/)
- Googleの20%ルールという名前で広がったので、マネージャー層を説得はしやすいかもしれないが期待が大きすぎて諸刃の剣にもなりうる
- 私のチームでも導入したが業務が炎上してなくなってしまったことも...:+1::+1::+1::+1:
- 「20%」というのをどう測るかが難しいですよね
- 20%は勉强に当てていいとマネージャーに言われたことがあったけど、結局作業に忙殺されてできなかった記憶
- 業務中に大々的に勉強時間をもらった事がないです。各自業務外で勉強する的な、勉強時間をもらったことあるかたがいるならどのように与えられて、どんな感じで勉強を進めているのか知りたいです。:+1::+1::+1::+1::+1::+1:
- 研修とかも全くないのでしょうか？
- 週次のチーム会で、「後半勉強会にしましょう！」と言って始めた時ありました。
- 勉強時間として用意された時間が、いつの間にかISSUE一覧から選択して作業する流れになってしまったことがあった。:+1:

### 8.6.4 イテレーションのコミットメントにリスクがあるとき
- なんだかんだ残業の同調圧力は避けられない:+1:

### 8.6.5 一線を越えてはいけない

- > 2~3イテレーション続けて技術的負債を支払っていないのなら、過度にコミットメントをしていてゆとりがないということだ。
- 思った以上に、技術的負債を支払う感覚は短いと感じた。でもそれだけイテレーションの、日常の中に技術的負債を支払わなければいけないのだと感じた。

### 8.6.7 質問
- > 勉強時間はお金をもらってやるような仕事ではないように聞こえます。...
- こう思う顧客は多いので、内部品質向上のための時間を貰う形にして、その中で調査という名目で勉強したことはある:+1::+1::+1:
- 受託ワークだと厳しい・・・！
- それでも直接関係あることしかできないので、この章の目的通りに実践するのは難しいと感じる面も...
- エンジニアは休みの日に勉強するべきか否か論争…:+1::+1::+1::+1:
- 業務中に勉強会しようとすると「暇ない」と言われ、業務外にというと「休みに仕事の勉強強要するな」と言われ... :+1::+1:

### 8.6.9 使用上の注意
- ゆとりはすぐ他の何かに侵食されてなくなってしまうので、こうやって『ゆとりをプロダクトに使うなよ？』という注意点が言語化されているのはとてもうれしい。:+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/810479118050918480)

----

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

- 開発をしながら運用保守が日直制度で回ってくるのは、ゆとりとして定義しておくべきか。あらかじめわかっているのだから、別で計画を立てるべき？:+1:
- 8.5.11のバットマンをチーム内で立てるから、計画には組み込まないように見えた。
- スプリントプランニングの際に、キャパシティの概念を適用するのもよいかもしれません。次のスプリントでどれくらいのストーリーポイントが実現できそうか見通しを立てる際に、(直近4～6のスプリントのストーリーポイント数の合計値)/(直近の4～6スプリントのキャパシティ=稼働時間)*次のスプリントのキャパシティ でストーリーポイント数を計算します。キャパシティは特定の開発者のスプリント内の稼働時間見込みです。キャパシティを算出する際には、保守運用や休暇取得をする場合を考慮してます。キャパシティを使うことで、無理のないゆとりのあるスプリント計画づくりができる感触を得ています。
- 開発している実感としては技術的負債などで生産性が落ちていると感じているが、自分の会社だとゆとりの必要性を管理側(マネージャーなど)に実感してもらうのが厳しい肌感覚がある。このプラクティスを実践されている方はどのようにして管理側の方の理解を得ているのか聞いてみたい。:+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/810471422882349087)
- そのようなケースではコミットメントしているタスクをやっているフリして取り組んじゃいます。:+1::+1:
- 変な話、イテレーション内でタスクを守ろうという意識が無いと、「ゆとり」というものが効果が出ないような気がするけど、どうなんでしょう。（そもそも守るような意識に向けないといけないのだろうけど）
- 声高にゆとりをあえて入れているのです！って宣言すると上から潰しに来られたりしませんか？:+1::+1::+1::+1:
- 「ゆとり」という響きが「なくてもいいもの」感あるので、違う言葉が欲しい気もしました・・・！:+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/810473955697491978)
- 『余白』
- 『Express』

### 8.6.4 イテレーションのコミットメントにリスクがあるとき
- 技術的負債を返済するために残業することってありますか？:+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/810476834222243851)
- コミットメントを守るための残業はあっても、負債返済のために残業する印象がなかったので聞いてみたい
- 昨今のご時世的にも違うやり方をした方が良いように思える:+1:
- 基本負債の返済はタスク着手して気づいた点を行うので最後にやってくることはないかな
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/810476834222243851)

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

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

### (このプラクティスを使っているなら)
- 自分がやっているプラクティスは、本書に書かれているもの突どんな点が違っているか？(気づいたことだけでいい、理由はいらない)
- もし書かれているとおりに従うと、何が起こると思うか？
- このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか？(プラクティスが不適切だということを多足噛めるために、お試しでやってみるのは良いことだ)

---

## 次のテーマにしたいもの
- 8.1 ビジョン:+1::+1::+1:
- 8.2 リリース計画 :+1::+1::+1::+1::+1::+1::+1: ★次回のテーマ！
- 8.3 計画ゲーム:+1::+1::+1::+1::+1::+1:
- 8.4 リスク管理:+1::+1::+1::+1:
- 8.5 イテレーション計画:+1::+1:
- 8.6 ゆとり[done]
- 8.7 ストーリー :+1::+1::+1:
- 8.8 見積もり[done]