アート・オブ・アジャイルデベロップメント読書会 6章冒頭＆6.1 信頼
===
###### tags: `アートオブアジャイルデベロップメント読書会`

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

# Discord開始位置

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

# 自己紹介

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

# 参加の仕方

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

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

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

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

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:00- | - | もくもくタイム（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分を予定しています
- 盛り上がったら延長することもあります

## 感想・気づき

### 6 コラボレーション

> P.105 プログラマが必要な情報にアクセスして理解する効率が上がれば上がるほど、ソフトウェア開発の効率も上がる。
- 言われると当たり前ですが、「協力すること」ミニエチュードのように、仕事に必要な情報の取得時間について、調べたり議論したことはなかった。:+1:

- コラボレーションミニエチュード
- やってみると面白そう。10分以内、1日以内、1日以上という分け方が面白い。:+1:

### 6.1 信頼

> 逆に、チームメンバーが助けを求めるためには、お互いを信頼しなければならない。チームメンバーの1人が答えられない質問に遭遇したら、ためらわずにその答えを知っている人に聞く。こうしたちょっとした質問がきっかけで、長いペア作業が始まることもある。

- 信頼という言葉が漠然としていてわかりづらかったが、他人と協力することを厭われないという信頼や、XPを実践しているチームが必ず成果を出すと信頼されている、という個人とチームの2種類の信頼があるみたい:+1::+1::+1:
- 言い方は悪いかもしれないが、親が子供のやることを黙って見守る類の信頼に近い気がした

> 他人を助けるのに時間をかけても非生産的だと思われない、と言う信頼:+1::+1::+1::+1::+1::+1:
- めちゃくちゃいい表現！！使っていきたい:+1:
- 個人じゃなくてチーム目線で考えると自ずと非生産的ではない気がする。

> 誰かと意見が異なるときにも、 敬意を払われるという信頼が必要だ:+1:
- 「議論＝戦い」と解釈してる時点で履き違えているなとよく思う。エンジニアにとても多い印象。互いの意見を共有し、着地点を探し合うということを知らない。ただこれは、本人の性格で終わらせる話でなく、あくまでコミュニケーションスキルとして学ぶ機会が必要なのかなと思う。社会人はコミュニケーションがまともに行えて当然という風潮があったりして、当たり前のことを学ぶ機会が意外と無い。:+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/851070866469290044)
- 忖度して相手を立てるか、何がなんでも相手を打ち負かすことを考える人は一定数いる。お互いに敬意を払って議論して、いい方向に進むためにもやはり信頼が必要なんですね。
- 「敬意を払う」というのも、時折誤解というか、（「議論＝戦い」のように）変な捉え方をされている気がする。敬意を払うことは、相手の主張に賛同すること、それを褒め称えることを必ずしも含まないはずでは、と思っている（本文の「敬意を払う」は、↓のような態度も包括していそうに思う）が、批判する = 敬意が無いかのように語られがちな印象がある[要出典]。
- 「あなたの主張それ自体は尊重するし、あなた自身には敬意も払う。しかしあなたの主張には共感しないし、同意しない」という態度は、最近ではどういう風に捉えられることが多いのだろうか（「矛盾してる」とか言われちゃうんだろうか）

### 6.1.1 チーム戦略#1：顧客とプログラマのあいだの思いやり

> 私が働いたことのある組織の多くは、顧客とプログラマのあいだにある「私たち対彼ら」という考え方に苦しんでいた。
- この構図は本当によく見る。「互いがwinwinになれたら良いのにな」と思いつつ、メンバーが顧客の悪口をしているところを横目で見ている。こういう人に限って顧客の真の要望には関心を持たず、自分の仕事の範囲で物事を見ている印象。:+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/851074769561714708)

### 6.1.4 チーム戦略#4: チームの継続性

