ObjectSquare [2005 年 5 月号]

[特別企画]


こんなテクノロジーに注目してます by オブジェクトの広場編集員

日々の業務に追われていると、 「なかなか最新技術の動向を追いきれない...」と感じることはありませんか?

特に、普段の業務で触れる分野であればともかく、 業務で触れることのない分野については、その概要さえ把握することが難しいものです。 例えば、Java による開発に従事していると、.NET の動向についていけない!! ということになってしまいがちですし、その逆もまた然りではないでしょうか?。 その一方で、この業界に属しているエンジニアであれば、 たとえ専門外のテクノロジーであったとしても、 現在注目されている、もしくは、これから注目されるであろうテクノロジーの概要くらいは把握しておきたいものです。

そこで今回は、オブジェクトの広場編集部のメンバーが注目している、 最新の技術を集めてみました。

当編集部のメンバーは、

などなど様々な業務に携わっています。本記事では、このように多種多様な業務に携わっているエンジニア達が、今現在どういった技術に興味を持っているのか、その理由と共に紹介させて頂きます。 本企画が、お忙しい皆様の技術動向チェックの一助になれば幸いです。

紹介テクノロジー一覧

Hibernate

概要

POJO (*1) をベースとした Java 向けの O/R マッピングフレームワーク。 EJB 3.0 に POJO が採用されるなど、Hibernate は EJB の仕様に大きく影響を与えてい ます。 Hibernate は、大きく仕様が変更された EJB よりも実績があると言えるでしょう。

(*1) POJO・・・Plain Old Java Objectの略。 特定のフレームワークやライブラリに依存しない普通の Java オブジェクト。 EJB を批判するために使用された用語。

関連 URL

ここに注目!!

注目している一番の理由は、従来の EJB 2.x の EntityBean より、開発の面で手間が省けることです。EJB による開発では、EntityBean の他に Home インタフェースや、Remoto インタフェースという EJB のフレームワークに依存した定義ファイルを作成する必要があり、コンポーネントベースによる開発が楽になると言われているわりには非常に手間がかかるものでした。一方、Hibernateによる開発では、POJO をベースとしているため、そのような手間は発生しません。

Hibernate での主な作業は、Java クラスとデータベースとのマッピングファイルを記述することくらいです。Hibernate には、HibernateExtensions というツール群が用意されており、マッピングファイルさえ記述すれば、後は、データベーススキーマや Java クラスファイルを自動生成してくれるからです。また、Middlegen というオープンソースのツールを利用すれば、データベーススキーマからマッピングファイルを自動生成することが可能であり、他のツールと連携することによってさまざまな状況に合わせた使い方ができるようになっています。

クエリは、HQL(*2),SQL,クライテリア(*3)と用意されていますが、多くの処理は HQL で事足りるでしょう。データベース独自のクエリを使用したい場合など、HQL で対応できない場合には SQL を使用することになります。

(*2) HQL・・・Hiernate Query Language の略。SQL に類似している。

(*3) クライテリア・・・HQL より進んだ機能。Java オブジェクトを扱うような感覚で、データアクセスが行なえる。

細かい部分においても実開発で役に立ちそうな機能が揃っています。 例えば、Java クラスの自動生成機能では、自動生成する部分と独自コードを 記述する部分を継承を使って 2 つに分離することができます(図1)。また、カスタム 型を指定すれば、生成される Java クラスの属性に永続化用の独自クラスを設定する ことも可能です。

自動生成部分と独自コードの分離
図 1 : 自動生成部分と独自コードの分離

最後に Hibernate 3.0 が、2005 年 3 月 31 日に正式にリリースされました。 さまざまな機能が加えられましたが、最も注目すべきは SQL 機能の充実だと 言えます。クエリー結果のマッピング方法が改良されたことにより、Ver3 では 普通の SQL と同じことが実行できるようになりました。

その一例として、テーブルの幾つかの項目だけを取得するクエリーの発行が 挙げられます。これは開発者に大きな安心感を与えてくれます。 ver2 の段階でも全体的に制約を感じることなく、実用的という印象を受けましたが、 ver3 ではその印象がさらに強くなりました。 SQL 機能の充実が、今後の普及に拍車を掛けるのではないでしょうか。

こんなエンジニアが注目しています

オープンソースで楽をしたいと同時に安心感も求める欲張り系エンジニア

JSON + JSON-RPC

