検索
特集

ITサービスの目的は「速く届けること」ではなく「価値を届けること」そもそも「サービス」とは何か?

IoT、X-Techトレンドの浸透を受け、各業種でITサービス開発競争が活発化している。これに伴い「開発するスピード」ばかりが注目されがちだが、言うまでもなく、ITサービスはリリースして終わり、ではない。リリース後こそ満足度を向上させていく必要がある。ではITサービスの価値を継続的に高め続けていくためには具体的にどうすればよいのだろうか?

PC用表示 関連情報
Share
Tweet
LINE
Hatena

従来型企業がITサービス競争に勝つために必要なこととは?

 デジタルトランスフォーメーションのトレンドが各業種に広がっている。もはやUberの例を出すまでもなく、「ITの力で実現した全く新しいサービス」に多くの企業が危機感を抱き、ITサービス開発に乗り出すケースも増えつつある。これを受けてIT開発=ビジネス開発といった認識も着実に浸透しつつあるようだ。

 こうした潮流の中で注目すべきは、企業の提供価値が「モノ」ではなく、それを通じて得られる「体験」に変わっていることだろう。IoTにせよX-Techにせよ、求められているのは「アプリケーションそのもの」ではなく「それによって得られる利便性」だ。

 周知の通り、ITサービス競争で勝負のカギを握るのは、競合に先駆けてサービスを開発・改善する「スピード」とされている。だが「体験」が売り物である以上、サービスがもたらす体験価値を担保・改善し続けなければ、使われなくなるか、かえって逆効果になってしまう。「いかに新規性あるサービス企画を迅速に作るか」ばかりが注目されがちだが、真に収益・ブランドを左右するのは、リリースした後なのだ。

 では「速く開発・リリースする」だけではなく、「より良い体験」を届け続けるためにはどうすればよいのだろうか? 特にデジタルの戦いは、最初からデジタルビジネスに特化した比較的小規模な企業が、従来型企業の市場に仕掛けるケースが中心だ。だが一般に、多数の部門が存在する従来型企業の場合、「関係組織が連携してニーズの変化に俊敏に対応する」ことはなかなか難しい。それが既存事業ではなく、ITサービスという新規ビジネスであればなおさらだ。そうした中でも、従来型企業がディスラプターに負けず、「より良いサービス」を届け続けるためにはどうすればよいのか?――

 本稿では、デジタルビジネスとサービスマネジメントに深い知見を持つ、ServiceNow Japan ソリューションコンサルティング本部 エバンジェリストの久納信之氏にインタビュー。デジタルビジネスの軸となる「サービス」という概念を確認するとともに、「より良い体験」をスピーディに提供し、継続的に改善するための「仕組み」を聞いた。

そもそもIT「サービス」とは何か?

 「ITサービスに限らず、昨今は企業の提供価値がモノ自体ではなく、それを通じた『より良い体験』に変わってきていると考えます。例えば自動車メーカーなら移動という体験を売る。消費財メーカーならより良い生活体験を売る。現金ですら、仮想通貨によってどのような体験価値をもたらすことが望ましいのか、あらためて問われているのが今ではないでしょうか」

ALT
久納信之氏 ServiceNow Japan ソリューションコンサルティング本部 エバンジェリスト

 激化するITサービス競争の背景について、久納氏はこう概観する。こうした中、エンドユーザーの支持を獲得する上では、サービスの「利便性、簡潔さ、透明性、提供・改善のスピード」がポイントになるとされている。実際、これらはAWS、Google、Facebookなど、支持されているITサービスの共通点だ。だが久納氏は、「これらだけで良いサービスが成立するわけではありません」と付け加える。

 「そもそもサービスとは、それを支えるプロセス、テクノロジー、人、パートナーの“組み合わせからなる価値”を提供するものです。この価値とは『有用性』と『保証』の2つを指しています。有用性とは『そのサービスを使うことで、“より良い結果が得られる”こと』、保証とは『そのサービスを使いたいとき、常に使える状態にあること』。つまり、より良い結果を継続的に提供し続けられることが、サービスとして成立する前提条件となるのです」

 例えばERPで言えば、単に「稼働する」というだけではなく、そのカスタマー(ビジネスに責任を持つ管理職)とエンドユーザーに対して期待されているビジネス価値を提供する必要がある。システムが止まって取引が滞ることのないよう、常に安定して動いている必要もある。これが「有用性」と「保証」だ。こう聞くと当たり前のようだが、この当たり前のことが意外とできていないことが多い。

 ERPなら、その提供価値はエンドユーザーが使うPCやタブレット、社内ネットワーク機器、取引先とやりとりするための電話やFAX、それらをオペレーションするプロセスや人など、実にさまざまなものが支えている。それらが全て機能して初めてサービスとしての有用性や保証を担保できるのだが、在庫管理、販売管理など、個別の各種機能にばかり注目してしまい、サービスという単位で考えられていることが少ない。

 「実際に、ERP導入でよくある失敗の1つとして、予算や納期が後になって膨らむという問題があります。こうした失敗のほとんどは、事前に“サービスの単位”を見誤まっていることが原因です。例えば、ERPを操作するためのPC、マニュアルまでは確保したが、サービスデスクは設置しなかった。そのため運用が始まってから、システムの操作が分からないといった問い合わせがばらばらに行き交ってしまい、導入初期の安定化期間が長期化する。しかもサービスデスクの設置が別プロジェクト扱いとなってERPプロジェクトと同期がとられていないどころか予算も別であったりする、といった具合です。これではERPの価値を届けられません」

 つまりサービスは、「機能」という単位で考えるのではなく、「価値を提供し継続的改善ができるまで」という単位で捉える。価値を支えるテクノロジー、人、パートナー、プロセスといった全要素を見据えて、きちんとサービスの「有用性」と「保証」を担保する“仕組み”を作ることが重要なのだ。

