原文：http://www.agiledata.org/essays/vision.html

この記事は、Agile Database Techniques Chapter 6より抜粋。

データは明らかにソフトウェアに基づいたシステムの重要な側面であり、その事実は情報技術(IT)産業が何十年も把握していたことだ。しかし、多くの組織が彼らのソフトウェア・プロセス内でデータへ取り組むのに四苦八苦している。広範囲の組織で働く特権を持っているコンサルタントとして見れば、10の組織のうち約1つがデータ指向の活動への取り組みに成功しているといえるだろう。 10のうち約6つは、自分たちはうまくやっていると考えているが実際にはそうではなく、そして残りは、組織が問題を抱えているというかなりよい考えを持っているが、そのことについて何をすればいいのかは分かっていない。これはあるべき姿ではない。

さてどのようにして問題を抱えていることを知るのだろうか。企業データ専門家は、データアーキテクトおよびデータ管理者の両方を含んでいるが、プロジェクト・チームの開発者が彼らの助言や標準やガイドラインや企業モデルを無視するという事実に不満を持つだろう。なお悪いことには、開発者はそういった人々や物事のことをそもそも知らないなんてことがしばしばある。開発者は、企業データ専門家が単純そうに見える変更を加えたり認可したりするペースが氷漬けであると認識し (まったくその通りであることもしばしばだが)不満を持つだろう。データベース管理者(DBA)は交戦中のこれら2党派の間に挟まれてしまうこともしばしばで、治安を守ろうと努力しながら自分たちの仕事を行おうとする。もしこういった問題の1つ以上が珍しくないような組織であれば、問題を抱えているということなのだ。

アジャイルデータ(AD)方法論のゴールは、ソフトウェア・システムのデータ面に関して効果的に一緒に働くために、種々様々な状況にIT専門家が適用することができるような戦略を定義することだ。これは、ADが「1つのサイズがすべてに適合する(one size fits all)」方法論であると言っているのではない。そうではなくて、組織内のIT専門家がソフトウェアに基づいたシステムのデータ面に関しては効果的に一緒に働くことができる、そんな哲学の集合がADなのだと考えて欲しい。確かにこの本はIT専門家が仕事に適用することができるような立証された技術も示しているが、ADの肝はその根本的な哲学にある。なぜAD手法を採用しなければならないか理解するためには、以下のトピックを熟考することが必要だ。

1. なぜ一緒に働くことが現在困難なのか

データ専門家と開発者の関係はさまざまな組織で多くの場合理想に満たない。もちろんこれらの2つのコミュニティーがとても効果的に一緒に働いている組織もあるが、そこには常に緊張がある——グループ間に存在するのが健全な緊張であれば組織に役立つこともあるが、不運にも、両者の違いはしばしば健全でない矛盾につながる。下にリストされたすべての問題を組織が経験するとは限らないかもしれないが、部分集合には恐らく苦しむだろう。データ専門家および開発者が克服しなければならない困難は次のものを含むだろう:

