アート・オブ・アジャイルデベロップメント読書会 6.2 全員同席
===
###### tags: `アートオブアジャイルデベロップメント読書会`

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

# Discord開始位置

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

# 自己紹介

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

# 参加の仕方

- マイクはいつでも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/DgN2fhzWfBt3jHeC1h5Clteo4TvoXmS6Hx06eM46RiQEpjkVv52ZlMeu8u2nLRJ0)を使って振り返り | |
| 21:50-21:55 | 5分 | 次回開催日と読む範囲決めてクローズ | |

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

# 感想など

## 目安の時間

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

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

- 決裁者、上司、PM、ステークホルダーほど不在がちで全員同席の対象から外しがちなのですが、効果的な解決方法あるんですかね？
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/856138944872972298)

### 6.2.5 部屋づくり

- フルリモート or 一部のエンジニアがリモートの場合でアジャイル開発をやっているチームは、どのように仕事部屋を設計しているのかが気になる（部屋というよりは、どういうツールを使っているか？かな）:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/856135742261559316)

### 6.2.4 全員同席の秘訣

- > 「質問されたときにはいつでも助けなければならない」
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/856142332138356736)
- このようなルールを実際に持っている人います？もしいたら、そのルールがあってどうでした？
- 開発組織で5分もわからなかったら他のペアに聞きにいけ、というのはよく言われます。聞く、聞かれることが当たり前となっているので、気軽に聞きにいくことが結構出来ています
- 質問に答えてると、質問に答えてほぼ1日終わることもありますね。（リモート会議繋いで、終わってタスクの準備しようとしたところで次の質問が来て...)

## 感想・気づき

- [著者ページ](https://www.jamesshore.com/v2/books/aoad1/sit_together) では、 "99 words" のまとめが書かれていたので共有します。 :+1:
- > Sitting together fuels team communication. This has impressive results, cutting time-to-market by two thirds in one field study*. It enables simultaneous phases, eliminates waste, and allows team members to contribute insights to others' conversations.
> To sit together, create an open workspace. This takes longer than you expect. Organize your workspace around pairing stations, locating people according to conversations they should overhear. Provide plenty of whiteboard space. Make sure there's room for personal effects and a place for private conversations.
> Open workspaces are hard for some to accept. Get team members' permission before switching, or they may rebel.
- > 一緒に座っていると、チームのコミュニケーションが活発になります。あるフィールドスタディ*では、市場投入までの時間が3分の2に短縮されたという素晴らしい結果が出ています。同時進行が可能になり、無駄がなくなり、チームメンバーは他の人の会話にインサイトを提供することができます。
> 一緒に座るためには、オープンなワークスペースを作ることです。これは思ったよりも時間がかかります。ペアリングステーションを中心にワークスペースを構成し、耳に入れるべき会話に合わせて人を配置します。ホワイトボードのスペースも十分に確保する。私物を置くスペースや、プライベートな会話をする場所も確保しておきましょう。
> オープンなワークスペースは受け入れがたい人もいるでしょう。チームメンバーの許可を得てから切り替えないと、反発される可能性があります。
- v2 ではタイトルが「Team Room」になっていた。内容を見ると、こっちの方がしっくりくるかも。一緒に座るだけじゃなく、部屋のレイアウトの話もあったので。
- 全員同席だと、一緒にお昼を取る頻度が増えて、コミュニケーションも関係性も良くなる感覚がある:+1:

### 6.2.1 コミュニケーション不足に対処する

- > XPでは、ビジネス、設計、プログラミング、およびテストの専門家を含むチーム全体が、オープンなワークスペースに一緒に座っています。質問があるときは、頭を向けて尋ねるだけです。すぐに応答があり、不明な点がある場合は、ホワイトボードで話し合うことができます。
- リモートになり、モブやペアを進めることである程度再現はできているものの、この問いかけのしやすさの便利さはなかなか到達できない。(チャットでメンションして、応答を待つとかはメールよりずっと早いが) :+1:
- オンサイトでもホワイトボードが活躍したように、オンラインでも miro のような共同編集ツールで会話できるかそうでないかで、会話しやすさは大きく異なる感覚がある。

- > P.118 直接的なコミュニケーションへの依存を減らすためにチームが主に使う手段は、開発をフェーズに分けることとそのフェーズごとの中間成果物としてのドキュメントだ
- 今までフェーズって何で区切るんだろうなってもやもやしていたのが、ここを読んで晴れた。直接的なコミュニケーション依存を減らしたいが為に、フェーズを分けてドキュメントを作るという考え方なんだな :+1::+1::+1:

### 6.2.3 より良いコミュニケーションを有効に使う

- > 全員同席すると生産性は2倍になり、製品化までの時間は社内基準のほぼ1/3にまで削減できたことがわかった[Teasley et al.]
- 凄まじい効果ですね。コミュニケーションのボトルネックが凄かったということでしょうかね。

- > プログラミングはソフトウェア開発における象徴的なアクティビティだが、ソフトウェアを成功させる本当の鍵はコミュニケーションだ。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/856144677572837451)
- わかりみ。でも、コミュニケーションについてプログラミングよりもかなり軽視されているように感じる。:+1::+1::+1::+1: :+1::+1::+1::+1:
- コミュニケーションをSlackでやり取りしているから取れている、と思っている人も結構いると思う（まぁ非同期的には取れているわけなんだけども）
- コミュニケーションて頻度や量ではなく、意思疎通できたかどうかだと思うんですよね :+1::+1:
- リモートになると雑談が減ってしまい、以前と比べカクテルパーティ効果が減っていると実感している。新人が入ってきたときもプロダクトのことを知る手がかりが減ってしまいどうしようかと頭を悩ませた経験も...
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/856147361440858172)
- ペアプロで常にコミュニケーションを取れるようにしつつ、1時間に1度休憩を挟み、再開するときに少し雑談を含めるとかの工夫で少しは改善されてきた:+1: :+1::+1::+1:
- 雑談苦手なので、会話のネタに困りがち:+1:
- 毎日15時になったら雑談タイム(おやつタイム)を入れる話を聞いて、取り入れてみてます。日の浅いメンバーも、馴染みやすくなった感あります。:+1::+1:
- 実際に会って雑談することはすごく必要だと思いますね。趣味とかの付き合い方は人によって異なりますが、その付き合い方でプライベートの重視度合いとか、取り組み方とか見えて来ると、その人への仕事の振り方、どこまで伝えれば上手くいきそうかとか分かると仕事しやすかったです。:+1::+1:

