マネジメントと監査

1. プロジェクトマネジメントの型とスコープ

プロジェクトを立ち上げてから閉じるまでに何を決めるのか、そのうちスコープ・資源・リスク・品質・調達・ステークホルダをどう扱うのかが分かります。

プロジェクトとは、決められた期間の中で、これまでにない成果物やサービスを作り出すために行う活動です。有期性（始まりと終わりがある）と独自性（毎回どこか違う）の二つを持つ点で、同じ手順を毎日回し続ける定常業務と区別されます。応用情報のレベルでは「用語を知っているか」ではなく「この状況でマネージャは何を根拠にどう判断するか」が問われます。判断の物差しになるのが、目的・成果物・体制・制約・前提を書いてプロジェクトを正式に発足させるプロジェクト憲章です。憲章はプロジェクトマネージャの権限の裏づけでもあるので、憲章に書かれていない要求が持ち込まれたときは、まず憲章と計画に照らして扱いを決めます。

国際的な進め方の枠組みとしてはPMBOKガイドとJIS Q 21500があります。JIS Q 21500では、活動を立上げ・計画・実行・管理・終結という五つのプロセス群に分け、管理する側面を統合・ステークホルダ・スコープ・資源・時間・コスト・リスク・品質・調達・コミュニケーションの十の対象群に整理します。PMBOKガイドは第7版で、決まった工程を順に踏む記述から、価値を届けるための原理原則とパフォーマンス領域を軸にした記述へと重心を移し、その方向は第8版にも引き継がれています。どちらにしても大事なのは、十の側面が独立ではなく互いに縛り合うという点です。スコープを広げれば時間とコストが増え、期間を縮めれば品質かコストのどちらかが犠牲になります。この綱引き（制約条件のトレードオフ）を明示して合意することが、マネジメントの中身そのものです。

スコープには、成果物の範囲を示すプロダクトスコープと、それを作るために必要な作業の範囲を示すプロジェクトスコープがあります。要求事項を集めてスコープを定義したら、成果物と作業を大きいものから小さいものへ階層的に分解します。これがWBS（Work Breakdown Structure）で、分解の最小単位をワークパッケージといいます。ここまで細かくして初めて、工数・期間・担当者・完了条件を具体的に決められます。各ワークパッケージの作業内容・成果物・受入基準を記した文書がWBS辞書です。「WBSにない作業はやらない」と決めておくことで、正式な変更手続を経ないまま範囲がじりじり膨らむスコープクリープを防げます。逆に必要な変更まで拒むのは誤りで、変更要求は変更管理委員会（CCB）で影響を評価し、承認されたらベースラインを改訂したうえで実施します。

資源のマネジメントでは、WBSの作業と組織の役割を対応づけた責任分担マトリックス（RAM）を作ります。実行責任・説明責任・相談先・報告先の4区分を割り当てる書き方をRACIチャートといい、1作業に説明責任者を1人だけ置くのが原則です。要員が特定の時期に集中しないよう、必要工数を時間軸に積み上げてから平準化する作業を山積み・山崩しといいます。なお、工数の単位である人月は、10人月を「10人で1か月」と読み替えられるとは限りません。遅れているプロジェクトへの要員追加は、教育と意思疎通の負担を増やしてかえって遅らせる（ブルックスの法則）ことがあります。関係者が増えるとコミュニケーション経路はn人でn(n-1)/2本に増え、人数の二乗に近い勢いで増えることも押さえておきます。

リスクマネジメントでは、リスクを洗い出し、発生確率と影響度で評価し（定性的分析）、必要なら金額や日数に換算して（定量的分析）、対応方針を決めます。マイナスのリスクへの対応は、原因となる作業や方式そのものをやめる回避、保険や外部委託で損失負担を他者に移す転嫁、確率か影響を小さくする軽減、対策せずに受け入れる受容の4種類です。プラスのリスク（好機）には活用・共有・強化・受容が対応します。対策を打ったあとに残るリスクを残留リスク、対策そのものが生む新たなリスクを二次リスクといいます。想定できたリスクの備えとして計画に織り込む金額がコンティンジェンシー予備、想定外の事象に備えて上位管理者が握る金額がマネジメント予備で、両者は権限の所在が違います。

品質のマネジメントは、作り込みの仕組みを整える品質保証と、成果物を測って基準に合っているか確かめる品質管理に分かれます。テストで欠陥を取り除くよりレビューや標準化で欠陥を作り込まないほうが安いというのが基本の考え方で、後工程で見つかるほど手戻り費用は大きくなります。調達のマネジメントでは、内製と外注のどちらが有利かを判断し、外注するなら契約形態と受入基準を先に決めます。ステークホルダのマネジメントでは、利害関係者を洗い出し、関心度と影響力の二軸で分類して関与の方針を変えます。影響力が大きく関心も高い相手には密に報告し、影響力が小さく関心も低い相手には定型の情報提供にとどめる、といった使い分けです。反対する立場の関係者ほど早期に巻き込むほうが、後の手戻りが小さくなります。

/* 関係者がn人のときの1対1コミュニケーション経路数 */○整数型: keiro(整数型: n)  return n * (n - 1) / 2 /* n = 6 のとき 15、n = 10 のとき 45、n = 15 のとき 105 *//* 人数が2.5倍で経路は7倍になる。会議体を階層化する根拠になる */

