基本情報技術者 用語集 マネジメント

スポンサーリンク

スポンサーリンク

Amazon公式サイト

プロジェクトマネジメントの基礎 ― 基本情報技術者 用語集

プロジェクトマネジメントは、基本情報技術者試験で必出の分野です。したがって、ここではプロジェクトの定義、QCD、PMBOKなどの基本用語をまとめて解説します。また、プロジェクト全体の流れも押さえておきましょう。

プロジェクトの基本

まず、プロジェクトという概念そのものを正しく理解することが大切です。たとえば、プロジェクトは「期間限定」「独自の成果物」「制約のなかで進める」という3つの特徴を持ちます。さらに、PMBOKやPMPなどの国際的な知識体系も基本情報技術者試験で問われます。

プロジェクト

独自の成果物やサービスを生み出すために、期間と資源を限定して行う一時的な活動。明確な開始と終了があり、定常業務とは区別される。期間・コスト・品質などの制約条件のなかで目標達成を目指す。例：新システム開発、オフィス移転、新商品立上げ、イベント開催

プロジェクトマネジメント

プロジェクトを計画・実行・統制・終結する一連の活動。QCDを満たすために資源・時間・リスクなどを適切に管理する。プロジェクトの成否を左右する重要な活動。例：スケジュール管理、コスト管理、品質管理、リスク管理を統合的に実施

QCD

Quality（品質）・Cost（コスト）・Delivery（納期）の頭文字。プロジェクトの3大要素であり、相互にトレードオフの関係にある。3つのバランスを取ることがプロジェクトマネジメントの核心。例：納期を短縮するためにコスト増加を許容する、品質を上げるために期間延長する

プロジェクトマネージャ（PM）

プロジェクト全体の責任者として、計画立案、進捗管理、ステークホルダ調整を担う役割。チームを率いて目標達成に導く。技術的スキルだけでなく対人スキルも求められる。例：プロジェクト全体の責任者として方針決定、進捗管理、リスク対応を統括

PMBOK

Project Management Body of Knowledge。プロジェクトマネジメントの知識体系で、米国PMIが発行する世界標準ガイド。10の知識エリアと5つのプロセス群で構成されている。例：スコープ管理、スケジュール管理、コスト管理など10の知識エリアを定義

PMP

Project Management Professional。PMIが認定するプロジェクトマネジメントの国際資格。プロジェクトマネージャの能力を客観的に証明する代表的な資格。例：35時間以上の研修と一定の実務経験を経て受験できる

ステークホルダ

プロジェクトに影響を与える、または影響を受ける関係者すべて。利害関係者ともいう。彼らの期待や要望を適切に管理することがプロジェクト成功の鍵。例：発注者、利用者、開発者、経営層、運用担当者、社会全体

プロジェクト憲章

プロジェクトの目的、範囲、責任者、予算などを定めた公式文書。プロジェクトの正式な開始を宣言し、PMの権限を明確にする。例：キックオフ時に経営層が承認し、PM任命と権限を文書化

プロジェクト計画書

プロジェクトの実行計画を具体的に文書化したもの。スケジュール、予算、リスク、体制などを記載する。プロジェクトの羅針盤として活用される。例：WBS、ガントチャート、リスク登録簿、コミュニケーション計画を統合した文書

キックオフミーティング

プロジェクト開始時に全メンバー参加で行う会議。目的、体制、スケジュール、役割分担などを共有し、チームの方向性を揃える。例：発注者・PM・チームメンバーが集まり、目標とルールを確認する初回会議

プロジェクトのプロセス群

次に、プロジェクトの進行段階を確認しましょう。PMBOKでは、プロジェクトを5つのプロセス群に整理しています。また、各プロセスがどう連動するかを理解すると、全体の流れがつかめます。

立上げプロセス

プロジェクトの開始を正式に決定する段階。プロジェクト憲章の作成やステークホルダの特定を行う。ここでプロジェクトの目的と範囲が明確になる。例：経営層の承認を得てプロジェクト憲章を発行し、PMを任命

計画プロセス

