【応用情報技術者】第9章システム開発技術について

白川秋

4時間前

9つめの応用情報技術者の科目A暗記用のブログです。
9つめですよ！11章で終わりですからね、いよいよ先が見えてまいりました。

というわけで、今日もがまだすばい！

第9章システム開発技術
みんなで使おう！Ankiアプリで暗記しよう
参考図書
合わせて読みたい
最後に

第9章システム開発技術

開発プロセス・手法

単語	意味
ソフトウェアライフサイクル	ソフトウェアライフサイクルとは、ソフトを作るときの「一生」を表す考え方です。企画→要件定義→設計→実装→テスト→運用→保守→廃棄までの一連の流れを指します。これにより、開発が無秩序にならず、品質やコストを管理しやすくなります。プロジェクト全体を見通すための地図のようなもので、どの段階で何をすべきかを明確にします。
ソフトウェア開発モデル	ソフトウェア開発モデルは、ライフサイクルの各工程を「どう進めるか」を決めた型（テンプレート）です。ウォーターフォールやアジャイルなど、目的や規模に応じて使い分けます。モデルを選ぶことで、チームの進め方が統一され、失敗を減らせるのです。つまり、開発の「戦略」そのものといえます。
ウォーターフォールモデル	ウォーターフォールモデルは、川が上流から下流へ一方通行に流れるように、工程を順番に進める古典的な開発モデルです。要件→設計→実装→テストと、前の工程が終わらないと次に進めません。計画が立てやすく、納期や予算が固定しやすい反面、途中で要件が変わると対応が難しいのが欠点です。
プロトタイプモデル	プロトタイプモデルは、まず簡単な試作品（プロトタイプ）を作ってユーザーに見せ、フィードバックをもとに本格開発する手法です。特に「どんな機能がいいか」が曖昧なときに有効です。試作→意見→改良を繰り返すことで、完成後に「思ってたのと違う！」を防げます。ただし、試作に時間を取りすぎると本開発が遅れるリスクもあります。
スパイラルモデル	スパイラルモデルは、リスク管理を重視した開発モデルで、円を描くように「計画→リスク分析→開発→評価」を繰り返します。各周回（スパイラル）で機能を追加し、リスクが高い部分を早期に潰すのが特徴です。大規模・高リスク案件に向いていますが、管理が複雑で小規模プロジェクトには不向きです。
インクリメンタルモデル	インクリメンタル（増分型）モデルは、ソフトを小さな「使える塊」に分けて、段階的に完成させていく方法です。最初は基本機能だけ、次は追加機能…と少しずつ増やします。ユーザーは早期に一部を使え、開発側もフィードバックを受けながら改善できます。ウォーターフォールより柔軟で、アジャイルの先駆けともいえます。
進化的モデル	進化的モデルは、ソフトを「進化」させるように、ユーザーのニーズに応じて継続的に改良していく開発スタイルです。初期バージョンを素早く作り、その後、使われ方を見て機能を追加・変更します。SNSやスマホアプリのように、市場の反応が重要なサービスに最適です。ただし、設計が後手に回るとコードがぐちゃぐちゃになる危険があります。
アジャイル型開発	アジャイル開発は、「変化に柔軟に対応する」ことを重視した開発手法です。大きな計画を立てるのではなく、短い期間（通常2〜4週間）ごとに「イテレーション（反復）」と呼ばれるサイクルを回し、そのたびに動くソフトを完成させます。これにより、顧客の要望に即座に応えられ、失敗を小さく抑えられます。
スクラム	スクラムはアジャイルの代表的なフレームワークで、開発を「スプリント」という短い期間（通常2週間）の反復単位で進めます。各スプリントで「使えるソフトの一部」を完成させ、毎回振り返りながら改善します。チームは自己組織化し、スクラムマスターが妨害を排除し、プロダクトオーナーが優先順位を決めます。
スプリントプランニング	スプリントプランニング（＝イテレーション計画）は、次のスプリントで何を作るかをチーム全員で決める会議です。プロダクトバックログから「今スプリントでできそうなタスク」を選び、具体的な作業に分解します。この会議で「達成目標（スプリントゴール）」も設定し、全員が同じ方向を向けるようになります。
デイリースクラム	デイリースクラムは、毎日15分以内で行う短い立ち会いミーティングです。メンバーは「昨日何をした？」「今日何をする？」「困っていることは？」の3点を共有します。進捗を可視化し、問題を早期に発見・解決するための仕組みで、チームの連携を強化します。会議室ではなく、ホワイトボードの前で立ったまま行うのが普通です。
スプリントレビュー	スプリントレビュー（＝デモ）は、スプリントの終わりに「できたものを関係者に見せる会議」です。実際に動くソフトをデモし、フィードバックをもらいます。これは「検査」ではなく「学び」の場で、次に何を優先すべきかを考える材料にします。顧客やステークホルダーが参加し、リアルな反応が得られるのが最大のメリットです。
スプリントレトロスペクティブ	スプリントレトロスペクティブは、チームだけで行う「ふりかえり」の会議です。「うまくいったこと」「改善したいこと」「次に試すこと」を話し合います。ソフトの質だけでなく、「チームの働き方」そのものを改善するのが目的です。心理的安全性が保たれていれば、正直な意見が出やすく、継続的な成長につながります。
プロダクトバックログリファインメント	プロダクトバックログリファインメントは、今後の開発候補である「プロダクトバックログ」を整理・詳細化する活動です。あいまいな要件を明確にし、見積もり可能な大きさに分割します。これにより、次のスプリントプランニングがスムーズになります。通常、スプリント中に少しずつ行われ、準備万端にしておきます。
XP	XP（エクストリームプログラミング）は、アジャイルの一種で、「コードの質」と「顧客との密接な連携」を極限まで追求する開発手法です。ペアプログラミングやテスト駆動開発など、一見過激なプラクティスを採用しますが、それが長期的な生産性を高めます。変化の激しいプロジェクトに特に有効です。
ペアプログラミング	ペアプログラミングは、2人で1台のPCを使ってコーディングする手法です。1人がコードを書く「ドライバー」、もう1人が全体を監視する「ナビゲーター」に分かれ、定期的に交代します。これにより、バグが減り、知識共有が進み、設計の質が上がります。初めは非効率に感じますが、長期的には生産性が向上します。
テスト駆動開発	テスト駆動開発（TDD）は、「テストを先に書いてからコードを書く」開発スタイルです。まず「こう動くべき」というテストを作り、それが失敗することを確認→コードを書いてテストを通す→リファクタリング、を繰り返します。式で表すと「赤（失敗）→緑（成功）→青（改善）」のサイクルです。これにより、バグが少なく、変更に強いコードが生まれます。
リファクタリング	リファクタリングは、「外部の動作を変えずに、内部のコードをきれいにする」作業です。例えば、長い関数を分割したり、変数名をわかりやすくしたりします。TDDと組み合わせると、安全にコードを改善できます。見た目は変わらないけど、将来の修正が楽になり、チーム全体の開発速度が上がります。
継続的インテグレーション	継続的インテグレーション（CI）は、開発者が頻繁にコードを共有リポジトリに統合し、自動テストで問題を即座に検出する仕組みです。1日に何十回もマージし、ビルドとテストを自動実行します。これにより、「最後にまとめて統合したら動かない！」という悲劇を避けられます。GitHub ActionsやJenkinsなどがよく使われます。
コードの共同所有	コードの共同所有とは、「このコードはAさんのもの」と決めず、全員が自由に修正できる文化です。XPの原則の一つで、特定の人がいないと修正できない「属人化」を防ぎます。そのためには、コードが読みやすく、テストが整っていなければなりません。結果として、チーム全体の責任感と品質が高まります。
YAGNI	YAGNI（ヤグニ）は「You Aren’t Gonna Need It（君はそれを使わないだろう）」の略で、「今必要ない機能は作らない」というXPの原則です。将来的に使うかもしれないと思って余計なコードを書くと、保守が大変になります。本当に必要になったらそのとき作ればOK。シンプルさと集中力を保つための知恵です。
リーンソフトウェア開発	リーンソフトウェア開発は、トヨタの「リーン生産方式」から着想を得た開発思想で、「無駄を徹底的に削る」ことを目指します。7つの無駄（待ち・過剰機能・バグなど）を排除し、価値あるものだけを素早く届けます。アジャイルと似ていますが、より「効率」に焦点を当て、MVP（最小限の製品）の早期提供を重視します。
組み込みソフトウェア開発	組込みソフトウェアとは、家電や車、医療機器など特定のハードウェアに内蔵され、その機器の動作を制御するソフトウェアです。この開発では、メモリや処理能力が限られているため、効率的で信頼性の高いコードが求められます。リアルタイム性（決められた時間内に処理を完了すること）も重要で、たとえば自動車のブレーキ制御では遅延が許されません。開発にはC言語やC++がよく使われ、ハードウェアとの連携テストが不可欠です。
プラットフォーム開発	プラットフォーム開発とは、他のソフトウェアが動く土台（基盤）を作る開発のことです。例としては、スマートフォンのOS（AndroidやiOS）、クラウドサービス（AWSやAzure）などが該当します。プラットフォームは安定性・拡張性・セキュリティが重視され、多くのアプリケーションが依存するため、一度作ると長期間使われます。2026年現在では、AIやIoTに対応した新しいプラットフォームの開発が活発です。
コンカレントエンジニアリング	コンカレントエンジニアリング（同時並行型開発）とは、設計・製造・テストなどの工程をバラバラに行わず、同時に進める手法です。これにより開発期間が短縮され、問題の早期発見が可能になります。たとえば、ソフトウェアの設計段階で品質保証チームが関与すれば、バグの原因を早い段階で潰せます。従来の「ウォーターフォールモデル」とは対照的で、アジャイル開発とも親和性が高いです。
コデザイン	コデザイン（共同設計）は、ハードウェアとソフトウェアを別々に設計するのではなく、両方を一体として同時に設計する手法です。特に組込みシステムやAIチップ開発で重要で、ハードとソフトの性能を最適にバランスさせられます。たとえば、AI推論用の専用チップ（NPU）では、ソフトのアルゴリズムに合わせてハードの回路を設計することで、高速化・省電力化が実現されます。
リエンジニアリング	リエンジニアリングとは、既存のシステムを分析し、より効率的・現代的な形に作り直すことです。単なる修正ではなく、「再設計」が目的です。たとえば、古いCOBOLで書かれた銀行システムをクラウド対応のJavaアプリに変えるのがこれにあたります。コストはかかりますが、長期的には保守性や拡張性が向上し、2026年ではDX（デジタルトランスフォーメーション）の一環として注目されています。
リバースエンジニアリング	リバースエンジニアリングは、完成したソフトウェアやハードウェアを分解・分析して、その仕組みや設計を明らかにする手法です。ソースコードがない古いシステムを理解するときや、競合製品の調査に使われます。ただし、著作権侵害になる可能性があるため、法的・倫理的な注意が必要です。ツールとしては、デコンパイラやディスアセンブラが使われ、2026年ではAIを使った自動解析も進んでいます。
フォワードエンジニアリング	フォワードエンジニアリングは、通常の「要件→設計→実装」という流れでソフトウェアを開発する方法です。つまり、リバースエンジニアリングの逆で、ゼロから新しく作る標準的な開発プロセスを指します。UML図や設計書からコードを生成する「モデル駆動開発（MDD）」もこの一形態です。2026年では、AIが設計書からコードを自動生成するケースも増えています。
ローコード開発	ローコード開発は、プログラミングの知識が少なくても、ビジュアル操作（ドラッグ＆ドロップなど）でアプリを作れる開発手法です。代表例はMicrosoft Power AppsやOutSystemsです。業務部門の社員が自らツールを作れる「Citizen Developer（市民開発者）」の増加を支え、2026年では企業のDX加速に大きく貢献しています。ただし、複雑な処理や高セキュリティ要件には向かない場合があります。
共通フレーム	共通フレーム（Common Framework）は、日本で策定されたシステム開発の標準ガイドラインで、IPA（情報処理推進機構）が提供しています。開発の各工程（要件定義から保守まで）で何をすべきか、どんな成果物を出すべきかが明確に定められています。これにより、異なる会社間でも共通言語で開発でき、品質や納期の安定化に寄与します。2026年版では、クラウド・AI・セキュリティへの対応が強化されています。
V字モデル	V字モデルは、開発工程とテスト工程が対になっていることを示すモデルです。左側が「要件→設計→実装」と下り、右側が「単体テスト→結合テスト→システムテスト」と上昇し、Vの字を描きます。たとえば、「ソフトウェア要件定義」に対応するのが「システムテスト」です。このモデルを使うと、各設計段階でテスト観点を明確にでき、漏れを防げます。ただし、変更に弱いという弱点もあり、アジャイルとは併用されることが多いです。
システム要件定義	システム要件定義は、ユーザーが求める機能や性能を「システム全体」の観点で明確にする工程です。たとえば「1秒以内に検索結果を表示する」や「1万人が同時にアクセスできる」などが含まれます。この段階では、ビジネス要件をIT要件に翻訳し、後の設計の土台になります。共通フレームでは、この成果物が「システム要件定義書」として文書化されます。
システム方式設計	システム方式設計は、システム要件を実現するための全体構成（アーキテクチャ）を決める工程です。どのサーバーを使い、どうデータをやりとりするか、クラウドかオンプレかなどを決めます。たとえば「フロントエンドはReact、バックエンドはJava、DBはPostgreSQL、ホスティングはAWS」といった具合です。この設計が後の開発の方向性を大きく左右します。
ソフトウェア要件定義	ソフトウェア要件定義は、システム内の「ソフトウェア部分」に焦点を当てて、何ができるかを詳細に定義する工程です。たとえば「ログイン機能」「商品検索」「支払い処理」など、具体的な機能一覧とその仕様（入力・出力・処理内容）を記述します。これは、開発者がコードを書く際の「設計図」となり、曖昧さを排除することが重要です。
ソフトウェア方針設計	ソフトウェア方式設計は、ソフトウェア要件を実現するための内部構造を設計する工程です。モジュール（部品）をどう分けるか、どう連携させるかを決めます。たとえば「認証モジュール」「在庫管理モジュール」「注文処理モジュール」のように分割し、それぞれのインターフェース（接続方法）を定義します。この設計がしっかりしていれば、チーム開発や保守が格段に楽になります。
ソフトウェア詳細設計	ソフトウェア詳細設計は、方式設計で決めたモジュールの中身をさらに細かく設計する工程です。具体的には、関数名・変数名・アルゴリズム・データ構造などを決めます。たとえば「在庫数が0ならエラーを返す」といった処理フローをフローチャートや擬似コードで記述します。この段階までしっかりしておけば、プログラミングはほぼ「書き写すだけ」になります。
ソフトウェア構築	ソフトウェア構築は、詳細設計に基づいて実際にプログラムコードを書く工程です。近年では、単にコードを書くだけでなく、自動テストやCI/CD（継続的インテグレーション／デリバリー）の仕組みも含みます。2026年では、GitHub CopilotなどのAIコーディング支援ツールが広く使われ、生産性が飛躍的に向上しています。ただし、コードの品質・セキュリティ・可読性は依然として人間の責任です。
ソフトウェアプロセスの評価	ソフトウェアプロセスの評価とは、開発の進め方が適切かどうかを客観的にチェックすることです。これにより、品質のばらつきを減らし、プロジェクトの成功率を高めます。国際標準であるISO/IEC 15504（SPICE）がよく使われ、プロセスの成熟度を「未実施」から「最適化」までのレベルで評価します。2026年では、AIによるプロセス自動診断も始まっています。
CMMI	CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）は、ソフトウェア開発プロセスの成熟度を評価・改善するための米国発のフレームワークです。レベル1（初期）からレベル5（最適化）まであり、組織がどの段階にいるかを示します。日本でも大手IT企業を中心に導入が進み、2026年現在は「CMMI V3.0」が最新版で、アジャイルやDevOpsへの対応が強化されています。
初期	「初期（Level 1）」はCMMIの最も低い成熟度レベルで、プロセスが文書化されておらず、成功が個人のスキルや努力に依存している状態です。プロジェクトごとにやり方がバラバラで、品質や納期が不安定になりがちです。スタートアップ企業や小規模チームに多く見られますが、成長とともに改善が求められます。
管理された	「管理された（Level 2）」では、プロジェクト単位で計画・進捗・コスト・品質が管理されるようになります。たとえば「このタスクは3日で終わる予定」が実績と照らし合わされ、遅れがあれば対応されます。ただし、組織全体での標準化はまだ不十分で、プロジェクトによってやり方が異なることがあります。
定義された	「定義された（Level 3）」では、全社横断で標準的な開発プロセスが確立され、すべてのプロジェクトがそれに従います。共通フレームやISO規格をベースにした手順書があり、新人でも一定の品質で開発できます。このレベルに到達すると、外部委託や協業もスムーズになります。
定量的に管理された	「定量的に管理された（Level 4）」では、プロセスのパフォーマンスを数値で測定・分析します。たとえば「バグ密度＝1000行あたり0.5件」や「テストカバレッジ＝90%」といった指標を元に、品質を予測・制御します。統計的手法（例：標準偏差）を使い、目標達成の確率を高めます。
最適化している	「最適化している（Level 5）」はCMMIの最高レベルで、継続的な改善が文化として根付いています。データに基づき、プロセスのボトルネックを発見し、新技術（例：AI、自動化）を積極的に取り入れます。失敗から学び、全社でベストプラクティスを共有し、常に「より良く」を目指す姿勢が特徴です。

