(cache) IT産業には民族誌が必要だ - 未来のいつか/hyoshiokの日記

2011-11-08

IT産業には民族誌が必要だ

先日から Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automationの読書会をしているというのは、日記にも書いた。*1

本日は第3章Continuous Integration（継続的インテグレーション）だ。早瀬さんが2号館のカフェテリアでやろうというので、近所のコンビニでビールとつまみを買いこんで参加した。（うひひ）

コンビニ袋にビールとポップコーンを突っ込んでカフェテリアに登場したところ、目ざとくビールを発見され、「おっビール」と言われるのだが、「えっビールじゃないんですか」と返す。早瀬さんもわたしのビールにつられてドリンクとつまみをコンビニに買出しに行った。

そんなこんなで、飲みながら第3章は始まったのであるが、その前にわたしのヨタ話を披露した。

Continuous Integrationという言葉はあのKent BeckのExtreme Programming Explainedと言う1999年に出版された本に最初に書かれたと、本書には書いてある。

シリコンバレーにいたころ、デイリービルドとかナイトリービルドとか呼ばれているプロセスは日常だったので、CIの言葉の起源が1999年のKent BeckのXPの教科書というのはちょっと意外な気がした。

本題に入る前の与太話として、シリコンバレー日記 (未来のいつか README http://web.archive.org/web/19981206133243/http://www.best.com/~yoshioka/d/98/ )を見せながら、「デイリービルド(http://web.archive.org/web/19990423132826/http://www.best.com/~yoshioka/d/98/i980218.html)」とか、「ソースコード管理システム(http://web.archive.org/web/19990423140752/http://www.best.com/~yoshioka/d/98/i980221.html)」とか、はたまた「夜中のビルド(http://web.archive.org/web/19990423182344/http://www.best.com/~yoshioka/d/98/i980405.html)」の話をする。「ビルド」(http://web.archive.org/web/19981205210826/http://www.best.com/~yoshioka/d/96/01/p960119.html)。

大規模ソフトウェア開発の現場では普通に行われていることで公然の秘密なんだけど、日本では当時ほとんど知られていなかったので、シリコンバレー日記として日々記すことはあながち無駄なことではないように思っていた。

もちろん、日本にもメインフレーマはあったので、同様な開発現場はあったと思うのだが、そのような現場の肉声は厚い組織の壁の内側にあったので、うかがい知りようがなかった。

デイリービルドやリグレッションテストについて、闘うプログラマーに記されていたので、まったく知られていなかったというわけではないが、現場感を持って語られることはほとんどなかった。

一方で、米国のソフトウェア開発の現場に働くエンジニアの流動性は高いので、Microsoftの出身者がOracleに転職して、そのビルドプロセスについてMSのベストプラクティスやdisciplineを転職先のOracleに輸入するということは日常的に行われていた。業界のpracticeやdisciplineが教科書という形式知になって流通するはるか以前に経験値として、人とともに緩やかに流通するというシステムがそこにあった。

RDBMSのアーキテクチャも、Sybase/Informix/Teradata/IBMなどなどの開発者が転職を繰り返すことによって、徐々に共通の理解が共有されていった。

そのようなものは論文になったり教科書になったりするよりも遥か前に暗黙知として人依存の形式で人とともに流通していた。

わたし自身も1984年に日本ディジタルイクイップメント研究開発センターという米国Digital Equipment Corporation (米DEC)の日本子会社に就職して、見よう見まねでmakefileのようなものを書き、夜中にビルドをするスクリプトをバッチで流して、テスト管理システム(DTM - DEC Test Manager)によって、ビルドしたイメージを自動テストするようなことは、普通に行っていた。

バージョンコントロールシステムはCMS (Code Management System)、モジュール管理システムはMMS (Module Management System)と呼ばれていた。DECのツールは大文字で3文字というのが暗黙のルールだった。

80年代に既に、夜中のビルドやリグレッションテストが普通にあったのだから、おそらくメインフレームの世界では70年代あるいはそれよりもっと昔から行われていたのだと思う。

富士通や日立あるいはNECのかつてのエンジニアたちのノウハウもどこかには絶対あったと思う。人材流動性がないが故に、あるいは彼らが管理職となるとともに、そのノウハウはどこかに死蔵され社会全体として活用される機会は永遠に失われた。

20数年前の新入社員が今年の新入社員と同じ本を今読んでいる。今年の新入社員にとってはCIという概念は非常に新しいリーディングエッジなテクノロジーだ。その今年の新入社員に対し20数年前の新入社員が20数年前の話をすることは老害かと言われるとそうかもしれないけれど、歴史を知ることは必ずしも無駄なことだとは思わない。

当時のVAX-11/730というマシンはVAX-11/780というマシン(1MIPS-1秒間に100万命令を実行)の1/3の処理性能しかなかったので、コンパイルの時間が非常にかかった。そのために、夜中にビルドするという方法を考えついて、テストも自動化した。うんぬんかんぬん。（VAXのコンパイラは1MIPSのマシンで1分間に約1000行コンパイルするので、数万行のプログラムのコンパイルには約1時間かかるとか)

変更はアトミックであるべきで、なんでもかんでも一つの変更に詰め込むことは良くないということを学んだとか、うんぬんかんぬん。

このようなことは、教科書にはあまり書いていないし、仮に書かれたとしても書かれるまでに何年もかかるので、それをビールを飲みながらあーだこーだ話すということは、若い人にとっては何かの参考になると思う。(例えば1分間に何行のプログラムをコンパイルできるかとかは簡単なベンチマークになるが学校では教えてくれない。大規模ソフトウェア開発の現場ではそーゆーどーでもいい知識というか相場観が役に立つ)

そして、そのようなベストプラクティスは人とともに伝わっていく。誰かが陽に伝えようとしない限り伝わらない。

楽天を卒業してGREEやDeNAやあるいは別の企業に転職するエンジニアがいたとして、彼らも、楽天で学んだ様々なことを暗黙知として、新しい会社に持っていく。もちろん、そこでは、楽天で学んだアンチパターン（失敗のパターン）は持っていかないから、どんどん、よいプラクティスが転職することによって流通していくというエコシステムが発生する。

後発の企業が有利なのは、その点である。

ソフトウェア開発の現場というのは伏魔殿で、外からは何が起こっているかさっぱりわからない。その中に入ってみない限り、わからない。IT 産業にいるものであっても、やはり、Googleで何が行われているか、Appleで、Facedbook、TwitterあるいはLinkedInで何が行われているかは、そこに勤めたことがなければよくわからないのである。