概要

JSON とは JavaScript Object Notation の略で、XML や S 式と同様な汎用的データ表現です。 JavaScript を利用してオブジェクトの構造を表現することに特色があり、オブジェクトのシリアライズ等に利用することが可能です。

JSON-RPC は XML-RPC の JSON 版、 つまり JSON のデータを伝送手段に使う RemoteProcedureCall のプロトコルです。 Python、Java、JavaScript、Ruby 等の言語による実装系が存在します。

関連 URL

ここに注目!!

JSON 単体は利用方法が限られていますが、JSON-RPC の潜在能力はかなり高いと思います。 JSON-RPC の強みは、JavaScript との親和性です。 JSON-RPC クライアントは一般的な HTML と JavaScript で記述することができます。 そのクライアントから直接 JSON-RPC サーバ上のオブジェクトのメソッドを呼び出すことができます。

いままでの Web アプリケーションのような画面遷移を経ずに、 サーバに非同期的にアクセスできるので非常にダイナミックな Web アプリを構築できます。 いわゆる Flash 等のリッチクライアントのように特別なソフトをインストールする必要はありません。

最近は Ajax(Asynchronous JavaScript + XML) が流行しています。 Ajax でも HTML + JavaScript クライアントから、サーバを非同期に呼び出すことにより、リッチなユーザインタフェースを実現します。Google Suggest のような実際のアプリケーションで体感もできます。 しかし Ajax では実装のためのフレームワークに定番と呼べるものが存在せず、開発者はまだまだ色々な部分を作りこむ必要があります。

JSON-RPC の実装系を使えば、Ajax より簡単に非同期 Web ユーザインタフェースを持つクライアントを記述でき、より本質的な部分に力を注げます。 流行の一歩先を行くために、要チェックの技術といえるでしょう。 (JavaScript 版の JSON-RPC の実装系内部では XMLHttpRequest など Ajax 系と同じ技術が利用されているので、これも Ajax の一部といえるかもしれませんが)

こんなエンジニアが注目しています

TBS の深夜ドラマは一年に 3 回くらい同じ奴やってることに気付いた夜更かし

Seasar - DI Container with AOP

概要

純国産の DI (*1) コンテナ。

オブジェクト間の依存性の排除、トランザクション制御、コネクション 管理が普通の Java オブジェクト (POJO (*2)) だけで実現可能。 O/R マッピングツールと組み合わせれば、もう重厚なアプリケーション サーバは必要ありません。 アンチ J2EE で生まれた技術ですが、次世代 J2EE へも大きな影響を 与えています。

(*1) DI・・・Dependency Injection (依存性の注入) の略。 オブジェクト間の依存関係を外部から設定する仕組み。

(*2) POJO・・・Plain Old Java Object の略。 特定のフレームワークやライブラリに依存しない普通の Java オブジェクト。 EJB を批判するために使用された用語。

関連 URL

ここに注目!!

なんと言っても開発が楽になること。 普通の Java オブジェクトを作るだけでよいので、高いツールを買ったり、 ファイルを EAR にまとめてデプロイなんてことは全く必要ありません。 デバッグも Eclipse などのフリーのツールで簡単にでき、 Mock Object (*3) を使って単体テストもさくっと書けます。 作ったオブジェクトは特定のフレームワークに依存せず、 また、アスペクト指向 (*4) 技術を使って、トランザクション制御や ログ出力等の設定を業務ロジックから切り離すことができるので、 オブジェクトの再利用性も高まります。

(*3) Mock Object・・・単体テストで、未実装のインタフェースや 外部リソースにアクセスするオブジェクトの代わりに利用する擬似オブジェクト。

(*4) アスペクト指向・・・横断的関心事 (Cross-Cutting Concern) と呼ばれる複数のオブジェクトに共通な処理を、オブジェクト本来の処理から分離する考え方。

こんなエンジニアが注目しています

やりたいことを簡単にかつ確実に実現したいだけの素直なエンジニア

Avalon(Longhorn)

概要

Avalon とは、次期 Windows(コードネーム:Longhorn)に搭載される下記のような特徴をもった UI 及び描画処理用の API です。

  1. XAML と呼ばれる XML をベースにした UI 記述言語
  2. .NET Framework 風の API (*1)
  3. 画面解像度に依存しない描画
  4. 描画の出力を画面以外のネットワークに対しても行うことが可能