目標達成のための具体的な計画を立てる段階。WBS作成、スケジュール策定、予算編成、リスク計画などを行う。最も時間をかけるべき重要な段階。例：WBSで作業を分解し、ガントチャートで日程を作成、予算とリスクも策定

実行プロセス

計画に基づいて実際に作業を進める段階。開発作業の実施、チーム運営、ステークホルダ調整などを行う。例：開発・テストを計画通りに実施、進捗を関係者と共有

監視・コントロールプロセス

実行プロセスと並行して、進捗を測定し計画との差異を把握・是正する段階。変更管理、品質管理、リスク監視などを含む。例：EVMで進捗・コスト乖離を測定し、必要に応じて計画を修正

終結プロセス

プロジェクトを正式に終了する段階。成果物の引渡し、契約の完了、振り返り、チーム解散などを行う。教訓の蓄積も重要。例：成果物を発注者に引渡し、レッスンズラーンドを記録して次に活かす

プロジェクトライフサイクル

プロジェクトの開始から終了までの一連の流れ。立上げ→計画→実行→監視→終結という5段階で構成される。例：各段階で異なる活動と成果物が定義されている

プロジェクトの各管理領域 ― 基本情報技術者 用語集

プロジェクトマネジメントには、PMBOKで定義された10の知識エリアがあります。とくに、スコープ・スケジュール・コスト・品質・リスクの5領域は基本情報技術者試験で頻出です。また、それぞれの管理ツールも合わせて押さえておきましょう。

スコープ管理

まず、スコープ管理から見ていきましょう。スコープとは「何をやるか」を定義する活動です。さらに、WBSによる作業分解はスコープ管理の中核手法です。たとえば、要件追加要請への対応もスコープ管理の重要なテーマです。

スコープ

プロジェクトで行う作業や生み出す成果物の範囲。何を含み何を含まないかを明確に定義することで、後の混乱を防ぐ。プロジェクト憲章や要件定義書で文書化する。例：「会員管理機能は含む、決済機能は含まない」と明文化

スコープマネジメント

プロジェクトの作業範囲を明確化し、変更を管理する活動。範囲の追加要請に対しては、影響評価と正式な承認手続きを経て対応する。例：「ついでに〇〇も」という要望には影響評価して工数・期限を見直す

WBS

Work Breakdown Structure。作業分解構成図。プロジェクトを階層的に分解し、管理可能な単位まで細分化する手法。スケジュール・コスト見積の基礎となる。例：プロジェクト→工程→作業→タスクと段階的に分解

ワークパッケージ

WBSの最下位レベルの作業単位。これ以上分解しない最小単位で、見積・スケジュール・実績管理の対象となる。例：1〜2週間で完了できる粒度に分解した個別タスク

スコープクリープ

正式な変更管理を経ずに、スコープが少しずつ拡大していく現象。小さな要望の積み重ねが大きな遅延を生む原因となる。例：「ついでにこれも」が積み重なって全体スケジュールが大幅遅延

スケジュール管理

次に、スケジュール管理を見ていきます。たとえば、クリティカルパスを把握することは、遅延を防ぐうえで欠かせません。また、ガントチャートやアローダイアグラムなどの可視化手法も基本情報技術者試験で頻出です。

スケジュールマネジメント

プロジェクトの納期を守るため、作業日程を計画・実行・統制する活動。各作業の所要時間と依存関係を整理し、進捗を追跡する。例：作業洗い出し→順序設定→所要時間見積→スケジュール作成→進捗管理

ガントチャート

縦軸に作業、横軸に時間を取り、横棒で作業の開始・終了・期間を表すスケジュール図。直感的に進捗を可視化できる。例：Excel、Microsoft Project、Backlogなどで作成・管理

アローダイアグラム（PERT図）

作業の順序と依存関係を矢印で表現する図。各作業の所要時間や前後関係を視覚化でき、クリティカルパスの特定に使う。例：作業A→作業B→作業Cと矢印で繋ぎ、最長経路を識別

クリティカルパス