分析・設計手法

単語	意味
構造化分析法	構造化分析法は、システムの「何をするか」を明確にする手法です。1970年代にトム・デマルコが提唱し、「データの流れ」を中心に問題を整理します。この方法では、業務の現状を図や表でモデル化し、曖昧さを排除します。特にDFD（後述）と組み合わせて使われ、複雑な業務を段階的に理解できるようにします。デマルコの貢献により、ソフトウェア開発は「芸術」から「工学」へと進化しました。
構造化設計	構造化設計は、「どう実現するか」を考える設計手法で、構造化分析の次に来ます。モジュール（部品）を階層的に分け、それぞれの役割を明確にし、結合度を低く、凝集度を高くすることを目指します。これにより、プログラムの修正やテストがしやすくなります。代表的なツールとして「構造図（Structure Chart）」があり、上位モジュールから下位モジュールへの呼び出し関係を視覚化します。
DFD	DFD（Data Flow Diagram：データ流れ図）は、システム内でデータがどう流れるかを図で表す手法です。円（プロセス）、矢印（データの流れ）、長方形（外部エンティティ）、二重線（データストア）で構成されます。たとえば、「注文を受け取る→在庫を確認→出荷指示を出す」といった流れを視覚的に表現できます。DFDは業務の本質を捉えるのに最適で、開発者と利用者の共通言語になります。
システムのモデル化	モデル化とは、現実の複雑な業務を簡略化して「モデル」として表現することです。これにより、誤解を防ぎ、開発の方向性を共有できます。モデルには「論理モデル（何をするか）」と「物理モデル（どう実現するか）」があります。2026年現在でも、UMLやDFDなどを使ったモデル化は、AIやクラウド時代の開発でも基本として使われています。
現物理モデル	現物理モデルは、「今、実際に使われているシステムのあり方」を示すモデルです。たとえば、「紙の帳票で管理している」「Excelで在庫を記録している」など、具体的な手段やツールを含みます。これは改善の起点となり、「どこが非効率か」を明らかにするために使われます。ただし、物理モデルだけでは本質的な課題が見えにくいため、論理モデルとの対比が重要です。
現論理モデル	現論理モデルは、「今の業務が本来どうあるべきか」を技術的手段に依存せず抽象的に表したものです。たとえば、「顧客から注文を受け、在庫を確認し、出荷する」という業務フローそのものを指します。このモデルは、紙でもシステムでも実現可能で、システム改訂の際の「理想の出発点」となります。構造化分析の核心ともいえます。
新論理モデル	新論理モデルは、「改善後の業務の理想像」を抽象的に表現したものです。現論理モデルの課題を解決し、効率化・自動化された業務フローを示します。たとえば、「注文と同時に在庫をリアルタイム更新する」などが含まれます。この段階ではまだ「どのソフトを使うか」は決めず、業務の本質だけを設計します。これが後のシステム設計の青写真になります。
新物理モデル	新物理モデルは、「新論理モデルをどう実現するか」の具体的な計画です。使用するプログラミング言語、データベース、クラウドサービス、API連携など、技術的詳細を含みます。2026年では、AWSやAzure、マイクロサービスアーキテクチャなどがよく使われます。このモデルに基づき、実際に開発チームがコーディングを進めます。
コンテキストダイアグラム	コンテキストダイアグラムは、DFDの最も外側の図で、システム全体を1つのプロセスとして扱い、外部とのデータのやり取りを示します。たとえば、「顧客」「配送業者」「支払いシステム」といった外部エンティティと、システムの間のデータの流れ（例：「注文情報」「請求書」）を描きます。これにより、システムの境界と役割が一目でわかります。
ミニスペック	ミニスペック（ミニ仕様書）は、DFDの各プロセスの詳細動作を記述した文書です。たとえば、「プロセス3：在庫確認 → 在庫数 ≥ 注文数なら『OK』、そうでなければ『不足』を返す」といった具合です。擬似コードや決定表で書くこともあり、開発者がプログラムを書く際の直接のガイドになります。小さい単位で仕様を固定するため、バグの防止に効果的です。
データとプロセス	システムは「データ（情報）」と「プロセス（処理）」で成り立ちます。データは「顧客名」「商品価格」など静的な情報、プロセスは「注文を登録する」「請求書を発行する」など動的な処理です。構造化分析ではプロセス中心、オブジェクト指向では両者を統合します。2026年では、ビッグデータやAIの台頭で「データの価値」がより重視されています。
プロセス中心設計	プロセス中心設計は、処理の流れ（プロセス）を軸にシステムを設計する方法です。構造化分析・設計が代表的で、「入力→処理→出力」の流れを重視します。たとえば、「受注→検品→出荷」といった業務フローを先に設計し、必要なデータは後から定義します。この手法は、業務改善が目的のシステムに適していますが、データの再利用性は低くなりがちです。
データ中心設計	データ中心設計は、まず「どんなデータが必要か」を設計し、その後で処理を決める方法です。データの整合性や再利用性を重視し、ER図（後述）を使ってデータ構造を明確にします。たとえば、「顧客」「商品」「注文」の関係を先に定義し、その上で「注文登録処理」を設計します。現代のデータベース駆動型システムやAI活用では、この考え方が主流です。
データモデリング	データモデリングは、現実世界の情報を「データの構造」として抽象化する作業です。代表的なのはERモデル（Entity-Relationship Model）で、「顧客（エンティティ）」と「注文（エンティティ）」の間に「1対多の関係」がある、などを図で表現します。これにより、データの重複や矛盾を防ぎ、効率的なデータベース設計が可能になります。2026年でも、NoSQLを含むあらゆるDB設計の基礎です。
データの標準化	データの標準化は、同じ意味のデータを統一ルールで扱うことです。たとえば、「都道府県」を「東京」「Tokyo」「TOKYO」と混在させず、「東京都」と統一します。これにより、検索・集計・連携が正確になります。国際的にはISO/IEC 11179などのメタデータ標準もあり、企業内でも「マスタ管理」が徹底されています。AI訓練データの品質向上にも直結します。
標準プロセスの設計	標準プロセスの設計とは、繰り返し発生する業務処理を共通化・テンプレート化することです。たとえば、「ユーザー登録」「パスワード再発行」などは、どのシステムでもほぼ同じ手順なので、標準化して再利用します。これにより、開発コスト削減・品質向上・セキュリティ強化が図れます。2026年では、DevOpsやCI/CDパイプラインにもこの考え方が反映されています。
一体化	一体化（インテグレーション）は、分析・設計・実装の各工程を密接に連携させることを指します。昔は「ウォーターフォール型」で分断されていましたが、現在は「要件→設計→コード」が連動するよう、ツール（例：Jira＋Confluence＋Git）で一元管理されます。これにより、変更への対応が速くなり、開発の透明性が高まります。アジャイル開発の根幹ともいえます。
ソフトウェア設計	ソフトウェア設計は、要件をもとに「どうプログラムを組むか」を計画する工程です。モジュール分割、インタフェース設計、エラー処理などを決めます。2026年では、マイクロサービス、イベント駆動、APIファースト設計が主流で、クラウドネイティブなアーキテクチャが重視されます。設計の良し悪しが、システムのスケーラビリティや保守性を左右します。
CRUDマトリクス	CRUDマトリクスは、各機能がデータ（エンティティ）に対して「Create（作成）」「Read（参照）」「Update（更新）」「Delete（削除）」のどの操作を行うかを表にしたものです。行に機能（例：「注文登録」）、列にエンティティ（例：「注文テーブル」）を置き、該当セルにC/R/U/Dを記入します。これにより、機能とデータの関係が明確になり、漏れや冗長を防げます。
事象応答分析	事象応答分析は、「外部からの出来事（事象）に対して、システムがどう反応するか」を分析する手法です。たとえば、「注文メールが届く（事象）→ 注文データを登録（応答）」のように、トリガーとアクションの関係を整理します。この手法は、リアルタイム処理やイベント駆動型システム（例：IoT、チャットボット）の設計に適しており、2026年ではますます重要になっています。
状態遷移図	状態遷移図は、あるオブジェクト（例：注文）が「どの状態（例：受付中→支払い済み→発送済み）」を経て変化するかを矢印で示す図です。各矢印には「イベント（例：支払い完了）」がラベルとして付きます。これにより、例外処理（例：キャンセル）も含めた全体像が把握でき、バグの少ないロジック設計が可能になります。ゲームやワークフローシステムでよく使われます。
状態遷移表	状態遷移表は、状態遷移図を表形式にしたものです。行に「現在の状態」、列に「イベント」を置き、交差セルに「次の状態」と「実行されるアクション」を記述します。たとえば、現在「受付中」で「支払い完了」イベントが起きると「支払い済み」に遷移し、「メール送信」アクションを実行、など。プログラムの条件分岐の設計に直接使えます。
ペトリネット図	ペトリネット図は、並列処理や同期処理を表現する数学的モデルです。「プレース（状態）」「トランジション（処理）」「トークン（進行状況）」で構成され、複数の処理が同時に動く様子を可視化できます。たとえば、「在庫確認」と「クレジット審査」が並行して終わったら「注文確定」に進む、といった動きを厳密に記述できます。リアルタイムシステムや製造ライン制御で使われます。
システム開発プロジェクトのライフサイクル	システム開発ライフサイクル（SDLC）は、企画から運用・保守までの一連の流れです。代表的なモデルには、段階的に進む「ウォーターフォール」、短い周期で反復する「アジャイル」、リスクを早期に潰す「スパイラル」などがあります。2026年では、クラウド・AI・セキュリティを考慮した「DevSecOps」型のライフサイクルが主流で、継続的改善が求められます。どのモデルでも、分析・設計は成功の鍵です。

