steps to phantasien

Communications of ACM

年始は食べものの調達が億劫で, 大鍋にカレーを作り三日三晩食べ続けた. 量が多過ぎたので最後の夜は友人 M に助けを求めた. 鍋を空にすべくたらふく食べたあと土産にもらったチャイをすすりふと見ると, やはり腹ごなしに本棚を物色していた M が CACM の山に目をとめていた.

CACM: Communications of ACM は, 米国のコンピュータ学会(ACM)が発行する月刊の会誌. 昔々はこれに論文を載せるのが計算機科学者のステータスだった, らしい. たとえば "Goto statement considered harmful" に 続く一連の論争は CACM の投稿欄で行なわれた. ダイクストラがジャンプ放送局に出てくる雑誌を想像してほしい. もうちょっとマシな例だと Quicksort なんかも CACM が初出のよう. 最近は分野の細分化が進み, CACM で最先端の研究が発表されることはなくなった. 今は ACM 界隈の研究を概観できる総合誌になっている.

情報系の大学にいた人ならなんとなく知っている話だろう. 教員の部屋の片隅に転がっている雑誌. M も見覚えがあったらしく, なんでお前はこんなもんを読んでるんだという顔をしていた. "実は結構面白いんだぜ" という話が頭をよぎったものの そのときは満腹の眠気で朦朧としており, そんなのより ベリーダイナマイト を読めと冷たくあしらってしまったごめん. 改めて(ベリーダイナマイトではなく) CACM の宣伝してみたい.

... と思っていたら Amazon で分散システムを作ってる計算機科学者 James Hamilton が Blog で CACM を勧めていた. まず虎の威を借りよう: あの James Hamilton も推薦する CACM を読まないなんて!

いまどきの CACM

私が大学の頃に読んだ CACM は, 基本的にそれほど面白い雑誌ではなかった記憶がある. インフォメーションエンタープライズ云々という話があったと思えば, 何の役に立つんだかわからないしょぼい UI とごっつい数式と謎のグラフをちりばめた論文があり, コラムも何がいいたいんだかわからなかった. そんなイメージ.

ところが在学中に見栄で ACM に加入したまま惰性で購読を続けていたら数年前から段々と改善のきざしがあり, 特に去年は紙面を刷新してバズワード寄りの野次馬や実際のソフトウェアで使われている話, 各分野での新しい話題の抜粋などを扱うようになった. ACM Queue とも結託し, だいぶ読むところが増えてきた. かつてはベローチェの壁紙みたいで興醒めだった表紙も格好よくなった.

というわけで個人的に興味をもった記事や興味のあるプログラマがいそうな記事を 2009 年の発行分から紹介してみる. はじめに ACM ぽくない記事から入って, そのあといかにもなやつをいくつか.

プログラミング

CACM はいかにもな論文だけでなく, ACM Queue の転載などプログラミングの話も "Practice" セクションで扱っている.

たとえば 3 月号は "Erlang の紹介" が載っていた. 書いているのはもともと Amazon S3 の開発者でいまは Google にいる Jim Larson. これは Google が Er(略). 内容はまあふつう. 直接プログラミングの役には立たないけれど, 同じ 3 月号では "ゲームにはゲーム用の言語処理系が必要なんだよ" と熱く語る記事も. たしかに文法はともかくランタイムはもっと工夫の余地があるかもね.

4 月号には DTrace 開発者による "オレオレ言語のススメ" が. カーネルデバッガのマクロの歴史を振り返りながら, オレオレ言語はいいものだと主張する. なぜか D の話はナシ. 同号には "動的言語の ORM" と題した Groovy の ORM (Grails ORM) の紹介記事も. なぜ ActiveRecord じゃなくての GORM なの? という気はする. 若干今更感を感じるのは ACM Queue からの転載だから.

5 月号の "API Design Matters" も ACM Queue から. (むかし紹介していた.) 同じ 5 月号には "Ajax なアプリのデバッグ方法" なんて記事もあり, 非同期のデバッグはろくでもないとぼやいたり arguments.caller を使った疑似スタックトレースの復元方法を紹介したり, ほんとに地味な話をしている.

プログラマ読みもの

プログラミングからは少しはずれたプログラマ向けの読み物も割と多い. 1 月号掲載 "64 ビットへの長い道程" では, CPU のビット数の変遷を概観する. LP64 と LLP64 というのがあってだな, なんて最近の話は後半のちょっとだけ. IBM には 24bit のアドレッシングモードを今でもサポートしてる CPU があってだな, なんて話と同列に扱われている. CPU 歴史は長いのですね...

9 月号, "わかるバージョン管理システム" は, Mercurial 開発者の Bryan O'Sullivan による DSCM 入門. ツールの使い方ではなく DSCM の有難味に 重点を置いているのがそこらへんの入門記事と違うところ. cherrypick, bisect, rebase といった DSCM 固有のアイデアを駆け足で紹介(cherrypick では Darcs の特徴的な依存モデルにも言及)しつつ, DSCM がもつコードレビューとの親和性の高さにきちんと言及するあたり, さすがにわかってるなあ. (なお Bryan O'Sullivan の熱い SCM 語りは Mercurial: The Definitive Guide の一章でも楽しむことができます.)

6 月号では "オープンソースじゃダメなんだ" と題し Stallman が吠えている.

こうした御意見頂戴的記事が多いのも (専門学会誌と比べた) CACM の特徴かもしれない. 4 月号 "社会科学としてのコンピューティング" では, 計算幾何学の教科書に溢れるまったく実社会を motivate しない例や説明文を盾に情報科学と現実世界の乖離を嘆き, 教育ではもうちっと社会の役に立つところを見せろと説く.

