公式サイト
http://www.agilesamuraibasecamp.org/
DoorKeeper
http://agilesamurai-basecamp.doorkeeper.jp/events/5844
Togetter
http://togetter.com/li/600193
以下の書籍をターゲットとしたイベントなのです。
 | アジャイルサムライ−達人開発者への道− (2011/07/16) Jonathan Rasmusson 商品詳細を見る |
場所は渋谷の株式会社サイバーエージェントさんです。
参加者は180人くらいでしょうか。1冊の書籍イベントにこれだけ集まるとは、アジャイルサムライ恐るべし。
今回は早割があるということで、キャンペーンチケット(1000円)に申込みました。
つーか当日、CodeIQの問題を解いて500円の図書カード貰ったので、実質500円で参加できたことに！
CodeIQの問題を解いて、図書カードをゲット！ありがたい〜 #agilesamurai
— makopi23 (@makopi23) 2013, 12月 8個人的に、この書籍はアジャイルサムライ横浜道場の読書会で2年くらいじっくり読んできた、思い入れのある本です。
たぶん、アジャイル関係の書籍の中で、私が一番最初に手を取った本だったはず。
読書会は他所でもちらほら見かけますが、今回のようなイベントも新しい試みで良いですね～
今回のイベントは「インセプションデッキ」と「テスト駆動開発(TDD)」の２トピックからどちらか１つを申し込み時に選ぶ方式になってました。
というわけで今回、私が選んだのは「インセプションデッキ」。やっぱ、デッキは１つのキモだと思うんです。
デッキをワークショップで丸１日学べるイベントはありがたい。
そういやDevloveでも以前、丸二日かけてインセプションデッキを作る勉強会がありました。
アレはすごく勉強になったなぁ。あの時にチームで頭を捻ってデッキを作った経験が今も活きている気がする。
そんとき書いた参加メモはこちら。もう1年以上前になるのか～懐かしい。。。
2012/9/8(土) ＆ 2012/9/23(日)
「アジャイルサムライDevLOVE道場二周目 第一回 インセプションデッキ(前編)&(後編)」に参加しました
TDDにももちろん興味があったんですが、7月と10月のTDDBCに参加したこともあり、今回はデッキの方に～。
でも休憩時間とかはTDDの方を覗いて、和田さんのお話とか聴いたりしてましたw
以下、個人メモ。丸一日、長いので、午前と午後で２回に分けて書く。
あ、ちなみに自分の復習のためにいつも書いてるので、毎回ダラダラ、メモを書き起こすだけ！
■ジョナサン・ラスマセン氏からのビデオメッセージ
イベントの冒頭、アジャイルサムライ原著者のジョナサン・ラスマセン氏からのビデオメッセージが上映されました。
ジョナサン・ラスマセン氏はカナダに住んでいるそうです。ジョナサン、実にオープンｗ
こーゆう試みは良いですね！
特に以下３点をメッセージに込められていました。
１．学んだことを他の人と共有する
２．常により良い方法を探す
３．楽しんでください
特に２．については、「明日から何をやるか」を考え、自分たちでもっと良いやりかたを見つけていくことを説いていました。
あと「３．楽しんでください」はすごく大事。
アジャイルを勉強したり、こーゆうイベントに参加したりする原動力って、個人的は「楽しいから」に尽きる。
■基調講演 角谷信太郎氏
アジャイルサムライ監訳者の角谷さんの基調講演です。
私が今回初めて知った裏話的な要素が多分にあり、大変参考になりました。
■本の一番最初に出てくる図（P.4）
・本で伝えたいことを１枚で表している図。
・お客さんは、そのソフトウェアを使う人。その人に価値のある成果を届ける。
・「成果」＝「動くソフトウェア」。もっと言うと、「ちゃんと動くソフトウェア」。
・設計していて、テストしていて、コードベースにマージされていて、お客さんの環境で動くソフトウェア。
・成果を毎週届けることは可能だろうか？
・ソフトウェア開発は難しい。
・何から始めていけばいいかを今日のイベントで考えていきましょう。
■Whole One Team（P.5）
・チームが一丸となって、一つのゴールに向かって協調しながら進んでいくことが大事。
・チームには、２つのロールがある。
①何を作るのかに責任を持つ人
②どうやって作るのかを決める開発者の集まり（プログラマ、デザイナ、QA、インフラ、etc）
・チームが「一丸となって」ゴールに向かって進んでいく。
■アジャイルサムライのお話の構造（P.6）
・この本の中には一通り、取っ掛かりになるものは全部入っている。
■なぜこの本を書いたのか？（P.7～P.11）
・２年前に著者のジョナサンが日本に来てくれた時に話をしてきた。
・マーチン・ファウラーは「もうこれ以上この世にアジャイルの本は要らないと思う」と言っていた。
・でも、たくさん本を読まないと全体像がつかめなかった。
・なら、世の中にある本を１冊にまとめたら値打ちがあるんじゃないか。
・そこで、７冊を１冊にまとめた。
■７冊の書籍（P.11～)
①１冊目
 | XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法 (2000/12) ケント ベック 商品詳細を見る |
