アート・オブ・アジャイルデベロップメント読書会 第5章
===
###### 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)

# 自己紹介

- ファシリ役
- 松岡
- タイムキーパー役
- 坂本
- 読み上げ役
- こばやし（t2_Kobayashi）
- まだい(madai0517)

# 参加の仕方

- マイクはいつでも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です。

# 第5章 考えること

### 目安の時間
- 30分

### 感想・気づき
- 「考えること」ミニエチュード
- これ、このまま輪読会でやっても良いのでは！？:+1:
- 
- > プラクティスが不適切だということを確かめるために、おためしでやってみるのはよいことだ
- この精神、すごく良いのでは・・！やってみたら意外に発見があるだろうから、「効果がありそうだからやる」だけじゃなくて、「効果がないことを確認する」というtryはすごく面白そう :+1: :+1::+1::+1::+1:

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

---

## 5.1ペアプログラミング

### 目安の時間
- 30分

### 感想・気づき
- >ペア作業は、よいプログラミング習慣を強化することもできる。XPは継続的なテスティングと設計の改善をよりどころにしており、かなりの自己鍛錬が必要だ。ペア作業をすると、こうした難しいが重要なタスクをやるのに、仲間からの前向きなプレッシャーをもらえる。コーディングに関する知識やヒントをチーム全体に広めることができる。(p.77):+1:
- 実体験としてよくわかります。一人で実施するときよりも、質の高いテストコードやプロダクトコードを書こうという良いプレッシャーを感じます。リファクタリングするときもデザインパターンの知識も共有できるので、ペアプログラミングのメリットを享受しています。
- > 問題を新しい人に説明するだけでも、問題解決に役立つことが多い(P78)
- わかる。喋ったら自己解決しちゃうこと結構ある。それで「すみません」って言ったりするけど「むしろこれでいいのだ」と思う:+1::+1::+1:
- > ペアの気分が暗くなってきた時は技術的な困難にぶつかっている兆候であることが多い :+1:
- これもわかる。物理オフィスだったらこういうの見かけて声かけるのは有効そう。リモートだと工夫が必要だけど。。
- > 議論をすると、あなただけでなくパートナーも学ぶことができる(P78)
- こういうのを事前にチームで共有しておくと非常にスムーズにいきそう
- > 疑問点が出てきたときには、ナビゲーターが調べる。スパイクソリューションは強力(P79)(スパイクは技術的な調査で、対象となるプログラムを作ったりすると良い(P355)
- 「ナビゲーターが指示してドライバーが書く」だけと思われがちだけど、もっと柔軟なものなのかもしれない:+1::+1::+1::+1:
- ペアプロするときにはニンニクの匂いに気をつけよう、という圧倒的な知見。笑(P80)

### 疑問・参加者に聞いてみたいこと
- ペアプロの前提条件（設計工程の有無、ドキュメントの有無、ドキュメントの記載レベル等）について本章では言及されていないが、この点に言及している文献をご存知の方はいらっしゃるか？また、皆さんはペアプロを始める前にどんな準備をしているか？:+1::+1:
- 77頁に「ペアプログラミングをしていると、コードに完全に集中して、生産性が高いフローの中で時間を過ごすことができる」とあるが、会話しながらコーディングすると集中状態に入りにくいという声も耳にする。皆さんはどう感じているか？また、ドライバがコードに完全に集中できるように工夫していることはあるか？（ドライバの立場からみた工夫とナビゲータの立場からみた工夫がありそう）:+1:
- わかりやすいところでいうと、slack見ない！ってのはわかりやすくあります
- 複数人でやると、話しかけられて一人が集中途切れても、もう一人は作業が続くのでペアで見ると集中状況がとぎれないというのも体感あります
- 「集中」のイメージが違ったりして。ひたすら黙々としている状態を「集中」と呼ぶ人もいそう:+1:
- ペアの変更ってどれくらいの頻度で実施していますか？
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/785117272083136522)
- 1日かかるタスクの場合にペアを途中で変えたことがなかったので、皆さんどうしているかディスカッションしてみたいです。(むしろタスクの粒度を4時間程度に小さくして個別にペアを組むとかでもありかもしれないと感じました。) :+1::+1::+1::+1::+1::+1:
- :memo: タスク途中でのペア交換はコンテキスト共有コストが大きくツラかった記憶が
- :memo: 変更していないですね。頻繁に変えられる程知識の共有ができていないですね。
- :memo: 特定の人しか知らないコードや設計意図がないように、知識の平準化を進めておかないと、いつでも誰とでも交代するのはむずかしい感じはする。
- :memo: チームメンバーのスキル差もあるので。。知識の共有だけではないかも
- :memo: 「知識が平準化されていない == 悪い」ってことでもないとは思ったりしています。
- P79「ナビゲートしているときには、目の前にインデックスカードを置いておく
- 何を書くのだろう？課題とは？
- スキル差のあるペアでプロダクトコードの実装をする際に工夫していることはありますか？
- 本書だと誰も知らない話題を調べることで対等なバランスを取り戻すことを提案してます。とはいえ、プロダクトコードの実装もしたいので、みなさんで実施している工夫などディスカッションしてみたいです。 :+1::+1::+1::+1:
- >p.82 私が知っているプログラマのうち、1か月間ペアプログラミングしてみて気に入らな かった人が1人だけいた。自分の意志に反してペアプログラミングを強制されていたためだ。
- 導入しようとして同じ状況になり、結局やめてしまった経験があります。皆さんはこのような状況になったときどうしますか？:+1:
- 1か月続ける前に瓦解してしまったので、"2人で1人分の仕事をするのはムダじゃないですか？"という質問に対し、一般論の答えしか出せなかったという反省はあります
- 実際やってみて1ヶ月で効果がえられた感じはなかったですか？
- 新メンバーへの教育的な効果は得られましたが、品質向上につながったかは測れなかったので、チームとしては微妙という評価でした
- ペアプロやってみて定着した人と、しなかった人の違いを知りたい。した人、しなかった人それぞれなぜそうなったか聞いてみたいです:+1::+1::+1::+1::+1::+1:
- ペアプロの時のドライバー・ナビゲーターってどれほど順守してますか？そのメリットデメリットを言語化するとどうなりますか？
- ペア向きの作業、そうでない作業の基準はありますか？:+1:
- ペアプログラミングやったことないのですが、ぶっちゃけ参加者の皆さんは「当然やっているでしょう」という感じなんでしょうか？（参加者のみなさんのうち、どれくらいの割合の方が実施されているのでしょうか？）
- なんか柔軟っぽいけど、ドライバーとナビゲーターって結局何するの！？ :+1::+1:

