基本情報技術者試験 用語集 開発技術

スポンサーリンク

スポンサーリンク

Amazon公式サイト

アルゴリズムとデータ構造 ― 基本情報技術者 用語集

アルゴリズムとデータ構造は、基本情報技術者試験で特に重要な分野です。したがって、ここでは探索・整列・再帰といった定番アルゴリズムと、配列・スタック・木構造などの代表的データ構造をまとめて解説します。

データ構造

まず、基本的なデータ構造を押さえておきましょう。それぞれの特性を理解すると、どの場面でどの構造を使うべきか判断できるようになります。さらに、試験では各構造の特徴と計算量がよく問われます。

データ構造

データを効率的に格納・操作するための形式。処理速度やメモリ効率は、適切なデータ構造を選ぶかどうかで大きく変わる。用途に合った構造を選ぶことがプログラミングの基本。 例：配列、リスト、スタック、キュー、木、グラフなど目的に応じて使い分ける

配列

同じ型のデータを連続したメモリ領域に並べて格納するデータ構造。添え字（インデックス）を指定するとO(1)で高速にアクセスできる反面、途中への挿入・削除はデータの移動が必要で遅い。 例：a[0]=10, a[1]=20, a[2]=30 のように添え字で直接アクセス

連結リスト

各要素がデータとポインタ（次の要素への参照）を持ち、鎖のように繋がるデータ構造。挿入・削除がポインタの書換えだけで済むため高速だが、n番目の要素にアクセスするには先頭から順にたどる必要がある。 例：単方向リスト、双方向リスト、循環リスト。メモリの動的確保にも利用

スタック

後入れ先出し（LIFO: Last In First Out）のデータ構造。最後に入れたデータを最初に取り出す。push（追加）とpop（取出し）の2操作が基本で、関数呼出しの管理や「元に戻す」処理に使われる。 例：関数の呼出し履歴管理、Webブラウザの「戻る」ボタン、Ctrl+Zの取消し操作

キュー

先入れ先出し（FIFO: First In First Out）のデータ構造。最初に入れたデータを最初に取り出す。enqueue（追加）とdequeue（取出し）が基本操作で、順番待ちの管理に適している。 例：プリンタの印刷待ち行列、OSのプロセススケジューリング、メッセージキュー

デック（deque）

Double-Ended Queue の略で、両端から出し入れできるデータ構造。スタックとキューの両方の性質を兼ね備える。 例：先頭にも末尾にも追加・削除ができるため、柔軟な待ち行列処理に利用

木構造（ツリー）

データを階層的に表現する構造で、根（ルート）・節（ノード）・葉（リーフ）から構成される。循環がなく、あるノードから子ノードへ枝分かれしていく。ファイルシステムの構造や構文解析で多用される。 例：ディレクトリ構造（/home/user/docs）、組織図、HTMLのDOM

2分木

各ノードが最大2つの子（左の子・右の子）を持つ木構造。データの探索や式の表現に適している。完全2分木では葉以外のすべてのノードが2つの子を持つ。 例：算術式「(3+5)*2」を2分木で表現し、後順走査で逆ポーランド記法に変換

2分探索木

「左の子＜親＜右の子」という大小関係を常に保つ2分木。この規則により、探索・挿入・削除が平均O(log n)で行える。偏りが大きいと性能が低下するため、AVL木やB木で平衡を保つ工夫がある。 例：1万件のデータから目的の値を約14回の比較で発見できる

ヒープ

「親が常に子以上（最大ヒープ）」または「親が常に子以下（最小ヒープ）」を満たす完全2分木。最大値や最小値をO(1)で取り出せるため、優先度付きキューの実装に使われる。 例：タスクの優先度管理、ヒープソートの基盤データ構造

ハッシュテーブル

キーをハッシュ関数で変換し、その結果をインデックスとしてデータを格納する構造。理想的にはO(1)でデータを検索できるが、異なるキーが同じ位置に割り当てられる「衝突」への対策（チェイン法、オープンアドレス法）が必要。 例：Pythonの辞書（dict）、JavaのHashMap、データベースのインデックス

グラフ（データ構造）

頂点（ノード）と辺（エッジ）で構成され、要素間の関係を表すデータ構造。有向・無向、重み付き・なしなどの種類がある。最短経路問題やネットワーク分析で幅広く使われる。 例：鉄道路線図、SNSの友達関係、Webページのリンク構造

探索アルゴリズム

次に、探索アルゴリズムを見ていきます。たとえば、線形探索と2分探索では計算量が大きく異なります。したがって、データの特性に合わせた探索方法を選ぶことが重要です。

線形探索（リニアサーチ）

データの先頭から順に1つずつ比較して目的の値を探す最も単純な探索方法。データが整列されている必要はないが、n件のデータに対し平均n/2回、最悪n回の比較が必要で効率はO(n)。 例：100件のリストで50番目にあるデータを見つけるには平均50回の比較

2分探索（バイナリサーチ）

整列済みデータの中央値と目的値を比較し、大小に応じて探索範囲を半分に絞ることを繰り返す方法。毎回半分になるためO(log n)と非常に高速だが、データが事前にソートされている必要がある。 例：100万件の整列済みデータでも約20回の比較で発見可能

ハッシュ探索

ハッシュ関数で計算した格納位置を直接参照する探索方法。理想的にはO(1)の定数時間で見つかるが、衝突が多いと性能が低下する。大量データからの高速検索に向いている。 例：辞書型データ構造やデータベースインデックスの内部で利用

