読者です 読者をやめる 読者になる 読者になる

「DevLOVE HangarFlight - Snow Barrage -」へ参加してきた #devlove1210

勉強会

http://led.devlove.org/hangarflight/snowbarrage.jpghttp://led.devlove.org/hangarflight/snowbarrage_title.pngDevLOVE HangarFlight - Snow Barrage -

アイディア、ノウハウを持った人が
情熱を持って話してくれる
そして、それに惹かれた人が160人も集まる
そんなイベントが世の中には存在する

続々と集まってくるため、15分押しで開始
Oracleの会場(オープニングは、2部屋分)もは、満員御礼、立ち見が出るほどの盛況ぶり

参加したセッション

前説

  • 無限フリードリンク、しかし、レッドブルはない
  • ブログを書くまでが勉強会、DevLOVE

出撃の刻 〜オープニング〜HF趣意説明-Snow Barrage

かつて、飛行機乗りにとって、空が危険だった頃
飛行機乗りたちは、自分たちの体験を飛び立つ前の
格納庫(ハンガー)で語り合うことで、
未知なる空を知ろうとした

ソフトウェア開発もまた、未だ容易ではない
かつて、飛行機乗りがそうしたように
我々も、我々のことを語ろう

◆HangarFlight、しましょうか◆
私たちはこれから先どれだけのサービスやシステムを生み出すのでしょうか
人一人が経験できることには、限りがあります
また、経験とは行動を起こした人への唯一の報酬といえます
しかし、人が語る経験を耳にし、それを自分事として捉えなおした時、
自分にとっての新たな発見があるのではないでしょうか
かつて、命を賭して、空を駆けた飛行機乗りたちにあやかり
私たちも、私たちの空を飛び続けるために、HangarFlightしましょう

◆Snow Barrageの世界◆
今回のHangarFlightは、SnowBarrage
集まった語り手たちは、いずれも開発現場の前線を飛び回る
Reckless(命知らずの) Pilotです
彼、彼女たちから次々と繰り出され紡がれる物語から、まさに弾幕ともいえる
圧倒的な勢いを感じることでしょう
HangarFlightはその帰り道からが私たちにとっての、旅の始まりです
来年の春に、再びこのHangarへと帰りついて下さい
その時、みなさんのHangarFlightを私たちは待っています
  • DevLove = gembaのハブ

人が語る経験を耳にし、それを自分事として捉えなおす

  • gemba
                      A                         B      
        意識       プラクティス    ←     プラクティス
                     ↓                         ↑
        行動       具体的行動               具体的行動
                                              経験

現場Bでの経験をプラクティス化して伝える
聞いた側は、そのプラクティスをそのまま行うのではなく、
その自分の現場で実践するにはどうするればいのかを考えた上で
実践する

        意識      コミュニケーション不足  ← コミュニケーション不足
                     ↓                         ↑
        行動        夕会                      朝会

現場Bでは、朝会を実施したが、課題は-コニュニケーション不足
現場Aではの課題も-コニュニケーション不足だが、朝だと集まれないので

  • 夕会を実施する
  • DevLOVE Urakata 募集中
    • 求められるモノ:やり切り力、パッション
一生=たかが300人月、自分の時間を拡張するために、他人の視点を借りる

@ 川端光義 氏-普通のプログラマチームによるアジャイル開発と少数精鋭によるアジャイル開発

大阪都民の川端さんの発表

  • Agileの中では、XP が一番だと思っている
