ITパスポート単語帳 - システム開発技術

情報システムとは、コンピュータなどの情報機器、ソフトウェア、通信ネットワークなどを組み合わせ、組織の活動の中で人間が日常的に行う情報の記録や参照、加工、伝達などの作業を効率的に行うことができるようにする仕組みである。

システム開発はそのようなシステムを新たに作り出し、利用者が業務で実際に使用可能な状態にするまでの一連の活動を指す。企画や構想、設計、製造や実装、試験、機材等の調達、現場への導入といった工程の組み合わせで、通常は専用のソフトウェアを新たに作り出すソフトウェア開発を伴うものをこのように呼ぶ。

システム開発手法

システム開発の工程(プロセス)は古くから様々な手法が研究・実践されてきているが、大きく分けて伝統的な「ウォーターフォール型」(ウォーターフォールモデル)と、近年急速に発展・普及している「アジャイル型」(アジャイル開発)に区分される。

ウォーターフォール型は要求定義、要件定義、基本設計、詳細設計、実装、テスト、納品・導入といった工程を順番に進めるモデルで、各工程を完了してから次の工程を開始し、原則として前の工程には戻らない。水が上から下に流れる滝(waterfall)になぞらえた名称で、大規模システムの開発では現在でも一般的に用いられる。

アジャイル型はこれらの工程を一度で全部終わらせようとせず、細かい対象範囲や期間ごとに繰り返していく手法の総称で、部分ごとに設計・実装・試験を繰り返す「インクリメンタル型」と、最初に荒削りに全体を組み上げ、機能の追加や修正を繰り返して完成度を高めていく「イテレーティブ型」(反復型開発)に分かれる。

システム開発事業

企業や官公庁などがシステム開発を行う場合、自社内の部署や人員によって行う内製と、外部の専門的な企業などに発注する開発委託のいずれかが行われる。また、状況によっては既成のパッケージソフトやクラウドサービスなどを購入・契約し、システム開発(ソフトウェアの新規開発)を伴わずに情報システムの導入・更新を行う選択肢もある。

日本では1950～60年代のコンピュータシステムの普及期以来、大企業や官公庁の多くがシステム開発を専門とする企業に開発業務を丸ごと委託する商慣行が定着しており、委託先の大手企業は「システムインテグレータ」(SIer：System Integrator)と呼ばれる。

インテグレータ自身はシステムの設計や開発プロジェクトの管理、顧客対応などに専念し、実際のプログラミングなどの業務の多くを協力企業(下請け企業)に再委託するという建設業界のゼネコンに似たビジネスモデルを確立している。

システム要件定義では、利用者がそのシステムで何がしたいのかを元に、それを実現するために実装しなければならない機能や、達成しなければならない性能などを開発者が検討して明確にしていく。

まとめられた成果は「要件定義書」として文書化されることが多い。一般的にこの段階では「何が」必要なのかを定義するに留め、それを「どのように」実現するかは後の工程で検討される。

主に利用者側の視点から業務手順を明確化して分析し、情報システムで何がしたいのかをまとめる工程と、これを元に開発者側の視点からシステムが何をすべきか、何が必要かをまとめる工程に分割して考える場合もあり、前者を(狭義の)要件定義と区別して要求定義と呼んだり、両者とも要件定義内の工程として業務要件とシステム要件と呼び分けたりする。

主に大企業などが専門の事業者にシステム開発を委託する際に用いられるウォーターフォール型の開発モデル(前工程を完全に終わらせて次工程に移る方式)では、システム要件定義はプロジェクトの最初に一度だけ行われ、これを元にシステムの仕様や設計が固められる。

一方、アジャイル開発など同じ工程の流れを循環的に繰り返す反復型の開発モデルでは、前の反復で作られた半完成品に触れながらシステム要件定義を繰り返し、段階的に要件を明確化・詳細化していく手法が用いられる場合もある。

システムが備えるべき機能や動作、振る舞いを定義したもので、システムが何を扱うのか、何を行うのか、利用者や外部システムに対してどのように振る舞うのかといったことを定める。扱うデータの種類や構造、処理内容、画面表示や操作の方法、帳票などの出力の形式などが含まれる。

これに対し、機能面以外の要件を「非機能要件」(non-functional requirement)と呼び、性能や信頼性、拡張性、運用性、セキュリティなどに関する要件が含まれる。

システム開発における要求分析や要件定義などの工程で主に検討されるのはシステムの機能や動作、振る舞いを定義する機能要件で、システムが何を扱うのか、何を行うのか、利用者や外部システムに対してどのように振る舞うのかといったことを定める。

