ソフトウェアアーキテクティングのプロセス：The Rational Edge（2/2 ページ）

[Peter Eeles，＠IT]

アーキテクティングは芸術だ

　アーキテクティングは科学だと考えることもできるが、創造性が必要になることもある。斬新で前例のないシステムを扱うときなどは特にそうだ。このような場合は、利用できる体系化された経験がない場合もある。真っ白なキャンバスを前にした画家がインスピレーションを求めるように、アーキテクトも、時には自分たちの作品を科学というよりむしろ芸術として考えることがある。しかしだいたいの場合、アーキテクティングに芸術的側面はほとんどない。例え最も斬新なシステムであっても、通常は、どこかにあるソリューションを複製し、これを検討中のシステムに適合させることが可能だ。

　ソフトウェアアーキテクティングのプロセスがますます主流になってくれば、これが「少数の選ばれし者」にしか理解できない不可解な手法だとは見られなくなってくる。そして、科学的根拠のある、明確で実証済みの幅広く利用可能な手法と見なされるようになる。

多くの学問にまたがるアーキテクティング

　アーキテクトには、ソフトウェア開発プロセスの多くの学問が必要になる。アーキテクトと最も関係の深い学問は設計だが、ほかにも多くの学問が必要になる。例えば、要件定義学においては、アーキテクトは、自分が特に関心を持つ要件を確実に把握できるようにする。彼らはまた、要件の優先付けも行う。アーキテクトはインプリメンテーションにも参加し、そこでソースコードや実行可能な成果物の整理に利用するインプリメンテーション構造を定義する。アーキテクトはテストにも参加し、そのアーキテクチャがテスト可能なもので、確実にテストされるようにする。アーキテクトは、具体的にガイドラインを設定するなど、開発環境の一部要因についても責任を持つ。（バージョンコントロールをサポートする）コンフィギュレーション管理構造は定義済みのアーキテクチャを反映する場合が多いため、アーキテクトはコンフィギュレーション管理戦略の規定も支援する。アーキテクトとプロジェクトマネジャーは密接に協力し、本稿の第2回で説明したように、アーキテクトはプロジェクト計画作業に対する意見を出す。

　アーキテクティングの範囲について説明をするときは、アーキテクティングと設計の間の関係に言及する必要がある。アーキテクトは設計の分野に大きく関与しているが、設計のすべてがアーキテクティングだとは見なされない。これは、アーキテクチャが重要な要素しか考慮せず、設計のすべての要素がアーキテクチャにとって重要だと見なされるわけではないからだ。例えば、ユーザーインタフェース画面の詳細設計は、アーキテクチャ上、通常は重要とは見なされず、ユーザーインタフェースのデザイナーに任せるのが最善だとされる。業務ロジックやデータロジックをサポートする要素など、システムのほかの要素にもこれと同じ考え方が当てはまる。アーキテクトは必要なところにだけ制約を設け、設計上の多くの判断はデザイナーに委ねる。

アーキテクティングは継続作業

　経験上、アーキテクティングはプロジェクトの初期に一度実行して終わりという作業ではない。アーキテクティングはむしろ、プロジェクトの作業全域に適用され、実働ソフトウェアを何度も引き渡していく中で「成長」していく。アーキテクチャは、引き渡しが行われるたびに完成度を高め、安定していく。ここから、プロジェクト全体を通してアーキテクトが何に重点を置いているのかという疑問が出てくる。

　ソフトウェアアーキテクティング作業の成功は、結果で判断する。従って、望まれる結果が徐々に変化すれば、アーキテクトの重点もそれに合わせて変化していく。このことは、Bran Selic（注2）の描いた図2で指摘されている。

注2　Branはこのグラフをナプキンの上に描いてPhilippe Kruchten氏に見せたという。

図2　時間の経過に伴うプロジェクトの重点の変化（クリックすると拡大）

　図2からは、プロジェクトの早い段階ではアーキテクトが発見の作業にかなりの重点を置いていることが分かる。システムの対応範囲の理解と、重要な機能とそれに関連するリスクの特定に重点が置かれている。これらの要素はいずれもアーキテクチャに明確な影響を与える。その後、焦点は発明の段階へと移り、ここでは完全なインプリメンテーションの基盤となる安定したアーキテクチャの開発が最重要視される。最後に、焦点はインプリメンテーションへと移り、発見と発明の大部分がここで行われる。

　発見、発明、そしてインプリメンテーションは厳密には逐次的でないことに注意したい。例えば、一部のインプリメンテーションは、アーキテクチャのプロトタイプを構築するのに伴いプロジェクトの初期段階で行われ、その後経験が増え、インプリメントアーキテクチャの特定の要素を実装すべく異なる戦略が採用されれば、プロジェクトの後半でも発見が行われていく。

　システムの引き渡しが行われるまでアーキテクティングのプロセスは完了ではない、という点は注目に値する。従って、アーキテクトはプロジェクトに最後まで関与する必要がある。アーキテクチャが安定すると、貴重な資源をほかのプロジェクトに回そうとして、プロジェクトからアーキテクトを外そうとする動きがしばしばある。しかし、プロジェクトではアーキテクチャ上の判断を下す必要が最後まで残る場合がある。ただ実際は、アーキテクチャに影響を与える主要な判断を下したらアーキテクトはチームの専属から外れる、という妥協点を見いだすことが多い。しかし、アーキテクトは完全に離れてはならない。もちろん、アーキテクトの役割をチームが遂行する、という一段と柔軟な状況も考えられる。こうすれば、一部のメンバーがほかのプロジェクトにも参加し、残ったメンバーがシステムアーキテクチャの整合性を保証できるようになる。

