ある朝会社にいくと git.webkit.org がダウンしている。仕事にならない・・・。 意気消沈したが くだを巻く口実ができたとウェブをひやかしていた 少し距離をおいて日々の業務を見直すいい機会だと調べものをしていたところ ソーシャルコーディングの講演で使われたスライド が紹介されておりふんふんと眺めた。

ソーシャルコーディングというのは　GitHub なんかで fork と pull request みたいな対話を通じ 友達百人できるかんじですすめる民主的で人類賛歌なソフトウェア開発のことを指す(と私はおおまかに理解した)。 たしかに GitHub で送った pull request が “Nice! Thanks!!” とかいって受け入れられるとうれしいよね。 プログラマやっててよかった気分になる。

私が仕事でやっているのはコミッタレビュアそれ以外の身分差別と中央集権型 SCM, キメてもセキュリティホールができるだけのプログラミング言語からなるプロジェクトで、 ソーシャルコーディング講演の文脈ではルネサンス以前、 いわば暗黒時代の荒野みたいなソフトウェア開発にあたる。

そんな殺伐プロジェクトだけれど、一方でけっこうソーシャルぽさを感じるところもある。 ただここでいうソーシャルはソーシャルは人間賛歌というよりウェブ用語のソーシャルで、要するにグラフがあったりするあれ。 暗黒時代の西洋人もたぶん人付き合いはしてたろうから殺伐としたプロジェクトにソーシャルグラフがあっても不思議ではない。 そして私がかんじるソーシャルぽさの原泉にはプロジェクトの Bugzilla がある。 ソーシャルぽさ…もうちょっと具体的には Twitter ぽさが、 20 世紀の BTS である Bugzilla からなぜか流れ出している。妙な話ではある。

Bugzilla Stream

多くの BTS 同様、 Bugzilla にはメール通知が備わっている。 自分に関係するバグに変更がおこるとメールが飛んでくる。 このメールを Gmail で jjjkjjj と消化する気分がなんとなく Twitter ぽい。 大半のどうでもいい通知のなかに、ぽつりと興味ぶかいものが混じっている。

モダンな BTS が大抵そうであるように、 Bugzilla は単なる BTS ではなくタスク管理ツールでありコードレビューツールでありパッチマネジメントツールでもある。 原則として全てのチェックインには対応するバグがあり、そのバグにはコードレビューの記録が残っている。 古いソフトウェアなので UX は最悪なものの、依存関係をもつバグやタスク、パッチをはじめとする各種添付ファイル、コードレビューまでが統合された Bugzilla のデータモデルはなかなか本格的だと思う。

そんなツールの性質上、各開発者の動向は多くの部分が Bugzilla 上にあらわれる。 作業をはじめるならバグ(チケット)をつくるし、大きな作業ならそれに加え依存関係の中心に「メタバグ」を登録する。 (“meta” と検索すれば具体例がみつかる。) パッチを書いたらアップロードする。アップロードしたパッチがレビューされコメントがつく。 そのフィードバックを反映してアップロードしなおす。同意、賞賛、罵り合い。 パッチが合意に至るとどこからともなく bot がやってきてパッチをツリーにコミットする。 コミットしたパッチがツリーを壊すとパッチは revert され、テストやビルドの失敗がコメントに記録される。

この一連の出来事が逐一メール通知で届く。

Follow

Bugzilla には誰かのアカウントを watch する機能がある。誰かを watch リストに登録すると、 その人の Bugzilla での行動が逐一通知されるようになる。これは Twitter の follow にちょっと似ている。 私はチームの同僚のほか、作業範囲が被るよその会社の人数名を watch している。 一時期は有名人を watch していたけれど流量が多すぎて挫けた。このへんも Twitter ぽいかもしれない。

Watch した結果、たとえば follow 相手が投稿したパッチをすかさずレビューしたりできる。 まわりの人の仕事の様子がなんとなくわかる効果もある。 たとえばチームのミーティングでは細かい実装の順番なんて話をしなくても、 登録されるバグから予定が透けて見える。

野次馬としては follower 数のランキングやグラフ構造に興味がある。 残念ながら Bugzilla はその情報を公開していない。

Favorite / RT