しかし、機能要件だけでは求めるシステムの定義としては不完全であり、システムに求められる特性や動作の前提条件などを非機能要件として定義する。例えば、可用性について何の要件も定めなければ、要求された機能は確かに動作するが装置の一部が故障すると即座にシステム全体が停止してしまう脆弱なシステムが納品される事態が起こりうる。

情報処理推進機構(IPA)の発行している「非機能要求グレード」では、大項目として「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つを定義し、それぞれについてさらに詳細な項目とレベルを定義している。

また、日本情報システム・ユーザー協会(JUAS)が発行した「非機能要求仕様定義ガイドライン」では、非機能要件を「機能性」「信頼性」「使用性」(操作性や習得の容易さなど)「効率性」(計算資源・時間を効率よく使っているか)「保守性」「移植性」「障害抑制性」(障害の発生・拡大のしにくさなど)「効果性」(投資対効果など)「運用性」「技術要件」(システム構成や開発手法など)の10種類に分類して定義している。

システム開発を委託する場合などに、発注元と委託先の担当者が集まり、委託先の作成した仕様書や設計書などを共同で検証し、発注元の求める要求が過不足なく反映されているかなどを確認する。内容に双方が合意すれば、委託先は実際の開発作業に取り掛かることができる。

契約条件によっては、要件定義や設計などの初期段階だけでなく様々な段階の成果物について共同レビューを実施することもある。また、発注元と委託先だけでなく、社内の情報システム部門と利用部門(ユーザー部門)など、立場や利害の異なる複数の組織間で行われるものが含まれる。

2011年に策定された国際標準のISO/IEC 25010では、ソフトウェアの品質を「明示された状況下で使用されたとき、明示的ニーズ及び暗黙のニーズをソフトウェア製品が満足させる度合い」と定義し、これを評価するための8つの特性、さらに細分化された31の副特性を挙げている。

8つの特性は「機能適合性」(functional suitability)、「性能効率性」(performance efficiency)、「互換性」(compatibility)、「使用性」(usability)、「信頼性」(reliability)、「セキュリティ」(security)、「保守性」(maintainability)、「移植性」(portability)で構成される。

国際規格のISO 9241-11では、使用性を「特定の利用状況において、特定の利用者によって、ある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、利用者の満足度の度合い」と定義している。漠然とした「使いやすさ」よりは限定された概念で、ある人がある状況下である目的を達することがどれくらい容易であるかを表している。

使用性は利用者への情報やメッセージの提示の仕方やタイミング、言い回し、操作要素や選択肢の提示の仕方、操作の理解のしやすさや結果の想像しやすさ、操作のしやすさや誤りにくさ、誤操作に対する案内や回復過程の丁寧さ、利用者の操作に応じた表示や状況の変化(インタラクション)などの総体で構成される。

高い使用性のために必要な実践は対象の種類(機器・ソフトウェア・Webページ等)や想定される利用者の属性、文脈や利用目的によって異なるため個別性が高く、ある状況では良い事例とされたものが別の文脈では悪い事例になる場合もある。

開発者が期待する使用性が備わっているかどうか確かめるには、利用者(やそれに近い属性の人物)の協力を得て実際に使ってみてもらい、想定通りの操作が行われるか、利用者が不満や戸惑いを感じないかなどをテストするのが有効であるとされる。このような試験を「ユーザーテスト」(user testing)あるいは「ユーザビリティテスト」(usability testing)という。

人工物について信頼性という場合、定められた条件(製造元の指定する定格値など)下で一定の期間(耐用年数など)、期待される機能を提供し続けることができる性質を表す。

修理不能な製品の場合は故障や破損のしにくさがそのまま信頼性とみなされ、平均故障率(FIT：Failure In Time)や平均故障時間(MTTF：Mean Time To Failure)などの指標が用いられる。修理可能な製品では平均故障間隔(MTBF：Mean Time Between Failures)などで表され、保守性(maintainability/serviceability)を含んだ概念となる。

信頼性にいくつかの性質を加えて、システムが期待された機能・性能を安定して発揮できるか否かを検証するための評価項目として用いる場合がある。よく知られるのは信頼性に可用性(Availability)と保守性(Serviceability)を加えた「RAS」で、これに完全性(Integrity)と機密性(Security)を加えたものは「RASIS」という。

一般的には基本設計や外部設計の一部として方式設計の後に行われ、要件定義で定められた機能を実現するためにシステムを機能ごとに分割し、それぞれに求められる外部仕様を策定していく。

画面のレイアウトや遷移、操作方法をなどを定める画面設計や、システムが取り扱うデータやファイルの仕様やデータベースの設計、発行する帳票の設計などを行うことが多い。

