複雑さに金が落ちる時代は本当に終わるのか？

• RailsやChuraのいけてないところ

これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。

(このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい)

Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。

だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソースなんだから、そういう問題点はたくさんの人が使っていくうちに自然とフィードバックによって直っていく。

id:habuakihiroさんは、Railsというソフト自体ではなく、それが想定している開発の手順に致命的な欠陥があると主張されているのだと思う。その欠陥とは、データベースの設計という工程が含まれていないことだ。

Railsによるソフト開発のライフサイクルは、まずデータベースのテーブルを定義することから始まる。テーブルとは、業務のデータを抽象化したもので、ソフト開発が始まった時点で誰にも自明に見えているものではない。業務分析からテーブル定義という作業では、多少なりとも形式化された作業手順が必要となるが、その手順がRailsには含まれていない。外付けである。外付けであるから好きなものを持ってきて組合せればよいかと言うと、普通の開発ツールならそれでよいのだけど、Railsの場合は、外付けの手順とRailsが想定している手順の間にギャップが発生してしまう。

「使う」ツールであれば単体の機能をツールが提供して、足りないものは外付けで、開発者がそれらを組合せて開発プロセスを組み立てていく。Railsのように「乗る」ツールは、暗黙に提供された開発プロセスに開発者が乗って行く、身をゆだねる必要があるので、そこに不足があることは致命的で、たった一つの不足によってツールの良さが大きく損なわれる。

ただし、「開発プロセスが前提とされている」と言っても、それは、幅の狭い一本道ではなく、アジャイルでいかようにも拡張できる柔軟なプロセスである。窮屈なプロセスではないので、不足があるにしても他のものならなんとかなるかもしれない。だが、欠けているものが「データベース設計」であるということはかなり致命的だ。

データベースのモデリングは業務分析と深く関わりあっていて、アルゴリズムのような純粋にコンピュータ技術的なものではなく、「業務」をいかに抽象化するかという話だ。これをきちんとやれば、スッキリとした見通しがよいソフトウエアができて、ここで手を抜くと、使い勝手が悪いシステムができる。特に、最初はうまく動いたとしても、業務の中で継続的に使っていくうちにボロが出て来る。

たとえて言えば、モデリングは業務ソフトの骨であって、骨の設計によって手や足の動く方向が決定してしまう。手足が曲がる方向と曲がらない方向が正しければ柔軟で使いやすいソフトウエアができる。モデリングが間違っていたら、業務がソフトの関節を逆方向にねじり上げるようなことになるのでので、ソフトが骨折してギブアップするか、「俺の手はこっちには曲がるけど、そういうふうには曲がらないんじゃ」とソフトが逆切れして業務を放り投げてしまい、システムが破綻する。

だから、業務分析とモデリングは直感でなくきちんと手順に添ってやるべき。DB設計重要。

しかしRailsは、「データベース設計は直感でやれ」と言っているに等しい。ブログとかブクマのようなものであれば直感でパッパッとできるかもしれないが、普通の業務はそうはいかない。

これはどういうことなのか？Railsは普通の業務には使えないのだろうか。

そうです。実はそうなんです。

Railsは普通の業務には使えないんです。

誰がそう言ったのか？

他ならぬDHHのボスが、そう言っているのだから、間違いない。

世の中にはたくさんの問題がある。難しい問題は他社にまかせて、単純な問題を単純に解こう。

More Constraints I said I’d discuss five things you need less of, but there is one thing you need more of: Constraints. All this less is really about more constraints. That’s where you’re forced to be creative. That’s where you’re squeezed to make better use of your money, your people, your time. And out of this squeeze will come better software, more satisfying software, and simpler solutions.

直感でテーブル設計をするということは、Railsを使う上で、非常に大きな制約になる。簡単な問題では大きく生産性が向上するとしても、あるレベル以上の難しい問題は解けない。

でも、これは仕様だと思う。「制約は多い方がいい」と言うJason Friedはそういうツールを欲しがっていて、まさにボスのお望み通りのものをDHHはこしらえたのだと思う。

実際、業務ソフトは典型的な80:20の法則であって、80%は単純なものだ。80%でよければ銀行のオンラインなんて単なる足し算と引き算だ。誰がやってもすぐできる。しかし、これを90%にすると何千万円になって、99.99%にすると何十億円になる。もし、「難しい問題は他社にまかせて」なんてボスが言ってくれるならば、DB設計は直感的にちょちょいのちょいでできる。

あー、DHHはいいボスがいてよかったね。ボクにはそんなボスはいないよ。「難しい問題は他社にまかせて」なんて言われたことないよ。残り20%の為にたくさん苦労してきたし、これからも苦労するよ。Railsって面白いけど、別世界の話だ。仕事で使うことなんてないさ。地球の裏側に面白いこと言う二人組がいたというだけの話さ。楽しい夢の話をありがとう。とても楽しかった。