プロジェクト全体の所要日数を決定する最長の経路。この経路上の作業が遅れると、全体の納期に直接影響する。例：余裕日数がゼロの経路。ここの遅れは全体遅延に直結する

クリティカルパス法（CPM）

クリティカルパスを特定して重点的に管理する手法。プロジェクトの納期短縮や遅延防止に効果的。例：クリティカルパス上の作業に経験豊富な担当者を配置

フロート（余裕時間）

作業の遅れがプロジェクト全体に影響しない範囲の余裕時間。トータルフロートとフリーフロートの2種類がある。例：余裕5日のタスクは多少遅れても全体スケジュールに影響しない

マイルストーン

プロジェクトの重要な節目や中間目標。期日と達成基準を明確にして、進捗の目安とする。例：要件定義完了、結合テスト開始、本番リリース日

クラッシング

追加資源（人員・予算）を投入して工期を短縮する手法。コスト増加を伴うため慎重な判断が必要。例：人員追加や残業増加で期間を1ヶ月短縮

ファストトラッキング

順次行う予定だった作業を並行化して工期を短縮する手法。リスクは増えるがコスト増は少ない。例：詳細設計完了前に一部のコーディングを並行開始

コスト管理

続いて、コスト管理を見ていきます。とくに、見積技法とEVM（出来高管理）は基本情報技術者試験で頻出です。また、各見積技法の特徴を比較しながら理解しておきましょう。

コストマネジメント

プロジェクトの予算を見積・統制する活動。予算消化率を監視し、コスト超過を防ぐ。例：予算を立案し、実コストを追跡、必要に応じて是正措置

類推見積法

過去の類似プロジェクトの実績を参考に見積もる方法。簡便だが精度は中程度。プロジェクト初期の概算見積に向いている。例：「前回の似た案件は3ヶ月だったので今回も同等と見積もる」

係数見積法（パラメトリック法）

規模などのパラメータと係数を使った数式で見積もる方法。客観的だが係数の精度が結果を左右する。例：1人月あたり1,000行などの係数を使い、規模から工数を算出

ボトムアップ見積法

WBSの個別作業を積み上げてプロジェクト全体を見積もる方法。精度は高いが時間がかかる。例：各タスクの工数を集計してプロジェクト総工数を算出

三点見積法

楽観値・最頻値・悲観値の3点から期待値を計算する方法。不確実性を考慮した見積に適している。例：期待値=(楽観+4×最頻+悲観)÷6 でPERT式の期待工数を算出

ファンクションポイント法

機能数や複雑さに基づいて開発規模を見積もる方法。利用者視点で機能を数えるため、技術非依存。例：入出力、問合せ、データファイルの数からFP値を算出

COCOMO

Constructive Cost Model。コード行数を元に開発工数を見積もるモデル。プログラム規模から人月を算出する。例：10万行のプログラム規模を入力すると必要人月が出力される

EVM（出来高管理）

Earned Value Management。コストとスケジュールを統合的に管理する手法。PV・EV・ACの3指標で進捗とコストの乖離を分析する。例：時点ごとにPV/EV/ACを比較し、SVとCVで遅れ・超過を判定

PV（計画値）

Planned Value。計画ベースの予算。ある時点までに完了しているはずの作業に対する計画上の金額。例：計画上「1ヶ月時点で500万円分の作業が完了している予定」

EV（出来高）

Earned Value。実際に完了した作業に対応する予算額。実完了率に応じた価値を金額で表す。例：実際は60%完了→EV=計画予算500万円×60%=300万円

AC（実コスト）

Actual Cost。プロジェクトで実際にかかったコスト。投入された工数や費用の実績値。例：実際に投入された工数・費用の累積値

SV（スケジュール差異）

EV − PV。スケジュールの進捗状況を示す指標。正なら前倒し、負なら遅れを表す。例：SV=-50万円→計画より50万円分の作業が遅れている

CV（コスト差異）

EV − AC。コスト効率を示す指標。正ならコスト節約、負なら予算超過を表す。例：CV=-100万円→予算より100万円多くかかっている

品質管理