実装の前段階

実装の前段階で行われる場合は、内部設計や機能設計などで定義されたシステムの構造や仕様などをプログラム単位に分割し、各プログラムの動作を定義していく工程を意味することが多い。この意味の場合は「プログラム設計」とほぼ同義とされる。

UMLのアクティビティ図やシーケンス図、クラス図などを用いてプログラムの挙動や構造を図示する場合や、プログラムコードにほぼ相当する内容を自然言語で記述する場合などがある。

プログラム設計の前段階

プログラム設計の前段階で行われる場合は、基本設計や概要設計で定められた機能や操作・表示方法などに基づいて、システムとしてそれをどう実現するかを具体的に定めていく。

システムをどのような構成にするか、それぞれの部分がどのような処理を行うべきか、それら部分間の連携・統合の方法などを決めることが多い。この意味の場合は「内部設計」とほぼ同義とされる。

狭義には、プログラミング言語やそれに相当する仕組みや道具を用いて、人間が読み書きしやすい形式のプログラム(ソースコード)を記述していく「コーディング」(coding)作業を指す。広義には、その前後に行われる、設計や試験(テスト)、修正(デバッグ)、実行形式や配布形式への変換(コンパイルやビルドなど)といった一連の作業を含む。プログラミングを行う人や職種のことを「プログラマ」(programmer)という。

プログラムの作成

プログラミングを行うには、まず何をするプログラムを作るのかを明確に定義し、仕様や要件を自然言語で記述したり、大まかな処理の流れを箇条書きやフローチャートなどの図表を用いて設計する。集団でソフトウェア開発を行う場合はプログラムの記述者とは別の設計者が専門に作業を行い、仕様書や設計書などの形でまとめる場合もあるが、個人が小規模のプログラムを作成する場合はこの工程を頭の中で行い、作業や手順としては省略する場合もある。

どんなプログラムを作りたいか決まったら、これをコンピュータが解釈できるプログラミング言語を用いてソースコードとして記述していく。言語やプログラムの記述法には様々な種類があるが、手続き型の言語(手続き型プログラミング)の場合、実行すべき命令を先頭から順に書き下していく。必要に応じて、複数の命令をひとまとめにして名前をつけて呼び出せるようにしたり(関数やサブルーチンなど)、条件分岐や反復(繰り返し)などで命令の流れの制御を行う。

プログラムの実行

ソースコードそのものはコンピュータ(の処理装置)が解釈・実行できる形式ではないため、これを機械語(マシン語)のプログラムなど実行可能な形式に変換する必要がある。ソースコードを機械語などのコード(オブジェクトコード)に変換する工程をコンパイル(compile)と呼び、プログラムの起動処理やライブラリなど実行に必要なコードを連結する工程をリンク(link)という。これら一連の工程を行って実行可能ファイルやパッケージを作ることをビルド(build)という。

スクリプト言語(軽量言語)などの場合はこうした明示的な変換工程は不要で、ソースコードを機械語に変換しながら同時に実行するインタプリタなどの処理系で直に実行することができる。記述したコードをすぐ実行でき手軽だが、変換しながら実行するため実行可能ファイルを生成する場合より実行速度やメモリ効率では劣る。

プログラムの修正

作成したプログラムが一度で完全に思い描いたとおりに動作する場合もあるが、大抵は何らかの誤りや不具合を抱えているものである。このため、ビルドしたプログラムを実行してみてテスト(動作試験)を行い、仕様通りに動くか調べる。

誤り(バグ)が発見されると原因や解決策を考え、正しく動作するようにプログラムを書き換える(デバッグ)。バグには単純な記述ミスのようなものから、そもそも解くべき問題に対して選択した計算手順(アルゴリズム)が合っていないといった根本的なレベルのものまで様々な種類がある。

デバッグ作業が完了したら再びビルドとテストを行い、誤りが正されていることを確認する。このビルド→テスト→デバッグの繰り返しによって次第にプログラムの完成度や品質が上がっていき、実際に実用可能なプログラムに仕上げることができる。実際のプログラミングにおいては作業時間の多くがこの繰り返しの工程に費やされる。

ソフトウェア開発の場合には、プログラムの仕様や構造を定めた仕様書や流れ図などの資料、あるいは頭の中に思い浮かべた処理の流れやアルゴリズム(計算手順)に従って、プログラミング言語を用いてソースコードを入力していく工程を指す。得られたソースコードは機械語(マシン語)のプログラムなどに変換されて実行される。

