マネジメント

稼働率とは？可用性の考え方とSLAでの判断基準【情報セキュリティマネジメント】

Source: pages\sg\availability.md
Permalink: /sg/availability/

まず結論

稼働率とは「サービスが使える状態だった割合」であり、可用性（Availability）を数値で表したもの
SG試験では「どの時間を対象にするか」と「停止時間の扱い」を正しく判断できるかが問われる

直感的な説明

稼働率はシンプルに言うと、

👉 「どれくらい止まらずに動いていたか」

です。

例えば会社のシステムで、

50時間中1時間止まった → ほぼ動いている
50時間中10時間止まった → かなり止まっている

👉 この「ちゃんと使えた割合」が稼働率です。

定義・仕組み

稼働率は、基本的に次の考え方で求めます。

👉 稼働率＝（稼働時間）÷（サービス提供時間）

別の言い方をすると、

👉 稼働率＝（サービス提供時間 − 停止時間）÷ サービス提供時間

MTBF・MTTRとの関係

MTBF：平均故障間隔（どれくらい長く動くか）
MTTR：平均復旧時間（どれくらいで直るか）

👉 稼働率は次の関係でも表せます

稼働率＝ MTBF ÷（MTBF ＋ MTTR）

SG試験での重要ポイント

① 分母を間違えない

❌ 24時間 × 日数
⭕ サービス提供時間だけ

② 停止時間の扱い

障害停止 → 含める
計画停止 → 条件次第

👉 「サービス提供時間外なら含めない」

③ 条件文を読む

営業日
提供時間帯
停止の条件

👉 ここを読み取る問題

どんな場面で使う？

使う場面

SLA（サービスレベル合意）で品質を決めるとき
クラウドやシステム運用の評価
業務システムの安定性判断

👉 SG試験では
「この稼働率は妥当か？」と判断させる問題が出る

注意が必要な場面

可用性（概念）と稼働率（数値）を混同する
提供時間と全時間を混同する
回数制限と時間制限を混同する

よくある誤解・混同

❌ 誤解①

「稼働率は常に24時間基準」

👉 ⭕ サービス提供時間が基準

❌ 誤解②

「停止回数も計算に使う」

👉 ⭕ 稼働率は時間だけを見る

❌ 誤解③

「計画停止は全部含める」

👉 ⭕ 条件文で判断する

SG試験のひっかけ

「営業日」「時間帯」を無視させる
「MTBF・MTTR」を出して混乱させる
「回数制限」を計算に入れさせる

👉 選択肢では
分母がズレているものを切る

まとめ（試験直前用）

稼働率＝使えた時間 ÷ 提供時間
分母は「サービス提供時間」
停止時間は「条件文で判断」
回数ではなく「時間」で考える
SG試験は
👉 「何を分母にしたか」で正誤が決まる

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

契約不適合責任とは？瑕疵担保責任との違いも整理【情報セキュリティマネジメント】

Source: pages\sg\contract-nonconformity.md
Permalink: /sg/contract-nonconformity/

まず結論

契約不適合責任とは「契約どおりでない成果物に対する責任」
SG試験では「完成後の不具合の責任」を問う問題で出る

👉 契約どおりかどうかで判断する

直感的な説明

イメージで考えると👇

約束したものと違う → 責任あり
約束どおり → 問題なし

例えば…

「この機能を持つシステム」と契約
→ 実際は機能が足りない

👉 契約不適合 → 責任発生

定義・仕組み

■ 契約不適合責任

成果物が契約内容と一致しない場合に発生
修正・損害賠償などの責任を負う

👉 契約とのズレがポイント

■ 何が請求できる？

発注側は👇を要求できる

修補（修正）
代替品の提供
損害賠償
契約解除

👉 状況に応じて選択できる

■ 旧制度との違い（軽く）

旧：瑕疵担保責任（キズがあるか）
新：契約不適合責任（契約どおりか）

👉 「契約基準」に変わった

どんな場面で使う？

■ システム開発（請負契約とセット）

納品されたシステムに不具合
要件どおり動かない

👉 契約不適合責任が問題になる

■ 委託先管理（科目B）

ベンダーとのトラブル
納品後の対応

👉 契約内容が重要になる

よくある誤解・混同

❌ バグがあればすべて責任になる

→ 誤り