用語

プロジェクト憲章

プロジェクトの目的・成果物・主要関係者・体制・制約・前提を記し、プロジェクトの発足を正式に承認する文書。プロジェクトマネージャの権限の根拠にもなる。

JIS Q 21500

プロジェクトマネジメントの手引を定めた規格。立上げ・計画・実行・管理・終結の5プロセス群と、統合・ステークホルダ・スコープ・資源・時間・コスト・リスク・品質・調達・コミュニケーションの10対象群で整理する。

プロダクトスコープとプロジェクトスコープ

前者は成果物そのものに含める機能や特性の範囲、後者はそれを作るために必要な作業の範囲。両方を定義しないと「作るもの」と「やること」がずれる。

WBS

作業分解構成図。成果物と作業を階層的に分解した図で、最小単位のワークパッケージまで細分化して工数・期間・担当・完了条件を決める。

WBS辞書

各ワークパッケージについて、作業内容・成果物・受入基準・前提などを記述した文書。WBSの箱だけでは分からない中身を補い、認識のずれを防ぐ。

スコープクリープ

正式な変更手続を経ないまま、小さな追加要求の積み重ねで範囲がじりじり広がっていく現象。期間とコストの超過の主要な原因になる。

変更管理委員会

CCB。変更要求を受け付け、スコープ・期間・コスト・品質への影響を評価して承認または却下する意思決定の場。承認後にベースラインを改訂する。

RACIチャート

作業と役割の対応表で、実行責任・説明責任・相談先・報告先の4区分を割り当てたもの。説明責任者は1作業につき1人にするのが原則。

山積み・山崩し

各時期に必要な要員工数を積み上げて（山積み）、山が高すぎる時期の作業を余裕のある時期へずらして平準化すること（山崩し）。資源平準化ともいう。

コミュニケーション経路数

関係者がn人のとき、1対1の経路はn(n-1)/2本になる。人数を増やすほど意思疎通の負担が急に重くなる根拠として使われる。

リスク対応の4分類

マイナスのリスクに対する回避・転嫁・軽減・受容。原因を断つ、他者に移す、確率や影響を小さくする、そのまま受け入れる、の4通り。

残留リスクと二次リスク

残留リスクは対策後になお残るリスク、二次リスクは対策を実施したこと自体が新たに生むリスク。どちらも計画に明記して監視する。

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

特定できているリスクが顕在化したときのために、コストベースラインに含めて確保しておく予備費。プロジェクトマネージャの裁量で使える。

マネジメント予備

想定していなかった事象に備え、コストベースラインの外側に置く予備費。使用には上位管理者の承認が必要で、権限の所在がコンティンジェンシー予備と異なる。

ステークホルダ分析

利害関係者を関心度と影響力の二軸で分類し、関与や報告の濃さを変える手法。影響力が大きく関心も高い相手を最重点で管理する。

例題

出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類5：プロジェクトマネジメント　中分類14：プロジェクトマネジメント

2. スケジュールとクリティカルパス

アローダイアグラムから最早・最遅とトータルフロートを求め、どの作業を縮めれば全体が縮むのかを判断できるようになります。

スケジュールを作る手順は、WBSの作業を洗い出す、作業どうしの前後関係をつなぐ、各作業の所要期間を見積もる、資源の制約を当てはめる、という順です。前後関係を表す図には二つの流儀があります。作業を矢印で、作業のつなぎ目を結合点（丸）で表すのがアローダイアグラム（PERT図、AOA）で、作業を四角で、依存関係を矢印で表すのがプレシデンスダイアグラム（PDM、AON）です。アローダイアグラムでは、実際の作業を伴わないが前後関係だけを示したい場合に、所要日数0の点線の矢印であるダミー作業を使います。PDMでは、前の作業が終わってから始める終了-開始（FS）のほかに、同時に始める開始-開始（SS）、同時に終える終了-終了（FF）、前が始まるまで終えられない開始-終了（SF）の4種類の依存関係を表せます。前の作業の終了から次の開始までわざと空ける待ち時間をラグ、逆に前が終わる前に先行して始める重なりをリードといいます。

日程計算は前から後ろへ1回、後ろから前へ1回の2回で終わります。前向き計算では、各作業について「先行作業がすべて終わる最も早い時点」を最早開始時刻（ES）とし、それに所要日数を足したものを最早終了時刻（EF）とします。先行作業が複数あるときは、そのうち最も遅く終わるものに合わせるので最大値を取ります。すべての作業のEFの最大値が、プロジェクト全体の最短所要日数です。後ろ向き計算では、全体の完了日を出発点にして、各作業について「後続作業をすべて予定どおり始められる最も遅い時点」を最遅終了時刻（LF）とし、そこから所要日数を引いたものを最遅開始時刻（LS）とします。後続が複数あるときは、最も早く始めなければならないものに合わせるので最小値を取ります。

