「設計」や「構築」よりも重宝されるスキル：The Rational Edge（2/3 ページ）

[Gary Cernosek，＠IT]

新しいITの現実に対応したアーキテクチャ管理

　IBMのRationalチームは現在、分析、設計、および構築と従来呼ばれていたものを拡張し、そこにアーキテクチャ管理を組み入れようとしている。これは、その原動力となる要件や、それをインプリメントするコードが変化する中でソフトウェアアーキテクチャを管理する専門分野だ。この専門分野では、会社独自の進化するビジネスプロセスやモデルと併せてアーキテクチャの整合性を保証する必要がある。アーキテクチャ管理はソフトウェアアーキテクチャ重視からの根本的転換を反映しており、そこでは設計が業務内容を決めるのではなく、業務内容が設計を決めている。

アーキテクチャ管理の必要性はどこから発生するのか？

　アーキテクチャ管理は、ソフトウェア開発を現在変えつつある3つの力によって構成されている。SOA、地域分散型開発（GDD）、そしてアウトソーシングとオフショアリングだ。そこで、アーキテクチャ管理が新しいソフトウェアアプリケーションの設計、選定、および導入にとって重要になりつつある理由を見極めるべく、これらの原動力を1つずつ見てみよう。

SOAが約束するもの

　企業が人材、プロセス、および技術を最大限効率的に利用するのにサービス指向アーキテクチャ（SOA）がいかに役立つかという話は出尽くした感がある。理論的にいえば、ITが身軽で競争力と効率の高い状態を維持するための手段は、SOAに対する各社のアプローチが体現している。そのどれもが、顧客中心の考えを目指したものだ。実際に機能するSOAは、既存アプリケーションの再利用、あるいはサービスモデルによる再利用を目指すアプリケーションをベースにし、ソフトウェア開発者がゼロからアプリケーションを設計および開発する負担を緩和する。データベーススキーマ、OS、サーバプラットフォーム、およびプログラミング言語に関してこれまでにくだされてきた決定は元のまま残っており、組み合わせを見直すことで今後も生き残ることができる。エンジニアがファイルやコードモジュール単位という基本レベルで作業をすることはなくなる。むしろ、抽象概念の高いレベルで作業を行い、提案しているソフトウェアの事業価値に取り組みむ。このような理由から、SOA経由でサービスへと変化したアプリケーションは、保管し、容易に見つけ出し、組み替え、新しいビジネスアプリケーションを素早く開発できるよう構造化されている。

　しかし、SOAが描くビジョンを実現するのは困難な作業だ。サービスを再利用するためには、これらを適切な形で持っておく必要があることは明らかだ。だが、まだ存在しないものを再利用するのは不可能だ。より端的にいえば、「サービス」を行き当たりばったりで構築するようなことはできない。これらは、所定の標準、プロトコル、そしてインタフェースに従って構築する必要がある。そのことが、結局はこれらを「標準」や「再利用可能」にするのだ。アーキテクチャ管理サービスが極めて重要な目的を果たすのが、まさしくこの部分だ。サービスは、サービス指向アーキテクチャ形式で再利用できるよう構築する必要がある。

地域分散型開発（GDD）の現実

　ソフトウェアの開発を行う組織が自社の開発スタッフを地理的に離れた場所に分散することは、例外的なことではなく普通のことになった。GDDの多くは、合併や買収がきっかけで発生する。急に引っ越しを行って人材を移動させるようなことや、拠点を閉鎖したり統合するようなことは企業にはできない。在宅勤務やリモートアクセス技術が利用できるため、スタッフを別々の場所に配備しておく方が経済的かつ現実的というのが企業の考えだ。

　IBM のRational部隊はその好例の1つだ。開発センター（IBMではラボと呼ぶ）は幅広く分散しており、社内のソフトウェア開発者全員が同じ製品の同じバージョンの開発を行う場合もある。この新しいスタイルの人員配置からは「開発者が各地に分散している場合は『アーキテクチャ』をどのように実現するのか？」という疑問が浮かんでくる。さらに重要なこととして、「アーキテクチャの整合性はどのように取るのか？」という疑問もある。誰かが「アーキテクチャを見せてほしい」といってきたときの回答は、それと関連したインプリメンテーションと一致する必要がある。そもそも、ビジネスの観点から見た場合、アーキテクチャはその基となった最新の業務要件と合致している必要がある。要件、設計、そしてインプリメンテーションを合致させることは常に課題だったが、 GDDではこれが一段と難しくなる。

アウトソーシングとオフショアリングのビジネス

　多くの企業は何らかの形でアウトソーシングやオフショアリングを行っている。これらは特殊な形態のGDDで、出資する組織内部ではなく外部に開発が分散しており、距離的に離れた場合が多い。極端な（そして、まれな）一例として、ITのすべてのニーズをアウトソーシングする顧客がいる。例えば、この会社はオンタリオに本社があるが、インドのバンガロールに拠点があって、そこで同社のIT機能すべてを提供している。本社もビジネスのモデリング作業を行うが、インドの請負業者がすべてのアーキテクチャ構築、すべての設計、すべてのコーディング、そしてすべてのテストを行っている。

　IBM のRationalが予想するもっと一般的なシナリオとしては、要件とアーキテクチャ（設計と構築）は社内で引き続き行うが、「コア部分」のインプリメンテーションはアウトソーシングするような顧客がいる。このようなタイプの顧客は、自社の業務要件と、これをどのように設計に転換するかを細かく把握することを希望もしくは必要としているが、幅広いインプリメンテーション作業の人件費が安いことも動機になる。

　このシナリオでは、アーキテクチャがある程度の「事実」あるいは正確さをもってインプリメントされるが、実際にはこれが完全なものになることはない。インプリメンテーションは、必然であれ偶然であれ設計から逸脱することは避けられず、アーキテクチャもある程度劣化することになる。GDDであれ何であれ、アーキテクチャの劣化はどのようなシナリオでも起こり得る（例えば、同じ場所に配置され、インプリメンテーションチームが隣の部屋や階下にいても体験することはある）。

　前述のように、GDDは難しいが、アウトソーシングはさらに難しい。これは、会社が異なり、時間帯が異なり、コミュニケーションや言葉の壁があるためだ。この例では、アウトソーシング先の会社がコードを書くと、これが顧客のところに戻って評価が行われる。ここで考えるのが、「請負業者は書かれたとおりにアーキテクチャをインプリメントしたか？」という根本的な問題だ。たぶん、「しなかった」という答えになることはある程度避けられない。

　ここが課題だ。アーキテクチャ管理は、ソフトウェアアーキテクトが「現況のアーキテクチャ」をオリジナルの設計、そして最終的には、そもそもの取り組みの要因となった企業のニーズと照らし合わせて評価するのを支援する必要がある。比較を行い、違いを探し、そして最後にこれらの違いを導入前に調整する。これがアーキテクチャ管理の中核にある目的だ。