最新プログラム技術を貪欲に習得する先進的ユーザー企業
先日、ある企業様向けにSeasar2の研修を行ってきました。
この企業は、SIerではありません。様々なインターネット関連のサービスを
手がけていますが、SIerにソフト開発を発注する立場のユーザー企業です。
この企業のすごいところは、Webアプリケーション開発の最先端の
プログラミング技術を普段プログラムを書かない担当者にも
組織的にプログラミング技術を学ばせている点です。
少し前に id:higayasuo さんのブログの
『元請けもきちんとプログラミングできるようになること』
というエントリが反響を呼んでいました。詳しくは以下をご覧ください。
プログラミングできない元請けがプログラム設計書をレビューするという矛盾
http://d.hatena.ne.jp/higayasuo/20080415/1208224902
このエントリのコメントやトラックバックからすると、
元請け企業のプログラミング技術不足の指摘は的を得ていると思います。
そんな中で、冒頭で紹介させて頂いたユーザー企業は元請SIerを飛び越して、
最先端のプログラミング技術を習得するといった行動を既に起こしています。
SI業界のオピニオンリーダー的な人の発言を超えた行動を
既に起こしているのだから素晴らしいです。
組織的に時間も予算も掛けて本腰入れて習得しようとしてるため、
とても強い企業体質を築けることが予想できます。
ソフトウェアの受託開発は、発注担当者の能力がプロジェクトの
成否に大きな影響を与えると私は考えてます。その上で発注担当者が
プログラム技術を習得しているということは、元請SIerとの共通言語が
できるために、ワンランク上のコミュニケーションが実現でき、
プロジェクト運営がスムーズになることが予想されます。
おそらく、こういった考えをこの先進的なユーザー企業の経営陣が
理解されているのだと思います。
このような勝ち組になりそうな先進的ユーザー企業に選ばれて
お付き合いする元請SIerはより一層プログラム技術を習得して、
さらなるプロフェッショナル性が求められることになりそうですね。
ps. ちなみに、このユーザ企業様に受けて頂いたSeasar2研修の内容は以下のとおりです。興味ある方は、ぜひ、どうぞ！
http://www.tafc.co.jp/seasar2_seminar0805.html
SAStrutsはなぜ大規模開発に向いているのか？
Teedaは大規模向きではないのか？
また、Teedaと比べるとどうなの？とか
Teedaは大規模向きではないのか？など
私のようなSeasar初心者には見えにくいと思います。
Teedaはとても先進的で優れたフレームワークだと思います。（私の周りのRailsな人も絶賛してました）
ただし、大規模開発となると実績や開発者集め、学習コスト、実行性能の面でSAStruts(Struts)と比べて不利に思えます。
さらに、非機能要件対策系の機能が豊富なのがTeedaの強みの１つですが、これについてはStrutsで培った非機能要件対策系のノウハウをSAStrutsにも持ち込みやすいためにTeedaの利点が薄れてしまうといった側面もあるかと思います。
S2DaoとS2JDBC
・S2JDBCは、どんな所がSAStrutsに最適化しているのか？
SAStruts + S2JDBC
Teeda + S2DAO
これがよく言われている黄金？コンビなのかもしれませんが
その理由は？と聞かれると、私のようなSeasar初心者は
返答に臆すると思います。
Teeda + S2Dao の組み合わせですが、Teedaの画面周りのデータ構造はフラットであり、フラットなSQLの結果セットであるS2Daoの2WaySQLとの相性が良いと考える人がいるかも知れません。
しかし、S2JDBCの機能はS2Daoの機能を包括しているので、Teeda + S2JDBCでも良いと個人的には考えています。
S2JDBCは「流れるようなインターフェース」のインパクトが強いためか、時々、勘違いされている人を見かけるのですが、S2JDBCでもS2Daoと同じ構文で2WaySQLを使うことができます。（しかも、S2JDBCの2WaySQLはS2Daoのものよりも地味に進化しています。）
さらに、全てのデータアクセス処理を2WaySQLで処理すると開発コストが高くなってしまうので、SQL自動生成機能を併用すると思います。2WaySQLとSQL自動生成機能については、排他関係ではなくて、使い分けの比率が大切です。（簡単なデータアクセスはSQL自動生成、複雑なデータアクセスは2WaySQLが基本。）そして、より生産性が高いSQL自動生成機能の適応範囲が増えることがトータルの生産性向上に繋がると考えています。
このように考えると、S2DaoのSQL自動生成機能よりもS2JDBCのSQL自動生成機能の方が圧倒的にパワフルなので、トータルの生産性はS2DaoよりもS2JDBCの方が高くなると考えています。