オブジェクト指向設計

単語	意味
オブジェクト指向の基本概念	オブジェクト指向とは、現実世界の「モノ（オブジェクト）」をソフトウェアの中で再現する考え方です。たとえば「車」には「色」や「速度」といった「データ（属性）」と、「加速する」「ブレーキをかける」といった「動作（メソッド）」があります。このように、データと処理をまとめて扱うことで、プログラムを整理しやすく、再利用しやすくなります。
オブジェクトとカプセル化	オブジェクトは、データとそのデータを操作するメソッドを一つにまとめたものです。カプセル化とは、この内部の詳細（たとえば変数の値）を外から直接いじれないように「隠す」仕組みです。たとえば、スマホの内部回路をユーザーが触れないようにするのと同じで、誤操作を防ぎ、安全な設計を可能にします。
クラスとインスタンス	クラスは「設計図」、インスタンスはその設計図から作られた「実物」です。たとえば「犬」というクラスがあれば、「ポチ」というインスタンスが生まれます。クラスライブラリとは、よく使うクラス（例：日付、ファイル操作など）をあらかじめ用意しておいたもので、Javaの`java.util`やPythonの`datetime`などが該当します。
インヘリタンス	インヘリタンス（継承）とは、あるクラスの機能を別のクラスが引き継ぐ仕組みです。たとえば「動物」という親クラスがあり、「犬」クラスがそれを継承すると、「犬」は「動物」の持つメソッドや変数をそのまま使えるようになります。これにより、コードの重複を減らし、保守性が高まります。
クラス間の関係	クラス同士はさまざまな関係を持ちます。代表的なのは「is-a（〜である）」と「part-of（〜の一部である）」です。たとえば「犬 is-a 動物」、「車 part-of エンジン」のように、関係性を明確にすることで、設計が整理され、バグの原因を減らせます。
is-a関係	「is-a関係」とは、「AはBの一種である」という関係です。たとえば「ペンギン is-a 鳥」のように、継承（インヘリタンス）で表現されます。この関係があると、親クラスの変数に子クラスのインスタンスを代入でき（ポリモーフィズムの基礎）、柔軟なプログラム設計が可能になります。
part-of関係	「part-of関係」は、「AはBの一部である」という関係です。たとえば「車のエンジンは車の一部」のように、これは「集約」や「コンポジション」としてUMLで表現されます。この関係は、オブジェクトの寿命や所有関係を明確にするのに役立ちます。
ポリモーフィズム	ポリモーフィズム（多態性）とは、「同じ命令でも、対象によって違う動きをする」仕組みです。たとえば、「鳴く」という命令を犬と猫に与えると、犬は「ワン」、猫は「ニャー」と返します。プログラムでは、親クラスのメソッドを子クラスで独自に実装（オーバーライド）することで実現します。これにより、コードの再利用性や拡張性が高まります。補足：ポリモーフィズムを使うと、処理の共通化ができ、新しい動物が増えても呼び出し側のコードを変更せずに済みます。
オーバーライド	オーバーライドとは、親クラスで定義されたメソッドを、子クラスで「上書き」して別の動きをさせる仕組みです。たとえば親クラスの「移動()」が「歩く」だったのに対し、子クラス「車」では「走る」に変えることができます。これにより、共通のインターフェースを保ちつつ、個別の振る舞いを実装できます。
抽象メソッド	抽象メソッドとは、「中身のないメソッド」で、「必ず子クラスで実装しなければならない」という約束事です。たとえば「音を出す()」という抽象メソッドを持つ親クラスがあれば、子クラスは「ワン！」や「ニャー！」など、具体的な実装を提供する必要があります。
抽象クラス	抽象クラスは、抽象メソッドを含むクラスで、それ自体はインスタンス化できません。主に「共通の設計ルールを強制する」ために使われます。たとえば「動物」という抽象クラスを作り、「犬」「猫」がそれを継承することで、全動物が「鳴く()」メソッドを持つことを保証できます。
オーバーロード	オーバーロードとは、同じ名前のメソッドを、引数の型や数を変えて複数定義することです。たとえば`print(String s)`と`print(int i)`のように、同じ`print`でも中身が変わります。これにより、使い勝手が良くなり、直感的なコードが書けます（ただしPythonなど一部言語ではサポートされていません）。
委譲	委譲とは、「自分では処理せず、他のオブジェクトに任せる」設計手法です。たとえば「車」クラスが「エンジン.start()」と呼ぶことで、エンジンの起動処理をエンジンクラスに任せます。これにより、責任の分離ができ、コードがシンプルで再利用しやすくなります。
伝搬	伝搬（プロパゲーション）とは、あるオブジェクトの状態変化が、関連する他のオブジェクトに影響を与えることです。たとえば「注文」オブジェクトの金額が変わると、「請求書」オブジェクトの合計も自動更新されるような仕組みです。イベント駆動型設計などでよく使われます。
UML	UML（Unified Modeling Language）は、ソフトウェアの設計を図で表現するための国際標準の記法です。2026年現在も広く使われており、クラス図やシーケンス図など、さまざまな図でシステム構造や動作を可視化できます。これにより、チーム開発での意思疎通が格段に向上します。
クラス図	クラス図は、システム内のクラスとその関係（継承・関連・集約など）を視覚的に表現するUMLの基本図です。各クラスは「クラス名」「属性（変数）」「操作（メソッド）」の3段階のボックスで表され、線や矢印でつながれます。たとえば「学生」と「授業」の関連や、「鳥」と「ペンギン」の継承などが一目でわかります。設計の青写真として、開発初期から保守フェーズまで幅広く活用され、2026年現在もソフトウェアエンジニアの必須スキルです。
関連	関連は、UMLで「クラス同士がお互いを使っている」ことを示す関係です。たとえば「学生」クラスが「授業」クラスを参照する場合、クラス図では線で結ばれます。この線には「多重度」（例：1対多）も記述でき、「1人の学生が複数の授業を取る」など、具体的なつながり方を明確にできます。関連は恒久的で、設計の構造を理解するのに不可欠です。一時的な利用ではない点が「依存」との違いです。
汎化	汎化は、UMLで「is-a関係」、つまり継承を表す記号です。親クラス（一般）から子クラス（特殊）へ「空の三角形の矢印」が伸びます。たとえば「鳥 ← ペンギン」のように、ペンギンは鳥の一種です。これにより、共通の属性やメソッドを親で定義し、子で特有の機能を追加できます。汎化を使うと、コードの再利用性が高まり、変更への耐性も強くなります。オブジェクト指向設計の根幹をなす関係です。
集約	集約は、「AがBを含むが、Bは独立して存在できる」弱いpart-of関係です。UMLでは「白抜きの菱形＋矢印」で表現されます。たとえば「大学」と「教授」の関係：大学が閉鎖されても教授は他の大学に行けます。ライフサイクルが別々で、所有関係はあるものの束縛は弱いのが特徴です。集約は、システム内の構成要素の緩い結合を設計する際に役立ちます。
コンポジション	コンポジションは、「AがBを強く所有し、BはAと共に消える」強いpart-of関係です。UMLでは「塗りつぶされた菱形＋矢印」で描かれます。例：「車」と「エンジン」—車が廃車になればエンジンも同時に不要になります。この関係では、部品の寿命が全体と完全に一致します。コンポジションは、密接に連動する部品を持つシステム（例：GUIコンポーネント）の設計に適しています。
依存	依存は、「あるクラスが一時的に別のクラスを使う」関係で、UMLでは「破線＋矢印」で示されます。たとえば「注文処理クラス」が「メール送信クラス」を一時的に呼び出す場合などです。恒久的な関係ではなく、メソッド内でのみ参照されるのが特徴です。依存は、モジュール間の結合をゆるく保ち、変更の影響を最小限に抑える設計に役立ちます。
シーケンス図	シーケンス図は、時間の流れに沿ってオブジェクトどうしがどのようにメッセージ（メソッド呼び出し）をやり取りするかを可視化するUML図です。縦に各オブジェクトの「ライフライン」を並べ、横方向の矢印で呼び出しを表現します。返り値や条件分岐も記述可能で、特にAPI連携やイベント処理の設計で重宝されます。2026年現在も、マイクロサービス開発で広く使われています。
ユースケース図	ユースケース図は、システムの利用者（アクター）とその人が使う機能（ユースケース）の関係を示すUML図です。「顧客が商品を注文する」などの業務シナリオを簡潔に表現できます。円（ユースケース）と人型アイコン（アクター）を線で結ぶだけで、誰が何をするかが一目瞭然。要件定義の初期段階やステークホルダーとの合意形成に非常に効果的です。
ステートマシン図	ステートマシン図（状態遷移図）は、1つのオブジェクトが持つ「状態」と、イベントによる「状態の変化」を示すUML図です。たとえばスマートフォンなら「ロック中 → 解錠イベント → 使用可能」のように遷移します。各状態から出る矢印に「トリガーイベント／実行アクション」を記述でき、複雑な振る舞いを持つオブジェクト（例：ゲームキャラクター）の設計に最適です。
アクティビティ図	アクティビティ図は、処理の流れ（ワークフロー）をフローチャート風に表現するUML図です。開始ノードから終了ノードまで、アクションを矢印でつなぎ、分岐（if）や並列処理（フォーク／ジョイン）も視覚化できます。業務プロセスの改善やアルゴリズムの検討に活用され、2026年現在もDevOpsやAgile開発で頻繁に使われる重要な設計ツールです。