この2回の計算から余裕が求まります。全体の完了を遅らせずにその作業を遅らせてよい日数がトータルフロート（全余裕）で、LS-ESまたはLF-EFで計算します。これに対し、後続作業の最早開始時刻を遅らせずに遅らせてよい日数がフリーフロート（自由余裕）で、後続作業のESの最小値からその作業のEFを引いて求めます。フリーフロートはトータルフロート以下になります。トータルフロートが0の作業をつないだ経路がクリティカルパスで、その長さが全体の最短所要日数と一致します。クリティカルパス上の作業が1日遅れれば全体も1日遅れるので、進捗管理の重点はここに置きます。逆にクリティカルパス以外の作業が余裕日数の範囲で遅れても、全体の完了日は動きません。クリティカルパスは1本とは限らず、同じ長さの経路が複数あれば全部がクリティカルパスです。

全体を縮めたいときは、まずクリティカルパス上の作業を縮めます。ここが応用情報でよく問われるところで、「クリティカルパス上の作業をn日縮めれば全体もn日縮む」とは限りません。縮めていくと、それまで2番目に長かった経路のほうが長くなり、クリティカルパスが移ってしまうからです。移った時点でそれ以上は縮まなくなるので、短縮できる日数は、元のクリティカルパスと2番目に長い経路の差までが上限になります。それを超えて縮めたいなら、2番目の経路も同時に縮める必要があります。短縮の手段には、要員や設備を追加投入して期間を買うクラッシングと、本来は順に行う作業を一部重ねて並行させるファストトラッキングがあります。クラッシングはコストが増え、ファストトラッキングは手戻りのリスクが増えるという、それぞれ別の代償を払う点が判断の分かれ目です。

進捗を見せる道具も使い分けます。ガントチャートは作業名を縦、日付を横に取って予定と実績を横棒で並べる図で、誰が何をいつまでにやるかと進み具合が直感的に分かりますが、作業間の前後関係は表しにくいのが弱点です。アローダイアグラムは前後関係とクリティカルパスが分かる代わりに、進捗の見せ方には向きません。重要な節目だけを日付で置くマイルストーンチャートは、経営層への報告のように粒度の粗い共有に向きます。実務では、計画時にアローダイアグラムでクリティカルパスを押さえ、日々の管理はガントチャートで行い、上位報告はマイルストーンで行う、という組み合わせが多く取られます。

資源の制約も日程を動かします。日程計算だけで作った計画では、特定の時期に必要な要員が手持ちを超えることがあります。そこで、余裕のある作業を後ろへずらして山を崩す資源平準化を行いますが、余裕を使い切った作業は新たにクリティカルになるため、平準化のあとはクリティカルパスを引き直します。また、遅れが出たときの対処としてよく挙がる要員追加は、その作業がクリティカルパス上にあり、かつ人を増やせば期間が縮む性質の作業（分割できる作業）であることが前提です。設計のように人を増やすと意思疎通の手間が増える作業では、追加投入が逆効果になり得ます。

/* 上の表から、開始から終了までの経路をすべて書き出して長さを比べる */経路1: A -> C -> E -> G = 3 + 4 + 6 + 3 = 16日経路2: B -> D -> E -> G = 5 + 2 + 6 + 3 = 16日経路3: B -> F -> G      = 5 + 9 + 3     = 17日  <- 最長 /* 最長の経路 B -> F -> G がクリティカルパス。全体の最短所要日数は17日 */ /* 前向き計算と後ろ向き計算の結果（ES:最早開始 LF:最遅終了 TF:全余裕） */作業  ES  EF  LS  LF  TFA      0   3   1   4   1B      0   5   0   5   0C      3   7   4   8   1D      5   7   6   8   1E      7  13   8  14   1F      5  14   5  14   0G     14  17  14  17   0

用語

アローダイアグラム

作業を矢印、結合点を丸で表し、前後関係と所要日数を示す図。PERT図ともいう。前向き計算と後ろ向き計算でクリティカルパスを求める。

ダミー作業

アローダイアグラムで、実際の作業を伴わないが前後関係だけを示すために引く所要日数0の点線の矢印。日程には影響しないが順序の制約は生む。

プレシデンスダイアグラム

PDM。作業を四角、依存関係を矢印で表す図法。FS・SS・FF・SFの4種類の依存関係とラグやリードを表現できる。

最早開始時刻

ES。先行作業がすべて終わる最も早い時点。先行が複数あるときは、それぞれの最早終了時刻の最大値を取る。

最遅開始時刻

LS。全体の完了を遅らせない範囲で、その作業を最も遅く始めてよい時点。最遅終了時刻から所要日数を引いて求める。

トータルフロート

全余裕。LS-ES（またはLF-EF）で求め、全体の完了日を遅らせずにその作業を何日遅らせてよいかを表す。0の作業がクリティカルパス上にある。

フリーフロート

自由余裕。後続作業の最早開始時刻を遅らせずに遅らせてよい日数。後続のESの最小値からその作業のEFを引く。トータルフロート以下になる。

クリティカルパス

所要日数の合計が最長になる経路。全体の最短所要日数を決め、経路上の作業には余裕がない。同じ長さの経路が複数あれば、そのすべてがクリティカルパスになる。

クラッシング

要員や設備を追加投入して作業期間を短縮する手法。コストは増えるが、作業の順序そのものは変えないので手戻りのリスクは増えにくい。

ファストトラッキング

本来は順に行う作業を一部重ねて並行実施し、全体を短縮する手法。追加費用は少ないが、前工程の結果が変わると手戻りが起きるリスクがある。