Javaプロジェクトの事例
XP知らない人〜、手が上がった人がいるのは時間的な都合でなかったことにして
  • ベンダー3社 Javaプロジェクト 40名1年間 500人月規模
  • 共通フレームワークチームだけAgile、あとのアプリケーション開発の2チームはWF(別ベンダー)
  • オリジナルで導入してたプラクティスはクレド
  • COBOLからJavaへの移行
    • 言語が変わるというだけではなく構造や考え方も変えないとならない
  • チーム構成
    • 共通フレームワークチームはJava経験者を集めた
    • マネージャーはCOBOL時代からいる保守的な人
      • 新しいものに対応するのに抵抗あり、そこがネック
  • それでもうまくいった
  • 成功の要因
    • 顧客のトップ(金融会社の専務取締役)がアジャイル開発に理解があった
      • 顧客のトップが週3日ぐらい本社ではなく、開発室にて仕事していた
      • 顧客のトップがシステムはインフラ、重要だという認識があったから
  • 問題
  • 実践した事1 クレド
    • リッツ・カールトンでは、クレド(信念、信条を記したもの)の読みあわせを行い、それに合わせてお客様にサービスする
    • 毎朝、アジャイルソフトウェア開発宣言、アジャイル宣言の背後にある原則の読みあわせを行った。
    • 読み合わせて、分からないところを議論
    • 実施できなかった部分は実施出来なかったからどうなったか、代替手段はなにかを議論
    • 夕方の5時、毎日15分
  • 効果
    • 指示待ち人間から自分から(別の)アプリチームへ積極的に打ち合わせしにいくようになった
  • 実践した事2 KPT
    • 2週間(1てレーション)に1回実施
    • 2週間ごとだと忘れるので毎朝メールで確認
  • 実践した事3 wiki
    • ドキュメントの90%はwiki
      • 共通チーム=ライブラリを作る、分かりやすくアプリチームに使ってもらうため
      • すぐにアプリチームに伝えるために全てをオープンに
  • 実践した事4
    • 週40時間
  • 抵抗勢力の登場
    • 変化を嫌う他のベンダーのうち1社
    • 新しいやり方に反抗やり方や見積もりにケチをつけてくるようになった
    • ある日、Wikiがすべて消える!!!!
    • 悪魔の声:絶対やつらの仕業、嫌がらせしてたあのベンダー
      • 今も同じ仕事をやっていれば間違えなくこの場で社名も言ってるだろう
    • 天使の声1:1週間前のバックアップならありますよメンバー
    • 天使の声2:1週間ぐらいの内容なら頭の中にありますよ
    • 全員で復旧、僕は、1時間ごとにバックアップするように
    • 団結力を上げたかったら、まずWikiを消せ
Rubyプロジェクトの事例
  • Rubyに恋を落ちた
  • Rubyやってる人、いいですね東京多いですね大阪少ないんですよね
  • RubyAgileは、ビールと枝豆ぐらい相性がいい
  • Rubyistはスキルが高い、でも個性が強いバランスボールに乗って仕事してる人とか
  • Macユーザが多い

この部屋もWindowsユーザー少ないな

  • XPのプラクティスが合わない
    • ペアプロ?嫌ですよ〜
    • コミュニケーションが上手くいかない
    • リファクタリングは自由にやっている
    • 常駐無理ですわー、在宅じゃないと嫌です→全員同席:無理
  • コーディング規約
    • タブ文字はスペース2文字だけ。みんな優秀なので、勝手にできるんで
  • ペースもバラバラ
    • 6時間の人、
    • 夜中に働く人
    • 何時間でもいける人
  • 重要
    • 計画ゲーム
    • シンプル設計
      • できる人たちは、オレオレ仕様(オレの考えた方がいいだろう)で変えてしまう、ブレて違う方向に行ってしまうそこは違うと説得
      • 汎用的に作ってしまうので、そこは後から追加用件でお金もらえるのに・・・
  • 3日のタスクと見積もったものが、3時間(テスト付き、リファクタリングされたものが)でてくる
  • Cucumber:受け入れテストの自動化のデモ
    • あれ?不可で落ちてるな・・・www
    • ビデオチャットで青森の人に修正依頼!

これ仕込み??

    • やべー(デモが)間に合わねー、なので後で
  • Cucumber:日本語で書ける受け入れテストが自動化できる

表示されてるテストコードは、GroovyのSpockみたな感じに見えたなぁ

  • コミュニケーションツール
    • PivotalTracker
      • D&Dで操作できるチケット管理、
      • 上が最優先
      • スマフォでも簡単に操作
      • 秘密事項なので項目はあまり見せられない
    • Redmine(Wiki)
      • Javaの事例で出てたので省略
    • IRC
      • リアルタイムのコミュニケーション
    • Skype
      • 仕様をしっかりと伝えるには、顔を見ながら話せた方がいいので。IRCとの住み分けはそこ
    • ML
Androidプロジェクトの事例
  • AndroidはScalaを選択
    • 出来る人のモチベーションを上げるために、何やったら面白い?という感じで技術者に選んでもらっている
  • プログラマにコミュニケーション能力は不要、
    • 逆にあえて不要じゃないかなと考えてる
    • すごい人たちは生産性が10倍とか
    • 家にこもってやってる人たちなので、コミュニケーションできなくて当然
    • 間に入ってる人が、プログラマがフルに力を発揮できるようにサポートする

凄腕のプログラマ=家にこもってるってのは偏見だと思うんだけどな。