モジュール設計

単語	意味
モジュール設計	モジュール設計とは、大きなソフトウェアを小さな部品（＝モジュール）に分けて作ることです。たとえば、ゲームを作るとき、「キャラクター操作」「敵の動き」「スコア管理」といった機能ごとに分けると、それぞれを別々に作ったり直したりしやすくなります。このように分けた部品が「モジュール」で、全体を効率よく作るための設計が「モジュール設計」です。これにより、バグの修正や機能追加が簡単になり、チーム開発もしやすくなります。
モジュール分割技法	モジュール分割技法とは、ソフトウェアをどうやってモジュールに分けるかのルールや方法のことです。代表的なものには「STS分割」「TR分割」「共通機能分割」などがあります。これらは、プログラムの流れや処理の種類を見て、「どこで切るのが一番自然で効率的か」を考えるためのテクニックです。良い分割ができれば、後でコードを直す手間が減り、品質も上がります。
STS分割	STS分割（ストリーム・トランスフォーメーション・ストリーム分割）は、入力→処理→出力という一連の流れに沿ってモジュールを分ける方法です。たとえば、注文データを受け取って（入力）、金額を計算して（処理）、請求書を出力する（出力）ようなシステムでは、この3ステップごとにモジュールを分けます。こうすると、各部分の役割が明確になり、テストや修正がしやすくなります。
TR分割	TR分割（トランザクション分割）は、1つの入力に対して複数の処理パターンがあるときに使う分割法です。たとえば、ATMで「預け入れ」「引き出し」「残高照会」といった操作が1つの画面から選べる場合、それぞれの操作を別のモジュールに分けます。この「1つの入力 → 複数の処理分岐」の形を「トランザクション」と呼び、そこから「トランザクション分割」とも呼ばれます。処理の種類ごとに独立させることで、変更が局所化されます。
共通機能分割	共通機能分割とは、複数のモジュールで使われる同じ処理（例：ログ記録、エラーチェック、日付計算など）を1つのモジュールにまとめる方法です。たとえば、何十もの画面で「ユーザー名を表示する」処理が必要なら、それを1カ所に集めておけば、修正の手間が大幅に減ります。このように共通部分を切り出して再利用することで、コードの重複を防ぎ、保守性が高まります。
アスペクト指向プログラミング	アスペクト指向プログラミング（AOP）は、共通機能分割をさらに進化させた考え方です。たとえば「すべての関数の実行時間を測る」や「アクセス権をチェックする」といった横断的な処理を、メインのコードに直接書かずに、別途「アスペクト」として定義します。これにより、本質的な処理（例：注文処理）と補助的な処理（例：ログ出力）が分離され、コードがすっきりします。AOPはJavaのSpring AOPやAspectJなどで実現されます。
ジャクソン法	ジャクソン法は、データの構造に注目してプログラムを設計する手法です。まず入力データと出力データの構造（例：リストや階層）を図にして、その対応関係からプログラムの構造を導きます。たとえば、入力が「注文書（ヘッダー＋複数の明細）」なら、プログラムもそれに合わせて階層的にモジュールを分けます。この方法は1970年代に提唱されましたが、データ駆動型の設計として今も有効です。
ワーニエ法	ワーニエ法は、処理の論理構造（順次・選択・反復）に基づいてプログラムを設計する方法です。処理を「順番にやる」「条件で分岐する」「繰り返す」といった基本ブロックに分解し、それに対応するモジュールを構築します。これは構造化プログラミングの考え方に近く、フローチャートや疑似コードから直接モジュール構造を導くことができます。教育現場でもよく使われる基礎的手法です。
モジュール分割の評価	モジュール分割が「良いか悪いか」を判断するのが「モジュール分割の評価」です。主に「構造上の評価」と「独立性の評価」の2軸で見ます。前者はモジュールの大きさやインターフェースの複雑さ、後者は他のモジュールへの依存度（＝結合度）を指します。良い分割とは、「小さすぎず大きすぎず」「他とあまり絡み合わない」モジュールの集まりです。これにより、長期的な保守が容易になります。
構造上の評価	構造上の評価では、モジュールの「大きさ」と「インターフェースの単純さ」を見ます。大きすぎるモジュールは理解が難しく、小さすぎると管理が大変です。理想的なのは、1モジュールが1つの明確な役割を持つサイズ（だいたい数十～数百行）。また、モジュール同士のやりとり（インターフェース）は、必要な情報だけを渡すようシンプルにすべきです。複雑なインターフェースはバグの温床になります。
独立性の評価	独立性の評価とは、モジュールがどれだけ「自分だけで完結しているか」を測ることです。独立性が高いほど、他のモジュールに影響されず、単体テストや修正が楽になります。この独立性は「結合度」の低さと「凝集度」の高さで表されます。つまり、「内部の処理が一貫していて（凝集度高）」「外とあまりつながっていない（結合度低）」モジュールが理想です。
モジュール結合度	モジュール結合度とは、モジュール同士がどれだけ密接につながっているかを示す指標です。結合度が低いほど、モジュールは独立しており、変更の影響が広がりにくいです。逆に結合度が高いと、1カ所直すだけで別のモジュールが壊れることがあります。結合度にはいくつかの種類があり、内容結合（最悪）からデータ結合（最良）まで段階があります。良い設計では、常に結合度を低く保つことが目指されます。
内容結合	内容結合は、あるモジュールが別のモジュールの内部コード（関数や変数）を直接参照・書き換えてしまう最も悪い結合です。たとえば、モジュールAがモジュールBの内部変数`x`を勝手に`x = 10`と書き換えるような状態です。これはモジュールの独立性を完全に損ない、バグの原因になります。現代のプログラミングでは、カプセル化（private変数など）でこれを防ぐのが基本です。
共通結合	共通結合は、複数のモジュールが同じグローバル変数や共用メモリ領域を共有している状態です。たとえば、全モジュールが`global_score`という変数を読み書きしていると、どこかで値が変わった理由がわからなくなります。これは内容結合よりマシですが、依然として危険です。共通結合を減らすには、必要なデータは引数で渡すようにし、グローバル変数の使用を最小限にします。
外部結合	外部結合は、モジュールが外部のファイル形式やハードウェア、APIなどの仕様に強く依存している状態です。たとえば、特定のCSV形式にしか対応しない読み込みモジュールは、形式が変わるとすぐ壊れます。これを避けるには、外部とのやりとりを「アダプターモジュール」に閉じ込め、本体のロジックからは切り離すのが有効です。これにより、外部環境の変化に強くなります。
制御結合	制御結合は、あるモジュールが別のモジュールの内部動作を「フラグ」や「コマンド」で制御する結合です。たとえば、モジュールAがモジュールBに`mode=1`と渡して「詳細モードで動け」と指示するようなケースです。これは一見便利ですが、モジュールBの内部ロジックが見え隠れしており、独立性が損なわれます。代わりに、目的に応じた明確な関数（例：`showDetail()`）を用意する方が安全です。
スタンプ結合	スタンプ結合（構造結合とも）は、モジュール間で大きなレコードやオブジェクト全体を渡し、その一部しか使わない状態です。たとえば、ユーザーオブジェクト（名前・年齢・住所・メール…）を丸ごと渡して、先方モジュールが「名前」しか使わない場合です。これは無駄な依存を生み、オブジェクトの構造が変わると影響が広がります。必要なデータだけを渡す「データ結合」に近づけるべきです。
データ結合	データ結合は、モジュール間で必要な最小限のデータだけをやりとりする、最も望ましい結合です。たとえば、合計金額を求めるモジュールに、単価と数量だけを渡すような形です。これにより、モジュール同士の依存が最小限になり、変更の影響範囲が狭くなります。現代のソフトウェア設計では、このデータ結合を目指して、インターフェースをシンプルに保つことが重要です。
モジュール強度	モジュール強度とは、1つのモジュール内での処理がどれだけ「まとまり」を持っているかを示す指標です。これは「結束性（コヒージョン）」とも呼ばれ、強度が高いほど、そのモジュールは単一の目的に特化しており、保守・修正がしやすくなります。たとえば「機能的強度」が最も強く、「偶然的強度」が最も弱いとされます。強度が高いモジュールは再利用性も高く、バグの混入も防ぎやすいです。
暗号的強度	暗号的強度は、モジュール内の要素が「暗号のように関連しているだけ」で、実際には意味的なつながりがない状態を指します。たとえば、複数の無関係な処理を1つのモジュールにまとめただけの場合が該当します。これは「偶然的強度」とも呼ばれ、モジュール強度の中で最も弱いタイプです。保守が非常に難しく、変更時に予期せぬ影響が出やすいため、避けられるべき設計です。
論理的強度	論理的強度とは、似た種類の処理（例：複数の入力処理や出力処理）を1つのモジュールにまとめた状態です。たとえば「すべてのファイル読み込み処理」を1モジュールに集約するなど。見た目は整理されていても、実際には異なる目的の処理が混在しているため、変更時に影響範囲が広がりやすく、中程度以下の強度とされます。
時間的強度	時間的強度は、「同じタイミングで実行される処理」を1つのモジュールにまとめたものです。たとえば、プログラム起動時に初期化する一連の処理を1モジュールにまとめるケース。処理の内容は異なっても「時間的に同時」である点でまとまっていますが、目的がバラバラなため、保守性は低く、強度は中程度と評価されます。
手順的強度	手順的強度とは、処理の流れ（手順）に沿って複数のステップを1モジュールにまとめた状態です。たとえば「データ取得 → 加工 → 出力」といった一連の流れを1つに。処理間に順序関係はあるものの、それぞれの目的が異なるため、機能的ではないとされ、強度は中程度。ただし、フローが明確な分、多少のまとまりはあります。
連絡的強度	連絡的強度（通信的強度）は、複数の処理が「同じデータ（引数やグローバル変数）を共有している」ために1モジュールにまとめられた状態です。たとえば、ある顧客情報を元に「名前表示」「住所表示」「注文履歴表示」を行う場合。共通データがあるためある程度まとまりがありますが、目的が異なるため、強度は中～高と評価されます。
情報的強度	情報的強度は、モジュール内のすべての処理が「同じデータ構造やオブジェクト」を操作するように設計されている状態です。たとえば、ある「商品クラス」に対して「価格更新」「在庫確認」「販売履歴追加」を行うモジュール。共通の情報単位を中心に処理がまとまっており、目的も近いため、強度は高めとされます。
機能的強度	機能的強度は、モジュールが「1つの明確な機能」のみを実現している状態で、モジュール強度の中で最も理想的です。たとえば「ログイン認証を行うモジュール」や「税込金額を計算するモジュール」など。役割が単一で明確なため、テスト・保守・再利用が非常にしやすく、高品質なソフトウェア開発の基本とされています。
領域評価	領域評価とは、モジュール間の結合（カップリング）の強さを評価する手法の一つで、特に「共有領域（グローバル変数など）を通じてやりとりする」設計の問題点を指摘します。共有領域が多いと、モジュール同士が密接に依存し、変更時の影響が広がりやすくなります。このため、領域評価では「共有領域の使用を最小限に抑える」ことが推奨されます。
コード設計	コード設計とは、システム内で使用する「識別子（コード）」をどう定義・構成するかを計画することです。たとえば商品や顧客に割り当てるIDの形式を決める作業。良いコード設計は、データの一意性・可読性・拡張性を確保し、運用ミスを防ぎます。近年では、セキュリティやプライバシー保護の観点から、個人を特定しないコード設計も重要視されています。
順番コード	順番コードは、連番（001, 002, 003…）で識別子を付ける方式です。シンプルで管理しやすく、重複も起きにくいですが、コードから意味が読み取れません。たとえば「注文番号」によく使われます。ただし、連番だと発注量などが推測されてしまうため、セキュリティ上は注意が必要です。2026年現在では、UUIDなどと組み合わせるハイブリッド方式も増えています。
区分コード	区分コードは、対象を「カテゴリごとに分類」してコードを割り当てる方式です。たとえば「部署コード：営業＝10、開発＝20、人事＝30」など。コードを見ただけで所属がわかるため、業務効率が上がります。ただし、分類が増えるとコード体系の見直しが必要になるため、拡張性を考慮した設計が求められます。
桁別コード	桁別コードは、コードの「各桁に意味を持たせる」方式です。たとえば「12345」のうち「1＝地域、23＝店舗、45＝商品カテゴリ」など。コンパクトに多くの情報を表現できますが、桁数が固定されるため柔軟性に欠けます。また、誤解を招きやすいため、マニュアルや辞書の整備が必須です。2026年では、JSONやXMLによるメタデータ併用が一般的です。
表意コード	表意コード（ニモニックコード）は、英単語や略語を使って意味を直感的に伝えるコードです。たとえば「TOKYO」「NYC」「PRD（製品）」「USR（ユーザー）」など。覚えやすく、現場での誤操作を減らせますが、言語や文化によって解釈が分かれる可能性があります。国際システムでは、ISO標準との整合性が重視され、2026年では多言語対応が前提となっています。

