基本情報技術者単語帳 - システム開発技術

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

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

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

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

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

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

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

個々のソフトウェアの開発者が毎回すべての機能をゼロから開発するのは困難で無駄なため、多くのソフトウェアが共通して利用する機能は、OSやミドルウェアなどの形でまとめて提供されている。

そのような汎用的な機能を呼び出して利用するための手続きを定めたものがAPIで、個々の開発者はAPIに従って機能を呼び出す短いコードを記述するだけで、自分で一から処理内容を記述しなくてもその機能を利用したソフトウェアを作成することができる。

広義には、プログラミング言語の提供する機能や言語処理系に付属する標準ライブラリの持つ機能を呼び出すための規約などを含む場合もある(Java APIなど)。

また、APIを経由して機能を呼び出す形でプログラムを構成することにより、同じAPIが実装されていれば別のソフトウェア上でそのまま動作させることができるのも大きな利点である。実際、多くのOS製品などでは同じ製品の旧版で提供していたAPIを引き継いで新しいAPIを追加するという形で機能を拡張しており、旧バージョン向けに開発されたソフトウェアをそのまま動作させることができる。

APIの形式

APIは人間が記述・理解しやすい形式のプログラムであるソースコード上でどのような記述をすべきかを定めており、原則としてプログラミング言語ごとに定義される。

関数やプロシージャなどの引数や返り値のデータ型やとり得る値の意味や定義、関連する変数や定数、複合的なデータ構造の仕様、オブジェクト指向言語の場合はクラスやプロパティ、メソッドの仕様などを含む。

通信回線を通じて遠隔から呼び出すような構造のものでは、送受信するパケットやメッセージの形式、通信プロトコル(通信規約)などの形で定義される仕様をAPIと呼ぶこともある。

Web API

近年ではネットワークを通じて外部から呼び出すことができるAPIを定めたソフトウェアも増えており、遠隔地にあるコンピュータの提供する機能やデータを取り込んで利用するソフトウェアを開発することができる。

従来は通信を介して呼び出しを行うAPIはRPC(リモートプロシージャコール)の仕様を元に製品や環境ごとに個別に定義されることが多かったが、インターネット上でのAPI呼び出しの場合は通信にHTTPを、データ形式にXMLやJSONを利用するWeb APIが主流となってきている。

2000年代前半まではWeb APIの標準として仕様が巨大で機能が豊富なSOAPの普及が試みられたが、2000年代中頃以降は軽量でシンプルなRESTful APIが一般的となり、狭義のWebアプリケーションだけでなく様々な種類のソフトウェアやネットサービス間の連携・接続に幅広く用いられるようになっている。

APIと実装

API自体は外部からの呼び出し方を規定した決まりごとに過ぎず、呼び出される機能を実装したライブラリやモジュールなどが存在して初めてAPIに挙げられた機能を利用することができる。

あるソフトウェアのAPIが公開されていれば、同じAPIで呼び出すことができる互換ソフトウェアを開発することもできる。ただし、APIを利用する側のプログラムが(スクリプトなどではなく)バイナリコード(ネイティブコード)の場合にはこれをそのまま動作させることはできないのが一般的で、同じソースコードを元に互換環境向けにコンパイルやビルドをやり直す必要がある(ソースレベル互換)。

また、API自体は標準実装における動作の詳細までは定義していないため、APIが同一の互換ソフトウェアだからといって動作や振る舞いがまったく同じであるとは限らない。商用ソフトウェアの場合はAPIが非公開だったり、すべては公開されていなかったりすることが多く、公開情報だけではAPI互換の製品を作ることも難しい。

APIと知的財産権

従来は特許で保護されている場合を除いて、APIそのものには著作権その他の知的財産権は存在しないとする見方が一般的で、実際、元のソフトウェアのコードを複製せずすべて独自に実装するという方法でAPI互換ソフトウェアが数多く開発されてきた。

ところが、米オラクル(Oracle)社が権利を有するJava言語やその処理系に関して、米グーグル(Google)社が同社の許諾を得ずにAndroidスマートフォン向けにJava APIを実装した実行環境(Dalvik VM)を開発・提供しているのは著作権侵害であるとの裁判が起こされ、米裁判所は訴えを認める判決を出した。今後はAPIの権利について従来の状況が変化していく可能性がある。

画面上にアイコンやメニュー、ボタンといった絵や図形に補助的な文字情報を組み合わせた操作要素が表示され、これをマウスやトラックパッド、タッチパネルなどのポインティングデバイス(位置入力装置)で選択してコンピュータへの指示を与える。

パソコンなどではオペレーティングシステム(OS)が管理する「デスクトップ」(desktop)と呼ばれる初期画面が表示される。各アプリケーションソフトは「ウィンドウ」(window)と呼ばれる矩形の領域を与えられ、その中で表示や操作を行う。複数のウィンドウを同時に開き、並行して処理を行ったり、即座に切り替えて操作することができる。

スマートフォンやタブレット端末では「ホーム画面」(home screen)が表示され、導入済みのソフトウェア(アプリ)がアイコンとして並んでいる。これをタッチ操作で選択するとアプリが起動して全画面で操作可能になる。複数アプリを同時に起動することはできるが、画面を切り替えて使用するのが一般的となっている。

CUIとの違い

一方、情報の提示も操作の受付も原則として文字によって行うユーザーインターフェースを「CUI」(Character User Interface：キャラクターユーザーインターフェース)あるいは「CLI」(Command Line Interface：コマンドラインインターフェース)という。

利用者はキーボードなどを用いてコンピュータへの指示を文字によって与え、コンピュータからの出力も画面に文字を表示して行われる。LinuxなどのUNIX系OSやメインフレーム(大型コンピュータ)、ネットワーク機器など、訓練を受けた専門の技術者やオペレータが操作する前提のコンピュータ製品で多く用いられる。

パソコン向けOSのWindowsやmacOS、スマートフォンやタブレット端末向けのAndroidやiOSなど、技術者ではない一般消費者や(企業の)従業員が操作することを想定したコンピュータ製品は、情報の見やすさや操作方法の習得のしやすさなどを重視してGUIを中心に構成することが多い。家庭用ゲーム機、デジタル家電など民生用コンピュータ応用製品の多くも、主要な表示・操作方式としてGUIを用いる。

ITの分野では、人や組織が提供する役務といった一般の外来語としての意味に追加して、コンピュータなどの機器やソフトウェアが、利用者や他の機器、ソフトウェアなどに対して提供する機能や働きのことをサービスということがある。

Windowsのサービス

Windowsでは、利用者や実行中のソフトウェアの求めに応じて即座に何らかの機能を提供できるよう、起動された状態でシステムに常駐するプログラムのことをサービスという。

システムやデータの管理や監視のための機能や、多くのソフトウェアが共通して必要とする汎用的な機能などを実装したもので、通常は操作画面などを持たず、利用者が直接操作することはほとんどない。

Windowsがオペレーティングシステム(OS)の機能の一部として標準的に提供するもののほかに、個々のアプリケーションソフトが提供するものがある。起動時に自動的に実行されるよう設定されており、コントロールパネルの「サービス」アプリから実行、停止、再起動を行うことができる。起動時の自動実行の有無も切り替えることができる。

コンピュータや情報システムなどの場合には、要求や入力が終了した時点から、応答や出力が開始される時点までの時間のことをレスポンスタイムと呼んでいる。

通信回線やネットワークを介してデータを送受信するようなシステムの場合は、相手方が送信を終えてから受信が始まるまでの時間を指し、信号が伝送路を往復する時間が含まれる。

ディスプレイの応答時間

画面表示装置(ディスプレイ)などの場合、画素の色を変更するのにかかる時間のことをレスポンスタイムと呼ぶ。この時間が短いほど高速に画面を切り替えることができ、動きの激しい映像などを精細に表示することができる。

単にレスポンスタイムといった場合は黒(消灯)から白(全点灯)に切り替えて再び黒に戻す動作にかかる時間を指すことが多いが、近年では実際の使用時に頻度の高い「中間色から別の中間色に切り替える速度」を表す「GTG」(Gray To Gray/G to G/中間階調応答速度)という指標もよく用いられる。

処理の場合

コンピュータの性能について言う場合は、単位時間あたりに与えられた処理を完遂できる回数を表す。CPUやメモリ、ストレージなど装置の構成や性能、処理内容などが複雑に影響しあって決まるため、単一で単純な指標はない。分野や用途に応じて業界団体などが用意した試験用のソフトウェア(ベンチマークプログラム)を実行し、処理件数を計測して相対的な値として表すことが多い。

通信の場合

通信回線や装置のデータ入出力の性能について言う場合は、伝送路を通じて単位時間あたりに送受信できるデータ量を表す。単位として、1秒あたりに伝送できるビット数である「ビット毎秒」(bps：bits per second)や1秒あたりのバイト数「バイト毎秒」(Bytes/s)、および、これらに大きさを表す接頭辞を付けたもの(Mbps、MBytes/sなど)を用いる。

通信システムやプロトコルなどについて用いる場合は、伝送路自体が全体として運べる理論的なデータ量から、制御データや誤り訂正符号などのオーバーヘッド分を差し引いた、実質的に相手方に伝達されるデータ(ペイロード)の量を表すこともある。

スループットとレイテンシ

処理や伝送の「速さ」はスループットだけでは決まらず、状況によっては一回ごとにかかる遅延時間(レイテンシ)が大きく影響する場合がある。一般に、大量のデータを連続的に扱う場合はスループットが支配的な要因となるが、二者が双方向的に相手からの応答を待って短く何度も繰り返し伝送を行うような系(通話など)ではレイテンシが支配的となることがある。

例えば、高解像度の映像を伝送できる高スループットの衛星回線でテレビ中継を行っても、出演者が回線越しに会話をすると発言ごとに数秒の「間」が生じることがある。これは衛星が遠く電波の到達に時間がかかることによるレイテンシの影響である。

実効スループット (有効スループット)

通信速度や処理能力の尺度の一つで、実際に通信や計算を行ったときの単位時間あたりの処理能力やデータ転送量のことを実効スループット(effective throughput)あるいは有効スループットという。

システムの処理能力の意味では、実際のデータを処理したときの単位時間あたりの処理能力を表し、理論上の最大処理能力(理論スループット)が同じでも、処理させるデータの選び方などの条件によって実効スループットは変化する。標準化されたベンチマークテストなどによって計測される。

通信速度の意味では、理論上実現可能な単位時間あたりのデータ転送量(理論スループット)から、エラー訂正による損失や、プロトコルのオーバーヘッド、データ圧縮による影響などを差し引いた、実効速度を表す。このため、実効スループットは通信環境や転送するデータの選び方などの影響を受ける。特定の環境のもとで実際に大きなファイルを送受信してみて、かかった時間を測って計測される。

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

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

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

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

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

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

一般の外来語としては、書籍や映像・音楽作品、ビデオゲーム、公演などを鑑賞したり、店舗や施設を利用したり、製品を購入・利用した人が、対象を評価することや、感想や論評を文章や評点などの形に表したものをレビューということが多い。

学術やビジネスの分野では、制作物の審査や検証、精査、出来事の再調査や振り返り、対象分野の総論的なまとめ、仕組みの見直しなどを指すこともある。

レビューする人のことを「レビュアー」あるいは「レビューア」(reviewer)、レビューされる人のことを「レビュイー」あるいは「レビューイ」(reviewee)と呼ぶ。

システム開発のレビュー

情報システムやソフトウェアの開発で、作成された仕様書やコードなどの成果物を開発者とは別の人が詳細に調べ、仕様や要求を満たす内容になっているか、誤りや不具合が無いか、資源の浪費や不必要な冗長さ、極端な低性能などの問題が無いかなどについて開発者にフィードバックする工程をレビューという。

具体的なレビュー手法として様々な方式が提案されており、複数の検証者がチェックリストなどを用いて精査した結果をミーティングで議論する「インスペクション」、本人と評価者が一堂に会してその場で検証や議論を行う「ウォークスルー」、成果物を評価者に送付・回覧して意見を求める「パスアラウンド」などがよく知られる。

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

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

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

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

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

システムが扱うデータの流れを整理するための図法で、対象となるシステムと利用者や外部のシステムなどのデータの流れを図示する場合と、システム内の構成要素(データストアやプロセスなど)間の流れを図示する場合がある。

データは発生源から様々な処理(プロセス)を経て出力先へ収まる。一つの図にあまり多くの要素を図示すべきではないとされ、。全体的で抽象的なレベルから作図し、段階的に詳細化した図を描いていくという手法が用いられることが多い。

DFDでは、データの保管や取り出しを行う「データストア」を平行な上下二本線で、データを処理するソフトウェアなどの「プロセス」を丸で、データの発生源や出力先である「外部実体」(ターミネータ)を長方形あるいは楕円で示す。これらの要素の間をデータの流れ(フロー)を表す矢印で結んでいく。

プロセスには入力と出力を表す「フロー」がそれぞれ一つ以上必要で、データストアや外部実体は入力または出力のいずれか一方のフローが必要となる。また、各フローの一方の端は必ずプロセスでなければならない。

システムが取り扱う対象とする現実世界の要素を抽象化し、名詞として表すことができるものを「実体」(エンティティ)として矩形で表す。実体は必ずしも物理的な存在とは限らず、情報や行為などでも構わない。

実体間の関係性を表す要素は「関連」あるいは「関係」(リレーションシップ)と呼ばれ、動詞として表すことができるものが該当する。図中では菱形もしくは矩形の間を結ぶ線分として表記される。

実体と関連は共にその性質を表す「属性」(アトリビュート)を複数持つことができる。属性は楕円で表し実体や関連と線分で紐付ける記法と、実体の矩形の中に列挙する記法がある。

多重度

また、記法によっては関連に多重度(cardinality/カーディナリティ)を設定することができるものがある。二つの実体の関連が一対一、一対多、多対多といった対応関係になっていることを表す。

例えば、ER図の表記法の一つであるIE記法では、関連の末端部分に「○」(0を表す)「|」(1を表す)、鳥の足のような三股の枝分かれ(任意の複数を表す)の3つの記号の組み合わせで数を表記する。「|」のみならば「必ず一つ」、「○」と三股ならば「0を含む任意個」を表す。

記法の種類

ER図は1975年にマサチューセッツ工科大学(MIT)のピーター・チェン(Peter Chen)氏がERモデルと共に考案した。氏の提唱したオリジナルの記法は現在ではPeter Chen記法とも呼ばれる。

用途などに応じて微妙に表記法の異なる10以上の記法が考案され、様々な用途に使用されている。中でも有名なものとして、米国立標準技術研究所(NIST)が規格化したIDEF1x記法(IDEF：ICAM Definition Language)、ジェームズ・マーティン(James Martin)氏が考案したIE記法(IE：Information Engineering)がよく利用される。

ソフトウェア開発では、プログラムを作成する前にシステムの設計や構造、振る舞いを定義し、発注者と開発者、あるいは開発チーム内で仕様について共通認識を得る必要がある。その際、説明が文章や箇条書きだけだと分かりにくく、多数の要素の複雑な相互作用などを簡潔に表現することが難しい。

UMLでは、システムをオブジェクトの組み合わせとしてモデル化し、その構造や仕様を図表によって記述するための表記法を定めている。システムの構成要素の定義や、要素間の関連性、要素の振る舞いなどを図示することができる。

図表の描き方が人や組織によってまちまちでは相互理解に支障を来すが、標準化されたUMLという共通の「言語」を用いることで、書き手の意図を正しく読み手に伝えることができる。システムの様々な側面を伝達できるよう、UMLには14種類の図が用意されている。

UMLの仕様は1996年に当時のラショナル・ソフトウェア(Rational Software)社(2003年に米IBM社が買収)が策定した。その後、仕様の策定・改訂は業界団体のOMG(Object Management Group)が行うようになった。UML1.4が2005年にISO/IEC 19501として、UML 2.4が2012年にISO/IEC 19505としてそれぞれ国際標準となっている。

図の種類

UMLで定義される図は大きく分けて、システムの構造を表す「構造図」(structure diagram)と、動作や変化を表す「振る舞い図」(behavior diagram)の2種類に分類される。

構造図には「クラス図」(class diagram)、「オブジェクト図」(object diagram)、「コンポーネント図」(component diagram)、「パッケージ図」(package diagram)、「配置図」(deployment diagram)、「複合構造図」(composite structure diagram)、「プロファイル図」(profile diagram)がある。

振る舞い図には「アクティビティ図」(activity diagram)、「ユースケース図」(use case diagram)、「ステートマシン図」(state machine diagram)、「相互作用図」(interaction diagram)がある。

相互作用図はさらに、「シーケンス図」(sequence diagram)、「コミュニケーション図」(communication diagram、以前はコンポーネント図と呼ばれていた)、「タイミング図」(timing diagram)、「相互作用概要図」(interaction overview diagram)に分かれる。

自動車の位置情報をリアルタイムに集約して渋滞情報を配信するシステムや、人間の検針員に代わって電力メーターが電力会社と通信して電力使用量を申告するスマートメーター、大型の機械などにセンサーと通信機能を内蔵して稼働状況や故障箇所、交換が必要な部品などを製造元がリアルタイムに把握できるシステムなどが考案されている。

これまでの情報システムとの違いとして、個々の機器の取り扱うデータ量や処理量、通信量は少ないが機器の数が桁違いに膨大であることや、従来のコンピュータ製品が人の周りや特定の場所(建物や部屋)に集中しているのに対しIoT機器は世の中の様々な場所に分散して配置される点などがある。

こうした特徴を反映し、低コストで生産でき低消費電力で稼働するICチップや、多数の機器からデータを集約して解析したり、同時に多数の機器を制御するソフトウェア技術、低消費電力で遠距離通信が可能な無線技術、環境中から微小なエネルギーを取り出す技術(エナジーハーベスティング)などの研究・開発が進められている。

LPWA (Low Power Wide Area)

IoTに必須の要素として、装置の消費電力が少なく、多数の機器を一つのネットワークに収容できる広域的な無線通信技術があり、これを「LPWA」(Low Power Wide Area)と総称する。そのような通信方式で構築されたネットワークは「LPWAN」(Low Power Wide Area Network)とも呼ばれる。

IoTを実現するには、携帯電話網など従来からある広域無線技術に比べ、十～数十kmといった遠距離や広い範囲をカバーでき、乾電池などの乏しい電源でも数か月から数年は稼働できることが求められる。一方、人間がスマートフォンなどの通信機器に求めるような高速なデータ伝送能力は必ずしも必要なく、数十～数百kbps(キロビット毎秒)程度あれば実用に供することができる。

このような特性を備えた新しい通信方式をLPWAと呼び、具体的な規格として「Sigfox」「LoRa」「Wi-Fi HaLow」「Wi-SUN」「LTE-M」「NB-IoT」「RPMA」などの方式が提唱されている。

M2M/センサネットワークとの違い

以前から、機器同士を直接繋いで自律的にシステムを運用する「M2M」(Machine to Machine)や、通信可能なセンサーを分散配置して高度な監視や制御を可能にする「センサネットワーク」(WSN:Wireless Sensor Network)などの概念が存在し、これらはかなりの部分がIoTと重複している。

ただし、IoTはインターネットへの接続を前提とするのに対し、これらの技術は閉じた専用ネットワークや独自プロトコル(通信規約)での運用を想定している場合が多い。また、M2Mやセンサネットワークは特定の目的のために機械同士が情報のやり取りすることで処理が完結する仕組みであることが多いのに対し、IoTは接続された機器と人や外部の情報システムとの相互関係がより重視される傾向がある。

IoE (Internet of Everything)

「ありとあらゆるものが接続されたインターネット」という意味で、モノのインターネットと、人やデータ、情報、ソフトウェアなどが中心の従来からあるインターネットが統合された姿を指す。

とはいえ、従来のインターネットとの違いは多数のモノが接続されている点であるため、実際上はIoTとほぼ同義として用いられることが多い。主に米シスコシステムズ(Cisco Systems)社が提唱している用語である。

情報システムやソフトウェアの設計や振る舞いの分析などで用いられる概念の一つである。利用者などの主体(「アクター」と呼ばれる)がシステムを用いて何かの機能を利用したり目的を達成しようとする際に、特定の状態からスタートしてどのような操作や応答が行われる(べき)かを記述する。

ユースケースはシステムの機能や要素と一対一に対応するとは限らず、一つのユースケースが行われる間に複数の要素を横断的に用いることもある。アクターが異なればユースケースも異なることがあり、一人のアクターが複数のユースケースを必要としたり、逆に一つのユースケースが複数のアクターで共有される場合もある。

ユースケースシステムは開発の初期段階で要求を明確化するために検討・記述されるのが一般的で、利用者やビジネス分析の専門家の視点から、対象システムをブラックボックスとして扱い、システムによって何をどのように行うのかを明らかする。

情報システムの専門家が関与して作成することは問題ないが、利用者が内容を理解できる形で作成しなければ意味がないため、システム上の専門用語や専門的な概念は極力用いないことが望ましい。また、この段階では過度に詳細化したり詳しい実装に立ち入るべきではないとされる。

システムの設計に必要な情報を図示する技法を定義した「UML」(Unified Modeling Lanugage)では、ユースケースを記述するための図法として「ユースケース図」(use case diagram)を定義している。開発現場でもこれを用いて図示することが多いが、各項目やフローの内容を箇条書きした表などの形で表すこともある。

製品を使って利用者が何をしたいのか、どうなることを望んでいるかを、技術的な概念や語彙を極力用いず、利用者が容易に理解できる平易な言葉で記述する。具体的にどういう仕組みや挙動、表示、操作によりそれを実現するかはこの段階では触れない。

一つの希望を一つの文で表現することが望ましく、たくさんのストーリーを箇条書きで列挙したものが利用者が製品に求めるものの総体となる。「私は ～ として ～ のために ～ したい」といった定型文(テンプレート)に当てはめて記述する手法がよく用いられる。

漠然とした大きな目標のようなものを表すストーリーのことは「エピック」(epic)と呼ばれ、より具体的で詳細なストーリーに分割していく。適切な大きさのストーリーの集まりを定義することができたら、各ストーリーを技術的にどのように実現するかを「タスク」(task)として定義し、開発作業に入る。

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

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

一般の外来語としては、書籍や映像・音楽作品、ビデオゲーム、公演などを鑑賞したり、店舗や施設を利用したり、製品を購入・利用した人が、対象を評価することや、感想や論評を文章や評点などの形に表したものをレビューということが多い。

学術やビジネスの分野では、制作物の審査や検証、精査、出来事の再調査や振り返り、対象分野の総論的なまとめ、仕組みの見直しなどを指すこともある。

レビューする人のことを「レビュアー」あるいは「レビューア」(reviewer)、レビューされる人のことを「レビュイー」あるいは「レビューイ」(reviewee)と呼ぶ。

システム開発のレビュー

情報システムやソフトウェアの開発で、作成された仕様書やコードなどの成果物を開発者とは別の人が詳細に調べ、仕様や要求を満たす内容になっているか、誤りや不具合が無いか、資源の浪費や不必要な冗長さ、極端な低性能などの問題が無いかなどについて開発者にフィードバックする工程をレビューという。

具体的なレビュー手法として様々な方式が提案されており、複数の検証者がチェックリストなどを用いて精査した結果をミーティングで議論する「インスペクション」、本人と評価者が一堂に会してその場で検証や議論を行う「ウォークスルー」、成果物を評価者に送付・回覧して意見を求める「パスアラウンド」などがよく知られる。

情報システムやソフトウェアの設計や振る舞いの分析などで用いられる概念の一つである。利用者などの主体(「アクター」と呼ばれる)がシステムを用いて何かの機能を利用したり目的を達成しようとする際に、特定の状態からスタートしてどのような操作や応答が行われる(べき)かを記述する。

ユースケースはシステムの機能や要素と一対一に対応するとは限らず、一つのユースケースが行われる間に複数の要素を横断的に用いることもある。アクターが異なればユースケースも異なることがあり、一人のアクターが複数のユースケースを必要としたり、逆に一つのユースケースが複数のアクターで共有される場合もある。

ユースケースシステムは開発の初期段階で要求を明確化するために検討・記述されるのが一般的で、利用者やビジネス分析の専門家の視点から、対象システムをブラックボックスとして扱い、システムによって何をどのように行うのかを明らかする。

情報システムの専門家が関与して作成することは問題ないが、利用者が内容を理解できる形で作成しなければ意味がないため、システム上の専門用語や専門的な概念は極力用いないことが望ましい。また、この段階では過度に詳細化したり詳しい実装に立ち入るべきではないとされる。

システムの設計に必要な情報を図示する技法を定義した「UML」(Unified Modeling Lanugage)では、ユースケースを記述するための図法として「ユースケース図」(use case diagram)を定義している。開発現場でもこれを用いて図示することが多いが、各項目やフローの内容を箇条書きした表などの形で表すこともある。

その工程内では解消が難しいような問題があり、一つ(あるいは、深刻な場合はいくつか)前の工程から改めて作業をやり直すことを指す。例えば、製品の試作の段階になって、設計上の重大な欠陥が見つかり、設計段階からやり直すといった事象である。

システム開発などで、前の工程を完結させて次の工程に移るウォーターフォール型の手法では、手戻りが発生するとコストや時間を大きくロスするため、なるべく手戻りが発生しないよう各工程での検証を厳重に行なうことが求められる。

一方、同じ工程の繰り返し自体を正規のプロセスとみなし、何度も反復する中で次第に完成度を高めていく手法が用いられることもある。

前のサイクルで発見・発生した問題を次のサイクルで解消したり、新しい要求を次のサイクルで実現するなど、ある種の手戻り自体を開発工程の一部に取り込むことで、途中までの成果が無駄になることを避けている。そのような開発手法にはイテレーション型、スパイラル型、インクリメンタル型、プロトタイピング型などの種類がある。

工業製品のモックアップは製品の外観や構造、部品間の干渉などを確認・評価するために作られるもので、実際の素材が金属であっても安価で加工の容易な木材やプラスチック、板紙などで作られる場合もある。

形状やサイズを確認する段階で制作されるものは塗装などは省略されるが、デザインの最終段階で検証を行う場合や営業や販売促進のためのサンプルとして製造されるものは本物そっくりに塗装や装飾などが行われる(逆に内部構造などは省略される)。

Webサイトやアプリのモックアップ

スマートフォンアプリなどのソフトウェアやWebサイト、Webアプリケーションなどの場合、完成後に実際に表示される状態を模した実物そっくりの画像や画面、Webページなどのことをモックアップという。

一方、ページやサイトの構成や遷移関係、ページ内のレイアウトなどを大雑把に示した簡易な図面のことは「ワイヤーフレーム」(wireframe)、実際に操作して動作を確認できる部分的な試作品を「プロトタイプ」(prototype)という。一般的にはワイヤーフレーム、モックアップ、プロトタイプの順に設計と試作を進め、実物の開発・製作に入る。

デジタルモックアップ (DMU：Digital Mock-Up)

工業製品や建築物の製図データなどから外観や構造などを3次元コンピュータグラフィックス(3DCG)として作成し、画面上に映し出す手法を「デジタルモックアップ」(DMU：Digital Mock-Up)という。

モックアップを3Dモデルとして表現する手法で、物理的なモックアップでは手間のかかる彩色や細部の意匠の変更などが短期間でできたり、可動部の動きや内部構造などを実物を制作する前に仮想的に再現して確認できる。

サイズや素材、機構の複雑さなどから実際のモックアップの作成に多額のコストや長い期間が必要な工業製品の場合には、DMUによってコスト低減や試作工程の期間短縮、試作回数の増加などが見込める。モックアップとDMUを併用し、DMUでの検証後に最終段階としてモックアップを作成する場合もある。

DMUを作成・評価する専門のソフトウェアをDMUツールという。設計工程で使われるCADシステムと連携したり、利用者を模した人体模型により使用時の操作性や視認性などを確認したり、組み立てや修理などの作業のしやすさを調べるといった高度な機能を提供する製品もある。

モックアップや概念実証(PoC)とは異なり、製品版と遜色ない機能や性能、外観などを備えており、実際に使用してみることができる。プロトタイプを用いて試験を行い、不具合の修正などを行ったら、これを量産して製品として投入することになる。

製品開発の初期段階でまず動作に必要な最小限の機能のみを実装したプロトタイプを作成し、これを元に試験、評価、修正のサイクルを何度も繰り返しながら徐々に完成度を高めていく手法を「プロトタイピング」(prototyping)という。反復型開発の一種で、ITの分野ではソフトウェアや情報システムの開発で用いられることがある。

プログラミングの分野では、C言語などで関数の宣言部分のみを記述したものをプロトタイプ宣言と呼んだり、JavaScriptなどのオブジェクト指向言語でオブジェクトを定義する際に複製元となるオブジェクトをプロトタイプと呼ぶなど、言語仕様上の特定の要素をプロトタイプと呼ぶことがある。

システムが扱うデータの流れを整理するための図法で、対象となるシステムと利用者や外部のシステムなどのデータの流れを図示する場合と、システム内の構成要素(データストアやプロセスなど)間の流れを図示する場合がある。

データは発生源から様々な処理(プロセス)を経て出力先へ収まる。一つの図にあまり多くの要素を図示すべきではないとされ、。全体的で抽象的なレベルから作図し、段階的に詳細化した図を描いていくという手法が用いられることが多い。

DFDでは、データの保管や取り出しを行う「データストア」を平行な上下二本線で、データを処理するソフトウェアなどの「プロセス」を丸で、データの発生源や出力先である「外部実体」(ターミネータ)を長方形あるいは楕円で示す。これらの要素の間をデータの流れ(フロー)を表す矢印で結んでいく。

プロセスには入力と出力を表す「フロー」がそれぞれ一つ以上必要で、データストアや外部実体は入力または出力のいずれか一方のフローが必要となる。また、各フローの一方の端は必ずプロセスでなければならない。

システムが扱うデータの流れを整理するための図法で、対象となるシステムと利用者や外部のシステムなどのデータの流れを図示する場合と、システム内の構成要素(データストアやプロセスなど)間の流れを図示する場合がある。

データは発生源から様々な処理(プロセス)を経て出力先へ収まる。一つの図にあまり多くの要素を図示すべきではないとされ、。全体的で抽象的なレベルから作図し、段階的に詳細化した図を描いていくという手法が用いられることが多い。

アクティビティでは、データの保管や取り出しを行う「データストア」を平行な上下二本線で、データを処理するソフトウェアなどの「プロセス」を丸で、データの発生源や出力先である「外部実体」(ターミネータ)を長方形あるいは楕円で示す。これらの要素の間をデータの流れ(フロー)を表す矢印で結んでいく。

プロセスには入力と出力を表す「フロー」がそれぞれ一つ以上必要で、データストアや外部実体は入力または出力のいずれか一方のフローが必要となる。また、各フローの一方の端は必ずプロセスでなければならない。

システムが扱うデータの流れを整理するための図法で、対象となるシステムと利用者や外部のシステムなどのデータの流れを図示する場合と、システム内の構成要素(データストアやプロセスなど)間の流れを図示する場合がある。

データは発生源から様々な処理(プロセス)を経て出力先へ収まる。一つの図にあまり多くの要素を図示すべきではないとされ、。全体的で抽象的なレベルから作図し、段階的に詳細化した図を描いていくという手法が用いられることが多い。

データストアでは、データの保管や取り出しを行う「データストア」を平行な上下二本線で、データを処理するソフトウェアなどの「プロセス」を丸で、データの発生源や出力先である「外部実体」(ターミネータ)を長方形あるいは楕円で示す。これらの要素の間をデータの流れ(フロー)を表す矢印で結んでいく。

プロセスには入力と出力を表す「フロー」がそれぞれ一つ以上必要で、データストアや外部実体は入力または出力のいずれか一方のフローが必要となる。また、各フローの一方の端は必ずプロセスでなければならない。

システムが扱うデータの流れを整理するための図法で、対象となるシステムと利用者や外部のシステムなどのデータの流れを図示する場合と、システム内の構成要素(データストアやプロセスなど)間の流れを図示する場合がある。

データは発生源から様々な処理(プロセス)を経て出力先へ収まる。一つの図にあまり多くの要素を図示すべきではないとされ、。全体的で抽象的なレベルから作図し、段階的に詳細化した図を描いていくという手法が用いられることが多い。

データフローでは、データの保管や取り出しを行う「データストア」を平行な上下二本線で、データを処理するソフトウェアなどの「プロセス」を丸で、データの発生源や出力先である「外部実体」(ターミネータ)を長方形あるいは楕円で示す。これらの要素の間をデータの流れ(フロー)を表す矢印で結んでいく。

プロセスには入力と出力を表す「フロー」がそれぞれ一つ以上必要で、データストアや外部実体は入力または出力のいずれか一方のフローが必要となる。また、各フローの一方の端は必ずプロセスでなければならない。

システムが扱うデータの流れを整理するための図法で、対象となるシステムと利用者や外部のシステムなどのデータの流れを図示する場合と、システム内の構成要素(データストアやプロセスなど)間の流れを図示する場合がある。

データは発生源から様々な処理(プロセス)を経て出力先へ収まる。一つの図にあまり多くの要素を図示すべきではないとされ、。全体的で抽象的なレベルから作図し、段階的に詳細化した図を描いていくという手法が用いられることが多い。

