Agile Conference tokyo 2011に参加してきた #agiletokyo

勉強会 Agile


直前の台風6号が本土上陸、関東直撃か？と言った不安はありましたが、幸い台風は進路を反らし、関東にも上陸する事無く不安は取り除かれ、無事開催会場にも着く事が出来ました。

開催会場は周りを住宅街に囲まれたとても庶民的な(？)風景の中にある江東区文化センター。

Togetterまとめ

その他参戦レポート

関連記事


基調講演：21世紀のソフトウェアデザイン

参加者の多くはこの人を観に来られた、という人が大半だったのではないでしょうか。かくいう私もその一人。XP/オブジェクト指向/UML等で有名なマーチンファウラー氏の基調講演です。

ファウラー氏については以下のサイト等を参照。IT技術者でそれなりに開発手法・技術に興味のある人ならば一度は耳にしているであろうビッグネーム中のビッグネーム。

講演は氏が数センテンス発言→翻訳者による翻訳、の繰り返しで進んで行きました。以下メモ。(翻訳聴きながら、というスタイルは初めてで慣れない部分もあり、結構抜けが多いかと思われます。詳細な内容についてはTogetter関連箇所にて情報補足して頂ければと。)

  • The essense of agile(アジャイルのエッセンス)
    • 1990年代のソフトウェア開発がどういうものだったのか、立ち戻ろう
      • タイムスケール
      • 品質の悪化はしょっちゅう
      • しかしながら先進的な取り組みをしている人達もいる
  • 2000年代
    • アジャイルソフトウェア開発
      • 広まっていくにつれ、Semantic Diffusion(意味の希釈化)を招く一面も。
        • 技術を伝達していくうちに、一番最初のものが見えなくなっていってしまった
        • 『アジャイル運動家』にとっては上記の状況はストレス。
    • Predictive Planning(予測型〜)からAdapting Planning(適合型〜)へ
      • 継続的にプランニングをし続ける、というスタイル
      • ちょっとだけプランニング、実行、学習、プランニング…（小刻み）
      • アジャイルの世界の中では歯車のように動いている
      • Release early and often
        • 早く、頻度を多くリリース
        • Adapting Planning→(needs)→Evolutionary Design/continurous integration/rafactoring
  • 人を配置・配属
  • ここではプロセスが重要
    • 適した人を配置していくアプローチ
  • アジャイルの世界の人々は↑に疑問を持った
    • 優秀な人たちが多い場合は上手くいくが…
  • 能力のある人たちが良い人間関係の下で動かなければよいプロセスがあっても効果が無い
    • 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
  • 統合にともなう痛み・苦しみ
  • 統合頻度の関連グラフ
    • 指数関数的に痛みは引き延ばせば伸ばす程大きくなる
    • どうせ痛むのであればいたくなる前に対処しちゃえば良いのではないか

↓

    • 継続的な統合
      • どんな細かい対応も、メインラインに統合
    • 頻繁にインテグレーションしているので大きな賭けをしなくてすむ
    • 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
    • 出来るだけオートメーション化した方がよろしい！
    • いつでもテスト出来るように、完璧に自動化。
      • Configure environment
      • Deploy binariees
      • Smoke test
      • ：
      • 英国人にとっては金曜の夜に飲みに行くのは重要
      • 日本人も『花金』を楽しんでください(←古っ!)

やべ…英語→翻訳をメモしてるので、内容にかなり自信が無い…(笑)

特別講演：Thoughtworks社による海外導入事例

副題：『〜アジャイルによる技術革新の加速と品質の改善：高パフォーマンスチームの構成要素は何か〜』。

