Exchange の要員計画

適用先: Exchange Server 2010 SP3

トピックの最終更新日: 2016-11-28

「Microsoft Exchange Server 環境の管理に、何人の IT プロフェッショナルが必要だろうか?」と思われるかもしれません。残念ながら、この質問に簡単に答えることはできません。ここでは、計画の参考になるように、最適な人員を計算するために考慮する必要があるいくつかの重要な要素について説明します。このトピックでは、十分な情報の下に人員を判断できるようにするため、組織のさまざまな面を評価します。

全体的には、人員レベルは組織の成熟度と必要なタスクに基づきます。組織の成熟度は、運用プロセスの成熟度、経験、ハードウェア、信頼性、および設計の各要素の上に成り立っています。必要なタスクは会社によって異なり、プロセスを評価して管理する Exchange 管理者によっても異なります。

組織の成熟度

基本的に組織の成熟度は、組織が開発した内部ポリシーと手順のレベルによって決定されます。たとえば、メッセージング環境を管理するために定義された手順が乏しく、サーバー構成の標準的な運用手順が存在しない組織の場合、ドライバーの更新、パッチのインストール、およびサーバーの構成に関して入念に文書を作成した他の組織と比較して、より多くのインシデントと停止が発生する可能性があります。

ただし、組織の成熟度はポリシーの使用に限りません。組織の成熟度には、管理者が環境を管理する方法も含まれます。たとえば、管理者が 10 台のサーバーに修正プログラムを適用する場合、順番に各サーバーにログインし、修正プログラムをダウンロードしてインストールするという方法もあります。このプロセスは非常に非効率的です。対照的に、管理者が自動パッチ展開システムを使用すれば、100 台のサーバーに修正プログラムを数分で簡単に展開することができます。これにより、効率は飛躍的に高まります。ただし、パッチ管理ソリューション自体を積極的に管理する必要があります。この要件により、さらにリソースが必要となり、正常かつ正確なソリューションを維持するための特定のポリシーと手順に従う必要性が生じます。

組織の成熟度は、次の各要素が基になっています。

-
運用プロセスの成熟度:  通常、十分に文書化された反復可能な操作方法を確立している場合、ほとんどのタスクが自動化されるため、定常的なメンテナンスまたは障害発生時のメンテナンスの必要性が少なくなります。

-
経験:   運用チーム メンバーの知識レベルと関連作業の経験は、チームのエンタープライズ メッセージング ソリューションを管理する能力にプラスの影響を与えます。

-
ハードウェア:   効率的なシステムと優れたストレージ プラクティスは、ユーザーの満足度を高く維持し、サポート コールや停止の回数を大幅に削減します。

-
信頼性:   ハードウェアにも関連しますが、信頼性はハードウェア、ソフトウェア、使用される機能、およびシステムに対する要求の組み合わせによって決まります。通常、信頼できるソリューションとは、ある作業の全体的な要求を満たすように特別に選択されたソリューションのことです。

> [!NOTE]
> 信頼性は、クラスタリングの同義語<EM>ではありません</EM>。クラスタリング ソリューションは複雑性を招くことから、経験のない組織にとっては適さない可能性があります。

• 設計:   Exchange 環境を適切に設計することで、前述した要素すべての効率が高まります。対照的に、設計がよくないと、ハードウェアや人員の経験による効率が低下することがあります。

組織の成熟度の各要素は、インフラストラクチャの最適化モデルと呼ばれる組織のプロファイルにまとめられます (以下の表を参照)。

インフラストラクチャの最適化モデル

インフラストラクチャの最適化の詳細については、「Microsoft Infrastructure Optimization」を参照してください。

インフラストラクチャの最適化モデルで各レベル間の違いを生む重要な要素は、テクノロジの使用方法、およびさまざまなレベルとグループ間でのシステムの標準化です。通常、組織の成熟度が高くなるほど、環境の管理に必要な人員が低くなります。ただし、テクノロジ自体によって組織の成熟度が上がることはありません。正確性、効率性、信頼性、および安定性を適切にサポートするために、すべてのソリューションを管理する必要があります。組織のポリシーはビジネス ニーズから導き出されるべきで、テクノロジはそれらのポリシーをサポートして促進させるべきです。