"管制よりアーキテクトのトムへ" は, 表題から想像できるようにアーキテクチャ宇宙飛行士の批判. どっかで読んだような... 参考文献ではちゃんと元ネタ も cite されている. 参考文献に漏れがないところは普通の雑誌に比べた学会誌の大きな利点だとおもう. この話自体は割としょーもないけどね.

ご意見系だけでなくジャーナリズムっぽい記事もある. 6 月号 "OLPC の理想と現実" は, セミインサイダーによる OLPC の近況報告とポストモーテムじみた lesson learned. 冷静な分析は一読の価値あり.

ビジネス読みもの

学生の頃はまったくどうでもよかったこの手の読みものも, 年をとるとそれなりに楽しめる. 書籍 "ソフトウエア企業の競争戦略" などの著者である 経営学者の クスマノ は, CACM にも多く原稿を寄せている.

クスマノによる "ビルゲイツの伝説" はタイトルだけで目頭があつくなる. (でも後半で微妙に悪口をいってるのは気にいらない. みんな Gates が好きなのに!) 今年の1月号, 同じくクスマノの "プラットホーム指向の進化" では, プラットホーム大好き論が炸裂する. 私はプラットホームをモノポリーのおまけだと思っているので, 最初からプラットホームを目指せという人間を全面的に信用していない. だからクスマノの言うことも気に入らないけれど, プラットホーム愛好家の語彙を知っておくのは(罵倒の材料として)悪くない. クスマノの考え方がよくわかるのは, 08 年 9 月号の "Apple の不思議" という記事. この中でクスマノは "Apple が製品だけじゃなくプラットホームにも力を注いだらもっとシェアをとれたのにね" という主張をしている. まったくろくでもない. (いちおう最後は "Apple の経営陣は両者のバランスをとろうとしている" とか言ってるけれどあからさまに修辞.) こういう腹立ちは明日への活力なので読むといいです.

Apple 関係ではむしろ "グローバルなイノベーションで価値を掴むのは誰か？ Apple iPod のケーススタディ" が面白かった. iPod を構成する要素技術の原価や利益率を推測し, iPod が売れたときに誰(+どの国)が実際の資金を獲得しているのかを分析する. 要するに "実は中国が儲かっちゃってるんじゃないの？" という米国人の心配を調べてみているわけ. 結論としては Apple や小売店はきっちり儲かってるから イノベーションを頑張るのは報われるんだよ, というところに落ち着く. 個人的には HDD を通じて日本が Apple の 1/3 程度の取り分をゲットしているのが興味深かった. これはでかい iPod の話だけれど, iPhone なんかはどうなんだろうね?

ビジネス読み物では他に "CTO Roundtable" といういかにも退屈なかんじの連載がある. ところが Cloud computing を扱った 8 月号では Amazon の CTO である Werner Vogels がしれっと混じっておりびびった. そりゃあなた CTO だけど...記事自体はエクセクチブな方々向け.

このようにエクセクチブ/マネジメント向けの記事も多い. "Virtual Extension" と題されたセクションはその方向に焦点を置いているらしい. (クスマノもここ.) Virtual Extension では先のようなコラムの他, マネジメントが興味を持ちそうな調査を紹介している. 2 月号 "ノート PC のマルチタスクとミーティング" では, 表題から想像できるとおりの行動について disturb の度合いを調査している. まあダメだよね, という結論. ミーティング中にカチャカチャやってる若者をとっちめたい管理職は読むとよいです. でも実際カチャチャやってるのは年寄の方が多いという気もするので, 若者こそ CACM を盾に上司をいじめるとよいです.

同程度にファニーな調査として 4 月号の "オブジェクト言語と印象管理" も紹介したい. この調査では, オブジェクト言語=モノを介したコミュニケーションですと最初に言い訳し(つまりタイトルは釣り), "IT 関係者" がまわり(=社内)のユーザにとって接しやすい人間であるためにはどうべきかを調査に基いて説く. たとえば机のまわりは綺麗な方がいいとか, 植物がある方がいいとか, 家族の写真が効くとか, デスクトップ PC よりノート PC の方が外交的に見えるとか(ほんとかよ). その上で管理職は部下にオフィスのカスタマイズを許してはどうかと提案する. うかつなカスタマイズはフラットランド住人の写真など逆に敷居を上げてしまう危惧を感じるのは私だけですか.

そのほか 7 月号 "卓袱台返しのエライ人がプロジェクトに与える影響", 9 月号 "アジャイル改で挑むアウトソース", 12 月号 "なぜあなたのプロジェクトは失敗するのか" など. 卓袱台...は ソフトウエア・クリエイティビティ の L.Glass らによる.

ハイテク

と, ここまでは若干ナナメな記事を紹介してきたけれど, ACM の本気はなんといってもハイテク話. "Research Hilight" セクションでは, 大学の研究者に混じり独占的ハイテク企業からの書き手が最近の成果などを割と詳しく紹介している.

1 月号では Amazon の CTO が "Eventually Consistent" の記事を寄稿している. (要はこれ.)

2 月号 "インターネットの性能改善" では, Akamai のエース科学者が CDN について解説する. 規模に応じた複数の CDN アーキテクチャを概観したあと, Akamai がそのどこに位置しているのか, どこに向かっているのかを示し, その困難とプラクティスを紹介する.

同号 "トランザクションメモリによる並列化" では, Redhat の Ulrich Drepper が TM の話を書いている. TM の話は他にも色々あるけれど, glibc メンテナである Ulrich Drepper 視点なのがちょっと面白い. 紹介している実装も gcc のパッチだったりする.

