 |
アーキテクチャ・ジャーナル アーキテクトが必要ないということはない！ Joseph Hofstader2008/10/20 |
|
|
| 本コーナーは、マイクロソフトが季刊で発行する無料の技術論文誌『アーキテクチャジャーナル』の中から主要な記事をInsider.NET編集部が選び、マイクロソフトの許可を得て転載したものです。基本的に元の文章をそのまま転載していますが、レイアウト上の理由などで文章の記述を変更している部分（例：「上の図」など）や、図の位置などを本サイトのデザインに合わせている部分が若干ありますので、ご了承ください。『アーキテクチャ ジャーナル』の詳細は「目次情報ページ」もしくはマイクロソフトのサイトをご覧ください。 記事の著作権はマイクロソフトに帰属する。
© 2008 Microsoft Corporation. All rights reserved. |
|
■概要
最近、ソフトウェア開発におけるアーキテクトの役割が非難の的になることが多くなっています。ソフトウェアプロジェクトでは、アーキテクトという肩書きは明確に定義されていないことが多く、アーキテクトの貢献度は容易に数値化できません。アーキテクトが " 象牙の塔" の住人でソフトウェア ソリューションを提供するという現実から切り離されているという認識が、アーキテクトという肩書きの人間に対する嫌悪の背景にあります。
この記事では、ソフトウェア開発におけるアーキテクトの仕事の弁護を展開します。有能なアーキテクトの資質を定義し、この仕事で成功するために必要なスキルについて説明します。この記事では、アーキテクトに対する否定的な見方に加担している一般の認識とアーキテクトが犯す誤りを考察します。究極の目的は、有能なアーキテクトがソフトウェアの開発過程にもたらす価値を示すことです。
■連中は何者なのか
情報技術の分野では、アーキテクトという肩書きほどむき出しの感情をかき立てるものはありません。アーキテクトという用語の定義について、数多くの討論に居合わせ、参加してきました。私が会議で自己紹介すると、反応は「恐れ多い」から「アーキテクトは必要ない」までいろいろあります。前者は友好的ですが、アーキテクトの高慢なイメージを反映しています。後者はアーキテクトの知識やスキルが無用であることを意味します。どちらもアーキテクトを本当に理解していないことを示しています。
2005 年の OOPSLA 会議で、Grady Booch が主催した「Birds of a Feather (類は友を呼ぶ)」(BOF) に出席したときのことです。トピックは彼が立ち上げ準備をしていた「Handbook of Software Architecture (ソフトウェア アーキテクチャの手引き)」でした。それに関係する話として、出席者の 1 人が IT と建築の両方で体験したアーキテクトとの否定的な経験の話を披露しました。1 つは、自宅の増築の設計図を作成したアーキテクトについての話でした。設計ソフトウェアで設計図を表示して調べたところ、数フィートの違いがあり、実際の建築ではそのアーキテクトの仕様に従うことができず、従わなかったということでした。彼が言いたかったことは、しかるべき立場にある多くの人々によって繰り返し言われてきたことですが、アーキテクトが具体的な成果物を提供するという現実から切り離されているということ、そしてアーキテクトの仕事は製品の開発に実際に取り組んでいるエンジニアや建築業者に任せておくべきだということです。
その会議とその後に他の人たちと交わした多くの会話から、私はソフトウェア製品に対するアーキテクトの役割は一体何なのか、有能なアーキテクトの特徴は何なのかといったことを考えるようになりました。私が行き着いた最も簡潔な定義は、IT アーキテクトの役割は、テクノロジを駆使して実装可能なシステムを定義することによって問題を解決することです。有能なアーキテクトは、拡張性があり維持管理しやすいソリューションを目指して、抽象的な知識と確かな手法を一連のテクノロジに応用することによってシステムを定義します。
この簡潔な定義の延長上には、有能なアーキテクトは土台となる知識を活用することによって成功を収めるということがあります。"問題を解決する" には、アーキテクトは問題領域をよく理解する必要があります。"テクノロジを使用したシステムの定義" は、アーキテクトに技術的な洞察力があることを意味しています。"抽象的な知識" には、技術的なソリューションを概念化する能力が要求されます。"確かな手法" は、似たような問題の解決に使用されたパターンを理解できることを前提とします。図 1 は、アーキテクトの重要なスキルを示しています。
 |
| 図 1: アーキテクトの主要スキル |
プロジェクトにアーキテクトがもたらす重要な利点は、堅牢なソフトウェア ソリューションの定義と開発にこれらのスキルを応用できることです。有能なアーキテクトは、ソフトウェア開発プロジェクトのすべての段階において貢献します。それには、問題領域の知識やソフトウェア ソリューションを概念化する能力といった問題空間の定義に不可欠のスキル、さらには適切なテクノロジとパターンを使用してソリューション空間を定義する能力が要求されます。製品開発にアーキテクトが積極的に参加しない場合、製品の開発に時間がかかる、適切に開発されないといったリスクが高くなります。図 2 は、アーキテクトのスキルが応用される開発プロジェクトの段階を示しています。
 |
| 図 2: ソフトウェア開発の段階とアーキテクトのスキル |
プロジェクトを成功に導くアーキテクトのスキルについて説明するのは、見かけより簡単ではありません。多くの領域、特に技術的な洞察力とパターンは、よくアーキテクトに必要な経験のレベルとの関係で議論されます。次のセクションでは、問題空間とソリューション空間に分けて、これらの各スキルの説明とこれらのスキルがソフトウェアの開発過程でアーキテクトの存在をかけがえのないものにする理由を説明します。
 |
| INDEX | ||
| ［アーキテクチャ・ジャーナル］ | ||
| アーキテクトが必要ないということはない！ | ||
 |
1．アーキテクトは何者なのか | |
| 2．問題空間で求められるアーキテクトのスキル | ||
| 3．ソリューション空間で求められるアーキテクトのスキル | ||
| 4．アーキテクトが注意しなければいけないこと | ||
 |
||
 |
「アーキテクチャ・ジャーナル」 |
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