### ミニエチュードの質問

- [discord](https://discord.com/channels/767540649418686486/774111081634332673/785114255300624395)

#### (もし使ったことがなければ)
- 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか？
- ペアの数だけ、タスクを推進できる人がいなかった。(二人とも初めてペアだと、タスクなかなか始らない)
- チーム員や上司、リーダーを巻き込んで始めることが難しい。:+1::+1::+1:
- 業務委託等の短期的に働くメンバーがいる中で、その方が得意でない分野においても、わざわざペアを組ませて時間を投資するのが難しそう。
- 業務委託等の形で参加することが多いので、組織文化に合わせざるを得ず、実践にまで届かない
- これまで経験したものとどう違うか？
- 一人で出来る範囲の限界を突破できる。
- スキトラ-->個人ワークより、短いサイクルで学べる
- 気が休まらないw:+1:
- 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか？
- 関係者の熱意や理解が必要。
- スムーズにやれるようになるには慣れが必要
- 慣れた個人への依存が残らないようにする。 (ペアの相手から学ぶ)

#### (もし使っているなら)
- 自分がやっているプラクティスは、本書に書かれているものとどんな点が違っているか？(気づいたことだけでいい、理由はいらない)
- 1日、むしろ同じタスクであれば同じペアが多いので、1日の中でパートナー交換はしたことがない :+1::+1::+1::+1: [discord](https://discord.com/channels/767540649418686486/774111081634332673/785116809174319115)
- 定期的に実行する状態には持って行けなかった。
- 全てペアプロで書いていない。:+1:
- 新人並みの人と組んだ時、教師と生徒になってしまった。:+1::+1:
- ペアプロ途中、ほとんど役割を交代していない
- リモートなので交代が手間というのも一部有る
- 相談や協働作業というより、設計や実装の意図を共有しつつ、他の人が詳細実装に着手するための枠組みを作る目的で、ペアプロの形式だけ借用しているケースも:+1:
- もし書かれているとおりに従うと、何が起こると思うか？
- 知識の共有が加速する:+1::+1:
- コード品質 (テスト、プロダクト) が向上する:+1:
- 新しくジョインしたメンバーが慣れるのに早くなる:+1:
- チームの流儀や文化など、プロダクトそのものや技術だけでない知識の交換が促される。新規メンバ導入時等にも役立つ。:+1:
- 知識のレベルがお互いに引き上げられる。教えるだけの場合もそれはそれで知識が増える。
- 「一人で黙々やりたい」というメンバーから反発がありそう:+1::+1:
- このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか？(プラクティスが不適切だということを確かめるために、お試しでやってみるのは良いことだ)
- ペアをもっと柔軟に変更する
- ペア交代の頻度を高める:+1:
- ほかのチームの人ともやってみる。
- ソロでのプログラミングを禁止する(ペアプロ養成ギプス):+1:
- オフラインでやる(オンラインでやる):+1:
- あえて役割を固定してみる(ナビゲーター or ドライバーの振る舞いに慣れさせる)
---

-------------------- 5.2 は次回以降の予定です！ いいねづけもまた今度で大丈夫です。 ---------------------

## 5.2 活き活きとした仕事

### 目安の時間
- 30分

### 感想・気づき
- 定時で帰るとか生き生きした状態で働くとか、こういうのをアジャイル文脈でみないけど、正式にプラクティスに入ってるのはすごく興味深い
- 食事、運動、睡眠までがアジャイルプラクティスだとは！
- 単純に、ここに書かれているようなチームだったらそりゃいいよな、と思う
- スクラムやってると、タスクが整理された状態が保たれやすくて、残業でなんとか。。。ととか考えなくて良くなってきた感覚ある。
- > 活き活きした仕事は、仕事をサボる言い訳ではない。きっちり1日分の仕事に全力を傾けることによって、信頼を作り出そう
- これが超大事！！成果出してるからいいよね？っていえるぐらいが最高に理想
-
- >プロジェクトマネージャはまた、不要なミーティングや電話会議の時間をずらすことによって、チームメンバーが充実した仕事をするのを助けることができる。情報満載の仕事場と適切な報告があれば、進捗会議の必要性をなくすことができる。
- そういえば、スクラムとXPのプラスティスでプロジェクト遂行しはじめてから、進捗報告会的なものしたことがないですね。WBSで管理していたことは進捗率を担当者に確認したりしてましたが、スクラムとXPの場合、バーンダウンでプロジェクトの状況もわかりますので無駄が省けているなと感じました。
- 最も簡単な活き活きとする方法の1つは、自分を大事にすることだ。毎日定時に帰宅しよう。
- ですよね。ただ、ペアプログラミングが乗ってくるとついつい時間が長くなってしまうことも...(反省)
- >p.89 われわれの経験では、デスマーチ・プロジェクトに共通する性質として、予想される価値が低いことがある。どうしようもなくつまらないプロダクトを世に送り出すためのプロジェクトなのだ。デスマーチになる本当の理由は、あまりにも価値がないので、普通のコストでプロジェクトを進めたらコストが効果を上回ることがあきらかだからだ。
- 苦労して実装した機能が、ほぼ使われずに終わる経験が...
- 顧客とのパワーバランスがおかしいとこうなるリスクがありますね
- せめて使われなかったら機能を削除するぐらいの交渉力が欲しい
- 理屈はわかるけど、具体的なプラクティスが難しい

### 疑問・参加者に聞いてみたいこと
- 活き活きとした仕事にするためにみなさんが工夫していることはありますか?
- 例: 雑談タイムや雑談チャネルを設けているなど

### ミニエチュードの質問
#### (もし使ったことがなければ)
- 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか？
- これまで経験したものとどう違うか？
- 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか？

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

---------------------- 以下、話したいやつ---------------------------------

### 次回トピック（5-9章)

- 5.3 情報満載の仕事場
- 5.4 根本原因分析 :+1:
- 6.2 全員同席 :+1::+1:
- リモートの現場増えてると思うけど、同席できないことで問題感じることあるか。どう解決してるか。
- 6.3 真の顧客の参加:+1:
- 6.4 ユビキタス言語 :+1:
- DDDの引用かと思ったら実際DDDへの言及があった記憶
- この本ではどのように説明し、どのように利用しようとしているのか、見てみたい
- DDDの説明・記述とこの本の説明・記述とで、比較してみたい
- 6.8 報告:+1::+1:
- チームの定例会などで、うまく報告できていないことが多いように感じる。後で大爆発を起こすことが多くて、皆でうまく報告しあえるようになりたい。
- 7.2 バグなし :+1:
- バグがないことの価値を改めて議論してみたい
- 7.3 バージョン管理:+1::+1:
- 普段「当たり前」みたいにされてあまり議論されないけど、意外と深い話ができる気がするので
- 7.4 10分ビルド :+1::+1::+1::+1:
- 現代において、みなさんがどのようにビルドやデプロイを自動化しているかがとても気になる！
- 7.5 継続的インテグレーション :+1::+1:
- 7.6 コードの共同所有:+1::+1:
- 実際のところ、どうやって共同所有に持っていくの？という疑問
- 7.7 ドキュメント:+1:
- 8.4 リスク管理:+1::+1:
- 8.5 イテレーション計画:+1::+1:
- 8.8 見積もり :+1::+1::+1::+1::+1::+1::+1::+1:
- ScrumFestSapporo2020の講演で、見積もりは未来予測の話で難しいという問題提起があったので、改めて考えてみたい
- 9.5 シンプルな設計 :+1::+1::+1::+1::+1::+1:
- YAGNIと変更容易性のバランスをどうしていますか？
- 9.6 インクリメンタルな設計とアーキテクチャ :+1::+1::+1::+1::+1::+1::+1:
- 設計やアーキテクチャを「インクリメンタルに進める」というテーマに関心
- 「インクリメンタルな設計/アーキテクチャ」が成立するための条件として、何を挙げているか見たい
- この本ではどのような説明や理論を出しているのか？