ITサービスマネジメントはサービス価値を担保するためのフレームワーク。マニュアルではない

 久納氏は「ここで重要なのは、そうした仕組みの在り方はサービスの価値によって変わってくることです」と話す。

 例えばスマートフォンを例にとれば、『たくさんのアプリを利用できて便利』なことが1つの価値だ。だがユーザーにとって「重要なアプリがインストールできない」「必須のアプリの動作が遅くて使いものにならない」と価値=「有用性」はなくなってしまう。そこで「問題があった際は、迅速に不具合を修正してサービスを快適に使えるようにする」という「保証」が必要になる。そのために、迅速なサービス再開を支えるサポートデスクを設置するといった手立てが必要となる場合もある。

 「つまり、ユーザーがスマートフォンとアプリに見出す価値が変われば、保証の中身も、そのための手立ても変わるということです。価値提供の仕組みは、価値の中身に応じて変わるのです」

 これが社内向け/社外向け問わず、ITサービス全般にも当てはまることは言うまでもない。例えばヘルプデスクでも、「ヘルプデスクありき」で考えるのではなく、サービスの成立に必要なら取り入れる。その上で、問い合わせ窓口としてコールセンター機能まで用意すればよいのか、あるいは問題を解決するサービスデスク機能まで持たせるかを判断する。

 では、こうした価値を提供できる「仕組み」を、ヌケなく、より確実・効率的に検討する上ではどうすればよいのだろうか?――久納氏は「そうした課題に応えるものが、ITサービスマネジメントです」と話す。

 「ITサービスマネジメントは、ITサービスの有用性と保証をマネジメントしていくためのフレームワーク。ビジネスニーズに基づいて期待する価値を提供できる戦略を考え、サービスを設計し、運用し、継続的に改善していく仕組みを作るための手掛かりとなるものなのです」

 フレームワークであり、決して規格マニュアルではない。前述したスマートフォンの例のように、「価値」の中身が変われば、その「有用性」「保障」を担保するための仕組みも変わる。そうした各社各様の「価値を担保する仕組み」を導き出すための考え方がITサービスマネジメントなのだ。

 「一般に、ITサービスマネジメントは、インシデント管理など『ITを日々効率的に運用するための“手段”』と理解されている傾向も強いようですが、それは誤解です。ビジネスデマンドからサービス戦略策定、設計、構築、オペレーション、継続的改善、そしてそれらを支える要員のスキル向上、組織のあり方までも包含した考え方、フレームワークなのです。従って、サービスの価値という目的起点で考えるものである以上、『サービスデスクを入れたからITサービスマネジメントが全てできる』といった考え方ももちろん誤りです」

 こうした理解を前提にすれば、ITIL(Information Technology Infrastructure Library)の見え方も変わってくるのではないだろうか。言うまでもなく、ITILはITサービスオペレーションのベストプラクティス集であり、「こうすれば良い」といったマニュアルではない。各社がITサービスの価値を担保するための仕組みを考える上で、参考として使うべきものにすぎない。

 「ITILに対する誤解として、ウォーターフォール型の重厚長大な開発に適用するもので、アジャイルと違って慎重にじっくりと進めるもの、といった見方をされることがありますが、決してそうしたものではありません」とも指摘する。

 「ITサービスマネジメントに取り組む初期段階において、ITILが推奨している手法は“ローハンギングフルーツ”――低い位置にあるもぎ取りやすい果実からもぎ取れ、ということ。例えばサービスを提供するまでの時間など、価値提供の在り方にKPIを設定して、スピーディーな改善を狙います。はしごを組んでじっくり計画を立てて成果を取るのではなく、むしろスモールステップ/クイックウィンで、小さく始めて、小さな成功をスピーディに積み重ねていくものなのです」