6 月号 "ブラウザにおけるフレーム間通信のセキュリティ確保" は, フラグメントを使った方法などフレーム間通信の手法を概観したあと, そのセキュリティ上の欠陥を指摘, 修正方法を提案する. (大半のブラウザやライブラリに報告の上修正済.) 競合条件をつく手口は見事というかなんというか...こんにちはの怖い人は読むとよいです.

著者のひとり Adam Barth は現在 Google Chrome のチームでセキュリティまわりを見ているらしい. WebKit のレビュア もやっている. Adam Barth はこのほかに "Chrome 開発で学んだブラウザセキュリティ" なんてのも書いている. 8 月号. Chrome 関係だと 他に今年 1 月号 "可搬で未信頼な x86 サンドボックスのための Native Client" なんて記事もあった. Google も CACM 好きだね.

12 月号 "ThinSight: 薄型で対話的な Surface 技術" では, MS Research の研究者が安価にマルチタッチの "Surface" 型ディスプレイを作る方法を紹介している. 光学センサを LCD に統合するのがポイントらしい(がよくわからず). Surface がはやるといいと思っている人は読むとよいです.

MapRecue 対決

James Hamilton が絶賛したのは今年の 1 月号に掲載された MapReduce 対決の記事. 詳しい内容は JH のページ に譲りつつ 野次馬の楽しみを分かちあいたい.

件の対決記事は二本建になっている. 一本目の "MapReduce and Parallel DBMSs: Friends or Foes?" は, DB の大御所 Stonebraker が書いた MapReduce と既存の並列 RDB の比較記事. 両者のアーキテクチャを概観した上で, MapReduce のオリジナル論文にあった grep など, いくつかのタスクについて行なったベンチマーク結果を報告する. その結果は "並列 RDB の方がぜんぜん速い" というもの. Stonebaker は勝負をわけた理由を分析しながら, "こうしてみると Hadoop が遅いのは当然だけど RDB と比べてインストールが楽なのは褒めてやんよ. お互い学ぶことはあるからねフフン." と結論する(脚色あり). Google ファンとしては感じわるい.

Stonebaker は以前 blog で MapReduce: A major step backwards という記事を公開し, 物議をかもしたことがある. CACM の記事はアカデミックな体裁で blog の煽り成分を薄めたものだと見ることができる. 私はもともと MapReduce がデータベースと対比できるとは思ってもいなかったので, blog の記事を読んだときは言わんとするところがよくわからなかった. CACM の記事で紹介されたベンチマークでようやく意図がわかった. 要するに "でかいデータから知りたい情報をひっこぬく" という用途を考えると, MapReduce もデータベースみたいなものと見なせるでしょということらしい.

さて, 話はここから面白くなる. 二本目の記事 "MapReduce: A Flexible Data Processing Tool" で, Jeffery Dean ら Google のエースエンジニアが Stonebraker の主張に意義を唱えるのだ. とっちめてやってくだせえ親方〜っ. 著者らは Stonebraker の主張する MapReduce の欠点ににひとつひとつ反論し, Google 内での MapReduce では指摘されたような欠点を克服済であり, だいたい並列 RDB なんてどのくらい耐故障性あるんだよまったくケッと一蹴する(誇張あり). ほーらごらん!

まあ現実的には公開されておらず使えもしない実装の話をされても困ってしまうけれど, こうした罵り合いじゃないや議論は読んでいて面白い. また Stonebraker の指摘する欠点は Hadoop ユーザの陥りがちな落とし穴として, Jeff Dean の反論はその解決策として読むこともできるかもしれない. EC2 のインスタンス費がかさんで困っている Hadoop ユーザは読むとよいです.

大御所のご神託

ハイテク記事は企業だけでなく, 大学発の研究もある. というか数ではこっちが多いはず. 特に親玉級の研究者がガツンと申し上げるホワイトペーパーは, 数はそう多くないけれど CACM らしい内容だと思う.

6 月号 "The Claremont Report on Database Research" は, 10 年毎に発行されるデータベース研究の指南書のようなもの. (専門家による紹介.) 10 年前は "The Asilomar Report on Database Research" だったらしい. DB 研究者でなくともバズ用語を仕入れて同僚を煙にまきたい先端愛好家は読むといいです.

10 月号 "A View of the Parallel Computing Landscape" は同じようなノリの並列プログラミング版で, ただ定期刊行物じゃなくてこれが初出. データベースのイケイケな感じにくらべると, どうしたらいいかわからない暗中模索な感じが伝わってきてやや胃が痛い. さっさとケリがついて Concurrency for Dummies みたいのを出せればいいのに. そういえば同じ Berkeley から出ている Cloud computing のホワイトペーパー "Aboeve the cloud" は CACM は載らなかったね.

ハイテクアルゴリズム

計算機科学といえばアルゴリズムとデータ構造! といいつつ私はだいぶ得意じゃないので流行ものっぽいのを二本だけ紹介.

5 月号 "Scalable Synchronous Queues" は java.concurrent とかの lock-free 実装を越えるスーパー並列キューの話. らしい. ごめん途中までしか読んでない. 著者には例のごとく Doug Lea がいる. (Java並行処理プログラミング の人ですね.)

10 月号 "Finding the Frequent Items in Streams of Data" はストリーム内に登場する最頻要素をみつけるアルゴリズムの簡単なサーベイ. 後半に登場する Count Sketch アルゴリズムがよくわからずぐぐったら Radium Software で紹介されていた. CACM の前に Radium Software を購読するとよいです. それにしてもストリームアルゴリズムって流行りそうで流行らないかんじだなあ. 専門家は使ってんのかな？

