BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル アジャイルアーキテクチャの相互作用

アジャイルアーキテクチャの相互作用

ブックマーク

原文(投稿日:2011/04/25)へのリンク

この記事は、最初にIEEE Software マガジンに掲載され、InfoQ & IEEE Computer Societyによってここに提供されています。

 

アジャイル開発は、その成果が完全に理解される前に始まります。そして、開発中に経験的知識が増えていくため、設計や計画を調整します。さらに、問題に最も近い人たちの判断を信じ、最終顧客と継続的に協力することを促します。アーキテクチャは、技術的なゆとりを生み出し、デザインパターンを作り、品質特性を拡張し、関心のある人たち全員に伝えられます。アジャイル開発とアーキテクチャという2つの組み合わせがアジャイルアーキテクチャであり、良いアーキテクチャに向かって進んでいくアジャイル技術を使うアプローチです。成功するアジャイルアーキテクチャにおいて必要とされるアーキテクトは、アジャイル開発を理解し、十分に定義された点でチームと相互に作用し、他のアプローチを用いてアーキテクチャ関連の経験から簡単に適応された重要なスキルを使ってチームに影響を与え、プロジェクトの方法論とは別にアーキテクチャ関連の機能を適用します。

アーキテクチャの相互作用のポイント

図1は、スクラム[1]、エクストリームプログラミング[2]、シーケンシャルプロジェクトマネジメントの組み合わせを簡略に示しています。これは、私が過去8年間かけて14のアジャイルプロジェクトでアーキテクチャに関する作業を指導してきた結果、効果的なことが分かっています。

図 1. アジャイルのアーキテクチャに関する作業のハイブリッドなフレームワーク。プロジェクトにアーキテクトを巻き込むことは、プロジェクトの目的を達成する手助けとなります。テーブル1では、さらに相互作用ポイント(緑)、重要な技術(金)、アーキテクチャ機能(紫)というフレームワークの要素を説明しています。

テーブル 1 は、図1の要素を簡単に説明しています。このリストは網羅的ではありませんが、アーキテクチャ機能は、アーキテクトが通常プロジェクトで実行するものです。

テーブル 2は、交差している点においてアーキテクトの主な関心や相互作用点とアーキテクチャ機能がどのように交わるのかを示します。まとめて言うと、3つのカテゴリと4つの項目によって、他の優先順位や選択肢に基づいてカテゴリや項目を追加することで、アジャイルアーキテクチャを拡張できることを理解し、指導するのに役立つフレームワークが作り出されます。

先行計画

各アーキテクチャ機能は、手法に関わらず、他のプロジェクトと同様、アジャイルプロジェクトの中で先行計画によって始まります。アーキテクトは以下の作業を行います。

  • 主要なハードウェアとソフトウェアを決定する。既存のコーポレート標準を使い、新製品に対しては概念実証を準備する。
  • 概要[3] と詳細[4] レベルで重要なデザインパターンを確立する。
  • コンポーネントやサービスの再利用の幅広い機会を確認する。
  • 上位レベルの図を作成する。
  • 技術面とビジネス面の品質特性[5]の概要と、トレードオフ[6]の基本について述べる。
  • ステークホルダの関心を理解し、一般的な技術的方向を共有するためにステークホルダに会うことで、コミュニケーションチャネルを確立する。

多くのことはアジャイルではないアプローチの活動と同様ですが、アジャイル開発の先行したアーキテクチャ関連の作業は、わずかだけれども重要な違いを含んでいます。アーキテクチャの方向は、特定の解決策よりも幅広い選択肢を含んでいるべきです。アーキテクチャに関する緩いまとまりは、アジャイルでは受け入れられます。なぜなら、システムを構築中に全ての参加者から集められた経験的知識が、より良い選択肢を明らかにするからです。[7] アーキテクトはあまりにも早く解決策を決めつけることがないようにうまくやりますが、この罠を避けることはアジャイル開発では特に価値があります。アジャイルでイテレーションや動くソフトウェアを作ることと協力を促進することは、フィードバックのループを生み出し、すぐには理解できなかったけれども、参加者全員が後でより良い解決策を見つけ出す素晴らしい機会を提供します。[8].