IT部門だけではなく、全部門が「サービサー」であるべきだ

 こうした「ITサービスの価値を確実に提供、改善し続ける」ための取り組みは、当然ながらIT部門がリードする必要がある。特に「速く作る」ことは競争参加の大前提であり、提供価値が本当の勝負である以上、ニーズが激しく変化する中でも価値をしっかりと届けられる仕組み作りは、従来型企業がスタートアップと戦う上で喫緊の課題となっていると言ってもいいだろう。

 だが前述のように、ITサービスはテクノロジーだけの問題ではない。価値を確実に提供するためには、人、プロセス、パートナーなど「テクノロジー以外の要素」も視野に入れて調整しなければ、結局「速く作る」ことはできない。ではIT部門が社内にITサービスマネジメントの仕組みを整備していくためには、何から取り組めばいいのだろうか? 久納氏が勧めるのは「サービスマネジメントという概念」の共有だ。

 「サービスマネジメントの考え方を全社で共有することが第一歩です。これに基づきITサービスを支える各部門が連携することで、期待する成果を確実に得られるようになるはずです。また、人事、法務、経理、総務といった各部門も『社内のエンドユーザーに、サービスを提供しているサービス部門』と位置付けることをお勧めします。例えば会計の決算処理や、法務の契約処理なども“サービス”です。そうしたサービス提供が速くなれば、ビジネス展開も当然速くなります。場合によっては、IT部門が提供するサービスのように、会計処理や契約処理についてもSLAを設定し、SLAの達成度で部門の業績を評価したり改善につなげたりする仕組みも考えることができます」

 このような「価値を生み出す仕組み」をイチから考えるのは非現実的だが、サービスマネジメントというフレームワークやITILというベストプラクティスをIT部門以外にも応用することで、“価値を生む自社なりの仕組み”を作る上で大いに参考にできるわけだ。「体験」というサービスのビジネス潮流を考えると、ITILやITサービスマネジメントの応用範囲と重要性は今後高まるといえる。

 概念を浸透させるために、ツールを利用することも有効だという。例えば久納氏が所属するServiceNowでは、サービスマネジメントの仕組み作りや、価値提供のプロセス遂行を支援するツールを提供している。

 「こうした取り組みで重要なのは、シンプリフィケーション、スタンダリゼーション、コミュニケーション。できるだけ簡単にして、誰でも取り組めるようノウハウを標準化していく。そして必要な情報をスムーズに交換・共有できる仕組みを整備することがポイントです」

ALT
「きちんとサービスの『有用性』と『保障』を担保できているかどうか、ITサービスの価値提供の在り方を見直してみると、さまざまな発見があるはず。IT部門のみならず、全部門がサービス提供者としてサービスマネジメントの考え方を取り入れると、会社としてのビジネス展開のスピード・質の向上に大いに役立ちます」

 久納氏は、「まずはIT部門が各種ITサービスの価値をきちんと担保できるよう、小さなことからでも取り組むことが大切」と力説する。例えば、価値の有用性と保証を担保するために、インシデント管理を実施しているなら、よく起こるトラブルを可視化して把握しておき、次に起こりそうな兆候が現れたら見極めて事前に対策を打つ。これによってサービスの有用性は確実に上がる。

 「社内向け/社外向け問わず、IT活用の在り方がビジネスの成果に直結している今、ITサービスの価値が強く問われている状況です。自分たちの提供しているITサービスが有用性と保障をしっかりと担保できているかどうか、あらためて確認してはいかがでしょうか。価値を担保する仕組みを整え、価値提供の在り方にKPIを設定し、対応をリアクティブからプロアクティブに変えるだけで、ビジネス部門から一目置かれるようになるはずです。まず現在の価値提供の在り方を見直し、小さなことからでも“変革”を始めてみてはいかがでしょうか」

Copyright © ITmedia, Inc. All Rights Reserved.

[an error occurred while processing this directive]
ページトップに戻る