■1 デブサミ2005: 1日目

昼休み

タイミングを逸してdotタン、コーチと路頭に迷う。機転を利かせたつもりで弁当を買って会場に戻ったら、食べる場所がないよ……。dotタンとコーチがテーブルを確保してくれたので、どうにか食べることができたが、食べたら食べたでごみ箱が見当たらない……。結局、家まで弁当箱のゴミを持って帰ってしまった。

明日はまともなものを食べるのだ。 参加セッションの感想はまた後ほど。

朝イチ

会社に寄って事務仕事やバーンダウンチャートの整理をしてから表参道へ。

XP事例カタログ

咳さん。XP祭2004でのお話の続き。咳さんのところは早ばやとbeyond XP。チャレンジ項目が:

• 1チームで複数バージョン並行開発
• 非アジャイルチームとの協働

いっかい咳さんの職場を見学してみたいなあ。「バーンダウンチャート……みなさん知ってますよね？」というのが個人的に嬉しかった。

小倉さん。ゲーム開発でのアジャイルプラクティス実践事例。 マスターアップまではイテレーティブにやれる、というのが納得。 「頻繁なリリース」と「納品」とは異なるものだということからの類推ができてなかったなあ。ゲームは受入テストの自動化はできるのかなあ。咳さんの話を聞いている限りだとなかなか難しそうな印象だけど。

猪狩さん。私は関係者なので、客観的な意見ではないとは思うが、メリハリとユーモアがあって、よかった。バーンダウンチャートのバーンアップぶりを史料とした「オンサイト顧客のタイミングのコツ」は、フルタイムでのオンサイト顧客が難しいところにも 参考になると思うのだが、どうか。

dotタンがイテレーション直後のバーンアップについて(?)、「計画時点でスパイクしきれないタスク？」とメモを残しているので、少し補足。イテレーション開始時のイテレーション計画時点では、このイテレーションでやることと、その受入テストの定義が主眼。つまり、Whatが中心。あまりHowについて突っ込んだ話はしない(というかプランニングもタイムボックス化されているのでできない)。プランニングの後、実際にタスクに着手しはじめるとタスクや疑問点が続ぞくと"発見"される。そういう意味では「計画時点でスパイクしきれないタスク」なのだけれど。プロジェクトやメンバーの特性にもよるとは思うけれど、我われのプロジェクトはタスクが"発見"されることが多い。

また、初めての機能を実装するイテレーションでは、機能追加や改善のときに比べると、発見タスクの発生数が格段に多くなる。新機能イテレーションが発見タスクで溢れてしまわないようにするための予防策としては、新機能の実装予定イテレーションよりも少し前のイテレーションでスパイクの時間をとることをストーリーにさせてもらっている。このための時間は2時間〜4時間程度。あらかじめスパイクをしておくとタスク分割の精度が随分あがる。けれど、それでもやっぱり10%〜20%ぐらいの"発見"タスクがあるような印象。

失敗から学ぶプロジェクトマネジメント

「プロジェクトとは本質的に失敗するものである」ドーン!!　お持ち帰り語録としては:

• 「コミュニケーションも仕事」
• 「失敗をナレッジにするのも仕事」

前者は結婚以来の我が家の家訓でもある。家訓であることと、それを巧くやれることとはまた別の話ですが。難しいところ。「コミュニケーションも仕事」に関しては私も語ろうと思えば勝手な思い入れを語れるとは思うけれど、先を急ごう。

秘密会議

「軽量Javaへの潮流」を偵察しようと思っていたけど、id:t-wadaさんとドトールの喫煙フロアに籠って作戦会議。気がつくと「技術系コーチング」の時間に食い込んで話し込んでしまったが、成果はあったので、よしとしよう。

なぜ「オープンソース」でうまくいくのか？——後編：まつもとゆきひろが語る「オープンソース的開発手法の現実」

セッション全体を通してえらくまったりした雰囲気。不思議な空間だった。翌日の神との対話でうかがった話によれば「オープンソース」という言葉は知っているけれど、実践については知らない方(有り体にいえば「スーツ」)向けの「オープンソース開発手法の現実」だったようで、スーツがドン引きになるようなネタは禁止だったそうです。でも、(Ruby1.8系)コミット回数ランキング第3位が我らがDave"達人"Thomas(トップ10圏内唯一の非日本人)とか「BTSめんどくせ」とかいった話を聞けたのがよかった。ちなみにHEADでのコミット回数ランキングでは、まつもとさんは僅差で2位だそうです(!!)。