運用のための MOF チーム モデル
Microsoft Operations Framework
ホワイト ペーパー
発行 : 2002 年 10 月
概要
このホワイト ペーパーでは、Microsoft Operations Framework の中核モデルの 1 つであるチーム モデルについて説明します (他には、プロセス モデルおよびリスク モデルがあります)。このホワイト ペーパーを読む前に、ここでのトピックに関する重要な背景情報を含む「MOF 実行概要」ホワイト ペーパーに目を通すことをお勧めします。
「運用のための MOF チーム モデル」ホワイト ペーパーでは、Microsoft Operations Framework (MOF) のアプローチおよび Microsoft 情報技術 (IT) グループ、顧客、パートナーの経験に基づくベスト プラクティスを提供します。また、より優れた効率性と相乗効果を実現するための IT 運用チームの構築方法について、ガイド機能を提供します。
運用のためのチーム モデルは、他のすべての MOF コンテンツにおけるチームの役割と機能に関するガイドとなるものです。MOF コンテンツには、Microsoft のプラットフォームでソリューションを管理および運用する際、パートナーや顧客が活用する MOF に関連して生み出される、さまざまなサービス管理機能 (SMF) ガイドおよびサービスの提供が含まれます。
これらの他の資料については、MOF に関する Web サイト (https://www.microsoft.com/japan/technet/itsolutions/techguide/mof/default.mspx) を参照してください。
トピック
はじめに
MOF チーム モデル
主要な品質目標
MOF チーム モデルの指針
チームの役割クラスタの説明
リリースの役割クラスタ
インフラストラクチャの役割クラスタ
サポートの役割クラスタ
運用の役割クラスタ
セキュリティの役割クラスタ
パートナーの役割クラスタ
チーム モデルの規模
MOF プロセス モデルとチーム モデルの併用
ITIL の関連資料
関連資料
寄稿者
はじめに
フレームワークの概要
情報技術 (IT) プロジェクトにより最大限の成果が得られるように、Microsoft では、Microsoft テクノロジを基盤として構築されるソリューションを効果的に設計、開発、展開、運用、およびサポートする方法に関する包括的なガイドを提供しています。この知識は、大規模なソフトウェア開発とサービス運用プロジェクト、プロジェクト導入における企業顧客へのコンサルティング経験、世界中の IT 業界からもたらされる最良の知識などに基づく Microsoft の豊富な経験を背景としています。
このガイドは、相互補完的な 2 つの統合知識体系 (フレームワーク) に組織化されています。つまり、Microsoft Operations Framework (MOF) と Microsoft Solutions Framework (MSF) です。
MOF は、Microsoft の製品とテクノロジを基に構築された IT ソリューションにおける基幹システムの信頼性、可用性、保守性、および管理容易性を各組織で実現するための技術ガイドです。MOF ガイドでは、複雑な分散異種 IT 環境の運用に関連する要員、プロセス、テクノロジ、および管理の問題を取り扱います。MOF の詳細については、https://www.microsoft.com/japan/technet/itsolutions/techguide/mof/default.mspx を参照してください。
もう 1 つのフレームワークである MSF では、さまざまな規模の組織またはプロジェクト チームのニーズを満たすための柔軟性の高いスケーラブルな方法が提供されます。MSF ガイドは、要員、プロセス、およびテクノロジの各要素と、大部分のプロジェクトで問題となるこれらの要素の取捨選択を管理するための原則、モデル、および運用規則で構成されます。このガイドにより、効果的な IT ソリューションを計画、設計、開発、および展開する際に役立つ実証済みの実践方法が示されます。MSF の詳細については、https://www.microsoft.com/japan/msdn/vstudio/productinfo/enterprise/msf/ を参照してください。
IT ライフ サイクル
IT テクノロジに基づくサービスを提供する場合、IT スタッフは次の 2 つの主要な項目を実践する必要があります。
サービスに対するニーズの把握とソリューションの開発
サービスを提供するソリューションの運用
Microsoft の 2 つのフレームワーク (MSF および MOF) では、MSF が最初の項目 (ニーズの分析と付加価値の高いソリューションの開発) に対応し、MOF が次の項目 (IT サービスの現状に基づくソリューションの運用) に対応します。
2 つのフレームワークは相互に補完し合うことで、"価値実現までの時間"、つまり、ニーズの把握からサービスの提供までに要する時間を最小化します。これらのフレームワーク間の用語と概念に一貫性があることも、高品質なサービスを提供するうえで重要です。
MSF と MOF では、新しいソリューションを開発および運用する際に、次の 4 つの基本的手順に従います。
新しいビジネス要件を定義します。
MSF と MOF を使用してソリューションを開発および展開します。
MOF を使用してソリューションを運用します。
繰り返し改善作業を行います。
展開済みのソリューションの変更は、運用要件、新しいビジネス要件、法的な規制要件のいずれかが原因となって発生します。
Microsoft の IT ライフ サイクルにより、IT サービスの費用効率の高い円滑な提供を目的として、IT 組織で発生する各種の活動がそれぞれ位置付けられ、相互に関連付けられます。MOF と MSF は、IT ライフ サイクルにおいて、別個でありながら相互に不可分であるようなフェーズに対応します。各フレームワークでは、それぞれの領域内で成果を得るために必要な要員、プロセス、およびテクノロジに関する有益で詳細な情報が提供されます。MSF と MOF には、有効な IT ソリューションを効果的かつ効率的に実現および運用するための、測定と繰り返し実行が可能な一貫性のあるプロセスが含まれます。
.gif "図 1: ビジネス ニーズを満たすために連携する MSF と MOF")
図 1: ビジネス ニーズを満たすために連携する MSF と MOF
MOF と ITIL
IT サービス管理における現時点での業界のベスト プラクティスは、英国の政府調達庁 (OGC : Office of Government Commerce) により IT インフラストラクチャ ライブラリ (ITIL : IT Infrastructure Library) としてドキュメント化されています。
OGC は、サービスの管理と運用のための情報技術の使用に関して、ベスト プラクティスとなるアドバイスとガイドの開発を担当する英国政府機関です。
この目的を実現するために、OGC は、世界中の主導的な IT 企業と共にさまざまなプロジェクトを認定し、IT サービス管理の運用規則に関するベスト プラクティスをドキュメント化および検証しています。ITIL には、現在 40 を超えるドキュメントがあります。各ドキュメントは、IT サービス管理における 1 つの機能に対応しており、他のドキュメントとの相互参照も可能です。
MOF では、これらの共同制作的な業界標準を Microsoft の製品およびテクノロジを使用するための特定のガイドと一体化させています。また、分散 IT 環境と業界動向 (アプリケーション ホスティング、Web ベースのトランザクションと電子商取引システムなど) をサポートするために、ITIL の実践体系が拡張されています。
設計上の検討事項
MOF は、以下の目的を満たすように設計されています。
実証済みの概念を使用します。
業界のベスト プラクティスを活用します。
運用知識に対して拡張可能な基盤を提供します。
要員、プロセス、およびテクノロジの問題に対処します。
顧客、パートナー、Microsoft Global Operations & Technology グループ (以前の ITG)、および Microsoft 製品とサービスの各組織からの情報を統合します。
ビジネスが変化する環境に迅速に適合できるように、IT の機敏性を向上します。
Microsoft Solutions Framework と一体化し、IT ライフ サイクルの他の部分を管理します。
サーバーやテクノロジの単なる管理ではなく、プロセスと手順を視野に入れながら、エンド ツー エンド サービスの管理をサポートします。
MOF モデル
MOF は、次の 3 つのモデルにより構成されます。
プロセス モデル
チーム モデル
リスク モデル
この 3 つのモデルにより、IT サービス管理での要員、プロセス、およびリスク管理に関するガイドが提供されます。各モデルでは、Microsoft プラットフォームを基盤とするシステムにおいて、高度な可用性、信頼性、保守性、および管理容易性を実現するためのテクノロジとベスト プラクティスの確立に重点が置かれます。また、他のテクノロジ プラットフォームとの相互運用性に関するガイドも提供されます。
MOF チーム モデル
概要
ベスト プラクティスの概念を導入するにあたり、Microsoft では、MSF の展開を通じて得られた教訓を活用し、組織の構造およびプロセスの所有に関する ITIL のベスト プラクティスを基盤とし、パートナー、顧客、および Microsoft の社内 IT グループが使用するための重要な成功要因をモデル化することにより、MOF チーム モデルを作成しました。
MOF チーム モデルでは、大企業の IT 部門から電子ビジネス データ センターやアプリケーション サービス プロバイダまで、成果を上げているさまざまな規模の IT 運用組織の一貫性のある品質目標に基づいて、IT サービス管理のガイドを提供します。
.gif "図 2: MOF のベスト プラクティスのソース")
図 2: MOF のベスト プラクティスのソース
実際の状況において何が功を奏するかということについての例や事例研究を精選した結果では、ここで説明する品質目標であるベスト プラクティスおよび反復可能な成功が重要だということがわかります。そこで、このような目標を MOF フレームワークに応用し、顧客やパートナーが運用およびサービス管理実践を改善し効率を高める方法について、具体例とアイデアを提供できるような形にしてあります。
Microsoft のプラットフォームでの分散コンピューティングをサポートしベスト プラクティスに導くという MOF の全体的な目標の方向性から外れないためには、このような環境におけるチーム モデルは、従来のホスト集中コンピューティングである階層的データ センター運用チームとは外観も実行方法も非常に異なる点に注意する必要があります。
"プロセスの所有" と "職能組織" に関する提案には微妙なバランスが存在します。たとえば、変更管理プロセス所有権は、ホスト (メインフレーム) 環境でははるかに容易に特定の人物に委任できました。その人物は、システムに対するエンド ツー エンドの変更管理権を所有している可能性が高かったからです。今日、変更管理の所有権は、地理的要因、ビジネス ユニット、タイム ゾーン、会社の境界さえ超えてしまうため、特定の人物またはグループに割り当てることははるかに困難になっています。
組織モデルは、組織内で使用されるプロセスと緊密な関係にあります。プロセスに関する責任は分担する必要があります。このため、そういったプロセスの達成方法について業界全体に標準的なベスト プラクティス (ITIL や MOF など) の意義を伝えることが重要となります。
MOF チーム モデルにより次のことを説明します。
運用チームを構築するためのベスト プラクティスの役割クラスタ。
各役割クラスタの主要な活動および能力。
さまざまな組織の規模および種類に合わせたチームの編成方法。
役割の効果的な組み合わせ。
Microsoft プラットフォームを基盤とする分散コンピューティング環境を実行、運用、および維持するうえで有益な指針。
MOF チーム モデルと MSF チーム モデルの関係性。
主要な品質目標
有効なサービス管理チームの目的
MOF チーム モデルは、運用チームがいくつかの重要な品質目標を達成する必要があるという考えに基づいています。Microsoft の社内運用チーム、パートナー、および顧客において繰り返された経験から、この原則は実際に有効であることが証明されています。このような目標がチームの原動力となり、MOF 内でのチーム モデルの定義に役立ちます。次にそれらの目標を示します。
適切なリリース管理、変更管理、およびすべての IT サービスとシステムに関する的確なインベントリ追跡
物理的環境およびインフラストラクチャ ツールの効率的な管理
良質な顧客サポートおよびサービス体制
予測可能、反復可能な自動化された日常的なシステム管理
企業資産の保護、システムおよび情報への適切なアクセス権限管理、緊急事態に対応するための事前対策の策定
サービス パートナーおよび納入業者との効率的で費用効果が高く、互いに有益な関係
リリースおよび変更管理
既存のリソースを最大限活用し、IT サービスおよびシステムの運用、維持にかかわるコスト コンポーネントを把握するには、運用チームは既存リソースを確認し詳細に追跡する必要があります。変更の計画化、リスク評価、変更実施に関する最良の意思決定を行う方法を知るには、そのプロセスを詳細に文書化すると共にこれまでの変更履歴を文書化することが必要です。文書化することにより、チームは全体的な IT 運用にかかわる経験から学習できると共に、内部の知識プールを蓄積できます。
変更に関する企業のナレッジ ベースや得られた教訓は、分散した実際のチームの経験をさらに積み上げていくうえで計り知れないほど貴重なものとなります。厳密に維持された構成管理データベース (CMDB) により、一貫性のあるインベントリ追跡および変更管理が実現します。
物理的環境およびインフラストラクチャ ツールの管理
効果的な IT 運用には、物理的環境に関する明確な標準と、物理的資産および現行の IT インフラストラクチャを維持管理するためのツールが必要です。IT 組織では、膨大な量の複雑な計画と、環境、ハードウェア、ソフトウェア、およびシステムの統合が必要です。組織、文化、地理的な境界が分散している場合には、インフラストラクチャ システム管理に、言語、タイム ゾーン、ビジネス要件などを割り当てる必要があり、さらに複雑さが増します。
効率的なサービス管理組織では、ビジネス要件やシステムの能力に応じて、リソースの集中と分散をいかにうまく組み合わせるかについて慎重に分析します。自動化と標準の反復 (画像、ハードウェア、ソフトウェア プラットフォーム、構成ツールなどについて) が強く奨励されます。
良質な顧客サポートおよびサービス体制
サポートの質は、最も顧客とユーザーの目につきやすく、IT 部門全体の質として受け取られます。次の 2 つが、高品質で一貫性のある顧客サポートを提供する能力への基本的制約となっています。
問題追跡、ナレッジ管理、およびコミュニケーション ツールの不十分さ。
サポートを提供するスタッフのスキル レベルのばらつきと頻繁な人事異動。
大部分の顧客満足度測定法は、問題解決に要した時間、報告される問題の数、最初の解決要求後も繰り返される問題や未解決の問題の数、および一般的な顧客満足度調査に基づいています。専門的なヘルプ デスクおよびサポート サービス組織、研修センター、ITIL ドキュメント、標準化およびベスト プラクティスを共有する他のコンソーシアムなど、サポート組織が活用できるリソースは数多くあります。
IT 運用グループにとって本当の "サービス体制を支える文化" を獲得することがこれまでになく重要になっています。IT システムのユーザー自身がますますテクノロジに精通し、自分をサポートしてくれるシステムやスタッフにより高い期待を抱くようになっているからです。
予測および反復可能な自動化されたシステム管理
運用環境を円滑にまた計画どおりに日々運営することは、事態がうまく推移している場合には当然のことのように受け取られがちですが、うまくいかなかった場合にはなかなか忘れてはもらえません。今日、組織内のあらゆるレベルのあらゆる人が、業務遂行上何らかの形でシステムの稼働状況に依存しています。効果的なサービス管理チームの主要な目標は、日々の定型的な作業ができる限り自動化され運用スタッフが手を出さずに済むようにしておくことです。
運用活動のポリシーと手順に関する一貫性のある詳細な文書化は、一貫したサービス管理実践を予測し反復する能力を高めるうえで役立ちます。システムが期待どおりに機能し、予想外の状況に陥ったときにタイミング良く通知が行われるよう、業務の自動化は、絶え間のない詳細なシステム監視と一体化させる必要があります。
企業資産の保護、権限の管理、および事前対策型のセキュリティ計画
企業が持つ有形無形の知的財産および資産に関するセキュリティ問題は、オンライン ビジネスや電子取引専門会社の発展と共に、これまでになく重要かつ困難になっています。セキュリティの確保は、管理者が権限のあるユーザーを識別および定義でき、権限を持つユーザーが必要とする情報に容易にアクセスできるようにし、同時に権限を持たない者による使用を防止できるものでなければなりません。
セキュリティ確保の実施では、どのシステムでどのレベルのセキュリティ管理が行われ、厳格なセキュリティおよび認証プロセスを自動化するうえでどのような技術が採用されているかという特定の情報の使用方法を定義するビジネス ポリシーおよび手順を示す必要があります。不測の事態に備えるためには、事前対策型のリスク管理および緊急事態に対する計画策定が必須です。
サービス パートナーおよび納入業者との互いに有益な関係
一般の企業社会、とりわけソフトウェア業界の基本的な方向性は、中核ビジネスとしての IT サービスへと向かっています。ソフトウェアそのものをサービスとして提供し、顧客と対面する物理的な実体や運用管理環境を持たず、これらのサービスに対するサポートも行わない真の仮想企業は、すべて他の企業とのしっかりしたパートナーシップを必要とし、専門商品や専門サービスを供給してくれる取引相手を求めています。互いに有益で費用効果の高いやり方でこのようなパートナーシップを既定し維持していくことは、すべての関係者が成功を収めるうえできわめて重要です。
品質目標を達成するためのチーム モデル
MOF チーム モデルの 6 つの役割 (次の項で詳述) は、上記の主要な品質目標と対応しています。これらは次の表に示すような形で対応します。
品質目標 |
チームの役割 |
|---|---|
リリースおよび変更管理 |
リリース |
物理的環境およびインフラストラクチャ ツールの管理 |
インフラストラクチャ |
良質な顧客サポートおよびサービス体制 |
サポート |
予測および反復可能な自動化されたシステム管理 |
運用 |
企業資産の保護、権限の管理、および事前対策型のセキュリティ計画 |
セキュリティ |
サービス パートナーおよび納入業者との互いに有益な関係 |
パートナー |
多くの場合、この役割は、IT 組織内および時としてビジネス ユーザー コミュニティ内のさまざまなグループや外部コンサルタント、パートナーとの間で分担されます。一般に、チームの構造、役割、責任がどのようなものであれ、実現できそうなこととその可能性が全員にとって明確になるように、実施方法を慎重に定義しはっきりと伝えることが必要です。これにより、特定個人の仕事やチームの取り組みへの質的な貢献の明確化に最も役立つ環境を実現できます。
MOF チーム モデルの指針
効果的な役割相互作用を実現するコンポーネント
効果的で能率的な運用チームを持つには、役割、責任、および職務権限を定義するだけでは不十分です。チームにとってのこういった重要な基礎的要素は、文化的価値観にまで浸透した基盤となる実施方法と原則、そしてチームの機能方法や意思決定および優先順位を決定する考え方についての基準となるガイドラインを用意したものでなければなりません。
MOF チーム モデルにとっての 5 つの主要原則およびガイドラインは次のとおりです。
優良な顧客サービスの提供
ビジネス上の優先順位の把握と IT によるビジネス価値の付加
強力で相乗効果のある仮想チームの構築
IT による自動化およびナレッジ管理ツールの活用
強力な IT 運用スタッフの獲得、養成、維持
優良な顧客サービスの提供
すべての運用グループの役割とは、最終的には顧客のためにサービスを提供することにあります。その顧客が外部のエンド ユーザーであれ、別の運用チームに所属する同僚や企業経営者であれ、高品質の徹底した顧客サービスを提供するというニーズが存在します。顧客サービスは 1 つまたは少数の役割に限定されるものではなく、末端の顧客だけが "唯一の" 顧客というわけではないということを重視するサービスに対する考え方がすべての運用チームに浸透していることが大切です。
サービス デスクや製品サポート サービスなどの専門のサポート チームに対しては研修、指導、管理、評価を行い、チームが提供する顧客サービスの質については、業務の直接的な結果であるため、ランク付けを行います。他のすべての運用管理役割における顧客サービスは、専門サポート チームほど直接的ではなくなりますが、重要性が低くなるというわけではありません。顧客のニーズをすばやく把握し、そのニーズに応えるために顧客との間で互いに納得のいく計画を立案し、迅速に動いて確約事項を遂行できる必要があります。
ビジネス上の優先順位の把握と IT によるビジネス価値の付加
ITIL および MOF の基本前提は、ビジネス上の優先順位が IT サービスの原動力になるというものです。IT グループの照準をビジネス計画に合わせるということは、あらゆる新規プロジェクトの計画策定において実行されなければならない基本作業となります。従来、情報技術は、ほとんど企業収益のプラス要素とはならないコスト センターと見なされてきました。しかし、Web を介して行われるビジネスの割合がますます大きくなるにつれて、IT に対する認識と期待は劇的に変化してきました。IT はもはや、企業のビジネス目標を達成する強力な推進力となっています。
IT 業界のアナリストによる複数のレポートでは、ビジネス目標にとっての IT の重要性およびこれに関連する問題点について、次のようないくつかの共通したテーマが挙げられています。
いまや IT の能力は、事業成績によって測定されている。
IT は、ビジネスにとっての真の有用性を示そうと奮闘を続けている。
IT は、IT インフラストラクチャやプロセスなどの言葉で表現されるようなビジネス問題へとその注目点を変えようとしている。
システム、ネットワーク、アプリケーション、およびビジネス プロセスの複雑な相互作用の関連付けは、既存のサービス管理ツールでは困難である。
ビジネス上の優先順位によって、運用がビジネスにどのように影響し、どの部分がどのような影響を受けるかなどが明確になれば、作業の質はより高まり、適切な重要度が与えられることが予想されます。変化するビジネス上の優先順位に対応しながら、新たなシステムを開発し、既存システムを維持していくことは困難な挑戦ではありますが、これはあらゆる IT 環境にとって基本前提になっています。さらに、個人的な仕事の満足度と誇りは、ビジネスの展望を理解し、いかに各個人が組織のビジネス上の優先事項の達成に貢献できるかという点を把握することから生まれます。
強力で相乗効果のある仮想チームの構築
MOF チーム モデルは、相互依存的で多くの専門分野にまたがる役割を担って働く仮想チームとして機能します。通常、IT 運用の役割は、ある製品の出荷に向けた単一プロジェクト チームの業務の一部ではなく、多くのさまざまなプロジェクトおよび運用システムで同時に業務を遂行するという点で、MOF チームはソフトウェア開発プロジェクトに焦点を合わせた MSF のチームとは異なります。プロジェクト中心で期限の定まった MSF 開発チームと比較した場合、プロセス中心の MOF チームは永続性のあるチームと言えます。
運用チームの役割は、一般にさまざまな組織に対して責任を負います。この点は、通常、1 つのビジネス ユニット内の共通の目標に向けて組織され提携関係を結ぶソフトウェア開発チームとは異なります。したがって、1 人のメンバがある大きなシステムにおいてインフラストラクチャとしての役割を担いながら、同時に、より小さなシステムにおいては、リリースと構成、インフラストラクチャおよびサポートの役割を果たすという場合も考えられます。
仮想チームは、主に電子的な手段によって互いにコミュニケーションをとり、共同作業を行う従業員のチームです。コミュニケーションは、組織の境界、空間、および時間の枠を超えて行われます。Web を介したスタッフとのリアル タイムの共同作業によって、人々の働き方や情報の共有方法が大きく変わろうとしています。インターネットはチーム メンバ間のコミュニケーションの新たな標準となり、共同作業ソフトウェアはいっそう高まった生産性獲得への道を開きつつあります。
仮想チームという概念は重要です。なぜなら、役割を規定の枠組みに封じ込める組織の境界がないため、仮想的な側面をカバーする、より強力なコミュニケーション、信頼に基づく合意と関係、明確な行動計画、行動項目が失われてしまわないようプロジェクトおよびタスクの追跡をサポートする自動化ツールなどが必要となるからです。
仮想チームにとってきわめて重要なコンポーネントは、それぞれの役割がシステムを稼働させ続けるために自らの責任を果たすという点で、他の役割に依存し信頼できることです。このことは、組織文化の融合、優れた管理、共に働く時間などを通じて発展します。たとえミスによってダウンタイムが発生しビジネスに障害が起こったとしても、1 人のメンバや 1 つの役割の落ち度とは言えません。むしろ、できる限り迅速にエラーを訂正しシステムを復旧することが仮想チーム全体の責任となります。
業界の調査によれば、仮想チームのメンバを選抜する際、コミュニケーション スキルやチームへの適合性が重視されることは多くの場合ほとんどないことがわかっています。アナリストたちは、この点が多くのチームの失敗の主要因であると語っています。
仮想チームを組織する場合、次のようなメンバを求めます。
独立して作業ができる。
指導力がある。
特定の技術的なスキルを持っている。
組織と知識を共有できる。
効果的な作業方法の開発に貢献できる。
IT による自動化およびナレッジ管理ツールの活用
従来、ナレッジ管理ツールは、ほとんどの場合サービス デスクや製品サポート サービスによって提供される機能であるという意識で捉えられていました。知識の宝庫としての、通常大規模で、インデックス化した検索可能なデータベースにより、顧客が遭遇する問題の根本原因となりうる既知のエラーや、関連性が予想される問題をすばやく取り出すことができます。
ナレッジ管理システムでは、その組織がサポートする製品、システム、およびテクノロジに関して最もよく起こる問題、質問、そして一般的なヒントやこつが集められます。このシステムでは、多くのサポート要員の努力を単一のソースに集積して、各サポート要員が他の要員の知識を活用できるようにすることにより、報告される出来事や問題を識別し、原因を明らかにし、解決するのに要する時間が大きく削減されます。
またナレッジ管理システムにより、製品、サービス、またはシステムの開発を担うビジネス グループに対しレポートおよび測定基準を提供するための、体系的で自動化された方法が確立されます。グループの側では、これらのレポートを活用することで、ユーザーからの苦情の傾向や将来のリリースに向けて求められる機能を特定できます。
自動化ツールには、電子メール配布リストのメンバ変更やネットワーク アクセス許可の付与というように、幅広い業務上の使い方があります。インフラストラクチャの役割では、他の運用管理グループに対する中核的なサービスとして、この種の自動化ツールの仕様書を所有していることがよくあります。これにより、定型的な手作業は取り除かれ、一括のセルフサービスおよび自動化された業務へと転換されます。これらのツールは、多くの運用管理ソフトウェア ベンダから購入できます。また、企業のエンタープライズ リソース計画システムを通じてカスタマイズされたものを作成することも、ゼロから作成することもできます。
仮想チームの学習成果は、テクノロジをより有効に、迅速に、そして安価に展開し運用するために、組織の知識を形成するうえで役立ちます。これを達成するには、個人の知識を捕捉し、プロセスの方法体系に組み込み、要員への依存性から脱却する必要があります。
強力な IT 運用スタッフの獲得、養成、および維持
強力な運用スタッフを惹きつけ確保しておくことは、費用効果の高い効率的な IT 組織を運営するうえで非常に重要です。これは、従来的な企業およびオンライン ビジネスの双方に当てはまります。このことは、IT 業界では卓越した才能の獲得競争が常に激烈であるという事実によっていっそうその重要性が増します。
情報技術によって、万人にとってのビジネス手法がかつてないほど変化し、変化のスピードも目を見張るほど速くなっています。専門的な IT スキルへの需要が急上昇しているため、IT 要員を惹きつけ確保することは非常に重要です。
IT 運用スタッフの価値を正しく評価するためには、企業は大きな思考方法の転換に対処することが必要です。従来、多くの企業では、開発者を技術スタッフのエリートと見なしていました。彼らは "さっそうとした" 技術の予言者であり実行者でした。完成したコードはそれを実行するだけの運用グループに引き渡されました。あるいは、ソフトウェア会社では、過去何年もかけて開発されたコードの多くは、パッケージに収められてパートナーや顧客に出荷され、統合および運用されました。
しかし、インターネットや電子ビジネスの急激な発展、とりわけ Microsoft 自体の "サービスとしてのソフトウェア" という構想や新たな .NET プラットフォームの出現により、運用はまさにソフトウェアの中核となり、"ソフトウェアを出荷する" という言葉は文字どおり再定義されました。運用は開発のまさに対等なパートナーであり、スケーラブルで、信頼性と可用性が高いソフトウェアの開発という要件の定義に際して、早期からの協力関係が求められます。Microsoft 自体の現在の進展により、さまざまな点でソフトウェア開発会社であるという意味合いが再定義されて、IT サービスおよび運用会社であるという意味づけが加わりつつあります。
Microsoft は技術的な認証基準の確立において大きな成功を収めてきました。これは、技術者の研修やスキルの発展には大いに意義のあることですが、同時に、企業にとっては資格を取得した技術者の維持確保という問題に直面しています。資格を取得した IT 技術者に対する需要は、そうでない技術者よりも高いため、通常、より高い給与を支払わなければならないからです。こういった技術者を評価し維持するには特別な注意を払う必要があるのです。
Microsoft 社内の人事グループには、最も重要な資産である社員を ADK、つまり惹きつけ (Attract)、養成し (Develop)、確保する (Keep) するという原則が昔からあります。運用要員のチームを管理するには、要因の補充、保持、および再教育をうまく組み合わせることが必要です。
要員を維持するうえで、当たり前のことなのに過小評価されているのは、まず適切な人材を雇うということの重要性です。IT グループの不適切な人材が、人手不足の領域の決定的に重要なポストに配置されてしまうという問題が発生したとします。不適切な人材は、自分自身の役割において十分な業績を上げられないだけでなく、自分の業務を遂行するために同僚に余分な手間をかける可能性があります。グループが必要とする人材であるかという "適合性と熟練度" の重要性は言うまでもなく、時間をかけて十分慎重に面接を行い、候補者を客観的に比較できるよう、面接の質問と応答の評価シートおよび成績表を用意してください。
再トレーニングと継続的な技術教育は、優秀な IT スタッフを維持するうえで非常に重要で、業界の調査によれば、これがスタッフを保持するためのトップ 5 の要因の 1 つになっていることがわかります。従業員の製品および技術的スキルを高めるということに加えて、IT 業務をより効果的に機能させるうえでも研修は有益です。なぜなら、研修によって従業員は技術、自動化、および費用抑制に関する最新情報に触れることができるからです。技術的なスキルおよびソリューションを適切に応用することにより、品質、費用効果、および IT サービスの有効性が高まるため、テクノロジの最新情報に精通していることは、顧客満足度と顧客関係管理を後押しするうえでも有益です。
高度な技術を持った生産性の高い従業員を惹きつけ保持するという問題に対応しようと、IT 業界向けに多くの "スタッフ保持フレームワーク" が公表されてきました。優秀な IT スタッフの維持に役立つ再利用可能なベスト プラクティスとしては次のようなものが挙げられます。
最も有用な従業員には高レベルの自主管理と独立性を与える。
個人およびグループの仕事が全体にとって価値あるものであるという気分を高めるために、ビジネスの運営のあり方や変化の方向について継続的に知らせていく。企業の方向性およびリーダーの構想への信頼は、多くの個人にとって会社に留まろうという意思決定に大きな影響を与える。
IT および業務グループの双方において、経営陣との良好な労働関係を促進しサポートする。
従業員が去っていったときだけ問題に対処するのではなく、重要な従業員を保持するということを管理の最優先課題とする。
金銭面およびそれ以外の面において、魅力のある報奨制度を提供する。あらゆる年齢層にとって、休暇、特に長期休暇の魅力が増大し、これを求める傾向にあります。
技術面でも個人的な成長という意味でも、昇進の機会を提供する。技術スタッフに対し、明確でわかりやすい成長経路を示します (単に管理職を目指すということではありません)。
在宅勤務や電子会議を含め、仮想チームの新しく柔軟で独創的な働き方をサポートする。
具体的かつよく検討された方法で、労働と実生活のバランスを組織面および管理面からサポートする。
チームの役割クラスタの説明
概要
ここではチーム モデルの 6 つの役割について説明しますが、これらは、必要な数々の中核業務を抽象化して "役割クラスタ" として整理したものとご理解ください。ここで説明する役割クラスタは、特定の組織構造や職種を規定したり、提案したりするものではありません。実際の編成は、組織やチームの状況に大きく依存します。グループの規模、システムの適用範囲と境界、地理的要因、チームのリソース状況、各スタッフの専門領域と経験などによって、IT 組織の編成は変わります。
チーム モデルのこの 6 つの役割クラスタは、業務とプロセスを一般的なカテゴリに分類し、役割と責任範囲を共通の枠組みで洗い出し、運用管理を成功に導くために各専門職能チームに求められる共通の目標を定めるものです。各役割クラスタの呼称は、Microsoft 社内のグループ、顧客、パートナーの経験や提案に基づいたもので、ITIL が示すプロセス所有の概念とも整合しています。機能遂行チームとは、MSF の定義では、役割の中に存在するチームのことをいいます。チームやプロジェクトが大きくなったときには、役割に所属する人材をその職能に応じてグループ化する必要があり、ここに機能遂行チームという考え方が生まれます。機能遂行チームの例としては、運用役割クラスタの "データベース管理チーム" を挙げることができます。
繰り返しになりますが、役割とは、特定の職種や組織構造を表すものではありません。運用管理グループは、大企業、中小企業、教育機関、電子ビジネス、ホスティングおよびアプリケーション サービスを提供するサービス プロバイダなど、さまざまな組織の中に存在します。しかし、いずれの組織においても、運用上の役割について共通の枠組みが求められることに違いはありません。当然のことながら、求められる運用業務の内容はビジネスによって異なります。共通の要件事項と組織固有の要件事項の両方を満たすには、IT サービスの管理部門は、既存の職責や決められた業務内容にとらわれることなく、求められる役割と責任範囲に対応し、適応できなければなりません。
それぞれの役割に携わるスタッフの数はさまざまです。小規模の運用管理部門であれば、1 人のスタッフが複数の役割を担当しなければ業務を遂行できないでしょう。しかし、大規模な IT 部門であれば、1 つの職責や作業に対して機能チーム全体を割り当てる場合もあるでしょう。チームの役割の組み合わせの推奨例については、後のセクションを参照してください。
企業が、仮想企業や日常の運用サポートを行う多くのパートナーに依存する地理的に分散したチームに発展すると、運用チームの機能的な役割には、可用性管理や変更管理などに対応する専門のプロセス所有者が含まれることになります。これは、ITIL に説明のある専門のプロセス所有者という概念を取り入れると同時に、その概念を戦略的なテクノロジ固有の機能チームと結び付ける方法でもあります。プロセスと機能の組み合わせの結果、仮想のプロセス チーム、つまり、作業を共同で行う内部および外部のリソース プールからの要員で構成されるグループが編成されます。
図 3 は、主要な機能役割、機能遂行チームと、これらが運用フレームワークのチームの役割クラスタとどのように関係するかを示したものです。なお、この図は、サービス管理部門の中に存在する多数の機能役割、機能遂行チームのうち、その一部を示しているに過ぎません。
.gif "図 3: MOF チーム モデルと職責または職能チームの例")
図 3: MOF チーム モデルと職責または職能チームの例
以下のセクションでは、MOF チームの役割について取り上げます。担当する業務、求められるスキル、他の役割や MOF プロセス モデルのサービス管理の機能との関係について詳しく説明します。
リリースの役割クラスタ
概要
MOF チーム モデルにおけるリリースの役割クラスタは、MSF チーム モデルのリリース マネージャ役割と交差する位置にあります。開発またはテストの段階から本番運用環境への移行はこの地点で行われ、本番運用への遅滞ない移行を実現するための重要なポイントになります。リリースの役割は、プロジェクト開発チームと運用グループを連結する役割を担います。また、ITIL の主要領域のうち、構成管理、およびソフトウェア管理と配布の 2 つの領域をカバーします。
本番運用にリリースした後 (MOF プロセス モデルの "変更" の領域に相当)、リリース役割は、以下の業務を担当します。
システムとその環境について、継続的に構成を把握し、変更を管理し、ステータスを報告する。
バージョンの管理、ソフトウェアの配布、ライセンスの追跡管理、使用状況の監視、廃棄情報の管理を含め、資産を管理する。
ハードウェア、ソフトウェア、その他の物理的資産のインベントリを CMDB として保守管理する。
リリースの役割クラスタは、インベントリ管理と資産価値管理の両方について責任を負います。厳格に CMDB を管理することによって、CMDB の各構成項目 (CI) を含めて、任意のベースラインにおけるすべてのシステムの識別と適用範囲を把握できるだけでなく、IT インフラストラクチャの状態をまとめた管理報告書も作成できます。
(ITIL に定められている) CMDB は、単なるインベントリや資産のリストではありません。システム相互の依存関係や、システムとユーザーの関係までを包含するものであり、変更要因や依存関係の追跡管理に役立てることができなくてはなりません。Microsoftｮ Systems Management Server などのツールを導入すれば、ネットワークに接続されたデバイスを自動的に検出できます。しかし、ネットワークに接続されていないデバイスもインベントリに間違いなく含まれるようにするには、すべての資産を定期的に調査する必要があります。このベースライン インベントリ レビューを実施する頻度は、記録された CI の範囲や環境変更の度合いに大きく依存します。
インストールのスクリプト化、移行の自動化ツールの導入は、組織の規模を問わず推奨しますが、大規模組織の場合は必須と考えていいでしょう。
リリースの役割は、リリース プロセスの改善と最適化の方法を常に模索し、安全で復旧が可能な、できる限りの自動化を施したリリースを実現します。たとえば、大企業の IT 部門であれば、本番運用への移行を管理し、ベスト プラクティスを取り入れる方法として、専属の "リリース サービス アナリスト" を採用することが考えられます。リリース サービス アナリストとは、リリースの役割の中に位置付けられ、同じ適用範囲と機能を実現する複数のプロジェクトを同時に担当します。特に、製品またはシステムを本番運用に移行させるために必要な作業を網羅した詳細なリリース プランの策定に責任を負います。リリース サービス アナリストの責務は、スケジュールどおりに円滑にリリースを実施することにあります。これは特化した専門能力となり、このノウハウはさまざまなシステムに活かすことができます。
業務内容
リリースの役割クラスタが担当する主要業務は、以下のとおりです。
開発またはテスト環境から本番運用への移行を管理する。
展開に伴う作業と手続きを整理し、繰り返し実施する作業項目についてポリシーを策定する。
構成管理のプロセス、記録、ツール、ドキュメントを管理する。
ツールやスクリプトの導入を通じてリリースおよび構成の徹底した自動化を図る。
プロジェクト開発チームと運用グループをつなぐ連結部分として機能する (MSF のリリース マネージャの役割と交差する役割)。
リリース準備の判断とリリースの可否基準を主導的に取りまとめる。
ハードウェア、ソフトウェアの変更を追跡管理、監査、報告する。
構成を管理する (CMDB を所有する)。
ソフトウェアのライセンスと配布を管理し、DSL (Definitive Software Library) を管理する。
リリース業務に伴うツールの選定、規定を管理する。
スキル
リリースの役割クラスタに求められる主要スキルは、次のとおりです。
あらゆるハードウェア コンポーネントについて知識を有している。
既製ソフトウェアのライブラリを管理し、安全な場所に保管し、監督できる。
盗難の可能性が高いハードウェア アイテム (メモリ、デジタル カメラ、Jaｚz ドライブなど) を保守管理し、盗難を防ぎ、安全な場所に保管できる。
ハードウェア互換性リストを用いて購買判断を支援できる。
情報サービス (IS) の監査手続きと標準規則を策定し、実行に移すことができる。
コンピュータ ハードウェアとソフトウェアの基本的な修復、設置とインストール、物理的なインベントリの管理ができる。
ソフトウェアのライセンス情報と利用状況を管理できる。
資産管理支援ツールを評価できる。
インフラストラクチャの役割クラスタ
概要
インフラストラクチャの役割クラスタは、知識、人、プロセス、テクノロジ、空間、パートナー、顧客をさまざまな形で結び付ける役割を担います。インフラストラクチャの役割は、進化し続けるエンタープライズ アーキテクチャをフォローすると同時に、ネットワーク、通信、ハードウェア、ソフトウェアの各観点から、ビジネス運営上の変化し続ける要件事項に対応する準備を整えなくてはなりません。この役割クラスタのこの責務を指して "インフラストラクチャ エンジニアリング" と呼ぶこともあります。
長期的な計画策定で重要となるのは、エンタープライズ リソースのキャパシティ管理です。アプリケーションの基盤となるビルディング ブロックの選定と管理も、インフラストラクチャの役割の重要な役割です。システム サービスはこの基盤の上で実行します。ビルディング ブロックの例としては、システム レベル ソフトウェア、Microsoft Systems Management Server に代表されるシステム管理ソフトウェア、ネットワーク管理ソフトウェア、ミドルウェア、セキュリティ ソフトウェアなどが挙げられます。
また、インフラストラクチャの役割の責任範囲としては、顧客データ、商品データなど広く共有されるデータの管理、(データ センタ、フィールド オフィス、リモート オフィス、テスト ラボ、開発ラボなどの) スペースとストレージの設計、インフラストラクチャのサポートに必要なツールの管理も含まれます。標準のディスク イメージ、承認済みビルドの CD、物理的なビルドの複製、データ センタのサーバーの物理的な配置とこれらの管理はすべて、インフラストラクチャの役割が共通して担当する業務です。
ビルやオフィスの移動、ビジネスの拡張、買収、物理的環境の変化などがあったときは、不動産および施設管理部門と緊密に連携しながら、すべての IT 上の要件事項に対処し、文書化します。配線、ラボのスペース確保、データ センタの設備、ユーザーのコンピュータの社内ネットワークへの接続などにも対処しなければなりません。
大企業の場合、インフラストラクチャの役割は、IT に関連するポリシー、手続き、方法論の策定と管理のほか、デスクトップ ハードウェア、サーバー ハードウェア、分散コンピューティングの接続構成、在宅勤務用の環境、コスト管理の手法などについて標準ルールを策定し、管理することが求められることも珍しくありません。"仮想企業" の概念が一般化するにつれ、"いつでもどこでも" 仕事ができる環境が求められていますが、これに伴うさまざまなオプションについても、技術的な理解と支援が欠かせません。
IT サービスのコストの管理は複雑で、誤解も少なくありませんが、コストの計算、追跡管理、報告の方法を規定する専属のグループを設け、この情報に基づいて計画と予算作成を実施することにより、コスト管理に伴う問題を大幅に緩和できます。
インフラストラクチャの役割はサポートの役割クラスタと運用の役割クラスタと緊密に連携することによって、インフラストラクチャ開発の効率化と展開の合理化を推し進めることができます。この協力体制によって、サポートの役割と運用の役割は、インフラストラクチャ ソリューションの円滑な運用に欠かせない堅牢なプロセスを築き上げることができます。
業務内容
インフラストラクチャの役割クラスタが担当する主要業務は、以下のとおりです。
IT インフラストラクチャを設計、管理し、変化の激しい業務要件に対応する。
リモート アクセス テクノロジ、コラボレーション テクノロジについて調査研究し、提案をまとめる。
一貫したインフラストラクチャの管理、手法、標準化のためのポリシーと手続きを策定し、文書化する。
IT インフラストラクチャ (コンピュータ、ネットワーク、機器) の運用とサポートに関する戦略をまとめる。
物理的環境の使用状況を調整し、データ センタ、ラボ、フィールド オフィスなど、地理的に分散した環境を設計する。
インフラストラクチャ エンジニアリング、ラボ、IT 施設を管理する。
システムおよびサービスのキャパシティを予測し、管理する。
インフラストラクチャ サービスの可用性を監視する。
コストを管理し、IT インフラストラクチャに伴う支出と配分を整理して予算化する。
サーバーのビルド、標準のディスク イメージ、ソフトウェアのインストールを管理する。
規定のコスト管理と課金管理のポリシーに基づき、コストと課金のレポートを管理職および顧客に提出する。
スキル
インフラストラクチャの役割クラスタに求められる主要スキルは、次のとおりです。
インフラストラクチャ ソリューションの設計、選定、調達にあたって、他の IT グループのニーズに応えるサービスを提供できる。
分散コンピューティング テクノロジ、リモート コンピューティング テクノロジについて精通している。
SNMP (Simple Network Management Protocol)、ネットワーク トラフィック分析を含め、ネットワーク管理について理解がある。
名前付けの標準と要件事項を理解している。
サイトとキャパシティ設計の見積もりと手法について理解がある。
マルチプラットフォームのサイト アーキテクチャとエンジニアリングを設計、サポートできる。
インフラストラクチャ ツールとサード パーティの管理システムについて広く深く理解し、選定とサポートができる。
サポートの役割クラスタ
概要
MOF のサポートの役割クラスタは、サービス デスクおよび障害と問題事項の管理を担当します。サポートは、企業の IT サービスの内部ユーザー (従業員) にとって重要なだけでなく、企業の製品やサービスの顧客となる外部ユーザーにとっても重要です。後者の場合は、一般的に、製品サポート、テクニカル サポートと呼ばれます。サービス デスクとは、ユーザー コミュニティと直接的に対話する窓口であり、顧客は企業の IT レベルをサービス デスクから判断する傾向があります。
サポートの役割クラスタの最重要課題は、タイムリーに、効率よく、的確にカスタマ サポートを提供することです。サービス デスクの人員配置にあたっては、ピーク時と閑散時の両方において、サポート スタッフの人数とサポートの需要量が比例するように計画します。サービス デスクのチームを効率よく運営することでサポート コストを低減できると同時に、障害に迅速に対応でき、サービス レベル契約で規定されたサービス水準の達成につながります。
支援ツールが導入されていれば、サポート スタッフは、問題の重要度とビジネスに与える影響の大きさに基づいて、対応作業の優先順位を付けることができます。また、サポート支援ツールにより、対応のスピードや、特定の問題についての障害件数など、サポートの成否の判断基準となる統計数字も得ることができます。すべての障害は最終的には問題別に分類し、該当する製品領域の問題解決チームが障害の根本原因を突き止めることになります。
ITIL に規定されているように、サービス デスクは、問題の根幹原因の分析の責任を負うものではなく、あくまで障害管理までがその責任範囲です。サポートの役割クラスタのチーム編成にもよりますが、問題として認識された障害の取り扱いは、サポート グループ内の決められたエスカレーション担当者が行います。
統計によれば、サービス デスクへの問い合わせのうち、"どうすればいいですか" という質問が 50% 以上を占めます。つまり、製品の操作方法や、マニュアルの記載ページを問う質問がほとんどです。
サービス デスクの業務を合理化するうえで最も効果的な方法は、ユーザーが自分で検索できる情報レポジトリを作成しておくことです。音声自動応答による FAQ (よくある質問とその回答) 集を作成しておくか、サービス デスクに問い合わせが多い質問とその回答集を Web サイトにまとめておくという方法が考えられます。このような情報源があれば、ユーザーはサービス デスクに電話することなく、自分で問題を解決でき、時間とお金を節約できるのみならず、顧客満足度を高め、ユーザーの知識を高めることにもつながります。
サービス デスクにかかってきた電話の内容については、対応するユーザー教育部門に定期的にフィードバックすることによって、サービス デスクでの障害件数が多い領域の情報をユーザー教育部門がタイムリーに把握できるようになります。
Microsoft 社の IT グループでは、"標準デスクトップ" を採用しています。標準デスクトップとは、オペレーティング システム、Office アプリケーション スイート、ウィルス対策ソフトウェアを標準化したもので、配布と更新を自動化しています。標準デスクトップの採用により、従業員の生産性を向上させ、ダウンタイムを軽減できます。サービス デスクは無数の製品に対応する必要がなく、サポートの品質向上にも貢献します。
アプリケーション固有の、またはサービス固有のサポート チーム ("本番稼動サポート") は、問題管理のエスカレーション チェーンにおいて 2 番目の階層に位置付けられます。ビジネス ユニットが専属の IT スタッフを抱える場合、そのビジネス ユニットの業務サポートは本番稼動サポート チームが担います。本番稼動サポート チームは、システムのみならず、業務についても深い知識を有します。このグループは、サービス デスクから報告された障害に対応します。障害の内容により、本番稼動サポートが直接的に解決することもあれば、データベース運用担当者やネットワーク運用担当者などの個別の運用チームと連携して迅速な問題の解決に当たることもあります。
問題管理の責任はサポートの役割が負うべきです。問題分析の役割を専属で設け、問題事項の追跡管理とフォローアップの責任を持たせることができれば理想的です。問題分析担当者は、問題の根本原因を該当するグループに解決させることもその役割の 1 つです。大企業の IT 部門や、アプリケーション ホスティング プロバイダなど、サービス レベルの維持がビジネスにとって不可欠な要素の場合、サービス レベル マネージャの役割を専属で配置できれば、大きな資産となります。ITIL では、サービス レベル マネージャをサービス レベル管理のプロセス所有者として規定しています。小規模な IT グループの場合であれば、サービス レベルの管理者を専属で配置することは現実的ではないでしょう。そのため、サービス レベルの管理プロセスは、必然としてサポート グループの主要職責の 1 つとなります。
必要性が認められれば、サービス レベル マネージャは、IT サービス プロバイダの能力について改善規定を定め、サービス レベル契約 (SLA) に定められたサービス レベルが順守されているかを監視します。これにより、顧客への高品質かつ迅速なサポートと、SLA の定める目標を犠牲にすることのないコスト管理が行われるようにします。
また、サポートの役割クラスタは、ビジネス ユニットの基幹システムのキャパシティ設計についても責任を負います。また、インフラストラクチャの役割と連携して、ビジネス ユニットのキャパシティと拡張計画が企業全体のキャパシティ設計プロセスと整合するようにします。
サポート プロフェッショナルの主要業界団体として、HDI (Help Desk Institute) があります。HDI は、その会員と会員を支援するベンダなど、内外のサポート組織が抱えるニーズに対応しています。ITIL は、HDI の協賛会員でもあります。
HDI の使命は、標準を策定し、認定制度とトレーニング プログラムを確立し、業界の各種情報を提供し、会員どうしの協業を促進することにあります。HDI の目的は、カスタマ サポート プロフェッショナルの啓蒙活動を世界的に展開することです。サービス デスクとカスタマ サポートの業界に特化したテクノロジ、ツールの情報、動向を提供するほか、個人とサポート組織の両方に向けたトレーニング プログラムと認定プログラムを提供しています。HDI の連絡先については、この資料の最後のリファレンスを参照してください。
業務内容
サポートの役割クラスタが担当する主要業務は、以下のとおりです。
IT ユーザー コミュニティの主たる窓口となり、カスタマ サービスを提供する。
顧客とのサービス レベル契約を管理し、合意した水準を常に満たすことによって、ビジネスを支援する。
高度な支援ツールとナレッジベース システムを活用して、効率よく障害と問題を解決する。
ユーザーからの要求と登録された障害に迅速に対応する。
基幹アプリケーションとサービスに対して本番稼動サポートを提供する。
管理レポートを作成し、サポート業務の各種指標と併せて提出する。
開発チーム、設計チームにフィードバックを提供する。
さまざまなグループに対して問題管理プロセスのサポートを提供する。
フェールオーバーと回復に関する対策を講じる。
スキル
サポートの役割クラスタに求められる主要スキルは、次のとおりです。
最新の IT 環境を理解できる。
サーバーとコンピュータの診断技術を理解できる。
優れた問題解決スキルを有する。
コンピュータ、サーバーのハードウェアとアーキテクチャに精通し、導入されているオペレーティング システムについて理解できる。
カスタム アプリケーションと市販のアプリケーションの両方について理解できる。
さまざまなデスクトップ構成と全社的に採用されている標準事項について理解できる。
使用しているネットワーク環境について理解できる。
サポートの傾向を把握できる (3 時間の間に同じ問題に対して 10 人が問い合わせを行ったなど)。
ユーザーのリモート ラップトップやその他のハンドヘルド デバイスに関するニーズを理解し、これに対応できる。
ベンダが提供する各種のカスタマ サポート支援ツールを評価できる。
問題事項管理システム、問い合わせ事項管理システムを管理でき、使用できる。
サポート対象のシステム、基幹サービス、テクノロジについて技術的に精通している。
運用の役割クラスタ
概要
運用の役割クラスタは、テクノロジ分野および、日々のビジネスを運営するうえで不可欠な本番運用システムの関連業務を重点的に担当する専門家で構成されます。大企業の運用役割では、メッセージング、システム管理、通信、ネットワーク、データベース管理など、それぞれの領域に特化した専門家を配置することになります。それぞれの専門技能では、テクノロジとサポート プロセスを効果的に実装し、サポートするための経験と知識が求められます。さらに、継続的にトレーニングを受け、最新の資格を取得することも欠かせません。システムの実装、保守、サポートを合理化し、自動化し、コストを抑えるためには、最新のテクノロジとツールに関する知識が必要となるためです。
運用の役割は、日々の運用業務とシステム管理業務を担当し、企業全体の IT サービスとアプリケーションを運営し、保守する役割を担います。また、データのバックアップ、保管、出力管理、システムの監視、イベント ログ管理、プリント サーバー、ファイル サーバーの管理など、定期的に実行するルーチン ワークも行います。
運用の役割はさまざまな機能グループと連携して、顧客の SLA に応えるため運用面の職責を確実に果たすことを期待されます。
業界のアナリスト アドバイザの報告によると、IT スタッフのポジションのうち、運用役割が新規採用と人員確保の最も難しい職種とされています。特に、システム管理、ネットワーク管理、データベース管理の職種でこの傾向が顕著に見られます。1990 年代後半まで、Web 開発や電子商取引開発と比べて、運用の役割は "魅力的" な職種とは考えられていませんでしたが、インターネットが成熟するにつれ、以前は最新のテクノロジだったものが一般的な存在となり、結果として有能なスタッフの新規採用も比較的に容易となりました。
電子商取引の普及により、高い可用性と信頼性でシステムを稼動させ続けることの重要性と、システム稼動状態の可視性が高まりました。多くの IT サービス管理部門にとって、運用関連の職種は中核的位置付けを占めるようになりました。Microsoft Windowsｮ 2000 のシステム管理など、特定のテクノロジに長けているだけでなく、組織管理、プロジェクト管理、コミュニケーションについても高いスキルを有していることが求められています。
運用管理グループは、技術的な手順や標準プロセスに関する大量のドキュメントを作成し、管理しなければなりません。具体的には、Windows 2000 の運用ガイドから、データベース復旧時の詳細なエスカレーション手順までがこれに含まれます。また、運用スタッフには、業務の一環として明確な技術資料を作成できるスキルが求められます。
業務内容
運用の役割クラスタが担当する主要業務は、以下のとおりです。
アカウントとシステム セットアップ構成を管理する。
メッセージング、データベース、通信の運用を管理する。
主要なパフォーマンス指標と基準を作成する。
ネットワークの運用とディレクトリ サービスを管理する。
システム管理を統括する。
ユーザー アカウントとアクセス許可を設定し、管理する。
バッチ処理を実行する。
ファイアウォールを管理する。
アプリケーション サービスを提供する。
ホスト統合サービスを提供する。
ディレクトリ サービスの運用を管理する。
イントラネット ホスティング サービスの運用を管理する。
デスクトップ サービスを実行する。
電子データ交換 (EDI) など、B2B 用のインターフェイスを管理する。
セキュリティ管理を担当する。
スキル
運用の役割クラスタに求められる主要スキルは、次のとおりです。
通信、広域ネットワーク (WAN)、ローカル エリア ネットワーク (LAN)、無線、ワイヤレスなど、企業を支えるネットワークを監督、監視、構成、保守できる。
サーバー ハードウェアおよびネットワーク オペレーティング システムに関する専門技能を有している。
デスクトップ オペレーティング システムに精通している。
運用上の手続き、ポリシー、優先順位を定義できる。
帯域幅の使用状況の監視、トラフィックのパターンと量の分析、問題事項が及ぼす影響の判断ができる。
複雑なサーバーとネットワークの構成作業や変更作業を実施できる。
ウイルスとその影響について理解し、適切な防護措置をとれる。
無線周波数、ワイヤレス アプリケーションを含む、音声およびデータ ネットワークに関する知識と経験を有している。
インターネットおよびイントラネットの各種テクノロジに精通している。
マルチベンダ、マルチプロトコルのネットワークの実装について専門技能を有している。
ネットワークおよびオペレーティング システムのセキュリティについて理解がある。
バックアップと復元の方法論、およびその関連テクノロジについて理解がある。
エンド ユーザー レベルと企業レベルそれぞれの業務目標を理解している。
一連のシステム ドキュメントを保守管理できる。
エンド ユーザーから報告された問題の解決にあたって、ヘルプ デスクと協力できる。
IT インフラストラクチャの運用、システムのシャットダウン、起動ができる。
データベースのインストール、起動、シャットダウンの作業を支援できる。
システムのパフォーマンスを監視し、最適化でき、異常を発見できる。
バッチ ファイルやスクリプトを作成して管理業務の効率化に貢献できる。
オペレーティング システムやサード パーティのツールが提供するスケジューリング機能について理解がある。
必要に応じて、プリンタ、スキャナ、RAID (Redundant Array of Independent Disks) ストレージ、CD-ROM タワー、光学式ストレージ ジュークボックスなどを管理できる。
セキュリティの役割クラスタ
概要
セキュリティの役割クラスタは、IT にかかわるほとんどすべての領域で重要な役割を担います。電子商取引では、特に重要な位置付けを占めます。セキュリティ基盤が弱い情報システムは、セキュリティ侵害を受ける原因になります。情報システムの構造やセキュリティ侵害の程度によっては、データの損失、利益の損失、人的傷害に至ることさえあります。セキュリティの役割クラスタとは、すべてのアクティビティにおいてリスク管理を積極的に実施すると言えるでしょう。
セキュリティの役割クラスタの主要な目標は、次のとおりです。
デー タの機密性の保証 承認された人物だけがデータを閲覧できるようにします。
データの整合性の保証 提供されるデータが正確であり、不正に変更されていないことを承認されたユーザーに対して保証します。
データの可用性の保証 承認されたユーザーが必要なときに必要なデータにアクセスできるようにします。
セキュリティは、6 つの要件に分けることができます。この要件は、原則と言い換えてもいいでしょう。どれも等しく重要ですが、実装は決して容易ではありません。この 6 つのセキュリティ原則を組み合わせることによって、データの機密性、整合性、可用性を保証する基盤となります。6 つのセキュリティ原則とは、以下のとおりです。
識別 ユーザーの名前、およびユーザーが身元をどのようにしてシステムに提示するかを処理します。
認証 パスワード、スマート カード、バイオメトリックスなどを処理します。認証は、ユーザーがシステムに対して自分の身元を証明するための方法です。
アクセス制御 "承認" とも呼びます。ユーザーに与えられたアクセス許可と特権を処理し、ユーザーがシステムに対して特定の機能だけを実行できるようにします。
機密性の維持 暗号化を処理します。機密性のメカニズムにより、格納されているデータの参照やネットワーク上の移動は、認定されたユーザーによってのみ行われることが保証されます。
整合性 チェックサムとデジタル署名を処理します。整合性チェックのメカニズムにより、ネットワーク上で移動するデータの破損、消失、または変更が発生していないことが保証されます。
否認不能性 デジタル署名を処理します。否認不能性は、トランザクションの発生が後から否定されないように、データが伝送または受信されたことを証明する手段です。
この役割のセキュリティ スペシャリストは、企業ネットワークの保護に伴う技術的な複雑さに対処するのみならず、業務上のポリシーや手順の策定にもかかわらなければなりません。具体的には、電子メール、リモート アクセスの使用状況、企業の機密に属する財務データ、人的資源データのほか、従業員の自宅電話番号リストなど個別の機密情報の管理までが業務範囲に含まれます。
情報セキュリティ アーキテクチャは、企業のビジネス プロセス、ポリシーの内容、プラットフォーム固有のセキュリティ対策手法のギャップを埋める役割を担います。ビジネス プロセスにおけるセキュリティの役割の例としては、退社する従業員の退出手順の策定と執行が挙げられます。知的財産をビジネスとする企業であれば、追跡管理は困難を極めますが、リスクも特に高く、管理の必要性が強く求められます。
セキュリティの役割は、全社的な IT アクティビティと部門レベルの IT アクティビティの両方にかかわります。また、インフラストラクチャの役割と協力して、サードパーティの不正侵入検出システムなど、セキュリティ関連のシステムや自動化ツールを評価することも重要な役割の 1 つです。
IT セキュリティの役割のもう 1 つの職責として、データの監査、保持、分類、完全破棄の包括的な手順を策定することがあります。法務資料、財務資料、記録資料は、法律、業界、企業が定める一定期間の間、安全性が確保された状態で保管しなければなりません。また、高価なストレージを節約するためにも、重要でないデータは定期的に破棄しなければなりません。ここでは、運用役割による効率的なバックアップとデータ取得のプロセスの策定が欠かせません。データに関連しては、物理的なセキュリティを確保することも重要です。電話回線、データ通信回線、各種資産に対する物理的なアクセス経路のほか、ビジネス パートナー、ジョイント ベンチャー、買収先企業への接続経路のセキュリティも忘れることはできません。物理的なセキュリティに脆弱な点があると、外部からの侵入を招きやすくなります。
業務内容
セキュリティの役割クラスタが担当する主要業務は、以下のとおりです。
IT リソースが正しく運用されているかどうかの監視作業を支援する。
不正侵入を検知し、ウイルス対策を施す。
サービス拒否 (DOS) 攻撃への対策を施す。
データの保持と安全なデータ廃棄にかかわるポリシーを策定する。
監査を実施し、レポートを作成する。
効果的なネットワーク ドメイン セキュリティの設計と管理を行う。
戦略的なセキュリティ テクノロジをテストし、実装する。
ネットワークの脆弱性を監視し、査定する。
ネットワークへの不正侵入に対して迅速、リアルタイムに対応する。
公開キー基盤 (PKI) テクノロジの要件事項を管理する。
インターネット プロトコル (IP) のセキュリティ要件を管理する。
認証とアクセス方法に関する要件事項を管理する。
パスワード ポリシーなど、ユーザー ポリシーの使用状況と要件事項を管理する。
対外的なセキュリティ要件および、コンピュータ ルームへの入室方法などの物理的なセキュリティ要件を管理する。
メッセージングのセキュリティ要件を管理する。
社内のセキュリティ イニシアチブについてテクニカル サポートと専門家の立場からの支援を提供する。
スキル
セキュリティの役割クラスタに求められる主要スキルは、次のとおりです。
セキュリティ ポリシーについて理解があり、その完全性について評価できる。
さまざまな業務領域と各業務領域で取り扱っているデータについて理解があり、これをセキュリティ強化に役立てることができる。
さまざまなサーバーに共有領域をセットアップできる。
企業の採用しているプラットフォームのセキュリティ モデルに精通している。
ネットワークに関する深い知識がある。
ウイルスとウイルス対策の方法論について理解がある。
セキュリティに関する問題と生産性に関する問題のバランスをとり、セキュリティ ポリシーの適用によっていずれかが犠牲になることを回避できる。
ユーザー グループごとに、異なるセキュリティ プロファイルをセットアップできる。
セキュリティ上の手続きについて、従業員を教育し、啓蒙できる。
セキュリティ上の問題が生じたときに、他の IT グループと共同作業ができる。
認証や暗号化など、データやファイルのセキュリティ保護の方法に理解があり、これを強化する製品について知識がある。
セキュリティ ソリューションを提供するベンダと協力し、製品の機能内容を評価できる。
従業員の退職など、セキュリティ上のリスクを監視し、セキュリティの確保に貢献できる。
セキュリティ監査を実施できる。
パートナーの役割クラスタ
概要
パートナーの役割クラスタには、さまざまな IT パートナー、サービス提供者、アウトソース ベンダが含まれ、これらは IT スタッフの仮想メンバとして活動し、ハードウェア、ソフトウェア、ネットワーク、ホスティング、およびサポートに関連するサービスを提供します。IT 組織がパートナーのサービスを利用する度合いは、企業の規模、所在地、業種、および戦略目標の違いにより、企業ごとに大きく異なります。電子ビジネスの進化を考えると、外部のパートナー企業は、テクノロジの所有者であり、重要なサプライヤであるといえます。たとえば、インターネットによる電子ビジネスを展開する企業は、電子商取引サイトの構築と運営に重点を置き、カスタマ サービス、製品受注処理、ハードウェア サポートなどの機能をアウトソースしています。
MOF チーム モデルにおけるパートナーの役割クラスタは、サービスの提供に欠かせない外部企業とのパートナーシップを表します。パートナーとの関係の実際の形態や性質は、さまざまな可能性が考えられます。しかし、効率的な運用チーム構造を考えるときに、パートナーの重要性はどれだけ強調しても足りません。パートナーとの関係管理のあるべき姿は、パートナーの種類や提供するサービスの内容によって大きく異なります。ここでは説明を簡単にするため、社内の "リレーションシップ マネージャ" のことを "パートナー アカウント マネージャ" と呼ぶことにします。
ベンダ、サプライヤ、アウトソース企業、その他のサード パーティ プロバイダから良質のサービスを受け、これを管理するためには、サービス レベル契約が重要な役割を果たします。パートナー アカウント マネージャは、サービス レベル契約の条項を作成し、コストを定め、契約の履行のためにパートナー プロバイダと顧客の両方が協力できるよう運用面の細部を継続的に管理することを担当します。
保守契約は、サード パーティの継続的なサービス レベルの代表例といえます。たとえば、Microsoft 社では、社内の IT ヘルプ デスク業務を、サービス デスク機能とヘルプ デスク スタッフの管理を主な業務とする企業にアウトソースしています。Microsoft の IT グループの従業員 1 人がアカウント マネージャとなって、ヘルプ デスク ベンダとの関係管理を担当し、サービス レベルを評価すると同時に、ヘルプ デスクの運営コストとのバランスをとりながら社内のエンド ユーザーに提供されるサービスの質を向上させるために必要な改善措置をとっていきます。
ナレッジ管理ツールも、パートナーやサプライヤの役割を管理するうえで重要な役割を占めるようになりました。電子ビジネスと仮想企業があらゆる規模の企業で存在感を増すようになり、オンラインによる通信とコラボレーションのツールがビジネスの成功の鍵を握るようになりました。Microsoft NetMeetingｮ と MSNｮ Messenger Service のテクノロジは、パートナーシップを強化し、仮想チームのコミュニケーション プロセスを強化するツールの一例です。アナリストのレポートによれば、コラボレーション ツールはまだ比較的初期段階にあるものの、ワークフローの改善、コストの削減、問題解決やブレインストーミングの効率化に既に貢献しているという報告もあります。
業務内容
パートナーの役割クラスタが担当する主要業務は、以下のとおりです。
ホスティング、ネットワーク、サポート、IT 保守などのサービスを提供する IT ベンダ、アウトソース パートナーのアカウント管理、関係管理を担当する。
サービス レベル契約など、プロバイダと顧客間の契約を管理し、役割と責任範囲を明確にする。
プロバイダと顧客間のインターフェイスに関するプロセスと手続きを確立する。
サプライヤとの SLA を作成し、管理する。
サード パーティの選択肢を評価検討する。
プロバイダ サービスの有効性を監視する。
パートナーシップの維持にかかるコストを交渉し、管理する。
IT 関連の調達と購買を管理する。
パートナーやサービス サプライヤが提供する業務内容は、提供する商品やサービスの性質によって大きく異なります。
チーム モデルの規模
小規模組織の場合の役割の組み合わせ
次の表は、さまざまな役割の組み合わせを示しています。不適切な組み合わせは、"N (No)" または "U (Unlikely)" で示し、相乗効果がある組み合わせは、"P (Possible)" で示しています。チーム編成を考えるときは、実際のメンバ構成、各メンバの経験、スキルによって、効果的な役割の組み合わせは変わってきます。
.gif "図 4: 成功する役割の組み合わせ")
図 4: 成功する役割の組み合わせ
行と列の交差する所に "N (No)" とある役割の組み合わせは、利害が一致しないため、推奨しない組み合わせです。"U (Unlikely)" で交差する組み合わせは、双方の役割で求められるスキルが大きく異なるため、現実的でない組み合わせを意味します。"P (Possible)" で交差する組み合わせは、利害が一致するため、可能な役割の組み合わせを表します。
当然のことながら、これは絶対的な基準ではありません。この表で不適切な組み合わせとあっても、組織によっては役割の共有に成功している場合もあります。ここでのポイントは、役割を組み合わせる場合は、それぞれの役割の目標と役割を常に念頭に置き、複数の役割を担当するチーム メンバ内で矛盾する要素をできる限り排除することが重要だということです。この点を軽視すると、重要な品質目標の一部が見落とされたり、何らかの形でリスクへの対応が誤って処理されたりする可能性が生じます。
コミュニケーションの重要性
MOF チーム モデル、およびすべてのフレームワーク モデルにおいて、コミュニケーションは中心的な役割を果たします。効果的なコミュニケーションの重要性を説く教材は数多く書かれ、特定の業界を対象にしたものもあります。IT 運用チームの合理化、効率化を考えるうえでも欠くことのできない要素です。
効果的で、正確、かつ時宜を得たコミュニケーションは、すべての役割において重要ですが、とりわけサポートの役割ではきわめて重要です。サポート役割の主な職責は、良質なサービスを顧客に提供することにあり、これには意思を明確に伝達できるコミュニケーション能力が強く求められます。
技術情報、手順情報を顧客に伝えることができるほか、サポート担当者に求められる重要な素質としては、常識でもありますが、対人関係の能力とカスタマ サービスのスキルを挙げることができます。IT とサービスについて顧客が受ける印象は、問題や障害が無事に解決できたかどうかや、費やされた時間だけでなく、ヘルプ デスクとのかかわりの中で得た体験からも大きな影響を受けます。ヘルプ デスク スタッフの態度、親切さ、全般的な好感度も重要な要素です。
運用管理グループの効果的なコミュニケーションについては、既にベスト プラクティスとして整理されたものがあり、どれも習慣とすることは難しくありません。具体的には、次のようなベスト プラクティスがあります。
各役割のグループ内で、または特定システムに携わるすべての役割が集まって、毎日または定期的に、重要なまたは緊急を要するシステム、ビジネスの問題事項について最新情報を提供したり必要な処置を検討する簡単な対策ミーティングを開く。
必要に応じてイントラネットまたはインターネット上に顧客用の Web ページを開設し、稼働時間、訪問者数、パフォーマンスの傾向、未解決の懸案事項などの運用指標を顧客がオンラインで確認できるようにする。
本番運用への最終リリース準備段階で、開発チームと展開チームを招集し、リリースの可否 (サインオフ) を確認するミーティングを運用役割が主催する。このサインオフによって、製品またはシステムの運用サポートについて、すべての運用管理グループの準備ができ、引き継ぐ体制が整います。
配布しやすく、読みやすい形式でステータス レポートを定期的に作成し、運用に関する主要なパフォーマンス指標について IT 管理コミュニティとビジネス コミュニティに報告する (サービス レベル契約の達成度、ヘルプ デスクのログ集計、各部門の目標の達成度など)。
MOF プロセス モデルとチーム モデルの併用
役割クラスタと作業領域の対応
MOF チーム モデルにおける役割クラスタと、サービス管理のライフサイクル全体における各役割の機能は、MOF のプロセス モデルと整合しています。プロセス モデルの作業領域は、線形ではなく、同時進行的に働き、チームやシステムに応じて複数の役割が 1 つの作業領域にかかわることができます。多くの場合、実際に複数の役割が 1 つの作業領域にかかわることになります。また、複数のシステムのサービス管理に従事している役割の場合は、同時に複数の作業領域に参加することがあります。次の図は、MOF 各役割クラスタと MOF プロセス モデルの 4 つの作業領域の関係を大まかに示したものです。
.gif "図 5: MOF チーム役割クラスタと MOF プロセスモデルの関係")
図 5: MOF チーム役割クラスタと MOF プロセスモデルの関係
ITIL の関連資料
コア モジュール
IT インフラストラクチャ ライブラリとは、IT サービス管理のベスト プラクティスを包括的に、一貫性ある形で体系的にまとめ上げたものです。OGC は英国において 40 冊を超えるライブラリを開発済みです。
OGC の目的は、情報システムを活用するビジネスの有効性を啓蒙することにありました。IT サービスのレベルを維持しながらコストを削減する必要性に多くの組織は直面し、ここから一連の標準を確立するというニーズが生まれました。そこで、業界をリードする専門家、コンサルタント、および現場が協力して、IT サービスのベスト プラクティスという構想が ITIL により実現されました。
各冊子は、IT サービス管理の特定要素に焦点を当て、他の冊子との相互参照を設けています。冊子を 1 つだけ取り出し、特定の要素だけを切り離して実装することもできますが、それぞれの冊子は全体を織り成す一部として捕らえたほうが高い効果を得ることができます。つまり、部分的に導入するのではなく、すべてを同時に導入することによって、組織は最大限の効果を得ることができます。
ITIL のうち、最も人気があり、参照頻度が高い冊子は、サービス サポートとサービスの提供に関するものです。
サービス サポート |
サービスの提供 |
|---|---|
構成管理 |
サービス レベル管理 |
ヘルプ デスク |
可用性管理 |
問題管理 |
キャパシティ管理 |
変更管理 |
コスト管理 |
ソフトウェアの管理と配布 |
緊急事態対策 |
チームと役割のガイダンス
10 のコア モジュールのほか、ITIL は、チーム、スタッフ配置、組織、パートナー、トレーニングの問題などに焦点を当てた資料も提供しています。具体的には、次のようなものがあります。
業務と管理技術
コンピュータ運用管理
顧客との通信
ヘルプ デスク
オフィス環境における人的要素
IT サービスの運用
IT ユーザーのための良質な職場環境の管理
供給業者との関係管理
小規模な IT 部門の実践集
IT インフラストラクチャの移行
サード パーティおよび単一ソースの保守
関連資料
受講コース
ITIL および MOF に関連する推奨コースを次に紹介します。
ITIL サービス管理エッセンシャル
Microsoft Operations Framework エッセンシャル (1737A)
Microsoft Operations Framework 変更作業領域 (1787A)
コースの開始時期については、https://www.microsoft.com/japan/technet/itsolutions/techguide/mof/default.mspx を参照してください。
書籍
このホワイト ペーパーで紹介した概念について詳しく知りたい方には、次の書籍をお勧めします。
『IT Service Management, IT Service Management Forum/CCTA』 ITIMF Ltd. (1995 年刊行、英語版)
Web サイト
Microsoft のフレームワークと提供している内容の詳細については、次の Web サイトを参照してください。
ITIL の詳細については、http://www.itil.co.uk/ (英語) を参照してください。
ヘルプ デスク協会 (Help Desk Institute) の詳細については、http://www.helpdeskinst.com/ (英語) を参照してください。
関連資料
MOF チーム モデルのベスト プラクティスの開発にあっては、次の文献などを参考にしました。
『Peopleware: Productive Projects and Teams, Second Edition』(Tom DeMarco、Timothy Lister 共著) New York: Dorset House Publishing Co. (1999 年刊行、英語版)
『Introduction to Computer Security: The NIST (National Institute of Standards and Technology) Handbook』(Barbara Guttman 著) NIST Special Publication 800-12 (英語版)
『IT Service Management Forum/CCTA (IT Infrastructure Library)』 ITIMF Ltd (1995 年刊行、英語版)
『IDC Bulletin #20862』(Philip A Mendoza 著) (1999 年 11 月刊行、英語版)
Microsoft Solutions Framework (MSF) チーム モデル (Microsoft Corp.)
Product Cycle Model (製品グループ開発用の内部コース) (Microsoft Corp.、英語版)
寄稿者
主な執筆者
- Bret Clark (Microsoft Corporation)
Neil Fairhead (Microsoft Corporation)
Kathryn Rupchock Pizzo (Microsoft Corporation)
編集者
Laurie Dunham (Microsoft Corporation)
その他の寄稿者
Bill Bagley (Microsoft Corporation)
Anthony Baron (Microsoft Corporation)
Mary Anne Blake (Microsoft Corporation)
Jeff Yuhas (Microsoft Corporation)
このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。
このホワイト ペーパーに記載された内容は情報提供のみを目的としており、明示または黙示に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。
お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではありません。
マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。
© Microsoft Corporation.All rights reserved.
Microsoft、MSN、NetMeeting、Windows は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。
記載されている会社名、製品名には、各社の商標のものもあります。
ダウンロード
このドキュメントをダウンロードする (英語)