XP祭り2010

昨日，早稲田大学理工学部校舎で開催されたXP祭り2010に参加してきました．
私自身も初参加だったのですが，会場でも初参加の人が多かったようです．

#xpjugのまとめとしては，
http://togetter.com/li/47581
ですが，取得できていない時間があったので，
http://togetter.com/li/47482
に補完を目的でとぅぎゃりました．

また，各資料へのリンクは下記の通り．

• 平鍋さん：
  • http://slidesha.re/ajotLE
• 清水川さん：
  • http://www.freia.jp/taka/docs/xpfest2010/
• 藤原さん・細澤さん・安藤さん（変更の可能性あり）：
  • http://daipresents.com/weblog/fujihalab/archives/2010/09/xp2010fes.php
• 長沢さん：
  • スライド：http://slidesha.re/bWU6Z8 ，
  • 動画：http://channel9.msdn.com/posts/tomohn/
• 水越さん：
  • http://www.slideshare.net/Akiyah/lt-5131650

とりあえず，全くまとまっていませんが，メモを羅列しておきます．
ぼちぼちとまとめていきます．

■概要メモ：

• XPというよりもアジャイル全般に関するユーザーコミュニティのカンファレンス．
• 参加者は約200名程度であり，ほとんどが開発者および開発マネジャの様子．
  • 今回に限っては初参加者が7割程度と多かった．
• アジャイルに限らず，様々な発表やワークショップが開催された

■感想みたいなこと：

• 細谷さんによるアジャイル開発におけるテストの考え方や，アジャイルプラクティスを用いたプロジェクトマネジメントの話，AglieUXの話など，単純にアジャイルプラクティスについての話ではなく，分野が広がってきているように感じた．
• Agile Conferenceの報告で言われていたが，アジャイルがブームではなく実績勝負の時代に突入していることを感じた．
• 平鍋さんによるアジャイルに関する過去・現在・未来の話など，今後の動向についても考えれているように感じた．

■詳細メモ：

■オープニング　XP入門(小井土さん，福井さん) 9:30-10:00

• アジャイル再来？
• UFJのPMはアジャイル嫌いといっていたが，アジャイルプラクティスをよくやっていた．
  • UFJでは20万人月予定が11万人月．

• 書籍プレゼント，EMZEROへのレビュー掲載あり
• 講演&ワークショップなどで半分，懇親会がもう半分

• 会場の1/3位はアジャイルやってる．実際のプラクティス実施としては，CIが人気．
• ScrumがUSで使われていたはず
• .Netでアジャイル少ない
• C/C++でもテストファーストは有効．組み込みでも．
• コミュニティはUGSS/アイネタ使うと10万くらいの支援費出る．
• XPの目的は優れたソフト開発を行うこと
  • 優れたとは，低コスト，少ない欠陥，高い生産性，投資回収率
  • アジャイルの導入により，コストよりも価値への社会的転換をしている．
  • でも，結局人．
    • アジャイル関係者はいい人が多いかも
• ThoughtWorksでも最初の3，4か月は信頼関係作成に注力する．
• ネットに資料置く予定．
• XPはプログラミングにフォーカスしている．
  • 良いコードの考え方が変わる．
• 結局，理念は全部大事
• XPの特徴として，様々なプラクティスがあることがある．
• どのような規模のチームにも対応可能
  • scale upの話は知見が多いので面白い．
• チームの状況を常に考えることが大事
  • ボトルネックの改善を常に考える
  • にこかれもそんな感じ．
• チーム感を出すときにハンドメイクやローテク大事
• 価値の最大化がアジャイルでは大切だが，それの実現にプラクティス．原則はそれらをつなぐもの．
• 完全・完璧なプロセスはない．
  • できることをしっかりやる．
  • 改善していく．
• XPとは，理想に対する考え方と振る舞い方

■アジャイルxテスト開発プロセスを考える(細谷さん)10:00-10:50

• ”JUDEで学ぶシステムデザイン”（2，3年前に書いた）の著者
• アジャイル tour 2010 oosaka : 2010.10.30(土)
• コンテキストを意識しよう
  • 発表者の背景を意識しないと，自分のところではうまくいかない．
  • 背景がことなると重点がことなる．
  • 森崎さんもそんなブログ書いている
• 背景：組み込み系，品質保証が重視される，開発期間長め
  • 一般受託開発も近いのでは．