アーキテクティングは多数の利害関係者主導で行われる

　本稿の前半で説明したように、アーキテクチャは多数の利害関係者のニーズを実現する。従って、アーキテクティングプロセスは、これらの利害関係者すべてに対応し、彼らの関心事、特にアーキテクチャに影響を与えそうなものを確実に把握し、明確化し、調整してうまく処理する必要がある。また、これらの関心事に対するソリューションを検討する際は、常に利害関係者を参加させることも必要になる。

　アーキテクティング作業に利害関係者全員を関与させる作業を過小評価してはならない。これらの利害関係者は、要件収集方法、アーキテクチャをドキュメント化する際の書式、そしてアーキテクチャの評価方法など、プロセスの多くの側面に影響を与える。

アーキテクティングにトレードオフは付きもの

　アーキテクチャに影響を与える多くの要因を考慮した場合、アーキテクティングプロセスにトレードオフがつきものであることは明らかだ。トレードオフは要件同士で頻繁に発生し、正しいトレードオフを判断すべく利害関係者に相談する必要も出てくる。トレードオフの例としては、コストとパフォーマンスがある。問題部分に処理能力を投入すればパフォーマンスは向上するが、それにはコストが掛かってくる。これは、要件の衝突の典型かもしれないし、アーキテクトが熱心にすべての選択肢を検討していると仮定すれば、ニーズの衝突する利害関係者が解決する必要のあるものだ。

　トレードオフはほかにも、ある技術の代わりに別の技術を採用する、サードパーティー製コンポーネントを複数の中から選ぶ、あるパターンの代わりに別のパターンを選ぶなど、ソリューションの部分でも発生する。トレードオフは回避できるものでも、回避すべきものでもない。複数の選択肢を検討し、その中からトレードオフを選択することもアーキテクトの仕事だ。

アーキテクティングには経験が役立つ

　アーキテクトが真っさらな状態から作業を始めることはほとんどない。彼らは先に述べたように、アーキテクチャのパターン、設計パターン、既製コンポーネントなどが体系化されている場合もある以前の経験を積極的に探す。つまり、アーキテクトは再利用可能な資産を探し出してくる。よほど無知なアーキテクトでもない限り、過去の作業を検討しないようなことはしない。

　再利用可能な資産は、繰り返し発生する問題に対するソリューションとなる。再利用可能な資産とは、再利用を念頭に置いて開発された資産のことだ（注3）。

注3　「Reusable Asset Specification」（2004年6月Object Management Group Inc.刊、04-06-06）。

　現行システムを検討するに当たり、アーキテクチャの要素が再利用可能であることは事実だが、アーキテクトは、アーキテクチャ、あるいはその要素を、現行システム以外で使える再利用可能な資産として検討することもできる。

アーキテクティングはトップダウンでもありボトムアップでもある

　多くのアーキテクチャは、1）アーキテクチャを定義する前に利害関係者のニーズを把握して要件を明らかにする、2）アーキテクチャの要素を設計する、そして3）これらの要素をインプリメントする、というトップダウンで検討されている。しかし、アーキテクチャがこのように完全にトップダウンで作られることはまれだ。アーキテクチャ実証用などとして開発してきた実働ソフトウェアから得た教訓により、アーキテクチャがボトムアップで作られる場合もよくある。アーキテクチャはまた、指定された設計上あるいはインプリメンテーション上の制約から、ある程度までボトムアップでも作られる。この場合、これらの要素はアーキテクチャが対応しなくてはならない「当然の前提」になる。例えば、リレーショナルデータベースや既存システムのインタフェースを使用する設計であること、といった制約がある。

　成功しているアーキテクトは、アーキテクティングには両方のアプローチが必要であり、自分たちのアーキテクチャが「トップダウン」と「ボトムアップ」の両方で作られていることを認識している。これはアーキテクティングに対する「真ん中狙い」アプローチとも呼ばれる。

---

　本稿ではソフトウェアアーキテクティングのプロセスの核となる特性に重点を置いてきた。アーキテクチャの項はこれで終わりとなり、来月からは重要なIT資産としてアーキテクチャを扱うことのメリットについて説明する。

要約

ソフトウェアアーキテクティング作業は、まだ新しいものの、ソフトウェア開発分野において認められた学問だ。しかし、そのような認識から、重点はアーキテクティングプロセスを完成させるテクニック、プロセス、そして資産に置かれる。このような完成度を高める方法の1つが、既存の多数の知識を利用することだ。大まかにいえば、アーキテクトがアーキテクチャを開発する際は、わざわざ一からやり直すのではなく、実証済みのソリューションを探し求める。参考になるアーキテクチャの観点から体系化された経験や、アーキテクチャおよびデザインパターンなどの再利用可能な各種要素には、それぞれに役割がある。しかし、ソフトウェアアーキテクティングのプロセスが土木工学のプロセスに少しでも完成度で近づくにはまだ時間が掛かるだろう。この完成度は、標準の利用や、最優良事例、テクニック、およびプロセスの理解など、多くの側面から検討することができる。その結果、現時点ではアーキテクトの経験がプロジェクトの成功を大きく左右する。