開発プロセスの用語
ソフトウェアライフサイクルプロセス
ソフトウェアライフサイクルプロセス（SLCP）は、システムの企画から保守までの各プロセスで行う作業をまとめたガイドラインです。日本では「共通フレーム」として整理されており、発注側と開発側が同じ言葉で作業内容を確認できるようにする役割があります。
| プロセス | 行うこと |
|---|---|
| 企画 | システム化の方針を策定し、システム化計画を作成する。開発順序、概算コスト、費用対効果、リスク、納期を検討する |
| 要件定義 | 業務上実現すべき機能や性能を明確にし、業務要件を定義する |
| 開発 | システム開発（システム要件定義、方式設計、結合、適格性確認テスト）と、ソフトウェア実装（ソフトウェア要件定義、方式設計、詳細設計、構築、結合、適格性確認テスト）を行う |
| 運用 | 完成したシステムを本番環境で稼働させ、利用者を支援する |
| 保守 | 稼働後の不具合修正や改良を行う |
次の図は、5つのプロセスを順番に並べたものです。
テストの種類
テストは、小さい単位から大きい単位へ順に進めます。
| テスト | 確認すること | 主体 |
|---|---|---|
| 単体テスト | モジュール単体が設計どおりに動くか | 開発者 |
| 結合テスト | モジュールをつなげたとき、モジュール間のやり取りが正しいか | 開発者 |
| システムテスト | システム全体が、定めた機能や性能を満たしているか | 開発者 |
| 受入れテスト | 完成したシステムが、発注時の要件を満たしているか | 利用者（発注者） |
| 回帰テスト（リグレッションテスト） | 修正したとき、修正箇所以外に問題が発生していないか | 開発者 |
受入れテストだけは利用者が主体です。回帰テストは工程の名前ではなく、修正のたびに行うテストです。
現場の開発フローと試験用語の対応
試験用語は、実務の作業と対応づけると覚えやすくなります。以下は、保守案件で問い合わせを受けてからリリースするまでの流れの一例です。
| 現場の作業 | 対応する試験用語 |
|---|---|
| 問い合わせ受付、チケット発番 | サービスデスク、インシデント管理 |
| 要件・仕様の整理 | 要件定義 |
| スケジュール計画 | WBS、ガントチャート |
| 設計書の作成、または既存の設計書の修正 | 方式設計、詳細設計、UML |
| 実装（ローカル環境、featureブランチ）、レビュー | 構築、レビュー |
| テスト仕様書の作成、レビュー | テスト設計 |
| 単体テスト（開発環境）、devブランチにマージ | 単体テスト |
| 結合テスト（保守環境）、masterブランチにマージ | 結合テスト、回帰テスト |
| 本番承認 | 変更管理 |
| リリース | リリース管理 |
次の図は、実装からリリースまでを、環境とブランチの移り変わりで示したものです。
開発手法の用語
アジャイル開発とイテレーション
アジャイル開発は、プログラミングとテストを重視し、要件定義や設計を柔軟に見直しながら進める開発手法です。短い期間の開発を何度も繰り返してシステムの完成度を高めていきます。この繰り返しの単位をイテレーションと呼びます。
XP（エクストリーム・プログラミング）
XPは、ソフトウェアの品質を高めつつ、変化する顧客の要求に対応する力を高めるためのアジャイル手法です。コミュニケーション、シンプルさ、フィードバック、勇気、尊重の5つを価値として掲げます。設計やコードを途中で変更・削除することをためらわない姿勢が「勇気」に当たります。
- ペアプログラミング：2人1組になり、1人がコードを書き、もう1人がその場でレビューする
- リファクタリング：外部から見た動作を変えずに、内部構造を整理して保守性を高める
スクラム
スクラムはアジャイル開発の手法の1つで、3つのロール、5つのイベント、3つの作成物で構成されます。
| 区分 | 要素 |
|---|---|
| 3つのロール | プロダクトオーナ、スクラムマスタ、開発チーム |
| 5つのイベント | スプリント、スプリント計画（スプリントプランニング）、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ |
| 3つの作成物 | プロダクトバックログ、スプリントバックログ、インクリメント |
名前が似ていて混同しやすいものは、次のように区別します。
| 用語 | 内容 |
|---|---|
| プロダクトオーナ | 何を作るかを決める。プロダクトバックログの優先順位に責任を持つ |
| スクラムマスタ | スクラムが正しく実践されるようチームを支援する。作業の指示はしない |
| プロダクトバックログ | プロダクトに必要な項目を優先順位順に並べた一覧 |
| スプリントバックログ | そのスプリントで実施する項目と作業計画 |
| スプリントレビュー | スプリントの成果物を関係者に見せ、意見をもらう |
| スプリントレトロスペクティブ | チームの進め方を振り返り、改善点を決める |
スクラムの公式ガイドは、2020年版で「開発チーム」を「開発者」に改めています。それ以前の教材や過去問では「開発チーム」と書かれています。
コンカレントエンジニアリングとリバースエンジニアリング
- コンカレントエンジニアリング：設計や製造などの各プロセスを並行して進め、開発期間を短縮する
- リバースエンジニアリング：既存のシステムや製品を解析し、仕様や設計を導き出す
プロジェクトマネジメントの用語
PMBOKの10の知識エリア
PMBOK（Project Management Body of Knowledge）は、プロジェクト管理の知識を体系的にまとめたガイドです。
| 知識エリア | 管理する対象 |
|---|---|
| プロジェクト統合マネジメント | 他の知識エリア全体の調整。プロジェクト憲章を作成する |
| プロジェクト・スコープ・マネジメント | 成果物と作業の範囲。過不足がないように管理する |
| プロジェクト・スケジュール・マネジメント | 作業の順序と期間、進捗 |
| プロジェクト・コスト・マネジメント | 費用の見積りと予算 |
| プロジェクト品質マネジメント | 品質の基準と、その達成状況 |
| プロジェクト資源マネジメント | 人員や機材の確保、チームの育成 |
| プロジェクト・コミュニケーション・マネジメント | 関係者への情報の伝達 |
| プロジェクト・リスク・マネジメント | リスクの特定、分析、対応 |
| プロジェクト調達マネジメント | 外部からの購入や契約 |
| プロジェクト・ステークホルダー・マネジメント | 利害関係者の特定と関与 |
10の知識エリアは第6版までの構成です。第7版（2021年）からは原則とパフォーマンス領域を中心とした構成に変わり、2025年には第8版が出ています。試験のシラバスが沿っているJIS Q 21500も、ほぼ同じ10項目を「対象群」として定めています（スケジュールに当たる項目は「時間」）。
プロジェクト憲章
プロジェクト憲章は、プロジェクトを公式に認可する文書です。プロジェクトの立上げ時に最初に作成し、目的や概要、プロジェクトマネージャの権限といった取り決めを定めます。プロジェクト統合マネジメントで作成します。
WBS
WBS（Work Breakdown Structure）は、プロジェクトの成果物と作業を階層的に分解した図です。コストの見積りやスケジュールの作成ができる大きさになるまで、要素を分解します。
アローダイアグラムとガントチャート
どちらもスケジュール管理に使う図ですが、わかることが異なります。
| 図 | 書き方 | わかること |
|---|---|---|
| アローダイアグラム | 作業を矢印で表し、作業の前後関係を結ぶ | 全体の所要日数と、遅れが許されない経路（クリティカルパス） |
| ガントチャート | 縦に作業、横に時間をとり、作業期間を横棒で表す | 各作業の予定と実績、進捗の状況 |
マトリックス組織
マトリックス組織は、技能ごとの部門（職能部門）と、事業やプロジェクトを遂行する部門の両方に、メンバーが所属する組織形態です。上司が2人になるため、指示の調整が必要になります。
リスクマネジメントの用語
リスクマネジメントのプロセス
リスクマネジメントは、次のプロセスで構成されます（JIS Q 31000）。
- コミュニケーション及び協議
- 適用範囲、状況及び基準
- リスクアセスメント
- リスク対応
- モニタリング及びレビュー
- 記録作成及び報告
このうちリスクアセスメントは、特定、分析、評価の順に進む3つの段階に分かれます。
| 段階 | 行うこと |
|---|---|
| リスク特定 | リスクを洗い出す |
| リスク分析 | 発生の頻度や確率、発生したときの被害の大きさを分析する |
| リスク評価 | 分析結果をもとに、受容できるかどうかを判断する |
リスク対応の4分類（回避・移転・低減・保有）
リスク評価の結果、対応が必要と判断したリスクには、次の4つのいずれかで対処します。
| 分類 | 別の呼び方 | 内容 | 例 |
|---|---|---|---|
| リスク回避 | ― | 原因を元から絶つか、別の手段に変更して、リスクそのものをなくす | リスクのある業務や機能をやめる |
| リスク移転 | リスク共有、リスク転嫁 | リスク発生時の損失を他者に負担してもらう | 保険に加入する、システムの運用を他社に委託する |
| リスク低減 | リスク軽減 | 発生の可能性や、発生したときの影響を小さくする | アクセス制御や社員教育（可能性を下げる）、代替システムの用意（影響を下げる） |
| リスク保有 | リスク受容 | 対策をとらず、リスクを受け入れる | 対策費用が想定される損失より大きい場合 |
次の図は、発生の可能性と影響の大きさから、どの対応を選ぶかの目安を示したものです。
RCM（リスクコントロールマトリクス）
RCMは、業務で想定されるリスクと、それに対する統制（コントロール）を対応づけた表です。内部統制の評価や監査で、リスクがどの程度低減されているかを確認するために使います。
サービスマネジメントの用語
ITIL
ITIL（Information Technology Infrastructure Library）は、ITサービスマネジメント（ITSM）のベストプラクティスをまとめたものです。システムを作ることではなく、作ったシステムをサービスとして安定して提供することを対象にしています。
インシデント管理と問題管理の違い
インシデント管理は「早く復旧させること」、問題管理は「原因をなくすこと」が目的です。サーバが停止した場合、再起動して復旧させるのがインシデント管理、停止の原因を突き止めて再発を防ぐのが問題管理です。
| プロセス | 目的 |
|---|---|
| インシデント管理 | インシデント発生時に応急処置を行い、サービスをできるだけ早く復旧させる |
| 問題管理 | インシデントの根本原因を突き止め、根本的に解決する |
| 構成管理 | サービスを構成する品目（CI）の情報を記録・管理し、他のプロセスに提供する |
| 変更管理 | 変更が与える影響を評価し、実施を承認する |
| リリース管理 | 変更管理で承認された変更を、スケジュールと手順を管理して本番環境に実装する |
インシデント管理と問題管理は「解決プロセス」、構成管理・変更管理・リリース管理は「統合的制御プロセス」に分類されます。この分類名はJIS Q 20000-1の2012年版のもので、2020年版では構成が変わっています。
次の図は、インシデントの発生からリリースまでの流れと、それを支える構成管理の関係を示したものです。
サービスデスクとチャットボット
サービスデスクは、利用者からの問い合わせを一元的に受け付ける窓口です。チャットボットは、その一次対応を自動化する手段です。
SLAとSLM
- SLA（Service Level Agreement、サービスレベル合意書）：サービスの提供者と利用者の間で、サービスの品質について取り交わす合意
- SLM（Service Level Management、サービスレベル管理）：SLAに基づき、サービスの品質を継続的・定期的に点検、検証して維持・改善する活動
SLAは「約束の内容」、SLMは「約束を守り続けるための活動」です。
調達と契約の用語
RFIとRFPの違い
どちらも発注元の企業がベンダに渡す文書ですが、目的と出す順番が異なります。
| 文書 | 正式名称 | 目的 |
|---|---|---|
| RFI | Request for Information（情報提供依頼書） | ベンダが持つ技術や製品などの情報を集める |
| RFP | Request for Proposal（提案依頼書） | システムの概要や調達条件を明示し、提案を依頼する |
順番は、RFIで情報を集め、RFPで提案を依頼し、ベンダから提案書と見積書を受け取って選定する、という流れです。
NDA
NDA（Non-Disclosure Agreement、秘密保持契約）は、機密情報を取引先に開示するときに、目的外の使用や漏えいを防ぐために結ぶ契約です。RFPなどで自社の情報を渡す前に結びます。
システム戦略の用語
| 用語 | 意味 |
|---|---|
| EA（エンタープライズアーキテクチャ） | 組織全体の業務とシステムの構造を整理し、全体最適を図るための枠組み。現状と理想の差をギャップ分析で明らかにして埋める |
| SoR（System of Record） | 企業内の情報を正確に記録し、安全に運用管理することを重視したシステム |
| SoE（System of Engagement） | 企業と利用者をどうつなぐかを重視したシステム |
| RPA（Robotic Process Automation） | 人が行っていた定型的な事務作業を、ソフトウェアによって自動化する |
| SaaS（Software as a Service） | ソフトウェアを、インターネット経由のサービスとして利用する形態 |
| CAD（Computer Aided Design） | コンピュータ支援設計。設計や作図をコンピュータで行い、データの管理、共有、修正、再利用をしやすくする |
| CAM（Computer Aided Manufacturing） | コンピュータ支援製造。CADのデータをもとに、製造工程をコンピュータで支援する |
設計と表現の用語
UML
UML（Unified Modeling Language）は、オブジェクト指向のシステム開発で使う、図の記法を統一したものです。図は、構造を表すものと、振る舞いを表すものに分かれます。
| 図 | 分類 | 表すもの |
|---|---|---|
| クラス図 | 構造 | クラスが持つ属性と操作、クラス同士の関係 |
| シーケンス図 | 振る舞い | オブジェクト間のメッセージのやり取りを時系列で表す |
| アクティビティ図 | 振る舞い | 処理の流れ。分岐や並行処理も表せる |
親和図法
親和図法は、集めた意見やアイデアを似たもの同士でグループにまとめ、問題の構造を整理する手法です。
UXとUI
- UI（User Interface）：利用者とシステムの接点。画面のレイアウトやボタン、操作方法など
- UX（User Experience）：製品やサービスの利用を通じて利用者が得る体験全体
UIはUXを構成する要素の1つです。
システム構成の用語
スケールアップとスケールアウト
どちらもシステムの処理能力を高める方法です。
- スケールアップ：サーバをより高性能なものに変える
- スケールアウト：サーバの台数を増やす
次の図は、2つの方法の違いを示したものです。