• アジャイルで品質はよくなるか？
  • 2001年にXP読み始めて，2003年から会社でやりはじめた．
  • 品質確かに良くなった．
  • 変更が変わるし，品質安定しないのではと思われていた．
• 同じアジャイルで正反対の印象．なぜだ？
• 品質のとらえ方には，1．品質の善し悪し，2．品質の確定性が
• アジャイルでは品質の確定性がアップダウンしながら上昇する
• WFでは品質の確定性が最後の方に一気に上昇する
• WFの方が効率良く品質揚げられそうか？
  • WFかアジャイルかで品質の有利/不利はない！
• WFでうまくいかないときは人災ではないか？
  • WFでは矛盾が下までするっといき，下までいった矛盾はなかなか治らない．
  • アジャイルでは強制的に矛盾が上にいくので解消されるのでは．
• WFでは実際には目標の品質と，実際の品質が異なることが多い．
  • 目標の品質が共有できていないことも多いため．
• 目標の品質を達成することが難しい
• 目標の品質って？
  • 開発対象，ドメインなど背景によって異なる．
  • 計画において定義し，共有することが大切
• 目標の品質を確定するためのテストモデル（考え方，テスト項目）
• テストフェーズで頑張ってもだめなことがあるため，開発対象の品質をあげるべきだろう．
• TEF東海の奥村健二さん，テスト開発プロセスの資料．ETWESTでの発表
• テストを開発しないといけないことは会場ではあまり知られていない模様…
• テスト開発プロセスはあまり実施されていないが実施しないといけないだろう．
• テストのスキルや手順は難しい．
• アジャイルの品質への効果
  • 早期に品質が良くなる．なぜか→早期に開発とテストが協調し始める．
    • テストフェーズでテスト環境の不備や機能不足を早期に発見する．
• アジャイルはWモデルと同じ効果がある
• テストエンジニアとの協調が早期に
• アジャイルでのテストで，品質の確定をどこでおこなうか．
  • いくつかのイテレーションの後に品質確定テスト．
  • 各イテレーションは一般的テスト
  • 一般的テストの情報を品質確定テストへ活かすことでテスト開発をおこなう．
• イテレーションごとにテスト観点を育てていく．また，機能などを育てていく．
  • マトリクスが左および下に成長していく．
• 実践アジャイルテストでは4象限
  • 包括的なテストをする際の参考になる．
• 繰り返しの中で目標品質に到達するためのテストモデルの開発を促進する．
  • 繰り返しをオーバーヘッドととらえない．
  • アジャイルと同じようにテストモデル開発をおこなえるのではないか．

• アジャイルでのテスト開発プロセスの検討
• 様々なコンテキストでのテスト開発プロセスの検討

• 価値と品質の考え方は？品質って何？
  • ユーザーの価値も品質の一つ．
  • 明示的に合意できない品質もある．例えば，いろんなアプリ入れても滞りなく使えること．
• 実際やったの？
  • まだ．
• テストとアジャイルのコミュニティの関係は
  • マニアックスで関係も．
  • アジャイルとテストの関係もソニーの永田さんが反応．
  • 山を東からのぼるか西からのぼるかの違いじゃないか．

■アジャイル開発の現在・過去・未来　-今を知り，源流を訪ね，先を見据える-（平鍋さん）11:00-11:50

• 人数多くてびっくり．
• 8割くらい，祭り初体験．
• なんで再び流行っているのか，アジャイルとは何かを話す．
• XPはAgileより前．
• 福井のブランド大使
• 従来は，ミッション・リスク分割型ビジネスとWF型開発だった．
  • IT側は仕様のみを作成すればよいとなっていた．
  • TATが遅い
• 最近では，市場とビジネスとITが入れ子構造になってきた．
  • ビジネスがアジャイルを求めてきた．
  • アジャイルには変化をプロセス内に組み込んでいるため，良い．
• 仕様がびしっと決まっているなら，WFの方がいい．ただ，仕様が動いているのでアジャイル．
• アジャイルは短いサイクルで分析，設計，実装，テストを並列に行う．
  • 作り直せる環境（IDE，CPUなど）が出来てきたため再び，
• 分割の仕方
  • 分割の機能できる．
  • 層できらない
  • ショートケーキを作り組み合わせてホールケーキにする．