@ Kenichi TAKAHASHI 氏-Jenkinsの運用を中心にRailsとCI(とサーバ仮想化)について

  • ほんとのタイトルは『ビルドを大事に』
自己紹介
  • RubyRuby on RailsGentooVim、タイル型MW、ソーシャルプログラミングが好き
  • Ganetiで構築した仮想サーバ上で、Jenkinsが稼働中、次の一手としてTravis CIの導入を予定している
使ってきたCIの遍歴
  • 今までつかってきたもの、CrusizeControl.rb、Jenkins、Signal、Integrity、BigTuna
  • 2008年
    • CIがあれば幸せだった
  • 2009〜2010
    • 第一次CI大戦なぜ使い分けるか?
      • RubyでJnekinsだとちょっとしんどかった
      • Rubyで自分たちでカスタマイズできるもの
      • マシンが遅かったのででスローテスト問題が発生
  • 2010年後半
    • Rails 3、Bundler、RVMなど新しいものが出てきて、未対応のIntegrityが脱落
    • 空いたMacMiniでプロジェクトごとに仮想サーバを用意
  • 2011年初頭
    • Jenkins、BigTunaの2強
    • BigTunaはRails製なので自分たちでメンテナンスできるから使ってきた
      • 実際は僕ともう一人ぐらいだけど
  • 2011年後半
    • Jenkinsの一人勝ち
      • 6プロジェクトで導入、
    • 初のプロジェクトへ導入
    • 仮想サーバクラスタ構築(Ganeti)、プロジェクトごとに仮想サーバ構築
  • 言語やフレームワークにあったCIサーバ、限られた資源でうまく回せるCIサーバを求めてきた
GanetiとIRC
  • インフラ:Ganeti
  • コミュニケーションツール:IRC
  • Ganeti:分散仮想サーバクラスタ
  • IRC:JenkinsからIRCへ通知、全てのJenkinsが集う
    • Nicknameはプロジェクト名
    • PrefixはIRCのMention形式 (プロジェクト名:)
    • IRCで状況を見て、コマンドを実行
      • プロジェクト名:status
      • プロジェクト名:build master
    • 黒塗りの資料(IRCのログ)
  • Ganetiで本番環境に近い環境構築、IRCでJenkinsさんと会話
  • 効果
    • PivotalTracker、Jenkinsも開発者も、IRCIRCを見ながら開発(コードとテスト)に集中できる
  • 導入事例2
  • 効果
  • 納品物はJenkinsがビルド、コンパイルしたものと本番環境でコンパイルしたものが違うということが少なくともなくなった

PivotalTrackerとCucubmerは、またでてきたRubyだと普通なのかな

  • テストにまつわる諸問題と戦うパートナーとしてのCI、
    • 手元では通ってたのにパターンを早期に発見できる
    • 上記の問題に悩まなくてすむのがありがたい
    • Jenkinsのマシンは専有できるので、時間がかかるテストを実施できる
  • Ganetiで自由な環境を低コストで提供、IRCでJenkinsとコニュニケーション、言語・フレームワークを超えたノウハウの蓄積(RubyJava)
これからのCI環境
  • Travis CI、github上のプロジェクト専用のCIサーバ、ビルドを仮想マシン(VirtualBox)上で実行
  • github上で、オーガニゼーションライセンスだと、プライベートリポジトリが作れる永和ではgithubにを移行を試みている
Q&A
  • Q.スローテストの問題解決方法は? カテゴリ分けなど
  • A.マシンを新しく買う
  • 外部にアクセスするテストなどはCIだけで流すように設定
  • スローテストを早くする
    • DBの設定などは事前にSQLベタ書きなどで用意してしまう
  • Q.rvmを無理やり使っているように感じている
  • A.rvm使わなくていいのなら使わない本番環境の都合でrvmなら、テスト環境もrvmにする

荒ぶる四天王決定戦 時間!コスト!品質!スコープ!最も荒ぶるモノは何か 今宵、真の荒ぶる四天王決めようッ!!

荒ぶる四天王を4つの部屋ごとに分けて、こういうことが必要だったんじゃないかという内容を模造紙に貼っていく
貼り出してみればだいたい分かると思います


細かく写真を取ってた方がいたので、Upされることを期待。





@ Hiroki Kondo 氏-DevLOVEで学んだ事を現場で広めるための48の戦略をFearless Changeから学ぼう

宿題

『やりたいことアイディア』を配った紙に書いてください。

  • Hiroki Kondo 氏が言った例「会社でもGroovyでコード書きたい!!」