次に、品質マネジメントです。たとえば、QC7つ道具は実務でも頻繁に使われる品質管理の基本ツールです。また、品質保証と品質管理の違いも整理しておきましょう。

品質マネジメント

成果物が品質要件を満たすよう計画・実行・統制する活動。品質計画、品質保証、品質管理の3つのプロセスで構成される。例：品質計画→品質保証（プロセス遵守）→品質管理（成果物検査）

品質保証（QA）

プロセスの遵守によって品質を担保する活動。標準プロセスや手順が守られているかを評価する。例：標準プロセスの監査、レビュー実施状況の確認

品質管理（QC）

成果物の品質を測定・検査する活動。具体的な欠陥の検出と分析が中心。例：テスト実施、検査、欠陥分析、不具合データ収集

QC7つ道具

品質管理でよく使われる7種類の図表ツール。数値データの分析に適している。例：パレート図、特性要因図、ヒストグラム、散布図、管理図、チェックシート、層別

パレート図

項目を多い順に棒で並べ、累積比率を折れ線で示した図。「20-80の法則」に基づき重点項目を可視化する。例：原因の上位20%が問題全体の80%を占めることが多い

特性要因図（フィッシュボーン図）

原因と結果の関係を魚の骨状に整理する図。問題の根本原因を体系的に分析する。例：「品質低下」を中心に、人・物・方法・環境の4要因で原因を整理

ヒストグラム

データを階級に分けて棒グラフで分布を表す図。データのばらつきや偏りを可視化する。例：テスト点数の分布を10点刻みのビンで表示

散布図

2変数の関係を点で表す図。変数間の相関の有無や強さを視覚的に判断できる。例：勉強時間と試験成績の関係を点でプロットし、正の相関を確認

管理図

工程が安定して管理状態にあるかを判定する図。上限・下限の管理限界線を超えた点を異常として検知する。例：UCL/LCLを超える点や連続上昇する傾向を異常として警報

チェックシート

項目別にデータを集計するための表形式ツール。データ収集を簡単・正確に行える。例：不具合の種類別・時間帯別の発生件数を集計する表

層別

データを意味のあるグループに分けて分析する手法。グループ間の違いを発見できる。例：時間帯別・担当者別・機械別に欠陥数を比較分析

新QC7つ道具

言語データ（文字情報）を扱うための品質手法。複雑な問題の構造化に有効。例：親和図、関連図、系統図、マトリックス図、PDPC法など

リスク管理

続いて、リスク管理を見ていきます。一方、リスクは「悪い影響」だけでなく「機会」も含む概念です。とくに、リスク登録簿による継続的な管理が重要です。

リスクマネジメント（PM）

プロジェクトのリスクを特定・分析・対応・監視する活動。不確実性に対処してプロジェクト成功率を高める。例：要員退職、技術的困難、要件変更など潜在リスクを管理

リスク特定

プロジェクトに影響しうるリスクを洗い出す活動。チームでブレインストーミングを行うことが多い。例：ブレストでリスクを列挙し、過去事例も参照

リスク分析

特定したリスクの発生確率と影響度を評価する活動。優先順位付けの基礎となる。例：「発生確率3×影響度5=15点」とスコア化し優先順位を決定

リスク登録簿

特定したリスクと対応策をまとめた一覧表。リスク管理の中心的なドキュメント。例：リスクID、内容、発生確率、影響、対応策、責任者を記録

コンティンジェンシープラン

リスクが顕在化した場合に備える代替計画。事前に準備しておくことで迅速に対応できる。例：キーマン離脱時のバックアップ要員確保、代替ベンダの選定

コンティンジェンシー予備費

想定リスクへの対応用に確保しておく予算。予期せぬ事態に備える保険的な予算。例：プロジェクト総予算の10%をリスク対応用に確保

その他の管理領域

さらに、PMBOKでは調達・ステークホルダ・コミュニケーション・人的資源・統合の各管理領域も定義されています。また、変更管理や構成管理もプロジェクト全体を支える重要な活動です。

調達マネジメント

