Javaを拓く人々
フレームワークでWeb開発を効率化
―エンジニアスキルの平準化にも成功―

取材 宮下知起
2001/2/15

テンアートニは創業時からJava/Linuxを使ったソリューションに注力してきたシステムインテグレータだ。同社では独自に開発したWebWorkBenchというフレームワークを受託案件の8割に適用し、Java開発の生産性向上とエンジニアのスキルの平準化に成功している。 今回はWebWorkBenchの開発を行った株式会社テンアートニ WebSolution本部 次長 長尾寿宏氏に、開発の経緯やメリットなどについて聞いた。（編集局）

---

[編集局]長尾さんご自身のJavaへの取り組みはいつ頃からでしょうか？また、その当時のJava開発の状況はいかがでしたか？

株式会社 テンアートニ WebSolution本部 次長 長尾寿宏氏

[長尾氏]1998年から取り組んでいます。当初はプロトタイプのような案件を多くこなしていました。アプレットを使った開発が多かったのですが、正直言ってアプレットには将来性はないと思っていました。もともとアプレットの目的はポータビリティだと思うんですが、Webブラウザの実装に依存する部分が大きいという欠点がありました。それにパフォーマンスの問題も大きかったですね。なにしろJavaのバージョンがどんどん上がっていきますので、通常のアプリーションと同等のメンテナンスの負荷がクライアント側にかかってくるのも大きな問題でした。

サーバサイドJavaにはじめて取り組んだのは非常に早く、1998年の後半です。ある外食産業大手企業のシステムを、ApacheにJServeを組み込んでつくりました。サーブレットに関しては書籍も雑誌の記事もなく、まったくの手探りでした。唯一の手がかりが、JBuilderが吐き出すコードのひな型でした。独自にセッション管理だとか、データベースのコネクションプーリングを実装して、なんとかシステムを完成させました。終わってみると、サーバサイドJavaはけっこういけるなと思いましたね。

■開発における標準化、共有化のポリシーがフレームワーク誕生のきっかけ

[編集局]御社独自のフレームワーク作成にとりかかったのはいつ頃のことでしょうか？

[長尾氏]実は先ほどの外食産業企業の案件の中で、すでにフレームワークを意識した開発を行っていました。そのプロジェクトが終わってすぐくらいに上司からの指示がありまして、案件とは別に作成をはじめました。

[編集局]フレームワークの発想はどこからきているのでしょう。それとJavaによる開発に抵抗感なく取り組めた理由は？

[長尾氏]私のバックボーンにはメインフレームの経験があります。この世界では、開発において標準化であるとか共用化というのが前提としてあるんですよね。そういった良いところは、オブジェクト指向モデルでも当然ながら実践していかなくてはならないと思ったわけです。そこでJavaでも、部品の再利用をはじめから目指しました。単なるクラスオブジェクトとコンポーネントの違いは、再利用を意識して作るかそうでないかの違いかと思います。

ところで、メインフレームを経験した後は、クライアント・サーバの開発も経験しました。どのようなシステムでもチェックしないといけないポイントは実は同じなのです。たとえば、チューニングが容易である、というようなポイントです。

あと、昔のSQL Windows（その後Centura）やDelphiといったオブジェクト指向ツールの経験も大きいですね。クライアント・サーバ型の開発では、これらのツールにOracleという組み合わせを多くやりました。当時から、部品づくりはやっていました。そのときのベースがいまに繋がっているのだと思います。

[編集局]フレームワークが具体的に形になったのはいつ頃でしょうか？

[長尾氏]日本アイテックス殿の事例の中で、フレームワークを全面的に使いました。私はプロジェクトリーダーという立場にありまして、業務分析やデータベース設計は担当者にまかせました。私はフレームワーク部分を一人で構築しました。もともとフレームワークのベースは2000年1月の時点でほぼ完成していましたので、そんなに時間のかかる作業ではありませんでした。

このフレームワークは、ビジネスプロセスを規定するものではなく、コードの実装にどう縛りを入れるかという性格のものです。日本アイテックス殿の事例の場合、画面数が400以上、スタッフも12、3名と大きな規模の開発だったために、ルールを決めないと色々な実装スタイルが生まれてしまう恐れがあるのです。この状況の中で標準的なコードのスタイルを定めるのが、フレームワークの第一の目的でした。

もう1つの大きな目的ですが、この事例ではフロントにはサーブレットを使いましたが、バックにはCORBAオブジェクトを使っています。サーブレットを担当するプログラマからは、このCORBAオブジェクトを1つの機能を呼び出すかのように利用できます。データベースへのアクセスとか、セッション管理、帳票出力といった括りで機能を提供するのです。リモートのCORBAオブジェクトにつながるコンポーネントを用意して、それを介して使うようなイメージといえばわかりやすいでしょうか。これで、サーブレットのプログラマはCORBAを意識することなく使えるのです。

■フレームワークがあればエンジニアのスキルチェンジも容易

[編集局]VBしか知らないエンジニアが、どうやってスキルチェンジすればよいと思いますか？

[長尾氏]Javaの知識よりも、Webまわりの知識が必要ですね。ですのでASP（Active Server Pages）をやられている方であれば、わりと近いところにいると思います。Javaという言語そのものは、それほど敷居は高いとは思えません。

