1.はじめに「モノの時代からコトの時代へ」と言われるようになってもう随分経ちます。製造業においても、モノの製造だけでなくサービスの分野に進出する動きが活発化しています。例えばクルマを例に挙げてみましょう。これまで自動車メーカーにとってクルマは販売するものであって、販売した後、つまりユーザーがクルマを使う局面には、あまり大きな注意を払ってきませんでした。あえて言うならアフターサービスが該当しますが、これ自体が独立した価値提供というよりも、モノとしてのクルマの価値を補完するものでしかなかったと言えるでしょう。アフターサービスの良さがクルマという商品（モノ）の価値を高めることはあっても、「アフターサービス（コト）を受けたいから、そのクルマを買う」ということは無かったはずです。 しかし最近は、ＩＴと融合させることで、道路情報を提供したり周辺のスポットを案内したりといったサービスが生まれてきています。まだまだ途上であり、それらのサービスのためにクルマを選ぶというところまでは行ってないでしょう。しかし最近わたしの知人が、ある高級車に付随しているコンセルジェサービスを賞して、「これだけでもこのクルマを選んだ価値がある」と言っていました。これはまさにクルマというモノではなく、そのクルマを使うコトが価値を持ち始めているということでしょう。 このような変化には、作れば売れる時代が去り、多様で安価な工業製品があふれるモノ余りの世の中となったこと、顧客の求める価値が商品そのものから、その商品を使うことで「どんな問題を解決できるか」や、さらには「どんな体験・感動を得られるか」へと移ってきたということが背景にあります。 |
2.グッズ・ドミナント・ロジックとサービス・ドミナント・ロジック2004年に、マーケティング研究者であるロバート・F・ラッシュとステファン・L・バーゴによって提唱された「グッズ・ドミナント・ロジックからサービス・ドミナント・ロジックへの移行」という考え方があります。これまでのように、モノを経済活動の基本単位とする「グッズ・ドミナント・ロジック（GDL」から、すべての経済活動をサービスとしてとらえる「サービス・ドミナント・ロジック（SDL）」へと、世の中が移行しつつあるという考え方です。 グッズ・ドミナント・ロジックの場合、「世の中にはモノとモノ以外の何かがある」という前提を置きます。モノが先に定義され、サービスとはモノ以外の何かのひとつに過ぎないというとらえ方です。 一方サービス・ドミナント・ロジックでは、世の中で行われる経済活動はすべてサービスとしてとらえます。その中に「モノを伴うサービス」と「モノを伴わないサービス」があるに過ぎないということです。つまり、モノ以外としてサービスをとらえるのではなく、サービスの一形態としてモノをとらえる見方ともいえます。 サービス・ドミナント・ロジックの考え方における「製品」とは、顧客が利用することではじめて価値（使用価値・経験価値）を生み出すモノを指します。またその価値とは顧客とともに生み出すものであり、同じ製品であっても顧客によって価値は異なる、という考え方を取ります。それゆえその製品開発においても、製品自体の品質や機能だけではなく、その製品を使用する局面、使用することで得られる価値にフォーカスしなければならないのです。 | ||||||
3.受託開発はサービスなのか「グッズ・ドミナント・ロジックからサービス・ドミナント・ロジックへ」。少し様相は違いますが、私たちの情報サービス産業でも、これと同じ様なことが起こっていると言えます。もともと情報サービス産業と呼ばれてはいますが、その主流である受託開発ビジネスの実質は、グッズ・ドミナント・ロジックの考え方に近いと言ってよいのではないでしょうか。「（業務システムという）特定顧客向けのカスタムメイド製品を製造し納品することで対価を得る」という収益モデルだからです。納品後の維持管理フェーズについては、もちろんサービスと呼んで良いでしょう。しかしそれは自動車のアフターサービスの域を出ていません。 しかし近年になって、多様なクラウドサービスが広まり、簡単に「とりあえず使ってみる」「ダメだったらやめる」...といったことが出来るようになりました。以前は高価なＩＴをオーダーメイドしなければ得られなかったものが、ブラウザからサインアップするだけで簡単に使い始めることが出来るようになったのです。要するに、その業界のモノ（製品）のコモディティ化が進むと、サービスにシフトせざるを得ないということなのでしょう。 | ||||||
4.情報サービス企業のサービスシフトこのようなことを背景に、受託開発を中心にしてきたシステムインテグレーターにも「サービスシフト」という潮流が生まれてきました。シフトしようとしているサービスは、インターネット上でアプリケーションを公開し、使ってもらうことで収益を上げる「Ｗｅｂサービス」が大半です。 ではもう少し掘り下げて、Ｗｅｂサービスには、どのような収益モデルがあるかを見てみましょう。以下に主なものを３つ挙げます。
これまで受託開発を中心にしてきたシステムインテグレーターが新たにサービスビジネスを始める場合には「(1)サービス課金モデル」が圧倒的に多いようです。またその内容も、業務支援を行うＢ２Ｂサービスが中心ですが、その理由は、
|
5.サービスシフトを成功させるためにはしかしWebサービスは受託開発と大きく異なります。特にシステムインテグレーターがWebサービスを行う場合、大きく考え方を変える必要があるのですが、それは簡単ではありません。 一番大きな違いは、新たにサービスを立ち上げる段階ですが、この段階では、さまざまな違いをはっきり意識して取り組まれることが多く、また「リーンスタートアップ」として多くの書物や記事が参考になるので、この記事では省略します。それよりも、リリース後の運用こそ、それまでとは大きく異なる考え方でマネジメントする必要があるのですが、意外とこれが意識されておらず、受託開発の維持管理フェーズと同じような考え方でマネジメントされることでうまく行かない例が多いように思います。以降では、リリース後のサービス運用において、どのように「考え方」を変えるべきかを整理していきます。 |
- (a)要求はユーザーから発生しない
- 受託開発では維持管理フェーズにおいても、顧客が要求を提示することがスタートになります。つまり機能追加や変更の要望が提示されることで仕事が始まるのです。しかしWebサービスの場合、ユーザーに頼らず自分達で要求を抽出し、具体化しなければなりません。しかもユーザー自身すら気づいていないニーズを考え出す必要があるのです。
もしユーザーがサービス・プロバイダに明示的に要求を突き付けてきた場合（そのユーザー固有の事情に起因しない限り）、既にそのサービスにストレスを感じていることになります。ひょっとしたら手遅れかもしれません。しかもそのようなユーザーはむしろ稀でしょう。大半のユーザーは口を閉ざしたまま、他のサービスに乗り換えてしまいます。Webサービスは過酷な競争の世界であり、代替はいくらでもあるのです。 - (b)現在のーザーではなく潜在ユーザーをターゲットにする
- Webサービスの新たな機能を検討する場合、現在のユーザーのことだけを考えていてはいけません。まだそのサービスを使い始めていない潜在ユーザーの要求を実現してこそ、ユーザー数を増やすことになるからです。ひょっとしたらそれは、目の前の既存ユーザーへの対応よりも優先すべきことなのかも知れません。
- (c)売上・利益の考え方
- 利益とコストの考え方も大きく変える必要があります。少し細分化して考えてみましょう。
(1) 利益の再投資
基本的にその時点で得ている収益は、それ以前に構築した機能が生み出していると言えます。またその収益に対応するコストとは、サービスを安定的に稼働させるコスト（狭義の運用コスト）のみととらえる必要があります。良いサービスを構築し、ユーザー数が増えていけば、ほぼ一定の運用コストに対して利益が増えていきます。Webサービスの魅力（おいしさ）はここにあります。
しかし良いサービスほどすぐに競合するサービスが登場し、さらに上を行く機能が提供されるでしょう。より魅力的な機能を常に追加し、既存の機能も洗練させることでサービスを進化させないと、あっと言う間にユーザーを奪われてしまいます。得た利益はサービスを進化させるための再投資に回さなければなりません。機能の洗練・拡張のための工数を常に投入し続けるのです。(2) コストの分類
同じ構造を別の観点で考えてみましょう。あるWebサービスを維持しているチームの工数を層別した場合、「現状の機能を安定的に運用するために費やしている工数（狭義の運用コスト）」と「現状の機能を洗練する、あるいは新たな機能を追加するための工数」に分けることが出来るはずです。その上で、後者にちゃんと工数を投入できているかを管理し、促進することが、Webサービスのマネジメントです。
そのためには、よりタスクを細分化したかたちで見える化することで、客観的に計測するタスク管理の仕組みが必要になります。つまり現状維持と将来の投資のどちらにどれだけ工数を投入しているのかを把握し、後者により多くの工数を投入する仕掛けを作ることがマネジメントのポイントなのです。もし現状維持にばかり工数を投入しているのであれば、それは既に危険信号と言っていいでしょう。将来への投資が少ないサービスは、あっという間に競争力を失っていくからです。(3) 運用工数を最小化する
このように考えた場合、いかに（狭義の）運用コストを圧縮し、将来の投資に回すかが成功のカギと言えます。そのためには、現状の運用作業をタスクレベルで詳細に分析し、ムリ・ムダ・ムラを減らすことで原価低減を図るべきです。また自動化できるタスクは自動化していくことも有効でしょう。このような改善活動も将来のための投資と考えてマネジメントすべきです。(4) 投資の継続
先に挙げた収益モデルのどれであれWebサービスはユーザー数を増大させていくことが出来るかどうかが勝敗のカギになります。それゆえサービス終了(EoL : End of Life)のその時まで、投資を継続する必要があります。
これらをイメージにすると、図１のようになります。
図1 売上・利益の考え方
- (d)最初からEoL(End of Life)を考える
- 全てのWebサービスが成功するとは限りません。また成功したWebサービスであっても、いつかは終わりの時がくるでしょう。しかしその判断は非常に難しいものです。それゆえサービス立上げ当初から、EoLを定義しておくことが有効です。つまり「どのような状態（客観的な数値で表現する）になったら」「どのようにサービスを終了するのか」「サービス終了にどの程度の期間と工数を投入するか」を先に決めておくことは非常に重要です。
6.なぜサービスシフトは困難なのか残念なことに、受託開発中心だったシステムインテグレーターにとっては、上記のような発想の転換は非常に困難です。それは、なぜでしょうか。以下に整理します。
|
7.最悪のシナリオ例えば、あるシステムインテグレーターが、良いアイデアをもとに良いサービスを立ち上げた結果、そこそこ収益を上げている状態であったとします。しかし先に述べたように、「考え方」の転換が無いと、以下のような最悪のシナリオに進む可能性があります。
これはまさに負のスパイラルというべき状態です。売上が下がった時こそ、さらに工数を投入してサービスの魅力品質を向上させる必要があるにも関わらず、その発想が出来ていないことが原因です。そしてこのスパイラルの行きつく先は最悪の状況です。B2Bサービスの場合、ユーザーはそのサービスにストレスを感じていても、簡単にはサービスを離脱できません。おそらく主要な顧客ほどそのサービスの長く留まることになるでしょう。しかし他のユーザーが離脱すればするほど、新たな投資は減っていき、ちょっとした使い勝手の改善すら対応されなくなっていきます。その過程で、そのサービス提供会社に非常に悪い印象を積み上げてしまうことになります。 この記事の最初の方に、システムインテグレーターがB2Bサービスを始めるケースが多い理由として「受託開発ビジネスを通して得た顧客をターゲットにできる」を挙げましたが、その場合、会社の重要な顧客に対して、大きなマイナスイメージを与えることになってしまいます。それはひとつのビジネスへのダメージではなく、会社全体へのダメージなのです。 |
8.最後に以上のように、システムインテグレーターがサービスシフトを進めるにあたっての課題を見てきました。最後にその対策を説明して終わりたいのですが、実は良い対策はありません。あえて言うなら、Webサービスの組織を他の組織から切り離す（例えば子会社化するなど）ことで、制度もマネジメントも別にすることができれば、一定の効果があるでしょう。しかしそれでも、新組織でマネジメントする人の「考え方」が変わらなければ、やはり最悪のシナリオに向かって進んでしまいます。 著書「チェンジリーダーの条件」の中でドラッカーはこう言っています。「マネジメントとは何にもましてものの考え方である」と。 |
*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。
『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。
同一テーマ 記事一覧
「組織文化とは何か（１）」
2018.04.26 共通 株式会社オージス総研 山海 一剛
「ソフトウェア維持管理の現場改善（４）」
2017.03.24 共通 株式会社オージス総研 山海 一剛
「ソフトウェア維持管理の現場改善（３）」
2016.07.27 共通 株式会社オージス総研 山海 一剛
「ソフトウェア維持管理の現場改善（２）」
2015.11.20 共通 株式会社オージス総研 山海 一剛
「ソフトウェア維持管理の現場改善（１）」
2015.10.14 共通 株式会社オージス総研 山海 一剛
「リーンで高機動な開発のススメ（１）」
2014.08.13 共通 株式会社オージス総研 山海 一剛
「デンマークからのアジャイラーII」
2010.06.08 製造 株式会社オージス総研 山海 一剛
「デンマークからのアジャイラー」
2010.05.07 製造 株式会社オージス総研 山海 一剛