Doorkeeper
http://xpjug.doorkeeper.jp/events/3035
Togetter
http://togetter.com/li/494409
場所は大阪の鶴見区民センターです。
参加者は１００人以上かな？
ウチの会社、4/27(土)から10連休なのです。年休を1日くっつけて、11連休にしてやった！
んで、4/27(土)に大阪の実家へ帰省したのですが、そのついでにXP祭り関西に参加することにしたのです。
早朝6時23分、品川発の新幹線の切符を事前に購入してたのですが、なんと寝坊・・・ orz
起きた時には既に新幹線が品川から発車してる6時半くらいで、はぎょおおお。。な状態。
んで急いで身支度して出発し、なんとか7時くらいの品川発の新幹線に乗れました。
しかも、自由席はガラガラ。2日前に指定席取った時は、あと2席くらしいか残ってなかったのに。。。
会場に到着したのは10時10分くらいで、10分ほど遅れてしまいました。
・・・と思ったら、開始は11時からだった件。
いや、XP祭りのサイトには10時開始って書いてあるんだけど、なぜか11時開始。
んでも、遅れた私はちょうどよかった。
【出版記念講演】
以下の書籍の著者のお2人による、出版記念です。
 | チケット駆動開発 (2012/08/24) 小川 明彦、阪井 誠 他 商品詳細を見る |