さて、そろそろボクは仕事に戻ろう。

と思ったら、そこにもう一人仲間が現れたんです。

The World *IS* Flatの中でフリードマンさんが、「世界のフラット化した10の力」の一つとして「インソーシング」なんてことを言っている。たとえば、UPSが東芝のパソコンの修理を請け負うという話。UPSの物流センターのハブの空港の中に、東芝の修理工場を作ってしまう。そして、故障したパソコンをハブに運び、直し、ハブから客の所に戻し、代金を受け取る。そういう一連の業務を東芝の看板でUPSの社員が行なう。

宅急便の代引とか、Amazon e託販売サービスみたいなことを、もっと大規模に総合的に行なうということのようだ。

インソーシングとは物流や在庫だけでなく、代金回収や売上分析からクレーム対応からその周辺にある業務を全部飲みこんでしまうことらしい。こういうことを地球規模で行う会社が、これからの流行りになると、" The World IS Flat "のフリードマンさんが言っている。巨大な企業が80:20の20を肩代わりするということだ。

コイツが、DHHやJason Friedの一味だとボクが思うのは、「難しい問題は他社にまかせて」系の話をしているからだ。

インソーサーに頼るならば、「業務」はずいぶん単純になるような気がする。そして、インソーサーというインフラが確立することで、特定の狭いジャンルに特化した企業が増えるから、そういう会社向けの単純な仕事が増えるのかもしれない。それが、不可避の流れだとしたら、「単純な仕事をスッキリこなす」系のツールの適用範囲は、今見える範囲より随分広がっていくだろう。

もちろん、残り20%の仕事は消えてなくなるわけじゃない。インソーサーの中には、これまで以上の巨大な複雑さが増殖していく。彼らは規模の経済によって、きめ細かく地道にそれをこなしていくだろう。id:habuakihiroさんクラスの技術者ならば、そこでいくらでも活躍の場がある。でも、そういうインフラ系の企業は、地球全体で二つか三つに集約されていくだろう。そこではとてつもない規模のシステムが開発され続け、巨大なソフト需要を生み続けるだろう。

それはそうなんだけど、そういう会社は地球全体で業種ごとに二つか三つ。

DHHとJason Friedのような人が特殊だと思っていて、ボクの方が普通だと思っていたけど、ボクの言う「普通」は地球全体で業種ごとに二つか三つに集約されていくとしたら、いったい全体、「普通」とはどっちなんだろう。単純なことを単純にこなす中小企業の単純なシステムを開発するソフトウエア技術者か、巨大なインソーサーの巨大で複雑なシステムを開発するソフトウエア技術者か。

「こういうDB設計があるとします」なんてところから始まってるプロダクトについては、技術的にいくら素晴らしくてもお客様の使い勝手に対する要件をクリアするということを含めたプロジェクト全体のスループットからみたら、所詮部分最適化でしかも下手したら全体の生産性に逆効果になりかねない代物に過ぎない、と判断します。

「逆効果」とまでは思わないけど、この主張は理解できます。何より、ここでid:habuakihiroさんが、暗黙にイメージされているであろう「業務」というものの性質について、私は共感します。

ただ、上に上げた三人の主張を自分なりに合成してしまうと、現在の「業務」に対する全体最適化は、「フラット化」された世界においては部分最適化になるということです。

「直感的DB設計 + アジャイル(テストファースト)による進化」で対応できる複雑さは、Rubyという言語の柔軟性とRailsとフレームワークの筋の良さによってかなり向上していると思います。しかし、向上しているとは言っても、私が今持っている「業務」のレベルの複雑さに対応できるものではない。ただ、そこにある「複雑さの限界」は、「インソーサー」という存在を前提とした業務の平均的複雑さにちょうどよく対応しているように、私には思えます。

「フラット化」された世界の「インソーサ」の外にあるシステムには、Railsはちょうどいいのかもしれません。もちろん疑問はたくさんあります。

経済の問題として、80:20の80に特化し20を切り落し「複雑な問題は他社にまかせて」連携する小規模な企業が、本当に経済の主流となるかどうか?

ソフトウエア開発の問題として、80:20の80に特化することが許されるとしたら、最適なソフトウエア開発プロセスはどのように変化していくか?

複雑さに金が落ちる時代は本当に終わるのか？

ということで、Ruby On Rails の提起している問題は、ソフトウエアの世界に留まらない、非常に大きな射程を持っているように思うのですが、楽々ERDレッスン (CodeZine BOOKS) を注文しつつ、自作のテンプレートライブラリをRails対応にする作業をしている私は、完全に日和ってます。