私は、マークアップエンジニアという言葉は知りませんでしたし、ぶっちゃけ CSS で盛り上がる世界が存在しているということも理解できませんでしたが、以下のエントリの言わんとしていることは賛成です。

ただ、一つ違和感がありました。

IT戦記 - マークアップエンジニアはどこへ向かうべきか（を考えてたらカッとなって LL の資料公開）より

(X)HTML + CSS しか出来ない人はそれなりに危機感を感じたほうがいいと思った今日の昼ご飯でした。

JavaScript をごりごり書いている私が言うのもなんですけど、そんなこと言っちゃったら、Web 系エンジニア全体が微妙な気が・・・。CSS がバッドノウハウの塊で、極めるほどの本質的な奥行きがないなら、JavaScript もある意味同じ気がします。ぶっちゃけ「ブラウザ上なのにこんなことできて凄い凄い！」という世界ですからね。(--;　VC なら凄くねぇ！

# デモ、VC ノホウガムツカシイあるヨ。

つまり、私が感じている違和感は、本質と表層の捉え方なんだと思います。

http://twitter.com/amachang/statuses/191263472 より

「CSS 道」は道が短すぎるんだ。マーケティングの為に長く見せてるけど、実際覚えることは少ない。「デザイン」か「JavaScript」を職業に出来るくらいにしとかないとヤバいと思う。

私としてはデザインと JavaScript を同列においているのが少し気に食わないわけです。本質的な奥行きを持つデザインと、表層的な奥行きしかない JavaScript で比較するなんて。JavaScript のノウハウの少なくない部分は、言語が改善されれば（あるいはフレームワークやライブラリによって）消えゆく「べき」ものです。CSS ハックの大半がブラウザ（主に IE）の改善とともに消えゆくように。本質的な奥行き感で言えば、デザインと UI プログラミングくらいなら、結論として納得感があるんですけど。

# 絵のセンスがない私にとっては、絵描きさんやデザイナさんは尊敬の対象です。

UI に関係するプログラミング言語の変化はめまぐるしいです。つい最近まで主流だった VB も Delphi も Java + Swing も生き残っているとは言いがたいです。変化の激しいこの世の中で、JavaScript だって長く生き残るかどうかはわからないわけですよ。Ajax や Comet だって、本質的な部分には非常に奥行きがあるわけですが、表層に限って言えばあまり言うことはないわけです。近頃は Ajax.Request とか dojo.bind とか書けば Ajax してくれますから。

でも、UI に関係するプログラミングは実に奥が深いです。下手な書き方をするとすぐにメンテ不能やテスト不能（VB や Delphi のフォームみたいに）に陥ります。また、ユーザが直接触る部分ですから、工夫の余地は無数にあります。これらは、言語によらない本質的な難しさであり、価値です。

もちろん、今使っているプログラミング言語に精通することは大切です。でも、IT の世界は歴史が浅く道具の変化が激しいので、本質的なスキルは何か見極めていかないといけないんじゃないかなと思います。CSS の後に JavaScript では・・・あまりにも短期的な視点で食っていくためというのがアリアリ。そりゃ、食わにゃ死にますが、長期的かつ本質的なスキル開発を促しても良いんじゃないかな？、と思いました。

あ、でも、本エントリの言わんとしていることには賛成です。第二の何かは、Rails している人も、PHP やっている人も、JavaScript をやっている人にも、等しく必要なんだってことです。Java している人にもね！

以下、余談。

○ 余談１

とはいえ・・・C/C++ 言語の世界は変化が少ない・・・というか、変化はしているのだろうけど、プログラミングそのものが奥行きを持っている気がします。対象領域の違いから来るものでしょう。C/C++ だってアプリの世界なら同じ問題を抱えていると思います。

○ 余談２

スタンドアロン（Delphi + VCL でも Java + Swing でも VB でもいいけど）の世界を知っていると、HTML + CSS + JavaScript（＋LAMP）が、意外と理にかなっていて面白い世界なのが良くわかります。Web 系技術が凄くないと連呼する人はいるけど、また、私もそう思うけど、これまでのやり方よりは優れているんです。個別に見ると新しい技術はなくても、組み合わせて使うと新しいみたいな感じです。
実際、Kodougu（Ruby on Rails + JavaScript で実装されたブラウザ上で動作するモデリングツール）は、Java + Swing や C# + Windows.Forms で実装された同系統のソフトよりもはるかに短いコード（＝メンテしやすい）で実装できています。やはり、Web 2.0 のときに技術的にも何かが起こったんだなって感じます。「気づき」のあるなしとか些細なことなんですけど。

前にも少し触れましたが、今、ネット上では生産性に関する議論がなされているようです。
# 多分、もう決着はついたと思いますが・・・。

下にネタもとのリンクを貼っています。いわゆるアルファブロガーに相当する人しか追っていません。あまりに議論が膨大なので。(--;　多分、議論は生産性と賃金についてです。賃金は当人の生産性によって必ずしも決まるものではなく平均生産性から決まる（by 山形氏）という話題から始まって、紆余曲折あって、賃金は限界生産性（※）によって決まるという結論になって終わります。結論が出た後は、富の分配システムの方に議論が行ったようです。

これだけ盛り上がったのは、いわゆる炎上に近い現象が発生したと考えて良さそうです。経済関係の議論の問題点として、複雑なケース（たいていの現実は複雑ですが）になると、モデルを組むことが難しくなって議論が定性的になったり直感に頼るようになったりする（※※）ので、なおさら炎上しやすいのだと思います。(--;　でも、私は皆さんが言いたいことはそんなに違わないと思っています。

※ 限界生産性とは、労働者を一人雇用したときに上昇する生産性のことです。SIer なら生産性＝売り上げでいいと思います。間違っても生産性＝書けるコードの量ではありません。SI は人月による人身売買ですから、何人売れるかで十分です。一人雇ったときに上昇する売り上げによって賃金が決まると言えば、直感的でしょう。

※※ 池田氏はモデルがシンプルなのでこうした罠にははまっていません。読み物としては山形氏のものが面白いです。

結論がわかりにくかったので、自分でも少し考えてみました。（結論をなぞっただけですけど。）

SIer の場合、限界生産性は横ばいに近い（人月でビジネスをするので、人数×単価で売り上げが決まる）のですが、研究開発などのイノベーションによって単価を上げることができる（＝限界生産性を上昇させる）のなら、売り上げが上がって賃金も上がるというわけです。前の職場はそうしたロジックを大切にしており、単価を上げるような研究開発を継続して行っているため、単価＆利益率は業界最高クラスです（※）。給料は中の上くらいですが。(^^;　たいていの SIer は限界生産性は横ばいだと思うので、賃金も横ばいです。ただ、オフショアの浸透などが SIer の単価を引き下げる要因になるので、給料は下がっていくのかなと思います。
# だからオフショアの影響を受けにくい職種（要求とか PM とか）にエンジニアは転向しようとするのです。

※ このブログは前の職場の人も読んでいるので、一言警告を。この優位性は長くはもたない・・・つまり、抱えているイノベーションや新しく生み出しているイノベーションが相対的に価値が低くなっているので、会社におんぶにだっこではいずれ給料が下がっていきます。この方向性（技術の××）で行くのなら個人個人がもう少し意識を高く持つ必要があるんじゃないかな。え？　仕事が忙しいからムリ？？　そもそも技術志向なんてやってらんない？？？　ま、そーだよねー。

ということは、SI に関しては単価の高い仕事に転向しないと給料は下がる一方だよ・・・と。プログラマは生きてけないよってね。上流志向の人ならいいけど、IT エンジニアになったらみんな上流に行かなくてはいけない・・・というのはちょっと窮屈です。（私は長くオフショアに関わったせいか、そういった窮屈感は感じなくなっていますが。）もっとも、池田氏の最後のエントリ（賃金格差の拡大が必要だ）が実現すれば生産性の高いプログラマなら生きていけるという話になって、技術屋にとっては技術力を磨くモチベーションになります。

池田信夫 blog 賃金格差の拡大が必要だより

労働時間で賃金を支払って年功賃金で会社にしばりつけるといった在来の賃金体系をやめ、優秀なプログラマには契約ベースで管理職より高い賃金を払う必要がある。

さーて、単価が下がってプログラマがいなくなるもしくはワーキングプアになるのが先か、優秀なプログラマなら生き残っていける社会が来るのが先か。どうしたもんだろ。

■ 議論の流れ
以下、議論の流れです。（めちゃくちゃ長いのでリンク先は興味のある人以外は読まなくていいです。）

2007/2/4
山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - ゴッドランドの経済学
http://d.hatena.ne.jp/wlj-Friday/20070204/p1

2007/2/11
山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - 生産性の話の基礎
http://d.hatena.ne.jp/wlj-Friday/20070211/p1

2007/2/12
池田信夫 blog 生産性をめぐる誤解と真の問題
http://blog.goo.ne.jp/ikedanobuo/e/cd4e52fd7cca96ac71d0841c5da0cb75

404 Blog Not Found:生産性より消費性
http://blog.livedoor.jp/dankogai/archives/50762325.html

2007/2/13
分裂勘違い君劇場 - アルファブロガーたちの地位争いが優良コンテンツを量産する
http://d.hatena.ne.jp/fromdusktildawn/20070213/1171359965

山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - それでも賃金水準は平均的な生産性で決まるんだよ。
http://d.hatena.ne.jp/wlj-Friday/20070213/p1

2007/2/14
池田信夫 blog 生産性と「格差社会」
http://blog.goo.ne.jp/ikedanobuo/e/b8b2dd3502ef769c7f5baf18143f53e1

2007/2/15
分裂勘違い君劇場 - 「他人の生産性が向上すると自分の給料も増えるのか？」を中学生でもわかるように図解してみました
http://d.hatena.ne.jp/fromdusktildawn/20070215/1171504603

山形浩生 の「経済のトリセツ」　　Supported by WindowsLiveJournal - 山形より上手でていねいな説明をごろうじろ。
http://d.hatena.ne.jp/wlj-Friday/20070215/p1

404 Blog Not Found:生産性は誰のものか
http://blog.livedoor.jp/dankogai/archives/50765006.html

池田信夫 blog 賃金格差の拡大が必要だ
http://blog.goo.ne.jp/ikedanobuo/e/b697e23a80b6602167c2f5e43ebad041

「レッドハット，「JBoss」の新戦略を明らかに」を読んで感じたことは、オープンソースで収益を上げるビジネスモデル（の一つ）が割と見えるようになってきたことです。

Red Hat のビジネスモデルを簡単に説明します。まず製品を二つのエディションに分けます。バイナリが無料のエディションと、有料のサブスクリプションに登録しないと入手できないエディションです。ソースコードは引き続き公開します。ユーザーが自力でコンパイルして利用することは自由です。ただし、サポートはつきませんし、推奨もしていません。収益はこの有料のサブスクリプションから得るわけです。今のところ、Red Hat 以外で有名どころとしては、MySQL がこのモデルを採用しています。

Red Hat が JBoss の買収を完了したのは半年位前でしたっけ。上記の記事は JBoss のビジネスモデルも Red Hat に合わせていくという内容です。なんとなく、オープンソースも普通のビジネスになってきたんだなぁ・・・と感じました。