深さ優先探索（DFS）

Depth First Search。グラフや木をできるだけ深く進み、行き止まりになったら戻って別の枝を探索する方法。スタックや再帰で実装する。全経路の列挙やバックトラックに向いている。 例：迷路探索、パズルの全解列挙、トポロジカルソート

幅優先探索（BFS）

Breadth First Search。始点に近いノードから順に広げていく探索方法。キューで実装する。重みなしグラフでの最短経路を求めるのに適している。 例：SNSの「友達の友達」検索、迷路の最短ルート探索

整列アルゴリズム

整列（ソート）アルゴリズムは試験で頻出です。また、それぞれの計算量と安定性の違いを理解しておくことが大切です。一方、実務ではクイックソートやマージソートが特によく使われます。

バブルソート

隣接する2つの要素を比較し、順序が逆なら交換する操作を繰り返して整列する方法。計算量はO(n²)で大規模データには不向きだが、アルゴリズムが単純で理解しやすいため学習用途で広く使われる。 例：[5,3,8,1]→隣同士を比較交換→[1,3,5,8]に整列

選択ソート

未整列部分から最小（または最大）の要素を選び、先頭から順に確定していく整列法。計算量はO(n²)で、データの初期状態に関係なく常に同じ比較回数がかかる。 例：[5,3,8,1]→最小の1を選んで先頭へ→[1,3,5,8]

挿入ソート

整列済みの部分列に、新しい要素を正しい位置に差し込んでいく方法。ほぼ整列済みのデータではO(n)に近い速度で動く利点があるが、最悪はO(n²)。 例：トランプの手札を小さい順に並べ替える操作と同じ原理

クイックソート

基準値（ピボット）を選び、それより小さい要素と大きい要素に分割して再帰的に整列する方法。平均計算量O(n log n)で実用上最速の整列法の一つだが、最悪ケース（すでに整列済み等）ではO(n²)に劣化する。 例：多くのプログラミング言語のソート関数の内部実装に採用されている

マージソート

データを半分に分割し、各部分を整列してから併合（マージ）する方法。分割統治法に基づき、常にO(n log n)の安定した性能を持つ。安定ソートである点も利点。追加メモリが必要。 例：大規模データの外部ソート（ディスク上の整列）にも利用される

ヒープソート

ヒープ構造を利用して整列する方法。最大（最小）値をヒープの先頭から取り出し確定させる操作を繰り返す。計算量は常にO(n log n)で追加メモリもほぼ不要だが、安定ソートではない。 例：メモリ効率が重要な場面で選択される整列法

シェルソート

一定間隔でグループ分けして挿入ソートを行い、間隔を徐々に縮めていく方法。挿入ソートの改良版で、離れた要素を早期に正しい位置へ近づけることで効率を上げている。 例：間隔を8→4→2→1と縮めながら挿入ソートを繰り返す

計算量・再帰・アルゴリズム設計

アルゴリズムを評価するには計算量の概念が不可欠です。さらに、再帰や動的計画法などの設計手法を理解することで、複雑な問題を効率よく解けるようになります。つまり、この知識はアルゴリズム設計の核心といえます。

計算量（オーダ）

アルゴリズムがデータ量nに対してどれだけの時間や空間を使うかを示す指標。O記法（ビッグオー記法）で表し、定数倍は無視してデータ量に対する増加傾向を示す。アルゴリズム選択の重要な基準。 例：O(1)定数＜O(log n)対数＜O(n)線形＜O(n log n)＜O(n²)二乗＜O(2ⁿ)指数

再帰

関数が処理の中で自分自身を呼び出す手法。問題を同じ構造の小さな部分問題に分解して解く場合に使う。必ず終了条件（基底条件）を設けないと無限再帰になる。 例：階乗 n!=n×(n-1)!、フィボナッチ数列、木構造の全ノード走査

動的計画法

部分問題の計算結果を表に保存し、同じ計算を繰り返さないことで効率化する手法。再帰的に解くと指数的に遅くなる問題を多項式時間で解ける場合がある。 例：フィボナッチ数の高速計算、ナップサック問題、最短経路問題

分割統治法

問題を小さな部分問題に分割し、各々を解いてから結果を統合する手法。再帰的な構造を持つ問題に有効。 例：マージソート、クイックソート、二分探索

貪欲法（グリーディ法）

各段階で局所的に最善の選択を繰り返し、全体の解を求める手法。常に最適解が得られるとは限らないが、特定の問題では最適解が保証される。 例：両替問題（大きな硬貨から使う）、ダイクストラ法、ハフマン符号

バックトラック

解の候補を試し、制約に違反したら直前の状態に戻って別の選択肢を試す手法。探索空間が大きい問題で、無駄な枝を早期に打ち切る「枝刈り」と組み合わせることが多い。 例：迷路探索、8クイーン問題、数独の解法

プログラミング ― 基本情報技術者 用語集

プログラミング分野では、言語の分類からコンパイラの仕組み、さらにオブジェクト指向やWeb技術まで幅広い用語が出題されます。そのため、この基本情報技術者 用語集では言語処理系の流れやオブジェクト指向の三大要素も丁寧に解説しています。

プログラミング言語の分類

プログラミング言語はその特性によっていくつかの種類に分類されます。たとえば、手続き型とオブジェクト指向型では設計の考え方が大きく異なります。したがって、各分類の特徴を理解しておくと、言語選択の判断基準になります。