「プログラミング」(programming)とほぼ同義とされることもあるが、プログラミングはコードの構想や設計、記述したコードのテストや修正(デバッグ)といったコード記述の前後の段階を含む概念とされることが多く、その場合はコーディングはプログラミングの一部となる。

また、コンピュータプログラムの作成だけでなく、人工言語を用いてコンピュータが処理できるコードを記述する作業全般をコーディングと呼ぶことがある。例えば、HTMLやCSSなどの言語を用いてWebページの内容やデザインをコードとして記述していく作業や、ハードウェア記述言語を用いて論理回路の構成を記述する作業などもコーディングという。

ソフトウェアの誤作動を引き起こすコンピュータプログラム中の欠陥を指し、人間がプログラムを書き記す際に起きる単純な誤記や勘違いなどによるものから、構想や設計の段階で誤りや矛盾が含まれていたことに起因するものなど、様々な原因によって発生する。プログラム中の誤りを発見し取り除く作業・工程を「デバッグ」(debug：除虫する)という。

バグを含むプログラムを実行することで生じる問題は様々だが、典型的なものとしては、利用者の操作に応答しなくなったり、設計意図と異なる挙動を示したり、誤ったデータを出力したり、記録されたデータを破壊したりといった振る舞いが挙げられる。

ビデオゲームの分野では、キャラクターやフィールドが通常はありえない状態になる現象や、不可能なはずの挙動や展開が可能になるバグが注目されることが多い。製品としては欠陥だが、バグによって可能になる奇妙な挙動や攻略テクニックなどを「裏技」「バグ技」などと呼んで面白がる文化がある。

潜在的なバグ

常に同じ実行箇所に差し掛かると同じ問題を引き起こすバグは発見しやすいが、いつどこで実行しても同じ箇所で必ず不具合を引き起こすとは限らない。特定の入力データや操作、使用環境や設定、あるいはそれらの特定の組み合わせによって発現し、それ以外の状況では誤作動を引き起こさない場合がある。

例えば、1980年代までは日付データの年号部分を西暦の下二桁で記録・管理することは記憶容量の節約や処理速度の向上に寄与するとして推奨されることが多かったが、西暦2000年に到達すると正常に動作しなくなる(西暦2000年問題)。実際、情報システム業界は1990年代末に業務用システムの改修に大きな人手を割くことになった。

バグの発見と修正

コンピュータプログラムの設計・記述の多くは人間が行うため、バグの発生・混入を未然に完全に防ぐ方法はなく、いかに効率よく早期に発見し取り除くかが重要となる。そのためには、ソフトウェア開発の各段階で繰り返し入念にテストを行い、発見された不具合や誤作動についてプログラム上の発生箇所や原因を特定し、対処方法を決定して修正などを行う。

発見されたほとんどのバグは正しい動作を行うプログラムコードに差し替えられる。発売・公開前のプログラムは修正して実行ファイルなどを作りなおすが、利用者の手元に提供した後にバグが発見されることもある。そのような場合には、開発元が「パッチ」「バグフィックス」などと呼ばれる修正プログラムをインターネットなどを通じて配布し、利用者側のソフトウェアを更新する。

オペレーティングシステム(OS)やライブラリ、ミドルウェアなど基盤的なソフトウェアの場合には、修正によってプログラムの振る舞いが変わり、従前の振る舞いを前提に動作していた他のプログラムなどに思わぬ影響を及ぼすことがある。深刻な影響が想定される場合はバグをあえて放置し、別の箇所や方法で悪影響を抑えるというアプローチが取られる場合もある。

歴史

古くは19世紀の記録に機械の設計・製造上の誤りや不良が “bug” と呼ばれていた事例がいくつか知られており、初出がいつに遡るのかは判然としない。現代のコンピュータのソフトウェアにおける用例に近い初期のエピソードとして最も有名なものは、1947年にグレース・ホッパー(Grace Hopper)氏が米ハーバード大学で遭遇した事例である。

初期の電気機械式のコンピュータ「Harvard Mark II」の不具合を調査する過程で、あるスタッフがリレー(スイッチ)に蛾が挟まって接触不良を起こしているのを発見した。彼女は日誌に蛾をテープで留め、“First actual case of bug being found”(実際にバグが見つかった最初の事例) と書き残した。

どのような単位でテストを行うかはプログラミング言語の種類や開発者、プロジェクトの方針によっても異なるが、多くの場合はクラスやメソッド、関数、プロシージャなど、言語仕様上ほかのプログラムから一つのまとまりとして扱われる最小の単位(ここでは便宜上モジュールと総称する)ごとに行われることが多い。

