デブサミ2009参加

devsumi2009

一昨年は1コマしかいけず、去年は全く行けなかったこともあって今年は会社休んでフル参加。
初めてマインドマップでメモなんかを取ってみた。
でも追いつかないところがかなりあったけど一応まとめてみる。


★2/12(木)

  • 12-A-1　開発プロセスの心
    • 開発プロセスとは見える化である
    • いろいろなプロセス(WF、反復型(RUP/UPなど)、Agile)
      • WF
        • オープン系以前はできることが決まっていたのでこれでよかった。
        • オープン系は出来る事が広がり、要求が複雑になったので、これじゃだめ。
        • 要求検証、アーキテクチャ検証が必要？
        • 成功させるにはこれらを隠れプロセスとして行っている。
      • イテレーティブ
        • リファレンスモデルとして実際はにはカスタムが必要
        • 要求(ユースケース)、アーキの検証で遂行で破綻する
        • 豆蔵時代からのポリシー「検証したものを提供する」
        • リスクマネジメント重要
      • Agile
        • プロセスは重視しないが存在する。
        • モデリングは走りながら行う。
        • Documentは目的に沿ったもののみ。
    • 反復とAgile
      • 反復は計画重視、Agileは価値重視
    • プロセスを進化させていかないとだめ
      • WF＞予算主導でなくしていく
      • 反復型＞要求開発が軽視されている
      • Agile＞ビジネススケールを考慮：ビジネスの場でこそ生きる
    • 要求開発はリコーソフトのWebを参照とのこと
    • 開発プロセスの進む方向
      • 要求開発のテーマは繋げる事
      • コタツモデル(かわいいイラスト)
        • 現場−経営−ITをつなげる
      • ビジネス開発とシステム開発を平行に進めることで価値が生まれる
      • もっとリアルなプランニングを(Agile？)
      • システム開発はクリエイティブな仕事、管理型から人の能力を活かすプロセスに
    • 守・破・離
    • 最適プロセスを作っていこう
　感想：
　開発プロセスの話。
　Agile志望の人間としてはAgile方面に進むべきという話に共感。
　自分の中で新しい話はそんなになかったけど整理された感じです。
  • 12-C-2　未来へつながる言語(印象に残ったとこだけ)
    • Pascal入門の本をかって読んだが、実行環境がなかった。
    • 今日はRubyの話はしない。
    • 世界最初の言語はPlankalkul(1948)、例外処理まであった。
    • でも実装されたのは2001年
    • まつもとさんの会社では半分はRubyの仕事で食ってる。
    • 残りの半分はCOBOL；病院関係のレセプトシステム
    • 子供を連れて行った病院では導入されてたとのこと
    • 温故知新。昔の言語のコンセプトが今取り上げられてトレンドになっている。
    • APLに注目してる
　感想：
　Bと迷ったけど生まつもとさんを見たことがなかったのでこちらへ
　生まつもとさんをはじめてみたけどいい人っぽいなぁと思った。(なんだそりゃ)
　あとは言語おたくなんだなぁという感じ。
　いろいろな話が聞けて面白かった。
　そのうち関数型言語、勉強しようかなぁ。
　っていうかまずはRubyか。
  • 12-A-3　時を越えたプログラミングの道への道(印象に残ったとこだけ)
    • プログラムを書いたことのないシステムエンジニアが
    • 威張っているような会社は
    • 早晩亡びる
    • XPの元ねたは時を越えた建設への道by Clistopher Alexander
    • XPを世に問い続けろ
