アーキテクチャ・ジャーナル アーキテクトのためのA〜Zガイド Mark Bloodworth、Marc Holmes 2008/11/25
Page1 Page2

Nは「N 層」の N

「机上の空論」
　 データ層、ビジネス ロジック層、ユーザー インターフェイス層。これで仕事が完了したかと思いきや、まだ終わっていません。N 層は単なる曖昧な用語であり、さまざまなコード群の間に何らかの区別があるべきだという概念を指しているにすぎません。Service-Oriented Architecture (SOA: サービス指向アーキテクチャ)、そして最近では、バックエンド (クラウド ストレージなど) またはフロント エンド (Facebook など) としてのクラウド サービスの普及により、実際にはアーキテクチャを説明することの方が、それを構築することよりも難しい場合があります。私たちは「ペトリ皿」アプローチのファンです。寒天ゼリーに浮かんでいるかのように、四角い箱が同心円の中に含まれています。
関連項目 : Needs (ニーズ)、Networks (ネットワーク)、Nonfunctional Requirements (非機能要件)、.NET

Oは Object Orientation (オブジェクト指向) の O

「これをカプセル化してください!」
　 Object Orientation (OO: オブジェクト指向) は、1990 年代に頭角を現したプログラミング パラダイムです。これは大きな問題やプログラムを、消化しやすい論理的に理路整然とした一口大に分けて、複雑さを克服する方法と考えることができます。オブジェクト指向は OO、あと 1 字で OOPS のように聞こえる OOP (Object Oriented Programming) と呼ばれることがあります。頭字語をすべて挙げるなら、OOAD (Object Oriented Analysis and Design) についても述べなければなりません。オブジェクト指向は、プログラミング パラダイムであると同様に分析手法でもあります。ただし、設計モデルと実装 (物理) モデルの間に変換が必要なように、分析 (概念) モデルから設計 (論理) モデルへの変換が必要な場合が多くあります。オブジェクト、つまり OO のコアとなるエンティティには、ビヘイビアとデータの両方があり、システムの機能はオブジェクトの相互作用によって実現します。クラスのインスタンスであるオブジェクトは、メソッドを通じてその力を発揮します。予想どおり、OO を把握するには重要なコンセプトと用語を学ぶ必要がありますが、中でも、継承、多態性、カプセル化、抽象化は最も重要です。
関連項目 : Operations (オペレーション)、Object-Relational Mapping (オブジェクト リレーショナル マッピング)、Operating System (オペレーティング システム)、OLAP

Pは Patterns (パターン) の P

「混沌状態から何かが見えてきたと思います。それはシマウマですか?」
　 パターンは、至る所にあるようです。4 人組がおり、そのオリジナルの設計パターンがあった場所には現在、さまざまな分野にまたがるパターン専門のリソースや本が数多くあります。一部は他より強いので、アーキテクチャの庭を適切に維持するために、パターンの慎重な除草が必要になります。パターンは、特定の概念を実装するためのテンプレートだけでなく、抽象的で複雑な概念について詳しい説明や図に頼らずに (おそらくこれも行いますが) 話し合うための共通の言語も提供します。
関連項目 : Principles (原理)、Platforms (プラットフォーム)、Politics (ポリシー)、Performance (パフォーマンス)、Process (プロセス)

Qは Quality (品質) の Q

「まずまずの出来では十分でない。」
　 品質は通常、「良い」の同義語として理解されています。「良い」の定義と測定は困難です。品質は定義され、評価可能でなければなりません。品質とは、ソリューションが、企業、業界、法的機関などが定義した必要条件と適用基準をすべて満たしているという保証です。評価基準と標準を定義および指定することで、ソリューションが評価可能になり、必要に応じて改良もできます。
関連項目 : Qualifications (資格)、Queries (クエリ)、Quantification (数量化)、Quantum Computing (量子コンピューティング)

Rは Roadmaps (ロードマップ) の R