役割の定義とタスクの割り当て

人員もエンタープライズ メッセージング チームへの要求に大幅に依存します。これらの要求は組織間で大幅に異なる場合があります。メッセージング管理者が Exchange Server 2010 システムの展開、構成、管理および維持だけを行えばよい組織では、管理者が Exchange、バックアップ、メッセージの検疫、モバイル デバイス、ネットワーク、ストレージ、および仮想化テクノロジを管理する組織と比べて、必要となる人員は少なくなります。

以下は、組織のメッセージング管理者の役割を評価する際に検討する重要な質問の一部です。

• Exchange チームは、Exchange を実行するサーバーの基本となる Windows オペレーティング システムについて一義的な責任がありますか?

• Exchange チームは、Active Directory ドメイン サービス、Microsoft SharePoint Foundation 2010 や Microsoft SQL Server などのその他テクノロジを担当しますか?

• Exchange チームが、サーバー、ネットワーク、およびストレージなどの Exchange 環境の物理ハードウェアを管理しますか?または Exchange サーバーを仮想化する場合、Exchange 管理者が仮想化ソリューションを管理しますか?

• Exchange チームが Exchange サーバーのバックアップ (テープベースまたはディスクベース) を管理しますか?

• Exchange チームは、メッセージング検疫インフラストラクチャを管理しますか?Exchange チームは、Exchange 以外のソフトウェアまたはハードウェアを管理しますか?

• 組織内で、メッセージングの運用と設計/アーキテクチャの役割が分かれていますか?

• Exchange チームが、メッセージングのネットワークまたは境界ネットワークのセキュリティを管理しますか?

• Exchange チームが、エンドユーザーにサポートを直接提供しますか?この場合、チームはメッセージング関連チケットすべてを受信しますか、それとも階層 1 および 2 からエスカレートしたチケットだけを受信しますか?

• Exchange チーム メンバーが、標準の日次、週次、月次、四半期次または年次タスクを実行しますか?その場合、どのようなタスクですか?どのような追加タスクを一覧に追加する必要がありますか?

• Exchange チーム メンバーは、メッセージング リソースに関連するセキュリティ問題に対応する責任がありますか?

• Exchange チーム メンバーが、探索検索を実行し、その他の法令遵守関連の問題に対応する必要がありますか?

• Exchange チーム メンバーが容量管理を行いますか?

この一覧はすべてを網羅しているわけではありません。組織のメッセージング管理者の重要なタスクが、この一覧に入っていない可能性があります。また、運用管理者のように、職務内容と必要なタスクがメッセージング管理者とは大きく異なる役職が存在します。個別の役職に焦点を当てるのではなく、チーム全体の観点からすべての役職を検討することが重要です。

以下の一覧に、大規模から中規模のエンタープライズ メッセージング展開の多くに共通する、役割と職務に割り当てられる可能性がある責任を示します。多くの場合、一覧にある役割は特定の役職ではなく、既存の役割の一部です (監督など)。たとえば、これは運用エンジニアの場合です。

-
監督

  - テクノロジの機能とビジネス ニーズを基にして、メッセージング テクノロジの構想を提供します。

  - メッセージング運用とメッセージング システム エンジニアリングの活動を連携させます。

  - 内外のソースにエンタープライズ メッセージング システム全般を説明します。

• マネージャー (メッセージング運用担当)

  • メッセージング システムが最高のパフォーマンスで機能していることを保証します。

  • システムのスローダウンとパフォーマンスの低下がユーザーに影響を与える前に、メッセージング運用チームがこれらの問題を認識することを保証します。

  • すべてのメッセージング運用技術者と運用アナリストに職務遂行に必要なツールを提供します。

  • ユーザーにメッセージング運用を説明します。

