Agile Conference tokyo 2011に参加してきた #agiletokyo
直前の台風6号が本土上陸、関東直撃か?と言った不安はありましたが、幸い台風は進路を反らし、関東にも上陸する事無く不安は取り除かれ、無事開催会場にも着く事が出来ました。
開催会場は周りを住宅街に囲まれたとても庶民的な(?)風景の中にある江東区文化センター。
Togetterまとめ
その他参戦レポート
- Agile Conference Tokyo 2011 行ってきました - ShiroKappa Blog
- Agile Conference tokyo 2011に行ってきました #agiletokyo - かおるんダイアリー
- Agile Conference Tokyo 2011 に行ってきました。 | shinodogg.com
- Agile Conference tokyo 2011 - せつないぶろぐ
- Agile Conference tokyo 2011に参加しました - ただいま修行中...
- Agile Conference Tokyo 2011に行ってきました - kunitooの日記
- 基調講演:Software Design in the 21st Centry (Martin Fowler 氏)
- 特別講演:ThoughtWorks社による海外導入事例 (Jez Humble 氏)
- 海外での実践助教と高品質でAgilityを高める"機械化"について (三井 伸行 氏、 畑 秀明 氏)
- 継続的フィードバック (長澤 智治 氏)
- Rubyによるアジャイル開発事例
- 技術開発現場のノウハウ共有に手をかけるな!アジャイル開発でよみがえった、プロダクト開発 (朝倉 慎一 氏)
- ユーザーと開発者のどまんなかを行くE-Agility協議会 (依田 智夫 氏、 牛尾 剛 氏、 永瀬 美穂 氏)
- アジャイル検定制度について (戸田 孝一郎 氏)
基調講演:21世紀のソフトウェアデザイン
参加者の多くはこの人を観に来られた、という人が大半だったのではないでしょうか。かくいう私もその一人。XP/オブジェクト指向/UML等で有名なマーチンファウラー氏の基調講演です。
ファウラー氏については以下のサイト等を参照。IT技術者でそれなりに開発手法・技術に興味のある人ならば一度は耳にしているであろうビッグネーム中のビッグネーム。
講演は氏が数センテンス発言→翻訳者による翻訳、の繰り返しで進んで行きました。以下メモ。(翻訳聴きながら、というスタイルは初めてで慣れない部分もあり、結構抜けが多いかと思われます。詳細な内容についてはTogetter関連箇所にて情報補足して頂ければと。)
- 2000年代
-
- Predictive Planning(予測型〜)からAdapting Planning(適合型〜)へ
- 継続的にプランニングをし続ける、というスタイル
- ちょっとだけプランニング、実行、学習、プランニング…(小刻み)
- アジャイルの世界の中では歯車のように動いている
- Release early and often
- 早く、頻度を多くリリース
- Adapting Planning→(needs)→Evolutionary Design/continurous integration/rafactoring
- Predictive Planning(予測型〜)からAdapting Planning(適合型〜)へ
- フレデリック・ウィンズロー・テイラー(Frederick Winslow Taylor)
- 人を配置・配属
- ここではプロセスが重要
- 適した人を配置していくアプローチ
- アジャイルの世界の人々は↑に疑問を持った
- 優秀な人たちが多い場合は上手くいくが…
- 能力のある人たちが良い人間関係の下で動かなければよいプロセスがあっても効果が無い
- a bad process will beat a good person every time
- agileの世界では
- 有能な人々を探す
- チームとしてコラボレーション出来るかどうかを見極める
- ある環境において(彼らにとってやりやすい)プロセスを作ってもらう
- ※プロセスありき→人ありきに
- Adaptive Planning
- People-first
- 人々はプロセスを自分で選択、もっと良くしよう→進化。
- 改善する事に熱意を持つようになる
- アジャイルに於いては、perfectという言葉は動詞として扱うべき。
- Perfect(完璧な:形容詞)
- to perfect(何かをより良いものにするために発達する・改善する:動詞)
- CONTINUOUS INTEGRATION AND DELIVERY
- when I was a lad…(ファウラー氏の昔話)
- 統合するプロセスに取り組んでいるプロジェクトに参加したときの話
- ファウラー氏『統合するのは大変なんだ・・・しない方が良いんだな』
↓
-
- 学生から大人へ、
- intergrationで苦戦するのを何度も見てきた
- 学生から大人へ、
- インテグレーションが大変だったという学生時代の話
- 1つのソースコードを分岐、
- 分岐したものそれぞれに対して対応
- 分岐されたものは違う場所で動いている
- 様々な問題が発生し得る
- Powerful merging tools
- Merge
- Textual(テキストのマージ:たやすい)
- Semantic(意味合いのマージ:してくれない/難しい。テストが必要)
- Intergration is hard…so don't do it often
- Merge
- 統合にともなう痛み・苦しみ
- 統合頻度の関連グラフ
- 指数関数的に痛みは引き延ばせば伸ばす程大きくなる
- どうせ痛むのであればいたくなる前に対処しちゃえば良いのではないか
↓
-
- 継続的な統合
- どんな細かい対応も、メインラインに統合
- 頻繁にインテグレーションしているので大きな賭けをしなくてすむ
- Bigマージを回避するために、頻度の高い統合(continu.. Integration)を行う
- リファクタリングをするのを怖れていると、コードの品質はどんどん低下していく。
- 継続的な統合
- マージングは問題が多く潜んでいる/都度連携取っていれば良いんだろうけど・・・
- Continuous integration:早期発見・早期治療が出来る事がメリット
- Continuous delivery:動作するかどうかはまだ分からない、動作して初めて意味を持つ
- Deployment pipeline
- How do we tell is it's production ready?(我々のコードはリリース可能なものなのか?)
- Testing(テスト)を天秤に掛ける
- 沢山テスト実施=自信、安心
- 一方で時間、コストも掛かる
- 幾つかのシーケンスをもうけてみる
- Confidence(安心、自信)
- Production
- Performance Test
- Functional Test
- Compile+Unit Test
- Timeliness
- Confidence(安心、自信)
- Testing(テスト)を天秤に掛ける
- 出来るだけオートメーション化した方がよろしい!
- いつでもテスト出来るように、完璧に自動化。
- Configure environment
- Deploy binariees
- Smoke test
- :
- 英国人にとっては金曜の夜に飲みに行くのは重要
- 日本人も『花金』を楽しんでください(←古っ!)
- How do we tell is it's production ready?(我々のコードはリリース可能なものなのか?)
やべ…英語→翻訳をメモしてるので、内容にかなり自信が無い…(笑)
特別講演:Thoughtworks社による海外導入事例
副題:『〜アジャイルによる技術革新の加速と品質の改善:高パフォーマンスチームの構成要素は何か〜』。
こちらも海外から招かれた凄いお方。Continuous Deliveryの著者であり、ThoughtWorks StudiosのPrincipalな方です。詳細なプロフィールなどはイベント公式等で。
- 作者: Jez Humble,David Farley
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2010/07/27
- メディア: ハードカバー
- 購入: 3人 クリック: 141回
- この商品を含むブログ (23件) を見る
- なぜアジャイルなのか?を考えよう
- whats the problem?
- 市場に投入するまでの時間が掛かり過ぎる
- web2.0
- filckr
- Yahooが買収、ージョンアップを1日に10回以上している。(未だに継続中)
- 頻繁なリリースで安定した品質にはハイクオリティな環境が必要
- filckr
- Agile:Case Studies and Lessons Learned
- 事例1:英国ガーディアン紙
-
- ニュースwebサイト。英国で最も有名であり、賞も受賞している
- 2006年までwebサイト内の記事はほとんど手作業で処理
- 移行には多くの手間が掛かる、数年に亘って対応する必要があるプログラムであった
- 古いサイトを新しいサイトに、というだけではない
- インタラクティブ、ダイナミック、マルチメディア化、ソーシャルネットワーキング対応化…全て行いたい。
-
- thoughtworksのやりかた
- 2週間で変化に対するラフ案を出す
- どこから始めたらいいかの整理整頓
- 旅行部門からスタートした
- 8か月後には作動
- トラベルサイトに特化して対応した…他の場面には適用可能ではない
- 2週間の方向付けフェーず:整理整頓に費やした
-
- アーキテクチャをどういう組み合わせで利用するかの決め時間に費やした
-
- リリース後、PageViewは10倍に増加
- 2週間で変化に対するラフ案を出す
- ビジネスサイドから見て『これだけ変わるのか』と確認出来、自信を得た
- フィードバックを初期の段階で得ることが出来た
- 学習した内容を使って次のフェーズを進める
- 最終的には全部を聡取っ替えしていった
- 最後は新聞の部分
- プロジェクトを通じて想定の70%で対応出来た
- thoughtworksのやりかた
-
- 1日辺り10万トランザクション
- 大きなレガシープラットフォームを利用
- 移行には数年を見込み、UKの方で担当者が50人、150人の人々がインドオフィスで計200人が関与
- こちらも少しずつのリリースで対応していった
- 利用:Thoughtworks studios agile ALM solution - mingle, Go, Twist
- 反復的に6週間毎のリリースを行っていった
- システムがいつでもキチンと作動しているように作業
- ビルドテストデプロイ自動化・可視化
- 出来るだけ自動化することが大事
- virtualizatoin(仮想化)も重要
- rapid frequent(迅速に、頻繁に)がお客様に高評価
- 大企業でも小さなところでもアジャイルは適用可能
- 海外ではアジャイルそのものが主流となっている
- 調査:業界全体の37%(6ポイント上昇)
- 1番目:アジャイル、2番目:no definedprocess(決まったプロセスを持たない)
- 調査:業界全体の37%(6ポイント上昇)
- じゃあ明日から・・・というほどアジャイルは簡単ではない
- 組織が障害となりうる・・どうやったら障害を乗り越えられるのか?
- 組織が障害となりうる・・どうやったら障害を乗り越えられるのか?
- プロジェクトマネジメントのやり方を変えていく
- 何かを革新していくやり方を変える
- 自分たちがその中でどうあるか、という点も問われる
- 障害
- 遅い意志決定
- リスクを嫌う文化
- 等々・・・
- ある意味では組織が立ちはだかっている
- "do less"
"You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new. Steve Jobs 顧客に欲しい物を聞いてから、それを与えようとしてはいけない。 それを作った時には、もう彼らは他の物を欲しがっているから。 スティーブ・ジョブズ"
- クオリティの話:開発の初期段階から品質を作り込もう
- インスペクション、テスティングはフェーズ(段階)ではない。いつも行っている
- バグはすぐに見つかってしかるべきなのに
- テスターがバグを見つけたら報酬・・・皮肉な話。見つからなかったら・・・に変えるべき
- qualityはそれに関わる全ての人々の責任である
- システムのクオリティを全員が見えるようにするのがテスターの仕事。クオリティを確保するのが仕事では無い
- インスペクション、テスティングはフェーズ(段階)ではない。いつも行っている
ここでは、テストの4象限の図が表示されていました。日本語資料でそのものズバリのものがあったのでリンク。
- アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-
- View more presentations from satoshimasuda
- 人についての話:アジャイルなチームをリードしていくにはどうすればいいのか?
- 人という生き物は何によって動機づけられるのか?
- お金?→実は必ずしもお金だけではない
- 創造性?
- クリエイター…自分が個として自立している、技術を修練・習得している事、エキスパート
- 目的、使命感・・・商品がどのような価値を見出すのか
- 全員がひらめきマンであり、クオリティマンであることが重要
- 人という生き物は何によって動機づけられるのか?
- アジャイルを可能にするための重要な要素
- 大きなものを機能横断的なものに分ける
- create autonomous, cross-functional product teams
- あなたはそれを作りなさい・実装しなさい(amazonの思想)
- フィードバックループを作る
- create feedback loops
- リッチなフィードバックループを色々な場所で作る
- create feedback loops
- create autonomous, cross-functional product teams
- 継続的な改善
- 大きなものを機能横断的なものに分ける
この後はセッションが計6つ続きます。11:00〜18:00という長丁場、開始2つの通訳付きでのセッション、途中PCのバッテリーがなくなりかけた・・・等々の要因もあり、全てのセッションを集中して聞く体力は残ってませんでした。印象に残った(=メモを取れた)もののみ触れていきます。
Session 2:継続的フィードバック
本年5月に米国アトランタのTech・Ed North America の基調講演でこれからのソフトウェア開発のコンセプトとして「継続的フィードバック」が発表されました。このコンセプトは、同時に発表された Visual Studio vNext を待たずして、Team Foundation Server 2010 を中心とした Visual Studio 2010 から実践していくことができます。 本セッションでは、開発スタイルを尊重し、かつ、顧客ビジネスを最大化するためのソフトウェアをデリバリーし続けるポイントと、限界を超えた開発支援ツールの今と、今後について紹介していきます。
講演直前にスライド資料が挙がっていたので、詳細は以下スライドをご参照下さい。
- 【Agile Conference tokyo 2011】 継続的フィードバック
- View more presentations from Tomoharu Nagasawa
そしてセッションで利用していた動画はこちら。
以下メモ。
- カンファレンスで話すの3回目(皆勤賞)
- MS:プラットフォームベンダーの会社です
- オフィスビジネスアプリケーション
- 本セッションのスタンス:アジリティを向上させる開発支援技術環境の進化
- Going agile with tool
- ふりかえり
- MSの中の人が『ドッグフード』で作ったものを商品化。→Visual studio
- 課題
- 分散したリポジトリ
- 本業に専念できない
- 長いwipによるフィードバック遅れ
- リアルタイムな共有
- →Visual Studioが対応。
- visual studio => Eclipseのアクセスも可能だったりする
- Test Manager:一度実行した手動ケースは記録され、自動実行可能。
- 障害発生時にチェックインをさせない機能
- リポジトリが1つなので様々な処理が効率化。
- 継続的デリバリー
- (滑らかな動画によるデモ実演)
- 継続的フィードバック
- ALM 2010 summitに長沢さん日本人でただ一人の参加
- ビジネスのアジリティが重要
- ビジネスのアジリティのためには以下が不可欠
- スクラム
- ALM
- ツールはシンプルに使いましょう
- ツールの連携の話は1個も出なかった
- Tech -ed North Americaの話
- アジャイルプラクティスの積極活用:6つのポイント
- ストーリーボード
- フィードバックを得るためのツール
- パワーポイントと連携
- コピペコード撲滅ツール
- analyze code clone
- 単体テスト効率化
- Tools for Agility
- 『やりたい事駆動』でツールを利用する
- オープンソースで提供されているツールの紹介
- no more tools!
- ツールを使いこなすことではなく、やらなければならない事を実現する為のツール
結果としてツールの紹介・単なる事例の紹介に終わったセッションもあった中、最後のコメントが非常に心に残りました。また説明の過程でスライド/動画/実環境を縦横無尽に切り替えて講演を進める長沢さんのスキルには唯々感嘆するばかりでした。
Session 4:技術開発現場のノウハウ共有に手をかけるな! アジャイル開発でよみがえった、プロダクト開発
- 萩原 純一 氏
UPされるのならば是非とも見返してみたい!と思えるような試行錯誤の数々が記されたスライド資料でした(この前辺りで一旦集中が切れてしまいメモ取ってなかった…)。プロジェクト独自の取り組みも色々されていたのですが、その中で朝会が2時間掛かってた!(→後に短縮したが)というのが驚き。
Session 5:ユーザーと開発者のどまんなかを行くE-AGILITY協議会(仮)
ITユーザー企業とアプリケーション開発者に、出会いと交流の場を提供する事を目的として設立された協議会。
上記お三方が以下の要点についてそれぞれ講演されました。
- (依田さん)
- コミュニティの出来た背景
- 問題点
- ユーザー側:骨太のシステム構築戦略が必要。
- 開発者側:何がビジネスに価値をもたらすかの感覚が不足している。
- 問題解決策としてのE-Agility協議会
- もっと互いを知ろう・教えあおう!
- これからの活動予定
- 年数回のカンファレンス実施(目標年4回)
- 勉強会(月例)を準備中
- E-Agilityの特徴
- 手組2.0/次世代手組のコンセプト
- ユーザ企業の発想/ユーザ事例
- いつもと違うメンバー構成
- ユーザ企業が元気になる手助けを。
- (永瀬さん)
- 協議会参加のススメ
- ユーザ企業にとって…
- 出会いの場(ユーザ企業/開発者)
- 悩みを共有出来る、解決のヒントをもらえる
- 開発者にとって…
- ユーザ企業と繋がるチャンス。
- ユーザ企業のナマの悩みは大好物。
- ユーザ企業にとって…
- 協議会参加のススメ
-
- ユーザーが少ない
- 平均年齢が高い
- 女性が少ない
-
- E-Agility協議会女子部を作ろう!(ど〜ん)
牛尾さんの『ア〜〜〜〜〜〜〜〜〜ジャイルっ!!』な雄叫びは聴くことが出来ませんでした。残念。
その代わり、永瀬さんが一部突き抜けたセッションを展開しておりました。(上記『ど〜ん』の部分で)
会場前列で豪快に笑っておられた方もいましたが、『あれ』の背景を皆さん御存知だったのでしょうか…(笑)
Session 6:アジャイル検定制度について
- 戸田 孝一郎 氏
セッション最後は検定試験制度について。紹介の対象となっていた検定試験のサイトはこちら。
まだ出来て日も浅く、これまでの総受験者247名に対し合格者は108名=合格率43.7%。
今現在では最下レベルであるL1の試験のみですが、今後上位レベル・範囲の拡大なども視野に入れて展開されていくという事です。
L1は試験時間30分、出題数30問4択形式。受験料は無料です。さほど難しくも無さそうですし、関連の書籍に目を通してみた上で是非チャレンジしてみてはいかがでしょうか。
という感じで長時間にわたるカンファレンスも終了。
帰りはmike_neck(TwitterID:@mike_neck)さん、ひろうぃん(TwitterID:@heroween)さん、そしてきょん(TwitterID:@kyon_mm)さんと近くのファミレスで夕飯&トーク。計3時間超は話し込んだのかな?長時間でしたがあっという間のひと時でした。