TeedaはRailsの夢をみるか？（睡眠時間的な意味で）
ここ１年近くはTeedaでの案件を業務で扱っています。また、Ruby on RailsやDjangoといった流行のフレームワークに関しても簡単なアプリを作れるレベルには勉強してきた所です。Teedaでは業務で２アプリ、プライベートで２アプリを開発しましたが、ここらあたりで簡単に振り返ってみたいかと思います。「さくさく感のある開発」がウリであるTeedaですが、本当にさくさく開発が可能なのでしょうか？
結論から言えば、Teedaの持つポテンシャルは非常に高いと考えます。ですが、そのポテンシャルをどれだけ引き出せるかのノウハウがまったくといって蓄積されていない、と感じています。
さて、現実のTeeda案件の話ですが、受注レベルで「Teedaを使うと生産性が高い」というメリットだけが一人歩きしています（少なくとも２回中２回とも…）。おまけに経験者が誰もいないという状況で、ろくに設計などを行わない状態で納期だけが2ヶ月後、そんな有様です。
当然ながらTeedaやSeasar2の思想や流儀を2ヶ月程度では覚えて終わりですから、開発に遅れが生じます（Javaの未経験者だらけの場合も！）。例えアラートをあげても「Teedaを使うと生産性が高い」から採用したわけで短納期で出来ないのは開発側に問題があると一蹴されます。未経験者がいるという事は理由にできず「それは御社の都合」となるわけです。
TeedaとS2Daoは、基本的に規約ベースのフレームワークです。規約を知っていれば、本当にさくさく開発できます。でも、規約ベースなので、規約を知らないと、何にもできなくなっちゃう。この辺が、大規模開発には向かないところ。
小規模で、みんなで気楽に質問し合えるような環境だと、知らないときは、誰かが答えてくれるんでいいんだけどね。
SAStrutsとS2JDBCは、大規模案件にも耐えられるように最初から設計されています。
http://d.hatena.ne.jp/higayasuo/20080908/1220865720
ひがさんのブログでもこのようなエントリーがありますが、これは現場レベルでも強く感じます。規約をある程度覚えて使えるようになるまでには、早い人で１ヶ月程度はかかります。また、この習得度に関しては本人の経験とセンスが求められるので、それまでコピペでしかアプリケーションを開発していなかった人には敷居が高いでしょう。大規模開発に向かないという事もありますが、開発期間が短い場合もさくさく開発するには経験が必要です。
したがって、開発チーム全員が経験者でなくとも経験者が３中に１人くらい必要です。また、全体の人数も多すぎると全体のレベルを合わせるのが難しく、１０名程度が現実的な最大人数かと思います。少なくとも、２社以上に分割発注したら確実にグダグダになります。
でも、規約さえ覚えてしまえば、本当にさくさく開発できるのは事実です。
Teedaを使い始める前の話ですが、Ruby on Railsに触れてみました。その時は、Ruby自体の心地よさとRailsのスピード感が気持ちいと感じたものです。Railsの思想に関しては少なからず衝撃を受けた人は多いと思います。RailsはDRYとCoCを基本理念としたフルスタックのフレームワークであり、必要なコード量が極端に少なくなります。レール（ルール）に乗れば目的地までの基本的な部分は自動でやってくれるわけです。
ですが、そのレールより少し外れた事をしようとした瞬間、そこは未開の荒野であり何時間も彷徨ったのは１度や２度じゃありません。また、後から自分で書いたコードを読むときに、Rubyは書きやすいけど読みにくい、と感じたものです。
今では普通の書店でも十冊近いRails本が並ぶようになりました。Railsが今後のWebアプリケーション開発でのメインストリームになるかどうかは解りません。ですが、後発のフレームワークに大きな影響を与えている事は確実で、後からTeedaを触った時にもRailsと同系統の臭いを感じたのもです。
自分はJavaの業務アプリの開発をメインに行っていましたが、そのほとんどはイントラ向けの○×管理システムのような類です。しかし、実際に関わったTeedaの案件はイントラで使用する業務アプリケーションではなく、インターネットで公開するWebアプリケーションでした。つまり、動的な部分があるWebサイトの構築、というパターンでTeeda（Java）が選択されているわけです。恐らくですが、Railsの案件でもカチカチの業務アプリケーションよりは、一部動的なWebサイトという案件が多くなるのではないでしょうか。
では、そのような一部動的なWebサイトの構築を行うとして、適切なフレームワーク（+言語）としてはPHPが主流かとは思います。その理由は習得しやすい言語であること、HTMLをベースにしているのでデザイナが理解しやすいこと、コンパイルやサーバの設定が複雑ではないこと、などかと思います。この牙城に対しJavaやRubyが進出しはじめた流れはあるかと思います。そんな流れの中で、どのように動的Webサイトに対してさくさく感のある開発ができるか、というのは課題なのではないでしょうか？
Teedaもその流れにうまく乗れればPHPが担当していたようなWebサイトの構築で活躍できると思います。Teedaでもいけそうだと思うポイントは以下の通りです。
言語（Java）の習得
バックグラウンド行われる処理（例えば、画像変換など）に関しては、それなりにJavaを経験した人が担当すべきかと思いますが、一般的なWebアプリケーションを構築する範囲で求められる言語知識は多くありません。むしろ、静的言語＋Eclipseなどの開発環境のメリットが生きてくるので、少しでもプログラミング言語の経験があればスタート地点としては十分です。
HTMLベースの開発
TeedaではHTML（厳密にはXHTML）をベースにしたフレームワークです。したがって、ある程度の方針を定めておけばデザイナが構築したWebページを大きな変更を行わずに動的に変換することができます。しかし、Teeda上の動的ページはWarの中にソースコードとして配置しなくてはなりません。デザイナから一方的にHTMLだけが送られてきて、それを修正しながら直すというのはあんまりです。変更があればまた同じ作業が繰り返されます。
この問題はフレームワークではなく開発方式の問題です。ソースコードの管理方法を見直した上で、デザイナを考慮したプロジェクト構成を構築することが重要かと思います。
プロジェクト管理
エンジニアとしてはフレームワークや言語などの方向に視点が偏りがちですが、デザイナを考慮したプロジェクト管理も必要です。Dreamweaver CS4ではSubversionのサポートなど、デザイナとエンジニアが仲良く開発できるようにする流れは確実にあります。
Tracを使い早い段階からデザイナとエンジニアが情報を共有する、共通のSubversionリポジトリを作成する、Maven2を使いコマンド１つでサーバに配備する、などプロジェクトを円滑に進める為に必要なツールやノウハウは色々とあるかと思います。
他にも静的なコンポーネントはWebアプリ（Javaで言えばWar）の外に出して管理すべきだとか、管理用のサイトはゼロから構築する必要がないとか、サブアプリケーションを適切に分割して再利用を促すとか、Django流のノウハウも色々あります。目指すのは、Railsのスピード感、Django流のクリア感、それらにJavaの堅牢さを加えられるのがTeedaかなと思います。
具体的なノウハウは、随時エントリーしていこうかと考えています。とはいっても、試行錯誤中のものなんですが。