ガントチャート

作業名を縦、日付を横に取り、予定と実績を横棒で表す図。進捗は分かりやすいが、作業間の前後関係やクリティカルパスは読み取りにくい。

マイルストーン

要件確定や本番移行などの重要な節目に置く、所要期間0の管理点。粒度の粗い報告や、契約上の区切りとして使われる。

資源平準化

特定時期に集中した要員の山を、余裕のある作業を後ろへずらして均すこと。余裕を使い切った作業は新たにクリティカルになるため、実施後は経路を引き直す。

例題

出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類5：プロジェクトマネジメント　中分類14：プロジェクトマネジメント

3. コスト見積りとEVMによる進捗管理

工数と費用の見積り方を選び分け、EVMのPV・EV・ACから遅れと超過を同じ物差しで読み取れるようになります。

コストの見積りは、規模を測る、規模から工数を出す、工数から費用を出す、という三段構えで考えると整理できます。規模の測り方の代表がファンクションポイント法で、外部入力・外部出力・外部照会・内部論理ファイル・外部インタフェースファイルという利用者から見える機能の数と複雑度に点数を付けます。実装言語に左右されないので、企画段階から発注側と受注側が同じ土俵で話せるのが利点です。対してLOC法は想定ソースコード行数を基準にするため、同じ機能でも言語や作り方で値が変わり、比較には向きません。COCOMOは規模を入力として工数と期間を数式モデルで求める方法で、係数を自組織の実績で較正しないと当たりません。

見積りの進め方には、過去の似た案件の実績から推定する類推見積法、WBSの末端ごとに見積もって積み上げるボトムアップ見積法（積算法）、作業種別ごとの標準工数を掛けて積み上げる標準値法、複数の専門家に匿名で回答させて意見を収束させるデルファイ法、楽観値・最可能値・悲観値の3点から期待値を出す3点見積法などがあります。どれを選ぶかは、情報の量と求める精度で決まります。企画段階のように情報が少ない時期は類推見積法が現実的で、設計が固まったあとはボトムアップ見積法のほうが精度が高くなります。ボトムアップ見積法は精度が高い代わりに、見積り自体に工数がかかり、末端が漏れると全体も漏れるという弱点があります。見積りの不確かさは時間とともに小さくなっていく（不確実性のコーン）ので、企画段階の見積りに幅を付けて示し、段階ごとに精緻化するのが実務の作法です。

決めた見積りを時間軸に並べ、いつまでにいくら使う予定かを累積で表したものがコストベースラインです。これを基準に、実績と比べて進捗とコストを同時に管理する手法がEVM（アーンドバリューマネジメント）です。EVMは三つの値を金額に換算して比べます。PV（プランドバリュー、計画価値）はその時点までに完了しているはずの作業の予算額、EV（アーンドバリュー、出来高）は実際に完了した作業に割り当てられていた予算額、AC（アクチュアルコスト、実コスト）はその作業に実際に費やした金額です。ポイントは、EVが「かかった金額」ではなく「終わった作業の値段」だという点です。EVを基準にPVと比べれば進み具合が、ACと比べれば費用対効果が分かります。

差異は引き算、効率は割り算で出します。スケジュール差異SV = EV - PV は、正なら計画より進んでおり、負なら遅れています。コスト差異CV = EV - AC は、正なら予算内、負なら超過です。比率で見るときはスケジュール効率指数SPI = EV / PV、コスト効率指数CPI = EV / AC を使い、1を超えれば良好、1を下回れば問題ありと判断します。引く順番と割る順番はどちらもEVが先だと覚えると取り違えません。SVを金額で見るとき「遅れているのに金額が小さいから軽微だ」と読むのは危険で、単位が金額なので工程末期には自然に0へ近づきます。進捗の遅れを日数で語りたいときは、EVがPVの水準に達した時点との差を見るなど、別の見方を併用します。

将来の予測もEVMの役目です。プロジェクト全体の予算総額をBAC（完成時総予算）とし、いまのコスト効率がこのまま続くと仮定すると、完成時総コストの予測EACはBAC / CPI で求まります。残作業に必要な額ETCはEAC - AC、完成時の差異VACはBAC - EACです。CPIが1を下回っているのにBACのままで報告するのは、予算超過を隠しているのと同じことになります。ただしEAC = BAC / CPI は「いまの効率が最後まで続く」という仮定に依存します。効率が悪い原因が初期の学習コストのように一時的なものだと分かっているなら、残作業は当初見積りどおりに進むと考えたEAC = AC + (BAC - EV) を使うほうが実態に近くなります。どちらの前提で予測したのかを添えて報告することが大切です。

SPIとCPIの組合せで打つ手が変わります。SPIが低くCPIが高いなら、安く進んでいるが遅い状態なので、要員追加や残業でコストを使って日程を買い戻す判断が成り立ちます。逆にSPIが高くCPIが低いなら、急いだ結果として金を使いすぎている可能性が高く、まず費用の使い方を絞ります。両方1未満ならスコープの見直しや納期の再交渉まで含めた計画変更が必要です。両方1を超えていても、見積りが甘すぎた、あるいは品質を犠牲にしていないかを疑うべきで、EVの計上基準（何をもって完了とするか）が甘いと数字だけがよく見えます。EVMは基準が明確でないと機能しない、という点が最後の落とし穴です。

