Seasar Conferenceの懇親会 でちょっと話したんだけど、TuigwaaとRailsは競合するかどうかという話題。
私は競合しないと思うよ。
Ruby on Railsとは何かと改めて言うなら、「DBをバックエンドに持ってCRUDするようなありがちな中小規模ウェブアプリケーション開発をアジャイルに進められるフレームワーク」だろう。
どうしてアジャイルに進めやすいかというと、
組み込みのテストサポート
Unitテストは勿論、Functionalテスト、Integrationテストまで。
scaffoldによって開発の極初期（着手後数分）からプロトタイプが手に入って、ここからインクリメンタルに開発可能
Convention over Configuration
ありがちなケースは簡単にできる。まれなケースでも対応できなくはない
- 「なんでもできる」を目指していないから、簡単なことは簡単にできる
これってTuigwaaの「ユーザー手動型」コンセプトとはまったく違うと思う。
Railsはあくまでも「ありがちな中小規模開発のコストを圧倒的に削減するフレームワーク」なのね。開発者が携わるのが前提にある。確かに、Railsが出てきた当初、 これだけ開発コストを下げられるなら従来は採算があわずに見送っていた非定型業務のシステム化も可能となるのではないか、っていう議論もあったかもしれない。でもそれはあくまでもrailsにとっては周辺領域であり、「やってできなくはない」であり、アウェイである。
一方、Tuigwaaにとってはそういう非定型業務のシステム化が正にその問題領域な訳で。殊、その領域においてはTuigwaaの方がRailsより優れるだろう。だって、Railsでは開発者の実装コストは下げられても、結局ユーザーと開発者のコミュニケーションコストは必要なんだもの。Tuigwaaはユーザー主導開発によって、そのコミュニケーションコストを無くすのが売りでしょ。
だから、Tuigwaaの登場によって「Railsが登場した当初、ちょっと妄想してしまった違う使いかた」は完全に食われたと言って良い。Tuigwaaが浸透するにつれて社内向けのツールに関しては、それがある程度定型な業務であっても「それTuigwaaでよくね?」って言われるようになるだろう。でも、それでも当分の間は専門知識を持った開発者が必要な規模、領域というのは残る。そういう開発対象こそが、Railsの本来の用途でしょ?
