CSKに聞く！ ITIL成否を分ける要因「なぜＰＤＣＡが回らない！？」 −　（１）

CAとともに、お客様へのITILコンサルティングや導入に携わるパートナー企業に、お客様の持つ課題や解決へのアドバイスを頂くインタビュー企画。第二弾は株式会社CSK-ITマネジメント(以下、CSK)の営業グループ マネジメントセンター サービスマネジメント課 課長の牧野 純也さんです。今回も前半・後半の2回に渡ってお話を伺います。
存知の方も多いと思いますが、CSKは2005年のホールディングス制導入に始まり、この7月にはCSK本体を中心としたグループ再編成により、ＩＴサービスに特化した会社として、CSK-ITマネジメントが設立されました。またデータセンター事業に対しても益々注力、間もなく関西に大きなデータセンターを開設・運用を開始されるそうです。牧野さんは、これまで数多くのITILコンサルティング・導入の経験をお持ちで、現在は社内のデータセンターにおいてITILの導入と内部統制整備のプロジェクトに参画されているそうです。こうした社内外の経験を踏まえ、お客様がITILを導入する際に、どこで苦労をされているのか、その原因はどこにあるのか、お話を伺いました。

■ ズバリ、お客様がITIL導入に際して最も苦労される点はどこにあるのでしょうか?
やはり最も苦労をするのは、いわゆるITILの3つのP(Process / People / Product)の中でいうPeople、つまり”人”の部分になると思います。プロセスの導入自体も大変ですが、最も大変なのはプロセスを整備した後、いかに改善のPDCAを回すかに尽きます。
プロセスの導入については、これまでの弊社のノウハウを活かしたテンプレートの活用などで、ある程度、標準的なプロセスの設計を短期間で実装することが可能です。しかしITILプロセスによる管理とは、組織に対して横串のプロセスを実装し、横断的にＩＴサービスを管理するものです。多くの場合、ＩＴ組織が、機能別に分かれていたり、自社内だけで管理プロセスが完結しない場合もあるので、利害関係者も含めて、いかに改善サイクルを回していくかが非常に難しいところです。

■ 折角構築したプロセスがまわらない要因はどこにあるのでしょうか?
そもそも「ITILの導入目的はなにか」ということが、実際に現場で作業に携わる人に伝えられていない、もしくはツール導入が目的化され、本来の改善を推進するということが全員の腹に落ちていない状況だと、導入後に現場の協力が得られず、改善のPDCAが回らないことが多いです。例えばサービスデスク製品を導入しても、インシデントの入力が徹底されなかったり、正しいルールで起票されないために、情報の精度が悪く改善ステップに至る事が出来ないといったことになります。
また、「管理プロセス」と「業務プロセス」の違いも、明確に説明し理解を得ることも重要です。あくまでも管理プロセスである”インシデント管理”と、業務プロセスである”障害対応手順”の違いを理解していただかないと、ツール実装の際に、現場から「この手順も自動化したい」、「ここは自社ツールで自動化しているで、これも追加したい」といった日常の障害対応手順をインシデント管理ツールに実装するようなことになり、その結果、過剰なカスタマイズが発生し、結局「使えないツール…」に陥ってしまうこともあります。

■ つまり、管理をする側の明確な目的意識と現場への説明がカギとなる、ということでしょうか?
そうです。ITILというのはＩＴサービスの管理のためのプロセスです。管理をしたい側から、その導入目的を示すことが重要です。例えばインシデントを記録することで、何を可視化し、どの様な改善を目指すのかを説明し、理解を得ることが必要です。このような理由から、弊社がお客様のITILのプロジェクトを始める際には、プロジェクトのキックオフの時に、現場の方やアウトソーシング・ベンダー方にも参加いただくことにしています。
また最近では少なくなりましたが、ITILの黎明期のころは、赤本・青本の通りにプロセスを実装しなければいけないという強迫観念にかられ、結局、時間やコスト面の制約から悩まれているお客様も多くいらっしゃいました。そういう場合でも、ITILの実装範囲を絞り込むための拠り所として「何をしたいのか」という目的が重要になります。
さらに、実際の導入作業を進めていくと、日常の作業手順に落とす工程では、現行の手順とITILの手順の間に、どうしても2度手間と思われるような箇所が生じることがあります。作業の効率化だけを見れば確かに2度手間なのですが、そのような場合でもITIL導入の目的に立ち返って、現場を説得することが必要となります。
ですからプロジェクトの初期の段階で、目的が曖昧であると判断した場合は、目的を明確化するための議論に多くの時間を割きますし、そこで確認した目的を組織内に浸透させるためのアドバイスもします。

こういった議論をするテーブルを用意し、それぞれの立場の意見を聞きだして整理をするということもコンサルティングを活用するメリットでもあり、我々の腕の見せどころだと思います。どの企業にも、上下関係の強さや組織間のパワーバランスなど、企業ごとに事情があると思います。こうした組織に横串のプロセスであるITILを導入することが、一番苦労させられるところです。

■ それでも組織の都合がぶつかり、折り合いのつかないこともあるのですか?
もちろん、同じテーブルについたからといって中々話しが纏まらない場合も多くあります。ただ議論をある程度重ねていくと、やはり現実的な共通認識が生まれると思います。例えば「経営トップの方針だから…」などと・・。
経営トップを巻き込むというのは、部門間の連携を円滑に進める上では非常に大きいと思います。あるお客様では取締役の方が毎回、プロジェクトの定例会に出席して頂きました。その役員の方が、プロジェクトの意思決定や部門間の調整に大きな力を発揮してくれて、プロジェクトが円滑に進んだという経験があります。ですからITILプロジェクトにおいては経営層の巻き込みが成功要因の一つともいえます。経営層が参画されない場合は、コンサルタントがその役を演じなければならない場合もあります。
なかなか調整や決定ができない場合は、「決められないのであれば、弊社の提示案で決めてしまいますよ」と背中を押します。
またITILは改善サイクルの構築なので、まずは着手してみるというスタンスも重要かと思います。ツールを実装する場合は、あとから設定変更で調整できるところもありますから、そういった部分は先送りして取りあえず着手してみることも必要です。
逆にもちろん予め決めておかないと、後々影響がある部分もあります。例えばサービスデスク製品を導入する際に、お客様には「エスカレーション先の決定」をプロセス設計の初期の段階で依頼しています。実際のツールの実装作業では、この作業は最後でも構いませんが、現実的には運用部門から開発部門にエスカレーションする場合もありますので、部門間の調整が必要になります。下手をすると、この調整だけで一・二ヶ月かかることもあるので、早めにお客様にお願いしていますね。そういった部分でも是非コンサルタントのこれまでの経験を上手く使っていただきたいですね。

木村泰介