クラウドとHTML5にPHPが沈むとき

インフラ・タグ仕様の両面からPHPの存在意義が問われているように思えます。
安価なインフラとの親和性、テンプレート志向、その双璧が意味をなさなくなってきそうです。

クラウドPHP

(特に日本では)PHPレンタルサーバーで最も利用しやすいプログラミング言語です。また、LAMPによる開発ノウハウが充実していますので、カジュアルな開発者がもっとも手にしやすい言語と言えそうです。
レンタルサーバーでのリソースがクラウドに移行しようとしている現在でも、たとえばGoogle App Engine上でPHPは実行可能で、Amazon S3,EC2へアクセスする機能を提供しているPHPフレームワークもあります。とはいえ、クラウド上での実装を考えると、関数型言語の方が向いているのは明らか。その意味では、Pythonのように関数型に近い言語の方が向いています。
レンタルサーバー上でPHPを使うにしてもそれなりに設定が必要だったのに比べると、クラウド上でPythonを扱うのは非常に簡単です。となると、PHPの発達要因の一つ、安価なインフラとの親和性は、いずれPythonが受け継ぐことになりそうです。

そもそもPHPは誰にとって有用だったか

PHPを書いている人たちの組成がどのようになっているのか正確なデータは持ち合わせていないのですが、PHPを利用している人のほとんどはWebアプリケーションとして利用していると思われます。
HTMLソース内にコードを書くことができ、バックエンドの実装もその延長線上にありましたので、JSPJSFで実装するよりもはるかに気軽にアプリケーションを構築することができました。
PHPが対象にしているほとんどは軽実装なWebアプリケーションであったことは間違いないと思います。

PHPはテンプレート言語

話のスコープをもう少し絞ると、PHPはテンプレート言語です。
PHPフレームワークが発達してきて、大規模な開発にも耐えられるようになってきたり、PHP製のCMSなどが普及してきたりという背景はあるものの、それらのほとんどがテンプレート志向から離れていません。

デザイナーの呪縛とテンプレート脳

従来あった言語に比べて、PHPerの考えるシステムは若干特殊です。ごく最近、ある開発者がしゃべってるのを見て、ぎょっとしたのですが、
MVCとはデザインとロジックの分離!」
え?って感じですね。まじですか。と。
そういう人が一般的かどうかはわかりませんが、上記のコメント、PHPerっぽくありません?
CMSなんかだと、デザイナーにはPHPを触らせないとか・・・そんな話の流れで、テンプレート言語として発達したPHPで書かれたテンプレートエンジン、しかもそのエンジンに再びロジックを実装するという冗長・・・
テンプレート志向とは、簡単に言うと、デザインはHTMLソースで書いて、そこに必要なロジックをテンプレート言語なりPHPをはさんでテンプレートを作成するという発想のこと。
ある程度発達したフレームワークですら、そのテンプレート志向から離れることができていない様子です。
そして、そのテンプレートを書くのはデザイナー!!
テンプレートにはデザイン要素と、静的な意味付けによるタグが準備されているわけです。CSSによってデザイン要素は少なくなってきているものの、テンプレート志向では、テンプレートに対するタグの意味付けは、静的で動かしにくいか、もしくはテンプレートにテンプレート言語によるロジックがねじ込まれるしかないわけです。

テンプレート脳でHTML5の力を発揮することはできない。

PHPフレームワークを利用していくとき、テンプレート志向ではHTML5の機能を生かしていくことはできないでしょう。
デザイナーが作成したパーツをジェネレートしていくだけのシステムでは、モデル上で意味のあったデータが分解されて、再びHTMLソースとして再構成される処理の中で、意味付けはあっさりと破壊されてしまいます。そこで、テンプレートにデータが投入される部分にロジックを書いて、この問題を解決しようと試みたとしても、その作業がどのくらい膨大でかつバグを生みやすいか、アーキテクチャの手戻りであるかということは言うまでもないでしょう。
実用面での話を一つだけ、テンプレート志向や、MVC(笑)だとVに処理を回したあとに、出来上がったコンテンツが意味を保持していないので、たとえば、検索文字列をハイライトしたり、処理をバイパスするためにキャッシュを導入したりしつつ適切なデータを更新するとかの状況では、出来上がった出力データを再度解析するなど無駄な処理になりがちです。

デコレーション志向

タグの意味付けがわかりやすくなって、CSSやJSと動的に連携させたコンテンツをジェネレートしていくためには、データもタグも意味のある状態をキープする必要があります。その場合、テンプレートの中にデータを出力していくという考え方ではなく、データを意味のあるタグでラップしていくというデコレーション思考の方が向いており、これはドキュメントのほぼ全体に対して言えることとなります。デコレーションされた側は文字列にせず、出力の瞬間まで意味を保持していれば、処理中でエラーがあったときや、完成したデータに対して処理を行うときなどに、意味のある処理を追加していくことができます。できあがったドキュメントのポイントポイントにデータ更新やタグ変更などを行うことが可能になるわけです。
CSSやJSを動的に追加するためにも成果物がどのようなデータ構成になっているかを保持している必要があります。

マークアップの位置づけの変化 ( 追記 5/31 )

これに対してジョン氏は,「デザインからマークアップを考えるのではなく,コンテンツからマークアップを考えてそれに対して装飾を行うというプロセスがよいのではないか」と提案しました。

 --- 「実践 CSS3 & HTML5 with Microformats ワークショップ」レポート ---より

http://gihyo.jp/news/report/2009/05/2901

コンテンツの意味付けからマークアップを行うのが基本となり、デザイン要素については、(これは以前からそうですけど)CSSに任せましょうというお話。これは、CSSの充実、ブラウザの対応力の強化による変化だと思います。
Webアプリ側からすると、MVCのVはマークアップとコンテンツをマージする機能を持っていますが、マークアップからデザイン要件を排除できるのであれば、Vはデザインではなくなります。MVCでのVは意味のドキュメント化であって、デザインとロジックの分離ではないわけです。つまり、「MVCはデザインとロジックの分離、もしくはデザイナーとプログラマーの分業」と言っていいのは〜〜まで。(ry
大量のビューファイルを用意したり、ビューの中でIfを乱発してロジックをねじ込むよりは、マークアップロジックを整理してアルゴリズムで育成してもいいのではないか。*1マークアップという作業は、コンテンツをデコレーションしていくものであって、マークアップの入れ物の中にコンテンツを投入するというのとは真逆な発想と言えると思います。

PHPでもデコレーションは可能だが

ではPHPでデコレーション志向はできないのか?そんなことはありません。
ただ、この部分、そこまでこだわって実装しなおすなら、何もPHPじゃなくてもいいんじゃね?っていう話になってきます。
できるけど、PHPのメリットはなくなるね。っていうお話でした。

それはクラウドの効果なのか? (追記)

publickeyさんのところに気になるエントリーが上がったので追記します。

ITの世界でも変わっていく分業制

僕はITでも似たようなことが起きるのではないか、と思っています。これまでアプリケーションの多くはパッケージソフトとして販売されていました。パッケージソフトでは、開発を担当するプログラマと、それをサーバやPCにインストールして運営するエンドユーザーはそれぞれ別の組織に属しており、分業が成立していました。

しかしクラウドの登場が、この分業制を終わらせることになりそうです。業務システムはパッケージとして販売される時代から、開発した人(もしくは組織)がそれをクラウドに乗せて運用しユーザーに使ってもらう時代になろうとしています。

クラウドは、編集者にとってのDTP、カメラマンにとってのデジタルカメラのような存在になるのではないでしょうか。

http://www.publickey.jp/blog/09/it_1.html

パッケージベンダの開発者とエンドユーザーが分業というのはちょっと意味がわかりません。分業制が終わるというよりも、パッケージベンダという範疇が大幅に市場を失うということは言えると思います。それがDTPやデジカメの話と関係しているというのは理解しかねるのですが、読みが甘いんでしょうか・・・
クラウドという側面はさておき、Web開発の現場では、デジカメ、DTPの世界と同じことが起きようとしていますので、比喩的には納得がいきます。デザイナーとプログラマーの分業がMVC(PHPの)で言われた時には、それぞれの仕事には乖離があったので分業が必要だったのですが、今後はデザインワークをロジカルに進めるフレームワークや、プログラムを行わずに機能を組み込めるCMSなど、両サイドから分業を不要にするアプローチが行われています。
Publickeyさんのエントリーがどのスコープについて語っているのか焦点が見にくいのですが、SIerについていえば、これまでもサーバーの運用ノウハウは保守費用を稼げて、ソフトハウスとの差別化ができるポイントだったと言えます。SIerにとってサーバー設備の運用が競争力の大きなウエイトを占めていたことが間違いないのですが、クラウドはその対象を変えたとしてもSIerの意義はほとんど変わらないでしょう。クラウドが担うのは、インフラの変化であってアプリケーションの変化ではないので、もともとインフラを扱っていたSIerからすれば、「もともと総合力勝負だよ?」というところです。
誰にとっての「IT総合力」なのかが明確になっていないと、クラウドによってもたらされる「IT総合力」の時代 - Publickeyというタイトルは、クラウドバズワードとして使っているだけのように見えてしまいます。MSも遅ればせながらクラウドをリリースしていることはPublickeyさんのエントリーにもあることなのに、これはどういった流れなのか、気になります。うーん、もしかして、中規模以下のパッケージベンダだけを対象にした話なのかもしれない。それなら合点がいくかも。
まぁ、いずれにしてもIT系の技術の進化は技術者がいらなくなる方向に進化するのは間違いなく、そこはねずみ講の破たんプロセスとなんら変わらないので、淘汰される会社もエンジニアも次の技術を見据えて、勉強する時間を十分にとっていく必要はありそうです。
その意味で、私のタイトルの釣り部分=>「PHPが沈むとき」というのは実はPHPが沈むということではなく、PHPはこれまでの意義を脱ぎ捨てて新しいステージに進化するのでその前振り、PHPerも他の技術を蓄えつつ行く先を見極める、そんな流れを感じています。

フィールド拡張とか

最近PHPCMSの話題がでるとき、フィールド拡張がやりやすいかどうかというのが頻出質問になっていますね。これはどういうことかといえば、すでにWebのニーズは動的なデータモデルの変更を必要としているが、テンプレート脳でその問題を解決するにはCMS側でフィールド拡張に対応していなければできないという、そういう流れと思われます。逆に言えば、フィールド拡張は若干手間のかかる作業になっていて、データベースのマイグレーションからシステム実装まで各種考えなければならない内容が増えていることの証です。そこを大変な開発リソースを割いて、フィールド拡張を実装しているケースが多いように思われます。
せっかく、フットワークの軽い言語を使っているのにそのメリットが生かされないとしたら、残念な感じですね。

*1:ブラウザーが糞だった時代にはそんなロジックを実装することはほぼ不可能だったので職人芸が必要だったわけですが