テスト

単語	意味
テスト	テストとは、ソフトウェアが仕様通りに動作するかを確認する工程です。バグ（不具合）を見つけ、品質を保証するために不可欠です。テストは「単体テスト」「結合テスト」「システムテスト」「受け入れテスト」など段階があり、近年では自動テストやCI/CD（継続的インテグレーション／デリバリー）と組み合わせて効率化が進んでいます。目的は「正しさの証明」ではなく「不具合の発見」です。
ブラックボックステスト	ブラックボックステストは、内部構造（コード）を一切見ずに、入力と出力の関係だけでテストする方法です。まるで「黒い箱（ブラックボックス）」の中身が見えないまま操作するイメージ。ユーザー視点での検証が可能で、要件ベースのテストに適しています。代表的手法には「同値分析」「限界値分析」などがあり、2026年でも基本中の基本とされています。
同値分析	同値分析は、入力データを「同じ挙動を引き起こすグループ（同値クラス）」に分けて、各グループから1つずつ代表値をテストする手法です。たとえば「年齢入力欄（0～120歳）」なら、「有効クラス：0～120」「無効クラス：-1以下、121以上」に分け、それぞれ1つずつテスト。これにより、テストケース数を大幅に削減できます。式で表すと、テストケース数 ≈ 同値クラス数となります。
限界値分析	限界値分析は、入力の「境界（限界値）」周辺でエラーが起きやすいことに着目したテスト手法です。たとえば「1～100の入力可」なら、0, 1, 2, 99, 100, 101をテストします。経験則として、境界付近でバグが集中するため、効果的です。求め方は、有効限界値：min, min+1, max-1, max 無効限界値：min−1, max+1 とし、これらをテストケースとします。
原因結果グラフ	原因結果グラフは、入力（原因）と出力（結果）の論理的関係を図で表現し、そこからテストケースを導出する手法です。たとえば「ログイン成功＝ID正しい AND パスワード正しい」のような条件をAND/ORで結び、網羅的にテスト設計します。複雑な条件分岐でも漏れを防げ、2026年でも金融・医療系システムで重宝されています。
実験計画法	実験計画法（DOE: Design of Experiments）は、統計学に基づき、少ない試行回数で最適な組み合わせを導き出すテスト手法です。たとえば「ブラウザ×OS×解像度」の組み合わせ爆発を防ぐため、直交表（L9表など）を使い、代表的なパターンだけをテスト。求め方は、因子（変数）と水準（選択肢）を決め、直交配列表に当てはめてテストケースを生成します。効率性と網羅性のバランスが優れています。
ホワイトボックステスト	ホワイトボックステスト（構造ベーステスト）は、プログラムの内部構造（ソースコード）を見て行うテストです。たとえば、if文やfor文の中身がちゃんと動くかを確認します。これは、開発者自身がコードのロジックを理解している前提で行われます。補足：ブラックボックステストが「外から見た動作」を確認するのに対し、ホワイトボックステストは「中身の動き」を検証する点が特徴です。
網羅性	網羅性とは、「どれだけ多くのパターンをテストしたか」を示す指標です。たとえば、100通りの条件があるのに10通りしかテストしていなければ、網羅性は10%です。高い網羅性はバグの見逃しを減らしますが、100%を目指すとコストが膨大になるため、バランスが重要です。補足：網羅性は「カバレッジ」とも呼ばれ、テストの質を評価する基準になります。
命令網羅	命令網羅（ステートメントカバレッジ）は、「すべての命令（コードの1行1行）を少なくとも1回は実行する」テストです。たとえば、if文の中のthen節だけを通ればOKですが、else節は無視しても達成できます。式で表すと「実行された命令数 ÷ 全命令数 × 100%」です。補足：最も基本的な網羅基準ですが、分岐の片方しか見ていないため、不十分な場合があります。
判定条件網羅	判定条件網羅（分岐網羅、ブランチカバレッジ）は、「if文などの分岐で、真（true）と偽（false）の両方を通る」テストです。つまり、ifのthen節とelse節の両方を実行します。式では「実行された分岐数 ÷ 全分岐数 × 100%」で求めます。補足：命令網羅より厳しく、よく使われる基準です。分岐網羅という別名は、プログラムの「枝分かれ」をすべて見るからです。
条件網羅	条件網羅は、「複合条件（例：AかつB）の各部分条件（A、B）をそれぞれ真・偽にする」テストです。たとえば、「A=true, B=false」と「A=false, B=true」のように、各条件を独立に変えてテストします。ただし、全体の結果（AかつB）がどうなるかは問いません。補足：個々の条件が正しく評価されるかを確認できますが、組み合わせまでは保証しません。
判定条件／条件網羅	判定条件／条件網羅（Modified Condition/Decision Coverage, MC/DC）は、条件網羅と判定条件網羅を組み合わせた厳格な基準です。各条件が「単独で判定結果を変える」ことを確認します。たとえば、(AかつB)でAだけを変えて結果が変わるかをテストします。補足：航空機や自動車など安全性が重要なシステムで使われ、ISO 26262などの規格で要求されます。
複数条件網羅	複数条件網羅（複数条件カバレッジ）は、「複合条件のすべての真・偽の組み合わせをテストする」方法です。たとえば、(AかつB)なら、(T,T)、(T,F)、(F,T)、(F,F)の4通りすべてを実行します。条件がn個なら2ⁿ通り必要で、現実的でないことも。補足：完全な網羅ですが、組み合わせ爆発の問題があり、実務ではMC/DCが好まれます。
制御パステスト	制御パステストは、「プログラムの実行経路（パス）をすべて通る」テストです。たとえば、if文が2つあると最大4通りのパスがあります。すべてのパスを通せば、ほぼすべての命令と分岐をカバーできます。補足：理論上は強力ですが、ループがあるとパスが無限になるため、実際には制限付きで使われます。
モジュール集積テスト技法	モジュール集積テスト（結合テスト）は、複数のモジュールを組み合わせてテストする技法です。単体テストでOKだったモジュール同士でも、つなげると不具合が出ることがあります。このテストでインターフェースの問題を発見します。補足：集積の順序として、増加テストの手法が使われます。
増加テスト	増加テストは、モジュールを1つずつ追加しながら結合テストを行う方法です。最初は1つのモジュールから始め、次々に他のモジュールを結合していきます。これにより、どこで不具合が起きたかを特定しやすくなります。補足：代表的な増加テストには、ボトムアップとトップダウンがあります。
ボトムアップテスト	ボトムアップテストは、下位（低レベル）のモジュールから順に結合していく増加テストです。まず部品となるモジュールをテストし、それらを組み上げて上位モジュールをテストします。スタブ（仮の上位モジュール）は不要ですが、ドライバ（呼び出す仮モジュール）が必要です。補足：実装が簡単な部品から始められるため、初期段階で動作確認が可能です。
トップダウンテスト	トップダウンテストは、上位（高レベル）のモジュールから順に結合していく増加テストです。まずメインの制御モジュールをテストし、必要な下位モジュールをスタブ（仮のモジュール）で置き換えます。補足：システム全体の流れを早期に確認できますが、スタブの作成コストがかかるのが欠点です。
折衷テスト	折衷テスト（サンドイッチテスト）は、トップダウンとボトムアップを組み合わせた方法です。上位と下位のモジュールを同時にテストし、中間層で合流させます。これにより、両方の利点を活かしつつ、テスト期間を短縮できます。補足：大規模システムでよく使われ、効率的な結合テストが可能です。
システム結合テスト	システム結合テストは、ハードウェア、ソフトウェア、ネットワークなど、すべての構成品目を組み合わせて行うテストです。モジュール単位ではなく、実際の運用環境に近い形で統合し、相互作用を検証します。補足：このテストで、異なるシステム間の通信エラーや設定ミスなどが明らかになります。
システム適格性確認テスト	システム適格性確認テストは、システムが要求仕様や契約通りに動作するかを最終確認するテストです。顧客やユーザーが関与し、「納品していいか」を判断するフェーズです。補足：受入テストとも呼ばれ、これに合格しないとシステムは本番運用に移れません。
機能テスト	機能テストは、システムが仕様書通りの機能を持っているかを確認するテストです。たとえば、「ログインボタンを押すと画面が切り替わる」など、ユーザー視点の動作を検証します。補足：ブラックボックステストの代表で、内部実装に依存せずに行われます。
性能テスト	性能テストは、システムの応答時間や処理速度、リソース使用量などを測定するテストです。たとえば、「1秒以内に検索結果が表示されるか」などを確認します。補足：性能要件を満たしているかを定量的に評価し、スケーラビリティの目安にもなります。
操作性テスト	操作性テスト（ユーザビリティテスト）は、ユーザーが直感的・快適にシステムを使えるかを評価します。UIの配置、操作手順の分かりやすさ、エラー時の案内などが対象です。補足：アンケートやユーザーテストを通じて主観的な評価も含みます。
障害回復テスト	障害回復テストは、システムがクラッシュやネットワーク切断などの障害から正常に復旧できるかを確認するテストです。たとえば、電源を落として再起動後、データが壊れていないかを検証します。補足：バックアップやロールバック機能の有効性を検証する重要なテストです。
負荷テスト	負荷テストは、システムが想定される最大負荷（例：同時アクセス数1万人）に耐えられるかを確認するテストです。通常の性能テストよりも厳しい条件で実施し、ボトルネックを探します。補足：サーバーのCPUやメモリ使用率も監視し、リソース不足のリスクを洗い出します。
耐久テスト	耐久テスト（ストレステスト）は、長時間・継続的に負荷をかけ、メモリリークや性能劣化がないかを確認するテストです。たとえば、24時間連続で通常の2倍の負荷をかけ続けます。補足：安定稼働に不可欠で、特に金融・医療システムで重視されます。
例外テスト	例外テストは、不正な入力や予期しない操作（例：空欄で送信、数字以外を入力）に対して、システムが適切にエラー処理するかを確認します。クラッシュせずにユーザーに警告を表示するかがポイントです。補足：セキュリティ対策の一環としても重要で、堅牢性を高めます。
運用テスト	運用テストは、システムの日常的な運用（バックアップ、監視、メンテナンス）がスムーズに行えるかを確認するテストです。たとえば、夜間バッチ処理が正しく実行されるかなどを検証します。補足：開発者だけでなく、運用チームが主体となって行うのが特徴です。
リグレッションテスト	リグレッションテストは、修正や追加機能によって、既存の機能が壊れていないかを確認するテストです。「後退テスト」とも言い、自動化ツール（例：Selenium）で繰り返し実行されます。補足：ソフトウェアの品質維持に不可欠で、DevOpsではCI/CDパイプラインに組み込まれます。
探索的テスト	探索的テストは、事前の計画を最小限にし、テスト実行中に得た情報をもとに次のテストを即座に決める柔軟な手法です。経験豊富なテスターが、直感や想像力を駆使してバグを探します。補足：仕様が曖昧な新規サービスや、創造的な観点からの検証に有効です。
ファジング	ファジングは、ランダムまたは半ランダムな不正なデータ（ファズ）を大量に入力し、クラッシュや脆弱性を引き出すテストです。たとえば、Webフォームに記号や超長文字列を送信します。補足：セキュリティテストの定番で、OWASPやNISTでも推奨されています。2026年現在、AIを使ったスマートファジングが注目されています。

