システムベンダなどが、自ら仮想マシン環境を開発する動きが広がっている。これを追う新連載の第1回として、NECにおける自社製仮想マシン環境開発に関する戦略を取り上げる インテルが新しいItanium2プロセッサやXeonプロセッサに搭載した「インテルVirtualization Technology」（VT）や、AMDがOpteronプロセッサに搭載した「AMD Virtualization」は、ハードウェアレベルで仮想化をアシストする機能だ。これらのプロセッサによる仮想化支援技術の登場は、注目を浴びつつある仮想マシンのさらなる普及、発展を強力に後押しすることとなるだろう。 国内のハードウェアベンダも相次いで仮想マシンの提供を開始あるいは表明している。本連載では、さまざまなプレイヤーによる仮想マシン環境への取り組みについて、その狙いや方向性を検証する。第1回としては、2007年の提供に向け、

2年ほど前から耳にするようになった「アスペクト指向」も最近ようやく広まってきた。この連載では「アスペクト指向とは何か？」というところから始め、AspectJやJBossAOPなどを用いたAOPの実装を紹介していく。 関心事の分離とは？ アスペクト指向の話には必ずといっていいほど「SOC」という言葉が登場する。このSOCは「Separation Of Concerns」の略であり、一般的には「関心事の分離」と訳されている。アスペクト指向を理解するためには「SOC」の概念を理解することが重要である。ここで、「また新しい3文字略語か」と顔をしかめて記事を読むのをやめてしまう読者がおられるかもしれないが、少し待ってほしい。このSOCは決して新しいキーワードなどではない。SOCとは、1960年代から1970年代にかけてのソフトウェア工学の黎明（れいめい）期に活躍し、「構造化プログラミング」を提唱した

前回「最低10年使える業務アプリケーション（前編）」は数年間アプリケーションを保持し運用し続けるためには多くの問題がある点を見てきた。今回は後編として、それらの原因と解決の方策を探り、現代のアプリケーションは長期運用に耐えるのかを考えたい。 動かなくなるカラクリ 前回「最低10年使える業務アプリケーション（前編）」、数年前に構築されたJ2EEアプリケーションが新しい環境で動作せず、企業担当者が怒りと悩みで苦しんでいる例をご紹介した。筆者はそこで、意外にも多くのアプリケーションで共通に持つ悩みを垣間見ることができた。 どういうことかというと、筆者が先の顧客に対し現象を調査したところ、当然ながら古いJDKのAPIとその挙動に依存して動作している個所、および古いJDKでしか動作しないライブラリやオープンソースが非常に多く見られ、さらに一部ではJ2EEの規約に違反していたため、新しいJDKやアプリ

使い捨ての業務アプリケーション ここ10年、いわゆるオープン系開発が主流になってきたころからだろうか、コンピュータ関連の急激な技術革新（という名の新製品ラッシュ）により、その上で動くアプリケーションはひたすら翻弄（ほんろう）され続けている。 例えば、たった10年間さかのぼっただけで、Windows 3.1の16ビットアプリケーション、およびWindows 95、Windows NT 3.51の初期型32ビットアプリケーションが混在する世界だ。その時代から多くのOS、言語が誕生し、忘れられ、淘汰（とうた）されている。 あまり知られていない業務用ハードウェア・ソフトウェアの世界はさておき、読者の方にもなじみ深いWindows上で動作する業務アプリケーションであれば、（1）.NET登場以前のVisual Studioなどで作成したWin32アプリケーション、（2）PerlやPHPなどオープンソー

前回（「口に出す前に考える、『システムって何？』」）で紹介した「逆システム学」は、経済や生物にとって重要なのは「多重で階層的な、開かれたフィードバック制御」なのであって、要素還元論でも全体的原理主義でもないのだ、という話だった。 個が最適に動くから全体としてうまく動くのではない。システム全体が個を制御するのでもない。個とシステムの間に「多重で階層的な、開かれたフィードバック制御」という領域があり、それこそが逆にシステムを形作っているのである。そしてそれは多分ソフトウェア開発でも同じであろうと考えた。でも正直なところ、これだけじゃあ、どういうソフトウェアを開発すればいいのかよく分からない。そこでこの問題をもう少し掘り下げて考えてみることにした。 例えば、典型的なウォーターフォール型開発プロセスでは、プロジェクトを駆動するのはプロジェクト初期に立てた要求仕様（何を作るか）とプロジェクト計画（ど

われわれは日常的にたやすくシステムという言葉を使ってしまうけれど、システムって何だ？ システムズ・エンジニアって誰だ？ 「最近システムがよく落ちるんで困るっすよ」ってどーゆーことだ？。 システムとは相互作用する複数の要素の集合。だから太陽系もシステムだし、会社もシステムだし、計算機もシステムだ。仏教的にはあらゆるモノはほかのモノとの相互作用においてのみ存在するわけだから、（仏教的世界においては）あらゆるモノはシステムということになる。とはいっても、例えば地球、月、太陽というたった3つのモノの（古典）力学的相互作用にさえ、厳密な一般解はないといわれているくらいで、カンタンではないのもシステムとゆーやつの特徴だ。 この複雑で厄介なシステムを「エンジニアリング」的に相手にして、飯を食っているのがわれわれシステムズ・エンジニアである。じゃあ、こんなものをどうやって相手にすればよいか。大きく分けて2

