http://xpjug.com/xp2016/
日時：2016-09-24（土）
会場：早稲田大学理工学部キャンパス(東京都新宿区大久保3丁目4-1)
主催：日本XPユーザグループ、早稲田大学グローバルソフトウェアエンジニアリング研究所
togetterまとめ：http://togetter.com/li/1028069

参加したのは以下の４つです。

基調講演
TDDハンズオン
作ってみよう！ジャーニーマップ
LT大会

基調講演

MS牛尾さんの講演。ソフトウェア開発について、日本がアメリカから５～８年遅れてるといわれるので観察してきた話。

USの開発チームの特徴

・PGが集中できる環境に投資。
・VSTSのチームでもVS使ってるのは一人だけだったｗ他は好きなエディタ使ってる。
・机はすべてキャスターがついててペアプロがすぐできる。
・F-TeamとL-Team
　→Fが新機能開発専門、Lが保守専門。Fは極力集中、メールも見なくていい。常にペアプロ。
　→どう考えてもLチーム嫌でしょ。だから定期的にメンバー交換。
　→Fは常にペアプロなので、メンバーが抜けても問題が起こらない。
・生産性の鍵は集中。
　→ DevOps的にはカンバンとテレメトリ
　　　→ 驚いたのは、ほとんど知っている事で構成されていた事。それでも生産性めっちゃ高い。　
　　　→ プラクティスを愚直にやってた。自分はいらないと思っていたルームレイアウトとかもやってた。
　　　→ 上司がアジャイルやDevOpsを正確に理解しているのも特徴。

ところでXP祭りなのでDevOpsとXPの話

・DevOps＝改善活動。自動化は重要だけど、自動化＝DevOpsではない。
・ツール入れないとできないDevOpsなんかない。
・テクノロジーが悪いのではなく、「生かすためのマインドセットとプロセスが揃わないといけない」。
・DevOpsのいろいろの基礎にXPがある。

・所でスクラムはエンジニアリングプラクティスが欠落してないか？と言われるけれど、
　→ エンジニアリングプラクティスを軽視したのではなく、スクラムを作るときに明示しなかっただけらしい。
　→ エンジニアリングのマインドセットを学ぶならXPの方がおすすめ。

日本がアメリカに追いつくには、文化を理解してマインドセットを見直さないといけない

・世界の標準でアジャイルの導入率8割。日本は全世界で断トツで導入難易度が高い。
・生産性の差が米日で10:6ある。
・日本は文化的な背景でうまく導入できない。
　　→ 西洋文化が根っこにあってできたプロセスだから、西洋文化を学んで、その上でやればいいんじゃないかと考えてる。

文化チェンジのおすすめ項目

１：生産性マインド

・予定がうまく終わらなかったら？
　→ 日米で単純に物量が違う（やることが少ない。少ない作業でどれだけ多くの価値を出すかを考えてる）
　→ Be Lazy（ドイツのことわざ。より少ない時間で成果を最大化する）。
　　→ 大事なことは何か。どれを捨てるべきかを考える。

・日米で「バックログに優先順位をつけて、通戦順位の高いものに集中する」と聞いて思い浮かべることが違う
　→ JP:上から順に全部やる。
　→ US:一番重要なものだけやる。
　　→ 重要な一個だけやったら、集中できたのでクオリティが上がった。
　　→ やらなかったことについては、やらなくても何も起こらなかった。

・日本で一人だけでやったら針のムシロだけど、チームでやったら気にならなくなる。
　

２：主体性マインド

・ありがちな質問「請負なのでアジャイルできない」「会社のルールがWF」
　→ そもそもインターナショナル環境は働きやすい
　　　→ ダイバーシティとか言うけど日本のは何か違う。
　　　　→ 日本だと、障碍者とか女性を受け入れてやらぁ、な態度
　　　　→ ワールドワイドだと常識が違うのは前提なので、自分のままでいられる。常識を盾に変わる事を要求されない。

・大人の概念の違い
　→ JP：我慢する人
　→ US：自分が幸せになることに責任を持つ人
　→ 自分の幸せ大事 → 相手の幸せを尊重 → 相手との違いはあるのが前提
　　　　　　　　　　　　　　↓
　　　　　　　　　　・相手の考えを尊重　
　　　　　　　　　　・相手に何かを求めない
　　　　　　　　　　　→ なので貢献しなくても怒られない
　　　　　　　　　　　　　→ 逆に貢献すると喜ばれる

・日本は失敗を防ぐマインド
　→ USは失敗が当然のマインド。失敗したら知見をありがとうと言われる。

・日本で、自分の思うところを素直に言うと炎上するようになった
　→ 相手の持ってる「あるべき」との比較で炎上したり賛同されたりする。
　　→ なのでブログ書いたら放置してます。わざわざ傷つく必要ないよね。
　　　→ USは違う意見はスルー。意見を言いたいなら自分でブログを書く。
　　　　→ でも書く時間を使ってるのは貢献。
・以上、こういう考え方をしてるという事を理解してからとりかかると、もう少しわかりやすくなる。

