【応用情報技術者】第10章マネジメントについて

白川秋

3時間前

10個めの応用情報技術者の科目A暗記用のブログです。
残すところあと1章。ここまでやってきました。皆さん暗記の方は捗っていますか？
応用情報技術者試験が今年？今年試験あるの？
よくわかってないですが、テンション落とさず、頑張っていきましょう。

来年から、応用情報技術者試験と高度試験を「プロフェッショナルデジタルスキル試験」として3領域・3試験に再編するとのニュースがありました。

まぁ、勉強を始めた人は、そのまま応用を受けましょう。この勉強は無駄にはならないはずです。（今年試験あるの？）

それでは、いってみよー！

第10章マネジメント
みんなで使おう！Ankiアプリで暗記しよう
参考図書
合わせて読みたい
最後に

第10章マネジメント

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

単語	意味
プロジェクトマネジメント	プロジェクトマネジメントとは、「限られた時間・予算・人員の中で、決められた成果を確実に達成するための管理手法」です。たとえば、スマホアプリを開発するとき、誰が何をいつまでにやるかを計画し、進捗を確認しながらチームを導きます。単なる作業ではなく、目標達成のための「戦略的指揮」が本質です。これにより、無駄を減らし、失敗を防ぎます。
定常業務	定常業務は、毎日・毎週・毎月と繰り返されるルーティンワークのことを指します。例えば、メール対応、システムの監視、給与計算などが該当します。一方、プロジェクトは「一度きりの特別な仕事」なので、期間や目的が明確です。定常業務は維持・運営が目的ですが、プロジェクトは「新しい価値を生み出す」点で大きく異なります。
プロジェクト	プロジェクトとは、「特定の目的を達成するために、期間・コスト・リソースが限定された一時的な取り組み」です。例として、「新サービスを3か月で開発してリリースする」などがあります。始まりと終わりがあり、日常業務とは異なります。成功すれば組織に新たな価値をもたらし、終わればチームは解散または次のプロジェクトへ移ります。
JIS Q 21500：2018	JIS Q 21500：2018は、日本が定めた「プロジェクトマネジメントの国際標準ガイドライン」です。ISO 21500を国内向けに翻訳・調整したもので、業種を問わず使える共通のフレームワークを提供します。2026年現在も有効で、企業や官公庁がプロジェクトを成功させるための基本指針として活用されています。
JIS Q 21500：2018のプロセス	この規格ではプロジェクトを①立ち上げ（目的・範囲の確認）、②計画（スケジュール・予算策定）、③実行（作業の実施）、④管理（進捗・リスク監視）、⑤終結（成果確認・クローズ）の5段階で進めます。これらは直線的ではなく、必要に応じて繰り返されます。全体を循環的に見直すことで、柔軟かつ確実な進行が可能になります。
ステークホルダ	ステークホルダとは、「プロジェクトに影響を与える人、または影響を受ける人」の総称です。顧客、ユーザー、開発者、経営陣、外部ベンダーなどが該当します。彼らの期待や懸念を把握し、適切にコミュニケーションを取ることが成功の鍵です。無視すると、途中で要望が変わり、プロジェクトが破綻するリスクがあります。
プロジェクトガバナンス	プロジェクトガバナンスは、「プロジェクトが正しく、倫理的かつ効率的に進められているかを監督する仕組み」です。意思決定のルール、責任の所在、報告体制を明確にし、不正や無駄を防ぎます。企業の「内部統制」に似ており、特に大規模案件では必須の枠組みです。
プロジェクト組織	プロジェクト組織は、プロジェクトのために一時的に編成されるチーム構造です。主な形態には「機能型（部署ごと）」「プロジェクト型（専任チーム）」「マトリックス型（両方の特徴を併せ持つ）」があります。IT開発では柔軟性が必要なため、マトリックス型がよく使われ、複数の部門から人材を集めて動きます。
プロジェクトマネジメントオフィス	PMO（プロジェクトマネジメントオフィス）は、複数のプロジェクトを横断的に支援・監督する専門部署です。テンプレート提供、進捗集約、教育、ベストプラクティス共有などを通じて、全社のプロジェクト成功率を高めます。大企業や官公庁では、PMOの有無がプロジェクト成否を分ける重要な要素です。
統合マネジメント	統合マネジメントは、「スコープ・コスト・スケジュール・品質など、プロジェクトのすべての要素を調和させ、全体最適で進める管理」です。一つだけを優先すると他の部分が崩れるため、バランスを見ながら調整します。プロジェクトマネージャーの最も重要な役割であり、成功の要と言えます。
スコープマネジメント	スコープマネジメントは、「プロジェクトで何をやるか（＝成果物の範囲）を明確に定義し、コントロールする」ことです。曖昧だと「あとで追加要望」が出て予算や納期が破綻します。そのため、最初に「含まれるもの・含まれないもの」を文書化し、関係者全員で合意します。
スコープの定義	スコープの定義は、顧客の要望を具体的なタスクや成果物に落とし込む作業です。たとえば「ログイン機能を作る」ではなく、「ID/PW入力→認証→ホーム画面遷移」と細分化します。これにより、開発チームと顧客の認識ズレを防ぎ、後々のトラブルを回避できます。
スコープの管理	スコープの管理は、「一度決めた範囲から逸脱しないよう監視し、変更があれば正式な手続き（チェンジコントロール）で対応する」ことです。無秩序な追加要望（＝スコープクリープ）はプロジェクト破綻の主因です。変更は「影響評価→承認→反映」の流れで厳密に扱います。
WBS	WBS（Work Breakdown Structure）は、「プロジェクトの成果物を階層的に細かく分解した図」です。トップに最終成果物、その下に主要成果物、さらに作業単位（ワークパッケージ）までツリー状に展開します。これにより、全体像が見え、誰が何をやるかが明確になります。
WBS辞書	WBS辞書は、「WBSの各要素について詳細を記述した補足文書」です。担当者、完了基準、所要工数、必要なスキル、関連リスクなどを記載します。WBSだけでは情報が不足するため、この辞書で曖昧さを排除し、作業の質を安定させます。
100％ルール	100％ルールとは、「WBSの最上位の成果物が、下位のすべての要素の合計で100％カバーされなければならない」という原則です。余分な作業があってもダメ、漏れがあってもダメ。完全に網羅されて初めて、正確な計画と管理が可能になります。
スケジュールマネジメント	スケジュールマネジメント（タイムマネジメント）は、「作業の順序・所要時間・依存関係を整理し、納期通りに進める管理」です。ガントチャートで可視化し、クリティカルパス（遅れると全体が遅れる経路）を特定。余裕を持たせた計画で、突発事態にも対応します。
コストマネジメント	コストマネジメントは、「予算を立て、実績を追跡し、超過を防ぐ管理」です。見積もり方法には「ボトムアップ見積（細かい作業から積み上げ）」や「アナログ見積（過去データ参照）」があります。式で表すと「総コスト＝Σ（作業単価 × 工数）」。定期的なレビューでズレを早期発見します。
マイナスリスクへの対応戦略	マイナスリスク（脅威）への対応は4つあります。①回避（リスク源をなくす）、②転嫁（保険や外部委託で他者に移す）、③軽減（発生確率や影響を小さくする）、④受容（対策せず起きたときに対処）。例：セキュリティリスクなら「回避＝使用禁止」「軽減＝暗号化＋監査ログ」など。
プラスのリスクへの対応戦略	プラスのリスク（機会）も存在します。対応は①活用（積極的に実現）、②共有（他社と協力）、③強化（確率や影響を高める）、④受容（見守る）。例：AI技術で開発が早まる可能性があれば「活用＝採用を決定」「強化＝追加学習データ投入」など、前向きに捉えます。