ビジョンおよび優先事項の違い。開発者はしばしば一つのプロジェクトの特定の要件に集中し、しばしば組織の残りからできるだけ孤立して働こうと努力する。 DBAは彼らが責任を負うデータベースに集中し、しばしば変更を最小限にすることでデータベース「保護」しようとする。データ管理者およびデータ・アーキテクトはしばしば企業の全面的なデータ要件に集中し、プロジェクト・チームの差し迫った要件を事実上排除する。明らかに各グループの範囲が異なり、優先事項が異なり、扱うべき問題が異なる。さらに悪いことに、直接のユーザから上級管理職までを含むプロジェクトの利害関係者たちも同様に、さまざまな優先事項およびビジョンを持っている。
役割の過剰な特殊化。専門家には狭い範囲に集中しすぎるようになる傾向があり、ソフトウェア開発の小さな1部分に関してすべての知るべきことを知ろうとして他のすべてを気に止めなくなることがある。データ正規化を聞いたことがないか、なぜそのようなことを行いたいか理解しようともしないような上級Java開発者や、ユニファイド・モデリング・ランゲージ(UML)のステートチャート図を読めないデータアーキテクトが見つかることは本当に珍しくない。過度に専門化されていると他のIT専門家と関係を持つのがしばしば困難である。アジャイルモデリング(Ambler 2002a)の根本的な哲学は、IT専門家がソフトウェア・プロセス全体についての一般的な理解を持っているべきであり、かつ1つ以上の専門を持っているべきということだ。ジェネラリストなので「ソフトウェア・ゲーム」に関係する問題の広範囲を適切に理解し、同時に彼らのチームに提示するべき専門的で価値のある技術を持っている。単に専門家か、彼らは単にジェネラリストであるような人々は領域の崖っぷちにいる。世の中のほとんどのことと同じく、それら2極端の中間にあるスイートスポットを見つけるほうがはるかによい。
プロセスのインピーダンスミスマッチ。ユニファイド・プロセス(Kruchten 2000; Ambler 2001b)、エクストリーム・プログラミング(Beck 2000)、スクラム(Beedle&Schwaber 2001)、 DSDM(Stapleton 1997年)、クリスタル・クリア(Cockburn 2001b)、そしてアジャイル・モデリング(Ambler 2002a)のようなそれらプロセスが共通して持っている少数のものの一つは、それらすべてが反復的で漸進的なやり方で仕事をするということだ。不運にもデータ・コミュニティー内の多数はまだ、ソフトウェア開発を直列かほぼ直列のプロセスとして見ている。ここには明白にインピーダンスミスマッチがあり、データ・コミュニティーが彼らのアプローチを再考する必要があることを示している。この本を読めばデータに対し反復的で漸進的なアプローチをとることが可能であると分かるだろうが、それは文化的・組織的な変更を組織に要求するような変更なのだ。
技術のインピーダンスミスマッチ。開発者はオブジェクトとコンポーネントを用いて仕事をする。しかし、データ専門家はデータベースとファイルで作業する。ソフトウェア工学の原則は、オブジェクトとコンポーネント用の根本的な基本のパラダイムを形成する。しかし、集合論は、リレーショナル・データベース(間違いなく最もポピュラーなデータベース技術)用の根本的な基本のパラダイムを形成する。根本的なパラダイムが異なるので、技術は完全には一緒に働けず、インピーダンスミスマッチがある。このミスマッチは克服することができるが、そうするためには重要なスキル群(この本によってカバーされた別のトピック)が必要だ。
硬直した管理。 IT専門家によって使用される技術や技法は急速に変化する。この事実は誰もがとてもよく知っていることだ。人々が企業階層を上へ進むにつれて、扱う問題は技術的なものがより少なく、人的なものがより多くなる。マネージャーになるという最終結果では技術的な端を失ってしまう。問題は、彼らの以前の開発経験(彼らが技術的な決定をする基盤となる経験)がもはや適用可能ではないかもしれないということだ。手続き的な技術からオブジェクト指向の技術に移行した時、我々は業界としてこのことを見た—— COBOLプロジェクトに関するよい決定だったかもしれないものは、Javaプロジェクトにとっては破滅のもとであると判明することもしばしばだ。我々がアジャイルソフトウェアプロセスに移るとともにはっきりもう一度この問題を見るだろう。管理は時勢とともに変化する必要がある。
組織的な困難。個人間およびグループ間の貧弱なコミュニケーションあるいは政治のようなよくある問題は、それらが他の努力を傷つけるのと同じくらいひどくソフトウェア開発のデータ面を傷つける。
貧弱なドキュメンテーション。ほとんどのドキュメンテーションは、1つの極端あるいは別の極端にあるように見える: ほとんどなかったりまったくなかったりするドキュメンテーションか、あるいは誰も読むものがないほど過度に複雑なドキュメンテーションか。開発の基準およびガイドラインに相互に一致していれば、レガシー・システムのドキュメンテーションやレガシー・データベース・ドキュメンテーションや企業モデルは、よく書かれた時に価値のある資源になるだろう。アジャイルドキュメンテーションは間違いなく成功のために重要だ。
効果がないアーキテクチャ上の努力。ほとんどの組織はエンタープライズアーキテクチャーに対しては著しい困難に直面する。これはどこからスタートするべきかも知らないような最も一般的な困難だ。バイアスがかかり、企業の1つの視点に過度に注目するエンタープライズアーキテクチャーは、組織の実際の要件を十分に解決しないアーキテクチャーに結びつく。 Zachmanフレームワークが示すように、考慮したい多くの潜在的ビュー(Zachmanは不運にもコンポーネントと呼ぶが、これは意味が多すぎる用語だ)があり、このコンセプトはアジャイルモデリングの’‘複合モデル’‘原理に獲得された。これらのビューはデータ、機能/プロセス、ネットワーク、人々、時間、動機づけだ。’'’象牙の塔アーキテクチャー、つまりプロジェクト・チームの日々の現実から立ち退いたチームによって形式化されたものは、紙上ではよく見えるが不運にも実際には失敗する。エンタープライズアーキテクチャー・モデルによって課された制約に開発者が不本意ながら準拠することは、そのようなモデルが存在することを開発者が知っているだけでも、さらによくある重大な問題だ。
効果がない開発ガイドライン。多くの組織が、すべてのIT専門家が従って働くような開発ガイドライン集に苦戦する。この理由は多くある。たとえば、そのようなガイドラインに従う必要を理解しない人々、誰か別の人によるガイドラインに従いたくない人々、過度に複雑なガイドライン、過度に単純化したガイドライン、特定のプラットフォームでは不適当なガイドラインに結びつく「1つのサイズがすべてに適合する(one size fits all)」的な姿勢、そして長い期間をかけてガイドラインを発展させることを嫌う姿勢。有効なガイドライン集が利用可能であるならば、そして誰もがそれらを適切に理解して適用するならば、 IT取り組みの生産力を劇的に改善することができる。
効果がないモデル化の取り組み。以前に示したいくつかの問題の結果こうなることもしばしばだ。開発の特定の面に注目した人々は、その狭い視界の優先事項を素晴らしく反映するが他の視点の現実を考慮に入れていないモデルをしばしば生み出すだろう。企業データ・モデルは、組織が要求するデータの優れたビジョンを示すかもしれないが、組織のデータ、機能、使用法および技術的な必要条件を反映する企業モデルは、はるかにもっと役立ちそうだ。 UMLのクラス図は、単一のプロジェクトの要件を反映するかもしれないが、アクセスするレガシー・データソースの現実を反映していなければ、それは実際上価値がほとんどない。モデラー、そして一般のIT専門家は、一緒に働いて本当に有効な完全な図面を見る必要がある。

