はじめに
応用情報技術者試験に向けて勉強を進める中で、「情報システム開発」分野の重要キーワードを自分なりに整理しました。
この分野は、出題範囲が幅広く、以下のような特徴があります：
- 要件定義からテストまで、ソフトウェア開発プロセスの全体像を問われる
- ウォーターフォールやアジャイル、UMLなど幅広い手法が登場
- 言葉の意味や違いが曖昧だと問題文の意図を読み違える可能性が高い
そこで本記事では、次のような方針で用語をまとめています。
✅ 各用語の「正しい定義」をできるだけシンプルに整理
✅ 思い出しやすくなるような「ゆるい補足メモ」付きで補完
あくまで自分用の整理メモですが、
同じように応用情報技術者試験に取り組んでいる方や開発プロセスを体系的に学び直したい方の参考になれば幸いです。
1. 共通フレームとV字モデル
共通フレーム（SLCP-JCF）
ソフトウェア開発やシステム構築における 「共通のものさし（枠組み）」 を提供するガイドライン。
正式名称は「ソフトウェアライフサイクルプロセス共通フレーム（SLCP-JCF）」。
📝memo：
プロジェクトに関わる人たちが「共通言語」で会話できるようにするためのルールブック。
「要件定義って何？」「開発ってどこからどこまで？」のズレをなくすための基準。
ソフトウェアライフサイクル
システムやソフトウェアの企画〜廃棄までを一連のフェーズとして捉える考え方。
JCFでは以下のようなプロセス区分が定義されている：
- 企画（事業企画／システム企画）
- 要件定義
- システム開発（方式設計、ソフトウェア設計、構築、テスト）
- 導入・運用・保守・廃棄
📝memo：
システムは作って終わりじゃなくて「育てていく」もの。
運用や保守も立派なライフサイクルの一部。
V字モデル
開発工程とテスト工程をV字型に対応させた開発モデル。
左側が設計フェーズ（上流）、右側が検証フェーズ（下流）で、それぞれの工程が対応している。
| 左側（開発工程） | 対応する右側（テスト工程） | 備考 |
|---|---|---|
| システム化の方向性・計画 | ― | ※超上流工程。品質確認の対象外とされることが多い。 |
| 要件定義 | ― | ※同じく超上流工程。対になるテスト工程は存在しない。 |
| システム要件定義 | システム適格性確認テスト | システム全体が要件通りに実現されているかを確認。業務視点の受入テストに近い。 |
| システム方式設計 | システム結合テスト | サブシステムや外部IFを含む結合。システム間インタフェースが対象。 |
| ソフトウェア要件定義 | ソフトウェア適格性確認テスト | ソフト単体が仕様通りに動作するかを検証。ブラックボックス視点のテスト。 |
| ソフトウェア方式設計 | ソフトウェア結合テスト | モジュール間連携や内部インタフェースの確認。 |
| ソフトウェア詳細設計 | ソフトウェアユニットテスト | 単体の関数・クラス等の内部構造をテスト。 |
| ソフトウェア構築（コーディング） | ― | ― |
📝memo：
上流工程の「xx要件定義」は下流工程の「xx適格性確認テスト」と対になる
上流工程の「xx方式設計」は下流工程の「xx結合テスト」と対になる
要件定義
ステークホルダー（利害関係者）からの要求を洗い出し、「システムに何を求めるか」を文書化。
機能要件
システムが“できるべきこと”（例：ログイン、データ検索）
非機能要件
性能、信頼性、保守性、セキュリティなどの“質的側面”
📝memo：
「ユーザーがやりたいこと」を“漏れなく・ダブりなく”整理する。
ここでのブレはあとあとまで響く。
システム要件定義
「要件定義」で整理した要求を、システム全体でどう実現するかを明確にする。
- サブシステム・外部システムとのインタフェース
- データフロー、業務プロセスとのマッピング
📝memo：
“業務目線”から“システム目線”へと視点が移る段階。
抽象的だった要求を、実装可能な粒度へ落とし込む。
システム方式設計
システム全体を構成するハード・ソフトの分担を明確にする。
- 機能配分（サーバ／クライアント、Web／バッチなど）
- ネットワーク構成・セキュリティ設計
- DB設計方針、性能設計
📝memo：
「どの機能をどこで処理する？」を考えるフェーズ。アーキテクチャ設計ともいえる。
ソフトウェア要件定義
システム方式設計に基づき、ソフトウェア（アプリ）が持つべき機能を定義。
- 画面仕様、入力チェック、業務ロジック
- ファイル・帳票などの出力要件
📝memo：
「このソフトは何ができればよいか？」という視点。詳細な業務フローと連携する。
ソフトウェア方式設計
ソフトウェア要件を達成するための、構造的な設計を行う。
- モジュール分割（どんな部品に分けるか）
- インタフェース仕様、呼び出し関係
📝memo：
「誰が誰を呼び出す？」を決める段階。
結合度やモジュール強度の話が出てくる。
ソフトウェア詳細設計
各モジュールの中身を設計する。ロジックやデータ構造を明確化。
- 制御構造、条件分岐
- 使用する変数、関数の仕様
📝memo：
実装直前の“レシピ作り”フェーズ。
コーディング担当がこの設計書をもとにプログラムを実装。
2. ウォーターフォールモデル
システム開発を上流から下流へと一方向に流れる滝のように進める開発手法。
各工程は明確に分かれており、原則として前工程が完了してから次工程へ進むスタイルを取る。
各工程の解説とポイント
| 工程名 | 解説 | 📝memo（補足） |
|---|---|---|
| 要件定義 | 利害関係者からの要求を収集し、システムで何を実現するかを決める | “どんな問題を、どう解決したいか”を固める。 |
| 外部設計（基本設計） | システムが外からどう見えるか、ユーザーとのやり取り、画面・帳票設計などを決める | 「ユーザーから見える仕様」を設計するフェーズ。UI/UXもここで検討することが多い |
| 内部設計（詳細設計） | 実装に必要な内部構造や処理の流れを詳細に決める | 実装担当がそのまま書けるレベルまで分解する。フローチャートや擬似コードが活躍 |
| プログラミング | 設計書に基づいてコーディングを行う | 詳細設計通りに実装できれば理想。でもここで“設計のアラ”に気づくことも多い |
| 単体テスト | モジュール単位でテスト。正しい処理が行われているかを検証 | 関数・クラス単位で動作確認。「部品テスト」的なイメージ |
| 結合テスト | 複数のモジュールを組み合わせて、連携が正常に動作するかを確認 | 連携バグがよく出るところ。テストデータの設計も重要 |
| システムテスト | システム全体を通した動作確認。要件通り動くかを検証 | 納品前の最終検証。パフォーマンステストや障害系テストも含まれることがある |
| 運用・保守 | リリース後の運用や障害対応、変更への対応など | ウォーターフォールの外だけど、実は一番長く付き合うフェーズ |
ウォーターフォールモデルのメリット
- 各工程が文書化されていて明確
- スケジュールが立てやすい
- 進捗が管理しやすい
📝memo：
要件が最初に固まっている場合には最適。公共系・大規模案件でよく使われる。
ウォーターフォールモデルのデメリット
- 後戻りが難しい（上流のミスが下流で大事故に）
- 要件変更に弱い
- 動くものが見えるのが最後の方
📝memo：
“動いてから見えてくる課題”に気づきづらいのが弱点。
3. アジャイル開発
変化に強く、柔軟に対応することを重視した開発手法。
ウォーターフォールのように全てを最初に決めてから作るのではなく、短いサイクル（スプリント）で小さな成果物を繰り返し作り、フィードバックを得ながら進める。
アジャイル開発の特徴
-
短い開発サイクル（スプリント）：
1〜4週間程度で設計からテストまでを回す -
ユーザー重視：
顧客や関係者と頻繁に会話し、期待とズレないように進める
動くソフトを重視：ドキュメントよりも実際の動作する成果物を優先 -
変化を歓迎：
要件変更や改善を途中で取り込みやすい
ウォーターフォール開発との比較
スクラム（アジャイルの代表例）
-
スプリント：
短期間の開発サイクル。各スプリントで「完成可能な製品の一部」を作る。 -
プロダクトバックログ：
作るべき機能や要望を並べたリスト。優先度はプロダクトオーナーが決定する。 -
プロダクトオーナー：
「何を作るか」を決める責任者。顧客の代弁者。 -
スクラムマスター：
チームがスクラムをうまく回せるようにサポートする役割。障害を取り除く調整役。 -
開発チーム：
設計・開発・テストを自律的に進めるメンバー。複数スキルを持つ多能工チームが理想。 -
デイリースクラム：
毎日短時間で進捗や課題を共有する。 -
スプリントプランニング：
次のスプリントで何を作るか計画を立てる。 -
スプリントレビュー：
スプリントで完成したものを披露し、フィードバックをもらう場。 -
スプリントレトロスペクティブ：
スプリントの振り返り。チームの改善点を話し合う。
※スクラム開発における1週間の流れ
XP（エクストリーム・プログラミング）
アジャイル開発の中でもコード品質と開発者の生産性向上に特化した手法を集めたフレームワーク。
-
テスト駆動開発（TDD）：
テストを先に書いてからコードを書く。 -
CI（継続的インテグレーション）：
コードを頻繁に統合し、自動テストで常に正しさを保証する。 -
CD（継続的デリバリー／デプロイ）：
常にリリース可能な状態を維持する。 -
リファクタリング：
機能は変えずにコードを改善する。 -
ペアプログラミング：
二人一組でプログラミングを行う。- ドライバ：コードを書く人
- ナビゲーター：戦略やコードの質をチェックする人
-
YAGNI（You Aren’t Gonna Need It）：
「どうせ要らない機能は作らない」思想。
4. モジュール分割（強度・結合度）
大きなシステムを 機能ごとの小さなかたまり（モジュール） に分ける設計の考え方。
役割ごとに整理しておくことで、変更・理解・保守のしやすさに繋がる。
モジュール分割の基本指針
モジュール設計における鉄則は、次のとおり：
- 強度（cohesion）は高く
- 結合度（coupling）は低く
モジュールの強度（Cohesion）
モジュール内の機能がどれだけ密接に関連しているかを表す指標。
強度が高いほど、1つのモジュールとしてまとまりが良い状態。
| 強度の種類 | 概要 | 良し悪し |
|---|---|---|
| 暗号強度（×最悪） | 機能間の関連を無視し複数の機能を1つのモジュールにまとめる | × 最悪 |
| 論理強度（×） | 関連した機能をまとめる。どれを使うかは引数で指定する。 | ✕ NG設計 |
| 時間強度（×） | ある時点に連続して使用する機能をまとめる | ✕ NG設計 |
| 手順強度（△） | 必ず順番（逐次） に実行される機能を1つのモジュールにまとめる。別のデータを使う。 | △ 注意必要 |
| 連絡強度（○） | 必ず順番（逐次） に実行される機能を1つのモジュールにまとめる。同じデータを使う。 | ○ 許容範囲 |
| 情報強度（○） | 特定のデータを扱う機能を1つのモジュールにまとめ隠ぺいする。 | ○ 許容範囲 |
| 機能強度（◎最良） | モジュールが 1つの機能のみ を提供する | ◎ ベスト！ |
モジュールの結合度（Coupling）
モジュール同士の依存の強さを示す指標。
結合度が高いと、「1つを直すと他も壊れる」状態になりやすいため、低く保つのが良い設計。
| 結合度の種類 | 概要 | 良し悪し |
|---|---|---|
| 内容結合（×最悪） | 他モジュールの内部構造に直接アクセスしている | × 最悪 |
| 共通結合（×） | グローバル領域のデータ構造を参照している | ✕ NG設計 |
| 外部結合（×） | グローバル領域のデータを参照している | ✕ NG設計 |
| 制御結合（△） | 制御フラグなどで処理の流れをコントロールしている | △ 注意必要 |
| スタンプ結合（○） | 構造体やレコード単位で情報をやり取りしている | ○ 許容範囲 |
| データ結合（◎最良） | 必要なデータ項目だけを引数として受け渡している | ◎ ベスト！ |
モジュール分割の代表的な3技法
① STS分割
処理を入力（Source）、変換（Transform）、出力（Sink）の3段階に分ける設計。
② トランザクション分割
処理の分岐に着目して、トランザクション（業務単位）ごとにモジュールを分ける設計。
③ 共通機能分割
複数のモジュールで使う機能を共通化してまとめる設計。
5. 分析・設計技法（DFD, ER, UML）
システム開発では、要件の理解や設計の段階で「可視化」や「構造化」が非常に重要。
代表的な分析・設計技法として、DFD（データフロー図）、ER図（エンティティ関連図）、UML（統一モデリング言語）が挙げられる。
DFD（Data Flow Diagram）データフロー図
システム内でのデータの流れと処理を表現する図。
よく出る構成要素は次のとおり：
- プロセス：データを処理する機能（例：注文受付）
- データストア：一時的に保存されるデータ（例：注文DB）
- 外部エンティティ：システムの外からやってくる人やシステム（例：顧客）
- データフロー：上記の間を流れる情報（例：注文情報）
📝 memo：
DFDは「何をどう処理するか」よりも、「どのデータがどこに流れるか」に着目した地図。業務フローの全体像把握に最適。
ER図（Entity-Relationship Diagram）
データベースの構造を設計するための図。
よく出る構成要素は次のとおり：
- エンティティ（四角）：ものや人、場所など（例：顧客、商品）
- リレーションシップ（ひし形）：エンティティ間の関係（例：購入する）
- 属性（楕円）：エンティティが持つ情報（例：顧客名、商品価格）
UML（Unified Modeling Language）
システムの「構造」や「振る舞い」を表現する図の集合。
試験や実務でもよく登場する主要な図は次のとおり：
①ユースケース図
誰（アクター） が、 どんな機能（ユースケース） を使うかを示す図
②ステートマシン図（状態遷移図・ステートチャート図）
オブジェクトがどんな状態にあり、どんなイベントで状態が遷移するかを表現する図。
③アクティビティ図
処理の流れや業務プロセスを表す図。フローチャートに近い。
④コンポーネント図
システムを構成する部品（モジュール）やサブシステムの構成と関係を表す図。
⑤クラス図
クラス（設計図）の属性や操作、クラス間の関係性を表現する図。
| 関係 | 定義 | 📝memo（補足） |
|---|---|---|
| 汎化 | 親クラス → 子クラスの継承関係（is-a） | 「スポーツカーは車である」のような関係 |
| 特化 | 汎化の逆。子クラスが親クラスを基に拡張している | 親 → 子という方向性で整理する |
| 集約 | 弱い「has-a」関係（部分が独立して存在可） | 学校が「教師」を持つが、教師は学校外でも存在できる |
| コンポジション | 強い「has-a」関係（部分が全体と一蓮托生） | フォルダ削除で中のファイルも消える関係 |
| 分解（part-of） | 一部として含まれているという関係 | 車は「タイヤ」などの構成要素から成るといった視点 |
⑥オブジェクト図
クラス図を元に、具体的なインスタンス（オブジェクト）を示す図。
⑦シーケンス図
オブジェクト同士の順番を、時間軸に沿って表現する図。
⑧コミュニケーション図
オブジェクト間のメッセージのやり取りを整理した図。
⑨配置図（デプロイメント図）
システムのソフトウェアやサービスが、どのハードウェア／ノード上で動作するかを示す図。
⑩パッケージ図
クラスやユースケースを機能ごとにパッケージ単位で整理する図。
6. オブジェクト指向の基礎
オブジェクト指向は、複雑なシステムを 「もの（オブジェクト）」のやり取り によってシンプルに捉える考え方。
クラスとオブジェクト
- クラス：
オブジェクトの設計図。どんな属性（データ）や操作（メソッド）を持つかを定義する。 - オブジェクト：
クラスから生成された実体。実際に動作したりデータを保持するもの。
📝 memo:
クラスが「レシピ」だとしたら、オブジェクトは「そのレシピから作った料理」。
同じレシピ（クラス）から、何皿でも料理（オブジェクト）を作れる。
カプセル化（Encapsulation）
データと処理を一つにまとめて、外部からは中身を直接いじらせないようにすること。
インタフェースを通じてのみアクセスできるようにする。
📝 memo:
家の中に金庫があっても、外からいきなり中身は触れない。
ちゃんと鍵（メソッド）を使って開けるイメージ。
継承（インヘリタンス）
あるクラス（親クラス）の性質を、別のクラス（子クラス）が引き継げる仕組み。
共通部分をまとめて再利用しやすくなる。
📝 memo
「哺乳類」という親クラスから「犬」や「猫」が派生するようなイメージ。
共通の性質は親に持たせて、子はそれをそのまま使ったり、上書きしたりできる。
オーバーライド
親クラスで定義されたメソッドを、子クラスで上書きして再定義すること。
同じ名前のメソッドでも、子クラス特有の動作にできる。
📝 memo:
「動物が鳴く」というメソッドを、犬クラスでは「ワン」と鳴くように書き換えること。これにより、後述、多態性（ポリモーフィズム）が実現できる。
多態性（ポリモーフィズム）
同じ命令（メソッド呼び出し）でも、オブジェクトによってふるまいが変わること。
継承やインタフェースと組み合わせて使われる。
📝 memo:
「鳴く」という命令に対して、犬は「ワン」、猫は「ニャー」、羊は「メェ」と鳴く。
同じ命令でも中身は違うこと。
インタフェースと抽象クラス
- インタフェース：
やるべきこと（メソッド名）だけを定義しておくもの。中身は持たない。 - 抽象クラス：
一部だけ中身（処理）を持てるクラス。共通部分のコードを再利用できる。
📝 memo:
インタフェースは「絶対このボタンは付けてね！」というルールだけ提示。
抽象クラスは「このボタン、こう押すといいよ」ってちょっと実装もしてくれる。
7. テスト技法と工程対応
単体テスト
関数・モジュール単位で内部処理が正しく動作するかを検証する。
テスト技法は次のとおり。
ホワイトボックステスト
プログラムの内部構造に着目し、コードの網羅性を確認する。
命令網羅
分岐については考慮せず、命令だけをすべて通るようにテストする
分岐網羅（判定条件網羅）
すべての分岐（ifやcaseの真偽）を網羅する
条件網羅
各条件式（複数条件の一部）の真・偽をそれぞれ網羅する
複数条件網羅
条件と分岐の両方を網羅する
ブラックボックステスト
仕様に基づいて、入力と出力の関係が正しいかを確認する。
同値分析
入力値を性質ごとにグループ化し、代表値のみをテスト。
境界値分析
境界付近の値（最小・最大・その前後）を重点的にテスト。
結合テスト
モジュール間や外部インターフェース間の連携が正しく機能するかを確認。
- スタブ：下位モジュールのダミー
- ドライバ：上位モジュールのダミー
8. レビュー
インスペクション
最も形式的で厳密なレビュー手法であり、事前準備・チェックリスト・役割分担（を明確にして実施される。
- モデレータ ：会議を進行する役割
- レビュアー ：レビューする人
- レビューイ ：レビューしてもらう人
📝 memo：
指摘の記録と分析を残すため、再発防止や品質改善に活用できるという利点があります。
ウォークスルー
作成者が自ら設計書・仕様書・ソースコードなどの成果物について関係者に説明し、フィードバックを受けるレビュー方法。
📝 memo：
バグの早期発見と除去を目的とする。
レビューの回覧方式
レビューの実施方法には、文書の回し方（回覧方式）にもいくつか種類がある。
プロジェクトの性質やチームのスタイルに応じて使い分けることで、効率よく的確なレビューが行える。
ラウンドロビン方式
レビューの役割（司会者、レビューアなど）を参加者全員が順番に担当するレビュー方法。
📝 memo：
参加者のレビュー視点が広がり、自分の担当以外への理解促進にも役立つ
パスアラウンド方式
実際に集まらずにメールなどで意見を交換するレビュー方法。
📝 memo：
レビューアは、同じ場所に集まる必要がなく、各自の都合の良いタイミングでレビューできる。
おわりに
この記事では、応用情報技術者試験の午前問題の「情報システム開発」について、キーワードを中心に整理してみました。
あくまで自分の理解を深めるためのまとめではありますが、同じように情報システム開発を一から学び直している方や、試験対策に取り組んでいる方の参考になればうれしいです。