RoRのmigrationで思ったこと

最近、それなりに本格的なシステムをRailsで開発しているのだけど、ActiveRecord::Migrationに衝撃を受けた。これはすごい。

昔話

20年ほど前、ソフトウェア開発の生産性が目に見えて向上した時期がある。ここで話しているのはビジネスソフトウェアのことね。

自分が入社した87年は、こんな感じで開発する文化がまだ残っていた。おそらく最後の頃だと思うけど。

  • ロジックの設計をするSEがいる
  • それをもとにコードを「紙に手書きする」プログラマがいる。専用の用紙があったのだ。
  • その紙を元にコードを入力するコーダ→コードは80桁のカードに入力
  • プログラマはカードの束をカードリーダに突っ込む
  • バッチ処理コンパイルされて、結果がリストに出力される
  • コンパイルが通らない場合はプログラマが原因を突き止めて、修正したコード入力をコーダに依頼する
  • 以下繰り返し[*1]

要するにプログラマはコーダへの作業指示をしていたわけだ。

この構図が激変したのは、TSS端末(とそれを接続するネットワーク)の価格が下落したことにより、プログラマ一人一人にコーディング環境が提供されるようになったあたりからだ。コンパイルして記述ミスを見つける作業が、それまでの数時間単位[*2]から10分単位に縮小された。外注していたコーダーは不要になった。ものすごい生産性の向上だった。

RailsのMigration

時は流れて20年。今どき、コードや作業指示を手書きやワープロで用意して他人に頼むことなんて...あるらしいのですなこれが。データベース周りだ。

Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series (Fowler))

Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series (Fowler))

Refactoring Databasesという本には、DBA(データベース担当)とプログラミング担当との微妙な関係が書かれている。

データというのはコードと同様、「価値」を持ったものだから大事に扱わないといかん。コーディングみたいにコンパイルしてだめだったからやりなおす、などという考えではいかんのだよ。だからデータベースは専門担当にやらせるべきだ、という考えはデータベース誕生の頃からあったらしい。

北米では[*3]「プログラマはデータベースの構成にタッチすることは許されない」、というのがビジネスアプリケーション開発現場での伝統だった。日本でもこれは似たようなものでしょ? [*4]

でも、RailsのMigrationみたいなことが普通に受け入れられると、DBAの仕事というのはデータベースの初期導入とチューニングだけになる。開発者はテーブルの定義や変更の都度、DBAに依頼書を書いて作業終了を待つ、ということから解放される。

もう一つある。紹介したRefactoring Databasesにも書かれているけれど、DBAの人はテーブル構成の変更を極度に嫌うのが常らしい。なので開発者は事前に充分にテーブル構成を検討しておく必要がある。これだけで設計フェーズのかなりの工数を食うはずだ。でも、RailsのMigrationみたいなことが普通になれば、この先行設計の負荷からも解放される。

なーんてことを考えたのだけど、体制図固めることが仕事のおじさん達はRailsなんかに興味持たないのがそもそもの問題なのね...

*1:カード束を床にぶちまけると、とほほな気分になったものだ

*2:プログラマとコーダが別ビルというのも珍しくなかった。さらにプログラマのいるビルにカードリーダがあるという保証もなかった。研修時には、カードの束もって地下鉄にのってて計算機センターまでいったこともある。

*3:この本の著者はカナダ人

*4:開発体制図にデータベースチームみたいなのがあったり、名刺にOracleMaster Goldなんて太字で入れたり...