例えば、データウェアハウスのプロジェクトにおいて、他の場所に直接データをフィードするか、それとも中間データマートを構築するかどうかという疑問が発生します。直接的なフィードは、より複雑であり、メンテナンス性と運用効率が悪くなります。しかしながら、データマートはより多くのスペースを使い、システムの運用全体を見れば、より多くのコストがかかります。アーキテクトたちは、どちらの選択肢もビジネスの目的に合い、どちらがより良い設計か決めるのは難しいけれども、チームであればアーキテクチャに関する限界の中で正しい決定をするという信頼を寄せていました。プロジェクトが実施され、この答えは自明の理になりました。チームはアーキテクチャをほどよく定量化して、アーキテクトはその役割を終えました。範囲や限界を決めることは、特定の解決策を定めることよりも機敏だと言えますが、アーキテクトは前もって範囲や限界を決めなければなりません。

ストーリーボードとバックログ

前もって計画することで、素早くストーリーボードに取り組み始め、プロダクト/スプリントバックログを構築することができます。この場合、アーキテクトは重要なステークホルダになります。アーキテクトは、初期のストーリーボーディングのセッションに参加して、アーキテクチャに関するユーザストーリーに貢献しなければなりません。このユーザストーリーは重大な基礎となり、方向性の決定に影響します。また、このアーキテクトはスプリント間で進行中のストーリーボーディングにも参加しなければなりません。そして、アーキテクチャを微調整したり、望ましくないずれを修正したりするアーキテクチャに関するユーザストーリーに貢献します。アーキテクトはプロダクトオーナーと共に、ビジネスユーザストーリーを用いてこれらのストーリーの優先順位付けを行い、スプリント中のビジネス機能と併せて、ユーザストーリーを構築しなければなりません。

アーキテクトは、しばしばビジネスと技術の両方の包括的な知識に基づいて、ストーリーボーディングの原動力になります。優れたアーキテクトというものは、ストーリーボード形式でビジネス以外の要求を引き出し、ビジネスに対する技術的制約を説明し、チームのために技術的な言葉でビジネスのニーズを言い換える良い立場にいることが分かります。アーキテクトがこのようにすれば、アーキテクチャに関するユーザストーリーをストーリーボードとプロダクトバックログに円滑に統合しながら、すべての立場の人たちが成功するように手助けできます。

例えば、データウェアハウスのプログラムは、エンタープライズデータの上位レベルの統合を求められました。アーキテクトは、第一アプローチとしてディメンショナルモデリングを使うことを推奨しました。また、データ作業を組織化するための初歩的なツールとして、問題の分解と作業の繰り返し[9]を促進するバスマトリックスを使うように薦めました。ビジネス(そして、大抵の技術コミュニティ)では、バスマトリックスを使うことはありませんでした。そのため、アーキテクトは最初のストーリーボーディングのセッションで、広範囲に渡って促進するようにしなければなりませんでした。3回目のセッションまでに、プロダクトオーナーはバスマトリックス形式で印刷したストーリーを手に入れました。5回目のセッションでは、チームはバスマトリックスのコンポーネントによってのみ成功が判断されていることに懸念を表しました。そこで、私たちは一歩下がって、再利用可能なコードのコンポーネント、データ品質に関する問題の解決、利用する新しいツールの取得などのあまり目に見えない作業の価値を強調しなければなりませんでした。このアプローチが明らかに勢いを得たのは、アーキテクトが初期の段階で円滑に進めたからでした。

スプリントへの参加