• アジャイルの現在位置
  • 開発者の手法に思われていて，MGR/ビジネスまでいかなかった．
  • Scrumが認定制度を設けたことで，キャズムを超えた．
  • LeanとTPSは別物と考えた方が良い
  • Leanの考え方はサービス，建築，医療など適用範囲が拡大している．
  • BT テレコムの人が，アジャイルを理解させる際に，各層ごとに渡す本を変えている，
  • デミングの思想が影響を与えている．
  • 最近は，大規模化，UXに進んでいる．
  • Kanbanコミュニティがスピンオフしてきている

• XPもパターンに源流を持つ．
  • ソフトの開発にpatternを適用したモノがXP
• ソフト開発はコンテキストに依存することが多い．
  • アジャイルに関しても本を読んでもわかりにくい．
• 良品計画の事例は全部テキストファイルとスクリプト．DBなし．
• 業務を理解している人はコンピュータを理解しないといけないし，逆も然り．

• 非WF型開発研究会からブレイクスルーが出せるのではないか．
• kanban
  • David Andersen
  • CMMIとか，数学的にしっかり表現したい．
• Henrik
  • 流す際には，タスクの固まりではなくて，ユーザーが価値がある思える最小単位を流す．
• ヤマハモーターソリューション
  • ピースごとに流している．
  • 保守行程．
    • 保守行程はアジャイルに向いているかも．ピースピース流せる．
• 看板はイテレーションレス．
  • できたものを1個ずつ進む．
  • Srucmはいくつか単位で進む．
  • WFは全部で進む
• Work in process(WIP): 仕掛費
  • kanban:最小
  • Scrum: 多少
  • WF:いっぱい
• 看板はリードタイム最小
• でも，生産性は同じ．
• 看板が注目されているのは，流れるような開発が行えるのではないかと．
• 海外でKanbanはやってきた．
• PJ系，ファシリテーション，エンジニアリング系
• アジャイルは経験者絶対！経験者に背景理解して貰わないと難しい．
• VPがアジャイル推進し始めた．ただし，世代交代のせいかも．
• アジャイル != Scrum
  • アジャイル - Scrum = エンジニアリングプラクティス，クラフトマンシップ
  • クラフトマンシップの左にあるものをやっていく過程で右が重要だ！
  • XPかも
  • アートオブアジャイルクラフトマンシップ
• アジャイルがキャズム超えた．
• Energized Work
  • 持続可能なペース
  • リ・チャージがないと活気がある仕事にならない．

■EMWEST vol.2 を通じて考えるアジャイルとテスト(細谷さん)13:00-14:10

• マナスリンクの野口さんよりEMWESTの紹介
• EMWESTなどがフリーペーパーである理由紹介
  • 食いつくの良さ8割：多くの人がボランティアで参加
    • 皆で共有したい
  • 広告1割
  • 愛1割
• 細谷さんへバトンタッチし，EMWESTの見所紹介
  • 奈良先端の森崎先生の記事：効果はコンテキスト次第
  • 電通大の西先生の記事：Wモデルはアジャイルに近い
• "アジャイル開発におけるコンテキストとは"として開発サイクルやリリースのタイミングに関して10分位グループ議論
  • そのコンテキストにおける品質向上を通じて，アジャイル開発での品質向上を考える，ための一歩．
  • フィージビリティスタディの時はアジャイルで，製品開発の時はWF
  • 社内システムの機能拡張・保守では，要求単位対応となりアジャイル的．
• "コンテキストに沿ってテストでどのように品質を確保するか"として，どんな課題があるかに関して15分位グループ議論
  • マインドマップ利用
  • 社内システムの機能拡張・保守を取り上げた
  • 複数平行開発による変更箇所の不明確化
  • XDDPなんてどうでしょう
  • 等々いろいろな観点やアイディアが出た
• コンテキストを整えてから議論することは重要
• JaSST 2010 Tokai が10/22に開催．そこでも，この手の話をしようと思っているとのこと．

■今日から始めるTOC-CCPM(竹林さん)14:00-15:00

• パーキンソンの法則：与えられた時間はすべて使ってしまう
• 学生症候群：締め切りぎりぎりまでおこなわない
• 遅れの伝搬
• TOC-CCPM
  • マルチタスク禁止：タスク切り替えオーバーヘッド削減
  • 個人からチームへ：見積もりをチームで考えることでバッファを考えない
    • 半分のタスクは遅れるのでおこらない．
    • 早く終わった場合に，次の回でも期間を短くしないことを約束する．
  • 正確な進捗把握
    • 進捗率とバッファ消費率の軸を持つバッファ傾向グラフで状態を把握する．