　感想：
　Eと迷ったけどこちらへ
　いつものように熱い話でした。
　XPの元ねたがあるのは知らなかった。
  • 12-B-4　並列処理開発を支援するコンパイラの機能
    • あまり覚えてないのでパス　
  • 12-A-5　ユーザー責任で25サイトをアジャイルに開発
    • リクルートの事例
    • 以前の考え方
      • サービススタート時の失敗はNG
      • いろいろ突っ込んでしまう
      • 開発長期化
      • 長期化すると次回はかなり後になってしまう
      • なのでいろいろ突っ込もうとする
      • 悪のスパイラル
    • スピードを早く！考え方を変える取り組み＞SWAT
      • スタート時100%→スモールスタート
      • いろいろ検討→コアに注力
      • 積み上げ予算→キャップをかぶせる(上限設定？)
      • ステークホルダの調整→ある程度チームに権限委譲
      • WF→Agile
    • SWAT(なんの略かは忘れた)
      • スピード
        • 1500FP 3ヶ月
      • Agile
        • 朝会、バーンダウンチャートetc
        • タイムボックス1week
        • Docレビュー×
      • コミュニケーション
        • ユーザ確認
        • 要件確認会
        • 80%ルール！！
        • ジャッジを早くする為、100%確定しなくとも80%で前に進める
        • ある程度手戻りがあってもそれは許容しスピード優先
      • シンプルDocument
　感想：
　ユーザー企業なのにすごい。
　80%ルール重要。
　ジャッジを早くすればいろいろ決まってくるので見えてくる。
　いい話を聞かせていただいた。
　要件確認会はうちにも必要だ。自分が伝言ゲームの中間の役になってる。
　これはいいセッションだった
  • 12-C-6　飛行船で萌え〜なんたらかんたら(覚えてるとこだけ)
    • 組み込みの技術者育成コミュニティでの取り組み？
    • スプーンをたたく音声パターンによって実際の飛行船を操作
    • Google Earthを使ってのシミュレータを開発
    • そのバグとり
    • 高度がマイナスになるバグ
    • 想定しない音声パターンでおちるバグ
    • 状態遷移図が不十分
    • きちっと状態船意表を整理して、未確定事項をつぶす
　感想：
　発表者の方も話していたが、組み込み系でも業務系に通じるところはあるかも
　あと組み込みだと年配の方でも現役でコード書いたりするというのはいいなぁ
  • 12-D-7　LT大会
　感想：
　A、Cとまよってこちらへ
　AはXP祭りとかで話を聞ける人だし、Cははてブリニューアルは記事になってたし
　わんくまの人面白かった。どら娘のつぼに入っていたのも面白かった
　漫才もあった。
　沢マンすごい
　いろんなコミュニティあるなぁ
　今仕事で開発できないから、コミュニティとか参加しようかなぁと思った。

ふぅ、一日目だけでお腹一杯。
2日目に続く。


★2/13(金)

  • 13-E-1　システムの見える化(ちゃんとメモ取ってないので感想のみ)
　感想：
　PPT資料をプレゼンモードじゃなく使っていた
　大規模はWF9割
　データを基に話していたので説得力はある
　ただし、データに取れていないところもあるのでは。
　結合以降の不具合数のデータを基にWFは品質が低くないとか。
　自分が関わった大規模なシステムは3つあるんだけど、3つとも結合以降でぼろぼろだったんだけどなぁ。
　たとえば仕様変更扱いとしたものは入ってないとかか？
　どのようなデータをとるかなどは主観的な部分。
　永和さんとかがこのようにデータ集めてみたらまた違う結果が出るのかな。
　ただこういう取り組みは重要だと思った。
  • 13-E-2　アート・オブ・アジャイルデベロップメント
    • タイトル本よりテスト関係の話を
    • Developer Testing
      • Red-Green-Refactorの前にThinkが加わっている
      • ピンポンペアリング→REDで交代
      • すばやく(何分か忘れた)テストできないものはもはやユニットテストではない
    • Customer Testing
      • 顧客に判断してもらう
    • QAテスト
      • XPでは存在しない
      • バグ0にするためには、33/37のプラクティスをやる必要がある
      • 探索的テストが代替？
    • ビジネス価値
      • バスタブモデル
        • Agileでは常時テストしてるので、テストフェーズを最後にもってくる必要がない？
      • レガシー、既存のテストコードがなかったら？
        • エンドツーエンドでストを書く
        • DBリファクタの本
      • 顧客2人に対してPG3人くらいでないと、顧客側確認などが遅れる要因となる
      • 顧客にもAgileを
