Webマガジン
「サービスシフトのためのマネジメント改革」
株式会社オージス総研

2017年06月号
  • 「サービスシフトのためのマネジメント改革」
株式会社オージス総研   山海 一剛

1.

はじめに

「モノの時代からコトの時代へ」と言われるようになってもう随分経ちます。製造業においても、モノの製造だけでなくサービスの分野に進出する動きが活発化しています。例えばクルマを例に挙げてみましょう。これまで自動車メーカーにとってクルマは販売するものであって、販売した後、つまりユーザーがクルマを使う局面には、あまり大きな注意を払ってきませんでした。あえて言うならアフターサービスが該当しますが、これ自体が独立した価値提供というよりも、モノとしてのクルマの価値を補完するものでしかなかったと言えるでしょう。アフターサービスの良さがクルマという商品(モノ)の価値を高めることはあっても、「アフターサービス(コト)を受けたいから、そのクルマを買う」ということは無かったはずです。
しかし最近は、ITと融合させることで、道路情報を提供したり周辺のスポットを案内したりといったサービスが生まれてきています。まだまだ途上であり、それらのサービスのためにクルマを選ぶというところまでは行ってないでしょう。しかし最近わたしの知人が、ある高級車に付随しているコンセルジェサービスを賞して、「これだけでもこのクルマを選んだ価値がある」と言っていました。これはまさにクルマというモノではなく、そのクルマを使うコトが価値を持ち始めているということでしょう。
このような変化には、作れば売れる時代が去り、多様で安価な工業製品があふれるモノ余りの世の中となったこと、顧客の求める価値が商品そのものから、その商品を使うことで「どんな問題を解決できるか」や、さらには「どんな体験・感動を得られるか」へと移ってきたということが背景にあります。

2.

グッズ・ドミナント・ロジックとサービス・ドミナント・ロジック