こちらも海外から招かれた凄いお方。Continuous Deliveryの著者であり、ThoughtWorks StudiosのPrincipalな方です。詳細なプロフィールなどはイベント公式等で。

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

  • なぜアジャイルなのか？を考えよう
  • whats the problem？
    • 市場に投入するまでの時間が掛かり過ぎる
      • 最初のリリースに6ヶ月…掛かり過ぎ。→バブルの時代で許されていた部分も？
      • 早いスパンで出してくる企業に対応せねばならない
        • もし大企業に属していてリリースまでに時間が掛かるのなら、小さいところ(＝スタートアップ企業)に食われてしまうかもしれない
        • 大企業の中でのIT環境は複雑になってきている
          • いつまでも終わらない…
        • もっとも基幹業務が最も古いプログラムを使っている場合も
        • 大企業になればなるほど動きづらくなる
          • 色んなものが生き続ける
          • IT部門はコストカットの対象になりがち
        • 顧客満足を優先し、価値のあるソフトウェアをリリース
  • web2.0
    • filckr
      • Yahooが買収、ージョンアップを1日に10回以上している。（未だに継続中）
      • 頻繁なリリースで安定した品質にはハイクオリティな環境が必要
    • ニュースwebサイト。英国で最も有名であり、賞も受賞している
    • 2006年までwebサイト内の記事はほとんど手作業で処理
    • 移行には多くの手間が掛かる、数年に亘って対応する必要があるプログラムであった
    • 古いサイトを新しいサイトに、というだけではない
    • インタラクティブ、ダイナミック、マルチメディア化、ソーシャルネットワーキング対応化…全て行いたい。
    • thoughtworksのやりかた
      • 2週間で変化に対するラフ案を出す
        • どこから始めたらいいかの整理整頓
        • 旅行部門からスタートした
        • 8か月後には作動
        • トラベルサイトに特化して対応した…他の場面には適用可能ではない
      • 2週間の方向付けフェーず：整理整頓に費やした
      • リリース後、PageViewは10倍に増加
    • ビジネスサイドから見て『これだけ変わるのか』と確認出来、自信を得た
      • フィードバックを初期の段階で得ることが出来た
      • 学習した内容を使って次のフェーズを進める
    • 最終的には全部を聡取っ替えしていった
    • 最後は新聞の部分
    • プロジェクトを通じて想定の70%で対応出来た
    • 1日辺り10万トランザクション
    • 大きなレガシープラットフォームを利用
    • 移行には数年を見込み、UKの方で担当者が50人、150人の人々がインドオフィスで計200人が関与
    • こちらも少しずつのリリースで対応していった
    • 利用：Thoughtworks studios agile ALM solution - mingle, Go, Twist
    • 反復的に6週間毎のリリースを行っていった
    • システムがいつでもキチンと作動しているように作業
    • ビルドテストデプロイ自動化・可視化
      • 出来るだけ自動化することが大事
    • virtualizatoin（仮想化）も重要
    • rapid frequent（迅速に、頻繁に）がお客様に高評価
    • 大企業でも小さなところでもアジャイルは適用可能
    • 海外ではアジャイルそのものが主流となっている
      • 調査：業界全体の37%（6ポイント上昇）
        • 1番目：アジャイル、2番目：no definedprocess(決まったプロセスを持たない)
    • じゃあ明日から･･･というほどアジャイルは簡単ではない
    • 組織が障害となりうる･･どうやったら障害を乗り越えられるのか？
  • 組織が障害となりうる･･どうやったら障害を乗り越えられるのか？
    • プロジェクトマネジメントのやり方を変えていく
    • 何かを革新していくやり方を変える
    • 自分たちがその中でどうあるか、という点も問われる
    • 障害
      • 遅い意志決定
      • リスクを嫌う文化
      • 等々･･･
    • ある意味では組織が立ちはだかっている
  • "do less"
    • 出来るだけ少なく事をしましょう
    • アメリカ国防総省
      • 開発したは良いけれど50％以上の機能が使われなかった
      • ソフ開プロセスで無駄
        • 使われない機能を作ってしまう
      • きっとすばらしい：仮説に過ぎない
        • 使っていない＝上手く行ったとは言い難い
    • 盛り沢山にしないで少なく進めて、そこに価値を付加
    • 毎日自分に問いかける『今、この状態でリリース出来るか』 
"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

顧客に欲しい物を聞いてから、それを与えようとしてはいけない。
それを作った時には、もう彼らは他の物を欲しがっているから。
スティーブ･ジョブズ"
      • 多くの人がイノベーション＝ひらめきと考えるがそうではない
      • こんな事が出来たら面白い・すごいんじゃないかなと仮説を立てる
        • それを元に実行出来る製品を考える
        • 最初のリリース（minimum viable product）を届ける
        • フィードバックを得る
        • ↓
        • イノベーションが見えてくる(以下繰り返し)
    • ※このやり方を採用しているスタートアップ企業は必ず成功する。
    • 継続的なデリバリー(continuous delivery) 3つの柱
      • 自動化（ビルド、デプロイ、テスト、リリース、インフラ、DB）
      • パターンとプラクティス
      • コラボレーション（協調）
  • クオリティの話：開発の初期段階から品質を作り込もう
    • インスペクション、テスティングはフェーズ（段階）ではない。いつも行っている
      • バグはすぐに見つかってしかるべきなのに
      • テスターがバグを見つけたら報酬･･･皮肉な話。見つからなかったら･･･に変えるべき
      • qualityはそれに関わる全ての人々の責任である
      • システムのクオリティを全員が見えるようにするのがテスターの仕事。クオリティを確保するのが仕事では無い

