ソフトウェアファクトリー（Software Factory）とは、関連するソフトウェア資産の構造化された集合体であり、特定の外部インタフェース定義に従ったソフトウェアアプリケーションまたはソフトウェアコンポーネントの製造を助ける。ソフトウェアファクトリーは、製造業の技法と原則をソフトウェア開発に適用するもので、それによって製造業の長所を模倣しようとするものである。また、ソフトウェアファクトリーは、一般にソフトウェア製造のアウトソーシングと関係が深い。ソフトウェア工学とエンタープライズアーキテクチャやソフトウェアアーキテクチャにおいて、ソフトウェアファクトリーは、さまざまなツール、プロセス、コンテンツを定型的な方式で設定するソフトウェアであり、フレームワークに基づいた適応・組み立て・設定により原型となるソフトウェア製品からの派生品の開発と保守を自動化するものである。コーディングは、（製造業における職人のような）専門的技量を必要とするので、アプリケーション層ではコーディングの必要性を排除し、IDEを使う代わりに事前定義されたコンポーネント群を組み合わせることでソフトウェアを構築する。コーディングは、新たなコンポーネントやサービスを開発するときのみ必要とされる。製造業と同様、コンポーネント（部品）の開発とシステムの構築には、技術が必要である。ソフトウェアファクトリーによって得られるのは、である。ソフトウェアファクトリーは、従来のアプリケーション開発において、似たようなアプリケーションの開発で得られた知識や資産を生かしていなかったという問題への対処である。ソフトウェアファクトリー以外にも、トレーニング、文書化、フレームワークといった対策がとられてきたが、さまざまなアプリケーション開発で得られた貴重な知識の伝達という意味では、間違いやすいプロセスでもある。ソフトウェアファクトリーは、特定スタイルのアプリケーション開発の成果を再利用しやすいパッケージ内に統合することで、この問題に対処する。適切なソフトウェアファクトリーを使ったアプリケーション開発には、生産性や品質の向上、機能の発展性といった多くの長所がある。個々のソフトウェアファクトリーは特定種類のアプリケーションの構築に特化しており、そのために設計された独自の資産を含む。一般に、多くのソフトウェアファクトリーは次のような相互に関連する資産を含む。ソフトウェアファクトリーによる製品構築には、以下のような活動が関与する。ソフトウェアファクトリーによるアプリケーション開発は、従来のソフトウェア開発に比べて様々な利点がある。これらの利点は、以下に示すように関係者の立場によって異なる価値を提供する。ビジネスタスクを簡素化できるため、ユーザーの生産性を増大させることができる。これは、一貫した共通のユーザーインタフェースを使うことにより達成され、エンドユーザーのトレーニングの必要性を低減させる。また、新たな機能の配備が容易であり、ユーザインタフェースが柔軟であるため、エンドユーザーは、ビジネスワークフローに従った方法でタスクを実行することができる。さらに、データ品質が改善されるため、コピー・アンド・ペーストなどでアプリケーションのパーツ間でデータをコピーする必要性が低減される。アーキテクトにとっては、アプリケーションやシステムの設計にソフトウェアファクトリーを使うことで、品質と一貫性を向上させることができる。最重要な機構と共通の要素だけを含む部分的な実装が可能なためである。これは、ベースラインアーキテクチャなどと呼ばれるもので、設計と開発を容易にし、アーキテクチャ上の決定を明確化し、開発の初期段階でのリスクを低減させる。また、ソフトウェアファクトリーは、一貫した予測可能な形でビジネスコンポーネントを開発・パッケージ・配備・更新することができ、ビジネスロジックとは独立なアーキテクチャ上の標準を実施可能である。開発者は、ソフトウェアファクトリーを使うことで、立ち上がり時間を短縮して、生産性を増大させることができる。これは、コードとパターンを含むアプリケーションの高品質な出発点（ベースライン）を作成できるからである。つまり、これは、プロジェクトが従来の開発方式より高いレベルから始まることを意味する。また、再利用可能な資産、ガイダンス、例などにより、典型的なシナリオやタスクに容易に対応でき、一貫した形で応用することができる。ソフトウェアファクトリーは、アプリケーションの複雑さを隠蔽する抽象化層を提供し、関心を分離する。そのため、個々の開発者は、ビジネスロジックやユーザインタフェースなどそれぞれ異なる分野に集中でき、根底にあるサービスについて深い知識を必要としない。ソフトウェアファクトリーで構築されたアプリケーションは、操作が一貫しているため、習得がしやすい。そのため、共通のビジネス要素とモジュールを容易に展開でき、また一連のアプリケーションを通じて、一貫性のある構成管理が可能である。アプリケーションは、相互に組み合わせ可能なアーキテクチャになっており、運用チームが基本的なサービスを制御することができる。ソフトウェアファクトリーという概念については、いくつかの対照的な見方があり、ツール指向な見方やプロセス指向な見方などさまざまである。以下では、日本、ヨーロッパ、北米で生まれた見方について解説する。このアプローチのソフトウェアファクトリーで生み出されたソフトウェアは、主に原子炉、タービンなどの制御システムである。主な目的は生産性に見合った品質の確保であり、コストが増大しても競争力が弱まらない分野に適用された。また、設計・プログラミング・テスト・インストール・保守を一貫した形で実施するための環境を整備するという目的もある。品質と生産性向上の鍵は、ソフトウェアは再利用である。組織的設計では、運用業務を規定通りな簡単で反復的なものにする断固とした努力を含み、業務プロセスの標準化を伴う。代表例として、東芝が適用したソフトウェアファクトリーの概念があり、1981年と1987年に論文が発表されている。EUREKAプログラムの下で資金提供された Eureka ソフトウェアファクトリーと呼ばれるものである。ヨーロッパの大企業、コンピュータメーカー、ソフトウェアハウス、研究機関、大学がプロジェクトに参加している。個別の供給業者が販売するコンポーネント群を集積してソフトウェアファクトリーを構築するために、技術、標準、組織的サポート、その他の基盤を提供することを目的としている。統合開発環境のアーキテクチャとフレームワークを生み出すことを目的としている。汎用ソフトウェアファクトリーは、その一部となるコンポーネント群や生産環境だけでなく、ソフトウェアコンポーネントの標準とガイダンスも開発する。ゴダード宇宙飛行センター (NASA) のソフトウェア工学研究所で開発された。このアプローチの目的は、「生産環境におけるソフトウェアプロセスを理解し、入手可能な技術の影響を判定し、改良した技法を開発プロセスに吹き込むこと」である。生産環境で新技術を試し、それによって得られた経験とデータを適用し、コスト、信頼性、品質への影響を測定した。このアプローチは、継続的な改良に主眼が置かれており、プロセス特性と製品品質の関係を理解することで改良していく。長所と短所を把握することで、その後のプロジェクトで活用できる経験を蓄積する。能力成熟度モデルで定義されたもので、予測可能で信頼できる、自律的に改善するソフトウェア開発プロセスを達成するフレームワークを生み出すことを意図していた。その戦略は、ソフトウェア開発組織の段階的改善から成り、どの工程が開発における鍵であるかを定義する。測定可能な範囲に留めようとするので、開発工程と品質は予測可能となる。ソフトウェアファクトリーという用語を最初に採用したのは日立製作所で、1969年のことである。その後、1975年には、 System Development Corporation などの企業が採用した。1976年から1977年にかけて、日本電気、東芝、富士通といった企業が追随した。Cusumano はソフトウェアファクトリーを6つの段階に分けられるとした。マイクロソフトの Software Factory は、2004年に発表したソフトウェア開発工程の進化を目指したビジョンに基づいており、.NET Framework の一部である。Microsoft Patterns & Practices Team は以下の4つのソフトウェアファクトリを開発している:Project Glidepath はマイクロISV指向のソフトウェアファクトリー。マイクロソフトからもリリースされている。EFx Factory は Microsoft Services が他に先駆けてリリースしたアーキテクチャ的ソフトウェアファクトリーであり、モデル駆動開発と統合実行環境ツールによってサービス指向の企業アプリケーションを構築する。.NET Database Application Development日本では、2006年11月27日、京都高度技術研究所が「ソフトウェアファクトリ研究会」を発足させた。これは、マイクロソフトの動きに直接関係したものではないが、マイクロソフトの動きに刺激されて、かつての「ソフトウェア工場」のコンセプトが甦ってきたものと言える。ソフトウェアファクトリーに対しては批判も多く、生産性が劇的に向上するはずがないとする見方もある。

出典:wikipedia