テスト管理手法

単語	意味
テスト管理手法	テスト管理手法とは、ソフトウェアの品質を保証するために、テスト計画・実施・評価を体系的に行う方法です。たとえば、テストケースを整理したり、バグの進捗を追跡したりします。代表的なツールにはJIRAやTestRailがあり、2026年現在も継続的にクラウド連携やAI活用が進んでいます。目的は「いつ・誰が・何をテストしたか」を明確にし、漏れや重複を防ぐことです。
バグ管理図	バグ管理図（Bug Trend Chart）は、テスト中に発見されたバグの数や修正状況を時系列で可視化したグラフです。横軸に日付、縦軸にバグ件数を取り、新規・未修正・修正済みの推移を色分けして表示します。これにより、「バグが増え続けている＝品質が不安定」や「修正が追いついている＝リリース可能」などの判断が可能になります。
ソフトウェアの信頼度成長モデル	信頼度成長モデル（Reliability Growth Model）は、テストを繰り返すことでソフトウェアの信頼性がどう向上するかを数理的に予測するモデルです。代表例にゴーモデル（Goel-Okumoto model）があります。このモデルでは、時間 t までに発見される累積バグ数 m(t) を m(t)=N(1−e−βt) と表し、N は総バグ数、β は発見率を示します。これにより、残りバグ数やリリース時期の目安が立てられます。
バグ管理	バグ管理とは、ソフトウェアの不具合（バグ）を発見から修正・検証まで一元的に追跡・記録するプロセスです。各バグには「重要度」「優先度」「担当者」「ステータス（新規・修正中・完了など）」といった属性を付与し、チーム全体で共有します。これにより、重大なバグを見逃さず、効率的な修正が可能になります。
バグ数の推測方法	バグ数の推測には、過去の類似プロジェクトのデータや信頼度成長モデルを用います。また、コード行数（LOC）や複雑度（Cyclomatic Complexity）から経験則で推定することもあります。たとえば、「1KLOC（1,000行）あたり0.1～1個のバグ」といった業界平均値を使う方法です。ただし、2026年ではAIによる静的解析でより精度の高い予測が主流になりつつあります。
バグ埋込み法	バグ埋込み法（Seed Bug Method）は、あらかじめ開発者が意図的にバグ（シードバグ）をプログラムに埋め込み、テストでどれだけ見つけられたかから、全体の残りバグ数を推定する方法です。全体の残りバグ数 B は、 B=(T−S)⋅SF ではなく、正確には次の式で求めます。実際に発見された全バグ数を T、そのうち埋め込んだバグ数（発見済み）を F、埋め込んだ総バグ数を S とすると、残りバグ数=(T−F)⋅(S−F)F ですが、一般的には単純な比例推定推定総バグ数=T⋅SF を用い、そこから既発見バグ T を引いて残りを推定します。
2段階エディット法	2段階エディット法は、まず自動ツールで構文チェック（1段階）を行い、その後人が論理的誤りを確認（2段階）するレビュー手法です。求め方というより「手順」ですが、効果測定には「1段階で検出されたエラー数 E1」と「2段階で追加検出されたエラー数 E2」を記録し、検出率=E1+E2推定総エラー数で評価します。2026年では、1段階にAIコーディングアシスタント（例：GitHub Copilot）を活用するのが一般的です。