３：雇用形態マインド

・ありがちな質問「アジャイルをできるほど優秀な人がいない」
　→ JP:雇われにくく雇われにくい
　→ US：首になりやすいけど雇われやすい。
　　→ プロが育つ
　　→ ポジションと役割がなくなったら優秀でも首。その代り勉強してればすぐ雇われる。
　　→ USは従業員満足度が高い
　　　→ すぐ雇用されるので、満足度を高くしないと人を引き留められない。
　　→ US:条件に閉じており、機会に開いている
　　　→ 条件に情の余地はない。その代り何度でもいつでも挑戦できる。
　　　→ KPIが、目標というよりは最低限のハードルみたいな印象？　

・従業員のエンゲージメントレベル（満足度）は日本と世界で逆転。
　→ 一番いいのは法律を変えること。チーム内でもいいし最悪海外に出てもいい。

・じゃぁ日本人の良さは？
　→ 物事の進め方、高い品質
　→ 人への接し方、客への接し方
　→ チームワークとグループへの貢献
　→ イノベーティブ（ちょうどイグノーベル賞でも同じ様なコメントありましたね）
　→ 美的感覚
　　→ これらを、生産性や３つのマインドセットが壊してる。

まとめ

USがいい、ではなく、彼らのよいところを学ぼう。
変えるべきはプラクティスではなく日本文化の方。
というわけでブログ書きました。
http://simplearchitect.hatenablog.com/entry/2016/09/24/113117

TDDハンズオン

PHPUnitを使って実際にTDDをやってみようというセミナー。
ただ、PHPでやるという事を見落としてて準備していかなかったので、聞いてるだけになっちゃいました。
環境作る努力はしたんだ…CentOS6.5の標準リポジトリのPHPが、PHPUnitを使えるバージョンに達してないのが悪いんや…。

以下は説明やFAQのメモ。

・TDDは開発者がチェックするためのテスト。つまりデバッグ行為（＋設計も）に近い。品質保証のため。ではない。
・テストケース１件に含まれるアサートは１つににした方がよい。その方がデバッグしやすい。
・いったん動作させるの大事
・切りのいいところで小さくコミットを繰り返す。大規模なリファクタの前にコミットしておくとよい。
・テストをある程度抽象化しておくと区切りやすい。
・作成途中で、テストをマージしたりリファクタしたりしてもよい。
・実際どの単位でテストを書いてわざと失敗させるかは慣れの問題が大きいが、最初はテストツールへの慣れなどもあるので、細かい単位でやった方がよい。
・テストを先に書くことで仕様の（特に異常系）をどうするかを考えるようになる。

まとめ

TDDは品質向上のためのテストではない。品質を向上させるのは設計、実装をする人。
講師さんのblog：http://hamuhamu.hatenablog.jp/entry/2016/09/25/133330
使った題材：https://github.com/hamuhamu/tdd_hands-on

作ってみよう、ジャーニーマップ　

公開資料：http://xpjug.com/xp2016-session-g6/

ジャーニーマップって？

・ペルソナが時間軸に沿って動いた跡がジャーニーマップ
・やり方はいろいろある。名前もいろいろ。大体同じ物を違う名前で呼んでる。
・Alignment Diagramという一段上の概念をジェームズ・カルバックが提唱してる。

JM(JourneyMap)解剖学

・JMとはつまり表です。
・横軸は時間。ステップとか起承転結みたいなもの。３～１０段階。
・縦軸は項目・そのステージで行うaction。
　→ 一段目にアクションを書く。
　→ 二段目以降は全部オプション。人ややり方によっていろいろある。
　　→ 思考、感情、ゲイン、ペイン、タッチポイント、真実の瞬間、発言の引用、定量データなど

ハンズオン

・3人一組。一人ペルソナ役になって、ある程度繰り返し行っている事柄についてのJMを作りました。
・今回は、「海外旅行を計画して帰ってくるまで」というテーマで作成。
・ざっくり手順
　　①ペルソナと設定する。
　　②JMのテーマを決める。
　　③テーマが何ステップあるか検討する（横軸の長さになる）
　　④各ステップ毎に、具体的なアクション（やること）を書き出す。
　　⑤ステップやアクションに対して、その時考えている事を書き出す
　　⑥ステップやアクションに対して、嬉しい/悲しいとなるのはどういう時かを書き出す。
　　⑦縦軸で（つまり時間毎に）内容を確認。
　　⑧最後に、気分の浮き沈みをグラフ化する。

まとめ

