公式サイト
http://xpjug.com/xp2013/
Togetter
http://togetter.com/li/564392
場所は早稲田大学理工学部キャンパスです。
参加者は200人くらい？でしょうか。大きなイベントですねー
私、参加は今回が2回目です。
去年はとても楽しかったので、今回もとても楽しみにしてました。
会場に到着すると、昨年と同様、書籍の山が。
今年も参加者へのプレゼントがあるようで、協賛の出版社様に感謝！
あと、ピアソン桐原が技術書から撤退という衝撃ニュースが先日流れましたが、絶版から書籍を救うべく、アンケートが実施されてました。
ピアソンの魅力的な技術書が多数掲載されてて、お気に入りのものにシールを貼る方式ですね。
私は以下の書籍にシール貼りました。
 | 達人プログラマー―システム開発の職人から名匠への道 (2000/11) アンドリュー ハント、デビッド トーマス 他 商品詳細を見る |
「達人プログラマー」は入社2年目の時に読みました。
達人プログラマになることを夢見ていたあの頃。。。
思い出深い本です。
 | 人月の神話 (2010/12/14) フレデリック・P・ブルックス Jr. 商品詳細を見る |
私が買った「人月の神話」は、もうちょと古い、赤い本でした。これは新人の時に読んだなぁ。懐かしい。
ピアソンの技術書、なんとか絶版にならないようになるといいですねー
以下、セッションの個人メモを復習を兼ねてダラダラ書きおこしてみる。
■A-1 オープニング＋アジャイルよもやま噺【トークライブ】
http://xpjug.com/xp2013-contents-a1/
去年もあった、冒頭セッションのトークライブですね。
今年は１時間まるまる漫才やるんかな・・・？ と思ったら、スライドを使ったちゃんとした講演が2本あった。
■XPの目標
・優れたソフトウェア開発を行うこと。
・世の中には悪い方法でソフトウェアを開発をしてて失敗しているプロジェクトが多いのでは。
・そこで、良い方法をケントベックが考えた。ソフトウェア開発に建築のパターンを初めて持ち込んだ。
・パターンを集めて、パターンランゲージとしてやればうまくいくんじゃないか。
・GoFのデザインパターンは「ソフトウェア」、XPのパターンは「チーム」を対象にしている。
■XPの焦点
大きく３つに焦点を絞っている。
１．ソフトウェアのプログラミングに対してどうするか
２．コミュニケーション
３．チームとしてのパワー
■XPのプラクティス
・どのプラクティスを使うかは、各チームによって違う。
・自分に合ったものを選んで組み合わせる。カスタマイズすることが必要。
・でも、絶対やるべきプラクティスがある。必要に応じて選べばいいプラクティスもある。
■XPの理念
・XPの理念は人にフォーカスしているのが特徴的である。
・５つの価値を挙げている。
①コミュニケーション
②フィードバック
③シンプルさ
④勇気
⑤尊重
・理念のうち「シンプルさ」というのがXPのが面白い。
→ 物事に対して「シンプルにあれ」というのがXPの大きな特徴である。
・XPとウォーターフォールの大きな違いが「フィードバック」があるかないか。
■短期の開発サイクル
・プロジェクトを最初にスタートするとき、メンバーは詳細なドメインの情報を持ってない。
・すべての人が同じように高いドメイン知識を持ってるわけじゃない。
・なので、少しずつ進めながらフィードバックを得てどんどん回していく。
・「最初から全ては分かっていない」ということを認めてからスタートするのがXP。
■価値、原則、プラクティス
・プラクティスは「やり方」。１つ１つのパターンと考えても良い。
・XPが提唱している13のプラクティスは、ほぼ全部やったほうが良い。
ちなみに入り口でXPの資料が配布されてました。以下が紹介されてます。
・５つの価値
・１４の原則
・１３の主プラクティス
・１１の必然的結果プラクティス
XPを１枚によく纏めた良い資料だと思います。
・「価値」と「プラクティス」って遠い。なので、上手くプラクティスを選べなかった。そこで「原則」を用意した。
・「価値」と「プラクティス」があって、それを繋ぐのが「原則」。
・「価値、「原則」、「プラクティス」の３つの関係を理解することが、XPをやろうとしたときに大事になる。
・全部やれとはいってない。あなたのチームにとっての価値はなんですか？ということををまず考えること。
・ここに書いてある価値、原則、プラクティスが全てとは言っていない。
・これらはケント・ベックが挙げているだけ。チームによって付け足して良い。
・ただ、３つの関係を崩さないようにカスタマイズするのが正しいやり方である。
・困っている所に対してプラクティスを当てはめる。
・困っているということは、価値の反対。そこから考えていけば価値に結びつく。
■XPの真髄
(1) 社会的な変革（Social Change）
・ケント・ベックがなぜXPを作ったかというと、Social Changeが挙げられる。
・まず、障害となっているものを除きましょう。
・あの時やったから今回もやる。それで失敗する。そして前例を言い訳にする。そうじゃなく、考えること。
(2) 自己改革
・「子供じみた自己」はダメ。視点を変えましょう。
・これだとビジネスに利用できないコードを作っちゃったりする。
・ビジネスの場合だと「十分」というのがある。100点は求められない。
・小井戸さんは、最近は、読みやすい、わかりやすいコードを書くことを意識するようにした。
・ペアプロとかTDDとかやると自分のコードがよくわかる。
■今日全力を尽くすことに対して自分自身を評価する
・良い言葉やな～・・・
■まとめ
・ソフトウェア開発はチーム。
・XPで面白いのは、個人、開発者として幸せな人生を送るにはどうすればいいか、が書いてある事。
・今回のプロジェクトだけじゃなくて、長い人生、自分をどう成長させるか、人にフォーカスしている。
・相手は人間。思い遣り、お互いの理解が重要。それが良いソフトウェアを生み出す。
---
引き続き、楽天の川口さんによる講演です。
■アジャイルの全体像を理解する
・「塹壕より Scrum と XP」という書籍がある。ここで「塹壕」というのは「一番下」、「現場」という意味。
・「Scrum and XP from the Trenches」の「Trenches」を塹壕と訳したのは直訳。本来は「現場」と訳すべき。
・塹壕こそが現場である。現場レポート大事。
・今回は一番下の現場ではなく、一番上から捉えてみよう、というのがスライドタイトルの趣旨。
■Agile and Lean
・AgileとLeanがいろんなとこで聞くようになった。それらの歴史の話を纏めたのがP.3の図。
・まずアジャイル宣言が2001年に発表された。これは文化を表したもの。
・派閥がScrumとXP。
(1) XP
・XPはケント・ベックが提唱した。これは建築のPatternsから来ている。
(2) Scrum
・Scrumも同じく、Patternsから来ている。
・Scrumは、日本の製造業の製品開発を体系化した野中郁次郎氏の論文が源流にある。
・ホンダの「シティ」という車を作るプロジェクトで、若手を大部屋に集めて、「今後のホンダを担う車を作れ」、という話が原点。
→ 結果として斬新な車が出た。
・このポイントは、達人を集めたのではなく、若手を集めたこと。
(3) Lean
・Leanはトヨタのプロダクションシステムから来ている。
・トヨタの生産方式を元にLeanと名前をつけた。
・AgileとLeanは全然絡んでいないが、海外の人は両方とも日本から来たと思っている。
・Leanをソフトウェアの分野に持ってきたのがメアリー・ポッペンディークの「Lean Software Development」。
・その後、デイヴィッド・アンダーソンがLeanに衝撃を受けて「Kanban」を出した。
・最近、エリック・リースの「Lean Startup」が出た。AgileとKanbanをビジネスに活かす。
⇒ Leanには「Lean Software Development」、「Kanban」、「Lean Startup」の３派がある。
---
・他の人と話をするとき、「おまえのアジャイルはどれやねん！」と最初に話すことが大事。
・この図だと非常に広いことがわかる。
■内部構造の話
(1) プロセスエンジニアリング
・プログラマとして無駄のないアウトプットを出しましょう。
(2) コラボレーション/信頼のコミュニティ
・チームとしてのコラボレーションが大事。
・書籍「組織パターン」の著者、ジェームス・コプリエンも、これが根幹としている。
(3) フロー状態/イノベーション
・「フロー状態」とは、要するに「凄いアウトプットが出る状態」のこと。
(4) プログラマーのライフハック
・@t_wada さんは、TDDをやる理由として「一人でも自分から始められるから」と言っている。
→ これはココに該当する。
(1)～(4)の、どのアジャイルをやっていこうかな、と考えるのがよい。
■外部インタフェースの話
(1) 組織と仕組み
・Agileをやろうと思ったらどういうアーキテクチャにすればリリースし易くなるか？
・そういうところを固めておかないといけない。
・変更のインパクトの大きいものと小さいものを分けないといけない。
・変更のインパクトが大きいものは最初にきちっとやらないといけない。
(2) インフラ系の継続的デリバリー
・モノを作っても、出てかないと意味ない。
(3) 要求と品質
・全体のテストをどーするの？とか、お客さんにとってどう嬉しいの？とか、作り手が固まってくると、このあたりが勝負のポイントになってくる。
(4) マーケットイン
・商売の話が出てくる。
・マーケットを捉えるにはどうすればいいか。仮説検証がどうしても必要。
■アジャイルの構成要素
・技術プラクティス：CI,TDD
→ 開発者のヘルシーさ。ここから始める方が多い。
・Metrics
→ 効果計測。最近注目のリーンスタートアップでも言われている。数値化されることで比較できる。
■アジャイル適用のADAPTモデル
・人はどうやればアジャイルやるようになるか？
→ Mike Cohn（「アジャイルな見積りと計画づくり」の著者）が定義している。
①まず知る
②やってみたくなる
③教えて、出来るようになってもらう。
④成果を出し始めると、社内がアジャイルになっていける。
・いきなり最後の「変える」をやろうとする。でも一人ひとりがやれるように左から順にいくべき。
■初期のスプリント
・ウォーターフォールだと、伏線が最後にあるのでを回収できない。
・途中でスコープの変更により昇龍拳がおきている。
■チームの成熟（4ヶ月後）
・バーンダウンチャートが最初に１回落ちている。あと、最後に課題が発見されている。これは良い。
・フィードバックを得ている。
■アジャイルテスト
・V字モデルはアジャイルじゃない、ということはない。これをどう回すかがアジャイル。
・要求を書く人が受け入れテストを書くと回ってくる。
■A-2 SEMATに関する講演【講演】
http://xpjug.com/xp2013-contents-a2/
■SEMAT：ソフトウェアエンジニアリングのエッセンス
・Ivar Jacobsonの考えやアイデアが中心。
・どう成長していけばいいのか。
・まず知識を伸ばしていこうとするが、それだけじゃダメ。
・そこで経験やガイダンスを得て、プロフェッショナリズムを身につけていく。
・普段は、技術や知識が溢れている中で手にとって、それに実践を積んでプロフェッショナリズムを高めていこうとする。
・でもそれは島々のアイランド状態では。密接に関連づけられていない。
・試行錯誤が必要だが、それは時間がかかり、間違った方向性に向かう可能性もあるし、リスクがある。
・そこでSEMAT！
・孤島を見ていって試行錯誤するんじゃなく、共通基板があって、きちんと関連付けられて整理されていれば、それを使うことでよりよく早く幸せにプロフェッショナリズムを高められる。
・ソフトウェアエンジニアリングはファッション業界のようなものである、という批判がある。
・いろいろ、あれがいいぞ、が出て群がっては、明日どうなっているかがわからない。
・いろいろでてきて流行り廃りが出てくる。１つ１つは魅力だが、点在状態である。
・我々がより良く進める際にすべてをカバーしているわけではない。
・共通基盤がないことが深刻な問題をもたらしていて、産業界と学術会に大きなギャップがあった。
・そこで2009年、運動が立ち上がった。それがSEMAT。
・堅固な理論、実証原則、ベストプラクティスに基づくソフトウェアエンジニアリング再建（共通理解）
・Ivar Jacobson、Bertrand Meyer、Richard Soleyの3人はトロイカと呼ばれる。
■共通基盤
・ソフト開発の核を定義しよう。
・理論がないわけではない。でも、いずれも共通基盤ではない。
・そこでSEMATが共通基盤を与える。
・同じ土台にのって議論したり、プラクティスを交換したり。そういうところに繋げる。
・理論的共通基盤のことを「エッセンス」と呼ぶ。
■エッセンス（カーネル＋言語）がOMG提案承認へ
・階層構造の一番下に「言語」がある。プログラミング言語じゃなくて、ビジュアル言語。図形のDSL。
・その上にカーネルが定義されている。大事なことの基本的な関係が定義されている。
・カーネルはプロセスとは独立している。広く共通に使えるものがつまっている。
・「言語」と「カーネル」がエッセンスで、その上にプラクティスを定義し、組み合わせる。
・手法やプロセスありきではなく、まずエッセンスありき。
■カーネル
・ソフト開発の状況、状態を表現するのに欠かせない情報。
・一番重要なのかアルファ。
・アルファ（alpha）は、AspirationLed Progress and Health Attribute略称。
・まず「アルファ」という名前ありきで略称を頑張ったｗ
・今どのくらい進んでいるのか、うまくいっているのか把握すべき最低限の事柄をアルファと呼ぶ。
・アルファの状態を遷移させていくために必要な作業があり、活動空間、活動がある。
・カーネルの中には、活動空間のテンプレートも入っている。それを各人において具体化、明確化して使う。
・SEMATはアジャイルの影響を強く受けている。チームや仕事の仕方など、取り組みを大事にしている。これがあってこそ進めていける。
・要求はいろんなステークホルダーから出てくる。
・要求だけじゃなく、取り組みや顧客も大事。そこから７つのアルファを抽出している。
■カーネルの特徴と留意
・ソフトウェア以外の事柄を大切にしている。
・アジャイル宣言を支持している。
・状態思考（not プロセス思考）
---
ここまでが午前のセッションでした。
■D-3 アジャイルセンター試験：出題編【その他】
http://xpjug.com/xp2013-contents-d3/
午後1発目のセッションは「アジャイルセンター試験」を選択しました。
問題用紙と解答用紙はこんなカンジ。
会場でお会いした @shinyaa31 さんからも受験を薦められました～
告知！ / 2013/09/14(土) XP祭り2013で『アジャイルセンター試験』を行います。by WHYWG #xpjug ｜ Developers.IO http://t.co/2RRniZKEjZ
— しんや (@shinyaa31) September 9, 2013
センター試験、懐かしいなぁ。。。
受験生時代を思い出します。
あの時代はPCやインターネットが自宅に無かったので、受験勉強に集中できたというのはあるな～
ファミコンや漫画をダンボールに詰めて封印して頑張ってた（笑
今の時代はPCとかスマホとか部屋にあるので、誘惑が多くてとてもじゃないが勉強に手がつかんかも・・・とか、いろいろ思いながらコレ受験してました。
難しかった。。。
■A-4 かんばん in Wonderland【講演】
http://xpjug.com/xp2013-contents-a4/
おなじみ Devloveの市谷さんと楽天の藤原大さんのセッションです。
■リーン開発の現場
Lean from the Trenches
 | Lean from the Trenches: Managing Large-Scale Projects with Kanban (2012/11/06) Henrik Kniberg 商品詳細を見る |