　感想：
　QAというか、非機能要件的なテストはAgileでもいるんじゃないかな。
　DBリファクタの本はあとで読む
　顧客側2人にPG3人というのはまあそうかな。
　確かに顧客側でとまることが多い。
  • 13-E-3　Hudsonによる印栗メンタルな開発
    • 自己紹介：Hudsonコミッタの方
    • はじめに：HudsonはCIツール
    • CI
      • XPプラクティス
      • 頻繁にビルド
      • メリット
        • 品質
        • 手戻りコスト減
    • Hudson
      • OSSのCIツール
      • 簡単、手軽、親切
      • いろいろ対応
      • SCM：SVN、CVS、VSS、GIT etc
      • Build：Ant、Maven、sh、bat etc
      • Report：(忘れた)
      • BTS：trac、jira　etc
    • サンプル
    • CIでビルドがこけても犯人探しをしちゃだめよ
　感想：
　B、Dと迷ったけどこちらへ
　以前CruiseControlは使ったことがあるけど、日本語化されてるしいい感じ
　使う機会があればつかってみたいな
  • 13-E-4　「レガシーコード」とはいったい！？(感想のみ)
　感想：
　昔いた会社の人(面識なし)がいた。
　テストコードのないコードがレガシーコードだ！！
　あなたが書いているのもレガシーコード？
　→今はほとんどコード書きませんが、うちの会社にあるコードはほぼ全部レガシーコードです
　本体側に手を入れてテストできるようなコードにしていくこともある
　→これは昔やっていたので同感
　レガシーコードに対する実践的なやり方(PassNullなど)は機会があれば参考になるかな
  • 13-B-5　アーキテクトって何ですか？(感想のみ)
　感想：
　Cとまよったけどこちらへ
　MCA取得のプロセス
　ジェダイ協議会？
　日本に2人
　全部英語
　熱く語るといいらしい
　福井さんってやっぱりすごい人なんだ
　福井さんの考えるアーキテクトって何でも屋？
　PMは予算管理し、引き締め約
　でも人は交換可能じゃないよ＞＜
　お父さんとお母さん？QCDのバランスは共有
　お酒は本物か？
　契約は請負でもその中でAgile的にできるところはあるのでやっている。大規模でも
  • 13-A-6　ひよこクラブ　ver.Engineer
    • よしおりさん：java
    • ほりさん：javascript
      • Y!フロントエンドエンジニア
      • 勉強法
    • 一井さん：php
      • ソースなんかはダウンロードしておくのがお勧め
      • 毎日やることが大事
      • ペチパー
    • 谷口さん（にぽたん）：perl
      • 管理職
      • でもコードは書く、割合は減ったけど
      • プレッシャーにならない程度に勉強
      • ぐぐる
      • 本
      • 読む：coderepos、GitHubなど
      • 書く
      • output＞blog
      • 管理職も悪くないよ、でも人は選ぶかも
　感想：
　今回1番のセッションかも
　outputか。
　でも当たり前だけどoutputする為には、何かやらないとoutputできないからやらなきゃ
　とりあえずデブサミの感想はまずoutput
  • 13-B-7　「気づき」をみんなで共有しよう(感想のみ)
　感想：
　A,Eと迷ったけど参加型セッションだったし行きたいセッションかぶってたから結構見れてないのがあったのでこちらへ
　B会場なのに人数が少なすぎ・・ちょっとびびった
　小井戸さんの帳票セッションの話しを聞けてよかった
　カードゲームでプロマネセッションがよかったみたい。
　大阪、仙台から来ている人もいた
　思いの熱さ、刺激を直接感じることができてよかった
　参加してよかった

まじめにメモ取れていないので、取り留めないし、だいぶすっ飛ばしているところはあると思うけどとりあえずOUTPUT。
熱、刺激をもらったけど、今の状況でこれをどうしていくかを考えないと。。。