アート・オブ・アジャイルデベロップメント読書会 7.6 コードの共同所有
===
###### tags: `アートオブアジャイルデベロップメント読書会`

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

# Discord開始位置

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

# 自己紹介

- ファシリ役
-
- 読み上げ役
-
- タイムキーパー

# 参加の仕方

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

# 感想など

## 目安の時間

## 感想・気づき
### 7.6　コードの共同所有
> 私たちはみな、高品質なコードに責任がある
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/805411885611483188)
- 毎日音読したいパワーワード:+1::+1::+1::+1:

> コードの共同所有は、コードを維持管理する責任をプログラマ全員に広げるものだ。
> 誰一人としてシステムのどの部分にも所有権を主張したりせず、誰もがどの部分にも必要な変更をすることができる。
- そういえば、ひと昔前はソースファイルの先頭に署名とか入れているプロジェクトもありましたが、最近はあまり署名を見かけないような気がします。
- チームでスクラムを初めて導入した時の振り返りで「自分が作り込んだ感覚が少なくて物足りなかった」という意見が出たことを思い出した。
- 「自分の所有権」だけでなく、「他人の所有権」が意識されがちなシーンもある（むしろ、そっちの方が多い:+1:
- 「ここは○○さんの対応した部分だから……」というタイプの会話:+1::+1::+1:
- -> 「知識のサイロ」へ接続するか
- 特に、そこの部分の仕様が入り組んでいて、かつ既存実装も膨大だったりややこしいことになっていたりすると、手が伸びにくくなったり:+1::+1:
- 「シンプル（≠ easy）な設計」が達成されていない環境では、「コードの共同所有」も発揮しづらいシーンが有るのかもしれない:+1::+1:
- 「シンプルな設計」が難しいときはモブ、ペアが特に威力を発揮しそう

> 実際に、コード品質を改善することがコードの共同所有の最も重要なポイントかもしれない。コードを共同所有すると、誰でも問題を見つけたら修正することができる。
- 前段の所有権にも関係するところで、誰もがコードを改善できるのはチーム開発する上で欠かせないことですね。ソースの担当者じゃないと編集できない(編集されるのを嫌がられる)だとリードタイムのボトルネックになったり、知識の共有が促進されないですね。:+1:
- 個人で所有しないように、という話もあるが、特定のモジュールを特定のチームでしかいじれず、という話もありそう

### 7.6.1 共同所有をうまくやる
> 自分のコードに誇りを持つのではなく、チームのコードに誇りを持とう。
- 全世界に浸透させたい良い言葉。 :+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/805411846286344202)
> 個人的な設計ビジョンを無理強いするのではなく、他のプログラマと設計の可能性を議論して、解決策を考えて合意しよう。
- わかりみ。修正プルリクエストがあった際に、設計の意図や課題意識を会話することで、知識の共有や、さらにより良い案も出てくることがありました。:+1::+1:

### 7.6.2 見知らぬコードで仕事をする

- > 設計を推測するスキルも大切だ。コードの各ステップで何をしているかを正確に知る必要はない。うまく 設計されたシステムでは、各パッケージ（あるいは、名前空間）にどんな責務があるのかを知るだけで十分だ。 - p.202)
- 「うまく設計されたシステム」であることがシレッと前提されている:+1:じんｎじんんじんんじんん
- まあ、「うまく設計されたシステム」でない場合は、細かく追いかけるしかないというのはそうではある
- 「うまく設計され」てない時は？については、↓で言及がある:+1:
- > もしXPを始めたところなら、まだ優れたユニットテスト一式はないし、設計もあまり当てにならないかもしれない。その場合には、設計を推測したり、ユニットテストを当てにしたり、リファクタリングすることはできないかもしれない。だから、コードをよく知っている人とペアを組むのがずっと重要になる。 - p.202
- 「まずはペアプロ」とある。7.6.1にある突然の退職者のことなどを考えると、こういったものの理解をペアプロ、モブプロで進めてるのは欠かせないことと実感する。
- 新しく開発者としてジョインした方向けに、プロダクトコードの一部の機能をライブコーディングしたことがあります。プロダクトコードの構造やTDDの進め方など一通り紹介できましたのでよかったかなと思います。(その後、さらに開発者増員が決定したので、後から録画しておけばよかったと気づきました汗):+1:
- > ドキュメントとしてのユニットテストに頼ろう。セーフティネットとしてね。
- セーフティネットであって、「それで全部まかなえる」という類の主張はしていない:+1:
- セーフティネットという言葉を使うからには、それより手前で何かしらの対策が施されているべき（それが喪失していたり、利用できなくなったりした場合の備えにはなるが、それで完結はしない）、というのを含意していると見た方が良さそう:+1:

### 7.6.4 質問
> 人がシステムの特定の部分に引き付けられるのは自然なことだ。人は特定の領域の専門家になる。全員が コードベース全体について一般的な理解を得るが、最近取り組んでいた箇所の詳細を知っているのはそれを やっていた本人たちだけだ。 　テストとシンプルな設計を使うと、このアプローチはうまくいく。シンプルな設計をしてコードの見通し の良さを重視していると、見知らぬコードも理解しやすくなる。（P203).
- 随時必要なものだけを育てていくと理解がしやすくとても良いと感じる。最初が巨大だと理解することに膨大に時間を使うか、諦めるかになると感じる

### 7.6.6 使用上の注意
> 誰もコードを所有しないことの言い訳として、コードの共同所有を使ってはいけない。マネージャはこう言う。「共同責任というのは誰にも責任がないことだ」 そんなことがコードで起こってはいけない。
- チームメンバー全員がコードに責任を持つことが必要だと感じた(当たり前のことだけど改めて感じた)。
- どのようにしたらチーム全員がコードに責任をもつように働きかけることができるのだろう？
- 責任を持つ代わりに、全員が助けるという状態に持っていくのが大事。(実際、できる人任せなりがちでそうならないのが多そう)

> コードの共同所有には、よいコミュニケーションが必要だ。
- 結局、コミュニケーションが重要かなと。

### 7.6.7 代替案
> コードの強い所有を使わないことをおすすめする。知識が凝り固まって、サイロ化を促してしまうためだ。
- 在籍が長くてメンテナンスし続けてきた人や肩書の凄い人（元◯◯CTO、各所で登壇している有名な◯◯さん）がいると、この強い所有は起きやすいんじゃないかと思った。

## 疑問・参加者に聞いてみたいこと
- 実際にやってるよ！やれてないよ！というのをアンケート取りたい

### 7.6 コードの共同所有
> コードの共同所有は、コードを維持管理する責任をプログラマ全員に広げるものだ。 - P.201
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/805402669094928404)
- 1人だけ飛び抜けたプログラマが居て、しかも個人ワークが大好きな人の場合、他の人がメンテできるようになるには具体的にどんな方法が考えられるか？:+1::+1::+1:
> 個人的な設計ビジョンを 無理強いするのではなく、他のプログラマと設計の可能性を議論して、解決策を考えて合意しよう。（ページ201).
- 個人ワーク好きなメンバーが事前事後にも説明もしないケースが辛い。メンバーの意識が変わらない場合はチームビルディングの問題としてメンバーアサインから重要となるのかも :+1:
- つい自分が得意なタスクや自分が理解している部分の変更のタスクをとってしまいがちになるが(特に納期などが迫っていると)、チームメンバがなるべく様々なタスクをとるような工夫などをしていれば聞いてみたい:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/805407408766844970)
- やはりペアプロしたり、期日のないタスクで入れ替えてみたりしました。
- 複数チームで同一プロダクトの開発をおこなっているときに、チーム最適化はされてもチームをまたがった最適化があまり意識できていないことがありました。(例えばプロダクトコードでチームAが担当した箇所は対応されていても、チームBの担当範囲の考慮がされていないなど)
- 複数チームで共同作業されるときに、皆さんはどのような工夫をされていますか？ :+1::+1:
- そもそもなんですけど、できるだけチーム間で依存が起きないように、依存を排除していこうという取り組みをしていました。依存が残っている状態では…まぁ、障害起きたことありますね…
- ペアプロ・モブプロやることへ抵抗感がある人へ広めるためにどんな手段があるか考えたい:+1::+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/805399996194488330)
- よくある反対意見としては時間的なコストが増えて開発スピードが出ないなど
- 身近に聞いた例だと、常に相手がいる状況は縛られてる感覚が強く、不自由でやりづらいなど

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

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

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