• PJの目的・成果物・成功条件を明確にする
  • 成果物は"運用マニュアル"等のように明確にする．
  • 成功条件は関係者全員がうきうきするものとする．
• TOC-CCPMの実例
  • 品質：バグ半減
  • 生産性：1.5倍に
  • スケジュール：3/4
• TOC-CCPMの落とし穴
  • ハイプレッシャー：常に時短勤務を強いられる
  • モチベーション低下："見積もりが甘い"と言われるとへこむ
  • 責任感：時間遅れに対して責任感を感じて何とかしてしまうことやその逆．
• 回避策として，TOC-CCPF
• モチベーション上昇
  • 作業遅延でも作業短縮でもほめる
  • 還元する
• "問題ない？"と聞くのではなく，"問題(気になる点)があるとすれば？"と聞く
• "あと何日でできる？"ではなく，"あと何時間でできる？"と聞く
  • 1日の長さはひとによってまちまちなため
• コンビネーションを意識する
  • チームとして最大のパフォーマンスとなるように．
• Change
  • 経験->挑戦
• TOC-CCPFの実例
  • 品質：バグ半分未満
  • 生産性：2倍
  • スケジュール：半分未満
• 導入するのならばきちんと導入すること
  • 中途半端の導入はぐずぐずになり，導入前より悪くなる．
• 個人の責任を薄くするには．(別の言い方では，責任をチームに移すには)
  • おこらない．
  • 遅れたら仲間が助けにはいるようにする
• TOC-CCPMの進捗管理などはExcelでおこなっている．
  • 公開できる情報は積極的に皆に公開する．
• コンビネーションを考えると専門化し，手伝いにくくなるのでは？
  • 得意な人は手を挙げず，フォロー役になってもらう．
• バッファ傾向グラフで危険領域に入った場合はどのようにすると良いのか？
  • どれだけメンバのやる気をあげられるか
• XPプラクティスを利用している．

■UXのツクリカタ -より良いユーザー体験構築のために検討するべきこと(東さん)15:00-16:00

• UXとは体験
• 経験は人による．コンテキストが異なれば異なる．
• 生産能力の向上により，差別化が求められるようになってきた．
  • 産業革命時，メルセデスは車にソファーをつけることで差別化をはじめた．
  • ソフトウェアも機能的には成熟してきたため，差別化の1つとしてUXが求められてkちあ．
• UXによってコスト削減につなげられることもある．
  • 無駄な機能開発などをしなくとも良くなるため．
• FURPS+:ソフトウェア・メトリクスにおける品質属性（attributes）モデル
  • 機能性（functionality）：
    • 特徴セット、能力、一般性、セキュリティ
  • 使いやすさ（Usability）
    • 人的要因、美的感覚、一貫性、ドキュメンテーション
  • 信頼性（reliability）
    • 故障と周期の重要性、復旧のしやすさ、予測性、正確性、故障の平均時間
  • 性能（Performance）
    • スピード、効率、リソースの消費、スループット、応答時間
  • 保守性（Supportability）
    • テストのしやすさ、拡張性、適用性、保守性、構成のしやすさ、サービスしやすさ、導入のしやすさ、ローカライズしやすさ
  • プロジェクト上の制約（plus Constraints）
    • 実装要求、インターフェイス要求、物理要求
• エクササイズ1：水道の蛇口
  • 水を出すのには，レバーをあげる？レバーをさげる？
• エクササイズ2：コンロの火消し
  • 燃え上がった火を消すためには，どのコンロのレバーを回す？
• UXによって無駄や事故が減る．
• iPhoneはUX業界では"iPhoneのように"などと形容詞になった．
  • UXのレベルを引き上げた
  • ただし，"iPhoneのように"は統一UIなのか，遅延なく動作することなのか，など様々．
• UXの数値評価結果例 -> 技術として良いものであってもお客様まで届かない要因がある．
  • スループット25%向上，エラー率25%低下
  • 63%の人が検索できずに，購入ををあきらめる．
• RIAによって変わるものに，ユーザーのloyaltyがある
  • iPhoneはloyaltyがある．こうなると様々なことがうまくいく．