それぞれのバグには報告者や担当者のほかに CC リスト がある。 コメントやパッチなどバグに動きがあると CC リストの面々に通知がいく。 CC リストは誰でも変更できる。だからあるバグの進展を見届けたいなら CC リストに自分を入れておけばいい。

CC リストにはバグへの関心を示す意味があり、その意味で favorite に似ている。 CC リストに入った事実は follower にも知らされるから同時に RT 的といえなくもない。 ホットなバグの CC リストは 10 人 20 人と膨らんでいく。

Google Code など最近の BTS によっては star をつける favorite 機能そのものを備えているけれど、 暗黒の荒野にそんな優しさはない。 CC リストに並ぶのも善意や好意だけとは限らず、やんちゃな変更に睨みを聞かせる用心棒の視線かもしれない。

Mention

CC リストには自分のアカウントだけでなく、他の誰かを登録してもいい。 パッチのレビューをたのむときは、レビュアの候補を CC リストに登録した上で、「すまんがレビューたのむ」とコメントを書く。 意見を求めるとき、持ち主の決まらないバグの担当を探すときなど、レビュー相手以外も CC リストに追加される。 誰かをよびだすこのかんじは mention に似ている。

多くのコードレビューシステム同様、 Bugzilla にも明示的にパッチのレビュアを指名する機能がある。 けれど件のプロジェクトでは意図的にその機能を外している。これは指名された人間以外にレビューの機会を与える利点がある。 一方で面倒そうなパッチは誰もレビューしたがらず放置される欠点もある。 ただ組織をまたいだ誰かにレビューを課すのはどのみち現実的ではないから、この判断は妥当な気もしている。

Hashtag

Hashtag… に直接該当するような機能は Bugzilla にない。さすがにね・・・。

特定の話題に関する発言をまとめるという意味では、 metabug (master bug) は遠からずなかんじ。 関連のあるバグ/タスクを統括する metabug を個々の具体的なバグに依存させておけば、 その metabug の CC リストに入るだけで依存先バグの変更が通知される。これを hashtag 的に使うことはある。 実際には一部の状態変更しか通知されないのだけれど、あまり困ることはない。

Bot

Twitter 上には多くの bot アカウントがある。 Bugzilla にも多数の bot が生息している。 日頃お世話になっているのはアップロードしたパッチのビルドが通るかをチェックしてくれる親切 bot と レビューの済んだパッチをコミットしてくれる commit bot。 そのほかパッチの中身から妥当なレビュアを割り出して CC リストに追加するおせっかい bot などがいる。

普段は IRC にいる bot がたまに Bugzilla にやってきて伝言を残すこともある。 「このパッチはビルドを壊したので revert したよっ」などと言い残していく。

Discover

さいきん Twitter の UI に追加されたはやりの話題がわかるやつ。も、 やはり Bugzilla にはない・・・

もっとも Twitter と違い、プロジェクトの Bugzilla に何億人ものユーザはいない。 だからプロジェクトの コミットログ を読めば、 ハイテクデータマイニングがなくても割となんとかなる。 コードレビューとの兼ね合いから、プロジェクトにはコミットログを詳しく書く習慣がある。 おかげでひと通り目を通すと熱心に開発されている箇所がわかる。

専用クライアント(がほしい)

このように Bugzilla は荒野でおきた身辺事情をくまなく伝える暗黒時代のソーシャルメディアとして機能しているのだけれど、 あいにく UX がぱっとしない。 この通知は誰かが私を mention したのだろうか、それとも follow している誰かの動向か。 一日数百通届く通知からはそうした文脈がわからず、ひたすら未読メールとして降り積もっていく。 当初はフィルタやラベルづけをがんばろうとしたけれど音を上げた。 各人の Dashboard, BugzilDeck があればどれだけ救われるか。 ソーシャルコーディング本家の GitHub が羨ましい。ダッシュボードもあるし、コメントではアットマークつきの mention だってできる。

最近は通知メールを処理しきれず無視することが増えた。 かわりに隣の同僚などから物理的にレビューをつつかれている。ごめんなさい・・これが Bugzilla 疲れってやつか・・・。

GitHub ほどの個人志向でなくても、 BTS はもっとソーシャル風味を強めることでよくなるだろう。 Teambox などグループウェアの中にはチームプレイの対話的側面を強調したものが増えてきた。 ソフトウェア開発向けツールもはやくそうなってほしいとおもう。