プログラミング言語

コンピュータに処理を指示するための形式言語。目的や分野に応じて多数の言語が存在し、低水準言語（機械語に近い）から高水準言語（人間の言葉に近い）まで抽象度が異なる。 例：C、Java、Python、JavaScript、Ruby、Go、Rust

低水準言語

機械語やアセンブリ言語など、ハードウェアに近いレベルで記述する言語。実行速度やメモリの細かい制御が可能だが、人間にとって読み書きしにくい。 例：機械語（0と1のビット列）、アセンブリ言語（MOV, ADD等の命令）

高水準言語

人間が読みやすい形式で記述でき、コンパイラやインタプリタを通じて実行するプログラミング言語。ハードウェアの詳細を意識せずにプログラムを書ける。 例：C、Java、Python、Ruby など、現在主流の言語はほぼ全て高水準言語

手続き型言語

処理手順を上から順に記述していくスタイルの言語。命令を順番に実行する直感的な考え方で、制御構造（順次・分岐・反復）を基本とする。 例：C言語、COBOL、Pascal、FORTRAN

オブジェクト指向言語

データ（属性）と処理（メソッド）をオブジェクトとしてまとめ、その組合せでプログラムを構築する言語。大規模開発での再利用性や保守性に優れる。 例：Java、C++、Python、Ruby、C#

関数型言語

関数の定義と合成でプログラムを表現する言語。状態変更（副作用）を避けることで、テストしやすくバグの少ないコードが書きやすい特徴がある。 例：Haskell、Lisp、Erlang、Scala。JavaScriptやPythonも関数型の要素を持つ

スクリプト言語

コンパイル不要で記述したコードをそのまま実行できる言語の総称。開発の手軽さと書きやすさが特徴で、Web開発やデータ処理に広く使われる。 例：Python、JavaScript、PHP、Ruby、Perl

マークアップ言語

文書の構造や意味をタグで記述する言語。プログラミング言語とは異なり、処理の指示ではなくデータの構造記述が目的。 例：HTML（Webページ構造）、XML（データ交換）、Markdown（文書記述）

言語処理系

言語処理系とは、ソースコードを実行可能な形式に変換する仕組みのことです。また、コンパイラとインタプリタの違いは試験でも重要なテーマです。さらに、字句解析から最適化までのコンパイル工程を順に理解しておきましょう。

コンパイラ

ソースコード全体をまとめて機械語に変換（翻訳）するプログラム。実行前に変換が必要だが、実行速度が速い。変換時にエラーを一括検出できる利点もある。 例：gcc（C言語）、javac（Java→バイトコード）

インタプリタ

ソースコードを1行ずつ解釈しながら逐次実行する方式。コンパイル不要で即座に動作確認できるが、実行速度はコンパイラ方式より遅い傾向がある。 例：Pythonの対話モード、JavaScriptのブラウザ実行、Rubyの実行

JITコンパイル

Just-In-Timeの略。プログラムの実行直前に機械語にコンパイルすることで、インタプリタの柔軟さとコンパイラの実行速度を両立する方式。 例：Java仮想マシン（JVM）、.NET CLR、JavaScriptのV8エンジン

リンカ

コンパイル済みの複数のオブジェクトファイルやライブラリを結合し、実行可能ファイルを生成するツール。外部関数の参照を解決し、一つの実行ファイルにまとめる。 例：複数の.oファイルと標準ライブラリを結合して実行ファイルを生成

ローダ

実行ファイルをディスクから主記憶（メモリ）に読み込み、実行可能な状態にするプログラム。OSの一部として動作する。 例：プログラム起動時にOSがローダを使ってメモリ上に配置

字句解析

コンパイルの最初の段階で、ソースコードを意味のある最小単位（トークン）に分割する処理。空白やコメントを除去し、キーワード・識別子・演算子などに分類する。 例：「int x = 10;」→「int」「x」「=」「10」「;」の5つのトークンに分解

構文解析

字句解析で得たトークン列を文法規則に照らして解析し、構文木（パースツリー）を作成する処理。文法エラーはここで検出される。 例：「a = b + c * d;」を演算子の優先順位に従って木構造に変換

意味解析

構文木が意味的に正しいかを確認する処理。型の整合性チェックや変数の未定義参照の検出などを行う。 例：文字列型の変数に整数を代入しようとしていないかチェック

最適化

生成されるコードの実行速度やサイズを改善する処理。不要な計算の除去、ループの効率化、定数の事前計算などを行う。 例：定数畳み込み（3+5を8に置換）、ループ展開、不要コード除去

オブジェクト指向

オブジェクト指向は現代のソフトウェア開発の中心的な考え方です。とくに、カプセル化・継承・多態性の三大要素は基本情報技術者試験でも頻出です。したがって、それぞれの概念と具体例をしっかり押さえておきましょう。

オブジェクト指向

データ（属性）と処理（メソッド）を「オブジェクト」としてひとまとめにし、オブジェクトの協調で動作するソフトウェアを構築する設計思想。カプセル化・継承・多態性が3大要素。 例：「車」オブジェクトに「速度」「色」というデータと「走る」「止まる」という処理をまとめる

クラス

オブジェクトの設計図にあたるもの。属性（フィールド）とメソッドを定義し、ここからインスタンス（実体）を生成する。同じクラスから何個でもインスタンスを作れる。 例：「Dogクラス」の定義から「ポチ」「タロウ」といった個別のインスタンスを生成