• JRAでの顧客満足度は95%になった
• ビジネスアプリケーションはアリとキリギリスで言うと，アリとなる
  • 常に使われる
  • 長く使われる
  • 共同作業による開発
• UXの検討
• ハイプ曲線
• 増やすことよりも減らすことを考える
• アプリケーションに対する忠誠心を良い状態にし続ける仕組みを作る．
  • その1つとして，UXを維持させる仕組みをもうける
• UXを維持させる仕組みとして下記の3つ，
  • ビルディングブロックセット
    • ある程度粒度が荒くないとだめ．
    • 例として，レゴブロックとして歯車機構ブロックを用意しておくことで，子供でも利用できる
  • インストラクションガイド
  • 走行可能なサンプル
• Model-View-ViewModel デザインパターン
  • 構成としては，ViewとModelの間にViewModelをはさむ
• なぜペイントではなく，PowerPointを利用するのか．
  • アイコンやテンプレートなど，ビルディングブロックセットがある
  • すでに多くの例が存在し，走行可能なサンプルがある．
• インタラクションはユーザーが起こして欲しいアニメ
  • アメリカの改札はどちらが入り口か不明
• レイアウト
  • 適切に組み替え可能になっていれば，繰り返し使えるとともに，バリエーションがつけられる
    • ほか弁はすごい．
    • iPhoneは整っている
• 変更/改善(ユーザー側)と安定稼働(情報システム側)のギャップを埋めるアーキテクチャが必要
  • ギャップを埋めるために開発中盤に呼ばれることが多い
• 事前にしっかりUIまで設計することは重要
• デザインは実装するもの
• 要求がふわっとしているので早くユーザーに見えることが大事
• プロトタイプのすべてを製品開発で使えるわけではない
• 東さんの会社では，下記のように言葉をきちんと定義している．このことは重要．
  • プロトタイプ：実際の製品開発へ使えるもの．実行可能性を探るもの．テクノロジー依存．
  • モックアップ：上流の合意形成のみに使えるもので，開発には使えない．テクノロジー非依存
    • 紙とかその場で書くものなどもある．
• Flash CatalystやExpression Blendなどを使うこともある
• 差別化できる部分は全体の一部
• UXのサンプルぱたんとして，インフラジスティックスのQuinceがある
• モチベーションの低い人にも継続的に使ってもらわないといけない
  • Business Enablerがいて，はじめてテクノロジーが届けられる．
• 水道の蛇口のように統一できないものはどうする？
  • 赤外線のように全く異なるもので置き換えられるのであれば，それで置き換える．または，パタンを作り，そのシーンに合わせる．
    • 別のものなら，モード分けしたり，マニュアルサポートしたり．
• 東証の入力ミス事件はどう見る？
  • リスク回避のためのUIはできたのではないか．ただし，メール送信時のポップアップと同じように，UIを作ったコンセプトを伝えておかないと形骸化し，失敗する．

■AC2010報告(藤原さん，細澤さん，安藤さん)16:20-16:50

• 洪水のせいで，ナッシュビルからオーランドに
• 江端さん：どういうイベントだったか？
  • 藤原：楽しい．会話たくさん．
  • 細澤：暑い人たちが集まるカンファレンス
  • 安藤：大きなエネルギーがあるところ
• 基調講演，1400人
• 夜はスポンサー&ディナー
  • 行ったら気さくに話してくれる場
• OpenJamスペース4カ所くらいあり
  • セッションの裏で暑い議論
• LiveAid
• ホテルもアジャイル化されていく．postitとかだらけに
• そもそも行くことになったのか．
  • 藤原；アジャイル実践中．カンファレンスの視察＆経験を社内フィードバック
  • 安藤：有名人に会える．家族旅行かねて．
  • 細澤：かわぐ→先輩→細で，お声が．
  • 三者三様
• 行く前の気持ちは？
  • 藤原：夏ばてしてた．いくのやだなぁ．プレッシャーしんどいなぁ．食わず嫌いだった．
  • 細澤：プレッシャーはあった．行ってみると，その場を楽しめた．
  • 安藤：2008年は行けるだけで楽しい．英語ダメだし今年はなぁと思っていたが行くのやめると行かなくなる．
• どんなセッションにでたか．
  • 藤原：エンタープライズ系
  • 安藤：お客様とダンスを踊ろう．Linda等々
  • 細澤：色々