外部から必要なものを調達する活動。ベンダ選定、契約締結、契約管理を含む。例：開発委託先の選定、機器購入、クラウドサービス契約

ステークホルダマネジメント

ステークホルダとの関係を構築・維持する活動。利害関係者の期待を管理し、プロジェクト推進を円滑にする。例：影響度マトリクスでステークホルダを分類し、対応方針を決定

コミュニケーションマネジメント

プロジェクト内外の情報伝達を計画・実行・管理する活動。情報伝達の漏れや誤解を防ぐ。例：報告書フォーマット、定例会議体、情報共有ツールの設計

人的資源マネジメント

プロジェクトチームの編成・育成・評価を行う活動。適切な人材配置がプロジェクト成功の鍵。例：要員計画、スキル開発、モチベーション管理、評価制度

統合マネジメント

プロジェクト全体を統合的に調整する活動。各管理領域の活動を統合し、整合性を保つ。例：変更管理、プロジェクト統合計画書の作成、フェーズ間の調整

変更管理

計画への変更要請を評価・承認・反映する手続き。無秩序な変更を防ぎ、影響を管理する。例：要件変更時の影響評価、CCB（変更管理委員会）での承認プロセス

構成管理

成果物のバージョンや関係を管理する活動。変更履歴を追跡し、再現可能性を保つ。例：ソースコード、設計書、文書のバージョン管理

サービスマネジメント ― 基本情報技術者 用語集

サービスマネジメントは、ITサービスを安定的に提供するための仕組みです。とくに、ITILというベストプラクティス集や、SLAというサービス水準の合意が中心テーマです。また、インシデント管理と問題管理の違いも基本情報技術者試験で頻出です。

サービスマネジメントの基本

まず、サービスマネジメントの基本用語を押さえましょう。たとえば、ITILは世界的な標準として広く参照されています。さらに、SLAはサービス提供者と利用者の合意文書として重要です。

ITサービスマネジメント（ITSM）

ITサービスを高品質に提供・運営する仕組み。利用者の視点でITを管理する考え方。例：障害対応、変更管理、リリース管理を統合的に運用

ITIL

IT Infrastructure Library。ITサービスマネジメントのベストプラクティス集。英国発祥で、世界標準として広く参照されている。例：ITIL v4が最新版で、サービスバリューシステムの概念を導入

ISO/IEC 20000

ITサービスマネジメントの国際規格。ITIL準拠の管理体制を認証する基準。例：認証取得することで対外的に運用品質を示せる

SLA

Service Level Agreement。サービス提供者と利用者の間で合意するサービス水準の文書。具体的な数値目標を含む。例：「稼働率99.9%」「応答時間1秒以内」「障害時1時間以内に復旧」

SLM

Service Level Management。SLAを達成するため、サービスレベルを継続的に管理する活動。例：実績測定→SLA達成評価→改善活動のサイクルを実行

SLO

Service Level Objective。サービスレベルの内部目標値。SLAより高い水準で設定することが多い。例：SLA「99.9%」に対し、内部SLOは「99.95%」と高めに設定

OLA

Operational Level Agreement。社内の部署間で結ぶサービス合意。外部向けSLAを支える内部合意。例：開発部門と運用部門の間で結ぶ作業の取り決め

サービス運用プロセス

次に、ITILの主要プロセスを確認します。たとえば、インシデント管理は「早く復旧」を目的とし、問題管理は「根本原因の除去」を目的とします。一方、変更管理とリリース管理は新規導入を制御するためのプロセスです。

インシデント管理

サービスを通常状態に早く戻すことを目的とした管理プロセス。原因究明より復旧を優先する。例：障害発生時の暫定対応で早期復旧、原因究明は問題管理に引継ぎ

問題管理

インシデントの根本原因を追究し、再発を防止する管理プロセス。長期的視点で対応する。例：頻発する障害の根本原因を特定し、恒久対策を実施

変更管理（ITSM）

システム変更を計画・評価・実施する管理プロセス。変更によるリスクを最小化する。例：変更諮問委員会（CAB）で承認後に実施、緊急変更も別ルートで対応

リリース管理