そういえば一部で大流行りな Seam Carving の元ねた "Seam Carving for Media Retargeting" も 1 月号に載っていた. (読んでない.)

リサーチ

ハイテクの話もいいけれど, アカデミックならではの話も読みたい. CACM はそんな欲求にも応えてくれる. といいつつ私にはそういうのをくまなく読めるリテラシーがないので ほとんど猫に小判. それでも中には面白い話があった. ここでも 2 本だけ.

"分散開発はソフトウェアの品質に影響するのか？ Windows Vista の実践ケーススタディ" は, Microsoft Research による表題通りの調査. 北米, 欧州, アジアの 21 キャンパス(事務所) に分散した Windows Vista 開発の記録と出荷後のバグ発生件数を元に, 分散開発と一箇所での (collocated) 開発の品質を比較する. 同様の調査はこれまでもあったが, 大半はいわゆる "オフショア" や "アウトソース" のプロジェクトだった. 調査には Microsoft のような単一企業内の対等なチームによる分散開発では何が起こるのか知りたいとう動機があったようだ. データの分析は "ほとんど差がない" という衝撃の事実を明らかにする. 著者は考えうる理由としてチームやオフィスの立場や力関係の対等さ, 文化的障壁を下げるための社員派遣, ツールの統一, ライフサイクルを通じて一貫した所有権, 共通のスケジュール, 経営を含めた組織の統一性などを挙げている.

まあ既存の調査が "修正の要求から実際の修正までの時間" といった柔軟性の指標を使っているところに "出荷後のバグ報告数" のような計測可能(かつある程度予防可能)な指標を持ってくるあたりに若干の後ろ暗さを感じなくはないけれど, オレたちソフトウェアを作らせたら凄いんだぜ! という Microsoft の力強い自負は伝わってきた. Vista は失敗だの Azure は継続的なんとかだのと煩い外野に苛立っている MS ファンは読むとよいです. 個人的には既存研究も読みたかったけど IEEE (入ってない) だったよ...

つづき. 9 月号 "Spamalytics: スパム広告コンバーションの実践分析" は, スパムメールの効果のほどを調べるために, ちょっとばかし botnet を拝借してスパムを送ってみましたよ, という話. 色々な意味で面白い.

(おそらく honeypot に飼っている) botnet の中継サーバをクラック(?) して 配信すべきメールを自分達のサイトに誘導するよう書き換え, 数百万台のワーカー bot から数億通のスパムメールを配信したという. そして偽スパムサイトに辿りつき "buy" をクリックしたユーザを数え, スパムの到達率を計算している. はたしてスパマーはどのくらい左団扇なのか？ スパマーに広告を頼むのは割に合うのか？ 気になる人は読むとよいです.

私の中ではスパマー=スパム王なので, 色々と感慨深いよみものでありました. 最近のスパム事情(バイアグラを売るかわりに嘘の企業情報を流して株価を操作する Stock Spam)の話や, ハイジャックした botnet である Storm Botnet の アーキテクチャ紹介も面白かった.

そのほか

と, だいたい面白かった話は紹介したつもりになって気が済んだ. (自分の興味にあったジャンルがないという人は, 単に私の軽薄な偏りが口に合わないだけだと思うので, バックナンバー目次を眺めてみると良いかもしれません. 機械学習や NP 完全もあるよ!)

そのほか ACM がやっているチューリング章を受賞した Liskov のインタビュー を読んでめちゃめちゃ現役なのにびびってみたり, Quicksort を発明した Hoare のインタビュー を読んでまだ生きてたかとびびってみたり, 海に消えた Jim Gray を悼んでみたり, 計算機科学有名人の話題にはことかかない.

ニュース欄もそこらへんのニュースサイトとはちょっとズレたかんじで面白い時がある. (インターネット中毒の話とか.) あとは SIGGRAPH の宣伝に夏を感じてみたりもできる.

毎号 100 ページちょっとのコンパクトな体裁なのに, 暇さえあれば隅々まで飽きずに読める盛り沢山な内容で, しかもフルカラー. 船便で印刷版が届くほか, 発行直後に PDF 公開のお知らせも届く. ACM 会員になれば ACM Digital Library にもアクセスできるから, ぐぐってみつけた論文が非公開で読めず涙することもなくなる. (IEEE や Springer などのトラップは除く.) まあ CACM に限らずコンピュータ系の読み物はウェブで検索すれば何割かは公開されているのがみつかるんだけれど, CACM については話題の取捨に有難味があると思う.

すわ購読! と思ったひとは オンラインのフォーム から ACM に入るとよいです.

学費の見返り

CACM を特に勧めたいのは, 情報系の学科出身だけれど仕事はハイテク感がなくて悲しい思いをしているひとたち(=情報系の卒業生大半). 世間の多くのプログラムは CS 的な価値観だと trivial なものが大半なので, 輪読や実験など辛い思いをした日々や完済遥かな奨学金がいまいち報われない感があるかもしれない. かといってたまに現れる non-trivial な問題と戦える腕もない. こうしてハイテクへの憧れは退屈の埃にまみれ挫折の泥に沈んでいく. けれど CACM を読んで人類の英知と野望の一端を楽しめるのは大学卒業の見返りとして悪くないと思う. 煤けた憧れにひとつまみの輝きを呼び戻してくれるから.