(*1) 既存の Win32 API は関数の羅列で構成されていました。おそらく C 言語からも呼び出せるようにするためではないかと思われます。

関連 URL

ここに注目!!

今、一番注目している理由は、旧来の Win32API や .NET Framework で 作成できる画面と比べて、「Avalon で作れば見た目がこんなにすごくなる!」 ・・・ことではなく、基盤技術に DirectX を利用していることです。

そもそも DirectX とは何かというと、Microsoft から提供されている マルチメディア機能を強化するための API のことです。Windows 標準の API というよりは、標準 API である Win32API をマルチメディア機能面で 補完する役割を担っています。DirectX には、描画・音声・入力機器 (ジョイスティックなど)に関するAPI があり、特に描画に関する部分は DirectX Graphics と呼ばれています。 DirectX はハードウェアを細かく制御することができる低レベル API で 「うまく扱えば」高性能・高品質な描画を行うことができます。

なぜ、この DirectX(DirectX Graphics)が基盤技術に据えられている ことに注目するのかというと、ハードウェア(主にビデオカード)と DirectX の間には密な関係があるからです。昨今のビデオカードの 進歩は目をみはるものがあります。ハードウェアに近い API である DirectX は、当然ビデオカードの仕様と密接な関係にあり、ビデオ カードの進歩とともに発展してきたという歴史があります。 DirectX はハードウェアにある機能が実装されていないと、ソフト ウェアでエミュレートします。(当然、性能・品質は著しく低下します。) ハードウェアが DirectX が要求するある一定の機能を実装すると、 晴れて「DirectX 対応ハードウェア」ということになります。 DirectX API を用いて開発されたソフトウェアを快適に動作させるには この「DirectX 対応ハードウェア」が必要になります。つまり、今は、 DirectX が提示した仕様をどれだけハードウェアが満たしているか、 という点が重要になりつつあるのです。

視点を切り替えて、Avalon の話に戻ります。Avalon は Longhorn 標準の API ですから、Avalon が要求する仕様をハードウェアが満たせないと Longhorn 上で動作するアプリケーションを快適に動作させることは できなくなります。Avalon の恩恵を 100% 受けるためには、「DirectX9 の仕様を満たしたビデオカード(*2)」が必要になるため、ハードウェア メーカは DirectX9 の仕様は満たさなくてはならないと考えるように なります。少し極端な表現をすれば、ソフトウェアの要求を満たすために ハードウェアの仕様を決める傾向が強くなってきたということです(*3)。

(*2) 2003 年頃から登場。Avalon の恩恵を 100% 受ける気がなければ、 それほど高性能なビデオカードは必要ありません。

(*3) もちろん、DirectX の仕様決めにビデオカード開発側の意見は多分に 取り入れられているでしょうから、決して一方的な関係ではないと 考えられます。それに、DirectX だけを視野に入れてハードウェアが 作られているわけではありません。通常、いくつかの規格を視野に入れて ハードウェアは開発されているはずです。

これまでは、OS をアップグレードするときには漠然と CPU パワーとメモリー 容量を確保すれば良かったのですが、これからはハードウェアの選定条件が 複雑化する可能性があります。これは、Avalon の出現によるものです(*4)。 今後の動きに注目です。

(*4) 誤解が無い様に書いておきますが、得られる恩恵も大きいのです。 ハードウェアの支援によって、処理によっては数倍〜数百倍の パフォーマンス向上が見込めます。このパワーを利用して、これまで 考えられなかったような UI も実現するかもしれません。

こんなエンジニアが注目しています

最近の仕事は C# で GDI+ なエンジニア

PMBOK(Project Management Body of Knowledge)

概要

プロジェクトマネジメントを実践する上で必要となる知識を9 つの知識エリアと 5 つのプロセス群として網羅的にまとめた体系。 PMBOK は、プロジェクトマネジメント協会 ( PMI ; Project Management Institute ) が策定し、IEEE で IEEE 1490 - 1998 として規格化されています。 今年 ( 2005 年現在 ) の 1 月に PMBOK 第 3 版が発行されました。

関連 URL

ここに注目!!

PMBOK はいわずと知れたプロジェクトマネジメントのデファクトスタンダード。 プロジェクトマネジメントを実践する上で必要となる知識を9 つの知識エリアと 5 つのプロセス群としてモレなく、ダブりなくまとめられているため、 PMBOK を見ればプロジェクトマネジメントに必要な知識が全て分かります。 でも、それだけが PMBOK がオススメな理由といってしまうのもお粗末なので、 実際のシステム開発に適用する上で、どのような観点から PMBOK が有効か説明しましょう。