ソフトウェア開発の効率性を考えていると、いつかは必ず人の問題に突き当たる。プロジェクトチームという開発者の集合はどのように形作られ、どのように動いていくものなのだろうか。そこには必ず何らかの機構（メカニズム）があるはずだ。（＠IT編集部） アーキテクチャといえば、普通はプロダクトの、あるいはソフトウェアのアーキテクチャを思い浮かべるわけだけれど、システムやソフトウェアを作っていく過程ではプロジェクトのアーキテクチャ、つまり開発に主体的にかかわっている人たちの集合がどのように形作られるかも、とても重要な要素になる。 なんでこんなことをいい始めたかというと、たまたま「フューチャー・オブ・ワーク」を読んだからなのだ。なんで、こんな本を読んだかというと、 著者のマローンは米マサチューセッツ工科大学で「The MIT Process Handbook Project」［注］というプロジェクトをやって

本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。（＠IT編集部） 生産性向上のメカニズム ソフトウェア開発における「生産性」とは何か。厳密に定義するのは難しい。生産性とは基本的には「あるアウトプットを得るのにどれだけのコストをかけたか」という尺度だ。さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが、じゃあ代わりに何を使えばいいのかはいまだにはっきりしない。ユースケースやストーリーで測る考え方もある。そんなものは存在しないという意見すらある。 そういう場合には視点を1レベル上げて考えてみよう。つまり、ソフトウェア開発だけ考えているから分

ソフトウェアアーキテクチャって何なの？（後編）：The Rational Edge（1/2 ページ） 前編ではソフトウェアアーキテクチャの定義を詳細に解説した。わかっているようで実は意外とあいまいなままだったソフトウェアアーキテクチャの本質に少しは迫れたと思う。後編ではソフトウェアアーキテクチャの構造をさらに掘り下げる。 ■アーキテクチャは論理的根拠に基づく判断を具体化する アーキテクチャで重要な側面は、最終結果だけでも、アーキテクチャ自身でもなく、なぜそのようになるのかという論理的根拠だ。従って、そのアーキテクチャに結び付いた判断と、その判断の論理的根拠を必ず文書化するよう検討することが重要だ。 この情報は多くの利害関係者、特にそれがシステムを保守する立場にあるような場合に関係してくる。この情報は、下された判断に結び付いた論理的根拠を修正しなくてはならない場合、不要な追跡作業を繰り返す必

ソフトウェアアーキテクチャって何なの？（前編）：The Rational Edge（3/3 ページ） アーキテクチャが構造を定義する 「アーキテクチャ」とは何か、と誰かに説明を求めると、10人中9人は何らかの形で構造に言及する。建築や、橋などの各種土木工事との関係が語られる。これらには、動作、目的への適合性、そして見栄えまで、ほかにも特性はあるが、最も聞き慣れていて、最も頻繁に言及されるのが構造上の特性だ。 従って、誰かに開発中のソフトウェアシステムのアーキテクチャを説明するよう求めると、アーキテクチャレイヤ、コンポーネント、あるいはディストリビューションノードなど、システムの構造面を示す図を見せられることになる。実際、構造はアーキテクチャにとって絶対欠かせない特性だ。アーキテクチャにおける構造の部分は、それ自身を見れば一目瞭然であり、その結果、アーキテクチャの大半の定義は故意に漠然として

ソフトウェアアーキテクチャって何なの？（前編）：The Rational Edge（1/3 ページ） The Rational Edgeより：ソフトウェアアーキテクチャという比較的新しい分野について概説する。今回はシリーズの第1弾という位置付け。この分野のキーワードを説明し、優れたデザインのアーキテクチャが、導入された環境にどのように寄与するのかを探っていく。 ソフトウェアへの依存度が高まっていることに疑問の余地はない。ソフトウェアは、複雑な航空管制システムだけでなく、かなり普及した携帯電話にも絶対欠かせない要素だ。実際、eBayやAmazonといった企業など、われわれが当然のように思っている多くの技術革新は、ソフトウェアがなければ存在していなかった。金融、小売り、公営企業といった従来の組織でさえも、ソフトウェアに大きく依存しているのだ。現代においては、ソフトウェアビジネスに全く関与してい

アーキテクトにはソフトウェア開発プロセスの理解が必要 アーキテクトには、ソフトウェア開発プロセスに対する正しい認識が必要だ。このプロセスによって、チームメンバー全員の良好な協力が保証されるからだ。優れたプロセスは、関係する役割、着手している作業、作成した成果物、そして役割間の引き継ぎ場所を明確にしている。アーキテクトはチームメンバーの多くと毎日やりとりするため、アーキテクトには自分たちの役割と責任を理解することが重要になる。開発チームは毎日アーキテクトからの指示を仰ぎ、その方法まで聞いてくることも多い。従って、アーキテクトの役割とプロジェクトマネジャーの役割との間には明らかに重複部分が存在する。 アーキテクトにはビジネスドメインの知識が必要 アーキテクトは、ソフトウェア開発について把握するだけでなくビジネスドメインも理解することが非常に望ましい（必須だとの意見もある）。 ［ドメインとは］そ

The Rational Edgeより：もし、ソフトウェアプロジェクトのマネジャーが映画業界用語でいう（作業完了の責任者である）プロデューサーならば、ソフトウェアアーキテクトは（作業を成功させ、最終的に利害関係者のニーズも満たす立場にある）監督だといえる。4回シリーズの2回目となる本稿では、ソフトウェアアーキテクトの役割について解説する。 今回は、ソフトウェアアーキテクチャを説明する4回シリーズの第2回目（第1回目は「ソフトウェアアーキテクチャって何なの？」を参照）となる。第1回目ではアーキテクチャとは何かを明確にした。そこで、今回はアーキテクチャの作成責任者であるアーキテクトについて考える。アーキテクトの役割はおそらく、どのソフトウェア開発プロジェクトにおいても最もその手腕を問われるものだろう。アーキテクトはプロジェクトの技術責任者であり、最終的にはプロジェクトの成否について技術面の責任