makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

「Agile Conference Retrospective」に参加しました

2012/10/19(金) 「Agile Conference Retrospective」に参加してきました。

Doorkeeper(告知サイト)
http://esminc.doorkeeper.jp/events/1771

ツイートまとめ(ゆかりんノート)
https://yukar.in/note/ckFj1s

Agile2012 Summary(ManasLink)
http://www.manaslink.com/articles/4796

ハッシュタグ: #agile2012ja


会場は品川シーサイドの楽天タワーです。
参加者は40名くらいでしょうか。

先日10/3(水) にも「オブラブ Agile2012報告会」というイベントがあり、こちらも私、行ってきてブログにも書きました。コチラ
今回も2012年のAgile Conferenceの報告会という意味では、同じ趣旨のイベントですね。

ちなみに今年のAgile ConferenceはUSAのダラスで8月に行われました。以下は公式サイト。
http://agile2012.agilealliance.org/

最初に楽天の吉岡さんより「Rakuten Technology Conference 2012」のご連絡がありました。
http://tech.rakuten.co.jp/rtc2012/
ちなみにコチラは私の英語力が足りないため、参加は見送りました。無念。。。

以下は@TAKAKING22さんがツイートしてくださった当日のお写真。
agile_20121019.jpg


以下、当日のセッションのメモ。(間違っているところあるかもしれません)



登壇者の自己紹介