プロセスでは、データの保管や取り出しを行う「データストア」を平行な上下二本線で、データを処理するソフトウェアなどの「プロセス」を丸で、データの発生源や出力先である「外部実体」(ターミネータ)を長方形あるいは楕円で示す。これらの要素の間をデータの流れ(フロー)を表す矢印で結んでいく。

プロセスには入力と出力を表す「フロー」がそれぞれ一つ以上必要で、データストアや外部実体は入力または出力のいずれか一方のフローが必要となる。また、各フローの一方の端は必ずプロセスでなければならない。

具体的にどんな存在のことをエンティティと呼ぶかは分野や製品によって異なるため一概には言えないが、一つの物事を表すひとまとまりのデータの集合などを意味することが多い。類義語には「インスタンス」(instance)、「オブジェクト」(object)などがある。

ソフトウェア設計などの分野では、システム上でデータとして取り扱うことができるよう抽象的にモデル化された、現実世界の対象物や概念のことをエンティティということがある。例えば、「学生」というエンティティをシステム上で表すために、「氏名」「学年」「学籍番号」という属性と「進級」「退学」「卒業」という操作の集合として定義する、といったモデル化が行われる。

HTMLエンティティ

HTMLやXMLなどのマークアップ言語では、特殊な記法によって画面上に表示された文字のことをエンティティという。「&」(アンパサンド)と「;」(セミコロン)で挟まれた文字列は表示する文字を指定する特殊な記法であるとみなされ、これを置き換えて実際に表示された文字をエンティティという。例えば、HTMLファイル中で「©」と記述すると画面上ではその箇所が「©」に置き換えられて表示されるが、この「©」という文字のことをエンティティという。

データベースのリレーションシップ

リレーショナルデータベース管理システム(RDBMS)で、複数のテーブルの間で特定のフィールドを関連付ける機能をリレーションシップという。

これにより、テーブル間で同じ情報が重複するのを避けることができ、あるフィールドの入力を別のテーブルの特定のフィールドの項目から選択するようにしたり、複数のテーブルを連結して情報をまとめたりすることができる。

例えば、受注テーブルの顧客コードに、顧客テーブルの顧客コードを関連付ければ、顧客テーブルに登録されていない顧客コードを受注テーブルに誤って入力してしまうことを防ぐことができる。関連付けられた他のテーブル上のフィールド(この例では顧客コード)を「外部キー」(foreign key)という。

一般的なリレーションシップでは外部キーの各項目が複数のレコードに繰り返し登場することがあり、このような関係を「一対多リレーションシップ」という。外部キーの各項目が一つのレコードにしか現れないよう制約する「一対一リレーションシップ」もあるが、使われる場面は少ない。また、両テーブルのフィールドが互いに相手方へ(一対多の)リレーションシップを張った状態を「多対多リレーションシップ」という場合がある。

システムが取り扱う対象とする現実世界の要素を抽象化し、名詞として表すことができるものを「実体」(エンティティ)として矩形で表す。実体は必ずしも物理的な存在とは限らず、情報や行為などでも構わない。

実体間の関係性を表す要素は「関連」あるいは「関係」(リレーションシップ)と呼ばれ、動詞として表すことができるものが該当する。図中では菱形もしくは矩形の間を結ぶ線分として表記される。

実体と関連は共にその性質を表す「属性」(アトリビュート)を複数持つことができる。属性は楕円で表し実体や関連と線分で紐付ける記法と、実体の矩形の中に列挙する記法がある。

多重度

また、記法によっては関連に多重度(cardinality/カーディナリティ)を設定することができるものがある。二つの実体の関連が一対一、一対多、多対多といった対応関係になっていることを表す。

例えば、ER図の表記法の一つであるIE記法では、関連の末端部分に「○」(0を表す)「|」(1を表す)、鳥の足のような三股の枝分かれ(任意の複数を表す)の3つの記号の組み合わせで数を表記する。「|」のみならば「必ず一つ」、「○」と三股ならば「0を含む任意個」を表す。

記法の種類

ER図は1975年にマサチューセッツ工科大学(MIT)のピーター・チェン(Peter Chen)氏がERモデルと共に考案した。氏の提唱したオリジナルの記法は現在ではPeter Chen記法とも呼ばれる。

用途などに応じて微妙に表記法の異なる10以上の記法が考案され、様々な用途に使用されている。中でも有名なものとして、米国立標準技術研究所(NIST)が規格化したIDEF1x記法(IDEF：ICAM Definition Language)、ジェームズ・マーティン(James Martin)氏が考案したIE記法(IE：Information Engineering)がよく利用される。

ソフトウェア開発では、プログラムを作成する前にシステムの設計や構造、振る舞いを定義し、発注者と開発者、あるいは開発チーム内で仕様について共通認識を得る必要がある。その際、説明が文章や箇条書きだけだと分かりにくく、多数の要素の複雑な相互作用などを簡潔に表現することが難しい。

UMLでは、システムをオブジェクトの組み合わせとしてモデル化し、その構造や仕様を図表によって記述するための表記法を定めている。システムの構成要素の定義や、要素間の関連性、要素の振る舞いなどを図示することができる。

図表の描き方が人や組織によってまちまちでは相互理解に支障を来すが、標準化されたUMLという共通の「言語」を用いることで、書き手の意図を正しく読み手に伝えることができる。システムの様々な側面を伝達できるよう、UMLには14種類の図が用意されている。

UMLの仕様は1996年に当時のラショナル・ソフトウェア(Rational Software)社(2003年に米IBM社が買収)が策定した。その後、仕様の策定・改訂は業界団体のOMG(Object Management Group)が行うようになった。UML1.4が2005年にISO/IEC 19501として、UML 2.4が2012年にISO/IEC 19505としてそれぞれ国際標準となっている。

図の種類

UMLで定義される図は大きく分けて、システムの構造を表す「構造図」(structure diagram)と、動作や変化を表す「振る舞い図」(behavior diagram)の2種類に分類される。

構造図には「クラス図」(class diagram)、「オブジェクト図」(object diagram)、「コンポーネント図」(component diagram)、「パッケージ図」(package diagram)、「配置図」(deployment diagram)、「複合構造図」(composite structure diagram)、「プロファイル図」(profile diagram)がある。

振る舞い図には「アクティビティ図」(activity diagram)、「ユースケース図」(use case diagram)、「ステートマシン図」(state machine diagram)、「相互作用図」(interaction diagram)がある。

相互作用図はさらに、「シーケンス図」(sequence diagram)、「コミュニケーション図」(communication diagram、以前はコンポーネント図と呼ばれていた)、「タイミング図」(timing diagram)、「相互作用概要図」(interaction overview diagram)に分かれる。

UML(Unified Modeling Language)はオブジェクト指向のソフトウェア開発において、データ構造や処理の流れなどソフトウェアに関連する様々な設計や仕様を図示するための記法を定めた標準規格である。クラス図はシステムの構造を図示する構造図の一つで、クラスの構成やクラス間の関係を表現することができる。

オブジェクト指向プログラミングでは互いに関連するデータと操作手順を「クラス」という単位で一体的に定義する。クラス図ではクラスを矩形で示し、クラス間の関係を線で表す。クラスを外部から操作する方法だけを定義した「インターフェース」(interface)も矩形で示し、クラスと対応付ける。

矩形の内部にはクラスが表す対象の性質や状態を表す「属性」(property)や、属性に対する操作である「メソッド」(method)を名前やデータ型と共に列挙する。他のクラスから見えるかどうかを指定したい場合は、項目の先頭に「+」(public：どこからでも見える)、「#」(protected：子クラスからのみ見える)、「-」(private：外部からは見えない)、「~」(package：同じパッケージ内から見える)という記号を付ける。

主な関係の種類

クラス間の関係は、クラスをプログラム中で実際に具象化した「インスタンス」(instance)同士の関係と、複数のクラス同士の関係に分かれる。クラス同士の場合もインスタンス同士の場合もありえる関係として「依存」(dependency)があり、あるクラスが機能するためには別のクラスの存在が必要という関係を表す。

インスタンス同士の関係としては、クラス間に何らかの繋がりがあることを示す「関連」(association)、あるクラスが別のクラスの部分を構成する「集約」(aggregation)や「コンポジション」(composition)がある。集約では部品は複数のクラスに属することができるが、コンポジションは所属先がただ一つに定まっている。

クラス同士の関係としては、あるクラスが別のクラスの子クラス(サブクラス)となる「継承」(inheritance)あるいは「特化」(specialization)、逆に、子クラスにとって親クラス(スーパークラス)であることを示す「汎化」(generalization)、抽象クラスやインターフェースで示された仕様を子クラスで具体化する「実現」(realization)あるいは「実装」(implementation)などがある。

role

ITの分野で “role” は、利用者やシステム上の何らかの要素が持つ立場や役割を指すことが多い。

データベース管理システムなどの利用者管理において、利用者のグループあるいは雛形のことをロールということがある。利用者の種類(管理者、開発者、一般利用者など)に応じて作られ、各利用者(のアカウント)はそれぞれのロールに属する。利用者が複数のロールに所属したり、ロールが他のロールに所属してその権限を引き継いだりできるようになっている場合が多い。

UMLのクラス図などで、クラスが他のクラスとの関係上、どのような立場・役割を果たしているのかを示すものをロールあるいはロール名(role name)という。複数のクラスと関連がある場合、相手によって異なる役割を担うこともあり、図上ではクラスとクラスを結ぶ関連を表す直線の終端付近に記入する。

roll

ITの分野で “roll” は、進めたり戻したりといった時間の流れや方向を伴う動作を表すことが多い。「ロール○○」(roll～)のように熟語表現の音写が多用される。

データベース管理システムなどのトランザクション処理で、障害発生時に進行中の処理をキャンセルして過去のある時点の状態を復元することを「ロールバック」(rollback)、過去のデータに実行済みの処理内容を反映させて完了させることを「ロールフォワード」(roll forward)という。

システムの運用開始や全面展開などを「ロールアウト」(rollout)、回数などのカウントや経過時間などが定められた上限を迎えリセットや切り替えなどが行われることなどを「ロールオーバー」(rollover)という。

システムの構造や構成を表す構造図(structure diagram)の一つで、モデルを膨大な数作成する大規模なシステムの全容を把握する場合などに、機能群を分割し、グループ化して整理することができる。

パッケージ図ではタブ付の長方形で一つのパッケージを表現し、この中にパッケージ名及びそのパッケージに所属する各モデル要素を記述する。パッケージ間の汎化・依存関係は、パッケージ間を破線の矢印で結ぶ。

パッケージはモデル要素に加えて別のパッケージを含むことができ、パッケージ間を関係を入れ子構造として表すことができる。オプションとしてステレオタイプを付記することができ、役割などの修飾情報を表すことができる。

パッケージマージ (package merge)

UML 2.0ではパッケージの再利用をより行いやすくするために、「パッケージマージ」という概念が追加された。複数のパッケージを統合(merge)して一つのパッケージとすることができ、既存のパッケージを再利用して新しいパッケージを作成することが容易になる。

パッケージの再利用にはパッケージマージの他に「パッケージインポート」がある。両者の違いはパッケージ間で同じ名前の要素の衝突があったときの処理にある。パッケージマージの場合は汎化の関係になり、双方の要素の特長を合わせ持つものになるが、パッケージインポートの場合はインポート元の要素は隠され、インポート先の要素のみを持つことになる。

想定されるユーザー(利用者や外部の別のシステムなど)を「アクター」(actor)と呼ばれる人型の要素で表し、下にアクター名を付す。アクターがシステムを使って行うことを「ユースケース」(use case)と呼び、楕円の中にユースケース名を記した要素で表す。

各アクターは自らの必要とするユースケースと直線で結ばれる。一つのアクターが複数のユースケースを利用することも、一つのユースケースを複数のアクターが必要とすることもありえる。

複数のユースケースが一つの要素や機能に関連して提供される場合には、「サブジェクト」(subject)と呼ばれるまとまりで括る。サブジェクトは矩形で表され、上部にサブジェクト名を記す。サブジェクトはパッケージとして定義し、別の箇所で再利用することができる。

ユースケース間にも関係を定義することができ、複数のユースケースから共通点を取り出して抽象化する「汎化」(白三角矢印)、一方がもう一方に含まれていることを表す「包含」(黒三角点線矢印に《include》の注釈)、一方に機能を追加してもう一方を定義する「拡張」(黒三角点線矢印に《extend》の注釈)がある。拡張されたユースケースは楕円の内部を上下に区切り上側にユースケース名を、下側に拡張ポイント名を記す。

シーケンス図の上方には、図中に登場するオブジェクトなどの構成要素を横に並べて表示する。それぞれの要素からは下に向かって「ライフライン」(lifeline)と呼ばれる破線が引かれ、その要素が有効である期間を示す。要素が消滅・退場する時点は×印で示し、そこでライフラインが途切れる。

要素が何かを実行している最中であることを示すにはライフライン上に縦長の長方形を描く。これを「実行仕様」(execution specification)という。箱の上端がその動作の開始時、下端が終了時をそれぞれ示す。

メッセージ

ある要素から別の要素へ何らかの作用を及ぼす際には、その二要素間を矢印で結び、線上に作用の内容を表記する。これを「メッセージ」(message)と呼ぶが、データの送受信だけでなく、操作の実行やインスタンスの生成などもメッセージに含まれる。

他の要素からのメッセージに答える「応答(reply)メッセージ」は破線の矢印で示される。送り先の応答を待つ「同期」(synchronous)メッセージは先端が黒三角の矢印で、待たずに先に進む「非同期」(asynchronous)メッセージは先端が三叉の矢印で示す。

また、図上に示されない相手からのメッセージは送り手が黒丸(●)で示された「ファウンドメッセージ」(found message)、図上に示されない相手へのメッセージは送り先が黒丸で示された「ロストメッセージ」(lost message)で表す。

製品を使って利用者が何をしたいのか、どうなることを望んでいるかを、技術的な概念や語彙を極力用いず、利用者が容易に理解できる平易な言葉で記述する。具体的にどういう仕組みや挙動、表示、操作によりそれを実現するかはこの段階では触れない。

一つの希望を一つの文で表現することが望ましく、たくさんのストーリーを箇条書きで列挙したものが利用者が製品に求めるものの総体となる。「私は ～ として ～ のために ～ したい」といった定型文(テンプレート)に当てはめて記述する手法がよく用いられる。

漠然とした大きな目標のようなものを表すストーリーのことは「エピック」(epic)と呼ばれ、より具体的で詳細なストーリーに分割していく。適切な大きさのストーリーの集まりを定義することができたら、各ストーリーを技術的にどのように実現するかを「タスク」(task)として定義し、開発作業に入る。

スクラムなどのアジャイル開発プロセスで用いられる概念で、開発プロジェクトが目指す目標や、ソフトウェアが実現すべき機能などを、大まかなまとまりとして表したものをエピックという。テーマや対象領域のような漠然とした大掴みな内容で構わないとされる。

エピックは作業として取り組む単位としては大きすぎるため、ソフトウェアによって何ができるのかを利用者の視点から定義・記述した複数の「ユーザーストーリー」に分割される。ストーリーは「プロダクトバックログ」というリストに列挙され、一つずつ開発すべき機能として消化されていく。

大規模なプロジェクトやソフトウェアではエピックとストーリーの間に「フィーチャー」(feature)という中間段階を設ける場合もある。逆に、規模が小さい場合はエピックを定義せずに最初からフィーチャーあるいはストーリーを列挙していく場合もある。

スクラムでは作業項目の定義を、利用者にとって何が可能になるかを表す「ユーザーストーリー」(user story)という単位で行う。ソフトウェアが実現すべき複数のストーリーが列挙された後、それぞれがどのような規模なのかを見積もるのにストーリーポイントが用いられる。

一般にポイントは整数で表され、挙げられた項目の中での相対的な大きさを表している。それ自体はプログラムのコード行数や完了までの作業時間など特定の量に対応するわけではない。任意の値を指定可能にする場合もあるが、選びやすいようフィボナッチ数列(1, 2, 3, 5, 8, 13, 21, 40, 61, …)の値から選ぶ方式を用いることが多い。

チーム内でストーリーポイントを決める際には、値の書かれた札を人数分だけ用意し、メンバーが一同に会して各ストーリーについて自分が思うポイントを一斉に挙げる。一致しなければ、なぜその値を選んだのかを発表し(全員ではなく最高点の人と最低点の人のみとすることが多い)、再び一斉に挙げる。この決定法を「プランニングポーカー」(planning poker)という。

スクラムは反復型の開発手法で、一度に全体を開発しようとせず、小さな単位で計画と実装を繰り返し、少しずつ全体の完成度を高めていくというアプローチを取る。一回の反復の単位は「スプリント」(sprint)と呼ばれ、概ね1週間から1か月程度の期間でスプリントを実施する。

スクラムでは開発チームが取り組むべき課題やタスクを「バックログ」(backlog)と呼ばれるリストで管理する。これは一種のでToDoリストであり、課題が優先順位を付けて列挙される。開発プロジェクト全体を通じて参照されるバックログがプロダクトバックログである。

プロダクトバックログには、製品に実装すべき機能(フィーチャー)、既存の開発物に見つかったバグの修正、技術的負債の解消、今後の開発で必要となる知識獲得や情報収集などの項目が組み込まれる。現在プロジェクトに必要とされる課題や作業はすべて含まれている必要があり、反復が進むに連れてバグ修正などが新たに追加されていく。

毎回のスプリントでは、プロダクトバックログの内容に基づいて、当該スプリントで取り組むべき作業や課題を「スプリントバックログ」として抽出する。スプリント期間中はこれをすべて消化することを目標にチームが作業を進めていく。スプリントが終わると、プロダクトバックログから完了した項目を取り除き、新たに生まれた項目があれば追加する。

開発期間中には、プロダクトオーナーと開発チームが揃って定期的に「リファインメント」というミーティングを実施し、プロダクトバックログの項目を再検討する。各項目について関係者全員が認識を揃え、内容の詳細化や明瞭化を行う。検討結果によっては項目の追加や削除、分割、優先順位の入れ替えなどが行われることがある。

一般的な表現形式では、表の上半分を条件、下半分を判断(動作、行動ということもある)とし、左端の列に条件や判断の項目を列挙する。条件の行には右にその正否(当てはまるか否か)を列挙していくが、このとき各列の正否の組み合わせがすべて異なるようにする。判断の行には、各列の条件の組み合わせの時にどのような判断となるかを記載していく。

列の数は条件の組み合わせの数だけ必要なため、2の条件数乗となる。すなわち、条件が2つなら(条件A：Yes,条件B：Yes)(Yes,No)(No,Yes)(No,No)の4列だが、3つなら8列、4つなら16列といったように条件が増えることに2倍に増えていく。

決定表は様々な分野で用いられるが、ITの分野ではシステム開発などでシステムの挙動を指定するために仕様書などに記載したり、テスト時にテストケースと正しい結果の対応関係を分かりやすく整理するために用いられることが多い。

SysMLが対象とする「システム」とは、個々の要素が相互に影響しあいながら、全体として機能するまとまりや仕組みのことで、情報システムやソフトウェアに限らない。機械や施設、組織、工程、情報など様々な人工物や仕組みの記述に用いることができる。SysMLはシステムの構造や振る舞いを図表を用いて記述し、設計や分析、検証などを行うことができる。

UML 2.0の仕様のうち「アクティビティ図」「シーケンス図」「ユースケース図」「ステートマシン図」「パッケージ図」を踏襲し、UMLの「クラス図」は「ブロック定義図」、「複合構造図」(コンポジット構造図)は「内部ブロック図」として定義されている。また、UMLにはない「要求図」「パラメトリック図」が追加されている。UMLでは基本的には表を使わないが、SysMLでは「アロケーションテーブル」と呼ばれる表を多用する。

SysMLの仕様は、システム工学の国際的な専門家組織INCOSE(International Council on Systems Engineering)とUML標準を管轄するOMG(Object Management Group)の合同作業部会によって検討・策定された。INCOSE側からは2005年にオープンソースのSysML仕様が公表され、OMGからは2007年に「OMG SysML」という標準規格が発行された。この仕様を元に、2017年には国際標準化機構(ISO)と国際電気標準会議(IEC)の合同委員会が「ISO/IEC 19514」という国際規格を策定した。

ITの分野では、人や組織が提供する役務といった一般の外来語としての意味に追加して、コンピュータなどの機器やソフトウェアが、利用者や他の機器、ソフトウェアなどに対して提供する機能や働きのことをサービスということがある。

Windowsのサービス

Windowsでは、利用者や実行中のソフトウェアの求めに応じて即座に何らかの機能を提供できるよう、起動された状態でシステムに常駐するプログラムのことをサービスという。

システムやデータの管理や監視のための機能や、多くのソフトウェアが共通して必要とする汎用的な機能などを実装したもので、通常は操作画面などを持たず、利用者が直接操作することはほとんどない。

Windowsがオペレーティングシステム(OS)の機能の一部として標準的に提供するもののほかに、個々のアプリケーションソフトが提供するものがある。起動時に自動的に実行されるよう設定されており、コントロールパネルの「サービス」アプリから実行、停止、再起動を行うことができる。起動時の自動実行の有無も切り替えることができる。

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

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

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

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

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

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

例えば、同じ機能を持つサーバを二台用意しておき、一方でシステムを稼働させもう一方を待機しておけば、稼働系が装置の故障などにより停止しても、即座に待機系に切り替えることにより運用を続行することができる。このように、互いに役割を代替することができる複数の系統を準備しておくことを冗長化という。

複数系統の一つが稼働して残りが待機する方式(アクティブ/スタンバイ構成、アクティブ/パッシブ構成などという)以外にも、普段から全系統が並列に稼働して負荷を分散しており、一部が停止しても残りの系統で機能を維持する方式(アクティブ/アクティブ構成)もある。

情報システムや機器、装置の冗長化以外にも、通信回線やデータ伝送路の冗長化、誤り訂正符号の付加など情報の冗長化、組織や人員配置の冗長化などもある。ITの分野に限らず様々な分野で一般的に行われる信頼性向上策であり、例えば航空機エンジンが一基停止しても飛び続けられるなどの例は有名である。

冗長化を行うには系統を単体で導入するより倍以上のコストが掛かるのが一般的であるため、コストを負担してでも無停止で運用することが要求される場合に行われる。ITの分野では政府や大企業の基幹システム、金融機関やインフラ事業者のシステムや通信回線などでよく用いられる。

一方、停止すると系全体が停止するような構成要素のことを単一障害点(SPOF：Single Point Of Failure)という。構成要素が多岐にわたるシステムの場合、一部の要素を冗長化してもSPOFが残っているとそこが停止すれば全体が停止してしまう「弱点」「急所」となってしまうため、いかにSPOFを残さないよう冗長化するかが重要となる。

事故や故障などが起きることを前提に、重要な機能を提供する機器を複数用意したり、一か所の問題が他へ拡大しにくい構造にするなどの手法で備え、一部が機能を失っても全体の性能や機能を落とさずに稼働を続行するような仕組みや考え方を意味する。

例えば、電源装置を二重化して片方が故障しても電源が落ちないコンピュータや、停電すると発電機が起動して電力を供給し続けるビル、二系統の通信回線を引き込み、片方が不通になってももう一方で外部と通信し続けるデータセンターなどがフォールトトレラント設計を考慮した設計と言える。

とはいえ、どのような損害を受けてもいつまでも正常に稼働し続けるシステムは作ることができないため、損害を受けてから機能を維持し続けられる時間が限られたり(発電機を備えたビルでも多くは数日分の燃料しか備蓄できない)、損害の大きさによっては稼働は継続するが機能や性能が低下したりすることもある。

一方、問題の個所を切り離したり停止するなどして機能や性能を低下させて稼働を継続することは「フェイルソフト」(fail soft)、問題が起きた時になるべく安全な状態に移行するよう制御することは「フェイルセーフ」(fail safe)、誤操作しても危険が生じない、あるいは誤操作できない構造や仕組みに設計することは「フールプルーフ」(foolproof)とそれぞれ呼ばれる。フォールトトレラント設計をこれらの概念の総称として用いることもある。

また、なるべく故障や障害が生じないようにすることは「フォールトアボイダンス」(fault avoidance)と呼ばれ、フォールトトレランスと対になる概念として用いられる。

個別の具体的な製品などの仕様や実装などではなく、抽象的あるいは基本的な構造や設計、動作原理、実現方式などを表すことが多い。また、製品シリーズなどに共通する仕様や設計のことや、特定の技術や構成要素に関する共通化・規格化された仕様などのことをアーキテクチャということもある。IT分野では俗に “arch” 「アーキ」等と略されることがある。

企業などの情報システムの分野では、個別のソフトウェアやシステムの仕様や設計よりも上位の、全社的なITシステムの全体構成や共通基盤、システムの仕様や設計、実装、運用などに関する規定や標準などの総体をアーキテクチャという。アーキテクチャの設計者を「アーキテクト」(architect：原義は建築士)という。

CPUアーキテクチャ

CPU(マイクロプロセッサ)の分野では、プロセッサに指示を与えるための命令の体系を定義した「命令セットアーキテクチャ」(ISA：Instruction Set Architecture)と、プロセッサ内部をどのような構造や構成にするかを表した「マイクロアーキテクチャ」(microarchitecture)の二つのアーキテクチャが用いられる。

命令セットアーキテクチャはCPUに与えるプログラムを記述する機械語の仕様を定めたもので、メーカーや機種、内部の回路設計などが異なっていても、同じ命令セットを実装していれば同じソフトウェアをそのまま実行することができる。

マイクロアーキテクチャは演算や制御などを行う具体的な回路の設計や構造を指す。同じメーカーの同じ製品シリーズのCPUは、過去の製品から命令セットを受け継ぎながら拡張していき、マイクロアーキテクチャは製品ごとに毎回設計し直して高速化や並列化を進めることが多い。

専門の事業者がデータセンター施設に設置・運用しているコンピュータやネットワーク環境などを契約者が借り受け、遠隔から操作して自分の必要なソフトウェアを組み込んで稼働させることができる。事業者のコンピュータなどを借り受けて使用するレンタルサーバやホスティングサービスは従来からあり、IaaSもその延長にあるが、より柔軟で包括的なサービスを指すことが多い。

IaaSの場合、一台単位で物理的に固定されたコンピュータ自体を貸し出すのではなく、物理コンピュータ上に仮想化技術で作り出された特定の仕様を持つ仮想サーバ(サーバインスタンス)を単位に契約が行われることが多い。これにより、メンテナンスや障害発生時などに速やかに別の機材に移転して稼働を続行したり、処理の負荷の増減に合わせて柔軟に資源の追加・削減(スケーリング)ができるといった利点がある。

料金は月額固定制の場合もあるが、基本料金に加えて一ヶ月の資源の使用量(外部へのデータ送信量など)の実績に応じた従量制を取るサービスが多い。企業などでシステムを運用する場合、自社内設置(オンプレミス)だと固定的に設備(その多くは税法上の資産)や人員を抱えることになるが、金額が同水準でもサービス料の形で支払う方が財務・会計の都合上好ましい場合も多い。

IaaSで提供されるのはコンピュータのハードウェア環境であるため、使用するオペレーティングシステム(OS)やミドルウェア、アプリケーションソフトなどは契約者側で用意して導入・設定する必要がある。OSなど特定の環境がある程度導入済みのコンピュータをサービスとして提供する形態は「PaaS」(Platform as a Service)という。

代表的なサービスとして、米アマゾンドットコム(Amazon.com)がAmazon Web Services(AWS)の一部として提供している「Amazon Elastic Compute Cloud」(Amazon EC2)や、米グーグル(Google)社がGoogle Cloud Platform(GCP)の一部として提供している「Google Compute Engine」(GCE)、米マイクロソフト(Microsoft)社がMicrosoft Azureの一部として提供している「Azure IaaS」などがよく知られる。

通常の場合、企業などで業務用システムなどを運用するには、コンピュータなどの機器にオペレーティングシステム(OS)、プログラミング言語処理系、ライブラリ、ミドルウェア、フレームワークなどを導入・設定し、実行環境を構築しなければならない。

PaaSは専門の事業者がデータセンターに設置したサーバにこのようなソフトウェア環境を構築したもので、これをインターネットを経由して契約者に貸し出して利用させる。顧客は実行したいアプリケーションを持ち込んで実行するだけですぐにシステムを運用でき、メンテナンスや障害対応なども事業者に任せることができる。

PaaSでは利用者が操作・設定可能なのはOSよりも上の階層であり、ハードウェアや仮想マシンの動作に直に介入することはできないが、逆に、これらの設定や運用などを自ら行う必要がなく、事業者側にすべて任せることができると捉えることもできる。

提供されるコンピュータは仮想化されており、利用者が必要に応じて性能などを指定することができる場合が多い。設備が固定されている自社運用(オンプレミス)とは異なり、突発的な負荷の増大に合わせて一時的に性能や容量を割り当てたり、負荷に応じて柔軟に性能の伸縮や契約の切り替えを行える点が大きな特徴である。

料金は契約期間に応じた月額基本料金にシステムの使用量(CPU実行時間や外部への送信データ量など)に応じた従量課金を加えた課金体系になっていることが多い。契約者は固定的に人員や設備を抱えることなく必要な分だけサービス料を支払って利用する形となる。

よく知られるPaaSとしては、米アマゾンドットコム(Amazon.com)がAmazon Web Services(AWS)の一部として提供している「Amazon Lambda」や「Elastic Beanstalk」などのサービス、米グーグル(Google)社がGoogle Cloud Platform(GCP)の一部として提供している「Google App Engine」(GAE)、米マイクロソフト(Microsoft)社がMicrosoft Azureの一部として提供している「Azure Cloud Services」、米セーフルフォース・ドットコム(Salesforce.com)社の「Force.com」や「Heroku」、などがよく知られる。

一方、仮想化されたハードウェア環境を遠隔からサービスとして操作・利用できるようにしたものを「IaaS」(Infrastructure as a Service)、具体的な特定のアプリケーションをインターネットを通じてサービスとして利用できるようにしたものを「SaaS」(Software as a Service)という。

従来、ソフトウェアを使用するには利用者がパッケージなどを入手して手元のコンピュータにプログラムを複製、導入し、これを起動して操作する方式が一般的だった。SaaSではソフトウェアの中核部分は事業者の運用するサーバコンピュータ上で実行され、利用者はネットワークを通じてその機能を遠隔から利用する。

利用者側には表示・操作(ユーザーインターフェース)のために最低限必要な機能のみを実装した簡易なクライアントソフトが提供される。専用のクライアントを導入する場合もあるが、一般的には全体をWebアプリケーションとして設計し、利用者はWebブラウザを通じてWebページとして実装されたクライアントを都度ダウンロードして起動する形を取ることが多い。

SaaS方式のソフトウェア提供は2000年代中頃からSFA(営業支援システム)やグループウェアなど業務用ソフトウェアを中心に広まり始め、2010年代以降はERPなどの大規模システム、あるいはオフィスソフト、ゲーム、メッセージソフト(Webメールなど)といった個人向けを含む様々な種類のソフトウェアで一般的になっている。

利用者側の特徴

利用者はサービスへ登録・加入するだけで、ソフトウェアの入手や導入を行わなくてもすぐに使い始めることができる。データも原則としてサーバ側に保管されるため、ソフトウェアやデータの入ったコンピュータを持ち歩かなくても、移動先などで普段とは別の端末からログインして前回の作業の続きを行うことができる。

料金もパッケージソフトのように最初に一度だけ所定の金額を支払う「買い切り」型ではなく、契約期間に基づく月額課金や、何らかの使用実績に応じた従量課金が一般的となっている。登録や利用は原則無料で高度な機能や容量などに課金する方式や、広告を表示するなどして完全に無償で提供されるサービスもある。

ただし、利用のためにはインターネット環境が必須で、回線状況によっては操作に対する応答に時間がかかる場合もある。また、サービスを脱退したりサービスが終了してしまうとソフトウェアを使用できなくなり、サーバ側に保存したデータにもアクセスできなくなる。データについては特定の形式でまとめて利用者側にダウンロードできる機能が提供されている場合もある。

事業者側の特徴

提供者側から見ると、システムの中核部分はサーバ側で実行され、Webブラウザなどをクライアントとするため、機種やオペレーティングシステム(OS)ごとに個別にソフトウェアを開発・提供する場合に比べ様々な環境に対応しやすい。

また、サーバ側でソフトウェアを常に最新の状態に保つことができ、機能追加や不具合の修正などを利用者側へ迅速に反映できる。機能を細かく分けて利用者が自分に必要なものだけを選んで契約するといった柔軟な提供方式にも対応しやすい。

ただし、処理の多くをサーバ側で行う必要があるため、利用者数や利用頻度などに応じてサーバの台数や性能、データ保管容量などを適切に用意し、必要に応じて増強しなければならない。インターネットを通じてサービスを提供するため回線容量なども提供規模に応じて必要で、単にソフトウェアを販売するより事業者側の投資やコストは重くなりがちである。

PaaS/IaaSとの違い

インターネットを通じて様々な資源や機能をサービスとして遠隔の顧客へ提供する事業形態はSaaS以外にも存在し、総称して「XaaS」(X as a Service：サービスとしての○○)と呼ぶ。