スケジュールマネジメントで用いる手法

単語	意味
PERT	PERT（Program Evaluation and Review Technique：計画評価レビュー技法）は、プロジェクトの所要日数を確率的に見積もる手法です。各作業に「楽観値（O）」「最頻値（M）」「悲観値（P）」の3つの期間を設定し、期待値Eを「E = (O + 4M + P) ÷ 6」という式で求めます。これにより、不確実性の高い開発タスクでも現実的な日程予測が可能になります。
アローダイアグラム	アローダイアグラム（矢線図法）は、作業を「矢印（→）」で、イベント（節点）を「○」で表すネットワーク図です。矢印の長さは時間ではなく、作業の依存関係を示します。この図を使うと、どの作業が他の作業の開始を待っているかが一目でわかり、全体の流れを視覚的に把握できます。ただし、現代ではPDM（プレジデンスダイアグラム法）の方が主流です。
クリティカルパス	クリティカルパス（最重要経路）とは、プロジェクト全体の完了日を決定する「最も時間がかかる作業の連なり」のことです。この経路上の作業が1日遅れると、プロジェクト全体も1日遅れます。逆に、余裕のある作業（非クリティカルパス）は多少遅れても影響しません。スケジュール管理では、このパスを常に監視することが重要です。
ファストトラッキング	ファストトラッキングは、通常なら直列で行う作業を「並行して」進めることで日程を短縮する手法です。たとえば、設計が完全に終わる前にコーディングを一部始めるなどです。ただし、リスクが高まり、後で修正が発生しやすくなるため、注意深く行う必要があります。これは「スケジュール圧縮」の代表的手法の一つです。
クラッシング	クラッシングは、クリティカルパス上の作業に「追加リソース（人・金・設備）」を投入して期間を短縮する方法です。たとえば、エンジニアを増員して開発スピードを上げるなどです。コストは増えますが、納期を守れる可能性が高まります。効果的なのは「単位コストあたりの短縮効果が大きい」作業に限定して行うことです。
プレジデンスダイアグラム法	プレジデンスダイアグラム法（PDM: Precedence Diagramming Method）は、現在もっとも広く使われるネットワーク図の描き方で、作業を「箱（ノード）」で表し、依存関係を矢印で結びます。4種類の依存関係があります。・FS（Finish-to-Start）：先行作業が終わってから次の作業が始まる（最も一般的）。・SS（Start-to-Start）：先行作業が始めば、次の作業も始められる。・FF（Finish-to-Finish）：先行作業が終わるまで、次の作業も終わらせられない。・SF（Start-to-Finish）：非常に稀で、先行作業が「始まると」次の作業が「終わる」関係（例：夜勤の引継ぎ）。　PDMは柔軟で、複雑な依存関係も表現できます。
クリティカルチェーン法	クリティカルチェーン法（Critical Chain Method）は、従来のクリティカルパス法に「人的・心理的要因」を加味したスケジューリング手法です。人間は「余裕があるとそれを全部使ってしまう（学生症候群）」という行動原理に基づき、各タスクの見積もりから余裕（バッファ）を削除し、代わりにプロジェクト全体の終端に「プロジェクトバッファ」を設けます。これにより、無駄な遅延を防ぎます。
クリティカルチェーン	クリティカルチェーンは、リソース（人・設備）の制約も考慮した「新たな最重要経路」です。従来のクリティカルパスは論理的依存だけでしたが、クリティカルチェーンは「同じエンジニアが複数の作業に必要」などの現実的制約を反映します。そのため、パスが変化しやすく、より実践的なスケジュール管理が可能です。
合流バッファ	合流バッファ（Feeding Buffer）は、非クリティカルパスの作業がクリティカルチェーンに合流する直前に設ける「安全在庫」のような時間です。これにより、非クリティカル側の遅れが最重要経路に波及するのを防ぎます。たとえば、ドキュメント作成が遅れても、開発本体（クリティカルチェーン）には影響しないようにする緩衝材です。
プロジェクトバッファ	プロジェクトバッファは、クリティカルチェーンの「最後」に設けられる全体の余裕時間です。各タスクから削った余裕時間を集めてここに置くことで、プロジェクト全体の納期を守るための「保険」となります。進捗管理では、このバッファの消費量を監視し、「バッファが半分以上使われたら要注意」といったルールでリスクをコントロールします。
ガントチャート	ガントチャートは、横軸に日付、縦軸にタスクを並べ、各作業の開始～終了を「横棒」で表す図です。直感的で見やすく、進捗状況（完了部分を塗りつぶすなど）も一目瞭然です。Microsoft ProjectやExcel、Jiraなど多くのツールで利用され、チーム内外への報告資料としても最適です。ただし、依存関係の複雑さは表現しづらい弱点もあります。
バーンダウンチャート	バーンダウンチャートは、アジャイル開発（特にスクラム）で使われるグラフで、縦軸に「残り作業量（ストーリーポイントや時間）」、横軸に「日数」をとり、理想線と実績線を比較します。理想線は初日から最終日にかけて直線的に下がり、実績線がそれより上なら遅れ、下なら進んでいることを示します。日々の進捗を可視化し、早期対応を促します。
タスクボード	タスクボードは、「To Do（未着手）」「In Progress（進行中）」「Done（完了）」といった列に付箋やカードを移動させながら進捗を管理するツールです。物理的なホワイトボードでも、TrelloやJiraのようなデジタルツールでも実現できます。視覚的でシンプルなため、小規模チームやアジャイル開発で非常に有効です。誰が何をしているかも共有しやすく、コミュニケーションが円滑になります。
トレンドチャート	トレンドチャートは、過去のデータ（例：バグ発生件数、テスト実行数、ビルド失敗回数など）を時系列でプロットし、その「傾向（トレンド）」を見るグラフです。単なる現状把握ではなく、「このままいくとどうなるか？」を予測するのに役立ちます。たとえば、バグ数が右肩上がりなら品質リスクが高まっているサインです。改善活動の効果測定にも活用されます。