ここでは、テストの4象限の図が表示されていました。日本語資料でそのものズバリのものがあったのでリンク。

  • 人についての話：アジャイルなチームをリードしていくにはどうすればいいのか？
    • 人という生き物は何によって動機づけられるのか？
      • お金？→実は必ずしもお金だけではない
      • 創造性？
      • クリエイター…自分が個として自立している、技術を修練・習得している事、エキスパート
      • 目的、使命感･･･商品がどのような価値を見出すのか
      • 全員がひらめきマンであり、クオリティマンであることが重要



この後はセッションが計6つ続きます。11:00〜18:00という長丁場、開始2つの通訳付きでのセッション、途中PCのバッテリーがなくなりかけた･･･等々の要因もあり、全てのセッションを集中して聞く体力は残ってませんでした。印象に残った(＝メモを取れた)もののみ触れていきます。

Session 2：継続的フィードバック

本年5月に米国アトランタのTech･Ed North America の基調講演でこれからのソフトウェア開発のコンセプトとして「継続的フィードバック」が発表されました。このコンセプトは、同時に発表された Visual Studio vNext を待たずして、Team Foundation Server 2010 を中心とした Visual Studio 2010 から実践していくことができます。
本セッションでは、開発スタイルを尊重し、かつ、顧客ビジネスを最大化するためのソフトウェアをデリバリーし続けるポイントと、限界を超えた開発支援ツールの今と、今後について紹介していきます。

講演直前にスライド資料が挙がっていたので、詳細は以下スライドをご参照下さい。

そしてセッションで利用していた動画はこちら。

以下メモ。

  • カンファレンスで話すの3回目(皆勤賞)
  • MS：プラットフォームベンダーの会社です
    • オフィスビジネスアプリケーション
  • 本セッションのスタンス：アジリティを向上させる開発支援技術環境の進化
  • Going agile with tool
    • ふりかえり
    • MSの中の人が『ドッグフード』で作ったものを商品化。→Visual studio
    • 課題
      • 分散したリポジトリ
      • 本業に専念できない
      • 長いwipによるフィードバック遅れ
      • リアルタイムな共有
    • →Visual Studioが対応。
    • Test Manager：一度実行した手動ケースは記録され、自動実行可能。
    • 障害発生時にチェックインをさせない機能
    • リポジトリが1つなので様々な処理が効率化。
  • 継続的デリバリー
    • (滑らかな動画によるデモ実演)
  • 継続的フィードバック
  • ALM 2010 summitに長沢さん日本人でただ一人の参加
  • ビジネスのアジリティが重要
  • ビジネスのアジリティのためには以下が不可欠
  • ツールはシンプルに使いましょう
  • ツールの連携の話は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時間超は話し込んだのかな？長時間でしたがあっという間のひと時でした。

今日のつぶやき 2011/07/20