• 毎晩飲んでた．
  • 安藤：主婦が最強話と独身男のモチベ向上話
  • 細澤：何もなくても4時間．それで仲良くなった．
  • 藤原：アジャイル何してるのか聞いていた．
• 参加の感想
  • 藤原：
    • アジャイルが実績勝負の時代に突入してきていると感じた．
    • コーチと経験不安
  • 安藤：
    • Poppendieckと話せた．ボランティアマネジメント．
    • 大規模の事例，基本に忠実だった．地道にコツコツ．
    • 日本の事例がない…．寂しい．
  • 細澤：
    • 熱い．ユーザ・顧客・チーム一番．問題意識高い
    • みんな優しい．英語なんとかなった．
    • コーチ多く，若い人少ない．
• 来年はソルトレークで開催
• 平鍋さん：日本のミッキーの反応は？
  • 藤原：世界との差を感じている．期待は感じるが，背中押せてない．
• 江端さん；なぜ来年も行こうと思うのか？
  • 藤原：自分以外の人が英語しか話していないのが楽しい．変化が楽しい．
  • 細澤：パワーがいい．パワーをもらいに行きたい．
  • 安藤：エネルギーが大きい分，自分も落ちることもあるが，楽しめる可能性があったため．

■AsianPLoP関連の紹介　17:00-17:17:30
鷲崎さん

• XP2011開催．2011.5.10-13.締め切り12月
  • 色々行われる
• プラクティス：実践により結果へとつながる
  • Scrum:スプリント計画
  • XP：チーム全体
• 経験ないと失敗するなら，こういうときにこうするというパタン
• プラクティス：こうしましょう！．
• パタン：こういうときこうしましょ．
• プラクティスもいいが元々のパタンもね．
• AsianPLoP2010
  • 今年3月実施．NII GRACE
  • 英語，日本語並列
  • 投稿16，rider
  • ソフト6編，非IT7編
  • WEBに情報あり：
    • http://patterns-wg.fuka.info.waseda.ac.jp/asianplop/japanese.html
• アジャイル開発の源流となるpatternもみんなでやりたい

本橋さん（AsinaPLoP次回委員長）

• パタン：デザイン，フォーム
• シェファーディングはレビューの1つ
• パタンまちづくりやってる
• 情報処理学会のウィンターワークショップで開催
• AsianPLoP
  • 9月から募集開始
  • 11末論文締め切り
• Lean 余分な肉がない．無駄なく活力がある．
• パタン
  • 知恵や経験をまとめる．
  • パタンランゲージ

■LT大会
長沢さん

• MSとアジャイル
• MSはプラットフォームベンダー
  • 維持・改善しつづける
• Excelはインターフェースとして使って欲しい．
• MSはアジャイル支援してる
  • 会議室解放あり

近藤さん

• 去年からXP，Ruby．
• TDDの神秘
  • Greenが出る画面がいい．
• はじめに設計あるのが良い．
• 一つ一つつくっていくのが良い．
• Greenの画面がつくった感えられる．
• TDDだとはじめに設計図を自ら作れるから良い．

天野さん

• 得する人損する人
• 導入難しい
  • 習慣を変えることが難しい
  • 損得勘定がある
• 利害関係者全員納得すれば導入できる
• リーン開発の本質
• アジャイルソフトウェア開発スクラム
• 人によって受け止め方が違う．
• いんぷり異なる
• ビジネスオーナー乗り気
• あとで資料公開あり

水越さん

• PM＝ポケモン
• ポケモンバトリオゼロをモデリング
  • ポケモンは失敗した
  • UMLでモデリングできた
• これをアジャイルプラクティスに導入できるのでは？
  • バトリオをプロジェクト
  • プラクティス

太田さん

• Stream コンピューティング
  • IBMと日立
• ほんとのリアルタイムを目指す
• 日立と呼び方違う
• Streamスタジオ
• 日本では1件のみ
• 海外ではそこそこ
• 金融，水，電波天文学，交通シミュレーション

樽本さん

• UXの潮流
• UXは5層構造
  • 下からつみあげていくことでよくする
• UCD
• UXは積み上げていく習慣．最低でも月単位
• 役割異なる相手にたくさんDoc生産する．
• WF
• Beck vs Cooper
  • 破局になるかとおもえたが，開拓者が生まれた．
• 内から外へ
• 並行して
  • UXが1スプリント先行