インスタンス

クラスから実際に生成されたオブジェクト（実体）。各インスタンスは独立した属性値を持つ。 例：Dogクラスから生成した「ポチ（体重5kg）」と「タロウ（体重8kg）」は別のインスタンス

カプセル化

データとメソッドを1つにまとめ、内部の詳細を隠蔽して外部からの直接アクセスを制限する仕組み。public/private等のアクセス修飾子で制御する。変更の影響を最小限に抑え、保守性が向上する。 例：銀行口座の残高を直接書き換え不可にし、入金・出金メソッド経由のみ許可

継承（インヘリタンス）

既存のクラス（親クラス）の属性やメソッドを引き継いで新しいクラス（子クラス）を作る仕組み。共通部分の再利用ができ、差分だけを追加・変更すればよい。 例：「動物クラス」を継承して「犬クラス」「猫クラス」を作り、各々に固有の振る舞いを追加

多態性（ポリモーフィズム）

同じメソッド名の呼出しで、オブジェクトの型に応じて異なる処理が実行される性質。プログラムの柔軟性と拡張性が高まる。 例：「鳴く()」メソッドが犬なら「ワン」、猫なら「ニャー」と動作を変える

抽象クラス

インスタンス化できず、子クラスへの共通の枠組みを提供するためのクラス。一部のメソッドの実装を子クラスに強制できる。 例：「図形」抽象クラスで「面積を求める」メソッドを宣言し、「円」「四角形」で実装

インタフェース

クラスが備えるべきメソッドの仕様（名前・引数・戻り値の型）だけを定めたもの。実装は含まない。多重継承の代わりに、複数のインタフェースを実装できる言語が多い。 例：Javaの Comparable インタフェースを実装するとソート可能なクラスになる

オーバーロード

同じメソッド名で引数の数や型が異なる複数のメソッドを定義すること。コンパイル時に引数の型で呼び分けられる。 例：add(int, int) と add(double, double) を同じクラスに定義

オーバーライド

親クラスのメソッドを子クラスで再定義（上書き）すること。多態性の実現に不可欠な仕組み。 例：「動物.鳴く()→デフォルト音」を「犬.鳴く()→ワン」で上書き

プログラミング基本要素

プログラムを記述するうえで欠かせない基本要素を確認します。たとえば、変数・制御構造・関数はすべての言語に共通する概念です。また、スコープや例外処理を理解することで、より品質の高いコードが書けるようになります。

変数

値を格納する名前付きの記憶領域。プログラム実行中に値を読み書きできる。宣言時にデータ型を指定する言語（静的型付け）と推論に任せる言語（動的型付け）がある。 例：int age = 30;（整数型の変数 age に30を代入）

制御構造

プログラムの実行順序を制御する仕組みで、「順次」「選択（分岐）」「反復（繰返し）」の3つが基本。この3構造の組合せであらゆる処理を表現できる（構造化定理）。 例：上から順に（順次）、条件分岐（if-else）、繰返し（for, while）

関数（メソッド）

一連の処理をまとめて名前を付け、再利用できるようにしたもの。引数で値を受け取り、戻り値で結果を返す。プログラムの部品化・再利用の基本単位。 例：function add(a, b) { return a + b; }（aとbを足して返す関数）

スコープ

変数や関数が参照できる有効範囲。ローカルスコープ（関数内）とグローバルスコープ（プログラム全体）がある。スコープを適切に設計することでバグを減らせる。 例：関数内で宣言した変数は関数外から参照できない

例外処理

プログラム実行中に発生する予期しないエラー（例外）を捕捉し、安全に処理する仕組み。try-catch構文が代表的。例外処理を適切に実装することでプログラムの異常終了を防げる。 例：ファイルが見つからない場合に例外をキャッチしてエラーメッセージ表示

Web技術

Web開発に関連する技術用語もしっかり押さえておく必要があります。たとえば、HTML・CSS・JavaScriptの役割の違いは基本中の基本です。さらに、REST APIやAjaxなどの概念は現代のWebアプリ開発で不可欠です。

HTML

HyperText Markup Language。Webページの構造（見出し、段落、リスト、リンク等）をタグで記述する言語。ブラウザがHTMLを解釈してページを描画する。 例：<h1>見出し</h1>、<a href="...">リンク</a>

CSS

Cascading Style Sheets。Webページの見た目（色、サイズ、レイアウト等）を指定するスタイルシート言語。HTMLと分離してデザインを管理できる。 例：color: red; font-size: 16px;で文字色とサイズを指定

JavaScript

Webブラウザ上で動的な処理を実現する代表的なプログラミング言語。ボタンクリック時の処理や画面更新など、ユーザ操作への応答に使われる。Node.jsによりサーバ側でも利用。 例：ボタンクリックでメッセージ表示、入力値のリアルタイム検証

JSON

JavaScript Object Notation。軽量なデータ交換形式で、キーと値のペアでデータを表す。人間にも読みやすく、Web APIのデータ形式として広く普及している。 例：{"name": "田中", "age": 30, "skills": ["Java", "Python"]}

REST API

HTTPプロトコルのメソッド（GET/POST/PUT/DELETE）でリソースを操作するWeb APIの設計スタイル。URLでリソースを指定し、HTTPメソッドで操作を表す。シンプルで広く普及。 例：GET /users（一覧取得）、POST /users（新規作成）、DELETE /users/1（削除）

Ajax