/* EVMの計算手順（BAC:完成時総予算） */○なし: EVMを計算する(実数型: PV, 実数型: EV, 実数型: AC, 実数型: BAC)  SV  ← EV - PV     /* 金額で見た進捗の差異 */  CV  ← EV - AC     /* 金額で見たコストの差異 */  SPI ← EV / PV     /* 進捗の効率 */  CPI ← EV / AC     /* コストの効率 */  EAC ← BAC / CPI   /* いまの効率が続く前提の完成時予測 */  ETC ← EAC - AC    /* 残りに必要な額 */  VAC ← BAC - EAC   /* 完成時の予算差異 */  if (SPI < 1 かつ CPI ≧ 1)    /* 安いが遅い。費用を使って日程を買い戻す判断が成り立つ */  elseif (SPI ≧ 1 かつ CPI < 1)    /* 速いが高い。まず費用の使い方を絞る */  elseif (SPI < 1 かつ CPI < 1)    /* 遅くて高い。スコープや納期を含む計画変更を検討する */  endif

用語

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

利用者から見える機能の数と複雑度に点数を付けて規模を求める手法。実装言語に依存しないので、企画段階から発注側と受注側が同じ基準で議論できる。

COCOMO

規模を入力として工数と期間を数式モデルで算出する見積手法。係数を自組織の過去実績で較正しないと精度が出ない。

類推見積法

過去の類似案件の実績から規模や工数を推定する手法。情報の少ない企画段階でも使えるが、精度は類似度と実績データの整備状況に左右される。

ボトムアップ見積法

WBSの末端作業ごとに見積もって積み上げる手法。積算法ともいう。詳細化後は精度が高いが、見積り自体に工数がかかり、末端の漏れが全体の漏れになる。

3点見積法

楽観値・最可能値・悲観値の3つの値から期待値を求める手法。PERTでは（楽観値 + 4 * 最可能値 + 悲観値）/ 6 を使う。

デルファイ法

複数の専門家に匿名で見積りを回答させ、集計結果を戻して再回答させることを繰り返し、意見を収束させる手法。声の大きい人に引きずられにくい。

コストベースライン

承認された見積りを時間軸に並べ、累積で表した支出計画。EVMのPVはこの曲線から読み取る。変更は正式な変更管理を経て行う。

PV・EV・AC

PVはその時点までに完了しているはずの作業の予算額、EVは実際に完了した作業に割り当てられていた予算額、ACはそれに実際に費やした額。EVは出来高であって支出額ではない。

SVとCV

SV = EV - PV はスケジュール差異で、正なら先行、負なら遅れ。CV = EV - AC はコスト差異で、正なら予算内、負なら超過。どちらもEVから引く。

SPIとCPI

SPI = EV / PV はスケジュール効率指数、CPI = EV / AC はコスト効率指数。1を超えれば良好、下回れば問題あり。どちらもEVが分子。

BACとEAC

BACは完成時総予算。EACは完成時総コストの予測で、いまの効率が続く前提ならBAC / CPI、非効率が一時的な前提ならAC + (BAC - EV)で求める。

ETCとVAC

ETCは残作業に必要な額でEAC - AC。VACは完成時の差異でBAC - EAC。VACが負なら予算超過の見込みを意味する。

不確実性のコーン

見積りの誤差の幅が、企画段階では大きく、工程が進むほど狭まっていくという性質。企画段階の見積りは幅を付けて示し、段階ごとに精緻化する。

例題

出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類5：プロジェクトマネジメント　中分類14：プロジェクトマネジメント

4. サービスマネジメントとファシリティ

ITILの考え方を軸に、インシデント管理と問題管理の役割の違い、SLAの決め方、可用性とキャパシティの守り方が分かります。

システムは作って終わりではなく、動かし続けて初めて価値を生みます。運用の良い進め方をまとめた事実上の標準がITILで、これを規格にしたものがJIS Q 20000（ISO/IEC 20000）です。ITILの新しい版では、需要から価値までを一つの仕組みとして扱うサービスバリューシステムと、その中核である6つの活動からなるサービスバリューチェーン（計画・改善・エンゲージ・設計と移行・獲得と構築・提供とサポート）という捉え方をします。細かい版の違いより大事なのは、運用の活動を「いま起きている障害を止める」「二度と起こさないようにする」「変えるときに壊さない」という役割ごとに分け、それぞれ別の指標で評価するという設計思想です。この分け方が分かっていれば、初見の場面でもどのプロセスの話かを判断できます。

利用者からの連絡を一手に引き受ける単一窓口がサービスデスクです。窓口を分散させると、たらい回しが起きて記録も残らないため、単一窓口にすることが原則になります。サービスデスクが受けた申告のうち、サービスの品質低下や中断を引き起こす事象への対応がインシデント管理です。インシデント管理の目的は「合意した時間内にサービスを復旧させること」であり、原因の究明ではありません。原因が分からなくても、再起動や代替機への切替え、既知の誤りに対する回避策（ワークアラウンド）の適用でサービスが戻るなら、それが正解です。これに対し、インシデントの根本原因を突き止めて恒久的に取り除くのが問題管理です。原因がまだ分からない段階の管理対象を問題といい、原因と回避策が判明したものを既知の誤りとして登録しておくと、次に同じインシデントが起きたときすぐ回避できます。同じインシデントが繰り返し起きているのに問題管理へ渡さないと、復旧作業だけが永久に続くことになります。