・なぜこの本を訳したのか？というと、Agile2012でHenrikのセッションに出たのがキッカケ。
■本の特徴
・まえがきをケント・ベックが書いている。
・「彼の本のいいところは、理論めいたところを協調してやれ、というのではなく現場でやった物語なのでリアリティがある、納得感がある。」
・Agile2012のダラスからの帰り道に、日本の現場に届けたいなぁと思った。
・翻訳やったことないのでどうしようかな・・・
・翻訳書で心に残ったものを思い出してみた
①アジャイルプラクティス
②アジャイルな見積りと計画づくり
③アジャイルサムライ
・これらの書籍で共通することは「二人で訳している」ということ。
・一人で訳すと、合ってるかどうか悩んで進めなくなる。でも二人だと意見を交わせる。
・相棒を探そうと思ったら、藤原大さんに行き当たった。
・翻訳は簡単じゃなかった・・・
・「ベニヤ板を磨き倒して、つるつるにする作業や！」 by藤原大さん
■Kanban
・Kanbanって馴染み深い言葉だけど知られる機会がない。
・2種類の表現がある。大文字と小文字の差。以下のように使い分ける。
①Kanban： 方法論
②kanban： タスクボードとかツール
・あと、カタカナが「方法論」、ひらがなが「トヨタ系のかんばん」で使い分けることにした。
■著者のDavidさん：皇居東御苑での出来事
・入口でカードを渡されて、このチケットの意味を考えた。
・これで量をコントロールしてるんじゃないか。
・カードが無くなると入れない。これってWIP（Work In Progress）制限じゃん。
・これをみて、製造業じゃなくてもかんばんは使えそう、と思った。
■カンバンの誕生
・量のコントロールが今日は重要。
・安定した開発をしたい。より良い作り方があるんじゃないか？
・「Drum-Buffer-Rope」とは、みんなでロープで繋いで歩いていく方式。これだと、一人だけ早く、とかできない。
・タスクボードとかスクラム版はカンバンシステムではない。
■リーンカンバン
・リーンカンバンは、縦に割ったり横に割ったりする。
・ゆるふわ原則が４つある。
・プラクティスは6個ある。昔は5個だったらしい。
■作り方
・タスクボードとかスクラムボードなど、いつものカンバンは、デービットさんは「カンバンじゃない」と言っている。
・リーンカンバンにするために一歩進化させる。
・ToDo, Doing, Doneの他に、AnalyzeとTestを追加して、更にDoingをDevに変更して、合計５区画にする。
・更に、AnalyzeとDevにもDoingとDoneを付ける。
・更にWIPを制限する。
■使い方
・POは機能を選ぶ（Pull ＝ 引っ張る）だけ。
・その時点でタスクはアサインされていない。
・イテレーションという概念がない。
・機能の開発は完了したら次の機能へ。
・ジャストインタイムに近い。
■さいごに
・見える化のためにやる。見える化は何のためか、まで考える。
・開発チームが枠を超えてテストチームを助けに行く。
→ カンバンの境目を超えろ。
A-5 Agile2013報告＋鷲崎先生講演【講演】
http://xpjug.com/xp2013-contents-a5/
道場主のAgile2013聴講報告あり。
横浜道場ではなんも言ってなかったのに・・・w
■D-6 アジャイルセンター試験：解説・発表編【その他】
http://xpjug.com/xp2013-contents-d6/
午後一で受験したアジャイルセンター試験の解答解説です。
まこぴ、一番最初に答案をマチコ先生から返却されましたが、渋い顔・・・
うーむ、６１点。
平均点が６４点らしいから、３点足りなかった・・・
このイベント、なかなか注目度も高かったようで、Togetterにもまとまってます。
Togetter
http://togetter.com/li/564194
出題者もアジャイルで著名な方ばかりで、解答解説もアジャイルサムライの西村さんとか、豪華でした。
こーゆう取り組みは面白いですねぇ。
珍回答とかもチラホラ紹介されてて、楽しいヒトトキでした。
アジャイルセンター試験の問20。JUnitの開発者＆デザパタの著者の名前を答える問題の解答が分からず、自分の名前を解答欄に書いて提出したら、解説時に珍解答として晒されたのは良い思い出として刻んでおくことにする・・・ｗ #xpjug
— makopi23 (@makopi23) September 14, 2013
■A-7 LT祭り【LT】
http://xpjug.com/xp2013-contents-a7/
今年もLT祭り！
去年のLT祭りは面白かったなぁ。今回も楽しみ！ #xpjug
— makopi23 (@makopi23) September 14, 2013
今年は13人で、一人5分なので1時間ちょいかな。
楽しいヒトトキでした。
特に佐野さんのラグビーの話とか、印象深いですねー。
おーなるほどなぁ、と感心したり。
XP祭りはLTで締めるのが良いですねぇ。盛り上がります。
そして最後に参加者への書籍プレゼントタイム！
@makopi23 は最後の方になって、以下の書籍をいただきました。
Rubyの書籍、いただきました。ありがとーございます！ちょうどRailsをかじりだしたトコなので、利用させていただきます〜 #xpjug pic.twitter.com/QijA1El2se
— makopi23 (@makopi23) September 14, 2013
ありがとーございます。
ちなみに @t_wada さんからもコメントが！
@t_wada おお！そうなんですね～、是非読んで写経してみようと思います！
— makopi23 (@makopi23) September 14, 2013
今年はほぼ全員に書籍が行き渡ったようです。ありがたい！
★感想：
今年のXP祭も、とても有意義でした。
午前のセッションでは、XPの講演を体系的に聞けたし、SEMATも初耳で参考になったし。
午後はカンバンも、アジャイルセンター試験も、Agile2013報告も、LT大会も、どれも濃い内容でした。
新しい知識が得られたのもそうなんですが、やっぱイベント自体が楽しいのが良いですね～
来年も楽しみです。
講演者さん、スタッフさん、会場提供者さん、皆様ありがとうございました。
- 関連記事