このうち、導入・設定済みのOSやサーバソフト、言語処理系など、アプリケーション実行環境一式(プラットフォーム)をサービスとして遠隔から自由に利用できるようにしたものを「PaaS」(Platform as a Service：サービスとしてのプラットフォーム)という。

また、情報システムの稼動に必要な機材や回線などのIT基盤(インフラ)をサービスとして提供するものを「IaaS」(Infrastructure as a Service：サービスとしてのインフラ)という。これらは主に企業などの情報システム部門やネットサービス事業者などが自らのアプリケーションの実行環境として使用するために提供される。

既成品という意味のパッケージ

既成品という意味のソフトウェアパッケージは、開発元が自ら設計・開発して完成品として流通事業者や顧客に販売しているソフトウェア製品を指し、利用者の要望に応じて個別に設計・開発されるオーダーメイドのソフトウェアと対比される。

個人が購入・利用するソフトウェアのほとんどはパッケージだが、企業などの情報システムでは構想時にパッケージと個別開発を比較検討してどちらにするか選択することがある。ソフトウェアパッケージの中には機能を改変したり追加できる仕組みを提供しているものもあり、これを利用して一部を自らの必要に応じて作り変える(カスタマイズ)場合もある。

ソフトウェアパッケージはすでに完成して販売されている製品であるため、利用者側にとっては設計や開発にかかる時間を省いてすぐに購入して利用することができる。他にも利用者がいるため、使用ノウハウなどの有益な情報を開発元から得るだけでなく利用者間で共有できる場合がある。多数の利用者が日々使用することで問題点なども早期に発見され、速やかに修正されることが期待される。コストも同規模、同機能、同性能で比較すればほとんどの場合既成品の方が安い。

ただし、仕様は開発元が策定し、潜在的利用者が共通して求めると想定される最大公約数的な内容であることが多いため、個々の利用者にとっては自らにとって必要な機能が不足していたり、不要な機能ばかり多く費用対効果が低かったりする場合もある。当然ながら自分(自社)しか使用しない特殊な機能などが標準で実装されることは期待できない。

物理的な梱包という意味のパッケージ

提供方式としてのソフトウェアパッケージは、プログラムやデータがCD-ROMやDVD-ROM、Blu-ray Discなどの物理的なメディアに記録され、マニュアルや保証書、利用許諾契約書(ライセンス)などと共に紙箱やプラスチックケースなどに梱包されて利用者に届けられるものを指す。店頭で販売され利用者が購入して持ち帰る場合と、オンラインで注文して宅配便などで配達される場合がある。

インターネットを通じてプログラムなどを配布するダウンロード販売(オンラインソフト)や、Webブラウザなどを介してインターネット上のサービスとしてソフトウェアの機能を提供するSaaS/クラウドサービスなどと対比される。

インターネット回線が低速だったりWebシステムの機能が貧弱な時代にはソフトウェア製品の標準的な提供手段だったが、現代ではスマホアプリのようにネットワークを通じた提供が一般的になり、パッケージ販売はパソコン向けの一部の製品で行われるのみとなっている。

多くのアプリケーションで共通して利用される機能やハードウェアの基本的な制御機能などは、個別に開発するのは非効率であるため、通常はOSの機能として提供され、アプリケーションはOSの機能を利用するだけで済むようになっている。

ただ、そのようなOSの機能はほとんどのアプリケーションが必要とするような極めて基本的・汎用的なものに限られるため、特定の分野でしか使われないが、その分野では必ず必要とされるような機能がミドルウェアとして提供されることが多い。

また、ミドルウェアの中には複数のOSやハードウェアに対応し、OSや機種ごとの差異を吸収する設計となっているものもある。アプリケーション開発者はシステムごとの違いを気にせずに、効率的に開発を進めることができる。

ミドルウェアの種類

どのような機能がミドルウェアとして提供されるかは分野によって大きく異なる。インターネット上のサーバなどではWebサーバやデータベース管理システム(DBMS)、アプリケーションサーバ、データ連携ツールなどが該当する。

業務システムなどでは、こうしたアプリケーションの基盤となる機能だけでなく、自身がアプリケーションとして動作し、システムの運用や管理など行うものをミドルウェアと呼ぶことがある。例えば、バックアップソフト、クラスタソフト、システム監視ツール、運用管理ツールなどである。

組み込みシステムのミドルウェア

産業機械やデジタル家電といった、いわゆる組み込みシステムでは、機器の性能や記憶容量が乏しく、分野や用途によって必要なソフトウェアの機能が大きく異なるため、OS標準の機能が最小限に絞り込まれていることが多い。

このため、パソコンやサーバではOSが提供するような基本的な機能も必要な場合にのみミドルウェアとして組み入れる仕組みになっている場合もある。ファイルシステムやネットワーク通信、グラフィック表示の操作画面(GUI：Graphical User Interface)などの機能である。

ライブラリやモジュールとの違い

汎用的な機能をアプリケーションに提供するソフトウェアには「ライブラリ」(library)や「モジュール」(module)なども存在するが、これらは単体では動作しないプログラム部品として提供され、アプリケーションの一部に組み込まれて一体的に動作する。

一方、DBMSのようなミドルウェアは単体で動作するソフトウェアであり、システム上に常駐して外部から処理依頼を受け付け、結果を送り返す。アプリケーション本体とは独立しており、配布や導入・設定、起動や終了などもアプリケーションとは別に行われるのが一般的である。

個別の具体的な製品などの仕様や実装などではなく、抽象的あるいは基本的な構造や設計、動作原理、実現方式などを表すことが多い。また、製品シリーズなどに共通する仕様や設計のことや、特定の技術や構成要素に関する共通化・規格化された仕様などのことをアーキテクチャということもある。IT分野では俗に “arch” 「アーキ」等と略されることがある。

企業などの情報システムの分野では、個別のソフトウェアやシステムの仕様や設計よりも上位の、全社的なITシステムの全体構成や共通基盤、システムの仕様や設計、実装、運用などに関する規定や標準などの総体をアーキテクチャという。アーキテクチャの設計者を「アーキテクト」(architect：原義は建築士)という。

CPUアーキテクチャ

CPU(マイクロプロセッサ)の分野では、プロセッサに指示を与えるための命令の体系を定義した「命令セットアーキテクチャ」(ISA：Instruction Set Architecture)と、プロセッサ内部をどのような構造や構成にするかを表した「マイクロアーキテクチャ」(microarchitecture)の二つのアーキテクチャが用いられる。

命令セットアーキテクチャはCPUに与えるプログラムを記述する機械語の仕様を定めたもので、メーカーや機種、内部の回路設計などが異なっていても、同じ命令セットを実装していれば同じソフトウェアをそのまま実行することができる。

マイクロアーキテクチャは演算や制御などを行う具体的な回路の設計や構造を指す。同じメーカーの同じ製品シリーズのCPUは、過去の製品から命令セットを受け継ぎながら拡張していき、マイクロアーキテクチャは製品ごとに毎回設計し直して高速化や並列化を進めることが多い。

データの入出力などを行なう端末やコンピュータが様々な箇所に複数(規模によっては多数)配置されるが、そこではデータの処理は行わず、中央のコンピュータ(施設)にデータを運搬あるいは送信し、集中的に処理を実行する。

管理が容易でコスト効率が高く、セキュリティを確保しやすいが、システム全体の性能や容量が中央コンピュータのそれに制約されるほか、中央コンピュータに障害などが発生すると全体が停止するリスクがある。

一方、端末などに処理能力を持たせたり、複数の大型コンピュータや施設を設置するなどして、複数のコンピュータや施設で分散して並列に処理を行う方式を「分散処理」(decentralized processing)という。

複数の実行主体で矛盾なく処理を分担できるよう特別に設計されたソフトウェアを用い、処理やデータを細かい単位で複数のシステムに割り当てて同時並行に進める。単体では平凡な性能のコンピュータでも、多数を連携させて分散することにより全体としては巨大な演算性能を得ることができる。

一か所の施設などに同じ機種やOSで稼働するコンピュータを集め、ネットワークで接続して連携させたものを「クラスタシステム」あるいは「コンピュータクラスタ」と呼び(性能目的の場合は特にHPCクラスタと呼ばれる)、インターネットなどを通じて広域的に、あるいは様々な機種のコンピュータを束ねて処理を依頼する方式を「グリッドコンピューティング」(grid computing)という。

一方、一台のコンピュータに複数のマイクロプロセッサ(CPU/MPU)を搭載(あるいは一つのプロセッサに複数のプロセッサコアを内蔵)し、複数のプログラムやデータを同時に処理することは「マルチプロセッシング」(multiprocessing)あるいは「並列処理」(parallel processing/並列コンピューティング/parallel computing)という。

個々の処理やデータの関連性や相互依存性が強く、ノード間のデータ送受信や全体の調整・統合処理が頻繁に必要となる科学技術シミュレーションなどは並列処理が向いており、相互の関連性が低くノード間の緊密な連携が不要な暗号解読などの処理には分散処理が向いている。

サービスは独立して動作するプログラムで、ビジネス上の観点からある特定の一つの機能のみを実装する。サービス間はHTTPのような軽量で標準的なプロトコル(通信規約)で通信し、事前に定義されたAPI(Application Programming Interface)によって互いの機能やデータを利用しあって連携する。

サービスは独立に開発することができ、各サービスを開発するチームも並行に作業を進めることができる。サービスごとに最適な開発手法を取ることができ、各々異なる言語やフレームワークが採用されることもある。欠陥の修正や性能の改善といった変更もサービス単位で行われ、他のサービスやシステム全体に影響を与えずに独立にリビルドやデプロイを実施できる。

実行、運用もサービスごとに独立しているため、各サービスを別々の物理サーバで実行したり、オンプレミスとクラウドに分けて配置するなど柔軟に構成を決定、変更できる。一部のサービスが停止してもその機能だけを中断して他のサービスの運用を続行したり、特定のサービスの負荷が高まった際にそこだけ性能を増強するといった対応を行うこともできる。

開発者がアプリケーションをネットワークに公開したい場合、通常は自前のサーバ設備を用意したり、サーバを貸与するホスティングサービスなどに申し込んで専用のソフトウェア実行環境の導入や初期設定を行い、アプリケーションを配備して実行を開始する。

一方、サーバレス方式の場合、クラウド事業者に利用を申し込む所までは同じだが、サーバ環境は事業者側で既に運用されており、アプリケーションを構成するプログラムなどを送信するだけで即座に実行を開始することができる。

初期設定や管理、運用などはすべて事業者側が行ってくれるため、契約者は自前のアプリケーション開発に集中することができる。利用料金も従量課金制の場合が多く、配備したプログラムが実行される度に、外部からのリクエスト回数やCPU実行時間などに単価を乗じた金額が請求される。

性能や容量の割り当ても完全に動的に行われるため、利用がなければ費用もかからず、突然の利用増にも瞬時に自動で対応することができる。ただし、開発に用いるプログラミング言語やミドルウェア、APIなどは原則として事業者側に用意されているものしか利用できないため、サーバをゼロから自前で構築する場合に比べて自由度は低い。

サーバレス方式のクラウドサービスには、開発したプログラムを関数単位で公開できる「FaaS」(Function-as-a-Service)と、アプリケーションが必要とする機能をAPIを通じて提供する「BaaS」(Backend-as-a-Service)がある。前者としては米アマゾンドットコム(Amazon.com)社の「AWS Lambda」や米マイクロソフト(Microsoft)社の「Azure Functions」、米グーグル(Google)社の「Google Cloud Functions」などが、後者としてはGoogle社の「Firebase」などがよく知られる。

クライアントサーバ方式の一種で、Webサーバがデータの保存や処理を行い、利用者がWebクライアント(通常はWebブラウザ)でサーバにアクセスし、データの閲覧や操作を行う。データはサーバ側で管理され、ブラウザさえあればどこからでも利用できる。

サーバとクライアントの間の通信方式(プロトコル)にはHTTPやHTTPSを、操作画面の構成にはHTMLやCSS、JavaScriptなどを用いる。インターネット上で標準的に用いられているWeb関連技術や開発ツールなどをそのまま流用することができ、ゼロからこれらの技術仕様や実装を設計・開発しなくて良いという利点がある。

また、WebサーバやWebブラウザをはじめ、WebアプリケーションフレームワークやJavaScriptライブラリなど多くのオープンソースソフトウェアや無償配布のソフトウェアを活用することができ、コスト低減や開発期間の短縮が期待できる。

特に、Webブラウザはほとんどの企業や家庭で導入されて日常的に利用されており、専用のクライアントソフトを端末に導入したり操作法に習熟する必要がないため、一般消費者向けのネットサービスなどで特に強い優位性となる。

ただし、Web技術はもともと静的な文書をページ単位で記述・伝送・閲覧することを想定したシステムとして始まったため、ネイティブアプリケーションのように端末の機能をフルに活用できるわけではなく、用途によっては専用システムを開発する場合に比べて機能や性能に大きな制約が生じることがある。

サーバはシステムで利用されるデータを保存・管理したり、接続された周辺機器などのハードウェアを管理したり、何らかのデータ処理機能を有するコンピュータやその上で動作するソフトウェアで、これらの機能や情報などをネットワークを通じて外部に提供することができる。

クライアントはサーバから機能や情報の提供を受ける機器やソフトウェアで、利用者が手元で操作し、画面表示や入力の受付などを担当する。クライアントはネットワークを通じてサーバに様々な要求を送り、サーバがこれに応えて処理を行い、応答を返す。

狭義には、企業などの情報システムの実装形態の一つで、機能や情報を提供するサーバソフトウェアと、これに対応する専用のクライアントソフトウェアにより役割を分担して処理を進める方式のことをクライアントサーバシステムと呼ぶことがある。

この文脈では、クライアントとしてWebブラウザなど汎用の製品を用いる「Webアプリケーション」(Web系システム)などは区別・対比される。広義には(あるいは、原理的には)、Webもクライアント-サーバ型のモデルで実現されるシステムであるため注意が必要である。

他の方式との違い

1980年代頃から普及し始めたシステム形態で、それ以前はメインフレームなどの大型コンピュータ(ホスト)などに通信回線を通じて入出力端末(ターミナル)を接続し、ホストが集中的に処理を行う方式が一般的だった。

クライアントサーバシステムと比べると、ホストとサーバ、ターミナルとクライアントの役割はそれぞれ似ているが、ターミナルにコンピュータとしての機能がなく表示や操作に単純な方式しか利用できない一方、クライアントは独立した一台のコンピュータやデジタル機器であり、サーバから受信したデータを用いて複雑な処理や表示、操作などを利用者に提供することができる。

ちなみに、サーバとクライアントのように非対称に役割を分担するのではなく、対等な機能や立場のコンピュータやソフトウェアがネットワークを通じて相互に要求や応答を送り合って一つの機能を実現する形態もあり、「ピアツーピアシステム」(Peer to Peer system、P2Pシステム)などと呼ばれる。

モックアップや概念実証(PoC)とは異なり、製品版と遜色ない機能や性能、外観などを備えており、実際に使用してみることができる。プロトタイプを用いて試験を行い、不具合の修正などを行ったら、これを量産して製品として投入することになる。

製品開発の初期段階でまず動作に必要な最小限の機能のみを実装したプロトタイプを作成し、これを元に試験、評価、修正のサイクルを何度も繰り返しながら徐々に完成度を高めていく手法を「プロトタイピング」(prototyping)という。反復型開発の一種で、ITの分野ではソフトウェアや情報システムの開発で用いられることがある。

プログラミングの分野では、C言語などで関数の宣言部分のみを記述したものをプロトタイプ宣言と呼んだり、JavaScriptなどのオブジェクト指向言語でオブジェクトを定義する際に複製元となるオブジェクトをプロトタイプと呼ぶなど、言語仕様上の特定の要素をプロトタイプと呼ぶことがある。

業務などで使用するシステムは様々な現実の存在を反映したデータを取り扱うが、システムの利用目的に照らして必要な情報(だけ)を、コンピュータプログラムによる自動処理に適した構造や形式で記録する必要がある。

現実の存在をどのようにデータとして表現するかを定めた取り決めがデータモデルで、データベースを用いたシステム開発などの際に設計作業の一環として作成される。データモデルを作成することを「データモデリング」(data modelling)という。

データモデルの表現形式や構築法には様々な手法があるが、例えば「ERモデル」(Entity-Relationship Model)を用いる場合、対象のうち名詞として表されるものを「実体」(entity)、実体間の関連性を「関係」(relation)、実体や関連の持つ性質を「属性」(attribute)として整理する。作成したモデルはER図などの形で図示して関係者間で共有することが多い。

人間による世界解釈からコンピュータの記憶装置上でのデータ構造へ落とし込んでいくため、対象全体を大まかにモデル化した「概念データモデル」、システム上で取り扱うデータをすべて詳細に定義した「論理データモデル」、論理データモデルをコンピュータ上の具体的な記録形式に変換した「物理データモデル」の三段階で詳細化する方式が用いられることがある。

企業などの情報システムではデータモデルが表すデータの格納先としてリレーショナルデータベース(RDB)が用いられることが多く、データモデルをもとに具体的なデータベーススキーマなどを設計し、データベース管理システム(DBMS)上でテーブルの構築などをしていく。

実際のプログラミング言語や架空の言語(擬似言語)を用いて、処理内容をプログラムコード風に書き下したものである。特定の言語における有効なソースコードにはなっておらず、コンピュータ上で実行してみることはできない。

よく見られるのは「if(現在時刻が12時より前) AMと表示 else PMと表示」のように、制御構文などは実際のプログラミング言語風だが、処理内容は日本語などの自然言語で人間が理解しやすいように書かれているコードである。実際に動くコードにするためには自然言語の部分をプログラミング言語の仕様に則った厳密な記述に改める必要がある。

逆に、「もし hour<=12 なら 表示("AM") そうでなければ 表示("PM")」といったように、制御文などを自然言語風に表記して、処理内容をプログラミング言語風に曖昧さ無く記述する様式もある。試験問題など、読み手の解釈次第で理解が大きく異なっては困る場合に好まれる記法である。

システムが取り扱う対象とする現実世界の要素を抽象化し、名詞として表すことができるものを「実体」(エンティティ)として矩形で表す。実体は必ずしも物理的な存在とは限らず、情報や行為などでも構わない。

実体間の関係性を表す要素は「関連」あるいは「関係」(リレーションシップ)と呼ばれ、動詞として表すことができるものが該当する。図中では菱形もしくは矩形の間を結ぶ線分として表記される。

実体と関連は共にその性質を表す「属性」(アトリビュート)を複数持つことができる。属性は楕円で表し実体や関連と線分で紐付ける記法と、実体の矩形の中に列挙する記法がある。

多重度

また、記法によっては関連に多重度(cardinality/カーディナリティ)を設定することができるものがある。二つの実体の関連が一対一、一対多、多対多といった対応関係になっていることを表す。

例えば、ER図の表記法の一つであるIE記法では、関連の末端部分に「○」(0を表す)「|」(1を表す)、鳥の足のような三股の枝分かれ(任意の複数を表す)の3つの記号の組み合わせで数を表記する。「|」のみならば「必ず一つ」、「○」と三股ならば「0を含む任意個」を表す。

記法の種類

ER図は1975年にマサチューセッツ工科大学(MIT)のピーター・チェン(Peter Chen)氏がERモデルと共に考案した。氏の提唱したオリジナルの記法は現在ではPeter Chen記法とも呼ばれる。

用途などに応じて微妙に表記法の異なる10以上の記法が考案され、様々な用途に使用されている。中でも有名なものとして、米国立標準技術研究所(NIST)が規格化したIDEF1x記法(IDEF：ICAM Definition Language)、ジェームズ・マーティン(James Martin)氏が考案したIE記法(IE：Information Engineering)がよく利用される。

情報システムやソフトウェアの設計や振る舞いの分析などで用いられる概念の一つである。利用者などの主体(「アクター」と呼ばれる)がシステムを用いて何かの機能を利用したり目的を達成しようとする際に、特定の状態からスタートしてどのような操作や応答が行われる(べき)かを記述する。

ユースケースはシステムの機能や要素と一対一に対応するとは限らず、一つのユースケースが行われる間に複数の要素を横断的に用いることもある。アクターが異なればユースケースも異なることがあり、一人のアクターが複数のユースケースを必要としたり、逆に一つのユースケースが複数のアクターで共有される場合もある。

ユースケースシステムは開発の初期段階で要求を明確化するために検討・記述されるのが一般的で、利用者やビジネス分析の専門家の視点から、対象システムをブラックボックスとして扱い、システムによって何をどのように行うのかを明らかする。

情報システムの専門家が関与して作成することは問題ないが、利用者が内容を理解できる形で作成しなければ意味がないため、システム上の専門用語や専門的な概念は極力用いないことが望ましい。また、この段階では過度に詳細化したり詳しい実装に立ち入るべきではないとされる。

システムの設計に必要な情報を図示する技法を定義した「UML」(Unified Modeling Lanugage)では、ユースケースを記述するための図法として「ユースケース図」(use case diagram)を定義している。開発現場でもこれを用いて図示することが多いが、各項目やフローの内容を箇条書きした表などの形で表すこともある。

リレーショナルデータモデル(関係データモデル)と呼ばれる数学的なモデルに基づいてデータを秩序立てて格納したデータ集合である。一件の登録単位は複数の属性(attribute)の組(tuple)で、同じ属性を持つ組を何件も集めたデータの集合体をリレーション(関係)という。

これは実際には縦横に項目が並んだ表(テーブル)の形で整理される。リレーションが表に相当し、属性を縦方向に並んだ列(column)、組を横方向に並んだ行(row)として表す。システムによっては行を「レコード」(record)、列を「フィールド」(field)と呼ぶこともある。

実際のデータベースは「顧客マスタ」「製品マスタ」「受注明細」のように複数の表の集合として管理されることが多い。「受注明細の顧客IDは顧客マスタを参照する」といったように複数の表にまたがって同じ属性を配置し、対応付けて管理することができ、複雑なデータや大規模なデータを柔軟に取り扱うことができる。

RDBMSによる管理

関係データベースはRDBMS(Relational Database Management System：リレーショナルデータベース管理システム)と呼ばれる専用のソフトウェアによって作成・運用されることが多い。データベースの管理はRDBMSが行い、他のソフトウェアは必要なときにRDBMSへ接続して操作を依頼する。

RDMBSへの指示には「SQL」(Structured Query Language)という問い合わせ言語が標準的に用いられ、データベースの作成や削除、テーブルへのデータの追加や更新、指定した条件を満たすデータ集合の抽出などの操作を行なうことができる。

著名なRDBMSとしては、米オラクル(Oracle)社の「Oracle Database」、米マイクロソフト(Microsoft)社の「SQL Server」、米IBM社の「Db2」などの商用ソフトウェア製品、オープンソースで配布されている「MySQL」「MariaDB」「PostgreSQL」などが知られる。

個人や小集団で利用する「Microsoft Access」や米クラリス(Claris)社の「FileMaker Pro」のようなデスクトップデータベース製品や、RDBMSをクラウドサービスとして提供する米アマゾンドットコム(Amazon.com)社の「Amazon RDS」「Amazon Aurora」などもある。

歴史

関係データベースの基礎となる理論は1969年に米IBM社のエドガー・コッド(Edgar F. Codd)氏が提唱したリレーショナルデータモデル(relational data model)で、これを元に開発されたRDBMSが1980年頃から当時の大型コンピュータ向けのソフトウェアとして普及し始めた。

1990年代以降は他の方式を圧倒し、企業などが情報システムでデータの記録や管理を行う際の標準的な手法として広まった。近年では、用途によっては「NoSQL」(Not only SQL)と総称される非リレーショナル型の方式が導入される事例も増えている。

一連の属性から成るデータのまとまり(レコード)を格納単位とし、レコード間は親子関係を持つが、各レコードは親レコードも子レコードも複数持つことができるため、必要に応じて関連する他の種類のレコードを参照することができる。

1970年代に考案された方式で、それ以前に主流だった「階層型データベース」ではレコード間を親子関係(親は必ず一つ)で結びつける木構造で管理していたが、ネットワーク型は親レコードを複数持つことができるため、現実世界のデータの関係に即した柔軟なモデリングが可能となった。

1980年代になるとデータの組を行と列を組み合わせた表のような形式で表現する「リレーショナルデータベース」が台頭し、商用データベース製品の主流の方式として定着したため、ネットワーク型が顧みられることはなくなった。2010年代には、データの繋がりを網状に表現できるという点はネットワーク型データベースに似ているが、より抽象度や柔軟性が高い「グラフデータベース」が登場し、リレーショナル型が苦手とする分野で活躍している。

オブジェクト指向データベースに格納されたデータ群はオブジェクト指向プログラミング言語からそのままの形で直に操作、参照することができ、リレーショナルデータベース(RDB/RDBMS)などで必要なデータ形式の変換や対応付け(O/Rマッピング)、問い合わせ言語による操作指示などが不要で、データ構造の変更などに柔軟に対応できるなどの長所がある。

ただし、特定のプログラミング言語から利用を前提としてシステムが多く、他の環境や言語から利用しにくい場合があるほか、データ構造が特定のアプリケーションの設計と密接に結びついているため、様々なプログラムから同じデータベースを利用するような用途には向かない。

オブジェクト指向データベースは異なる種類・形式のデータが混在するデータ群や、多数のデータが一体的に結び付いたデータ構造の格納に適している。特定の言語で開発されたシステムが取り扱う複雑な構造のデータを高速に処理する用途や、CADシステムやマルチメディアデータベースなどでの応用がよく知られている。

オブジェクト指向データベースを作成・管理するためのデータベース管理システム(DBMS)は「オブジェクト指向データベース管理システム」(OODBMS：Object-Oriented Database Management System)という。著名な製品には米オブジェクティビティ(Objectivity)社の「Objectivity/DB」や米インターシステムズ(InterSystems)社の「Caché」などがある。

オブジェクト指向データベースとしての機能に加え、問い合わせ言語としてSQLを利用できるなどリレーショナルデータベースとしての特徴を兼ね備えたものは「オブジェクトリレーショナルデータベース」(ORDB：Object-Relational Database)、その管理システムは「オブジェクトリレーショナルデータベース管理システム」(ORDBMS：Object-Relational Database Management System)と呼ばれる。

インメモリデータベースでは原則としてすべてのデータをメモリ上に展開し、データの読み込みや追加、変更、削除をすべてメモリ上で完結させることで、従来型の数百倍から数万倍も高速に処理を実行することができる。ただし、メモリ上のデータは電源を切ると失われてしまうため、システムの終了・再起動時や一定時間ごとなどに、メモリ上の内容をストレージに保存してデータの永続性を確保する機能が搭載されている。

また、トランザクションログや変更履歴(ジャーナル)などをストレージに記録したり、ネットワークを通じて別のコンピュータにデータベースの複製を取るレプリケーション機能などにより、不意な電源断などで内容が失われても、なるべく直近の状態を復元できるよう配慮されていることが多い。

オンディスクデータベース (on-disk database/disk-based database)

従来型のストレージに記録されるデータベースのことをオンディスクデータベースと呼ぶことがある。英語では “on-disk database” の他に “disk-based database” などとも呼ばれる。ほとんどのデータベースシステムはこの方式であるため、このような呼び方をするのはインメモリデータベースと対比する文脈にほぼ限られる。データ容量や設定などによりインメモリとしてもオンディスクとしても動作するハイブリッド型のデータベース製品もある。

同じ施設の複数のサーバなどに、あるいは、地理的に離れた施設に設置されたサーバなどにレプリケーション機能などでデータを分散して管理する。データの転送や複製は利用者やアプリケーションからは透過的に行われ、どのサーバに接続しても単一のデータベースであるかのように振る舞う。

複数のコンピュータでデータ管理を行うことで、可用性を高めることができる。一部の機器が停止しても他の機器を用いて外部に対するサービス提供を継続することができ、装置の故障などでデータを喪失する危険も減少する。

また、データの読み出しは複数のシステムで並列に行うことができるため、台数を増やせば全体としての性能を向上させることができる。世界的に利用されるサービスでは、データを地理的に分散させることで利用者や端末に近い場所からサービスを提供することができ、通信遅延の低減や回線資源の節約に繋がる。

一方、分散システム一般の性質として、CAP定理により一貫性(Consistency)、可用性(Availability)、分断耐性(Partition-tolerance)の3つのうちいずれか2つしか同時に確保することができないため、厳密な整合性が求められるような処理には向いていない。また、システム構成が複雑になれば、その分だけ管理・運用にかかるコストや手間、セキュリティ上の懸念は増大する。

トランザクション処理やテーブルの結合といったRDBやSQLが得意とする機能が利用できない代わりに、大規模な並列分散処理や柔軟なデータ構造の定義など、リレーショナル型では不可能だったり苦手な機能を実現したものが多い。

代表的な方式として、標識(key)と内容(value)を一対一に対応付けて保存する「キーバリューストア」(KVS：Key-Value Store)がよく知られる。NoSQLの中で分散型KVSが最も種類が多く広く普及しており、KVSを指してNoSQLと呼ぶ用例が見られるほどである。

KVS以外の方式としては、柔軟で複雑な構造のデータをそのまま格納する「ドキュメント型データベース」(文書指向データベース)、表中の同じ列のデータをまとめて記録する「カラム型データベース」(列指向データベース)、グラフ構造でデータ間の繋がりを表現できる「グラフ指向データベース」などがある。

他の既存システムや外部の事業者が提供するサービスなど、外部の別のシステムとの連携が必要なシステムで行われる。システムテストなど、システム単体としての動作の検証は済んでいる必要がある。顧客が利用する機材で動作するかどうかのテストを含む場合もある。

システム統合テストを行う場合はシステムテストとユーザー受け入れテスト(UAT：User Acceptance Test)の間に実施するのが一般的だが、他システムとの接続が特に意識されない場合は単体の工程としては行わないこともあり、システムテストや受け入れテストの工程の一部とする場合もある。

また、システムテストのことや、統合テスト(結合テスト)の最終段階などのことを指してシステム統合テストと呼ぶ場合もある。

一般の外来語としては、書籍や映像・音楽作品、ビデオゲーム、公演などを鑑賞したり、店舗や施設を利用したり、製品を購入・利用した人が、対象を評価することや、感想や論評を文章や評点などの形に表したものをレビューということが多い。

学術やビジネスの分野では、制作物の審査や検証、精査、出来事の再調査や振り返り、対象分野の総論的なまとめ、仕組みの見直しなどを指すこともある。

レビューする人のことを「レビュアー」あるいは「レビューア」(reviewer)、レビューされる人のことを「レビュイー」あるいは「レビューイ」(reviewee)と呼ぶ。

システム開発のレビュー

情報システムやソフトウェアの開発で、作成された仕様書やコードなどの成果物を開発者とは別の人が詳細に調べ、仕様や要求を満たす内容になっているか、誤りや不具合が無いか、資源の浪費や不必要な冗長さ、極端な低性能などの問題が無いかなどについて開発者にフィードバックする工程をレビューという。

具体的なレビュー手法として様々な方式が提案されており、複数の検証者がチェックリストなどを用いて精査した結果をミーティングで議論する「インスペクション」、本人と評価者が一堂に会してその場で検証や議論を行う「ウォークスルー」、成果物を評価者に送付・回覧して意見を求める「パスアラウンド」などがよく知られる。

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

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

リレーショナルデータベースのテーブルやCSVファイルのように、一件のレコードの構成、各項目のデータ型や形式、項目の並び順、項目やレコードの区切り文字などが事前に決まっており、同じ構成のレコードの繰り返しとしてデータを列挙したものを指すことが多い。

ソフトウェアによって容易に読み込んで内容を認識させることができ、大量のデータを集計したり分析するのに適している。人間がそのまま眺めて読みやすい形式とは限らず、ソフトウェアによって抽出や集計を行ったり、見やすいよう整形したり、レポートなど別の形式へ変換してから人間に供されることが多い。

一方、Webページや電子メール等のメッセージ、ワープロソフトやプレゼンテーションソフトなどで作成した(見栄え重視の)文書ファイル、画像や音声、動画などのメディアデータといった、決まった形式や配置に従ってデータが並んでいるわけではない不定形なデータ群のことを「非構造化データ」(unstructured data)という。

Webページの構造化データ

WebページのHTMLコードは、Webブラウザにその文書の構造やレイアウトを伝達するという意味では構造化されているが、書かれている情報をサイト横断的に同じ形式に従って自動収集・処理できるような構造にはなっていない。

そこで、ソフトウェアが自動処理しやすいようページ内に書かれている内容を特定の規約に則って構造化として記述する手法が提唱されている。同じ情報を人間向けと機械向けに同じページに埋め込んでおき、ブラウザは人間向けのデータを表示し、Webロボットなどの自動処理プログラムは機械向けのデータを収集する。

様々な手法が提唱されているが、現在有力な方式はHTMLのヘッダ領域などにJSON-LD形式でスクリプトの形で情報を埋め込む手法で、Schema.orgという業界団体が情報の種類ごとにデータの記述形式(スキーマ)の標準を提案している。

例えば、ある行事の開催案内のWebページに、Schema.orgの定義する「Event」(行事)のスキーマで構造化を埋め込むことで、巡回してきたロボットに行事名や主催、出演者、開催日時などを伝達することができる。