1.1 問題があるという警告信号

組織にとっては問題を有することを否定することは非常に容易である。手遅れになる前に上級管理職が問題を検出することは非常に困難である場合もある。聞くべき「悪いニュース」は彼らに届くずっと前にろ過されるからである。組織の他の所にいる人々が問題を検出することは困難である場合もある。彼らの意見では多分、すべてはかなりうまくいっている—— 不運にも彼らが状態を判断するのに使用している価値システムは理想的でなく、それらが起こしている問題について盲目にする。以下は潜在的な徴候のリストである。各々が、あなたの組織に一つ以上の課題があることを示すかもしれない。アジャイルデータ手法はそれら課題に対処するのを助けるかもしれない:

人々は一つ以上のグループの努力にかなり失望する、またはその努力に欠ける。
ソフトウェアは開発されないか、または開発されれば長くかかりすぎる。
責任追及が起こる。「データ管理者は進歩を遅らせている」または「開発者は組織の方針に従っていない」がよく見られる不平である。なお悪いことに、責任追及者は彼らもまた問題の一部分であることに気づかない。
ソフトウェアに基づくシステムを開発し、保守し、サポートするために緒に働くことより、政治問題により高い優先順位が与えられる。
進行中の確執が人々/グループの間にある。「あなたはいつも…」及び「あなたは決して…」のようなフレーズは確執があることの非常によい手がかりである。
あなたの組織内の有名な問題が対処されようとしない。なお、改善案は無視されたようであり、何も起こらず、拒絶の理由は提供されない。
人々はほとんどあるいは全く報酬なしで過度に長時間働いている。
チームに、とりわけプロジェクトチームに影響を与える決定は、外見上恣意的で横柄な方法でなされる。

