# Agile459読書会(2018/04/11)

## 近況
### @ueda
- 納品後にCSSまわりについてふりかえりをしていて、BEMという書き方を知りました。
> [一番詳しいCSS設計規則BEMのマニュアル](https://qiita.com/Takuan_Oishii/items/0f0d2c5dc33a9b2d9cb1)
- せっかくoasis買ったのに、物理的に本が積み上がっている。
- D3jsは、勉強中。バーンダウンチャートもこれで書いています。

### @kobatomo
- 今日は、入園式でしたー。案の定、親と離れると泣いていた息子。たくましくなれよー思う親心。
- 今回の役割、今回の目標が追加されていて助かるー。(Keep)

### @kkd
- 今週土曜の100kmマラソンの準備で大わらわ
- ちょっとだけブロックチェーン勉強した。
- アジャイルを普通の人に説明する時の説明文を考え中

### @got
- 日曜日に親と子供を連れて日帰り松山旅行！
- 松山城にのぼって、道後温泉に入ってきただけだったけど、すごく楽しかった！そして疲れた・・・

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

## 今回の目標
- 対象　10章 経営幹部 〜 第11章
- [] 1テーマ 10分程度を目安に進めますね。
1. 19:30 - 19:35 アイスブレイク(近況)
1. 19:35 - 19:45 10章 経営幹部
1. 19:45 - 19:55 10章 テクニカルライター
1. 19:55 - 20:05 10章 ユーザー
1. 20:05 - 20:15 10章 プログラマー
1. 20:15 - 20:25 10章 人事
1. 20:25 - 20:35 10章 役割
1. 20:35 - 20:45 11章 制約理論
1. 20:45 - 20:55 振り返り
1. 20:55 - 21:00 次回役割

# 10章 XPチーム全体

## 経営幹部
### @ueda
> チームの健全性を計測する2つのメトリクス
> 開発後に発見された欠陥数
> アイディアに投資してから収益が生まれるまでのタイムラグ
- 経営幹部というよりは管理職的な立ち位置？

### @kobatomo
- 経営幹部がXPを推奨してくれるなんて最高の職場ですね。そんな会社を目指す。

### @got
> 数字の「ゲーム」に挑戦しても数字以外は何も改善されない。
- すごく刺さる。考えさせられる言葉。
目的を見失わないこと。
> チームが新機能をこまめにデプロイし始めたら、バリューの流れのボトルネックは組織の別なところに移動するだろう。
> 経営幹部は、この移動がポジティブなものであるとあらかじめ会社に認識しさせておく必要がある。
- 「あらかじめ」がないと問題になるんだろうな・・・

### @kkd
- 投資回収時期の話大事だなぁ
- キャッシュにするまでのリードタイムが重要→出す→ニーズに合わす→リンスタも同じだなぁ
- 経営者に技術的負債を理解してもらうのが大変かもしれない
- バグを放置・レガシーコード→開発速度が遅くなる→テストにかかる時間が増える→開発に割ける時間がなくなる→変化に適応できない→死亡
- 短期視点（その場限りの速度）と長期視点（持続可能な開発速度）のバランス
- 国内では、2007年頃までは、アジャイルは開発サイドからのアプローチだったが、2008年以降にビジネスサイド（顧客）から求められることが増えた印象
- 一度失敗しないとわからないかもなぁ。。。
- XPチームは、会話をしながら仕事をする。>> これは大事。

## テクニカルライター
### @ueda
- かつて、立ち上げたばかりの取説専門の部署で仕事をしたのを思い出した。
- 半年のサイクルで製品をリリース。今思えばすごいスピードだったなぁ。
- 前職で外部委託する際の仕様書作成。外注さんから好評だったことも。（他が丸投げすぎて...

### @kobatomo
- ユーザーが必要と思うドキュメントは、できるだけ早めにリリースしているなぁー。
> ユーザーがドキュメントを見ていなければ、その部分を書くのはやめよう。
- ごもっとも。外部に公開していない場合、見ているか見ていないかは、聞くしかないかな。聞けていない。。
- ドキュメントのフィードバックはもらってない、ことに気がついた！

### @got
- あったら良いと思う役割。
- ~~けど、あえてテクニカルライターという役割を持たせた理由ってなんだろう？~~
- ~~ドキュメントを含んだプロダクトを、XPの柔軟性（終盤になっても変更を受け入れる）と速度（週次リリース）からどうやって生み出せば良いか？を考えた末の案（苦肉の策）なのかな？~~
- ~~すべてのドキュメントがソフトウェアから自動的に生み出せればいいけど、対ユーザ、対顧客を考えたときにはそういうわけにはいかないのだろう。~~
- 書いてある中身が「テクニカルライターとしての役割」ではなく「テクニカルパブリケーションのスキル」だ。

### @kkd
- ライターさんに頼みたいと思うことは多々あった
- サイト、マニュアル、リーフレット、ブログ、xxx、etc
- 今だと、SNS投稿とか、ブログ発信とかもあるよね。
- 全部自分でやってたら大変だし、わかりにくい文書になる
- でもまず自分で書いて伝えようとするのは大事
- チーム内のドキュメントはWikiとかで共有しながら書くのがいいね
- オフィス文書使ってるなぁ(@kobatomo)
- そういうもんだと思ってるのだろうね(@kkd)
> ドキュメントの利用状況も追跡してもらおう
- グロースハックみたいなことかいてあるなぁ。さすが！！
- 基本的に「マニュアルが必要なのは使いにくい証拠」という姿勢は持っておきたい
> XPの哲学とは、現状から始めて理想に向かって進むことだ。現状からでも少しでも改善できるだろうか？
- この考え凄い好きなんだけど、理想が見えてない人もいるよね。

## ユーザー
### @ueda
- ここでいうユーザーとは「ユーザー」というロール（役割）のことかな？
> ユーザーコミュニティーとの強い関係性を持っていたり...
- 実際に使う人たちと繋がってないといけない。なるほど。

### @kobatomo
- 自分のチームだと、顧客だね。顧客がプロダクトオーナーも担っている。

### @got
> ユーザーはコミュニティーの代表者であることを忘れないようにしよう。
- 顧客の先に「ユーザ」がいるのではなく、「コミュニティー」がいる。
ユーザーのさらに向こう側。広いわー。
> チームには、その間に他のストーリーに取り組んでおいてもらおう。
- 進められることはどんどん進める。
- ストーリーの切り方

### @kkd
- システムをほしい・使う人？
- 利用者（使う人）と顧客（お金を払う人）は分かれることもあるね
- 受託の場合のユーザーと、サービス開発のときのユーザーはまた別だね
- Tech系のコミュニティは、ベンダー主導でやってるよね。ビジネスの一貫として。
- 利用者の早期からの巻き込みは大事だよねぇ
　　 - 時代は、流れているよー。昔：今：目的は変化する。

## プログラマー
### @ueda
> プログラマーは社交性や人間関係のスキルを...
- 勉強会など外部のコミュニティに参加する機会が増えてはいるものの、
- 日々の業務に追われて、外部との接点が少ないエンジニアも多いのでは？
- と言いつつ、人間関係は難しい

### @kobatomo
- はい。私はプログラマーです。

### @kkd
- プログラマーはコード書いてるだけじゃないんだよね。
- プログラマーなのか、ソフトウェアエンジニアなのか、スタンス違いそう

### @got
- 「技術スキル」と「社交性や人間関係のスキル」がまだまだ足らない。
- 足らないと思うのが、素晴らしいと思います！(@kkd)

## 人事
### @ueda
- XPの透明性が人事評価につながるのかぁ。なるほど。
- というか、評価する人がXPのチームと一緒に働くことが面接につながると。
- 優秀なチームワークに対してインセンティブを与える。（ムムッ

### @kobatomo
- 約束を守ってこそ。信頼が生まれるもんねー。
- あー。ペアプログラミングするという話をすると工数が倍かかるーという話になる。
- やったことない人には、利点を説明するのもむずかしい。
- 上司がペアプログラミングをやったことがないのに、ペアプログラミングを進めてもよくわからないよねー。
- 人事って？？

### @kkd
- 人事評価（個人）とチーム評価のギャップはよく言われる話
- 評価制度やめたって話も聞きますね。皆平等。
- チームのメンバーがお互いに評価するといいのかも
- 「あいつはできるから、高くてもいい」とか。
> ペアプロで試験する
- いいね！
- 孤独で凄腕プログラマーもうまく使いたい！！

### @got
> XP適用前の評価の仕方を大きく変える必要はない
- そもそもの評価の仕方に問題を抱えている場合は問題外・・・
> 優秀なチームワーク
- チームワークの評価ってなんだろう？
- 360度評価とか？
- 評価は、なんであるのだろう？
　　 - 一人一人の評価は、大変。
　　 - 当たり前のことに問いを出すことも大事。

## 役割
### @ueda
- 最初は役割を固定。役割の習慣が身につけば他の役割を担う。そしてチームに貢献。

### @kobatomo
> チームメンバーがチームに最善を尽くして貢献することが大事。
- まぁ、そうだよね。
- ここの内容は、自分の環境と違うため、理解に苦しむ。
- 何が、チームに最善かはやっぱり考える。自分だと特に結合フェーズ(I/F)かなぁ。
- 自分と他人が作ったものと結合評価する際に、まずは自分は最善を尽くした。
- ポカミスはないぜーという状態で評価している（まぁ、見つかることもあるが。。。数は少なめ）。
- くだらないポカミスで何度も評価を繰り返すと、効率が悪く。モチベーションも上がらない。
- 相手のことを思って開発することが大事。あとは、相手が忙しいときは、ジョブチェンジしたりするよねー。
- リスペクトするということかなぁー。
- たくさんの役割があって、WaiWai開発したいねー。
- チームにユーザーも入っているので自分は、ユーザーのために開発していくなー。

### @got
> チームメンバーが相互にリスペクトした新しい人間関係を築くことができれば
- 第4章 価値を今更ながら見返す。
> 単純に1人が一つの役割を担うとは限らない。
- 組み合わせ注意な役割ってあるのだろうか？
- 別な流れではあるけれど、そこらへんのベストプラクティス（パターンというべき？）がSCRUMとしてまとまった？
> チームが成熟しても、権限と責任のバランスを保つことを忘れない
- チームの成熟に方向（正誤）がある？
- 権限と責任のバランスが崩れた成熟されたチームって？
> 「その懸念」を「行動」で「裏付けられる」ように～
- ？

### @kkd
- ロール（役割）は御札のようなものかなぁ
- 得意なことは活かしたいよね
- でも他もできることあるよね、必要なことは。
- ロールで境界引きすぎるとチームが分断される。
- 役割の重なり合いに価値がある（エッジ効果）

# 11章 制約理論
### @got
> あまり効果がないことでおなじみのウォーターフォール型の開発スタイル
- ですよね。
> XPは「プッシュ」モデルではなく「プル」モデル
- 急に出てきたモデルの話。これまでこんなイメージの説明ってなかったような・・・
> 制約理論の弱点
- 理論だとか方法だとかだけが語られると、同じ流れになりそう。
- なのでもう一度、ザ・ゴールを見る。（疲れるけど）
> 経営幹部の支援やチーム外の人たちとの強い人間関係はXPの適用には不可欠
- 第10章 役割 経営幹部でもで出た内容。
- 「10年前だから」ここまで強調されていたのだと思いたい。

### @kobatomo
> 制約理論では、あらゆるシステムに同時に一つの制約が存在すると考える。
> システムの制約は、仕掛かり品が山積みになったところ。
> 制約を排除すれば、また別の制約が作り出される
- はい。その通りと思います。
> 処理する要件、実装する設計、統合してテストするコードを山積みにしてビックバンのインテグレーションを行う。
- ウォーターフォールしか知らない時代は、ソフトウェア開発はこうするものと考えていたなー。
> その間残りのストーリーは、実装の対象に選ばれるまで壁に
> 貼り付けておく。
- スループットをあげることを目的にWIP制限をタスクボードにつけた時から、一度にたくさんのフューチャーを作っていくことをやめた。
- リリースの回数を多くしていくことを続けた。
> 経営幹部の支援がない場合は、たとえ評価や保護が得られなくても、自分自身でよりよい仕事をする覚悟を持たなければならない。
- 自分の仕事の仕方を変えたくてAgile, XPの本を手にとり、展示会、コミュニティーに参加して実践者の話を聞く。聞いたことを自分の現場で実践していく。２０１２のキックオフ当初を思い出した。
- 覚悟は、すでにあるのでは？経営幹部の評価は必要か？

### @kkd
- ボトルネックの移動は常に意識しておいたほうがいい。チームの外側に移動すると気づかないこともあるかも。
- 自分のチームはいい感じ。でも他でいろいろ時間かかってる、とか。
- バリューストリームマッピング(VSM)はボトルネックを見つけるのに便利
- 「全体」とは何を指すのかは、意識合わせしておいたほうがいい。人によって見えてる範囲が違う。
- VSMは役に立つよ
- アジャイルのTOCの応用についての本はこちら
- https://amzn.to/2qns0ll

### @ueda
- XPを適用することでスループットが上がると、その外側（マーケティング、営業、マネジメント）がボトルネックになる。
- 開発チームはXPによって開発プロセスが常に改善されていく。その外側にある組織自体も変わっていく必要がある。

## ふりかえり
- @kkd
- 細かく区切ってTimebox意識するのはいいね
- もう少し大きい単位でTimeboxでやると、もっと進むかな？
- 今後は章単位でtimeboxingかな？
- @got
- 11章をもう一度みてみるよ！
- 目標の明確化が良かった！
- @ueda
- 勉強するキーワードが出たので深掘りする。
- 体調がすぐれず失礼しました。
- 制約理論読めてませんでした。後日読んでコメントを入れておきます。
- @kobatomo
- 10Pのベロシティー。
- わいわい開発するぞー

## 次回
2018/4/25 (水) 19:30 - 21:00

- 対象：12章-13章

### 役割分担
- 司会：@got
- connpass：@kobatomo
- connpassグループ通知
- グループ → グループにメッセージを送る
- wiki：@ueda
- hackmd：@kkd

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