雑記 Twitter

  • @_john_doe_ なるほど。TDDはやはり実戦参加されるのが一番効果的ですよ。自分もTDD熟練度低めですが今度BootCamp に初参戦します。初心者目線で分かりやすくレポート出来ると良いなあと思ってます。 posted at 23:41:35
  • @libero_18 合格率50%未満なので以外と玉砕確率高めですよねw posted at 23:29:11
  • @_john_doe_ ありがとうございます。しかしust経由のまとめなので実際に参加された方々のレポートには遠く及ばないですよ〜(^-^; posted at 23:25:06
  • 有料化される前にとれる所は取ってみたいですね〜。 QT @tkmnow: 無料ときましたね！ RT @shinyaa31: アジャイル検定、受験料とかは幾らなのかしら？興味深いですな。 #agiletokyo #agiletokyo posted at 23:20:59
  • @libero_18 ですね。取っつき易そうではあるし、時間見つけてチャレンジしてみたいですね。 posted at 23:18:44
  • @kyon_mm @heroween @mike_neck ありがとうございました! posted at 23:14:58
  • agiletokyo 終了後同じく参加されていた @mike_neck さん、 @heroween さん、 @kyon_mm さんと夕飯＆トーク＆トーク。3時間超があっという間。皆さんお疲れ様でした＆ありがとうございました！ posted at 23:12:25
  • アジャイル検定、受験料とかは幾らなのかしら？興味深いですな。 #agiletokyo posted at 17:39:27
  • RT @kawaguti: @changeworlds の笑い声が響く #agiletokyo posted at 17:34:19
  • やはり会社としてプロセス改善に取り組んでいるところは良いなあ。振り返りや改善の記録は参考になる部分は多い。 #agiletokyo posted at 16:57:17
  • こちらの事例は現場感満載で参考に出来る事は多いなあ。後でスライド公開されるのかな？ #agiletokyo posted at 16:53:02
  • RT @QuestionDriven: 先ほどとの違いは、現場感があるかないか、ではないでしょうか #agiletokyo posted at 16:47:25
  • #agiletokyo このセッションは正直響くものが無かったなぁ... posted at 16:15:07
  • いざって時のためにノートPC用の外付けバッテリー用意するかなぁ。 posted at 16:09:41
  • @ShiroKappa @cointoss1973 Let's Note のバッテリーが残り1時間になった時点で一時的に電源を落としました。(^-^; ギリギリ持たせられるペースで行こうと思います。 posted at 16:06:52
  • RT @calpo22: #agiletokyo セッションを聞いてSeleniumのテストケースは作りづらくて放置になってたけど、とりあえず明日の手動テストの操作部分の自動化だけはしとこう、と思った。 posted at 15:58:48
  • RT @tetsu_m: 講演後、すぐにロビーのところに出て聴衆と積極的にコミュニケーションをとっている @tomohn は、ホンモノのヱヴァンジェリストや #agiletokyo posted at 15:58:26
  • お疲れさまです。今日は電源用意されてないのはかなり厳しいですね...。 QT @ShiroKappa: MBAの電池切れた(/ _ ; ) iPad2に乗り換え posted at 15:57:24
  • ノートPC一時シャットダウンして一息入れる。 posted at 15:55:24
  • 一旦マシン落として休憩するか･･･ 残り1時間しか持たないしな。 posted at 15:51:17
  • RT @daipresents: 横浜に近づくほど雨足が強いです posted at 15:47:47
  • 時折赤ちゃんの声が聞こえる･･･ #agiletokyo posted at 15:46:18
  • RT @ryuzee: ながさわさんのすごいのは自分は解はもってないからチームで考えてね♪ってはっきり言えちゃうことだと思う posted at 15:44:12
  • RT @zuisener: No more tools!ツールの議論だけではなく、やりたいことを試すためのツールを議論しよう。試用版はフリー、1日あれば構築できる。 #agiletokyo posted at 15:39:26
  • MSのセッションはスライド/動画/実演デモ/リアルタイム映像等めまぐるしく切り替わっててその辺の豪華さ・展開のスムーズさに驚き。 後でスライド見返してみよう。 #agiletokyo posted at 15:37:24
  • 段々人減ってきたような気がしなくもない #agiletokyo posted at 15:34:23
  • バッテリーがあと1時間しか持たない･･･（>_<）そろそろアナログ（紙とペン）に置き換えようかな。 posted at 15:33:17
  • RT @mori_ryuji: うーむ。動くテストがあれば確かにバグ票そのものがいらんなぁ。 #agiletokyo posted at 15:19:22
  • RT @changeworlds: #agiletokyo IBM も MS も同じ様にツールのプレゼンなんだけど、全然プレゼンの方向性が違うなぁ。 #agiletokyo posted at 15:14:21
  • スライドと動画と実行環境と･･･動きが滑らかすぎる（*_* ）MS系の開発環境だとやはりVisual Studio一択なのだろうか。 #agiletokyo posted at 15:12:55
  • RT @sandinist: microsoft長沢さんのお話スタート "継続的フィードバック" ツールの話もするけどそれだけじゃないよということわりから入った。 #agiletokyo posted at 14:53:33
  • 次の @tomohn さんのセッションは事前にスライドが公開されているので助かります。 #agiletokyo / 【Agile Conference tokyo 2011】 継続的フィードバック http://t.co/iNqXyjl posted at 14:49:50
  • RT @kyon_mm: 日本が。。。とか自動化が。。。じゃなくってExcel使わないと管理してる気になれない人たちが問題なんだと思うんだけどなぁ。。。 #agiletokyo posted at 14:48:39
  • RT @changeworlds: #agiletokyo RTCつかったことあるけど、良いツールなんだけど、説明の仕方があまり好ましくなくて、ツールが可哀想。agileする時にこういう時に困りますが、RTCだとこうやって解決出来ますよって、話にならなかったのが勿体無い。 posted at 14:47:36
  • RT @setunai: ファウラーさん帰っちゃった #agiletokyo posted at 14:47:21
  • 今日は牛尾さんのアジャイルな雄叫びが聞けるのだろうか。 #agiletokyo posted at 14:47:06
  • （；・Д・）高っ！ / 日本IBM、「Jazz」準拠の「Rational」ソフトウェア開発ツール - SourceForge.JP Magazine : オープンソースの話題満載 http://t.co/wDQ2cbU posted at 14:45:31
  • 休憩5分は短いよな〜。10分欲しいところです。 #agiletokyo posted at 14:43:36
  • 同感。 RT @kyon_mm: ですねー　RT @gab_km 何か、14時以前と以後とでのワクワク感のギャップがハンパない…。 #agiletokyo posted at 14:41:36
  • RT @shinodogg: #agiletokyo ツールの機能の説明よりも現場の泥臭い話が聞きたいなぁ。。 posted at 14:39:14
  • RT @gab_km: 何でこんなツールを作ろうとSIerさんって考えちゃうんだろう。例えばScrumなら、要求なんて「顧客」が現場にいるから、すぐに聞けるじゃないか。 #agiletokyo posted at 14:39:12
  • RT @kakutani: 設計の終焉? は小野さんが訳してくれた http://www.objectclub.jp/community/XP-jp/xp_relate/isdesign... #agiletokyo posted at 14:37:46
  • RT @tomohn: MS セッション資料を公開しました http://t.co/tGfJvyR #agiletokyo posted at 14:36:49
  • RT @mike_neck: 「Agile Conference Tokyo 2011 午後 Jez Humble氏の講演 #agiletokyo」をトゥギャりました。 http://togetter.com/li/163764 posted at 14:35:38
  • RT @mike_neck: Agile Conference Tokyo 2011 マーティン・ファウラー氏の基調講演 #agiletokyo http://t.co/1Sh5e2Y posted at 14:35:35
  • ここは製品紹介の時間？ #agiletokyo posted at 14:33:05
  • 1枚辺りの情報量多いな〜（-ω- ） #agiletokyo posted at 14:30:58
  • バッテリーあと3時間･･･持つか？ #agiletokyo posted at 14:06:20
  • RT @lenomick: yuguiさんのギークオーラが半端ない！ l [連載：ギークな女子会] べにぢょ編?−女性Googlerは、とにかく「仕事を面白くする才能」に長けている!! ｜ エンジニアtype http://bit.ly/ppOFwi posted at 12:44:49
  • 周辺施設の予想外の庶民的雰囲気に若干戸惑いつつも昼飯done. 電源の類がないので昼休憩は節電モードで。 #agiletokyo posted at 12:41:07
  • ギリギリ間に合った。 #agiletokyo posted at 10:58:51
  • タクシーの運ちゃんには会場の地図HPを見せて一発理解。こういう時はスマホ便利ですな。 posted at 10:36:20
  • 日本橋からタクってみた。約20分程掛かる見込み。ギリギリかな...。 posted at 10:33:20
  • うむ、日本橋まで電車使って現地まではタクる事にしよう。 posted at 10:17:49
  • #agiletokyo 今日の会場は電源は使えるのかしら？長時間のイベントなのでノートPCの電源が持つか心配。 posted at 09:57:28
  • agiletokyo に参加すべく現在向かっているが予定より少々遅れ気味。東陽町から場所探して歩く事を考えたら日本橋からタクシー使った方が手っ取り早いかなぁ。この天気だし。 posted at 09:53:13
  • 公益財団法人 江東区文化コミュニティ財団 http://t.co/QoMlxio posted at 08:26:03
  • Agile Conference tokyo 2011 - イベントTOP http://t.co/8rwkIAY posted at 08:25:55
  • 台風は列島上陸は無さげな感じなのかしら？予想図見る限りでは。 http://t.co/S7TvwuP posted at 03:43:22
  • 起床。あ"ち"い"･･･（-ω-；） posted at 03:35:10