単体テストは対象のモジュールが意図したとおり正しく機能するかを確認するために行われるもので、想定される引数の組み合わせなどを与えてみて、エラーが発生しないかどうか、意図した結果を返すかなどを調べる。

単体テストツール

関数などの単位では実行プログラムとして単独で実行できないことが多いため、モジュールを呼び出す「ドライバ」(driver)や、モジュールから呼び出されるプログラムのダミーである「スタブ」(stub)などのテスト用プログラムが必要となる。

汎用的なドライバやスタブの機能を持ち、テスト対象とテスト条件を指示するとテスト用のプログラムを自動生成してテストを実行し、結果を提示する「単体テストツール」もある。現代のソフトウェア開発の現場では、コードの記述者がこうしたテストツールを活用して単体テストを済ませるスタイルが広まっている。

単体テストの意義

すべてのモジュールに単体テストを実施することは時間や工数、コストがかかるが、問題を早い段階で発見することができ、後の段階で発見されるよりも容易に修正できることが多い。また、単体テスト完了後は各モジュール単体の動作が正しいことが保証されるため、以降の開発・テスト工程の効率を高めることができる。

これに対し、複数のモジュールを組み合わせて正しく連結できるかどうかを調べるテストを「結合テスト」「統合テスト」「連結テスト」「インターフェーステスト」などと呼び、システム全体を対象に行うテストは「システムテスト」という。

開発したプログラムの挙動を確かめるテスト手法の一つで、プログラムコードの構造に基づいて命令文や内部状態を網羅するようにテストケースを作成する。コードの理解が前提となるため開発者が実施することが多く、主に単体テスト(ユニットテスト)で用いられる。

テスト対象のソースコードのうち、どの程度の割合のコードがテストされたかを表す尺度を「カバレッジ」(テストカバレッジ/コードカバレッジ)という。何に着目するかによって「命令網羅」「判定条件網羅」「条件網羅」「複数条件網羅」「経路組み合わせ網羅」などの種類がある。

ホワイトボックステストはコードが意図した通りに動作しているかを確かめられるが、コードの内容を前提にテストケースを作成するため、プログラムに与えられた仕様を満たしているかを十分に調べきれない場合がある。特に、コードに記述のない機能の不足・欠損を見逃すことがある。

一方、プログラムの内部構造とは関係なく、外部から見て仕様書通りの機能を持っているか確認するテストを「ブラックボックステスト」(black-box testing)という。また、ホワイトボックステストとブラックボックステストを組み合わせた手法を「グレーボックステスト」(gray-box testing)ということがある。

プログラムが仕様や開発者の意図と異なる動作をする場合、そのような動作を引き起こすプログラム上の欠陥、誤りを「バグ」(bug：虫)という。テストなどによって発見された誤作動・不具合について、その原因やソースコード上での位置を探索・特定し、意図した通りに動作するように修正する作業をデバッグという。

バグの探索

デバッグ作業ではまず、バグがプログラムのどこに潜んでいるのかを探し出す。バグはエラーなどで停止したコードに存在するとは限らない。あるコードが誤ったデータを生成し、そのデータを使って処理を行おうとした別のコードが致命的なエラーを起こして停止するということもあるからである。

位置が特定されると、なぜそのような誤りが生じたのか原因を調べる。単純な誤記によるものから、プログラムを構成する論理やアルゴリズムの誤りに原因がある場合、当初の想定では予期していなかった入力値や動作環境など、様々なものが原因になりうる。

バグの修正

原因が特定されると修正が行われるが、様々なシステムの基盤に用いられるような製品では外部のシステムがすでにそのバグが存在する前提で作られてしまっている場合もあるため、修正せずに存在を周知して個別に対策するよう呼びかける場合もある。

また、修正によって新たなバグが発生したり、別の箇所に潜んでいたバグを顕在化させる「デグレード」と呼ばれる事態が生じることもあるため、修正したプログラムは当該箇所以外への影響も含めて入念にテストされることが多い。

デバッガ

デバッグ作業を支援するソフトウェアを「デバッガ」(debugger)あるいは「デバッグツール」(debugging tool)という。“debugger” は英文法的には「デバッグを行う者」という意味だが、プログラムを自動的に修正してくれるわけではなく、バグの位置を特定するためにプログラムの動作状況を解析・可視化する機能などを提供するものを指し、デバッグ作業自体は人間の開発者が行う。

人間の書いたプログラムコードには、単純な誤記や根本的な論理の誤り、設計時に策定された仕様や要求の未達成、目的通りに動作はするが効率や性能の悪い構造、資源の浪費や不必要な冗長さ、潜在的に外部からの攻撃に悪用可能な脆弱な箇所、他の人が見て動作を理解しにくい箇所、コーディング規約に従っていない記述など、様々な誤りや問題点が含まれることがある。