コードを書けば、アーキテクトはアーキテクチャが作られていることをよく理解できます。[10] しかし、アーキテクトの能力を完全に実践的にするのではなく、アーキテクトを組織に広めることで高い価値を得るものだと私たちは考えます。幸運なことに、アジャイルは、チームを信じるという解決策を提供します。このため、アーキテクトは目的を理解し、設計の問題に挑戦する手助けをしながら、スプリント中にチームと大いに協力する必要があります。[11] このように複数のプロジェクトを扱うために、アーキテクトはチームに多くの詳細を残さなくてはなりません。動くソフトウェアに対するアーキテクトのレビューがアーキテクチャに関して高い品質を示し続ける限り、アーキテクトはチームメンバに詳細を残し、組み合わされた技術的知識と仕事のすぐ近くにいるという確信を与え、物事を軌道に乗せるでしょう。つまり、実践的な実施を約束することは、スプリントがアーキテクチャやその他のことからはずれているようなときに、正当だとみなされますと。そのようなときに、アーキテクトは実践的な貢献者になり、チームと協力して、チームが割り当てられた仕事を完成させるようにする責任を負います。

例えば、データウェアハウスのアーキテクチャには長年に渡る疑問があります。正規化モデリングとディメンショナルをいつ、どの程度使うのかということです。[12]アーキテクトたちは、特定のアジャイルデータウェアハウスのプロジェクトの初期の段階でこの論争を扱い、機能を最大化させるもっとも完全な形式で両方とも行われることを薦めました。いくつかのスプリントの後で、プロジェクトベロシティは、要求されているタイムラインに追いついていませんでした。これは、方法論に関わらずに共通の状態でした。アーキテクチャに関する変化が加速を助けられるかどうかを見るために、私は、4番目のスプリントで初めて現場の役割に参加しました。現場の作業と2つのチームの7人の専門家から活発な情報提供に基づいて明らかになったのは、正規化モデルを通して、ディメンショナルモデルにすべてのデータを任せるようにデータを動かすことは、ビジネスの目的に合わせるために必要ではありませんでした。(この特定のプロジェクトにとってであり、一般的には必ずしもそうではありません。) 私たちは、1年以上も正規化レイヤを計画してきました。それから、この新しい洞察に基づいて、私たちは、30日でこのレイヤを実現しました。マネジメントやアーキテクチャの統治を行う広範囲に渡る議論が必要とされましたが、次のスプリントまでにその変化が現れて、プロジェクトでは確実にベロシティが増加しました。

動くソフトウェア

各スプリントの後で、チームとプロダクトオーナーは、正式なスプリントレビューで動くソフトウェアを見せなければなりません。そうすれば、アーキテクトを含むステークホルダたちが、全体の進捗をよく見て、フィードバックを返せます。スプリントレビューでは多くのステークホルダたちは会話の時間を競い合うため、ほんの2、3時間で終わるでしょう。そのため、アーキテクトは、正式なレビューの数日前に動くソフトウェアをレビューし始めるべきです。このような場合、ソフトウェアにまだ作成中の部分があるかもしれませんが、正式なスプリントの終了日が近づくと、有意義なレビューに耐えうるほどソフトウェアは安定するでしょう。安定したアジャイルプロジェクトでは、動くソフトウェアと共にドキュメントを繰り返し納品することが求められます。これには、アーキテクチャに関するドキュメントも含まれ、ドキュメントのない動くソフトウェアやシステムの機能性は動くソフトウェアとはみなされません。各スプリントで示されるこのドキュメントのレビューは、アーキテクチャレビューの有効な方法です。もっと重要なのは、アーキテクトはコードとシステムの機能性に深く入り込んで、動くソフトウェアをレビューすべきだということです。

例えば、過去10年間に渡って、私は数百のスクリプトをためてきました。これらのスクリプトは、データウェアハウスプラットフォームやデータ処理アプリケーションのアーキテクチャ分析を自動化するものです。私のチームが動くソフトウェアをリリースするときに、私はこれらのスクリプトを動かします。そして、プラットフォーム、スキーマ、データモデル、データ品質、その他のデータアーキテクチャの様々な側面の健全性を完全に示す報告を数分で手に入れます。発見された問題は、現在のスプリントで対処されるか、または、適切なバックログに入れられます。プロセスの測定を手助けするために、私はチームにこれらのスクリプトを提供しています。そうすれば、チームは、私がいなくてもアーキテクチャの検査を自動で実施できます。必然的に、チームは私が見逃していた何か重要なチェックを行う貴重なスクリプトを持つことになります。私たちは、アーキテクチャ検査を自動化する最高に洗練された方法を用いて、お互いに一歩先に出ようとしながら、共にシステムのアーキテクチャの品質を向上させています。

