アーティファクト (ソフトウェア開発)

ソフトウェア開発におけるアーティファクト（英: artifact、成果物）は、ソフトウェア開発過程で生成される副産物である。一部のアーティファクト（例：ユースケース、クラス図、要件定義書、設計書）は、ソフトウェアの機能、アーキテクチャ、設計を記述するのに役立つ。その他のアーティファクトは、プロジェクト計画、ビジネスケース、リスク評価など、開発プロセスそのものに関わるものである。

ソフトウェア開発に関連する「アーティファクト」という用語は、主に特定の開発手法やプロセス（例：統合プロセス）と結びついている。この用語の使用は、それらの手法に由来する可能性がある。

ビルドツールでは、テスト用にコンパイルされたソースコードをアーティファクトと呼ぶことがよくある。これは、テスト計画を実行するために実行ファイルが必要となるためである。テスト対象の実行ファイルがない場合、テスト計画のアーティファクトは非実行ベースのテストに限定される。非実行ベースのテストにおけるアーティファクトは、ウォークスルー、インスペクション、正当性の証明である。一方、実行ベースのテストには、少なくとも2つのアーティファクト、すなわちテストスイートと実行ファイルが必要である。「アーティファクト」は、生成されたリリースコード（コードライブラリの場合）やリリース済み実行ファイル（プログラムの場合）を指すこともあるが、より一般的には、製品そのものではなくソフトウェア開発の副産物を指す。オープンソースのコードライブラリには、貢献者が自分の変更によってコードライブラリにリグレッションバグを引き起こさないことを確認できるよう、テストハーネスが含まれていることが多い。

アーティファクトと見なされるものの多くは、ソフトウェアドキュメンテーションである。

エンドユーザー開発において、アーティファクトは、一般的なプログラミング言語の知識を必要とせずにエンドユーザーによって作成されたアプリケーション、または複雑なデータオブジェクトである。アーティファクトは、データベース要求や文法規則^[1]、あるいはユーザー生成コンテンツのような、自動化された動作や制御シーケンスを記述する。

アーティファクトの保守性は様々であり、主にそのアーティファクトが果たす役割によって左右される。その役割は、実用的なものか象徴的なもののいずれかである。ソフトウェア開発の初期段階では、請負業者がプロジェクトのニーズを満たすことにどれほど真剣であるかをプロジェクトスポンサーに示すという、象徴的な役割を果たすために設計チームによってアーティファクトが作成されることがある。象徴的なアーティファクトは、情報の伝達能力は低いことが多いが、見た目は印象的である。象徴的なアーティファクトは、情報アーキテクチャ業界において「彩飾された巻物（illuminated scrolls）」と呼ばれることがある。これは、その装飾が理解を深めるのに何の役にも立たないためである。一般的に言えば、象徴的なアーティファクトは、その象徴的な品質を維持するために多大な労力を要するため、保守不可能と見なされることもある。このため、象徴的なアーティファクトは、プロジェクトスポンサーに提示され承認された後は、実用的な役割を果たすアーティファクトに置き換えられる。実用的なアーティファクトは通常、プロジェクトのライフサイクル全体を通じて維持される必要があり、そのため一般的に高い保守性を備えている。

アーティファクトは、成果物（デリバラブル）として、プロジェクトマネジメントの観点から重要である。ソフトウェアプロジェクトの成果物は、アーティファクトにソフトウェア本体を加えたものとなる可能性が高い。

副産物としてのアーティファクトという意味合いは、科学において、問題そのものではなく、実施中のプロセスから生じる何か、すなわち目的ではなく手段に由来する関心対象の結果を指すために「アーティファクト」という用語を使用するのと似ている。

アーティファクトを収集、整理、管理するために、ソフトウェア開発フォルダが利用される場合がある。