私達は効果的に一緒に働く方法を見つける必要がある。データのコミュニティと開発者のコミュニティとの間、そしてプロジェクトのコミュニティと企業のコミュニティとの間には明確な違いがある。私達が異なったコミュニティについて述べているという事実もまた問題の一部であり、恐らく間違いなく根本的原因のひとつである。あなたは基本的な決定をしなければならない。あなたの組織内の既存の問題を悪化させるのに弁解としてこれらの相違を使用するべきか、またはこれらの相違を大いに楽しみ、それらを利用する方法を見つけるべきか。私は後者を好む。私の経験は、アジャイル・ムーブメントの価値そして原則が、一緒に働くための有効なアプローチの基礎を形作るということである。

2. アジャイル・ムーブメント

ソフトウェア開発者が直面した困難に対処するために、 17人の方法論学者の最初のグループは2001年の2月にアジャイルソフトウェア開発アライアンス (www.agilealliance.org)を結成した。これはしばしば単にアジャイル・アライアンスとも言われる。このグループについての興味深い事は、皆異なった背景から来たことと、それでいながら方法論学者たちが普通同意しない問題(Fowler 2001a)についての同意を得られたことである。この集団はソフトウェアを開発するよりよい方法を奨励するための宣言を定義し、その宣言に基づいて、アジャイル・モデリングのようなアジャイルソフトウェア開発プロセスのための規準を定義する原則集を作り出した。

2.1 アジャイルソフトウェア開発宣言

宣言(Agile Alliance 2001a) は4つの簡単な価値声明によって定義される—— 理解するべき重要な事は、右側の概念も評価するべきであるが、 (イタリック体で示される)左側の事をさらにもっと評価するべきであることである。宣言について考えるよい方法は、これが好みを定義することであって代替案ではなく、ある区域への着目を奨励するけれども他を除去するものではないということである。アジャイル・アライアンスは以下を評価する:

個人や相互作用をプロセスやツールよりも重んずる。チームの人々がソフトウェア・システムを構築し、また、それをするために、彼らは相互に有効に働く必要があります—— プログラマー、テスター、マネージャー、モデラーおよびあなたの顧客を含みますがそれらだけに限ってはいません。誰がよりよいシステムを開発するだろうとあなたは考えますか: 5人のソフトウェア開発者が自分のツールをもって一つの部屋でともに働く場合と、あるいは5人の未熟な「ハンバーガー調理係」が十分に定義されたプロセス、利用可能な最も精巧なツール、および金で買うことができる最良のオフィスをもって働く場合では？プロジェクトがまあまあ複雑だった場合、私の金はソフトウェア開発者上に賭けます。あなたは？ポイントは、考慮すべき最も重要な要素は人々で、彼らがどのようにともに働くのかということです。なぜなら、あなたがきちんと理解していないのであれば、最良のツールおよびプロセスはちっとも役に立たないからです。誤解しないでほしいのですが、ツールとプロセスは重要です、ただそれらはともに有効に働くことほど重要ではないというだけです。古い格言を思い出してください、ツールを備えたフールはやはり馬鹿です。これは管理職には受け入れがたいことなのでしょう、なぜなら彼らは人々と時間が(すなわち人と月が)交換可能である(Brooks 1995)としばしば信じたいからです。
動くソフトウェアを分厚いドキュメントよりも重んずる。何を造るつもりであるかを説明する50ページのドキュメントと実際のソフトウェア自体とどちらが欲しいかをユーザに尋ねるとき、彼らはどちらを「選ぶ」と思いますか？私の推測は、100回のうちの99回は動くソフトウェアを選ぶということです。これが実情であるなら、ソフトウェアを速く頻繁に生産し、ユーザに好みのものを与えるようなやり方で働くことはより多くの意味をなすことになりませんか？その上、内部動作や用法の抽象化について説明する複雑で技術的な図よりもかなり簡単にあなたが作り出すソフトウェアをユーザが理解できるのではないかと私は疑いますが、どうでしょうか。ドキュメンテーションには適した役割があり、適切に書かれていれば、システムがどのように、なぜ構築されているか、そして、システムをどのように扱うかを人々が理解するための貴重なガイドです。しかしながら、ソフトウェア開発の主要なゴールがドキュメントではなくソフトウェアを作成することであることを忘れないでください—— そうでなければ、それはドキュメンテーション開発と呼ばれるものではないでしょうか。
顧客との協調を契約上の駆け引きよりも重んずる。あなたの顧客だけが、彼らが何を望むかあなたに伝えることができます。ええ、恐らく彼らは正確にシステムの仕様を決める技術を持っていません。ええ、おそらく彼らは最初から正しくそれをするわけではありません。ええ、おそらく彼らは気が変わるでしょう。顧客との共同作業は困難ですが、それが仕事の現実です。顧客と契約を結ぶのは重要ですし、皆の権利と責務を理解することはその契約の基礎を形成するかもしれません。しかし、契約はコミュニケーションの代用品ではありません。成功している開発者は彼らの顧客と共に密接に働き、彼らの顧客が必要とすることを発見する努力を注ぎ込み、道に沿って顧客を教育します。
変化に対応することを計画を硬直的に守ることよりも重んずる。人々はさまざまな理由で彼らのプライオリティを変えます。仕事があなたのシステムの上で進行するにつれて、問題領域とあなたが造っていることに関するあなたのプロジェクトの利害関係者の理解は変化します。ビジネス環境は変化します。技術は時間変化しますが、常により良くなるわけではありません。変化はソフトウェア開発の現実、あなたのソフトウェアプロセスが反映しなければならない現実です。計画案を持つことは間違っていません。実際、それを持っていなかったならばどんなプロジェクトも私は心配でしょう。しかしながら、計画案は融通が利くもので、あなたの状況が変化するのに従ってそれを変える余地がなければなりません。そうでなければ、あなたの計画は急速に無関係になります。

これらの価値声明についての興味深い事は、ほとんど皆が直ちに同意するけれども、実践ではめったに支持しない何かがそこにあるということだ。上級管理職は、従業員こそがあなたの組織の最も重要な面であると常に公言するけれども、 ISO-9000準拠のプロセスに従い、スタッフを取り替え可能な資産として扱うよう主張する。なお悪いことに、プロジェクトチームに従うように主張したプロセスに準拠するために十分な資源を提供することを管理職はしばしば断る。ソフトウェアの作成がソフトウェア開発の基本的な目的であることにはだれもが容易に同意するのに、単に袖まくりしてそれを造るかわりに、ソフトウェアが何であるか、そしていかに造られるだろうかを記述するドキュメンテーションを作り出すことに数ヶ月も費やすよう主張する。おわかりだろうか——人々はある事を言いながら別の事をする。これは今すぐ停止しなければならない。アジャイル・モデラーは言ったことをするし、すべきことを言う。

