2011-09-13

最近もらった本: アジャイルサムライ

いただきました. ありがとうございます.

そして読んでいるうちに, どうも自分はアジャイルへの興味が失せていると気付いた. さいわい "アジャイルサムライ" は良く書かれており 感想はもうウェブ上にたくさんあるようなのでここでは保留し, かわりになぜ自分の関心が失せたのかを説明してみたいと思う.

理由はだいたい二つある気がする. ひとつはしょうもない理由: 私の参加しているプロジェクトはとても大きく, 独自の開発スタイルをもっている. したっぱの自分はそのやり方に口を出す気がなかなかおきない. 時差があり英語も苦手(これはほんと情けなくて泣ける)だからなおさら乗り気でない. 変える気がないものへの関心は薄れる.

二つ目はもう少しマシな理由. 件のプロジェクトはそこそこアジャイル風になっている. おおよそ time-boxed にリリースがあるし, 開発者の自動テストもある. リファクタリングは日常で, あまり BDUF してる様子もない. 官僚的なやり方は大変嫌われており, 小心者としてはもう少し官僚的というかルールがあってもいいんじゃないかと思うこともある. セキュリティ/プライバシや UI に関係する変更にはそれなりのプロセスがあるけれど, それは書類を埋めれば突破できる牧歌的官僚制というよりエキスパートとやりあう決闘... というとおおげさだけど白熱しがちな議論の舞台となる. プログラマ同士がやりあうコードレビューが一番官僚的といえば官僚的かもしれない. 命名規約からデザインまで, 割と細かく指摘をうけるし, 自分もそういう指摘をする.

開発スタイルに関する議論で <アジャイル> という言葉を目にすることはほとんどない. かわりに意思決定/開発の <スピード> や開発者の <生産性> , プロダクトやコードの <品質> は引き上げるべき価値としてよく強調される. 反復開発や試行錯誤は議論の前提になっている. プロジェクトの中心的なメンバーや勤務先の文化が作りだしたこの開発スタイルは割とよくできているため, まあこんなもんでいいかと思えてくる.

デザインパターン

むかしデザインパターンというソフトウェア開発のアイデアが一世を風靡したことがあった. まともなおっさんプログラマならだいたいデザインパターンのことを知っているし, 情熱をもって勉強した人も多いと思う. 私もそれなりに熱心だった頃がある.

アジャイルはデザインパターンに似たところがある.

デザインパターンは C++ と Java の時代に生まれた. 実際, C++ や Java で仕事をするならデザインパターンを知っていた方が都合が良い. こうした言語でぼんやりコードを書くとひどいものになる. 柔軟さや保守性より性能や互換性を優先した言語のデザインや, 歴史的経緯で広まってしまったまずいデザインのライブラリやフレームワークがプログラマを取り囲んでいるからだ. デザインパターンは言語ニュートラルな <良いデザイン> である以上に, ある種の言語がもつ落とし穴のワークアラウンド集として読むことができた. (というのはだいたい Peter Norvig のうけうりです.)

Ruby や Python など比較的モダンな言語で暮らすプログラマは, かつての C++/Java プログラマのような情熱をもってデザインパターンに取り組まないと思う. 新しい言語には, そもそもデザインパターンが意識していた落とし穴が少いからだ. Norvig によると GoF の 23 パターンのうち 16 種類は Lisp だとえらく簡単に実装できるという. 要するに普通に書けばだいたい OK というわけ.

空気

Norvig は言語機能だけに議論を絞っていたけれど, デザインパターンへの意識は開発者の身のまわりにあるコード資産の影響も大きいと私は思う. 歴史のある C++ コードはほんとにひどいものが多く, そのスタイルに倣ってコードを書くと自然とひどいコードになる. Java はだいぶマシだけれど, それでも玉石まじっている. (すくなくともデザインパターンが支配する前の Java にはユニークなコードが多かった.)

翻って Ruby をみると Rails がある. Rails はデザインパターン愛好家が全力で Ruby を使ったようなフレームワークだ(った). Ruby と Rails で職業プログラマをはじめた人にとってデザインパターンは空気のようなものだろう. ActiveRecord は PoEAA の Active Record パターン である 以前に Rails の ORM 実装だし, M や V や C にも同じことがいえる.

以前, 仕事で Python の SQLAlchemy という ORM を使ったことがある. これは ActiveRecord とは違う方向で PoEAA にかぶれたコードベースだった. でも同僚はそれを気にしていなかったろうし, 実際気にする必要もなかった. 私も聞き覚えのあるクラス名が目にとまり PoEAA をみなおし思わず吹き出しそうになっただけで, パターンの知識が自分の SQLAlchemy 向けコードを変えたとはまったく思わない.

