プロジェクトマネジメント
プロジェクト
・プロジェクト： 目的のために作られた組織
（構成）
▷ プロジェクトマネージャー： プロジェクトの責任者
▷ プロジェクトメンバ： 構成員
▷ ステークホルダー： 利害関係者（従業員・株主・顧客・得意先・地域社会）
PMBOK（Project Management Body of Knowledge）
プロジェクトマネジメントの知識を体系的にまとめたもの
（10個の知識エリア）
統合マネジメント・スコープマネジメント・スケジュールマネジメント・コストマネジメント・品質マネジメント・資源マネジメント・コミュニケーションマネジメント・リスクマネジメント・調達マネジメント・ステークホルダーマネジメント
PDCAサイクル
プロジェクト：「立ち上げ」〜「集結」＝PDCAサイクル(Plan-Do-Check-Action)で継続的に改善
統合マネジメント
他の知識エリアを統合的に管理
(活動例)
- 構成管理： 成果物のバージョン管理（常に最新）
- プロジェクト憲章の作成： プロジェクトを認可するために必要な文書
スコープマネジメント
プロジェクトの作業範囲・作業内容を定義する
WBS（Work Breakdown Structure）＝作業・分解・構造
作業を階層的に分解した図にする → 作業範囲を明確にする
スケジュールマネジメント
プロジェクトのスケジュール管理
ガントチャート
作業内容を棒状にした図
※ アローダイアグラム（作業順序を矢印で表した図）も含まれる
※ マイルストーン（中間到達点）：工程の節目に設定 → 作業管理がし易くなる
※ トレンドチャート：マイルストーンの予定↔︎実績 ＝ 進捗・コストを把握
コストマネジメント
予算の管理
→いくつかの見積もり方法
ファンクションポイント法
機能ごと(画面数・帳票数・ファイル数)に難易度をポイント化して見積もる
（その他の見積もり法）
| 見積もり法 | 内容 |
|---|---|
| 類似見積法 | 類似したシステムを元に見積もる |
| プログラムステップ法(LOC法) | プログラムのステップ（行）数で見積もる |
| COCOMO法 | プログラムのステップ数＋開発者のスキル＋難易度＝見積もる |
| 標準タスク法 | 成果物・作業単位で見積もる |
＊ COCOMOで見積もる → 「生産性データ」の収集が不可欠
開発工数（開発の時間）
開発コストを見積もるときに使う （単位： 人月）
例）「10人月」 の作業
「10人でやれば１ヶ月、5人でやれば２ヶ月、1人でやれば10ヶ月」かかる作業のこと
＊ 工数 → 進捗管理 ＋ 品質管理 の基準になる
TCO（Total Cost of Ownership）
システム導入〜運用までの総コスト
- イニシャルコスト： システム導入時の初期コスト 例） プリンタの購入
- ランニングコスト： システム導入後の運用・保守・維持コスト 例） 紙代・インク代・電気代
その他の知識エリア
| 知識エリア | 内容 |
|---|---|
| 品質マネジメント | 成果物の品質管理 |
| 資源マネジメント | 人的・物的資源管理 |
| コミュニケーションマネジメント | 適切なコミュニケーションを選択 |
| リスクマネジメント | リスク管理 |
| 調達マネジメント | 外部資源の調達管理 |
| ステークホルダーマネジメント | 利害関係者の管理 |
＊ フィージビリティスタディ： 新しいプロジェクト → 実現可能性を評価
工程管理
アローダイアグラム（Arrow Diagram）
作業の順序を矢印で示した図
最早開始日
前作業が終了 → 最も早く後作業を開始できる時点
→ 最早開始日 ＝ 前作業の最早開始日 ＋ 作業日数
＊ 複数の前作業が合流する場合（3,5,6）： 最も遅い作業に合わせる
＊ FS関係（Finish-to-Start）： 前の作業が終了 → 後の作業が開始する関係
最遅開始日
遅くとも完了しないといけない時点
→ 最遅開始日 ＝ 後作業の最遅開始日 ー 作業日数
＊ 複数の後作業が合流する場合（4,2,1）： 最も早い作業に合わせる
＊ クリティカルパス（危険な経路）：それ以上遅れてはいけない。
→ 上記のクリティカルパス＝①→②→④→⑤→⑥ （最早開始日＝最遅開始日の結合点を結んだ経路）
スケジュールの調整
- クラッキング： 予定が遅れる→人・金ふやす
- ファストトラッキング：工程が終了する前に、次の工程へ進む
ITサービスマネジメント
利用者 → ITサービスを快適に利用できるように管理すること
・ ITIL(Information Technolgy Infrastructure Library)： ITサービスマネジメントに関するベストプラクティス（最も効果的な実践方法）作成
→ ITサービスマネジメントのデファクトスタンダード
サービスサポート
ITILの中で、「日々の作業をまとめたもの」
→ １機能・５業務プロセスで構成
サービスデスク
ITサービス利用者 ↔︎ 事業者 窓口
＜問い合わせ内容＞
- インシデント：利用者にITサービスを提供できなくなる現象
-
サービス要求：「パスワード再発行して・使用方法教えて」
- → 要求実現：サービス要求に応えること
→ インシデント管理＋サービス要求 ＝ インシデント管理及びサービス要求管理
＜利用者からインシデント報告＞
- 記録をとる
- 解決方法わかる場合
- 利用者に伝える （インシデントクローズ）
- 解決方法が分からない場合
- 問題管理スタッフに解決を委ねる（エスカレーション）
→ サービスデスクを「どこに置くか」
| 種類 | 窓口 |
|---|---|
| 中央サービスデスク | 一箇所に集中 |
| ローカルサービスデスク | 利用者の近くに置く |
| バーチャルサービスデスク | 分散 → 仮想的に一箇所集中 |
インシデント管理
インシデント（障害）が発生 → 復旧を優先するプロセス
問題管理
- エスカレーションされたインシデントの原因発見 → 解決策を提供
- 解決済みインシデント → 記録＆今後に役立てる
変更管理
インシデントの解決策：ITサービスの変更が必要になった時
→ ITサービスの変更 → 承認 or 却下
リリース管理
承認された変更 → 適切なタイミングにリリース(実装)
構成管理
構成管理データベース（CMDB：Configuration Management Database）使用 → IT資産を管理
サービスデリバリ
ITILの中で、「ITサービスの計画・改善を図る」
サービスレベル管理
利用者が求めるサービスレベルになってるか評価
- サービスレベルアグリーメント（SLA：Service Level Agreement）： 利用者と事業者のサービスレベルに関する合意書
- サービスレベルマネージメント（SLM：Service Level Management）： ITサービスの管理
可用性管理
利用者が使いたいときに使えるように、管理する
キャパシティ管理
ITサービスで使う、システムの容量・能力を管理する
ファシリティマネジメント(facility:設備)
IT設備の管理
例）
- サージ保護デバイス： 落雷 → 過電圧を防ぐ
- UPS： 電源の瞬断・停電対策 → システムを終了させるために電源供給する装置
システム監査
客観的に情報システムを監査する。システムのリスクに適切に対処してるかチェック
＜２種類＞
- 内部監査：企業内の監査部門が行う
- 外部監査：第三者機関に依頼する
＊ システム監査基準：（経済産業省）システム監査人の行動ルール
システム監査の手順
- システム監査計画の作成
-
システム監査の実施： 監査計画に基づいて３ステップで実施
- 予備調査： アンケート → 現状把握
- 本調査： 監査証拠を入手（システム監査を裏付ける記録）
- 評価・結論： 監査証拠 → 監査調書をまとめる
- システム監査の報告： 監査報告書を作成 → 監査依頼者に報告
- フォローアップ： 監査依頼者（改善命令） → 監査対象 ← （改善状況モニタリング）システム監査人
内部統制
企業自ら、経営者の責任で体制を構築・運用する仕組み
▷ そのために、役割分担・権限を明確にすること（職務分掌）
▷ 経営層の不正を防ぐため、株主・監査役が企業を監視すること（コーポレートガバナンス）