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

## 近況
### @ueda
- 2012年10月にサムライ本読書会の予習でXP本に触れていた
[ユーザーストーリー – 明日の予習](https://www.netplan.co.jp/archives/2142)
- AWS Lambdaのデプロイをshellで自動化してみた。

### @kobatomo
- TDDBCをメインで進める。嫁と都合がバッティングしている。5/19は調整中なり。
- 会社のパソコンをNewマシーンに変更。デスクトップを購入した。
- 昨日リリースした。自信を持って顧客に価値を提供するサイクルができていることが、良い感じ。TDDに感謝。
- すばらしい！！domodomo

### @kkd
- 3月は出張が多くて疲れた。4月はレース出張が始まるｗ
- IKIGAI(いきがい)についてのワークショップをはじめている。今度愛媛でもやる予定。香川でもやる？
- https://www.slideshare.net/kkd/ikigai-quest
- 香川場所を抑えるのでお願いしたいです。
- 人にとって適正なテクノロジーというのをずっと考えている
- いらないんじゃない？そんなの...

### @got
- 軽微な改修の結果確認を、今は死んでる Selenium Builder を使用してテストしてみた。
- bravo!!

# 10章 XPチーム全体

## テスター
### @ueda
> テスターの役割は開発の初期段階に移行している
- という認識がなかった。
> 「ログインが３回失敗すると...何が起きれば良いでしょうか」
- テスターがコミュニケーションを増幅する役割。
- とはいえ、必ずしも正解でもないというリスク。
- プログラマとペアになって問題解決を支援というのは良いですね。

### @got
- 工程の最後に出てくるような品質管理部門とは違うなぁ。
テスト担当者（作業者）でもない。
- テスト作業員ではない
-
> 機能が実装し終わる前に、システムの受け入れ可能な機能を構成する要素の定義や仕様化を支援する
- 実装の前にテストがあるというのはやっぱり大きい。
- そんなテストを作り出せる「強力なテストスキル」もあったら良い。
> 「ハッピーパス」を視野に入れながら、そこから外れたときに何が起きるかを質問するのが得意である
- 要件を持ち帰って、検討して、フローを書いて、やっと「これ考えないとやばくない？」にたどり着くことが多い。
聞いてるその場のコミュニケーションとして聞けたら幸せになると思う。
- ハッピーパス： 正常系

### @kobatomo
- 異常系を考えるときは、誰かと話しながらやっているなぁー。誰かと話すとそういう視点もあったかと気づくこともあるよね。確かにコミュニケーションが増幅するな
- 第３者的に誰かいてくれたら...
-
### @kkd
- チームにテスターがいると、最初にいろいろテストケースを考えられるので、後戻りが少ない
- 以前面倒見たチームで最初からテスターがいてよかった経験があった。
- テスターは部署（品質管理部門）が違うので、開発チームの外側での調整が大変だった
- テスターをチームで抱えることの障害は組織的なものになる
- 自分はテストしかできません、と言われると辛い

## インタラクションデザイナー
### @ueda
> システム全体のメタファー
- 実在する物に例えること？ ファイアウォールとか？
- 検索してみたら「エリック・エヴァンスのドメイン駆動設計」でXP本が引用されていた
- 「About Face 3 インタラクションデザインの極意」という書籍を見つけた

### @got
- 「ペルソナ」って単語はここ数年のUI/UXの話で出てきたのかと思ったら、もっともっと前だった。
> デプロイされたシステムの利用状況を評価して、新しいストーリーの機会を見つけたりする。
- もちろんこの役割だけではないけれど、「チームが顧客を支援する」感覚が、すごくいい。
- デザイナーさんが評価して、UIを洗練していく

### @kkd
- UXデザイナー＆グロースハッカーのことかなぁ？今だと
- もう少し役割が分かれてないイメージ
- システムのメタファは、XPの初版にはプラクティスでした。
- https://www.slideshare.net/kkd/metaphors-we-develop-a-software-by-7661294
- https://www.slideshare.net/kkd/metaphor-we-design-by

## アーキテクト
### @ueda
> システムの成長に合わせてアーキテクチャを追従させる
- なかなか大変な（知識、経験を要する）仕事ですね。
- システムの分割（比較的独立した単位に分割して、システムを拡張）というのも気になる

### @got
- インフラ部隊という意味ではなさそう。
> 小さなシステムのアーキテクチャは、大きなシステムのアーキテクチャと同じであってはいけない。
- 「ハンマーを持つとすべてが釘に見える」というたとえ話もあるので、とても身の引き締まる言葉。
> グループが小さなセクションに集中しているときに～
- モノを作っている最中は集中しすぎてしまう傾向があるので、全体俯瞰した視点で支援してくれると助かる。
（俯瞰した視点を忘れるなという話か・・・）

### @kobatomo
> XPチームは、統治分割を行う。分割統治ではない。
- わかるようなわからないような。
- 最初から分割して開発しない、最初は皆で動くものを作ってから、後で徐々に分割して開発する方向にうつるってことかな。(@kkd)

### @kkd
- ここで言うのは、プログラミングもするアーキテクトだねー。
- 「アーキテクトも他のプログラマーと同じようにプログラミングのタスクにサインアップする」
- Evolutionary Architecture（進化的アーキテクチャ）をできる人のことかなー
- https://www.thoughtworks.com/books/building-evolutionary-architectures

## プロジェクトマネージャー
### @ueda
> チームへ向かうコミュニケーションを円滑に
- I've never seen a PM like that. So I'm trying to be a good one.
> ベストなチームは週の作業をわずか1時間で計画。
- 経験してみたい...
- 以下、PM関連ツイートが流れていたのでピックアップ
[...実は足りていないのはディレクターだったりPMだったり...](https://twitter.com/hisaju01/status/973336062813597696)
[...「優秀な人」なんてまずやって来ない。...](https://twitter.com/ohtsuka/status/974150092520177664)

### @got
- 「プロジェクト『リーダー』」ではないのは、プロジェクトを円滑に進めるためには「顧客、スポンサー、サプライヤー、ユーザ」と「チーム」の間に層（壁じゃないよ）が必要（推奨？）ってこと？
> XPの計画づくりは活動であり、フェーズではない。
- ここで否定されている「フェーズ」の計画って、ウォーターフォールのような段階的に時期を決められてしまった計画を指している？
> 効果的なファシリテーターになるほうが、得られる力は大きい。
- やっぱりファシリテート力は大事・・・
- 難しいのは「効果的」

### @kobatomo
- チームのメンバが増えればこそ、必要な立ち位置。チーム内の一体感や信頼関係を築くコミュニケーションとは？
　 - おやつ神社を設置。> いい
　 - 感謝の言葉を伝える。
　 - コーヒースペースに遠慮なく行く。
　 - 心理的安全を作る（https://bizhint.jp/keyword/101187）
　 - 雑談いいよ。テーマ決めずに。

### @kkd
- PMっているのかなぁ？ Scrumだとスクラムマスターだと思う
> XPの計画づくりは活動であり、フェーズではない。
- そうだよねー。プランニング・計画づくりって言葉が、その意味。
- 昔プレッシャーかけるPMやってしまったことがある。。。（アジャイルに出会う前）
- チームの一体感を作るのでなく、単に皆のお伺い役のPMもいたなぁ。

## プロダクトマネージャー
### @ueda
> チームがオーバーコミットしていたら...
- 理解しました。抱えすぎなんですね。だから優先順位をつけて支援。
- 本物の顧客参加は仕掛かり中...（ヒアリングまででその先に進みそうにない
- ヒアリングまでできた。

### @got
- マネージャが二人連なってる！と思ったら、こっちは「『プロダクト』マネージャ」。
> プロダクトマネージャは、顧客とプログラマーのコミュニケーションを促進する。
- プロダクトマネージャが指示する側で、プロジェクトリーダーやチームが支持を受ける側、と捉えるとプロダクトマネージャが「顧客」に思えた。
けど、プロダクトマネージャよりもその先に「顧客」がいる。
- Scrumのプロダクトオーナー（PO）のイメージ？

### @kkd
- スクラムだとPOのことかな？
- ストーリーをうまく書いていくのが大事だね。
- 落とし所をつけるストーリーを書けるかどうか。ストーリー分割のテクニック。
- プロダクトに責任を持つ。ストーリーを書く。

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

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

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

### @kkd
- 経営者に技術的負債を理解してもらうのが大変かもしれない
- バグを放置・レガシーコード→開発速度が遅くなる→テストにかかる時間が増える→開発に割ける時間がなくなる→変化に適応できない→死亡
- 短期視点（その場限りの速度）と長期視点（持続可能な開発速度）のバランス

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

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

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

### @kkd
- ライターさんに頼みたいと思うことは多々ある。
- 全部自分でやってたら大変だし、わかりにくい文書になる
- グロースハックみたいなことかいてあるなぁ。さすが！！

## ユーザー
### @ueda
- ここでいうユーザーとは

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

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

### @kkd
- システムをほしい・使う人？

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

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

### @kkd
- プログラマーはコード書いてるだけじゃないんだよね。

## 人事
### @ueda
- XPの透明性が人事評価につながるのかぁ。なるほど。
- 優秀なチームワークに対してインセンティブを与える。（ムムッ

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

### @kkd
- 人事評価（個人）とチーム評価のギャップはよく言われる話
- 評価制度やめたって話も聞きますね。皆平等。
-

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

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

## ふりかえり
- XPって凄いなぁ。役割は今でも通用する内容だった。(@kkd)
- ～というメンバ（人）ではなくて@kkdが言った「ロール（役割）」だということが分かった。(@got)
- アーキテクトがプログラミングのタスクにサインアップするように、横のロールにも対応できることがポイント。(@ueda)
- いろんな視点で仕事をするっていうのが大事なんだろうなぁ。自分にとって優先度の高い役割をチョイスしよう(@kobatomo)@@
- 昔やってたプラクティス一覧。お暇なら見てよね。(@kkd)
- https://www.slideshare.net/kkd/the-collection-of-practice-in-our-team-2006-version

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

- 対象　経営幹部 〜 第11章

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

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

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