「あなたは上の道、私は下の道を選びます。」
　 アーキテクチャと現実がばらばらになることがあるのは、時間が経つにつれて概念の生成とその後のビジョンの具現化に差が生じる場合です。多くの障害物が美しいアーキテクチャの邪魔をします。障害物とは、見解の相違、製品戦略の変更、短期的な駆け引きの必要性などです。ロードマップは、現在、近い将来、そして実装後の展望を提供して、元のビジョンを維持するのに役立ちます。ロードマップはビジネスに見通しと技術チームの目標を提供できます。ロードマップがあれば、最初は何をしようとしていたのかを覚えていることができます。
関連項目 : Requirements (必要条件)、Realization (実現)

Sは Strategy (戦略) の S

「何を達成しようとしているのか?」
　 戦略は目標を達成する方法を策定します。アーキテクチャの戦略は、企業の戦略から引き出されます。アーキテクチャによって企業が目標を達成できなければなりません。「戦略的」という言葉は慎重に用いる必要があります。多くの人々が、利点の曖昧な高コストの長期的投資を正当化するために使用していました。巧妙な軍事作戦と同様に、戦略は適応性がなければ、現実に遭遇したときに崩れてしまいます。戦略は戦術と混同されたり、戦術の反対だと間違えられることがよくあります。戦術は特定のアクションであり、目的を達成することによって戦略の実装となります。
関連項目 : Services (サービス)、Software (ソフトウェア)、Standards (規格)、Security (セキュリティ)、Scalability (拡張性)

Tは Thinking (思考) の T

「私は考えるので、時間的な余裕が生まれます。」
　 スキルとしての思考は通常、開発者やアーキテクトにとって問題ではありません。むしろ考える場所と時間を見つける方が難しいです。ブログ圏からの膨大な情報 (良い情報、悪い情報、不快な情報) が溢れる今日では、自ら考えたい気持ちになるのが難しいときがあります。そのような重大な活動に焦点を当てる必要があり、アーキテクトは場所と時間を見つけてそれを守る用意ができていなければなりません。思考について考えてみましょう。あなたに合う方法は? 列車での長旅ですか? 音楽ですか? それとも熱い泡風呂でしょうか? オフィスに風呂場を設置するのは難しいでしょうが、可能かもしれません。
関連項目 : Technology (テクノロジ)、Transparency (透明性)

Uは Understanding (理解) の U

「理解していただけたと思います。」
　 理解は知識を補完するものです。人、システム、プロセスを理解することは、ソリューションの結果を大きく左右します。理解は想定の正反対のものです。悪質なアーキテクトは想定を理解として提示するでしょうが、これは良くないことで、理想のアーキテクチャには到達できません。質問は理解に至るための重要な手段であり、上手に使えば、プロジェクトを脱線させる想定や神話、その他の力を打ち破ることができます。
関連項目 : UML、Unix

Vは Values (価値) の V

「どうしてこうするのか説明してください。」
　 アーキテクチャの価値は原理、つまり意思決定を導く価値体系と表すことができます。アーキテクチャの実践は、これらの価値で構成されています。したがって、原理はアーキテクチャの根底にある基盤です。効率的であるためには、企業レベルの原理は少数とし、幹部の支持がなければなりません。良い原理は、明白で一貫性と関連性があり、照準が正しく、適応能力と安定性があります。
関連項目 : Virtualization (仮想化)、Visualization (ビジュアライゼーション)、Views (ビュー)

Wは Whiteboard (ホワイトボード) の W

「図を描いた方がわかりやすいでしょう。」
　 ホワイトボードを上手に使うスキルは真の芸術です。見習いになるのは簡単ですが、達人になるのはなかなか困難です。我々自身の経験からも、ホワイトボードでの演出が悪いために実装されずに終わったすばらしいアイデアが多数あるのではないかと思います。将来、コンピューター テクノロジのパイオニアたち (あなた方のこと) が人々の記憶に刻まれているとすれば、記念碑として最もふさわしいのは、白い大理石のホワイトボードで作られた巨大な彫像でしょう。うっかり使ってしまった油性マーカーの跡が少し残っているのが話の種になるかもしれません。
関連項目 : Workflow (ワークフロー)、Wikis、Windows、Web

Xは XML の X