画面上にアイコンやメニュー、ボタンといった絵や図形に補助的な文字情報を組み合わせた操作要素が表示され、これをマウスやトラックパッド、タッチパネルなどのポインティングデバイス(位置入力装置)で選択してコンピュータへの指示を与える。

パソコンなどではオペレーティングシステム(OS)が管理する「デスクトップ」(desktop)と呼ばれる初期画面が表示される。各アプリケーションソフトは「ウィンドウ」(window)と呼ばれる矩形の領域を与えられ、その中で表示や操作を行う。複数のウィンドウを同時に開き、並行して処理を行ったり、即座に切り替えて操作することができる。

スマートフォンやタブレット端末では「ホーム画面」(home screen)が表示され、導入済みのソフトウェア(アプリ)がアイコンとして並んでいる。これをタッチ操作で選択するとアプリが起動して全画面で操作可能になる。複数アプリを同時に起動することはできるが、画面を切り替えて使用するのが一般的となっている。

CUIとの違い

一方、情報の提示も操作の受付も原則として文字によって行うユーザーインターフェースを「CUI」(Character User Interface：キャラクターユーザーインターフェース)あるいは「CLI」(Command Line Interface：コマンドラインインターフェース)という。

利用者はキーボードなどを用いてコンピュータへの指示を文字によって与え、コンピュータからの出力も画面に文字を表示して行われる。LinuxなどのUNIX系OSやメインフレーム(大型コンピュータ)、ネットワーク機器など、訓練を受けた専門の技術者やオペレータが操作する前提のコンピュータ製品で多く用いられる。

パソコン向けOSのWindowsやmacOS、スマートフォンやタブレット端末向けのAndroidやiOSなど、技術者ではない一般消費者や(企業の)従業員が操作することを想定したコンピュータ製品は、情報の見やすさや操作方法の習得のしやすさなどを重視してGUIを中心に構成することが多い。家庭用ゲーム機、デジタル家電など民生用コンピュータ応用製品の多くも、主要な表示・操作方式としてGUIを用いる。

文書の見出しや枠線、罫線、表、項目名といった記入様式(フォーム)に相当する部分をあらかじめ作成しておき、記入内容に相当する原稿を与えるとシステム側で自動的に重ね合わせて印刷してくれる機能である。

伝票のように同じ様式で毎回異なる内容の印刷物を作成する必要がある場合、書類を作成するたびに雛形に内容を入力する手間がかかるが、フォームオーバーレイに対応したシステムでは雛形と内容の重ね合わせを印刷時に自動的に行なってくれる。書類の作成や印刷にかかる手間や時間を削減でき、窓口業務などでよく用いられる。

リミットチェック (限界検査/限度検査)

数値などが規定された上限あるいは下限に収まっているかどうかを調べることをリミットチェックという。値が規定された上限値より小さいか、下限値より大きいかを調べるもの。上限あるいは下限のみが設定されたものを指すことが多い。

レンジチェック (範囲検査)

数値などが規定の範囲内に収まっているかどうかを調べることをレンジチェックという。上限と下限の両方が定義され、値がその間に存在することを確認する。

フォーマットチェック (書式検査/形式検査)

あらかじめ定められた書式(フォーマット)に則って記述されているかどうかを調べることをフォーマットチェックという。

例えば、日付を入力すべき場所に、有効な日付として解釈可能なデータが入力されているか、電話番号や郵便番号として入力されたデータの桁数が適切か、数字とハイフン以外の文字が混じっていないか、といった点を検査する。形式上の誤りがないかを調べるチェックであり、論理的、意味的に妥当かどうかといった点については別の手法により検査する。

シーケンスチェック (順序検査/順番検査)

順序が決められているようなデータで、入力値が順番通りに並んでいるか確かめることをシーケンスチェックという。

順序が決まっているデータ群に対して行われるチェックで、規定された順序どおりに並んでいるかどうかを調べる。例えば、時系列の変化を記録したデータが日付・時刻の推移の通りに並んでいるか、伝票番号のような通し番号が付与されたデータが昇順(小さい順)あるいは降順(大きい順)に並んでいるか、といったことを調べる。また、連続した番号などが対象の場合には、あるべきデータが抜け落ちていないかどうかを調べる場合もある。

論理チェック (ロジックチェック/妥当性チェック)

データの論理的な整合性を確かめることを論理チェックあるいは妥当性チェックという。

生年月日が未来の日付になっているなど、データ単体として論理的にありえない状態になっていることを検知したり、複数の項目やデータ間の関係を調べ、販売したチケット数が座席数より多い、発送日が発注日より過去になっている、などの論理的に矛盾したデータが入力されていないかを調べる。

ニューメリックチェック (数値検査)

データが数値としての形式を満たしているかどうかを判別することをニューメリックチェックという。

個数や値段など数値を入力すべき場所に、数値として解釈可能な文字群が正しく入力されているか、アルファベットや日本語文字など、数値として扱うことができないデータが含まれていないかを調べる。

数値であることが確認されたあと、その値が上限あるいは下限を超えていないか調べるのは「リミットチェック」あるいは「レンジチェック」の役割で、個数に小数点以下の値があるなど論理的に正しくないことを検知するのは「論理チェック」の役割となる。

バランスチェック (平衡検査)

必ず一致していなければならない一対のデータを実際に計算してみて一致するかどうか確認することをバランスチェックという。

会計データの借方と貸方のように、2つ以上の異なるデータの並びについて、その合計値などが最終的に必ず一致しなければならない場合がある。このような場合に、実際にそれぞれ計算してみて一致するかどうかを確認することを指す。

自動車の位置情報をリアルタイムに集約して渋滞情報を配信するシステムや、人間の検針員に代わって電力メーターが電力会社と通信して電力使用量を申告するスマートメーター、大型の機械などにセンサーと通信機能を内蔵して稼働状況や故障箇所、交換が必要な部品などを製造元がリアルタイムに把握できるシステムなどが考案されている。

これまでの情報システムとの違いとして、個々の機器の取り扱うデータ量や処理量、通信量は少ないが機器の数が桁違いに膨大であることや、従来のコンピュータ製品が人の周りや特定の場所(建物や部屋)に集中しているのに対しIoT機器は世の中の様々な場所に分散して配置される点などがある。

こうした特徴を反映し、低コストで生産でき低消費電力で稼働するICチップや、多数の機器からデータを集約して解析したり、同時に多数の機器を制御するソフトウェア技術、低消費電力で遠距離通信が可能な無線技術、環境中から微小なエネルギーを取り出す技術(エナジーハーベスティング)などの研究・開発が進められている。

LPWA (Low Power Wide Area)

IoTに必須の要素として、装置の消費電力が少なく、多数の機器を一つのネットワークに収容できる広域的な無線通信技術があり、これを「LPWA」(Low Power Wide Area)と総称する。そのような通信方式で構築されたネットワークは「LPWAN」(Low Power Wide Area Network)とも呼ばれる。

IoTを実現するには、携帯電話網など従来からある広域無線技術に比べ、十～数十kmといった遠距離や広い範囲をカバーでき、乾電池などの乏しい電源でも数か月から数年は稼働できることが求められる。一方、人間がスマートフォンなどの通信機器に求めるような高速なデータ伝送能力は必ずしも必要なく、数十～数百kbps(キロビット毎秒)程度あれば実用に供することができる。

このような特性を備えた新しい通信方式をLPWAと呼び、具体的な規格として「Sigfox」「LoRa」「Wi-Fi HaLow」「Wi-SUN」「LTE-M」「NB-IoT」「RPMA」などの方式が提唱されている。

M2M/センサネットワークとの違い

以前から、機器同士を直接繋いで自律的にシステムを運用する「M2M」(Machine to Machine)や、通信可能なセンサーを分散配置して高度な監視や制御を可能にする「センサネットワーク」(WSN:Wireless Sensor Network)などの概念が存在し、これらはかなりの部分がIoTと重複している。

ただし、IoTはインターネットへの接続を前提とするのに対し、これらの技術は閉じた専用ネットワークや独自プロトコル(通信規約)での運用を想定している場合が多い。また、M2Mやセンサネットワークは特定の目的のために機械同士が情報のやり取りすることで処理が完結する仕組みであることが多いのに対し、IoTは接続された機器と人や外部の情報システムとの相互関係がより重視される傾向がある。

IoE (Internet of Everything)

「ありとあらゆるものが接続されたインターネット」という意味で、モノのインターネットと、人やデータ、情報、ソフトウェアなどが中心の従来からあるインターネットが統合された姿を指す。

とはいえ、従来のインターネットとの違いは多数のモノが接続されている点であるため、実際上はIoTとほぼ同義として用いられることが多い。主に米シスコシステムズ(Cisco Systems)社が提唱している用語である。

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

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

単体テストツール

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

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

単体テストの意義

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

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

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

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

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

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

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

ソフトウェア統合テストが終了すると、最終段階のテストとして、本番同様の環境を構築してハードウェアや通信回線なども含めシステムが全体として適切に機能するかを検証する「システムテスト」(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)という。

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

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

後方互換と前方互換

同じ系列の新しい製品が、古い製品の仕様や機能を包含しており、互換性がある状態のことを「後方互換」(backward compatible)、逆に、古い製品が新しい製品に対して互換性を有する状態を「前方互換」(forward compatible)という。一般に、既存の製品の仕様はすでに明らかだが、将来の製品の仕様を正確に予見することは難しいため、前方互換性は限定的なものになることが多い。

上位互換と下位互換

また、同じ系列の上位の(機能や性能などが優れている)製品が、下位の製品の仕様や機能を包含しており、互換性がある状態のことを「上位互換」(upward compatible)、逆に、下位の製品が上位の製品に対して互換性を有する状態を「下位互換」(downward compatible)という。通常、下位の製品は上位の製品に比べ機能や仕様が制限・限定されているため、下位互換性は部分的・限定的なものである場合が多い。

ソース互換 (ソースレベル互換)

ある機種やOSで動作するコンピュータプログラムのソースコードを、追記・修正せずそのまま別のコンピュータ向け使用できることをソースレベル互換(source-code compatibility)あるいはソース互換(source compatibility)という。

ソースコードは人間にわかりやすいプログラミング言語で書かれたプログラムで、そのままではコンピュータ(のCPU)が解釈・実行することができないため、コンパイルやリンクなどの工程を経て実行可能形式のバイナリコードに変換される。

ソースレベル互換とは、ある複数のプラットフォーム間で、同一のソースコードを用いてコンパイルなどを行い、同じように動作する実行プログラムを作ることができる互換性を指す。

バイナリ互換 (バイナリレベル互換)

ある機種やOSで動作する実行可能形式のコンピュータプログラムを、そのまま異なる種類のコンピュータシステム上で動作させることができることをバイナリレベル互換(binary-code compatibility)あるいはバイナリ互換(binary compatibility)という。

バイナリコードはコンピュータ(のCPU)が直接解釈・実行できる機械語(マシン語)や、仮想マシン(VM)で実行できるバイトコードなどを用いて構成されたプログラムで、コンピュータで直に起動・実行することができる。

バイナリレベル互換とは、ある複数のプラットフォーム間で、同じ実行形式のプログラムファイルなどを同じように起動して動作させることができる互換性を指す。

国際規格の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」という。

単に「安全」と訳してしまうとセーフティとの区別を表せないため、文脈や対象により「警備」や「警護」「防犯」(人や物など)、「安全保障」(国家など)のように訳し分ける場合もある。

ITの分野では訳さずに外来語として「セキュリティ」をそのまま用いる。コンピュータやソフトウェア、データ、通信路などを暗号や防御ソフト、アクセス制御機構などを用いて技術的に保護し、機密情報の漏洩や通信の盗聴、データの改竄や消去、コンピュータへの攻撃や侵入などの危険を排除することを表す。

保護する対象により、「情報セキュリティ」「サイバーセキュリティ」「コンピュータセキュリティ」「ネットワークセキュリティ」など様々な分野に分かれる。

機器やシステムなどの場合には、一定の水準の機能や性能を保つ上で、日常的にどのくらいの作業が必要になるかといった点や、一部が老朽化したり故障した際に、いかに容易に発見や修理、交換を行えるかといった点が中心となる。

ソフトウェアの場合には、誤りや不具合の発見・修正のしやすさや、事前に予定されていなかった仕様変更や機能追加などの行いやすさ、ソースコードの読みやすさといった点が中心となる。

機器のポータビリティ

機器や装置、設備などについて移植性という場合には、単純に物理的な持ち運びやすさを意味する。

形状や重量などが所持や運搬に適していることや、特定の場所に据え置いて使う前提ではなく、様々な場所に移動して使えるよう設計されていることなどを指す。「新機種は従来より薄型・軽量で移植性が高い」といったように用いる。

ソフトウェアのポータビリティ

ソフトウェア(コンピュータプログラム)について移植性という場合は、他の環境に移植して動作させる容易さを意味し、「移植性」とも訳される。

通常、ソフトウェアはある特定の機種やCPU、OS、言語処理系などで動作させる前提で開発されることが多いが、これを異なる環境で動作するよう修正や追加を行うことを「移植」(porting：ポーティング)という。

移植のしやすさはソフトウェアの種類や作り方、基盤とする技術などによって大きく異なり、ほとんどあるいはまったくそのままで他の環境で動作する場合もあれば、全面的な作り直しに近い作業が必要となる場合もある。この移植の行いやすさを移植性という。

ナンバーポータビリティ (番号持ち運び制度)

電話サービスの加入者が別の通信事業者のサービスに乗り換える際、それまで使用していた自分の電話番号をそのまま持ち運べる制度を「ナンバーポータビリティ」(number portability)あるいは番号移植性、番号持ち運び制度などという。携帯電話の番号を持ち運ぶことは特に「MNP」(Mobile Number Portability)と呼ばれる。

従来は別の事業者に契約を切り替えると電話番号も新しい番号に変わってしまうため、知人や関係先への周知の面倒さが事業者変更の大きな障壁となっていた。このような状況は通信サービスの自由な競争を阻害しているという議論が起こり、2000年前後に各国で相次いでナンバーポータビリティ制度が導入された。日本では2001年に固定電話の番号が、2006年に携帯電話の番号がそれぞれ持ち運び可能となった。

業務の手順や工程を図などに書き表して定義し、それに合わせてシステムの挙動を決定していく。現実の手順に基いてシステムの動作を考えるため分かりやすく、設計工程を低コストで手早く済ませることができる。

特定部門の特定の業務手順をシステムに反映させることが主眼であるため、部署を超えた利用やデータの伝送、再利用などはあまり考慮されず、システム間でデータの重複や不整合が起こったり、接続や連携ができず全体最適化の妨げとなることがある。また、業務手順が変更されるとわずかな違いでも大幅な改修が必要になったり、データの連続性が失われたりすることがある。

一方、業務の内容を表すデータの構造や流れに着目し、データモデルの策定を中心に設計を行う手法を「データ中心アプローチ」(DOA：Data Oriented Approach)という。業務へのコンピュータ導入の初期(1970年代頃まで)にはプロセス中心設計が一般的だったが、システムの規模や種類が増えデータ管理が重視されるようになるとDOAへの注目が集まった。

まず業務で扱うデータ全体をERモデル(Entity-Relationship model)など何らかの手法でモデル化し、データベースやデータファイルの設計や構造などとして明確化する。プログラムはこのデータ群を業務手順に従って入出力、加工、保存する道具として設計・実装される。

企業などが永続的に保存・管理するデータの種類や意味、形式などは比較的安定しており、これをシステム構造の基礎におくことで、業務内容や手順に変更があってもデータベース部分はそのままでプログラムのみを修正・置するといった更新が行いやすくなる。

また、データ中心設計では具体的な処理内容やプログラムの実装とは切り離してデータを定義・蓄積するため、様々なシステムや部門(野心的なプロジェクトでは全社・全システム)で共有される情報資産としてのデータ基盤を構築することができる。一度データ基盤を整えれば、システムやプログラムの追加や修正も局所的な変更で対応できるようになる。

データ中心設計やそれに類似する考え方(DCE：データ中心工学、IE：インフォメーションエンジニアリングなど)は1970年代に広まったもので、それ以前は業務の流れや処理の手順などを中心にシステムを設計するPOA(Process Oriented Approach：プロセス中心アプローチ)が一般的だった。

これは業務の一部の手順を自動化する小規模なプログラムの開発には適していたが、システムの規模や対象の範囲が広がると、データの形式や扱い方が部署やシステムごとに異なり整合性がないことが開発や運用の効率悪化を招くようになり、データを中心に据えるデータ中心設計の考え方が脚光を浴びるようになった。

システムが取り扱う対象とする現実世界の要素を抽象化し、名詞として表すことができるものを「実体」(エンティティ)として矩形で表す。実体は必ずしも物理的な存在とは限らず、情報や行為などでも構わない。

実体間の関係性を表す要素は「関連」あるいは「関係」(リレーションシップ)と呼ばれ、動詞として表すことができるものが該当する。図中では菱形もしくは矩形の間を結ぶ線分として表記される。

実体と関連は共にその性質を表す「属性」(アトリビュート)を複数持つことができる。属性は楕円で表し実体や関連と線分で紐付ける記法と、実体の矩形の中に列挙する記法がある。

多重度

また、記法によっては関連に多重度(cardinality/カーディナリティ)を設定することができるものがある。二つの実体の関連が一対一、一対多、多対多といった対応関係になっていることを表す。

例えば、ER図の表記法の一つであるIE記法では、関連の末端部分に「○」(0を表す)「|」(1を表す)、鳥の足のような三股の枝分かれ(任意の複数を表す)の3つの記号の組み合わせで数を表記する。「|」のみならば「必ず一つ」、「○」と三股ならば「0を含む任意個」を表す。

記法の種類

ER図は1975年にマサチューセッツ工科大学(MIT)のピーター・チェン(Peter Chen)氏がERモデルと共に考案した。氏の提唱したオリジナルの記法は現在ではPeter Chen記法とも呼ばれる。

用途などに応じて微妙に表記法の異なる10以上の記法が考案され、様々な用途に使用されている。中でも有名なものとして、米国立標準技術研究所(NIST)が規格化したIDEF1x記法(IDEF：ICAM Definition Language)、ジェームズ・マーティン(James Martin)氏が考案したIE記法(IE：Information Engineering)がよく利用される。

システムが取り扱う対象とする現実世界の要素を抽象化し、名詞として表すことができるものを「実体」(エンティティ)として矩形で表す。実体は必ずしも物理的な存在とは限らず、情報や行為などでも構わない。

実体間の関係性を表す要素は「関連」あるいは「関係」(リレーションシップ)と呼ばれ、動詞として表すことができるものが該当する。図中では菱形もしくは矩形の間を結ぶ線分として表記される。

実体と関連は共にその性質を表す「属性」(アトリビュート)を複数持つことができる。属性は楕円で表し実体や関連と線分で紐付ける記法と、実体の矩形の中に列挙する記法がある。

多重度

また、記法によっては関連に多重度(cardinality/カーディナリティ)を設定することができるものがある。二つの実体の関連が一対一、一対多、多対多といった対応関係になっていることを表す。

例えば、実体の表記法の一つであるIE記法では、関連の末端部分に「○」(0を表す)「|」(1を表す)、鳥の足のような三股の枝分かれ(任意の複数を表す)の3つの記号の組み合わせで数を表記する。「|」のみならば「必ず一つ」、「○」と三股ならば「0を含む任意個」を表す。

記法の種類

実体は1975年にマサチューセッツ工科大学(MIT)のピーター・チェン(Peter Chen)氏がERモデルと共に考案した。氏の提唱したオリジナルの記法は現在ではPeter Chen記法とも呼ばれる。

用途などに応じて微妙に表記法の異なる10以上の記法が考案され、様々な用途に使用されている。中でも有名なものとして、米国立標準技術研究所(NIST)が規格化したIDEF1x記法(IDEF：ICAM Definition Language)、ジェームズ・マーティン(James Martin)氏が考案したIE記法(IE：Information Engineering)がよく利用される。

システムが取り扱う対象とする現実世界の要素を抽象化し、名詞として表すことができるものを「実体」(エンティティ)として矩形で表す。実体は必ずしも物理的な存在とは限らず、情報や行為などでも構わない。

実体間の関係性を表す要素は「関連」あるいは「関係」(リレーションシップ)と呼ばれ、動詞として表すことができるものが該当する。図中では菱形もしくは矩形の間を結ぶ線分として表記される。

実体と関連は共にその性質を表す「属性」(アトリビュート)を複数持つことができる。属性は楕円で表し実体や関連と線分で紐付ける記法と、実体の矩形の中に列挙する記法がある。

多重度

また、記法によっては関連に多重度(cardinality/カーディナリティ)を設定することができるものがある。二つの実体の関連が一対一、一対多、多対多といった対応関係になっていることを表す。

例えば、関連の表記法の一つであるIE記法では、関連の末端部分に「○」(0を表す)「|」(1を表す)、鳥の足のような三股の枝分かれ(任意の複数を表す)の3つの記号の組み合わせで数を表記する。「|」のみならば「必ず一つ」、「○」と三股ならば「0を含む任意個」を表す。

記法の種類

関連は1975年にマサチューセッツ工科大学(MIT)のピーター・チェン(Peter Chen)氏がERモデルと共に考案した。氏の提唱したオリジナルの記法は現在ではPeter Chen記法とも呼ばれる。

用途などに応じて微妙に表記法の異なる10以上の記法が考案され、様々な用途に使用されている。中でも有名なものとして、米国立標準技術研究所(NIST)が規格化したIDEF1x記法(IDEF：ICAM Definition Language)、ジェームズ・マーティン(James Martin)氏が考案したIE記法(IE：Information Engineering)がよく利用される。

リレーショナルデータベースの正規化

リレーショナルデータベース(RDBMS)では、データの保守性向上や処理の高速化を図るため、データベース内で同じ情報が複数の箇所に重複して記録されず、個々のテーブルは主キーから直接連想されるデータのみで構成されるよう設計するのが理想とされている。

この基準に基づいてデータ構造を再編する作業や操作のことをデータベースの正規化と呼び、正規化の度合いによって第1正規化から第5正規化、およびボイスコッド正規化などの種類に分類されている。

浮動小数点数の正規化

浮動小数点数を符号部、仮数部、指数部に分けてビット列で表す場合、同じ数を同じ符号化方式で表す場合でも仮数と指数の取り方によって複数の表現が可能となるが、標準となる形式を定めてこれに合わせて表現することを正規化という。

IEEE 754などの標準規格では有効数字の桁数が最大限に確保される表現に正規化するよう定められている。具体的には仮数部のビット列の左端の値が0以外になるように仮数を決め、それに合わせて指数が算出される。

XML文書の正規化

XML文書はテキスト形式を採用しているため、ホワイトスペースの扱いや要素の出現順序などに非常に寛容である。しかし、ソフトウェアにXML文書のデータを渡す場合や、データが改竄されていないことを証明するための署名などを行う場合には、XML文書を一定のルールに従って整形しなおす必要がある。

XMLの正規化は「Canonicalized XML」規格に定められたカノニカライズ(canonicalize)と、「XML Normalization」規格に定められたXML文書のノーマライズ(normalize)、XML規格本体に定められた属性値のノーマライズ(Attribute-Value Normalization)の3種類がある。

カノニカライズは論理的に同等の文書がバイナリデータのレベルで完全に一致するように整形する手順を定めており、XML文書が改竄されていないことを証明するための電子署名を有効に機能させるために必要となる。

XML文書のノーマライズは、ソフトウェアが文書の解釈や変換などを行いやすいように表記法を統一する処理を指す。XMLは名前空間を使用する場合などに意味的に同じ内容を複数の表記で書くことができるが、XML Normalization規格ではこれを一定の基準に基づいて統一された表記にすることを求めている。

属性値のノーマライズは、人間の入力の都合や見やすさなどのために様々な表記が混在する属性値を一定の基準で変換し、ソフトウェアが表記の揺れに影響されないようにする処理である。文字参照表現を参照先の文字自体で置き換えたり、改行文字やタブ文字を空白文字(16進数で20)に置き換えたり、連続する複数の空白を一文字に短縮するといった変換が行われる。

ITの分野では、コンピュータプログラムの設計やアルゴリズム(計算手順)の理解などのために、内部で行われる処理や演算の詳細な流れを流れ図に表すことが多い。プログラムに限らず、業務手順など様々な過程や手順の図示に応用できる。

一つの流れ図には開始と終了があり、その間に一つ以上の工程が含まれる。流れは分岐や繰り返しによって複数に枝分かれしたり戻ったりすることがあるが、途中どのような経路を通っても必ず一つの開始から始まって一つの終了で終わる。

流れ図で用いる部品の種類や図記号の形状はJIS X 0121で規格化されており、一般的にはこれを用いることが多い。主な部品として、開始や終了を表す「端子」(円・楕円・角丸長方形)、「処理」(長方形)、プログラムにおけるサブルーチンや関数などの「定義済み処理」(左右が二重線の長方形)、「入出力」(平行四辺形)、条件分岐などの「判断」(菱形)、繰り返しの範囲を示す「ループ端」(開始は上側、終了は下側の角が欠けた長方形)、他の図との出入り口を示す「結合子」(小さな丸)、処理の流れを示す「線」(右や下へは線分・左や上には矢印)などがある。

システムが扱うデータの流れを整理するための図法で、対象となるシステムと利用者や外部のシステムなどのデータの流れを図示する場合と、システム内の構成要素(データストアやプロセスなど)間の流れを図示する場合がある。

データは発生源から様々な処理(プロセス)を経て出力先へ収まる。一つの図にあまり多くの要素を図示すべきではないとされ、。全体的で抽象的なレベルから作図し、段階的に詳細化した図を描いていくという手法が用いられることが多い。

DFDでは、データの保管や取り出しを行う「データストア」を平行な上下二本線で、データを処理するソフトウェアなどの「プロセス」を丸で、データの発生源や出力先である「外部実体」(ターミネータ)を長方形あるいは楕円で示す。これらの要素の間をデータの流れ(フロー)を表す矢印で結んでいく。

プロセスには入力と出力を表す「フロー」がそれぞれ一つ以上必要で、データストアや外部実体は入力または出力のいずれか一方のフローが必要となる。また、各フローの一方の端は必ずプロセスでなければならない。

様々な表現形式があるが、一般的な手法では、対象が取りうる状態を円や矩形などで列挙し、どこからどこへ遷移が起きうるかを矢印によって示す。各矢印の脇に、その遷移が起きるための条件やきっかけとなる出来事などを記述する。自らに遷移する場合は自分を指し示す輪っか状の矢印を書き入れる。

対象に開始や終了がある場合は、特殊な記号で示される場合がある。UMLでは開始を塗りつぶした丸印で、終了を内側を塗りつぶした二重丸で記載するよう定められている。

状態遷移表

状態遷移図の各状態を一行として表の形で書き表したものを状態遷移表という。

一般的な形式では、各行が対象の状態を、各列がイベントを表し、ある状態のときにあるイベントが起きたときにどの状態に遷移するかを書き入れていく。

また、縦軸・横軸ともに状態を並べ、各状態の交差する項目にそのような遷移が起こるイベントを書き入れていく様式もある。

ソフトウェア開発の分野ではテストを行う際にテストケースを漏れなく網羅するために状態遷移表が作成される場合がある。

ステートマシン図 (state machine diagram)

ソフトウェアの設計などに用いられるUML(Unified Modeling Language)では、状態遷移図に相当する図をステートマシン図(state machine diagram)として定義している。

あるオブジェクトの振る舞いを漏れなく記述するために用いられるもので、開始状態を塗りつぶした丸印(●)、終了を内側を塗りつぶした二重丸で表し、途中の状態を角丸の矩形を並べて図示していく。

状態間は遷移する方向に矢印で繋ぎ、脇に遷移の説明を添える。遷移したときに実行する動作がある場合は矩形を横に区切って下半分に動作の内容を記述する。

コンピュータのCPUがプログラムを実行する際、特に指定がなければプログラムを先頭から読み込んで命令を並んでいる順に従って一つずつ実行していく。この最も基本的な命令実行の制御構造を、(他の構造と対比するため便宜的に)順次構造と呼ぶ。

一方、命令の中には命令実行の流れを変更するものもある。これを用いて、条件に従って別の実行位置に流れを分岐させる制御構造を「選択構造」あるいは「分岐構造」、条件が満たされる間だけ同じ個所を繰り返し実行する制御構造を「反復構造」あるいは「繰り返し構造」という。

コンピュータのCPUがプログラムを実行する際、特に指定がなければ命令を先頭から順に実行するが、分岐命令が存在する場合、特定の条件が満たされたらメモリの指定番地に実行位置を変更(ジャンプ)し、以降はそこから順に命令を実行していく。

このような実行制御を「条件分岐」と呼び、プログラムに複雑な処理をさせたい場合は必須の機能となる。一方、条件が満たされる間だけ同じ個所を繰り返し実行する制御構造もあり、「反復構造」あるいは「繰り返し構造」という。

コンピュータのCPUがプログラムを実行する際、特に指定がなければ命令を先頭から順に実行するが、反復構造になっている場合、指定の条件が満たされている間、指定範囲の末尾の命令を実行したら範囲の先頭に戻り、その範囲を繰り返し実行する。

同じ処理を様々な対象に次々に適用したい場合などに用いられ、プログラムに複雑な処理をさせたい場合には必須の機能となる。一方、特定の条件が満たされたらメモリの指定番地に実行位置を変更(ジャンプ)する制御構造もあり、「選択構造」あるいは「分岐構造」という。

一つ一つの処理は横長の長方形で表し、順番に実行するときはこれを縦に連結する。繰り返し制御は大小の長方形の入れ子で表し、繰り返し範囲を示す大きな長方形の中に、繰り返される個々の処理を小さな長方形で記す。

条件分岐は長方形の内部を3つの三角形に区切った図で表され、中央に条件を、左右に真偽を記し、左右のそれぞれの三角形の下にその条件の時に実行される処理を長方形で記す。元の幅の長方形が出現すると分岐終了となる。

NS図は1972年にニューヨーク州立大学ストーニーブルック校の大学院生だったアイザック・ナッシー(Isaac Nassi)氏とベン・シュナイダーマン(Ben Shneiderman)氏が考案した。ドイツでは1985年にDIN 66261として標準規格となっているが、日本や国際機関では標準化されていない。

一定の方針に基いてモジュール分割を行うことにより、開発者にとってプログラムの構造が見通しやすくなり、複数人での分担や問題発生時の原因の発見、コードの再利用などが行いやすくなる。古くから様々な技法が提唱されている。

共通機能分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、プログラム中の様々な箇所で共通して行われる処理をモジュールとして切り出す方式を共通機能分割という。

プログラム中にはエラー処理のように、様々な処理の中で同じか似たような処理を行う箇所が存在する場合があり、これを共通の機能として分離して一つのモジュールにまとめ、必要な時に呼び出すようにするのが共通機能分割である。まず全体を他の手法でモジュール分割し、複数のモジュールに共通する部分を共通機能分割で取り出すといった利用法が多い。

TR分割 (トランザクション分割)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの種類とその処理内容に応じて分割する方式をTR分割(トランザクション分割)という。

対象となるデータの種類と、そのデータに対する関連する一連の処理をトランザクションという単位にまとめ、プログラムをトランザクション単位で分割していく手法で、データの種類などによって処理の流れが複数に分岐する場合によく用いられる。

STS分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの入力(Source：源泉)、変換(Transformation)、出力(Sink：吸収)の3つに分割する手法をSTS分割という。

プログラム中でのデータの流れに着目し、プログラムへのデータの入力や取得、読み込みなどを行うモジュールと、データの計算や加工、変換などを行うモジュール、データの出力や表示、印刷、書き出しなどを行うモジュールに分割する。

これらのモジュールを直に繋いで流れ作業的に連続して実行する場合もあるが、これらの上位に制御用のモジュールを配置してデータの流れや実行状態の管理を行う場合もある。

ワーニエ法 (Warnier method)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入力データの構造を分析してプログラムの構造を決定していく方式をワーニエ法という。1970年代にフランスの情報科学者ジャン・ドミニク・ワーニエ(Jean-Dominique Warnier)氏によって考案された。

ワーニエ法では、データがいつ、どこで、何回使われるかを分析し、これを元に、順次(連結)、選択、繰り返しの3種類の制御構造を組み合わせて制御の流れを決めていく。これを図示したものをワーニエ図という。

ジャクソン法

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入出力データの構造からプログラムの構造を決定していく方式をジャクソン法という。マイケル・ジャクソン(Michael A. Jackson)氏が1975年に発表した。

プログラムの入力データと出力データの対応関係を把握し、入力から出力が得られるようプログラムの構造を決定していく。その際、データやそれを扱うモジュールを、基本、連接、選択、反復の4つの要素を組み合わせて表現する。

一定の方針に基いてモジュール分割を行うことにより、開発者にとってプログラムの構造が見通しやすくなり、複数人での分担や問題発生時の原因の発見、コードの再利用などが行いやすくなる。古くから様々な技法が提唱されている。

共通機能分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、プログラム中の様々な箇所で共通して行われる処理をモジュールとして切り出す方式を共通機能分割という。

プログラム中にはエラー処理のように、様々な処理の中で同じか似たような処理を行う箇所が存在する場合があり、これを共通の機能として分離して一つのモジュールにまとめ、必要な時に呼び出すようにするのが共通機能分割である。まず全体を他の手法でモジュール分割し、複数のモジュールに共通する部分を共通機能分割で取り出すといった利用法が多い。