1.開発プロセスを PMBOK で補強しよう!

UP や RUP などの重量級の開発プロセスも、アジャイルな開発プロセスも、いざ実践しようとすると、 どうプロジェクトマネジメントすればよいのか判断に迷ってしまうことがあります。 これらの開発プロセスを実践する場合には、PMBOK でプロジェクトマネジメントプロセスを補強しましょう。

PMBOK は、プロジェクトマネジメントで行わなければならないことと、そのために必要な知識を、9 つの知識エリアと 5 つのプロセス群に分けて、漏れなくダブりなく説明しています。PMBOK を使って、開発プロセスをフィットギャップ分析することで、実践的な開発&プロジェクトマネジメントプロセスを作ることができます。

例えば、RUP をフィットギャップ分析すると、「コストマネジメント」、「コミュニケーションマネジメント」、 「調達マネジメント」の説明が不足していることがわかります。

2.第 3 版でより詳しく、より洗練され、より使いやすくなった!

より詳しく

PMBOK 2000 年版ではなかったものの、実際のプロジェクトでは必要なプロセス、インプット、アウトプット、ツールと技法などが追加されました。 例えば、2000 年版では、ステークホルダーのマネジメントや課題管理について何も書かれていませんでした。 第3版では、これらのためのプロセスやツールと技法が追加されています。

より洗練され

PMBOK 2000 年版で分かりにくかった内容が、名称を変更したり、プロセスを別の知識エリアに移動したり、プロセスやツールと技法を複数に分割したりするなどして、整理されました。 例えば、2000 年版では、プロジェクトの立ち上げに関するプロセスが「スコープマネジメント」にあったり、プロジェクトの終結に関するプロセスが「コミュニケーションマネジメント」にあったりと、関連するプロセスが様々な知識エリアで定義されていましたが、第3版では、これらのプロセスが「統合マネジメント」にまとめられました。

より使いやすく

それぞれの知識エリアの説明の初めに、プロセスとデータの関係を整理したプロセスフロー図が追加されていたり、 用語集が 30 ページから 70 ページに増えていたりと、読みやすく理解しやすくなりました。

こんなエンジニアが注目しています

PMBOK も勉強したいけど、ITIL も勉強したい規格マニア

P2M(Project & Program Management)

概要

日本発のプロジェクトマネジメントの知識体系。

PMBOK では「プロジェクト/契約の完遂」の視点が強いですが(もちろん読み方次第ではありますが)、 P2M ではより視野を広げた「ステークホルダに価値を創出する」観点を重視しています。

関連 URL

ここに注目!!

プロジェクト・マネジメントって大変ですよね。 する方もされる方も。 「マネジメント」って結局は、 関わっている人々(ステークホルダ)にまたがる課題を最少化したり最適化することなんです。 対象が複雑だから、うまく行うにはコツが必要になります。 このコツを形式化したパターン集(あるいはパターン言語)で最も有名なのが、 PMI の PMBOK です。

当然ながら PMBOK も万能ではないし、 そこにはいろいろな前提や有効な範囲があります。 特に、ソフトウェア開発プロジェクトはどうしても 「探求型プロジェクト」になってしまいますが、 これがなかなか PMBOK では管理しきれません。 そこで毛色の違った日本発のプロジェクトマネジメントの知識体系、 PMCC のプロジェクト & プログラム・マネジメント 略して P2M に目 をつけています。


P2M を PMBOK と比べると、以下の 3 つの違いが挙げられます。

  1. 「プログラム」も扱う程に視野が広い。
  2. 遂行プロセスよりは問題の押さえどころを重視している。
  3. ナレッジ・マネジメントに重きが置かれている。

順番にみていきましょう。

1. 「プログラム」も扱う程に視野が広い。

「何が価値があることなのか、クライアントにも明確には分からない。」 こういった状況が当たり前に存在するこの業界では、 最後の納品までスコープの調整活動を続けることもしばしば。 クライアント側にはコントロールできない制約が次々と現れるのも日常茶飯事。 オキャクサンのいうことが変わるのは、ある程度しょうがありません。