👉 契約に含まれていなければ対象外

❌ 完成していれば問題ない

→ 誤り

👉 完成していても契約と違えばNG

❌ 準委任契約でも同じ責任がある

→ 誤り（重要）

👉 原則は請負契約で問題になる

SG試験のひっかけ

「契約どおり」→ OK
「期待どおり」→ NGの可能性

👉 “契約”という言葉に注目する

まとめ（試験直前用）

契約不適合責任 → 契約と違えば発生
判断基準 → 「契約どおりか？」
請負契約とセットで出る

👉 YES → 問題なし
👉 NO → 責任発生

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

就業形態の違いを完全整理【SG試験で迷わない判断基準】

Source: pages\sg\employment-type-comparison.md
Permalink: /sg/employment-type-comparison/

まず結論

就業形態は「雇用契約先」と「指揮命令者」で切り分ける
SG試験では「誰に責任があるか」を判断させる問題として出題される

直感的な説明

同じ職場にいても、実はこんな違いがあります。

社員A → 会社に直接雇われている
社員B → 別の会社に雇われて派遣されている

👉 見た目ではなく
👉 「誰と契約しているか」が本質

定義・仕組み

■ まずは全体の切り分け（超重要）

区分	雇用契約先	指揮命令
正社員・契約社員・アルバイト・パート	就業先企業	就業先企業
派遣社員	派遣会社	就業先企業

👉 ここが最重要
派遣だけ「雇用」と「指示」が分かれる

■ 就業形態の違いまとめ（試験対策用）

以下の表で「契約期間・労働時間・雇用契約先」を整理しておくと、SG試験で迷いません。

就業形態	契約期間	労働時間	雇用契約先
アルバイト	有限	短時間	就業先企業
契約社員	有限	正社員と同じ	就業先企業
派遣社員	（契約は派遣会社と）	正社員と同じ	人材派遣会社
パートタイマー	なし（または柔軟）	短時間	就業先企業

👉 SG試験での最重要ポイント

派遣社員だけ「雇用契約先」が違う（＝人材派遣会社）

👉 切り分けのコツ

「その人は誰に雇われているか？」で判断する

■ 個別の違い

正社員

無期雇用（期間の定めなし）
フルタイムが基本

契約社員

有期契約（期間あり）
仕事内容・条件が明確

アルバイト

有期契約
短時間・副業的な位置づけが多い

パートタイマー

短時間勤務
労働時間が短いことが特徴

派遣社員（最重要）

雇用契約 → 派遣会社
指揮命令 → 就業先企業

👉 SG試験ではここが狙われる

どんな場面で使う？

■ SG試験での典型パターン

① 教育・訓練の責任

派遣社員 → 派遣会社と就業先の両方が関係
直接雇用 → 自社が責任

② 情報セキュリティ事故

誰が責任を負うか？ → 雇用契約・指揮命令で判断

③ 委託先管理

派遣社員は「外部扱い」に近い

👉 科目Bでめちゃくちゃ出るポイント

よくある誤解・混同

❌ よくある誤解①

「同じ場所で働いている＝同じ会社の社員」

👉 完全にNG

❌ よくある誤解②

「契約社員は外部の人」

👉 誤り
→ 契約社員は内部（直接雇用）

❌ よくある誤解③

「派遣社員は就業先と契約している」

👉 誤り（超頻出） → 契約は派遣会社

SG試験のひっかけまとめ

「派遣社員＝自社の従業員」→ ❌
「契約社員＝外部」→ ❌
「パート＝特別な制度」→ ❌（ただの短時間労働）

まとめ（試験直前用）

判断基準はこの2つだけ
→ 雇用契約先
→ 指揮命令者
直接雇用
→ 正社員・契約社員・アルバイト・パート
派遣社員
→ 雇用：派遣会社
→ 指示：就業先

👉 迷ったらこれ
「派遣だけ別物」

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

MTBFとは？平均故障間隔の意味と稼働率との関係【情報セキュリティマネジメント】

Source: pages\sg\mtbf.md
Permalink: /sg/mtbf/

まず結論

MTBFとは「故障してから次に故障するまでの平均時間（どれくらい長く動き続けるか）」を表す指標
SG試験では「MTTRとの違い」と「稼働率との関係」を正しく切り分けられるかが問われる

直感的な説明