2.2 アジャイルソフトウェア開発の原則

アジャイルソフトウェア開発とは一体どんなものなのかを人々がよりよく理解するのを助けるために、アジャイル・アライアンスのメンバーは宣言に含められた哲学を、アジャイルモデリング(AM)のようなアジャイルソフトウェア開発方法論が同意するべき12の原則集に精製した。それらの原則集は：

価値のあるソフトウェアをできるだけ早い段階から継続的に引き渡すことによってお客様の満足度を高めることをもっとも優先します。
要件の変更は例え開発の後期であっても受け入れます。アジャイル･プロセスは変化を味方につけることによってお客様の競争力を引き上げます。
動くソフトウェアを数週間から数か月というできるだけ短い時間間隔で繰り返し引き渡します。
ビジネスをする人と開発者はプロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。彼らが必要とする環境と支援を与え、仕事が無事終わるまで彼らを信頼してください。
開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果的な方法は、面と向かって話をすることです。
動いているソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。スポンサー、開発者、ユーザは一定のペースで永続的に保守できるようにしなければなりません。
卓越した技術と優れた設計に対する不断の注意こそが機敏さを高めます。
単純さ——作業せずに済む量を最大限に引き上げる技量——が本質です。
最良のアーキテクチャ、要件、設計は、自己組織的なチームから生み出されます。
どうしたらチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

ちょっと立ち止まってこれらの主義について考えよう。これはあなたのソフトウエアプロジェクトを実際に機能させるような方法か？これはプロジェクトが機能するはずであるとあなたが考えるような方法か？原則をもう一度再読しなさい。それらは何人かの人々が主張するように過激で不可能なゴールなのか、それらは無意味にごもっともな声明なのか、またはそれらは単に常識なのか。これらの原則が常識の基礎を形作り、成功するソフトウェア開発のための努力はそれを基にすることができると私は信じる。 IT専門家のデータ指向の努力を指示するのに使用することができる基礎。

3. アジャイルデータの哲学

最初にして最大のポイントは、アジャイルデータ手法はアジャイル・アライアンスの価値と原則に同意するということだ。このアドバイスはスタート地点としてとてもよいものではあるが、前に書いた問題を解決する哲学にまで拡張される必要がある。アジャイルデータの哲学とは:

データはソフトウェアに基づいたシステムのいくつかの重要な面のうちの1つです。
開発チームは、企業の問題に関して適切に考慮し行動しなければなりません。
企業グループは、企業の資産を育み、かつ組織内で開発チームのような他のグループを支援するために存在します。企業グループは、顧客の期待および顧客が働く方法を反映した、アジャイルなやり方をとるべきです。
各開発プロジェクトはユニークで、そのニーズに適合した柔軟なアプローチを要求します。1つのソフトウェア・プロセスはすべてに適合するとは限りません。また、したがって、データの相対的な重要性はアドレスされている問題の性質によって異なります。
IT専門家たちはともに有効に働き、そうすることを困難にする挑戦を克服するために積極的に努力しなければなりません。
どのような問題であれ、「スイートスポット」を見つけるために、つまり黒い極端および白い極端[1]を回避して、あなたの全体的状況のために最適な灰色を見つけるために積極的に努力するべきです。

面白い観察結果は、これらの哲学のほとんどがデータに特有ではないということだ。代わりにそれらは一般的な情報技術の努力に適用可能だ。第一原則が暗示するように、単なるデータではなく全体像を見る必要がある。したがって、データに特有の法則は恐らくあまり役立たないだろう。これは異端だろうか? いいや。単なる常識だ。

4. アジャイルデータ早分かり

アジャイルデータ手法は4つの役割——アプリケーション開発者、アジャイルDBA(Sadalage&Schuh 2001年)、企業管理者および企業アーキテクト——を定義します。これでIT専門家はカバーできるでしょう。これらの役割、また、それらがどのように相互に働くかは、アジャイルデータの役割に、より非常に詳しく議論されます。テーブル1は、IT専門家のためのアジャイルデータ手法の意味あい(アジャイルデータの役割でカバーされる意味あい)を要約します。