アジャイルアーキテクトの技術

アーキテクトとしてこれらの相互作用のポイントに飛び込むのは、騒然たる経験となることでしょう。皆忙しく、開発者たちはアーキテクトを懐疑的に見るかもしれません。そして、良いアーキテクチャを無視することを正当だとするビジネスの優先順位が常にあるように見えます。混乱を最小化するために、非常に骨の折れる経験だけを最適化する数多くのちょっとした技術が必要です。その中で、上位4つの技術を紹介します。

スプリント用の形式に分解する

アジャイル開発では、プロダクトオーナーがユーザストーリーを分解することが求められます。ユーザストーリーは、ビジネスの価値を示すほど実体があるものでありながら、スプリントで実行できるぐらい小さなものにします。同様に、技術チームは、スプリント中に効率的に構築できる形までユーザストーリーを分解します。この分解に対してアーキテクトが貢献することは、アーキテクチャの重要性に境界を与え、分解の作業全体がこれらの境界に従っていることを確認するように、プロダクトオーナーと技術チームと共に取り組むことです。アーキテクチャの重要な境界は、ビジネスと技術的機能性の2つの集合の間にあります。ここでは、ハードウェアとソフトウェア、デザインパターン、そして、品質特性に大きな違いがあります。図2の2つの例を見てみましょう。

図2. 全員が、ユーザストーリーをスプリント用の形式に分解することに貢献します。アーキテクトは、これらの例に示されているように、アーキテクチャの重要性の境界に影響を及ぼすことによって、貢献します。数字は、作業量に応じて、スプリントやスプリントのまとまりを表します。

最初の例の中で、私たちはサービス指向アーキテクチャ(SOA)のプラクティスを使いながら、サードパーティのためにエンタープライズウェブサービスを構築しなければなりませんでした。このサービスプロジェクトチームは、サービスインタフェース、持続レイヤ、外部データ検索という3つの主要分野の技術的機能性まわりを構築する9つのスプリントのアプローチを使いました。最初2、3回のスプリントで、チームはサービスインタフェースを発表しました。サービスへのクライアントコールは、ハードコーディングされたレコードを1つだけ返すものでしたが、トランザクションはうまく定義された規約によって完全な機能サービスコールを経由しました。アーキテクチャに関して、このサービスインタフェースが取り組んだのは、Java、ウェブサービス標準、XML、そして、クライアントシステムにビジネスを示すスクリーンを構築するためのレコードを与えながらパターンを呼ぶことでした。スプリントの第2段階で、チームは、外部ベンダからではなく、ローカルのデータベースからサービスを100レコード返せるようにしました。そして、ビジネスレビューでより多くのケースを示しながら、データベース環境、データモデル、そして、オブジェクトリレーショナルマッピングレイヤに取り組みました。3段階目のスプリントでは、チームはサービスコールが外部ベンダに対して行うようにしました。ここで取り組んでいたのは、ファイアーウォールの問題、ベンダデータフォーマット、そして、潜在的な要求でした。早い時期から、サービスの機能性が増えることで、動いているソフトウェアに基づいた進捗を具体的に示しました。そして、チームはビジネスの目に見える価値を与えながら、技術的チャレンジの狭い範囲にチームが集中するようにしました。

2番目の例では、私たちは大きなデータウェアハウス環境を納品する必要がありました。ビジネスの視点から、データウェアハウスの納品物は、データ主体レベルでうまく分解するためにそのまま貸し出されます。そのため、適切に定義されたテーブル構造にちょうどよく合います。しかし、技術的な視点からテーブル内の属性はアーキテクチャに関する重大な違いがあり得ます。例えば、保険料と支払請求額は、ソースシステムから来る基本的な保険情報であり、関連する保険料と生じた支払い請求額は複雑な計算によるもので、これらの計算によってシステム全体を保証できます[13]。 ビジネスの視点では、保険料は1つのカテゴリであり、支払請求額は別のカテゴリです。アーキテクチャ的な視点では、基本データ属性は1つのカテゴリであり、複雑な計算は別のものです。これらの違いのバランスをとるために、チームは複雑さによって作業を分解し、もっとずっと複雑な属性をもっとゆっくりと進歩的に構築しながら、基本属性を素早く納品できます。