これらは本人による検証では見落としたり、問題を認識できない場合があるため、別の開発者にコードを渡し、様々な観点から調査、検討を行ってもらうことがある。これをコードレビューという。

コードレビューを実施することで、開発者個人の力量に依存せず組織的にコード品質を一定に保つことが期待され、思い込みや見落とし、個人的な癖により不良箇所が生じたり、後で別の人がメンテナンスしにくくなることを防止する。

また、開発チーム内でレビューを行うことで、お互いの担当範囲について理解を深めてチーム内の連携を強化したり、人に見られることを前提に分かりやすい論理や記述を心がけるようになる(可読性の向上)などの効果も期待できる。

複数のモジュールを結合したときに正しく機能するかを確かめるテストで、主にモジュール間の接続点(インターフェース)がうまく機能するかを確認する場合と、結合した状態で外部から見て一体として正しく機能するかを確認する場合がある。

統合テストが終了すると、最終段階のテストとして、本番同様の環境を構築してハードウェアや通信回線なども含めシステムが全体として適切に機能するかを検証する「システムテスト」(system testing)が行われることが多い。

種類

モジュールの組み合わせ方には様々な方法論があるが、機能を呼び出す側を上位、呼び出される側を下位と捉え、下位側から上位側へ、あるいは上位側から下位側へ向かって順番に結合していく手法が用いられることが多い。

最下位のモジュールから上位に向かって順番にテストしていく方式を「ボトムアップテスト」(bottom-up testing)という。未完成の上位側モジュールの代わりとして、機能呼び出し部分のみを実装したダミープログラムである「テストドライバ」(test driver)が用いられる。

一方、最上位のモジュールから下位に向かって順番にテストしていく方式は「トップダウンテスト」(top-down testing)という。未完成の下位側モジュールの代わりに想定される応答の一つを固定的に返すダミープログラムである「テストスタブ」(test stub)が用いられる。

また、上位側と下位側の両方から結合を進めていく「サンドイッチテスト」(折衷テスト)や、全モジュールの完成後にすべて結合して一気にテストする「ビッグバンテスト」などの手法もある。

呼称

企業や現場によって様々な呼称が用いられるが、「結合テスト」あるいは「統合テスト」と呼ばれることが多く、略号は「IT」(Integration Testing)を用いることが多い。モジュール間の通信に特化したテストを連結テストと呼ぶ場合があるなど、同じ呼称が組織や分野によって微妙に異なる内容を指す場合もある。

英語では “intergration testing” (インテグレーションテスト)あるいは “interface testing” (インターフェーステスト)と呼ぶのが一般的で、「JT」(Join Testing)、「CT」(Combined Testing)、「LT」(Link Testing)などの英略語は和製英語とされる。

入力と出力のみに着目し、様々な入力に対して想定通りの出力が得られるかどうかを確認する。テストケースの作成などに関して、内部の処理手順やプログラムの構造などは考慮しない。

とはいえ、闇雲に値を与えても正しい処理が行われているか確認できないため、仕様上同じ処理が行われるはずの値の範囲やグループを求め、それぞれの範囲から代表値を選んでテストする「同値分割」や、範囲の境界付近が正しく処理されるか確認する「限界値分析」(境界値分析)などの手法が用いられる。

一方、プログラムなどの構造を見ながら内部のデータやコードが正しく機能しているかを検証する手法を「ホワイトボックステスト」(white box testing)という。

想定される状況に近い状態で実際に稼働させ、あらかじめ設定された性能に関する要件を満たすかどうかを判定する。要件として設定される要素としては、単位時間あたりの処理量(スループット)、操作などに対する応答時間(レスポンスタイム)や待ち時間、消費・占有する資源(リソース)の量などを用いるのが一般的である。

ロードテスト/ストレステストとの違い

システムに通常時やピーク時に想定される負荷をかけ、性能や耐久性を計測するテストを「ロードテスト」(load testing)という。特に、ピーク時に想定される高負荷にシステムが耐えられるか(あるいは要件通りに処理・応答できるか)確認するものは「ピークロードテスト」(peak load testing)と呼ばれることもある。

また、システムへの負荷を次第に上げていき、想定の上限を超えて高め続けていったときに、どの程度まで処理を続行できるか、過負荷時にどのような反応や不具合が生じるかといったことを調べるテストを「ストレステスト」(stress testing)という。