その他のメディアたち

プロジェクトでは Bugzilla 以外にもいくつかのメディアが対話を担っている。 真っ先に思い浮かぶのは メーリングリスト。 ただメーリングリストに流れる話は重要ではあるものの、議論として面白い投稿はそれほど多くない。 リストへの投稿はプロジェクト全体に向けられたメッセージだから、誰かと対話しようという意思が薄いのだろう。 それに参加者が多いほど立ち入ったことは話しにくくなる。野次馬にとって白いのは圧倒的に Bugzilla だと私は思っている。

もうひとつの対話チャネルは IRC. IRC は逆にとてもソーシャル・・・というかくだをまいてる感じがして、 有益さはともかく私はけっこう好き。挨拶や雑談がとびかうのは IRC だけだ。 常連が Bugzilla の URL を交換しレビューをせがみあっている様子もみられる。 ちょっとずるい・・・実際、 Bugzilla 上ではなかなか反応のないレビュアをつかまえる裏口として IRC を使うことはある。 東京からだと時差でしんどいのが欠点。

気楽さが過ぎてお互いのパッチにケチをつけあっているうち険悪なムードになる場面もあるが、 そういうのがすぐ流れて消えてしまうのも IRC のいいところ。 ウェブブラウザの開発者が HTTP 以外のプロトコルに依存している事実だけは若干後ろめたい気もしている。

最後の対話パスは オフラインの meetup. こういうところで普段話せない人と話すのは楽しいし、 オンラインだと険悪になりがちな話題に決着をつけるなら顔を合わせて議論するほかない。 そういえば GitHub の東京 Drinkup は行きたかったなあ. Rails も Node.js もわかんないのでハブられそうだけど…

荒野の人情

Bugzilla 通知の消化、メーリングリスト購読、 git log 閲覧, IRC での世間話… こう並べてみると、私は結構な時間をプロジェクトのソーシャルメディアに費やしている。

Twitter をやらなくても日々を暮らしていけるように、 プロジェクトのソーシャルメディアと距離をおいて仕事をすることはできる。 会社員生命に関わる情報は向うからやってくる。 くだをまいてるヒマがあったらコードをかいた方が、たぶんだいぶ仕事ははかどる。

私は目の前に読むものがあるとついひやかしてしまう。あげくの果てにそれで疲れてしまう。だいぶ中毒っぽい。 ただこの中毒的メディアにも少しはいいことがある。

まず、メディアの中に身を投げれば流れがわかる。いま泳ぎやすい場所がわかる。

たとえば Bugzilla をぶらぶらしていると、 いつか直したいと思いつつ放置していたダメなコードに誰かが手をつける場面にでくわすかもしれない。 これはチャンスだ。一人だと手に負えない仕事でも二人ならさっと片付くことがある。 プロジェクト固有の事情もある： お互いレビュアだと相互レビューができてるから仕事の進みがいい。

後回しにして積んでおいた未実装の機能に誰かがパッチをよこすこともある。 そんなときはささっとレビューしてしまおう。仕上がったパッチがチェックインされれば私の仕事は少し進む。 書き手の成果は少し増える。おたがいうれしい。通知を無視していたらしばらくは見逃していたことだろう。

流れに身を任せるだけでなくちいさく声をあげると、流れ自体がかわることもある。

たとえば私はときどき冷やかしで、仕事とは関係ないパッチもレビューしている。 するとたぶん相手から反応のあるレビュアだとみなされるのか、次のパッチでもふたび CC されたりする。 勤務先が同じとおぼしき別の開発者からも CC されはじめる。何かが伝播している。 同業者の性格やレビューへの反応はプロジェクト参加者にとっていい話の肴だろうから、 なにがおきたかは想像がつく。私もよくその手のゴシップで同僚と盛り上がっているし。

色々な事情で本業にヒマができると、適当にみつけた面白そうなバグをなおす。 仕事や寄り道の途中でみつけた見るに耐えないコードを手直しすることもある。 こういう雑用では勤務先以外の人からもよくレビューをうけるため、段々とある種の顔見知りになる。

顔見知りになると、大きな変更の初手のような一見自明でない変更も相手にしてもらえることが増える。 たぶん同じパッチを通りがかりの身で書いても放置されるとおもう。 信頼を得た、グラフの次数が増えた、そう感じる瞬間がやってくる。