スポーツをしたことがあればプロスポーツ観戦の興奮が高まるように, 楽器をやったことがあれば音楽鑑賞の楽しみが増すように, 情報科学をかじったことがあればハイテク野次馬の蘊蓄にも磨きがかかるというもの. アルゴリズムがわからいまま適当に実装したらさっぱり動かず卒論の締切間近な四面楚歌だとか, 三年前の論文を読んで改良を試していたらもっと良いアルゴリズムが半年前に発表されてた修論の締切間近な五里霧中だとか, そういう心配なしに読む CACM は, 最新の面白いコンピュータ話をつまみ食いできる割と楽しい読み物なのでした. ほんとはね.

近況

プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう.

最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない.

フェーズ 1 - Trac, Excel, たまにペアプロ

いまのチームはプログラマが 3 人, 上司が 1 人いる. 一年前, プロジェクトが始まったときのプログラマは年寄 A と若者 B の 2 人だった.

プロジェクトのはじめに書くコードの質はその後のプロジェクトを左右する. A はプロジェクトの構造 (たとえば tier の数やプロセスの分割, 使う言語やライブラリ...) にいくつか思惑を持っていたが, 一部のモジュールについてはさっさと B に仕事を押し付けたいとも考えていた. そこで A はいくつかの雛形を書き, そのノリで実装を続けるよう B に作業を引き継いだ. A は B がどんなコードを書くかよく知らなかったので, 最初のうちしばらくは一日の半分程度をペアプログラミングで進めた. たとえば B は単体テストを頼りにコードを書くスタイルを身につけていなかったが, A はペアプロを通じて B が単体テスト主導でコードを書くよう求めた.

機能は第一に Excel 上のリスト ("product backlog") で管理し, 実装作業は Trac のチケットとして管理した. 機能と作業は 1:1 に対応することもあったが, 多くは 1:N だった. product backlog 上の進捗更新は 2 週に一度だった. (つまり 1 イテレーションは 2 週間だった.)

フェーズ 2 - 人がふえる, 印刷チケット

最初のリリースが済んだあと, 別のプロジェクトからプログラマ C がやってきた. (フェーズ 1 の段階で最終的なリリースには間に合わないことがわかっており, 助けを求めていた.)

コードのスタイルは固まってきたように思えたので, 以前ほどペアプロはやらなくなった. C はまだプロジェクトのコードベースに慣れていなかったが, C に頼みたい部分は既存のコードの接合が疎な上に A にも思惑のない部分だったため, フェーズ 1 での B のようにペアプロをすることはなかった.

C はアジャイルを愛好しており, 特にタスクボードなど tangible な路線を好んでいた. C の提案により, チームは進捗の可視化をはじめた. Trac のチケットを印刷して壁に貼り, 進捗に応じてマスを移動していく. 印刷用のチケットは C 謹製のスクリプトで作られた. A4 1 枚あたり 15 のチケットを, ハサミでチョキチョキ切って壁の模造紙に貼りつけた.

フェーズ 3 - Trac チケット廃止, 一方向メールレビュー

アジャイル好きの A と C は オブジェクト倶楽部２００９夏イベント に参加した. 基調講演のスライドには様々なプロジェクトのタスクボードが写真で 紹介されており, それが C の興味を引いた.

自分達のチームとあの写真はだいぶ違うというのが A と C の共通見解だった. 写真でみたタスクボードはカラフルだし, カードのテキストも手書きだ. 自分達の印刷したカードはどうもしょぼい. 一方で Trac の内容を色ペンでカードに書き移すのは面倒くさい.

いっそ Trac との二重管理はやめてしまえばいいと C は主張した. A は懐疑的だったが, 実際のところチケットが電子化されている利点を活用していないのも事実だった. イベント参加の勢いもあり, バグ管理以外は Trac をやめてみることにした. 翌日にはポストイットにチケットを転記し, Trac 上ではチケットを close した. B は突然のアナログ化を訝しんでいたが, 勢いに水を差すほどではなかった.

半月後, ポストイットの使いにくさを嫌気した C はどこからかインデクスカードを持ち込み, ポストイットをインデクスカードに転記した. 同時に kakutani.com に学んだという ひっつき虫 も導入された. このときも A は大した興味を示さなかったが, タスクボードの利便性は大きく改善した. インデクスカード+ひっつき虫はポストイットにくらべ剥がす/貼るの繰り返しに強く, 保存もしやすい.

それはさておき, A は最近一月ほどのチケットのスループット低下を気にしていた. 著しくスループットをおとしていた B にインタビューすると, テストの実装に時間がかかっているという. コードをみると xUTP のアンチパターンを絵に描いたような光景が広がっていた. その反省から A はチームのコードをレビューするようになる. Subversion から前日の差分を確認し, 指摘事項をメールする形でレビューを開始した.

フェーズ 4 - 炎上, 野ざらし

中間リリース前の試験でいくつか大きな問題がみつかり, 解決にむけ過労な日々がはじまった. 序盤の計画に不備があったためのトラブルで, 簡単な解決はなかった. 試行錯誤を通じいくらか改善した上で顧客に謝罪し, 最終的に一応の決着はみた.

過労期間中のイテレーションは破綻した. 作業時間のうち調査が多くの割合を占め, 計画が立たない. また外出も増えてスプリント計画のミーティングは流会が続いた. 結果として一ヶ月以上イテレーション計画が更新されなかった. タスクボードにはインデクスカードが山積していった. (作業をインデクスカードに書くことはやめていなかった.) 各人が作業に忙殺され, レビューも行われなくなった.

チームは誰もが疲弊していた. 気がつくと夏が終わっていた.

フェーズ 5 - イテレーション短縮, ハンコレビュー