TR分割 (トランザクション分割)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの種類とその処理内容に応じて分割する方式をTR分割(トランザクション分割)という。

対象となるデータの種類と、そのデータに対する関連する一連の処理をトランザクションという単位にまとめ、プログラムをトランザクション単位で分割していく手法で、データの種類などによって処理の流れが複数に分岐する場合によく用いられる。

STS分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの入力(Source：源泉)、変換(Transformation)、出力(Sink：吸収)の3つに分割する手法をSTS分割という。

プログラム中でのデータの流れに着目し、プログラムへのデータの入力や取得、読み込みなどを行うモジュールと、データの計算や加工、変換などを行うモジュール、データの出力や表示、印刷、書き出しなどを行うモジュールに分割する。

これらのモジュールを直に繋いで流れ作業的に連続して実行する場合もあるが、これらの上位に制御用のモジュールを配置してデータの流れや実行状態の管理を行う場合もある。

ワーニエ法 (Warnier method)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入力データの構造を分析してプログラムの構造を決定していく方式をワーニエ法という。1970年代にフランスの情報科学者ジャン・ドミニク・ワーニエ(Jean-Dominique Warnier)氏によって考案された。

ワーニエ法では、データがいつ、どこで、何回使われるかを分析し、これを元に、順次(連結)、選択、繰り返しの3種類の制御構造を組み合わせて制御の流れを決めていく。これを図示したものをワーニエ図という。

ジャクソン法

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入出力データの構造からプログラムの構造を決定していく方式をジャクソン法という。マイケル・ジャクソン(Michael A. Jackson)氏が1975年に発表した。

プログラムの入力データと出力データの対応関係を把握し、入力から出力が得られるようプログラムの構造を決定していく。その際、データやそれを扱うモジュールを、基本、連接、選択、反復の4つの要素を組み合わせて表現する。

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

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

一定の方針に基いてモジュール分割を行うことにより、開発者にとってプログラムの構造が見通しやすくなり、複数人での分担や問題発生時の原因の発見、コードの再利用などが行いやすくなる。古くから様々な技法が提唱されている。

共通機能分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、プログラム中の様々な箇所で共通して行われる処理をモジュールとして切り出す方式を共通機能分割という。

プログラム中にはエラー処理のように、様々な処理の中で同じか似たような処理を行う箇所が存在する場合があり、これを共通の機能として分離して一つのモジュールにまとめ、必要な時に呼び出すようにするのが共通機能分割である。まず全体を他の手法でモジュール分割し、複数のモジュールに共通する部分を共通機能分割で取り出すといった利用法が多い。

TR分割 (トランザクション分割)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの種類とその処理内容に応じて分割する方式をTR分割(トランザクション分割)という。

対象となるデータの種類と、そのデータに対する関連する一連の処理をトランザクションという単位にまとめ、プログラムをトランザクション単位で分割していく手法で、データの種類などによって処理の流れが複数に分岐する場合によく用いられる。

STS分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの入力(Source：源泉)、変換(Transformation)、出力(Sink：吸収)の3つに分割する手法をSTS分割という。

プログラム中でのデータの流れに着目し、プログラムへのデータの入力や取得、読み込みなどを行うモジュールと、データの計算や加工、変換などを行うモジュール、データの出力や表示、印刷、書き出しなどを行うモジュールに分割する。

これらのモジュールを直に繋いで流れ作業的に連続して実行する場合もあるが、これらの上位に制御用のモジュールを配置してデータの流れや実行状態の管理を行う場合もある。

ワーニエ法 (Warnier method)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入力データの構造を分析してプログラムの構造を決定していく方式をワーニエ法という。1970年代にフランスの情報科学者ジャン・ドミニク・ワーニエ(Jean-Dominique Warnier)氏によって考案された。

ワーニエ法では、データがいつ、どこで、何回使われるかを分析し、これを元に、順次(連結)、選択、繰り返しの3種類の制御構造を組み合わせて制御の流れを決めていく。これを図示したものをワーニエ図という。

ジャクソン法

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入出力データの構造からプログラムの構造を決定していく方式をジャクソン法という。マイケル・ジャクソン(Michael A. Jackson)氏が1975年に発表した。

プログラムの入力データと出力データの対応関係を把握し、入力から出力が得られるようプログラムの構造を決定していく。その際、データやそれを扱うモジュールを、基本、連接、選択、反復の4つの要素を組み合わせて表現する。

オブジェクト指向プログラミングのクラス

オブジェクト指向では、互いに関連するデータと、データに対する操作(メソッド)を一つの「オブジェクト」(object)と呼ばれる単位に一体化(カプセル化)して取り扱う。あるオブジェクトがどのようなデータとメソッドから作られるのかを定義した雛形をクラスという。

プログラムの実行時にはクラスを元にメモリ空間上に具体的なオブジェクトが生成される。この実体化されたオブジェクトのことを「インスタンス」(instance)という。同じクラスから複数のインスタンスを生成することができ、それぞれ異なる内部状態を持つことができる。

クラスには、オブジェクト内部で取り扱うデータ(フィールド/メンバ変数)の名称やデータ型、アクセス可能な範囲(クラス外から参照・操作可能か否かなど)を宣言する。同様にメソッド(メンバ関数)の名称や引数、処理内容の詳細、アクセス範囲も記述する。

データや手続きは通常はインスタンスに属するが、クラスそのものに属するものを宣言することができる。クラス自体に属するデータを「クラス変数」(静的フィールド/静的メンバ変数)、クラス自体に属する手続きを「クラスメソッド」(静的メソッド)という。

クラスの継承

クラスベースのプログラミング言語では、あるクラスを元に一部を改変して別のクラスを定義することができ、これをクラスの「継承」(inheritance)という。このとき、元になったクラスを「親クラス」(parent class)「スーパークラス」(superclass)「基底クラス」(base class)などと呼び、新たに定義されたクラスは「子クラス」(child class)「サブクラス」(subclass)「派生クラス」(derived class)などという。

抽象的・汎用的なクラスを元に具体的な機能を付け足したクラスを派生させていくことで、大規模なソフトウェアを効率的に開発することができる。言語によっては親クラスのメソッドを子クラスが同じ名前で別の内容に差し替えることができる。このように、同じ名前がクラスによって異なる内容を指すことを「ポリモーフィズム」(polymorphism：多態性)という。

オブジェクト指向プログラミングで、クラス定義に基いて実行時にメモリ上にデータと手続きの集合として実体化されたオブジェクトのことをインスタンスという。クラスからインスタンスを生成することを「インスタンス化」(instantiation)という。

クラスは一種の雛形であり、同じクラスから作られたインスタンスは同じ変数(プロパティ)と手続き(メソッド)を持つが、各プロパティに代入される値はそれぞれのインスタンスごとに固有となる(インスタンス変数の場合)。あるインスタンスのプロパティの内容を書き換えても、同じクラスの他のインスタンスの同名プロパティは影響を受けない。

VMインスタンス

コンピュータ仮想化の分野では、物理的な一台のコンピュータ上で、ソフトウェアとして実装された仮想的なコンピュータを仮想マシン(VM：Virtual Macine)と呼び、コンピュータ上に起動したVMのことを「VMインスタンス」という。

利用者やオペレーティングシステム(OS)などから見ると、VMインスタンスはあたかも一台のコンピュータが稼動しているかのように振る舞い、実際のコンピュータと同じようにソフトウェアを起動し、利用者の操作を受け付け、外部とデータのやり取りを行うことができる。

VMインスタンスの実体はコンピュータのメモリ上に展開されたプログラムとデータの集合であるため、物理コンピュータそのものとは異なり、ある瞬間の構成や状態をデータとして丸ごと保存して後で再現したり、稼働状態のまま通信ネットワークを通じて他の物理コンピュータに転送し、移動先で同じように稼働を続行することができる。

様々な分野や場面で用いられる一般的な用語で、それぞれの対象が持つ固有の属性値やその集合体のことを指す。例えば、「ファイルの属性」と言った場合には、ファイル名やファイルの種類、ストレージ上での所在、アクセス権の設定、作成日時、最終更新日時、データサイズ、読み取り属性などが含まれる。

Windowsなどでは、対象の属性の表示や変更を行う設定画面や設定ソフトなどのことを「○○の属性」のように表示するため、文脈によっては「属性を開く」といったようにこの設定画面のことを指して属性という場合もある。

オブジェクト指向プログラミングにおけるプロパティ

オブジェクト指向プログラミングでは、オブジェクトのフィールド(メンバ変数)を外部から直に操作するように記述できるが、実際には内部的にメソッド呼び出しを利用するよう自動的に変換してくれる機能を属性ということがある。

通常、フィールドへ外部からアクセスするには「アクセサメソッド」(setterメソッド/getterメソッド)を定義する必要があるが、属性機能のある言語ではこれを簡易化し、少ないコード量で安全にフィールドへアクセスできるようにしてくれる。

例えば、objオブジェクトのPropフィールドを外部から参照するには、クラス内でgetPropメソッドを定義し、外部から x=obj.getProp() のように記述するのが一般的だが、プロパティとして宣言することにより x=obj.Prop のように記述するだけで内部的にアクセサメソッドを呼び出して値を取り出してくれる。

オブジェクト指向プログラミングのメソッド (メンバ関数)

オブジェクト指向プログラミング(OOP)では、データと手続きを「オブジェクト」(object)として一体化(カプセル化)して定義、利用する。この、オブジェクトに内包された手続き(データに対する処理内容を記述したプログラム)のことをメソッドという。言語によっては「メンバ関数」などということもあるが、ほぼ同じものを指す。

メソッドはそのオブジェクトに対する操作内容の詳細が実装されており、外部からメソッドを呼び出して起動することにより、その内容が実行される。操作の詳細をオブジェクト内部に隠蔽することができ、プログラムの再利用性や生産性を高めやすくなると言われている。

インスタンスメソッドとクラスメソッド

一般的なメソッドは実行時に展開されるクラスのインスタンス(instance)に付属する「インスタンスメソッド」(instance method)で、所属するインスタンスのプロパティに対する操作などを行うことができる。「メンバメソッド」(member method)と呼ばれることもある。

一方、言語によってはクラス自体に付属する「クラスメソッド」(class method)を定義できる場合があり、クラス変数(静的変数/スタティック変数)の操作や参照、あるいは特に内部状態を必要としない基本的・汎用的な機能の提供などのために用いられる。「静的メソッド」(static method/スタティックメソッド)と呼ばれることもある。

メソッドのオーバーライド

一般的なクラスベースの言語ではメソッドはクラスの一部として定義される。あるクラスの内容を引き継いで一部を変更して別のクラス(サブクラス/派生クラス)を定義する際、元のクラスにあるメソッドと同名のメソッドを定義して別の内容に置き換える場合がある。

この操作をメソッドの「オーバーライド」(overriding)と言い、同名のメソッドがクラスによって異なる振る舞いをすることを「多態性」(polymorphism：ポリモーフィズム)という。サブクラスで機能を追加・変更する必要がある場合などに利用する。引数の型や数を派生元クラスのメソッドに揃えなければならないなどの制約を課している言語もある。

HTTPリクエストメソッド

通信プロトコルのHTTPでは、クライアントからサーバへ要求(リクエスト)を行う際、その種類を示すデータのことをメソッドと呼んでいる。主なメソッドとして、資源の送信を要求する「GETメソッド」、資源の受信(クライアント側から送信)を要求する「POSTメソッド」、資源本体ではなく資源についての情報(メタデータ)を要求する「HEADメソッド」などがある。

オブジェクトは外部に公開された手続き(メソッド)により機能を提供する。内部の状態を表す変数なども、外部からの参照・操作が必要なものだけが専用の手続きによってアクセス可能となり、それ以外は外から見えない存在となる。

十分にカプセル化されたオブジェクトを組み合わせてプログラムを構築していくことにより、オブジェクトの内部の仕様の変更が外部に予期せぬ影響を及ぼしたり、外部からの予期せぬ干渉でオブジェクトの状態が壊されることを防ぐことができるようになる。

通信におけるカプセル化

データ通信においてカプセル化といった場合には、ある通信手順(プロトコル)によるデータ表現の内部に、別のプロトコルによるデータ表現を埋め込んで伝送することを指す。

通信プロトコルの多くは、送受信するデータの基礎単位(パケットやフレームなど)の構造を定義しており、先頭に制御情報などを含むヘッダ領域、その後に運びたいデータの本体(ペイロードやボディ)が続いている(末尾にも制御情報などが付加される場合もある)。このデータ本体部分に、より上位のプロトコルの送受信単位を埋め込むことをカプセル化という。

カプセル化は多段階に行われることが多く、各階層のプロトコルは自らの機能に専念し、上位あるいは下位のプロトコルの詳細を気にしなくても良くなる。また、インターネットのように様々な伝送媒体や異なる管理主体のネットワークをまたいで通信するのも容易となる。

例えば、LAN上をWebデータが流れる場合、EthernetフレームのペイロードにIPパケットがカプセル化され、IPパケットのペイロードにTCPパケットがカプセル化され、TCPパケットのペイロードにHTTPメッセージがカプセル化されて伝送される。

サブクラスはスーパークラスの持つプロパティやメソッドを引き継いでおり、元のクラスに無い独自の部分だけを新たに定義・実装して作られる。また、元のクラスで定義されているメソッドなどを上書き(オーバーライド)して独自のものに改変することもできる。

言語によっては、あるクラスのサブクラスを元にさらにサブクラス(孫クラス)を作成することもでき、標準のクラス群を木構造的に何段階も派生させ、徐々に具体性・個別性を持たせていくことができる。

一般的には木構造の根本に近いスーパークラスほど抽象的・シンプルで機能や構成要素が少なく、派生すればするほど機能が豊富で具体的な、「重たい」仕様となる。

継承関係にあるクラス間では、元になるクラス(スーパークラス、親クラス、ベースクラス、基底クラス、基本クラスなどと呼ばれる)の持つメソッドやプロパティなどが、新たに産み出されたクラス(サブクラス、子クラス、派生クラスなどと呼ばれる)に引き継がれ、その機能のすべてを利用することができる。

継承を利用することでコードの再利用性が高まり、汎用的・抽象的な機能の実装をスーパークラスに任せ、サブクラスにはその機能を利用した個別具体的なコードを書くだけでよくなる。例えば、バイト単位で入出力する汎用的なクラスを元に、ファイル入出力のクラスやネットワーク入出力のクラスを派生させることで、両者に共通するコードを何度も繰り返し記述する必要がなくなる。

言語によってはスーパークラスに複数のクラスを指定する「多重継承」を行なうことができ、様々なクラスの機能を同時に利用することができる。ただし、単純な多重継承はスーパークラス間でメソッド名が衝突した場合の対処など問題が起きやすいため、代わりにインターフェースやミックスイン、トレイトなどのコードを再利用する仕組みを用意している言語もある。

UML(Unified Modeling Language)はオブジェクト指向のソフトウェア開発において、データ構造や処理の流れなどソフトウェアに関連する様々な設計や仕様を図示するための記法を定めた標準規格である。クラス図はシステムの構造を図示する構造図の一つで、クラスの構成やクラス間の関係を表現することができる。

オブジェクト指向プログラミングでは互いに関連するデータと操作手順を「クラス」という単位で一体的に定義する。クラス図ではクラスを矩形で示し、クラス間の関係を線で表す。クラスを外部から操作する方法だけを定義した「インターフェース」(interface)も矩形で示し、クラスと対応付ける。

矩形の内部にはクラスが表す対象の性質や状態を表す「属性」(property)や、属性に対する操作である「メソッド」(method)を名前やデータ型と共に列挙する。他のクラスから見えるかどうかを指定したい場合は、項目の先頭に「+」(public：どこからでも見える)、「#」(protected：子クラスからのみ見える)、「-」(private：外部からは見えない)、「~」(package：同じパッケージ内から見える)という記号を付ける。

主な関係の種類

クラス間の関係は、クラスをプログラム中で実際に具象化した「インスタンス」(instance)同士の関係と、複数のクラス同士の関係に分かれる。クラス同士の場合もインスタンス同士の場合もありえる関係として「依存」(dependency)があり、あるクラスが機能するためには別のクラスの存在が必要という関係を表す。

インスタンス同士の関係としては、クラス間に何らかの繋がりがあることを示す「関連」(association)、あるクラスが別のクラスの部分を構成する「集約」(aggregation)や「コンポジション」(composition)がある。集約では部品は複数のクラスに属することができるが、コンポジションは所属先がただ一つに定まっている。

クラス同士の関係としては、あるクラスが別のクラスの子クラス(サブクラス)となる「継承」(inheritance)あるいは「特化」(specialization)、逆に、子クラスにとって親クラス(スーパークラス)であることを示す「汎化」(generalization)、抽象クラスやインターフェースで示された仕様を子クラスで具体化する「実現」(realization)あるいは「実装」(implementation)などがある。

静的型付けの言語で関数などを定義する際には、引数や返り値のデータ型を指定しなければならないため、処理内容が同じでもデータ型ごとに整数用、浮動小数点数用、複素数型用…といったように異なる(名前の)関数を何度も繰り返し定義しなくてはならず、呼び出し側も型ごとに異なる関数を呼び分けなければならない。

多相性に対応した言語では、同名の関数などを繰り返し定義することができ、型ごとに別々の関数を用意しなくても一つの(共通の名前を持つ)関数としてまとめることができる。ただし、具体的な処理内容は型ごとに個別に記述しなければならない。。

分類

呼び出し側に記述された引数の型や数の違いに応じて、処理系が自動的に合致する実装を選んで呼び出してくれる方式を「アドホック多相」(ad hoc polymorphism)、呼び出し時に型をパラメータとして明示的に指定する方式を「パラメータ多相」あるいは「パラメトリック多相」(parametric polymorphism)という。後者はC言語などでは「テンプレート」(template)、Javaなどでは「ジェネリクス」(generics)と呼ばれる機能として知られる。

また、二つのデータ型が基本型と派生型の関係にあるとき、基本型を引数に取る関数を定義することにより派生型でも同じように動作させるようにすることができ、これを「サブタイプ多相」「部分型多相」(subtype polymorphism)などという。オブジェクト指向プログラミング言語では親クラスから派生(継承)した子クラスがメソッドの内容を上書き(オーバーライド)したり、インターフェースで定義されたメソッドを実装することによりこれを実現している。

パッケージソフト

商用ソフトウェアの分野では、システムやソフトウェアを顧客の要望に応じてオーダーメイドで開発する場合と対比して、市販されている出来合いの製品のことをパッケージと呼ぶことがある。

文脈によっては、単体で提供されている複数の製品を組み合わせて一体化した複合的な製品を表す場合もあるが、英語ではこの意味の用語として「スイート」(suite)の方が好まれる。

また、ダウンロード販売・配布やWebアプリケーションなどの形でオンラインサービスとして提供する場合(SaaS/ASP/サブスクリプション)と対比して、店頭などで販売される物理的な記憶媒体(光学ディスクなど)による提供方式を「パッケージ版」ということもある。

配布パッケージ

ソフトウェアを配布・販売する際に、実行可能プログラムや関連するファイルなど、ソフトウェアの実行に必要な資源を一つにまとめた提供単位のことを配布パッケージという。

ソフトウェアの本体である実行ファイルや、実行ファイルが参照・連結するライブラリやモジュールなどのプログラムファイル、画像ファイルなどの各種リソース、設定ファイルなどで構成される。

また、これら実行に必要なファイルやフォルダなどをコンピュータのストレージ内に配置・導入し、システム設定の追加や変更などを行うインストーラが添付されていることもある。この場合、利用者はまずインストーラを起動してソフトウェアをコンピュータに導入する必要がある。

光学メディアなどに記録されて販売される製品ではこれらがディスク上に一つずつ記録された状態で提供されることが多いが、ダウンロード提供されるソフトウェアではすべてを一つの圧縮ファイルにまとめて提供することが多い。

部品化されたプログラム

いくつかのプログラミング言語や開発環境では、ある機能や対象に関連するクラスや関数などの宣言やコードをひとまとめに集めたプログラム部品をパッケージということがある。

開発者がプログラムの冒頭でパッケージの名前や所在を記述して使用を宣言すると、そのパッケージ内で定義されている機能を呼び出して利用できるようになる。

必要な機能だけを選んで追加することにより実行可能コードやその生成作業を簡素化・効率化できるほか、後から新しい機能を追加して利用するのが容易になる。

オブジェクト指向プログラミングの分野では、様々なクラスやオブジェクトに共通する性質をまとめ、それらの共通の親クラス(スーパークラス)として定義することを汎化ということがある。共通機能を一つのクラスにまとめることで、同じ機能を何度も重複して開発することを避けられる。

機械学習における汎化

パターン認識や機械学習の分野では、既知のパターンから特定の分類に共通する性質や法則性、規則性などを抽出して、未知のパターンの認識や分類に応用できる形にまとめることを汎化ということがある。

機械学習ではシステムに大量の学習データ(訓練データ)を与えて分類や予測を行うモデルを構築するが、最終目的は学習したことのない未知のデータに対して適切な分類や予測を行うことである。構築したモデルに未知のデータを与えたときの回答の精度を「汎化性能」という。

「ドメイン」(domain)とは領域、分野などの意味を持つ英単語だが、ここで言うドメインとは開発したソフトウェアが利用される業界や分野、事業、業務(あるいはこれらの総体)のことである。業務アプリケーションなどの開発に適用されるため「ビジネスドメイン」とも呼ばれる。

開発者は、ソフトウェアが利用される対象領域に熟達した「ドメインエキスパート」と共に当該ドメインを分析し、様々な対象や構造、操作などをソフトウェア上の概念として記述した「ドメインモデル」を作成する。開発者はモデルをプログラムのソースコードに忠実に反映させていく。

例えば、運送会社の情報システムを設計するのであれば、「顧客」「貨物」「経路」「輸送」といった概念がクラスやインスタンス、プロパティ、メソッドなどの形でソースコードに登場し、業務上のアクションとプログラム上の処理単位を対応付けながら開発を進めていく。

ドメインエキスパートはソフトウェア開発の知識を持たないことが前提となるため、開発者との対話を通じてドメイン知識のうちソフトウェアが取り扱う対象の取捨選択や概念の整理を行う。ドメインモデルは関係者全体で共通認識となる必要があり、UMLなどの図表を用いて理解のすり合わせを行う。

ドメイン知識の表現には「エンティティ」「値オブジェクト」「ドメインサービス」などの典型的なパターンを利用し、「集約」「仕様」などの概念を補助的に用いる。モデルに基づくアプリケーション構築の際には「リポジトリ」「アプリケーションサービス」「ファクトリ」などの手法が用いられる。

「ドメイン駆動設計」という用語および概念は、2003年に米ソフトウェア設計コンサルタント、エリック・エヴァンス(Eric Evans)氏が著書 “Domain-Driven Design: Tackling Complexity in the Heart of Software” (邦題：エリック・エヴァンスのドメイン駆動設計 - ソフトウェアの核心にある複雑さに立ち向かう)の中で提唱した。

インターネットドメイン名

インターネットなどのIPネットワーク上では機器やネットワークは「IPアドレス」と呼ばれる番号で識別・指定されるが、これは人間には覚えにくいため、英数字などを組み合わせた分かりやすい名前としてドメイン名が与えられる。

インターネット上の機器やネットワークの識別名で、URLやメールアドレスなど他の識別情報の一部としても用いられる。異なる個人や組織で同じ登録名が重複しないよう、全世界で一元的に発行・管理されている。登録される識別名はアルファベットと数字、ハイフン「-」の組み合わせで構成される。近年では日本語など各国語の文字も一部で使用できる。

ネットワーク上で別の機器などにアクセスするためにはIPアドレスを指定する必要があるため、ドメイン名とIPアドレスを対応付ける「DNS」(Domain Name System)という世界規模の分散データベースシステムが運用されている。人間が指定したドメイン名はDNSによってIPアドレスに変換され、ソフトウェアはIPアドレスを用いて相手方の機器に接続を試みる。

「ドメイン」の他の用法

IPネットワークにおけるドメイン名以外にも、Active Directoryの「ADドメイン」のように、ネットワークの範囲や管理単位、ディレクトリサービスなどで同じ資源を共有する利用者やコンピュータのグループのなどのことをドメインということがある。

システム開発では、システム化の対象となる業種、事業、業務などの種類や分野のことをドメインと呼ぶことがある。特定の業種や業務に固有の知識を「ドメイン知識」、システム化する分野の知識に基づいてデータやシステムの構造を設計していく開発手法を「ドメイン駆動設計」(DDD：Domain-Driven Design)という。

機器やシステムなどの場合には、一定の水準の機能や性能を保つ上で、日常的にどのくらいの作業が必要になるかといった点や、一部が老朽化したり故障した際に、いかに容易に発見や修理、交換を行えるかといった点が中心となる。

ソフトウェアの場合には、誤りや不具合の発見・修正のしやすさや、事前に予定されていなかった仕様変更や機能追加などの行いやすさ、ソースコードの読みやすさといった点が中心となる。

ある開発プロジェクトで作成したプログラムのソースコードを、別のプロジェクトで同じ機能を実装するためにそのまま流用できる性質のことを表す。再利用性が高いコードが豊富に存在すれば、新たに開発しなければならない部分を減らしてコストや期間を節約することができる。

プログラムを再利用しやすくするには、コードを機能ごとにまとまった部品(関数やクラス、モジュール、コンポーネントなど)の集まりとして設計し、部品間の依存関係を最小限に抑えて独立性を高める必要がある。汎用的な機能とアプリケーション固有の機能を明確に分離する必要もある。

様々なプログラムから呼び出して使用できる部品を集めたプログラム集を「ライブラリ」(library)と呼び、再利用性を高めるためによく用いられる。汎用的なものはソフトウェアメーカーなどが開発者向けに提供しているが、開発者が将来プログラムを再利用するために独自に作成する場合(カスタムライブラリ)もある。

一定の方針に基いてモジュール分割を行うことにより、開発者にとってプログラムの構造が見通しやすくなり、複数人での分担や問題発生時の原因の発見、コードの再利用などが行いやすくなる。古くから様々な技法が提唱されている。

共通機能分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、プログラム中の様々な箇所で共通して行われる処理をモジュールとして切り出す方式を共通機能分割という。

プログラム中にはエラー処理のように、様々な処理の中で同じか似たような処理を行う箇所が存在する場合があり、これを共通の機能として分離して一つのモジュールにまとめ、必要な時に呼び出すようにするのが共通機能分割である。まず全体を他の手法でモジュール分割し、複数のモジュールに共通する部分を共通機能分割で取り出すといった利用法が多い。

TR分割 (トランザクション分割)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの種類とその処理内容に応じて分割する方式をTR分割(トランザクション分割)という。

対象となるデータの種類と、そのデータに対する関連する一連の処理をトランザクションという単位にまとめ、プログラムをトランザクション単位で分割していく手法で、データの種類などによって処理の流れが複数に分岐する場合によく用いられる。

STS分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの入力(Source：源泉)、変換(Transformation)、出力(Sink：吸収)の3つに分割する手法をSTS分割という。

プログラム中でのデータの流れに着目し、プログラムへのデータの入力や取得、読み込みなどを行うモジュールと、データの計算や加工、変換などを行うモジュール、データの出力や表示、印刷、書き出しなどを行うモジュールに分割する。

これらのモジュールを直に繋いで流れ作業的に連続して実行する場合もあるが、これらの上位に制御用のモジュールを配置してデータの流れや実行状態の管理を行う場合もある。

ワーニエ法 (Warnier method)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入力データの構造を分析してプログラムの構造を決定していく方式をワーニエ法という。1970年代にフランスの情報科学者ジャン・ドミニク・ワーニエ(Jean-Dominique Warnier)氏によって考案された。

ワーニエ法では、データがいつ、どこで、何回使われるかを分析し、これを元に、順次(連結)、選択、繰り返しの3種類の制御構造を組み合わせて制御の流れを決めていく。これを図示したものをワーニエ図という。

ジャクソン法

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入出力データの構造からプログラムの構造を決定していく方式をジャクソン法という。マイケル・ジャクソン(Michael A. Jackson)氏が1975年に発表した。

プログラムの入力データと出力データの対応関係を把握し、入力から出力が得られるようプログラムの構造を決定していく。その際、データやそれを扱うモジュールを、基本、連接、選択、反復の4つの要素を組み合わせて表現する。

一定の方針に基いてモジュール分割を行うことにより、開発者にとってプログラムの構造が見通しやすくなり、複数人での分担や問題発生時の原因の発見、コードの再利用などが行いやすくなる。古くから様々な技法が提唱されている。

共通機能分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、プログラム中の様々な箇所で共通して行われる処理をモジュールとして切り出す方式を共通機能分割という。

プログラム中にはエラー処理のように、様々な処理の中で同じか似たような処理を行う箇所が存在する場合があり、これを共通の機能として分離して一つのモジュールにまとめ、必要な時に呼び出すようにするのが共通機能分割である。まず全体を他の手法でモジュール分割し、複数のモジュールに共通する部分を共通機能分割で取り出すといった利用法が多い。

TR分割 (トランザクション分割)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの種類とその処理内容に応じて分割する方式をTR分割(トランザクション分割)という。

対象となるデータの種類と、そのデータに対する関連する一連の処理をトランザクションという単位にまとめ、プログラムをトランザクション単位で分割していく手法で、データの種類などによって処理の流れが複数に分岐する場合によく用いられる。

STS分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの入力(Source：源泉)、変換(Transformation)、出力(Sink：吸収)の3つに分割する手法をSTS分割という。

プログラム中でのデータの流れに着目し、プログラムへのデータの入力や取得、読み込みなどを行うモジュールと、データの計算や加工、変換などを行うモジュール、データの出力や表示、印刷、書き出しなどを行うモジュールに分割する。

これらのモジュールを直に繋いで流れ作業的に連続して実行する場合もあるが、これらの上位に制御用のモジュールを配置してデータの流れや実行状態の管理を行う場合もある。

ワーニエ法 (Warnier method)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入力データの構造を分析してプログラムの構造を決定していく方式をワーニエ法という。1970年代にフランスの情報科学者ジャン・ドミニク・ワーニエ(Jean-Dominique Warnier)氏によって考案された。

ワーニエ法では、データがいつ、どこで、何回使われるかを分析し、これを元に、順次(連結)、選択、繰り返しの3種類の制御構造を組み合わせて制御の流れを決めていく。これを図示したものをワーニエ図という。

ジャクソン法

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入出力データの構造からプログラムの構造を決定していく方式をジャクソン法という。マイケル・ジャクソン(Michael A. Jackson)氏が1975年に発表した。

プログラムの入力データと出力データの対応関係を把握し、入力から出力が得られるようプログラムの構造を決定していく。その際、データやそれを扱うモジュールを、基本、連接、選択、反復の4つの要素を組み合わせて表現する。

一定の方針に基いてモジュール分割を行うことにより、開発者にとってプログラムの構造が見通しやすくなり、複数人での分担や問題発生時の原因の発見、コードの再利用などが行いやすくなる。古くから様々な技法が提唱されている。

共通機能分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、プログラム中の様々な箇所で共通して行われる処理をモジュールとして切り出す方式を共通機能分割という。

プログラム中にはエラー処理のように、様々な処理の中で同じか似たような処理を行う箇所が存在する場合があり、これを共通の機能として分離して一つのモジュールにまとめ、必要な時に呼び出すようにするのが共通機能分割である。まず全体を他の手法でモジュール分割し、複数のモジュールに共通する部分を共通機能分割で取り出すといった利用法が多い。

TR分割 (トランザクション分割)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの種類とその処理内容に応じて分割する方式をTR分割(トランザクション分割)という。

対象となるデータの種類と、そのデータに対する関連する一連の処理をトランザクションという単位にまとめ、プログラムをトランザクション単位で分割していく手法で、データの種類などによって処理の流れが複数に分岐する場合によく用いられる。

STS分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの入力(Source：源泉)、変換(Transformation)、出力(Sink：吸収)の3つに分割する手法をSTS分割という。

プログラム中でのデータの流れに着目し、プログラムへのデータの入力や取得、読み込みなどを行うモジュールと、データの計算や加工、変換などを行うモジュール、データの出力や表示、印刷、書き出しなどを行うモジュールに分割する。

これらのモジュールを直に繋いで流れ作業的に連続して実行する場合もあるが、これらの上位に制御用のモジュールを配置してデータの流れや実行状態の管理を行う場合もある。

ワーニエ法 (Warnier method)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入力データの構造を分析してプログラムの構造を決定していく方式をワーニエ法という。1970年代にフランスの情報科学者ジャン・ドミニク・ワーニエ(Jean-Dominique Warnier)氏によって考案された。

ワーニエ法では、データがいつ、どこで、何回使われるかを分析し、これを元に、順次(連結)、選択、繰り返しの3種類の制御構造を組み合わせて制御の流れを決めていく。これを図示したものをワーニエ図という。

ジャクソン法

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入出力データの構造からプログラムの構造を決定していく方式をジャクソン法という。マイケル・ジャクソン(Michael A. Jackson)氏が1975年に発表した。