表 1. IT専門家のための意味あい。

役割	意味あい
全員	誰でも彼らが何を遂行しようとしているか、また、それらをどうやって遂行するのかに関しての共通のビジョンに同意しなければなりません。アジャイルソフトウェア開発者は喜んで他のものと仕事をし、必要であれば同じ場所に配置します。ドキュメンテーションはソフトウェア開発の現実です。あなたのアプローチにおいてアジャイルであることを選んでください。アジャイルソフトウェア開発者は1つ以上の専門を持ったジェネラリストであるために努力します。1つの「プロセスサイズ」がすべてに適合するとは限らないので、アジャイルソフトウェア開発者は彼らのアプローチにおいて柔軟です。ソフトウェアがあなたの主要なゴールです。次の努力を可能にするのはあなたの第2のゴールです。
アプリケーション開発者	アプリケーション開発者は、プロジェクトの利害関係者と緊密に仕事をしなければなりません。アプリケーション開発者は、レガシー・システムとデータベースが彼らに制約を置くことを認識しなければなりません。アプリケーション開発者は彼らの組織の標準およびガイドラインに従い、喜んでそれらの継続的な発展へフィードバックを行なうべきです。アプリケーション開発者は、企業アーキテクト(プロジェクト・チームの活発なメンバーになるべき人々)と一緒に仕事をするでしょう。
アジャイルDBA	データ指向開発の努力を実行し支援するために、アジャイルDBAはアプリケーション開発者と非常に緊密に仕事をします。ちょうどアプリケーション開発者がやるのと同じように、アジャイルDBAは喜んで反復しインクリメンタルなやり方で働くべきです。アジャイルDBAは、かつ企業のmetaデータ、標準およびガイドラインを利用し、発展させることを支援するために、企業管理者と仕事をするでしょう。
企業管理者	データ資源管理より企業管理に多くの意味があります。企業管理者の主要なゴールは、プロジェクト・チームの努力を支援して、企業の全面的な必要を反映した解決策へチームをガイドすることを支援することです。企業管理者は、官僚政治家の人工的な必要ではなく開発者の実際の必要を反映する、柔軟な標準およびガイドライン集を開発し支援します。企業管理者は、現在の環境によって課された制約を連絡するために、組織の中の他の人々を支援し、ともに仕事をします。
企業アーキテクト	企業アーキテクトは単なるデータ・アーキテクチャー以上のものに注目します。企業アーキテクトは反復しインクリメンタルなやり方で働きます。企業アーキテクトは、プロジェクト・チームと積極的に協力し、アーキテクチャーを伝えて、プロジェクト・チームにアーキテクチャーおよびモデル化の技術を指導し、そしてアーキテクチャーを発展させるために使用する実際世界のフィードバックを獲得します。

5. アジャイルデータは私たちの問題を解決するか?

するべき重要な質問は、ソフトウェア開発のデータ面において組織が直面する問題に、哲学および示唆された文化的変更が対処するのどうかだ。テーブル2は、アジャイルデータ手法によって示唆された潜在的な問題および解決をリストし、事実は間違いなくこうだと示す。

表 2. 個々の問題はどのように対処されるか。*