MTBFはシンプルに言うと、

👉 「どれくらい壊れにくいか」

です。

例えば、

MTBFが長い → なかなか壊れない（安定）
MTBFが短い → すぐ壊れる（不安定）

👉 「連続して動ける時間の長さ」と考えると分かりやすいです。

定義・仕組み

MTBF（Mean Time Between Failures）は、

👉 1回の故障から次の故障までの平均稼働時間

を表します。

イメージ

システムの状態は次のように繰り返します。

稼働 → 故障 → 修理 → 稼働 → 故障 → 修理

👉 このうち
「稼働している時間の平均」がMTBF

MTTRとの関係

MTBF：どれだけ長く動くか（稼働時間）
MTTR：どれだけ早く直るか（停止時間）

👉 セットで出題されることが多い

稼働率との関係

稼働率は次の関係で表されます。

👉 稼働率＝ MTBF ÷（MTBF ＋ MTTR）

SG試験でのポイント

MTBFが長い → 故障しにくい → 可用性が高い
MTBFが短い → 故障しやすい → 可用性が低い

👉 可用性（稼働率）とセットで考える

どんな場面で使う？

使う場面

システムの信頼性評価
サーバやネットワーク機器の選定
SLAの設計（どの程度安定させるか）

👉 科目Bでは
「この構成は安定か？」を判断する材料になる

注意が必要な場面

MTTRと混同する
「復旧時間」と勘違いする
稼働率そのものと勘違いする

よくある誤解・混同

❌ 誤解①

「MTBFは復旧時間」

👉 ⭕ MTBFは
“壊れていない時間”

❌ 誤解②

「MTBFが長ければ復旧も早い」

👉 ⭕ 無関係
復旧の速さはMTTR

❌ 誤解③

「MTBF＝稼働率」

👉 ⭕ 違う
稼働率はMTTRとセットで決まる

SG試験のひっかけ

MTBFとMTTRを入れ替えて出す
「平均復旧時間」と書いてMTBFを選ばせる
稼働率と混同させる

👉 選択肢では
“壊れていない時間か？”を確認する

まとめ（試験直前用）

MTBF＝故障と故障の間の時間（稼働時間）
長いほど「壊れにくい」
MTTRとセットで覚える
稼働率はMTBFとMTTRで決まる
SG試験は
👉 「壊れている時間か？動いている時間か？」で切る

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

MTTRとは？平均復旧時間の意味と短縮の考え方【情報セキュリティマネジメント】

Source: pages\sg\mttr.md
Permalink: /sg/mttr/

まず結論

MTTRとは「障害が発生してから復旧するまでの平均時間」を表す指標
SG試験では「MTBFとの違い」と「短縮するための運用」を判断できるかが問われる

直感的な説明

MTTRはシンプルに言うと、

👉 「どれくらい早く直せるか」

です。

例えば、

MTTRが短い → すぐ復旧できる（影響が小さい）
MTTRが長い → 復旧に時間がかかる（業務影響が大きい）

👉 「止まった後、どれだけ早く元に戻せるか」と考えると分かりやすいです。

定義・仕組み

MTTR（Mean Time To Repair / Recovery）は、

👉 障害発生から復旧完了までの平均時間

を表します。

イメージ

システムは次のように動きます。

稼働 → 故障 → 修理 → 稼働

👉 このうち
「故障している時間」がMTTR

MTBFとの関係

MTBF：壊れていない時間（稼働時間）
MTTR：壊れている時間（復旧時間）

👉 この2つでシステムの可用性が決まる

稼働率との関係

👉 稼働率＝ MTBF ÷（MTBF ＋ MTTR）

MTTRが短い → 稼働率が上がる
MTTRが長い → 稼働率が下がる

SG試験でのポイント

MTTRは「短いほど良い」
運用改善で短縮できる指標

👉 技術よりも運用の問題として問われることが多い

どんな場面で使う？

使う場面

障害対応プロセスの評価
インシデント管理（復旧対応）
SLAでのサービス品質管理

👉 科目Bでは
「復旧を早くするには何をすべきか？」が問われる

MTTRを短くする具体例

手順書の整備（対応の標準化）
監視の強化（早期検知）
予備機・バックアップの準備
担当者教育・訓練

👉 これがそのまま選択肢になる

よくある誤解・混同

