Tweet

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

Page1 Page2

　アーキテクトであることは、作成者が同じ部屋にいなければ意味がわからない突飛な図で人々を困惑させることではありません。もはやアーキテクトは批判的に手を振り、「規定のアーキテクチャと整合性がない」という理由でアイデアを却下することはできません。今日のアーキテクトには、ビジネス、チーム、ビジョン、テクノロジ、さらには広大な世界に対する数多くのさまざまな責任があります。

　この記事では、Mark Bloodworth と Marc Holmes がアーキテクトのための便利な A 〜 Z ガイドを提供しています。成功を祈ります。すべてのアーキテクチャが "n 層" でありますように。"n" は 1 より大きい任意の値で、"層" はよく似たコードの集合の比喩にすぎないことを考えれば、可能性は非常に高いでしょう。

Aは Advocate (提唱者) の A

「その方法はあまりお勧めできません。」
　 アーキテクトはビジネスの関係者に技術的な問題点を説明してアドバイスする必要があります。また、開発チームに構築方法についてアドバイスできることも必要です。このようなアドバイスはアーキテクトにとって金銭と同じであり、賢く投資すれば、好意と信頼が返ってきます。アーキテクトがアドバイスを求められるのは、「全体を見ること」がアーキテクトの仕事だからです。
関連項目 : Abstraction (抽象)、Agile (機敏な)、Acrobat (アクロバット)、Availability (可用性)、Analysis (分析)、Applications (アプリケーション)

Bは Balance (バランス) の B

「もう少し左へ。そのまま。もう少し。行き過ぎです。すみません。」
　 すべての決定にはトレードオフが伴います。たとえば、セキュリティ対策を追加すると、パフォーマンスが低下する場合があります。適切なトレードオフを行うのはアーキテクトの役割です。アーキテクチャはゼロ サム ゲームですが、アーキテクトはシステムの目的を知ることで、システムを成功に導くトレードオフを選択できます。もちろん、目的が競合する場合は、問題点を説明し、目的に優先順位を付けて解決方法を探すのがアーキテクトの仕事です。
関連項目 : Best Practice (ベスト プラクティス)、Benchmarks (ベンチマーク)、Building Blocks (ビルディング ブロック)

Cは Coach (コーチ) の C

「つらくても頑張ろう!」
　 ソリューションの実装には非常に多くの選択肢があり、アーキテクトは自分の「アーキテクチャ」の概念を開発チームに単に口頭で伝えることはできません。アーキテクトには、開発チームの指導が求められるようになりました。これには、よりソフトなスキルが必要です。つまり、「これをしろ」「あれをしろ」と指示するのではなく、方法と理由を尋ねるスキルです。アーキテクチャの理由を理解している開発チームの方が、より熱心に取り組み、実装に成功する可能性が大きいのです。アーキテクトは、開発チーム内で有能なスタッフを見つけて、有益な昇進のチャンスを与えることができます。
関連項目 : Communication (コミュニケーション)、Champion (チャンピオン)、Context (コンテキスト)、Collaboration (コラボレーション)、C#

Dは Dependencies (依存関係) の D

「これを外すとどうなるだろう? ああ!」
　 アーキテクチャを構成しているコンポーネント間の関係は、根本的な重要性を持っています。依存関係は必然的なものですが、できるだけ管理する範囲を最小にとどめるべきです。図を描いて、依存関係を調べます。直接的 (A が B に依存、B が A に依存) か、間接的 (A が B に依存、B が C に依存、C が A に依存) かにかかわらず、循環しているのは良くありません。D に依存しているものが多い場合は、D を変更すると大きな影響が出るため、D は安定している必要があります。
関連項目 : Design (設計)、Development (開発)、Delivery (納品)、Domain (ドメイン)、Documentation (文書)

Eは Evangelist (伝道者) の E

「すごいものをお見せしましょう。」
　 アーキテクトは、自分が選んだものを提唱する必要があります。その他の人は、アーキテクチャのアイデア、フレームワーク、指針となる価値を信頼する必要があります。伝道とは、いろいろな人に話をすることです。大別すると、技術関係の聞き手とビジネス関係の聞き手がいますが、その中にも実にさまざまな人がいます。アーキテクチャは、そのそれぞれに説得力のある話が必要です。伝道者は、共通の理解を得るために、複雑なシナリオをまとめ上げて単純化することができます。
関連項目 : Enterprise (企業)、Engineer (エンジニア)、Enthusiast (熱心な人)

Fは Frameworks (フレームワーク) の F

「どのように達成するか?」
　 ソリューションのアーキテクチャを作成するのは容易なことではありません。複数のソリューションのアーキテクチャを作成する場合は、特に時間的なプレッシャーとソリューション間の統合を考えれば、さらに難しくなります。アーキテクチャ フレームワークは、無駄な労力を省くための骨組みで、アーキテクチャ作成プロセスにツール、方法、共通の語彙を提供します。アーキテクチャ フレームワークは、アーキテクチャの「どのように」という質問に対処するものと見なすことができます。
関連項目 : Facts (事実)、Functionality (機能)、F#、Firewall (ファイアウォール)

Gは Governance (ガバナンス) の G