プログラムの入力データと出力データの対応関係を把握し、入力から出力が得られるようプログラムの構造を決定していく。その際、データやそれを扱うモジュールを、基本、連接、選択、反復の4つの要素を組み合わせて表現する。

プログラム中の様々な状況や箇所で繰り返し必要となるような処理をサブルーチンとして名前をつけて一つの塊として定義することで、その処理を何度も繰り返し記述・複製する必要がなくなり、コード量の削減や開発効率の向上、記述ミスなどによる誤り(バグ)の減少などが期待できる。

サブルーチン内部の処理に反映させるため、呼び出し側から値を指定できるようになっている場合が多く、この値を「引数」(ひきすう/argument)という。また、処理結果として呼び出し元に値を返すことができる場合があり、この値は「返り値」あるいは「戻り値」という。返り値を持つサブルーチンは「関数」(function)と呼ぶのが一般的である。

かつてはプログラムが起動したとき最初に実行される主系統のコード集合を「メインルーチン」(main routine)、そこから呼び出される形で実行される副系統のコード群をサブルーチンと呼んで区別していたが、現在ではそのような構造に当てはまらない例も増えており、サブルーチンのことを単にルーチンと呼ぶことも多い。

サブルーチンに相当するコード集合は、プログラミング言語によっては「プロシージャ」(procedure)のように異なる名称で呼ばれることもある。オブジェクト指向プログラミングでは一般的に「メソッド」(method)という。返り値を持つか否かで名称が異なる言語(Pascalのプロシージャと関数など)や、C言語のようにすべてを関数と呼ぶ場合もある。

内容結合

最も結合度が強いのが「内容結合」(content coupling)で、他のモジュールの内部動作に直接影響を受けたり、他のモジュールの内部の状態を直接参照しているような場合を指す。

共通結合

2番目に結合度が強いのは「共通結合」(common coupling)で、プログラム全体に渡って有効なグローバル変数などの資源を共有している状態を指す。

外部結合

3番目に結合度が強いのは「外部結合」(external coupling)で、プログラムの外部で定義されたデータ形式や通信プロトコルなどを共有している状態を指す。

制御結合

4番目に結合度が強いのは「制御結合」(control coupling)で、他のモジュールにその処理内容を指示するためのデータ(フラグなど)などを渡して内部の処理を制御する関係にある場合を指す。

スタンプ結合

5番目に結合度が強いのは「スタンプ結合」(stamp coupling)で、モジュール間で複数のデータを連結した複合的なデータ構造を受け渡すが、そのすべてを使用するわけではない状況を指す。

データ結合

6番目に結合度が強いのは「データ結合」(data coupling)で、引数や返り値など単純な型のデータを受け渡す場合を指す。一般的な関数やメソッドの結合はこれに当たるものが多い。

メッセージ結合/無結合

一般的にはスタンプ結合あるいはデータ結合が最も弱い結合度とされるが、さらにその下に、単に呼び出しを行えるだけでデータの受け渡しなどは行わない「メッセージ結合」(message coupling)や、まったく何の結びつきもない「無結合」(no coupling)が定義される場合もある。

例えば、算術演算を行うプログラムを設計する際、四則演算をすべて行う関数を一つ作る場合と、加算、減算、乗算、除算のそれぞれを行う関数を四つ作る場合とでは、前者の方が関数の機能の分割量が高い(粒が大きい・粗い)、後者は分割量が低い(粒が小さい・細かい)という。

同じように、情報やデータ、工程、組織などについても、一つの管理単位やまとまりの中に様々な要素が含まれている状態を「分割量が高い」、より小さな多数の構成単位に細分化されている状態を「分割量が低い」という。

ITの分野では、コンピュータプログラムの設計やアルゴリズム(計算手順)の理解などのために、内部で行われる処理や演算の詳細な流れを流れ図に表すことが多い。プログラムに限らず、業務手順など様々な過程や手順の図示に応用できる。

一つの流れ図には開始と終了があり、その間に一つ以上の工程が含まれる。流れは分岐や繰り返しによって複数に枝分かれしたり戻ったりすることがあるが、途中どのような経路を通っても必ず一つの開始から始まって一つの終了で終わる。

流れ図で用いる部品の種類や図記号の形状はJIS X 0121で規格化されており、一般的にはこれを用いることが多い。主な部品として、開始や終了を表す「端子」(円・楕円・角丸長方形)、「処理」(長方形)、プログラムにおけるサブルーチンや関数などの「定義済み処理」(左右が二重線の長方形)、「入出力」(平行四辺形)、条件分岐などの「判断」(菱形)、繰り返しの範囲を示す「ループ端」(開始は上側、終了は下側の角が欠けた長方形)、他の図との出入り口を示す「結合子」(小さな丸)、処理の流れを示す「線」(右や下へは線分・左や上には矢印)などがある。

一般的な表現形式では、表の上半分を条件、下半分を判断(動作、行動ということもある)とし、左端の列に条件や判断の項目を列挙する。条件の行には右にその正否(当てはまるか否か)を列挙していくが、このとき各列の正否の組み合わせがすべて異なるようにする。判断の行には、各列の条件の組み合わせの時にどのような判断となるかを記載していく。

列の数は条件の組み合わせの数だけ必要なため、2の条件数乗となる。すなわち、条件が2つなら(条件A：Yes,条件B：Yes)(Yes,No)(No,Yes)(No,No)の4列だが、3つなら8列、4つなら16列といったように条件が増えることに2倍に増えていく。

決定表は様々な分野で用いられるが、ITの分野ではシステム開発などでシステムの挙動を指定するために仕様書などに記載したり、テスト時にテストケースと正しい結果の対応関係を分かりやすく整理するために用いられることが多い。

一つ一つの処理は横長の長方形で表し、順番に実行するときはこれを縦に連結する。繰り返し制御は大小の長方形の入れ子で表し、繰り返し範囲を示す大きな長方形の中に、繰り返される個々の処理を小さな長方形で記す。

条件分岐は長方形の内部を3つの三角形に区切った図で表され、中央に条件を、左右に真偽を記し、左右のそれぞれの三角形の下にその条件の時に実行される処理を長方形で記す。元の幅の長方形が出現すると分岐終了となる。

NS図は1972年にニューヨーク州立大学ストーニーブルック校の大学院生だったアイザック・ナッシー(Isaac Nassi)氏とベン・シュナイダーマン(Ben Shneiderman)氏が考案した。ドイツでは1985年にDIN 66261として標準規格となっているが、日本や国際機関では標準化されていない。

一定の方針に基いてモジュール分割を行うことにより、開発者にとってプログラムの構造が見通しやすくなり、複数人での分担や問題発生時の原因の発見、コードの再利用などが行いやすくなる。古くから様々な技法が提唱されている。

共通機能分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、プログラム中の様々な箇所で共通して行われる処理をモジュールとして切り出す方式を共通機能分割という。

プログラム中にはエラー処理のように、様々な処理の中で同じか似たような処理を行う箇所が存在する場合があり、これを共通の機能として分離して一つのモジュールにまとめ、必要な時に呼び出すようにするのが共通機能分割である。まず全体を他の手法でモジュール分割し、複数のモジュールに共通する部分を共通機能分割で取り出すといった利用法が多い。

TR分割 (トランザクション分割)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの種類とその処理内容に応じて分割する方式をTR分割(トランザクション分割)という。

対象となるデータの種類と、そのデータに対する関連する一連の処理をトランザクションという単位にまとめ、プログラムをトランザクション単位で分割していく手法で、データの種類などによって処理の流れが複数に分岐する場合によく用いられる。

STS分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの入力(Source：源泉)、変換(Transformation)、出力(Sink：吸収)の3つに分割する手法をSTS分割という。

プログラム中でのデータの流れに着目し、プログラムへのデータの入力や取得、読み込みなどを行うモジュールと、データの計算や加工、変換などを行うモジュール、データの出力や表示、印刷、書き出しなどを行うモジュールに分割する。

これらのモジュールを直に繋いで流れ作業的に連続して実行する場合もあるが、これらの上位に制御用のモジュールを配置してデータの流れや実行状態の管理を行う場合もある。

ワーニエ法 (Warnier method)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入力データの構造を分析してプログラムの構造を決定していく方式をワーニエ法という。1970年代にフランスの情報科学者ジャン・ドミニク・ワーニエ(Jean-Dominique Warnier)氏によって考案された。

ワーニエ法では、データがいつ、どこで、何回使われるかを分析し、これを元に、順次(連結)、選択、繰り返しの3種類の制御構造を組み合わせて制御の流れを決めていく。これを図示したものをワーニエ図という。

ジャクソン法

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入出力データの構造からプログラムの構造を決定していく方式をジャクソン法という。マイケル・ジャクソン(Michael A. Jackson)氏が1975年に発表した。

プログラムの入力データと出力データの対応関係を把握し、入力から出力が得られるようプログラムの構造を決定していく。その際、データやそれを扱うモジュールを、基本、連接、選択、反復の4つの要素を組み合わせて表現する。

一定の方針に基いてモジュール分割を行うことにより、開発者にとってプログラムの構造が見通しやすくなり、複数人での分担や問題発生時の原因の発見、コードの再利用などが行いやすくなる。古くから様々な技法が提唱されている。

共通機能分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、プログラム中の様々な箇所で共通して行われる処理をモジュールとして切り出す方式を共通機能分割という。

プログラム中にはエラー処理のように、様々な処理の中で同じか似たような処理を行う箇所が存在する場合があり、これを共通の機能として分離して一つのモジュールにまとめ、必要な時に呼び出すようにするのが共通機能分割である。まず全体を他の手法でモジュール分割し、複数のモジュールに共通する部分を共通機能分割で取り出すといった利用法が多い。

TR分割 (トランザクション分割)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの種類とその処理内容に応じて分割する方式をTR分割(トランザクション分割)という。

対象となるデータの種類と、そのデータに対する関連する一連の処理をトランザクションという単位にまとめ、プログラムをトランザクション単位で分割していく手法で、データの種類などによって処理の流れが複数に分岐する場合によく用いられる。

STS分割

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、データの入力(Source：源泉)、変換(Transformation)、出力(Sink：吸収)の3つに分割する手法をSTS分割という。

プログラム中でのデータの流れに着目し、プログラムへのデータの入力や取得、読み込みなどを行うモジュールと、データの計算や加工、変換などを行うモジュール、データの出力や表示、印刷、書き出しなどを行うモジュールに分割する。

これらのモジュールを直に繋いで流れ作業的に連続して実行する場合もあるが、これらの上位に制御用のモジュールを配置してデータの流れや実行状態の管理を行う場合もある。

ワーニエ法 (Warnier method)

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入力データの構造を分析してプログラムの構造を決定していく方式をワーニエ法という。1970年代にフランスの情報科学者ジャン・ドミニク・ワーニエ(Jean-Dominique Warnier)氏によって考案された。

ワーニエ法では、データがいつ、どこで、何回使われるかを分析し、これを元に、順次(連結)、選択、繰り返しの3種類の制御構造を組み合わせて制御の流れを決めていく。これを図示したものをワーニエ図という。

ジャクソン法

プログラム全体を複数の部品(モジュール)に分割するための設計指針の一つで、入出力データの構造からプログラムの構造を決定していく方式をジャクソン法という。マイケル・ジャクソン(Michael A. Jackson)氏が1975年に発表した。

プログラムの入力データと出力データの対応関係を把握し、入力から出力が得られるようプログラムの構造を決定していく。その際、データやそれを扱うモジュールを、基本、連接、選択、反復の4つの要素を組み合わせて表現する。

既成品という意味のパッケージ

既成品という意味のソフトウェアパッケージは、開発元が自ら設計・開発して完成品として流通事業者や顧客に販売しているソフトウェア製品を指し、利用者の要望に応じて個別に設計・開発されるオーダーメイドのソフトウェアと対比される。

個人が購入・利用するソフトウェアのほとんどはパッケージだが、企業などの情報システムでは構想時にパッケージと個別開発を比較検討してどちらにするか選択することがある。ソフトウェアパッケージの中には機能を改変したり追加できる仕組みを提供しているものもあり、これを利用して一部を自らの必要に応じて作り変える(カスタマイズ)場合もある。

ソフトウェアパッケージはすでに完成して販売されている製品であるため、利用者側にとっては設計や開発にかかる時間を省いてすぐに購入して利用することができる。他にも利用者がいるため、使用ノウハウなどの有益な情報を開発元から得るだけでなく利用者間で共有できる場合がある。多数の利用者が日々使用することで問題点なども早期に発見され、速やかに修正されることが期待される。コストも同規模、同機能、同性能で比較すればほとんどの場合既成品の方が安い。

ただし、仕様は開発元が策定し、潜在的利用者が共通して求めると想定される最大公約数的な内容であることが多いため、個々の利用者にとっては自らにとって必要な機能が不足していたり、不要な機能ばかり多く費用対効果が低かったりする場合もある。当然ながら自分(自社)しか使用しない特殊な機能などが標準で実装されることは期待できない。

物理的な梱包という意味のパッケージ

提供方式としてのソフトウェアパッケージは、プログラムやデータがCD-ROMやDVD-ROM、Blu-ray Discなどの物理的なメディアに記録され、マニュアルや保証書、利用許諾契約書(ライセンス)などと共に紙箱やプラスチックケースなどに梱包されて利用者に届けられるものを指す。店頭で販売され利用者が購入して持ち帰る場合と、オンラインで注文して宅配便などで配達される場合がある。

インターネットを通じてプログラムなどを配布するダウンロード販売(オンラインソフト)や、Webブラウザなどを介してインターネット上のサービスとしてソフトウェアの機能を提供するSaaS/クラウドサービスなどと対比される。

インターネット回線が低速だったりWebシステムの機能が貧弱な時代にはソフトウェア製品の標準的な提供手段だったが、現代ではスマホアプリのようにネットワークを通じた提供が一般的になり、パッケージ販売はパソコン向けの一部の製品で行われるのみとなっている。

Modelはデータの管理や手続きを扱い、Viewは他の二要素からの指示を受けて利用者への表示・出力(の変更)を行い、システムによっては利用者の操作・入力内容をControllerに伝達する。Controllerは利用者からの操作や入力を受け付けて解釈し、ModelやViewに対応する処理を行うようメッセージを発する。

このように役割に応じて各要素を分離することにより、各要素の内部設計や開発を分業しやすくなり、変更が他の要素に影響するのを避けやすくなる。例えば、内部的な機能や処理は変えずにユーザーインターフェースのデザインや操作方法のみを改良するといったことが行いやすくなる。

MVCモデルはもともと1980年代にSmalltalkでのGUIアプリケーションの設計のために考案されたモデルで、1995年にデザインパターンを世に広めた有名な書籍「オブジェクト指向における再利用のためのデザインパターン」(Design Patterns:Elements of Reusable Object-Oriented Software)で紹介されたのをきっかけに広く知られるようになった。

Webシステムの応用は1999年のJavaServer Pages(JSP) Model 2でサーバ側プログラムの設計パターンとして採用されたことから本格化したと言われている。この実装ではModelがViewへ直接指示を行わず、ControllerからViewの制御を行うようになっており、このような設計モデルをオリジナルのMVCモデルと区別して「MVC2」と呼ぶこともある。Webサーバの構造上はこちらのほうが自然なため、Webアプリケーション開発の現場などではこれを指して単にMVCモデルと呼ぶことも多い。

ソフトウェア開発者は個別には異なる対象や処理を扱うプログラムを記述していても、似たような構図や構造の問題に遭遇することがある。設計やコーディングの経験を積んでいくうちに、熟練した開発者の中には「このような問題を解決するには、このような構造のプログラムを作ればよい」というノウハウが蓄積されていく。

このような頻出する問題と典型的な解決策を他の人が参照して応用できるよう、再利用しやすい形に抽象化、形式化した形で整理したものがデザインパターンである。問題と解決策を一組として「Stateパターン」「Iteratorパターン」のように名前が付けられている。

1995年にオブジェクト指向プログラミングの分野で有名な「GoF」(Gang of Four：四人組)の通称で知られる研究者グループ、エーリヒ・ガンマ(Erich Gamma)氏、リチャード・ヘルム(Richard Helm)氏、ラルフ・ジョンソン(Ralph E. Johnson)氏、ジョン・ブリシディーズ(John M. Vlissides)氏による共著「オブジェクト指向における再利用のためのデザインパターン」(原題“Design Patterns: Elements of Reusable Object-Oriented Software”)の中で23のパターンが紹介されたことを契機に広まった。

一般の外来語としては、書籍や映像・音楽作品、ビデオゲーム、公演などを鑑賞したり、店舗や施設を利用したり、製品を購入・利用した人が、対象を評価することや、感想や論評を文章や評点などの形に表したものをレビューということが多い。

学術やビジネスの分野では、制作物の審査や検証、精査、出来事の再調査や振り返り、対象分野の総論的なまとめ、仕組みの見直しなどを指すこともある。

レビューする人のことを「レビュアー」あるいは「レビューア」(reviewer)、レビューされる人のことを「レビュイー」あるいは「レビューイ」(reviewee)と呼ぶ。

システム開発のレビュー

情報システムやソフトウェアの開発で、作成された仕様書やコードなどの成果物を開発者とは別の人が詳細に調べ、仕様や要求を満たす内容になっているか、誤りや不具合が無いか、資源の浪費や不必要な冗長さ、極端な低性能などの問題が無いかなどについて開発者にフィードバックする工程をレビューという。

具体的なレビュー手法として様々な方式が提案されており、複数の検証者がチェックリストなどを用いて精査した結果をミーティングで議論する「インスペクション」、本人と評価者が一堂に会してその場で検証や議論を行う「ウォークスルー」、成果物を評価者に送付・回覧して意見を求める「パスアラウンド」などがよく知られる。

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

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

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

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

IT業界の場合、仕様書やプログラムコードなどの成果物を、同僚(peer)の技術者が読み込んで検証する活動のことを意味することが多い。レビューを同じプロジェクトのメンバーが行なうことで、互いの知識やノウハウを共有・移転したり、成果物の欠陥や問題点を早期に発見することなどが期待される。

具体的なレビュー手法として様々な方式が提案されており、複数の検証者(レビューア)がチェックリストなどを用いて精査した結果をミーティングで議論する「インスペクション」、本人と評価者が一堂に会してその場で検証や議論を行う「ウォークスルー」、成果物を評価者に送付・回覧して意見を求める「パスアラウンド」などがよく知られる。

科学界・学術界では、学会誌などに投稿された学術論文を同じ分野の別の研究者が検証して掲載可否などを判定する活動を意味し、日本ではピアレビューと外来語では呼ばず伝統的に「査読」という。

分野や製品によって具体的な手法は異なるが、製品の仕様や設計を策定した段階で、企画などの前工程、製造や販売、保守など後工程の部門を交えて様々な角度から評価や検討を行い、設計部門だけでは気づかない問題点を洗い出して改善を図る。

工業製品の開発や大規模なプロジェクトの場合、設計が完了して製造など後の工程に入ってしまうと、前後の工程に関連する問題(企画意図から外れている、製造コストが高すぎる等)が後で発見されても、修正のために費用や期間を大きくロスしてしまうため、設計の段階で各部門の専門的知見を交えて問題を潰すためにデザインレビューが行われる。

このような関連部門を集めて行う公式なデザインレビューは「フォーマルデザインレビュー」(FDR：Formal Design Review)とも呼ばれ、これとは別に設計部門内で担当者が他のメンバーを集めて行う非公式なデザインレビューを「インフォーマルデザインレビュー」(IFR：Informal Design Review)と呼ぶことがある。

ソフトウェアインスペクション (software inspection)

ソフトウェア開発におけるレビュー手法の一種で、仕様書やソースコードなどの成果物を人の目で見て不具合や問題点が無いか検証する作業をインスペクションという。

プログラムコードなどの成果物を、その開発工程に直接携わっていない第三者がインスペクタ(inspector)となって読み込み、事前に決められたチェックリストなどに基づいて欠陥や問題がないか精査する。

検証が終わったら司会者(モデレータ)を中心にミーティングを開催し、インスペクタが検証結果を開発者(オーナー)に報告する。インスペクタに数名を指名する場合もあるが、それぞれ一人で独立に作業を行う。

プログラムなどを実際に動作させてみる動的テストと対比して静的テストに分類される。動作するコードができる前の仕様書などの段階で行うことができ、また、動的テストでは検知できない潜在的な問題点を見つけることができる場合がある。静的テスト手法としては他にウォークスルーやピアレビューなどがよく知られている。

変数のインスペクション

プログラムのデバッグツールなどの機能の一つで、実行中のプログラム中の変数などの内容を表示できるようにするものをインスペクションという。

ブレークポイントやステップ実行などと組み合わせ、特定の実行状態において変数の内容がどうなっているか、処理の進行に伴ってどのように変化していくかを監視することができる。

ネットワークのインスペクション

ネットワークの分野では、ネットワークの境界などに設置されたルータなどの装置が、内外を流通するデータ(パケット)を監視することをパケットインスペクション、あるいは略して単にインスペクションという。

パケット内部のデータを解析し、外部からの侵入や攻撃、マルウェア流入などが疑われる不審なパケットを検出すると、破棄したり、相手先からの接続を遮断したり、管理者に通報したりする。

ITの分野でも、電子掲示板(BBS)やチャット、メーリングリスト、コミュニティ型のネットサービスやWebサイトなどで、議事の進行や議論の整理などの役割を担う人をモデレーターということがある。問題を起こす参加者の追放や発言記録の削除や修正など、システム上の特別な権限を与えられている場合もある。

情報システム開発などの分野では、成果物のレビュー手法の一つである「インスペクション」(inspection)において、会合を主催し、参加者の選出や役割の依頼、スケジュールや会場の調整、会議の司会・進行などを行う役割のことをモデレーターという。

類義語には「ファシリテーター」(facilitator)や「コーディネーター」(coordinator)などがある。会議・会合などにおける進行役という文脈では意味に厳密な違いがあるわけではないが、モデレーターはどちらかというと会の進行よりも議論の内容に立ち入って整理、仲裁、仲介する役割というニュアンスが強くなるとされる。

レビュー手法のウォークスルー

システム開発の分野では、開発プロジェクトのメンバーが一堂に会し、仕様や構成の問題点を探したり解決策を討論したりする作業のことをウォークスルーという。

正式なレビューなどとは異なり、必要に応じて短時間開催されるインフォーマルな検討会で、プロジェクトの管理者は参加せずに作業者のみで開かれる場合が多い。特に要件定義や仕様策定、設計などの上流工程で行われることが多い。演劇の分野で話の流れを確認するための立ち稽古や通し稽古から派生した用語とされる。

3DCGのウォークスルー

3次元グラフィックス(3DCG)やバーチャルリアリティ(VR)、ビデオゲームなどの分野では、立体的に描画された建造物や仮想空間を、実際にその中にいる人物の視点で自由に動きまわって眺めることができる表現手法をウォークスルーという。

自由に移動しながら好きな場所を好きな角度から見ることができる。大規模な建築物の設計などで、完成後に内部がどのように見えるかプレゼンテーションする際などに利用されている。

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

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

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

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

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

プログラム言語でプログラムを開発することを「プログラミング」(programming)、プログラム言語で記述したプログラムを「ソースコード」(source code)という。語彙、文法、記法などが自然言語よりも厳密に定義されており、記述したソースコードはソフトウェアによって自動的に解析、処理、変換などすることができる。

コンパイラとインタプリタ

プログラム言語は人間にとって理解、記述しやすい語彙や文法で構成された言語であり、そのままではコンピュータ(のCPU)が解釈、実行することができないため、ソフトウェアによってCPUが実行可能な言語(機械語、マシン語)によるプログラムに変換して実行される。

開発時や導入時などに一度にまとめて変換処理を行うことを「コンパイル」(compile)、そのような変換ソフトを「コンパイラ」(compiler)という。実行時に変換と実行を同時並行で行うソフトウェアを「インタプリタ」(interpreter)という。

高水準言語と低水準言語

プログラム言語は人間にとっての理解のしやすさや機械語に対する抽象度の高さによって分類されることがあり、機械寄りの言語を「低水準言語」(low-level language)あるいは「低級言語」と呼び、人間寄りの言語を「高水準言語」(high-level language)あるいは「高級言語」という。

機械語の命令コードと一対一に対応する命令語を用いてプログラム言語を行う低水準言語のことを特に「アセンブリ言語」(assembly language)と呼び、機械語への変換ソフトを「アセンブラ」(assembler)という。

プログラミングパラダイム

プログラムをどのようなものとして捉え、構築していくかについて一定の設計思想やルールがある場合が多く、これを「プログラミングパラダイム」(programming paradigm)という。複数の書き方が可能な言語は「マルチパラダイム」であるという。パラダイムに基いて言語を分類することもある。

手続きを順番に記述していく「手続き型言語」(procedural language)あるいは「命令型言語」(imperative language)や、関連するデータ群と手続き群を一つのまとまりとして捉える「オブジェクト指向言語」(object-oriented language)、プログラムを関数の組み合わせとして捉える「関数型言語」(functional language)、データ間の関係や論理を記述していく「論理型言語」(logic programming language)などの種類がある。

また、主な利用目的や主要な処理系の実装方式により分類することもあり、記述や実行の手間を軽減して迅速にプログラム開発ができる「スクリプト言語」(script language)あるいは「軽量言語」(LL：Lightweight Language)、特定の分野や処理に特化した「ドメイン固有言語」(DSL：Domain Specific Language)などの分類がある。

プログラミング言語の文法とは異なり、様々な書き方が可能な場合にどういった書き方(スタイル)にするかを集団内の約束として決めたものを指す。変数や関数などの命名規則や、利用してはいけない機能などの禁止事項、インデントやスペース、括弧や演算子などの記号の配置の仕方などで構成される。

企業の開発部門やオープンソースプロジェクトなど集団でプログラミングをする場合、各々ばらばらの流儀でコードを書くと他人の書いたコードを理解したり修正したりすることが難しくなる。コードの表記法をコーディング標準として統一しておくと、可読性や保守性が高まり、開発効率を向上させることができる。

どのような規約を定めるかは言語や開発環境の制約、組織やメンバーの考え方や方針により様々で、一律に良し悪しや優劣を定められるものではなく、集団が異なれば同じ項目でも異なる方針が採用されることもしばしばである。PythonのPEP 8のように言語側で標準のコーディング標準が用意されている場合もある。

具体的な項目としては、実行制御の入れ子(ネスト)構造に従った各行先頭の字下げ(インデント)の仕方(タブかスペースか、一段何文字分とするか等)、コードブロックの開始や終了を示す括弧や制御文の置き方(行末で開始するか、改行して行頭で開始するか等)、コメントの記述形式、変数や演算子などの前後に空白文字を置くか否か、三項演算子など可読性を落としがちな構文の使用を許容するか否か、などがある。

曖昧さのない単純で明確な手順の組み合わせとして記述された一連の手続きで、必ず有限回の操作で終了し、解を求めるか、解が得られないことが示される。コンピュータで実行する場合は、基礎的な演算、値の比較、条件分岐、手順の繰り返しなどを指示する命令を組み合わせたプログラムとして実装される。

数値などの列を大きい順または小さい順に並べ替える「整列アルゴリズム」、たくさんのデータの中から目的のものを探し出す「探索アルゴリズム」、データが表す情報を損なわずにより短いデータに変換する「圧縮アルゴリズム」といった基本的なものから、画像の中に含まれる人間の顔を検出する、といった複雑なものまで様々な種類のアルゴリズムがある。

同じ問題を解くアルゴリズムが複数存在することもあり、必要な計算回数や記憶領域の大きさ、手順のシンプルさ、解の精度などがそれぞれに異なり、目的に応じて使い分けられる。例えば、ある同じ問題に対して、原理が単純で簡単にプログラムを記述できるが性能は低いアルゴリズム、計算手順が少なく高速に実行できるが膨大な記憶領域を必要とするアルゴリズム、厳密な解を求めるものより何桁も高速に近似解を求めることができるアルゴリズムなどがある。

コンピュータ上でソフトウェアによって管理され、特定の構造や形式に従って同種のデータ群を蓄積したものを指すことが多い。「データベース」の語は文脈によって、実際に蓄積されたデータの集合体そのものを指す場合と、これを管理する「データベース管理システム」(DBMS：Dababase Management System)を指す場合、両者やデータを利用するアプリケーションソフトなどを含めたシステム全体を指す場合がある。

DBMSは管理者が設定した一定の形式や構造に従ってデータをストレージ装置などに記録・蓄積するシステムで、大量のデータを系統立てて保管することができる。必要に応じて検索、抽出、加工することができるため、企業の情報システムのデータ管理の中核として利用されることが多い。

リレーショナルデータベース

データベースにはデータをどのような構造や方式で格納、管理するかによって様々な種類がある。今日最も一般的に利用されるのは「リレーショナルデータベース」(RDB：Relational Database/関係データベース)と呼ばれるもので、一件のデータを複数の属性の値の組として表現し、組を列挙することでデータを格納していく。属性を列、組を行とする表(テーブル)の形で示されることが多い。

RDBの操作は「SQL」(Structured Query Language)と呼ばれる専用の問い合わせ言語で行われることが多い。命令語と操作対象、条件などを連ねてDBMSに指示を与える言語で、テーブルの作成や削除、テーブルへのデータの追加や上書き、削除、DBMS自体の設定の変更などの操作を行うことができる。

リレーショナルデータベースを管理するためのDBMSのことを「リレーショナルデータベース管理システム」(RDBMS)という。Microsoft AccessやFileMaker Proのようなデスクトップアプリケーションから、企業などの情報システムで専門の技術者が運用するOracle DatabaseやMicrosoft SQL Server、MySQL、PostgreSQLなどのサーバアプリケーションまで様々な規模、機能の製品がある。

一般的には「順接、反復、分岐の三つの制御構造のみを組み合わせて処理の流れを記述すること」と説明されることが多いが、これは本来の定義とは異なる誤解が広まったものだとも指摘される(後段で詳述)。

今日一般的に言われる構造化プログラミングとは、プログラム中のコードの実行順の制御を、記述した順番に実行する「順接」あるいは「順次」(sequence)、指定された条件が成り立つ間繰り返す「反復」あるいは「繰り返し」(iteration)、指定された条件を満たすか否かによって枝分かれする「分岐」あるいは「選択」(selection)の三つのみを組み合わせて記述することとされる。

特に、実行順の制御をこの三つに限定することにより、かつてのプログラミングで多用されていた、指定した任意の位置に無条件に移動する “goto” 文を排除し、処理の流れがあちこちへ飛んで見通しが悪くなるのを防ぐことが重要であると説明される。

構造化定理とその解釈

この原則は1966年にイタリアのコンピュータ科学者コラド・ベーム(Corrado Böhm)とジュゼッペ・ヤコピーニ(Giuseppe Jacopini)が証明した「構造化定理」(Structure theorem)あるいは「構造化プログラム定理」(Structured program theorem)によって基礎付けられているとされる。

確かにこの定理はすべてのアルゴリズムが順接、反復、分岐の三つの組み合わせで記述できることを示してはいるが、計算科学における理論上の可能性を述べており、これによって見通しの良いプログラムを開発できるといった趣旨の主張は含まれていない。

実際、高名なコンピュータ科学者のドナルド・クヌース(Donald Knuth)は、プログラムからgoto文を除去してこの三つの組み合わせに置き換えることにより却って構造が失われる例を示し、構造化定理のこのような解釈を批判している。

ダイクストラの構造化プログラミング

「構造化プログラミング」(structured programming)の語が最初に提唱されたのは1969年にオランダのコンピュータ科学者エドガー・ダイクストラ(Edsger W. Dijkstra)が発表した論文で、本来はこちらが構造化プログラミングの定義であるとされる。

彼の主要な問題意識は、プログラムの規模が大きくなっても正しさを容易に検証できるような「良く構造化されたプログラム」(well-structured program)を記述する方法論で、そのためのいくつかの考察と原則を構造化プログラミングという概念でまとめた。

これには、現代では関数やサブルーチンなどとして知られる、プログラムの「段階的な抽象化」(step-wise abstraction)、現代のオブジェクト指向プログラミングに近い、「抽象的なデータ構造」(abstract data structures)とこれに関連付けられた「抽象的な構文」(abstract statements)の「共同詳細化」(joint refinement)が含まれる。

これらを適用したプログラムは上下に階層化された交換可能なモジュール(部品)を連結したような構造になると指摘し、これを真珠のネックレスの構造に例えて説明している。この論考には「構造化定理」も「三つの制御構文」も「goto文」も登場せず、構造化プログラミングの本来の概念とこれらとはあまり関係がない。

しかし、ダイクストラが別の機会に発表したgoto文の濫用に疑問を呈する論説(1968年の “Go To Statement Considered Harmful” )や、他の論者とのいわゆる「goto文論争」、また、「構造化定理」と「構造化プログラミング」の名称の類似性などを通じて、次第に「三つの制御構文」式の理解が広まっていったと考えられている。

ITの分野では、システム開発などの各工程で制作される様々な文書やプログラムなどについて、対応関係や変更履歴などを記録し、追跡や検証ができる状態を追跡可能性という。

例えば、要件定義と仕様書、仕様書とソースコード、仕様書とテスト仕様書などの間で、前工程で規定された項目が後工程の成果物に漏れなく反映されているかをチェックできるようにすることなどを指す。