❌ 誤解①

「MTTRは壊れにくさの指標」

👉 ⭕ 違う
復旧の速さの指標

❌ 誤解②

「MTTRが長い＝安定している」

👉 ⭕ 逆
復旧が遅いだけ

❌ 誤解③

「MTBFと同じ意味」

👉 ⭕ 完全に別

MTBF：壊れない時間
MTTR：直す時間

SG試験のひっかけ

MTBFとMTTRを逆にする
「平均復旧時間」をMTBFと誤認させる
技術対策と運用対策を混同させる

👉 選択肢では
「復旧を早くする話か？」を見る

まとめ（試験直前用）

MTTR＝復旧までの時間
短いほど良い（影響が小さい）
MTBFとセットで覚える
稼働率に直接影響する
SG試験は
👉 「復旧の速さの話か？」で判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

請負契約と派遣契約の違いとは？指示系統で判断するポイント【SG試験】

Source: pages\sg\outsourcing-contract-difference.md
Permalink: /sg/outsourcing-contract-difference/

まず結論

請負契約は「成果物に責任を持つ契約」、派遣契約は「人を提供して指示を受けて働く契約」
SG試験では「誰が誰に作業指示できるか」を判断させる問題としてよく出題される

直感的な説明

外注の形には大きく2パターンあります。

請負契約
→「仕事を丸ごと任せる（結果で評価）」
派遣契約
→「人を借りて、自分たちの指示で働いてもらう」

例えば、

ホームページ制作を丸投げ → 請負
エンジニアを常駐させて作業 → 派遣

というイメージです。

この違いが、指示を出してよい相手を決めます。

定義・仕組み

請負契約

成果物に対して責任を持つ契約
発注元（依頼する側）は、作業の中身に直接口出ししない
作業指示は「受注側の責任者」が行う

👉 ポイント
発注元 → 作業者に直接指示はNG

派遣契約

人材を提供し、派遣先の指示で働く契約
作業指示は「派遣先」が行う

👉 ポイント
派遣先 → 作業者に直接指示OK

SG試験での本質

SG試験では細かい法律よりも、

👉「指示系統が正しいかどうか」

を判断させる問題が中心です。

どんな場面で使う？

請負契約が使われる場面

システム開発を一括委託
保守運用を外部に丸投げ

👉 「成果で責任を持たせたい」とき

派遣契約が使われる場面

社内に常駐して開発
チームの一員として作業

👉 「自分たちで指示して動かしたい」とき

注意すべき場面

SG試験では、

請負なのに直接指示している
派遣なのに指示していない

という「逆パターン」がよく出ます。

よくある誤解・混同

❌ 請負でも細かく指示してよい

→ NG

請負では、発注元が作業者に直接指示するのは不適切
（指示は受注側の責任者経由）

❌ 派遣なら何でも自由に指示できる

→ 注意

業務指示はできるが、

就業条件の変更
契約内容の変更

などは別問題

SG試験のひっかけ

SG試験では次のように問われることが多いです。

「A社がB社の要員に直接指示」→ 不適切（請負）
「派遣なのに指示していない」→ 不適切
「就業条件を現場で勝手に変更」→ 不適切

👉 「指示してよい関係か？」で切る

まとめ（試験直前用）

請負：成果物責任 → 直接指示NG
派遣：労働提供 → 直接指示OK
SG試験では「指示系統」が最重要ポイント
選択肢では「誰が誰に指示しているか」を必ず確認する
「契約形態と指示の関係がズレていたら誤り」と判断する

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

SLAの問題まとめ（稼働率の考え方と計算のコツ）【情報セキュリティマネジメント】

Source: pages\sg\sla-summary.md
Permalink: /sg/sla-summary/

まず結論

SLA（サービスレベル合意）の問題は「サービス提供時間」と「停止時間」を正しく切り分けて、稼働率を判断する問題
SG試験では「どの時間を分母にするか」「どの停止を含めるか」を見極めさせる

直感的な説明

SLAは「どれくらいちゃんとサービスを動かすか」という約束です。

例えば会社のシステムでいうと、

営業時間中は止まると困る
夜間のメンテナンスはOK

というように、「止まっていい時間」と「ダメな時間」があります。

👉 つまり
“全部の時間”ではなく“約束した時間だけ”で考えるのがポイントです。

