# Agile459読書会(2018/02/21)

## 近況
### @ueda
- 近くの公園で新たに懸垂ポイントを4ヶ所発見。
- 普通の公園では一箇所ある。ブランコの支柱、滑り台、ぶら下がり健康器具
- 地図を作ろう！
- AWS-C9でいろいろ試し中...
- Cloud9

### @kobatomo
- Alexa Dayに参加。VUIに未来を感じた。
- Amazon Echoが届いて一ヶ月になる。家族は普通にAlexaを操作している様子。次は電源On/offをできるようにしようかな？

### @got
- 「さとう」です。システムの運用やってる。
- 古いシステム（CGI）のカットオーバーができた。設定がコードに埋め込まれていたので、テストを手動＋TDD的にやって外出してみた。うまく動いてよかった。

### @kkd
- 全体的に体力落ちてるので復活中...
- [アジャイルの導入の記事](https://goo.gl/fWE7b5)がブログがはてブでバズってた。

### @matamiya
- 「おかむら」さん（@gotさんと同じ会社！？）
- @kobatomo さんの紹介で来ました！
- 回線の施工管理
- 話してる内容がほとんどわからないので、困惑している！？勉強しにきた。

# 9章 導出プラクティス

## 本物の顧客参加
### @ueda
- まさに進行中の案件で抱えている問題。作り手の都合ばかりで**一般利用者のメリットが見えない**。
- 「使いたい人」が掘り下げられていない。そのままではうまくいかない。
- 「何ができたら嬉しいんですかね？」を毎週聞いていた。やっと方向性がみえてきた。
> [ソーセージ工場 by KentBeck](
)
- 「透明性」の欠如のこと。ブラックボックスで何してるかわからない状況のこと。

### @got
> ソフトウェアはそれを構築した組織を反映している。
- [コンウェイの法則（Conways' Law）](http://www.melconway.com/Home/Conways_Law.html)
- 「人月の神話」で名前が付いた事を今回調べて知った。
- 「コンウェイの法則」＝ソフトウェアの構造は、組織の構造に類似するというもの。

> ソーセージ工場
- Scrumの「透明性」と似てる。
- 人と人との信頼関係ってとても大事。

> 見積りが正確であり、欠陥率が～
- 現状を認識したうえで、さらなる改善って大事。
- こういうのを「現状を良しとせず」という？

### @kkd
- 「チーム」といった時に、誰が含まれ、誰が含まれないのかを、チームに聞く。
- お客様もチームに含める
- 顧客の巻き込みは重要だなー

### @matamiya
-

### @kobatomo
- 直接やりとりできることは本当に無駄がないよね。
- あの人の期待に応えたい。それができる距離感が今の会社にはある。
- 隠すことはしないが、自分はこうしたいという意思を持って相談している。時間切れで聞くこともあるが。
- 開発の様子を開示は今はできていないこと。これからこれから。ぜひ、今週のユーザーストーリーを一緒に決めていきたいねー。

## インクリメンタルなデブロイ
### @ueda
- どちらかというと、過去の失敗を中心に書かれている。トラウマになってるんじゃないかと。
> 技術的および社会的な足場を用意することは、移行のための保険料
- 移行といえば、みずほ銀行が今年6月から新システムに移行らしいですね。

### @got
> 新機能を追加せずに「Dデイ」に向けて何か月も準備をするのだろう。
- 既存のソフトウェアに手を入れる＆リリースするってことだよね。
- ソフトウェア以外の問題（飛ばしてはいけない段階的な審査、スタンプラリーなど）が目の前の壁。
- ここでもコンウェイの法則か。

> 技術的および社会的な足場を用意すること
移行のための保険料
- 昔と違って環境も仮想化で用意できるから、足場は作れる。
- その手間一つで助かることもある。
- その手間を惜しんだせいで反対のケースも・・・
### @kobatomo
- 今すぐできるちょっとした機能や限定的なデータセットを見つけてデブロイするんだー。本当、これだよね。。
- 続きは、読書会で！！

### @kkd
- ちょっとずつ変えていくという話かな？
- システム移行のアンチパターン→そのままがらっとリプレース→死亡
- いるもの・いらないもの選別
- 少しづつリプレース（やったことないなー）
- **心の底から**が重要だなぁ

### @matamiya
- ユーザ教育と開発コストとどちらがかかるのか
- システムここまでやるの？（エラー再現してまで数字合わせ）
- 少し引いたわー！
- 「前のままで」→楽だからだろうな（懸田）

## チームの継続
### @ueda
> チームを継続しながら適度なローテーション
- 固定されたチームで、ローテーションがないケースが多いような。

### @got
- プロジェクトが終わっても、形式上のチームは解散しても、チームを継続したいよね。

> チームを継続しながら適度なローテーションを行えば・・・
- 目指したいですね。

### @kobatomo
- これも難しいプラクティスだ。自分にっては、すべての人を可能な限り有効活用するようにプロジェクトの節目で、解散し再割当といった場合もあることが普通と思っていた。

> 気心の知れた信頼できる人と一緒に働くことの重要性
- 相談しやすいという心理的安全が生まれる。

### @kkd
- 「チームは生き物」と考えたら、人の入替えで済むはずないとわかる。臓器移植は注意しないｔ失敗しちゃうよ！→死亡
- 信頼関係、知識、文脈への理解
- 細胞は入れ替わるんだよねー。
- 新陳代謝

### @matamiya
- チームを崩す ⇒ チームの知識が失われる？
- 一部の人が知ってることが、わからなくなるとか。
- 人役（にんやく）＝仕事をする人
- ドキュメントのこす？ -> 古くなるし。

## チームの縮小
### @ueda
> トヨタ生産方式で使われているプラクティス
- へぇ〜
- 確かに車の生産効率とか考えるとシビアな問題か。
- これかな？ https://www.consultsourcing.jp/2564
> チームメンバーの誰かの手が空くまで、開発を改善していく
- そこまで突き詰めるという発想はなかった。

### @got
> チームの能力が高まったら
- この前置きが大事

- 以前と負荷が同じなまま、人を減らせるってすごい。
しかも仕事量は人を減らす前と同じ。
- トップダウンでチーム縮小させるのではなく、ボトムアップでチームがチーム自身を縮小させる。

### @kobatomo
- Q Why?
> チームメンバが少ない時は、他の小さなチームと統合。
>

### @kkd
- 「ベロシティを挙げる」のと近いかな？
- うまくやれるような人が少人数いればまわる、でもリスクもあるね→パンデミック問題
- 組織で広げるためには、経験者がばらけて、チームを作るのが定石

### @matamiya
-　日本でこれが可能なのか？
-　減らしても、新しい仕事が降ってくると辛いよね。
-　自動化、開発効率を上げるという方向に向かうという
-　職場風土と密接に関係しているよね

## 根本原因分析
### @got
> 同じ種類の過ちをチームが二度と犯さないように
- 自分ではなくてチーム。
- チームをどこまでと捉えるか。
- 自動テストできてる前提の話。まだまだ。

### @ueda
> 欠陥を再現する最小限のスコープでユニットテストを書く
- なるほどー！！これ、取り組みやすいかも。
- 普段のユニットテストが正常系に偏りすぎている？
- イレギュラーなケースをもう少し想定（意識）してみる？

### @kobatomo
- 5回のなぜ。は、ふりかえりの中で使えるなー。今度やってみる。
- 全部のProblemに対しては難しいけど、重要Problemは、メンバで話し合ってTryへ移行するのは良いかも？

### @kkd
- 短絡的な「WHY」に注意。あとは「人を責める」とうまくいかない。
- https://shigotonomirai.com/why-why-analysis-point
- https://resilient-medical.com/medical-safety/why-why-analysis
- 「なぜなぜ分析」の体系だったやり方を発表してる人がいた

### @matamiya
-　ほかの人が知らないことを知らない
-　伝えるのが面倒
-　言っただけ(聞き手が理解していない)
-　自分だけが知っていることに謎の優越感を感じる？

## コードの共有
### @kobatomo
- 共有は何かしらの形でしている。自分だけができるというのは極力避ける。（メインとサブ）
- 社内の設計思想を合わせるのが勉強会だったりする。

- Q.
２組のペアで広範囲に多くを変更すると、互換性のない
解決コストの高い変更が増えてしまう。

具体的にどんなことを言っているのだろうか？
多くの変更の定義は？？

### @got
- 「置いてある」のではなく「共有されている」。

### @kkd
- この記事みてね。https://twop.agile.esm.co.jp/how-did-we-embrace-changes-as-developer-8794826bc515
- 「共有している」の満足条件とは？
- 場所がわかってて、誰でも触れて、皆が触ってる、変更している、互いの作業にフィードバックしあってる、ところまでいかないと。

### @ueda
> ペアプログラミングを実施すれば、チームメイトがお互いに品質に対する貢献を示すことができる
- 個人に責任を負わせるのはダメですよね。チームとして品質に貢献。いいですね。
- 連帯責任！

## コードとテスト
### @kobatomo
- テストコードがドキュメントになる様をこの前見た。
- Doxygenとか使って、コードからどうドキュメントを作るかを昔は考えたなぁー。社内ルールに適合するため。
- ウォーターフォールと比較しているように捉えた。

### @got
- ここで言われている「テスト」は「テストコード」？それとも「仕様書」も含んだもの？
- テストコードのこと。

- 管理されてないコードのテストはどうすれば？
- まずコードを管理する。で、テストも残す。かな？
- レガシーコード改善ガイドに書かれてる。
-
### @kkd
> これから何をするのか、何をしないのか、どのようにやるのか

やらないことを決めるの大事だなー。（でも何度も出てくることも）

### @ueda
> コードとテストだけを永続的な作成物として保守すること
- テストも永続的に。なるほど。
> その他のドキュメントは、コードとテストから生成すること
- この部分、どうすれば...?

### @matamiya
-　儀式はバリューの流れを遅らせるって？
-バリュー：①価値観、②製品の価値←今回はこれ
-儀式：組織のルール、しきたり

##

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

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

## ふりかえり
- @got
- 毎回読む本が増えてる！大事なのだろうなぁ〜。
- @ueda
- 後半読み込めてなかった。ちゃんと読まないとナー。新しく参加されてよかった！
- @matamiya
- @kobatomoから「精神修行だから」と言われてた。なるほどな、ということもたくさんあった。
- もうちょっと読み込んで疑問点を書くようにしよう！
- @kkd
- いろいろきづかされました！

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

- 対象　
- ９章「単一のコードベース」〜１０章最初まで
-
### 役割分担

- 司会
- @ueda
- connpass
- @got
- wiki
- @kkd
- hackmd
- @got

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

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