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

[Gary Cernosek，＠IT]

アーキテクチャ管理はどのような影響を与えるのか？

　アーキテクチャ管理の原理が成果をもたらすと、今日における企業ITの管理手法に変化が起きてくる。アーキテクチャ管理の専門分野はビジネスの原動力に重点を置き、そのため技術の高いレベルでの抽象化を活用することから、アプリケーション開発プロジェクトのライフサイクルに携わるスタッフの中で「左シフト」が出てくる。つまり、開発の各段階における役割自体はそのまま変わらないが、これらの役割を現在担っている人々は左に動く。従って、プログラマーだった人は設計者、設計者だった人はアーキテクト、アーキテクトだった人はアナリストやエンタープライズレベルのアーキテクトへとそれぞれ変化していく。

　本質的に起こっているのは、「エンタープライズアーキテクチャ」と呼ばれるものの熟成だ。ソフトウェアアーキテクチャ管理（Rationalが主に使う定義）がうまくなれば、それが結果的には、一部の人材、時間、リソース、そしてスタッフをソフトウェアアーキテクチャ管理より上流にシフトさせていくことになる。つまり、全社レベルのアーキテクチャを構成する、これら以外のものをすべて管理することだ。

　ソフトウェアアーキテクチャの管理がうまくなれば、異種スタンドアロンモデリングツールからの情報が統合され、統一された手法でこれらすべての情報にアクセスできるよう、ハードウェア、データ、そして運用環境と一緒にソフトウェアも投入し、これらすべてをコーディネートされたツールやシステムでまとめられる。

　例えば、「A42アーキテクチャモジュールのバージョン6が搭載された社内のコンピュータすべてと、これに接続されたデータベースすべてを教えてほしい」といったクエリを行う場合を考えてみたい。今日、このような質問に答えるのは非常に難しい。これは完全な手作業であり、データベースの得意なツール、ソフトウェアモジュールの得意なツール、ハードウェアと導入の得意なツールが必要だが、このようなクエリが要求するプロセスを自動化するワークフローにまとめられるツールは、単独のものも組み合わせたものも存在しない。

アーキテクチャ管理からはどのような機会が生まれるか？

　アーキテクチャ管理は、ソフトウェアの設計や開発の手法と、要件、設計、およびコーディング全体の変更を管理する手法を改善できるチャンスを提供する。重点をライフサイクルのさらに「左」に移すことで、ITスタッフを当面の業務要件に近づけ、これにもっと時間を使えるようにできる。また、このようにすることで、ソフトウェア納入プロセス全体の品質と生産性を大幅に改善できることになる。

　しかし、これらのメリットを十分に理解するには、今日の大半の組織が抱える課題を認識する必要がある。基本的に、アーキテクチャ管理を実行に移すに当たっては2つの課題がある。それらが、「ITの管理職とスタッフの教育と啓もう（けいもう）」と、「同ソフトウェア納入ライフサイクルのフロントエンドで必要とされる一段と堅牢な自動化」だ。

教育と啓もう

　アーキテクチャ管理とは、分析、設計、および構築に関する従来の概念を広範に拡張したものだが、そこには、ITの現場全体からの抵抗が予想されるほどの違いが存在する。ソフトウェアの開発と納入は何年も前から行われてきており、開発組織にはその作業を行うためのシステムもある。これらのシステムを変更する提案は決して軽視してはならず、提案が採用されても、変更が難しいのが普通だ。変更の必要などのような状況でも同じだが、選定を成功させる重要な要素は教育と情報だ。

　アーキテクチャ管理の理解と認識に必要な教育は、この学問が改善を必要とし、さほど新しいものではないことを受け入れることから始まる。アーキテクチャは、常に設計者と開発者が管理する必要があったが、SOA、GDD、およびアウトソーシングなど、前述した原動力となる要因が効力を発揮し始める中、これまで常に行われてきた進め方のスケーラビリティが危うくなってきた。1週間で働ける時間は限られており、採用できる人の数も限られており、回避策の策定に向けて彼らを教育する時間も限られている。教育は、スタッフ、時間、そして社員の抱えるストレスの傾向までを開発グループに厳しく詳細に調査させることから始めるのも良いかもしれない。

堅牢な自動化：フロントエンドの一新

　過去の手法より優れたアーキテクチャ管理方法に対する一般的なニーズを認識したら、正しい選択は自然に出てくる。ソフトウェア業界には、市場を正反対の方向に向かわせている2つの傾向がある。1つは、「低賃金労働力」（つまり、アウトソーシング）の利用であり、もう1つが最新ツール類による超高度な自動化の利用だ。この点で、今日われわれが理解している開発者は、かなり様子が異なるようになる。高価なツールを購入して新技術を教え込むより、破格の値段でアウトソーシングした労働力に古い方法でコードを書かせた方が組織には安上がりなため、開発者はアウトソーシング環境での作業を選ぶか、あるいは後援組織から要求される作業を前倒しして進めることになる。重要な部分が自然に分かれることで、バックエンドの作業はアウトソーシングされるか自動化されるかのいずれかとなっていく。

　アウトソーシングの流れは分かる。ツールなどの面では、フロントエンドのライフサイクルツールが非常にパワフルであるため、今日のような核となる部分のインプリメンテーション作業を低コストでローエンドのところにアウトソーシングする必要性が徐々になくなっていくことは想像できる。フロントエンドのライフサイクルツール類が改良されれば、その作業を手作業で行うインプリメンテーションチームにアウトソースする機会は最小限に抑えられる。つまり、そこには両極端となる2つのものがある。逆さまにされた砂時計のように、砂はいずれかの方向に落ちていき、その間には狭い接点しかない。ここ数年のIT業界がそうであったように、一連の作業は労働力の安い方へと流れていく。アウトソーシング労働市場にビジネス上のメリットがない企業は、もう一方へと動いていく。つまり、彼らはアーキテクチャが最も重要なビジネスのフロントエンドを自動化するツールを開発するようになる。

---

　本稿は、ソフトウェア納入の周辺で起こりつつある劇的な変化に気づいたIT部門担当バイスプレジデントの話を引き合いに出すことから始まった。これらの傾向が、技術に対するニーズ、ITスタッフの構成方法、必要なツールの種類、そしてビジネスモデルや手法の理解方法を変化させつつある。SOA、GDD、およびアウトソーシングは、このような傾向の中でそれぞれ独立した力を持ち、役割を担っている。これら3つが合わさったことが要因となり、ソフトウェアアーキテクチャを一段とうまく管理できるものに対して分析、設計、そして構築の研究を適用したい考えも生まれてきた。刻々と変化する要件や不完全なインプリメンテーション作業への対処を進める中、われわれはIT業務をさらにうまく管理する必要があり、その関連性はますます高まっている。

　最優良事例としてアーキテクチャ管理を導入していくと、課題が幾つか発生してくる。しかし、これらのトレンドに直面する組織は、より優れた生産性の高いソフトウェアアーキテクチャ管理手法を得られるようになるため、これらの課題を克服する価値は十分にある。そうしていくことで、企業は自分が最も得意な本業に集中できるようになる。

要約

アーキテクチャ管理は、ソフトウェア開発を現在変えつつある3つの力によって構成されている。「SOA」「地域分散型開発（GDD）」そして「アウトソーシングとオフショアリング」だ。ここからも明らかなように、アーキテクチャ管理は市場のニーズが作り上げたものだといえる。その利点は、ソフトウェアの設計や開発の手法と、要件、設計、およびコーディング全体の変更を管理する手法を改善できるチャンスを提供すること。

原文へのリンク