システムに通常時やピーク時に想定される負荷をかけ、性能や耐久性を計測する。設計時に想定した動作環境や仕様の範囲内の負荷で正常に動作するかを検証したり、負荷を高めていったときの性能の劣化や異状が発生する限界を調べたりする。特に、ピーク時に想定される高負荷にシステムが耐えられるか(あるいは要件通りに処理・応答できるか)確認するものは「ピークロードテスト」(peak load testing)と呼ばれることもある。

一方、想定を超える高い負荷をかけたり、定格外の過酷な動作環境に置かれたときのシステムの挙動や、過負荷時にどのような反応や不具合が生じるかといったことを調べるテストは「ストレステスト」(stress testing)という。

日本語の「負荷テスト」は、ロードテストを指す場合、ストレステストを指す場合、性能テスト(パフォーマンステスト)を指す場合、これら負荷に関連するテストの総称とする場合などがあり、分野や組織によって異なる意味を表すことがあるため、目的や手法を確認したほうが良い。

ソフトウェア開発の過程で不具合が発見されたり、新たな機能を追加や挙動の変更を行うためにプログラムが修正されることはよくあるが、その修正の影響を受けてそれまで正常に動作していた部分が異状をきたすようになったり、隠れていたバグが露見することがある。

このような現象を「デグレード」あるいは「リグレッション」などという。これを避けるため、機能追加やバグ修正などでコードの一部が改修されたあと、それまでの動作に意図しない変更や問題が生じていないか確かめるテストを回帰テストという。

範囲や対象を絞らず行うテストを「フルリグレッションテスト」というが、一部を変更するたびにすべての機能やコードをテストし直すのは時間やコストの負担が大きいため、修正箇所が影響する可能性があるプログラムの範囲を見極め、重要な機能を優先してテストするといった運用が行われることが多い。

また、開発環境の変更や、運用開始後のオペレーティングシステム(OS)やプログラム実行環境、データベース管理システム(DBMS)などのミドルウェアの更新(アップデートおよびアップグレード)に伴ってデグレードが起きることもあり、このような環境変更の際にも回帰テストが実施される。

システムが発注した仕様を満たしているか、マニュアルなどの文書に誤りが無いか、障害発生時など運用上の様々な状況に対して想定通りに対処できるかなどを利用者側がチェックする。実務を想定して実際に使用してみる実地試験(ベータテスト)を行うこともある。

開発側の瑕疵による不具合などが見つかった場合は、工程を差し戻して修正などを行い、改めて受け入れテストを行う。発注側の想定漏れなどで導入できないことが発覚し、改修の必要が生じた場合は追加作業の発注となることが多い。

第三者によるUAT

受け入れテストの実施は受け入れ側の情報システム部門やその要員によって実施されるのが一般的だが、開発側との専門知識の格差やテストの実施に必要な人員・コストなどの問題、情報システムのテストに関する経験や知見の不足などから十分なテストの実施が困難なことがある。

そのような場合に、開発を請け負った事業者とは別の外部の事業者からテストに関する支援を受けたり、テスト自体を一部またはすべて委託する場合もある。システム開発関連企業の中には受け入れテストを請け負うサービスメニューを用意している事業者もある。

ベンダーテスト

官公庁などの公的機関向けに開発したシステムに対して行う、品質を保証するためのテストを「ベンダーテスト」という。システムの開発側(ベンダー)で行うテストという意味。

テスト内容とテスト結果を合わせて報告することで、要求された仕様を満たしていることを保証するために行う。典型的には、単体テスト(ユニットテスト)、システムテスト、統合テスト、負荷テストなどの工程からなる。

一般的には業務上そのシステムを実際に利用することになる発注元の最終利用者(業務担当者)が行なうもので、実際のデータや業務手順に沿ってテスト計画を組み立てて実施する。

納品を受諾するかどうかを判定する受け入れテスト(承認テスト/検収テスト)を兼ねる場合や、ある程度の期間を費やし、担当者がシステムの操作に習熟する研修を兼ねる場合もある。

運用テストでは、仕様書通りの機能が実装されていることを確認するだけではなく、操作に対する応答時間や処理性能を計測したり、高負荷時の反応や耐久性を調べたり、入力ミスや誤操作、ハードウェア障害などを故意に発生させてエラー処理や復旧などの手順を確認したりすることもある。

すべてのテスト工程が終わり、システムが完成した段階で実施される工程で、実際の業務の現場にシステムを導入し、旧環境からの置き換えや切り替え、データの移転(データ移行)などを行う。業務に支障をきたさないよう、夜間や週末、連休などを利用して行われることが多い。