【出版記念講演１】「アジャイルの夢を現実に！ - プラクティス・プラクティス -」
阪井 誠氏／株式会社SRA
以下、スライドにない口頭説明の部分を中心に、メモ。
■アジャイル開発への期待
・スライドに「YAGNI」という言葉が出てきた。知らないのでググってみる。
・YAGNI： "You ain't gonna need it"、縮めて YAGNI。
機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則らしい。
■アジャイル開発への障壁
いくつか障壁があるが、逃げ道もある。
(1) 契約
・障壁：
請負開発ではスコープを変更できない。全部開発しないといけないので。
・逃げ道：
請負といっても、リリースは１回だけ、とは言われていないはず。
要件が固まってなくても無理やり契約するのではなく、契約を複数にわけて、決まったところから契約すればよい。
(2) 場所
・障壁：
タスクボードがプロジェクトルームに置けない。
・逃げ道：
タスクボードが置けなくても、RedmineとかITSを使えば代用できる。
※ITS = （Issue Tracking System/問題追跡システム）
(3) 開発標準
・障壁：
納品ドキュメントが契約上、減らせない
・逃げ道：
納品までに作れば良い。（開発中は作らない）
■夢を実現する方法
・プラクティス導入にも優先順位が大事。
・プラクティスをやることが開発の目的ではない。
・プラクティスが実践できない時は、期待しているものを他の物で実現できればよい。
・不安のままプラクティスを導入するのは信頼貯金に反するのでやめたほうがよい
・忘れていけないのは、黄色のパターンがあること。プラクティスにも相互関係がある。
■アダプタブル・ウォーターフォール
・いろんな人の能力を最大限発揮できるようにする改善活動
・１００％アジャイルじゃなくてもよい。
■複数リリース
・リリース後の修正が多い時は、一気にリリースしないほうが良い。
・最初にやってみた知見をもとに次の契約をするようにする。（複数契約）
■変化を受け入れて管理する
・EXCELで管理やろうと思っても、できることはできる。ある程度まではうまくいく。
・ただ、変更が急に増えてきたりとか、人を投入し始めると、Excelだとしんどくなる。
・負担と効果が半々ならば、チケット駆動でやるべき。
■リスクベースの計画
・「最終決定時点」という言葉は、リーンソフトウェア開発の言葉。
■自律的組織と集中
・決定してしまう前に、チームのメンバみんなに見てもらうことが非常に大事。
・みんなで意見を出し合って、見積もりを確認しあって、計画を実現できるようにする。
・意見を言うということはコミットしているということ。自分で発言して自分でちゃんとやることが大事。
・サーバーントリーダーシップ（※１）という考え方が大事。
・偉そうにしている人と、本当に偉い人は違う。
・本当に偉い人は、必要な時は手を貸すし、そうじゃないときはメンバにまかせる。
（※１）サーバントリーダーシップ、という言葉を初めて聞きました。以下の記事が参考になるかも。
ITPro：サーバントリーダーシップとは
http://itpro.nikkeibp.co.jp/article/Keyword/20100723/350589/
・お客さんから直接メールとかで指示がきたりとか、そういう割り込みを防ぐ仕組みが大事。
■ドキュメントの軽量化
・綺麗な詳細設計書は、システムを作った後の作成で許してもらえるなら、後に作る。そうすると手戻りが減る。
■コミュニケーションと情報共有
・お菓子を配りながら顔色を見ると良い。
・気を付けないといけないのは、お菓子をもらうと残業しないといけない、と思われてしまうところ。
■難しいプラクティス
・請負契約という制約は、段階リリースとか複数契約で逃げるべき。
■まとめ
お客さんがアジャイルやりたい、と言ってくれた時のチャンスを逃さないよう、準備を整えておくことが大事。
【出版記念講演２】「チケット駆動開発をパターン言語で読み解く」
あきぴー氏／XPJUG関西 副代表
以下、スライドにない口頭説明を中心に、メモ。
■「チケット駆動開発」の略称： TiDD （← 今日初めて知った）
■チケットとは
・チケットはプロセスを管理するもの
・チケットは手順を書いたものなので、背後では状態遷移図というワークフローが動いていて、それで制御されている。
・チケット駆動開発はメトリクス収集ツールにもなる。
■TiDDの価値観とは
・価値観はフワフワしているので、指針がほしい。それがプラクティス。
■プラクティスとは
・プラクティスとは、良い方向に開発者を導くもの。
■チケットの粒度
・チケットのサイズは、大きくても２～３日で実現できるようにすべき。
■TiDDによるパラダイムシフト
・すべてのタスクはチケットとして上がってくる。
・チケットを登録していくと、チケットの枚数や内容をコントロールしていくことになる。これがスコープ。
■No Ticket, No Commit
・ソースをコミットする前に、チケットにコミットの理由を書け。
・そうすると、人が途中で抜けたりしても問題なく開発できる。トレーサビリティが重要。
・チケットとソースコードが紐づくことによって、リズミカルな開発になる。
■小規模リリース
・１イテレーションで消化したチケット数を数えてみると、各イテレーションであんまり変動がない。
→ イテレーション単位の平均消化チケット数がベロシティに対応すると考えている。
・メトリクスを貯めて振り返りで見てみるとおもしろい。
■開発のリズム
・リズムがあるからこそ楽しい。これはチケット駆動開発をしてみないとわからない。
・持続可能なペースでしか開発しない。
■TiDDは自発的行動を促す
・チケット駆動開発の良いところは、ツールの環境を作ってあげると人が勝手に育つとこ。
・従来はガントチャート作ってスケジュール管理したりして、上から目線だった。
・毎朝チケットを確認するようにすると、自分がどのくらい作業できるかを把握できるようになる。
→ 教育的な効果がある。
・社会人１～２年目でも新米リーダーでも、チケット駆動開発をやることでリスク管理とかを学んでいく。
■まとめ
・チケット駆動開発はアジャイル開発の１つだと言いたい。
・パターン言語でそれをうまく表現したい。
・複数のプラクティスを組み合わせるとうまくいく。
→ プラクティスの組み合わせ方、パターンマップを作りたいと思っている。
・組み合わせの相乗効果を見たいと考えている。
■【アジャイル屋台】
もう一つの会場は「和室」です。ここでは「アジャイル双六」なるものが開催されてました。
ということでお昼休みに覗いてみました。
和室に入ってみると、アジャイル双六が。
無料配布もされてたので一式、戴きました。感謝。
あと電源とかも提供されてて、ノートPCの充電とかもさせていただきました。
【講演１】「初めてのアジャイル開発」- 我々はどのようにアジャイルを実践したか-
アジャイルサムライ読書会at大阪道場 by @kitora_naoki氏
発表スライド、公開されるかな。。？とりあえずメモ。
■アジャイルをやってみた理由：
・やってみたかった
・このメンバならやれると思った
→ モチベーションが重要。
■コミュニケーション
・仕事だけでなくランチとか飲み会が重要になってくる。仕事の場以外で、違う会話がでてくる。
→ 親交が深まる。
・いつもはお弁当だけど、月曜だけはみんなと外に食べに行く。
→ プロジェクトがうまくまわるようになった
■スクラムを選んだ理由
・独自の方法を編み出すのは上手いやり方ではないかな、と思った。
・上手くいくやり方があるなら、そこに乗っかるのがいいかなと思った。（巨人の肩に乗る）
■インセプションデッキ
・是非やるべきと思っている。
■3人の石切り工の話
・「3人の石切り工の話」自体は以下とかが参考になるかも。
http://switchdec.com/peter-drucker-quarrier-three-1687.html
・モチベーションがすごく重要。何のためにシステムを開発するのかを意識すること。
・4人目の話があってもいいのでは。
→ 4人目：「安らぎの場を提供するため、心の拠り所を作っているんです」
・システム開発も同様、モチベーションが大事。
■デイリースクラム
・誰かへの報告になると、形骸化していく
・問題解決は別の場でやる。
・いつ、どこで、誰と、問題解決の打ち合わせするのかだけをデイリースクラムで決める。
■TDD
・実装してからテストしようとすると、テストしにくいなぁ、と気づくことがある。
→ それで手戻りとか発生することもある。
・テストから先に書くと、そんなことにはなりえない。
・JUnitでテストをやるとき、テストメソッドは日本語でもいいと思っている。
■振り返り
・いきなりKeepとかProblemとかを出そうとして、出てこないことをよく見かける。
・そんなときは、Good, Badを事実ベースで洗い出してから原因・問題分析すると良い。
・いきなりKPTのあのフレームを埋めようとしないほうがよい。
■継続的デリバリー
・デプロイお願いします、とか頼まれて作業が中断されると、お互いに気を使うし、効率もよくない。
・あの人じゃないとリリースできない、とか属人性が発生すると良くない。
・本番に自動でデプロイできることはSIだと必須ではない。一日に何回もデプロイすることはない。
→ ただしステージング環境までは自動デプロイの仕組みを作っておく。
【講演２】「京アジャ 春の特別出張編」
京都アジャイル勉強会
京アジャチーム開始 #xpjugkansai twitter.com/nyoronyoro21/s…
— nyoronyoro21さん (@nyoronyoro21) 2013年4月27日講演者は京都アジャイル勉強会のお二人です。
こんな用紙が配布されました。参加者みんなでエレベータピッチを作ります。
んで講演者が上司役になり、参加者が壇上に上がって「アジャイル開発を導入したい」と実際にアピールする実践の場が繰り広げられました（笑
これが盛り上がりましたねー。つーか、壇上に上がっていく参加者たち、アピールうますぎだろ。
関西人パワーを垣間見た気がする。いや、私も実家は大阪なんで、関西人なんだが。
■最後のまとめ
・エレベーターピッチは、誰向けなのかによって変わる。
・チャンスは突然やってくる。でも、いきなりアピールするのは難しい。
・でも、素振りならひとりでもできる。チャンスに備えて素振りをやるかどうかは、あなた次第！
---
漫才のようなヒトトキ。笑いが溢れて、大変好評でした。
【講演３】「プラクティスって何だろう。」
スクラム道関西
Xp祭り関西2013 from 雄一郎 山本
以下、スライドにない口頭説明の部分を中心に、メモ。
---
■プロダクトオーナーって、ホンマたいへん！
・責任は一人で追うが、タスクは一人で負う必要はない
■デイリースクラム
・みんながスクラムマスターを見て話すのはダメ。
・スクラムマスター中心でやるものではない。それだと報告会になってしまう。
■レビュー
・チームが頑張ったのでOK、はだめ。
・アウトプットは厳選に評価しないといけない
■レトロスペクティブ
・チームが改善を選択する。それを繰り返して改善していくことが大事。
・必ずしも問題は深堀する必要はないと考えている。
---
ここからはスクラム道関西の５名が壇上にあがり、参加者から質問を受け付ける質疑応答の時間です。
質疑応答
Q1
レトロスペクティブで最初は有用な意見が上がって来た。
でも最近、どうでもよさそうなものしか上がってこなくなった。
打開するアイデアあればおしえてほしい。
A1
・気分を変えるために、何回か前の振り返りのホワイトボードの写真を持ち出してきて、それについて話してみる。
・飽きたら辞めてみる。振り返りがある時とない時の差がわからないからマンネリする。
→ 良いかどうかわからないのにリソースを投入するのは疲れるだけ。
・メンバを導いてみる。やりすぎると誘導になってしまうが。
---
Q2
みなさんがスクラム、アジャイルを始めたきっかけは。
A2
・走りながらやるしかないプロジェクトだったから、仕方なくやった。
・長い先のことは分からないので、2週間ずつできる開発方法を探したらアジャイルが見つかった。
・他に方法がなかった。
・デスマを経験して、なんか良いやり方はないかなぁと探してみた。
・「ピープルウェア」と「ゆとりの法則」という本を読んで、今の状況はおかしいな、と思った。
 | ピープルウエア 第2版 － ヤル気こそプロジェクト成功の鍵 (2001/11/26) トム・デマルコ、ティモシー・リスター 他 商品詳細を見る |
 | ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解 (2001/11/26) トム・デマルコ 商品詳細を見る |