■大澤俊介さん
・Atlassian社で働いている。
・Twitter IDは@Sean_SF。ショーン、というカッコいい外人みたいな名前でやっている。
・帰国子女とかと間違えられるが、日本生まれのショーネンです(笑
・Agile Conference 2012で、Atlassian社もスポンサーとなっていて、Nicholasも参加していた。
・今回Nicholasが来日するということで、@papandaさんに無茶振りして、今回のイベントに至った。
・今回は、ニックの通訳として参加している。
・ダバディ(元・日本サッカー代表監督のフィリップ・トルシエの通訳)のような、意訳した通訳ではなく、今回は直訳を目指して頑張りたい(笑

■Nicholas Muldoonさん(本日は皆さんからニックという愛称で呼ばれていた)
・Atlassian社で、2007年から働き始めていてGreenHopperという製品のプロダクトマネージャをやっていた。
・去年からアジャイルエバンジェリストとして活躍している。
・オーストラリア人だが、シドニーからサンフランシスコに転勤になって働いている。
・日本に来られて光栄。

■安井力さん
・アジャイル自体は10年以上やっている。
・最近は、ボードゲームやカードゲームのようなものをつかってアジャイルの教育をやっている。

■上田佳典さん
・NECビックローブで、新サービスの立ち上げを担当している。
・それと平行して、大規模なサービス開発をどんどんアジャイル化していこう、という試みもやっている。

■松元健さん
・バンダイナムコスタジオで開発やっている。
・経営企画に近いポジションでスクラムマスターをやっている。
・スクラム道のスタッフをやっている。(スクラム道:http://www.taoofscrum.org/contents/
・スクラム道で今、みんなで本を書いている。来年のデブサミまでには、スクラムに関する本を出せるかな、と思っている。

■伊藤宏幸さん
・スクラムマスターを社内でやっている。
・先ほどちょうど、認定スクラムプロダクトオーナーの研修を終えて、急いでココにきた。
・ManasLinkさんで、Agile2012の記事を投稿している。 http://www.manaslink.com/articles/4796

■藤原大さん
・楽天で、社内の開発支援の部隊でマネージャをやっている。
・最近は小さめのPJのサポートとかアジャイル導入のサポートとかやっている。
・来月11月にコミュニティでアジャイルのイベントをやる。
 - AgileTourOsaka2012 in Minoh 箕面の滝からこんにちは
  http://kokucheese.com/event/index/55362/
 - Ultimate Agilist Tokyo - 集え、日本の活動家たちよ
  http://ultimateagilist.doorkeeper.jp/events/1823
  
■市谷聡啓さん
・本日の司会。
・DevLoveというコミュニティを主宰している。


本日のアジェンダ

■1.アナログツール vs デジタルツール
■2.日本 vs 海外
■3.Enterprise Agile
  ①トップダウン vs ボトムアップ
  ②チーム vs 会社
  ③現場 vs 経営 などなど
■4.アジャイル vs ウォーターフォール
■5.SI vs サービス


■1.アナログツール vs デジタルツール

●アナログツールについて 安井さん
・ホワイトボードと付箋とマーカーがあれば幸せ。
・簡単で、シンプルなところからスタートできる。
・チームごとに最適なツールを作れる。
 - 自分たちの仕事を、ツールを媒体として改善していける。

●アナログツールについて 松元さん
・Agile Conference 2012で、"ヘンリックのかんばん"がすごく人気だった。
 → 聴講者の食いつきが凄かった。
・ヘンリックのセッションが、なんでそんなに人気があるのか考えてみた。
 - 過程がわかりやすく見ることができるからでは。
・デジタルツールは、何かしらの考えがあって作られている。
 - 合うか合わないかでだいぶ変わる。
・アナログの利点: 試す、変える、俯瞰する

●デジタルツールのならではの良さ ニック
・アナログは最高の方法。
・私はデジタルツール側のベンダー所属なので、発言にバイアスがかかってるので信用しない方が良い(笑
・デジタルは、自動で計算してくれる。

●市谷さん
・アナログは簡単に始められるけど、めんどくさい。
 - ベロシティとかの計算を自分でやらないといけなかったりする。
 → 何か工夫ありますか?

●安井さん
・アナログだと、ベロシティ出すために計算したり、毎日やるのは大変。
 → 時間で見てるから大変になる。
・じゃあ、タスクを同じくらい時間かかる粒度に分けて、枚数で数えるようにした。
 → ボードを管理するめんどくささから、プロセスを変えて改善した。
 
●松元さん
・仕事の仕方を変えるに慣れると、タスクの粒度が揃ってくる。
 → 揃ってくれば、数えるだけでいい。
・プロダクトバックログに載っているストーリがー終わっているかどうかが重要であるのであって、タスク自体の追跡はあまり意味がないのではないか。


●市谷さん
・デジタル化のコスト(利用料金や習熟時間)や、利用しないというリスクを、どうリスクヘッジしているか?

●ニック
・デジタルツールの習熟に時間がかかる、と言うが、アジャイル自体の習熟に時間がかかるので、それはデジタルツールに限った話ではない。
・アジャイルとは、journey(旅)である。常に学び続けなければならない。だから、デジタルツールを学ぶコストも当然、ずっと掛かっていく。
・デジタルツールは、スケールさせることができる
・デジタルツールに慣れてくると、タスクを完了させることに集中できるようになる。アナログのままだと、ずっとタスクを手で数えることをやらないといけない。

★結論:
・ヘンリックの考えたかんばんは最強。
・アジャイルなら、デジタルツールも学ぶべき。


■3.Enterprise Agile
 ボトムアップ(現場から) vs トップダウン(経営層から)
 チーム vs 組織 などなど

 
●伊藤さん
・最近気になるのは、「アジャイルを売ろう」とするマネージャや営業が多いこと。
 → アジャイルって売り物ですか?というのがいつも疑問だった。
 
・「アジャイル開発手法」という表現に問題があるのではないか?
 → 日本だと、アジャイルは「開発の話」だと思われてしまう。
   USAのアジャイルは、「テクニカルプラクティス+マインドセット」の両方がセット。どっちか一方ではない。

・アジャイルは「開発手法」だと思われる故に、改善しないといけない本来の人たちが、「開発の話は、オレには関係ない」と無関心になっているのが問題である。

●上田さん
大規模サービスも全部アジャイル化していこう、というコンセプトでやっている。
最初は未経験だったので、まず取り組みやすいといわれる新サービスからやった。

 ・まず新事業でアジャイルを知ろうとした。
 ・大規模チームも徐々にアジャイル化 ← いまここ
 ・エンタープライズアジャイルを実現したい。
 
 自分にとってのアジャイルとはなんなのか、をしっかり考えることが大事。
 まずはアジャイル開発とはなにか、を考えるところから始めてもいいのでは。

●松元さん
・Agile 2012でMike Cottmeyerがレクチャーのセッションをやっていて、まとめっぷりが凄かった。
 - 意思決定はトップダウンでやっていきましょう。
 - 実際にどこから手をつけるか、といったら、開発チームから。(ボトムアップ)

・AGILEな組織をAGILEな考え方で作る。
・組織、手法、人、制度を順繰りに移行していく。
 - まず、ちょっとチームを作る
 - プラクティスを実験的にやってみる
 - 良いとこ悪いとこをを知った上で、理解する。
 
 これで1週。これを少しずつ範囲を広げながら続けていく。

・意思決定はトップダウンで、ボトムアップから始める。
・全体ロードマップや指標を整備してプログレスを取る。

●安井さん
・アジャイルを広げていく過程で、どこかで壁にあたる。
・壁に当たる理由:アジャイルが「開発」だと思っている。
・ビジネスとかマネジメントとかになると、アジャイルは「開発」なんだから、こっちくんなという話になる。
・しかしアジャイルでは、ビジネスからフィードバックを得なきゃいけない。
 でも、アジャルは「開発」の話だから、ということで、どこかで止められてしまう、という事象がおきる

・上の立場(社長と話ができるレベル)の人がアジャイルを理解してくれていると、壁を越えやすい。
・逆に開発の現場にいる人だけだと限界があるので、いろんな人を巻き込んで、いろんなアプローチで攻めるのが重要である。

 -どこまで行くのか
 -覚悟してるのは誰か
 -アプローチはひとつじゃない

●聴講者からのコメント1
 開発者がビジネスサイドに寄り添うか、ビジネス側が開発側に寄っていかないかぎり、壁は越えられないのでは。


●聴講者からのコメント2
 「Do Agile」か「Be Agile」という話について。


●伊藤さん
・Do Agile
 - アジャイルをする。いろんなプラクティスを使ってやる。
 - あくまで「やる」だけ、そこで止まってしまう。
 - 改善までは考えが及び難い。

・Be Agile
 - 全体的な視点で改善を続けるのが、良いアジャイル。
 - 「アジャイルであれ」
 
●安井さん
 ケントベックの本には「変化を包容せよ」と書いてあった。


●聴講者からのコメント3
 上の立場の人と意識が違うと、評価が変わってくるのでは、と思う。
 アジャイルで現場が頑張っていても、上の立場の人の理解が無いと、「なに遊んでるんだ」となってしまう。
 
 これまでに、上の立場の人に共有ができて、評価を変えれたことがあったか?
 あったならば、どうやって改善したのか?

 下々ががんばっても理解してもらえないと神々の評価に繋がらない。
 アジャイルとしてうまくいくのか?
 
・藤原さん
 -上司とコンフリクトしたことがないのでわからない
 -アジャイルは改善活動なので、上司に説明して理解を得た上でアジャイルを採用している。
 -評価は全社員と同じ方法でやっている。特別なことはやっていないが問題は出ていない。
 
・ニック
 ボトムアップとトップダウンについて、2006年のオーストラリアでの経験の話をシェアしたい。
 そのときは、スクラムを小さなチームで、Do Agileで始めた。

 - 朝会をやる
 - スプリントをやる
 - etc

 → Do AgileからBe Agileになるまで、2年かかった。

 別の例として、2万8000人いるような銀行でアジャイルの導入をやった。
 大きな銀行でも、Be Agileになるまで何年もかかった。

●聴講者からのコメント4
Be AgileとDo Agileの具体的な違いは何か?

・ニック
 Be Agileは、マインドセットの話である。
 何のためにやるのか理解して、どうやったらもっとうまくやれるかを探して、改善し続けること。
 その銀行では、CEOがアジャイルに理解を示して全社的に広げることができた。

●市谷さん
開発もロクにアジャイルで出来ていないのに、組織をどうやってアジャイルにしますか?
AGILE 2012で見てきた具体的な話があれば、お願いします。

●藤原さん
・Agile2012へ行ってみて、参加者の多くが「企業にどう導入するか」とか「どう組織を変えるのか」が難しいと困っていたので、日本とあまり変わりはないかな、と感じた。
・でも、海外のほうがやはりスピードが早い。
・一番初めにどうやったら良いかは、国によって解が違う。
 -インドでは、まずトップを落とせ。
 -自由そうな国では、ボトムアップでやらせてくれる。
 
 → 自社の組織文化に合わせてやるしかない。
 
 楽天だと、ボトムアップでやらせてもらっているので、コンフリクトしていない。
 逆に、トップダウンでやれ、と言われても、そこまでエンタープライズをいきなり導入するか、というと、やりかたがわからないのが本音
 → 1つずつ考えて、Try and Errorでやるしかない。

・トップの理解は怖い。
 - アジャイル=早い、をどう捉えているか。
 - 誤解を解くのは別で考えなければならない。
 
●上田さん
・神々と下々の話で、意識の違いがでる原因として、アジャイルやることが目的、という風に神々に見えてしまうのがある。
・目的を実現するためにどうすればよいのかを神々の人に相談し、それで「アジャイルで解決できるかもしれないね」という風になれば、神々の理解も得られるのでは。

Agile2012で、Dean Leffingwellがエンタープライズアジャイルの説明をしていた。
http://www.manaslink.com/articles/4735(参考:市谷さんのレポート)
そこで、マインドセットの話が12個くらいでてきた。
開発のプラクティスとマインドは切り分けられない。
目をそらすのではなく、マインドセットから変えていく努力が必要だな、とそのセッションを聞いて感じた。

●市谷さん
でも、マインドセットを変えるのは難しいですよね。どうすればよいか。

●安井さん
・他人の考えを変えられるわけがない。自分から変わるしかない。
・自分がまず変わって周りに影響を与えると、周りも変わる。

●伊藤さん
・マインドセットを変えようとするのではなく、自分から「変わりたい」と思わせることが重要。

・事例:チーム間でお互い殴り合いの喧嘩するようなチームがあった。
 - 原因: お互いを批判する文化にいた。
 - 対処: 批判するのをやめよう、もっとお互いしゃべっていいんだよ、とした
    → Facebookに意見を書いてお互いが見えるようにしましょう、とした。
    → 自分から意見を言うようになった。
    → お互い、あなたの言っていることがわかりました、というようになった

もっと話していいんだよ、と気付かせる環境を作ってあげるのが重要。
問題は、大抵がコミュニケーションミス、コミュニケーションロス。
お互いがもっと見えるよう、見せ合えるよう、アイデアをシェアできるようやってみれば、変わるのでは。

●聴講者からのコメント5
神々の人は成果を求める。
数値化して、アジャイルやるといいことがあるんですよ、と神々に説明しなければならない。
数値をどうみせるか、いい方法ないか?有無を言わせない数字って出せるか?
ベロシティを神々に説明しようとしても、ベロシティって何?から始まってしまう。

●松元さん
サービスは、小さく作って動かしちゃって数字を出している。
2年もかかるようなプロジェクトだと、成果というよりも、リスクがとても大きい。その案件が上手くいってるのかどうなのか、が一番、神々が知りたいこと。
神々にバーンダウンとか見せてあげると、対応をしてくれるようになる。
現状をきちんと見せる。嘘をつかない数字を見せる。

本当のリスクを踏んでいる人のとこに正しい情報が集まっていればいいのでは。

●上田さん
工数だけ確保して、1ヶ月いくらという形で、何ヶ月か積んでおくスタイルの契約で、その範囲の中できちんとプロダクトを作って見せる、という開発をしているSIerがあった。
そこでは、KPIもチームの中で決めていた。
チーム毎にお客さんと納得した上でケースバイケースでKPIを作るのが良いと思った。

●ニック
ストーリーポイントを使って、マネージャを教育して、スプリントデモにマネージャを呼んで、実際どれだけストーリーを消化したか、話をするのはどうか。

●伊藤さん
実際に、モノを見せるのがいいのではないか。
スプリントの最後のレビューで、作ったものをデモをする。ステークホルダーをお招きして、動くものを見せたら、それは立派な指標や成果になるのでは。

●藤原さん
成果というと「開発生産性とは何か」みたいな話になってしまう。
そんなことを私が言われたら、「じゃ、今の生産性を出してみて」って言ってみる。

ベロシティというものを説明して、生産性の変わりにしていると説明する。
見せる化することが重要。
 
一番効果的なのは、「楽しそう、雰囲気がよい、リリース回数が多い」というのが評価される軸と思う。
一番お勧めなのは「リリース回数」。
何が良くなっているのかを焦点を絞って示す。

●伊藤さん
「Legacy Mindsetからアジャイルへ」
Agile2012で、Dean Leffingwell氏のセッションが「Scaled Agile Framework」だった。
エンタープライズでアジャイルでやるための仕組みとかパターンを纏めている。
SAFでググるとヒットするのでそっちを見ると参考になる。
→ http://scaledagileframework.com/


■2.日本 vs 海外
●上田さん
・日本は、プロダクトオーナーの考え方が確立、浸透していない、と感じた。
・Agile2011で、LindaさんがProduct Discoveryを行うためのフレームワークを紹介してくださった。
 → 日本ではそういうのは弱いなぁ、やってないなぁ、と感じた。
・アジャイルってドキュメント作らないんでしょ、という誤解が日本にはある。
・日本だと、アジャイルの解釈が人によって大きく異なる。

●安井さん
・Agile2012のような世界的なカンファレンスは日本では無いという意味で、日本はアジャイル普及してない。
・海外では、ITという枠を遥かに超えてアジャイルを普通にやっている。
・数としては日本は普及してない。
・日本だと、開発の話だと思われている
・日本だと、カンバンといったマネジメント系よりも、TDDとかCIとか技術的プラクティスは流行っている。
・日本だと、アジャイルコーチでお金を貰ってる人が少ない。
・日本の面白いところで、ソフトウェア開発と関係ない世界にアジャイルが普及してたりする。(事例:佐賀県庁のパスポート発行)
 →平鍋健児さんが、「プロジェクトファシリテーション」という言葉でアジャイルをいろんなところで話していた影響もある。

●市谷さん
海外だと、登壇する人とかはLLCとか自分の会社を作ってる人が多い。

●ニック
海外は、日本のリーン開発とかトヨタの事例とかから学んでアジャイルに取り入れている。
海外は、日本がアジャイルの国だと思っている。
EUとかUSAとかでは、10年前からアジャイルが有効だと証明されていて、キャズムを超えている
でもEUとかUSAでも、アジャイルの普及は時間がかかっている。
日本はグラフでイノベーターの位置にいるから、普及にあと10年かかるかもしれない。
インドとかは英語が普及しているから、アーリーアダプタになるかもしれない。
中国では、まだアジャイルが始まってもいない。

●市谷さん
日本も海外と同じくらい時間かけている。
なぜ10年経っても同じ位置にいるのだろうか。
XPユーザ会やケントベックの書籍は2001年くらいなので、10年は経っている。

●伊藤さん
日本は、失敗してはいけない、というプレッシャーを感じすぎている。
USAのユナイテッド航空のシステムは、いつも落ちている。
それでも、いつものことだから、と気にせず運行している。
それに対して日本は失敗してはいけない、と恐れて一歩を踏み出すことを恐れている。
海外は成功事例も多いけど、失敗事例も多い。
でも彼らは失敗したことを、失敗ではなく学びと捉えてプラスにしようとみんなにシェアしている。
それに対して、日本は失敗を恥と捉えてしまう。

●聴講者からのコメント6
IT技術者はどんな会社に所属しているか、という調査があった。
それによると、日本はほとんどがSIerで、USAでは半数がユーザ企業の情報部門にいる。これが日本と海外の発展の仕方を変えたのでは。
エンドユーザの近いところにいる海外では、アジャイルを適用しやすかったのでは。
日本はピラミッド構造で、よきにはからえ、で作らせる構造がこの10年間変わってきてないので、そこが原因では。
明るい兆しとして、楽天とかDeNAとかGREEとか、本業がITではなくてサービスの会社にエンジニアが移ることが加速してきているので、日本もアジャイルっぽくなっていくといいなぁ、と思っている。

●吉岡さん
Be AgileかDo Agileか、という話で言うと、競争力がある会社は変化にadaptしているという意味でBe Agileだと思う。
トヨタがBe Agileというのは、圧倒的に車の生産に関して競争力を持っているから。
ある新しい車を作る時に、市場の調査からプロダクトが出てくるまでが、他の企業よりも遥かに早かった。だから変化に適応できた。

日本では、ITは受託開発がほとんどで、圧倒的に競争力がない。なのでBeingでもDoingでもない。
圧倒的に競争力を持っている会社があれば、それは結果としてBeing。
ユーザ企業かSIerという軸ではなくて、仮にGREEとかが競争力があるとしたら、手法としてより効率のよい開発をしている事例なのかな、と感じた。
同じ会社でも、Beignが上手くいってるところもあるし、ないところもある。

●川口さん
海外=英語圏。英語圏は、アイデアを持ってる人口が圧倒的に多い。
あっというまに英語でブログとかで伝わる。
日本では、一部の人がそれを見聞きして翻訳してから伝える。
その分、フィルタが入るので遅れているのでは。

●市谷さん
確かにそのとおりだと思う。
Agile2012へ行くと、著名な人たちが最新の話を目の前でしてくれる。
日本だと、それが日本語に訳されて出てくるのを待っている状態。
そもそも翻訳されず入ってこないものもある。

●川口さん
今日ニックと同じ時間を共有している、このような場の共有が、海外では普通に起きている。

●聴講者さんからのコメント7
今、日本は高齢化社会で、部署によっては、10人いたら8人管理職だったりになる。
アジャイルを導入することによって、役割を再編成できるのでは。
マネジメントの人もコードを書けたりとか、アジャイルで再編成できるところが利点ではないかな、と思っている。

●及部さん
私もAgile2012に参加したが、アジャイルとか関係なしに、上司やチームメンバとコミュニケーションやらないと、うまくいかないと感じている。
海外では、そこをすごくポジティブに考えている人が多いと思った。
難しく考えすぎずに、仲良く楽しくやっていいけばいいのでは、と思っている。


最後に「Why Agile?」と「Agile Conference」

●安井さん
Why Agile?

・自分が楽しく仕事がしたいと思ってたらアジャイル、XPに出会った。
・XPやりたいと思ったら、一人ではできないので、周りにも広げないといけない。
・XPと言い続けたら、徐々に回りに広がっていった。
・それやっていくと、マネージャとかお客さんとかまで広がっていく。
・ふと気づくと、「あれ?俺、何がやりたかったんだっけ?」と自問自答した。
 → 楽しく仕事したい、が原点で、それは「開発すること」だった。
・でも、今アジャイルが楽しい。もう一回再確認して、アジャイルコーチをしている。
・今でも、自問自答することがある。

Agile Conference
・Agile Conferenceは大変。(体力、金銭、家庭)
・たとえ話:
 おもちゃを買いに行くとき、商店街のおもちゃ屋に行くか、デパートのトイザラスに行くか、で考える。
 近所のおもちゃ屋さんでも、欲しい物があることがわかれば、買うのは楽。
 でも、トイザラスに行くと、思っても見なかったものに出会ったり、おもちゃがたくさんあることに刺激されたり、違った経験が得られる。
 
 このたとえ話で言う「おもちゃ屋」とは、
 ・商店街のおもちゃ屋 = 日本の勉強会とか
 ・デパートのトイザラス = Agile Conference

 Agile Conferenceは、世界中のアイデアの展示会であって、この中から好きなものを持って帰ってこれるすばらしい場所だと再認識した。
 近場の勉強会とかイベントもすばらしいが、Agile Conferenceは、それとはレベルが違った価値が得られる。
 
●上田さん
Why Agile?

上司から、やれといわれたから。
→ トップダウンでアジャイルが始まった。

もうひとつの理由として、ボトムアップの観点があった。
エンジニアとしてスキルを高めていかなくては、という危機感。
変化に挑戦(チャレンジ)するのは楽しい。

Agile Conference
藤原さんに誘ってもらってAgile Conferenceに初参加したが、上司を熱意を伝えてわかってもらえて、会社のお金で参加できた。上司の説得もチャレンジの1つだった。

●松元さん
Why Agile?

・技術をもっと磨きたい
・開発をもっとうまくやりたい
・プロジェクトをもっとよくしたい
・現場と経営を直結したい ← いまココ
・人材育成

Agile Conference
・Agile Conference 2012は、まさにオアシスだった。
・運営者とか登壇者とかにギャップがなく、オープンな雰囲気をすごく感じた。
 メアリー・ポッペンディークとかが受付で記録係やってたりする(笑
・色々と無茶をしても、案外なんとかなるもの。
・歩き続けることが大事。

●伊藤さん
Why Agile?

・私の戦場だから。
・アーキテクトをやっていたが、プライドの高いプログラマと設計者との板ばさみになっていた。
・そこで、私がチームの交通整理役となって、人と人とを繋ぐコネクター役に価値があると信じてずっと頑張っていた。
・それでも、中途半端な奴、と言われてへこんでいた。
・後々、自分がやっていることがスクラムやアジャイルに行き着いた。
・そこが自分の居場所だと思うし、アジャイルで生きていこうと思っている。

Agile Conference 2012
・最高のレジャーである。
・著名な人がどこにでもいて、話ができて友達になれる。
・心から溶け込める空気がある。
・行って、試して、おもしろい、と経験してもらいたい。

●藤原さん
Why Agile?

アジャイルがやりたいから。
もともとSIerで働いて、開発生産性が~、とか言われていた。
これにどう回答していこうか悩んでいたが、マッチしたのがたまたまアジャイル開発だった。
今も試行錯誤してるが、答えはない。やって気づくしかない。
他にいい方法が思いついていないので、このまま続けて行こうと思っている。

Agile Conference 2012
・最初は会社の命令で行かされるとあって、嫌だった。
・でも行ってみて凄くよかった。
・でも、その良さは言葉では伝わらない。なので、今年は市谷さんと及部さんを連れて行った。
・よし、みにいこう、って一歩を踏み出せる人がもっと増えればいいなぁ、って思っている。

●ニック
Agile Conference

・私のAgile Conferenceは、2009年のシカゴから始まった。最初は学ぶほうだった。
・行くと、誰もがオープンで、半分の人が実践者で、他にも学習者がたくさんいた。
・今年2012年のAgile Conferenceはすごく素晴らしいものだった。
・来年2013年のAgile Conferenceは素晴らしいイベントになる。ビジョンを得るために行くべき。

●市谷さん
Why Agile?

値打ちがあることを作りたいから。
一つの在り方がアジャイルでは。

●大澤さん
・今日は通訳で失敗した。でも、これは失敗じゃなくて学び。
・無茶振り、ってのを英語に訳すのが大変だった。


●市谷さんのclosing
以下のイベントをやります。

Ultimate Agilist Tokyo - 集え、日本の活動家たちよ
http://ultimateagilist.doorkeeper.jp/events/1823



感想:

日本でアジャイルの先駆者とでも言える方々が、海外の本場で何を見て、何を感じ取ってきたのか、非常に興味深く聞かせていただきました。
こーゆうイベントは良いですねー。Agile Conferenceに行けなかった人に情報を共有してくださるのは、ほんとありがたいです。

あと、英語、やっぱ大事!ニックのリアル通訳、大澤さんと安井さん、カッコよかた。
英語の話はセッションの中でも出ましたが、知見を広げるためにはやっぱ必要だなあと思いました。

オレもいつか、Agile Conferenceとかで登壇できるようなエンジニアになりたい。
ただ、当然それはすぐには無理で、身近なトコから一歩を踏み出して行こうと思います。

企画者さん、運営者さん、登壇者さん、会場提供者さん、皆様ありがとうございました。
関連記事
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://makopi23.blog.fc2.com/tb.php/27-4d322e8e
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。