基本情報技術者試験のマネジメントでは、プロジェクトを進めるための管理や、システムを安定して使い続けるための運用管理が問われます。
かんたんに言うと、マネジメントは「システムを作る仕事」と「作った後に使い続ける仕事」をうまく進めるための考え方です。
マネジメントの基礎から確認したい方は、先にITパスポートのマネジメント系入門を読むと、開発、プロジェクト管理、サービス運用の全体像をつかみやすくなります。
用語をただ覚えるだけでは、選択肢で迷いやすくなります。大切なのは、それぞれの用語が「何を管理するものか」「何を目的にしているか」を見分けることです。
マネジメント分野が科目A・科目Bのどちらで問われやすいかを整理したい方は、基本情報技術者試験の科目Aと科目Bの違いも参考にしてください。
ここだけ読めばOK
基本情報技術者試験のマネジメントでは、QCD、WBS、ガントチャート、リスク管理、SLA、インシデント管理、問題管理、変更管理、リリース管理を押さえましょう。
特に、WBSは「何をやるか」、ガントチャートは「いつやるか」、インシデント管理は「早く復旧する」、問題管理は「根本原因を調べる」と分けて覚えることが大切です。
基本情報技術者試験のマネジメントでは何が問われる？
基本情報技術者試験のマネジメントでは、システム開発やシステム運用を進めるための管理方法が問われます。
試験では、用語の意味だけでなく、場面に合う管理方法を選ぶ問題が出ます。
プロジェクト管理の用語が問われる
プロジェクト管理とは、システムを作る仕事を、期限や予算を守りながら進めるための管理です。
たとえば、新しい予約システムを作る場合、いつまでに作るのか、いくらで作るのか、どの品質を満たすのかを考える必要があります。
ここでよく出るのが、QCD、WBS、ガントチャート、リスク管理です。
サービス管理の用語が問われる
サービス管理とは、完成したシステムを安定して使えるようにするための管理です。
たとえば、社内システムが止まったときに、早く復旧する、原因を調べる、変更を安全に反映する、といった対応が必要になります。
ここでよく出るのが、SLA、インシデント管理、問題管理、変更管理、リリース管理です。
開発・運用の流れを理解する必要がある
マネジメントの用語は、開発の話なのか、運用の話なのかで意味が分かれます。
開発では、計画、作業分解、日程管理、品質管理が大切です。
運用では、障害対応、問い合わせ対応、変更作業、サービス品質の維持が大切です。
問題文を読むときは、まず「今は作っている場面か」「すでに使っている場面か」を確認しましょう。
基本情報技術者試験で押さえるマネジメントの全体像
マネジメントは、システムに関わる仕事をうまく進めるための考え方です。
全体の流れをつかむと、用語がばらばらに見えにくくなります。
システムを計画する
まず、何を作るのか、何のために作るのかを決めます。
目的があいまいなまま進めると、必要な機能が抜けたり、あとから大きな変更が増えたりします。
システムを作る
計画が決まったら、作業を分けて進めます。
このときに使うのがWBSです。WBSでは、作業を細かく分けて、やることを見えるようにします。
品質・費用・納期を管理する
システム開発では、品質、費用、納期のバランスが大切です。
品質を高めようとすると、時間や費用が増えることがあります。納期を短くしようとすると、品質に影響することがあります。
この3つのバランスを考える考え方がQCDです。
費用や経営まわりの考え方もあわせて確認したい方は、基本情報技術者試験のストラテジ入門も参考になります。
リスクを管理する
プロジェクトでは、予定通りに進まないことがあります。
担当者が急に休む、必要な機器が届かない、仕様変更が入る、といった問題が起きるかもしれません。
このような「まだ起きていないが、起きる可能性があること」を管理するのがリスク管理です。
運用中のトラブルに対応する
システムは作って終わりではありません。
運用が始まると、障害、問い合わせ、変更依頼などが発生します。
このとき、早く復旧するのがインシデント管理、根本原因を調べるのが問題管理です。
プロジェクト管理とは？
プロジェクト管理とは、目的のある仕事を計画通りに進めるための管理です。
基本情報技術者試験では、プロジェクトの範囲、日程、費用、品質などをどう管理するかが問われます。
プロジェクトは目的と期限がある仕事
プロジェクトとは、目的と期限がある仕事です。
たとえば、「3か月以内に在庫管理システムを作る」という仕事はプロジェクトです。
いつまでも続く日常業務とは違い、始まりと終わりがあります。
スコープを管理する
スコープとは、プロジェクトで行う作業の範囲です。
どこまで作るのか、どこからは作らないのかを決めます。
スコープがあいまいだと、「この機能も追加してほしい」という要望が増え、日程や費用に影響します。
スコープを管理するときには、WBSが使われます。WBSで作業を細かく分けることで、プロジェクトに必要な作業範囲を見えるようにできます。
スケジュールを管理する
スケジュール管理では、作業の順番や期間を管理します。
どの作業を先に行うか、どの作業が遅れると全体に影響するかを確認します。
ガントチャートは、スケジュールを見えるようにする代表的な図です。
費用を管理する
費用管理では、プロジェクトにかかるお金を管理します。
人件費、機器の費用、外部サービスの利用料などが含まれます。
予定より費用が増えすぎないように確認します。
品質を管理する
品質管理では、できあがったシステムが必要な水準を満たしているかを確認します。
たとえば、動作が正しいか、処理が遅すぎないか、利用者が使いやすいかを確認します。
品質を軽く見ると、あとで障害や手戻りが増える原因になります。
QCDとは？
QCDとは、Quality、Cost、Deliveryの頭文字を取った言葉です。基本の意味から確認したい方は、QCDとは？も参考にしてください。
システム開発では、品質、費用、納期をまとめて考える必要があります。
Quality：品質
Qualityは品質です。
システムが正しく動くか、使いやすいか、必要な性能を満たしているかを表します。
品質が低いと、不具合が増えたり、利用者が使いにくくなったりします。
Cost：費用
Costは費用です。
開発にかかるお金、人件費、機器やサービスの費用などを表します。
費用をかければ品質を高めやすくなることもありますが、予算には限りがあります。
Delivery：納期
Deliveryは納期です。
いつまでに完成させるかを表します。
納期を短くしすぎると、確認不足や品質低下につながることがあります。
QCDのバランスが大事な理由
QCDは、どれか1つだけを見ればよいものではありません。
品質を高めるには、費用や時間が必要になることがあります。
費用を下げすぎると、人手や確認作業が足りなくなることがあります。
納期を早めすぎると、テストが不十分になることがあります。
そのため、QCDは3つのバランスで考えます。
問題でQCDを見分けるポイント
問題文に「品質」「費用」「納期」「コスト」「期限」「期日」「予算」などの言葉が出てきたら、QCDを考えます。
たとえば、「品質を保ちながら納期内に完成させる」「予算内で開発する」といった文が出たら、QCDの話です。
| 用語 | 見るポイント | 問題文のヒント |
|---|---|---|
| Quality | 品質 | 不具合、性能、使いやすさ |
| Cost | 費用 | 予算、コスト、人件費 |
| Delivery | 納期 | 期限、スケジュール、納品日 |
WBSとは？
WBSとは、プロジェクトの作業を細かく分けたものです。基本の意味から確認したい方は、WBSとは？も参考にしてください。
Work Breakdown Structureの略で、日本語では作業分解構成図と呼ばれます。
かんたんに言うと、「やることリストを大きな仕事から小さな作業に分けたもの」です。
WBSは作業を細かく分けたもの
たとえば、Webサイトを作る仕事があるとします。
そのままでは大きすぎて、何をすればよいか分かりにくいです。
そこで、設計、画面作成、テスト、公開準備のように作業を分けます。
さらに、画面作成をトップページ作成、問い合わせページ作成、記事ページ作成のように分けます。
このように、作業を細かく分けるのがWBSです。
WBSでは、作業を大きなまとまりから小さな作業へ分けていきます。
いちばん下の細かい作業単位は、ワークパッケージと呼ばれます。
ワークパッケージまで分けると、担当者、作業期間、費用を決めやすくなります。
作業の抜け漏れを防ぐ
WBSを作ると、必要な作業を見落としにくくなります。
頭の中だけで考えると、テストや確認作業を忘れてしまうことがあります。
作業を分けて見えるようにすることで、抜け漏れを防ぎます。
担当や期間を決めやすくする
作業が細かく分かれていると、誰が担当するのか、どれくらい時間がかかるのかを決めやすくなります。
大きな作業のままだと、担当も期間もあいまいになります。
WBSは、計画を立てるための土台になります。
ガントチャートとの違い
WBSは「何をやるか」を分けたものです。
ガントチャートは「いつやるか」を日程に並べたものです。
この違いは、基本情報技術者試験でとてもよく問われます。
たとえると
WBSは、引っ越しでやることを「荷造り」「電気の手続き」「住所変更」のように分けることです。
ガントチャートは、それらを「何日にやるか」とカレンダーに並べることです。
ガントチャートとは？
ガントチャートとは、作業の予定や進み具合を横棒で表した図です。基本の意味から確認したい方は、ガントチャートとは？も参考にしてください。
作業ごとの開始日、終了日、期間を見えるようにできます。
ガントチャートは作業予定を横棒で表したもの
ガントチャートでは、縦に作業名を並べ、横に日付や期間を並べます。
それぞれの作業を横棒で表すことで、いつ始まり、いつ終わるのかが分かります。
文章だけで予定を書くよりも、全体の流れをつかみやすくなります。
作業期間を見える化する
ガントチャートを見ると、どの作業が長いのか、どの作業が重なっているのかが分かります。
複数の作業を同時に進められるか、先に終わらせる必要がある作業は何かを考えやすくなります。
進み具合を確認する
ガントチャートは、予定だけでなく進み具合の確認にも使えます。
予定より遅れている作業があれば、早めに対策できます。
たとえば、担当を増やす、作業の順番を見直す、範囲を調整するなどの判断につながります。
WBSとセットで理解する
ガントチャートは、WBSで分けた作業をもとに作ることが多いです。
まずWBSで「何をやるか」を決めます。
そのあと、ガントチャートで「いつやるか」を決めます。
WBSとガントチャートの関係
WBSとガントチャートは、どちらもプロジェクト管理で使います。
ただし、役割は違います。
WBSは作業を細かく分けるもの
WBSは、プロジェクトに必要な作業を分けるために使います。
目的は、作業の全体像をはっきりさせることです。
「何をやる必要があるか」を整理するためのものです。
ガントチャートは作業を日程に並べるもの
ガントチャートは、作業を日程に並べるために使います。
目的は、作業の順番や期間を見えるようにすることです。
「いつやるか」「どれくらい進んでいるか」を確認するためのものです。
WBSからガントチャートを作る流れ
WBSとガントチャートは、次の流れで考えると分かりやすいです。
- プロジェクトの目的を決める
- WBSで作業を細かく分ける
- 作業ごとに担当者を決める
- 作業ごとに期間を見積もる
- ガントチャートで日程に並べる
- 進み具合を確認する
何をやるかと、いつやるかを分けて考える
問題で迷ったら、「何をやるか」と「いつやるか」を分けて考えましょう。
作業を分ける話ならWBSです。
日程や横棒の図、進み具合の話ならガントチャートです。
| 用語 | 役割 | 見分け方 |
|---|---|---|
| WBS | 作業を分ける | 何をやるかを整理する |
| ガントチャート | 日程に並べる | いつやるかを見える化する |
リスク管理とは？
リスク管理とは、問題が起きる可能性を考え、前もって対策することです。
基本情報技術者試験では、リスクの意味や、リスクへの対応方法が問われます。
リスクは問題が起きる可能性
リスクとは、まだ起きていないが、起きる可能性がある問題です。
たとえば、開発メンバーが不足するかもしれない、外部サービスが止まるかもしれない、仕様変更が増えるかもしれない、といったことです。
すでに起きている問題は、リスクではなく課題と考えます。
リスクを洗い出す
リスク管理では、まずどのようなリスクがあるかを洗い出します。
思いついたものをただ並べるだけではなく、プロジェクトに影響しそうなものを整理します。
人、費用、日程、品質、外部サービス、法律やルールなど、さまざまな面から考えます。
発生確率と影響度を見る
リスクは、発生確率と影響度で考えます。
発生確率は、そのリスクがどれくらい起きやすいかです。
影響度は、起きたときにどれくらい大きな影響があるかです。
発生確率も影響度も高いリスクは、優先して対策します。
回避・低減・移転・受容の考え方
リスクへの対応には、代表的に回避、低減、移転、受容があります。
| 対応 | 意味 | 例 |
|---|---|---|
| 回避 | リスクが起きる原因をなくす | 危険な方法をやめて別の方法に変える |
| 低減 | 起きる可能性や影響を小さくする | 事前テストを増やして不具合を減らす |
| 移転 | リスクの影響を外部に移す | 保険に入る、外部業者に任せる |
| 受容 | リスクを受け入れる | 影響が小さいので特別な対策をしない |
問題でリスク対応を見分けるポイント
問題文に「事前に」「発生する可能性」「影響度」「対策を検討する」などが出たら、リスク管理を考えます。
また、対応策の見分け方も大切です。
危ない作業そのものをやめるなら回避です。
起きにくくする、または影響を小さくするなら低減です。
保険や外部委託で影響を移すなら移転です。
対策せず受け入れるなら受容です。
サービス管理とは？
サービス管理とは、システムやITサービスを安定して使えるように運用することです。
システムは、作って公開すれば終わりではありません。
利用者が使い続けられるように、問い合わせ、障害、変更、品質を管理する必要があります。
サービス管理は安定して使えるように運用すること
サービス管理の目的は、利用者が安心してサービスを使える状態を保つことです。
たとえば、社内の勤怠システムや販売管理システムが止まると、仕事に大きな影響が出ます。
そのため、トラブルに早く対応し、同じ問題をくり返さないように管理します。
利用者からの問い合わせに対応する
サービス管理では、利用者からの問い合わせや依頼にも対応します。
たとえば、「ログインできない」「画面の使い方が分からない」「エラーが出た」といった問い合わせです。
この窓口の役割を持つのがサービスデスクです。
障害や変更を管理する
運用中のシステムでは、障害が起きることがあります。
また、機能追加や設定変更が必要になることもあります。
このような障害や変更を場当たり的に行うと、別のトラブルを起こすことがあります。
そのため、インシデント管理、問題管理、変更管理、リリース管理のような考え方が必要です。
サービスの品質を保つ
サービス管理では、サービスの品質を保つことも大切です。
どれくらいの時間使えるようにするか、問い合わせに何時間以内に対応するかなどを決めます。
このような約束を明確にするものがSLAです。
SLAとは？
SLAとは、Service Level Agreementの略です。
日本語では、サービスレベル合意書と呼ばれます。
かんたんに言うと、サービスを提供する側と利用する側の約束です。
SLAはサービスレベルの合意
SLAでは、サービスをどの水準で提供するかを決めます。
たとえば、システムをどれくらいの時間使えるようにするか、障害時にどれくらいで対応するかを決めます。
約束を文章で明確にすることで、利用者と提供者の認識のずれを防ぎます。
稼働時間や対応時間を決める
SLAで決める内容には、稼働時間や対応時間があります。
たとえば、次のような内容です。
- 月間稼働率を99.9％以上にする
- 障害の受付時間を平日9時から18時までにする
- 重大な障害は2時間以内に一次対応する
- 問い合わせの回答期限を決める
稼働率や可用性の考え方をあわせて確認したい方は、基本情報技術者試験のクラウド・システム構成入門も参考にしてください。
利用者と提供者の約束を明確にする
SLAがないと、利用者は「もっと早く対応してくれると思っていた」と感じるかもしれません。
提供者は「そこまでの対応は契約に入っていない」と考えるかもしれません。
SLAは、このような認識のずれを防ぐためのものです。
問題でSLAを見分けるポイント
問題文に「サービスレベル」「合意」「稼働率」「対応時間」「利用者と提供者の約束」などが出たら、SLAを考えます。
単なる問い合わせ窓口の話ならサービスデスクです。
サービスの水準を合意する話ならSLAです。
インシデント管理とは？
インシデント管理とは、サービスに影響する出来事が起きたときに、早く通常の状態へ戻すための管理です。インシデントの基本の意味を確認したい方は、インシデントとは？も参考にしてください。
基本情報技術者試験では、問題管理との違いがよく問われます。
インシデントはサービスに影響する出来事
インシデントとは、サービスの利用に影響する出来事です。
たとえば、システムにログインできない、画面が表示されない、プリンターが使えない、といったことです。
大切なのは、利用者が困っている状態を早く解消することです。
早く通常の状態に戻すことが目的
インシデント管理の目的は、早く復旧することです。
根本原因を完全に調べることよりも、まず利用者が作業できる状態に戻すことを優先します。
たとえば、サーバーの原因調査に時間がかかる場合、一時的に別のサーバーへ切り替えて使えるようにすることがあります。
原因の完全解決より復旧を優先する
インシデント管理では、応急処置を行うことがあります。
原因が完全に分かっていなくても、サービスを使える状態に戻すことを優先します。
これは、病院でまず痛みを抑える処置をすることに似ています。
問題管理との違い
インシデント管理と問題管理は、目的が違います。
インシデント管理は、早く復旧することが目的です。
問題管理は、根本原因を調べ、再発を防ぐことが目的です。
| 用語 | 目的 | 見分け方 |
|---|---|---|
| インシデント管理 | 早く復旧する | 使えない状態を早く直す |
| 問題管理 | 根本原因を調べる | なぜ起きたかを調べ、再発を防ぐ |
問題管理・変更管理・リリース管理
システム運用では、障害の原因を調べたり、変更を安全に行ったり、本番環境へ反映したりします。
ここで出てくるのが、問題管理、変更管理、リリース管理です。
問題管理は根本原因を調べる
問題管理とは、インシデントの根本原因を調べ、再発を防ぐための管理です。
たとえば、何度も同じ障害が起きる場合、その場で復旧するだけでは不十分です。
なぜ同じ障害が起きるのかを調べ、原因を取り除く必要があります。
このように、原因調査と再発防止を行うのが問題管理です。
変更管理は変更による影響を管理する
変更管理とは、システムの変更を安全に行うための管理です。
たとえば、設定を変える、プログラムを修正する、機器を入れ替えるといった作業があります。
変更は便利な反面、新しい障害を生むことがあります。
そのため、変更の内容、影響範囲、実施するタイミング、戻し方を事前に確認します。
重要な変更では、変更してよいかを確認するために、変更審査委員会が関わることがあります。
変更審査委員会は、CCBと呼ばれることもあります。
CCBでは、変更の必要性、影響範囲、リスク、実施時期などを確認し、変更を承認するかどうかを判断します。
リリース管理は変更を本番環境へ反映する
リリース管理とは、変更した内容を本番環境へ反映するための管理です。
本番環境とは、利用者が実際に使う環境のことです。
テスト環境で確認した変更を、いつ、どのような手順で本番へ反映するかを管理します。
3つを運用の流れで理解する
問題管理、変更管理、リリース管理は、流れで理解すると分かりやすいです。
- 障害が起きる
- インシデント管理で早く復旧する
- 問題管理で根本原因を調べる
- 修正が必要なら変更管理で影響を確認する
- 重要な変更ならCCBで承認を受ける
- リリース管理で本番環境へ反映する
問題で迷ったときは、今どの段階の話をしているのかを確認しましょう。
基本情報技術者試験で間違えやすいマネジメント用語
マネジメント分野では、似た言葉の違いを問う問題が出ます。
言葉の名前だけで覚えると間違えやすいため、役割で見分けましょう。
WBSとガントチャートの違い
WBSは、作業を細かく分けるものです。
ガントチャートは、作業を日程に並べるものです。
問題文に「作業を分解する」「作業の構成を示す」とあればWBSです。
「横棒」「日程」「進捗」「開始日と終了日」とあればガントチャートです。
リスクと課題の違い
リスクは、まだ起きていないが起きる可能性があるものです。
課題は、すでに起きていて対応が必要なものです。
たとえば、「担当者が退職するかもしれない」はリスクです。
「担当者が退職し、作業が止まっている」は課題です。
SLAとサービスデスクの違い
SLAは、サービスの水準に関する合意です。
サービスデスクは、利用者からの問い合わせを受ける窓口です。
「稼働率」「対応時間」「合意」という言葉があればSLAです。
「問い合わせ」「窓口」「利用者対応」という言葉があればサービスデスクです。
インシデント管理と問題管理の違い
インシデント管理は、早く復旧することが目的です。
問題管理は、根本原因を調べて再発を防ぐことが目的です。
「とにかく使えるように戻す」ならインシデント管理です。
「なぜ起きたかを調べる」なら問題管理です。
変更管理とリリース管理の違い
変更管理は、変更してよいか、影響はないかを管理します。
リリース管理は、変更した内容を本番環境へ反映することを管理します。
「変更の承認」「影響範囲」「戻し方」「CCB」なら変更管理です。
「本番環境へ反映」「リリース計画」「展開」ならリリース管理です。
マネジメント問題の解き方
マネジメント問題は、用語を知っているだけでは解けないことがあります。
問題文の場面を読み取り、どの管理の話なのかを判断することが大切です。
開発の話か運用の話か確認する
まず、問題文が開発の話か、運用の話かを確認します。
開発の話なら、QCD、WBS、ガントチャート、リスク管理が出やすくなります。
運用の話なら、SLA、インシデント管理、問題管理、変更管理、リリース管理が出やすくなります。
何を管理しているのかを見る
次に、何を管理しているのかを見ます。
品質、費用、納期ならQCDです。
作業の分解ならWBSです。
日程や進み具合ならガントチャートです。
起きる可能性のある問題ならリスク管理です。
目的が復旧か原因調査かを見分ける
運用の問題では、目的を確認します。
早く使える状態に戻すならインシデント管理です。
根本原因を調べて再発を防ぐなら問題管理です。
ここは非常に間違えやすいので、問題文の目的に注目しましょう。
用語の名前ではなく役割で判断する
基本情報技術者試験では、用語の名前を少し言い換えて問われることがあります。
そのため、丸暗記だけでは対応しにくいです。
「この用語は何をするものか」「何のために使うのか」を考えて選びましょう。
選択肢の似た言葉に注意する
マネジメント分野では、似た言葉が選択肢に並ぶことがあります。
特に、インシデント管理と問題管理、変更管理とリリース管理、WBSとガントチャートは注意が必要です。
選択肢を見たら、名前ではなく役割に置き換えて判断しましょう。
基本情報技術者試験ではマネジメントがどう出る？
基本情報技術者試験では、マネジメント分野の用語が科目Aで問われます。
また、問題文の中でプロジェクトや運用の場面を読み取る力も必要です。
プロジェクト管理の用語を問う問題
プロジェクト管理では、作業範囲、日程、費用、品質などを管理する用語が問われます。
特に、プロジェクトには目的と期限があることを押さえておきましょう。
スコープ管理では、作業範囲を見えるようにするためにWBSが使われます。WBSの最下層の作業単位をワークパッケージと呼ぶ点も、あわせて押さえておくと理解が深まります。
QCDやリスク管理を問う問題
QCDでは、品質、費用、納期の3つを見分ける問題が出ます。
リスク管理では、発生確率と影響度、リスク対応の種類が問われます。
回避、低減、移転、受容の違いは整理しておきましょう。
WBSやガントチャートを問う問題
WBSとガントチャートは、セットで問われやすい用語です。
WBSは作業を分けるものです。
ガントチャートは作業を日程に並べるものです。
「何をやるか」と「いつやるか」を分けて覚えましょう。
SLAやサービス管理を問う問題
SLAでは、サービスの水準を合意することが問われます。
稼働率、対応時間、受付時間、利用者と提供者の合意といった言葉に注目しましょう。
インシデント管理と問題管理を見分ける問題
インシデント管理と問題管理は、基本情報技術者試験で間違えやすい組み合わせです。
インシデント管理は早く復旧することです。
問題管理は根本原因を調べることです。
問題文の目的が「復旧」なのか「原因調査」なのかを見て判断しましょう。
確認問題
ここまでの内容を確認しましょう。
QCDの3つは何ですか？
QCDの3つは、Quality、Cost、Deliveryです。
- Quality：品質
- Cost：費用
- Delivery：納期
システム開発では、この3つのバランスを取りながら進めることが大切です。
WBSとガントチャートの違いは何ですか？
WBSは、作業を細かく分けるものです。
ガントチャートは、作業を日程に並べるものです。
つまり、WBSは「何をやるか」、ガントチャートは「いつやるか」を整理するものです。
インシデント管理と問題管理の違いは何ですか？
インシデント管理は、サービスに影響する出来事が起きたときに、早く通常の状態へ戻すための管理です。
問題管理は、根本原因を調べ、再発を防ぐための管理です。
試験では、「早く復旧する」ならインシデント管理、「原因を調べる」なら問題管理と見分けましょう。
変更管理とリリース管理の違いは何ですか？
変更管理は、変更してよいか、変更による影響はないかを管理することです。
重要な変更では、変更審査委員会、つまりCCBが承認に関わることがあります。
リリース管理は、承認された変更を本番環境へ反映することを管理します。
試験では、「変更の承認」「影響範囲」「CCB」なら変更管理、「本番環境へ反映」ならリリース管理と見分けましょう。
まとめ
基本情報技術者試験のマネジメントでは、プロジェクト管理とサービス管理の用語が問われます。
プロジェクト管理では、QCD、WBS、ガントチャート、リスク管理が重要です。
QCDは、品質、費用、納期のバランスです。
WBSは作業を細かく分けるもの、ガントチャートは作業を日程に並べるものです。
WBSの最下層の作業単位は、ワークパッケージと呼ばれます。
リスク管理では、まだ起きていない問題の可能性を考え、発生確率と影響度を見て対策します。
サービス管理では、SLA、インシデント管理、問題管理、変更管理、リリース管理が重要です。
SLAは、サービスの水準について利用者と提供者が合意するものです。
インシデント管理は早く復旧すること、問題管理は根本原因を調べることです。
変更管理は変更の影響を管理し、重要な変更ではCCBが承認に関わることがあります。
リリース管理は、変更を本番環境へ反映する管理です。
マネジメント問題では、用語の名前だけでなく、何を目的にした管理なのかを見分けることが大切です。
マネジメントを含めた基本情報全体の進め方は、基本情報技術者試験の勉強方法も参考にしてください。