• マネージャー (メッセージング システム エンジニアリング担当)

  • メッセージング システムのパフォーマンスを向上させるために、メッセージング チームを主導して継続的な分析と設計レビューを行います。

  • メッセージング チームに職務遂行に必要なツールとトレーニングを提供します。

  • 運用チームからの適切なエスカレーションに応え、それらのエスカレーションに人員を割り当てます。

• 副運用アナリスト

  • メッセージング環境内の新規実運用サーバーをインストール、構成、および文書化します。

  • メッセージング システムの問題の基本的なトラブルシューティングを実行します。

• 運用アナリスト

  • メッセージング環境内の新規実運用サーバーをインストール、構成、および文書化します。

  • メッセージング システムの問題のすべてのトラブルシューティングを実行します。

  • 問題が日次ログに適切に文書化されることを保証します。

• 上級運用アナリスト

  • 新人運用アナリストの指導を支援し、必要に応じて運用アナリストの職務を実行します。

  • 運用アナリストおよび技術者によって解決されないエスカレーション問題を処理します。

  • 日次ログがシステム トラブルシューティング情報の有益な資料集となることを保証します。

• 副運用エンジニア

  • 運用アナリストおよび技術者と協働して、基本的な分析と設計を実行します。

  • 考察を深めるため、エンジニアリング チームのその他メンバーに見解と推奨案を提示します。

• 運用エンジニア

  • 運用アナリストおよび技術者と協働して、詳細な分析と設計を実行します。

  • 運用側からの初期エスカレーションを処理します。

  • 運用チームからのすべてのエスカレーションをトラブルシューティングし、追跡調査を行います。

  • エンタープライズ メッセージング システムのリリース済み製品の機能をユーザビリティの点から評価します。

• 上級運用エンジニア

  • リリース済み、およびリリース前のメッセージング システムを評価します。

  • 実装予定の機能に対する詳細なテスト計画を提供します。

  • 次世代のメッセージ製品のリリースによる影響を最小限にします。

  • 高度なエスカレーションを処理し、必要に応じて Microsoft テクニカル サポートに連絡します。

• メッセージング運用技術者

  • メッセージング システムの日常的な監視とレポートを処理します。

  • イベントが日次ログに適切に記録されることを保証します。

  • 勤務時間中に発生したすべてのイベントが記録され、適切な担当者に報告されることを保証します。

  • また標準の「PC ヘルプデスク」部門からのエスカレーション要求を処理します。

各作業に必要な人員を高い精度で計算するには、さまざまなメッセージング チーム メンバーの役割を明確に定義し、それらの役割の要求を客観的に評価することが役立ちます。

テクノロジの影響の評価

組織がさまざまな役割と責任を定義した後、次のステップではテクノロジを評価して、目的のタスクをソリューションの技術コンポーネントに対応させます。通常、ソフトウェアの改善により、管理者は旧バージョンと比べてはるかに迅速に特定のタスクを完了し、一般的なワークフローを自動化し、その他の個人やチームに特定のタスクを委任できる場合があります。

次の例を検討します。Woodgrove Bank の管理者は、誤って削除してしまったアイテムを取得するために、メールボックスを復元してほしいという依頼を頻繁に受けます。これらの依頼は、(Exchange Server 2003 システムへのアクセスに必要なアクセス許可がある) メッセージング エンジニアと (実際の復元操作を処理する) バックアップ エンジニアの支援が必要になります。Woodgrove Bank が Exchange Server 2010 を展開した後にも、削除されたコンテンツを復元する必要性は依然として存在します。しかし、すべてのユーザーが単一アイテムを回復できるようにすれば、実際の復元作業は、メッセージング管理者 (役割ベースのアクセス制御によって適切なアクセス許可が与えられている)、または人事部門の法令遵守管理者が実行できるようになります。バックアップ エンジニアが復元作業に関わらないため、処理全体がより単純になり、より短時間で完了できます。

