デブサミ2011( #devsumi )1日目参加メモ
デブサミ2011の一日目へ参加した際のメモです．
■日時：2011/02/17(木) - 18(金) 09:30-18:15
■場所：目黒雅叙園
■参考：http://codezine.jp/devsumi/2011/
■参加者数：のべ1000名以上
■参加したセッション
□萩原さん，福井さん -BIG DATA を扱うアーキテクチャーの原則-
□畑さん -Agility@Scale(アジャイル開発のスケールアップ)実戦編-
□小川さん，阪井さん -チケット駆動開発〜タスクマネジメントからAgile開発へ〜-
□鈴木さん，小川さん，吉羽さん，大澤さん -チケット管理システム大戦争 JIRA vs Redmine vs Trac〜ユーザが語る．なぜ私はこのツールを使うのか〜-
□西村さん -今そこにあるScrum-
□高橋さん -RIAの性能テストとアプリケーション品質向上のための管理手法-
□吉岡さん -デブサミオフィシャルコミュニティから選出のLT大会-
■資料
- 講演資料：http://www.slideshare.net/event/developers-summit-2011
- Togetterのリスト：http://togetter.com/t/devsumi?page=1
- デブサミに関するツイートをゼンブ見る！＜デブサ見＞2011：http://labo.artry.net/devsumeet2011/tweets
- デブサミ2011 資料・Togetter集：http://labo.artry.net/devsumeet2011/afterlinks
- デブサミまとめまとめ:2011：http://devsummary.miukoba.net/
■感想
昨年に続き2度目の参加でしたが，技術的にはアジャイル&クラウドの実践に関する話が多いように感じました．そんな中，今回は開発プロセスセッションをメインに，所々，これからのアーキテクチャセッションに参加してきました．
開発における条件(組織の文化なども含めて)がまるっきり一緒になることはそうないので，最近では，紹介されている方法を参考にさせてもらう姿勢で聞くようにしています．特に，「どんな条件」で「どんなことをして」，「どうなった」のうちの，「どんなことをして」「どうなった」の部分の参考にしています．
#「どんな条件」の話も聞けると良いのですが，まだまだその辺の話をきちんと含めた上での話は難しいことが多いのかもしれません．各条件が起因しているのか否かもわかりにくいですので，「どんな条件」自体がわかりにくいですし．
そんな姿勢での講演への参加でしたが，色々なツール・方法論，効果が見られたのは収穫でした．改善を望む限り進歩し続けるのかなと思います．
あと個人的には，開発プロセス系のセッションの会場にいて，銀の弾丸を求める人がまだまだいるのかなと感じました．
■ログ的メモ(長文につき要注意)
□萩原さん，福井さん -BIG DATA を扱うアーキテクチャーの原則-
- VSUGのアーキテクトアカデミーの第3回を兼ねている
- クラウドの先の話．クラウドでビックデータを扱う際の考え
- ビックデータの理由．
- 1.ビデオ発信などコンシューマデータの増加
- 2.センサネットワークのようなセンサデータ
- 3.コンテキストアウェアネス
- ステータス情報だけでなく，ステータスからひっぱりだせる情報の要求が増えている．
- ビックデータをどう扱っていくが問題
- 通勤ラッシュが起きるかがビックデータの示唆を与える．
- 通勤ラッシュはなぜ起きるのか？
- 福井：処理能力が足りないのでは．
- 会場より：負荷，整合性
- スケーラビリティには条件がある
- ボトルネックとなる場所は一箇所に定まらない．
- 窓口が有限なので，その数までしかいかない．
- ある処理が終わらないと処理のまちがある．すなわち，処理時間も条件．
- 窓口と処理時間は分けて考えないといけない．
- N-tierモデル
- Universal Scalability law
- 制約はcontention，coherency
- contentionがフロント
- coherencyバック．MapReduceはこっちを改善する
- データアーキテクチャの開発どうあるべきか．
- 原則1
- 論理レベルのデータ配置
- 更新系と参照系をわける
- 概念上の分類をし，負荷分散のために分割し，最後に配置を考える．
- 論理レベルのデータ配置
- 原則2
- リアルタイム操作のデータモデル：CQRS
- 更新系と参照系を分ける
- 更新系:OLTP，参照系:分析
- 更新系：行指向，参照系：列指向
- いかに一貫性を図るかを検討しないといけない
- 更新系と参照系を分ける
- ビックデータの場合は非正規化するのは無理で，joinがいる．
- そのひとつの実現として，ハッシュジョイン
- 小さい方のデータテーブルを転送する．
- 小さいデータテーブルからハッシュテーブルをメモリ上に作成する．
- そのひとつの実現として，ハッシュジョイン
- アーキテクチャの原則
- データ分割による競合防止
- メモリ上の効率利用
- データ全体を載せるのではなく，インデックスをのせることや分割してのせる．
- その次に転送効率化を目指す
- その次に並列可能箇所の並列実行
- 最後に，負荷分散
- この辺の話は日経SYSTEMSに寄稿している
- 日経SYSTEMSの"クラウドの設計セオリー"
□畑さん -Agility@Scale(アジャイル開発のスケールアップ)実戦編-
- プレゼン資料の配布あり
- プラクティスの話ではなく，他に取り組まないといけないことがあるのではないか
- 日本において，アジャイル開発は実践段階に入った
- アジャイル開発をおこなうにあたって，規模の増大や開発チームのやる気を阻害する原因
- カルチャーや価値観の変更
- 既存ルールの変更，確立されているルール運用の変更
- 過去の管理成果物などの再利用の困難
- 中間管理職のリードやサポートが変革の源となる
- 中間管理職の不安
- 感覚的にやりたくない
- どのように管理するのか
- テクニックの問題
- バーンダウンチャートで進捗感出来るのか
- 複数チームではどうするのか
- 現在，チームがおこなっている具体的なテクニックの中からアジャイルテクニックを取り上げ，発展させる．
- 管理上の仕組みの問題
- 見えすぎて困る
- 遅れの報告の説明が煩雑
- 見えて欲しい人を見方にして，見える方向に持って行く．
- 正面突破で説得するのは難しい場合が多い
- 評価のため失敗したくない
- マネジメントは失敗すると次がない
- さらに上位マネジメントに協力してもらい，チャレンジへの評価リスクを下げてもらう
- QA
□小川さん，阪井さん -チケット駆動開発〜タスクマネジメントからAgile開発へ〜-
- http://www.slideshare.net/akipii.oga/2011agile
- http://www.slideshare.net/MakotoSAKAI/dev2011-17-b31-6970758
- http://togetter.com/li/102077
- 阪井さんから，チケット駆動開発について
- ソフト開発楽しいですか？
- 本来，ものづくりだから楽しいはず
- 不完全な人間間違いを犯さない計算機と戦わないといけない．
- 勉強することなどやることがたくさんある
- 本来，ものづくりだから楽しいはず
- チケット駆動開発は作業抜けを泣くとともにプロジェクトを活性化させる
- 注目される理由
- 小規模かつ高機能なソフト開発
- 環境の流動化
- ユーザ要求の不安定化
- 上記3点より，機敏に動くことが求められる
- 従来の課題
- 課題の解決
- チケット管理方式
- ワークフロー型
- 必ずチェックが入る
- トップダウン組織
- 仕様の一貫性を保証できる
- オープン型
- ネットワーク組織的
- 機敏さ，自由がある
- ワークフロー型
- アジャイル開発の課題
- 頻繁に変わるタスク管理
- 継続的な修正と頻繁なリリース管理
- 本番運用と開発中の2本のコードラインを持つ並行開発
- チケット駆動開発はTracのチケット管理から生まれた
- BTS/ITSをバグ管理だけでなくタスク管理に使う
- チケット駆動開発の運用ルールは2つ
- チケットはタスクカード
- チケットに構成管理情報を付与する
- No Ticket No commit
- 運用サイクル
- バージョン作成
- チケット作成(変更もどんどんチケット作成する)
- チケット解決
- バージョンリリース
- バージョンふりかえり
- 改善要望・障害発生
- 運用後
- アジャイル開発を実践する方法．下記3つ．
- タスク管理をデジタル化
- XPのタスクカードをデジタル化する
- 計画に基づかない突然のタスク管理がやりやすい
- もともとバグ管理ツールなので，突然に強い
- 強力なチケット集計機能
- 小規模リリース
- 自然な変更管理
- ワークフローで変更管理
- バグ修正のワークフローのようにワークフローを定義できるとともに，フローを変更することができる．
- SCM(構成管理ツール)連携でトレーサビリティ
- No Ticket No commitなので，仕様からコードまでトレーサビリティ
- チケットの親子関係で要件管理
- 親チケットをストーリーカード，子チケットをタスクカードに．
- 親チケットの属性に子チケットの情報をロールアップ
- ワークフローで変更管理
- 並行開発
- アジャイル開発は自然に並行開発になる
- リリースブランチとタスクブランチ
- 機能開発のブランチとバグ対策のブランチ，リリースブランチ
- リリースブランチとタスクブランチ
- アジャイル開発は自然に並行開発になる
- 4か条
□鈴木さん，小川さん，吉羽さん，大澤さん -チケット管理システム大戦争 JIRA vs Redmine vs Trac〜ユーザが語る．なぜ私はこのツールを使うのか〜-
- http://www.slideshare.net/SeanOsawa/jira-vs-redmine-vs-trac
- http://togetter.com/li/102109
- デブサミ後に作成された比較サイト：http://confluence.atlassian.co.jp/display/ATL/Comparison+of+issue+tracking+systems
- 大澤さん：JIRA使用歴2年
- アトラシアン
- 大澤推測，表65%，オリジナル25%，チケット管理システム10%
- 「違いを詳しい人に聞いてみよう」がセッションの企画発端
- ハッシュタグ( #itsjp )
- なぜチケット管理システムを使うのか．
- なぜ，そのツールを使っているのか．
- Trac
- Redmine
- JIRA
- チケット管理しかしない．シンプルで必要十分
- マルチプロジェクト前提
- サブシステム，フェーズ，目的などなど
- 優秀なコミュニケーションツール
- 検索クエリーの共有範囲の設定やoffice製品連携，(設定面倒だが)柔軟なワークフロー設定などできる
- 吉羽さん：一過性のコミュニケーションはどう？
- 鈴木さん：使いながら落ち着いていく．チケットの切り方にはノウハウがいる．
- エンタープライズ対応
- 商用製品なので，明確なリリースやパートナー企業がサポート
- 周辺製品との連携充実
- アジャイルPM(GreenHopper)など
- オープンな文化
- 吉羽さん&鈴木さん：GreenHopperのようなかんばんはアナログ・デジタルの使い分けは大事．
- 効果
- 課題
- JIRA
- プラグイン機能の活用
- PMとしての活用
- 顧客からサービスデリバリーまで一元管理
- 蓄積情報の活用
- 拡販
- JIRA
- trac導入
- 使うなら最初から．場として使う
- 顧客にも公開して使ってもらう
- 毎日使い続ける
- 定期的な棚卸をする
- ゴミ箱にしない
- 放置チケット数＝プロジェクトの健康状態
- 自分たちで使い方を継続的に改善する
- もっと使ってもらうようにしてもらいたい．excel作るコスト削減
- 複数のツールに習熟している人はもっと公開してほしい．
- 小川さん：各ツールくせがある．まとめてもらったら，面白いなぁ．
- 鈴木さん；使いこんでいくといい．
- 大澤さん：このセッションがきっかけになればいい．
□西村さん -今そこにあるScrum-
- http://www.slideshare.net/nawoto/clear-and-present-scrum-on-devlopers-summit-2011-6963258
- http://togetter.com/li/102139
- Agile Coaching by Rachel Davies and Liz Sedley
- 今出来ることは何か．
- イベントじゃない人たちに調査した．
- 純粋Scrum58%，残りはXPとのハイブリッド
- 海外の成功事例が出てきたの広まってきた．
- 国内では調査がないので，nawotoさんの場合．
- 海外と同じく，経営層やマネージャーから言われる．
- 作業に集中したいという欲求に答える
- プロジェクトのゴールに近づくことを推奨される
- よく質問する人のそばに座る
- プロジェクトのゴールに近づくことを推奨される
- 初めてのスクラムは楽しい．
- 製品開発終わるとチーム離れる人にとっては，開発中に聞けるのは良い経験
- このままほっておくとスクラムは枯れてしまうのではないかと思う
- そこで，知ってほしいことがある．
- 今の開発チームとスクラムのチームにギャップがある
- チームに責任があることを自覚していない
- スクラムマスタが決めてくれるに違いない
- チームに責任があることを自覚していない
- チームの責任は要求の一覧から決めること→完了まで．
- スクラムはフレームワークのみ．
- 大まかな流れのみ．
- 中身は各自詰める必要がある
- ただし，スクラムガイドにヒントは書いてある．
- 皆が力を貸すこと
- チームは自己組織→答えは，皆が良いと思える方法を入れれば良い．しかし，成果を出す責任はある．好き勝手やってよいわけではない．
- ただし，スクラムガイドにヒントは書いてある．
- だらだらしないために，スクラムではチェックポイントがある．
- できるか不安な人に向けて，明日に備える．
- となりの人の仕事を手伝えるか？
- プラクティスの過程で皆の知識や考えが共有される．
- 今はやりやすい環境が揃ってきた
- 本
- コミュニティ
- QA
- スクラムコーチをしていてどんな時に成功したと思うか？
- 開発者によかったと言ってもらえたとき
- XPじゃなくてスクラムな理由
- 日本人にはどっちが向いている？
- 入れるとしてはXPかもしれないが，あまり区別していない．
- スクラムを支援するツール
- ポスト・イット．初めてやるならアナログがいい．すぐ書き換えられるし．
- 既存のチームにスクラムを導入した場合，効果をどのくらいで感じるか．
- チームとして機能しだすのは1ヶ月くらい
- スクラムのアンチパターンはないか
- 1.スクラムマスタがリードしてしまう．2.チームで仕事をすることが分かっていない．
- SIや受託開発での成功事例は？
- 自分たちが出来ている．相談されているところもSIある．中小のSIで始まっている
- チームの仲悪いと成り立たない？おとなになれない人はチームから外していいか？
- 仕事なので．最悪外す．
- プラクティスを部分的に入れるのがいいのか，全部入れるのがいいか
- ケースバイケースだが，練習なら個別．仕事なら全部．相補作用するので．
- スクラムコーチをしていてどんな時に成功したと思うか？
- 個人的QA@アンオフィシャルパーティ
□高橋さん -RIAの性能テストとアプリケーション品質向上のための管理手法-
- 別途資料参照
□吉岡さん -デブサミオフィシャルコミュニティから選出のLT大会-
- 岩切さんあいさつ
- LT(3分30秒)
- オープンビジネスソフトウェア協会
- WEBのお仕事には名前がのらない．野菜とかにはのっているのに．
- それでいいのか？
- staffroll.net：スタッフロール作成サイト
- shibuya.trac
- チケット駆動開発宣言
- しぶとらの活動の結果
- チケット駆動開発宣言
- 日本mysqlユーザー会
- 略はMyNA
- 2000年発足
- 基本的な活動はML
- 今後ユーザー同士のコミュニケーションを増やす
- GoogleAppEngineユーザー会
- appengine ja night
- 実践的ノウハウの共有
- twitterによる情報共有
- appsと組み合わせるとメールサーバなしでメール遅れる．cronも動く
- jaws user group
- #jawsug
- webサイトあり
- 玉川さんによるブログあり
- 3/4全国大会開催
- java読書会
- 13年目．ずっと変わらず．
- みんなで読んだらめげないのでは
- みんなで音読したらいいじゃない
- 謝辞もソースも音読
- わからなければ声に出して聴く．
- 議事録をメモしている
- 平均12.1人．最小2人，最多30人．月1土曜10：00-17：00
- AgileUCDja
- UCDの6原則
- つまらんので4つ追加している
- ユーザーの声を聞くべからず
- ユーザーに弟子入りし，ユーザの経験を聞く
- 1人のためのデザインをする
- 手を動かしならが考える
- スケッチング&プロトタイピング
- 早期に失敗する
- fast, small, often, smart
- ユーザーの声を聞くべからず
- 要求開発アライアンス
- 関東・関西で開催している
- #redajp
- いかに合意形成するかが最近の話題になっている
- アジャイルプロセス協議会
- www.agileprocess.jp
- 企業中心
- 来年度から個人参加できる体制をつくろうとしている
- ワーキンググループ活動がメイン．本体ではその支援．
- devlove
- 2008/06発足
- 3/1社内勉強会勉強会
- 矢倉大夢
- 中学2年生
- セプキャンの説明
- 若いプログラマキャンプへゴー
- -
