ITIL
■ITILとは
Information Technology Infrastructure Library
ITシステムの保守運用にかかわるベストプラクティスフレームワーク
"発注者が"受注者（外部ベンダという意味ではない）からITサービスを効率的効果的に取得するプロセスのITサービス取得（Acquisition）マネージメントのフレームワーク
そのプロセスは、戦略、企画、予算、計画、調達、開発、運用、評価、廃棄のライフサイクルからなり、調達と開発で広義のProcurement調達とし取得の一部である
パブリックドメインフレームワークでITILは英国王位著作権による公共物、許可なしにコピー、出版、改変はできない
ITサービスという言葉の定義を明確にし共通言語になり得る
可用性を上げることが高品質というのではなく、ビジネス要件を満たすことを品質アプローチで捉え顧客視点でのサービス合意と提供を行う
■7つの書籍で解説
１）サービスサポート-青本・サポートのマネジメント
-サービスデスク
-インシデント管理
-問題管理
-構成管理
-変更管理
-リリース管理
２）サービスデリバリー-赤本・ユーザのサービス要求に対するマネジメント
-サービスレベル管理
-ITサービス財務管理
-キャパシティ管理
-ITサービス継続性管理
-可用性管理
３）ビジネスパースペクティブ-ビジネス環境について
-事業継続性管理
-パートナーシップとアウトソーシング
-変化への対応
-抜本的な改革を通じた商慣習の変換
４）ICTインフラストラクチャマネジメント-インフラについて
-ネットワークサービス管理
-運用管理
-ローカルプロセッサーの管理
-コンピュータのインストールと受入
-システム管理
５）アプリケーションマネジメント-アプリケーションのライフサークル
６）プランニングtoインプリメントサービスマネジメント-ITIL導入
７）セキュリティマネジメント-セキュリティについて
■ITIL誕生の背景
英国OGC(Office of Goverment Commerce)がITサービス管理の独自ノウハウをITIL化
1980年台情報システム管理体系（ISMA、電算センタ向け）→1990年代ITプロセスモデル（ITPM、C/S向け、ユーザ重視プロセス指向）→2000年頃ITILに代表されるITサービスマネジメント
ITサービス管理がユーザに委ねられることが多く運用管理の巧拙がコストやクオリティを大きく変えてしまっていた
アウトソーシングにおけるサービス品質の確保のためSLAに結果責任を持たせた
パッケージの度重なる外付けでシステムサポートが複雑化していった、組織目標とワークプロセスのユーザ部門との共有化を図りたかった
■その他IT取得プロセス関連
アメリカ連邦政府が活用するIT取得プロセスが、エンタープライズアーキテクチャ（EA）
アメリカ連邦政府のPM方法が、アーンドバリューマネジメント（EVM）
■日本の背景
戦前から1975年までは製品の欠陥をなくす品質管理QC
1975-1995年は品質目標の主眼は作業と生産工程の改善であり、受発注の関係に進化したTQC
1995年以降、品質管理の主眼がマネジメントにTQM
■ITILの特徴
ビジネスを成功させるには何が必要かという視点を要求する
組織の強み・弱みを明らかにすることをアセスメントとし要求する
トップのコミットメント、リーダシップが導入には必要
古いITに固執してしまったり、いったん投資してしまったため継続するのではなく、勇気を持って廃棄し、新しいビジネス形態に合わせていく合理を提供
ITILを導入すれば終わるものではなく改善継続を要求する
優れた組織は勇気を持ってプロセスをシンプルにする
ITILではシステム運用部門の仕事を運用ではなくサービスと定義している
ITサービスに対する事業部門からの厳しい評価があって成立する
■ITIL資格試験
ファンデーション認定（40問の4択式、60分、6.5割正答で合格）、マネージャ認定（英語筆記試験、受講10日間）
■BS15000認証取得
BS15000＞PD0005実施要綱＞ITILプロセス定義
BS15000は、itSMFを中心に国際規格化ISO化の活動が進んでいる、2007年予定、ISO27001
ITサービスマネジメント分野の組織認証を得る場合、BS15000はitSMFによって認定を受けた組織による監査に合格することで認証を得ることができる、以下方法
１）理解 書籍や研究会への参加、研修、教育サービスの受講
２）現状分析 ITILやBS15000の診断項目に基づいた現状分析を行う
３）プロセス改善
４）予備審査 再度診断項目に基づいた現状分析
５）本審査 審査機関の審査を受ける
６）認証取得
■itSMF
itSMFは会員制の組織、itSMFジャパンは300を越える団体・個人が加盟、1200人以上の会員
■４つのITILイズム
前向きであることProactive 積極的改善をプロセスに取り込むこと
計測できることMeasureable 計画の内容と実績を数値化可視化
予見できることPredictable 将来の財政やキャパシティが耐えうるか
管理できることManagable 管理のレベル・量・スピードに無理がないか
■ITサービス受益者
-顧客customer 経営レベルのシニアマネジメント(ITサービスの費用を支払う責任のある)をITサービスの顧客という
-ユーザ 実務レベルの日々ITサービスを受ける利用する人
■ITサービス提供者
-サービスプロバイダ サービスの提供に責任を持つ組織、で通常IT部門内の部署
-サービスサプライヤ 実務担当部署、外部提携先や請負先
■サービスマネジメント
サービスマネジメントは、サービスサポートとサービスデリバリからなり、プロセス・機能を1つの機能と管理プロセス10個に分けている
1つの機能は（サービスデスク）であり、プロセス10個は（サービスサポート：①インシデント管理、②問題管理、③変更管理、④リリース管理、⑤構成管理 / サービスデリバリ：⑥サービスレベル管理、⑦ITサービス財務管理、⑧キャパシティ管理、⑨可用性管理、⑩ITサービス継続性管理）である
■サービスデスク
インシデント管理、問題管理、変更依頼、保守契約、ソフトウェアのライセンス、サービスレベル管理、構成管理、可用性管理、ITサービス財務管理、ITサービス継続性管理
コール対応、情報提供、ITサービスサプライヤとの連絡役、ITインフラの監視を行う
ITに関連したすべての問題の最初の連絡窓口、単一窓口 SPOC（Single Point Of Contact）がよい
全インシデントの記録をライフサイクルでマネジメントすること、インシデントのオーナーシップ
インシデント以外のITサービスに対する依頼事項などに幅広く対応する
インシデントの回復状況を逆に顧客に対して伝えるなど双方向の流れがあること
サービスデスクはサービスの範囲を拡大し、次の事項の処理もしくは管理とのインターフェースを担う
■サービスデスクの種類
ローカルサービスデスク（ユーザ内に設置されたサービスデスクでオンサイト対応可能）
中央サービスデスク（拠点を一箇所に集めたサービスデスク）
バーチャルサービスデスク（実際には分散しているが擬似的に一つのサービスデスクとして機能を提供）
■サービスデスクのスキル
よきチームプレイヤとして、最初の接点として、問題を抱えている相手に対して冷静かつフレンドリな対応が求められる
■サービスデスクの種類
サービスデスク機能は一箇所に纏められることが望ましく、中央サービスデスクと呼ぶ
反対はローカルサービスデスク、また、グローバルに単一の窓口を持つバーチャルサービスデスク
24時間の提供は Follow the sunが一般的で太陽の出ている地域に順番にサービスデスクの機能をシフトさせていく
■サービスプロバイダの相違
ヘルプデスクはインシデントを可能な限りすばやく管理調整し解決することを主要な目的としている。
コールセンタは大量コール数を専門的に処理することを重点としている
サービスデスクは単にインシデントの解決に留まらず企業のITシステムの運用に携わる
■コール＞インシデント＞既知のエラー＞問題
コールは、インシデントと変更依頼RFCからなる
インシデントとは、質の下落を招くもの。パスワード失念対応などサービスリクエストも含まれる。トナー交換など厳密にはRFCに位置づけられるサービス要求もインシデントとして処理されることがほとんど
既知のエラー、KnowError,KE,診断に成功した問題で永久的代替策もしくは一時的回避策が存在するもの、RFCが出せる状態、変更管理の過程で対応策が実施されるまで
問題、根本原因不明のインシデント
■インシデントの解決レベル
ワークアラウンド 暫定的にインシデントや問題を回避する処理
レゾリューション 永久的な解決
（ローカル用語：リストア 既知のエラーの対応策で回避する処理）
■サービスデスク管理フロー
インシデント管理 インシデント受付＞オーナシップ/コミュニケーション＞(自己解決/ワークアラウンドの提供) (できるだけ早く通常のサービス運用を回復させること)
問題管理 問題＞ワークアラウンド/リゾリューションの発見＞(RFC) (根本原因の検知と解決および予防をすること、既知のエラー化と解決)
変更管理 RFC＞（リリース） (RFCの受領と優先順位の分類、委員会召集と変更のスケジュール遂行、テストサーバでの変更)
リリース管理 リリース＞（解決） (計画された変更の実施のため予定立て、テスト、配布、確定したソフトやハードのバックアップの保管、構成管理へ結果伝達、本番サーバでの変更)
構成管理 CMDB（アップデート）
■インシデント管理
ビジネスに対するITサービスの復旧を第一に考える
インシデントの解決に向けてサービスデスクが初期対応可能か判断
インシデントコントロールサポートもしくはインシデントのエスカレーション
インシデントライフサイクル インシデントの状態を監視し解決の終結を見届ける
全てのインシデントのオーナはサービスデスク
マネージメントへの情報提供、顧客に進捗情報を伝達などコミュニケーション
インシデントデータベースに記録
ワークフローポジション（インシデントのステータス、インシデントライフサイクルにおいてインシデントの現在を表したもの）
影響が大きいもの、長期間に渡るインシデントは重大なインシデントの候補となり、問題マネージャによりすべての主要当事者と定期的に会合が開催され、措置の決定およびフォローが行われる
サービスデスクは全ての措置・決定事項が記録されていることを確認し、専門家サポートグループがサービスデスクの対応を助ける
■問題管理
インシデント発生の根本原因を明確にし、解決と再発防止に力点をおく
根本原因を究明し問題を排除し変更を実施するまでの流れを受身的な側面リアクティブと呼び、そうした問題が他でも発生しないかどうかを分析報告し教訓としてインシデントの再発防止を水平展開していく作業を積極的な側面プロアクティブとよぶ。傾向分析や他のITサービスへの展開を行って初めてプロアクティブと言える。
問題は、インシデントで見つかるものや、キャパシティ管理やパフォーマンス分析の過程で見つかるもの、可用性管理のCFIA、FTA、リスク分析といった分析結果から見つかるもの、エラー対処で見つかるもの等がある
KT法、フィッシュボーンダイヤグラムなどでで分析
■KT法
ケプナー/トレゴー手法、現状分析→問題分析（原因究明）→決定分析（最適案選択）
■フィッシュボーンダイヤグラム
結果を引き起こす可能性のある要因を一覧。中骨の一番右に結果を入れ、背骨からでる小骨には結果を引き起こす要因を入れる。小骨からさらに枝分かれした小さい骨に要因の中に含まれる要素を入れ図式化する。
■構成管理
計画、構成アイテム選定、コントロール、状況説明、検証と監査
ライフサイクルにおけるステータスコードの決定
所有者やユーザ部署、ITサービスを提供する人、構成文書、またそれらの相互関係を含む、全インフラストラクチャのCIを目に見える形で識別すること。各アイテムに管理番号のラベル付けや、バージョン名を明記するなど
インフラの標準化しシンプルにすることが成功の鍵
■CI（構成アイテム、Configuration Item）
ハード、ソフト、文書
最小限のレコード数で最大限のコントロールを導き出せるように分割する
SLAや変更要求などの文書もアイテムに含まれる
■CMDB（構成管理データベース、Configuration Management Database）
論理的にCIの関係を関係づける、ソフトウェアがどのビジネスサービスでどういうハード環境で動くのかといった情報
実質的には、図、写真、テキストなどインフラの物理的な実態資料、Cabファイル、（インシデント、問題、既知エラーを含む）
■確定版ソフトウェア保管庫（DSL,Definitive Software Library）
DSLは物理的な保管領域を表現し、どういった媒体で保管するか、
ソフトウェア、ライセンス、ドキュメント
■確定版ハードウェア保管庫（DHS、Definitive Hardware Store）
全ユニットの予備部品のための安全な保管庫、ハードウェアは稼働中のアイテムと同じ構築レベルで維持される。スタンバイ機
■構成ベースライン
ある時点での構造とその詳細の双方を把握するためのスナップショット、切り戻しポイントの判断材料に活用する。
変更管理のために最初にベースラインを定義し、その差異から効率的なモニタリング・コントロールが可能
■変更諮問委員会（CAB、Change Advisory Board）
RFCは変更管理マネージャのもとに集められ、変更諮問委員会と呼ばれる委員会で検討される。変更管理マネージャはその議長を務める。緊急時の意思決定は、小規模なCAB緊急委員会（CAB/EC, Change Advisory Board/Emergency Committee）が行う。レビューの対象となっている変更の文書は事前に配布される。
RFCをCABまで貯める、RFCの優先順位を決める、予算管理を行う
通常少人数で開催される、その時々によってメンバは変更される。実際の会議に開かずに意思決定することもある
■RFCの分類
軽微な変更は、変更マネージャに決定責任が委任される
深刻な影響、資源が必要な場合はCABの関与が必要
重大な影響、主要な資源が必要な場合はCAB関与の前に上級管理者の承認が必要
■リリース管理
ソフトウェア及びハードウェアおよび関連文書がその対象
デルタリリース（変更分のみ）
フルリリース（CIコンポーネント郡、イメージとしては単一ソフト）
パッケージリリース（リリースユニットをグループ化したもの、イメージとしては作業環境一式）
■サービスデリバリ
サービスレベル管理（①サービスカタログ、②期待管理、③SLA(OLA、UC)、④SIP:service improvement program）
ITサービス財務管理（①IT会計＜コスト定義と費用対効果レポート＞、②IT予算＜支出予測と経費上限設定＞、③課金）
キャパシティ管理（キャパについてのコストと需要のバランスをとる様、計画の文書化・監視・分析・チューニングを行う。①事業キャパシティ管理＜業務計画の文書化＞、②サービスキャパシティ管理＜SLAレスポンス計測調整＞、③リソースキャパシティ管理＜システム利用率の予測調整＞、④需要管理＜キャパ不足に対して長短期のリソース割り＞）
可用性管理（日常の障害の管理対策。可用性%、信頼性MTBF時間/件、保守性MTTR時間/件、故障樹解析（Fault Tree Analysis）、サービス停止分析（SOA）、コンポーネント障害インパクト分析（CFIA））
ITサービス継続性管理（災害の管理対策、オフィスの備えなど。リスク評価、ビジネスインパクト分析）
■SLM（サービスレベル管理）
計画、調整、原案作成、合意、モニタリング、報告といった一連のプロセス
アウトプット：SLR（サービスレベル要件、サービススペックシートとサービス品質計画）、サービスカタログ（全サービス、構成要素、課金などを記載）、SLA（サービスレベルアグリーメント）交渉管理、OLA（オペレーショナルレベルアグリーメント、サービスデスクとITサポートグループ間の関係を定義するのが一般的）、UC(Underpinning Contract,請負契約、保守契約とサポート契約)
責任に対して明確な視点を与える、サービスの品質を定量化、改善の余地を見つける、ビジネス要件の焦点を絞りこむ、サプライヤのパフォーマンス管理、課金のため信頼できる根拠提供
SLAの数を減らす
■SLAの典型的な内容
サービス内容、時間帯、可用性と信頼性、サポート経路、トランザクション応答時間、バッチターンアラウンドタイム、スループット、継続性とセキュリティ、課金、報告とレビュー、成果のインセンティブとペナルティ
■SLR
service Level Requirement、ITサービスの業務要件を記録、事業を代表する上級管理者に属する。サービスレベル目標（SLO）やSLAの公式化につながる交渉の基礎となる
■OLA
サービスマネジメントチームが所有する内部文書
ITサービスのサポートおよびデリバリに関してその責任範囲を設定
条項はサービス要綱、サービスレベル目標、サービスレベルアグリーメントに含まれる質的量的記述をサポートしなければならない
■ITサービス財務管理
コストを予測しサービス毎にコストを計算し、そのコストを受益者に配分し、議論することで最適な状態に向けてゆくこと
IT=資産として捉えることを根付かせる
予算管理(財務目標＜計画と実績＞)＞IT会計（原価モデル＜費用対効果＞）＞課金（課金ポリシー）
■予算管理
予算管理はコストを予測し経費に上限を設定
■IT会計
ITサービスに対する費用対効果。どこで何のためにいくら発生したかについて詳細な情報を提供する。
■課金
公正にITサービスが受益者から回収されることに注力する
実際にお金を組織内でやり取りするかはその組織の成熟度による
計算はコストモデルが参考になる
■コストモデル
ITILではコストタイプとして6分類、ハードウェア、ソフトウェア、人員、収容設備（オフィス、倉庫、光熱費）、外部サービス（警備費、人事オーバーヘッド、アウトソーシングなど）、振替（原価部門からの内部課金）
直接費（to:マーケ、営業、製造、財務などへ）、配賦間接費、未配賦オーバヘッドに分けられる
配賦間接費（Abserbed cost）間接費の内、人数割で計算できる形で按分できるもの
未配賦の間接費（Unabserbed cost）計画検討費などのように無理やりどこかの部署にコストを寄せるもの
■キャパシティ管理
以下の3つのキャパシティ管理
サービスキャパシティ(現在と将来のビジネス要求を理解、適切なキャパシティ計画、SLAパフォーマンス目標設定参考に使われる)
ビジネスキャパシティ(作業形態および資源活用、事業キャパシティ管理ごとに設定されたサービス目標が適合していることを確実に）
リソースキャパシティ(ハードウェアとソフトウェア最適化、アップグレードの計画立案、コンポーネント障害インパクト分析を活用しインフラストラクチャの弾力性を明確に、投資対効果の有効性を確保）
■キャパシティ計画
リソース使用状況とサービスパフォーマンスを文書化。事業戦略と計画を使用し将来の資源要件を予測する
トレンド分析（スプレッドシート）、分析しモデル化（待ち行モデルなど）、シミュレーションしモデル化（イベントをモデル化、時間と資源で最もコストがかかるもの）
アプリケーションサイジング（SLAを満たすためリソース要件を見積もる、アプリ導入前に現存リソースで対応可能か、将来の増加に耐えうるか）
キャパシティ管理データベースにデータ（事業データ、サービスデータ、技術的データ、財務データ、利用データ）を蓄積し、レポート作成（サービスレポート、例外レポート、キャパシティレポート）などキャパシティ管理に役立てる
■可用性管理
可用性（合意されたサービス時間からダウンタイムを引いた割合99.99%）
信頼性（信頼性と冗長性に依存する。平均故障間隔（MTBF、故障するまでの時間の平均値、総稼働時間／総故障件数、120時間/件））http://www8.plala.or.jp/ap2/shinraisei/shinraisei3.html
保守性（動作状況に復旧するための平均時間を示す平均修復時間。1件あたりの修復時間、3時間/件）
サービス性（可用性、信頼性、保守性を保障する契約上の協定）
セキュリティ（サービスの機密性、完全性、可用性。通称CIA）
サービス停止分析（SOA) : IT、ビジネス、第三者的メンバーが参加するチームで体系化した方法を用いサービス中断をレビューし、技術、プロセス、風土の不足を明確にする
コンポーネント障害インパクト分析 (CFIA)：コンポーネントが障害を起こした時のインパクトを予測・評価し代替パスがない単一障害点（SPOF:Single Point Of Failure）を識別する
故障樹解析 Fault Tree Analysis (FTA)：信頼性解析手法の一つで、故障の発生経路、発生原因及び発生確率を、その発生の経過をさかのぼって樹形図に展開しそれぞれの発生確率を加算し評価，解析する手法
http://images.google.co.jp/images?hl=ja&q=Fault%20Tree%20Analysis&btnG=%E6%A4%9C%E7%B4%A2&lr=&ie=UTF-8&oe=UTF-8&um=1&sa=N&tab=wi
■ITサービス継続性管理
事態発生時あらかじめ決められたレベルにビジネスレベルプロセスを維持する能力を提供すること。Business Continuity Managementの一部、計画導入のプロセス。
ビジネスインパクト分析、リスク評価、ビジネス継続性戦略（リスク、回復、継続性オプションのバランスを図る）、導入（ビジネス回復計画、技術面回復計画と手順書、初期テスト）、運用管理（教育、レビュー、変更管理、保証）
3つのスタンバイ（コールドスタンバイ72時間-、ウォームスタンバイ24-72時間、ホットスタンバイ即時）
ビジネスインパクト分析：ITサービスに起因する問題が元でビジネスが中断したときに、ビジネスへのインパクトを分析評価すること
■ITIL実装
ITIL実装でのビジネス上のメリットを明確にすることは重要
組織の状態やゴール設定によって具体的な活動が決まる
トップマネジメントの理解促進、社内説明努力でスムーズなトップダウンが必要
■プロジェクト管理
手法（米PMBOK、英PRINCE2）
プロセス（立上、計画、実行、コントロール、終結）
達成基準と成果物、期間、コスト、リスクを計画段階で明確にしプロジェクト計画を関係者で合意する。日々の活動の延長でなく明確な達成目標、目標値や範囲でプロセスは変わるし実現できるツールも変わる
プロジェクトマネージャ（ビジネス上メリットやリスクなどどんな影響を与えるのかを正しく伝える役割、ステークホルダへの初期段階での説得）
標準マニュアルを作成し20名研修すれば終わり、でなく、ビジネス上どのような目標を達成できたかということ、適切なタイミングでのトレーニング、意識改革や研修、プロジェクト管理など組織ソフトスキルに依存せず適切な投資やプロセス改善を行う
導入前と導入後で、可用性が向上したのか、インシデントの即時解決率が上がったのかなど、成功の可否を判定する明確な判断基準を用意すべき
ビジョン（ハイレベルのビジネス目的、アセスメント、測定可能なターゲット、プロセス改善、測定結果と測定基準）
アセスメント（ITサービスマネジメントプロセスのパフォーマンス評価項目（顧客サービス、ビジネス計画策定、サービスレベル管理、IT財務管理、ITサービス継続性管理、可用性管理、キャパシティ管理、サービスデスク、インシデント管理、問題管理、変更管理、構成管理、リリース管理）、顧客からの評価、プロセス導入状況）
■成果の測定
測定基準と測定結果を比較することで評価できる、設定した基準値をクリアできているか重要施策が納期通りに完了しているか
ITサービスマネジメント導入前と導入後で顧客満足度調査を行う
■改善活動
カルチャ（サービス提供の実態を監視、パフォーマンスデータを日々チェック、スタッフのモチベーションや次の目標に対するスタッフの理解確認）
ナレッジマネジメント（意思決定を支援するデータ郡、サプライヤや顧客との間の情報、アイデアや事例、ベストプラクティスを共有）
■SIP
サービス改善計画/プログラムservice Improvement Plan/Program
サービスレベル要件を満たすサービスが提供されない場合、またはより高い費用対効果が達成可能である場合に策定される、事業サイドの担当者が判断できる明確なマイルストーンを含むべきである
■KPI
Key Performance Indicator、重要業績評価指標。業務プロセスの実施状況を図るもので、中間目標で表す。目標が売上の場合、KPIは成約件数やクレーム数といった中間目標となる。KPIからアクションプランへ繋げる。
■シックスシグマ
正規分布において平均値から6σの範囲に入らない確率は100万分の3.4。その品質のバラツキをプロセス改善で高めようとする手法。数値管理を徹底する。データの検証などを通じてばらつきの原因を分析し，管理項目とその目標値を明確化する。そのうえで管理項目のばらつきを抑える改善策を施す。経営層、チャンピオンやブラックベルト、グリーンベルトなどの役割と責任体制を設けるなどする。
■CMMI(Capability Maturity Model Integration，能力成熟度モデル統合)
品質向上、コスト削減、納期遵守の達成を目指し、開発プロセス改善のモデルを示したもの。以下のような5段階のプロセス成熟度がある。
レベル１）開発プロセスが場当たりできでなく一貫性を持つ（初期）
レベル２）プロジェクトの計画、コストの経験則を共有できる（管理された）
レベル３）開発から保守までカバーする標準プロセスを持つ（定義された）
レベル４）各種の計測基準が定められ分析ができる（定量的管理された）
レベル５）定量的なフィードバックにより、継続改善ができる（最適化された）
■PMBOK(Project Management Body Of Knowledge) 画像
知識エリアXプロセスXパートの3次元
これらをインテグレーションして計画立案・実施していくことで、「各領域をきちんとやる」のではなく、バランスでQCD（quality, cost, delivery）を保証する
-9つの知識エリア
総合管理（プロジェクト憲章作成、プロジェクトの目的の明確化、管理手法の確立）
スコープ管理（タスクの洗出し、提出物、環境などアプトプットの決定）
スケジュール管理（スケジュール表、進捗管理表、現物ベース確認、顔色で判断）
コスト管理(見積もり、経験勘度胸・スケジュール工数・画面数・機能数・ファイル数、工数を原価管理)
品質管理（品質基準書、開発標準所、テスト仕様書、品質＝ユーザ満足度、1本目はソースをチェック、後工程に不良を流さない）
組織管理（相手方の体制・協力先の把握、リーダー教育）
コミュニケーション管理（きちんと記録する）
リスク管理（リスク一覧、問題点一覧、計画/監視/管理）
調達管理（RFP、発注仕様書、気持ち次第で出来不出来が変わる、協力するが信じない、プロジェクト管理方法・ルールの指定）
-5つプロセス
立ち上げ
計画
実行
監視・管理
終結
-3つのパート
入力（状況）
ツールと実践技法
出力（タスク、成果物）
総合力を高めることがPMの本質
PMする内容を正しくすることが重要で無意味な事は命取り
安定的品質を求める管理方法とスキルアップを求める管理方法がある
ITはプロセス化できないクリエイティブな職人であることを認識することが重要
現場経験からのアイデア、スムーズに行く方法を（ペーパープロトタイプやモックアップ）
独自方法＞PMBOK
PDCAが長期的展開で日本的、PMBOKはミッション明確化で米国的、CMMは数値指標化で米国的
リーダー番頭（具体的に指示を出す）
お役所仕事では現場に浸透しない、真剣な段取りと粘り強さが必要
PDCA（問題点認識→改善計画→実行→評価・レビュー）
■ITIL事例
MS ITILには何をすべきか事例の記述はあるが実現方法には書かれていない→MOFを開発（マイクロソフトオペレーションフレームワーク）
P&G 4項目に絞った（サービスレベル管理（SLA、OLA）、サービスデスクインシデント管理、問題管理、変更管理）、前月のトラブルを週1回2時間レビューし傾向分析、問題特定、対策を検討する体制を作った、4つでは問題管理が難しい）
インテル マレーシアとカリフォルニアでFollowザSunの24時間サポート、変更リリースを年3回だけにし一連の厳格なテストを義務付けた
東京ガス プロセス度を高め属人化を低くしたかった、プロセスオーナの概念を導入し権限を持たせプロセス化の不備をなくした、形骸化させないことが課題
英銀行 コンサルタントは該当部門長と業務経験豊富なコアメンバーに対して簡単なワークショップを複数開催、ビジネス密着した柔軟なプロセスを作成
英メーカ コンサルタント2ヶ月インタビュー形式でアセスメントを実施150箇所を改善
■メモ
IT部門が別会社のようにサービスを提供する
サービスデスクによるインシデントの一元管理
SLAによる課金とペナルティ
チェンジアドバイザリボードによるRFCの優先順位決定
ファンデーション, 試験, 資格, foundation, ファウンデーション, 問題集, ファンデーション, 試験, 模擬, 試験, 試験, 問題, マネージャー, 問題, 入門, 受験, 導入, サービス, サポート, セミナー, manager, 受験料, 運用, 模擬, 問題, 研修, 練習, 問題, サービス, デスク, ファンデーション, 資格, 教科書, ポリシー, 構成, 管理, 用語, 用語, 集, 事例, ツール, 書籍, インシデント, 管理, 問題, 管理, pdf, sla, インパクト, 分析, サービス, サポート, サービス, デリバリー, 実践, 概要, 試験, 対策, 資格, 試験, practitioner, サービス, マネージャー, ファンデーション, 問題, アセスメント, セミナー, 2007, 大阪, アダルト, サービス, デリバリー, インシデント, 赤本, 手順, 書, 認定, 試験, 運用, 管理, 開発, 依頼, nec, v3, 富士通, 障害, 管理, ファンデーション, 合格, 率, ファンデーション, 練習, 問題, 構築, 導入, 事例, 過去, 問, ファウンデーション, 資格, 本, 試験, 問題集, 資格, 取得, プラクティショナー, 合格, 過去, 問題, 青本, プラクティショナ, 効果, 無料, 雛形, iso, 合格, 率, 変更, 管理, 大全, 無料, 試験, , cmdb, pd0015, subversion, サービス, カタログ, リリース, 管理, 試験, 問題, パソコン, 版, cobit, nec, pd0005, による, 運用, 管理, 実際, サービス, カタログ, サンプル, ファウンデーション, 試験, ファンデー