Asynchronous JavaScript and XML。ページ全体を再読込せず、バックグラウンドでサーバと非同期通信し部分的に画面を更新する技術。Webアプリの操作性を大幅に向上させた。 例：Googleマップのスクロール更新、メールの新着通知、検索候補の即時表示

フレームワーク

アプリケーション開発の骨格（ひな形）を提供する再利用可能なソフトウェア基盤。規約に従って開発することで、高品質なソフトを効率的に構築できる。 例：Spring Boot（Java）、Django（Python）、React/Vue.js（JavaScript）

ライブラリ

特定の機能を実現する再利用可能なプログラム部品の集まり。フレームワークと異なり、開発者が主体的に呼び出して使う。 例：NumPy（Python数値計算）、jQuery（JavaScript DOM操作）、Lodash（ユーティリティ）

開発プロセス・手法 ― 基本情報技術者 用語集

開発プロセスの選択はプロジェクトの成否を左右します。たとえば、ウォーターフォールとアジャイルの違いは基本情報技術者試験の頻出テーマです。また、DevOpsやCI/CDなど近年注目される手法もここで押さえておきましょう。

開発モデル

開発モデルとは、ソフトウェアを作るための進め方のことです。たとえば、ウォーターフォールとアジャイルでは開発の流れが大きく異なります。したがって、プロジェクトの特性に合ったモデルを選ぶことが重要です。

ウォーターフォールモデル

要件定義→設計→実装→テストと各工程を順番に進める伝統的な開発モデル。前工程の成果物を次の工程の入力とし、原則として前工程には戻らない。大規模システムや要件が明確な案件に向いている。 例：政府系大型システム、基幹業務システムで広く採用

プロトタイプモデル

早い段階で試作品（プロトタイプ）を作成し、利用者に実際に操作してもらいフィードバックを得ながら開発を進める手法。要件が曖昧な場合に有効。 例：UI画面のモックアップを先に作り、利用者の意見を反映して修正

スパイラルモデル

計画→リスク分析→開発→評価のサイクルを螺旋（スパイラル）状に繰り返し、徐々に完成度を高めるモデル。各サイクルでリスクを評価するため、リスク管理に優れる。 例：リスクの高い機能から着手し、サイクルごとに品質を向上

インクリメンタルモデル

システムを機能単位に分割し、段階的にリリースしていく手法。最初にMVP（最小限の製品）を出して順次機能追加することで、早期に利用者の手に届けられる。 例：第1リリースでログイン機能、第2リリースで検索機能と順次拡張

アジャイル開発

アジャイル開発は、変化に柔軟に対応するための手法として広まっています。とくに、スクラムやXPといったフレームワークは試験にもよく登場します。また、スプリント・バックログ・レトロスペクティブなどの用語も確認しておきましょう。

アジャイル開発

短期間（1〜4週間）の反復（イテレーション）で設計〜テストを繰り返し、変化に柔軟に対応する開発手法の総称。2001年の「アジャイルソフトウェア開発宣言」で理念が示された。 例：「プロセスよりも個人と対話」「契約交渉よりも顧客との協調」など4つの価値を重視

スクラム

アジャイル開発の代表的フレームワーク。プロダクトオーナー（要求の優先順位決定）、スクラムマスター（プロセスの促進・障害除去）、開発チームの3つの役割で運営する。 例：スプリント計画→日次スクラム→スプリントレビュー→レトロスペクティブのサイクル

スプリント

スクラムにおける開発の単位期間。通常1〜4週間の固定長で、この間に計画・設計・実装・テストを行い、動作するソフトウェアを完成させる。 例：2週間スプリントで「ユーザ登録機能」を設計からテストまで完了

プロダクトバックログ

製品に対する要望や改善項目を優先度順に並べたリスト。プロダクトオーナーが管理し、常にビジネス価値の高いものが上位に来るよう整理する。 例：「決済機能追加（優先度：高）」「デザイン改善（優先度：中）」などのリスト

デイリースクラム

毎日15分程度で行う短いミーティング。各メンバーが「昨日やったこと」「今日やること」「困っていること」を共有し、チーム全体で進捗と課題を確認する。 例：朝9時に立ったまま15分。課題は別途解決の場を設ける

レトロスペクティブ（振り返り）

スプリント終了後にチームで振り返りを行い、プロセスの改善点を議論する会議。次のスプリントでの改善アクションを決める。 例：KPT（Keep=良かった点/Problem=問題/Try=次に試すこと）で整理

XP（エクストリームプログラミング）

少人数チーム向けのアジャイル開発手法。ペアプログラミング、テスト駆動開発、継続的インテグレーション、リファクタリングなどのプラクティスを組み合わせる。 例：常にペアで開発、テストを先に書いてから実装する

ペアプログラミング

2人で1台のPCを使って共同で開発する手法。1人がコードを書き（ドライバ）、もう1人がリアルタイムでレビュー（ナビゲータ）しながら随時交代する。品質向上と知識共有に効果的。 例：経験者と初心者のペアで技術移転を促進

テスト駆動開発（TDD）

Test Driven Development。まず失敗するテストコードを書き、テストを通すための最小限の実装をし、その後リファクタリングするサイクルを繰り返す手法。 例：Red（失敗テスト）→Green（実装して成功）→Refactor（整理）のサイクル

リファクタリング

外部から見た動作（入出力）を変えずに、コードの内部構造を改善する作業。可読性、保守性、拡張性を向上させる。テストがあることで安全に行える。 例：重複コードの共通関数化、長すぎるメソッドの分割

