序文:親愛なるすべてのアーキテクトに
ア ーキテクチャ ジャーナル へようこそ。今号のテーマは ”ソフトウェア ファクトリ” です。
20 世紀初頭、生産ラインを初めて取り入れた工場が建設されましたが、その開拓者の 1 人に Henry Ford がいます。彼が取り組んだ仕事の多くは、注目に値するものでした。なぜなら、製品の価格を下げながら、作業者の生産速度を高めたからです。 100 年ほどの月日が流れた今日、同様の経緯を繰り返し、我々の業界では ”アプリケーション” という言葉が日常的に使われるようになっています。
この領域での考え方を最初に広めた書籍に 『Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools (ソフトウェアファクトリ : パターン、モデル、フレームワーク、およびツールによるアプリケーションの組み立て)』 、 Jack Greenfield 他 (Wiley、2004 年) があります。この本に概説されている構想に基づいて、我々は幸運にも Jack Greenfield、Steve Cook 両氏の共同執筆記事を紹介できる運びとなりました。
記事 「剥き出しの言語」 で、 Jack はドメイン特化言語 (DSL) がソフトウェア ファクトリ方法論においてどのように役割を果たし、この方法論を利用する際に陥りやすい落とし穴をどう回避するのかについて説明しています。 Jack の記事では、この論点における新機能についても紹介します。以前より、本誌読者の皆様から、尊敬される著名なソフトウェアアーキテクトの経歴について多数のお問い合わせをいただいておりました。今回、 Jack には主要な記事を書いてもらったばかりでなく、彼とひざを交えて話しをする機会を持ち、彼の経歴について詳細を知ることができました。今号からの新たなコラム 「アーキテクトプロフィール」 に概要を示していますので、ぜひ、ご覧ください。このコーナーを楽しんでいただくことができたら、たいへん嬉しく思います。また、これからの ”アーキテクチャジャーナル” でプロフィールを知りたいアーキテクトなどについて、皆様からのご意見やご要望をお待ちしております。
Steve Cook 氏の記事では、 DSL を使用して大きな問題を小さな問題に単純化する方法について深く掘り下げて説明します。ソフトウェアファクトリプラットフォームでのアプリケーションについても取り上げています。続いて Marcel de Vries 氏が、ソフトウェアファクトリのテーマである、製品開発で改善を要する局面を判断するのに必要なレポート機能とウェアハウス機能について論じます。
”アーキテクチャジャーナル” の寄稿者として復帰した Tom Fuller 氏は、再利用可能なプロセスやその他の戦略的プロセスを促進するソフトウェアファクトリの柱の根幹について説明します。 Tom の記事に続き、EDS の Steve Eadie 氏がグローバル システム インテグレータ (GSI) の視点から見たソフトウェア ファクトリの実装について論じます。 Steve は、開発チームが世界各地に分散している状況下でソフトウェア ファクトリを使用することについて、 GSI の立場から考えを述べています。
最後に、 Lewis Curtis 氏と George Cerbone 氏が、パースペクティブベース アーキテクチャに関する彼らの考えについてのアウトラインを説明します。プロジェクトについて ”正しい質問をする” ための 1 つのテクニックとして、要求分析手法が紹介されています。
Henry Ford の革新への思いを胸に、今回の ”アーキテクチャジャーナル” が、形状、規模、特性にかかわらず、あらゆる要望に応えたソフトウェアを提供できるような、ソフトウェア ファクトリおよび生産ラインの構築に役立つことを願っています。
Simon Guest
なお、本ジャーナル日本語版では特別寄稿として、日本のソフトウェアファクトリの先駆者として高名な、松本 吉弘 氏 (現在、財団法人・京都高度技術研究所顧問) の記事 「ソフトウェア開発における人の知識・能力・コミュニケーション」 を掲載しております。
アーキテクチャ ジャーナル - 第 9 号 : ソフトウェア ファクトリ - の内容
.jpg) | 「剥き出しの言語」、すなわちモデル化すべきでないもの DSL は単独で使用しても役に立つ言語ですが、どのような場合に使用し、どのような場合に使用すべきでないかなどについて、だれもが熟知しているとは限りません。陥りやすい落とし穴を回避しつつ有用な資産を構築するときに、DSL がソフトウェア ファクトリ方法論においてどのように役割を果たすかについて説明します。 |
| |
| |
.jpg) | ドメインに特化したモデリング DSL の本質は、大きな問題を小さな問題に単純化することです。専用の DSL をソフトウェア ファクトリ プラットフォームとオーサリング環境に組み込む方法を見いだします。 |
| |
| |
.jpg) | ソフトウェア ファクトリ 4 本柱の根幹 今日のソフトウェア開発が直面する問題への対策として戦略的プロセスが一般化しています。プロダクト ライン方法論を導入して、資産の再利用を促進し、アーキテクチャ駆動型開発などの戦略的プロセスを導入する方法を検討します。 |
| |
| |
.jpg) | ソフトウェア ファクトリ 4 本柱の根幹 今日のソフトウェア開発が直面する問題への対策として戦略的プロセスが一般化しています。プロダクト ライン方法論を導入して、資産の再利用を促進し、アーキテクチャ駆動型開発などの戦略的プロセスを導入する方法を検討します。 |
| |
| |
.jpg) | GSI の視点から見たソフトウェア ファクトリ ユーザー満足度を維持しながら生産性を高めることが求められています。この目標は業種を問わずあらゆる規模の企業に当てはまる世界的な関心事です。開発者が各地に分散している状況下での、グローバル システム インテグレータ (GSI) におけるソフトウェア ファクトリ アプローチの可能性を探ります。 |
| |
| |
.jpg) | パースペクティブベースアーキテクチャ手法 技術革新に伴い、組織は費用効率を考慮した決定を速やかに行うことが求められています。一方で、IT 環境と新しいビジネスソリューションの連携は、ますます複雑化しています。構造化された重点的な問題への取り組みを通して高品質の意思決定を促進する PBA 手法を使用して、企業の戦略的思考を体系化します。 |
| |
| |
.jpg) | ソフトウェア開発における人の知識・能力・コミュニケーション プロセスの工業化および自動化の取り組みが前進しつつあるとは言え、同時に以前にも増して設計者の存在が重要です。ソフトウェア ファクトリを有効に活用するために必要となる、設計者の知識・能力・コミュニケーションの果たす役割について考察します。 |
| |
| |