そんなときに拠り所となる基準は、当初求められたプロジェクトの外にあったりします。 「なぜプロジェクトが立ち上げられたか」や 「ものを作るプロジェクトの完遂後、どうしていくか」の大きな構想の方は安定してるかもしれません。 プロジェクトがその大きな構想に合致していて管理ができるなら、 途中のやり方はいくら変えてもいいでしょう。 ですから仕事の範囲があくまでプロジェクトではあっても、 オーバリーチして背景を押さえる P2M のプログラム運営の体系が役に立ってきます。 「客の欲しがる物ではなく、必要としている物を作る」提案型の SE の仕事には大事な事ですね。

2. 遂行プロセスよりは問題の押さえどころを重視している。

PMBOK ガイドを見ると、 各知識領域のプロセスは「入力・ツール/技法・出力」の組でまとめられているのが分かります。 これは、ソフトウェア・エンジニアならよく知っている 構造化モデルの IPO(Input / Process / Output) フレームワークですね。 勿論、使える状況ならば、バンバン使って頂いて結構です。 でも、入力が本質的に得られない状況ではどうでしょう? 根性で入力を作り出しますか? それもプロらしい 1 つの方法ですが、 もしかしたら違った前提を持ったフレームワークの方が効率いいかもしれません。

解決領域ではなくて、問題領域に根ざしていた体系の方が、応用は利くはずです。 P2M では IPO のかわりに、6 つの要素でテンプレートを揃えてます。 数が多いのがタマにキズですが、 抽象度を上げて「目的」と「環境変化制約条件」が明示されているのが素晴らしい。 これなら手に入るものを入力とした、自前の手段を作り出す足がかりになります。 ありがちな制約を押さえた上で目的を果たすことができるでしょう。

3. ナレッジ・マネジメントに重きが置かれている。

ではそれらの知識でもって、例えば要求みたいな不明確な事柄を、任命 された担当が孤軍奮闘東奔西走して解決できるでしょうか? とてもムリでしょう。 そこで、「3 人寄れば文殊の知恵」の原理を活用したい。 これがナレッジ・マネジメントです。

ただし、巷で誤解されている様な、情報/知識の蓄積(ストック/文書化)とは違います。 情報/知識の流量(フロー/コミュニケーション)を確保するのが本質です。 当然、必要ならば蓄積によるバッファで流量の健全性を確保します。 ソフトウェア業界の人ならここ最近よく聞く論調と符合するのは、偶然ではありません。なにしろ「SECI サイクル」「場」といった理論背景がアジャイル系のプロセスと共通なんですから。 人と人の間の知識交換をいかに健全に保つか、 価値を生む知識創出のスパイラルをどう確保するか。 これがあらゆるテーマに渡って押さえられています。


さて、PMBOK との比較でここまで書いてきました。 別に PMBOK を批判したいわけではなくて、 補完する物として P2M の体系に期待したいのです。 やっぱり PMBOK は便利ですから。

最後に、期待に当たっての P2M の懸念事項を挙げておきます。

P2M 標準ガイドの執筆にはわりとアカデミックな面々が多く参画しているせいもあってか、抽象的な記述が多いです。 受け付けない読者も沢山いるでしょう。 まだ初版が発行されてから歳が浅いので、 更に改訂を待てば具体的な記述も増えるかもしれません。 でも、噛めば噛むほど味が出るコイツは、すでに役立つ域には達しています。 深い含蓄をいぢり倒して、しばらく独りでコッソリ得してやろうと思います。

こんなエンジニアが注目しています

PMBOK は固すぎて、なにか物足りさを感じてしまったエンジニア

リアル・オプション

概要

金融工学から生まれたリスク管理手法。

「手を打たない」ことがリスクに 対するもっとも賢い選択という状況があります。 つまり不確定性が高すぎる場合、状況が変わるまで身を伏して待つとい う選択肢(オプション)の確保を考慮するのです。状況毎に対策を立案し、 今実施するのと後で実施する場合の損得を計算すると、あーら不思議、 納得して状況を放置できます。

「お金」という抽象的なものではなくて、リアルな「成果物」を得る選 択肢なので、「リアル・オプション」です。

ここに注目!!