カンバン

作業をカード化してボード上に「To Do → Doing → Done」と可視化し、流れを管理する手法。作業中（WIP）の上限を設けて渋滞を防ぐことが特徴。 例：Trello、Jiraのボードビューで日常的に利用されている

DevOps・継続的開発

DevOpsは開発と運用の連携を深める考え方です。さらに、CI/CDの導入によってリリースサイクルを大幅に短縮できます。つまり、現代のソフトウェア開発ではDevOpsの概念を理解しておくことが不可欠です。

DevOps

開発（Development）と運用（Operations）を密に連携・統合し、ソフトウェアの開発からリリースまでのサイクルを高速化する取組み。自動化とコミュニケーション改善が中核。 例：開発者が運用まで責任を持ち、ツールと文化の両面で改善

CI（継続的インテグレーション）

Continuous Integration。開発者が変更したコードを頻繁に共有リポジトリに統合し、自動でビルドとテストを実行する手法。統合時の問題を早期に発見できる。 例：GitHubへのpushごとにJenkins/GitHub Actionsで自動テスト

CD（継続的デリバリ／デプロイ）

Continuous Delivery/Deployment。テスト済みのコードを自動的に本番環境へリリースできる状態にする（デリバリ）、または自動で本番へ反映する（デプロイ）手法。 例：mainブランチへのマージで自動的にステージング→本番へ反映

Git

分散型バージョン管理システム。ソースコードの変更履歴を記録し、複数人での並行開発を可能にする。現代のソフトウェア開発では事実上の標準。 例：GitHub、GitLab、Bitbucketと組み合わせてチーム開発

ブランチ

並行して別の作業を進めるために、ソースコードの履歴を分岐させる仕組み。機能追加やバグ修正を独立して進め、完了後にメインに統合（マージ）する。 例：mainブランチ（本番）、developブランチ（開発）、feature/login（機能別）

プルリクエスト

ブランチの変更内容をメインブランチに統合する前に、チームメンバーにレビューを依頼する仕組み。コード品質を維持するための重要なプロセス。 例：GitHubのPRで差分を確認、コメントでフィードバックし承認後にマージ

要件定義・設計 ― 基本情報技術者 用語集

要件定義と設計は、開発の上流工程にあたります。とくに機能要件・非機能要件の違いや、UMLの各種ダイアグラムは基本情報技術者試験で繰り返し出題されるため、しっかり整理しておくことが大切です。

要件定義

要件定義は開発の成否を左右する最も重要な工程のひとつです。とくに、機能要件と非機能要件の違いを正確に理解しておく必要があります。また、RFPやヒアリングなどの手法も基本情報技術者試験で問われます。

要件定義

システムが実現すべき要件を明確にする工程。利用者や関係者から要望を聞き出し、機能要件・非機能要件・業務要件として文書化する。開発の成否を左右する最重要工程とされる。 例：「会員登録、商品検索、カート、決済」が機能要件、「応答3秒以内」が非機能要件

機能要件

システムが提供すべき具体的な機能に関する要件。「何ができるか」を定義する。 例：会員登録機能、商品検索機能、決済機能、メール通知機能

非機能要件

性能、可用性、セキュリティ、拡張性など、機能以外のシステム品質に関する要件。「どれだけ上手くできるか」を定義する。 例：応答時間3秒以内、稼働率99.9%、同時1万ユーザ対応、個人情報暗号化

RFP（提案依頼書）

Request For Proposal。発注者がベンダに対し、システムの要件を提示して提案（技術・費用・体制等）を求める公式文書。ベンダ選定の基礎資料となる。 例：「要件概要、制約条件、評価基準」を記載しベンダ各社に送付

設計工程

設計工程では、要件を具体的な実装仕様に落とし込みます。たとえば、基本設計と詳細設計では対象読者と記述レベルが異なります。さらに、モジュール強度や結合度は設計品質を評価するための重要な指標です。

基本設計（外部設計）

利用者から見た仕様を決める設計段階。画面レイアウト、帳票、機能構成、外部システムとの連携仕様などを定義する。「何を作るか」をユーザ視点で決める。 例：画面遷移図、帳票レイアウト、機能一覧、インタフェース仕様書

詳細設計（内部設計）

プログラムの内部構造を決める設計段階。モジュール構造、アルゴリズム、データベースの物理設計などを定義する。「どう作るか」を開発者視点で決める。 例：モジュール構成図、処理フロー、テーブル定義書、クラス設計

モジュール強度

モジュール内の要素がどれだけ関連しているかの指標。強度が高い（=1つの機能に集中している）ほど良い設計。機能的強度（最良）→暗号的強度（最悪）の7段階がある。 例：「消費税計算」だけを行うモジュール（機能的強度）が最も良い設計

モジュール結合度

モジュール間の依存の強さの指標。結合度が低い（=依存が少ない）ほど良い設計。データ結合（最良）→内容結合（最悪）の6段階がある。 例：引数でデータだけを渡す「データ結合」が最も良い設計

UML・設計図

UMLはソフトウェア設計を図で表現するための標準的な記法です。また、クラス図・シーケンス図・ユースケース図などの種類をそれぞれの目的とともに把握しておくことが大切です。したがって、図の種類と用途の対応関係を整理しておきましょう。

UML