・ジョナサンが一番影響を受けた本。ケント・ベック著。
・これはアジャイルのムーブメントの始まりの１冊。
②２冊目
 | リファクタリング―プログラムの体質改善テクニック (Object Technology Series) (2000/05) マーチン ファウラー 商品詳細を見る |
・ThoughtWorks社で働いていた時に、マーチン・ファウラーがケント・ベックと一緒に書いた本。
・２番目に影響を受けた本。
(1) 目の前にあるコードを良くしていく活動は大事だ。
(2) ソフトウェアを作るとき、ちゃんと作らないといけない。それを継続的に続けて行かないと、動くソフトウェアを届けられない。
最初の２冊にこの２点が来ている点がポイント。
③３冊目
・「XPエクストリームプログラミング実行計画」
・今から読む必要はないと思う by 角谷さん
④４冊目
・「XPエクストリームプログラミング導入編」
・ケントベックがXPの考え方を示している。
・実際プロジェクトでXPをやるとどうなるの？というのをレポート風に書いてある。
⑤５冊目
 | テスト駆動開発入門 (2003/09) ケント ベック 商品詳細を見る |
・最初にして一番いい本。
・「なぜテスト駆動開発をしないといけないのか？」から書いてある。
・絶版なので、なんとかする！ by 角谷さん
・TDDは、和田さんの活動をフォローしていくのがいい。
⑥６冊目
・「USER STORIES APPLIED」
・日本語版は無い。いい本だけど、読むのは大変。
・マイク・コーンというスクラム界の凄い人が書いた本。
⑦７冊目
 | アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ (2009/01/29) Mike Cohn、マイク コーン 他 商品詳細を見る |
・内容が凄く良い本。角谷さんが訳した。
これらをまとめていく必要がある。
■Also had new material（P.18）
・７冊の内容だけじゃなく、新しい要素を追加した。それが「インセプションデッキ」
・みんなで認識を合わせていくためのツール。この新しい考え方を導入した。
・これらをまとめて、１冊で読める本として出したのが「アジャイルサムライ」。
・次のステップとして、ソフトウェア開発の現場で試していく入り口にこの本がなるといいな、と思っている。
■なぜサムライ？（P.21）
・なぜサムライなのか？なぜパイレーツとか忍者じゃないのか？
・これは、アジャイルサムライの「監訳者あとがき」にも書いてある。
・ジョナサンが一番好きな本は「Way OF The Peaceful Warrior」だった。
 | Way of the Peaceful Warrior (2004/04) Dan Millman 商品詳細を見る |