これらの例で一般的に[14]チームが必要だったのは、ビジネス中心の分解を第一アプローチとするように出来るだけ多く考慮することでした。しかし、効率的なプロジェクトの納品のために、アーキテクチャに関する境界は時々打ち破らなければなりません。アーキテクチャに関する境界全体で繰り返すことで、あまりにも多くの挑戦が同時に起こり、プロジェクトにリスクを与えるでしょう。私たちがデータウェアハウスの問題の中でしたように、例えば、9スプリントの端から端まで属性の9分の1を移動したことよって、SOAの例の中のデータの問題を分解しようとしたならば、チームは一度に数多くの新しい技術を扱わなければならなかったでしょう。ビジネス側が実際よりもずっと早く生のデータを見たがったとしても、これは大きな問題を引き起こしたことでしょう。

同様に、私たちがSOAの問題のように、データウェアハウスの例の中で技術レイヤの問題を分解することを試したならば、基本属性であっても、難しい属性と同じくらい遅くなったでしょう。そして、ビジネス側では出来る限り早くもっとも複雑な属性を見たがったとしても、ひどい納品遅れの原因になることでしょう。お互いに分解するアプローチを使うこれらの2つの例の無力さは、分解は納品物の性質に合ったものでなければならないことを示しています。

プロダクトオーナーの主張

分解された問題から動くソフトウェアへのパスはプロダクトオーナーを通して行われ、アーキテクトはプロダクトオーナーと共にアーキテクチャ的な作業の価値を増やすことを求められます。このことに関連するもっとも重大な2つの側面は、システム設計を作成してリファクタリングすることと、ビジネスの価値に関して、品質特性の価値を決めることに関係します。これらの側面はビジネスの機能性と競争するチームの時間を必要とします。プロダクトオーナーがアーキテクチャに関する作業の価値を理解しない場合、その作業はプロダクトバックログの中の優先順位がずっと低いままで、アーキテクチャの品質は低下するでしょう。

幸運なことに、設計作業は品質特性にほぼすべて直接貢献し、品質特性の改善はほぼすべてビジネスの価値になります。メンテナンス性によって、ビジネスの機能性が後のスプリントで素早く構築でき、システムの寿命をより速く拡張して、改善できるようになるでしょう。その結果として、より速く市場に出ます。拡張性によって、重要なマーケティングキャンペーンのピークに大きな問題が起きた時に、危機であってもビジネスのロスを防ぐ、速いパフォーマンスを提供するシステムになります。他にもいろいろあります。本来、良いアーキテクチャとビジネスの価値の結び付きは、アジャイル開発が唯一ではありません。しかし、アジャイル開発がプロダクトオーナーに与える力によって、頻繁に価値を明らかにするために、特に重要になります。そして、あまり目に見えない動くソフトウェアを作り出す傾向がある、アーキテクチャ的に重くてリバースするのが難しいコンポーネント[15]を構築することに高い価値がある場合、最初の数スプリントで起きるもっとも重要な主張があります。

例えば、私たちは300のデータエントリー画面を持つ予定のインターネットアプリケーションを開発していました。速い進捗を示し、ステークホルダの信頼を得るために、私たちは、最初の数スプリントで出来る限り多くの画面を開発することも出来ました。しかし、その代わりに、全画面において高度な再利用が可能である、柔軟な入力フィールド編集設計をチームで構築させるようにプロダクトオーナーを説得しました。これによって、初期のスプリントレビューで完成した画面は少なくなりましたが、システムのメンテナンス性は向上しました。プロジェクトが終わる頃には、非常に速く画面を作成できるようになりました。初期のアーキテクチャ関連作業の価値をプロダクトオーナーに注意深く説明し、こうすることを承認させなかったならば、この速さで画面は作成できなかったことでしょう。

アーキテクチャバックログ

