公式サイト
http://2015.scrumgatheringtokyo.org/
場所は六本木のヤフー株式会社さんです。
参加者は２００人弱くらいでしょうか。XP祭りに匹敵する規模ですね～
毎年、このイベントはたしか有料だったんですが、今年から３日間のうち最初の２日間は無料に！
これはありがたいですねー。しかも週末なので業務を気にすること無く参加できます。
2週間近く経ってしまいましたが、自分が参加したセッションのスライドが出揃ったので、自分の復習のため今更ながらメモ書き残す。
■ [1C-1] いまココにある請負アジャイル開発現場の実態
～4年で4億弱売上20案件以上の実践経験から語る～
セッション内容： コチラ
初日１発目のセッション、どれも面白そうだったんですが、拝承SIerに身近なネタということでこのセッションを選択。
■ １．タイプ別Agile PJ事例
まず興味深いのが、Agile PJを３つのタイプに分けて、事例を紹介している点です。
- 強引にAgile（請負契約タイプ）
- Agileで提案（コンペタイプ）
- Agileで協業（レベニューシェアタイプ）
「強引にAgileタイプ」では、要件定義を最初と最後の２回やった、という点が興味深い。
あと要件定義書の意味合いをW/Fから変えている点。
「Agileで提案タイプ」でも、請負契約からは逃れられなかったとか・・・。
「レベニューシェアタイプ」、これは新しいですね。得られた収入をシェアしながらそれを元手に広げるタイプ。
■２．プラクティスの適用及び改善事例
(1) バーンダウンチャート
バーンダウンとバーンアップを組み合わせる紹介がありました。
バーンアップは登っていくので、開発者の気持ちも上がっていくとのこと。
あと、バーンアップとバーンダウンがクロスする地点を見ることで遅れとかが見やすくなるとのことでした。
なるほど。
(2) ペアプロ
ペアプロは合わなかったとのことで、「親方制度」という形で工夫して運用しているとのこと。
「親方」。名前付けすることで馴染み深くなります。
(3) KPT
KPTにTを足して、KPTTとしているとのこと。Tは、Thanks。追加することで盛り上がったそうです。
自分たちに合う合わないを見極めてプラクティスを採用したり改善したり、プラクティスもAgileであれ！
■３．これからAgileへ挑む方へ ～Agileで悩んでいる方へ～
「変えるならチームじゃなくてプラクティス変えればいい」という言葉、良いですね。
上手くいかないからといって人に原因を求めるのではなく、人はそのままに、やりかたを変えることで改善できないか模索。
■Q&A
Q.
Agileを一括請負契約にすると、スコープが固定されてしまうが、どう対処するのか？
A.
一括請負契約の解釈を、お客さんと会話して合意するようにしている。
Agileを一括請負契約にすると、スコープが固定されてしまうが、どう対処するのか？
A.
一括請負契約の解釈を、お客さんと会話して合意するようにしている。
契約に「ここまで開発してリリースしてね」と書いてあっても、「こういうふうに進めたほうがもっと良いですよ」とお客さんと会話して、一括請負契約の解釈を変えるように仕向ける。
---
ちなみにこのQ、私が挙手して質問しました。契約の「解釈」を変えるとは、斬新です。
ちなみにこのQ、私が挙手して質問しました。契約の「解釈」を変えるとは、斬新です。
■ [1C-2] 開発モデルの作り方 ～守破離の破！～
セッション内容： コチラ
AEP読書会でいつもご一緒している藤村さん。
読書会でも以前、オフショア開発に関する発表をしていただきました。
CSM研修や勉強会で学んだことを現場にひたすらアウトプットしようとする姿勢がまず素晴らしい。
INPUTばかりしてても価値は生み出せず、OUTPUTしないと意味が無い。
あと、パリス・ヒルトンとの写真にまつわる何気ない話、あれ、結構大事だと思うんです。
うるさいくらい言い続けること。自分の考えを声に出して、相手にアピールすること。
そうすると、それに関連するチャンスが来た時に、「あ、そういえば」と声がかかる。
自分が「守・破・離」の今どこにいるのか、意識すること大事。
守が出来てないのに破をやろうとしてしまうこと、多々ありますよね・・・
守破離の前に「お試し」を入れて、「試守破離」と自分なりにカスタマイズしてみたり、RFCモデルという開発モデルを自分で作ってみたりと、新しいものを生み出すパワーと発想力が裏山氏・・・
最後のQ&Aでも藤村さん
「失敗しても個人じゃなく会社が痛いだけなんだから、失敗を恐れずチャレンジしたらいいんじゃね？」
こーゆう考えを持てるように私もなりたい。
■ [1B-3] 大きな組織にスクラムの輪を広げていくために
セッション内容： コチラ
パターンランゲージを作る取り組み、最近特によく見かけるようになりました。
テスト自動化については、テスト自動化研究会や関西の方でもパターン化に取り組んでる点は先日のブログにも書いたし。
あと、アジャイルでもFealess Changeとかもパターンですね。
「６．失敗していただく」は、これは難しい判断ラインだと思いました。
失敗を許容する、失敗に妥協する、というラインにならないよう、どこまで介入するかの見極めが難しい・・・
「１３．蟹の季節」、パターン名が斬新でワロタ。
「１．新しいこと担当」は、前のセッションで藤村さんが紹介したパリス・ヒルトンのお話と通じるものがあります。
個人的には、「３．対岸の火事のうちに」がしっくりきました。
来るべき時に備えて技術やノウハウを貯めておいて、いざ、声がかかった時にスッと対応できるように準備しておく大事さは、これまでの仕事でとても実感してきたからです。
■ [1A-4] 自己組織的なScrumチームの目指し方
セッション内容： コチラ
会社名から「ドラクエ開発してる会社や！」と思って参加したんですが、違いましたスミマセン・・・
私も会社で「自己組織的ってどういうこと？」ってよく聞かれるんですが、土肥さんは「ワクワクする組織」という定義をされてます。
ちなみに去年１１月に受けたCSM研修では、自律的、という意味を考えるワークショップとして、床に線路のテープを引いてその上をペアで歩くやつやりました。
私はあのCSM研修のワークショップから得られたイメージが強いですね。
あと、自己組織化プロセスを個人とチームでそれぞれ５段階で分類している点が面白いと思いました。
自分やチームの取り組みが、自己組織成長プロセスのグラフの、どこに位置しているのかを考えるのは役立ちそうです。
ちなみに、土肥さんがいろんな取り組みをチームメンバにさせてた中で、「異質で大変な経験をさせて失敗させてみる」というのが心に残りましたね。
土肥さんは、メンバを海外に行かせて英語がしゃべれない体験をさせて「英語ができないと始まらないんだ」という実感をさせた例を挙げていましたが、これ、すごい重要だと思うのです。
人間、モチベーションが上がるタイミングって、興味があるか、追い込まれるかのどちらかなんじゃないだろうか。
そして、前者だけでなく後者を上手く利用することで、もっと進化を多様化させていけるんじゃないかな、と思った次第。
上手く取り入れていきたいなと思いました。
■ [1A-5] XP Never Dies ～あなたがXPを学ぶべき108つの理由～
セッション内容： コチラ
西村さんの話を聞いて、そういやXP本、読んだことないな～、と激しく実感した・・・
 | XPエクストリーム・プログラミング入門―変化を受け入れる (2005/12) ケント ベック 商品詳細を見る |