- > 生産的なチームを維持することで、この無駄を避けることができます。ほとんどの組織は、人を会社の基本的な「リソース」と考えています。代わりに、チームをリソースと考えてください。プロジェクトに人を割り当てるのではなく、プロジェクトにチームを割り当てます。人々にチームに参加してもらい、複数のプロジェクトに協力してもらいます。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/851087220693925948)
- 大体、「チームのナレッジを分散する」名目で分解されることは多いと感じるし、チームメンバーの囲い込みをするマネージャは嫌われる傾向がある気はする。チームビルディングの手間を考えて、完全分解は避けたほうが効率的な面はありそう。
- 新しくチームを構成すると、関係作りが大変なので、チームとして継続して開発することを提案したい。経営層やチーム管理してる人に何を伝えれば実現できるのだろうか？:+1::+1::+1:

### 6.1.5 印象

- XPチームが解雇されたことについては度肝を抜かれた。価値あるものを届けていれば、ビジネスサイドの信頼は勝ち取れるものだと思っていたが、そういうわけではないのか。:+1::+1::+1:
- これは現代でもあり得る話？:+1::+1::+1:
- ビジネスサイドからもチームとしての活動自体の価値にも理解されていることも重要かなと思う。
- > 「彼らは本当に働いてますか？」
- 現実に、組織で唯一のアジャイルチームだったりすると、残業時間が少ない、業務時間内の勉強会開催頻度などを理由に「あのチームは暇だろうから、人員をうちによこしてくれ」と言ってくる人は多い。:+1::+1::+1:
- こう言うの嫌いだったり不要だと思うエンジニアの人は多そうだけど、大事だよなぁ・・・！こう言うことに言及されてる技術書って少ないよな、と思う:+1::+1:

### 6.1.7 組織戦略#2: コミットメントを果たす

> ステークホルダーはソフトウェア開発についてあまりよく知らない。これはステークホルダーに肩身の狭い思いをさせてしまう。つまり、以前ひどい結果を経験したのに仕事がうまくいっているか聞くこともできず、あなたの仕事を当てにしなければならないのだ。:+1::+1:
- ビジネスサイドの人が開発チームのやっていることに、遠慮がちに質問してきたことを思い出した。:+1:
- 開発自体に詳しくない＋XPなどの考え方をわかっていないと質問しづらさを感じさせていることにとても反省している

### 6.1.8 組織戦略#3: 問題を管理する

- > 重要 残業への依存は、体系的な問題を示しています。
- ベロシティがわからなくなるなど問題があります。「残業当然」みたいになっているチームと、文化を揃えていきたい。:+1::+1:

### 6.1.9 組織戦略#4: 顧客の目標を尊重する

> プログラマは顧客を歓迎するために人一倍努力すべきだ
- こういう発想を持ってるエンジニアばかりではない気がするけど、大事だなぁ:+1::+1::+1::+1:

> 顧客もスケジュールについて不満を言ったり、見積りについて論争したくなるのを我慢するべきだ。私はここではプログラマの役割を強調している。
- 受託開発の時に顧客もエンジニア経験者で、こちらの見積もりに不満を言われ、論争が泥沼になったことはよくあった
- その認識のすれ違いはどこからきたんでしょう？:+1::+1::+1::+1:

> 反復の早い段階で、最も困難で最も不確実なタスクに取り組みます。
- この結果か、バーンアップチャートを作ると二次関数的になることが多い。（対策すべきか、結構分析が悩ましい）
- どう言うことか聞いてみたい。笑:+1::+1::+1:
- スプリント序盤は難しいタスクで停滞、終盤に簡単なもの含めて消化されて伸びるパターンと、単純に夏休み宿題パターン、スプリント前半に前のスプリントの隠れた積み残しがあるパターンなど

### 6.1.11 組織戦略#6: 正直になる
> 真実を伝えるという教訓
> > 私たちは7ヶ月以内に出荷する必要があったが、リリース計画によると13ヶ月かかることになっていた
> > （中略）
> > スケジュールは秘密にしておくことはできない。奇跡の巻き返しなんてものはない。本当の出荷日はいつか知られてしまうんだ。
- 今まさに同じ状況にいますw　7月中にリリースしたいと要望ありましたが、フロントエンドのポイントとベロシティで計算するとどう考えても9月頭…ｗ　**もちろん**正直に言いました！:+1::+1::+1::+1::+1::+1:

> 私たちの仕事は危機に瀕していたが。なんとか間に合わせようとした。ブルックスの法則を無視して大量のプログラマを雇うことにした。