Unified Modeling Language。ソフトウェアの構造や振る舞いを図式化する国際標準の記法。13種類の図があり、目的に応じて使い分ける。オブジェクト指向開発で広く使われる。 例：クラス図（構造）、シーケンス図（動作）、ユースケース図（要件）

クラス図

クラスの属性・メソッドと、クラス間の関係（継承、関連、依存等）を表すUMLの構造図。設計段階でシステムの静的構造を可視化する。 例：「顧客」クラスと「注文」クラスの1対多の関連を線と数字で表現

シーケンス図

オブジェクト間のメッセージのやり取りを時系列で表す図。縦軸が時間、横軸がオブジェクトで、処理の順序と相互作用が一目で分かる。 例：ユーザ→ログイン画面→認証サーバ→DBの順にメッセージが流れる様子を記述

ユースケース図

システムが提供する機能と利用者（アクタ）の関係を大まかに示す図。要件定義の初期段階で「誰が何をするか」を関係者間で共有するのに使う。 例：「顧客が商品を検索する」「管理者が在庫を更新する」を楕円と人形で表現

状態遷移図

オブジェクトが取り得る状態と、イベントによる状態変化を表す図。注文の処理フローやシステムのモード遷移を記述するのに適している。 例：注文の「受付→決済待ち→発送準備→発送済→完了」の遷移を矢印で記述

DFD（データフロー図）

Data Flow Diagram。データの流れを「プロセス」「データストア」「外部実体」「データフロー」の4要素で表す図。システムの入出力と処理の関係を可視化する。 例：「顧客」→注文データ→「受注処理」→在庫データ→「在庫DB」の流れを記述

フローチャート（流れ図）

処理の流れを「処理（長方形）」「判断（ひし形）」「端子（楕円）」「矢印」などの記号で表す古典的な図。アルゴリズムの可視化やプログラム設計に使われる。 例：「開始→入力→判断→処理A/処理B→出力→終了」の流れを図で記述

デザインパターン

デザインパターンは、設計上の定番問題に対する再利用可能な解法です。たとえば、MVCやシングルトンは実務でも頻繁に使われます。一方、GoFの23パターンすべてを暗記する必要はなく、試験頻出のパターンを重点的に理解しておきましょう。

デザインパターン

ソフトウェア設計で頻繁に現れる問題に対する再利用可能な解法をパターン化したもの。GoF（Gang of Four）による23パターンが有名。 例：生成パターン（Factory, Singleton）、構造（Adapter）、振る舞い（Observer）

MVC

Model（データ・ビジネスロジック）、View（画面表示）、Controller（入力の受付と制御）の3つに分離するアーキテクチャパターン。役割分担により保守性と拡張性が向上する。 例：Ruby on Rails、Spring MVC、Laravel など多くのWebフレームワークで採用

テスト ― 基本情報技術者 用語集

テストはソフトウェア品質を保証するための重要な工程です。基本情報技術者試験では、ホワイトボックス／ブラックボックスの違いや、単体テストからシステムテストまでの工程を問う問題が多く出ます。さらに、スタブやドライバの役割も頻出です。

テストの工程

テスト工程は設計工程に対応する形で段階的に進めます。たとえば、単体テスト・結合テスト・システムテストはそれぞれ異なる目的を持ちます。また、受入テストや回帰テストの役割も正確に理解しておく必要があります。

単体テスト

プログラムの最小単位（関数・メソッド・モジュール）を個別に検証するテスト。他のモジュールから切り離して動作確認する。詳細設計に対応する工程。 例：JUnit（Java）、pytest（Python）でメソッド単位のテストコードを実行

結合テスト

複数のモジュールを組み合わせてインタフェースや連携が正しく動くか検証するテスト。基本設計に対応する工程。 例：認証モジュールとユーザ管理モジュールを繋いでログインからユーザ情報取得までを確認

システムテスト（総合テスト）

システム全体として要件（機能・非機能）を満たしているか検証するテスト。要件定義に対応する工程。本番と同等の環境で実施する。 例：全機能の動作確認、性能テスト（同時1万ユーザ）、セキュリティテスト

受入テスト

発注者（利用者）が成果物を確認し、契約上の要件を満たしているか判定するテスト。合格すれば検収（納品完了）となる。 例：発注者が実際に操作して「仕様通りに動くか」を確認

回帰テスト（リグレッションテスト）

バグ修正や機能追加の後に、既存機能が壊れていないか確認するテスト。変更による意図しない影響（デグレード）を検出する。自動テストと相性が良い。 例：修正後にCI上で全テストを自動実行し、既存機能の正常動作を確認

テスト技法

テスト技法とは、テストケースを効率よく設計するための手法のことです。たとえば、同値分割と限界値分析を組み合わせることで、少ないテストケースで高い網羅率を達成できます。また、ホワイトボックスとブラックボックスでは着眼点が大きく異なります。

ホワイトボックステスト

プログラムの内部構造（コード）を把握した上で行うテスト。すべての命令や分岐が実行されるようテストケースを設計する。単体テストで主に使われる。 例：if文のtrue/falseの両方を通るテストケースを作成

ブラックボックステスト

プログラムの内部構造を見ず、仕様（入力と出力の関係）だけに基づいて行うテスト。「正しい入力で正しい出力が得られるか」を検証する。 例：仕様書の「年齢は0〜150の整数」に対し、有効値・無効値・境界値でテスト

命令網羅（C0）

すべての命令文を最低1回は実行するテスト基準。最も緩い網羅基準。 例：if文の中のコードも含めてすべての行を通るテストケース

