# Agile459読書会(2018/05/09)

## 近況
### @ueda
- 「ザ・ゴール」より VII 報告書 - 32の途中
> どうすれば人を説得できるのか、
> どうすれば古い習慣を取り去ることができるのか、
> どうしたら新しいことを嫌う人たちや体制を克服できるのか
- 「ザ・ゴール」読了。
- あとがきによると、本を読んで実践することで生産スケジューリングソフトが障害になってしまうという皮肉な結果に。
- ふとツイートのキーワードが気になって、
> [在庫、経費、スループットの3つの指標を考える。...](https://twitter.com/npmyj/status/993499628652789760)
- 「ザ・ゴール」をベースに書き換えた文章みたいで、オリジナル(というか元ネタ?)について言及しないまま評価するのはどうなのかと。
### @kkd
- GWに出たレースでリタイアして凹んでる。。。。
- vue.jsとか触ったけどよく出来てるなー。
- note.muもはじめたよ

### @kobatomo
- TDDBCのconnpass作ったー。ただ、管理者にしているのに、見れる人と、見れない人がいるー。なんでだー。(5/10公開)
- 最近 Slack通知でどこが更新されたかわからなくなった。見れる設定があれば教えて欲しい。
- 子供とマイクラしに、e-トピアさんへ。瀬戸大橋がすごかったね。

### @got
- GWは初のUSJ、大阪中心部への上陸！
- 特にUSJに関しては、待たせ方が客のストレスににならないつくりに関心しました。
さすがエンターテインメント！

## 今回の役割
- 司会： @ueda

## 今回の目標
- 14章 設計：時間の重要性
- 15章 XPのスケーリング

## タイムテーブル
- 19:30 - 19:40 自己紹介や近況など
- 19:40 - 20:15 14章
- 20:15 - 20:45 15章
- 20:45 - 21:00 振り返り

# 14章 設計：時間の重要性
### @ueda
> パーマカルチャーのように「各要素が有益に関連したシステム」が設計
- 有益に関連、というところまで意識していない。
> ソフトウェアはレバレッジゲーム
- そういうことができてよいはずなのに、わざわざ苦労する方向を選んでしまっているような...
> XPの戦略は「何も設計しない」ではなく「常に設計する」
- ドキュメントがボトルネックにならないように
> 103p下: インクリメンタルなデータベース設計の洗練された戦略
- 一般的にこの手法が使われている？
> Once and Only Once
- DRYとかDBの正規化までは頭の中にありますが、それでは足りない？
> パターンとは、重複をほとんど必要としないコードの構造
- 「パターン」という言葉はそういう意味で使われていたのか！！
- ここではデザインパターンに近い - kkd
> 104p中: システムにフィーチャーを追加するという問題に集中しているため、設計を改善するまでには至らなかった
- 振り返ると大半がそんな感じですね。
> 本当に優れた仕事をしたときのモチベーションや満足度が、どれほどのものかを考えていなかった。
- はい。その通り。言い換えると、そういう満足度を体験する必要がありますね。
> 105p上: 設計とは、技術側の人間とビジネス側の人間の信頼関係を築く(kizuku)ためのものである
- ただし、ドキュメントに依存しすぎてボトルネックにならないように
- 要求された機能を毎週デリバリー！！

### @got
> (p.101)10年間で「すべてを設計する」ことから「何も設計しない」ことへと振り子は大きく揺れた。
- CodeComplete2版が2004年。それから10年以上経っても・・・
- 参考(Google Books)
- https://books.google.co.jp/books?id=LpVCAwAAQBAJ&lpg=PA119&vq=BDUF&hl=ja&pg=PA119#q=BDUF&f=false
> (p.103) コストの話
- 「時間-コストカーブ」のグラフが全く出てこないけど何でだろう？
文章ではそれらしく出てきてはいるけれど・・・
- 従来の手法（？）
> (p.103) 間違いが多ければ、プロジェクト期間中に修正や対応が必要になるため、総コストはもっと高くなるだろう。
- Once and Only Onceの説明で
> (p.104) コードにこのような特性が備わっていれば、継続的に変更を加えても、コストを抑えることができる。
- 以下記事の「変化ヲ抱擁セヨ」にグラフがありましたー。
- [extreme programmingの魅力を探る](http://objectclub.jp/community/XP-jp/xp_relate/xp-intro)
- 第一版にはこのグラフがあった
- 
> (p.103) 経験にもとづいた設計の場合は～、最小限の初期設計の時間に加えて、稼働中のコードや実データにあとから設計判断を組み込むコストが必要になる。
- 「経験のみ」で「現場にもとづかない」設計ってことかな？
- 当時10年程前の設計のまま「昔と同じ方式だから大丈夫！」で、稼働後に大やけどした苦い経験・・・
> (p.104) コードを修正しながら、少しづつきれいにしていこう。設計の改善をやりすぎてしまう誘惑に打ち勝とう。現在に影響を与えている設計を改善する習慣を身に付けよう。
- （必要のない）改善ではなく、目の前と進む先にある問題に対応していく。
> (p.105) XPスタイルの設計と、戦略の代償
- 「規律」を余計なコストと見ている人たちをどう変えていくか。
- 規律によって何が得られるかわからない。得られることの有益性を感じたらかわるかも。

### @kkd
- パーマカルチャーはXPの類似性多数
- PCのデザイン：要素間の有益な関連＝要素のInputとOutputを結びつける、組み合わせて相乗効果をもたらす、etc
- データベース設計の戦略の話（P103)
- これってRoRに組み込まれて広まったのかな？
- マイグレーションスクリプト <= あー、なるほどー！！（@ueda
- Once and Only Once = DRY　でもいい。
- 最近だとEvolutionary Architectureかな？
- https://efcl.info/2017/10/09/clean-architecture-and-building-evolutionary-architectures/
- ビッグりファクタリングは大変
- こまめに変化させていけば大丈夫だけど
- とはいえ、スピード（ビジネス）優先→レガシーコード→スピード低下→リファクタリング、というパターンもあるかなぁ

### @kobatomo

- 沢田マンションすごい。
ブログ見て、おおと思った。
- AgileJapan2018で沢マン見学したらどうか！？

- ENUFって何だろう？
- https://enterprisezine.jp/iti/detail/2392
- 必要な分だけ？

- P102-P103のグラフ。
- 理解不足。
- 簡単な機能追加は直感でも可能、複雑な仕組みになると熟考さらに経験が必要
-

- 当初の設計の前提が変わっても開発ペースを維持できる。
本当？？

- シンプリティな解決策。
- どうしてこうなっているのか？設計思想が理解できるか？これって、普段の勉強会とかで基本構造は、こうするという意識づけがないと、難しいよねー。

- 情報を残す。伝えるというのは、個人的にはドキュメントかなー。
- 「情報を残す」とは書いてないよ。いかに伝えるか。
- そういえば、Lightweight Architecture Decision Record (adr)っていうのあるなぁ
- アーキテクチャの変更を履歴管理するツール
- http://tbpgr.hatenablog.com/entry/2017/02/22/080000
- こんな感じで残すのもありだよねー。

# 15章 XPのスケーリング

## 人数
### @ueda
- スケーリングについて意識していなかった。（一つのチームで完結するところまでしか考えが及んでいなかった。
> 複数のチームをそれぞれ単独（一つのチーム）として管理。
> 小さなチームでプロジェクトを開始。自律的な複数のチームで作業を分担。
- なんとなく理解。
> [PMBOK(ピンボック)](https://ja.wikipedia.org/wiki/PMBOK)
- プロジェクトマネジメントについてどのように学べば...?

### @got
> (p.108上) よくある厳格なコントロールと書類の承認だけが解決策というわけではない。
- 「だけ」は否定しているけれど、そのものは否定していない。

> (p.108上) 問題解決の３つのステップ
- 一時的に３が見つかったとしても、じっと見れば １→２ のループで解決する流れになりそう。
- それでも解決できないのであれば複雑（重量級と言うべき？）な解決策を取る。
> 大規模プロジェクトマネジメントの適用
- 「１→２」のループで解決するためにはスキルも必要・・・

> (p.108中) システムを自然な切れ目にそって分割
- 良い意味で抽象的な言い回し。
- （独立して機能する）機能？インクリメンタルにリリース可能な単位？場合による？

### @kkd
- アジャイルのスケーリングの話は国内でもここ数年で事例は増えている（はず）
- IPAの調査とかもやったなぁ → https://www.ipa.go.jp/sec/softwareengineering/reports/20120328.html
- 100人規模とかもある。
- スケールについてのアジャイルの話題はホットですね
- SAFe, Scrum@scale, LeSS(Large Scale Scrum)
- 「スケールさせない」という選択肢もある気がしてる
- 人が増えると、デメリットもあるし。でもこう考える人あまりいない？
- ソニックガーデンはそうかも。
- 東芝医療？ マニュアルテスト　テストの合間にコード書く
- 咳さんのXPのスライド → https://speakerdeck.com/m_seki/xp-matsuri-2014-keynote
-

## 投資
### @ueda
- XPの開発スタイルが費用なのか、投資なのか。会計処理の問題。

### @got
> (p.109上) ソフトウェア開発を費用で処理している企業は、デプロイ後のプログラムの継続的な保守作業としてXPを正当化できる。
- 「継続的な保守作業」がある前提だけど、無い場合は？
- これは後で出る「期間」につながりそう

> (p.109中) 財務面での協力者
- 第10章 XPチーム全体 - 経営幹部の話と絡む？
- でも、XPチーム全体に会計を担当するロールって無かった。
- だから「XPのスコープ外」？

### @kkd
- ソフトウェアの資産計上の話とかもあるよね。
- 『脱予算経営』 https://amzn.to/2K3vQre

## 組織の規模
### @ueda
- PMの位置付け。立ち回り。

### @got
> (p.109下) 組織の期待に答えると同時に、XPのよいところを維持するには想像力が必要
- XPに限らず。
- 抵抗しようと思うと「チームに必要な支持者たちが敵になってしまう」ことに・・・
- お互いに協力しあう（リスペクトする）ことが大事。

## 期間
### @ueda
- 自動テストやインクリメンタルな設計により、小さなチームで継続的にインテグレーション可能。
- 「ロゼッタストーン」を書く。将来の保守のための簡単なガイド。

### @got
> (p.110下) プロジェクトが停止する前に、XPチームで「ロゼッタストーン」を書くことが多い
- 停止ししてからでは遅いし、停止する前（気配すらないのに）書いてしまって変更コストがかかるのも微妙。
- 「新たに配属される保守担当者」がいることを前提として書くのならいいのだけれど・・・
- バランス難しい。

### @kobatomo
- テストのおかげでっていうの大事。

## 問題の複雑さ
### @ueda
- 専門家とペアになって課題に取り組む。プロジェクトの中で学習。

### @got
> アクチュアリーとのペア
- ペアプログラミングではなくて、ペアワーク（ラーニング）？
- 協力というよりリスペクト大事。

## 解決策の複雑さ
### @ueda
- ビルドプロセスの制御（自動ビルド）
- ストーリーとストーリーボードにより取り組んでいる課題と時間を可視化。
> 継続的にデリバリーしながら少しずつ複雑さを削り取っていく。
> 適切な作業に必要な見積りが受け入れられやすくなる。
- 見積りから始まるのではなくて、XPで進めていく中で見積りが立てやすくなる。見通しが良くなる。

### @got
> (p.111下) 墓穴を掘る状況を脱する
- 墓穴から這い上がることだけに集中するとダメだよね。

> (p.111下) 計画づくりを見える化すれば、時間がかかっている場所を全員が把握できる
- 「全員」の範囲はXPチーム全体？顧客も含む？
- きっと広ければ広いほど良いと思うのだけれど・・・

## 失敗の重大さ
### @ueda
- 前にはNASAの引用がありましたが、ここでは人命に関わる病院のソフトウェア。
- XPによってトレーサビリティへの対応が簡単。
- 審査官との継続的な関係。（どちらかというとビジネス的な。

### @got
> (p.112中) XPの流れの原則からすると、審査がプロジェクトの最後のフェーズになってはいけない。
- スクラムの「あっても良いができるだけ無くせ」と言われる「リリーススプリント」に近いかも。
- そもそも「フェーズ」であることが流れの原則に反してる？

> (p.112中) 審査官との継続的な関係を築けば、審査の成功率が高まる
- 継続的な関係を築くにはお金が必要なことも・・・
- 費用と投資と話に！
- 「継続的な関係を築く」ことでお金の話も柔らかくなるかも？

> (p.112下) トレーサビリティの実現
- まさかソースコードが管理されていないプロジェクトが未だにあるなんて！！！

## ふりかえり
### @kkd
- みんなのコメントで読めた。
- @kobatomo さん、ドキュメントで困ってる？

### @kobatomo
- 読めてないので参加しにくかった。@kkdさんに感謝（slackのコメント)。
- 参加してくれてありがとう！(@kkd)
- 「事前に読んでなくてもいいよ」とconnpassに書いてもいいかも

### @got
- 複雑さという @kkd さんの説明で、自分で理解したように思えていたことが自分の言葉で説明できていないことにきづけた。

### @ueda
- XPよりもザ・ゴールで頭がいっぱい（ｗ

## 次回
2018/5/23 (水) 19:30 - 21:00
第15章 期間 ～ 第17章 はじまりの物語

### 役割分担
- 司会： @kkd
- connpass： @ueda
- connpassグループ通知
- wiki：@got
- hackmd：@got

## ベロシティ
読書会のベロシティを測ろう。
- 前々回は、10ページ
- 前回は、11ページ
- 今回は、10ページ