2017/06/24（土）車で1時間半かけてついてみたら駐車場が満車。
土地勘がなくて他に探すあてもなく、基調講演の動画はどこかに登録されているだろうと、待っていたら30分過ぎてた。
（その後動画を見つからず、なんとかPDFの資料を発見 http://www.agilejapan.org/session.html
　今年も運良くいただいた魂本でも基調講演の内容が明記されててよかった）

#【基調講演】 “モダンアジャイル”Joshua Kerievsky 氏

2001年2月アジャイルソフトウェア開発宣言 (マニフェスト) を見たとき、
これは開発者に幸福をもたらしてくれるもののように思えた。
そして顧客とともに目指すべき道もここにあると。
http://agilemanifesto.org/
http://agilemanifesto.org/iso/ja/manifesto.html

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

しかしあれから10年以上たった2017年、まだまだ開発者も顧客も幸福とは言えない事例がある。
何が間違ってたのか、何が足りなかったか、そんな疑問に答えるのがモダンアジャイルかもしれない。

人々を最高に輝かせる(契約交渉よりも顧客との協調を、)
安全を必須条件にする(プロセスやツールよりも個人と対話を、)
高速に実験学習する(計画に従うことよりも変化への対応を、)
継続的に価値を届ける(包括的なドキュメントよりも動くソフトウェアを、)

モダンアジャイルはアジャイルマニフェストのエッセンスをしっかりと引き継いだまま発展させたものだ。
モダンアジャイルを知ろうとすることで、私たちは再びアジャイルマニフェストをより深く理解することになるだろう。
アジャイルマニフェスト間違っておらず、さらによりよく進化する余地があったんだ。

GoF の罪として
4人は OOPSLA'99 において，裁判にかけられた．罪状は「Singleton という名前でグローバル変数を正当化した」．
というのが有名だが、それよりもパターンさえ使っていれば優れたコード&設計のように誤解させ、
パターンを使わなくてもいい部分にまで、パターンを持ち込み過剰&的外れな汎化・抽象化したコードを
大量生産させたことが最大の罪ではないか。

そんなことをぼんやりと思っていた私に、パターンから離れるというリファクタリングを教えてくれたジョシュアさんが大好きだ。

パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法

著者 : ジョシュア・ケリーエブスキー

日経BP社

発売日 : 2005-08-04

ブクログでレビューを見る»

[設計の終焉?(原題: Is Design Dead?) マーチン・ファウラー
単純さとはいったい何か]
(http://objectclub.jp/community/XP-jp/xp_relate/isdesigndead#n171)
にも彼らしさを感じられる意見が述べられていて嬉しかった。

そしてモダンアジャイルでまた新たな気づきを与えてくれたジョシュアさんをさらに好きになった

memo

"Safety is a basic human need and a key to unlocking high performance. @JoshuaKerievsky
"Learn more, earn more." Warren Buffett Business Magnate
"We're working on much bigger failures right no." Jeff Bezos CEO, Amazon

招待講演:木下史彦氏 @fkino 50分でふりかえるアジャイルムーブメントの歴史 2017年版

半年ほど前に平鍋さんのツイートでこのスライドを見かけて、直接話を聞きたくて富山まで行ったといっても過言では無いぐらい楽しみにしていた。
そのわりには古今東西アジャイルマニフェスト執筆者で指名されて三人しか答えられないという失態。
最近お気に入りの James Grenning さんを言えなかったのが特に残念。

テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計

著者 : James W. Grenning

オライリージャパン

発売日 : 2013-04-24

ブクログでレビューを見る»

アジャイルは今でも現在進行形。
XP、Scrum、リーン、カンバンなどの多様化アジャイルの実践方法は進化してきた

http://agilemanifesto.org/
http://agilemanifesto.org/iso/ja/manifesto.html

We are uncovering better ways of developing software by doing it and helping others do it.

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

アジャイルマニフェストは銀の弾丸ではなく、まだまだ進化することを宣言していた。
モダンアジャイルもさらなる進化を遂げるだろう。そして私自身も進化したい。

平鍋さんアジャイルやめる発言もなんか元気をもらえた。（ちょっとおかしい？）
自分はその 1/100 も実践できていないのだから、諦めるのはまだ早い。

休んだり、やり方を変えてみたり、まだまだ……。

地方コンテンツ:麦島一氏 @mugi_uno Misocaでのミーティング＆ふりかえり術

コミュニケーション、コラボレーションで重要なミーティング、ふりかえり
自分だけでも明日から始められるミーティング、ふりかえりのコツが満載。

ミーティングの共有と議論を分離する。
　　担当を割り振ってあとで話す。　そのあともう一周する。
　　聞いてるだけの人はいらない。結果を共有するだけでいい。

そうは言っても脱線はする。
　　遮ってでも止める。止めるのも勇気がいる。止められるほうもビビる。
　　なんで議論を止めるのか、を全員がわかっていると難なくできるようになる。

Misocaでよく聞くワード。
　　それは後で話しましょう。この場はやめよう、担当者同士で話そう。
　　議論が硬直化したら → やってみよう。

会議を効果的に行うにはリスクを恐れずに、関係者を絞るしかなさそう。
全員に全部周知徹底なんてどうせ無理なんだし、
やってみないで結果を完全に予想するなんて無理なんだから、
前向きなあきらめと、それを肯定できる勇気が必要かな。

振り返り
Tryが腐らないように誰かがやる。アサインではなくサインアップ。
　傍観者効果。誰かが傍観していると自分も傍観する。
　やるよ！手伝うよ。
　　綺麗事。やりたくないなーって思う。　それはしかたない。そういうもの。
　やるよ。に感謝する。
　Actionを貧乏くじにしない。

無理だわー
　おそらく正しい。
大事なのは方法よりも理解。ちゃんと説明して理解してもらう。
まずは自分のチームで。自分だけで。
小さく始めよう。

ふりかえりをやりたがらないというより、Try Action をやりたがらないのかな。
Try Action をたくさん引き取ってやりきる人には、ほんと感謝してばかりだ。
傍観している人を巻き込むには何かをやめる Try も必要なのかな。

ここまで文化として定着するまでにはいろいろつらいこともありそうだけど、今よりもすこしづつよくしたい。

フィッシュボールでのディスカッション

真ん中に6席用意して、話す人がその席に、他参加者は周りに座る。
真ん中の6席には空席を常に1つとなるようにして、話し終わったら離席、話したい人が真ん中へ……。
ってのがフィッシュボールらしい。
空席を常に1つがルールだったが、たまに空きがなくなってもいいし、2つ空いてもいい気がしたけど
いろいろな人が自分のタイミングで好きなことを話せる、いい方法だと感じた。

心理的安全とか、勉強会の運営に関するヒントがもらえた気がするので試してみたい。

一年前からそれほど成長していない自分に、同じことを繰り返してるだけのような
気がして辛くなる感じもあるけど、足踏みのような一歩でも転んだり、回り道したりしながら
変えていくしかないんだろう。

来年も参加できたらいいな。