・すごい体操選手が怪我をして、自分の生きる意味を見失いがちだった時に、ガソリンスタンドで出会った老人から生きる意味を見出していく話。
・状況を受け入れていくこと、抵抗しないこと、などを説いている本。
・そこで、心穏やかに人生を過ごしていく考え方をソフトウェア開発にも応用したいと考えた。
→ 「The Way of the Agile Warriror」という書名を最初に付けた。
→ 「それでおまえは分かるけど、読者にはそのニュアンスは伝わらない」と編集者に言われた。
→ WarriorをSamuraiに変えた。
・私も「サムライ」が良いと思っている。 by 角谷さん
■マスター・センセイと熱心な弟子（P.25）
・マスター・センセイは、実在した武士とかモノノフではない。本の中では「概念」！
・本を書く背景になった20世紀終わり～21世紀初頭のような、アジャイル開発を実践していた人たちが纏まった何か。
・謝辞に挙げている人物たちから受けた影響の象徴としての存在が「マスター・センセイ」。
・具体的には、ケント・ベック、マーチン・ファウラー、メアリー・ポッペンディークや、ThoughtWorks社の同僚の皆さんとか。
■アジャイルなソフトウェア開発とは？（P.27）
・10年近く活動してきた彼なりの考えをプレゼンしたのが「アジャイルサムライ」。
・これから取り組む皆さんは、書籍から受け取った思いを持って、現場で実践していけるといいなと思っている。
・でも、なかなか難しい。どうやればいいか。
・大事に思っていることは、「アジャイルソフトウェア開発とはなんなのか？」を考えること。
・「アジャイルプラクティス」という書籍の最初に、アジャイルソフトウェア開発を定義した一文がある。
・開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行い続けることである。
・この一文がすごく気に入っている。 by 角谷さん
・ソフトウェア開発がアジャイルであるとは、価値のあるソフトを届けるというゴールに向かって、チームが協調性を大事にする環境を作る。
・その環境の上でやってみて、フィードバックする。
・成功はない。考えて、実行に移す。
・自分たちのやりかたを調整し続ける。
・プラクティスに囚われると見失うことが多い。
・目的に向かって協調できる環境になっているか？を考える。
・少しづつアクションしてみて、学びながら調整していく。
・今取り組んでいるチームで、フィードバックが効いて、ゴールに向かって協調できているかどうか、一人ひとりが見ていく。それを大事に思うことが重要。
・当事者意識を持って働きかける。
・良いプラクティスはあるが、それをやることではなく、どう現場に働きかけていくかが大事。
・ものごとの名前に囚われないようにしてください。
■次の10年へ（P.31）
・やっと、アジャイル開発の考え方が受け入れられやすい下地が整ってきたなと思っている。
・今日の１日がキッカケになればいいなあと思っている。
・でもこの10年、アジャイルをやろうとスタートした人がいては、一人倒れ、二人倒れ。。。
・でも、この周回が大事。
■Inception Deck（P.33）
・価値を届けるツールの１つとして、何を作るのか、どう作るのか、自分たちのゴールを明確にする。
・でも、それだけではソフトウェアは書けない。
・その片一方がテスト駆動開発。
・ただ「テスト駆動開発」とか、言葉にとらわれてはいけない。
・コードを書かないと何も実現できない。
■Clena Coder（P.34）
・角谷さんお勧めの本。以下は角谷さんの大好きな言葉↓
・プログラマは詳細の管理者である。
・それが我々の仕事だ。
・システムの振る舞いを詳細に決める。
・そのためにテキスト言語を使う。
・（それがコードだ）。
・この言葉を実現するためにTDDがどう使えるのかを考えてほしい。
１．学んだことを他の人と共有すること
２．常によりよい方法を探し続けること
３．楽しんでください
■Ron Jeffriesの言葉
・師を仰ぎ、師を追いかけ、師に歩調をあわせ、師の意図を汲み、そして自らが師となるのだ。
・同じトピックに興味をもった人たちの集まりはすごく大事。今日の場を大事に。
■どうやって始めるの？ 西村直人氏
角谷さんの基調講演の後は、インセプションデッキトラックとテスト駆動開発トラックに分かれました。
インセプションデッキトラックの最初は、アジャイルサムライ監訳者の西村さんの講演です。
１．デッキって何だ？
・デッキは、プロジェクトを上手く進めるためのもの。
・プロジェクトの行先にスポットライトを当てる。
・「もっと早くいってよ！」といったような遣り取りを無くすためにインセプションデッキを使う。
・デッキは、プロジェクトをうまく進められるかを確認して調整するための活動。
・いろんな活動はこれまであったが、時間をかけたり一部の人間がやってたりしてた。
・そうじゃなく、みんなが集まって大事なことを調整するのがデッキ。
・やり方は、めっちゃ簡単。質問にみんなで答えていくだけ。
・みんなで話し合って、ひとつの答えを作る。
・知らないことはうまくできないし、みんなの理解はおもったよりバラバラ。
■われわれはなぜここにいるのか
・プロジェクトのゴールは１つ。
・ゴールは目指すトコ。
・ゴール以外に、「ミッション」というものがある。絶対に達成しないといけないもの。
■エレベーターピッチ
・ゴールは２種類ある
①ビジネスとしてのゴール
お金を出してくれた人の対価がいる。そういう人がいることを知ることは大事。
②使う人にとってのゴール
・デッキで何がしたいかを一言で言うと、「期待」と「実現可能」の両方を早い段階から一致させること。
２．どうやって作るの
・準備して、理解して、調整して、まとめていく。このサイクル。
■１．準備
・・・難しい。ヘタすると、沈黙したり空中戦になる。
・なので、おたがいが話しやすいようにたたき台が重要。それについて人を集めてディスカッションする。
■２．理解
・お互いの違いを明らかにする。
・ファシリテーターが意見を引き出す
・付箋を使って、気になることを書いてもらう。
・大事なのは「みんな」。
・オレの意見を聞け、じゃなくて、相手の意見を聞く。
・「チーム＝みんな」という考え方。
・「あいつはプログラマの意見だから」とかじゃない。
■３．調整
・声の大きい人とか役職が上の人とか、「この問題の答えはこうだよね！」というと、みんな沈黙してしまう。
・しかも、誤解をして受け取ってることがある。
・これだと、「みんなとしての答えを出す」ということにはならない。
・なので、それぞれの意見を調整する。
・ファシリテーターを立てたり、付箋を無記名でやってみたりとかの工夫をする。
・大事なのは、出てきた答えが「できそうだ、いけそうだ、実現可能だ」と思えるか。
・それがひとつの判断ポイント。じゃあ、どう確認するか？
・みんなに手を上げてもらって、５段階で指を出してもらう。
・そうやれば全員の意思を確認できる。
・ぱっと手を上げて、２とかだったら話し足りてないとかに気づける。
■４．まとめ
・「あの話って、前に話してきたことと違ってきているような。。。」ってなことが絶対起きる。
・なので、いつでも確認できるよう、更新できるよう、スライドにまとめる。
・印刷して見えるところに置いておく。
・共有フォルダに入れても見られないのでダメ。
・作ったスライドが、日々の判断材料になっているかがポイント。
これがオーソドックスなインセプションデッキの作り方。
３．一人で作ろう！
・なんだ。。。集まる、対話？？？超難しいやん！
・一人でやってみよう。
・では、一人ではどう始めるのか。
・準備して、理解して、調整して、まとめていく。この４つのサイクルは一緒。この繰り返し。
■１．準備
・まずは自分の理解をまとめてみよう
・自分の整理の意味をこめて、スライドを作ってみる。
・たくさんのインプットがあるはず。
・直感が正しかったりする。それを理由付するためにちょと書いてみる。
・大事なのは、全部書けなくても構わないということ。
・「分からない」ということを理解することが、一人で始めるときのポイント。
■２．理解
・知っている人に聞きに行けばいい。わからないことを質問する。率直に聞けばいい。
・大事なのは、デッキじゃなくて質問しよう。
・デッキのここを埋めたいのですがわかりません、とかいうと、デッキから説明しないといけなくなる。
・そうじゃなく、わからないことをストレートに聞きましょう。
・大事なのは、やり方にこだわらないこと。
■３．調整
・自分が不安を感じることを伝える。「こういうところが気になるんですが」ぐらいで構わない。
・多くの場合、相手から「こうなんだ」と言われると黙ってしまう。
・まずは自分の不安を口に出す。質問をしにいったついでに聞いてみるとか。
■４．まとめ
・最新の情報をまとめて、まわりに伝える。まとめ方がスライドなだけ。
・インセプションデッキのフォーマットを使っていれば、注目してもらいやすい。
■タイミング
・デッキを書くタイミングはいくつかある。
・プロジェクトが始まるとかは調整しやすい。なので前の方でやる。ただ、それにこだわらなくてもいい
・ふりかえりでマンネリ化してるときにやってみるのもいい。今日はリスクについて、とか、ゴールについて、とか。
・自分が悩んだときとか、いつでも。
・自分がもやもやしてると、みんなももやもやしてるので、興味を持ってやってくれる。
・その手段としてデッキは使える。
■現場で練習
・家でやるより、現場でやったほうがいい。
・現場で練習したほうがいろんなバリエーションが経験できる。
■One More Thing
・デッキは、プロジェクトのもやもやを晴らすだけではない。
・作ると、プロジェクトの意図がわかってくる。
・すると、自分の作ってているものに関心が生まれる。
・すると、モチベーションが湧くようになってくる。
・すると、自分の範囲外にもアイデアが出てくる。
・それが価値につながってくる。
・それらは徐々に広がっていく。
・広がれば、デッキは強力な武器になる。
・明日から是非調整してみよう。
★質疑応答
Q.
１プロジェクトのエンジニアが少なかったり、プロジェクトを掛け持ちしてたりすると、デッキ作成のため作業時間が減ると思うのですが、どーすれば？
A.
・スクラムは、みんなが協力してやったほうがいいものは、みんなを集めてやる。みんなでやる。
・エンジニアとかデザイナーとか、こだわらずにみんなでやる。
・みんなで集まってやるので、オーバーヘッドがあるのも事実。
・じゃあ、オーバーヘッドを取り除く活動もみんなでやれるか、というと、プロジェクトを掛け持ちしてるとしんどいかも。
・なので、しんどいというアラートをきちんと上げること。
・スクラムで成果をアピールしたあと、プロジェクトの掛け持ちを解消すればもっと成果だせるよ、とアピールすることが大事。
Q.
・デッキ作りにエンジニアが受け身で困っている。企画部の人との温度差がある。どーすれば？
A.
・人をくすぐるポイントは違う。なので、まず個人ごとにやりかたを変えてみる。
・受身の状況では事故が起きる。なので、それを利用する。
・「デッキ作りをきちんとやってなかったから事故ったんですよ」と、ちゃんと言う。
・あとは、成功体験から始める。
・エンジニアだけでデッキ作りをやるのもあり。そのほうが壁が少ないかも。
★午前の部の感想：
初心者をターゲットとしたイベントっぽい位置づけらしいけど、ぜんぜんそんなこと無かった！
少なくともこの午前の講演２本は、玄人、素人の関係なく、万人に聞いて欲しい内容だったと思う。
つーか午前だけでもアジャイルサムライの監訳者お二人＋裏のTDD側で和田さん講演とか、豪華すぎワロタ。
午後のセッションについては、明日にでもメモ書く～
- 関連記事
-
- 「Agile Samurai Base Camp」に参加しました ～其の弐～ （午後の部）
- 「Agile Samurai Base Camp」に参加しました ～其の壱～ （午前の部）
- 「リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜」に参加しました