「それが小委員会の意見です。」
　 真剣にビジネスを行うつもりなら、スーツを着なければならない時代が来たと言われています。管理は、アーキテクチャのビジョンを実現するうえで重要な部分です。集中、分散、連合などの IT モデルにかかわらず、等しい価値の競合的な要求があります。優れたアーキテクチャはさまざまなニーズに柔軟に対応できる必要がありますが、ビジネスの短絡的な要件によってアーキテクチャの価値が失われるようではいけません。同様に、優れた統制はテクノロジに関するダッシュボードスタイルの前向きな見通しをビジネスに提供できます。共通の理解は常に望ましいことです。
関連項目 : Generative Programming (生成的プログラミング)、Generalist (ジェネラリスト)

Hは Human Dynamics (人間力学) の H

「気難しいユーザーがいなかったら、システムは成功しただろうに!」
　 優れたソリューションを提供するには、人間どうしの対話方法と、それをサポートするシステムの操作方法を理解することが重要です。各プロジェクトおよびチームの力関係はさまざまです。出資者との関係やモチベーションはプロジェクトごとに異なる場合があります。人間関係の舵取り方法を知ることは、良いアーキテクトであり良いリーダーであるための重要なスキルの 1 つです。
関連項目 : Heterogeneous Environments (異種環境)、Heated Debates (熱い討論)、High Performance Computing (高性能コンピューティング)

Iは Innovation (革新) の I

「あらゆる組織の活力源」
　 ほとんどの製品は、発明、革新、商品化、余剰のサイクルと見なすことができます。発明にはコストと時間がかかり、運や、考え方の大きな飛躍が必要になることもあります。商品化の時点でゲーム終了ですから、他者の作業を利用するのが最善のオプションでしょう。したがって通常は、既存のアイデアやソリューションを進化させ革新することで、効率性、競争に勝てる差別化などの利点を達成できます。この方法は、価値は小さいかもしれませんが、価値が下がることはありません。小規模なチームなら着実に革新を進めることができ、名前を売るチャンスになります。大規模なグループや組織はそれほどすばやく進めないかもしれませんが、個人やチームの革新を組織全体に浸透させて、このインスピレーションとイマジネーションを最大限に活用するメカニズムを構築する必要があります。アーキテクトは革新のために技術チームの口となり、ビジネスの耳となることができます。
関連項目 : Integrity (整合性)、Inspiration (インスピレーション)、Infrastructure (インフラストラクチャ)

Jは Judgment (判断) の J

「大きな力には大きな責任が伴います。」
　 議論が終わり、技術的な決定をする段階になると、アーキテクトが判断を下さなければなりません。チームはアーキテクトの判断を信頼し、アーキテクトの優れた判断がチームに自信をもたらします。好むと好まざるとにかかわらず、一連の良い判断や悪い判断によって、このアーキテクトが保守的か賢明か、衝動的か先見の明があるか、先入観に捕らわれているか挑戦的か、などの特徴が見えてきます。良い判断を下すことは重要ですが、現実には良い判断からも悪い結果が生じることがあります。ミスをすることよりも、何もしないことを心配すべきです。
関連項目 : Java、Just In Time

Kは Knowledge (知識) の K

「今知っていることをあのとき知っていたら。」
　 知識はアーキテクチャの重要なツールです。もちろん、知識の限界を心得ていることは良いことです。知識はアーキテクチャの重要なツールです。未知だと知られている領域は、概念の証明やその他の知識構築を行う時期に来ています。一方、知られていない未知は厄介です。アーキテクチャの世界では、異常を起こす得体の知れない原因に相当します。テクノロジの知識は、アーキテクトが使いこなす必要のある専門分野の1 つに過ぎません。アーキテクトは、組織の構造、企業の戦略、ビジネス プロセス、開発方法論など、技術的でない要素の影響についても知る必要があります。
関連項目 : Kernel (カーネル)、Keyboard (キーボード)

Lは Leadership (リーダーシップ) の L

「どこまでもあなたに付いていきます。」
　 アーキテクトにとってリーダーシップは不可欠であり、通常は思想リーダーシップとチーム リーダーシップの 2 つの形態をとります。アーキテクチャとその背景にある価値の守護者として、アーキテクトは思想リーダーなのです。アーキテクトは絶えずビジョンを再評価し、競合するビジョンと新しいテクノロジについてのコメントを添えて、より新しくより洗練されたビジョンを再現します。チーム リーダーとして、アーキテクトはライン部門を管理する義務はないかもしれませんが、信頼、洞察、モチベーション、インスピレーションなどを与えるチームの象徴となることが求められる場合があります。
関連項目 : Lean (リーン)、Linux、Latency (遅延)、Load Balancing (負荷分散)

Mは Modeling (モデル化) の M

「さて、この仕組みが目に見えるように、小枝とギターの弦だけを使ってこのモデルを作成しました。」
　 モデルは、何か (たとえばビジネス プロセスやコンピューター システム) を表したものです。モデルのビューは、問題やソリューションに関する概念を伝達および理解するための手段となります。ビューごとに扱う概念が異なります。複数の問題点に取り組もうとして 1 つのビューに詰め込みすぎると、ビューが複雑になりすぎるか、理解が単純化されすぎてしまいます。このようなモデル ビューを表す共通の表記法があれば、モデルに関する話が簡単になります。ただし、表記法自体が複雑になりすぎると、この利点はすぐに失われます。
関連項目 : Management (管理)、Maintainability (保守性)、Messaging (メッセージング)

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

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

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