モダンな言語とモダンなコードベースの上で仕事をするプログラマにとって, デザインパターンはどれくらい重要だろうか. たぶん ActiveRecord (など)のリファレンスやコードを読むほうが手っ取り早く効くに違いない. ディティールがあるし, なによりすぐに使えるから.

Rails 育ちのプログラマが読む GoF や PoEAA に, 残念な内製フレームワーク育ちの C++/Java プログラマがかつて感じたような感動はないだろう. 既視感があふれすぎている. 知識をまとめて整理する役にはたつだろうし, 教養としてとりくむ意義はあると思うけどね.

プロセス・リーディング

ウォーターフォールや低熟練チームのプロジェクトに対するアジャイルは, C++ に対するデザインパターンに似ている. そこにある問題に名前をつけて際立たせ, よりよい解決方法を提案している.

一方で, エラい人が "Launch and Iterate!" とか "Over-communicate!" とか言ってプレッシャーをかけてくる組織の場合, アジャイルの想定していた歴史的な課題の大半はそもそも存在しない. これは必ずしも該当組織の開発プロセスが洗練されていることを意味しないけれど, とにかく前提が違っている. 前提が変わった世界で改めてアジャイルを学ぶ価値はどれだけあるのか. たぶんそれは, Rails プログラマが PoEAA を読むのと同じようなものだと思う: 勉強してもいいけど, 急ぎの仕事ってかんじじゃない.

大学を卒業してすぐ私と同じ職場に勤めている若者諸兄の中には, その仕事の仕方が勤務先で編み出されたユニークなものだと思っている人もたぶんいる. その半分くらいは単にアジャイルなだけだと知識があればわかる. ただそうわかったところで仕事がはかどるわけでもない. SQLAlchemy が PoEAA 信者の仕事だとわかっても面白いだけなのに似ている.

個々のチームのありかたはコードほど使いまわしが効くものではないから, 新しくチームを作ってプロジェクトをはじめるような場面では知識が役にたつだろう. それでも近隣のうまくいっているチームを真似する方がやはり即効性は高いに違いない.

私の今の関心は, 一般化されたプラクティスのアイデアではなく自分のいるプロジェクトという具体的な実装に向いている気がする: こいつにはどういう弱点がって(例: コードサイズ, 時差), それはどうやってワークアラウンドできるのか? (例: 朝はとにかくレビューの返事に集中する.) どういうコードがレビューを突破しやすいのか (例: まずでかいパッチで大意を説明してから小さいパッチにわけろ.) 大きな変更をするのに安全なタイミングはいつか? (例: そんなものはない.) どうやって分散した意思決定の主体と話し合って物事を前に進めるのか? (例: あのモジュールつくってるチームってどこにいるの? どのメーリングリストに訊けばいい? ここでゴネるか引き下がろうか?)

こういうディティールはしょうもないものも多くうんざりすることさえあるが, 仕事を進めるには欠かせない. それに, 根からイテレイティブなプロジェクトが大きくなっていくありさまを目の当たりにする面白さは間違いなくある. 想像もしなかった問題がばさばさ現れるから, いつも肝をひやしてばかりだけれど.

隣の芝生

私のいるプロジェクトはデスクトップ環境向けにネイティブコードを書くといういささか前時代的な製品を開発しており 開発者も大陸をまたいで散らばっているため, イテレイティブ/アジャイルといっても C 言語でオブジェクト指向をするみたいな無理矢理感はある. Co-located なプロジェクトでマネジドコードを書くウェブの仕事だと, もっと小さく速く物事が進むだろうなと想像している.

私はたまに余暇で Facebook Engineering ウォッチ活動をしていて, その一環で見た リリースエンジニアリングに関する講演 は ウェブ開発の俊敏さをよく伝えていた. Facebook のコードは毎週ブランチを切って (time-boxed に) リリースされているらしいけれど, 講演は週単位にリリースする開発では何がおこり, 何が必要なのかの一端をのぞかせてくれる. 設定用フラグのフレームワーク, reputation 評価を備えたチェリーピックツール, Torrent を使ったデプロイ... 具体的な実装への興味は尽きない. (他所の会社のビデオをみる暇があったら自分の勤務先の他のプロジェクトをよく調べろという気もする.)

Facebook に限らず, ウェブの仕事はアジャイル/イテレイティブ開発がデフォルトになっていくだろうし, 既になっている組織も多いと思う. その常識が根付いたところに何があらわれるのか. 人々はどのような問題に頭を悩ませ, どんな選択肢が生まれるのか.

というようなことに気をひかれつつ, しかし目先の問題はビルドが遅いこととクラッシュの原因がわからないことで, 軽量言語で仕事したい...と弱音をはいたりすることもなきにしもあらずながらイテレイティブとかいってる今日このごろでございます.