ITの地殻変動はどこで起きているのか？～SeasarとRuby、そしてPF

2008年になってみて、ITの地殻変動がどこに起こっているのか？を考えてみる。
※以下は殴り書き。後でロジカルにまとめる。

【1】XPからPF(プロジェクトファシリテーション)へ

ウォーターフォール型開発はメインフレーム＋Cobolの時代の開発プロセス。今となっては古い。

RUPは、業務向けオブジェクト指向開発を基盤とした開発プロセス。
馬鹿でかい。皆こなしきれない。
ウォータフォール型開発に、各フェーズでインクリメンタル型を取り入れただけ。

XPは、Webシステムを基盤とした開発プロセス。
XPは、ここ10年の経験に裏打ちされた開発プロセスの革命。
ソフトウェア工学にも新しい知見を生み出した。

XPでは、プログラマは、コーディングするパンチャーではなく、システムの品質に対する最終責任者。
ドキュメントよりも動くプログラム重視。
プロトタイプ重視。

ソース共有、コーディング規約、常時ビルド、そしてインクリメンタルな開発。
いずれも、Webシステム開発にすごくマッチする。

Webシステムの場合、Webサーバーでデプロイしてリリースすれば、いつでも誰でも稼動確認できる。
常時ビルドしているから、常時リリースできる。

顧客も設計者も開発者も巻き込む。
昨今の時代、要求の一つであるリリーススケジュールが最も大きな意味を持つ。
リリースするタイミングが遅れるほど、マーケットシェアを失う。

機能単位に細かくリリースして、システムをバージョンアップしていく。
バージョンアップしないシステムは、時代にマッチした新規機能が追加されないので、死んでいるのも同然。
常時リリースできる開発スタイルだからこそ、取れる戦略。

XPは技術重視、プログラマのための開発プロセス。
平鍋さんが提唱するPF（プロジェクトファシリテーション）は、XPの弱い部分であるチームビルディングにフォーカスを当てる。

昨今では、3～6ヶ月単位のプロジェクトで、新規メンバーをかき集めて、システム開発するパターンが多い。
この時に、すぐにチームビルディングできるかどうかは、プロジェクトの成功を大きく左右する。

プロジェクトが求める役割に各メンバーがマッピングできるか？
プロジェクトが進行中、ぶち当たる課題、そして突然のトラブルに、チームとして解決できるか？

ニコニコカレンダー、バーンダーンチャート、タスクかんばんという進捗管理。
朝会、KPTという場。

技術だけでなく、チームそしてプロジェクトをコントロールできるか？

【2】Webフレームワークに関数型言語の特徴を取り入れてみる

IT技術は、Reach(使用人数のスケール)とRich（UIの使いやすさ）の2軸を拡張する方向で発展してきた。

メインフレーム
→デスクトップ
→Webアプリ
→Webリッチクライアント

Webフレームワークでは、まずSeasarがDependencyInjection、Aspectという観点を実現した。
そして、RubyOnRailsが、REST思想を実現した。

REST思想は、EJBやSOAPの反対に位置するもの。
すごくシンプルな発想。
誰でもプログラムで実装できる。

Webシステムの最大の特徴は、ステートレスであること。
ステートレスだからこそ、スケールアップがすごく簡単。
Webサーバーを増設すればいい。

REST思想は、Webアプリがステートレスである特徴をよく生かしている。

だとしたら、ステートレスである関数型言語の方がオブジェクト指向言語よりもWebフレームワークに向いていないか？
オブジェクト指向はデスクトップアプリ開発から生まれた。
デザインパターンはオブジェクト指向のカタログ。

RubyがJavaと違うコーディングスタイルは2つあると思う。
一つはクロージャ。
もう一つは、短絡評価(short-circuit evaluation)。

最近のコーディングスタイルとして、メソッドチェーンや3項演算子を使いまくるソースをよく見かける。
JavaScriptでは、Prototype.jsを見ると、3項演算子を3個以上も繋げているソースもある。
メソッドチェーンの利点は、英文を読んでいるかのように1行で済むこと。
Javaならば、メソッドでチェーンするたびに、オブジェクトのNULLチェックが必要になる。
後者は、ダックタイピングの特徴もあり、オブジェクトに定義されていないメソッドがあれば無視される。

クロージャは、まだ理解し切れていない。
普通は、ループ処理の代わり。

クロージャが本当の威力を発揮するのは、継続(Continuation)を使うこと。
継続(Continuation)は、本質的にGOTO文と同値。
return, break, continueは全て継続(Continuation)で書き直せる。

継続(Continuation)をWebフレームワークに取り入れると、Webシステム開発がすごく楽になる。
その発想は、下記を参照せよ。

部分継続の使用法

閲覧は自由だが書き込みはログインが必要なサイトを作る場合の例が書いてある。
クライアントから見ると次のような画面遷移になるだろう。

1.投稿記事入力フォーム(ここで入力してポストする)
2.ログイン認証画面 （ここでログインチェック）
3.記事閲覧画面(投稿記事もしくは記事一覧などを表示する)

すると下記のようなロジックが必要になる。

2-1.入力フォームから記事がポストされた時にログインしてなければ、ポストデータを退避しておき、ログイン認証させるためのページを返す。

2-2.ログイン認証を行い、認証が成功したら、退避していた情報から記事投稿の処理を再開して記事投稿後のページを生成して返す。

つまり、Webアプリはステートレスなので、ポストデータは一度セッションに退避して保持しなければならない。
また、退避していたセッション情報から記事投稿の処理を再開する部分などは決して楽なプログラミングではないだろう。

継続(Continuation)を使えば、途中まで実行した手続きをクロージャで保持し、しかも途中から処理を再開するルーチンをコールできる！
つまり、投稿した後の処理を継続(Continuation)を使って、ログイン認証成功後に呼び出すように表現できるのが、継続Webフレームワークの最大の特徴なのだ。

継続サーバーの概念は、「ハッカーと画家」「JavaからRubyへ ―マネージャのための実践移行ガイド 」でも取り上げれている。
今後数年で出てくるはず。

【3】日本のIT技術の希望～SeasarとRuby、そしてPF

日本のIT開発は、舶来品の部品で開発しているようなもの。
だが、2000年以後、日本独自の技術や概念が出てきた。

JavaのフレームワークSeasar。
Railsを生み出したオブジェクト指向言語Ruby。
そして、XPを補完するPF。

それらは日本のIT技術の希望。