Chapter 32
科目A-1｜開発技術の用語を順に解説します。
要件定義とは 要件定義とは、システム開発の最初の工程であり、クライアント（発注者）がそのシステムを使って「何をしたいのか」「どのような機能が必要か」を明確にし、開発の仕様として取りまとめる作業のことです。 要件は大きく分けて、以下の2種類に分類されます。 機能要件：ユーザーが画面で操作する機能や、システムが処理する内容そのもの（例：ログイン機能、商品の購入カート機能、検索機能など）。 非機能要件：機能以外の性能や品質に関する要素（例：アクセス集中時に耐えられる処理速度、24時間稼働し続ける信頼性、セキュリティ基準、
外部設計とは 外部設計とは、システム開発において、要件定義で決まった内容をもとに、システムの「ユーザーから見える部分」の仕様を決める工程のことです。「基本設計」とも呼ばれます。 主に、ユーザーが操作する画面のデザインや配置（画面レイアウト）、データを入力したり結果を表示したりする画面間の流れ（画面遷移図）、印刷される帳票のレイアウト、他システムとのデータのやり取りの方法などを設計します。発注者（クライアント）にとっても仕上がりイメージを確認しやすい部分であるため、認識のズレがないように打ち合わせを重ねながら合意を形
内部設計とは 内部設計とは、外部設計（基本設計）で決まった仕様をもとに、プログラマーが実際にプログラムコードを書くことができるように、システムの「ユーザーからは見えない裏側の仕組み」を詳細に設計する工程のことです。「詳細設計」とも呼ばれます。 外部設計が「何を見せるか（表面）」を設計するのに対し、内部設計は「どのようにコンピュータで処理するか（裏面）」を設計します。具体的には、データの処理ロジック（アルゴリズム）、データベースのテーブル構造やデータの保存形式、プログラムを機能ごとに分割した「モジュール」の設計、エラ
モジュール分割とは モジュール分割とは、ひとつの大きなプログラムを、特定の機能や役割を持った小さくて独立した部品（モジュール）に細かく分ける設計手法のことです。これにより、プログラムの構造が整理され、開発、テスト、修正が格段に行いやすくなります。 モジュール分割を上手に行うための評価基準として、「結合度」と「凝集度（ぎょうしゅうど）」があります。 結合度（低い方が良い）：モジュール同士の結びつきの強さです。これが低いほど、一つの部品を直したときに他の部品が壊れる連鎖反応を防げます。 凝集度（高い方が良い）：一つのモ
単体テストとは 単体テストとは、システムを構成する最小単位の部品（モジュールや関数、クラスなど）が、単体で正しく設計通りに動作するかを検証するテストのことです。英語では「ユニットテスト」とも呼ばれます。 プログラム全体を組み立ててからテストを行うと、バグ（不具合）が見つかったときに「どの部品のせいで動かないのか」原因を特定するのが非常に困難になります。そのため、家を建てる際にレンガや柱の強度を個別に検査するように、プログラムのパーツ一つひとつを個別にテストします。通常はプログラムの作成者が行い、テストを自動的に実行
結合テストとは 結合テストとは、単体テストをクリアした複数のプログラムの部品（モジュール）を組み合わせたときに、それらが連携して正しく動作するかを検証するテストのことです。モジュール同士をつないだ境界（インターフェース）でデータの受け渡しがスムーズに行われているかを確認します。 個別の部品がどれだけ完璧に動いていても、それらを合体させたときに「データの形式が合わない」「処理を送るタイミングがズレて動かない」といった問題が頻繁に発生します。結合テストでは、複数のモジュールを段階的に組み立てながら、処理の流れがスムーズ
システムテストとは システムテストとは、開発したすべてのプログラムやハードウェアを結合し、システム全体として要件定義で定めた機能や性能、品質がすべて満たされているかを検証する最終段階のテストのことです。「総合テスト」とも呼ばれます。 個々の機能が正しく動くかだけでなく、実際の運用環境に近い状態で全体を動かします。機能要件（想定通りの画面遷移や計算結果が得られるか）はもちろん、非機能要件である「大量のアクセスに耐えられるか（負荷テスト）」「24時間連続で動かしてもメモリが不足しないか（信頼性テスト）」「不正な操作を弾
受入れテストとは 受入れテストとは、開発会社から納品されたシステムに対して、発注者（クライアントや実際の業務ユーザー）が自ら操作を行い、業務で問題なく使えるか、求めていた要件がすべて実装されているかを確認するテストのことです。日本語では「検収（けんしゅう）テスト」とも呼ばれます。 これまで開発側が実施してきた単体・結合・システムテストは、「設計書通りにバグなくプログラムが動くか」を技術的な視点で検証するものでした。これに対し、受入れテストは「実際の業務の現場で、使い物になるか」をユーザーの視点でチェックします。テス
ホワイトボックステストとは ホワイトボックステストとは、プログラムの内部構造（ソースコードの処理ロジックや条件分岐など）がどうなっているかを理解した上で、そのプログラム内のすべての記述ルートが正しく実行されるかを検証するテスト手法です。中身が透けて見える「白い箱（透明な箱）」に例えてこう呼ばれます。 このテストでは、ソースコードの条件分岐（if文など）に注目し、すべての処理ルートを漏れなく通過するようなテストデータを作成します。テストの網羅性を測る指標として以下のようなものがあります。 命令網羅：プログラム内のすべ
ブラックボックステストとは ブラックボックステストとは、プログラムの内部構造やソースコードの中身は一切気にせず、システムの「入力（インプット）」と「出力（アウトプット）」の関係だけに注目して、仕様書通りに正しく動作するかを検証するテスト手法です。中身が見えない「黒い箱」に例えてこう呼ばれます。 このテストでは、「このようなデータを入力したら、仕様書通りにこの結果が返ってくるはずだ」という観点で検証します。テストデータの選び方には、以下のような代表的な設計手法があります。 同値分割：入力値を「同じ結果が得られるグルー
リグレッションテストとは リグレッションテストとは、システムの一部のプログラムを修正したり機能を追加したりした際に、その変更によって「これまで正常に動いていた他の部分に予期せぬ不具合（デグレード）が発生していないか」を確認するための再テストのことです。日本語では「回帰テスト」と呼ばれます。 プログラムは複雑に絡み合っているため、「Aというバグを直したら、全く関係なさそうなBという機能が動かなくなった」というトラブルが頻発します。このような副作用がないかを確認するため、以前合格したテスト項目をもう一度実行し直します。
レビューとは レビューとは、システム開発の各工程（要件定義、設計、プログラミングなど）で作成された成果物（仕様書やソースコード）を複数のメンバーで確認し、誤り（バグ）や考慮不足がないかを検査する作業のことです。早期に問題を発見することで、開発の後半での手戻り（修正作業の増加）を防ぐ目的があります。 レビューには、以下のような代表的な手法があります。 ウォークスルー：成果物の作成者が進行役となり、関係者を集めて成果物を読み進めながら、意見交換や問題点の洗い出しをカジュアルに行う手法。 インスペクション：役割（司会者、
リファクタリングとは リファクタリング（Refactoring）とは、プログラムの「外部から見た動作や機能」は一切変えずに、内部のソースコードの構造を整理して、より読みやすく、メンテナンスしやすい綺麗な状態に書き直す作業のことです。 システム開発を続けていると、場当たり的な修正が重なり、プログラムが複雑で読みづらい状態（いわゆるスパゲティコード）になりがちです。そのまま放置すると、新しい機能を追加しにくくなったり、バグが混入しやすくなったりします。リファクタリングを行うことで、重複しているコードを共通化したり、分か
ウォーターフォールモデルとは ウォーターフォールモデルとは、システム開発の手法（プロセスモデル）の一つで、「要件定義」「設計」「プログラミング」「テスト」「運用」といった各開発工程を、上から下へと順番に一つずつ終わらせながら進めていく方法です。水が高いところから低いところへ落ちる「滝（Waterfall）」に似ていることからこの名がついています。 この手法では、原則として「前の工程が完全に終わるまでは、次の工程に進まない」というルールで進めます。各工程の終わりには、設計書などの成果物がしっかりと作成され、承認を得る
アジャイル開発とは アジャイル開発とは、システムやソフトウェア開発において、短期間で動作するプログラムを作り、それを何度も繰り返しながら徐々に完成度を高めていく開発手法です。「アジャイル（Agile）」には「素早い」「機敏な」という意味があります。 従来の開発手法であるウォーターフォール開発では、最初にすべての設計を完璧に決めてから開発を行っていましたが、アジャイル開発では計画を細かく分け、短いサイクルで開発とテストを繰り返します。これにより、開発の途中でユーザーからの要望が変わったり、不具合が見つかったりしても、
スクラムとは スクラムとは、アジャイル開発における代表的なフレームワーク（枠組み・進め方）の一つです。ラグビーの「スクラム」のように、開発チーム全員が密に連携し、一丸となってプロジェクトを進めることからこの名前がつきました。 スクラムでは、一般的に1週間から4週間程度の「スプリント」と呼ばれる短い期間を一つの単位として開発を繰り返します。チームメンバーには役割があり、製品の責任者である「プロダクトオーナー」や、チームが円滑に動けるよう支援する「スクラムマスター」、実際に手を動かす「開発メンバー」などが協力し合います
XPとは XP（エクストリーム・プログラミング：Extreme Programming）とは、アジャイル開発における手法の一つで、技術的な実践（プラクティス）に重点を置いた開発手法です。「極限（Extreme）プログラミング」という意味があり、ソフトウェア開発における良い習慣を極限まで高めて実践しようという思想から生まれました。 XPには、開発を成功させるための重要な価値観（コミュニケーション、シンプル、フィードバック、勇気、リスペクト）と、具体的な19の実践ルールがあります。代表的なものに、2人のプログラマーが1
テスト駆動開発とは テスト駆動開発（TDD：Test-Driven Development）とは、プログラムの実装コードを書く前に、まずそのプログラムが満たすべき動作を確認するための「テストコード」を先に作成し、そのテストに合格するように実装を進めていく開発手法です。 一般的な開発では、コードを書き終えた後にテストを行いますが、TDDでは手順が逆になります。まず、わざと失敗するテストを書き（Red）、次にそのテストを通過する最小限のコードを書き（Green）、最後にコードを綺麗に整える（リファクタリング）という短い
DevOpsとは DevOps（デブオプス）とは、システムの「開発（Development）」を担うチームと「運用（Operations）」を担うチームが密接に連携し、より迅速かつ安定して価値あるソフトウェアをユーザーに提供し続けるための開発手法や文化のことです。 従来は、新しい機能をどんどん作りたい「開発側」と、システムを安定して動かし続けたい「運用側」で対立が生じがちでした。DevOpsでは、両者が共通のゴール（ビジネス価値の最大化）に向かって協力し、ツールの導入や自動化を進めます。これにより、開発したプログラ
CI/CDとは CI/CDとは、ソフトウェア開発における「継続的インテグレーション（Continuous Integration）」と「継続的デリバリー（Continuous Delivery）」、または「継続的デプロイメント（Continuous Deployment）」を組み合わせた言葉です。開発プロセスを自動化し、素早く安全に本番環境へ届ける仕組みを指します。 CI（継続的インテグレーション）は、開発者が書いたコードを共有のシステムに統合するたびに、自動的にビルドやテストを実行し、エラーを検知する仕組みです。
バージョン管理とは バージョン管理とは、作成したプログラムやファイルの変更履歴を記録・管理し、過去の状態にいつでも戻せるようにする仕組みのことです。また、複数の開発者が同時に同じファイルを編集した際に、お換いの変更が上書きされて消えてしまわないように調整する役割も持っています。 現在、最も広く使われているバージョン管理ツールとして「Git（ギット）」があります。バージョン管理を導入することで、「いつ、誰が、どのファイルの、どの部分を、何の目的で変更したのか」が明確になり、万が一プログラムに不具合が発生したとしても、
プロトタイピングとは プロトタイピングとは、システムやソフトウェアの開発において、早い段階で「試作品（プロトタイプ）」を作成し、ユーザーや開発チーム内で実際に触って確認しながら開発を進める手法です。 仕様書などの文章や図面だけで画面の操作感やシステム全体のイメージを正確に共有することは難しく、完成間近になってから「思っていたものと違う」といった問題が発生することがあります。そこで、まずは見た目や主要な動きだけを再現した簡易的な試作品を作り、ユーザーからフィードバックを得ます。これにより、認識のズレを防ぎ、手戻りのコ
リバースエンジニアリングとは リバースエンジニアリングとは、完成した製品やソフトウェアを分解・解析し、その仕組みや構造、設計データ、ソースコードなどを明らかにする技術や手法のことです。「リバース（逆）」という言葉通り、通常の「設計図から製品を作る」という流れを逆行させて「製品から設計図を導き出す」アプローチです。 この技術は、古いシステムで設計図（ドキュメント）が紛失してしまっている場合の解析や、他社製品の技術的な仕組みの調査、セキュリティ分野におけるコンピュータウイルスの解析（マルウェア解析）などに広く用いられて
UMLとは UML（Unified Modeling Language：統一モデリング言語）とは、ソフトウェアの設計やシステムの構造、動作の流れを視覚的に表現するための、世界的に統一された「図の書き方のルール（表記法）」です。 システム開発に関わる人々（開発者、顧客、マネージャーなど）が言葉だけで設計を議論すると誤解が生じやすいため、共通の「図」を使って意思疎通を図ります。UMLには様々な種類の図があり、システムの構造を表す「クラス図」、システムの機能と利用者の関係を表す「ユースケース図」、時間の経過に伴う処理の流
公式資料へのリンクと確認日を各記事に掲載しています。