すべてのステークホルダのように、アーキテクトは、プロジェクトベロシティで許されているよりも素早く製品に機能性を盛り込みたいと考えます。このため、(アーキテクチャ関連の)機能性をプロダクトバックログにいれる必要があります。プロダクトバックログの利用がすべてそうであるように、作業は優先度順に並べられます。そして、作業するのに十分な時間やお金がない場合は、その作業は実施されないかもしれず、結果として、妥協したアーキテクチャになるでしょう。確かに、アーキテクチャ関連作業が決して実施されることがないくらい優先順位が低ければ、アーキテクチャの質は低下します。しかし、プロダクトバックログの原則を適切に使い、プロダクトオーナーの適切な主張を受けることで、プロジェクトが終わる前に、価値の低いアーキテクチャ関連作業が起こる可能性はなく、非常に価値の高いアーキテクチャ関連作業が実施される結果になるはずです。

アーキテクチャへの焦点を明確にし、アーキテクチャ関連の評価を促進するために、アーキテクチャバックログと呼ばれる別々だけれどもつながっているプロダクトバックログが、アーキテクチャ作業を追跡するべきです。大抵の文書では、プロダクトバックログを1つだけ利用します。実際に、私は複数の物理的なプロダクトバックログの維持が役立つことを見つけました。それぞれのバックログは目的に応じたものですが、すべて1つの論理的プロダクトバックログとして集合的に使います。想定外のバックログは、ゴールではなく、おそらく決して実施されないウィッシュリストバックログであることを明らかにします。そのようなモジュール化は、全体像を失うことなく、メインバックログをできるだけ明瞭な状態にしておく手助けをします。このために、アーキテクチャバックログと共にあるのです。アーキテクチャバックログは、アーキテクトによってメンテナンスされ、適切な時と場所でプロダクトオーナーとチームに伝えられ、アーキテクトによって影響されたプロダクトオーナーの判断に基づいて、アイテムをメインバックログに移動させます。そして、特に役立つのは、そのようなアイテムを重要だとみなして、実行しながらプロジェクトのアーキテクチャ品質を評価することだと分かりました。そのような採点によって、プロダクトオーナーに明確で計測可能な仕組みを与え、プロダクトオーナーはアーキテクチャバックログからメインバックログへストーリーを移動して、そのストーリーを完了できるようになります。

増え続けるエンタープライズアーキテクチャ

ここまで私が主張してきたアーキテクチャへのアプローチで注目しているのは、プロジェクトを実施することです。これは、スプリント中に構築された動くソフトウェアが増え続けることから、正しい方向へシステムアーキテクチャを動かすアーキテクトのたった1つの最高の機会が得られるという仮定に基づいています。この方向に関する影響の多くは、プロジェクトのビジネスの目的に合うことに集中していますが、大企業への最大の価値には、エンタープライズアーキテクチャ(EA)の視点で、この指示を補足する必要があります。

ここで自分たちが決めた4つの機能を使い、アーキテクトが確実に以下の点を実施するプロセスとして、EAを定義します。

  • 同一のハードウェアとソフトウェアスタックから引き出す。
  • 同じデザインパターンとデザインパターン言語を活用する。
  • 同じ定義と同じ採点基準を用いて、同じ品質特性を採点する。
  • これらのことをそれぞれ外部と内部のシステムの両方で行う。
  • アーキテクト同士、そして、プロダクトオーナーとコミュニケーションする。

システム間の要求は、システムの相互作用によってデザインパターン[16]の新しいレイヤを導入する可能性があり、品質特性全体が変わるかもしれないという観察に基づいています。例えば、2つのシステムは個々に拡張できますが、相互に影響する場合は拡張しません。EAに関するこのような定義は大抵アジャイルとは無関係ですが、アジャイルの視点から、アーキテクト同士やアーキテクトから技術チームやプロダクトオーナーに対して必要とされるコミュニケーションや協力が重要だと言えます。

