皆さん、こんにちは。
今回は、いつものテクニカルの内容ではなく、運用面での話をしたいと思います。
最近、業務において、運用面の話を個人的に考える機会がありましたので、この機会に整理したいと思います。
<ラージ エンタープライズとは？>
まずは、定義のお話から。タイトルにも記載したラージ エンタープライズですが、単純に日本語訳すると、大企業となります。今回のこの記事での位置づけとしては、スモール エンタープライズ (小規模企業)、ミディアム エンタープライズ (中規模企業)、ラージ エンタープライズ (大規模企業) という感じで企業規模を示すものとなります。位置づけなので、人により解釈が異なりますが、ラージ エンタープライズは、10,000 デバイス以上相当の管理端末がある企業のことを示すことにします。
<なぜ、ラージ エンタープライズの運用について考えるか>
私は、幸いなことに、インターンでお世話になった会社も含めると、スモール、ミディアム、ラージのエンタープライズの社内システムを経験することができました。あくまで、私の経験ですが、ラージ エンタープライズとそれ以外の違いを改めて整理したいと思い、このポストをすることにしました。
<チームの関係性>
ラージ エンタープライズ環境では、社内システムの担当するチームが細分化されているケースが多いです。スモールやミディアム環境だと、社内 SE というくくりで、サーバー システムの管理やネットワークの管理、またプリンターなどの管理など多岐に渡るシステムの管理を同一チームで行うことが多いです。
しかし、ラージ エンタープライズの場合は、10,000 人以上のエンド ユーザーを相手にすることになるため同一チームで扱うことは非常に困難です。そのため、通常はネットワーク専業のチーム、サーバー システムの管理チーム、クライアント PC 管理のチームのように、社内システムを管理するチームが別チームとなります。また、いわゆる IT 部門の数も 100 名以上になるケースもあります。その場合、自チームだけでシステムが完結しないため、他チームとの調整も必要になってきます。
その点、ラージ エンタープライズでは、社内でのチーム間の調整能力も必要になってきます。
<エンド ユーザー サービスの関連性>
また、運用の仕方も変わるかと思います。具体的には、エンド ユーザーからのインシデントやリクエストなどの対応のパスです。スモールやミディアムだと、エンド ユーザーと社内システム担当者の距離が近いため、サービス デスクやヘルプ デスクから直ぐに社内システム担当者へエスカレーションが来ます。
ITIL (Information Technology Infrastructure Library) でいうところの、L1 (Tier 1)、L2 (Tier 2)、L3 (Tier 3)の概念ですね。(組織により、L4 (Tier 4) も組織内にあるケースもあり)
スモールやミディアムだと、サービス デスクやヘルプ デスクの L1 から、次のエスカレーション パスが L2 と L3 が一緒になった、社内システム担当者 (社員) の場合もあります。その場合、エンド ユーザーからの問い合わせを迅速に対応かつ手厚く対応できるケースが多いです。ただし、エンド ユーザーからの問い合わせ対応に追われ、社内システム全体の改善や対応が疎かになる場合もあるかと思います。
ラージ エンタープライズの場合、多くは L2 と L3 は分離されていますので、エンド ユーザーからの問い合わせが社内システム担当者 (社員) に直接来ることは希です。(ただし、ビジネス部門との関連性により、異なる場合もあるかと思います。) そのため、L3 である社内システム担当者 (社員) は、エンド ユーザーからの問い合わせを直接対応することは少なくなります。その分、社内システム全体に関わる変更などに注力することが可能になります。
ということは、ラージ エンタープライズの L3 の立場の人が、エンド ユーザーからの個別の問い合わせにフォーカスするということは、組織全体の 10,000 人のユーザーへ影響のある変更や対応を疎かにして、会社全体としてのシステムを危うくするということにも繋がります。(極端ですが。。。)
そのため、ラージ エンタープライズとスモール、ミディアムの L3 の立場の役割は異なります。もちろん、エンド ユーザーにシステムを提供している IT 部門としては、エンド ユーザーをないがしろにしてはいけません。ただし、リソースの問題があるので、1 名や数名にフォーカスするのか、全体の 10,000 人を相手にするのかは考える必要があります。
<変更管理について>
通常、社内システムであっても、ITIL (Information Technology Infrastructure Library) ベースの変更管理プロセスにアラインすることが求められます。
ただし、スモール環境では、変更管理プロセスが明確に定義されていない場合も多いです。規模が小さいため、社内システムへの変更を行う際に、社長やマネージャーの承認さえあれば、システム変更が可能な場合も多いです。
ミディアムの場合、変更管理プロセスにより議論はされますが、利害関係者 (ステークホルダー) が多くないこともあり、変更の記録を残すことにフォーカスしている場合も多いです。
ラージの場合は、関連する組織が IT 部門内でも多いため、CAB (Change Advisory Board) ミーティングを定期的に開催し、利害関係者 (ステークホルダー) で議論して、合意した上で、変更を実施する場合が多いです。また、影響度が大きいものは、上層部のマネージメントによる承認が必要だったりもします。
<今回のまとめ>
今回は、思いついた限り、ラージ エンタープライズの運用について述べてみました。このシリーズは今後も続けていければと思いますので、ご期待 (?) ください。皆さんも自組織の環境に合わせてこの記事が少しでも役立つものになれば幸いです。