もうすぐ今のプロジェクトで働き始めて二年になる。 今は最初のころよりもだいぶ自由に身動きできる。今のほうがずっと楽しい。 それはコードベースへの理解が深まったのと同時に、人々の中に自分の根が広がったからでもある。 バグとパッチで切り結ぶ荒くれものばかりとおもってた荒野の根城に居場所がみつかる。 ソーシャルコーディングというよりワイルドコーディングってかんじだけど、それも悪くない。

写真: http://www.flickr.com/photos/jay_que/2809782040/

同じような主張は、ビジネスとしてのオープンソースが隆盛を極めた 2000 年前後にもみられた。 時は流れ、今はソフトウェアそのものよりはアプリケーションやサービスをウェブ越しに売る時代。 ハイテク企業の前線もコード自身からデータやユーザの時間といったコード以外の部分に少しづつ軸足を移しつつある。 そうした企業は十年前とは異なる文脈でコードをオープンソースにしはじめた… というだいたいの背景を踏まえつつ読むと、もじょ先生の話は感慨深い。

もじょ先生はスタートアップの founder/CTO らしい立場でオープンソースの利点を説いている。 私はスタートアップ勤務でもなければ経営者でもないけれど、なりゆきからオープンソースなコードで仕事をしている。 そこで私個人がオープンソースな仕事のコードをどう感じているか、どんな風に嬉しいのか、 ヒラ従業員からみたオープンソースの話を書いてみたい。

一応事前にあやまっておく(?)と、基本的に仕事のコードがオープンソースなのはいいですよウヘヘ という自慢話なのでそういうのが嫌いなひとは適当にスキップしてくださいね。

職探し

もじょ先生は、仕事コードをオープンソースにしておくと雇用の役に立つと主張している。 該当プロジェクトにパッチを送ってくれる開発者がいたら、その人は潜在的なヘッドハント候補になる。 プロジェクトに興味を持ってくれているし、なによりパッチをみればコード書きの腕前がわかる。 ややこしいインタビューなんて必要ないという。

雇われる側にも同じことが言える。 オープンソースのプロジェクトなら、 ある職場で働くと決める前にコードをみることができる。 これはその職場で働くかどうかの決断を後押ししてくれる。

職場を移るとき、行き先のコード品質はいつも大きな不安のもとだ。 もし仕事でさわるコードがひどいものだったら… 月曜の朝、またうんざりなコードをいじる日々がはじまるのかと絶望する自分を思い浮かべて足がすくむ。 デスマ、薄給、トンガリ頭とおなじくらいこわい。あるいはもっと。

私は今の勤め先が公開するコードをいくつか眺めていたし、 いまのプロジェクトのコードも覗いていた。 だから仕事を始めるにあたりひどいコードへの不安はなかった。 それほどすばらしくない部分があることもわかっていたから、叶わぬ過剰な期待もなかった。

良いソースコードは良いエンジニアリング、よいプログラマの証左でもある。 コード自体は良いのに周りのインフラやプロセス、 コードを書いたプログラマがダメなことは少ない。 コードのスナップショットだけでなく、 レポジトリの履歴やバグトラック, CI のダッシュボードなども公開されているなら 仕事の様子をもっと詳しく見ることができる。実際にパッチを送ってみることだってできる。 一日のコミット量やパッチの粒度、ブランチの使い方、インフラの自動化具合、 バグやパッチをめぐる議論の口調、ツリーの greenness。 自分が迎えるであろう一日を思い浮かべる材料は事欠かない。 自社のエンジニアリングに熱弁を振るう blog 記事や豪華ランチつきオフィス・ツアーもいいけれど、 個人的にはコードやバグトラック、メーリングリストのように仕事の様子が見える方が信用できる。

実際、まともなコードとクリアなワークフローの上で仕事をするのは気分がいい。 自分が正しいことをしていると思える。遠くまで視界がひらけていている。 でも私がこう書いたのを読むよりは、該当プロジェクトに パッチを書いてチェックインするまでを見届ける方がわかることは多い。 会社説明会よりインターンの方がいろいろわかるのと同じ。 良し悪しだけじゃなくて好みもあるしね。

