アート・オブ・アジャイルデベロップメント読書会 第2版 #2 Zero Friction
===
###### tags: `アートオブアジャイルデベロップメント読書会`

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

# Discord開始位置

* [connpass募集ページ](https://agiledevs.connpass.com/event/193498/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)
* [discord:2021/xx/xx]()

# 自己紹介

- ファシリ役
-
- 読み上げ役
-

# 参加の仕方

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

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

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

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

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:30- | - | もくもくタイム（hackmd書き込み） | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 参加者アンケート | |
| 20:25-20:35 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:35-21:45 | 70分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:45-21:50 | 5分 | [miro](https://miro.com/welcomeonboard/OW54WlJIZ3pKQlBwbUtTc0p3d1Y3UlJOWWgycGx4S2ZLZGpyUGtVeXRCOG1HUUs3QnJVREwzY29LOTJnSU1UeXwzMDc0NDU3MzQ3MDA4ODU5ODI5)を使ってふりかえり | |
| 21:50-21:55 | 5分 | 次回開催日と読む範囲決めてクローズ | |

* 流れ
* 10分ごとにトピックを区切って議論します
* 10分経った段階できりがよければ次の話題に、そうでなければ延長します
* 議論するトピックは最初に「いいね」がついた数の多い順です。
* 「疑問・参加者に聞いてみたいこと」→「感想・気づき」の順番で進めます
* その前に、議論するトピックを決めるための投票を行います
* ひとり1トピックには1票、全体では何票でもOKです

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

### 目安の時間

- 1トピックにつき10分を予定しています
- 盛り上がったら延長することもあります

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

### Five-Minute Integration

- > Your script should report success or failure within five minutes—ten at most.
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/953252790015250462)
- 皆さんはCI/CDに何分くらいかかっていますか？ :+1: :+1::+1::heavy_check_mark:
- ビルド、ユニットテスト、SAST、静的解析を行うため、それぞれをうまく併走させてもなかなか5分を切れず...(6～7分くらい):+1:
- 同じぐらいですね・・・！

- 本章以外にも、開発スピードを加速させる(または低下させるものを除外する)ために皆さんで工夫されていることはありますか？:+1::+1::+1::heavy_check_mark:
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/953255618423193620)

- みなさんは、バッチでビルドしていますか？:+1:

- みなさんがCI/CDに任せていること、任せたいけど任せられていないことを聞いてみたい:+1::+1:

- > 自動化する時間をどのように見つけますか？
- 皆さんはこういう時間をどのように作っていますか?:+1::+1::heavy_check_mark:
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/953258997832630322)

## 感想・気づき

> Fast feedback. A fast, automated build will make a big difference to your quality of life, and it will open up opportunities for other improvements as well. See “Zero Friction” for more.
- How to be agileのところ
- 立て付けとしては、早いフィードバックを得るために、Zero Frictionを利用する。
- 10分ビルドの話がこれになったんだろうか？
- 読んでいるとそれっぽい。10分ですら遅いよね、みたいな意味合いでZero Frictionになったのかな

- 開発者の人の言語環境は何なんだろうなぁと思ったりしました
- なんとなく用語や雰囲気的に node.js 感ある

- Zero friction状態だと1時間デプロイが可能になるのか！って分かってテンション上がりました（最初の小話）

### One-Second Feedback

> Development speed is the most important area for eliminating friction. When you make a change, you need to get feedback about that change in less than five seconds. Less than one second is best. Ten seconds at the very most.
> 開発スピードは、摩擦をなくすために最も重要な分野です。変更を加えたとき、その変更に関するフィードバックを5秒以内に得る必要があります。1秒以内がベストです。長くても10秒です。
- リモートになって、よりここの「すぐのフィードバック」というのは意識しないと会話しにくくなった気もする？ 1秒フィードバックを実践するのには、むしろ向いているのかもしれない。
- SpringBootなんかは起動に10秒じゃ済まないんだよな。。
- IDE が高速にフィードバック返してくれるので1秒以内と半分は言えそう。章のテーマ的にもビルドだけではなくなっていますね。