ちなみにピアソンなので絶版になってしまいましたが、西村さん曰く、今年９月くらいに新訳が出るそうな！
翻訳はリーダブルコードなどで信頼と実績の、角さん。
これは買うしかない。
ちなみにXP本のポイントは、「最初に読むべき本だけど詳しい」だそうな。
オフショアやスケールの話まで書いてあったり、ちゃんとプラクティスを基礎と応用に分けていたり。
XP本と対比されてたのが、この日配布されてたスクラムガイド。ルールブック的。
西村さん曰く、「あんな薄いので、ホントに実践できますか！？」
あと、XPはGeek！のくだりで、「プロペラ帽」の話を紹介していました。
XPではプロペラ帽をかぶる文化があったそうで、「XP プロペラ帽」でググってください、だそうな。
んでググってみると、どうやら"「プロペラ帽」はハッカーの印、トリッキーなコードを書いた人はこれをかぶらないといけない。"というネタがいくつかヒットしました。
いかにも技術寄りなXPらしい逸話ですね。
他に紹介されてた１０８の理由の一部。
■プレッシャーが少ない
- スクラムだと「スプリントが終わった後に、毎回リリースしなきゃ・・・」ってなる。
- スプリント ・・・ 走り抜けろ、的な。しんどい。
- イテレーション ・・・・ カッコイイ。単に「繰り返すんだよ」としか言ってない。
■１人でもできる
- 西村さんも一人で始めた。
- ペアプロとかも、一人でやってた。ドライバーとナビゲーターを時間で区切って、１５分で交代してた。
- 一人でタスクボード作ってみたり。
- やってみてわかることが非常に多い。やればやるほど上達する。一人でやっててスキル上がったなぁ、と思う。
■価値が明記されている
- このチームをアジャイルにしていきたいと思った時、上手くいっているかどうかを考えるのは難しい。
- 大事なのは、価値が浸透してきているかどうか。
- XPは、価値がちゃんと明記されている。
- でも抽象的なので行動に移せない。なのでXPは・・・（下に続く）
■原則がある
- 原則に従ってると行動しやすくなる。「例：小さなステップで」
- 原則を自分の行動規範にできる。
■経験者を呼びやすい
- XPが日本に入ってきて１０年。大御所はXPから入ってることが多い。
- XPの一部をやったことある人は、結構多い。XPの経験者は探しやすい。
- XPを初めてやる時に経験者を呼べるのはアドバンテージ。
■コーチいらず
- コーチ重要。呼んだほうがいい。でも、いなくても大丈夫。
- ほとんどのチームって、コーチを呼べない。でも、「いなくても大丈夫」と本に書いてあると安心。
■始め方に触れている
- 最初は何をやらないといけないのか？まずXPのプラクティスをマッピングしましょう。とかちゃんと書いてある。
■役割と振舞いが詳しい
- チームメンバはどういう振る舞い、権限を持ったらいいのか。
- XPは役割が明言されている。例えば「重役」というロールとその役割までが明記されている。
■大事なのは改善だけではない
- 悪いことを見つけて良くするだけがジャイル開発じゃない。
- 調和とかバランスとか活気のある仕事、とかも大事。
- それを追求するのもいいんじゃないか。
■XPを使用しない理由が明確
- XPの価値と組織の価値が合わない時は、XPをやるな。
- 人間性を無視する会社はXPをやるな。
- XPをやるかどうか、判断するときのきっかけになる。
■バージョンアップ
- XPはプラクティスの数とか増えていっている。
- スクラムガイドだと、改訂で抽象度が上がるだけ。「考えろ」と言われているだけ。
- XPだと、バージョンアップに具体性があるので心強い。
- XPは、自分たちの身近な取り組みがXPのプラクティスとして取り込まれるかもしれない、という夢がある。
■ユーモアがある
- 前述した「プロペラ帽」の話は、一番酷いコードを書いた人がその帽子を１日中かぶる、というルール。
- ユーモア大事。「効果がなくても面白いプラクティス」とかも人を惹きつける。
■目的が壮大、名言連発
- XPは壮大な社会実験だ、と言ってたり。
- プログラマの生活を俺が変える！
- ５０年後はITからバイオ分野に変わると言われているが、俺がそんなことさせない！とか言っている。
- Social Change with you
- みんなもっとすごいことできるだろ、とか
西村さんが最後に言ってたのは、XPは超楽しそう！という点から始まったということでした。
チーム角谷の事例とか。
私が最近よく聞くフレーズに「Be Agile, Not Do Agile.」があります。
個人的にはこれに賛成なのですが、私は「Do Agile」から始めても良いと思ってます。
だって、私だって「アジャイルって楽しそう！アジャイル開発やってみたい！」から始めた１人だし。
誰だって、「楽しそう！」「俺もやってみたい」って思いがまずあって、そっから始めるもんではないでしょか。
ってなことを考えさせられたりと、大変参考になるセッションでした。
■ Closing
最後に参加者全員が一部屋に集まって、Closingです。
７～８人で１チームになって、「来年のScrumGatheringのポスターを考える」というテーマでチーム対抗戦です。
各チーム、制限時間内で模造紙と付箋とペンを使い、ポスターを仕上げていきました。こんな感じ。
そしてウチのチームはと言うと・・・
５枚も作ってしまった・・・。でも、けっこーいい感じ出してるんじゃないでしょか。
最後に、各チーム１名がみんなの前でプレゼンしてアピールし、投票で優勝チームを決めました。
そして・・・
・・・最多得票で、なんと優勝は我がチーム！
@iwaoRd さんと @araratakeshi さんが上手くチームを引っ張ってくれました。感謝。
最後に参加者全員で集合写真を撮ってScrumGathering １日目は終焉となりました
★感想：
今回、１日目が無料イベントとなったことで初参加しましたが、とても内容が濃くて有意義でした。
これで無料なんて、有料の３日目なんて、どんなんやねん。
来年も無料だといいなぁ～
あと、やっぱ英語頑張らないと・・・
せっかく大御所のコープとかセッション持ってたのに、俺の英語力が貧弱すぎて、二の足を踏んでしまった・・・
関係者の皆様、ありがとーございました。