- これは本当に誰も幸せにならないからやって欲しくない...。でも、解決策が当事者で出せないのも事実な気がする。どうやっても無理だから、「締め切りを伸ばすべき」だという理屈を通したい。でも、それができるような信頼ができていないのが問題なんだろうなぁ。:+1::+1::+1:

### 6.1.12 質問
- > 残業は小さい問題を解決するのには役立つが、あなたが ~~ゴリウル~~~ とりうる手段の中で最初の手段や唯一の手段にしてはいけない
- め、名言だな・・・！:+1::+1:
- ゴリウルって強い言葉:+1::+1:
- くぅー:+1:
- 
- この画像どこから拾ってきたの！返してきなさい！
- ゴリラのようにゴリ押すということか
- 

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

### 6.1 信頼

- この本で言及されているやり方以外に、信頼を高めるやり方を実践されているのがあったら聞いてみたいです:+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/851067062084042752)
- 信頼という言葉は「メンバーに任せる」みたいな意味も含まれているように個人的には感じます。(実際とても大事だと思います。)ただ、他の文脈でよく出る"心理的安全性"は気軽に提案や懸念を言える環境を大事にするといった意味合いが強いように感じます。"信頼"にメンバーに任せるという意味が含まれている場合、気軽に懸念が伝えられないのでは？とも思うのですが、"信頼"と"心理的安全性"についてどのように考えていますか？:+1:

### 6.1.1　チーム戦略#1：顧客とプログラマのあいだの思いやり

- 顧客の要求があまりに無茶に感じるような場合、心理的な対立構造ができやすいと思うことがありますが、こういう工夫しましたとか経験談があれば聞きたい (社外の人との調整が難しい):+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/851059988750270514)
- 例えば、顧客はテスト自動化で工数削減したいけど、今の設計的に難しいみたいな
- アジャイルサムライにもでてくる、あらぶる四天王はすべて満たせない現実を踏まええて、顧客の真の価値や競合に打ち勝つために最も重視すべきものは何かを顧客と会話することかなと思います。ときには、それ本当に必要ですか、と顧客に聞く勇気も必要になりますよね。

### 6.1.8 組織戦略#3: 問題を管理する

> もし四半期に1つ以上のイテレーションで通常の就業時間の10%を超える残業をしているチームがあれば、私は組織の問題を探そうとする。
- 「組織の問題」という言葉、他でも出てきますが、具体的にどういうことを意味している？このケースでは、例えば組織にどのような問題がある？
- 6.1.8に残業に頼ってしまうと過度なコミットメントを約束してしまう、といったことが書かれているので、残業前提のスケジュールを組んでしまうことを問題視しているのかと思いました
- チームだけで解決できない問題、という意味もあるのかな？と思いました:+1::+1::+1:
- 逆に顧客と合意した期日までに間に合わせないといけないなど、残業をしなければいけない（であろうと思った）時、ノー残業が当たり前になっているチームにどう働きかけたらいいのかなと悩んだりしますが、どうしたらいいのか。:+1::+1::+1:
- 届ける機能を減らす、という選択肢もあるだろうけど、そればかりやっていると顧客の信頼を失いそうな気がする:+1:
- チームが守る意識を持つことが大事そう。。KentBeckのXPの本に「責任は割り当てるのではなく、引き受けることしかできない。」と言うセリフがある。チーム自体が間に合わせる責任を自ら引き受ける必要があると思えるかどうか。。

### 6.1.10 組織戦略#5: チームを宣伝する

- 宣伝という行為はエンジニア苦手なイメージありますが、社内で自分のチームはこういう宣伝したよ、的な事例あれば聞きたいです。（ちなみに自分はチームビルディングの内容や結果を公開したり、チームが担当する業務上の難題を敢えてpublicチャンネルで相談したりします）:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/851064251316961290)

### 6.1.12 質問

> メンバーはお互いに異議を唱える方法を学ぶ必要がある。意見の相違は当たり前のことであり、受け入れることができるということを知るのは役に立つ。安心して異議を唱える方法を見つけよう。
- 安心して異議を唱えるにはどうすればよいか？:+1::+1:
- 5.5.3(P.98) の **最優先条項** が使えそう