北村 俊義
株式会社野村総合研究所
上席システムコンサルタント

EXIN認定ITILマネージャ

こんなはずではなかったアウトソース

アウトソースを行っているユーザから、「思ったほど効果が出なかった」、「こんなはずではなかった」などの声を良く聞く。前回（第4回）はコスト管理の観点からPC管理の外部委託（アウトソース）について言及したが、本稿ではアウトソースで陥りやすい落とし穴についてお話したい。アウトソースを期待通りの効果を出し、業務を改善するにはどのようにすればよいのだろうか。

■ アウトソース先の選定 〜RFPの功罪〜

自社業務を外部にアウトソースする際は、委託したい業務を、RFP(Request For Proposal)の形でまとめ、複数社のコンペによりアウトソーサを決めるのが一般的である。ＲＦＰを要求事項として、より優れた内容、より安価な価格を提案したアウトソーサが選定される。非常に合理的なシステムであるが、いくつかの問題も含んでいる。

RFPを記載する際は、必要な運用要件をベンダーに伝わる形で盛り込むことが最低限の条件であるが、より精度の高い提案を受け入れるためには、現状のシステム環境や業務の特性、執務場所の環境、各種ステークホルダの所在など、伝えるべきことは多くある。ただし、そのすべてを正確に書面に表現するのは土台無理であろう。すなわち、完璧なRFPなど存在しないのである。

一方、ベンダーから受領した提案は、RFPに記載された要件に対応した回答がひとつひとつ記載されてくるだろう。その回答を並べてみたとき、方式やコスト面で優劣が明らかな場合はまだ良い。大抵はどのベンダーもある程度やってくれそうに見えてしまうのではないだろうか。これは、RFPが詳細であればあるほどそうなる可能性が高い。

しかし、その中にも、経験に裏打ちされたものとそうでないものが必ずある。ノウハウのあるベンダーは、きちっとリスク要素を提示しているはずである。そしてそれらは、RFPに書ききれなかった事項を補完してくれている。ネガティブな表現をするのは、ベンダーとしても気が進まないものであるが、そのアウトソース企画を効果あるものにしようと熟慮を重ねているなら、お客様に対して遠慮はできないのである。

■ 運用準備 〜SOW準備してますか？〜

アウトソース先を決定して、運用を開始した後、少しずつ運用コストが膨らんでいってしまうという声もよく聞かれる。多くは、アウトソース契約をしたときの条件と、実際に始めたたきの内容が違うことを理由に、「追加要件」に対するコストが発生してしまうということである。こういった事態が「こんなはずではなかった」という気持ちを生むきっかけになっていく。これを防ぐためには「業務仕様書（SOW : Statement of work）」を準備し、業務内容や入出力、プロセスといったものの基準を共有しておくことが有効であろう。基となる情報が揃っていれば、何を追加する必要が生じたのかを明らかにすることができる。そうなれば、追加される料金の妥当性も判断可能になるのである。

■ 運用開始 〜手綱を離さない〜

アウトソースを始めてしばらくたてば、少しずつ運用は安定してくるだろう。何も問題がなければ、そのまま彼らに任せておけば大丈夫だろうか？

一旦アウトソースを行えば、業務プロセスの実行はアウトソーサに移管される。そのプロセスの管理までを移管してしまうケースと、プロセスの実行までにとどめるケースとがあるが、どちらの場合でもプロセスのアウトプットを評価できる状態を保たなくてはならない。手綱を放してしまってはいけないのである。

もし手綱を放してしまったら、アウトソーサにコストダウンや品質アップを申し入れても、プロセスそのもの議論に終始し、主導権を握られたままになってしまう。常に双方が対等に向き合うためには、共通の評価のものさしが必要となる。

■ 一本目の手綱はＳＬＡ　〜ユーザ視点で効果的に活用〜

一本目の手綱として、SLA（Service Level Agreement）の効果的な活用について説明したい。

サービス品質とコストを合意するためアウトソーサとSLAを結ぶことはかなり一般的なことになってきている。しかし、アウトソーシングの活用範囲が広がってきた結果、エンドユーザから見た「サービス」が提供されるまでのプロセスに、複数のアウトソーサが関与する場合が増えてきた。こうなると、「サービス」をエンドツーエンドで捉えられるように準備しておかないと、ＩＴ部門が本来果たすべきである「エンドユーザ向けのサービスを満足させる」という目標を達成できないのである。そう、ITILで提唱されているところの、OLA（Operational Level Agreement）の概念に登場していただこうというわけである。