・ジャーニーマップ＝時系列で変化を記述したもの
・何の役に立つのか。
　・ASISを把握して、tobeをデザインするのに役立つ。
　・JMは指さしでここで、とやれるのが強み。つまりタンジブル。
　・JMの元になるのはペルソナ。
　　　→ そこからジャーニーマップを作りバリュープロモーションキャンバスができる。
　　　→ VPCからユーザーストーリーマップを作る。

・オライリーからMappingExperienceという本が出てる。
・ただし、今のところ和書がない。
参考：http://ecbible.net/contents-marketing/customer-journey

LT大会

途中でPCのバッテリー切れました。後ろの方はメモ取れてません…。

藤沢さん：価値と原則と失敗談を交えて抱負を語りたい。

一人カンバンモドキとかやってみた。意外と評判よかった。でも何も変わらなかった？
→ プラクティスの前に価値と原則があるんじゃないか
価値：汎用的だが抽象的なので実践できない。
原則：価値とプラクティスの橋渡し
目的に合ったプラクティスが見つからないときは、元になってる価値や原則に立ち返るといいかも。

松井さん：アジャイルプラクティスを広めたい。ので、一実践の紹介

学生時代に足りなかったもの＝振り返る週間
　→ 教授「PDCAを意識しろ」=>PDCAは概念。実践はKPT。
　　　なので、研究室訪問についてのKPTをやった。Actでもionまで落とし
　　　→ 学生でも結構やれた。
リクルータKPTの実践を検討してみてください。

木下さん：永和システム事業部長さん

事業計画をCCで公開してるけど、そこにコミュニティを書いてる。
XPにもコミュニティの話あるよ。
単なる勉強会とか仲良しクラブじゃなく、町内会という感覚。
目付役も見守ってくれる人も同志もいる。
コミュニティ重要：感謝。

及部さん：こんなアジャイルは嫌だ

https://speakerdeck.com/takaking22/konnaaziyairuhaiyada-number-xpjug
アジャイル普及したので一歩離れたところで見つめなおしてきた
スプリントの終わりまで問題ありません。→何の成果も（略
終わらなかったスプリントを伸ばして対応する
スプリント計画は総工数をスプリントで割った。
認定プログラマなので信じてください。
俯瞰してみてアジャイルが嫌いな人が、嫌う理由がわかった。
　→ 失敗を壁にしている人の問題。
　→ アジャイル老害になってませんか？

中川さん：PyCon JP2016レポート

Python割となんでもできる（rubyに負けてないよ。
pyConでGxPの鈴木さんがマイクロサービスの話してたよ

小林さん:永和システムは本当にエクストリームか？

ペアプロやってない
テストファーストでもあまりないかも。
デイリーは微妙だけどウィークリーならやってる。

天野さん：俺たちの老害

kptaの紹介
tryは試したいこと、AcTIONを実行したいこと
けぷたclub
KPTAやると結婚できるらしいぞ

むりょういさん：xpの読書会をやりました。

2章から読んで最後に1章。
メンバーは柱
難しいけど頑張って読んで。

クロージング

「Android開発の教科書」という本頂きました。ありがとうございます！

まとめ

私個人の感想です。

基調講演

日米で生産性に格差があるのは事実だし、その差を埋めるために文化を学ぶのはいいのだけど、ちょっといい面だけ取り上げ過ぎな感も。例えばリーマンの直後とか、米の失業率かなり悪かったと思うんだけど、本当にすぐ再雇用されたの？みたいな。
一方で、日本も終身雇用がエンジニアのスキルを上げたとか言われてたとも思うし。
ただやっぱり、この話を一番聞くべきは、ここに来てない管理職だよねとTwitterで言われてたり、日本の管理職は技術の勉強してない（牛尾さん曰く、米のリーダーはXPを正確に理解してるとも）などの面、改善するべきですよねぇ・・・。

野良LT

昼休みに野良LTでKPTAとKPTATAHの話を聞いた。面白そうなのでやってみようと思う。
http://www.slideshare.net/samuraiRed/xp2016ltkptkptakptatah

TDD

とにもかくにも、準備不足。
話としては過去に聞いた事のある内容が多かったので、後は慣れるまで愚直にやる、というハードルを越えればできそう（飽きっぽい）。
ただ個人的には、I/Fの設計ってクラス図or(C++の）ヘッダファイル書くときにやってた感があるので、設計のためのTDDってピンとこない面がまだある（デバッグのための、は理解できる）。エラーケースのバリエーションとかのエラーの返し方のルールとか、ヘッダに定義書く段階でチェックするものでしょ、と。

ジャーニーマップを作ろう

恥ずかしながら参加するまでユーザーストーリーマップとジャーニーマップの区別がついてませんでした。
今回は本当に基礎というか、こういうものですよ感が強かった（題材にもよるけど）ので、仕事で使うには実践して経験値稼がないとうまく回らなそう。

LT大会

XP祭りといえばこれ。SlideShareで公開されてるものとかあると思うんですが、全部探せませんでした・・・