当日の人員配置や作業手順、時程、資機材の配置図などをまとめた詳細な計画書を作成して臨むことが多い。本番そっくりな環境を用意して移行リハーサルを実施することもある。トラブルの発生に備え、移行中止判断の基準や、移行前の状態に原状復帰するための手順なども準備する。

移行の仕方はシステムの構成や業務の特性などによりいくつかの手法がある。ある時点で旧システムを全面停止して新システムを一気に導入する「一斉移行」(一括移行)、機能や業務ごとに何段階かに分けて少しずつ入れ替える「順次移行」(段階移行)、特定の部署で試験的に移行を実施し、安定運用を確認してから残りの部門で一斉に移行する「パイロット移行方式」などである。

ソフトウェアの開発工程が一通り完了し、開発者側によるテストが済んだソフトウェアを、開発者が発注者に納品し、受注者側が受け入れ可否を判断する工程である。

発注者は発注時に合意した仕様や契約に基づいて、発注通り作られているが、実際の環境に導入して正常に稼働するかなどをテストする。発注側によって行われる最終確認のテストを「ユーザー受け入れテスト」(UAT：User Acceptance Test)あるいは「検収テスト」という。

開発者は発注者による問い合わせなどに答え、また、テストが円滑に進むよう支援する。発注側の担当部門やスタッフの知見やノウハウが心もとない場合には、開発者と利害関係の無い別のシステム関連会社にテスト実施の支援を依頼する場合もある。

テストの結果が受け入れ基準を満たしていれば、ソフトウェア受け入れ完了となり、開発プロジェクトおよび契約は終了となる。発注者側では機材の設置やソフトウェアの導入、利用者への操作方法の教育や利用環境の整備などを行い、業務での利用を開始する。

完成したソフトウェアには開発時に発見・除去しきれなかった欠陥が残っていることがあり、利用者からの指摘などに基づいて速やかに修正して入れ替える仕組みを整えることは重要である。連携先システムの仕様変更など外部環境の変化に適応するための改修、性能や使い勝手の向上といった改良も必要に応じて行われる。

ソフトウェアの「一生」をモデル化したSLCP(ソフトウェアライフサイクルプロセス)の標準にもソフトウェア保守に関する規定がある。JIS X 0161ではソフトウェア保守プロセスを、

• 環境変化に対応する「適応保守」(adaptive maintenance)
• 発見されたバグを修正する「是正保守」(corrective maintenance)
• 是正保守に時間がかかる場合の応急手当として行われる「緊急保守」(emergency maintenance)
• 性能や機能、保守性、使いやすさなどを改良する「完全化保守」(perfective maintenance)
• 潜在的な不具合が顕在化する前に修正する「予防保守」(preventive maintenance)

の5つに分類している。

利用者から見たソフトウェアの持つ機能を分解し、外部との入出力、ファイルとの入出力など種類ごとに整理してそれぞれいくつあるかを数える。利用者が認識しない内部的なデータ処理などはカウントしない。

それぞれの機能について過去の類似の事例などから導き出された複雑度の評価を行い、その機能の持つ点数(ファンクションポイント)とする。これをプログラム全体に渡って合算した合計値に、システムに要求される特性(データ通信が必要、分散処理が必要)に応じて決定される上下35%(0.65～1.35)の幅を持つ係数を掛け合わせて評価値とする。

ソースコード行数(LOC：Line Of Code)などによる評価・見積もりに比べ、プログラミング言語の種類や書き方、機能の実装方法などに依存しない、データフローダイアグラムやER図など設計段階で作成される資料から算出できる、利用者から見た機能に基づくため利用者側(開発依頼側)の納得を得やすいといった利点がある。

一方、機能の複雑度の判定などは主観が入り込みやすく、過去に類似の事例のない場合の評価が難しいといった難点もある。アメリカでは1986年に業界団体のIFPUG(International Function Point Users Group)が設立され、評価法についての標準的なガイドラインを発行している。これに基づく算出法のことをIFPUG法ということがある。

過去に類似の事例が存在する点についてはその事例の実績値を採用し、事例がない点については経験や勘を元に見積もっていく。

そのプロジェクト特有の事情などは反映されにくく、精度は担当者の知識や経験に大きく左右される。過去に類例の乏しい特殊な案件や新しい種類の案件など、類推が難しい場合もある。

要件や機能などが明確に定義される以前の初期の段階でも適用可能なため、詳しい状況が確定する以前の企画の初期に見積もりが必要な場合に用いられることがある。精度が低く客観性や根拠にも乏しいため、要件定義以降の詳細な見積もりには適さないとされる。