例えばパソコン増設で、ユーザが申請書を提出してからパソコンが設置されるまでのリードタイムを指標値(SLA)とした場合、申請書が提出されてから承認するまでの時間（社内承認部署)、ネットワーク工事に要する時間（ネットワークアウトソーサ）、パソコンを調達する時間（PC運用アウトソーサ）など、各プレイヤーがそれぞれの責任で達成すべき指標値(OLA)を共有し、関連者全員で目標管理するのである。

こういったサービス改善をしようとすると、得てして関連アウトソーサ同士の責任の擦り合いになりがちだが、IT部門が手綱をさばき、共通の管理指標を一緒に上げようすることにより、いろいろなアイデアが出てくるものである。エンドユーザ視点での共通目標値の設定管理は、関連者間で同じベクトルに向かうことができる非常に有効な方法である。

上記グラフはパソコンの障害復旧時間の目標値に対する達成率の例である。青線はＰＣ管理アウトソーサが復旧に要した時間の達成率推移、赤線は保守部品の調達やエンドユーザ都合による手待ち時間など、ＰＣ管理アウトソーサの責に帰さない時間も含んだトータル時間の達成率推移である。赤線の値が右肩上がりに改善しているのが読み取れるであろう。

「達成率」よりも「改善率」

ここで触れておきたい重要なことがある。それは、目標管理で着目すべきは達成率ではなく改善率であるということである。甘い目標値を１００％達成できたとしても何の意味もない。改善率に着目することにより、甘い目標値を設定したアウトソーサも安穏としていられなくなる。地道な継続改善活動を行わない限り、指標値が右肩上がりすることはない。

図１のグラフは、パソコンの障害復旧時間短縮という改善活動を情報システム部門と関連アウトソーサ、保守ベンダーと取り組んだ結果であるが、それに対応してエンドユーザの満足度も向上した（図２のグラフ）。パソコン管理アウトソーサの目標値達成率のみに着目してもこの結果は得られなかったであろう。

■ 二本目の手綱は競争原理

通常のアウトソースのスキームでは、3年、5年といった複数年契約を前提とする場合が多いであろう。おのずとこの契約期間中は自由な競争原理が働かない状態になる。契約更改時がその権利を行使する最大のチャンスであるが、そのときに契約更新を前提とした交渉ではなく、アウトソーサを切り替えられる状態を作ったうえでテーブルに着くべきである。オルタナティブがあって初めて対等の交渉が可能になる。相手はその道のプロなのだから、彼らと戦うのではなく、アウトソーサ同士で戦わせて勝ちあがったものを選べばよい。

一般に、アウトソーサの変更はスイッチングコストやリスクも発生する。そのため、既存アウトソーサに少々の不満があったとしても現状に甘んじて継続契約するケースが散見されるが、ここでも前述のSOWとSLAが有効活用できるであろう。どのような業務をどのようなレベルでやる必要があるのか、そして、そのサービス価格はいくらなのか、が可視化されていれば、適正な競争調達を行うことが可能になる。特に、ＰＣ管理のようなコア業務と直結しないコモディティーサービスは切り替えやすい業務といえる。

但し、現行アウトソーサとの契約を打ち切る場合、現行アウトソーサに対して、次の契約更改時にはもう一度交渉のテーブルにつける状態にしておくこともまた重要である。もしそれを怠ってしまったら、次の契約更改時にアウトソーサの選択肢が狭まってしまい、中長期的にはアウトソーサ選択のオルタナティブを狭める結果になるであろう。既存アウトソーサには契約を更改しなかった理由を真摯に伝え、次の契約更改までの情報提供や提案依頼を行い、健全な自由競争が維持されるように既存アウトソーサと大人の関係を保っておく必要がある。

■ お互いがプロとして尊敬し合えるパートナーシップ構築を

アウトソーサとの馴れ合いからは改善や進歩を生み出さないが、対決からも何も生まれない。サービス委託者はアウトソーサに対して一般に強い立場にあるが偉いわけではない。筆者の経験でも、よい仕事ができたなと思えたときは、必ず顧客からその道のプロとして接していただき、当方も顧客に対して尊敬できる関係になれた時だった。お互いがお互いをプロとして認め尊敬できる関係構築こそが、アウトソース成功の一番の秘訣といえるのではないだろうか。