サービスを変えるときの守りが、変更管理・リリース管理・構成管理です。変更管理は、変更要求を受け付けて影響とリスクを評価し、承認と切戻し手順の準備を経て承認する活動です。リリース管理（リリース及び展開管理）は、承認された変更を本番環境へ実際に移す活動で、リリース単位の計画、テスト、展開、そして失敗したときの切戻しを担います。構成管理は、ハードウェア・ソフトウェア・文書などの構成品目とその関係を構成管理データベース（CMDB）で正確に保つ活動で、変更の影響範囲を判断する土台になります。三つの関係は、構成管理が地図を持ち、変更管理が行き先を決め、リリース管理が実際に運ぶ、と考えると整理できます。緊急変更は通常の承認手順を短縮できますが、記録を省いてよいわけではなく、事後に必ず正式な記録と評価を行います。

提供する品質の約束がSLA（サービスレベル合意書）です。SLAは提供者と利用者の合意文書で、サービス時間帯、可用性、応答時間、障害時の回復目標、報告方法、未達時の措置などを、測れる形で書きます。SLAの中の個々の目標値をSLO、内部の計測指標をSLIと呼び分けることもあります。同じ提供者の中で部門間に置く目標をOLA、外部委託先との契約に置く目標を裏付け契約（UC）といい、外部委託先の目標が甘いと自社のSLAは守れません。決めた目標を継続的に測り、報告し、改善へ回す活動全体がSLM（サービスレベル管理）です。目標値は高ければよいというものではありません。可用性を99.9%から99.99%へ上げると、許される年間停止時間は約8.8時間から約53分になり、必要な冗長構成と運用体制の費用は跳ね上がります。業務が本当に必要とする水準を決めることが、SLAを結ぶ実質的な作業です。

可用性管理は、稼働率の目標を決めて設計と運用で守る活動です。稼働率はMTBF / (MTBF + MTTR) で求まり、上げる手は二つしかありません。故障しにくくする（MTBFを延ばす）か、直りを速くする（MTTRを縮める）かです。冗長化やホットスタンバイはMTTRを縮める側の投資、部品の品質向上や予防保全はMTBFを延ばす側の投資と整理できます。災害時の目標としては、どの時点のデータまで戻せるかを示すRPO（目標復旧時点）と、いつまでに復旧させるかを示すRTO（目標復旧時間）を分けて決めます。RPOはバックアップの取得間隔で、RTOは切替えの仕組みで決まるので、投資先が違います。キャパシティ管理は、処理量・応答時間・資源使用率を監視し、需要の伸びを予測して、不足する前に増強する活動です。閾値を超えてから慌てるのではなく、傾向から先回りするのがキャパシティ管理の値打ちです。

設備そのものを守るのがファシリティマネジメントです。停電への備えとしては、瞬断や短時間の停電をしのぐ無停電電源装置（UPS）と、長時間の停電に備える自家発電装置を組み合わせます。UPSだけでは数分から数十分しか持たないので、UPSは「安全に落とすまでの時間」または「発電機が立ち上がるまでの時間」を稼ぐ装置だと理解します。地震対策には、建物ごと揺れを絶つ免震と、揺れを吸収して小さくする制震があります。空調は温度と湿度の両方を管理し、湿度が低すぎると静電気、高すぎると結露の問題が出ます。入退室管理では、共連れを防ぐアンチパスバックや二重扉方式が使われ、電源系統や通信回線を二重化して単一障害点をなくす設計も、ファシリティ側の可用性対策に含まれます。

/* 可用性の目標値から、許される停止時間を出す */○実数型: 停止許容時間(実数型: サービス提供時間, 実数型: 目標可用率)  return サービス提供時間 * (1 - 目標可用率) /* 24時間365日運用（年8760時間）の場合 */目標99.0%   -> 8760 * 0.010  = 87.6時間/年目標99.9%   -> 8760 * 0.001  = 8.76時間/年目標99.99%  -> 8760 * 0.0001 = 0.876時間/年（約53分） /* 稼働率 = MTBF / (MTBF + MTTR) */MTBF=1200時間, MTTR=30時間 -> 1200 / 1230 = 0.9756（97.56%）

用語

サービスデスク

利用者からの問合せや障害申告を受け付ける単一窓口。連絡先を一つに集約して記録を残し、たらい回しを防ぐことが目的。

インシデント管理

サービスの中断や品質低下を、合意した時間内に復旧させる活動。目的は復旧であって原因究明ではなく、回避策で戻せるならそれでよい。

問題管理

インシデントの根本原因を特定し、恒久的に取り除く活動。原因未特定のものを問題、原因と回避策が判明したものを既知の誤りとして管理する。

ワークアラウンド

根本原因を除かないまま、サービスを暫定的に回復させる回避策。インシデント管理の武器であり、恒久対策は問題管理へ引き継ぐ。

変更管理