アーキテクト同士のコミュニケーションは、集中したEAプラクティスと正式なEAプロセスがあることで、もっともよく達成できます。シニアマネージャたちは、このプラクティスを作り出さなければなりません。確実にアーキテクト同士のコミュニケーションを促進・評価し、本気で優れたEAを手に入れる程の資金を出さなければなりません。一度形ができれば、このプラクティスは正式なプロセスとツールを確立します。具体的に言えば、アーキテクチャの運営委員会として、同一基準のアーキテクチャの採点方法や、問題を確認し、すぐに実施できる改善を行うピアレビュープロセス、そして、プロジェクトの作業から生まれた標準化を進める役割などがあります。しかし、常に2つの中心となるアジャイルの考慮点が影響力を持たなければなりません。1つは、ここは個人個人が協力し合うコミュニティであり、ただのプロセスや成果物の集合ではないことです。もう1つは、このプロセスの力は正式な権威ではありませんが、アーキテクトの専門知識とプロジェクト作業に直接参加することに由来する正当性が存在することです。

アジャイルチームとプロダクトオーナーのコミュニケーションは、物理的にアーキテクトを分散して、相互作用点でアーキテクトたちをEAの懸念事項に組み込ませることによって、最もよく達成できます。私がこれまで主張してきた集中活動は、重要であるけれども主要ではないアーキテクトの時間の一部です。アーキテクトは、チームやプロダクトオーナーと物理的に適切な場所にいて、出来る限り多くの時間を過ごようにするべきです。そうすれば、直接コミュニケーションする機会が多くなります。アーキテクトがプロジェクト作業のアーキテクチャの面を主張するならば、EAの懸念事項を組み入れなければなりません。例えば、特定のハードウェアと一連のソフトウェアを主張する場合、デザインパターンや品質特性と同様に、プロジェクトの必要性だけでなく、望ましいEAの方向性に基づかなければなりません。これは特にシステム間の懸念事項にとって重要なことです。アーキテクトは、システム間の力学を理解する唯一の位置にいますが、チームやプロダクトオーナーはそうではありません。そのため、アーキテクトは、隠れた問題を明らかにしたり、他の人たちは見つけないかもしれない幅広い機会を見つけたりする唯一の責任を持ちます。アーキテクトを含むすべての人たちが注目するのは、プロジェクトに資金が提供されたビジネスの機能性と、どのプロジェクトでも現れる短期的に実行するという挑戦です。しかし、EAのゴールに対する納得できる確固としたビジョンと、時を超えて各プロジェクトの各スプリントで優れたアーキテクチャが効果的に混ざり合うことで、EAの状態は着々と改善されることでしょう。

例えば、2009年に私の会社は、「アジャイルビジネスを理解するインフラストラクチャの創造」[17]というこの業界の賞を取りました。この会社は、2008年にビジネス上の理由からプロジェクトに資金を提供しましたが、EAのコミュニティでは2006年にこのアーキテクチャを考え出していました。それは、実際に納品する機会が現れる2年前でした。問題は、リサーチコミュニティがメインデータウェアハウスから隔離されたプラットフォーム上で運営されていたことでした。その結果、サイロ化され、データの重複が起こり、不適切な運用手続きが取られていました。同時に、メインデータウェアハウスは、研究者たちのニーズを満たさない技術を使い、リサーチ作業には厳しすぎる運用基準を持っていました。

長年、2つの部門で働き、特有の文化と環境を理解してきて、アーキテクトたちは妥協案を構築することを提案しました。その妥協案とは、データウェアハウスの運用手続きと中央化されたデータ資産に加えて、それぞれがリサーチャの順応性、システムのメンテナンス性、そして、運用の効率性のバランスをとるように順応する、リサーチプラットフォームの技術を使った1つのレイヤでした。EAの解決策は、2年間、ほっておかれました。プロジェクトがEAの解決策を進める機会を得ると、アーキテクトたちはプロジェクトに影響を及ぼし、その成功は会社と業界の両方で認識されました。そして、アーキテクチャの再利用性は、将来のプロジェクトにとって、とても魅力的なものになっています。