フェーズ 4 は正しく終えることができなかった. 書面の都合で形式的なリリースをしたあと, 次の工期に食い込みながら問題の改善を続けていたからだ. リリースの区切れ目がはっきりしないまま, 済し崩し的に次のリリースに向けた作業が始まるなか, B がポストモーテムを強く求めた. A と C はミーティングを好まない上に横着な性格だったため, わざわざ管理職を掴まえて場所を確保して...と面倒の多いポストモーテムに積極的でなかった. B はそれを察知し, なかば強引にポストモーテム開催を押し切った.

ポストモーテムでは, イテレーションのミーティングやコードレビュー, ペアプログラミングといったそれらしい活動が壊滅していた点が問題点に挙がった. たとえばイテレーションは二週間で区切られていたが, 月に二回の再計画ではミーティングが流会すると予定がずれすぎて悲惨という指摘があった. ちょうど アート・オブ・アジャイル デベロップメント を読み終えたところだった C は Shore にならった一週間のイテレーションを提案し, 試してみることになった.

結果としてこれは上手くいった. もともとチームは誰も計画能力が高くないため, 二週間のイテレーションにぴったりの作業を積み上げるのは難しかった. またプロジェクト自体も流動性が高く, 新しい要望を二週間保留するのは現実的でなかった. なにより作業の単位として "一週間" は区切りがよく, ミーティング場所の確保や管理職の都合, 対外的な足並みなどを融通しやすかった.

レビューについては, 風化しやすい点と A だけが一方的にレビューをしている点が問題視された. どうすればレビューをさぼらずに済ませるかを相談し, タスク=インデクスカード単位のワークフローにレビューを持ち込むことになった. 作業が終わったインデクスカードを適当なメンバーに渡し, レビューを求める. レビューが済んだら作業完了とする. 全員がレビュアであり, 同時にレビュイにもなる.

加えて, レビューを受理したメンバーはインデクスカードにハンコを押すことになった. これもうまく行った. タスクボード上でハンコの押されたカードの量がチームの進捗を表すようになると, ハンコをおさずに作業を終えたと主張するのが難しくなる. だからレビュイーはレビューをさぼらなくなる. レビュアー側も, レビューをさぼっていると机に手渡されたインデクスカードが溜まってしまう. だから最低でも一定数のカードがたまると重い腰をあげてレビューをするようになる. ハンコを押すのがそれなりに気分が良いのも思わぬ発見だった. カードとハンコがレビューに tangibleness を与えた. (ハンコとレビューの高い親和性は他でも見ることができる. 基本的にレビューを必須とする webkit では, ふだんは "Reviewed By" と書くべき ChangeLog のエントリに時折 "Rubber Stamped by" という メッセージがあらわれる.)

ハンコによって進捗を見せるため, タスクボードを進捗ステータスによって分割しなくて済むようになったのも 思わぬ副作用だった. チームが使っているタスクボードはそれほど大きくないため, ステータス毎に面積を食わないのは都合が良い.

フェーズ 6 - プラニング・ポーカー

プロジェクトのなりゆき上, 炎上フェーズ以降このフェーズまで大きな機能要求が保留され, 細々とした機能追加と様々なインフラの準備で日々が過ぎていた. しかしこのフェーズ以降, また大きな機能追加がいくつも予定されていた.

イテレーションを 1 週間に縮めてタスクボードが秩序をとりもどしてから, 顧客から要望が届き次第とりあえず見積りをする習慣ができつつあった. 顧客とのミーティングから戻った A が "また要望が増えた..." とぼやくと, それじゃ見積りですかね, と手近な机で見積りがはじまる. タスクボードにもある種の割れ窓効果があり, ステータスの曖昧なカードが散乱していると見積りの意欲が削がれる. 逆に手綱を持っている実感があると見積りにも精がでた.

チームではプラニング・ポーカー風の見積りを採用していた. ただしポーカーのカードはなく, 紙切れの端に数字を書いていた. また Trac 主体で作業を管理していた頃はチームでの見積りをさぼりがちだった.

あるとき C がどこからかプラニング・ポーカーの実物を入手してきたので, 実際の見積りにも使ってみた. トランプと紙切れの差は, インデクスカードとポストイットの違いほど大きくはなかったが, メンバー間の見積りが不一致だった場合の議論と再見積りは身軽になった.

フェーズ 7 - product backlog の復活

フェーズ 3 の頃から, プロジェクトの冒頭で作った product backlog は保守しきれなくなっていた. イテレーション感覚が長すぎたこと, product backlog と trac の二重管理, 長期間のトラブル対処などがあり, 新しい作業はタスクボードに直行するようになっていた.

一方で, 大きな単位の作業見積りや進捗の報告にタスクボードとインデクスカードは向かなかった. タスクボードに収まるのは 1-2 週間分の作業に過ぎず, これまでの作業を振り返るのはやりにくい. 将来のリリースに関する計画についても同じことが言える.

直近 1-2 フェーズの見直しで目先の秩序は取り戻せていたため, チームは大局的な混乱の回復に目を向けることができた. 顧客から新しい機能要求の見積りを求められたとき, C の提案によって古い product backlog は一旦捨てることになった. そしてタスクボード(とプレ・タスクボードのカード入れ)に積み上がった 機能のリストを product backlog の Excel シートにバックポートした. こうして作成された product backlog は顧客への進捗報告に用いるようになった.

進捗報告のためにアドホックな資料を捏造しないというのも, フェーズ 5 のポストモーテムからあらわれた反省だった. 顧客からのプレッシャーに晒された人間がアドホックに資料をつくると, 都合の悪い事実(=遅れ)を顧客から隠しがちになる. そうした目先のごまかしも炎上を招いた一因だという反省があった.

ごっこあそびの習熟

ハンコレビューの話をするつもりが, 一年をだらだら振り返る内容になってしまった. まあ年末ですからね...