コストマネジメントで用いる手法

単語	意味
標準タスク法	標準タスク法は、過去の類似プロジェクトで実際にかかった工数やコストをもとに、新しいプロジェクトの見積もりを行う方法です。たとえば、「ユーザー登録機能を作るのに前回は40時間かかった」という実績があれば、今回も同じような機能なら40時間と見積もるわけです。この手法は、繰り返し開発する業務系システムなどでよく使われ、経験則に基づくため初心者でも扱いやすいのが特徴です。ただし、まったく新しい技術を使う場合は精度が下がります。
三点見積法	三点見積法は、「最楽観値（O）」「最可能値（M）」「最悲観値（P）」の3つの見積もりを使って、より現実的な予測値を出す方法です。計算式は「(O + 4M + P) ÷ 6」で、これを期待値と呼びます。たとえば、ある作業が「うまくいけば5日、普通なら8日、トラブルで17日かかるかも」と思ったら、(5＋4×8＋17)÷6＝9日と算出されます。これにより、単純な平均よりも現実に近い見積もりが可能になります。
COCOMO	COCOMO（ココモ）は、「Constructive Cost Model」の略で、ソフトウェア開発の規模（通常はソースコード行数）から工数や期間を推定するモデルです。1981年にボヘム博士が提唱し、その後「COCOMO II」として改良されました。基本式は「工数＝ a × (KLOC)^b」で、aとbはプロジェクトの複雑さ（例：組み込み型、半独立型、有機型）によって変わります。たとえば、有機型ならa＝2.4、b＝1.05など。2026年現在も、特に大規模システムの初期見積もりで使われています。
ファンクションポイント法	ファンクションポイント法（FP法）は、プログラムの「機能の数」から規模を測る手法で、コード量に依存しません。つまり、どんな言語を使っても同じ機能なら同じ点数になるため、公平な比較が可能です。この方法では、外部入力・出力・問い合わせ・内部ファイル・外部インターフェースの5種類の要素を数え、それぞれに重みをかけて合計します。その合計を「未調整ファンクションポイント（UFP）」と呼び、さらに複雑さ補正を加えて最終的なFP値を算出します。
ファンクションポイントの求め方	まず、5つのコンポーネント（EI, EO, EQ, ILF, EIF）を分類し、それぞれ「シンプル（3点）」「中程度（4点）」「複雑（6点）」に分けて点数を付けます。すべての点数を足したものがUFPです。次に、14の「一般システム特性（GSC）」（例：データ通信の有無、処理性能要件など）を0～5点で評価し、その合計をTとすると、調整係数CAF＝0.65＋0.01×Tを計算します。最終的なFPは「UFP × CAF」で求められます。このFP値に生産性（例：1FPあたり8時間）を掛けると工数が出ます。
類推見積法	類推見積法は、過去に行った「似たようなプロジェクト」の実績データを参考にして、新規プロジェクトのコストや期間を推定する方法です。たとえば、去年作ったECサイトが1000万円・6カ月だったなら、今年作る似たようなECサイトも同じくらいと見積もるわけです。この手法は、詳細設計前の初期段階で使われやすく、顧客への概算提示に便利です。ただし、類似度が低いと大きな誤差が出るため、注意が必要です。
LOC法	LOC（Lines of Code）法は、ソースコードの行数（Lines of Code）から開発規模や工数を推定する古典的な手法です。たとえば、「1人月で500行書ける」という生産性があれば、1万行のシステムは20人月かかると計算できます。しかし、言語によって1行の意味が違う（Pythonは簡潔、COBOLは冗長）ため、言語ごとの換算が必要です。また、再利用コードや自動生成コードをどう扱うかで結果が大きく変わるため、近年はFP法などと併用されることが多いです。
Dotyモデル	Dotyモデルは、1990年代に提案されたソフトウェア工数推定モデルで、COCOMOの一種とされることもあります。このモデルは、プロジェクトの「複雑さ」「チームの熟練度」「使用技術」などの要因を数値化し、工数を調整します。具体的には、ベース工数に複数の補正係数（例：0.8～1.2）を掛け合わせて最終工数を算出します。2026年現在ではあまり主流ではありませんが、COCOMO IIの補助的モデルとして一部の組織で参照されています。
COSMIC法	COSMIC（Common Software Measurement International Consortium）法は、国際標準（ISO/IEC 19761）として認められた機能規模測定手法です。FP法と似ていますが、データの「移動」（Entry, Exit, Read, Write）の数を基に規模を測るのが特徴です。たとえば、ユーザーがデータを入力（Entry）し、システムがDBから読み取り（Read）、処理結果を画面に出力（Exit）する——この一連の流れで3ポイントと数えます。リアルタイムシステムや組み込み系にも適用でき、2026年ではグローバル企業を中心に採用が増えています。
EVM	EVM（Earned Value Management：アーンドバリューマネジメント）は、プロジェクトの進捗を「スケジュール」と「コスト」の両面から定量的に評価する手法です。単に「作業が50％終わった」ではなく、「予定していた価値のうち、どれだけを実際に獲得したか」を金額で測ります。これにより、プロジェクトが「予定より遅れているのか」「予算オーバーなのか」を早期に把握できます。2026年現在、政府系や大手IT企業のプロジェクト管理で広く使われています。
PV	PV（Planned Value：プランドバリュー）は、「その時点までに計画されていた作業の予算金額」を指します。たとえば、100万円のプロジェクトで全体を10週間とし、3週目終了時点で30％の作業を終える予定なら、PV＝30万円です。これは「予定していた価値」であり、EVMの基準線として使われます。PVが高いほど、その時点での計画上の進捗が大きいことを意味します。
EV	EV（Earned Value：アーンドバリュー）は、「実際に完了した作業に割り当てられていた予算金額」です。たとえば、先ほどのプロジェクトで3週目に25％しか終わっていなければ、EV＝25万円です。これは「獲得した価値」と訳され、実際の進捗を金額で表現します。EVがPVより低ければ「遅れている」、高ければ「前倒し」だと判断できます。
AC	AC（Actual Cost：実コスト）は、「実際にかかった費用」を指します。たとえば、3週目終了時点で28万円を使っていたなら、AC＝28万円です。これは会計データから直接得られる値で、EVと比べることで「予算内で進んでいるか」がわかります。ACがEVより高ければ「コストオーバー」、低ければ「節約できている」と評価されます。
EVMの評価値の求め方	VMでは、以下の指標でプロジェクトを評価します。まず、コスト偏差CV＝EV－AC、スケジュール偏差SV＝EV－PV。プラスなら良好です。効率指標として、　CPI（コスト効率）＝EV÷AC 　SPI（スケジュール効率）＝EV÷PV 　1以上が理想です。将来予測では、残作業の見積もり（ETC）を「(BAC－EV)÷CPI」で算出し（BACは総予算）、　完成時総コストEAC＝AC＋ETC、　完成時予算差異VAC＝BAC－EAC で求めます。これらを使えば、プロジェクトの今後の見通しを数字で明確にできます。

