X-over Development Conference 2010 ( #XDev )
今日はX-over Development Conference 2010(略称 XDev)に行ってきました.
目的としては,奈良先端大の森崎さん( @smorisaki ),マイクロソフトの
長沢さん( @tomohn ),CECの沼倉さんの講演を聴講することでした.
ちなみに,会の概要は下記の通り.
- 【名称】X-over Development Conference 2010
- 【日時】2010年9月7日(火) 10:30〜17:20(10:00開場)予定
- 【会場】目黒雅叙園(東京都目黒区下目黒1-8-1)
- 【受講料】無料(事前登録制)
- 【主催】日経BPセミナー事業センター
- 【協力】COBOLコンソーシアム
- 【参加者数】私見ですが500人程度
- 【URL】http://itpro.nikkeibp.co.jp/ev/xdev/index.html
ざっくりとした感想としては,まだまだソフトウェア開発技術は成長の余地が
あるなぁということを感じました.逆に,パラダイム変化的な急激な生産効率
向上もないかなぁと感じしました.
#過去に急激な効率向上が起きたのかと言われると思いつきませんが…
参加者の傾向としては,比較的開発チームマネジャーやその上以上の方が
多く参加しているように感じました.
以下では,聴講した各講演に関する私的メモを残しておきます.
いずれ整理したいところです.
■東証が実践、「手戻り」と「不具合」を無くす開発手法
- 東京証券取引所 宇治 浩明 氏
- arrowheadの開発時の話
- 発注者として責任を果たすために意識したことは下記2点
- 成功の勘所
- 危機意識の共有
- 発注者責任の明確化
- リスク管理の可視化
- 経営トップによるPJ推進体制
- 上流工程完璧主義
- フィードバックV字モデル
どうやったら,普通の開発でここまで充実した上流工程にできるのだろう.
やはり危機意識なんだろうか…
■アジリティ向上のためのツール活用 -Visual Studio 2010 の世界観-
- マイクロソフト 長沢 智治 氏
- 開発のアジリティ向上とそのためのVisual StudioとTeam Foundation Server の話.
- あくまでツールは手段という話し方でした.
- 話がうますぎる.エバンジェリストとはこういうものかと実感しました.
- あくまでツールは手段という話し方でした.
- 個人スキルからチーム力へ移行してきている.
- 透明性を確保するツールができてきている.
- VS2010はチームのスキルにあわせた選択を.
- TFSはビルド管理,構成管理,作業項目管理など様々なものの一元化.
- eclipseやoffice,WEBなど多くのI/Fを持っている.
TFSやVSの使わせ方を一度学んでおきたいところです.ツールがよいのは
伝わったので,あとは使ってもらうための障害を少しでも取り除きたいです.
■がんばるだけのレビューになっていませんか?〜 実測データの分析と国際研究動向から対策を導く〜
- 奈良先端科学技術大学院大学 森崎 修司 氏
- 先日のXP祭りでも細谷さんがおっしゃっていたが,「コンテキスト+結果」を対にして因果関係を分析考察してから導入して欲しい.
- レビューが形骸化に至る原因としては,下記3点.
- コミュニケーション不足
- リソース不足
- 事前合意,意識合わせの不備
- 講演内容としては下記3点.
- レビューの原理,原則の紹介
- レビューの成果物は各種ドキュメントに含まれる問題点のリスト
- 課題や状況次第で変化しやすい
- レビュー技法の研究動向紹介
- 自動化,作業分担,優先順位づけがおこなわれるようになってきた.
- プロセス・受発注者の事前合意PJ紹介
- レビューの原理,原則の紹介
キーワードや怪しいところを自動抽出し,そこをチェックというのは良い
アイディアでした.同じような考え方はあちこちで使えそうです.
■HTML、RIA、そしてデータベース 機能/性能テストの自動化で効率向上
※追って追記
DBを使ってテストをしたことがないせいか,あまりしっくりきませんでした.
DBを使って困るとありがたみをかんじるのでしょう.
■AJAX、Flexなど、新時代Webシステムに対する最新テストの勘所
※追って追記
非同期の問題はAjaxに限らず,組込システムのシステムテストで発生する問
題なので,似たようにシステムテストができないかと考え中.
■設計工程の品質確保と改善事例〜日本語の「あいまいさ」を測る〜
- シーイーシー 沼倉 靖弘 氏
- 前半は品質の作られ方の話,中後半はClearDocの話.
- 「まず,予防」
- 実際にレビューができなくとも,設計工程でテストの視点を入れるだけでも効果はある.
- ClearDoc
- 仕様書のあいまいな部分を示してくれる.
- 先の森崎さんの話をツール化したものといえるかも.
- 実績・事例ともにいくつか存在する.応用もいくつか考えられる.
- 仕様書のあいまいな部分を示してくれる.
※追って追記
仕様の勘違いは直せないものの曖昧性を削減し,開発者が意味を取り違える
ことはなくなりそう.今後が面白そうなツール.
■もし情報システム部のマネージャーがドラッカーの『マネジメント』を読んだら
※追って追記
もしドラ読んでいる人は会場の1/3位のようでした.その人達はDruckerの本も読んでいるようでした.