> 一緒に座ることには、もう1つの隠れた利点があります。それは、チームが怒鳴り、グループ間の態度を打ち砕くのに役立ちます。距離は敵対関係を助長し、「それらの人々」を非難するようです。 :+1:
- リモート主流になる前、拠点が違う人同士が険悪になることは度々あった。ビデオ会議は大抵お互いに対する不満を溜め、終わった後に電話で補っていた記憶がある。

### 6.2.4 全員同席の秘訣
> プロダクトマネージャーが外出しているあいだは、ドメイン専門家がうまくバックアップすることが多い。
- この解決方法、プロダクトマネージャー以外に決定権が無かったり、そもそもドメイン専門家なんて都合よく存在しないことも多いので現実的じゃないと思うなぁ

> P.120 答えが分かる人が部屋のすぐ向こうにいるのに、頭を抱えて行き詰まっているのは意味がない。こういった助けを求める姿勢を後押しするために、チームの多くは次のようなルールを持っている。「質問されたときにはいつでも助けなければならない」
- そういえば、むかし別のチームが質問されたら「はい、喜んで！」とかって返事するチームがあったなぁ。:+1:
- いまのチームだと、5分考えてわからなければ別の人に質問しなさいって言っているのは、こういうことを考えているんだろうなぁって思った:+1:

> 中断は流れを混乱させ、生産性を損なうので、このルールはばかげているように聞こえるかもしれません。プログラマーが中断後にフローに戻るには15分以上かかります[ DEMARCO＆LISTER1999 ]。
> 幸いなことに、ペアプログラミングでは、フローの動作は異なります。遅延は発生していないようです。1人のプログラマーが質問に答え、もう1人は目前の問題について考え続けます。中断が終わると、すぐに「どこにいたの？」仕事を再び動かします。
- ペアプロで、一人は何をしていたのか覚えていられるという強みはいい材料。割り込みに二人で対応してしまわないように気をつけたい。:+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/856150534398410752)

### 6.2.5 部屋づくり

- > 一緒に座ることは、言いやすく、やりにくいことの1つです。行為自体が難しいということではありません。本当の問題はスペースを見つけることです。
- プロジェクトルームの奪い合いのような問題はよく見かける。これの話だと、集まれる対面テーブルの集合が自由に使えるのであれば、部屋に拘らなくても良い？

- 欧米の文化的背景も影響していそう。スクラムやXPを取り入れるまでは、個室のブースで独立して作業していることが前提でしたが、コミュニケーションの無駄を省くために大部屋で一緒に作業しよう、という風に理解しています。対比的に、日本は明治（か昭和か忘れてしまいましたが）ごろには大部屋で一緒に作業していたようですね。[『日本社会のしくみ　雇用・教育・福祉の歴史社会学』](https://bookclub.kodansha.co.jp/product?item=0000321617):+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/856154006166568960)
- むしろ全員同席の文化的な側面は日本はもともと備えている可能性があるので、全員同席できない理由はないはず。。。（あるとしたら別の要因？≒メンバーシップ雇用とか雇用の流動性も関係していそう）
- いわゆる「ワイガヤ」という奴が近そう。
- 全員同席をしていても、タスクベースで専任化しちゃっているから、コミュニケーションを頻繁に取るようなことが無くなったのではないかなぁという気持ち
- 後は日本人の細部までこだわる完璧主義的なところが、ドキュメントの作り込みに走ってしまって、コミュニケーションを取らない方になったとか？

### 6.2.12 代替案

- > プログラマーのチームが複数ある場合は、それぞれが完全に異なるコードベースで機能するように、責任を分離することを検討してください。[Evans]は、そうするためのオプションについて優れた議論をしています。
- チーム兼任者問題が、ここでも出てくる。一つのチームに専念できないことがこれを機能させないことにつながる面もあるが、日によって専念する日を決める仕組みづくりの裏付けとして捉えることもできるかも。
- Evans本14章はチーム兼任ではなく複数チーム間の関係についての話では？
- ↑その通りですね。引用するべきものを間違えました。

----

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

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

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