変更要求の影響とリスクを評価し、切戻し手順の準備を確認して承認する活動。緊急変更でも記録と事後評価は省かない。

構成管理データベース

CMDB。ハードウェア・ソフトウェア・文書などの構成品目と、その相互関係を記録したデータベース。変更の影響範囲の判断に使う。

SLA

サービスレベル合意書。サービス時間帯、可用性、応答時間、回復目標、報告方法、未達時の措置などを測れる形で合意した文書。

OLAと裏付け契約

OLAは同一組織内の部門間で結ぶ運用レベル合意、裏付け契約（UC）は外部委託先との契約。これらの水準が甘いと対外的なSLAは守れない。

SLM

サービスレベル管理。SLAで決めた目標を継続的に測定し、報告し、レビューして改善につなげる管理活動全体を指す。

稼働率

MTBF / (MTBF + MTTR)。故障しにくくする（MTBFを延ばす）か、直りを速くする（MTTRを縮める）かの二方向でしか改善できない。

RPOとRTO

RPOはどの時点のデータまで復旧させるかの目標でバックアップ間隔が決める。RTOはいつまでに復旧させるかの目標で切替えの仕組みが決める。

キャパシティ管理

処理量・応答時間・資源使用率を監視し、需要の伸びを予測して不足前に増強する活動。閾値超過後の対処ではなく先回りが役割。

UPS

無停電電源装置。瞬断や短時間の停電の間だけ電力を供給し、安全に停止させるか自家発電装置が立ち上がるまでの時間を稼ぐ。

アンチパスバック

認証済みの人に続いて入る共連れがあると入退室の記録の整合が崩れるため、共連れを検出でき、成立しにくくできる仕組み。

例題

出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類6：サービスマネジメント　中分類15：サービスマネジメント

5. システム監査と内部統制

監査人の独立性、監査手続と監査証拠の集め方、監査証跡と可監査性、内部統制とITガバナンスの関係が分かります。

システム監査は、情報システムにまつわるリスクへの対応が適切に整備され、運用されているかを、独立した立場の者が点検・評価し、関係者に助言・勧告する活動です。ここでいちばん大事なのが独立性で、二つの面から見ます。一つは外観上の独立性で、監査の対象となる部門や業務から組織的に離れていること。もう一つは精神上の独立性で、公正かつ客観的に判断する態度を保つことです。自分が設計したシステムを自分で監査すれば外観上の独立性を欠きますし、上司の意向を忖度して結論を変えれば精神上の独立性を欠きます。なお、システム監査人は助言や勧告を行いますが、指摘した不備を自ら直したり、被監査部門に代わって統制を運用したりはしません。それをすると、次の監査で自分の仕事を監査することになるからです。監査人が外部の者か組織内の者かは独立性とは別の話で、内部監査部門の監査人でも、被監査部門から独立し社長直属など上位に報告する体制があれば独立性は保てます。

監査の進め方は、計画・実施・報告・フォローアップの順です。まず監査計画を立て、リスクの高い領域に資源を厚く配分します（リスクアプローチ）。実施の段階は、対象の概要をつかむ予備調査と、実際に証拠を集めて確かめる本調査に分かれます。証拠を集めるためにあらかじめ定める手順が監査手続で、その結果得られた事実が監査証拠、実施した手続と得た証拠を記録したものが監査調書です。監査調書は、結論の裏づけであり、後から第三者が同じ判断に至れることを示すものなので、いつ・誰が・何を・どうやって確かめたかを残します。最後に監査報告書で意見を述べ、指摘事項について改善の実施状況を後日確認するフォローアップまでが監査人の役目です。改善そのものを行うのは被監査部門であって監査人ではありません。

証拠の集め方にはいくつもの技法があり、確かめたいことによって選びます。チェックリスト法とインタビュー法は運用の実態を広く把握するのに向き、突合・照合法は帳票と記録を突き合わせて整合を確かめます。コンピュータ処理そのものを確かめる技法としては、あらかじめ結果の分かるデータを流して処理結果を確かめるテストデータ法、本番のファイルに監査用のダミー口座などを設けて本番処理の中で検証するITF法（組込み監査法）、処理の途中経過を抜き出して記録するスナップショット法、監査用のモジュールをアプリケーションに組み込んで条件に合う取引を抽出する監査モジュール法（埋込み監査モジュール）、監査用のプログラムでファイルを直接分析する監査ツール法などがあります。テストデータ法は本番データを汚さない代わりに、テストしていない経路の欠陥は見つかりません。ITF法は本番環境の実態を確かめられる代わりに、ダミーデータが本番の集計に混ざらないよう厳重な管理が要ります。

監査が成り立つ前提が監査証跡と可監査性です。監査証跡とは、ある取引や処理について、入力から出力まで、あるいは出力から入力まで、経路をたどって追跡できるようにする記録の連なりです。ログ、更新履歴、承認記録、帳票の連番などがこれにあたります。可監査性とは、システムが監査証跡を備え、監査が実施できるように作られている性質のことです。ここが要点で、可監査性は運用が始まってから足せるものではありません。ログの取得項目や保存期間、権限の記録といった要件は、要件定義や設計の段階で組み込んでおく必要があります。だからこそ、開発の各工程に監査の視点を入れる開発中の監査という考え方があります。

