アーキテクトへの道 シリーズ 第一話
アーキテクチャって何? アーキテクトってどんな人?
■はじめに
みなさん、人生エンジョイしてますか? 今回から「アーキテクトへの道」と称した連載企画を開始いたします。アーキテクトになりたいと考えている方や、自分ってアーキテクトなんだろうかと疑問を抱いている方をはじめ、すでにアーキテクトとして活躍されている方にも広く情報発信してまいりますのでぜひおつきあいいただければ幸いです。
■アーキテクチャって何?
みなさん"アーキテクチャ"という言葉から何を連想しますか? 過去いろんな人に聞いてみました。大体こんな感じです。
- システム開発の上流工程
- システムの基本的な枠組み
- パターンとか経験則
- うーん、机上の空論でしょ
最後の一つを除いてどれも合っていますが、やはりピンときませんね。そもそもアーキテクチャって何でしょうか? オブジェクト指向のような開発方法論のことでしょうか? MVC などのパターンのことでしょうか? UP などの開発プロセスとの関係は? それとも .NET や Java のフレームワークのこと? 3 階層? ･･･
標準の定義を引用するとアーキテクチャとは
《アーキテクチャ》 … システムのコンポーネント、コンポーネント同士と環境との間の関係、およびその設計と進化を支配する原理に体現された、システムの基本的な構造。 (※ANSI/IEEE 1471-2000 から引用)
ではアーキテクトってどんな人のことを指しているのでしょうか?
《IT アーキテクト》 … 戦略的情報化企画局面におけるビジネス／IT上の課題を分析し、ソリューションの枠組みを策定するとともにソリューションアーキテクチャ (構造) を設計する。 (※IT スキル標準概説書－情報処理推進機構から引用)
実際のところどうなんでしょうか? 私の経験から大雑把に言ってしまうとアーキテクチャとはシステム構築、アプリケーション開発時に守るべきお作法です。アーキテクトとはそのお作法を決めて開発者のみなさんに理解してもらい、また定期的にそのお作法が守られているかを確認する人です。ビジネス寄りの人もいれば技術寄りの人もいます。
■これまでの経験から
私が最初にアーキテクチャについて取り組みを始めたころはこのように感じていました。
「"アーキテクチャ" とはパフォーマンス、拡張性、生産性、信頼性 (○○性を挙げだすときりがないので英語ではまとめて abilities といったりします) を確保するためにどうすればいいのかを考慮してそれを実現する枠組みのことかなぁ。」
今おもえば大きくはずれてはいませんが、当時はまだ漠然としたイメージでしかありませんでした。現在はどうかというと、漠然としていて当たり前だということが分かりました。その間何年も費やしています。まさかそれだけかと思われるかもしれませんが、そのとおりです。
アーキテクチャに限らず、プログラミング言語や方法論やひいてはスポーツにいたるまで何事も始めた当初は難しく考えすぎて不安な気持ちに駆られますが、随分と経験を積むと結局キーポイントってこうなんだねということがわかり、さほど難しく考える必要などないのだと気づくわけです。
ただ漠然としたまま放って置くわけにはいきません。個別のプロジェクトに適用してプロジェクトメンバーが利用できるためには、具体化していく作業が必要です。
そのイメージを下図に示します。
.gif "図 1. アーキテクチャの構築")
図 1. アーキテクチャの構築
上図点線の右側が汎用的 (普遍的) な要素です。一般的にアーキテクチャというとこちら側をイメージする方が多いように思われます。それで机上の空論などと揶揄されるケースがあるわけです。
しかし実際のプロジェクトに適用するにはそのプロジェクトに合わせてより詳細化・具体化していく作業が必要です。つまり点線の左側の部分を考慮することで、普遍的なものをベースとして、そのプロジェクトに最適化していくことが求められます。
そういう作業を通じて規定されたアーキテクチャは実際の開発時に活かされる、意味のあるアーキテクチャと言えます。アーキテクチャとして規定するものとしては大体以下のものが含まれます。
- 論理的なシステム構造の規定
サブシステム構成
論理レイヤー構成・依存関係の方針
コンポーネント構造・粒度・種別・役割の方針
コンポーネント間の対話スタイル (タイプ / インスタンス、同期 / 非同期)
コンポーネント間の振る舞いの方針
- 物理的なシステム構造の規定
対話プロトコル (Webサービス / メッセージキュー)
データ形式 (バイナリ / XML)
データアクセス方式 (ストアドプロシージャ、SQL 文)
トランザクション実装方式 (ADO.NET / COM+ / DBMS)
物理ティア構成 (Rich クライアント＋Web ファーム＋DB クラスタ)
- データ構造に関する規定
- セキュリティや信頼性確保などの運用管理ポリシー
- 使用するプラットフォーム、ミドルウェア、市販ソフトなどの利用規定
■アーキテクトの資質
スポーツを例に挙げると、上達するにはその道を究めていかなければなりません。オリンピックに出場するためには最高峰に上りつめる徹底的な努力が必要です。
アーキテクチャも全く同じで奥は非常に深く、範囲も非常に幅広いものです。あくなき探究心なしには頂点を極めることなどできません、どこまでも続く終わりなき旅のような気がします。私もその旅の途中ですが、道しるべとなるべきものがいくつかあると考えています。その中で重要なものの一つとして物の考え方が挙げられます、思考態度と言い換えてもいいです。
目的を達成するためにどうすればよいのかという思考態度
例えばパターンに関していうと、パターンを適用することそのもので満足している方をたまにお見かけしますが、それでシステムの保守性や柔軟性が本当に確保されるのでしょうか? 目的が達成されたかどうかが唯一の指標であるべきです。
ではアーキテクチャの目的とは何でしょうか。著名なアーキテクトの言葉を借りると「複雑さの管理と変化への対応」です。含蓄のある言葉だと思います。もう少しかみ砕いていうと、そのアーキテクチャに従うことでシステムが要件どおりに機能し、システムの運用・保守が効率よく実行できて、さらにはシステム変更時に苦労することなくスムーズにバージョンアップが行えることです。
今規定しようとしているアーキテクチャがその目的を達成できるのかと常に自問自答しながら進めていくことが肝心です。アーキテクチャを決めることが目的ではなく、その結果が重要なわけです。当たり前のことを言っていますが、それが難しい事だと分かる方は開発者として正しい経験を積み重ねてこられた方です。そしてその難しさを解決している方がアーキテクトです。
抽象化された思考態度
ある日突然「今回は 3 階層にしましょう」と言われた経験ありませんか? 3 階層にしてなにがメリットなのでしょうか? ここでずばり正解を言える方はすでに立派なアーキテクトだと思います。Web サーバー、アプリケーションサーバー、データベースサーバーの 3 つのサーバーに分けてそれぞれに UI、ビジネスロジック、データを配置すると分散システムとして・・・柔軟性が保てる・・・。うーん完全な間違いではありませんが本質とは少し違います。
アーキテクチャ パターンの一つとして Layers (レイヤー) というものがあります。これは物理的にサーバーを 3 つの階層に分けるという意味ではなく、論理的に分けるという意味です。論理的に分割することによって分割されたもの同士の依存関係を整理することが目的です。例えば UI、ビジネスロジック、データを論理的に分割してそれぞれをコンポーネントとして構築し、物理的には 2 つのサーバーに配置するということはごく一般的な例です。
図でご説明するとまず一つめの図にあるのが論理的なレイヤー (層) です。各レイヤーには役割に応じたコンポーネントが存在します。そしてこれらのレイヤー間の呼び出しは上から下へはメソッドコール、下から上にはイベント通知というのが教科書的な Layers パターンとなります。(もちろん何事にも応用の必要がありますが) こうすることによって下のレイヤは上のレイヤには依存しなくなります。
.gif "図 2. アプリケーションの論理的な階層")
図 2. アプリケーションの論理的な階層
そしてこれらの論理的なレイヤーおよびそれに属するコンポーネントをどのように物理的サーバーに配置するかというと、2 つめの図に示すようにさまざまな例があります。
.gif "図 3. アプリケーションの配置")
図 3. アプリケーションの配置
■まとめ
今回は第一回目として導入部分についてお話をさせていただきました。次回はさらに掘り下げた内容で、いろんな視点からアーキテクチャについてお伝えしたいと思いますのでご期待ください。
.gif "Top of Page")
Top of Page