新規または変更されたサービスを本番環境に展開する管理プロセス。例：リリース計画、テスト、展開、ロールバック準備を一連で管理

構成管理（ITSM）

IT資産の構成情報を維持管理する活動。すべての構成要素とその関係を把握する。例：CMDBで全機器・ソフト・関係を一元管理

CMDB

Configuration Management Database。構成管理データベース。ITサービス提供に必要な構成要素を一元管理する。例：サーバ・ネット機器・アプリの構成情報と相互関係を集約

サービスデスク

利用者からの問合せ窓口。インシデント受付の最前線として機能する。例：ヘルプデスク、コールセンター、チャットサポート

キャパシティ管理

サービスに必要な処理能力を確保する管理。将来の需要を予測してリソースを計画する。例：将来の負荷を予測してサーバ増強を計画的に実施

可用性管理

サービスを使える状態に維持する管理。冗長化や災害対策で可用性を高める。例：冗長化構成、定期バックアップ、災害対策（DR）の整備

継続性管理

災害や重大障害が発生してもサービスを継続できるよう備える管理。例：DRサイトの構築、BCPの策定と定期訓練

情報セキュリティ管理

サービスの機密性・完全性・可用性を維持する管理。情報資産を脅威から守る。例：アクセス制御、暗号化、ログ監視、インシデント対応

サプライヤ管理

外部サプライヤとの関係を管理する活動。契約遵守状況やSLA達成度を監視する。例：契約管理、SLA遵守状況の定期確認、関係改善

運用の役割・体制

さらに、サービスデスクから専門技術者まで階層的な対応体制が組まれます。たとえば、1次・2次・3次対応というエスカレーション体制が一般的です。また、ナレッジ蓄積も継続的な改善に欠かせません。

1次対応

サービスデスクで行う初期対応。問合せ受付、初期診断、簡易な問題解決を担当する。例：問合せ受付、初期切り分け、FAQやマニュアルでの解決

2次対応

専門技術者が行う詳細対応。1次で解決できない技術的問題を担当する。例：データベース管理者やネットワーク技術者が詳細調査・対応

3次対応

製品開発者やベンダの専門家が行う深層対応。最も複雑な問題を担当する。例：ソフトウェアのソースコードレベルでのバグ調査

エスカレーション

解決できない問題を上位や別部門に引き継ぐこと。早期解決のための重要な仕組み。例：サービスデスク（1次）から専門技術者（2次）へ引継ぎ

FAQ

よくある質問と回答集。利用者の自己解決を促し、問合せ削減に貢献する。例：問合せ削減のためにWebサイトや社内ポータルに公開

ナレッジベース

過去の問合せ・解決ノウハウを蓄積した情報源。トラブル対応の効率化に役立つ。例：過去の障害事例と対応手順を検索可能な形で蓄積

ファシリティマネジメント ― 基本情報技術者 用語集

ファシリティマネジメントは、建物や設備を効率的に運用管理する活動です。とくに、データセンタの設備管理は基本情報技術者試験で問われることがあります。また、UPSや空調設備などの基本要素も押さえておきましょう。

施設・設備管理

まず、データセンタの設備について確認しましょう。たとえば、UPSは停電時の電源確保に不可欠です。さらに、空調設備や消火設備もサーバ運用の生命線です。一方、入退室管理は物理的セキュリティの基本です。

ファシリティマネジメント

建物・設備など物理資産を効率的に運用管理する活動。経営戦略と整合させて施設を活用する。例：オフィス、データセンタ、工場の維持運営と改善

データセンタ

サーバなどのITインフラを集中的に設置・運用する専門施設。高い耐災害性と運用品質を持つ。例：耐震構造、空調設備、自家発電装置、入退室管理を完備

サーバルーム

サーバ機器を設置する専用の部屋。温湿度管理、入退室管理、消火設備が必須。例：適切な温湿度管理とアクセス制限でサーバを保護

耐震・免震

地震対策の設備。耐震は揺れに耐え、免震は揺れを軽減する構造。例：免震床でサーバラックの転倒・損傷を防止

UPS

