DevLOVE HangarFlight Ruby編「あなたの話が聞きたい。」のこと
きょうから RubyKaigi ですね。行かれる方はお気をつけて。
さて、去る7月6日に RubyKaigi Advent Calendar の一部として DevLOVE HangarFlight - Ruby編「あなたの話が聞きたい。」 を開催しました。詳細はリンク先の DevLOVE 公式ブログを見ていただくとして、ここでは開催に至るまでの経緯とかを書いてみようとおもいます。
はじまり
- 1月ごろに @bash0C7 さんから RubyKaigi Advent Calendar を DevLOVE でやりたい！というお話があった
- でも、@bash0C7 さんは RubyKaigi の準備でいそがしい
- DevLOVE の人だれかやらない？
- ・・・（手を挙げる）！
- それじゃ @kakutani さんに紹介するよ
という流れがあって、今年のデブサミでたどたどしい挨拶を @kakutani さんにしつつ、こんなことをやりたいですという話をしたような気がします。はっきりいって緊張しすぎて何を話したか覚えていないのですが、大筋では最終的なイベント内容とずれていなかったような気がします。
たぶん自分の思いとしては、好きな Ruby で 4tate した人の話が聞きたかったのでした。
わたわた
自分のはっきりしない思いが形になるまでは、わたしの力不足もあり、かなり時間がかかりました。なんとか最終的には extreme なダブルイベント開催となりましたが、6月に入るころは本当に開催できるのか、プレッシャーで気が気ではなかったのを覚えています。w
ダブルイベントの先輩はこちらです。DevLOVE Birthday! 〜RubyKaigiの帰り道に生まれしもの〜
わたしが余りにもワタワタしていたためか @DiscoveryCoach さんが会場やスピーカの手配、ダイアログファシリテーターとしてのご参加など大幅に手助けしてくださり、@bash0C7 さん、@papanda さんにも助けられつつなんとかアウトラインをつくっていけました。みなさん、ありがとうございます。わたしの人生のほとんどは他人の手助けでできています。
ただ、最初にこのイベントの開催でご相談させていただいた @yotii23 さんには、なかなかまとまらずご迷惑をかけてしまいました…。うまく進められなくてごめんなさい。
また、@changeworlds さんにはわたしが Redmine プラグインをつくったときの話が聞きたい！とお願いした際、いろいろと貴重なアドバイスをいただきました。それは彼の講演にもあった「非忠誠の誓い」にもつながる内容でした。あれがなかったら、いろいろな人の話を聞きたいというわたしの思いは折れていたかもしれません。大きな感謝を。
それから、懲りずに見守ってくれたわたしの家族に、最大の感謝をおくります。
かいさい
そんなわけで（どんなわけで）さまざまな方の手助けがあって無事に開催されたわけですが、もう録画の手配ができなかったことが残念でたまらないぐらい素晴らしい内容でした。こうなると、ビデオカメラが欲しくなりますね（！）。ぜんぶの方に謝辞を書きたいのですが時間が・・・！！ひとまず今日はここまで。
DevLOVE 我々は、現場から学ぶ。 〜パターンマイニングの実践〜 に参加してきました
6月23日に開催された「DevLOVE 我々は、現場から学ぶ。 〜パターンマイニングの実践〜」に参加してきました。
無数の開発プロジェクトがあるように、開発の現場にということで、鷲崎さん・羽生田さん・本橋さんによる、「パターンマイニング」実践ワークショップを通じてその方法を学ぼう、というのが本イベントの趣旨でした。
眠るノウハウや定石もまた、無数に存在するはずです。
これらの経験が、活かされることなく、プロジェクト完了とともに
埋葬されるに任せるのは、あまりにも甲斐の無い話だと思いませんか。
では、具体的にはどうすれば体験を活かすことが出来るのでしょうか。
ワークショップは「協調型マイニング」という手法で行われました。以下、個人的なメモです。誤り等ありましたらご指摘下さい。
パターンマイニングって？
- パターンとは、特定の状況で繰り返しおきる「問題＋解決」のこと
- パターンは名のない質（QWAN）を備えている
- パターンを知っていれば、同じことで何度も悩まなくてすむ（＝これ、前にもあった！）
- パターンマイニングとは「経験」を抽象化して、パターンを掘り出すこと
- パターンの効果範囲と効き目はトレードオフ。ある状況に特化しているほどよく効くが、適用できる状況は少なくなる
協調型マイニングとは？
- 数名一組でパターンマイニングを行う手法
- パターンを抽出するドメイン（特定の問題領域）を決める
- それぞれの成功体験を付箋に書く
- 書いた付箋を貼りながら他の人に説明する。このとき、似ている内容の付箋は近くに貼っていく
- 初期状況、アプローチ、結果
- 似ている付箋どうしからパターンを抽象化できないかみる。できそうなら付箋に書いて貼る
- 状況、問題、フォース、解決、結果
- パターン名をつけてまとめ、全員に発表！
最後の「フォース」というのはスターウォーズ用語で、パターンマイニングの肝となる部分だそうです。説明を聞いたときは正直よくわからなかったのですが、つぎのワークショップで明らかになりました。
協調型マイニングの実践
ここからは５人１組となって、実際にパターンマイニングをやってみました。
講師の鷲崎さんより「お題」がいくつか出され、グループごとにそれを選択します。このお題が前項でいう「ドメイン」となります。ちなみに、私のテーブルでのお題は「転職」でした。他にも「勉強の仕方」「通勤」「読書の仕方」などなど。
あとは前項の手順に従ってみんなでパターンを抽出していきます。
貼られた付箋のようす。みなさんの体験を聴くだけでも、かなり勉強になりますね。
スライド説明のときに謎だった「フォース」ですが、ワークショップでの説明によって「この状況、この問題で、なぜその解決を選んだかの理由」だとわかりました。そしてこのフォースを抽出することで、いっけん似ているパターンもさらにブレイクダウンできることが判明したりするのだそうです。
フォースの抽出によって、パターンが真に使えるものに変わるのだな、と感じました。
最後に、すべてのテーブルで結果発表。パターンの名前付けにも個性が。私たちのグループで導出されたパターンは以下のようなものでした。
- パターン名：めぐりあい
- ドメイン：転職
- 状況：自分の将来が不安
- 問題：新天地を見つけたい
- フォース：
- 社内では情報を得にくい
- 転職エージェントは堅い
- 社外ならざっくばらんに聞ける
- コミュニティのことは知っていた
- 解決：コミュニティで情報を集め、新天地を紹介してもらう
- 結果：新天地にめぐりあえた
感想
たいへん面白く、そして有益なワークショップでした。これを職場でやってみたらさぞ刺激的でしょう！欲を言えば、他のテーブルの結果が見られるとよいなと感じました。
講師のみなさん、DevLOVEスタッフのみなさん。ありがとうございました。
- 作者: 中谷多哉子,青山幹雄,佐藤啓太
- 出版社/メーカー: 共立出版
- 発売日: 2001/05/15
- メディア: 大型本
- クリック: 2回
- この商品を含むブログ (2件) を見る
ジュンク堂トークセッション「システム開発の未来―システムと組織を同時に変革する―」に参加してきました
2011年6月9日に、池袋ジュンク堂書店 4F 喫茶で行われたトークセッション「システム開発の未来―システムと組織を同時に変革する―」に参加してきました。
エリック･エヴァンスのドメイン駆動設計（いわゆる DDD 本）を翻訳なされた和智さんと、フューチャーセンターファシリテータの野村さんによる、参加型対話セッションです。
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (130件) を見る
以下は、わたしの個人的なメモ書きになります。あまりまとまっていませんし、自己流解釈となってしまっている箇所もあると思います。
大きな課題
- 日本のシステム開発、どうなっちゃうの（和智さん）
- フューチャーセンター について（野村さん）
問いかけと話し合い
1. システム開発の課題って？
- 「ユーザ or 開発者の言葉がよくわからない」
- 組み込みハードを作っているが、ソフトウェアの人と話しが通じないという悩みがある
- 業務システム発注をしているが、仕様を伝えても理解してるのかしてないのかわからず、あとでトラブルになる
- 仮想アイドルが流行ったとき、CGを学ぶ若者に制作を頼んでもイメージがうまく伝わらないことがあった。数値で言えば伝わるが…
2. どこのコミュニケーションがうまくいってない？
- ユーザも開発者も、すべて！
- ユーザ側の意見をとりまとめる人がいないとうまくいかない
3. システム開発にどんな夢がある？
- システムを通じて社会を幸せにしていきたい
- ユーザと開発者の共同作業としていきたい
DDD について（和智さん）
- 「ソフトウェアを作る上で、ビジネスパーソンと本当に協力していきたいと思うなら、この本を読みなさい」 by エリック・エヴァンス
- 顧客のビジネスを理解せよ
- 顧客の言葉で理解せよ
- その先にある「モデル」を理解せよ（※顧客がビジネスに対して持っている全体像）
- ソフトウェアは、モデルに従ってつくれ
- ソフトウェアは話し合いながらつくれ
- ソフトウェアは、育てるもの
- 顧客のビジネス全体のことを考えよ
- 実装してみるとモデルの矛盾に気づくことがある。ユーザにフィードバックするとよい
- …という話しは、当たり前のこと。しかし、実践はむずかしい
- なぜできないのか？
- 大きなコスト、承認のプロセス（予算、稟議…）
- それで本当に幸せなシステムができるのか？
- 開発者が頑張るだけではダメ。ユーザも変わる。
- 組織に、コミュニケーションを重視する風土が必要
DDD と組織論（野村さん）
- いまの和智さんのお話、組織論とどう関係ある？
- ゲーム会社では DDD が当然となっているが、システム開発ではできないことが多いと聞き、何か問題があるのではと思った（参加者の方）
- 自分自身（野村さん）がこうかなと思ったことをお話します
- 自社でナレッジマネジメントの研究をしていた。ラベル付け替えではなく、本当のビジネスにしようとした
- 組織の中の「価値」ってなんなのか？
- IDEO からは「チームがもっとも大事なことを知っている」というやり方を学んだ
- しかし、承認のプロセスに阻まれてしまった
- 会社を変えないと、いいものを世に出すこともできない。→フューチャーセンターへ繋がる
- フューチャーセンターをやる
- ゲーム作りのように普段の仕事をする
- みんなで参加し、アイディアを出しあって手を動かせば「自分ごと」だと思える
- 「自社のためだけに（商品を）作っていたら、会社は駄目になる」
- 新しい文化を持ち込まないとダメ
- 日常で行っている、そのプロジェクトのやり方自体を変えよう
質問タイム
- 企業の人はフューチャーセンターになぜ来てくれるのか
- 空間、ファシリテート、方法論のパッケージを求めている
- コミュニケーション不全は日本の組織の共通課題（縦割り組織、タコツボ化？）
- 「暗黙の仮定」を壊さないといけない（納期を守らないとクビになる…とか）
- システムの一部にならない、と決めた人がシステムを変えていくだろう
- 隣の人がやってるからやる、という人はそのシステムに加担している
- 辞めるつもりでやる
- 会社の枠を外して考える。会社のリソースを使ってやろうぐらいの気持ちで。
- 新しい企業とお会いしたらまず「ゲリラ戦士」をさがしている
- ゲリラ戦士とは、自分の立場を破壊してでも、組織を変えたいと思っている人
- 保身しながら会社を変えることはできない
- ゲリラ戦士を褒めてくれるのは、ゲリラ戦士だけ。でも、トップは見ていてくれるかも…？
- 会社を変えるための、もうちょっと安全なヒントをもらえませんか？
- 社長をフューチャーセンターに誘ってみる
- 「あなたの知識が必要なので、フューチャーセンターに参加してくださいますか」
- 反応ないなら諦めた方が…
- 社長の限界は、会社の限界（！）
DevLOVE HangerFlight Spring Bomb に参加しました
昨日の HangerTalks の熱が冷めぬまま、本日 2011/5/21 は DevLOVE HangarFlight - Spring Bomb - に参加しました。
詳細は Togetter をご覧ください。以下は、感想を。
講演の感想
当日は裏方メインで、講演は、やきとりいこと鳥井さん @yotii23 の「はったり活用法 - より高く飛び，そして帰還するために」のみ（司会として）聴かせていただきました。
仕事でお客さんと話すとき、自分の説明できないことを聞かれて慌てるシーンはよくありますが、そのときのベストプラクティスを「はったり」という観点から分析してまとめていて、ちょっと、このユニークな分析は他にはないのではないか、と感じました。また、そのときにはったりを活用する理由が「保身」ではなく「お客さんと良い関係を築き、よいサービスを提供するため」というのも素敵でした。
個人的には、かつて小さい受託システムで、要件定義から運用保守まで全部担当した時のことを思い出しました。。。最新の技術動向に、お客さんのほうが詳しかったりするとかなり冷や汗が出たりしますよね（ははは・汗）。
最後に、DevLOVEからの無茶ぶりを快く聞いていただき、ありがとうございました！！
イベント雑感
昨日の HangerTalks につづき裏方としての参加となりました。おもしろそうな講演ばかりで耳がダンボになったりしつつも、この場を作っている充実感というのもあり、本当に不思議な体験をしているなあと。いま、我々が体験していることは一体何なんだ？ わかりませんがすごい疾走感です。
今回も参加者の方においしいお菓子をいただきました。いつもありがとうございます m(_ _)m
さいごに
スピーカーの皆様、参加された皆様、ありがとうございました。裏方の皆さま、お疲れ様でした。みなさまのフライトの成功を心より願っております。
おまけ
会場で見かけたいろんなでぶっち。
DevLOVE HangerTalks に参加しました
2011/5/20 に開催された DevLOVE HangerTalks 〜空を飛ぶのに、翼の1本や2本折れたところで。〜 に参加しました。
今回は、DevLOVE スタッフである「こしば」さんと「ちゃちゃき」さんのお二人よりお話を聞きつつ、参加者全員で対話を行うというものでした。詳細については、Toggeter をご覧ください。
イベントの雑感
お二人の講演が、いつになく心にしみる内容でした。自分の中の自分にとって重要な問題を、自分の考えで解決していく話。まさに "あなたの話が聴きたい" を地で行く、すばらしい講演でした。最後の参加者ダイアログも含めて。
お二人の、印象に残った言葉です。
- 希望をなくしたら死ぬしかない。希望さえあれば生きていける。（こしばさん）
- 今よりよい未来を、大事な人のために。（ちゃちゃきさん）
主観による紹介LTをしました
今回は、お二人のお話の前の「紹介LT」群にまじって、こしばさんの紹介LT をさせていただきました。
といっても、私の「こしば歴」はまだ半年。このようなご紹介をする事におこがましさも感じましたが、それでも、これまでこしばさんと接していて少なからず感銘を受けた部分について、余す所なく盛りこんでみたつもりです。似顔絵が（見ないで描いたという言い訳をもってしても）似てなさすぎる点はご容赦ください。
Developers Summit 2011 のこと
なかなか書けなかったのだが、少しだけ。2/17〜18 に開催された Developers Summit 2011 に参加したときのことを。
デブサミは、今年が初参加である。2010年になるまで私はそもそもこうしたイベントや勉強会などに参加したことがなかった。いや、カンファレンス系のものに出たことはあったのだが、たんなる傍観者の域を出ず、けっきょくすべてのスキルは自習以外では身につかないと考え、興味自体を持つことがなかった。
しかし、2009年のリーマンショックを機会に、IT勉強会に参加。その後、とりつかれたように参加しまくり、あれよあれよというまに、2010年の末にはとうとう DevLOVE スタッフの仲間入りをさせていただいた。
そして KDI 野村さん @nomutaka と共におこなう参加型セッションの企画、帆立て (#4tate) のこと、デブサミ配布しおり の作成。
企画を通して、わたしは徐々にデブサミがどういうものであるのかをおぼろげながらも知ることになった。主催者である岩切 @kohsei さんの想いの強さ、9回もこの奇跡のイベントが続いていること、@papanda さんをはじめとするすでに参加した皆さんの、デブサミに対するそれぞれの想い。
私はそんな想いを感じながらの初参加となった。セッションは以下の 6 つしか聞けなかったけれど、幸せな参加であったと思う。
- 【17-E-1】DBも進化せよ〜変更に強いDB開発方法論を導入するためにJiemamyのチャレンジ
- 【17-B-5】今そこにあるScrum
- 【17-E-7】デブサミオフィシャルコミュニティから選出のLT大会2011
- 【18-D-1】これからのRIAの話をしよう 〜システムの利用者と開発者にやさしい、UXとUI設計について〜
- 【18-B-3】これからの「アジャイル」の話をしよう ――今を生き延びるための開発手法とスキル
- 【18-B-7】未来のために私たちの帆を立てよう
どれも、素晴らしいセッションだった。地豆の思わず使ってみたくなる素敵な紹介とその場リリース、豊富な経験に裏打ちされた質疑応答が圧巻の「今そこにあるScrum」、世界の広大さを感じたLT大会、容赦ない内容の濃さで攻めるRIA、腹をくくった「アジャイル」の胸が熱くなる話。すくすくスクラムの OpenJam も楽しかった。
そして、最後の 18-B-7 で参加者のみなさんの掲げた色札を数える「野鳥の会」をしながら、わたしは考えた。デブサミは、開発者という人々の「想い」に焦点を当てる、稀有な場であるのだと。
この場を創りだしたスタッフの皆様と、スピーカーの皆様、当日お会いして話をしたすべての参加者の皆様に、感謝。
初デブサミを終えて、わたしは今、自分のまわりに横たわる「なぎ」の海で、帆を立てて航海することができるかを模索している。この日を無駄にはしたくない。
2011年は、Rails3を使おう！〜masuidriveに学ぶ に行ってきました
1/12 に開催されました 2011年は、Rails3を使おう！〜masuidriveに学ぶ に行ってきました。
Rails3 について概要がざっくりわかり、なかなか良かったです。懇親会には出られませんでしたが…
追記：当日のつぶやきをまとめました。http://togetter.com/li/88929
以下、自分用メモです。ちっともまとまっていません。
1. Rails3情報源の歩き方 @knsmr
- ASCII, @IT, Matzの追っかけ, Google, そしてRails
- 英語圏だと情報がすごく多い
- エンジニアはもちろん英語を読めたほうがいい。TOEICはペースメーカー。800点後半で講演がわかるなど
- まずは公式サイト, Screencasts おもしろい, Document/Guides 他の本はいらない？！ APIリファレンス, 公式アナウンス
- EdgeRails はちょっと更新が止まってる
- もっと追いたい人は公式リポジトリ github rails/rails
- 公式BTSはスパムが増えて追いづらい
- Githubは宇宙！ Rubyコミュニティはつながる。PHPは島宇宙
- ウォッチャー数とフォーク数が人気度の指標
- よさげなプラグインは Asakusa.rb できく
- Ruby Toolbox ジャンル別に検索できる
- それってRails3で動くの？ メジャーなものはけっこういける
- Screencast が豊富。Railscasts は毎日更新, 文字で読みたい人は ASCIIcasts, 公式サイトにRails3で変わったことガイドがあるので必見！
- Rails for Zombies
- Rails3 cheat sheets
- Ruby on Rails Turorial PDFのほうが読みやすい
- 公式 Rails Wiki 和訳は追いついてない
- Confreaks カンファレンスをウォッチする
- RubyConf, RailsConf, RubyKaigi RuRuKo
- OSSは人が作る
- 海外のオンライン媒体。RubyInside おすすめ。Engine Yard ブログ, 息抜きにRuby Quicktips
- はてダのRuby, RailsをRSSに登録するのもいい
- るびま
- ML: Ruby on Rails Talk 流量多いので検索する
- StackOverflow もよい
- RailsBridge コミュニティ？
- Rails勉強会東京, 関西
- 日本語による情報は少ない！@IT の Rails Hub でやっていく
2. Rails3を使おう！ @masuidrive
- おさらい, Railsの歴史
- Rails の特徴 CoC, DRY, MVC, Full stack, Generator : Write less code
- Rails 1 から 2 になって使う人が増えた。1のころはRubyプログラマ自体が少なかった。
- Rails 2 で変わったこと： RESTful, JSON, security (えらい先生に吊るし上げられる）, 多言語対応, パフォーマンス改善
- Rails 2 の問題。複雑すぎる（コードが多い）、遅い、プラグインがすぐ非互換になる、環境構築（レンタルサーバにない、依存関係が厳しいなど）
- 2のあとの流れ。Yet another Rails 的な
- Sinatra シンプル
- Merb + DataMapper モジュール差し替えの自由があるが不安定（非実用）
- Merb gets merged into Rails in 2008. モジュール構造、Plugin API, MatzRuby以外でも動作する
- Passenger: Apache モジュール。１サーバで複数のRailsアプリの管理もかんたん
- Heroku: Railsクラウド. Railsを基盤としてビジネスする人の増加（米）
- そして Rails3
- Sexy になった = きれいに書けるようになった。hash 渡し→メソッドチェーン
- フルスタックだがモジューラブル
- Arel: ActiveRecordの新しいクエリエンジン。SQLのところを抽象化
- Bundler: gemの管理。
- Rails 2 を Rails 3 へあげるべきか？
- 最新のRailsは一番いいRails。プラグイン対応、安定性、マイナーバージョンを飛ばしてあげるのは大変 2.3→3.0のうちにやるべし
- 3.0.3以降で安定してきた by アーロン
- モジュール構造になるとメソッド呼び出し回数が増え、どうしても遅くなる。3.0.2以降で改善
- ActiveRecord: ActiveModel, SQLAdapter, Arel(ここだけいじって速度をあげた。モジュール化の恩恵）
- 2からのコード書き換え
- Rails 3 でかわったところ
- User.find --> User.where
- 表記の省略がおおい。すっきり書ける
- Bundler 簡単にコマンド１つでインストール。関連gemを全部いれてくれたり
- ERb: default HTML escape
- ActionMailer の位置づけ
- script/* ---> rails *
- respond_to :html, :json, respond_with(@hoge)
- ActiveRecord の lazy loading
- 3でプラグイン非互換が減るかも、とかいろいろ期待される
- Titanium mobile の宣伝がありつつ終了
- 質疑応答
- Q.Ruby のバージョンは？ A. 1.8.7 (1.9 も試してはいる)
- Q.Rails1 で動かしてるのはなぜ？ A.終了したプロジェクトで工数をかけられない