2004年に、マーケティング研究者であるロバート・F・ラッシュとステファン・L・バーゴによって提唱された「グッズ・ドミナント・ロジックからサービス・ドミナント・ロジックへの移行」という考え方があります。これまでのように、モノを経済活動の基本単位とする「グッズ・ドミナント・ロジック(GDL」から、すべての経済活動をサービスとしてとらえる「サービス・ドミナント・ロジック(SDL)」へと、世の中が移行しつつあるという考え方です。
グッズ・ドミナント・ロジックの場合、「世の中にはモノとモノ以外の何かがある」という前提を置きます。モノが先に定義され、サービスとはモノ以外の何かのひとつに過ぎないというとらえ方です。
一方サービス・ドミナント・ロジックでは、世の中で行われる経済活動はすべてサービスとしてとらえます。その中に「モノを伴うサービス」と「モノを伴わないサービス」があるに過ぎないということです。つまり、モノ以外としてサービスをとらえるのではなく、サービスの一形態としてモノをとらえる見方ともいえます。
サービス・ドミナント・ロジックの考え方における「製品」とは、顧客が利用することではじめて価値(使用価値・経験価値)を生み出すモノを指します。またその価値とは顧客とともに生み出すものであり、同じ製品であっても顧客によって価値は異なる、という考え方を取ります。それゆえその製品開発においても、製品自体の品質や機能だけではなく、その製品を使用する局面、使用することで得られる価値にフォーカスしなければならないのです。

3.

受託開発はサービスなのか

「グッズ・ドミナント・ロジックからサービス・ドミナント・ロジックへ」。少し様相は違いますが、私たちの情報サービス産業でも、これと同じ様なことが起こっていると言えます。もともと情報サービス産業と呼ばれてはいますが、その主流である受託開発ビジネスの実質は、グッズ・ドミナント・ロジックの考え方に近いと言ってよいのではないでしょうか。「(業務システムという)特定顧客向けのカスタムメイド製品を製造し納品することで対価を得る」という収益モデルだからです。納品後の維持管理フェーズについては、もちろんサービスと呼んで良いでしょう。しかしそれは自動車のアフターサービスの域を出ていません。
しかし近年になって、多様なクラウドサービスが広まり、簡単に「とりあえず使ってみる」「ダメだったらやめる」…といったことが出来るようになりました。以前は高価なITをオーダーメイドしなければ得られなかったものが、ブラウザからサインアップするだけで簡単に使い始めることが出来るようになったのです。要するに、その業界のモノ(製品)のコモディティ化が進むと、サービスにシフトせざるを得ないということなのでしょう。

4.

情報サービス企業のサービスシフト

このようなことを背景に、受託開発を中心にしてきたシステムインテグレーターにも「サービスシフト」という潮流が生まれてきました。シフトしようとしているサービスは、インターネット上でアプリケーションを公開し、使ってもらうことで収益を上げる「Webサービス」が大半です。
ではもう少し掘り下げて、Webサービスには、どのような収益モデルがあるかを見てみましょう。以下に主なものを3つ挙げます。
(1)サービス課金モデル サービスを利用することに対して、ユーザーに直接課金するモデルです。
(2)広告収入モデル ユーザーには無料で使用してもらい、広告掲載を行うことで広告主から収益を得るモデルです。
(3)マッチングモデル 掲載側とユーザーとのマッチングを行い、結果に応じて掲載側から報酬を得るモデルです。
これまで受託開発を中心にしてきたシステムインテグレーターが新たにサービスビジネスを始める場合には「(1)サービス課金モデル」が圧倒的に多いようです。またその内容も、業務支援を行うB2Bサービスが中心ですが、その理由は、
  • 受託開発ビジネスを通して得た顧客をターゲットにできるので、新規に顧客開拓するオーバーヘッドが少ないこと。
  • それまでの業務アプリケーション構築のノウハウが活かせること
の2つではないでしょうか。特に後者については、既存のパッケージをマルチテナント化した上でクラウドに移行して、手っ取り早くサービスを立ち上げる例も少なくありません。

5.

サービスシフトを成功させるためには

しかしWebサービスは受託開発と大きく異なります。特にシステムインテグレーターがWebサービスを行う場合、大きく考え方を変える必要があるのですが、それは簡単ではありません。
一番大きな違いは、新たにサービスを立ち上げる段階ですが、この段階では、さまざまな違いをはっきり意識して取り組まれることが多く、また「リーンスタートアップ」として多くの書物や記事が参考になるので、この記事では省略します。それよりも、リリース後の運用こそ、それまでとは大きく異なる考え方でマネジメントする必要があるのですが、意外とこれが意識されておらず、受託開発の維持管理フェーズと同じような考え方でマネジメントされることでうまく行かない例が多いように思います。以降では、リリース後のサービス運用において、どのように「考え方」を変えるべきかを整理していきます。
(a)要求はユーザーから発生しない
受託開発では維持管理フェーズにおいても、顧客が要求を提示することがスタートになります。つまり機能追加や変更の要望が提示されることで仕事が始まるのです。しかしWebサービスの場合、ユーザーに頼らず自分達で要求を抽出し、具体化しなければなりません。しかもユーザー自身すら気づいていないニーズを考え出す必要があるのです。
もしユーザーがサービス・プロバイダに明示的に要求を突き付けてきた場合(そのユーザー固有の事情に起因しない限り)、既にそのサービスにストレスを感じていることになります。ひょっとしたら手遅れかもしれません。しかもそのようなユーザーはむしろ稀でしょう。大半のユーザーは口を閉ざしたまま、他のサービスに乗り換えてしまいます。Webサービスは過酷な競争の世界であり、代替はいくらでもあるのです。

(b)現在のーザーではなく潜在ユーザーをターゲットにする
Webサービスの新たな機能を検討する場合、現在のユーザーのことだけを考えていてはいけません。まだそのサービスを使い始めていない潜在ユーザーの要求を実現してこそ、ユーザー数を増やすことになるからです。ひょっとしたらそれは、目の前の既存ユーザーへの対応よりも優先すべきことなのかも知れません。

(c)売上・利益の考え方
利益とコストの考え方も大きく変える必要があります。少し細分化して考えてみましょう。

(1)
利益の再投資
基本的にその時点で得ている収益は、それ以前に構築した機能が生み出していると言えます。またその収益に対応するコストとは、サービスを安定的に稼働させるコスト(狭義の運用コスト)のみととらえる必要があります。良いサービスを構築し、ユーザー数が増えていけば、ほぼ一定の運用コストに対して利益が増えていきます。Webサービスの魅力(おいしさ)はここにあります。
しかし良いサービスほどすぐに競合するサービスが登場し、さらに上を行く機能が提供されるでしょう。より魅力的な機能を常に追加し、既存の機能も洗練させることでサービスを進化させないと、あっと言う間にユーザーを奪われてしまいます。得た利益はサービスを進化させるための再投資に回さなければなりません。機能の洗練・拡張のための工数を常に投入し続けるのです。

(2)
コストの分類
同じ構造を別の観点で考えてみましょう。あるWebサービスを維持しているチームの工数を層別した場合、「現状の機能を安定的に運用するために費やしている工数(狭義の運用コスト)」と「現状の機能を洗練する、あるいは新たな機能を追加するための工数」に分けることが出来るはずです。その上で、後者にちゃんと工数を投入できているかを管理し、促進することが、Webサービスのマネジメントです。
そのためには、よりタスクを細分化したかたちで見える化することで、客観的に計測するタスク管理の仕組みが必要になります。つまり現状維持と将来の投資のどちらにどれだけ工数を投入しているのかを把握し、後者により多くの工数を投入する仕掛けを作ることがマネジメントのポイントなのです。もし現状維持にばかり工数を投入しているのであれば、それは既に危険信号と言っていいでしょう。将来への投資が少ないサービスは、あっという間に競争力を失っていくからです。

(3)
運用工数を最小化する
このように考えた場合、いかに(狭義の)運用コストを圧縮し、将来の投資に回すかが成功のカギと言えます。そのためには、現状の運用作業をタスクレベルで詳細に分析し、ムリ・ムダ・ムラを減らすことで原価低減を図るべきです。また自動化できるタスクは自動化していくことも有効でしょう。このような改善活動も将来のための投資と考えてマネジメントすべきです。

(4)
投資の継続
先に挙げた収益モデルのどれであれWebサービスはユーザー数を増大させていくことが出来るかどうかが勝敗のカギになります。それゆえサービス終了(EoL : End of Life)のその時まで、投資を継続する必要があります。

これらをイメージにすると、図1のようになります。
売上・利益の考え方
図1 売上・利益の考え方
(d)最初からEoL(End of Life)を考える
全てのWebサービスが成功するとは限りません。また成功したWebサービスであっても、いつかは終わりの時がくるでしょう。しかしその判断は非常に難しいものです。それゆえサービス立上げ当初から、EoLを定義しておくことが有効です。つまり「どのような状態(客観的な数値で表現する)になったら」「どのようにサービスを終了するのか」「サービス終了にどの程度の期間と工数を投入するか」を先に決めておくことは非常に重要です。

6.

なぜサービスシフトは困難なのか

残念なことに、受託開発中心だったシステムインテグレーターにとっては、上記のような発想の転換は非常に困難です。それは、なぜでしょうか。以下に整理します。
  1. 要求についての考え方
    受託開発において要求は必ずユーザーから提示されるものであるため、主体的に要求を作り出すという経験がありません。またその場合、ユーザーの使い方を分析すれば良いと考えがちですが、それでは新規ユーザーの獲得につながる新しいアイデアにはつながりません。要するに要求を開発すること自体に慣れていないのです。
    また受託開発では、当初定義した要求事項が開発途上で変化・増大してしまうことは、プロジェクトの大きなリスクにつながります。それゆえ要求を膨らませるということ自体に本能的な警戒心があるようです。サービスをより良い方向に進化させるためにはコストや実現可能性を無視し、夢や妄想レベルにまで発想を広げないと良いアイデアは出ないのですが、受託開発を長く経験したエンジニアは「要求は抑えるべきもの」という思考パターンが刷り込まれており、無条件にその本能が発動して自由な発想を阻害するようです。これはマネジメントの問題ではなく、マインドセットの問題と言えるでしょう。

  2. コストについての考え方
    先にも述べたように、Webサービスの場合、現在の利益を将来の投資に回すという発想が必要です。一方、受託開発案件の維持管理フェーズの場合、「月単位に、契約金額(売上)に対して、利益を出せる工数まで投入する」というかたちになります。つまり月という短い期間に閉じて、売上・利益を評価するかたちでマネジメントされており、先に述べた「今の利益を将来の投資に回す」といった考え方とは真逆の発想になります。
    残念ながらシステムインテグレーターがWebサービスを運用する場合、受託開発案件の維持管理フェーズと同じ考え方で収益を評価している例が多いように見えます。つまり受託案件の維持管理とWebサービスが、同じルールでマネジメントされてしまうわけですが、これでは将来への投資が促進されません。これはマネジメントの問題であると同時に、制度(ビジネスの収益性を評価する仕組み)の問題であるとも言えます。

  3. EoLについての考え方
    システムインテグレーターは、そもそもサービスの終了について考えること自体が無いと思います。受託開発ビジネスのスコープは、システムを開発してリリースするまで。納品したシステムの終焉とは、システムのリプレース案件であり、取って代わる新たなシステムの方に目が移ってしまっています。しかしWebサービスにおいてEoLは非常に重要です。特にB2Bサービスの場合、ユーザーはそのサービスを業務に使っているわけですから、出来る限り迷惑をかけないよう慎重に進める必要があります。そしてそれには手間も時間もかかります。だからこそ事前にEoLを定義しておく必要があるのですが、その重要さに気づかないケースが多いようです。

7.

最悪のシナリオ

例えば、あるシステムインテグレーターが、良いアイデアをもとに良いサービスを立ち上げた結果、そこそこ収益を上げている状態であったとします。しかし先に述べたように、「考え方」の転換が無いと、以下のような最悪のシナリオに進む可能性があります。
  1. 当初はユーザー数も順調に伸び、利益が増え続けていたが、競合サービスが登場したことで利益に陰りが見え始める
  2. 現在の売上に対して、現在の運用体制が妥当か?という短期的観点で評価してしまうので、売上が下がれば体制を縮小する
  3. 結果としてサービス進化のための投資が削られることになり、競合サービスとの差が開いていく
  4. サービスの進化が鈍化することでユーザーが徐々に離脱していき、売上が減少する
  5. 減少した売上に見合った体制へとさらに縮小されることで、さらに進化が鈍化する
これはまさに負のスパイラルというべき状態です。売上が下がった時こそ、さらに工数を投入してサービスの魅力品質を向上させる必要があるにも関わらず、その発想が出来ていないことが原因です。そしてこのスパイラルの行きつく先は最悪の状況です。B2Bサービスの場合、ユーザーはそのサービスにストレスを感じていても、簡単にはサービスを離脱できません。おそらく主要な顧客ほどそのサービスの長く留まることになるでしょう。しかし他のユーザーが離脱すればするほど、新たな投資は減っていき、ちょっとした使い勝手の改善すら対応されなくなっていきます。その過程で、そのサービス提供会社に非常に悪い印象を積み上げてしまうことになります。
この記事の最初の方に、システムインテグレーターがB2Bサービスを始めるケースが多い理由として「受託開発ビジネスを通して得た顧客をターゲットにできる」を挙げましたが、その場合、会社の重要な顧客に対して、大きなマイナスイメージを与えることになってしまいます。それはひとつのビジネスへのダメージではなく、会社全体へのダメージなのです。

8.

最後に

以上のように、システムインテグレーターがサービスシフトを進めるにあたっての課題を見てきました。最後にその対策を説明して終わりたいのですが、実は良い対策はありません。あえて言うなら、Webサービスの組織を他の組織から切り離す(例えば子会社化するなど)ことで、制度もマネジメントも別にすることができれば、一定の効果があるでしょう。しかしそれでも、新組織でマネジメントする人の「考え方」が変わらなければ、やはり最悪のシナリオに向かって進んでしまいます。
著書「チェンジリーダーの条件」の中でドラッカーはこう言っています。「マネジメントとは何にもましてものの考え方である」と。

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。

同一テーマ 記事一覧
山海 一剛  記事一覧
2017年06月号のコンテンツ
『Webマガジン』に関しては 弊社の「個人情報の取り扱いについて」に同意の上、
下記よりお気軽にお問い合わせください。

ページトップへ戻る