サービスマネジメント

単語	意味
サービスマネジメント	サービスマネジメントとは、ITサービスを「計画→設計→提供→改善」する一連の活動で、単なるパソコン修理ではなく「ビジネスとITをつなぐ仕組み」です。たとえば、学校のオンライン授業システムが突然止まらないよう、事前に監視・保守・改善を行うのがこれにあたります。顧客が求める価値（例：安定・速さ・安全）を確実に届けるための管理手法であり、2026年現在、クラウドやAIサービスの普及でその重要性はさらに高まっています。
JIS Q 20000-1：2020	JIS Q 20000-1：2020は、日本の国家規格で、国際標準「ISO/IEC 20000-1」を日本語化・国内事情に合わせたものです。2020年に改訂され、サービスの設計から継続的改善までを体系的に定めています。2026年時点で、多くの企業や自治体がこの規格に基づきITサービスを提供しており、認証取得は信頼性の証となっています。特にDX（デジタルトランスフォーメーション）推進企業では、この規格への準拠が必須とされるケースも増えています。
サービスマネジメントシステム	サービスマネジメントシステム（SMS）は、組織全体でITサービスを効果的に提供・管理するための統合的な仕組みです。方針、プロセス、役割、資源などを体系化し、「PDCAサイクル（Plan-Do-Check-Act）」で継続改善します。たとえば、障害対応手順やコスト管理ルールもSMSに含まれます。SMSがあることで、サービス品質が安定し、経営戦略との整合性も保たれます。ISO規格でもSMSの整備が求められており、2026年ではクラウド環境でのSMS運用が主流です。
サービスポートフォリオ	サービスポートフォリオは、企業が提供するすべてのITサービスを一覧化したリストで、「サービスカタログ（今使えるもの）」「サービスパイプライン（開発中）」「廃止予定サービス」の3つで構成されます。これにより、経営陣は「どのサービスに投資すべきか」を判断でき、ユーザーも将来のサービス動向を把握できます。たとえば、新しいAIチャットボットが「パイプライン」にあり、古いメールシステムが「廃止予定」なら、計画的に移行できます。無駄な重複開発を防ぐ効果もあります。
サービスの計画	サービスの計画は、ビジネス目標に基づき、必要なITサービスを設計・準備する最初の段階です。顧客ニーズや市場動向を分析し、「何を」「いつまでに」「いくらで」提供するかを明確にします。たとえば、「来年度中に全社員向けにセキュアなリモートワーク環境を月額500円で提供」といった具合です。この計画がなければ、無駄な投資やサービスのミスマッチが起こり、コスト増や顧客離れにつながります。経営陣の承認を得る重要なステップでもあります。
サービスカタログ管理	サービスカタログは、現在利用可能なITサービスの詳細をまとめた「メニュー帳」です。ユーザーが「どんなサービスがあるか」「どう使うか」「いくらかかるか」を理解できるように、機能・価格・利用条件・サポート範囲などを記載します。たとえば、「クラウドストレージ：100GBまで無料、追加は1GBあたり10円」など。カタログ管理は、この情報を常に最新に保ち、透明性を高める活動です。内部向け（社員用）と外部向け（顧客用）で内容を分ける場合もあり、2026年ではポータルサイトでの公開が一般的です。
資産管理	資産管理は、ITに関連するハードウェア・ソフトウェア・ライセンスなどの「資産」を購入から廃棄までライフサイクルで管理することです。たとえば、ノートPCの導入台数、Officeのライセンス数、クラウドサブスクリプションの契約内容などを正確に把握します。これにより、不要なライセンスの削減、セキュリティリスクの低減、監査対応が可能になります。2026年現在、クラウド時代には「サブスクリプション型資産」の管理が特に重要で、コスト最適化に直結します。
構成管理	構成管理は、ITサービスを構成する要素（サーバー、ネットワーク、アプリなど）を「構成アイテム（CI）」として管理し、それらの関係性を可視化する仕組みです。たとえば、「このWebアプリはAサーバーとBデータベースに依存している」といった関係を記録します。障害発生時に「影響範囲を素早く特定」でき、変更時のリスクも低減できます。中心ツールは「構成管理データベース（CMDB）」で、2026年ではAIによる自動関連付け機能も登場しています。
サービスレベル管理	サービスレベル管理（SLM）は、顧客と合意したサービス品質（例：可用性99.9％、応答時間5秒以内）を維持・監視するプロセスです。定期的にパフォーマンスを測定し、問題があれば改善策を講じます。たとえば、「先月は99.5％しか稼働しなかったので、冗長化を強化する」など。SLMは信頼関係を築く鍵であり、成果は「サービスレベル報告書（SLR）」で可視化されます。2026年ではリアルタイムダッシュボードによる監視が主流です。
サービスレベル合意書	サービスレベル合意書（SLA）は、サービス提供者と顧客の間で結ぶ「サービス品質に関する契約書」です。応答時間（例：2時間以内）、復旧時間（例：4時間以内）、ペナルティ条項（例：遅延1時間ごとに料金10％返金）などを明記し、双方の責任を明確にします。SLAがないと、トラブル時の対応が曖昧になり、信頼関係が損なわれます。SLAはサービスマネジメントの根幹をなす文書で、2026年ではクラウドサービスでも標準的に提供されています。
サービスの予算業務及び会計業務	ITサービスの予算・会計業務は、サービスのコストを見積もり、資金を確保・管理する活動です。需要（ユーザーが求めるサービス量）と供給（実際に提供されるサービス量）のバランスを取りながら、無駄のない投資を行います。たとえば、「来期のクラウド利用料は需要予測に基づき120万円を計上」といった具合です。これにより、経営判断がデータに基づいたものになり、サービスの価値最大化が図れます。2026年では、使用量ベース課金（Pay-as-you-go）との連携が重要です。
需要管理	需要管理は、ユーザーのITサービスに対する「需要」を予測・調整する仕組みです。たとえば、新学期や決算期にアクセスが集中するため、事前にリソースを増強します。ピーク時や季節変動に対応し、過剰な供給（無駄）や不足（サービス低下）を防ぎます。需要と供給のバランスが、コスト効率とサービス品質を左右するため、非常に重要です。2026年では、AIや機械学習を活用した需要予測が一般的になり、精度が飛躍的に向上しています。
容量・能力管理	容量・能力管理は、将来の需要を見据え、ITリソース（CPU、メモリ、ストレージなど）の「供給能力」を最適に保つ活動です。需要が増える前にリソースを拡張し、パフォーマンス低下を防ぎます。たとえば、「来月の新サービス開始に備え、サーバー台数を20％増やす」など。需要と供給の見通しがこの管理の鍵であり、コスト抑制とユーザー満足の両立を実現します。2026年では、クラウドの自動スケーリング機能と連携した動的管理が標準です。
変更管理	変更管理は、システム設定やソフトウェア更新など「変更」を安全に実施するためのプロセスです。変更がサービスの設計・構築・移行フェーズに悪影響を与えないよう、事前評価・承認・テストを行います。たとえば、OSのアップデート前に「他のアプリと衝突しないか」を検証します。失敗すれば大規模障害につながるため、慎重かつ迅速な対応が求められます。緊急変更と通常変更でフローを分け、2026年では自動テストとの連携が進んでいます。
サービスの設計及び移行	サービスの設計・構築・移行は、新サービスや更新サービスを現場に導入する一連の流れです。要件定義からテスト、本番環境への移行までを含み、ビジネスニーズに合致した高品質なサービス提供を目指します。たとえば、新しい勤怠システムを「テスト環境で3週間試験→全社展開」のように進めます。この段階でミスがあると、後の運用に大きな負担がかかり、コスト増にもつながるため、丁寧な実施が不可欠です。移行後のレビューも重要なステップです。
リリース及び展開管理	リリース及び展開管理は、新しいソフトウェアや機能を本番環境に「安全に公開」するためのプロセスです。設計・構築・移行フェーズの最終ステップとして、バージョン管理やロールバック手順（元に戻す方法）を整備し、ユーザーへの影響を最小限に抑えます。たとえば、新機能を一部ユーザーに先行公開（カナリアリリース）し、問題がなければ全ユーザーに展開します。2026年ではDevOpsやCI/CDパイプラインとの連携が標準で、高速かつ安全なリリースが実現されています。
システムの移行方式	古いシステムから新しいシステムへ切り替える方法を「移行方式」といいます。一気に全部変える「一斉移行」、少しずつ変える「順次移行」、新旧を同時に動かす「並行運用」、一部の部署で試す「パイロット移行」などがあります。どの方式を選ぶかで、リスクやコスト、ユーザーへの影響が大きく変わります。たとえば、病院や銀行のようにミスが許されない現場では安全重視の方式が選ばれます。
一斉移行方式	一斉移行は、ある日を境に古いシステムを完全に止め、新しいシステムに一気に切り替える方法です。準備が整えば短期間で完了し、二重運用の手間やコストがかかりません。しかし、新システムに不具合があると業務が止まるリスクがあります。そのため、事前の徹底テストとバックアップ計画が必須です。例えるなら、自転車の補助輪を一度に外して乗るようなものです。
順次移行方式	順次移行は、システムの機能や対象部門を少しずつ新しいものに置き換えていく方法です。全体のリスクを分散できるため、万が一トラブルが起きても影響範囲が限定されます。ただし、新旧システムが混在する期間が長くなり、管理が複雑になるデメリットもあります。たとえば、全国展開のチェーン店で、まず関東だけ新POSシステムを導入し、その後全国へ広げるといった使い方がされます。
並行運用移行方式	並行運用では、新旧のシステムを同時に動かし、結果を照合しながら徐々に新システムに移行します。安全性が高く、間違いがあればすぐ旧システムに戻せます。ただし、人手やサーバー資源が2倍必要で、運用コストが高くなります。特に金融機関や医療システムなど、データの正確性が命の分野で使われます。信頼性を最優先する代わりに、コストと手間を引き受ける方式です。
パイロット移行方式	パイロット移行は、特定の部署や地域など限られた範囲で新システムを試し、問題がなければ全体に展開する方法です。実際の現場で検証できるため、本格導入後の失敗を防げます。成功すれば他の部門への説得材料にもなります。ただし、パイロット環境と本番環境の差異によって、思わぬ問題が後で出ることもあるため、環境の再現性が重要です。
インシデント管理	インシデント管理とは、システム障害やユーザーからの不具合報告（＝インシデント）を迅速に受け付け、記録・分類・対応し、通常のサービスレベルまで復旧させる仕組みです。目的は「解決」ではなく「サービスの早期復旧」です。たとえばメールが届かないという報告に対し、根本原因を後回しにして、まず一時的な回避策で送受信を可能にします。これにより業務の中断を最小限に抑えます。
サービス要求管理	サービス要求管理は、ユーザーからの「パスワード再発行」「新アカウント作成」などの標準的な要望を、定型プロセスで処理する仕組みです。これらは障害ではなく「実現」すべき正当な要求です。自動化やワークフローにより、迅速かつ正確に提供することで、ユーザー満足度を高めます。たとえば、社内ポータルから申請すれば、承認後すぐにアクセス権が付与されるといった流れが該当します。
問題管理	問題管理は、繰り返し発生するインシデントの根本原因を突き止め、恒久的に「解決」する活動です。インシデント管理が「火を消す」なら、問題管理は「火が出ないよう配線を直す」ことに相当します。これにより、将来的な障害を未然に防ぎ、サービス品質を向上させます。たとえば、毎週同じ時間にサーバーが落ちる場合、その原因を調査し、ソフトウェアのバグ修正などで「実現」的に改善します。
サービス保証	サービス保証（Service Warranty）とは、ITサービスが「いつでも利用でき、安全で、継続的であること」を保証する概念です。具体的には、可用性（どれだけ使えるか）、信頼性（どれだけ壊れないか）、セキュリティ（情報が守られるか）、継続性（災害時も動くか）の4つで構成されます。これは「サービスがどんな価値を提供するか（ユーティリティ）」とセットで、顧客への約束となります。
サービス可用性管理	サービス可用性管理は、システムが「必要なときに使える状態」を維持・向上させる仕組みです。可用性は「(稼働時間 ÷ (稼働時間＋停止時間)) × 100%」で求められます。たとえば年間99.9%の可用性なら、年間の停止時間は約8.8時間以内です。ハード故障対策、冗長構成、監視体制などを整え、ビジネス要件を満たす可用性を実現します。
サービス継続管理	サービス継続管理は、災害やサイバー攻撃など非常時でもITサービスを一定レベルで継続・復旧させるための計画と活動です。バックアップ、代替拠点、通信回線の多重化などを用意し、RTO（復旧目標時間）やRPO（許容データ損失量）を定めます。これにより、企業が社会的責任を果たし、顧客信頼を維持できる体制を「実現」します。
事業継続計画	事業継続計画（BCP：Business Continuity Plan）は、地震やパンデミックなど大規模な災害が発生しても、重要な業務を止めずに続けるための計画です。ITだけでなく、人・物・場所全体を対象とし、優先業務の特定、代替手段の確保、訓練の実施などが含まれます。BCPは単なる危機対応ではなく、企業の存続と社会的信頼を「実現」するための戦略です。
ビジネスインパクト分析	ビジネスインパクト分析（BIA：Business Impact Analysis）は、BCPの第一歩として、各業務が停止した場合の影響（金銭的・社会的・法的）を評価し、復旧の優先順位を決める手法です。たとえば、オンライン決済システムが止まれば1時間で数億円の損失になるため、最優先で復旧すべきと判断されます。この分析により、限られた資源を効果的に配分できます。
ITIL	ITIL（Information Technology Infrastructure Library）は、ITサービスを効果的・効率的に提供するためのベストプラクティス集です。2026年現在、最新版は「ITIL 4」で、従来のプロセス中心から「バリューストリーム」や「アジャイル」「DevOps」と融合した価値創出型のフレームワークになっています。世界中の企業がITサービスマネジメントの基準として採用しています。
サービスデスク	サービスデスクは、ユーザーからの問い合わせや障害報告を受け付けるITサポートの窓口です。単なるヘルプデスクではなく、インシデント管理やサービス要求の一次対応、エスカレーションを行う「サービス提供の顔」として機能します。電話、メール、チャット、チケットシステムなど多様な手段で対応し、ユーザー体験の向上に貢献します。
中央サービスデスク	中央サービスデスクは、企業全体のITサポートを1か所で集中して行う方式です。標準化された対応が可能で、スキルの高いスタッフを効率的に配置できます。コスト削減や対応品質の均一化が図れますが、時差や言語の壁があるグローバル企業では課題も生じます。本社機能が強い組織に向いています。
ローカルサービスデスク	ローカルサービスデスクは、各地域や支社ごとに設置されたサポート窓口です。現地の言語や文化、業務習慣に即した対応が可能で、ユーザーとの信頼関係が築きやすいのが利点です。ただし、対応品質やコストが地域ごとにばらつく可能性があり、全体の統制が難しくなります。多国籍企業の現地法人によく見られる形態です。
バーチャルサービスデスク	バーチャルサービスデスクは、物理的な拠点を持たず、リモートでスタッフが対応する方式です。クラウドツールやリモート操作ソフトを使い、どこからでもサポートが可能です。人件費の最適化や柔軟な人員配置が可能ですが、セキュリティ管理やコミュニケーションの工夫が求められます。コロナ禍以降、急速に普及しています。
フォロー・ザ・サン	フォロー・ザ・サン（Follow-the-Sun）は、地球の自転に合わせて、アジア→ヨーロッパ→アメリカの順にサポート拠点を切り替え、24時間365日対応を実現する仕組みです。たとえば東京の夜はロンドン、その夜はニューヨークのスタッフが対応します。これにより、ユーザーは常に「昼間のサポート」を受けられ、ビジネスのグローバル化を支えます。