Problem	Solution
異なるビジョンおよび優先事項	アジャイルデータは、あなたの同僚の見解を理解して尊重し、ともに働くようにIT専門家に嘆願します。
役割の過剰な特殊化	アジャイルデータは、1つ以上の専門を持ったジェネラリストになることで、ジェネラリストであることと専門家であることの両極端の間にある「スイートスポット」を探すようにIT専門家に依頼します。
プロセス・インピーダンス・ミスマッチング	アジャイルデータは、インクリメンタルで反復するアプローチ、最も現代の開発用の標準、およびアジャイルソフトウェア開発のためのデファクトスタンダードに従って働く準備ができるように企業とデータの専門家に嘆願します。さらにアジャイルデータは、現在の環境および組織のための将来のビジョンを認識し、彼らの努力に制約を設置するようにアプリケーション開発者に嘆願します。
技術インピーダンス・ミスマッチング	アジャイルデータは、IT専門家たちがともに緊密に働き、そうしながら互いから学習することを必要とします。アジャイルDBAは、データ指向のコードを書くためにアプリケーション・スキーマをデータ・スキーマに写像し、それらの成果物のパフォーマンスをチューニングする技術を持っています。
硬直した管理	アジャイルデータは、上級管理職とともに仕事をし、かつ現代のソフトウェア開発の現実の中で彼らを教育してくれるように企業アーキテクトに依頼します。同様に、アプリケーション開発者はラインおよび中間管理職の両方とともに働き、彼らを教育することを支援するべきです。
組織的な挑戦	アジャイルデータは、IT専門家にプロジェクトの利害関係者と互いに働き、彼らを尊重し、かつともに有効に働くために積極的に努力するように嘆願します。
貧弱なドキュメンテーション	アジャイルデータは、アジャイルドキュメンテーション(Ambler 2002a)の法則に従うようにIT専門家に命令します。
効果がないアーキテクチャの努力。	アジャイルデータは、アーキテクチャーへの多重視界/モデルアプローチをとり、かつそれらのアーキテクチャーを支援し証明するために、プロジェクト・チームに積極的に作用するように企業アーキテクトに助言します。その後、これらの努力からのフィードバックはアーキテクチャーの将来の繰り返し開発で反映されているべきです。
効果がない開発ガイドライン	アジャイルデータは、企業管理者に明瞭で、有効で、適用可能な標準とガイドラインを書き、かつ開発チームからのフィードバックに作用する準備ができているように嘆願します。
効果がないモデル化の努力	アジャイルデータは、アジャイルモデリング(Ambler 2002a)方法論の法則および慣習に従うようにIT専門家に命令します。

6. 参照

7. 脚注

[1] エクストリーム・プログラミング(XP)にあてつける意図はまったくない。XPは正しい状況下では非常に効果的なソフトウェアプロセスだ。

2004-10-14 (木) 13:06:54 六 : お礼いうの忘れた、早速の反応有難う御座います。私は英語がからっきしなので今後の充実楽しみにしています。ザッパのかつての邦題はここが詳しいですよ。http://homepage.mac.com/club_k2/zappa/album_list.html
2004-10-14 (木) 12:49:53 六 : うーん慣用表現でしたか、残念。カッコ付きだしもしかして、と思ったのですが。ところで万物、いい邦題だと思うんですけどねぇ、廃止になって残念。
2004-10-14 (木) 11:04:37 猪股 : “one size fits all”は、英語では「フリーサイズ」を表す言葉として普通に使われているみたいです。なので元ネタがザッパ師匠かどうかはわかりませんが、アルバムの邦題が「万物同サイズの法則」だったと知って興味深いです。
2004-10-14 (木) 10:56:50 六 : はじめまして、blikiに続き、楽しみに拝見しております。ところで大した話ではないんですが、「1つのサイズがすべてに適合する」の箇所の原文はもしかして「one size fits all」でしょうか？だとしたら、多分ですが、元ネタはフランク・ザッパというミュージシャンのアルバム・タイトルだと思われます。その場合、かつての邦題である「万物同サイズの法則」と訳すと、一部の人が（もしかしたら著者の方も）喜ぶかも知れません。
2004-10-06 (水) 17:43:47 kdmsnr : ありがとうございます!!!!!
猪股 - 以前訳したものです。機械翻訳に毛が生えた程度ですし、語尾もそろってませんが、こっそり載せておきます。