Uninterruptible Power Supply。無停電電源装置。停電時に瞬時にバッテリ電源に切り替える。例：停電を検知すると瞬時にバッテリへ自動切替

自家発電装置

停電時に独自で発電する装置。UPSと組み合わせて長時間停電に対応する。例：UPSがバッテリで短時間、自家発電が長時間の停電をカバー

空調設備

サーバルーム内の温湿度を一定に保つ設備。サーバの過熱故障を防止する。例：室温20〜25℃、湿度40〜60%を維持して機器寿命を延ばす

消火設備

火災時に火を消すための設備。サーバ室では水を使えないため特殊な消火方式を採用する。例：ガス消火設備で水によるサーバ損傷を回避

入退室管理（FM）

建物・部屋への出入りを管理する仕組み。物理的セキュリティの基本。例：ICカード認証、生体認証、警備員配置、入退室ログ記録

システム監査 ― 基本情報技術者 用語集

システム監査は、ITに関する適正な運用を独立した立場から検証する活動です。とくに、独立性の確保が監査の前提条件です。また、監査手法や手順も基本情報技術者試験で問われます。

監査の基本

まず、システム監査の基本原則を確認します。たとえば、監査人は被監査部門から独立している必要があります。さらに、システム監査基準とシステム管理基準は経済産業省が定める公式の指針です。

システム監査

ITに関する適正な運用を独立した立場から検証する活動。客観的な評価で改善提言を行う。例：情報システムの信頼性・安全性・効率性を第三者視点で評価

システム監査人

システム監査を実施する専門家。独立性と専門性が求められる。例：内部監査人、外部監査法人の監査人、公認システム監査人

システム監査基準

経済産業省が定めるシステム監査のあり方を示す公式基準。監査人の心得や監査の進め方を規定する。例：監査人の独立性、専門性、客観性などの規範を明示

システム管理基準

経済産業省が定める情報システムの管理に関する基準。監査の判断尺度として利用される。例：監査人が「適切な管理がなされているか」を判定する物差し

監査の独立性

監査対象から独立した立場で監査を行う原則。客観性と公正性を保つために不可欠。例：自分が開発したシステムは自分で監査しないというルール

監査の手順

次に、システム監査の手順を見ていきます。具体的には、計画→予備調査→本調査→報告→フォローアップの流れで進めます。また、各段階で適切な記録（監査調書）を残すことが重要です。

監査計画

監査の対象・目的・方法を定めた計画。年次計画と個別監査計画がある。例：年次監査計画で年間の監査対象を決定、個別計画で詳細を策定

予備調査

本調査の前に対象システムや業務を把握する活動。本調査の効率化に貢献する。例：システム概要、業務フロー、関連文書を事前に確認

本調査

監査証拠を収集して評価する活動。監査の中心となる活動。例:ドキュメント確認、ヒアリング、サンプル抽出による検証

監査証拠

監査の結論を裏付ける客観的な事実や記録。証拠の十分性と適切性が重要。例：操作ログ、設定ファイル、ヒアリング記録、文書類

監査調書

監査の実施記録。証拠と判断過程を整理した重要な文書。例：監査手続、発見事項、結論、関連証拠を体系的に記録

監査報告書

監査結果をまとめ依頼者に提出する公式文書。改善提案も含む。例：指摘事項、原因分析、改善提案、結論を記載

フォローアップ

指摘事項が改善されたか後日確認する活動。監査の実効性を高める。例：3か月後に改善対応状況を再確認、未対応事項を経営層へ報告

監査の手法

さらに、監査にはさまざまな手法があります。たとえば、ドキュメントレビューやヒアリングは基本的な手法です。一方、テストデータ法やITF法はシステムに直接働きかける高度な手法です。

ドキュメントレビュー

関連文書を確認する監査手法。書類上の整合性を検証する。例：設計書、運用手順書、ログを確認して規定遵守を検証

ヒアリング

関係者から聞き取り調査する手法。実態を把握するのに有効。例：運用担当者へ業務実態を質問し、文書との乖離を確認

視察（現場観察）