レビュー

単語	意味
レビュー	レビューとは、ソフトウェアの成果物（設計書・コード・テストケースなど）を関係者で点検し、欠陥を早期に発見する活動です。コードを動かす前にミスを潰せるため、コスト削減と品質向上に非常に有効です。高校生で言えば、「友達に作文を添削してもらう」ようなものです。
レビューの種類	レビューには、非公式なもの（例：ペアプログラミング中の会話）から、正式な会議形式（例：インスペクション）までさまざまあります。主な種類として、ウォークスルー、ピアレビュー、インスペクション、承認レビューなどがあり、目的や参加者、厳格さが異なります。
承認レビュー	承認レビューは、プロジェクトの重要なマイルストーン（例：基本設計完了）で、上位管理者や顧客が成果物を正式に承認するためのレビューです。ここを通らないと次のフェーズに進めません。品質だけでなく、予算・スケジュールとの整合性も確認されます。
成果物レビュー	成果物レビューは、ドキュメントやコードなど「何かを作った結果」に対して行うレビュー全般を指します。設計書なら仕様の矛盾、コードならバグや可読性、テストケースなら網羅性をチェックします。すべてのレビューは、この成果物レビューの一種です。
ピアレビュー	ピアレビューは、同僚（ピア）同士で互いの成果物をチェックし合う方法です。上下関係がなくフラットなため、気軽に意見が言いやすく、学習効果も高いです。GitHubのプルリクエスト機能を使ったコードレビューが、2026年でも最も広く使われているピアレビューの形です。
ウォークスルー	ウォークスルーは、作成者が自分の成果物を説明しながら、参加者が疑問を投げかけたり誤りを指摘したりする非公式なレビューです。役割分担は特に決まっておらず、雰囲気は勉強会に近いです。目的は「理解を深めること」に重きを置きます。
インスペクション	インスペクションは、モデレータ・レビューア・作者・記録係など役割を明確に分け、事前準備と正式な会議で厳密に欠陥を洗い出す最もフォーマルなレビュー手法です。IEEE標準にもなっており、航空宇宙や医療機器など高信頼性が求められる分野で使われます。
ラウンドロビンのレビュー	ラウンドロビンレビューは、複数のレビューアが順番に（または同時に）同じ成果物を独立してレビューし、結果を統合する方法です。偏りを防ぎ、多角的な視点を得られますが、工数がかかります。オンラインツールで並行レビューできる環境が2026年では整っています。
パスアラウンド	パスアラウンドは、成果物を紙やPDFなどでレビューアに回覧し、各自がコメントを書き込んで次の人に渡す非同期レビューです。会議を開かなくてよいのでコストが低く、忙しい人でも参加しやすいですが、議論が深まらない欠点があります。
デザインレビュー	デザインレビューは、システムやソフトウェアの設計段階で行う専門的なレビューで、アーキテクチャの妥当性・拡張性・保守性などを評価します。UML図やER図を用い、設計ミスが後工程で大きな損害にならないよう早期に防ぎます。
形式手法	形式手法（Formal Method）は、数学的論理（例：述語論理・オートマトン理論）を用いて仕様や設計の正しさを証明する超厳密なレビュー技法です。たとえば、「このプログラムは絶対にクラッシュしない」ことを証明できます。難易度が高いため限られた分野（鉄道制御・暗号プロトコルなど）で使われていますが、2026年には一部のAI安全基準にも応用され始めています。