プログラミング言語の文法とは異なり、様々な書き方が可能な場合にどういった書き方(スタイル)にするかを集団内の約束として決めたものを指す。変数や関数などの命名規則や、利用してはいけない機能などの禁止事項、インデントやスペース、括弧や演算子などの記号の配置の仕方などで構成される。

企業の開発部門やオープンソースプロジェクトなど集団でプログラミングをする場合、各々ばらばらの流儀でコードを書くと他人の書いたコードを理解したり修正したりすることが難しくなる。コードの表記法をコーディング標準として統一しておくと、可読性や保守性が高まり、開発効率を向上させることができる。

どのような規約を定めるかは言語や開発環境の制約、組織やメンバーの考え方や方針により様々で、一律に良し悪しや優劣を定められるものではなく、集団が異なれば同じ項目でも異なる方針が採用されることもしばしばである。PythonのPEP 8のように言語側で標準のコーディング標準が用意されている場合もある。

具体的な項目としては、実行制御の入れ子(ネスト)構造に従った各行先頭の字下げ(インデント)の仕方(タブかスペースか、一段何文字分とするか等)、コードブロックの開始や終了を示す括弧や制御文の置き方(行末で開始するか、改行して行頭で開始するか等)、コメントの記述形式、変数や演算子などの前後に空白文字を置くか否か、三項演算子など可読性を落としがちな構文の使用を許容するか否か、などがある。

横書きの日本語は段落の先頭を一文字分字下げすることになっているため、文書作成ソフトなどにはそのための機能が用意されていることが多い。

ソースコードのインデント

プログラミングの分野では、プログラムの構造を見やすくするために制御構文の内側にある行などの先頭に一律に同じ幅の空白を挿入することをインデンテーションという。

どの行が同じブロックに含まれるのか視覚的に分かりやすく表示することができ、プログラムの流れが理解しやすくなる。範囲の取り違えなどに起因するバグなどを減らす効果も期待できる。

あるブロックの中に別のブロックが含まれるという入れ子構造(ネスト)になっている場合、各行のインデンテーションも入れ子の深さに応じて長くなっていく。これにより、プログラムの階層構造をコード中で視覚的に表すことができる。

インデンテーションとして挿入されるのはタブ文字か連続した空白文字(スペース文字)で、タブ文字の場合はインデンテーションの幅は表示する側のソフトウェアの設定により異なる。空白文字で表す場合は2～8文字程度の連続した空白でインデンテーションする。

読む側で好みの幅を調整できるのでタブが好ましいとする人と、書く側で幅を決定して環境によらず同じように表示できるので空白文字が好ましいとする人の間で長年論争があり、また、いずれの場合も一段のインデンテーション幅を何文字分とするかで好みが分かれる。

ほとんどのプログラミング言語ではインデンテーションはソースコードの見た目の問題でありプログラムの意味には影響を及ぼさない(取り除いても同じように動作する)が、Pythonのようにインデンテーションによってプログラムの構造を記述する言語もある。

よく知られるのはプログラムの制御構造のネストで、if( 条件A ){ ... if( 条件B ){ ... } ... } といったように、条件分岐やループの内部に、別の条件分岐やループなどが含まれた制御構造を指す。複雑な条件による分岐や多重ループを記述するための基本的なテクニックとして多くのプログラミング言語で利用できる。

for文の中にfor文を記述するなど、同じ構文を入れ子状に繰り返すことを指す場合が多いが、while文の中にif文など、異なる制御構文を内部に記述することも含む場合がある。内側の構文の内部にさらに構文を重ねて、マトリョーシカのように何重も入れ子にすることができ、階層の多さを「ネストの深さ」と表現することがある。

サブルーチンなどのネスト

プログラミング言語の中には、サブルーチンやプロシージャ、関数、クラスなどのコードのまとまりをネストさせ、内部に同種のまとまりを定義することができるものもある。例えば、関数の内部に定義された別の関数を「関数内関数」「ローカル関数」などと呼び、クラスの内部に定義された別のクラスを「クラス内クラス」「インナークラス」「内部クラス」などという。

データ構造のネスト

あるデータ構造の要素として、そのデータ構造自身を埋め込むことができる場合があり、データ構造のネストを形成する。例えば、配列を構成する個々の要素が配列になっている多次元配列は配列のネストである。

配列の配列など、内部が再帰的に同じ構造になっているものを指すことが多いが、連想配列の要素が配列になっているものなど、制御構文の場合と同じように異なる構造が入れ子状になっている場合も含むことがある。

クラス名やメソッド名、関数名、定数名、変数名など、プログラム上で定義して扱う対象に名前を付ける機会は多くあるが、複数人で開発を行う場合などにそれぞれが異なる考え方や基準で名前を付けると、互いのコードの可読性や視認性が損なわれ、開発効率や保守性の悪化につながる。名前の衝突や使い回しなどでバグが生じることもある。

そこで、名前の付け方に一貫したルールを設け、これに従って識別名を命名するようにするのが命名規則である。よく定義された命名規則に従うと、対象の意味や機能、使い方などが名前からある程度推測できるようになり、コード自体がドキュメントの役割を果たすようになる。検索や置換、ツールによる自動化なども行いやすくなり、デバッグや修正、追加開発の効率も向上する。

どのような規則を定めるかはプログラミング言語や開発環境の制約、組織やメンバーの考え方や方針によって様々であり、必ずしも良し悪しや優劣を論じられるものではなく、規格化された標準などがあるわけでもない。言語やフレームワークによっては仕様上定められている命名規則が存在する場合もある。

よく定められる項目としては、「isClickable()」のように先頭や末尾に付け加える特定の意味を持つ接頭辞や接尾辞(ハンガリアン記法)、大文字と小文字の使い方や組み合わせ方、複数単語の連結の仕方などがある。古くはメモリ容量節約などのため、名前の文字数の制限が定められることもあった。

キャメルケースとスネークケース

英語の複合語や、フレーズ(句)や文を一語に繋げて表記する際、“JavaScript” のように各構成語の先頭を大文字にする方式を「キャメルケース」(camel case)という。大文字部分が上に出っ張っているのをラクダ(camel)のこぶに例えた呼称である。

このうち、“getDate” のように先頭は小文字とする方式を「ローワーキャメルケース」(LCC：Lower Camel Case)、“GetWindow” のように先頭も大文字とする方式を「アッパーキャメルケース」(UCC：Upper Camel Case)あるいは「パスカルケース」(Pascal Case)という。

一方、「file_get_contents」のように単語間のスペース(空白文字)をアンダースコア(_)に置き換える方式を「スネークケース」(snake case)という。大文字がなく、長く一連なりに文字が続く様を地を這う蛇(snake)になぞらている。

利用者がキーボードで文字を入力し始めると、その文字の並びで始まる入力候補のリストを表示する。方向キー操作などで一つを選択して決定すると、表示された単語やフレーズが入力される。選択せずに文字を入力し続けることで、候補の内容が絞られていき動的に候補リストが変化する。

言語仕様や標準ライブラリなどに含まれるキーワードを単純に提示するものが多いが、現在のプログラムで宣言済みの変数名や定数名など取り込んで提示したり、オブジェクトのインスタンス名を入力するとそのクラス定義から推測されるメソッド名やプロパティ名を自動的に抽出して表示するといった高度な補完機能を実装したものもある。

Visual StudioのIntelliSenseのように統合開発環境(IDE)に組み込まれたコードエディタで提供されることが多いが、単体のテキストエディタなどでも実装例がある。特定の言語や環境におけるコード補完を提供する「言語サーバ」(language server)という仕組みもあり、コードエディタとLSP(Language Server Protocol)という通信規約(プロトコル)で問い合わせを受け付けて補完候補を返答する。

行頭にスペースやタブ文字などを挿入して先頭の文字の位置を後方に下げることを「インデント」(indent：字下げ)という。箇条書きの先頭を本文より下げたり、プログラム中のコードブロックがどこからどこまでか分かりやすくためによく用いられる。

プログラムの記述では何行も連続してインデントすることが多く、ブロックが入れ子構造になっている場合には何段階も深くインデントする場合もあり、改行するたびに手入力でインデントするのは煩わしい作業になりがちである。

そのような場合に、オートインデント機能は利用者に代わって前の行と同じインデントを挿入し、前の行と同じ位置から文字を入力できるようにしてくれる。利用者がインデント位置を前後にずらせば、次の行はその行と同じ位置までインデントしてくれる。

オートインデント機能はプログラム記述に適したテキストエディタ(コードエディタ)で提供されることが多いが、ワープロソフトなどの文書編集ソフトでリスト(箇条書き)機能の一部として提供されることもある。コードエディタの場合は、入力済みのプログラムを解析し、ブロックの構造に従ってインデントを挿入する「自動整形」機能が提供されることもある。

コンピュータプログラムのソースコードやマークアップ言語で装飾された文書を表示・編集する際に用いられる機能で、プログラミング言語の予約語や区切り記号、マークアップ言語のタグ名や属性値などを着色することで、それ以外の部分と見分けやすくすることができる。

言語仕様上の予約語、コメント、リテラル、演算子、括弧、区切り記号など、キーワードや記号の意味や種類に応じて異なる表示を行う。文字色を変化させる他に、フォントを切り替えたり、太字(ボールド体)や斜体(イタリック体)などスタイルを変化させる場合がある。

どのような文字列や記号に意味があるかは言語によって異なるため、規則を言語ごとに用意して切り替えて使用できるようになっていることが多い。著名な複数の言語にあらかじめ対応しているエディタが多いが、利用者が独自に規則を定義して保存できる仕組みを備えていることもある。

また、コード記述の支援機能をエディタや統合開発環境(IDE)などに提供する「LSP」(Language Server Protocol)という通信規約(プロトコル)もあり、特定の言語の仕様に対応した「言語サーバ」を追加することで、その言語のシンタックスハイライト機能を利用可能にできるエディタ製品も増えている。

HTMLファイルにCSSのスタイル指定やJavaScriptのコードが埋め込まれている場合など、複数言語が混在する場合にはうまく機能しないこともある。プログラムが長い場合や構文が複雑な場合には、色分け処理に時間がかかったり、入り組んだ箇所の解釈を誤る場合もある。

開発者がデバッガなどの支援ツールを用いてソースコード上の特定の行や文をブレークポイントに指定してプログラムを実行すると、その位置の命令が実行される直前に中断される。その瞬間の変数の値やCPU内部のレジスタの内容など、プログラムの実行状態を詳細に調べることができる。

ブレークポイントにはプログラム中の位置を指定するのが一般的で、これを「命令ブレークポイント」という。言語処理系によっては、特定のメモリ位置へのデータの書き込み時に中断する「データブレークポイント」あるいは「ウォッチポイント」や、特定のキー入力の組み合わせなどを中断条件に指定できる場合もある。

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

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

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

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

IT業界の場合、仕様書やプログラムコードなどの成果物を、同僚(peer)の技術者が読み込んで検証する活動のことを意味することが多い。レビューを同じプロジェクトのメンバーが行なうことで、互いの知識やノウハウを共有・移転したり、成果物の欠陥や問題点を早期に発見することなどが期待される。

具体的なレビュー手法として様々な方式が提案されており、複数の検証者(レビューア)がチェックリストなどを用いて精査した結果をミーティングで議論する「インスペクション」、本人と評価者が一堂に会してその場で検証や議論を行う「ウォークスルー」、成果物を評価者に送付・回覧して意見を求める「パスアラウンド」などがよく知られる。

科学界・学術界では、学会誌などに投稿された学術論文を同じ分野の別の研究者が検証して掲載可否などを判定する活動を意味し、日本ではピアコードレビューと外来語では呼ばず伝統的に「査読」という。

レビュー手法のウォークスルー

システム開発の分野では、開発プロジェクトのメンバーが一堂に会し、仕様や構成の問題点を探したり解決策を討論したりする作業のことをウォークスルーという。

正式なレビューなどとは異なり、必要に応じて短時間開催されるインフォーマルな検討会で、プロジェクトの管理者は参加せずに作業者のみで開かれる場合が多い。特に要件定義や仕様策定、設計などの上流工程で行われることが多い。演劇の分野で話の流れを確認するための立ち稽古や通し稽古から派生した用語とされる。

3DCGのウォークスルー

3次元グラフィックス(3DCG)やバーチャルリアリティ(VR)、ビデオゲームなどの分野では、立体的に描画された建造物や仮想空間を、実際にその中にいる人物の視点で自由に動きまわって眺めることができる表現手法をウォークスルーという。

自由に移動しながら好きな場所を好きな角度から見ることができる。大規模な建築物の設計などで、完成後に内部がどのように見えるかプレゼンテーションする際などに利用されている。

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

バグの探索

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

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

バグの修正

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

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

デバッガ

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

処理の流れや変数の内容などを頭の中で思い浮かべながらプログラムコードを目で追い、記述の誤りや論理の矛盾、不適切な実行の流れなどを探し出す。ペンなどで印をつけたりメモ書きしながら行なうことも多い。

かつて、大型コンピュータを大人数で共有するのが一般的で、端末を自由に使用できずコンピュータ上での一つ一つの作業の実行にも時間がかかっていた時代に、ソフトウェアによるテストやデバッグ、プログラム修正の前段階に行う作業としてよく実施されていた。

これに対し、デバッガなどのソフトウェアを用いてコンピュータ上で行なうデバッグ作業は「マシンデバッグ」(machine debug)と呼んでいた。現代では端末を自由に操作できる環境が一般的になったため、紙に印刷せず画面にソースコードを表示して黙読するデバッグ作業を指して机上デバッグと呼ぶことが多い。

「静的解析ツール」と総称されるツール群を用いて、人間の記述したプログラムのソースコードを解析し、プログラミング言語の文法や仕様を満たしているか、定められたコーディング規約に則っているかなどを調べる。

個々の命令文などの単位では形式的な問題がなくても、実行の流れを解析して、初期化前の変数の内容を参照していたり、確保したメモリ領域の境界を越えてアクセスしようとしているなど、実行時に問題となり得る箇所を指摘してくれるツールもある。

高い安全性や信頼性が求められる航空機や原子炉、人工衛星などの制御システム、セキュリティ分野などでは、定理証明支援系などのツールを用いてプログラムの正しさや安全性を数学的に証明する「形式手法」(formal methods)が用いられることもある。

静的テストの手法としては他に、主に人間(開発者以外の第三者)がソースコードを読んで問題がないか調べる「レビュー」(review)がある。一方、実際にプログラムを実行してみて問題が発生しないか確かめることは「動的解析」(dynamic analysis)と呼ばれ、一般に単にソフトウェアのテストと言えばこちら(のみ)を指すことが多い。

ソフトウェアテストにおける動的解析

ソフトウェア開発の分野では、作成したプログラムを実行し、あるいは操作してみて正しく動作するか確かめることを動的テストという。ソフトウェアテストの手法の一つで、単にテストと言えば動的テストを指す。

一方、プログラムを実行せずに、プログラムコードを人間や専用のソフトウェアなどが読み込んで内容を分析し、誤りがないか確かめる手法を「静的解析」(static analysis)という。通常、ソフトウェアテストでは主に動的テストが活用され、静的解析は補助的に、あるいは特別な目的(形式手法による証明など)のために用いられることが多い。

マルウェア検知における動的解析

マルウェア対策の分野では、コンピュータウイルスなどの感染が疑われる実行プログラムを隔離された仮想的なシステム環境で実行してみて、不審な挙動が無いか調べる検知手法を動的テストという。

実際のシステム環境には影響を与えない「サンドボックス」(sandbox：砂場)と呼ばれる仮想的なプログラム実行環境を用意し、その中で怪しいプログラム(あるいは既知のマルウェアそのもの)を実行して振る舞いを調べる。感染後の実際の挙動を確かめられるため、感染の有無の調査よりも対策や復旧に必要な情報を得るために活用されることが多い。

一方、実行はせずに、プログラムコードに既知のマルウェアと共通するパターンが含まれるか、攻撃に繋がる不審な命令などが含まれるかなどを解析する手法を「静的解析」という。また、コード以外のプログラムファイルについての情報や特徴(ファイル名の拡張子や添付されたデジタル署名など)を解析する手法は「表層解析」と呼ばれる。

開発者はプログラム中の任意の位置にアサーションを挿入し、その箇所に差し掛かった際に満たされているべき条件を記述する。言語処理系は実行時にアサーションの記述した条件を評価し、これが満たされていない場合にはエラーや例外を発生させたり、メッセージを表示して処理を中断する。条件評価の詳細や関連する変数の値などの情報を表示する場合もある。

プログラミング言語の仕様・機能の一部や開発支援ツールとしてこれを実行時に自動的にチェックする仕組みが提供されている場合があり、これを「アサーションチェッカ」(assertion checker)という。

アサーションは開発時のみ使われリリース時には不要なため、アサーションチェックに対応した言語や処理系ではアサーション関連のコードを削除しなくても有効・無効を簡単に切り替えられるようになっていることが多い。

人間がプログラミング言語で書いたソースコードには誤りが含まれることがあり、コンピュータが実行可能な形式(オブジェクトコード)に変換できないような文法上の誤りなどはコンパイラなどが検出して修正を促すが、処理の論理的な誤りなどを自動的に検知するのは難しく、開発者が自力で欠陥を見つけて除去しなければならない。

デバッガはプログラムの実行状態に介入したり、実行中のある瞬間におけるコード中の変数やメモリの特定の番地、CPU内部のレジスタなどの値を表示することができ、どこで誤りが生じているのか探し出すのを手助けしてくれる。

ブレークポイント(breakpoint)機能はプログラマがコード中の任意の箇所を指定し、実行時にその場所に差し掛かったら強制的に実行を一時停止してその時点での変数などの状態を確認することができる。

ステップ実行(step by step execution)あるいはシングルステップ実行(single stepping)は、ブレークポイントなどで一時停止後、プログラムを一ステップ(一行、一命令など)ごとに実行する機能で、各ステップで実際にどのような処理が行われたかを確認しながら実行を進めることができる。

ステップ実行中に関数呼び出しなどに出くわした場合に、その内部へ移動してさらにステップ実行するステップイン、ステップインした関数等の終了までを一気に実行(呼び出し元に戻った時点で一時停止)するステップアウト、関数等の呼び出しなどをスキップするステップオーバーなどの機能が利用できる場合もある。

オブジェクトコードを実行しつつ、対応するソースコード上での実行位置や変数名などを参照できるものをシンボリックデバッガ(symbolic debugger)あるいはソースレベルデバッガ(source-level debugger)と呼び、通常はこちらが使われるが、ソースコードが入手できない場合など特殊な状況で利用される、実行形式コードを直接解析するデバッガ(low-level debugger/machine language debugger)も存在する。

プログラミングツールのトレーサ

プログラムの修正を補助するツールの一種で、プログラムの実行過程を記録して可視化するソフトウェアをトレーサーという。

トレーサー上でプログラムを実行すると、その過程を追跡・記録し、実行された命令を順番に、レジスタや変数の値などの状態と共に表示してくれる。これを見ることで、プログラムが意図したとおりに動作しているかを調べたり、どこに誤りがあるかを発見するのが容易になる。

ストレージ(外部記憶装置)内のすべてのファイルやディレクトリ、データベース内の全データ、仮想化環境(仮想マシン)の実行状態など、刻々内容が変動する何らかのデータ集合について、ある瞬間の状態を丸ごと写し取った複製のことをスナップショットという。

スナップショットを取って保管しておくことで、データが破損・喪失した際に、ある特定の時点の状態を復旧したり、別の機器にデータやシステムの状態を複製・移転することができる。また、後から過去のある時点の状態を参照することもできる。

システムが稼動状態のまま漫然とデータをコピーすると、複製開始から終了までの途中の段階で利用者や他のソフトウェアが一部のデータを書き換えてしまう恐れがあるため、スナップショット作成中は一時的に書き込みを禁止したり、書き込むべき内容を保管しておいて終了後にまとめて反映させるといった機能が提供されることが多い。

ソフトウェアのスナップショット

ソフトウェア開発やプログラミングの分野では、開発中のソフトウェアについて、ある時点におけるソフトウェアを構成するプログラムコードや関連するデータなどのまとまりをスナップショットと呼ぶことがある。

バージョン番号などが付与され、正式に利用者向けに提供される「リリース」(release)とは異なり、主に開発者や熟練利用者向けに、ある日時における最新版を共有するために作成される。最新機能などを試すことができるが、十分なテストなどが行われておらず動作が不安定なことが多い。

画面のスナップショット

パソコンやスマートフォンなどで、ある瞬間の画面全体やソフトウェアの表示状態を画像として取得して保存したものを「画面キャプチャ」「スクリーンショット」などというが、これをスナップショットと呼ぶことがある。“snapshot” の原義の一つに「スナップ写真」があり、これに近い用法である。

開発途上の対象物を試しに動かしてみて、仕様通りに動作するか、期待した性能を発揮するかなどを調べるために用意される。具体的にどのような構成の環境にするかは対象物の種類やテストの内容、目的に応じて変わる。

情報システム開発の場合、プログラム部品など構成要素のテスト(単体テストなど)は開発環境上でデバッガやテストツールなどを使って行うことが多い。全体が完成して最終確認の試験を行う場合は、実際の稼働環境(本番環境)と変わらない構成で構築された「ステージング環境」を用意することが多い。

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

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

単体テストツール

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

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

単体テストの意義

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

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

デバイスドライバ

コンピュータ内部に装着した装置や、外部に接続した機器を制御・操作するための専用ソフトウェアを「デバイスドライバ」(device driver)または「ドライバソフト」(driver software)と呼び、「ドライバ」と略すことが多い。

オペレーティングシステム(OS)がハードウェアを制御するための橋渡しを行なうプログラムで、OSに組み込まれてその機能の一部として振舞う。原則として装置ごと、OSごとに必要となるが、USB機器のように基本的な機能は汎用ドライバ(標準ドライバ)で制御できる場合もある。

テストドライバ

ソフトウェアテストの分野で、テスト用の呼び出しプログラムを「テストドライバ」(test driver)または「サンプルドライバ」(sample driver)、あるいは単にドライバという。

複数のソフトウェア部品(モジュール)の結合テストを行なう際に、呼び出し側のモジュールが未完成であったり、テストのために実行するのが面倒だったりする場合に、その代用として作られる。逆に、呼び出される側のモジュールの代用となるプログラムは「スタブ」(stub)という。

ドライバ回路

電子回路で、対象に電力を供給して動かしたり、遮断して止めたりする機能を持った回路を「ドライバ回路」(driver circuit)「ゲートドライバ」(gate driver)などという。モーターなどの電気駆動の装置を制御するのに用いられる。

ソフトウェアテストで、あるモジュール(部品)の動作をテストする際、呼び出し先の下位モジュールの代わりをする空のモジュールのことをスタブという。下位モジュールが未完成なうちに上位モジュールのテストをしたい場合に用意される。これとは逆に、下位モジュールを呼び出すだけの機能を持った上位モジュールの代用品は「ドライバ」(テストドライバ)という。

スタブは本物の下位モジュールと同じ名称や引数、返り値の型などを持ち、上位モジュールから同じコードで呼び出される。内部は空で何も処理を行わないが、本物と同じような値を返さなければならない場合には、想定される返り値の一つをあらかじめ算出しておき、これを定数として機械的に返却するといった処理を行うことが多い。

また、分散システムなどで、ローカル側でメソッド呼び出しなどを受け付けるオブジェクトなどのことをスタブということがある。自身は処理そのものは行わずリモート側への仲介を行う機能のみを持つ。スタブ自体はローカルであるため、呼び出し元は通信の詳細を意識せずローカル呼び出しのみを用いてコードを記述することができる。

ソフトウェア開発では記述したプログラムのテストと修正を繰り返して品質を向上していくが、テストの序盤は発見数が少なく、次第に一定のペースで発見できるようになり、開発が終盤に差し掛かると再び発見数が減少していく(最終的には見つからなくなる)という経過をたどるのが一般的である。

この過程を、縦軸を累積発見数、横軸を経過時間(テスト回数やテストケース数などで代理することもある)とする平面上に曲線で表したものがバグ曲線である。序盤の発見数から曲線の形状を推定してその後の推移を予測することができる。どの程度の累積バグ数になったら十分な品質になったと判断できるかの基準として用いる場合もある。

曲線の形状は序盤が下に凸(加速度が正)、中盤の変曲点を境に上に凸(加速度が負)で、終盤に一定の値に収束するような形をしており、ゴンペルツ曲線やロジスティック曲線などで近似し、最小二乗法などの手法で係数を決定することが多い。

横軸が時間(日付や開始からの経過時間)、縦軸がテスト項目数およびバグ数を表し、未実施テスト項目数、累積バグ検出数、未解決バグ数の3つの曲線を描画する。未実施テスト項目数は累積テスト実施項目数とする場合(曲線の形状が反転する)もある。

テスト工程を開始すると、未実施テスト数は左上から右下に向かって下落していき、累積バグ数は左下から右上に向かって増加する。未解決のバグ数は初期には発見されるに従って増えるが、解決した分だけ減少するため、順調に修正が進めば横ばいや減少の傾向を示す。

ある程度テストを進めると累積バグ数の増加の仕方が緩やかになっていき、やがてすべてのバグが発見され頭打ちとなる。すべてのテストを実施しても累積バグ数が平らにならない場合はテストの実施が不足している可能性がある。また、未解決のバグが蓄積しテストが進まず、未実施のテスト数が横ばいになってしまう場合もある。

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

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

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

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

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

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

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

ソフトウェアやシステムが期待通り動作するかを確認するために用意するもので、一つのプログラムをテストするために複数のテストケースを作成することが多い。複雑・大規模なソフトウェアでは膨大な数のテストケースを作成することもある。

テストケースは基本的に「このような条件・状況でこのような入力を与えると、このような結果になる」という形で表現される。人が読んで分かるよう文書として作成し、人がそれを読んで一件ずつテストする場合と、一定のデータ形式で記述あるいは自動生成し、テストツールを用いて自動的に検証する場合がある。

作成した各ケースについて、実施したテスト結果(合否や出力値、システムの挙動など)を記録し、開発者にフィードバックするデータ管理の仕組みも必要となる。一度テストしたケース群はプログラムに対応付けて保管しておき、バージョンアップなどの際に再度実施することでデグレード(リグレッション)を防ぐことができる。

ケースの作成

テストケースの作成にあたっては、テストの対象、目的、構成や環境、前提条件、操作手順、入力データ、期待する出力データや振る舞いなどを、誰が見ても同じように実施できるよう曖昧さなく記述する必要がある。

テストの目的に応じて、「正常な操作や入力に対して、期待した結果が得られる」ことを確かめる正常系テストと、「異常な操作や入力に対して、致命的な事態に陥らずに対処できる」ことを確かめる異常系テストがあり、それぞれのケースを作成する必要がある。

よほど単純なプログラムでない限り、ありとあらゆる操作や入力値の組み合わせを試すことはできないため、同じ挙動が期待される範囲から代表して一つのケースが作られる。このとき、入力値のバリエーションに重複や欠落が起きないよう、同値分割、境界値分割、ペアワイズ法などの手法が駆使される。

プログラムの内部構造に基づいてテスト方針を決める「ホワイトボックステスト」の網羅性を表すレベルの一つで、プログラムに含まれる命令文(ステートメント)をなるべく多く網羅するようテストケースの作成などを行う。

網羅性の水準としては他に「分岐網羅」(C1)や「条件網羅」(C2)などがあり、命令網羅の網羅性はこれらより低いが、最も少ないテストケースで実施することができる。分岐網羅は命令網羅を包含するため、分岐網羅率が100%ならば命令網羅率も100%となる。

プログラムの内部構造に基づいてテスト方針を決める「ホワイトボックステスト」の網羅性を表すレベルの一つで、複数の条件を組み合わせた条件分岐がある場合に、個々の条件の真偽に着目する。

例えば、if(A or B) という複合的な条件がある場合、Aが真の場合と偽の場合、Bが真の場合と偽の場合のすべてが含まれるようにする。すなわち、(A,B)=(真,真)(偽,偽)の2ケース、あるいは、(A,B)=(真,偽)(偽,真)の2ケースのどちらかをテストすれば網羅できる。

網羅性の水準としては他に「命令網羅」(C0)や「分岐網羅」(C1)などがあり、条件網羅はこれらより多数のテストケースが必要だが網羅性も高くなる。分岐網羅は命令網羅を包含するという関係にあるが、条件網羅は必ずしもこれらを含んだり含まれたりするとは限らない。

複合条件網羅 (MCC：Multiple Condition Coverage)

プログラム中の条件分岐に複数の条件の組み合わせがある場合に、そのすべての組み合わせを網羅することを複合条件網羅という。

条件網羅では個々の条件について真と偽の両方が含まれていれば別の条件との組み合わせは関知しないが、複合条件網羅では条件の真偽のすべての組み合わせをテストする必要がある。if(A or B) という2つの条件を組み合わせた分岐の場合、(A,B)=(真,真)(偽,偽)(真,偽)(偽,真)の4ケースが必要となる。

複数条件網羅

「複数条件網羅」という用語は、一般的には複合条件網羅の同義語として、一つの条件分岐に含まれる複数条件のすべての真偽の組み合わせを網羅することを意味する場合が多い。

一方、複合条件網羅とは異なるとする立場もあり、その場合は、プログラム中の複数の条件分岐の真偽のすべての組み合わせを網羅するという意味に解釈することが多い。例えば、テストするプログラム中に条件分岐がXとYの2つ含まれている場合に、(X,Y)=(真,真)(偽,偽)(真,偽)(偽,真)のすべての組み合わせを網羅する。ただし、分岐が入れ子(ネスト)状になっておりXの結果によってYへ到達するか変わる場合にはこの限りではない。

プログラムの内部構造に基づいてテスト方針を決める「ホワイトボックステスト」の網羅性を表すレベルの一つで、プログラム中の条件分岐で枝分かれしている命令の流れについて、なるべく多くを網羅するようテストケースの作成などを行う。

網羅性の水準としては他に「命令網羅」(C0)や「条件網羅」(C2)などがあり、判定条件網羅の網羅性は両者の中間程度となる。命令網羅は判定条件網羅に含まれるため、判定条件網羅率が100%ならば命令網羅率も100%となる。

プログラムの内部構造に基づいてテスト方針を決める「ホワイトボックステスト」の網羅性を表すレベルの一つで、複数の条件を組み合わせた条件分岐がある場合に、個々の条件の真偽に着目する。

例えば、if(A or B) という複合的な条件がある場合、Aが真の場合と偽の場合、Bが真の場合と偽の場合のすべてが含まれるようにする。すなわち、(A,B)=(真,真)(偽,偽)の2ケース、あるいは、(A,B)=(真,偽)(偽,真)の2ケースのどちらかをテストすれば網羅できる。

網羅性の水準としては他に「命令網羅」(C0)や「分岐網羅」(C1)などがあり、複数条件網羅はこれらより多数のテストケースが必要だが網羅性も高くなる。分岐網羅は命令網羅を包含するという関係にあるが、複数条件網羅は必ずしもこれらを含んだり含まれたりするとは限らない。

複合条件網羅 (MCC：Multiple Condition Coverage)

プログラム中の条件分岐に複数の条件の組み合わせがある場合に、そのすべての組み合わせを網羅することを複合条件網羅という。

条件網羅では個々の条件について真と偽の両方が含まれていれば別の条件との組み合わせは関知しないが、複合条件網羅では条件の真偽のすべての組み合わせをテストする必要がある。if(A or B) という2つの条件を組み合わせた分岐の場合、(A,B)=(真,真)(偽,偽)(真,偽)(偽,真)の4ケースが必要となる。

複数条件網羅

「複数条件網羅」という用語は、一般的には複合条件網羅の同義語として、一つの条件分岐に含まれる複数条件のすべての真偽の組み合わせを網羅することを意味する場合が多い。

一方、複合条件網羅とは異なるとする立場もあり、その場合は、プログラム中の複数の条件分岐の真偽のすべての組み合わせを網羅するという意味に解釈することが多い。例えば、テストするプログラム中に条件分岐がXとYの2つ含まれている場合に、(X,Y)=(真,真)(偽,偽)(真,偽)(偽,真)のすべての組み合わせを網羅する。ただし、分岐が入れ子(ネスト)状になっておりXの結果によってYへ到達するか変わる場合にはこの限りではない。

少ないテスト回数でより広い範囲をカバーするための手法の一つで、出力が変化する境界付近では条件式の記述ミスや設計書の解釈の誤りなどによりバグが頻発するため、その付近の値を重点的に調べる。

例えば、「6歳未満」「6歳以上18歳未満」「18歳以上」といった条件で処理が分岐する場合、境界付近にある5歳、6歳、17歳、18歳といった入力値をテストケースに選択する。

これに対し、出力が同値となるグループの中から適当に選んだ代表をテストデータとして取り上げる手法は「同値分割」「同値分析」と呼ばれる。一般的には同値分割と限界値分析法を併用することが多い。

少ないテスト回数でより広い範囲をカバーするための手法の一つで、期待される出力や処理結果が同じであるような入力は「同値クラス」と呼ばれる一つの集団にまとめる。その中から適当に選んだ一つの入力のみを試すことで、効率良くテストを進めることができる。

例えば、「18歳未満」という条件で行われる処理があるとき、その箇所を0歳から17歳まで18回テストする代わりに、10歳の場合のみをテストすることで大幅にテスト回数を減らすことができる。

