デザイナに eRuby を書かせるべきか否か

masayang氏に、わざわざ回答をいただいた。ありがとうございます。

  • eRubyでXHTMLの大枠を記述するのはRubyエンジニア
  • そのeRubyの編集をデザイナにも解放せよ
  • デザイナがeRuby構造を壊したとしても、テストで検知できるし、最悪リポジトリから戻せるではないか
技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記

これは同意できる。

  • リポジトリの概念はCSSの階層構造を理解できるデザイナなら、すぐに習得できる
技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記

これはよくわからない。リポジトリと、CSSの階層構造は、似ているとは思えない。

  • デザイナが先にHTMLテンプレートを作成し、プログラマがそれを参照にeRubyを書くという古典的手法では、「先に画面デザインを確定させる必要がある」ということになり、Agileの持ち味をぶち壊すことになる。
技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記

eRuby や Smarty のようにテンプレート中にロジックを埋め込むタイプだと、主に 2 つのアプローチがある。

  • (a) デザイナが HTML を書いて、プログラマがそれにロジックを埋め込む
  • (b) ロジックを含む HTML テンプレートをプログラマが書いて、デザイナが書き直す

masayang氏は、(a)のやり方は古典的であり、Agile の持ち味をぶち壊すといっており、37signals がとっているような (b) のやり方を勧めている。
(ここまではあってるよね?)


自分としては、(a) も (b) も間違いだと確信している。こういう問題が発生するのは、そもそも HTML の中にロジックを埋め込んでしまう eRuby や Smarty の仕様が原因である。HTML と Presentationg logic をちゃんと分離するようなツールを選べば、このような問題は発生しないし、デザイナが eRuby を書く必要もない。

eRuby や Smarty のようなタイプのものは、プログラマが HTML も書く場合は手軽な方法でありお勧めできるが、デザイナを入れて協業するようなプロジェクトには向かない。

で、id:kwatch さんの指摘
> いやー、超ありそう。つーか、SmartyとかJSPとかでもありそう。デザイナ涙目。
が成立するかどうかってのは、デザイナ作業によるデグレードをテストで検知できるか否かにかかっているのではないかと。つまり、テストフレームワークの選択と、それをチームが正しく使っているかどうか。

技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記

違うと思うなあ。デザイナと協業しようという工夫と熱意がプログラマにあれば、協業するためのライブラリを持ってくる(あるいは作ってしまう)なんて難しいことではない。でも現実にはそんなプログラマがいないから、デザイナが苦労しているだけ。
正直、デザイナに eRuby を書かせるなんてのは、プログラマの都合をデザイナに押し付けているだけだと思う。
Ruby on Rails でいえば、DHH が eRuby で満足しちゃっているのが元凶。

進化した技術を習得した技術者が集まる現場では、当然分業体制も変わってくるよね、という当たり前といえば当たり前の結論。だけど、わかってない人達は、わかってないこともわかってくれない。COBOL屋の話と同じだ。

技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記

まあ、これはその通りだと思う。デザイナが (JavaScript も含めて) プログラムを書くようになるんだから、プログラマもデザインに限らず要件定義や営業もできるようになるべき。

参考:米国における「Web Designer」求人一例
...(snip)...
もちろん、プログラマとデザイナの分業を維持している会社もまだまだ残っているよ。でも、ちょっと検索しただけでも、そういう分業体制が破壊された会社が見つかる、という意味をこめて上記3事例を載せてみた。

技術が変われば分業体制も変わる - サンフランシスコ出羽守手記(masayangの日記

これはすごい。デザイナの募集のはずなのに、まるでプログラマを求めているかのような条件ではないか。参考になるなあ。
この条件をクリアできるデザイナだと、給料はどのくらいになるのかな。これが平均レベルとかだったらやばいね。