パッチを書くなら、 3-4 個は試してみたほうがいい、 プロジェクトの規模が大きいと、最初はしきたりを理解するだけでくたびれてしまう。 そういえばプロジェクトの規模がわかるのもいいところ。

自分のものなかんじ

愛着のある仕事のコードはどんなものだろう。 これまでに書いたコードを振り返ると、自分が多くの部分を書いたものには愛着を感じた。 半分・・・は無理でも、ある規模のコードで 2-3 割を占めれば愛着がうまれる。 そんなコードを書いた職場やプロジェクトを移るときは、 もうすこし良くしてあげたかったと心残りがある。

この愛着は所有感の表れだと思う。 自分の書いたコードは自分のもの。自分自身の断片、自分のものである以上はよくしてあげたい。

もちろん厳密にいえばこの所有感はまやかしだ。 仕事で書いたコードは勤務先のものだったり、 受託開発だったら多くは発注者のものだろう。

相対的にみると、有期のプロジェクトが終わると納品されてさよならになる 受託開発のコードは愛着を感じにくい。別れがくるとわかっているから。 勤務先のために書くコードはもう少し愛着をもちやすいけれど、 終身雇用なヒトでもない限りいつかは別れがやってくる。 実際は職場を変えなくても自分がプロジェクトを離れたり。 プロジェク自体がキャンセルになればコードはいなくなる。 そうわかっていても愛着を感じてしまうのは、 投じた労力への後ろ髪、そしてコードの大半を書いた人間がもつ実質的な影響力のためだろう。 たくさんコードを書いたら、そのコードの行方に少しは口を挟める。

オープンソースのプロジェクトは愛着を持ちやすい。 コードが誰かの独占的な持ち物ではないからだと思う。 自分の意に反してどこかに消え去ってしまう心配が少ないから心を許せる。 明文化されていない「実質的な」影響力に頼らなくてすむ。

私が仕事でおじゃましているプロジェクトの中で私が書いたコードは 1% 未満だけれど、 それなりにプロジェクトへの愛着はある。 特に自分が手を入れたモジュールは良くしてあげたいと思える。

Your mind can be on it.

コードやプロジェクトへの愛着は仕事を離れても続く。 たとえば WebKit の IRC channel には、勤務時間に限らず常駐しているメンバーが多い。 真夜中に “good night” と退室していく人をよく目にする。 こうした常連にとって、 WebKit は生活の一部になっている。

私は IRC が好きではないので勤務中以外は常駐していないけれど、 それでも仕事のことはよく考えているし、プロジェクトの比較的立ち入った話を ウェブに書いたりワークショップで話したりするのは割と好きだ。 だから仕事の話をおおっぴらに書ける今の perk は私にとってだいぶ嬉しい。 コードをみながら具体的な実装の話を書けるのはいい。

Chromium 用の高速ビルドツールである Ninja はなぜか github にホストされており、 プロジェクトが余暇にうまれたことを示している。これも愛着の表れとみていい。

オープンソースな仕事でなくても、仕事のためのツールやライブラリを余暇に書いて公開しておき、 それを仕事に持ち込んで使うことはある。特に Web で仕事をする人にはそんなところがある。

仕事のプロジェクトがオープンソースになっていると、こうした仕事関係余暇ハックの敷居はさがる。 余暇のコードが本業のコードに依存しても構わないため、依存関係の制限が少なくなるからだ。 本業のコードから独立した部分をうまく抜き出し、仕事以外で使えるツールに仕立てることもできるだろう。

Twitter の Jeremy Cole は、 ある講演 の中で オープンソース仕事の良さをこんな風に説明している:

One of the main things that open-source gives us is the ability to take the work with you wherever you go, and not have to worry about being changed what you are working on, or feeling like you are just doing a day job.

You can feel like you are building something that you can keep and that lasts really long time. You are sure the company couldn’t just kill the project because the code is out there, and if they did, you could keep working on if you really liked it.

See. You can free to think about how you are building it, how new architecture it should have, and all that.

While you take a shower, while you are driving around or whatever you are doing, your mind can be on it.

And that is one of the awesome things in open-source.

愛着のある仕事コードがオープンソースであることの良さを端的に説明していると思う。 かつて MySQL に勤めていた Jeremy Cole は退職後も MySQL にパッチを書いていたというからなかなか説得力がある。 Twitter 自身にも、もじょ先生のいう積極的なオープンソース化を地でいく所があるよね。