あと、従来手法の設計アプローチでもJavaのシステムは作れます。本に書いてある通りでなく、これまでの自分の経験をうまく活かしてJavaのシステムを作っていくことを目指すべきではないでしょうか。

[編集局]フレームワークの効果は？

すでに、案件の8割はフレームワークを使用しています。フレームワークをベースに業務アプリケーションを作るのであれば、データベースの設計と画面の設計ができていれば簡単です。フレームワークは基本的なクラス群なので、解釈によって自由に使えてしまう性格を持っています。ですので、社員には標準的な使い方を教えることにしています。

そうですね、簡単なDBの更新フォームであれば半日くらいでできるでしょう。簡単なDBシステムであれば3日もあればできる。

また、このフレームワークは「WebWorkBench」として製品化しています。私たちが蓄積したWeb開発のノウハウを、多くの人たちに使っていただきたいというのが趣旨です。また、フレームワークにはCORBA ORBとしてVisiBrokerを使っていますので、ボーランドさんにご協力をいただきAppServer 4.5と組み合わせたパッケージの提供を開始しています。また、2月23日には、このWebWorkBenchもとにWebアプリケーション構築における問題点とその解決法決についてセミナーを開催する予定です。

[編集局]エンジニアはフレームワークに慣れるまでどれくらい時間を要しますか？

[長尾氏]面白いのは、縛りが多い部品なので、はじめてこのフレームワークの世界に入った人は慣れるまで生産性が上がりません。しかし、いったん慣れてくるとものすごく生産性を上げます。その成長曲線がすごいのです。

慣れるまでの期間ですが、画面制御はどうやってつくるんだ、みたいな色々なパターンがありますので、１案件をこなす期間が必要です。基本的な部分は１週間くらいで理解できると思います。

[編集局]Javaが初めてというエンジニアでも適応できるのでしょうか？

[長尾氏]弊社でも未経験者を数名、中途採用しています。フレームワークを使った開発には、かえってJavaを経験していない方のほうが早く適応してくれているように思います。あくまで部品として考えて使っているからかもしれませんね。

■プロジェクトが失敗する原因は何か？

[編集局]御社には失敗した案件がよく持ち込まれてくる聞きます（笑）。それらを見られて、失敗の原因は何だと思われますか？

[長尾氏]部品の設計が誤っているのだと思います。設計で間違っている。オブジェクト指向言語のうまい使い方を知らないのだと思います。効率のよい部品をつくるという側面を失ってしまうといけない。

基本的には、誰もが使える部品をどう作るかという点と、それを組織内でどう運営していくかという点の2点が重要です。あとは、一般的なシステム作りのノウハウをもっているかという点だと思うんですよ。データベースの操作も満足に知らないというレベルに結構出会います。

また、我々はJavaを扱うSIerですが、すべてをJavaで書こうとは思っていません。データベースではストアドプロシージャを使いますし、必要でしたらCも使う。Javaだけでやろうとすると、どこかで歪が出てきます。

あと、とにかくアプリケーションサーバを買えばよいという風潮があります。オーバースペックのアプリケーションサーバを利用するケースは良くないと思いますね。アプリケーションサーバの提供している機能の半分も使っていないという状況が多いのではないでしょうか。EJBを使うのであれば必要ですが、サーブレット、JSPレベルでは必要ないケースも多いのです。

弊社では、ApacheにTomcatという組み合わせで構築する例が多いです。フロントでのロードバランシングが必要であればロードバランサーを。アプリケーションレベルのロードバランシングを行うのであれば、セッションのデータ層はCORBAベースで実現します。CORBAオブジェクトの単位でクラスタリングを行い、ロードバランシングできるのです。これも、すでにフレームワークに含まれていますが、このようなシステム構成であれば、分散環境にも対応できるわけです。

[編集局]CORBAはやはり今後も重要な技術でしょうか？

[長尾氏]私は必要な技術だと思っています。分散オブジェクトのコアとしては非常に重要だと思います。将来はEJBのインターフェイスでラップされるような使われ方をしていく可能性はあると思います。

[編集局]CORBAはエンジニアにとって非常にとっつきにくい印象があるのですが。

[長尾氏]CORBAはフレームワークを作るので調べ始めました。手順が多いという点で敷居は高いですが、そんなに難しいものではないと思います。ただ、何にどう使うという点を明確にしないで使うと、いいものが出来上がらないですね。たとえばCORBAのオブジェクトも色々な作り方があります。EJBでいうエンティティBeanライクな使い方や、ビジネスオブジェクトのように使い方があると思いますが、弊社はそういう使い方をしていません。あくまでも、どんなクライアントからも、データベースのサービスを返すものとか、名前を渡せば帳票を返すとか、どこからも使えるサービスを立ち上げるかたちで利用しています。

[編集局]最後に、これからJavaを始めるエンジニアに一言いただけませんか。

[長尾氏]とにかく自分でトライしてみることじゃないですかね。JBuilderなどに添付しているサンプルを頼りに自分で書いてみて動きを確かめてみるというのが重要です。小さいところから大きく膨らませていくというのが重要だと思います。

　

[関連リンク]
株式会社テンアートニ
WebWorkBench紹介ページ

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）