アジリティとアーキテクチャに優劣の差はありません。アジャイル開発は、アーキテクトにビジネスと技術チームと密接に働く機会を繰り返し与えます。そして、継続的にシステムが良いアーキテクチャの方向に進むようにします。そうすることで、挑戦を表し、方法論に関わらず優れたアーキテクチャを実現する困難さを内在したり、短期間の出来事を使って長期間の成果へと推し進めなければならない原因となったりします。アジャイル手法をここで示した視点へ簡略化して、重大な相互作用点で影響を与えることで、技術のあるアーキテクトは中心となるアーキテクチャの作業に集中したまま、アジャイル開発に順応できます。これによって、個々のシステムとエンタープライズの行動の集合は、今日のビジネスのニーズに合わせて、この先ずっと技術的に持続可能になるでしょう。これが、納品の方法論とは関係のない、アーキテクチャの価値に関する提案です。

著者について

James Madison氏は、大きな保険会社のシニアインフォメーションアーキテクトであり、エンタープライズアーキテクチャ部門のアジャイルトレーニングの第一インストラクタです。Madison氏のアジャイルプロジェクトに含まれるのは、ウェブ、フルクライアント、サービス指向アーキテクチャ、データウェアハウジング、そして、インフラストラクチャの構築やプラットフォームの移行などの従来アジャイルではないプロジェクトなどです。Madison氏はRensselaer Polytechnic Instituteのコンピュータサイエンス学科の修士号を取得しています。連絡先はmadjim@bigfoot.com


[1] K. Schwaber, Agile Project Management with Scrum, Microsoft, 2004 (邦題「スクラム入門-アジャイルプロジェクトマネジメント 」)

[2] K. Beck and C. Andres, Extreme Programming Explained: Embrace Change, 2nd ed., Addison-Wesley Professional, 2004 (邦題「XPエクストリーム・プログラミング入門―変化を受け入れる」)

[3] M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley Professional, 2002 (邦題「エンタープライズ アプリケーションアーキテクチャパターン 」)

[4] E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, 1995. (邦題「オブジェクト指向における再利用のためのデザインパターン」)

[5] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 2nd ed., Addison-Wesley Professional, 2003, pp. 71–98 (邦題「実践ソフトウェアアーキテクチャ」)

[6] R. Kazman, M. Klein, and P. Clements, ATAM: Method for Architecture Evaluation, tech. report CMU/SEI- 2000-TR-004, ESC-TR-2000-004, Software Eng. Inst., Carnegie Mellon Univ., 2000.

[7] M. Poppendieck and T. Poppendieck, Lean Software Development: An Agile Toolkit for Software Development Managers, Addison-Wesley Professional, 2003, pp. 38–45, 103–111. (邦題「リーンソフトウエア開発~アジャイル開発を実践する22の方法~」)

[8] K. Schwaber and M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2002, pp. 23–30 (邦題「アジャイルソフトウェア開発スクラム 」)

[9] R. Kimball and M. Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling,” John Wiley & Sons, 2002, pp. 78–88

[10] V. Subramaniam and A. Hunt, Practices of an Agile Developer: Working in the Real World, Pragmatic Bookshelf, 2006, pp. 155–157 (邦題「アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣」)

[11] M. Fowler, “Who Needs an Architect?” IEEE Software, vol. 20, no. 5, 2003, pp. 11–13

[12] M. Ross and R. Kimball, “Differences of Opinion,” Intelligent Enterprise, 6 Mar. 2004

[13] J. Madison, Very Large Calculation Systems, Casualty Actuarial Soc., 2009

[14] J. Shore and S. Warden, The Art of Agile Development, O’Reilly, 2008, pp. 214. (邦題「アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング 」)

[15] M. Fowler, “Who Needs an Architect?” IEEE Software, vol. 20, no. 5, 2003, pp. 11–13.

[16] G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addison-Wesley Professional, 2003

[17] “Best Practices in Business Intelligence: Creating an Agile BI Infrastructure,” Computerworld, 2009; 

この記事は最初にIEEE Software マガジンに掲載されました。IEEE Software 使命は、先頭に立つ将来のソフトウェア実践者たちのコミュニティを作ることです。このマガジンは、エンジニアやマネージャたちが急激な技術の変化に遅れないように、信頼できて役に立つ最先端のソフトウェア開発の情報を提供しています。

 

 

 

この記事に星をつける

おすすめ度
スタイル

BT