> このタイプの高速フィードバックは、ゲームチェンジャーです。あなたはとても簡単に実験して繰り返すことができます。大きな変更を加えるのではなく、非常に小さなステップで作業できます。それぞれの変更は1行か2行のコードである可能性があります。つまり、間違いがどこにあるかを常に把握できます。デバッグは過去のものになります
- ”デバックは過去のものになります”はカッコイイ。たしかに、テスト駆動はその感じある。ただ、5秒の速度でフィードバックにもらいたいけど、そこまで早くない。:+1::+1::heavy_check_mark:
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/953266098910949377)
- 常にテストを流すっていうのは、pytestとかでそんなオプションがあったような気が。
- なんかこれフロントっぽいですね
- goとかって早いんですかね？

### Know Your Editor

- > Take the time to get to know your editor really, really well.
- わかりみ。IDEの機能を使い倒すと生産性向上と本来の業務(モデルをコードに反映するなど)に集中できることが多いです。IDEの機能やショートカットをゴリゴリに使っている人とモブプロすると学ぶことが多くて助かります。:+1::+1::+1::+1::heavy_check_mark:
- IntelliJのリファクタ機能とかマジで強いので本当に生産性に影響がありますよね
- IDE Tips教えるおじさんは一人欲しい:+1:

- > エディタの熟練度がどれほどの違いを生むことができるかの例については、彼女のGilded Roseビデオ、特にパート2でのEmilyBacheの名手パフォーマンスを参照してください。
- これ見たいな、どこにあるんだろ
- 書籍の脚注にありました:+1:
- パート1 https://youtu.be/zyM2Ep28ED8
- 2 https://youtu.be/OJmg9aMxPDI:+1:
- 3 https://youtu.be/NADVhSjeyJA
- ありがとうございます！！これは見てみたい

### Reproducible Builds

### Five-Minute Integration

- > Your script should report success or failure within five minutes—ten at most.
- 第1版だと10分ビルドでしたね。10年で世の中の流れが加速したとのことかもしれませんね(実際、10分は長い...)。より高速なフィードバックが競争力の源泉の1つになりうる的な。 :+1::+1::+1:

- 単純にビルドが。。ビルド時間が伸びていきます先生・・・！(Kotlinです):+1::+1:

### Control Complexity

> In most cases, it’s best to wrap the third-party tool or library in code you control. The job of your code is to hide the underlying complexity and present a simple interface customized for your needs.
> ほとんどの場合、サードパーティのツールまたはライブラリを自分で制御するコードでラップするのが最善です。コードの仕事は、根本的な複雑さを隠し、ニーズに合わせてカスタマイズされたシンプルなインターフェイスを提示することです。 :+1: :+1:
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/953268819110015006)
- ここのコラム(KEY IDEA)は正直しびれました。便利なものなら入れればいいじゃんって感覚だったので
- zero frictionの章になぜあるのかは気になる:+1:

### Automate Everything

> build：コンパイルおよび/またはlint、テストの実行、および成功または失敗の報告
watchbuild：ファイルが変更されると自動的に実行されます
integrate：build本番環境のような環境で実行し、コードを統合します
deploy：実行integrateしてから、統合ブランチをデプロイします
rundev：手動によるレビューとテストのためにソフトウェアをローカルで実行する

どんな自動スクリプトがあったら良いのか例が列挙されていて助かる

### Automate Incrementally

### Automating Legacy Code

- 全般的に、あらかじめスプリント計画に組み込んだ「ゆとり」(Slack)を活用して、徐々に改善していくことが提案されていますね。「ゆとり」の改善をちょっとずつ積み重ねることで、あるべき姿に近づくイメージ。:+1:
- 既にあるプロジェクトは同じイメージ
- 新規プロジェクトだとある程度先に整備をしたい

### Questions

> How do we find time to automate?

- これを見つけられなくなった時は、いよいよあり方を見直す時なのかもしれない。とはいえ、「自動化の時間がないから今回は手でやる」はよくある話。 :+1:

- > The same way you find time for coding and testing: it’s simply part of the work to be done. During the planning game, when you think about the size of each story, include any automation changes the story needs.
- ほんそれ。スプリント計画に含めておけば自動化の作業が捻出できます。逆に計画に含めていないと、ほかの作業で埋まってしまってどんどん負債がたまっていってしまいますよね。(コンテキストにもよりますが、自動化をするための「承認」をしようとすると余分な労力使ってしまいますので、クラスの設計やIF文の設計と同じくらいの温度感で自動化できるといいですよね。)

### Prerequisites

### Indicators

### Alternatives and Experiments