最近みた TechTalks

2007-05-04

溜めないうちに... そういえば最近 Best Tech Videos On The Net というサイトをみつけた. Google TechTalk 以外も色々紹介しているのが面白く, 購読してみてます. 参考まで.

SAXually Explicit Images: Data Mining Large Shape Databases

ABSTRACT:

巨大な時系列データや画像のコレクションをインデクス化する問題は, ここ十年で大きな関心を集めている. しかし, この種のコレクションをデータマイニングするには大きな未探索領域がある. 以下二点のように具体的なデータマイニングの問題を考えてみよう:

Motif Discovery (duplication detection): 大きな時系列データや画像のレポジトリから, 類似したパターン/画像の繰り返しをみつける

Discord Discovery: 大きな時系列データや画像のレポジトリから最も異常な時間や画像をみつける

我々が示すように, このどちらの問題も人類学, 犯罪防止, 動物学, エンターテイメントのような広い分野に応用できる. どちらの問題もオブジェクト数の二乗の時間で解くのは簡単だ. しかし現実の問題では線形時間のみが役に立つ. この講演では, SAX (Symbolic Aggregate ApproXimation) というデータの記号表現がこれらの問題に対する高速でスケーラブルな解法となることを示す.

でかい時系列データをデータマイニングにかけるための画期的なデータ表現を考えましたという話. 具体的なアルゴリズムはよくわからなかったけれど, 解析したデータの具体例が色々でてくるためか, 話は割に面白かった.

symbolic な表現というのは文字列みたいなもの. 実数の列として保存されている実際のデータを, この SAX では文字の列(のようなもの)で表現する. 文字集合というのは要するに有限の整数に対応づけられるから, 結局これは離散化とか量子化の話だと思えばいい. 時系列というけれど, 実際には色々なデータを時系列に符号化できるという. たとえばヒルベルト空間充足を使えばボリュームも時系列になるよねとか.

素朴に考えると, データ全体を舐めて値域を求め, その範囲を適当な幅で分割すればアルファベットにマップすることはできる. ただそんな方法では精度が悪くて使えないから, もっとスマートな方法が必要になる. その表現方法自体はビデオをみるとわかる. ただどうデータマイニングに使えるのかはよくわからない. まあデータマイニングを知らないから仕方ないけど... 線形時間のアルゴリズムも解説されるが, こっちもさっぱり.

そういう専門的なのは抜きにしても, 具体的なアプリケーションの紹介が面白い. 心臓の波形なんかはいかにもデータマイニングっぽいが, そのほかに人類の祖先が描いた壁画, 猿人類の頭蓋骨, セサミストリート(?)のイラストなどをマイニング(クラスタ化とか)する例が出てくる. すげー. 実際に意味にあるデータを相手にした話っていいよね.

講演をした Eamonn Keogh のサイトには SAX のページがある. 概要紹介のスライドとかも置いてある. 論文(" A Symbolic Representation of Time Series, with Implications for Streaming Algorithms. ") もちょっと読んでみたけどやはり具体的なデータマイニング方法のことはわからず. 素人には無理だわ...

Scrum Tuning: Lessons learned from Scrum implementation at Google

ABSTRACT:

Adwords は Google で Scrum を実施し, 小刻みな導入によって目覚しい成功をした. Agile 2006 conference で紹介したように, これは Scrum チームをうまく立ち上げる成功例となっている. Scrum の発明者であり共同創始者である演者は. Google で Scrum を実施するにあたりこの方法をとった. その際の Scrum の難所をいくつか述べ, それから "Google Way" で Scrum を分散, スケールされる次のステップを提案する.

Google の AdWords チームで Scrum やってみたよ, という話. 講演者の Jeff Sutherland は Scrum の親玉の一人. コンサルタントとして AdWords チームに Scrum をもちこんだらしい. なかなか面白かった. Google ファンクラブ的な面白さもあるし, Scrum のケーススタディーとしても楽しめる. 英語は聞きづらいけどスライドが細かめ. 話の半分は一般的な Scrum の紹介で, もう半分が AdWords のケーススタディ. 野次馬としてケーススタディだけ少し詳しめに紹介.

Sutherland は段階的に Scrum を導入する. まず最初は, リリース・バックログとバーンダウンチャート. チームへの負荷が少ないものから選ぶとこうなるらしい. リリース・バックログはチームの TODO リストだからどうせ何か作るだろうし, バーンダウンチャートは Sutherland が作ったんだろうね. リリース・バックログでの要件は曖昧でないものが必要になる. これは HTML のモックで機能を検討する従来のスタイルがそのまま使えたという. モック+メモで要件としては十分ということだろう.