分岐網羅（C1）

すべての分岐（if文のtrue/false等）を最低1回は実行するテスト基準。命令網羅より厳密で、実務でよく使われる水準。 例：if (a>0 && b>0) の真と偽を両方テストする

同値分割

入力値を同じ結果になるグループ（同値クラス）に分け、各グループから代表値を1つ選んでテストする手法。テストケース数を効率的に絞れる。 例：「0〜100点（有効）」と「それ以外（無効）」に分け、各1つの代表値でテスト

限界値分析

境界値（有効範囲の端）とその直前直後の値でテストする手法。バグは境界付近に集中するため、同値分割と併用して効果が高い。 例：「0〜100点」なら-1, 0, 100, 101の4値でテスト

テスト結合方式・補助

結合テストの進め方にはいくつかの方式があります。たとえば、トップダウンとボトムアップでは使う補助部品が異なります。したがって、スタブとドライバのどちらを使うかは結合の方向によって決まります。

トップダウンテスト

上位モジュールから順にテストし、未完成の下位モジュールは「スタブ」で代替する結合テスト方式。上位の制御ロジックを先に検証できる。 例：メイン処理を先にテストし、DB接続モジュールは固定値を返すスタブで代替

ボトムアップテスト

下位モジュールから順にテストし、未完成の上位モジュールは「ドライバ」で代替する結合テスト方式。基本的な部品の品質を先に確保できる。 例：計算ライブラリを先にテストし、呼出し側はテスト用ドライバで代替

スタブ

トップダウンテストで使う仮の下位モジュール。呼ばれたら固定値を返すだけの簡易的なプログラム。 例：DB接続モジュールのスタブ：常に「{“name”:”テスト”}」を返す

ドライバ

ボトムアップテストで使う仮の上位モジュール。テスト対象の下位モジュールを呼び出すための簡易プログラム。 例：テスト用ドライバから計算モジュールに値を渡し結果を表示する

カバレッジ

テストで実行されたコードの割合を示す指標。命令網羅率、分岐網羅率などがある。品質基準としてカバレッジの目標値を設定することが多い。 例：「コードカバレッジ80%以上」「分岐カバレッジ100%」を品質目標に設定

レビュー

レビューはテストの前段階として成果物の品質を高める活動です。また、ウォークスルーとインスペクションでは主催者や形式が異なります。一方、コードレビューはアジャイル開発でも日常的に行われる重要なプラクティスです。

レビュー

成果物（設計書、コード等）を関係者が検証し、欠陥や改善点を見つける活動。テスト前に品質を向上させる重要な工程。 例：設計書レビュー、コードレビュー、仕様書のウォークスルー

ウォークスルー

作成者が主導で内容を順に説明し、参加者から意見や指摘をもらう非公式なレビュー手法。 例：設計者が設計書の内容を説明しながらメンバーの指摘を収集

インスペクション

第三者（モデレータ）が主催し、チェックリストに基づいて体系的に欠陥を検出する公式なレビュー手法。最も厳密で欠陥検出率が高い。 例：チェックリストに沿って設計書を1項目ずつ確認し指摘を記録

運用・保守 ― 基本情報技術者 用語集

運用・保守は、システム稼働後に長く続くフェーズです。基本情報技術者試験では、4種類の保守（是正・適応・完全化・予防）の違いや、移行方式の選択について問われることがあります。

保守の種類

システムの保守にはいくつかの種類があります。たとえば、是正保守はバグ修正、適応保守は環境変化への対応です。一方、完全化保守と予防保守はシステムをより良くするための積極的な取り組みです。したがって、4種類の違いをしっかり整理しておきましょう。

是正保守

発見されたバグ（不具合）を修正する保守。稼働中のシステムで問題が報告された場合に行う。保守作業の中で最も頻繁に発生する。 例：「特定の条件で計算結果が誤る」バグの修正パッチ適用

適応保守

ハードウェアやOSの更新、法改正など外部環境の変化にシステムを対応させる保守。 例：新OS対応、消費税率変更への対応、新ブラウザへの対応

完全化保守

性能改善や機能追加など、システムをより良くするための保守。ユーザの追加要望への対応も含む。 例：処理速度の向上、新しいレポート機能の追加

予防保守

将来の問題を未然に防ぐための保守。潜在的なバグの修正やコードの改善を行う。 例：リファクタリング、古いライブラリのバージョン更新、技術的負債の解消

移行方式

システムの移行方式は、リスクと手間のトレードオフで選択します。たとえば、並行移行は安全性が最も高い一方でコストもかかります。また、段階移行とパイロット移行はリスク分散の観点から多くのプロジェクトで採用されています。

一斉移行

ある時点で全業務を一気に新システムに切り替える方式。準備は大変だが移行完了が早い。失敗時のリスクが大きい。 例：年末年始の休業中に全社一斉切替え

段階移行

業務や拠点を段階的に順次切り替える方式。リスクを分散できるが、移行期間が長くなる。 例：東京支店→大阪支店→名古屋支店の順に月ごとに移行

並行移行

旧システムと新システムを一定期間並行稼働させ、結果を照合して問題がないことを確認してから切り替える方式。最も安全だがコストと手間がかかる。 例：3か月間、旧新両方で処理を行い結果が一致することを確認

パイロット移行

限られた範囲（1部署や1拠点）で先行移行して検証し、問題がなければ全体に展開する方式。 例：1支店で1か月試行→問題なし→全国100支店へ展開