システム監査

単語	意味
システム監査	システム監査は、情報システムが正しく動いているかを第三者がチェックする仕組みです。不正やミスを防ぎ、法令遵守や業務の信頼性を高めます。たとえば、テストで先生がカンニングを監視するようなもの。2026年現在、DX推進でその重要性はさらに増しています。監査結果は改善につながり、企業の持続可能性を支えます。
システム監査の流れ	監査は「予備調査→本調査→評価・結論→フォローアップ」の4段階で進みます。まず対象を把握し、詳細を調べ、問題点を評価して改善を促します。建築で言えば、設計確認→工事検査→完成評価→アフターフォローと同じ。クラウド環境への対応も標準化され、効率的かつ透明なプロセスが重視されています。
フォローアップ	フォローアップは、監査後の改善が実際に実行されたかを確認する工程です。指摘だけで終わらず、組織が本当に良くなるよう後押しします。テストで間違えた問題を後日再チャレンジさせるようなもの。2026年では半年〜1年周期で見直しが行われ、PDCAサイクルの確立が求められています。継続的改善が信頼を築きます。
システム監査基準	監査基準は、公正で質の高い監査を行うためのルールです。日本では情報システム監査協会が策定し、独立性・計画性・証拠に基づく評価を定めています。スポーツのルールブックのように、誰もが同じ条件で監査できるように整えられています。これにより、国内外での信頼性が確保され、ESG評価などにも活用されています。
システム監査の実施	監査は内部または外部の独立した監査人が行います。偏りなく証拠を集め、客観的に評価するのが原則です。2026年ではリモート監査が主流ですが、物理セキュリティ確認には現地調査も必要です。クラウド環境でもログ取得やアクセス確認が標準化され、透明性と効率性が両立されています。独立性が監査の信頼を支えます。
予備調査	予備調査は、監査対象の全体像をつかむ準備段階です。システムの目的、使われている技術、関連法規などを調べ、リスクの高い部分を特定します。旅行前に地図や天気を確認するようなもの。2026年ではAIによる事前分析も導入され、重点領域を効率よく絞り込むことが可能になっています。計画が成功の第一歩です。
本調査	本調査は、実際に証拠を集める核心工程です。インタビュー、ログ確認、テストデータ投入などで検証します。料理の味見のように、一部を実際に動かして確かめることも。2026年では自動化ツールで大量ログを高速分析し、人的ミスを減らしながら精度を高めています。正確な証拠が適切な評価の基礎になります。
評価・結論	集めた証拠を監査基準と照らし合わせ、「適切」か「改善要」などの結論を出します。テストの採点のように、間違いの場所と理由も明確にフィードバックします。結果は監査報告書として経営陣に提出され、2026年ではESGやサプライチェーン評価にも活用されています。明確な結論が行動を促します。
情報システムの可監査性	可監査性とは、監査しやすいようにシステムが設計されている状態です。ログ記録、アクセス制御、文書化などが整っていれば、監査もスムーズです。逆にブラックボックスでは監査不能になり、リスクが高まります。2026年ではクラウド契約にも可監査性が盛り込まれ、開発段階から考慮されるのが普通です。設計の工夫が未来を守ります。
監査証跡	監査証跡は、システム内で自動記録される操作履歴（ログ）です。「誰が、いつ、何をしたか」が追跡でき、不正防止に役立ちます。スマホの使用履歴のようなもの。2026年ではAIが異常な証跡を自動検知し、改ざん防止のため別システムに保存されるのが原則です。証跡の完全性が信頼の基盤です。
監査証拠	監査証拠は、結論を支える根拠となる情報で、ログ・文書・ヒアリング記録などが該当します。量も質も「十分かつ適切」である必要があります。裁判で証拠を出すのと同じで、曖昧では判断できません。2026年ではブロックチェーンで証拠を改ざん防止保管するケースも増えています。信頼できる証拠だけが真実を明らかにします。
インタビュー法	インタビュー法は、関係者に直接話を聞いて情報を得る技法です。事前に質問を計画し、偏りなく聞き取ります。例えば「どの部分が分かりにくかった？」と具体的に尋ねるイメージ。2026年ではオンライン会議とAI音声認識で自動要約・分析が可能になり、人的バイアスの低減が図られています。対話は理解の鍵です。
現地調査法	現地調査は、現場に出向き設備や作業を直接確認する方法です。サーバールームの温度、カードキーの運用、紙文書の保管などをチェックします。ネット写真ではなく、実際に美術館へ行くようなもの。2026年でも物理セキュリティや災害対策の確認には不可欠です。目で見る確かさが信頼を生みます。
ウォークスルー法	ウォークスルー法は、一つの取引データを最初から最後まで追跡し、システムの流れを確認する手法です。「注文→在庫引当→出荷→請求」といった一連の流れをたどります。自分のLINEメッセージが相手に届くかを確認するような感覚。2026年では可視化ツールでプロセス全体を簡単に把握できます。流れの確認が問題発見の第一歩です。
突合・照合法	突合・照合法は、異なる情報源を比較して一致を確認する技法です。例：システム売上データと会計データが同じかをチェック。友達とテストの答えを照らし合わせるようなもの。不一致があれば誤りや不正の兆候です。2026年ではAIが大量データをリアルタイムで高速照合し、早期発見が可能になっています。一致は信頼の証です。
コンピュータ支援監査技法	コンピュータ支援監査技法（CAATs）は、ITツールで監査を効率化する方法です。大量ログの分析や異常検出に使われます。Excelより専用ソフトで一括処理するイメージ。2026年ではクラウド型CAATsが主流で、機械学習で過去の不正パターンから新たなリスクを予測できます。テクノロジーが監査の質とスピードを高めます。
テストデータ法	テストデータ法は、架空のデータをシステムに入力し、正しい出力が出るかを検証する手法です。例：100円×2個＝200円になるか確認。業務データに影響を与えず安全に検証できます。2026年ではテストデータを自動生成するツールが普及し、複雑なシナリオも簡単に試せます。安全な検証が品質を守ります。
監査モジュール法	監査モジュール法は、システム内に監査用プログラムを組み込み、リアルタイムで監視する方法です。不正操作を即記録・通知するドライブレコーダーのようなもの。2026年ではクラウドアプリの標準機能として提供され、開発段階から組み込めるようになっています。常時監視が最強の防御手段です。