今のチームの成果が文句なし, という気はない. テストが遅いとか, 顧客のフィードバックを十分にとりこめてないとか, 運用のやりづらいシステムとか, 不満は色々ある. "アジャイルだ" というつもりもない. プロジェクトは大粒のリリースからなる半ウォーターフォールで, 毎週顧客にデモすることもない. 契約も硬直的で変化を抱きしめるどころか下手すると突き放しかねない. いわゆる "アジャイルごっこ" の域を出ていない. でも "ビジネスとアジャイル" のような議論を蒸し返したくないので, 今はごっこ遊びを卒業するアイデアを考えない.

ここ 1-2 年, チームで働く意義や, チームの善し悪しに興味を持ってきた. 今日の話もそれが主題. 今年の仕事はこの興味にいくらか答えてくれたと思う.

たとえば, 私は上で紹介したハンコレビューを気に入っている. それは仕組み自体よりこの方法に至った経緯を支持したいからだ.

ハンコレビューはインデクスカードを使う. インデクスカードはプロジェクト途中に C が持ち込んだものだ. (しかも最初はポストイットだった.) 最初にレビューをはじめたのは A だったし, プロジェクトの混乱後にプロセスを立て直せたのは, 規律にうるさい B がポストモーテムを開催したからだった. 見積りにポーカーを持ち込んだのは C だった. 継続的な見積りをさぼらず続けられたのは B の姑気質によるもので, 開発者の見積りが幅を効かせているのは A がはじめにそうしたからだ.

チームの記憶

こう書くと, チームはメンバー選びが重要で 1+1 が以下略とありがちな主張を続けたくなるかもしれない. メンバー選びがどうでも良いとは思わないけれど, 私はその手の組合せ最適化主義によってチームの価値を裏付けるのを好まない. チームメンバーの組合せがよければ, 最初から良い仕事ができるのだろうか?

ハンコレビューの話にもどると, まずインデクスカードを使う気になったのは, しばらく Trac を使っていた二人がタスクカードに関する基調講演を聞いたからだ. Trac の善し悪しに関する共通の体験があったからこそ, それを捨ててインデクスカードを使う気になった. 体験を共有していないプロジェクトの冒頭に同じ議論はできない. (私の勤務先はどのチームも Trac を使っているけれど, その依存度はまちまち. "共通の体験" とはいえない.)

レビューのプロセスを改善する気になったのは, その前に不完全なレビューをしていたからだろう. プロセスのまずさに合意があったからこそ, それを正そうという議論ができる. レビューをはじめたのも, それまでに書いたコードの負債に対する不安をわかりあっていたからだ. 見積りを改善する気になったのは, ザルな見積りのせいで迎えたリリース前の酷い夜を思いだすからだし, 流会つづきで野ざらしになったタスクカードの苦い記憶がイテレーションの短縮につながった. タスクボードのレイアウト変更に抵抗がないのは, Trac 放棄に大した手間を要さなかった過去の体験があるからだ.

共に失敗したからチームとして反省できるし, チームでの反省があるから各人の好みにあわないプロセス変更にも手がだせる. 何かをうまくやった記憶があるからそれを失なったことがわかる. メンバーの性格を理解できるから自分の立ち位置を選べる. 信頼して仕事を任せることもできる.

反省や体験, 記憶や理解には時間がかかる. 逆に言えば, チームとして過ごした時間にはそうした代えがたい価値が潜んでいる.

Grady Booch は, ソフトウェアのアーキテクチャが <種族の記憶> に潜んでいると語った. (とむかし平鍋 blog に書いてあった.) Booch の文脈はレガシーソフトウェアの保守に関するもので, だからアーキテクチャを明らかにするには当時の開発者にインタビューをする必要がある, といった話につながる. レガシーコードから失われたアーキテクチャを復元する取り組みを, Booch は "ソフトウェア考古学" と呼んだ.

チームの記憶は, Booch のいう "種族の記憶" に似ている. ソフトウェアのアーキテクチャだけでなく, もっと多くの記憶が蓄積されている. (上司の寝坊の程度, 同僚の飽きっぽさ, バグの調査にでかけた日の昼食...) Booch の興味は失われた記憶の復元にあったが, 私達開発者は失われる前の記憶をもっている. その記憶を失わずにすめば, 考古学者の世話にならなくても済むだろう.

プロジェクト指向の組織は, プロジェクト単位でチームを集め, 解散する. "チームの記憶" に価値を認めるなら, こうしたプロジェクト単位のチーム構成がどれだけ散財なのかがわかると思う. プロジェクトを通じて蓄えた記憶の山を, 納品と同時に処分してしまう. シュレッダーにかけられた機密書類のように切り刻まれるチームの記憶.

考古学者にさよならを

伝え聞く限り, チームの記憶がもつ価値に意識的なソフトウェア開発組織は多くない. チームの価値創出を組合せ最適化だと捉えている組織もある.

パッケージソフトウェアや自社サービスの開発など, プロジェクトのおわりで解散する動機のうすい開発チームは, 結果としてチームとしての能力を高める傾向があるようだ. 単発の受託開発が主体の組織は, プロジェクト毎に記憶を捨てがちになる. 失われた記憶を取り戻そうと引き継ぎ文書書きに明け暮れる様は悲しい. 生きたソフトウェアをつくるはずの費用が博物館づくりに消えていく.

様々な商業上の制約によって, チームを壊さなければいけないことがあるのもわかる. けれど無自覚にそれを破壊しているように見える場面に出会うことは多い. 本当にその解散は割に合っているのか? 無形の財を踏みにじりながら, ソフトウェアで価値を生み出していると胸を張れるのか？

