読み込み中...
読み込み中...
読み込み中...
読み込み中...
読み込み中...
ソフトウェアを作るとき、いきなりプログラミングを始めるわけではありません。「何を作るか決める → 設計する → 作る → テストする → 使い始める」という流れがあります。この流れの進め方を 開発モデル と呼びます。
家を建てることに例えると分かりやすいです。家を建てるとき、まず「どんな家が欲しいか」を決め（要件定義）、設計図を描き（設計）、実際に工事をし（実装）、完成検査をして（テスト）、引き渡します。ソフトウェア開発もこれと同じ流れですが、家と違って「途中で間取りを変えたい」という要望に柔軟に対応しやすいのがソフトウェアの特徴です。
このセクションでは、代表的な開発モデルと、開発プロセスの標準的な枠組みである 共通フレーム を学びます。
開発工程を 上流から下流へ順番に 進める最も基本的な開発モデルです。水が上から下へ流れ落ちる（waterfall）ように、前の工程が完了してから次の工程に進みます。原則として 前の工程には戻らない ことを前提とします。
| 特徴 | 説明 |
|---|---|
| 利点 | 計画が立てやすい、進捗管理がしやすい、大規模開発に向く |
| 欠点 | 上流の誤りが下流で発覚すると手戻りが大きい、要件変更に弱い |
| 適した場面 | 要件が明確で変更が少ないプロジェクト（基幹業務システム等） |
ウォーターフォールモデルの最大の弱点は、要件定義の誤りがテスト段階まで発見されないと、大幅な手戻りが発生することです。この弱点を補うために、次に紹介する様々なモデルが考案されました。
開発の早い段階で 試作品（プロトタイプ） を作り、利用者に確認してもらうことで要件の認識のずれを防ぐモデルです。
家づくりで例えると、設計図だけでなく 模型（ミニチュア） を作って「こんな感じの家になりますがどうですか？」と確認してから本格的に建築を始めるイメージです。
| 特徴 | 説明 |
|---|---|
| 利点 | 利用者が早い段階でイメージを確認できる、要件の誤解を早期に発見できる |
| 欠点 | プロトタイプ作成のコストがかかる、プロトタイプがそのまま本番に使われてしまうリスク |
| 適した場面 | ユーザーインターフェースの要件が不明確なプロジェクト |
システムを サブシステム（機能単位） に分割し、サブシステムごとに「設計 → 実装 → テスト」のサイクルを 繰り返す モデルです。各サイクルでプロトタイピングを行い、リスクを段階的に解消していきます。
| 特徴 | 説明 |
|---|---|
| 利点 | リスクを早期に発見・対処できる、段階的に完成度を高められる |
| 欠点 | 全体の進捗管理が難しい、開発期間が見積もりにくい |
| 適した場面 | 大規模で技術的リスクが高いプロジェクト |
短い期間（1〜4週間） のサイクルを繰り返し、動くソフトウェアを 小さな単位で素早く リリースしていく開発手法の総称です。「agile」は「素早い」「機敏な」という意味です。
家づくりで例えると、最初から豪邸を建てるのではなく、まず「住める小屋」を建てて住み始め、必要に応じて部屋を増築していくイメージです。
スクラム（Scrum） が最も広く使われている手法です。
| 要素 | 説明 |
|---|---|
| プロダクトオーナー | 製品の責任者。何を作るか（優先順位）を決める |
| スクラムマスター | チームの進行役。障害を取り除く |
| 開発チーム | 実際に開発を行うメンバー（通常3〜9人） |
| プロダクトバックログ | 実装すべき機能の一覧（優先順位付き） |
| スプリント | 1〜4週間の開発サイクル |
| スプリントレビュー | スプリント終了時に成果物をデモする |
| デイリースクラム | 毎日15分程度の短い進捗報告ミーティング |
| レトロスペクティブ | スプリント終了時にチームの改善点を振り返る |
XP（エクストリームプログラミング） は技術的なプラクティスを重視する手法です。
| プラクティス | 説明 |
|---|---|
| ペアプログラミング | 2人1組でプログラミングする。リアルタイムでコードレビュー |
| テスト駆動開発（TDD） | テストを先に書き、テストが通るようにコードを書く |
| リファクタリング | 動作を変えずにコードの内部構造を改善する |
| 継続的インテグレーション（CI） | コードを頻繁に統合し、自動テストで品質を確認する |
開発チーム（Development） と 運用チーム（Operations） が密に連携し、ソフトウェアの開発からリリース・運用までを 自動化・迅速化 する考え方です。
従来、開発チームは「新しい機能を素早くリリースしたい」、運用チームは「安定稼働を維持したい（変更は最小限にしたい）」という対立する目標を持っていました。DevOps はこの壁を取り払い、両チームが一体となって取り組みます。
| プラクティス | 説明 |
|---|---|
| CI（継続的インテグレーション） | コード変更のたびに自動ビルド・自動テストを実行 |
| CD（継続的デリバリー/デプロイ） | テスト済みのコードを自動的に本番環境へ反映 |
| Infrastructure as Code（IaC） | インフラ構成をコードで管理し、環境構築を自動化 |
| モニタリング | 本番環境の状態を常時監視し、異常を即座に検知 |
| モデル | 進め方 | 要件変更への対応 | 適した規模 |
|---|---|---|---|
| ウォーターフォール | 上流→下流を1回 | 困難 | 大規模・要件固定 |
| プロトタイピング | 試作品で確認後に開発 | 早期に修正可能 | 中小規模 |
| スパイラル | 機能単位でサイクル反復 | 各サイクルで対応 | 大規模・高リスク |
| アジャイル | 短いスプリントで反復 | 柔軟に対応 | 中小規模・要件変動 |
| DevOps | 開発と運用の一体化 | CI/CD で迅速に対応 | 全規模 |
共通フレーム とは、ソフトウェアの開発や取引において、発注者と受注者が 共通の用語・作業内容で認識を合わせる ための枠組みです。正式名称は SLCP （Software Life Cycle Process）で、国際規格 ISO/IEC 12207 を日本の慣行に合わせたものが 共通フレーム 2013 です。
共通フレームは、ソフトウェアのライフサイクル全体を以下のようなプロセスに分類しています。
| プロセス | 内容 |
|---|---|
| 企画プロセス | システム化構想、システム化計画の立案 |
| 要件定義プロセス | 業務要件・機能要件・非機能要件の定義 |
| 開発プロセス | 設計・実装・テスト |
| 運用プロセス | 本番環境での稼働、監視 |
| 保守プロセス | 障害対応、機能改善、是正保守・適応保守・完全化保守・予防保守 |
| 保守の種類 | 目的 | 例 |
|---|---|---|
| 是正保守 | 発見された障害の修正 | バグ修正 |
| 適応保守 | 環境変化への対応 | OS アップデートへの対応 |
| 完全化保守 | 性能改善や機能追加 | 処理速度の向上 |
| 予防保守 | 将来の問題を未然に防止 | 潜在的な不具合の事前修正 |
共通フレームを使うことで、「要件定義」「基本設計」などの言葉が開発者と発注者の間で同じ意味になり、認識のずれによるトラブルを防げます。
ポイント
ウォーターフォール は上流→下流を順に進め、前工程に戻らない原則。計画しやすいが要件変更に弱い。 プロトタイピング は試作品で早期確認。 スパイラル はサブシステム単位でサイクルを反復しリスクを段階的に解消。 アジャイル は1〜4週間のスプリントで動くソフトを素早くリリース。代表手法はスクラム（プロダクトオーナー・スクラムマスター・スプリント）と XP（ペアプログラミング・TDD・リファクタリング）。 DevOps は開発と運用の一体化で CI/CD が核。 共通フレーム（SLCP） は ISO/IEC 12207 に基づく日本版の標準プロセス。保守は是正・適応・完全化・予防の4種。
用語
ソフトウェア開発では、いきなりプログラムを書き始めるのではなく、 何を作るかを明確にし （要件定義）、 どう作るかを決め （設計）、 正しく動くかを確かめる （テスト）という一連の工程を経ます。
家づくりに例えると、「4人家族で3LDK、駐車場付き」が要件定義、「間取り図を描く」が外部設計、「配管や電気の設計」が内部設計、「完成検査」がテストに当たります。
このセクションでは、ウォーターフォールモデルの各工程に沿って 設計の段階 と、各設計に対応する テストの段階 を体系的に学びます。特に試験で頻出の Vモデル による設計とテストの対応関係が重要です。
システムに求められる要件を明確にする工程です。利用者（顧客）の業務や要望をヒアリングし、 何を実現すべきか を文書化します。
| 種類 | 説明 | 例 |
|---|---|---|
| 機能要件 | システムが実現すべき機能 | 「商品を検索できる」「カートに追加できる」 |
| 非機能要件 | 性能・信頼性・セキュリティなど機能以外の要件 | 「応答時間3秒以内」「稼働率99.9%」「SSL暗号化」 |
非機能要件は見落とされがちですが、本番稼働後のトラブルの多くは非機能要件の不備に起因します。
システムの 利用者から見える部分 を設計する工程です。「何を」作るかを決めます。
| 設計項目 | 内容 |
|---|---|
| 画面設計 | 画面レイアウト、入力項目、操作の流れ |
| 帳票設計 | 出力帳票のレイアウト、出力項目 |
| データベース設計（論理設計） | ER図、テーブル定義 |
| 外部インターフェース設計 | 他システムとの連携方法、データ形式 |
| コード設計 | コード体系の決定（商品コード、顧客コードの形式） |
外部設計で決めた内容を どのように実現するか を技術的に設計する工程です。開発者向けの設計であり、利用者には見えない内部構造を決定します。
| 設計項目 | 内容 |
|---|---|
| モジュール分割 | プログラムを機能単位に分割 |
| データベース物理設計 | インデックス、パーティション、テーブルスペース |
| 入出力詳細設計 | バリデーション仕様、エラーメッセージ |
| アルゴリズム設計 | 処理手順の詳細化 |
各モジュールの内部ロジックを詳細に設計します。フローチャートや擬似コード（疑似言語）でアルゴリズムを記述し、プログラミングの直前段階となります。
プログラムを適切な単位（モジュール）に分割することで、開発効率と保守性が向上します。良い分割の原則は モジュール強度を高く、モジュール結合度を低く することです。
モジュール内部の機能の関連度合いです。 強いほど良い 設計です。
| 強度（高い順） | 説明 |
|---|---|
| 機能的強度 | 1つの機能だけを実行する（最も良い） |
| 情報的強度 | 同じデータ構造を扱う複数の機能をまとめる |
| 連絡的強度 | データを受け渡しながら順に実行する機能をまとめる |
| 手順的強度 | 順に実行するが、データの受け渡しがない機能をまとめる |
| 時間的強度 | 同じ時点で実行する機能をまとめる（初期化処理等） |
| 論理的強度 | 類似の機能をフラグで切り替える（入力種別で処理分岐等） |
| 暗合的強度 | 関連のない機能をたまたままとめた（最も悪い） |
モジュール間の依存度合いです。 低いほど良い 設計です。
| 結合度（低い順） | 説明 |
|---|---|
| データ結合 | 必要なデータだけを引数で渡す（最も良い） |
| スタンプ結合 | データ構造（レコード等）を丸ごと渡す |
| 制御結合 | 制御用のフラグやスイッチを渡して動作を変える |
| 外部結合 | 外部宣言されたデータを共有する |
| 共通結合 | グローバル変数（共通領域）を介してデータを共有する |
| 内容結合 | 他のモジュールの内部を直接参照・変更する（最も悪い） |
試験対策のポイント: モジュール強度は「高いほど良い」、モジュール結合度は「低いほど良い」。「強度が高く結合度が低い」= 独立性が高い 良いモジュール設計です。
ウォーターフォールモデルの設計工程とテスト工程を V 字型に対応づけたモデルです。各設計段階に対応するテスト段階があり、 設計で決めたことをテストで検証する という対応関係を示します。
| 設計工程 | 対応するテスト | 検証内容 |
|---|---|---|
| 要件定義 | 受入テスト（承認テスト） | 利用者の要件を満たしているか |
| 外部設計 | システムテスト（総合テスト） | システム全体が仕様通りに動作するか |
| 内部設計 | 結合テスト（統合テスト） | モジュール間の連携が正しいか |
| プログラム設計 | 単体テスト（ユニットテスト） | 個々のモジュールが正しく動作するか |
個々のモジュール（関数・メソッド等）が設計通りに動作するかを検証するテストです。テスト技法として ホワイトボックステスト を使います。
プログラムの 内部構造（ソースコード） に着目してテストケースを作成する技法です。「白い箱」なので中身が見える＝コードの中身を見てテストします。
| カバレッジ基準 | 条件 |
|---|---|
| 命令網羅（ステートメントカバレッジ） | すべての命令（文）を少なくとも1回実行する |
| 分岐網羅（ブランチカバレッジ） | すべての分岐の真偽を少なくとも1回実行する |
| 条件網羅（コンディションカバレッジ） | すべての条件の真偽を少なくとも1回実行する |
| 複合条件網羅 | すべての条件の真偽の組み合わせを実行する |
例: if (A && B) という条件がある場合
カバレッジの網羅度は 命令網羅 < 分岐網羅 < 条件網羅 < 複合条件網羅 の順に高くなります。
プログラムの 外部仕様（入出力） に着目してテストケースを作成する技法です。「黒い箱」なので中身が見えない＝コードの中身を知らなくてもテストできます。主に結合テスト以降で使用します。
| 技法 | 説明 | 例 |
|---|---|---|
| 同値分割 | 入力値を「同じ結果になるグループ（同値クラス）」に分け、各グループから代表値をテスト | 年齢入力（0〜17: 未成年、18〜64: 成人、65〜: 高齢者）から各1つ |
| 境界値分析 | 同値クラスの境界にある値をテスト。バグは境界に集中する | 17, 18, 64, 65 をテスト |
| 原因結果グラフ | 入力条件（原因）と出力（結果）の関係をグラフ化し、デシジョンテーブルを作成 | 複数条件の組み合わせテスト |
| デシジョンテーブル（決定表） | 条件と動作の全組み合わせを表にまとめる | 割引条件（会員/非会員 × クーポン有/無）の網羅 |
ホワイトボックスとブラックボックスの使い分け:
| 比較項目 | ホワイトボックステスト | ブラックボックステスト |
|---|---|---|
| 着目点 | 内部構造（コード） | 外部仕様（入出力） |
| テスト設計者 | 開発者 | テスト担当者・利用者 |
| 主な使用場面 | 単体テスト | 結合テスト〜受入テスト |
| 利点 | 論理的な網羅性を確保 | 仕様通りの動作を確認 |
複数のモジュールを組み合わせ、モジュール間の インターフェース（データの受け渡し） が正しいかを検証するテストです。
| 方式 | 説明 |
|---|---|
| トップダウンテスト | 上位モジュールから下位モジュールへ順に結合。未完成の下位モジュールは スタブ で代替 |
| ボトムアップテスト | 下位モジュールから上位モジュールへ順に結合。未完成の上位モジュールは ドライバ で代替 |
| ビッグバンテスト | すべてのモジュールを一度に結合。障害の原因特定が難しい |
試験で問われるポイント: 「スタブ」と「ドライバ」の区別。スタブは 下位 モジュールの代わり（トップダウンで使う）、ドライバは 上位 モジュールの代わり（ボトムアップで使う）。
システム全体が外部設計の仕様を満たしているかを検証するテストです。機能テストに加え、 非機能要件 （性能、負荷、セキュリティ、障害復旧等）のテストも行います。
利用者（発注者） が実施するテストです。要件定義で定めた要件を満たしているか、業務で使えるかを確認します。このテストに合格すると、システムの 検収（受入れ） が行われ、開発が完了となります。
ポイント
設計は要件定義 → 外部設計 → 内部設計 → プログラム設計の順。 Vモデル で各設計に対応するテストが決まる（要件定義↔受入テスト、外部設計↔システムテスト、内部設計↔結合テスト、プログラム設計↔単体テスト）。 ホワイトボックステスト は内部構造に着目（命令網羅・分岐網羅・条件網羅）、 ブラックボックステスト は外部仕様に着目（同値分割・境界値分析）。結合テストでは トップダウン はスタブ、 ボトムアップ はドライバを使う。モジュール設計は 強度が高く結合度が低い ほど良い。
用語
テストだけでは品質は確保できません。テストの前段階で 設計書やコードを人の目で確認する「レビュー」 と、プロジェクト全体で品質を数値で管理する 品質管理 の仕組みが重要です。
レビューは、家づくりでいえば工事の途中で「設計図通りに建てているか」「配管に問題はないか」を第三者がチェックすることに当たります。工事が終わってから問題が見つかるよりも、途中で発見したほうが修正コストは圧倒的に小さくなります。ソフトウェア開発も同じで、上流工程でのレビューほど効果が高いとされています。
レビューには形式の違いによりいくつかの技法があります。
| 技法 | 説明 |
|---|---|
| インスペクション | 訓練された モデレータ（進行役） が主導する最も公式なレビュー。参加者が事前にレビュー対象を読み、会議で欠陥を指摘。発見された欠陥は記録・追跡する |
| ウォークスルー | 作成者 がレビュー対象を説明しながら参加者と一緒に確認する。インスペクションより非公式 |
| ラウンドロビンレビュー | 参加者が 持ち回り でレビュー対象を説明し、全員でチェックする |
| ピアレビュー | 同僚（ピア）同士でコードや設計書をチェックし合う。日常的に行う非公式なレビュー |
インスペクションはFE試験で特に問われやすいため、詳しく押さえましょう。
インスペクションとウォークスルーの違いは「誰が主導するか」です。インスペクションは モデレータ 、ウォークスルーは 作成者 が主導します。
ソフトウェアの品質を体系的に評価するための国際規格が ISO/IEC 25010 です。ソフトウェアの品質を 8つの特性 に分類しています。
| 品質特性 | 説明 | 具体例 |
|---|---|---|
| 機能適合性 | 要求された機能を正しく提供しているか | 計算結果が正確、必要な機能が揃っている |
| 性能効率性 | 資源の使用量に対して適切な性能か | 応答時間が短い、メモリ消費が少ない |
| 互換性 | 他のシステムと情報交換・共存できるか | 他システムとのデータ連携、同一環境での共存 |
| 使用性 | ユーザーにとって使いやすいか | 操作が直感的、学習コストが低い |
| 信頼性 | 障害なく正常に動作し続けるか | 障害からの回復、一定時間の安定稼働 |
| セキュリティ | 不正アクセスからデータを保護できるか | 認証、アクセス制御、暗号化 |
| 保守性 | 修正や変更がしやすいか | コードが読みやすい、モジュール化されている |
| 移植性 | 他の環境に移行しやすいか | 異なるOSでの動作、インストールの容易さ |
試験では「〜に該当する品質特性はどれか」という形式で出題されます。各特性の定義を正確に理解しておきましょう。
覚え方のコツ: 「 機 能・ 性 能・ 互 換・ 使 用・ 信 頼・ セ キュリティ・ 保 守・ 移 植」→「きせいごしようしんせほい」と頭文字で覚える方法もあります。
テスト工程で発見されるバグ（欠陥）の 累計数 を時間軸でグラフにしたものです。別名 ゴンペルツ曲線 とも呼ばれます。
信頼度成長曲線は S 字型（緩やかな立ち上がり → 急増 → 収束）を描くのが理想的です。
| 曲線の形状 | 意味 | 対応 |
|---|---|---|
| S 字型（理想） | バグが順調に発見され、収束に向かっている | テスト終了の目安 |
| 収束しない（右肩上がり） | バグが次々と見つかり続けている | 品質が低い。設計からの見直しが必要 |
| 早期に横ばい | テスト初期でバグがほとんど見つからない | テストが不十分な可能性。テストケースの見直し |
信頼度成長曲線が収束（横ばい）に達したとき、「これ以上テストしてもバグは見つからない」と判断し、テスト終了の根拠とします。ただし、早期に横ばいになった場合は、テスト自体の質が低い（バグを見逃している）可能性があるため注意が必要です。
テストがプログラムのどの程度を網羅しているかを数値で表す指標です。
テストカバレッジ = (テストで実行された項目数 / 全項目数) x 100 [%]
例えば、プログラムに100個の分岐があり、テストで80個の分岐を実行した場合:
| 種類 | 測定対象 |
|---|---|
| 命令カバレッジ（C0） | 全命令のうち実行された命令の割合 |
| 分岐カバレッジ（C1） | 全分岐のうち実行された分岐の割合 |
| 条件カバレッジ（C2） | 全条件の真偽のうち実行された割合 |
カバレッジが高いほどテストの網羅性は高いですが、100% でも全てのバグを発見できるとは限りません。カバレッジは品質の 必要条件 であって 十分条件 ではないことを理解しておきましょう。
テスト工程の進捗と品質を管理するためのグラフです。以下の3つの曲線を同一グラフ上にプロットします。
| 曲線 | 説明 |
|---|---|
| テストケース消化数（累計） | テストの進捗を示す |
| バグ検出数（累計） | 品質の状況を示す（信頼度成長曲線） |
| バグ未修正数 | 残存するリスクを示す |
バグ検出数が収束し、未修正数がゼロに近づいたとき、テスト完了と判断できます。
ポイント
レビュー技法は インスペクション （モデレータ主導、最も公式）と ウォークスルー （作成者主導）を区別する。品質特性 ISO/IEC 25010 は8つ（機能適合性・性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性）。 信頼度成長曲線 は S 字型が理想で、収束すればテスト終了の目安。収束しなければ品質不足、早期横ばいはテスト不足を疑う。 テストカバレッジ は C0（命令）< C1（分岐）< C2（条件）の順に網羅度が高い。カバレッジが高くても全バグ発見の保証はない。
用語