Exchange Server 2010 のいくつかの機能を使用すると、管理者が異なるレベルで異なるチームにタスクを割り当て直したり、タスクの必要性を完全になくしたりできる可能性があります。以下の表は、Exchange Server 2010 の主要な機能と、これらの機能がサポートできるタスクへの変更を示しています。この表に記載されている機能は完全なリストではありません。もちろん、これらの機能を使用するかどうかは、任意に選択することができます。

上記の一覧は Exchange Server 2010 に固有のものですが、タスクとテクノロジ間の対応付けに関する原則は、どのバージョンが使用されていても変わりません。テクノロジを十二分に活用することで管理者は可能な限り最も効率的な方法で職務を果たせるようになるため、その他のタスクに時間を割けるようになり、その他のチームへの要求も同様に減らせます。

人員の計算

冒頭で触れたように、特定の Exchange 組織を管理する特定の推奨人員を導きだす簡単な公式はありません。さまざまな要素が非常に複雑で変化に富みます。規模とスコープが同様の 2 つの組織においても、管理者の職務、管理者の Exchange の管理経験、環境の自動化の程度に応じて、必要な人員は大幅に異なる場合があります。

人員を計算する際に検討する最も重要な要素は、現在のインフラストラクチャで必要なタスクすべてを実行するために必要な合計時間数です。運用の成熟度が上がるような大きな変更が環境に加えられる場合、理想的なインフラストラクチャで必要なタスクすべてを実行するために必要な合計時間数を計算することも適切であると言えます。次に、1 日の作業時間、1 週間の作業日数、および休暇と病気欠勤日の平均日数などのその他の要素を考慮し、合計時間数を推奨人員に換算します。人員は常に小数点以下を切り上げ、人員が必要な時間を上回り、不足しないようにする必要があります。

次の Exchange 運用タスク チェックリストのサンプルは、人員レベルを計算する前に、どの程度まで細かくタスクを分ければよいかを示しています。

サンプル - Exchange の運用タスク チェックリスト (場所ごと)

この例では、組織はタスクの合計が 9,792 時間を要すると判断しました。フルタイムの従業員が 1,635 時間働くと仮定すれば、この分析は、組織は 1 人従業員の 600%、分かりやすく言えば、6 人のフルタイム人員が Exchange 組織の管理に必要であることを示します。このサンプルのタスク リストは、運用チームのみを対象としています。お客様は、エンジニアリング チームとヘルプ デスク チームにも同様の分析を実施する必要があります。

役職の数も、組織の規模と複雑さに応じて変化します。小規模の組織では、複数の役割を組み合わせたり、役割を完全に省略したりすることがありますが、大規模の組織では、複数の従業員が特定の役割を担当することがあります。たとえば、ある大手金融機関は、ユーザー 45,000 人のリソースを 1 日 24 時間、1 週間 7 日ベースで管理するメッセージング チームを擁します。このような組織のメッセージング サービスの人員には、通常、次の表に示される役職で 30 ～ 32 人が在籍します (役職と職務は、このトピックの「役割の定義とタスクの割り当て」で定義しています)。

終わりに

特定の Exchange 環境を管理するのに必要となるエンジニア、管理者、およびその他のサポート人員の人数を判断するには、入念にビジネス要件を収集し、さまざまな要素を検討し、とりわけ慎重に計画する必要があります。必要となる人員を判断するには、まずユーザー コミュニティのニーズの判断、それらニーズを満たす役割の定義、テクノロジの評価、テクノロジと役割間の対応付けを行い、最後に必要なタスクを実行するのに必要となる時間を計算する必要があります。これは複雑なプロセスですが、最終結果を参考にすることで、過剰な人員配置で組織やチームに不要の負担をかけることなく、メッセージング チームの能力をビジネス (およびユーザー) のニーズに過不足なく合わせられるはずです。

 © 2010 Microsoft Corporation.All rights reserved.