現場の実態を直接確認する手法。実際の運用状況を肌で感じ取る。例：データセンタの入退室管理を実地で確認

サンプリング

母集団から一部を抽出して検証する手法。全件確認が困難な場合に使う。例：1万件の取引から100件を抽出して詳細確認

テストデータ法

監査人が用意したテストデータでシステムの動作を確認する手法。例：異常データを入力してチェック処理が正しく機能するか確認

並行シミュレーション法

監査人が独自に作成したプログラムで同じ処理を行い、結果を照合する手法。例：本番処理と監査用プログラムの結果を比較してロジックを検証

監査モジュール法

本番システムに監査用モジュールを組み込み、常時監視する手法。例：本番取引から異常パターンを自動検知して通知

ITF法

Integrated Test Facility。本番環境に監査用の仮想口座を設けてテストする手法。例：通常業務に紛れて監査用の取引を実施し、処理結果を検証

内部統制 ― 基本情報技術者 用語集

内部統制は、組織の業務適正を確保するための仕組みです。とくに、COSOフレームワークやJ-SOX法は基本情報技術者試験で問われます。また、IT全般統制とIT業務処理統制の違いも整理しておきましょう。

内部統制の基本

まず、内部統制の概念と構成要素を押さえましょう。たとえば、内部統制には4つの目的と6つの基本要素があります。さらに、COSOは世界的に参照される代表的なフレームワークです。

内部統制

業務の適正を確保するための社内の仕組み。経営者から従業員まで全員が役割を担う。例：経営者の指示、業務手順、相互チェックなどの体系的な仕組み

COSO

米国で策定された内部統制のフレームワーク。世界的に参照される標準。例：金融商品取引法の内部統制報告制度（J-SOX）の基礎

内部統制の4つの目的

業務の有効性・効率性、財務報告の信頼性、法令遵守、資産の保全の4つ。例：これら4つを達成するために統制を構築・運用する

内部統制の6つの基本的要素

統制環境・リスクの評価と対応・統制活動・情報と伝達・モニタリング・IT対応の6要素。例：日本版SOX法（J-SOX）での内部統制の構成要素

統制環境

組織の意識・文化など内部統制の基盤となる要素。トップの倫理観が大きく影響する。例：経営者の倫理観、組織風土、人事制度、組織構造

統制活動

経営方針を実現するための具体的な手続。日常業務の中で実施される。例：承認手続、照合作業、職務分掌、物理的アクセス制限

モニタリング

内部統制の有効性を継続的に評価する活動。問題点の早期発見と是正に貢献する。例：内部監査、自己点検、経営層への定期報告

業務統制・IT統制

続いて、業務統制とIT統制の具体例を見ていきます。たとえば、職務分掌と相互牽制は不正防止の基本です。また、IT統制は「全般統制」と「業務処理統制」の2層で構成されます。

職務分掌

業務を複数人に分けて1人で完結しないようにする仕組み。不正と誤りを防ぐ基本原則。例：申請者と承認者を別人にして相互チェック機能を確保

相互牽制

互いをチェックすることで不正・誤りを防ぐ仕組み。職務分掌と密接に関連する。例：会計担当と支払担当を別にして相互チェック

IT全般統制

IT基盤全体を支える統制。複数のシステムに共通する基盤的な統制。例：アクセス管理、変更管理、運用管理、システム開発管理

IT業務処理統制

個別業務処理の正確性を保つ統制。アプリケーション内に組み込まれる。例：入力チェック、エラー処理、整合性チェック、出力検証

J-SOX（金融商品取引法の内部統制報告制度）

上場企業に対し内部統制報告書の提出を求める日本の制度。財務報告の信頼性確保が主目的。例：上場企業は財務報告に関する内部統制を評価・報告する義務

SOX法

米国のサーベンス・オクスリー法。企業会計の不正対策を目的とした法律。例：エンロン事件を契機に2002年制定、米国上場企業に適用

監査証跡

処理の経過を追跡できる記録。事後の検証や責任追及に使われる。例：誰がいつ何を変更したかのログ、操作履歴