配備目標の確認

Communications Services ハードウェアまたはソフトウェアを購入または配備する前に、配備目標を明確にする必要があります。組織内のさまざまなソースから、配備の要件があがってきます。多くの場合、要件はあいまいな言葉で表現されますが、それを特定の目標に向けた明確な定義に変える必要があります。

要件分析の結果は、明確で簡潔な言葉で定義し、配備による成果を評価できる目標としてまとめる必要があります。プロジェクト関係者からの同意を得た明確な目標がなければ、先に進んでも成功するのは困難です。

配備を計画する前に検討の必要がある要件には、次のものがあります。

• ビジネス要件

• 技術の要件

• 財務の要件

• サービスレベル契約 (SLA)

ビジネス要件の定義

ビジネスの目標は、配備の決定に大きく影響します。具体的には、ユーザーの行動、サイトの配布、配備に影響を与える潜在的な政治的要因について理解しておく必要があります。これらの業務上の要件を理解していない場合は容易に想定を誤り、配備設計の精度に影響を与えることになりかねません。

運用の要件

直接的な目標を持った一連の機能上の要件として、運用要件を明確にします。通常、次の項目が該当します。

• エンドユーザー機能

• エンドユーザー応答時間

• 可用性 / 稼働時間

• 情報の保存と保持

たとえば、「適切なエンドユーザー応答時間」という要件を評価可能な用語で言い換えて、関係者全員が何が「適切」で応答時間がどのように評価されるかを理解できるようにします。

カルチャーとポリティクス

配備を考える場合、企業のカルチャーとポリティクスを考慮する必要があります。需要というものは、結局はビジネス要件そのものから生み出されてくるものです。例:

• サイトの中には、配備されたソリューションを独自に管理する必要があるものもあります。そのような需要が、プロジェクトのトレーニング費用、複雑さなどを発生させる元となります。

• LDAP ディレクトリに個人情報が含まれている場合、人事部門はそのディレクト リを自己の管理下におきたいと考えるはずです。

技術要件の定義

技術の要件 (または機能の要件) は、組織のシステムニーズの詳細です。

既存の利用率パターンのサポート

既存の利用率パターンを、配備実現のための明確で評価可能な目標として定義します。そのような目標を定義する際に参考となる質問を、次に示します。

• 現在のサービスはどのように利用されていますか。

• ユーザーは分類可能ですか (一時的なユーザー、常用ユーザー、ヘビーユーザーなど)。

• ユーザーはどのような方法でサービスにアクセスしますか (自身のデスクトップから、共有 PC または工場の現場から、ローミングラップトップからなど)。

• ユーザーが通常送信するメッセージのサイズはどのくらいですか。

• カレンダのアポイントには、通常、何人くらいの招待が掲載されていますか。

• ユーザーはメッセージをいくつ送信しますか。

• 通常、ユーザーが日ごとまたは時間ごとに作成するカレンダ予定および作業はいくつですか。

• ユーザーがメッセージを送信するのは、社内のどのサイトですか。

• 必要とされる並行性 (任意の時刻に接続可能なユーザーの数) はどの程度ですか。

サービスにアクセスするユーザーについて調査します。ユーザーはいつ既存のサービスを使うのかといった要素が、配備の要件、ひいては配備の目標を定める重要なポイントとなります。組織の今までの事例からこれらのパターンを得ることができない場合は、他の組織の事例を研究し、推測します。

利用率のきわめて高い部署では、専用のサーバーが必要になる場合もあります。一般に、ユーザーが実際のサーバーから遠く離れており、回線速度も遅い場合、応答時間が長くなります。応答時間が適切であるかどうかを検討する必要があります。

サイトの分散

次の質問を検討して、サイトの分散が配備目標に与える影響を理解します。

• サイトは地理的にどのように分散されていますか。

• サイト間の帯域幅はどれだけありますか。

  集中化方式を採用する場合は、分散化方式よりも広い帯域幅が必要です。ミッションクリティカルなサイトには、専用サーバーが必要です。

ネットワーク

ネットワーク要件の理解に役立つ質問を、次に示します。

• 内部ネットワーク情報をわかりにくくしたいと考えますか。

• ネットワークサービスに冗長性を持たせたいと考えていますか。

• レイヤーホストにアクセスする場合に、利用可能なデータを制限したいと考えていますか。

• エンドユーザーの設定を簡略化したいと考えていますか (たとえば、エンドユーザーを移動する場合に変更が不要な単一のメールホストをエンドユーザーに入力させるなど)。

• ネットワークの HTTP トラフィックを削減したいと考えていますか。

これらの質問に「はい」と答えた場合は、2 層アーキテクチャーをお勧めします。

既存のインフラストラクチャー

より信頼性の高い高可用性帯域幅が利用できる場合は、集中化サーバーを採用できます。

• 既存のインフラストラクチャーと設備で、この配備が可能ですか。

• DNS サーバーは追加の負荷を処理できますか。ディレクトリサーバーはどうですか。ネットワークはどうですか。ルーターはどうですか。スイッチはどうですか。ファイアウォールはどうですか。

サポート要員

24時間、週に 7 日 (24 x 7) 体制のサポートは、特定のサイトでのみ提供されます。少数のサーバーによる簡単なアーキテクチャーの場合は、サポートが容易です。

• 運用グループと技術サポートグループに十分な能力があり、この配備を促進できる状況にありますか。

• 運用グループと技術サポートグループは、配備期間中に増大する負荷に対処できますか。

財務要件の定義

財務上の制約は、配備の構築方法に影響を与えます。財務上の要件は全体的な視点から明確に定義される場合が多く、配備の限界や目標が明確になります。

ハードウェア、ソフトウェア、および保守のための明確なコスト以外に、次のような他のコストがプロジェクト全体に影響を与えます。

• トレーニング

• ネットワーク帯域幅やルーターなどのサービスや設備のアップグレード

• 配備のコンセプトを検証するのに必要な人員やリソースのような配備コスト

• 配備されたソリューションを管理する人員のような運用コスト

プロジェクトの要件に関連する数多くの要素を注意深く分析することで、プロジェクトに関連する財務上の問題を回避することができます。

サービスレベル契約 (SLA) の定義

サービスレベル契約には、稼働時間、応答時間、メッセージ配信時間、および障害回復のような領域に関連する配備を盛り込む必要があります。サービスレベル契約自体には、システムの概要、サポート組織の役割と責任、応答時間、サービスレベルの評価方法、要求の変更などの項目が網羅されています。

サービスレベル契約の範囲を決定する際には、システムの可用性に対する組織の予測が重要なポイントとなります。システムの可用性は、システム稼働時間に対するパーセンテージで表されます。システムの可用性を表す公式は次のとおりです。

可用性 = 稼働時間 / (稼働時間 + 停止時間) * 100

たとえば、サービスレベル契約で稼働時間が 99.99 パーセントと規定されている場合、1 か月に許されるシステムが使用できない時間は、約 4 分間となります。

さらに、システムの停止時間とは、システムが使用できない時間の合計を意味します。この合計には、システム障害やネットワークの停止などの予期しない停止時間だけでなく、計画された停止時間、予防的保守、ソフトウェアのアップグレードやパッチを当てる時間なども含まれます。システムが 7x24 (週 7 日、24 時間) 稼働を前提としている場合、アーキテクチャーに冗長性を持たせて計画された停止や予期しない停止に備え、高可用性を確保する必要があります。