---
Q3
スクラムをやって、顧客の感想とかなんかあったか。
A3
・お客さんからの一番の感想は「しんどい」。システムって作るのこんなにしんどいのか。
→ 2週間ごとに高いレベルを求められる。
・「やっと、ウチのシステムを作ってる気になった」とお客さんから言われたのが嬉しかった。
→ お客さんはしんどそうだけど、楽しそうにやってた。
---
Q4
アジャイル知らない立場の人たちに考え方を伝える良いアイデアがあれば教えて欲しい。
A4
・やりかたに特殊なことはなんにもない。子供のやり方に戻す。うまくいかなければ変える。
・キャンプに一緒にいってカレーを作れ、と言う。
→ キャンプでカレーを作るとなると、みんな事前に調べて練習してくる。
→ チームで一緒になんかやってみると、アジャイルと同じなんだ、と気づく。
・朝会、タスクボード、振り返りの3つだけ、2週間だけでもやってみる。
・丸一日、時間をもらって、アジャイルの説明もきっちりして、ワークショップもして、スクラムを体験してもらう。
→ 参加者に、アジャイルっていけそうだね、と実感してもらえるように持っていく。
・ほんとにみんながアジャイルをやりたがっているかを確認したほうがよい。
・やってみると、しんどいけど楽しい、という雰囲気には絶対なる。
・紙飛行機ワークショップとか、マインドを盛り上げていくのが有効かな、と思う。
・チームメンバをアジャイルのコミュニティに誘う。勉強会に一緒に行ってみる。
→ そうすると個性の面白い人が周りにいっぱいいる。外の世界に触れてもらう。そうすると機運が高まる。
---
Q5
POが価値をうまく定義できないとき、チームのメンバーってどう助けられるか？
A5
・プロダクトバックログはREADYになってないといけない。でもREADYにならないことがある。難しいので。
・POに、水着に着替えて、遊びにいくぞ、と見せつける。
・いずれにせよ、POが要件をバックログに定義できないなら、チームは仕事をしてはならない。
・POがバックログにストーリーを定義できてないなら、仕事が止まっていることをPOにとことんまで見せつけろ。
・本当の価値はPOじゃないと決めるのは難しい。
・仕様をちゃんと作れるようにするのがPOの役割だが、それはチームで救えるところもある。
・POから「相談のってやー」と言われて、チームと一緒に話し合って手伝うこともある。
・POの下に8チームもついてたことがあった。
→ どうしても間に合わない状況になった。
→ 各チームから二人ずつ出して、POチームに投入した。
→ ベロシティが3倍になった。
・仕様が確定してないから適当に作る、は絶対ダメ。
・POとチームがバックログについて話す場で仕様が決まらなかったら、いったんその場を解散する。
→ POに考えさせる時間を設ける。
・無理してプロダクトバックログを書かずに、１回くらい１イテレーションをかけてエンジニアに好きなことやらせる。
→ その際、バックログに技術的負債を返すようなタスクを上げて、2週間でやる。
→ やってみて、その後すごい生産性あがった。
■まとめ
チームが考えて、工夫することが大事。
【ライトニング・トークス】（5名）
Eishi Saitoさん
井上 和馬さん
Tatsuya Ishikawaさん
@HIDARI0415さん
@kazuhito_mさん
---
どれも素晴らしいLTでした。内容も良いし、なにより面白い。笑いがある。
ちなみにUstで見れるようです。 http://www.ustream.tv/recorded/32017285
最後にXPJUG関西代表の西さんより、閉会のご挨拶。これにて終了となりました。
感想：
予想を裏切らない素晴らしいイベントでした。
去年は東京のXP祭りにも参加しましたが、それと遜色ないレベルだと思います。
笑いアリ、感心あり。関西らしらを随所に感じられました。
来年もGW期間に開催されるなら、また帰省を兼ねて参加したいと思います。
惜しむらくは、関西のエンジニアさんとお話する時間がなかったこと。
来年もし参加するなら、懇親会にも出てみたいと思いました。
ワークショップとかもあるといいなぁ。
関西のアジャイルなエンジニアさんたちのお顔を拝見できて、講演も聞けて、満足。
運営者さん、講演者さん、ありがとうございました。
