●よくある失敗例１ 運用設計の不備 プロジェクトにおいて、構築側と運用側のメンバーや会社が異なる場合、 運用引継ぎが発生します。 このとき、どうしても期限が切られている構築側とこれから長い航海に出る運用側では、 意識や優先順位が異なり、その穴を埋めるためにも運用設計が必要なのです。 タイトなスケジュールで作り上げるの構築側と、安定した船出を求める運用側、 なかなか意識の差ははげしいものがあります。 極端な話、頭の中はこのような状況でしょうか。 構築側：「運用のことは運用ベンダが考えるだろう。とにかく構築を終わらせなければ。」 運用側：「きちんと所定の情報をインプットしてくれなければわからない。こうしたことは考慮されているか？」 構築側と運用側、どちらになにを期待するのか、しないのか、 役割分担、作業範囲、理想の運用の姿、過渡期の姿・・・ ある程度の共通認識をもって本稼働に挑むのとそうでないのとでは、稼働直後のシステム安定度に大きく影響します。 ●よくある失敗例２ 分業による管理コスト上昇 システムは多くの技術要素から成り立っています。 ITILのサービスカタログという考え方で表現してみるとわかりやすいのですが、 サービス視点でシステムを整理していみると、登場人物（担当者/会社/体制/チーム）の多さに驚きます。 OS、ミドルウェア、DB、H/W、アプリケーション、ネットワーク、セキュリティ、監視通知、 アプリ運用、プログラム保守、ワークフローシステム、会計システム、BIシステム、パソコン・・・ 一昔前はシステム運用といえば、大手1社に丸投げしてしまうケースが多かったのですが、 オープン化や統制の強化の流れを経て、ユーザ自らがこれらを主体的に管理するという考えが広まりました・ もちろんユーザ自らが主体的に運用に参加することは当然ですし、全く異論の余地がありません。 しかし。主体的な参加と、自身で抱え込んでしまうことは違います。 これだけの技術/サービス要素が分散していると、なかなか管理をしきれるものではありません。 その結果、せっかくひとつひとつ、サービスを比較してコストが安い体制をとったにも関わらず、 社員のサービス残業として見えないコストになっていることが少なくありません。 このお話、情報システム部門の課長さんにはだいたい「うんうん」と頷いていただけるのではないでしょうか。 仮にひとつひとつのベンダコストは安くても、これらを管理するユーザやシステム部門の工数が膨大になってしまう、 というわけです。 ●よくある失敗例３ インシデントの長時間化 よくある失敗例２で、たくさんのサービスや技術要素が関係する、というお話をしました。 多くの要素が絡むということは、運用担当者にもそれ相応の技術スキルが必要です。 障害や問い合わせが発生した際、それぞれの異なる窓口に対して状況を正確に伝え、目的の回答を得る。 これはなかなか簡単なことではありません。 じゃあなんのためのサポートなんだという声が聞こえてきそうですが、残念ながら、実態はこのようなことは少なくありません。 単なるオペレータでは窓口のたらいまわしが発生し、インシデントの長時間化という結果が待っています。 よくあるSAPシステムの例を取ると、こんなかんじです。 　SAP・・・SAP OSS 　ジョブ/監視・・・日立 　OS・・・Microsoft 　サーバ・・・HPサーバ窓口 　ストレージ・・・HPストレージ窓口 　バックアップ・・・HPソフトウェア窓口 この例では、サーバ、ストレージ、バックアップをHPから購入していますが、 サポート契約が別々という例です。 これらのサポートレベルはもちろんまちまちです。 受付時間、初動までの時間、土日の対応、保守費、契約体系、バージョンアップ権、障害と通常問い合わせ、代理店とメーカー・・・ サポートと一言で言っても、何から何まで定義がバラバラです。 ですので、あの窓口はあのレベルだからこういう話し方、こっちの窓口は・・・ と窓口毎に担当者のスキルレベルも異なるので、障害の短期解消を目指すために担当が回答しやすくなるよう、 動きやすく情報を提供する、という問い合わせ方をしないと、どうしても長期化しがちなのです。 ○ではどうしたらよいか？ よくある失敗事例として３つあげました。 これらは実際に弊社自身が過去陥った失敗です。 ではどんな体制を組めばよいのか、どんな運用ベンダに依頼をすればいいのでしょうか。 思いのほか今回の「運用で失敗しないために　後半」が長くなってしまいました・・・ 次回「運用で失敗しないために　後半２」として、運用体制の組み方について書きます。
TOP