memoの場 このページをアンテナに追加 RSSフィード Twitter

2011-04-12

[]QCon Tokyo 2011( #qcontokyo )参加メモ QCon Tokyo 2011( #qcontokyo )参加メモを含むブックマーク QCon Tokyo 2011( #qcontokyo )参加メモのブックマークコメント

QCon Tokyo 2011へ参加した際のメモです.

■日時:2011/04/12(火) 10:00-20:45

■場所:東京ファッションタウン

■参加者数:150名位?

■資料:http://qcontokyo.com/

プログラム

  • 上記参照

■感想

  • とても熱気のある良い場でした.スタッフ・スピーカー・コミュニティ・参加者の皆々様ありがとうございました.
  • 急遽Ericさんと和智さんのサイン会が行われたので,持って行ったDDD日本語版にサインをいただきました.お二人ともサインの書きすぎで大変だったかと思います.快く応じてくださいまして,ありがとうございました.
  • TwitterのEvan Weaverさんやクオリティ&テストパネルディスカッションも聞きたかったです.
    • パラレルセッションは聞きたいものが重なると悩みますね.

■メモ・気づきなど

  • DDDに関して(Eric Evansさん)
    • モデリングすることが中長期的良いというのは思いこみ.
    • ドメインとは,知識または活動の領域であり,モデルとは,そのドメインの洗練された側面を表現する抽象的なシステムである.
    • ドメインには複数のモデルが存在し,モデルは特定のシナリオで役に立つ.
      • 正しいモデルが1つあるのでなく,可能性がある複数のモデルが存在する.
    • モデルの探求のためには,良いシナリオを対象として,モデルをとりあえず作り,ドメインエキスパートに見せ話をしていく.繰り返し.
    • レガシーシステムへDDDを適用する際の効果的な方法も,本中にAnticorruptionLayerやOpenHostServiceなどの戦略などとして書いている.
    • より知りたい場合の参考先
  • 自律的な学びのデザインと誘発 ― 学びのパターン・ランゲージ(井庭さん(慶應義塾大学))
    • 学び方は教わらず,自己で磨いていくしかない.
    • 学び方は1つではない.そこでパターンを作った.
    • パターンは抽象的なので当てはまりやすいが,具体的な学び方は個々に考えるしかない.
    • ミニワークショップ
      • [フルサイズのワークショップの場合]1.過去に経験しているパターンをリストアップ.2.とりいれたいパターンをピックアップ.3.とりいれたいパターンを過去に経験している人を見つけ,経験を聞く.
      • [今回のミニワークショップの場合]1.限定したパターンの中で,過去に経験しているパターンをリストアップ.2.ペアを組む.3.ペアの片方のみ経験しているパターンを経験している人から聞く.
      • パターンは番号ではなく,名前で呼ぶこと.
    • 各自の経験をコミュニケーションしていけた.これにより組織としての経験にもなる.
  • 品質検査技術のトレンド レビューと測定・欠陥工学を中心に-(細川さん(日本アイ・ビー・エム株式会社))
    • レビュー自体は悪いことがわかるだけ.品質が良くなるわけではない.
    • レビューは細々やった方がいい.
      • 前の方に直しておくほうがいい(プレッシャーないし)
    • レビューを嫌う心理的側面もある
      • レビューをやらせる側は考慮するといい.
    • 完璧なペアプロはレビューしたのと,投資や効果が同じと言われている.
    • テスト・品質に関してはアジャイル,トラディショナルな方法では速さは変わらない.
    • プログラム検収の際には,自動化ツールで検出する欠陥部分と,目視で確認する欠陥部分を分けた方が効率的
    • 品質検査も,予備調査,情勢判断,意思決定,行動,の順で実施することでより効果的
    • Pubmedのようなバグのマスターをつくっていきたい.
    • 技法も大事だが,技法でどんなバグが発見できるか知ってほしい.
    • 一流のレビュアは診断屋
    • 品質は腕で作るのではなく,科学の力と眼で創出する
  • Get Clean, Stay Clean - 価値を向上し続けるための秘訣(長沢さん(日本マイクロソフト株式会社))
    • VS2005開発時,開発し続けるために,4ヶ月間開発を止め,見つめ直した.
    • 品質向上させるために,文化や組織,やり方など様々なものを変えた.
      • その結果:技術的負債を10分の1に.高い予測可能性.
    • 開発時には,まずGet Clean, Stay Cleanをすることになった.
      • 継続開発なので,負債とかが溜まっていく.
    • 文化の見直しの1つとして,FeatureComplete,クオリティゲート,隔週のリスク報告義務など
      • コードのCompleteのコストではなく,FeatureのCompleteのコストで考える.
  • アジャイルプロセスの呪縛 (大槻さん(株式会社一),濱さん(株式会社アッズーリ))
    • アジャイルプロセスの呪縛
      • 1.人間中心の呪縛
      • 2.問題解決の呪縛
    • 1.人間中心の呪縛
      • ビジネスを開発者中心の考えになっていないか.
      • 労働力中心
    • 人間中心の呪縛からの解放
      • ソフトウェアの側から見た定量的な分析と評価を進める必要がある.
      • 人間ビジネスから仕掛けビジネスへの転換が必要なのではないか.
    • アジャイルは,価値創造という意味では実現できているが,人月ビジネスからは脱却出来ていない.
      • 価値創造でありながら仕掛けビジネスへの展開することが今後の目標.
トラックバック - http://d.hatena.ne.jp/teyamagu/20110412/p1