次は daily standup meeting を導入する. これは当初反対を受けたという. ベンチャーはあらゆるプロセスに反対するものだと Sutherland はいうけれど, ミーティングや文書嫌いを美徳とするような文化はありがち. 気持ちはわかる.

Sutherland によると, チームの意思疎通不足で実際に問題が起きており, 朝会導入後はそれが解消したという. たとえば, リファクタリングが盛んなのはいいけど二人で同じ場所をリファクタリングしてしまう. 依存関係のあるモジュールで依存元の完成を待つ時間が長い, 完成したモジュールを QA がテストしたいがテスト方法がわからない, などの問題があったそうな. 最初のうちは朝会の時間が長引きがちだったがそれもすぐ解消し, 最後には Sutherland がいなくても自然と朝会をするくらい根付いた.

あるスプリントで, プロジェクトの遅れが明らかになる. どうも見積りどおりに作業が進んでいない. しかも進みも遅くなりはじめる. Sutherland が原因を探ると, "作業中" 状態で放置されたタスクが多かった. それを完了しようとしても, バグ修正なんかが思ったように進まず後半でずるずる遅れたらしい. ありがちだな. Sutherland はバーンダウンチャート上で "作業中" の数もわかるように "見える化" し, 注意を仰いだ. その後, チームは "作業中" を減らすようになったという.

最初のプロジェクトはこんかなんじで終わったらしい. バーンダウンチャートの可視化は評判がよく, チームはバックログのメンテくらいはしても良いと思うようなった. あとスプリントごとに QA を頼めるので, プロジェクトの最後にドカっと頼むよりはやりやすかったという. 問題点としては, バグ修正のバックログを溜めたせいでプロジェクトの最後で燃えたり, 優先順位のついてない要件があったりしたのがよくなかったとのこと.

こうした反省を踏まえながらプロジェクトは先へ. 次のプロジェクトでは Scrum を強化し, プロダクト・バックログを導入する. これは要件の優先度づけを強化するため. 更に, バグを溜めないべく反復型開発をもちこんでいる. 反復の期間は 2 週間で, その間にバグをとって完動状態にする. 反復型開発の導入は反発を受けがちだけれど, 前プロジェクトでバグを溜めて痛い目にあった反省もありエンジニアは乗り気だったという. ただ QA は大変で, まだ面倒が多いらしい. QA のエンジニアはチームをまたいで働くことが多く, QA の組織が反復型向けに人をつけられないと厳しいということだった.

そんなとこです.

文化と対価

AdWords の例を見る限り, Google は開発プロセスの緩いチームがけっこうありそうだ. まえにいいアジャイルと悪いアジャイルを読んだ時もそんな印象を受けた. 緩いプロセスを好むプログラマは多いし, 失敗したプロセスのせいで嫌な目に遭ったプログラマも多い. この緩さ (世間のいう"自由") が魅力的に映ることはあるんだろうね.

うまく回っているプロセスはラクだし気分もいい. けれどプロセスの導入は失敗することも多い. だからプロセスを持ち込まずに個人を信じ, (AdWords の例に出てきたような) 緩さからくるグダグダのコストは受け入れて "自由" を保つ. そんな選択はありうる. 割が合うのかは怪しいけれど, googly な気はする. オーバーヘッドはスケーラビリティで相殺できるというわけ. プロセスを使いたいチームは使えばいいんだろうしね.

トレードオフとは別に好みの問題もある. 私はプロセスに乗ってラクしたい性質だ. だからその緩さにはそもそもあまり気乗りしない. "自由" は他の方法で担保できてほしい. たとえばいわゆる "xx% 制度" はそのための仕組みの一つだと思う.

逆にプロセスを使わないのも, もしかすると好み ... cultural engineering の一環なのかもしれない. Google は企業文化の設計に力を割いている印象がある. 文化維持費の一環としてシェフやロケット模型にドルを払う. 同じようにソフトウェア開発の生産性を支払う. 予算が許すなら無茶な話でもない.

ただ, プロセスなしの "自由" にかかるコストは一定でない. ソフトウェアの規模が大きくなれば混沌は幾何級数的に増していき, やがて手に負えなくなる. 平たくいえば, プロセスなしに 100 万行を超えるソフトウェアは作れない, 気がする. 彼らはこの先どう問題に向き合っていくのだろうか. Scrum が流行るのか, 何らかのプロセスが芽生えるのか, でかいコンポーネントを作らず疎結合で乗り切るのか, 実は天才プログラマなら 100 万行でもズババっと書けるのか.

野次馬的な興味は尽きない.