未来のソフトウェア考古学者より, いま目の前にいる利用者のために働きたい... と大仰な主張をする気はないけれど, チームの記憶を大切にした方が楽しく働けると思うんだよね.

といったところで良いお年を.

最近もらった本 - アジャイルな見積りと計画づくり

(最近はうそです. もらってから半年くらいたってます....)

プロジェクト管理の本だった. 見積りの話も丁寧に書かれている. プロジェクト管理の二本柱(PMBOK による) "計画" と "監視制御" のうち, "計画" に占めるソフトウェア開発固有な部分は見積りくらいだから, 当然といえば当然かも. 前半 2/3 が計画(=見積り), 後半 1/3 が監視制御の話. 顧客に見積りや計画を求められる管理職には読んでおいて欲しい気がしたけれど, 管理職が読むのを期待するよりは自分で読んで見積りができるようにしておく方が たぶん現実的だし, 本書の趣旨にもあっていると思う.

本書の前半で説明されている見積りについて言えば, 規律にうるさい マコネルの見積り と比べ 実施の敷居は低い気がするので, まずはこのコーン式見積りをやってみるのが良さそう. 私のいるチームも planning poker もどきをやったりしている. 未熟なのでまだ精度は低いけれど, プレッシャーで見積りが縮むことは減ったとおもう. (そういえば "痛ポーカーがあればいいのに" という話を見積のたびにしている. 本題とは関係ないけど誰かに作ってほしい.)

本書後半の監視と制御の話は, タスクボードやバーンダウンチャートなど Scrum 周辺で見かける話とかぶった. ただ他のアジャイルの本と違ってテストやリファクタリングなどコード寄りの話がなく, 自分の苦手な部分が抜き出されている感じで申しわけなくなりながら読んだ. 監視や制御について自分は素人だと再認識した.

面倒の取り分

世の中には PM という名の管理職制度があるせいで, 管理職でない下っ端が自分は管理をしなくて良いと誤解することがある. 基本的に管理の仕事は面倒だから, アジャイルになったところで必ずしも楽しいものではない. 作業時間を記録する, タスクをカードに書きだす, ポイントを集計してチャートを書く, バグに追われて機嫌の悪い同僚にミーティングを促す ... 意志が弱かったり締切に終われたりすると, 言い訳を探してさぼりがちになる. 管理職の存在は格好の言い訳を与えてくれる.

ところが現実の管理職がこうした面倒を引き受けてくれることは少ない. 私がこれまで見てきた管理職の仕事は渉外が主で, 身内の世話に十分な資源を割く例は少なかった. 顧客対応のコストが大きい受託開発ではよくあるパターンだと想像している. 字面だけ見ると管理の仕事を管理職がやるのは当然だから, チームを管理しない管理職を責めるのは当然と感じるかもしれないし, いくらかは憂さ晴らしにもなる. けれど次のプロジェクトで同じ管理職の面倒見がよくなることもまずないだろう. 下手をすると管理と銘打った謎のエクセルシートに記入を求められ, 更なる不幸を招くかもしれない. (エクセルに恨みはないけれど, 気に入らない場面にはいつも顔を出すんだよね...) プログラマが忙しい程度には管理職も忙しいと考えるのが自然だ.

コーンの本をはじめとするアジャイルの開発手法は, 私達プログラマが管理職に押し付けながら書類に埋もれ果たされることのないモヤモヤした期待を, 名前のついた部品=プラクティスにばらしてくれる. 部品にばらされたことで, 私達はそれを検分することができる. ああ, これは自分でやった方がいいな. これは管理職よりお客さんに頼まないと. これは経営判断がいる. これはいらない...

従来のプロジェクト管理手法も独自の部品をもっているけれど, そこにプログラマ向けの部品はなかったと思う. だからプログラマは安心して <管理> を 管理職にまかせ, 管理職は誤った判断を下し, プロジェクトは失敗し, 異動が発令され, 焼け野原から這い出したプログラマは亡き管理職の無能を偲べばよかった. 平社員万歳!

コーンの切り出した部品は, モヤモヤの中にはプログラマの成分も多く含まれていることを示した. 見積りと計画, その追跡は代表格. こういう仕事は面倒で, できればやりたくない. でも他人に任せるともっとひどいことになる. 面倒でも不恰好でも自分でやった方がいい. (正直なところ私は見積りが劇下手なので, 自分が見積りや追跡をしたところで失敗することはよくある. けれど自分の見積りが下手で炎上するのと上司がアホで炎上するのとでは, 前者の方がだいぶ腑に落ちやすい.)

私は日頃から プログラマは管理職のどんぶり判断にプロジェクトを委ねるな と主張しているのだけれど, プログラマがコード書き以外にどんな役割を果たすべきか, そのために何をすればいいのかの道筋を示せず, もどかしく思っていた. コーンの本はそれをある程度説明してくれた.

見積りと追跡は当然として, 自分がその先どの責務まで踏み込むべきかは今も私にとって自明でない. ただコーンがそのモヤモヤに絞って輪郭を与えたおかげで, いくらかは考えが進んだ. 結局私達の多くはプリマドンナではないし, 私達の管理職の多くは BillG のインタビューを突破していないし, 私のオフィスは西海岸でもシアトルでもマンハッタンでもなく新宿のはずれにあり(これは別にいいんだけど), 潤沢な資金をもたらす革新的/独占的ソフトウェアのために働いていたりはしない. 私達の多くは, 才能からでなく面倒を引き受けることで対価を受け取っている. 数多ある小さな面倒を一つ一つ拾い上げ解きほぐす手管が, プログラマのうたうひとつのアルトなのだと思う.