監査の背後にあるのが内部統制です。内部統制とは、業務の有効性と効率性、財務報告の信頼性、事業活動に関わる法令等の遵守、資産の保全という四つの目的を達成するために、組織内のすべての者によって遂行される仕組みを指します。基本的要素は、統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング、ITへの対応の六つです。統制活動の代表が職務分掌で、申請する人と承認する人、開発する人と本番へ反映する人を分けることで、一人の不正や誤りが最後まで通らないようにします。ITに関する統制は、IT全般統制と業務処理統制に分けて考えます。IT全般統制は、開発と変更の管理、アクセス管理、運用管理といった、複数の業務処理を下支えする土台の統制です。業務処理統制は、入力チェックやマスタとの突合のように、個々の業務処理の中に組み込まれた統制です。土台であるIT全般統制が弱いと、いくら業務処理統制を作り込んでも、後から改ざんできてしまうため信頼できません。

内部統制を制度として求めているのが、金融商品取引法に基づく内部統制報告制度、いわゆるJ-SOXです。上場会社の経営者が、財務報告に係る内部統制の有効性を自ら評価して内部統制報告書を作成し、公認会計士等の監査を受けて提出します。ポイントは対象が財務報告に係る内部統制に絞られていること、そして評価するのは経営者自身であることです。情報システムの統制も、財務報告に影響する範囲でこの評価の対象になります。より広い枠組みがITガバナンスで、経営者が、ITへの投資と利用を組織の戦略に沿った方向へ導き、評価し、監視する責任を負うという考え方です。JIS Q 38500では、この責務をEDMすなわち評価（Evaluate）・指示（Direct）・モニタ（Monitor）の三つで表します。ITガバナンスの主体は経営者であり、システム監査はそのモニタを助ける手段の一つ、という位置づけになります。

/* 主な監査技法の選び分け */確かめたいこと                          -> 向いている技法運用の実態や手順の遵守状況              -> インタビュー法, チェックリスト法帳票と記録の整合                        -> 突合法, 照合法処理ロジックが仕様どおりか              -> テストデータ法本番処理そのものの正しさ                -> ITF法（組込み監査法）処理の途中でデータがどう変わったか      -> スナップショット法運用中の異常な取引を継続的に拾いたい    -> 監査モジュール法大量データの網羅的な分析                -> 監査ツール法

用語

外観上の独立性

監査人が、監査対象の部門や業務から組織上・身分上離れていること。自分が設計や運用に関与したシステムを監査すると、この独立性を欠く。

精神上の独立性

監査人が、公正かつ客観的に判断する態度を保つこと。組織図の上で離れていても、忖度して結論を変えればこの独立性を欠く。

リスクアプローチ

限られた監査資源を、リスクが高いと評価した領域へ重点的に配分する監査計画の考え方。すべてを一律に調べるより効果が高い。

監査手続

監査目的に照らして十分かつ適切な監査証拠を得るために、あらかじめ定めておく手順。予備調査と本調査で用いる。

監査調書

実施した監査手続と、得られた監査証拠、判断の過程を記録した文書。監査意見の裏づけであり、第三者が追跡できるように残す。

テストデータ法

結果があらかじめ分かっているデータを処理させ、出力を確かめる技法。本番データを汚さないが、用意しなかった経路の欠陥は検出できない。

ITF法

組込み監査法。本番ファイルに監査用のダミー口座などを設け、本番処理の中で検証する技法。実態を確かめられるが、集計への混入防止の管理が要る。

監査モジュール法

監査用のモジュールをアプリケーションに組み込んでおき、条件に合う取引を継続的に抽出して記録する技法。運用中の異常を継続監視できる。

監査証跡

取引や処理を、入力から出力へ、または出力から入力へたどれるようにする記録の連なり。ログ、更新履歴、承認記録、帳票の連番などが該当する。

可監査性

システムが監査証跡を備え、監査を実施できるように作られている性質。運用開始後には足しにくいので、要件定義や設計の段階で作り込む。

職務分掌

申請と承認、開発と本番反映のように、相互に牽制すべき役割を別の担当者に分ける統制活動。一人の誤りや不正が最後まで通らないようにする。

IT全般統制

開発と変更の管理、アクセス管理、運用管理など、複数の業務処理を下支えする統制。ここが弱いと、業務処理統制の結果も信頼できなくなる。

IT業務処理統制

入力チェック、マスタとの突合、例外処理の記録など、個々の業務処理の中に組み込まれた統制。処理の正確性と網羅性を確保する。

内部統制報告制度

J-SOX。金融商品取引法に基づき、上場会社の経営者が財務報告に係る内部統制の有効性を評価して内部統制報告書を作成し、監査を受けて提出する制度。

ITガバナンス

経営者が、ITの利用と投資を組織の戦略に沿うよう方向づけ、評価し、監視する責務。JIS Q 38500では評価・指示・モニタの3活動で表す。

例題

出典・根拠：IPA「応用情報技術者試験（レベル3）」シラバス Ver.7.2 大分類6：サービスマネジメント　中分類16：システム監査

演習：この章の問題を解く

ランダム出題の演習ツールです（JavaScript が有効な場合に動きます）。上の「確認問題」はそのままでもすべて読めます。