定義・仕組み

SLA（Service Level Agreement）は、サービス提供者と利用者の間で決める「品質の約束」です。

SG試験では特に「可用性（稼働率）」がよく問われます。

基本の考え方

稼働率＝（サービス提供時間 − 停止時間） ÷ サービス提供時間

ここで重要なのは次の3点です。

① 分母（サービス提供時間）

24時間ではなく「サービス提供時間帯」を使う
例：営業日9時〜19時 → 1日10時間

👉 SG試験では
「提供時間を読み取れるか」が最重要ポイント

② 停止時間に含めるもの

障害停止 → 含める
計画停止 → 条件による

👉 「サービス提供時間帯に行わない」と書いてあれば
計画停止は含めない

③ 複数条件の扱い

例：

停止回数：2回以下
停止時間：合計1時間以内

👉 稼働率に使うのは
「合計時間」だけ

回数は品質管理の条件であり、計算には使わない

どんな場面で使う？

使う場面

委託先との契約（クラウド・システム運用）
社内システムの運用ルール決定
サービス品質の評価

👉 科目Bでは
「この条件で妥当か？」を判断させる問題が出る

注意が必要な場面

24時間サービスと勘違いする
計画停止を全部含めてしまう
回数制限を時間に換算してしまう

よくある誤解・混同

❌ よくある誤解①

「1週間＝24時間×7日で計算する」

👉 ⭕ 正しくは
サービス提供時間だけ使う

❌ よくある誤解②

「停止2回だから2時間止まると考える」

👉 ⭕ 正しくは
“合計時間”が上限

❌ よくある誤解③

「計画停止も全部ダウン時間に入れる」

👉 ⭕ 条件文を確認
提供時間外ならカウントしない

SG試験のひっかけ

「営業日」「提供時間帯」を読み飛ばさせる
「回数」と「時間」を混同させる
「計画停止」を入れるか迷わせる

👉 選択肢では
“24時間で計算しているもの”はほぼ誤り

まとめ（試験直前用）

稼働率は「サービス提供時間」を分母にする
停止時間は「合計時間」で判断（回数は使わない）
計画停止は条件を確認（時間外なら含めない）
SG試験では
👉 「何を分母にするか」でほぼ決まる

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る

SLAとは？サービス品質の約束を理解する【情報セキュリティマネジメント】

Source: pages\sg\sla.md
Permalink: /sg/sla/

まず結論

SLAとは「サービスの品質を数値で約束する取り決め」
SG試験では「サービスの品質管理」と「責任範囲」を判断させる問題で出る

👉 どこまで保証しているかを数値で確認する

直感的な説明

イメージで考えると👇

「だいたい動く」 → NG
「99.9％動く」 → OK

例えば…

システムの稼働率 99.9％
障害対応時間 1時間以内

👉 サービスのレベルを見える化したもの

定義・仕組み

■ SLA（Service Level Agreement）

サービス提供者と利用者の間の合意
品質を数値で定義する

👉 曖昧さをなくすための契約

■ 主な項目

稼働率（可用性）
応答時間
障害対応時間
サポート時間

👉 測れるものを決めるのがポイント

■ なぜ重要か

トラブル時の判断基準になる
「できているかどうか」を客観的に判断できる

どんな場面で使う？

■ クラウドサービス

SaaS / IaaS
外部サービス利用

👉 SLAで品質を確認する

■ 委託先管理（科目B）

運用・保守の外注
ベンダー管理

👉 「どこまでやるか」を明確にする

よくある誤解・混同

❌ SLAがあれば絶対に障害は起きない

→ 誤り

👉 あくまで「保証レベル」であってゼロにはならない

❌ SLAは努力目標

→ 誤り

👉 合意事項なので守るべき基準

❌ SLAと契約は別物

→ 誤り（重要）

👉 契約の一部として扱われることが多い

SG試験のひっかけ

「高品質」など曖昧な表現 → NG
「99.9％」など数値 → SLA

👉 数値かどうかで見分ける

まとめ（試験直前用）

SLA → サービス品質の数値化
判断基準 → 「数値で定義されているか」
委託先管理で重要

👉 数値あり → SLA
👉 曖昧表現 → NG

🔗 関連記事

関連記事は準備中です。

🏠 情報セキュリティマネジメントトップに戻る