しょうもないROI算出に時間を使ってはいけない：久納と鉾木の「Think Big IT！」〜大きく考えよう〜（4）（2/3 ページ）

[久納信之／鉾木敦司,ServiceNow Japan]

ジューサーのように、ERPを戸棚に眠らせるつもりなのか？

　いったん、話をITに戻そう。例えば、全社を挙げてERPの導入を行ったとしよう。労力／時間／購買資材など、全てを合計すると何億、何十億円なんてケースもざらだ。Go-live（Cut Over）直後のサポート期間（early life support）では、プロジェクトチームが一丸となって問い合わせやインシデントに対応し、産みの苦しみの中で何とか安定稼働へとこぎ着けていく。

　次に来るステップは、このサポートオペレーションの定常運用体制への移行だ。これがなければ、ERPを導入したプロジェクトチームのメンバーは次のプロジェクトに進むことができない。そこで必要になってくるのが、問い合わせ、インシデント、変更要求などに対応する正規のサービスデスクとそのオペレーションプロセスだ。

　当然のことながら、サービスデスクの設置にはシステムや通信インフラの導入、人材確保や教育などの費用が必要になる。さて、大抵の企業において、ここである不可思議な問題が発生する。実のところ問題は2つ存在するのだが、1つは会社の上位マネジメントやファイナンス部門がこの「サービスデスク設置事案」に関して、

A.1つの単独プロジェクトとして費用の正当化（正当性証明）を求めてくる問題

　もう1つは

B.ROI算出による正当化（正当性証明）を求めてくる問題

だ。

　どういうことかと言うと「サービスデスク設置事案」が、ERPプロジェクトから独立して切り離され、その上でROI評価を求められるという状況に陥るのだ（ここではサービスデスクにフォーカスして話をしているが、その他の必須とされる監視やオペレーションを含めてITサービスマネジメント全般に同じことが言える）。

　このAとBという2つの問題をご覧になって、皆さんも違和感を覚えないだろうか？　それぞれ一緒に見てみよう。

A.「サービスデスク設置事案」の独立問題

　サービスデスクがあるおかげで、「ERPサービスの使い方などの質問にタイムリーに答えられる」「障害インシデントに早急に対応できる」「ビジネス変化に即応するための変更要求を正規の変更管理プロセスで吸い上げられる」わけだ。逆にサービスデスクがなければ、ERPサービスを安定的に利用することは難しい。つまり、サービスデスクは、「ERPサービスが顧客やユーザーに十分な価値を提供するために、ERPの価値を存続させ、価値を継続的に高めるために必須のもの」であり、「ERPサービスの一部」なのだ。この「必須の一部」というのがポイントだ。なのに、サービスデスク単独の事案として切り離して考えられ、単独で投資の正当性を求められるケースが多い。

　一方で、「ERP導入に際して発生するさまざまなインフラ整備」には、単独での正当性が求められない。例えば、自社製品の新たな出荷エリアにネットワークを導通させ、無線LANを整備し、新たな端末を確保しても、これらの費用はERPサービス（のエリア拡大）に必須の一部と見なされ、単独でのROI算出と費用の正当性は求められない。最初から「ERPプロジェクト本体に含むべきもの」として扱われているからだ。

　これはダブルスタンダードではないだろうか？　なぜインフラ整備はERPプロジェクト本体に含まれて、サービスデスクは含まれないのだろうか？

　「ERPサービスを構成する一連の必須要素」は、全て最初からERPプロジェクトに組み込まれているべきだし、最初から予算化されているべきだ。その上で、個々に発生する費用が全体最適の観点から妥当なものであるか、リーズナブルであるかの検証をすべきだ。「ジューサーの掃除や刃の交換コストまで勘案した上でジューサーを買うのか」を判断すべきなのと同じだ。サービスデスクだけ切り放して費用対効果を検証することは理に適わない。

　この矛盾は、整合性の取れないSLAという形でも馬脚をあらわしてくる。

　サービスデスク設置のROIを、サービスから切り離して算出しようとすると、どうしてもその期待効果の指標はありきたりなものに終始してしまう。MTTR（Mean Time To Recovery：平均修復時間）を筆頭に、質問に対する平均回答時間、1次回答率といった常連KPIがよく持ち出される。総じて言えば、サービスデスク導入によって、サービスレベルの向上がどれほど見込めるのかを何とか証明しようとするわけなのだが、サービスレベルは「サービス本体の特性や企業内での重要性」に照らし合わせて決めるべきものだということは皆さんにも合意いただけると思う。単純に、どんなサービスでもMTTRや平均回答時間などを極限まで短縮すれば良いというものではないのだ。

　第一に、企業にはビジネス目標がある。そこから逆算してERPサービスの重要性が見定められる。そして、それに基づいて稼働率やスループット、サポートのあるべきレベルが決定され、具体的なKPIの設定とその数値目標に落とし込まれる。つまり、KPIとその目標値も、やはりERPサービスと切り離して検討すべきものではなく、ビジネス目的に基づく各種KPIの正当性についてユーザーと議論し、合意形成（Service Level Agreement）を進めてこそ意味を成してくるものなのだ。

　ところが、今多くの現場で書かれている稟議書では、単独事案としてERPとは切り離された“無難なKPI”が設定され、何とか捻り出したロジックとともに効果がうたい上げられている。肝心のサービスと切り離されて考えられている以上、こんな状況で信憑性のある費用対効果が示せるわけがない。結論として、具体性や説得力に欠ける起案と見なされ、「サービスデスク設置に必要な予算が確保できない」ということになってしまう。買った後のことをよく考えていなかったジューサーのように、ERPを戸棚に眠らせるつもりなのか？

B.ROI不適合問題

　今から20年ほど前は、IT投資の正当性証明の際にROIモデルを用いることは非常に有効であった。なぜなら時代は高速化、最大化のフェーズにあったからだ。

　当時は、それまで手作業で行われていたオペレーションを自動化する、旧世代のコンピュータ上で行われていた処理を最新の機種に載せ替える、といったIT化の効果を得やすい業務が、企業内に十分な量存在していた。よって、かき集めた同質の既存業務を一網打尽にIT化すれば、高速化、最大化を標榜しやすく、ROI算出は強力な正当化の武器となった。

　時を経て、現在ではどうか？

　時代は俊敏性、最適化のフェーズにある。効果の得やすい社内業務は既にあらかたIT化された。現在では、ビジネス判断に即応し、ただちに何かを試してその結果を検証したり、効果が出そうな領域に素早く限られたリソースを集中させたりするような俊敏性、最適化を可能にするIT基盤が求められる。

　この手の起案と、ROIモデルはそもそも相いれない。なぜなら、従来のように「その基盤上に、どういった性質の業務が、どれだけの量で出現するか」をあらかじめ予測することは困難だからだ。ROIモデルは万能薬ではない。こういったケースでは、ROIのロジックを捻り出している時間自体が無駄になってしまう。

編集部注：先を予測することが難しい以上、「速く失敗して、速く学び、速く改善すること」が、ITサービス開発などデジタルトランフォーメーションの取り組みにおいては、成功の鉄則といわれています。「そうした取り組みに最初からROIを求めるのはそもそもナンセンスだ」という意見は、取材でも実際によく耳にします（画像はイメージです）