• 軽い手法
• 米国発アジャイルUXの波が起きてる
  • 2013年に来るかと思ってる

林さん

• ふりかえり
• CAがふりかえり
• KPT難しいかも．
• ふりかえりむずい
• おこったことが把握できない．評価できない．
• わかっている課題はすぐ枯渇する．

きんちゃん：矢島さん

• 対話と場がつくるカポエラ．
• コミュニケーションと場がつくるArt．
• 実演
• じんが，攻撃，避ける，ぱふぉーぱんす
• 周り取り囲み
• 楽器，歌，拍手
• 新宿とかでやってる

石橋さん

• zerobaseの人
• 経営寄りの話
• 落としてみてね
• 評価対象がアウトカムがいいがどう評価したらいいか分からない
• 価値の性質
  • 主観的
    • 非客観
  • 取引前提
    • 交渉次第で変化する
• 取引すればわかる
  • 客がいればいいが社内は？→社内取引で評価
• 開発部門と営業部門が取引関係にあると考えることで評価する
• さらに進めて，個人間取引をやっている．
• 会社として自由を保障しないといけない

ぱぱんだ：市谷さん

• 楽天に転職
• 前の会社の話
  • 特殊契約した．
• Sales.comきた．
  • しょぼいけど，すでにあるよ．
• システム
  • 適切にあれば安ければ安いほど良い=SaaS
  • 答え探しがいる=Aglie
• 境界を越えていこう．

江藤さん

• 外資系フランク，SI文化異なる
• 日雇いプログラマを管理するのは大変
• 受け入れテストが重要だが，それ以外に興味があることをある．

■基調LT（渋川さん）

• 基調LTって何か不明なので，普通に話す．
• 長瀬さん，くらぬきさんが前の代表
• LTの作り方
  • 5分間
    • できれば5分楽しんで欲しい
  • 質疑がない
    • 自分ペース
• ニーズとUSPをまず考える
  • 客層について考える
  • なるべく多くの人を楽しませる
    • 聞きたい話をしゃべる
  • 内輪ねた大切
    • ただし，一部だけ分かるのはだめ．全員分かること．
    • 当日セッションの他の人の
  • USP (ゆにーくせりんぐぽいんと)
    • 一番得意なモノ．
      • 客層と一緒ならそのまま発表
      • 違っても喜んで貰えるならそのまま
      • そうでなければ組み合わせる
    • 初心者だけど頑張りましたネタは無敵
      • 成長物語
    • 初心者でも出来ますネタも強い
• ネタを決めたら迷わない
  • まずテキストに書き出す．
    • しゃべり原稿になる．
    • キーデモ．写真，動画も検討する
  • しゃべり原稿は1W前，スライド作成は1,2D前，
  • しゃべり原稿とプレゼン資料は分ける
  • 手を挙げて貰う
    • 参加してもらう．観客をつかむ
  • 1ネタを印象づけるのに注力する
    • サイドストーリーは風化する
  • 笑いは重要
  • 自己紹介不要
  • 続きは懇親会でもそこそこ．全員だと萎えるが．
• 簡単なので，やってみて
  • 会話のきっかけ
  • LTのネタをして思えるようになる．
• ふりかえり
  • XPJUGの歴史
    • 今年は9回目の祭り
    • XPがにほんにもたらしたもの
      • 自動化，DRY，TDDなどのソフトウェア開発技術
      • アジャイルに適した新しい開発技術
        • Java, LL, XML, コンポーネント
      • ファシリテーション：コーチング，振り返り
      • マインドスキル：マインドマップ
• 個人が貰ったモノ
  • たくさんの仲間
  • Pythonに触るきっかけ
  • 本を書くチャンス
  • 雑誌の記事を書くチャンス
  • 就職

• XPJUG
  • 参加したきっかけは？
  • 変わったこと：環境，気持ち，仲間

• 今回のコンセプトは祭り．
  • XPの多様性をそのまま表現
• 財産は人．

• コミュニティ
  • ユーザの協力の下に，一緒に大きなモノを作り上げる
    • 日本では，今までは形のあるものを残すことがあまり考えられていなかった

• コミュニティの方法論こそが企業が今ほしがっていることでないだろうか．
  • モチベーションを維持する
  • 新しい人に入ってもらう
  • 常連になってもらう
  • 周りの人に動いて貰いやすいように仕事を作る