“<xs:element name=’ quote’ type=’ xs:string’ />”
　 世界共通のマークアップ言語になった XML は、一般的なデータ保存形式であり、システムやアプリケーションを統合する手段でもあります。中傷する人やライバルのマークアップ言語 (JSON や YAML) もありますが、XML の普及に対抗できるものはありません。XML を Web のエスペラント語と見なす人がいますが、XML は共有言語の基礎にすぎません。XML は文字と句読点を提供しますが、単語や文法は提供しないと考えてください。XML スキーマ (XSD) は XML ドキュメントを定義する手段で、共有してドキュメントの検証に使用できます。RelaxNG のような代わりもありますが、XSD なら XML と同様、十分に普及しているのでパートナーや顧客に理解されるでしょう。
関連項目 : XSD、XPath、XQuery、XAML、XOML

Yは YAGNI の Y

「目標を見失うな! 目標を見失うな!」
　 優れた設計は素晴らしい設計とは限りません。的確な判断によって、いつ新機能を構築するか、以前の作業を再利用するか、機能を省くかを決定することも、アーキテクチャのゲームに含まれます。ただし、先のことはわからないので、将来必要になる場合に備えて新しい機能を構築し続けるのも魅力的です。もちろん周知のように、利用可能な新しい手法、チャネル、さらには言語のせいで、今日長続きするソフトウェアは少なくなっています。確信がない場合は、おそらく必要ないでしょう。
関連項目 : YAML、Yottabyte

Zは Zeitgeist (時代精神) の Z

「格好いい人達は皆そうしている。」
　 時代精神つまり「その時代の精神」は、思考と価値とリーダーシップの重要な側面です。それは「老化」が現れる速度で増幅されます。結局、我々は既に Web 2.0 上にあります。時代精神にいかに反応するかを理解することで、正しい手段を講じて状況の変化に対応できます。「明日の Facebook として我々自身を改革しよう。」通常、これはアーキテクトにとっては新しい考えの表明というよりも (それらは実装にすぎない)、むしろテクノロジの展望で基礎となる思想的要因とその重要性です。普通の人が「ソーシャル ネットワーキング｣と見なすものは、アーキテクトにとっては「セマンティック Web｣なのです。
関連項目 : Zeal (熱意)、Zettabyte、Zero Day Exploit (ゼロデイ攻撃)

■最後に

　この A 〜 Z ガイドの編纂に着手したとき、その構成がどれほど難しいかと思いました。実際、可能性が多すぎて、個々の項目のメリットについて何時間も話し合いました。

　我々にとってこのリストは、アーキテクチャについて語ることは、よりソフトなスキルについて説明することだという確信でした。広範な技術展望を理解しなければならないので、判断力、バランス感覚、その他の知恵です。つまり、アーキテクチャを設計して実装するのに必要なスキルです。

　我々はこの A 〜 Z ガイドを楽しみながら書くことができましたが、ぜひ読者自身の考えもお聞かせください。アーキテクトなら、全員が同じリストに同意するはずがありません。

著者について Mark Bloodworth は、マイクロソフトの Developer and Platform Evangelism チームのアーキテクトです。マイクロソフトに入社する前は、BBC Worldwide のチーフ ソリューション アーキテクトとして、アーキテクチャとシステム分析を担当するチームを率いていました。この職務にはテクノロジ戦略、アーキテクチャ、チーム管理も含まれていました。Bloodworth の経歴はソフトウェア開発および設計であり、Web アプリケーションおよび統合を専門としています。これまでの経歴は、.NET をはじめとするマイクロソフト テクノロジの使用を中心としていますが、Java の経験も豊富です。remark.wordpress.com でブログを運営しています。 Marc Holmes は、英国マイクロソフトの Developer and Platform Evangelism チームのアーキテクトです。さまざまな顧客、パートナー、および ISV を対象としたアーキテクチャ、設計、概念実証を専門としています。マイクロソフトに入社する前は、BBC Worldwide の大規模な開発チームでアプリケーションおよび Web 担当責任者として活躍していました。Holmes は、『Expert .NET Delivery Using NAnt and CruiseControl.NET』(カリフォルニア州バークレー : APress、2005 年) の著者です。http://www.marcmywords.org でブログを運営しています。

INDEX
	［アーキテクチャ・ジャーナル］
	アーキテクトのためのA〜Zガイド
	1．A〜M
	2．N〜Z

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）