タイトル
  • パターンといういうとわかりにくいので、戦略とした
  • タイトルの48個は釣りでした
    • 48個だと多いので、今回は8個に絞る
      • Evangelist
      • Just DO IT
      • Test the Water
      • Innovator
      • Ask for Help、
      • Just say thanks、
      • Time for Reflection、
      • Step by Step
    • 書籍は48個、書籍に載せられてないものも追加されていってる
  • DevLOVEで真っ先に取り上げられそうな内容だが、まだ発表されたことがなかった

Fearless Changeって本のタイトルだったんだ

  • 訳書はでていない
    • 川口さんがだそうとしている。
  • Fearless Changeの読書会もやっているよ
  • Lindaさんの基調講演も川口さんがYoutubeにあげている
1番重要なパターン Evangelist/Energizer
  • Evangelist
    • 新しいアイディアを情熱と共に伝えられる人
  • Energizer
    • 新しいアイディアと情熱を伝達させられる人話しを聞いていると元気になる人
    • Evangelistが営業の人の肩書きになってしまったので、誤解を生まないように設けられた。
    • Energizer の例 @papanda
    • Evangelistになるのは難しくない
    • まず自分でそのアイディアの良さを実感しましょう
    • 何がいいのか説明できない
    • 良いアイディアと信じられれば自然と説明に熱がこもってくる
    • 今情熱が足りないのでレッドブルでチャージします

ここでもRedBull飲むデモンストレーションかw

    • 論理的な説明よりも情熱(パッション)大事
Just DO IT:ちょっと試してみる
  • 情熱を持った人の気持ちが伝わったら、他人の情熱を自分が感じたら、ちょっと試してみる
  • 目的:効果と制限を感じる
  • 例 BootCamp、ワークショップ系のイベント、一人でこっそり
Test the Water:現場の反応を試して見ること
  • お風呂入るときに、足をちょこんといれてみること(だと思っている)
  • あんまりがんばらない形で広める無理強いしない全てのアイディアはみんなのために
  • 信頼貯金を貯めるために、全てのアイディアはみんなのために
  • Test the waterの活動例
    • 昼飯時に誘って仲間に話してみる
    • yamamerとかに書いてみる
  • 1回だけであきらめず、何回か話題に出してみる
  • それって何がうれしいの?って聞かれたりするけど、うまく説明できなかったりする
  • うまみを伝えられそうになったら具体的な普及活動
Innovator:普及活動してくれる人
  • Innovator 100人中2、3人
  • 新しいモノが好き
  • こういう人たちを巻き込むとあの人がいいと言ってるなら、いいのかもと広がっていく
  • Innovatorは新しいアイディアに響きやすい
Ask for Help:助けを求める
  • 時間は有限、組織にアイディアを根付かせるためには、少なくとも、一人の時間では足りない
  • 助けてもらえたらお礼を言う
  • 気になる方は、『夫婦 ありがとう』でぐぐってみてください
Time for Refleciton:ふりかえりをする時間を確保する
  • よくあるのはKPT
  • 何がうまくいってたか、次はどうするべきかを考えるための時間こういうことがあったよねと気づく時間
  • ブログに書くまでがDevLOVEです これも、Time for Reflectionの一例
  • 反芻する時間、参加者が今後どうしたいか、次どうしようかと考えるこれが一番重要
Step by Step:アイディアを広める取り組みは少しずつ、気長に行きましょう
  • アイディアを広めるのは想像以上に時間がかかる@kanu_の例 Tracの導入するのに3年かかった、引き継いでくれる人がいなかったなど
  • うまく広がって行ったらDevLOVEの渾身会で話しましょうそしてDevLOVEで前に立ちましょう
  • もし、くじけそうになったら、DevLOVEには思いを共有できる戦友がいる
  • 他の人が興味があるアイディアじゃないとだめ、自分がやりたいだけでは広まらない
  • 失敗しても血肉となる『失敗は学び』
  • 僕自身この資料をまとめて Ask for Helpが足りないと気づいた
  • 興味があれば、Googleグループへ
  • さっき書いた『やりたいことアイディア』を共に広めたい人の名前を裏にかいてください
  • 当たり前のように感じられる人もいるけど、体系的にまとめられたもの、パターン化されてるもの

こういうものもパターン化されてるということがが一番の驚きだった。

