プロジェクトマネジメント
ステークホルダ
プロジェクトマネジメントオフィス
組織としての標準化、プロジェクトマネジメントの教育訓練、プロジェクトの監視を行う
アローダイアグラム
クラッシング
クラッシングとは、プロジェクトの工期を短縮する手法の一つで、クリティカルパス上の工程に追加の資源（人員、資金）を投入して予定より短い工期で完了すること。工期の遅れを挽回するために用いられることがある。
プロジェクトのスコープはそのままに、コストを追加投入することでプロジェクト全体のスケジュールを短縮させる方法です。業務内容に精通したメンバの増員や時間外勤務の拡大などがこれに該当します。
ファスト・トラッキング
ファストトラッキングとは、プロジェクトの工期を短縮する手法の一つで、工程が完了する前に次の工程を開始すること。工期の遅れを挽回するために用いられることがある。
見積り
COCOMO
過去の類似システムの開発実績などからおよそのプログラムの行数を見積もり、これに、開発特性やコスト要因（難易度やシステム特性）などを加味して開発コストを算出する手法。
ファンクションポイント法
開発するシステムに必要となる機能の数から開発コストを算出。 ユーザー側から見た機能に基づいて見積もる方法なので、機能の数を把握する必要がある。
アーンドバリューマネジメント（EVM）
EVMでできること
コストとスケジュールを加味した進捗管理ができる
プロジェクトを完成させたとしても、予算オーバーしたり納期に間に合わなかったりしたら成功とはいえません。よくある失敗の原因は、プロジェクトのスケジュールは守っていてもコストまでは意識していないことです。
このような失敗を防ぐためにEVMが活用されます。特にプロジェクトの遅延やコスト超過、問題点の早期発見などの効果が期待できるでしょう。
部門ごとの進捗状況を統一した尺度で把握できる
プロジェクトでは、コストとスケジュールの２つを指標にしてプロジェクト管理を行います。
通常の進捗管理の場合、スケジュールに対しての進捗具合を把握できますが、コストまでは把握できません。EVMであれば２つの情報を一元管理できるので、より客観的にプロジェクトの進行具合を把握し、従業員に対しても具体的な提案ができるでしょう。
EV（出来高）
EVとは「Earned Value」の略であり、ある時点において完了している工程の「予算コストの合計値」を表します。EVとPVを比べることにより、計画と実際のスケジュールの差異を算出できます。 評価時点で実際に完成している成果物を金額に換算した値。
PV（計画予算）
PVとは「Planned Value」の略であり、プロジェクトの計画時に作成された予算のうち、「特定の時点までに完了すべき作業の予算コスト」です。これを基準値として、特定の段階においてコストオーバーがあれば作業が遅れていると判断できることから、PVはベースラインとも呼ばれています。 評価時点までに完成する予定だった成果物を金額に換算した値。
AC（実際に発生したコスト）
ACは「Actual Cost」の略であり、「実コスト」と訳されます。特定の時点までに投入された実際に「実際に発生したコストの合計値」のことです。EVとACはどちらもある時点でのコストの合計値ですが、EVが予算である点に対して、ACは実際にかかったコストを表す点に大きな違いがあります。そのためEVとの差から予算を超過していないか判断できます。 EV ＞ AC → 生産性が高い
CV（コスト差異）
EV - AC
SV（スケジュール差異）
EV - PV
CPI（コスト効率指数）
CPIは「Cost Performance Index」の略であり、プロジェクトの進捗に対して、計画と比べてどのくらいのコストがかかっているかを算出します。現時点で完了した作業の予算コスト「EV」を、実際に発生したコスト「AC」で割り算出します。
EV / AC
CPIが1であれば予算どおりですが、1よりも大きく異なる場合は計画コストの見直しが必要です。 なお、1より大きければ計画していたよりもコストが発生しておらず、1よりも小さければ計画よりもコストを多く使っていることになります
SPI（スケジュール効率指数）
EV / PV
BAC（完成時総予算）
BACは「Budget at Completion」の略であり、「プロジェクトに必要な予算の合計値」を指します。プロジェクトの計画立案時に算出される数値で、EVを算定する際の根拠となる数字でもあります。
EAC（完了時コスト予測）
EACは「Estimate At Completion」の略であり、現時点でのプロジェクト完了時の総予算を指します。現在の作業ペースでいくと、最終的にどの程度コストがかかりそうかを予測する数値です。実際に発生したコスト「AC」と、残作業に予測されるコスト「ETC」を足して算出します。
AC + ETC = EAC
EACを算出することで将来的な予測が可能となり、現時点でどのように対応すべきかの判断がつきやすいでしょう。
例
期間10日間、5日目終了時点の状況は以下。この時点でのコスト効率が今後も続くとしたとき、完成時総コスト見積もり（EAC）は？
完成時総予算（BAC） 100 プランドバリュー（PV） 50 アーンドバリュー（EV） 40 実コスト（AC） 60
現時点で完成している成果物に対するコストはEV（出来高）。EVとACを比較すると、現時点で40万円相当の成果物を作成完了しているが、そのため60万円の実コストがかかっている → 予定の1.5倍のコストがかかっている → 全部の作業に1.5倍のコストがかかる 完成時総予算100万円で、現在のコスト効率が続くと、100万円 × 1.5 = 150万円のコストが必要になる。
プロジェクト・リスク・マネジメント
脅威（マイナスのリスク）への戦略
エスカレーション エスカレーションとは、上位者、上席者に指示を仰ぐことです。 例えばコールセンター業務に言えば、電話をとったオペレーターでは対応できない内容を質問されたら、上位の管理者に対応してもらい、それでも対応しきれない場合は技術者に交代してもらうことです
回避 回避は脅威を取り除く対応です。 例えば「スケジュールが間に合わない機能の一部をあきらめる」などは回避の戦略になります。
転嫁 転嫁は脅威が発生した場合に、その脅威の影響を第三者に移転することを指します。 具体的な例としては保険が挙げられます。
軽減 軽減は脅威の発生確率を低下させたり、影響度を小さくする処置をする戦略です。 実際のプロジェクトで最も採用されるのはこの軽減ではないでしょうか。
受容 脅威の受容とは、一言で言うと何も処置をしないということです。脅威を認識し、そのまま受容するという意味です。 例えば「通信状況によってはWebサイト更新システムの予約投稿が設定した予約時間に比べて１分程度ずれることがある」というリスクがあったとします。 こうしたトラブルは発生確率も低く、１分程度であれば影響度も高いとは言えません。そのため、リスクとしてはプロジェクト・チーム内で認識しながらも、特別な対応はとらないということが多々あります。
好機（プラスのリスク）への戦略
エスカレーション 好機に対するエスカレーションは、脅威と同じく、プロマネやプロジェクト・チームの上位者・上席者に判断を仰ぐことです。
活用 好機の活用はその好機による利益を捉えようとする戦略です。 例えば、「イベントの開催日を桜の開花時期にあわせる」というのは、好機の活用の典型例と言えるでしょう。
共有 好機の共有とは、その名の通り第三者と好機による利益を共有することです。 特別目的会社やジョイントベンチャーがこれの例に挙げられるものの、意思決定の人数が増えるため、その後のプロジェクト進行との兼ね合いを見定める必要があります。
強化 好機の強化とは、好機の発生確率を高めたり、影響度を大きくさせて、好機の利益を高めようとする戦略です。 例えば、「桜の開花にあわせてイベントを行う」ことは好機の活用ですが、さらに「桜に関するイベント名にしよう」というのは影響度を高めようとする強化の戦略です。
受容 好機の受容は、脅威の時と同じく、とくに積極的な対応をとらないことです。
サービスマネジメント
インシデント
インシデント管理とは？
サービスの迅速な復旧を優先
インシデント管理とは、ビジネスへの影響を最小限に抑えるために、可能な限り迅速にサービスを復旧するための一連の活動のことです。インシデント管理では、インシデントの根本原因を深く調査することよりも、一時的な回避策を活用しながらサービスを迅速に復旧することを優先します。
インシデントの一次対応は、サービスデスクのスタッフで行うことが一般的です。
事例の場合、サービスデスク部門から経理部門担当者に「システムからのサインアウト」を依頼し、インシデントを迅速に解決しています。その他にも「経理システムの代わりにメールでエビデンスを残し決済処理を実施する」などの回避策が考えられます。
では、問題管理とは？
インシデントの根本原因を調査し予防
問題とは、インシデントを引き起こす根本原因のことを指します。この事例の場合は「経理システムのサーバーのメモリ不足」です。
問題管理とは、インシデントの根本原因を調査し、恒久的な解決策を特定する一連の活動のことです。根本原因を特定することで、インシデントの再発や将来的に新たなインシデントが発生することを予防します。
【事例】プリンターが反応せず、印刷ができなくなった
サービスデスク部門の担当者が、営業部門の社員から「プリンターが動かないため、会議で使用する資料を印刷できない」という問い合わせを受けました。サービスデスク部門担当者は、同じフロアで使っている別のプリンターで印刷するという解決策を提案し、会議の進行にひとまず影響が出ないよう対応しました。その後、業者に連絡し、調査してもらった結果、プリンターの故障が原因であることがわかり、修理してもらいました。 この場合、ITIL®では、「印刷ができない」という事象を”インシデント”と呼びます。そして、「印刷ができない」というインシデントの、根本的な原因である「プリンターの故障」が”問題”に該当します。
現場で求められる問題管理のプロセス
この事例では、ひとまずビジネスへの影響を最小限にとどめるために、「別のプリンターで印刷する」という対応をしています。これはインシデントへの対応、つまりインシデント管理なので、問題管理には含まれませんが、ビジネス上では緊急措置として求められる対応となります。
一方、問題管理プロセスでは、二度と同じ事象が発生しない状態をつくる必要があります。そのため、印刷できない原因を突き止め、解決策を立案し、解決するまでの作業が求められます。
この事例では、「業者に調査をしてもらい、プリンターを修理してもらう」という対応が問題管理プロセスと言えます。
現場ではこのようにして、インシデントの発生から始まる問題管理のプロセス上で、インシデントと問題に対する対応がそれぞれ求められることになります。
システム監査
プレシデンスダイアグラム法
作業を「アクティビティ」、マイルストーンを「イベント」と言う。
リードとラグ
リードとは、先行するアクティビティが終了する前に後続アクティビティの開始を繰り上げる時間のことです。後続アクティビティを開始する時には準備時間が必要な場合、その時間分をリードとして設定します。（下図の番号3） 逆に、先行アクティビティが終了しても後続アクティビティの開始を遅らせる時間をラグと言います。例えば、機器を発注して納品待ちのような場合、発注アクティビティ（番号1）の後続（番号2）は納品されるまでラグが発生するでしょう。
システム監査
システムの可監査性
監査証拠
監査結果を裏付けるために必要な事実。
監査証跡 監査対象システムから出力に至る過程を時系列で追跡できる一連の仕組みや記録。
監査調書 システム監査人が適用した手続、収集した資料、発見した事実を記録した資料類。
監査報告書 システム監査の実施が終了した後に、監査に依頼者に提出する報告書で、実施した監査の対象や概要のほか、指摘事項などを記載。
システム監査基準
システム監査基準とは、企業などの情報システムの監査を行うシステム監査人が順守すべき規範を定めたガイドライン。経済産業省が編纂・公開している。
システム監査業務（情報システムのガバナンス、マネジメント又はコントロールを点検・評価・検証する業務）の品質を確保し、有効かつ効率的な監査を実現するためのシステム監査人の行為規範を定めたものです。
システム管理基準
システム管理基準とは、経済産業省が公開している、企業などの情報システムを適切に管理するためのガイドライン。組織体の経営陣がITガバナンスを確立するために必要となる基本的な事項を体系的に示している。
情報セキュリティ監査の目的
保証型の監査
監査対象の情報セキュリティマネジメント体制又は管理策が、監査実施の時点で適切であったことを監査意見として表明する形態の監査
助言型の監査
今後の改善を目的として、監査対象の情報セキュリティマネジメント体制又は管理策の欠陥や懸念事項等の問題点を検出し、必要に応じて監査意見として改善提言を表明する形態の監査
監査手続の手法
ウォークスルー法
ウォークスルー法とは、 システム監査におけるレビュー方法の1つで、データが生成されてから活用されるまでの一連の流れを書類上、もしくは、実際にシステムを動かすことで確認する方法です。ウォークスルーには「歩いて通り抜ける」という意味があります。
ウォークスルー法では一連の流れを追うことで、システムに欠陥がなく正しく動くことを確認します。
インタビュー法（質問書・調査票）
監査対象の実態を確かめるために，システム監査人が，直接，関係者に口頭で問い合わせ，回答を入手する。
ドキュメントレビュー法（文書及び記録の収集・閲覧）
監査対象の状況に関する監査証拠を入手するために，システム監査人が，関連する資料及び文書類を入手し，内容を点検する。
コンティンジェンシ計画
コンティンジェンシープランとは、不測の事態が起きたときの対応法を定めた計画のことです。緊急時の影響を最低限にとどめるため、特に影響が大きいと思われる金融業界や生活インフラ業界などでは、コンティンジェンシープランが策定されています。
可用性管理
可用性管理には以下の５つの要素が必要になります。
１．可用性 ２．信頼性 ３．保守性 ４．サービス性 ５．対障害弾力性
可用性
可用性とは、SLAで合意した稼働時間に対し、実際にどのくらいの時間稼働するかを示します。具体的には以下の式で算出します。 ■可用性＝実際の稼働時間／合意した稼働時間
信頼性
信頼性とは、どれほど中断せずにシステムを利用できるかを示す指標です。具体的には２つの指標があり、それぞれ以下の式で算出します。
■MTBF＝（使用可能時間－総停止時間）／停止回数 ■MTBSI＝使用可能時間／停止回数
保守性
保守性とは、システムが停止から回復する能力を示す指標です。具体的には以下の式で算出します。 ■MTRS＝総停止時間／停止回数
サービス性
サービス性とは、ベンダーが合意した「可用性」「信頼性」「保守性」を守る能力のことです。上記３つの要素のように、具体的な時間を元にした数値で算出することはできません。
対障害弾力性
対障害弾力性とは、障害発生時に稼働を継続する能力のことです。対障害弾力性が高ければ、たとえシステムの一部に障害が発生しても停止せずに済みます。
データ管理者（DA）とデータベース管理者（DBA）
データ管理者（DA:Data Administrator）
業務の実世界から概念設計、システム化の範囲で論理設計などデータそのものの管理を行う。
データベース管理者（DBA:DataBase Administrator）
DAが設計した論理データモデルから物理設計を行い、データベースを構築したり、構築後のデータベースの運用設計および運用保守などデータベースの管理を行う。
フェーズ・ゲート
１つのフェーズが完了すると、次のフェーズへ移行する前にフェーズ・ゲートと呼ばれるレビュー期間が存在します。フェーズゲートでは “次のフェーズへ移行すべきか”や”プロジェクトを継続してもよいか” などが判断します。
RACIチャート
RACIチャートとは「Responsible」「Accountable」「Consulted」「Informed」の頭文字を合わせた言葉で、それぞれの役割を表にまとめたものです。具体的にはプロジェクトチーム内において、誰がどのような役割で関わるのかを示し、役割や責任を明確にします。
Responsible（実行責任者）
実行責任者（Responsible）は、割り当てられたタスクの責任を直接担って作業します。具体的な業務として、成果物などの作成を行います。タスクをほかのプロジェクトメンバーに割り振る役割ではなく、実際にタスクの遂行にあたる人のことです。
質問や報告をする相手を明確にするために、原則として各タスクにつき1名に限定しますが、複数いる場合もあります。複数いる場合は混乱を避けるために、RACIで定義されている役割のほかに、コラボレーター（共同作業者）として追加するのが一般的です。
実行責任者（Responsible）は、常に進捗を説明責任者（Accountable）に報告してタスクを計画通り進めることが求められます。タスクによっては、実行責任者が説明責任者を兼ねる場合もあり、実行責任者が自ら承認してタスクを遂行します。
Accountable（説明責任者）
説明責任者（Accountable）は、タスクの完了を統括する責任を担います。ただし、プロジェクト全体に対してではなく、個々のタスクで業務を行います。実行責任者（Responsible）が計画通りタスクを遂行できるよう、状況を確認・采配するのも説明責任者の役割です。
また、説明責任者はタスクの進捗状況や完了状況などを、必要に応じて報告先（Informed）へ報告します。なお、実行責任者と説明責任者との違いにおいて、実行責任者は実際にタスクを遂行する部下、説明責任者はそれを管理し責任を担うのが上司と考えると分かりやすいでしょう。
説明責任者は、タスクをすべて完了させるプロジェクトマネージャーを務める場合と、タスクが完了したことを正式に承認する管理者を務める場合があります。責任の所在を明確にするために、原則として1つのタスクにつき説明責任者は1人です。
Consulted（相談先）
相談先（Consulted）は、タスクの遂行や成果物について実行責任者（Responsible）から相談を受け、タスクの完了をサポートする役割を担います。「協業先」と呼ばれることもあります。
相談先は、プロジェクトを開始して間もない時期や、実行責任者から相談を受ける機会が少ない時期にも積極的にサポートをしなければなりません。一般的に、タスクを完了して成果物を納品する際には、その評価と承認は1人で担当します。しかし、タスクやプロジェクトのマイルストーンごと、あるいは成果物ごとに複数名配置される場合もあります。
相談先に選出されるのは、タスクの遂行に必要な知見や専門知識、経験を持った実行責任者にあたる人物が一般的です。実行責任者と相談先とでコミュニケーションを図り、タスクが計画通りに遂行できるようサポートします。ただし、タスクの実行そのものや、関係者への説明には責任を負いません。
Informed（報告先）
報告先（Informed）は、プロジェクトで扱うデータ・システムを管理している管理部門や、総務部門が担当し、タスクの進捗や状況に関する報告を受けます。タスクの遂行やプロジェクトの進行に直接関わらなくても、変更や追加などがあった場合には報告先に伝えなければなりません。
直接関わらない点については、相談先と報告先の両方に共通しています。しかし、相談先は双方向のコミュニケーションであるのに対し、報告先は一方向的なやり取りであることが大きな違いです。
通常、報告先は成果物以外の側面には関わりを持たず、実行責任者から一方通行の報告を受けるのみです。報告を受けた内容に問題が見つかった場合は、説明責任者へ連絡します。タスクによっては、相談先と報告先はいなくても構わないとされており、相談先と報告先を兼任する場合もあります。
プロジェクトにプラスの影響を与えるリスク(好機)への対応戦略
活用
好機が確実に到来するように、現実化の不確実性を取り除くための戦略
共有
好機を得られる能力の高い第三者にプロジェクトの実行権限の一部、または全部を与える戦略
強化
好機のプラスの影響を増加させたり、その発生確率を高めたりする戦略
受容
積極的な利用はしないが、好機が現実化したときにはその利益を享受しようとする戦略
サービス・ポートフォリオ
サービス・プロバイダによって管理されている全てのサービスをリスト化し、そのサービスごとに詳細情報をまとめたものです。サービス・ポートフォリオ内のサービスは、サービス・ライフサイクル上の位置に応じ、"検討中か開発中"サービスのリストである「サービス・パイプライン」、"稼働中か展開可能"サービスのリストである「サービス・カタログ」、"廃止済み"サービスのリストである「廃止済みサービス」に分けて管理されています。
情報セキュリティの三大要素
機密性とは
機密性とは、おそらく皆さんが「情報セキュリティ」と言われてイメージするものではないでしょうか。簡単に言うと機密性とは、「情報を見られたくない人に見せないように、しっかり管理しましょうね」ということです。
代表的なもので言うと、不正アクセス対策が挙げられます。情報の流出を最小限にするために、顧客情報にアクセスする際はIDとパスワードの入力を求めたり、そのIDやパスワードが外部あるいは内部で流出しないようにしっかり管理したりすることが情報の機密性に繋がります。
可用性が「使える状態」であるのに対して、機密性が「使えない状態」という要素を持っているため、混乱してしまう人がいるかもしれませんが、可用性は「見ても良い人に見せられる状態」、機密性は「見せたくない人が見られない状態」のことを言います。
完全性とは
完全性とは、「情報がちゃんとした状態であること」を指します。「ちゃんとした状態」とは、簡単に言えばデータが正確であり、最新のものである状態のことです。
例えば顧客データの住所が違っていたり、古い電話番号だったりしたら、そのデータは使い物にならないですよね？ このため、情報は正確かつ最新の状態に保たれている必要があるのです。
可用性とは
可用性とは、「使用可能な状態」のことで、英語ではAvailability（アバイラビリティ）と表現します。単語のもととなっているAvailという単語は「役に立つ」とか「利用可能」という意味合いを持っています。
少し長ったらしく表現すると、可用性とは「情報を使いたいと考えたときに使える状態にしておくこと」のことを言います。
例えば、お客様の個人情報を例にしてみましょう。顧客情報というのは、情報セキュリティにおいて絶対に流出してはいけないものです。このため、強固なセキュリティのもと管理する必要があります。だからとって、使用しにくい状態にしてしまってはいけません。仮に「顧客情報にアクセスするためには、リアルタイムで社長の承認が必要である」としてしまった場合、確かにセキュリティは保たれるかもしれませんが、業務に支障をきたしてしまいます。しかし、誰もがアクセスできる状態であっては、セキュリティを保つことができなくなってしまう可能性もあるのです。
——つまり、情報の可用性とは、「その情報を見ても良い人が、情報を見られる」という状態のことを指します。
実際の現場に置き換えてみると、各現場の管理者のみが情報にアクセスすることができて、それ以外の従業員はその管理者を経由して情報にアクセスできるようにしておく…みたいな状態のことです。