リスク管理の基本に「余分な仕事をする」というのがあります。 語弊のない云い方をすれば、「転ばぬ先の杖」ですね。 「泥縄」の方が結果的に仕事が多くなるので、 リスクに先回りして手を打っておくのです。 勿論全部に対処してたらキリがありませんので、 重大なものから順に優先度をつけることになります。 優先度付けの常套手段としては、期待値を利用する方法があります。 起きてしまった時に想定できる損害と、起きる確率をかけるのです。 1 つ 1 つのリスクは大概、起きるか起きないか 2 つに 1 つ、 丸ごと損害を被るか全く無傷か 2 つに 1 つでしょう。 期待値と同じ損害になるものなんて、きっとないんです。 でも集まれば、バラツキが均されて結果として同じものになるので、 損害の期待値の大きさが対処の優先度になります。

損害の大きさを見積もるのは無茶じゃないし、 その時点での確率も見積もれるでしょう。 難しい? いいんです、確率なんだから「テキトー」で ! さて、これで計画を立案・実行すればリスクは最小化されることになります。

しかし、コストは最小でしょうか? 人間ですから、手を抜けるものなら、作業を一つでもサボりたいですよね。 もちろん、上に書いたことに嘘はありません。 でも「テキトー」にしか出せない確率には悪魔が宿ります。 時間が経つと状況が変わって/見えてきて、どんどん正確になってきます。 変わる/見える時期が分かるとしたら、それまではリスク対処作業をサボりたいですよね。やらなくていいかもしれないんですから。

実は皆様もやってるんではないでしょうか? それをアドホックではなくて、エンジニアリングに乗せましょう。 どうせなら、納得ずくで楽したいですからね。


金融工学には「オプション」という考え方があります。 例を挙げれば、火災保険がありますね。 契約料という「プレミアム」を支払うことで、 火事が起きた時に損害を諦めるか保険会社に請求する選択肢「オプション」が手に入るアレです。(まあ、この場合の選択肢「オプション」は確実に行使するわけですけど。)

それでは、我々ソフト屋の場合、「プレミアム」「オプション」ってなんでしょうか? ここまで、リスク・ヘッジをサボることから話を始めてきましたが、 サボるにしても、完全放置はまずいですよね。 最低限の準備だけはしておかないと。 「後の先」を取れる様に、構えはしておかないと。 そう、構えがあると、後で本格的な回避活動をする選択肢が出てくるのです。 この「構え」のための工数や労力が「プレミアム」、後で行う回避活動が「オプション」なのです。 このような、 「お金の請求」といった抽象的なものでなくて、 より具体的な「行動」というリアルな選択肢を「リアル・オプション」といいます。


「実践するとなると大変そうだなぁ。」そう思われる方もいらっしゃるでしょう。 (なにせ私自身もそう思っています。) ですから、私の場合、リスク・ヘッジ策そのものが大変な時にだけ、きっちり計算します。 明らかな時は、当然サボります。

実は、イテレーティブな開発も同じ原理だったりします。 恣意的に状況が早く見えるように、早い段階で後工程に手を着けるのはそういうことなのです。

こんなエンジニアが注目しています

期待値だけでリスク管理をするのに限界を感じつつあるソフト屋

Software Factories

概要

「現在のソフトウェア開発は職人芸・個人技に頼りすぎている。 ソフトウェア開発も自動車に代表される通常の工業製品同様、 もっともっと工業化・自動化していこうよ!!」 というコンセプトのもと、 Microsoft で Visual Studio を開発しているチームが提唱・具現化している開発方法論。

関連 URL

ここに注目!!

「ソフトウェア開発を工業化、自動化しましょうよ。」という説明だけ聞くと、 「んー、Microsoft も MDA と同じことを目指しているのかな?」と思われる方もいらっしゃるでしょう。

確かに、Software Factories ではソフトウェア開発を工業化するための 1 手段として モデル駆動開発(MDD)も利用します。 しかし、 MDD だけでなく、パターン、フレームワーク、プロダクトライン、 そして何よりもこれらの考え方をサポートするためのツール側の強力なサポートも Software Factories のスコープに入っています。 これに対し、OMG の MDA は、 MDD に関係する仕様の標準化に焦点を当てているだけにすぎません。 そう、MDA が MDD のみを扱うのに対し、 Software Factories では、MDD は 1 つのトピックに過ぎないのです。 Software Factories は、ソフトウェア開発を向上させる技術・考え方なら何でも積極的に取り入れる包括的なアプローチといえます。

