ソフトウェア開発管理技術の要点とまちがえやすい点（ITパスポート試験 論点テキスト）
ITパスポート試験のマネジメント系（開発技術）のうち、「ソフトウェア開発管理技術」にあたる12論点を、要点60本・まちがえやすい点41本にまとめました。
最終更新：2026年10月6日
ご利用にあたって：本ページおよびアプリ「ITウカール」は、政府・経済産業省・独立行政法人情報処理推進機構（IPA）のいずれとも関係のない、個人開発の非公式サイト・アプリです。公式の文章の転載ではありません。出題範囲・受験の情報は、必ずITパスポート試験の公式サイトでご確認ください。
このページの論点
開発プロセス・手法
UMLの図法とその使い分け
クラス図・ユースケース図・シーケンス図・アクティビティ図が何を表すかを扱い、図ごとの着目点の違いが問われる。
要点
- クラス図は、クラスの属性（データ）や操作（メソッド）と、クラス間の関連・継承・集約などの静的構造を表す図である。
- ユースケース図は、アクターとシステムが提供する機能（ユースケース）との関係を表し、求められる機能の全体像を利用者視点で把握するために用いられる。
- シーケンス図は、オブジェクト間のメッセージのやり取りを時系列に沿って表現する図で、処理の呼び出し順序を把握するのに適する。
- アクティビティ図は、処理の流れを分岐・並行処理・合流などを含めて表現でき、業務フローやアルゴリズムの可視化に用いられる。
まちがえやすい点
- シーケンス図は時系列のメッセージのやり取りを表す図であり、分岐や並行処理を含む処理の流れ全体を表すアクティビティ図とは異なる。
- ユースケース図は利用者視点で機能を表す図であり、静的構造を表すクラス図や状態の変化を表す状態遷移図とは目的が異なる。
オブジェクト指向の基本概念とクラス関係
カプセル化・継承・多相性・汎化の意味と、デザインパターンの位置づけを扱う。
要点
- カプセル化は、データ（属性）とそれを操作する手続（メソッド）を1つのオブジェクトにまとめ、内部の詳細を外部から隠蔽する考え方である。
- 継承（インヘリタンス）は、上位クラスの属性やメソッドを引き継いで下位クラスを定義し、共通部分の再利用と差分の追加を可能にする仕組みである。
- 多相性（ポリモーフィズム）は、同じ名前のメッセージに対して、受け手となるオブジェクトのクラスに応じて異なる動作を実行できる性質である。
- 汎化（継承）は、あるクラスが別のクラスの一種であるというis-a関係を表す関係である。
- デザインパターンは、オブジェクト指向設計で繰り返し現れる典型的な問題とその解決策の型を汎用的に整理したもので、設計の再利用や意図の伝達を容易にする。
- 構造化手法は、処理や機能に着目して、システムを段階的に細かく分割しながら、データフロー図などで分析・設計する手法。
まちがえやすい点
- 集約は全体と部分（has-a）の関係を表し、あるクラスが別のクラスの一種であるis-a関係を表す汎化（継承）ではない。
- カプセル化は内部の隠蔽であり、上位クラスの性質を引き継ぐ継承や、同名メッセージに多様な応答をする多相性とは別である。
- デザインパターンは問題と解決策の型であり、具体的な実装の骨組みを提供するフレームワークや、再利用可能な関数・部品群であるライブラリとは異なる。
DevOpsと継続的インテグレーション・デリバリー
DevOps、DevSecOps、継続的インテグレーション・デリバリー・デプロイメント、IaCの意味と自動化の範囲の違いを扱う。
要点
- DevOpsは、開発（Development）と運用（Operations）が協働し、自動化されたパイプラインで頻繁かつ安全にリリースする文化・手法である。
- 継続的インテグレーション（CI）は、変更を頻繁に統合し、自動ビルド・自動テストで早期に問題を検出する手法である。
- 継続的デリバリーは、コード変更のたびにビルドと自動テストを行い、いつでも本番環境へリリースできる状態を常に保つ手法である。
- 継続的デプロイメントは、テストを通過した変更を人手の承認を挟まず自動で本番環境へ反映する手法である。
- DevSecOpsは、開発・運用・セキュリティを一体化し、工程の早い段階からセキュリティを組み込むことで安全性と迅速性を両立する考え方である。
- IaC（Infrastructure as Code）は、インフラ構成をコードで管理し、その実行により同一環境を自動かつ再現性高く構築できる手法である。
- MLOpsは、機械学習モデルの開発から運用までを、自動化や継続的な改善を取り入れて、開発側と運用側が連携して回し続ける取組。
まちがえやすい点
- 継続的デリバリーは本番反映の直前まで自動化し反映は手動承認とする点で、承認を挟まず自動で本番反映する継続的デプロイメントとは異なる。
- 継続的インテグレーションは変更の統合と自動テストを行う段階であり、本番へいつでもリリースできる状態を保つ継続的デリバリーとは別である。
- 開発と運用の役割を厳格に分けてやり取りを減らす状態は、DevOpsが解消しようとしている状態であり、DevOpsの考え方とは異なる。
- 継続的モニタリングは稼働監視を指し、変更の自動ビルド・テストから本番反映までを扱う継続的デプロイメントではない。
- DevSecOpsはセキュリティを統合する考え方であり、開発工程の進め方の分類であるウォーターフォールとは別である。
ソフトウェア資産の再利用とライセンス形態
部品の再利用、プロダクトライン開発、コピーレフト、ローコード開発といった開発・利用形態の特徴を扱う。
要点
- コピーレフトは、改変・再配布したソフトウェアについても元のライセンス条件（ソースコード公開など）を引き継がせる考え方で、GPLがその代表例である。
- ソフトウェア資産の再利用は、過去に開発したモジュールやライブラリなどの部品を整備・蓄積し、複数のプロジェクトで再利用できるようにする取組みである。
- プロダクトライン開発は、共通の基盤部品やアーキテクチャを整備し、それらを組み合わせて仕様の異なる複数の製品群を効率よく開発する手法である。
- ローコード開発は、画面上で部品を組み合わせるなど最小限のコーディングで開発でき、迅速化と非専門家の参加を可能にする手法である。
まちがえやすい点
- パーミッシブライセンスは改変後のソースコード公開を義務付けない緩やかなライセンス形態であり、改変後も同じ条件を引き継がせるコピーレフトとは異なる。
- スクラッチ開発は既存資産を用いずゼロから開発する方式であり、既存の部品を活用するソフトウェア資産の再利用とは異なる。
- プロダクトライン開発は複数製品の共通化を主眼とし、単一製品の開発プロセスを反復的に進めるスパイラルモデルやプロトタイピングモデルとは目的が異なる。
ウォーターフォール・スパイラルなどの開発モデル
ウォーターフォール、スパイラル、プロトタイピング、インクリメンタル各モデルとリバースエンジニアリングの違いを扱う。
要点
- ウォーターフォールモデルは、各工程を順番に完了させながら進め、原則として前工程には戻らない開発モデルである。
- スパイラルモデルは、サブシステムごとに設計・試作・評価のサイクルを繰り返し、反復のたびにリスクを分析しながら完成度を高めていく開発モデルである。
- プロトタイピングモデルは、試作品を早期に提示して利用者の確認を得ることで、要件定義段階での認識のずれを早期に是正する手法である。
- インクリメンタルモデルは、システム全体を分割し、優先度の高い部分から順に設計・開発・リリースを繰り返して機能を段階的に積み上げていくモデルである。
- リバースエンジニアリングは、既存のプログラムやシステムを解析して仕様や設計情報を導き出す活動であり、仕様書が散逸した既存システムの保守や再構築の前段階として行われる。
- ウォーターフォールモデルは、工程を順に進めるため計画は立てやすいが、後戻りの手間が大きい。
- アジャイル開発は、短い反復を重ねて要求の変化に対応しやすくする開発手法である。
まちがえやすい点
- ウォーターフォールモデルは一方向の順次進行型であり、反復開発のスパイラルモデルや、試作品で早期確認を行うプロトタイピングモデルではない。
- スパイラルモデルはサブシステム単位の反復開発であり、開発工程とテスト工程の対応関係を示すVモデルとは別である。
- リバースエンジニアリングは解析によって設計情報を取り出す活動であり、外部仕様を変えずに内部構造を整理して改善するリファクタリングとは異なる。
スクラムの役割と成果物
プロダクトオーナー・スクラムマスター・開発者の役割と、プロダクトバックログなどの成果物・指標の区別を扱う。
要点
- プロダクトオーナーは、プロダクトの価値を最大化する責任を負い、プロダクトバックログの内容と優先順位を管理する役割である。
- スクラムマスターは、スクラムチームがスクラムの理論とプラクティスを理解し実践できるよう支援し、開発の妨げとなる障害の除去に努める役割である。
- スクラムの開発チームは、スプリントの中で誰がどの作業を行うかを自分たちで決める。
- プロダクトバックログは、プロダクトに必要な機能・要望を優先順位付けして並べた一覧であり、プロダクトオーナーが内容と優先順位の管理に責任を持つ。
- スプリントバックログは、1スプリントで実現する項目とそれを実現するための作業タスクの一覧であり、開発チームが管理する。
- 完成の定義（Definition of Done）は、作業が完了したと認めるための品質基準や条件をチームで共有・明文化したもので、認識のずれを防ぐ。
- ベロシティは、1スプリントで完了できた作業量の実績を示す指標で、過去の実績を基に次以降のスプリントの作業量を見積もる計画の基礎となる。
まちがえやすい点
- スクラムマスターの役割はチームの妨げを取り除いて進め方を支援することであり、作業を割り当てる管理者の役割とは別である。
- プロダクトオーナーは「何を作るか」に責任を持ち、「いかに作るか」を支援するスクラムマスターとは役割が異なる。
- プロジェクトマネージャはスクラムの公式な役割として定義されておらず、プロダクトオーナーやスクラムマスターとは異なる。
- プロダクトバックログは製品全体の要求一覧であり、1スプリント分を選び出した作業一覧であるスプリントバックログとは対象範囲が異なる。
- ベロシティは1スプリントの完了量の実績であり、予算消費速度を表すバーンレートや、着手から完了までの所要時間を表すリードタイムではない。
スクラムのイベントとタイムボックス
スプリントとその中のデイリースクラム、レビュー、レトロスペクティブの目的と実施時期の違いを扱う。
要点
- デイリースクラムは、スプリント期間中に毎日短時間で行い、作業の進捗確認と計画の微調整を行うイベントである。
- スプリントレトロスペクティブは、チームの活動プロセス自体を振り返り、次のスプリントに向けた改善策を検討するイベントである。
- スプリントレビューは、スプリントの終了時に完成した成果物を関係者に見せてフィードバックを得るイベントで、その結果はプロダクトバックログの見直しに反映される。
- スプリントプランニングは、スプリント開始時に計画を立てるイベントである。
- スプリントは1〜4週間程度の反復期間で、その終わりに動くソフトウェアを示す。
- タイムボックスは、作業時間の長さをあらかじめ固定し、その時間内で達成できる範囲に成果をまとめる時間管理の考え方である。
まちがえやすい点
- スプリントレビューは成果物を確認するイベント、スプリントレトロスペクティブは進め方自体を振り返るイベントであり、対象が成果物かプロセスかで異なる。
- バックログリファインメントはバックログ項目の詳細化であり、プロセスを振り返るレトロスペクティブとは異なる。
- レトロスペクティブはスプリントの終わりに進め方を振り返る会議であり、毎日短時間で進捗と障害を共有するデイリースクラムではない。
- マイルストーンは節目の時点、クリティカルパスは所要期間が最長の経路を表し、時間を固定して範囲を調整するタイムボックスとは別である。
XPのプラクティス
ペアプログラミング、テスト駆動開発、リファクタリング、モブプログラミングが何を行う手法かの区別を扱う。
要点
- ペアプログラミングは、2人1組で作業し、一方がコードを書き他方がリアルタイムで確認や助言を行うことで、欠陥の早期発見や知識共有を図る手法である。
- リファクタリングは、プログラムの外部から見た振る舞いを変えずに、内部構造を整理して可読性・保守性を高める作業である。
- テスト駆動開発（TDD）は、テストコードを先に書き、それを満たすように実装を進めるXPのプラクティスである。
- モブプログラミングは、3人以上の開発者チーム全員が同じ画面を見ながら1つの作業に取り組み、操作担当を交代しつつ共同でコードを書き進める手法である。
まちがえやすい点
- モブプログラミングは2人1組で行うペアプログラミングを拡張した形態であり、参加人数と協働の形が異なる。
- ペアプログラミングは2人1組での共同作業であり、内部構造の整理を行うリファクタリングや、テストを先に書くテスト駆動開発ではない。
- リファクタリングは振る舞いを保ったまま内部構造を改善する作業であり、不具合を発見・修正するデバッグとは別である。
アジャイルの価値観と関連手法
アジャイルソフトウェア開発宣言の価値観、ユーザーストーリー、MVP、かんばんなど関連する考え方を扱う。
要点
- アジャイルソフトウェア開発宣言は、個人と対話、動くソフトウェア、顧客との協調、変化への対応という4つの価値観を、それぞれの対比項目より価値があるとしている。
- アジャイル開発は、短い反復で動くソフトウェアを積み上げ、関係者との対話を通じて変化する要求に対応していく進め方である。
- ユーザーストーリーは、システムに求める機能を利用者視点の短い文で表し、優先順位付けの基礎とするものである。
- MVP（Minimum Viable Product）は、仮説検証のため必要最小限の機能に絞った製品で、無駄な作り込みを避け早期に学びを得る。
- かんばん方式は、作業の流れをボードとカードで可視化し、各工程の仕掛り作業数に上限（WIP制限）を設けて、ボトルネックの発生を早期に把握し継続的に流れを改善する手法である。
まちがえやすい点
- 最初に要件をすべて固めて後戻りしない前提はウォーターフォールモデルの考え方であり、変更を受け入れる前提に立つアジャイル開発とは別である。
- かんばん方式はスプリントのような固定の反復期間を前提とせず、その点でスクラムとは異なる。
- ユーザーストーリーは要求の最小記述単位であり、利用の流れを詳述するユースケース記述や、検証の条件を示すテストケースではない。
- アジャイルソフトウェア開発宣言は「契約交渉よりも顧客との協調」を重んじるものであり、対比の向きを逆にした説明とは別である。
- MVPは必要最小限の機能に絞った製品を指し、サービス品質の合意であるSLAや、作業を分解した構成図であるWBSとは異なる。
開発プロセスの成熟度と共通フレーム
CMMIによる成熟度評価と、IPAが策定した共通フレームの目的を扱う。
要点
- CMMIは、組織の開発プロセスの成熟度を複数の段階（レベル）で評価し、プロセス改善の指針を提供するモデルである。
- 共通フレーム（SLCP-JCF）は、ソフトウェアライフサイクルにおける作業項目や役割、用語を包括的に定義したガイドラインで、IPAが策定している。
- ソフトウェアライフサイクルは、企画から保守までを通して捉える考え方である。
まちがえやすい点
- CMMIは開発プロセスの成熟度を評価するモデルであり、品質マネジメントシステムの国際規格であるISO 9001や、ITサービスマネジメントのベストプラクティス集であるITILとは異なる。
- 共通フレームは作業の枠組みを定めるものであり、特定の言語やツールを指定するものとは異なる。
- 共通フレームはライフサイクル全体の作業項目を定義するガイドラインであり、ソフトウェア品質特性の規格であるISO/IEC 25010とは目的が異なる。
構成管理とバージョン管理
構成管理、バージョン管理システム、トランクベース開発が、成果物の版や変更をどう扱うかの違いを扱う。
要点
- 構成管理は、成果物の版を識別・記録し、変更履歴を追跡することで成果物全体の整合性を保つ活動である。
- バージョン管理システムは、ソースコードなどの変更履歴を記録し、複数開発者による同時編集や過去バージョンへの復元、変更のマージを可能にする仕組みである。
- トランクベース開発は、開発者が主幹となるトランク（mainブランチ）に小さな変更を頻繁に統合する開発スタイルで、長期間分岐したブランチ同士の大きな統合作業やコンフリクトを避けやすい。
まちがえやすい点
- 構成管理は成果物の版を管理する活動であり、変更要求の承認可否を判断する変更管理や、本番環境への展開を管理するリリース管理ではない。
- 構成管理台帳は管理対象を一覧化した文書であり、履歴の記録と復元・マージを可能にするバージョン管理システムとは別である。
- トランクベース開発は小さな変更を頻繁に統合する方式であり、長期の機能ブランチを前提とするフィーチャーブランチ開発とは統合の頻度と粒度の考え方が異なる。
開発委託の契約形態と検収
請負契約と準委任契約の責任の違い、および成果物の受領を認める検収の意味を扱う。
要点
- 準委任契約は、仕事の完成ではなく専門的な業務の遂行を引き受ける契約形態で、受託者は善良な管理者の注意をもって業務を遂行する義務を負うが、成果物の完成責任は負わない。
- 請負契約は、受託者が成果物の完成を約束し、注文者が完成した仕事の結果に対して報酬を支払う契約形態で、受託者は原則として成果物に対する契約不適合責任を負う。
- 請負契約では指揮命令は受注者側が行い、発注者が受注者の従業員へ直接指示を出すと実態が労働者派遣とみなされ、偽装請負として問題になる。
- 検収は、納入された成果物が仕様・要件を満たすかを確認したうえで、発注者が受領を正式に認める行為である。
まちがえやすい点
- 準委任契約は成果物の完成責任を負わず業務の遂行自体を引き受ける点で、仕事の完成と成果物の引渡しに対して報酬が支払われる請負契約とは異なる。
- 検収は成果物の受領を認める行為であり、稼働後の維持である保守や、新システムへの切替えである移行とは別である。
ほかのページ
この論点の問題は、アプリで解けます
ITウカールは、ITパスポート試験の対策アプリです。論点テキストはアプリの中でも無料で読めて、各論点の問題を解いて理解を確かめられます。分野別の演習・本番形式の模擬試験・間違えた問題の復習まで、1つのアプリで進められます。
出典と作り方
この読み物は、IPA「ITパスポート試験 シラバス Ver.6.5」の中分類の順に、アプリ「ITウカール」の収録問題の解説をもとにアプリ製薬が作成したものです。公式の文章の転載ではありません。問題文・選択肢は載せていません。