これに対し、出力が切り替わる境界となる値をテストデータとして取り上げる手法は「限界値分析」または「境界値分析」と呼ばれる。一般的には同値分析法と限界値分析を併用することが多い。

例えば、いくつのバグがあるか分からないプログラムに開発者がわざと20個のバグを埋め込み、テスト担当者に送る。担当者は埋め込まれたバグがどこにあるか知らない状態でテストを行い、15個のバグを発見したとする。

開発者に発見したバグの詳細を報告し、15個のバグのうち、埋め込んだものが5個、本物のバグが10個だったとする。埋め込んだバグの発見率は5/20で25%であるため、本物のバグも同じ割合で発見できたと仮定すると、もともと存在した本物のバグは10/0.25で40個、残りは30個と推定できる。

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

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

開発途上の対象物を試しに動かしてみて、仕様通りに動作するか、期待した性能を発揮するかなどを調べるために用意される。具体的にどのような構成の環境にするかは対象物の種類やテストの内容、目的に応じて変わる。

情報システム開発の場合、プログラム部品など構成要素のテスト(単体テストなど)は開発環境上でデバッガやテストツールなどを使って行うことが多い。全体が完成して最終確認の試験を行う場合は、実際の稼働環境(本番環境)と変わらない構成で構築された「ステージング環境」を用意することが多い。

複数のモジュール(部品)を組み合わせてソフトウェアなどを開発する場合、問題の発生箇所を特定しやすくするため、いきなりすべてを繋いで一気に調べるのではなく、少しずつ追加していきながら何度も繰り返し試験する「結合テスト」がよく用いられる。

その際、「スタブ」(stub)と呼ばれるダミーの下位側(呼び出される側)のモジュールを用意し、上位モジュールから順に結合してテストする方式をトップダウンテストという。上位モジュールに問題が見つからなければ、スタブを本物の下位モジュールに置き換えて再びテストが行われる。同じ手順を何段階も繰り返し、上位側から下位側へ順番にテスト対象を広げていく。

最上位のモジュールからテストしていくため、システムの中枢部分に致命的なバグがある場合などに早期に発見して取り除くことができるメリットがある。一方、プログラミングとテストを並行して行おうとするとスタブを大量に用意しなければならない。

一方、下位モジュールから順に結合しながらテストを繰り返す手法を「ボトムアップテスト」、上位側と下位側から同時に結合していく手法を「サンドイッチテスト」(折衷テスト)、全モジュールの完成後にすべて結合して一気にテストする手法を「ビッグバンテスト」という。

複数のモジュール(部品)を組み合わせてソフトウェアなどを開発する場合、問題の発生箇所を特定しやすくするため、いきなりすべてを繋いで一気に調べるのではなく、少しずつ追加していきながら何度も繰り返し試験する「結合テスト」がよく用いられる。

その際、「ドライバ」(driver/テストドライバとも)と呼ばれるダミーの上位側(呼び出し側)のモジュールを用意し、下位モジュールから順に結合してテストする方式をボトムアップテストという。下位モジュールに問題が見つからなければ、ドライバを本物の上位モジュールに置き換えて再びテストが行われる。同じ手順を何段階も繰り返し、下位側から上位側へ順番にテスト対象を広げていく。

最下位のモジュールからテストしていくため、一般的な開発手法ではプログラミングと並行してテストを実施しやすいが、上位側のテストは手薄になりがちで、システムの中核部分や全体の連携などに潜在する問題を十分に洗い出せないこともある。

一方、上位モジュールから順に結合しながらテストを繰り返す手法を「トップダウンテスト」、上位側と下位側から同時に結合していく手法を「サンドイッチテスト」(折衷テスト)、全モジュールの完成後にすべて結合して一気にテストする手法を「ビッグバンテスト」という。

デバイスドライバ

コンピュータ内部に装着した装置や、外部に接続した機器を制御・操作するための専用ソフトウェアを「デバイスドライバ」(device driver)または「ドライバソフト」(driver software)と呼び、「ドライバ」と略すことが多い。

オペレーティングシステム(OS)がハードウェアを制御するための橋渡しを行なうプログラムで、OSに組み込まれてその機能の一部として振舞う。原則として装置ごと、OSごとに必要となるが、USB機器のように基本的な機能は汎用ドライバ(標準ドライバ)で制御できる場合もある。

テストドライバ

ソフトウェアテストの分野で、テスト用の呼び出しプログラムを「テストドライバ」(test driver)または「サンプルドライバ」(sample driver)、あるいは単にドライバという。

複数のソフトウェア部品(モジュール)の結合テストを行なう際に、呼び出し側のモジュールが未完成であったり、テストのために実行するのが面倒だったりする場合に、その代用として作られる。逆に、呼び出される側のモジュールの代用となるプログラムは「スタブ」(stub)という。

ドライバ回路

電子回路で、対象に電力を供給して動かしたり、遮断して止めたりする機能を持った回路を「ドライバ回路」(driver circuit)「ゲートドライバ」(gate driver)などという。モーターなどの電気駆動の装置を制御するのに用いられる。

ソフトウェアテストで、あるモジュール(部品)の動作をテストする際、呼び出し先の下位モジュールの代わりをする空のモジュールのことをスタブという。下位モジュールが未完成なうちに上位モジュールのテストをしたい場合に用意される。これとは逆に、下位モジュールを呼び出すだけの機能を持った上位モジュールの代用品は「ドライバ」(テストドライバ)という。

スタブは本物の下位モジュールと同じ名称や引数、返り値の型などを持ち、上位モジュールから同じコードで呼び出される。内部は空で何も処理を行わないが、本物と同じような値を返さなければならない場合には、想定される返り値の一つをあらかじめ算出しておき、これを定数として機械的に返却するといった処理を行うことが多い。

また、分散システムなどで、ローカル側でメソッド呼び出しなどを受け付けるオブジェクトなどのことをスタブということがある。自身は処理そのものは行わずリモート側への仲介を行う機能のみを持つ。スタブ自体はローカルであるため、呼び出し元は通信の詳細を意識せずローカル呼び出しのみを用いてコードを記述することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェアに対するテストの多くは、想定される用途や使用環境、操作方法、入力データなどをに対して期待通りの処理や動作が行われるかを調べるために行われる。しかし、それだけでは想定外の操作やデータによって致命的な誤作動が引き起こされる可能性が残るため、通常は想定されない利用パターンに対する反応を調べるファジングが行われる。

最も一般的な方式では、「ファジングツール」「ファザー」と呼ばれる専用ソフトウェアを用いて対象の挙動に問題を引き起こしそうな入力値を大量に自動生成する。これをテストツールで次々にテスト対象に与え、その反応から未知の問題が発生しないか調べる。

検査用の入力値は正常な入力値の例を元に、一部を置き換えたり改変するなどして生成する手法が用いられることが多いが、まったくランダムに生成する手法や、怪しい入力値を人が考えて列挙する方式、値を連続的に変化させてあり得る入力値をしらみつぶしに調べる方式などが用いられることもある。

システム開発の初期段階では要件定義を行い、システムを導入する業務をどのように行うか、その中でシステムがどのような役割を果たすべきかを策定していく。最初に行われるのは業務プロセスの明確化で、対象業務の現状を分析し、システム化後に実現すべき業務の詳細な手順や情報の出入りを明らかにする。これを業務要件という。

業務要件が定義できたら、これを実現するためにどのような情報システムを開発すべきか、システムが何をできなければならないかをシステム要件として定義する。このうち、システムが備えるべき機能を定めたものを「機能要件」、性能や容量、セキュリティなど機能以外に満たすべき事項や制約を定めたものを「非機能要件」という。

システム要件を定義する段階では、何を使ってどのように実現するのかには踏み込まず、あくまで何ができなければならないかを記述する。実装方式の検討は次の設計フェーズで行われる。また、業務に対するシステム機能の過不足が生じないよう、システム要件の各要素が業務要件のどれを実現しているのかを意識して明確化すべきとされる。

他の既存システムや外部の事業者が提供するサービスなど、外部の別のシステムとの連携が必要なシステムで行われる。システムテストなど、システム単体としての動作の検証は済んでいる必要がある。顧客が利用する機材で動作するかどうかのテストを含む場合もある。

システム統合テストを行う場合はシステムテストとユーザー受け入れテスト(UAT：User Acceptance Test)の間に実施するのが一般的だが、他システムとの接続が特に意識されない場合は単体の工程としては行わないこともあり、システムテストや受け入れテストの工程の一部とする場合もある。

また、システムテストのことや、統合テスト(結合テスト)の最終段階などのことを指してシステム統合テストと呼ぶ場合もある。

個々のモジュール(部品)を対象とした単体テスト、複数のモジュールを組み合わせた結合テストがすべて終わったあとに仕上げとして行うテストである。製品として完成したものを本番とほとんど同じ環境でテストする。

システムが全体として要求された仕様通りに動作するか、性能や負荷への耐性は十分か、操作性やセキュリティに問題が無いかなどを検証する。システム検証テストで問題が発見されなければ開発側での工程は終了し、顧客への引き渡し、顧客側での受け入れテスト(UAT/検収テスト)などを経て、実環境での稼働開始などの段階へ進む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一般的なテスト手法では、プログラムの仕様や設計を元にテストケースを作成し、テスト工程では事前に決めたケースについてテストを実施して結果を開発側にフィードバックする。

一方、探索的テストではテストの目的や終了の目安だけを決め、細かいテストケースは事前に作成しない。テスターが実際に操作したりプログラムの挙動を見ながら、気になる箇所を次々にテストしていき、結果を記録して開発側にフィードバックする。

テストの準備かかる手間を軽減でき、すぐにテストに着手することができるほか、仕様や設計が不確かな箇所にも柔軟に対処できる。反復型開発手法との相性も良い。網羅的にケースを作成する場合に比べ、重要な箇所やテスターが不審に感じた箇所を集中的にテストすることができるため、バグ発見の効率も良いとされる。

ただし、どこをどのようにテストするかはテスター個人の知識や技能、経験、勘に依存するため、属人性が高く質が一定しない。テストの範囲や詳細さの管理、コードや仕様に対する網羅性の確保なども難しく、品質保証の目的で実施するのには向いていない。

似たテスト手法に「アドホックテスト」あるいは「モンキーテスト」と呼ばれるものがある。事前に手順を定めずにテスター自身がテスト内容を決める点は共通しているが、「その場の思いつき」「ランダム性」が重視され、開発者の思いも寄らない使い方をしたときにどう反応するかといった点を確認するために行われる。

ソフトウェアを構成するプログラムファイルやデータファイルをストレージ(外部記憶装置)の所定の位置に配置するだけでインストールが完了する場合と、OSの設定などの一部を追加・変更する必要がある場合がある。記憶媒体を機器に挿入すれば起動する家庭用ゲーム機のゲームソフトのように、インストールの作業を行わなくても使用可能なソフトウェアもある。

複雑、大規模なソフトウェアやシステム関連のソフトウェアなどはファイルのコピーだけでなく設定作業が必要な場合が多く、利用者が手作業しなくても済むように、インストール処理を自動化するソフトウェアが配布パッケージ中に含まれていることが多い。これを「インストーラ」(installer)と呼び、起動時にオプションを指定したり起動後に対話形式で必要な項目を入力することで、利用者に代わってインストール処理を進めてくれる。

インストールには目的や状況により様々な種類がある。既存のソフトウェアの影響を受けないような状態(記憶装置を完全に消去する等)にした上でまったく新しくインストールすることを「クリーンインストール」(clean install)、インストール済みのソフトウェアのファイルや設定が破損するなどした際に再度インストールを行なって導入直後の状態に戻すことを「修復インストール」(recovery install)という。

また、同じソフトウェアの新しいバージョンをインストールして古いバージョンを上書き、更新することを「アップグレードインストール」(upgrade install)という。修復インストールとアップグレードインストールを合わせて「上書きインストール」(overwrite install)と分類する場合もある。

これに対し、コンピュータに組み込まれたソフトウェアを消去し、導入前の状態に戻す処理や作業のことは「アンインストール」(uninstall)、アンインストールを行うソフトウェアは「アンインストーラ」(uninstaller)という。また、コンピュータやOSなどの製品にあらかじめソフトウェアがインストールされた状態で出荷・提供されることを「プレインストール」(preinstall)という。

開発中のシステムがどのような状態に達したら本稼働(カットオーバー)に移行するのかを定めた基準のことで、システムそのものの品質や稼働試験の進捗などに加え、利用者への周知や操作手順の教育などの進捗、運用・保守などの体制、移行時に問題が発生した場合の対応計画の策定状況などを勘案する場合が多い。

開発終盤のシステム全体のテストなどが行われるタイミングで、開発プロジェクトの関係者が集まって判定会議を行うことがある。導入可否判断基準に基づいて進捗の確認や事前のスケジュール通りに稼働を開始できるかの確認などを行う。

仮想化とは機器の持つ機能や能力、容量などをソフトウェア的に分割あるいは統合し、複数の機器をまとめて一台のように振る舞わせたり、一台の機器を分割して複数の独立した仮想的な機器として振る舞わせる技術である(通常は後者の分割を指す)。

仮想環境はコンピュータなどIT資源をそのまま用いず、仮想化された仮想マシン(VM：Virtual Machine)などの単位で運用する。サーバなどを仮想環境で運用することにより、機器の物理的な構成とソフトウェアやシステムの運用を分離することができる。

これにより、用途ごとに複数の物理的なサーバ機に分かれて運用されていたシステム群を単一のサーバインフラに統合(サーバ統合)して管理の集中化や効率化を図ったり、機器メンテナンスなどの際に仮想マシンを別の物理サーバに移転してサービスを継続するといった柔軟な運用が可能となる。

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

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

第三者によるUAT

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

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

ベンダーテスト

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

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

納品された製品の種類や型番、数量が発注時に指定した通りに揃っているか、仕様や品質の基準などを満たしているか、破損や汚損、欠陥、不具合、不良品が無いかなどを調べる。対象が機械やソフトウェアなどの場合は、実際に動かして挙動を確認する動作試験を行う場合もある。

一般的には検収に合格すると納品完了となり、代金の請求と支払いの手続きに進む。検収完了をもってその製品に関する責任は受注者から発注者へ移動し、後で不具合などが見つかっても発注者側の負担で解決するのが原則である。ただし、契約内容や両者の力関係により必ずしもその通りにならないことも多く、原因や責任、費用負担をめぐって争いになる場合もある。

情報システム開発の委託の場合は、受注者によるシステムの開発が終わり、発注者側に構築されたシステムに対して、発注側の人員や責任において稼働試験を行うことが多い。これを「受け入れテスト」(UAT：User Acceptance Test/ユーザーアクセプタンステスト)と呼び、これに合格すると納品されたシステムの検収完了となる。

検収が完了したら、発注者が受注者に検収書を発行する場合がある。法的に義務付けられている書類ではないが、トラブル防止や手続きを円滑に進めるために発行される。記載される項目としては、発注者と受注者、商品の名称や数量、金額、検収を行った日付や担当者、部署などがある。

コンピュータ上で閲覧、操作できる学習教材と、カリキュラムや成績、到達度などを把握、管理するシステムを組み合わせたものが一般的で、学習者が自習する形式のものと、教師が講座を運営する前提のものがある。

紙の教科書やプリントなどを中心とする従来の教材に比べ、音声や映像を組み合わせたり、利用者の操作に応じて展開や選択ができる双方向性を活用したり、関連する項目をすぐに参照できるハイパーリンクの仕組みなど、コンピュータならではの機能を利用することができる。

また、自習形式のシステムの場合、学習者が決まった場所や時間に集まって受講する必要がなく、インターネットなどを通じていつでもどこからでも教材にアクセスし、習熟度に応じて自分のペースで学習を進めることができる。

一方、様々な情報や仕組みを組み合わせた教材の開発は難しくコストがかかり、特定のシステムやサービスでしか利用できない問題がある。また、一斉講義ではない方式だと教師と学習者の接触機会が限られ、その場で質問して疑問を解消するといった活動が難しいほか、実技や実習が中心の内容は扱いづらい。学校のような長期的な学習活動の場合は学習者の意欲や自己管理の維持が課題となることもある。

企業研修や資格試験の講座などで広く活用されているほか、通信教育過程を中心に教育機関での利用も広がっている。大学などの高等教育機関では「OCW」(オープンコースウェア)あるいは「MOOC」(Massive Open Online Course)と総称される公開講座形式のオンライン教材の無償公開が活発になっており、世界のトップクラスの大学の講座を誰でも聴講することができるようになりつつある。

ソフトウェアの導入(インストール)や新規ファイルの作成など、必要な設定項目や入力すべき情報が複数(しばしば多数)ある場合によく用いられる方式で、入力事項を案内と共に一度に一つだけ画面に表示し、利用者がそれに答えると次の項目に進むという動作を繰り返す。

どんなに項目が多かったり入力内容が複雑でも、利用者は一度に一つの項目のみ答えればよいため、いっぺんにすべての項目を表示するよりも体感的な難解さを軽減することができ、初心者やコンピュータの操作に熟達していない利用者にとっては使いやすいとされる。

一方、利用者が重視しない項目でも回答しないと次に進めず、表示の仕方によっては処理の全体像が見通しにくく、途中で中断したり以前の項目に引き返すと途中まで入力した内容がやり直しになる場合があるなど、熟練の利用者には冗長だったり制約に感じられる点も多く、あまり好まれない傾向にある。

製品などの解説を記述した文書の一種で、コンピュータやソフトウェアなど利用方法が複雑な製品について提供されることが多い。製品に関連する情報を網羅的に掲載、説明した取扱説明書やリファレンスマニュアルなどとは区別されるが、これらの一節として収録されていることもある。

販売されている製品の場合は書籍やパンフレット、シートなど印刷物の形でパッケージに同梱されることが多いが、解説を映像で収録したDVDなどが添付される場合もある。ネットサービスやフリーソフトウェア、プログラミング言語など、物理的なパッケージを伴わないものの場合はWebサイトや動画共有サイトのビデオの形で公開されることが多い。

ソフトウェア製品やゲームソフトなどでは、機能の一部としてチュートリアルが実装され、実際に利用者に操作の練習などをさせながら解説を進めるものもある。利用開始時や初回起動時などに自動的に開始されるようにできていることが多い。ゲームの場合は開始直後の序盤のステージなどがチュートリアルを兼ねた構成になっていることもある。

チュートリアルは単に内部の構造や機能、利用法などを個別に解説するのはなく、利用を始めるまでの準備や導入作業、初期に行う設定や手続き、基本的な事項や概念の説明、初歩的な使い方などを順を追って具体的に提示する。実践や例が豊富に盛り込まれ、チュートリアルに沿って作業すれば一通りの知識や技能が身につくように設計されている。

一般の外来語としては、一対一あるいは少人数制で教育を行うことをチュートリアルということがある。そのような指導を行う指導者を「チューター」(tutor)という。家庭教師や個別指導塾などでの指導が該当する。学校や塾などで、卒業生や大学生などがチューターとなり補修や個別指導を行うプログラムを提供している場合もある。

情報セキュリティ上のインシデント

情報セキュリティの分野では、情報管理やシステム運用に関して保安上の脅威となる人為的な事象を「セキュリティインシデント」(security incident)と呼び、これを略して単にインシデントと呼ぶことが多い。

当該組織が運用するコンピュータシステムや管理下にある情報の機密性、完全性、可用性を脅かす(危険性のある)何らかの人為的な事象を指し、マルウェア感染や不正アクセス、パスワード漏洩、Webサイト改竄、機密情報流出、フィッシング、サービス拒否攻撃(DoS攻撃)などが含まれる。

インシデントが発生した際に行われる被害把握や原因特定、正常な状態への復旧、利害関係者への報告や連絡といった対応業務を「インシデントレスポンス」(incident response)という。これを行うために組織内に設置された部署を「CSIRT」(Computer Security Incident Response Team/シーサート)という。

ITサービスにおけるインシデント

企業の情報システム運用などの分野では、利用者がITシステムによって本来できるはずの業務、行為を正常に遂行できない状態や事象のことをインシデントという。「できない状態」そのものを指す概念で、それが機器やソフトウェアの不具合や障害、故障に由来する場合、不具合等は「インシデントの原因」であると考える。

例えば、利用者から「コンピュータを使おうとしたら画面が真っ暗で表示されない」という報告を受けた場合、「ディスプレイ装置が壊れていた」というハードウェア障害が原因の場合もあるが、「ディスプレイの電源コンセントが外れていた(ことに利用者が気付かなかった)」といった原因によって起こっている場合もある。

このため、インシデントはそれ自体を故障や障害とは区別して登録・管理する必要があり、ITシステムにおけるインシデントを情報システム部門が記録して対応する業務を「インシデント管理」という。

アクシデントとの違い

英語の “accident” (アクシデント)は事故、災難、偶然、運、巡り合わせ、偶発的な出来事、予期せぬ失敗といった意味の英単語で、故意や必然ではなく偶然に起こった悪い出来事、あるいは予期せず不意に生じた事態という意味合いがある。

通常、アクシデントは何らかの被害や損害、不利益が生じてしまった事故や事件そのものを指す一方、インシデントはその一歩手前の予兆や異変、逸脱や違反行為、危機的な状況や現象などのことを指すという違いがある。

他分野におけるインシデント

IT分野以外でも、重大な事故に繋がりかねない、いわゆる「ヒヤリハット」事象や逸脱事例などを指してインシデントという用語を用いることがある。特に、医療など事故が人命に直結する分野でインシデントの概念を用いることが多い。日本では航空法や鉄道事業法において、事故に繋がりかねない危険な事象の報告義務などを定めており、これを「重大インシデント」という。

ITの分野では、システム開発などの各工程で制作される様々な文書やプログラムなどについて、対応関係や変更履歴などを記録し、追跡や検証ができる状態をトレーサビリティという。

例えば、要件定義と仕様書、仕様書とソースコード、仕様書とテスト仕様書などの間で、前工程で規定された項目が後工程の成果物に漏れなく反映されているかをチェックできるようにすることなどを指す。

ソフトウェアインスペクション (software inspection)

ソフトウェア開発におけるレビュー手法の一種で、仕様書やソースコードなどの成果物を人の目で見て不具合や問題点が無いか検証する作業をインスペクションという。

プログラムコードなどの成果物を、その開発工程に直接携わっていない第三者がインスペクタ(inspector)となって読み込み、事前に決められたチェックリストなどに基づいて欠陥や問題がないか精査する。

検証が終わったら司会者(モデレータ)を中心にミーティングを開催し、インスペクタが検証結果を開発者(オーナー)に報告する。インスペクタに数名を指名する場合もあるが、それぞれ一人で独立に作業を行う。

プログラムなどを実際に動作させてみる動的テストと対比して静的テストに分類される。動作するコードができる前の仕様書などの段階で行うことができ、また、動的テストでは検知できない潜在的な問題点を見つけることができる場合がある。静的テスト手法としては他にウォークスルーやピアレビューなどがよく知られている。

変数のインスペクション

プログラムのデバッグツールなどの機能の一つで、実行中のプログラム中の変数などの内容を表示できるようにするものをインスペクションという。

ブレークポイントやステップ実行などと組み合わせ、特定の実行状態において変数の内容がどうなっているか、処理の進行に伴ってどのように変化していくかを監視することができる。

ネットワークのインスペクション

ネットワークの分野では、ネットワークの境界などに設置されたルータなどの装置が、内外を流通するデータ(パケット)を監視することをパケットインスペクション、あるいは略して単にインスペクションという。

パケット内部のデータを解析し、外部からの侵入や攻撃、マルウェア流入などが疑われる不審なパケットを検出すると、破棄したり、相手先からの接続を遮断したり、管理者に通報したりする。

レビュー手法のウォークスルー

システム開発の分野では、開発プロジェクトのメンバーが一堂に会し、仕様や構成の問題点を探したり解決策を討論したりする作業のことをウォークスルーという。

正式なレビューなどとは異なり、必要に応じて短時間開催されるインフォーマルな検討会で、プロジェクトの管理者は参加せずに作業者のみで開かれる場合が多い。特に要件定義や仕様策定、設計などの上流工程で行われることが多い。演劇の分野で話の流れを確認するための立ち稽古や通し稽古から派生した用語とされる。

3DCGのウォークスルー

3次元グラフィックス(3DCG)やバーチャルリアリティ(VR)、ビデオゲームなどの分野では、立体的に描画された建造物や仮想空間を、実際にその中にいる人物の視点で自由に動きまわって眺めることができる表現手法をウォークスルーという。

自由に移動しながら好きな場所を好きな角度から見ることができる。大規模な建築物の設計などで、完成後に内部がどのように見えるかプレゼンテーションする際などに利用されている。

IT業界の場合、仕様書やプログラムコードなどの成果物を、同僚(peer)の技術者が読み込んで検証する活動のことを意味することが多い。レビューを同じプロジェクトのメンバーが行なうことで、互いの知識やノウハウを共有・移転したり、成果物の欠陥や問題点を早期に発見することなどが期待される。

具体的なレビュー手法として様々な方式が提案されており、複数の検証者(レビューア)がチェックリストなどを用いて精査した結果をミーティングで議論する「インスペクション」、本人と評価者が一堂に会してその場で検証や議論を行う「ウォークスルー」、成果物を評価者に送付・回覧して意見を求める「パスアラウンド」などがよく知られる。

科学界・学術界では、学会誌などに投稿された学術論文を同じ分野の別の研究者が検証して掲載可否などを判定する活動を意味し、日本ではピアレビューと外来語では呼ばず伝統的に「査読」という。

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

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

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

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

規模の大きなプログラムを長期間に渡って開発し続けていると、急な仕様変更や機能追加でその場しのぎの継ぎ接ぎが行われた箇所や、柔軟性や拡張性に乏しい設計や構造、無駄な重複、意図の読み取りにくい難解・煩雑な箇所が増えてくる。

そのような場合に、そのまま開発を続行するのではなく、一度立ち止まって既存のコードを見直し、開発者にとって理解のしやすい構造や設計に改める作業をリファクタリングという。機能の追加や不具合の改善などは行わず、内部構造の改善に徹し、あくまで外部から見た振る舞いは変えないのが原則である。

リファクタリングによって開発の進捗そのものは変わらないため、一見、工数が増えて工期が遅れるだけの無駄な作業のように感じられるが、内部がひどく混乱したプログラムの場合、そのままコードの追加・修正を続けるよりも、見通しを良くして作業を再開する方が開発効率や速度が向上し、新規コードの品質向上や新たなバグの抑制を期待できる。

リファクタリングによって挙動が変化したり品質が低下することがないよう入念にテストする必要があり、小刻みにテストを実施できる環境作りが重要となる。また、リファクタリングに失敗しても元の状態に戻すことができるよう、バージョン管理システムなどで変更履歴の把握や管理を適切に行う必要がある。

企業などが他社製品のリバースエンジニアリングによって得られた情報は、類似製品や互換製品の開発、同等の機能の実現などのために利用されることが多いが、自社特許の侵害が無いか調査するといった目的で行われることもある。

ソフトウェアの場合には実行可能形式のプログラムから逆アセンブルや逆コンパイルなどを行って、(不完全な)ソースコードを取得して動作を解析することが多い。他の工業製品の場合と同じように互換製品などを開発するために行われるほか、コンピュータウイルスなどマルウェアの動作を詳細に調べ対策プログラムを開発したり、ソフトウェアの保安上の弱点(脆弱性)を探し出すなどセキュリティ上の目的で行われることも多い。

リバースエンジニアリングを行うこと自体は合法だが、抽出したコンピュータプログラムを丸ごと複製して自社製品に組み込むといった行為は著作権違反、企業秘密(営業秘密)として保護された製法や構造などを割り出して無許諾で模倣した場合は不正競争防止法違反などに問われることがある。

このような権利侵害を避けるため、リバースエンジニアリングを行うチームが外形的な仕様などを記述し、隔離された別のチームが書面を元に同じ働きをする実装方法を独自に考案するという手法が用いられることがある。これをクリーンルーム設計(クリーンルーム手法)という。ただし、この方式では特許権や意匠権の侵害を避けることはできない。

データインテグリティ (data integrity/データ完全性)

データの処理・読み込み・書き込み・保管・転送などに際して、目的のデータが常に揃っていて、内容に誤りや欠けが無いこと(および、それが保証されていること)をデータの完整性という。日本語で「完全性」の訳語が当てられることもある。

データベースにおける正規化や制約の設定などが不十分でデータ間の関係に矛盾が生じたり、装置の障害やソフトウェアのバグによって内容の欠損や変質が起きたり、外部の攻撃者によって改竄されたりすると、完整性が損なわれることになる。

製品が利用者に引き渡され、実際の利用環境で稼働を開始した後に発生した問題や顕在化した欠陥について、これを是正して問題を解消するために行われる修正・更新作業である。誤作動を引き起こすプログラム中のバグの修正などが含まれる。

一方、問題として顕在化する前に潜在的な不具合などを解消する保守作業は「予防保守」、問題が発生したが根本的な対策が困難か時間がかかるため、とりあえず応急処理を施す保守作業は「緊急保守」という。また、仕様が古く新しい外部環境に対応できないなどの問題に対処するための修正は「適応保守」という。

機器の場合、定期的に点検を行い、消耗が起きやすい機器や部品は規定の利用期間や利用回数が経過した時点で正常に稼働していても交換するなどの対応を行う。ソフトウェアの場合、潜在的な不具合を見つけ、障害として顕在化する前に修正することなどを意味する。

交換などのメンテナンスを行う基準として、導入からの経過時間や累積稼働時間などを基準とする方式を「時間基準保全」、装置や部品の劣化や摩耗などの度合い、データ量や累積伝送量など何らかの使用量を基準とする方式を「状態基準保全」という。

予防保守は量的な基準に基づいて一定の間隔で計画的に実施されるが、機器の種類によっては装置の状態を監視し、量的な基準ではなく故障の予兆となる現象や状態を検知して交換などのタイミングを判断する「予知保全」(predictive maintenance)が行われる場合もある。

保守工程は予防保守以外にも様々な分類があり、発見された問題を解決するために行う「是正保守」、利用環境の変化に対応するために行う「適応保守」、性能や保守性を改善するために行われる「完全化保守」、緊急の事態に対応するために行う「緊急保守」などがある。

製品が利用者に引き渡され、稼働を開始した後に、製品を取り巻く環境に変化が起こり、これに適応させるために機能の追加や修正などが必要な場合に行われる保守作業である。

運用基盤のオペレーティングシステム(OS)やミドルウェア、ライブラリなどが更新されて仕様が変更された場合や、連携している外部のネットサービスの仕様が更新された場合、外部とやり取りするデータ形式に変更が必要になった場合、法律や制度が改正されて対応が必要になった場合などに行われる。

なお、利用環境への適応ではなく性能の向上や機能に追加、使い勝手や保守性の改善など、製品を改善し完成度を高める目的で行われる保守作業は「完全化保守」という。保守作業の分類としては他に、不具合への対応や問題の解消のために行われる「予防保守」「是正保守」「緊急保守」などもある。

製品が利用者に引き渡され、実際の利用環境で稼働を開始した後に、何らかの改良を行うために行われる修正・更新作業を完全化保守という。性能の向上、機能の追加や変更、保守性の改善、操作体系の見直しなどが含まれる。

保守工程は完全化保守以外にも様々な分類があり、潜在的な問題点が顕在化する前に解消する「予防保守」、発見された問題を解決するために行う「是正保守」、利用環境の変化に対応するために行う「適応保守」、緊急の事態に対応するために行う「緊急保守」などがある。

メーカーや販売代理店などの保守要員が、顧客が製品を利用している現場に出向き、故障した製品の修理、稼働中の製品の点検、消耗品の交換などの保守作業を行う。利用者は事前に電話や電子メール、Webサイトの入力フォームなどで現況を細かく報告し、日時の交渉などを行う必要がある。

引き取りや交換よりも緊急性を要する場合や、利用者自身には対応できない高い専門性が求められる場合などに利用されることが多い。主に法人向け製品や、家庭向けでも移動が容易でない大型家電(冷蔵庫や洗濯機など)、コンピュータなど専門知識を要する製品で提供されることが多い。

一方、製品を利用者がメーカーなどのサポート拠点に配送し、事業者が修理などを行って送り返す方式を「センドバック保守」という。企業や製品によってはオンサイトかセンドバックを選択できるようになっている場合もあるが、オンサイトの方が料金が高額となるのが一般的である。

サービス拠点に滞在する保守要員がインターネットや専用回線を通じて顧客が運用する機器やシステムにアクセスし、ソフトウェアを操作して装置の状態を診断したり、ソフトウェアのアップデート作業などを行う。顧客の求めに応じてトラブルに対応したり、質問や相談に応じることもある。

スタッフが顧客の施設を訪れなくても遠隔から作業できるため、訪問型のオンサイト保守よりもコスト的に有利なことが多い。顧客からの連絡や監視システムからの通報を受けてすぐに保守作業を開始できるため、スピーディーな対応が可能となる。

サーバなど常時運用するシステムが対象の場合は、遠隔からシステムの常時監視や日常的な運用業務を行うリモート監視、リモート運用などと組み合わせ、総合的な遠隔サポートサービスの一貫として契約することもある。