※ ちなみに、Software Factories では、 MDA とは異なり、UML ではなく Domain Specific Language(DSL) を利用してモデルを記述します。 これは、 「UML は議論や考えをまとめるためにホワイトボードやメモ等に書く用途には有用である。 しかし、モデルからコードを生成するための言語としては必ずしも適切ではない。」 という Microsoft の判断に基づいています。

また、 Software Factories の最大の特徴として、 プロダクトラインソフトウェア工学(PLSE)をその中核に据えている点が挙げられます。 何も Software Factories に限った話ではないのですが、 プロダクトの可変性、共通性という視点を軸に長期的視野で開発を進めていく PLSE のアプローチは、 似たようなシステムなのにわざわざ 1 から作り直したり、 既存のソースコードをコピペで繋ぎ合わせて開発を進めたりしている(そして、加速度的に破綻していく)、 現在の開発スタイルを大きく変えてくれるもの、と期待しています。

残念ながら日本語で参照できる情報はまだ少ない Software Factories ではありますが、 「ここ 10〜15 年間くらいのソフトウェア工学のあらゆる成果を利用して、 ソフトウェア開発を今すぐ楽にしようよ!!」 という Microsoft からの提案である、と私は捉えています。 もちろん、Sogtware Factories で目指している世界の全てが、すぐに実現されるわけではないでしょうが、 1 エンジニアとして、今よりももっと「楽しく」開発できるようになるのではないか、とワクワクしながらその動向に着目しています。

また、この Microsoft の動向が Java 陣営や OMG 等の他の団体の動きに良い影響を与えるのではないか、と別の効果も期待しています。 (実はこちらの期待の方が大きかったりするのは秘密です。)

こんなエンジニアが注目しています

仕様の乱立は困るけど、切磋琢磨して業界全体が良くなっていくのは大歓迎の中立派

Eclipse GMT プロジェクト

概要

Eclipse の Generative Model Transformer プロジェクト。 MDA の実現に必要なツールを構築・連携させよう、という目標を掲げ、活発に活動しています。 その成果は、OMG が現在策定中の MDA 関連仕様に影響を与えるかも !?

関連 URL

ここに注目!!

現在 MDA を実践しているのはごく一部の先進的な企業・集団だけで、 一般の開発で本格的に実践できる段階には、残念ながらまだ至っていません。 「ソースコードじゃなくて、モデルを中心に開発しようよ !!」 というコンセプトには多くの人・企業が賛同しているにも関わらず、 なぜ MDA はなかなか実用の域に達しないのでしょうか?

勿論、この問いに対する答えは人によって千差万別で、絶対的な解などありません。 ただ、私自身は以下の 2 つの状況が MDA 普及の足を大きく引っ張っているのではないか、と考えています。

  1. 本格的な MDA ツールは非常に高価であり、気軽に試用・評価できない。
  2. 関連仕様がまだフィックスしきっていないため、MDA ツール間の連携が望めない。

こういった状況の中で、 Eclipse GMT プロジェクトで無償のモデルコンパイラが開発されれば、 MDA の効果をお金を払うことなく気軽に試せるようになり、 "MDA の普及を妨げている要因 (1)" に一石を投じることができるのではないでしょうか。 さらに試用の結果、そのパフォーマンスが実用に耐えうるね☆ということになれば、 そのまま実開発へ適用 !! なんてこともあるかもしれません。

また、このプロジェクトを進めていく過程で得られた知見が、 現在 OMG が策定している QVT という仕様にもフィードバックされることになっているので、 "MDA の普及を妨げている要因 (2)" を多少なりとも解消してくれます。 特に、他の MDA ツールとは異なり、 GMT プロジェクトにはベンダーの思惑が(直接的には)入っていないので、 MDA ツールの連携を促進させる起爆剤になる可能性も持っています。

さらに、他の Eclipse プロジェクトと同様、 その成果はオープンソースとして公開されるので、、 コードを覗けば、MDA がどのように実現されているのか、誰でも知ることができます。 これにより、GMT プロジェクトの成果をベースとした MDA ツールが多数登場する、なんて薔薇色の未来がひょっとしたら来るかもしれません。 (私の妄想でしょうか ^ ^;)

このように、MDA を実用段階までひっぱっていく上で、 GMT プロジェクトは重要な役割を担っているため、その動向からは目を離せません。

こんなエンジニアが注目しています

ソフトウェア開発にまつわる単調な作業は極力自動化してやりたい怠惰系エンジニア



© 2005 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP