企業IT部門がもっと効率的に新機能を提供するためには

最初に簡単な前提を示しておこう。それは、「今日の企業IT部門は新しいビジネス機能をほとんど提供できていない」ということだ。異論のある人もいるだろうが、たいていの企業幹部は賛同してくれるだろう。

そう考える根拠は何か? IT担当者の声を聞いてみよう。彼らはほとんど故障修理ばかりを行っている。新しい機能ではなく、サポートとセキュリティを提供することに時間を費やしているのだ。通常、予算の80%は現行システムの保守に使われている。彼らについて、Gartner社は暗い見通しを述べている。「融通のきかないインフラストラクチャの『世話係』としてのIT部門は、いずれ消えゆく運命にある」。

サービスとしてのソフトウェア(Software-as-a-service:SaaS)は急速に発展してきている。これは、コアコンピタンスでない部分をIT部門の手から解放する手段だからだ。IT部門が業務マネージャのニーズに応じられない場合でも、SaaSを利用すれば、IT部門の手を借りずに済む。企業ビジネスユニットや中小企業でも、サブスクリプションサービスを利用すればさまざまな処理をオンラインで実行できる。オープンソースは、企業ITの政治的問題や官僚主義を避けるためのある種の自助努力であり、企業ITの中から生まれてきたものもいくつかある。

今のところ、YahooやAmazonのような広告収入またはトランザクション収入に基づくサービスや、Salesforce.comやRightNowのような組み込みのビジネスプロセスを備えたサブスクリプションサービスは、従来のソフトウェアベンダやIT部門に対して高い壁を築いている。Googleはユーザが許容できるオンライン応答時間を短縮化した。37 Signalsなどの企業はWebインタフェースの新しい可能性を示している。Paul Rademacherのように、GoogleマップとCraigslistのレンタル掲示板を組み合わせて画期的な機能を公開している個人開発者もいる。このような新しい動きを見ていると、古いビジネスのやり方は受け入れられにくくなるだろうと思う。

これからの企業のIT部門はただの「ファイアウォール設置屋」になってしまうのか、それとも新しい機能を作り出すという役割を今後も担い続けるのだろうか? IT Manager’s Journal編集部(以下、ITMJ)はこの点について、ActiveGrid社の創立者でCEOであるPeter Yaredに話を聞くことができた。

ITMJ: 何年か前、ハーバード大学のNicholas Carr教授が「IT Doesn’t Matter(もはやITに戦略的価値はない)」という論文を発表しました。この主張に反対する人も多くいますが、このような考え方が出てきたのはなぜでしょうか?

PY: ITはここ数年で数々の困難を乗り越えてきました。既存のシステムをWebインタフェース方式にスケールアップし、インターネットトラフィックの負荷を処理するというのは非常に大きな挑戦でした。今日では、ごく単純なWebアプリケーションでも、何かコードを書こうとすれば専門家の手が必要になります。ごく基本的なアプリケーションを作るのでさえ非常にたいへんなので、情報収集を単純化し、ユーザエクスペリエンスを充実させ、ビジネス機能を自動化し、業務を合理化するというIT本来の能力が損なわれています。これまでは個々のアプリケーションが他のアプリケーションをことをまったく考えていなかったので、共有するのも簡単ではありませんでした。当社では、企業開発者がXMLネイティブな複合アプリケーションを作成できるようにするために、ActiveGrid Application Builderを一から開発しました。

ITMJ: ActiveGrid Application Builderのターゲットは誰ですか? そしてその理由は?

PY: かつては、大卒の新入社員を雇い、何週間かPowerBuilderのトレーニングをすれば、その新人が新しいビジネスアプリケーションを開発できるようになるという時代がありました。しかし今では、J2EEのような複雑なプラットフォームのおかげで、そんな光景はすっかり見られなくなりました。かつてのPowerBuilderはどれだけ開発者の役に立ったでしょうか? PowerBuilderでは、開発者はいきなり空白ページを目にするのではなく、既知のソリューションのパラメータをいじることから始めることができました。それに比べて現在では、Visual Basicのように単純な言語でさえ、開発者はまず空白ページから始め、そこに機能を付け足していきます。ActiveGrid Application Builderでは、まずウィザードから始まり、開発者が既知のデータベースからスキーマをインポートすることができます。システムのロジックは適切にカプセル化された標準XMLコンポーネントから成り、ボタン1つで配置できます。これにより約10倍の生産性向上が見込まれます。

ITMJ: .NET以外の4GL開発言語を使っている人はほとんど見かけませんが、御社の開発システムの勝算はどこにあるのでしょうか?

PY: たいていの4GLは、2つの問題のうちどちらかを抱えています。1つ目は、プロプライエタリなメタデータを使用していることです。ただ、.NETの場合は、基盤となるプラットフォームがMicrosoftのものなので問題ありません。2つ目は、コードジェネレータが装飾過多なのでラウンドトリップ開発が面倒なことです。開発者にとってはどちらの問題もわずらわしいので、4GL環境は使われていません。

ここ数年の重要な出来事は、宣言的なXML標準がいくつか定められたことです。たとえば、データソースを定義するためのXML Schema、Webプロセスフローを定義するためのBPEL、動的ユーザインタフェースを定義するためのXForms、データクエリを定義するためのXPathとXQueryという具合です。ActiveGrid Application Builderでは、高度な4GL開発を行いつつ、これらの標準に基づいてファイルをリアルタイムに編集します。そのため、プロプライエタリなメタデータやコード生成を使わずに、4GLのメリットをすべて享受することができます。

ITMJ: なぜJavaを使用しないのですか?

PY: Javaは複雑な言語であり、本格的なシステムプログラマにとっては魅力的ですが、それ以外の多くの開発者はその複雑さゆえにしり込みしてしまいます。Javaはもともとセットトップボックス用に設計された言語ですが、それでは関心を呼ばなかったので、Javaのマーケティング担当者はターゲットをデスクトップにしました。しかしそれでもうまくいきませんでした。やはり複雑すぎたからです。最終的には、「一度書けば、どこでも動く」という性質がソフトウェアの移植性という要件を解決することになり、Javaを救いました。企業各社は、サーバプラットフォーム間の移植性を実現するためにJavaの複雑さを喜んで受け入れました。しかし今日では、Linuxサーバを手頃な価格のx86サーバに移行する企業が増えているため、移植性に対する需要は減少してきました。Amazon、Google、Sabreのように広範なトランザクション網を持つ企業は、従来的な3層アーキテクチャの固定的なコストと技術的な制限のために、J2EEや.NETを使用していません。その代わりに、手頃な価格のx86やLAMPプラットフォーム(LAMP=Linux、Apache、MySQL、PHP/Python/Perl)にアプリケーションを配置しています。

しかし、ここでもう一歩進めて考えてみましょう。今日、最も垂直統合が進んでいる形とは、手頃な価格のネットワーク上に手頃な価格のx86ハードウェアを配置し、そこでLinuxを実行した上でApacheを実行するというものです。LAMPはオープンソース開発の大いなる自主的選択の例であり、私はこれを「ソフトウェア的ダーウィニズム」と呼んでいます。つまり、進歩が積み重なって最善のソリューションが形作られたというわけです。LAMP構成上でテストを実行してみたところ、ノード間通信の応答時間は、セッションの確立から切断までを含めても0.5ミリ秒以下でした。企業はもはやオープンソースを興味深いトレンドとは見ていませんが、LAMP構成のことは高く評価しています。ただ難しいのは、プロプライエタリ・ソフトウェアと複雑なアーキテクチャを統合しつつ、オープンソースの経済性を損なわないようにすることです。

PY: LAMP構成で開発することに他の理由はありますか?

ITMJ: あります。LAMP構成をサポートしているISPは何千社とあります。LAMP上で開発していれば、ActiveGrid開発者は、PHP 5とApache 1.3、さらにMySQLまたはPostgreSQLをサポートしているどのISPのサーバにも、アプリケーションをボタン1つで配置できます。要するに、Do It Yourself方式のSaaSということです。アプリケーションを自分で作成して配置することができ、マシンを購入する必要はありません。

ITMJ: 開発者がプロプライエタリ・アプリケーションサーバから離れつつあるのはなぜでしょうか。

PY: アプリケーションサーバは、バックエンドシステムのマルチプレクサとしては非常に優れています。しかし、このようなミドルウェアを導入するほど複雑なシステムはもはや必要とされていません。これらのミドルウェアは多様なAPIを使用してバックエンドマシンと通信を行い、もともとテキストではなく高度に構造化されたデータを扱うために設計されたものでした。今では、手頃な価格のソフトウェアとハードウェアを使用して、大容量のテキスト提供サーバとして設計されたシステム上にWebアプリケーションを配置することができます。これこそまさにブラウザやWeb上のその他のデバイスが必要としているものです。XML形式の自己記述的なテキストを、HTTPを通じて何百、何千というブラウザやその他デバイスに提供できるのです。Google、Yahoo、eBay、Amazonなどは、一流のコンピュータ科学者を雇ってこの種のアーキテクチャを組み立てています。ActiveGridはこの能力をすべての開発者に利用していただくためのものです。かつて、人々は自動車を1台ずつ手で組み立ていました。しかし、それは遠い昔の話です。当社のオープンソースのApplication Builderは、アプリケーションを作るための組み立てラインを開発者にご提供します。これはフリーなので、どなたでもダウンロードして試していただけます。

ITMJ: PHPのようなスクリプト言語をパフォーマンスを低下させずに使用するにはどうすればいいですか?

PY: 全体的な作業負荷と、Unixのスクリプト言語の起源に注意する必要があります。スクリプト言語で何か複雑なこと、たとえば文字列の置換やネットワーク呼び出しなどをするときには、過去何年間にもわたって強化されてきたC/C++のライブラリを呼び出しています。これはJavaと大きく違うところです。Javaでは、文字列の置換から算術演算にいたるまで、すべてのことを仮想マシン内で処理します。

ITMJ: では、最後にまとめさせてください。まず、ActiveGridの目的は、広範囲にわたる多トランザクションのWebサービスを支えるソフトウェアを作ることである。ActiveGrid Application Builderは、XML標準に基づいて、そのソフトウェアをデータベースなどのバックエンドリソースに接続する。準拠しているXML標準は、XML Schema、XPath、BPEL、XFormsである。Application Builderは、単純なフォーム、スクリプト、サービスを備えたウィザードベースの使いやすい4GLである。現在では、このロジックと統合WebサーバとデータベースをApache Software Licenseの下で無料でダウンロードできる。

PY: そのとおりです。当社のオープンソースプロジェクトのファイルをダウンロードしたい方や、詳細について知りたい方は、www.activegrid.com/developergridにアクセスしてください。

ITMJ: どうもありがとうございます。

John Koenig − ソフトウェアベンダおよび投資家を顧客とする経営コンサルタント会社、Riseforth, Inc.の創立者。ITMJに数多く寄稿。詳細についてはwww.riseforth.comを参照のこと。ご連絡は(650)726-7775またはjkoenig@riseforth.comまで。

原文