# Agile459読書会(2018/03/07)

## 近況
### @ueda
- d3jsを試してみた。[burndown](https://npmyj.github.io/reading-circle/burndown.html)
- AWSの本を買うのにかさばるのでKindleにしてみた。が、目的の本が「固定レイアウト」でがっかり。

### @got
- アジャイル レトロスペクティブズ 買いました！読んでます！
- ファシリテーション。意見の発散・集約。
- チームとして考えていくときに...
- KPTもやり方の一つ。ふりかえりの仕方にもいろいろある。

# 9章 導出プラクティス

## 単一のコードベース
### @kobatomo
- 納得。派生系ばかり作るとメンテナンスが大変だよねー。時間がないからを理由にその場しのぎの設計にならないようにしないとね。C#実践開発手法 (マイクロソフト公式解説書)は、参考になりましたー。(SOLID原則)

### @got
> 単一のコードベースから複数のプロダクトを作れるように～
- それはそれで設計・仕組みも大変だろうけど、複数のバージョンをそれぞれを維持するコストとを天秤に乗せてみるといいのかもしれない。
- 「出来るように作り直す」のも解きほぐす案の一つ？

### @ueda
> 単一のコードベースを妨げている根本的な設計の問題を解決すること
- Androidアプリ開発を始めた当時(2010秋頃)を思い出した。
- iPhoneはあった。Androidは普及し始めたあたりかな・・・
- 手作業で管理するのではなく、アプリ（システム）で管理する仕組み
- 機種によって実装の仕方を調整しないといけなくて苦労。 - 機種依存の壁にぶちあたった
- 今思えばもう少し掘り下げて対応してみても良かった。（あまり余裕がなかった）

## デイリーデプロイ
### @ueda
- デプロイの自動化がなかなか難しい。
- おそらく技術的な問題ではなくて、経験的なもの。（やればできる？
- 取り組んでいる仕事の規模が比較的小さいので手作業で間に合っている？
- 動かく環境（開発、検証、本番...）が多くなると、手間が多い
- 今の課題になっている
- やるしかない！

### @got
- 外から得られる情報を見聞きしてても、この項目が10年以上前に書かれているとは思えない。
- ThoughtWorks Radarの2011年みると、Continuous DeliveryがAdopt（業界に受け入れられた）、Continuous DeploymentはTrial(試し中）となっています。XPはその更に数年前なので、やってない所は時代に取り残されている感がする（周囲の環境にもよりますが）--kkd

> こまめにデプロイするには多くの障壁がある。
- 「技術的な障壁以外はどうにもならないよ！」と書きたくなったけど、どの障壁に対しても少しずつ積み上げるように改善してくしかないんだろうな...
- jss?? のツイートで自動化についての議論を見かけた。組み込み系の人など、かなり自動化が進んでいるようで。
- http://jasst.jp/symposium/jasst18tokyo.html

## 交渉によるスコープ契約
### @ueda
- 「最初のリリースは試作レベルで、機能の確認ができたら次のステップとして作り込みをしましょう」というような相談をしている。
- 最初に設計して・・だと見積の精度が出ない。まず作ってみないとわからない、で進めないとお客さんも感覚がつかめない。作っていくとお客さんも感覚をつかめていく。
- 進んだこと、話したことを共有してくとよく進める。
- ただ、契約の話（文章化）は難しい・・・

### @got
> 長期的なひとつの契約ではなく、短期的な契約をいくつも結ぶようにして、リスクを減らすこと。
- 契約に限った話で言うと、ここでいう「リスク」ってなんだろう？
- 長期な契約だと、はじめに不確定な要素が多い。始まってみると想定外のことが発生する！ことに対する＞リスク
- 要件にかかわってくる

> 供給側と顧客の利益を一致させる仕組みであり、～
- この話って会社対会社のような契約の話だけでなく、人と人との合意の話でも同じような。
- ソニックガーデンは契約形態が違う。この問題をクリアしている。(@kkd)
- むかーし、牛尾さんがこんなやりかたやってました（プリペイド型契約）。http://objectclub.jp/community/XP-jp/xp_relate/xp_present
- 

## 利用都度課金
### @ueda
- 今、AWSでの開発に取り組んでいて、AWS自体が従量課金なので、それをベースに考えると、利用都度課金の説明もつきやすいかも。
- 何れにしても、これまで受託開発ばかりやってきたので、利用都度課金については取り組んでみたい。

### @got
- ソフトウェアを「作って運用する側」でなく、「売る側」の視点が新鮮。
> お金の流れをソフトウェア開発に直結～
- 収益を上げることを考えなきゃならないので、本当はすごい必要な視点なのかも。

### @kkd
- 価値創造契約 https://agile.esm.co.jp/services/value_creating_contract/
- まさにPay Per Use

# 10章 XPチーム全体
### @ueda
- 「インタラクションデザイナー」というポジションって普通にあります？単にUIのデザインではなさそう。
> 全員がロープに結ばれているという感覚
> 全員で足並みをそろえて歩いた方が、ずっと先まで進める
- モブプロを経験したのでよくわかる。

### @got
> ハッピーエンドではない話
> どのグループも自分たちをもっと大きなグループの一部であるとは考えていなかった。このような～
- もしかしてこの『グループ』には「プログラマー」も含まれている？

> 全員で足並みをそろえて歩いたほうが、ずっと先まで進める
- 「どこかにたどり着くため」ではなくて、「ずっと先まで進むため」？
- プロジェクトじゃなくて、プロダクト（ずっと続く）

## ふりかえり

- ふりかえりの時間をちゃんととりたい（20:45-) (@got)
- デイリーデプロイが課題になってるので、問題意識があるうちにしかかっておきたい(@ueda)
- 契約はもっと勉強が必要だなぁ(@ueda)
- 少しづつ進めていく（前から言ってるなぁ） (@got)
- 二人でも淡々と進めていてよかった(@kkd)
- ThoughtWorksの事例、知っておくのは良い。(@kkd)

## 進め方のふりかえり

- ２人でも同じペースだった。もっとシンプルに話せる？
- 一人の持ち時間を決めておくといい？
- この読書会で何を価値とするかが重要(@kkd)
- @kobatomo さんのプランだと6月末には終わらせたい？(@got)
- 読書会のペースを落とすか、いったん止めるか。(@kkd)
- PofEAAの読書会が途切れたのを知って...(@got)

## 次回
2018/3/28 (水) 19:30 - 21:00

- 対象　

### 役割分担
- 司会 @got
- connpass @kkd
- wiki @ueda
- hackmd @ueda
- connpassのグループに通知
- 読書会を知らない人もいそうなので。。--kkd
- グループメッセージの送信

読書会のベロシティを測ろう。

## ベロシティ
- 前々回は、８ページ
- 前回は、６ページ
- 今回は、6ページ