ほしいと言ってみる

余暇ですごいコードを書きオープンソース化してプロジェクトを育て、 その実績を勤務先に認めさせて仕事に持ち込む。 そんな方法が、お仕事オープンソースの実現パターンとして知られるようになった。 スーパープログラマの努力が認められるのは素晴らしいと思うし、 これをやってのけた人々はすごいと思う。

私は自分のコードをオープンソース化するのに何も努力していない。（※仕事はがんばってます。） 昼間書いたコードが勝手に表に出ていく。 プロジェクト開始時のメンバーたちは今の状態をつくるのに何らかの労を割いたことだろう。

先に書いたとおり、仕事コードがオープンソースなのはいろいろと良いことがある。 だからできればガッツあふれるスーパープログラマ以外も オープンソースなコードの上で仕事ができた方が楽しいと思う。 根性と才能があればオープンソースを仕事に出来るというのは、 仕事と子育てを両立し出世街道を邁進するハイパーキャリア女子を 雇用機会均等の証にするみたいでやや居心地が悪い。 たぶん私には余暇で書いたコードを仕事に持ち込む実力も根性もない。

これは私個人の印象なのだけれど、 「仕事のコードがオープンソースだと嬉しい」という主張は プログラマにもプログラマ以外にもあまり認知されてない気がする。 コードの読み書きに興味がないとぴんとこない話だろうし、文句は言えない。

けれど認知が広まれば、たとえば茨の努力ルートに入る前に まず今書いてるコードをオープンソースにしたいと言ってみれば、 案外するっと話が進んだりしないだろうか。楽観的すぎるかもしれないけれど、 福利厚生としてオープンソースが喜ばれると経営者や管理職が認識すれば 願いが聞き届けられる可能性は上がると思う。

世にある景気のいいソフトウェア会社の中には、 プログラマ獲得のためにけっこうな予算を割いているところがある。 入社時にいくらか余計に現金を払ったり、高級な椅子、広い画面、おいしい食事を用意したりする。 これはどれも素晴らしいものだと思うけれど、たぶん結構高くついている。 プログラマばかり優遇するせいでプログラマ以外の同僚ににらまれたりしないか心配でもある。

コードをオープンソースにするのは、ふつうそれほど高くつかない。GitHub のホスト代くらいでいい。 プログラマ以外の人にとってコードはどうでもいいだろうから、オープンソース化で角が立つこともなかろう。 少なくともプログラマを絶賛募集中の会社にとって、 オープンソース化はプログラマを相手にした割のいいアピールになりうる。 実際、企業アカウントで細々としたコードを公開する小さな会社は東京でも見かけるようになった。

まだそうなっていないプログラマは、 試しに仕事のコードがオープンなのは自分にとって嬉しいとアピールしたり、 仕事で使える Github アカウントがほしいとねだってみればいいと思う。 そして仕事コードのうち表に出しても角が立たなそうな部分　(もじょ先生によれば “almost everything”) を少しずつ仕事用 Github に移して開発を進め、 区切りのいいところで交渉してレポジトリを private から public に flip する。 そのくらい融通の効く会社がたくさんあると、プログラマの仕事はもっと楽しくなることだろう。

ある日、よその会社で働く友達のコミットにバグをみつけた。昼休みにちょこっと直して pull request:

commit 80e62a7654637d9ed930a2818c28b20cc794fcc8 (HEAD, master)
Author: Hajime Morrita <omo@dodgson.org>
Date:   Sun Nov 27 16:30:29 2011 +0900

    エスケープ漏れを修正。グラコロ一個でどうか。

そんな日がくればいい。

tDiary に特に不満はないんだけど、 書いたものを git で管理しつつ手元から rsync で push できる Octopress も なかなかいい子だとおもう。ただはやりものなので廃れたらまた tDiary に帰るかも・・・。

• このページ (かわらず): http://steps.dodgson.org/
• フィード URL: http://steps.dodgson.org/atom.xml
• タイトル写真: http://www.flickr.com/photos/_belial/5929930548/
• git repo: https://github.com/omo/s2p/
• 過去の記事 (2008/08 - 2011/10): http://stepped.dodgson.org/
• 過去の記事 (2003/11 - 2008/08): http://dodgson.org/omo/t/