@ & @ 藤原大 氏-アジャイルで目指した坂の上の雲

  • 楽天主義 -optimism
    • もう半分しかない
    • まだ半分もある
  • 坂の上の雲:登っていけばやがてはそこに手が届くと思い登っていった、雲=クラウド
  • 共通認識を1つ作る
    • 誠とは言を成す
  • お互い背中合わせになるようにミーティングでは会話をしましょう
  • ツールの活用
    • wiki
    • タスクボードだと終わったらログが残らないので、mediawikiに行ってきた
    • yammer
      • 勉強会などはyammerにインスタントに流す

このボード、XP祭りのLTで動画流してたやつか

  • LineCoverage:98%、QA:Case1881、Bug:28
  • QCon、Agile Japanなどの勉強会に参加、Agile Japanにはマネージャー層にも参加してもらう
  • リリースすごろく

すごろくって、リリース以外にも展開できそうだな

  • ふりかえり Mgr:Agileが善、それ以外が悪になってしまった
  • 流れに乗るのに3ヶ月専門家を呼ぶのは必要
  • 新しい気づき、チャレンジする気持ち、みんなで聞く、みんなで解決する気持ち
  • 英語でプレゼン!とおもいきや最初のあいさつだけここまでが限界

あれそのネタ、社内のどこかで聞いたぞw

  • 三木谷著 成功の法則=アジャイル宣言 なんだ同じじゃん
  • しかし、もとに戻った
  • ボードも無くなり
  • Standup meetingもなくなり
  • WBSのエクセル管理
  • どうしてこうなった
  • Give Up Changing
  • ふりかえり Mgr 失敗は誰にもできることじゃない
  • 見える化はできたが、見せる化ができなかった
  • 次はこうしようという工夫
  • あきらめない気持ち
  • Action
    • 見える化+見せる化、
      • マネージャーはわざわざ見に来ないので見せる化が大事
    • 巻き込む
      • 一緒に笑って、一緒に苦しんで、巻き込む
    • Changeの成功体験を作る継続的Change、継続的challenge
  • 他人を変えることは難しい、まずは自分から変えてみよう

僕は他人と過去は変えられない、変えられるのは自分と未来だけ って言葉をよく使う
なんか諦めモードと捉えられることが多いんだけど
他人を変えようとがんばるよりも、自分を変える方が簡単。妥協の方向じゃなくていい方向にね

  • 個人からチームへ広げる
  • Doing 人単位 1人2個までしか貼れないようにする
  • ふりかえり、画像とグラフをたくさんでmediawiki
  • 自分はスケールしないので、組織でスケール
  • 世界を変える
  • 思いはつながる
  • 改善したいという要求をうけいれられないのは、モチベーションが下がるどんどん取り入れていくためのチームビルディングをとりいれていきたい

Q&A

  • Q.変わったきっかけ、
  • A.とことん喧嘩した
  • A.優先順位付けされていない指示が、直接メンバーにくるので、私(藤原さん)をすべて通してくれとお願いした

渾身会で、聞いた話

  • Qマネージャー層に勉強会に参加してもらうにいい作戦はあるだろうか?
  • A.喧嘩したときに、マネージャー、メンバー全員で議論
  • 特定の人を名指しで批判することになってしまうので、そこは上手く舵取り
  • 何が問題で、どう解決していくかに焦点を当てて議論
  • 解決すべき点については、マネージャーもメンバーも同じ
  • どのように解決するかについて議論するときにこういうやり方がありますよと。
  • 最初はAgileという言葉は出さない
  • 机の上にこっそりアジャイルサムライを置く

渾身会

米国産のRedBull(容量591ml)を初めて飲んだ件について
巨大RedBullを目印に@に出会ったー
顔とidが初めて一致したw



他のまとめ

Shinya’s Daily Report 『DevLOVE HangarFlight -Snow Barrage-』に参加してきた #devlove #devlove1210
終わった直後に公開するという進化を遂げた。スーパーまとめ職人に目覚めてしまった。


Seize The Day! DevLOVE Hanger Flightに行ってきた。
マインドマップ。こちらもイラストを入れるという進化を遂げている。


木綿豆腐。 DevLOVE HangarFlight -Snow Barrage- に参加してきました



俺たちのハンガーフライトと渾身会の分はもっと足したいな。
用があるので、とりあえずここまで。













高野 登、undefined、高野 登のAmazon著者ページを見る、検索結果、著者セントラルはこちら
価格: ¥ 1,575


価格は記載時点のものです。購入前にAmazonでご確認ください。









Mary Lynn Rising, Linda Manns
価格: ¥ 3,251


価格は記載時点のものです。購入前にAmazonでご確認ください。