February 2013 Archives

■    身近なところから始めてみたら

何度も繰り返してしつこいと思われるかもしれませんが、設計といってもITシステムを設計するわけではありません。どんなサービスをどんなふうに提供したら喜ばれるのかということ、すなわち"スタイル"のようなものを設計することが大事になってきます。ですから、企業でいえば社風とか事業方針といったものが反映されてくるわけです。

そう考えると、ITはひとまず置いておいておもてなしのスタイルを考えましょうというのが出発点のようです。これだと、何か身近にありそうですよね。会社の業務ではなくても、例えば何かのイベントを行うとか、ボランティアなんかもそうだし、簡単な例でいくと、職場の忘年会の幹事に指名された時を想定してみてください。

ある日、部長からお前今年の忘年会を企画してくれと依頼されたらあなたはどうしますか?参加するみんなが喜ぶような企画・計画をしますよね。そして、実行して皆さんが満足できたらうれしいと思うはずです。そのためにどうしたらよいのかが設計となるわけです。ここで気がつくと思いますが、そんなことにITシステムを設計するだろうか。もちろん、計画を進めてたり、実行するときにITを使いますが、それはあくまで道具として使うわけです。

言い方はおかしいのですが、忘年会開催プロセスも立派なプロセスです。では、実際にプロセス的に追っかけてみましょう。まずは、部長からだいたいこのあたりで、部全体でやろうぐらいな言い方で頼まれるはずです。さらに、今は業績も良くないのであまり派手にはやらない方がいいだろうといった制約を言われることもあるでしょう。

忘年会の開催を頼まれ、それに応えて実施するまでの手順がプロセスですから、さてどうしましょうかと考えたとき、おそらくいつまでに何を決めたらよいのかということが浮かぶと思います。つまり、決めるべきこと、それはいつまでなのか、決めるにはどんな情報を参照するのか、制約条件はあるのか、だれに相談をしたらよいのかといったことになるでしょう。

もう少し具体的に見ていくと、わかりやすいのは5W1Hで考えたらよいでしょう。まあ目的は忘年会だからWhyは除いてもいいので、まずはいつでしょうね。日時(When)を決めます。次に場所(Where)、そしてどんな形式や会費(What)にするのか、それが決まると参加者(Who(m))を募集します。さらに当日の進行(How)を決めて実施ということになると思います。

ただ、こうしたことが簡単に決められるとは限りません。日時にしても部の業務のスケジュールとか部長の出張の日とかをチェックするはずです。場所はそれこそ「ぐるなび」や「食べログ」で調べるとか、過去に評判がよかったところとかを探しますよね。また、出欠をとるのにメールじゃないアプリを使うでしょう。

ですから、プロセスを実行するうえで決めなくては行けないこと、それを決めるときに参考とする情報や制約、それがいつまでなのかという管理指標などを定義していくのがプロセス設計なのです。そこに全体の進捗が見えるようにするためとか、情報がネットからリンクされるとか、通知配信する仕組みとか、そういったところで必要に応じてITを使うことだと思います。

当たり前のことですが、この幹事さんが、スマホだけで忘年会を企画・計画・実施したからといって、プロセス設計、オペレーションをしていないとは言えないでしょう。自分の手帳に手書きで書いてそれをチェックしながらやるのもプロセスオペレーションです。つまり誰でもやっていることなのだが、それをもっと明示的にオープンにして行くことなのだが、そのためには前回提起したように標準的構造化をしたWhatが必要で、その構造にあった中味をデザインすることが大切なのです。
  

ビジネスサービスのつくり方 - 第3章 設計■    WhatはHowに優先する
サービスの構成要素とサービスをデザインすべき領域について議論してきたが、いったい何を設計したらよいのでしょうか。サービスを提供する実体というか広い意味でのツールは何かを考えてみましょう。それは少し抽象的かもしれませんが「プロセス」と言ってもよいと考えています。

サービスの構成要素は「プロセス」「機能」「情報」ということを言いましたが、この3つが等価に並んでいるのでしょうか。どうも主従関係がありそうですね。これからは「プロセス」を広くとって主として見ることにします。すなわち、「機能」「情報」はプロセスの中に包含して考えていこうということです。プロセスをオペレーションするためにもつべき機能であり、サービスを受けるための機能であり、プロセスにおける意思決定のための情報であったり、プロセスで生成されるデータであったり、サービスそのものが情報の固まりだったりするわけです。

ということは、サービスを提供するのは「プロセス」を通して行われると規定できそうです。そのとき、すぐにサービスプロセスをどうやって作ったらよいのかという進み方はちょっと勇み足ですよね。それだと、サービスごとにあるいはサービス受給者ごとに作らないといけなくなります。そこはちゃんと構造化して、こんな形のサービス形態で提供するというふうに考えたいものです。ある程度標準化、共通化することが望まれます。

それでその構造はどうあるべきかを発想するときにはオペレーションから見ていくことをお勧めします。なぜならば、所詮ツールを作るのですから、使われないものをせっせと作っても意味がありません。使ってもらって、あるいは受けてもらった結果としてサービス受給者が満足しなくてはいけません。ですから、実際のサービスオペレーションから使ってもらえるため、喜んでもらえるためにはどんなサービスの形がいいのか、つまりHowの前にWhatをしっかりとデザインすることが大切です。

こうしたWhatはHowに優先するという考え方をもたないと、たとえば情報システムをつくる場合なんかだと、直ぐにどんな言語で開発したらよいのかとか、パッケージはどれにしようかといった技術視点でのHowからのアプローチになりがちでです。いくら腕のいい大工さんが家を作ったとしても、ひどい設計の家だと何ともならんでしょう。ところが日本ではHowの技術を評価する傾向が強いように思います。いいものを作れば売れるという思いもここから出ています。

よく例え話をするのですが、有名な岡野工業の岡野社長の話です。直径0.2ミリという極細の痛くない注射針(現在は0.18ミリだそうです)を深絞りというプレス加工技術で作ってしまったことで有名になりました。多くの人は岡野さんを絶賛するのですが、もちろんそれを否定するわけではないのですが、もう少しインシュリンの注射針で苦しんでいる人を助けてあげたいということから極細の注射針を作ってくれと頼み込んだテルモの人を褒めてあげたいのです。

HowではなくWhatを考えた人です。もちろん、両方とも重要であることは間違いないのですが、岡野さんのHowを生かすためのWhatを考えたことがすごいのであり、そこからあのような製品ができたのです。サービス学会では「製造業=製造代行サービス業」と定義していることからもビジネスサービスではWhatを先行させるアプローチが重要なのです。
  

■    デザイン領域

ビジネスサービスをデザインする場合、サービスの持つ機能と同時にどこの領域をデザインするのかを議論する必要があります。ビジネス活動というのは、経営から現場の作業、会社全体から個人というように多岐にわたるからである。この縦横の各領域で求めるサービスも違うし、やらなければいけないことも異なってきます。

ここをあまり細かく分けてもまたわからなくなりますので次の3つくらいの領域に分かることでよいかと思います。

①Design in Management
②Design in Operation
③Design in Action

最初のマネジメントのデザインですが、サービスデザインという言葉が似合わない感じがしますね。特に日本ではあまりイメージがわかないと思います。しかしながら、サービスという意味合いが薄いかもしれませんが、デザインという考え方はぜひ採り入れたいものです。一番のいい例は「戦略のデザイン」や「事業のデザイン」です。どうもこの辺をきちんとデザインできている経営者や事業部長が少ないような気がします。

それは別な言葉で言うとプロフェッショナルがいないということです。マネジメントのプロはちゃんとデザインをしますというかここが命です。日本では現場のプロはいっぱいいますが、経営のプロというのはわずかです。本来は経営や事業運営も気合だけの人、みんなに好かれる人、過去に実績のあった人がするようなものではなく、高度なデザイン力を持った人がなるべきでしょう。

オペレーションというのは、組織に割り当てられた業務プロセスを円滑に運営することです。それに必要なことは、「適正なコントロール」「効率的なオペレーション」「正確なモニタリング」ができるようにデザインすることです。このなかで「効率的なオペレーション」というのがちょっとあいまいですが、要はスピードと質の高い意思決定ができているかということです。そして、それを可能にするためには、センシングをちゃんとやって、状態を的確に把握して、管理目標から乖離したらそれを修正するように制御しすることができていないといけないわけです。ここのところのデザインが非常に重要になってきます。

アクションレベルでは、基本的には役割を与えられた人が、その責任においてやるべきことを適切に実行できるかが問われます。つまり、所与の単位意思決定を行って業務進めていきます。そうした、アクションレベルのデザインで気をつけなくてはいけないのは、孤立したアクション、すなわち個人が自分の勝手な判断で行わないようにすることです。それと、自分の行為が受益者にとってよいサービスとなっているかを絶えず意識することではないでしょうか。

それぞれのレベル、エリアでつながりのある動きができて、その結果が顧客にとって良いサービスとなることをデザインすることがサービス提供者としての責務になってくるのです。これらはとりもなおさず「組織論」あるいは「組織能力」になっていることがお分かりだと思います。ビジネスは組織が提供するサービスによって収益を確保することで成り立っているわけです。
■    サービスは何から成り立っているのか

さて、次は設計フェーズに入ってきます。ビジネスサービスの何を設計することになるのでしょうか。それを考えるにはサービスは何から成り立っているのかを見るのがよいでしょう。まずはサービス学会のサービスの定義は「提供者が受給者の望む状態変化を引き起こす行為」となっています。ところで、サービスという概念で見るとこの定義のようにITシステムのことではないことがわかると思います。

つい、企業的なビジネスサービスはITシステムによるサービスだと思いがちですが、人手によるおもてなしもサービスになるわけです。ただ、会社は、組織としての活動が基本ですから、おもてなし風な個人に依拠したものはあまり対象にはしませんが、ITだけではなく人とITとの合わせ技だということを理解してください。

ですから、ここでは「提供者が受給者の望む状態変化を引き起こす行為」がうまくいくような仕組みはどんなものであるのかという捉え方をします。ビジネスでは往々にして受給者は顧客ということになります。ですから、お客さんがこんなものが欲しい、こんなことをして欲しいと望んだとき、それに答えてやることです。ただ、この受給者は顧客だけに限ったことではなく、例えば社内の従業員に向けてサービスを提供するなんてこともあるので、社内外に受給者がいます。

さて、サービスを提供する仕組みはどんな要素から成り立っているのでしょうか。メタレベルで見ると「プロセス」「機能」「情報(データ)」から成り立っていると考えています。つまり、サービスはワンショットで終わることはほとんどなくて、いくつかのサービス要素を順番に繰り出すことが多いと思います。これがプロセスです。連続、非連続問わず徐々に望む状態に変化させるという流れです。

そのときの変化のさせ方とか提供の仕方などは受給者が望むようにしようとします。早くしてほしいのかとか、驚きを与えてくれとか、逆に安心感をもたせてくれといったように提供の仕方に工夫がいります。それが機能です。ITで機能というと検索ができるようにとか、計算速度を早くとか、画面のレスポンスが何秒とかいうシステム的な機能を考えがちですが、最初の段階ではもう少し抽象度を上げて見たほうがよいでしょう。

そして、ビジネスサービスでは結局は受給者に与えるものは「情報」という形になります。もちろん、商品という物理的なものを渡すというサービスがありますが、それでも、受給者はモノそのものというより、そのモノに付帯した情報を求めているのではないでしょうか。つまり、そこに載せる情報は何がよいのか、どんな情報を参考にしてモノを渡すのか、サービスを行った結果も情報として残るということもあるわけです。

ということで、ビジネスサービスを構成する要素は大きく「プロセス」「機能」「情報」になると考えています。ということで、ビジネスサービスを構成する要素はどんなものが必要なのか、その組み合わせ構造をどうしたらよいのかが設計になります。実際の設計ではこうした要素を更に分解していき具体的な要素機能や構造に落とし込んでいきます。
 

■ どこから始めたらよいのか

ビジネスサービスの企画はビジネスモデル起点のハイブリッドアプローチで行うのが基本なのだが、現実にはそうはいかないケースが多くあると思う。つまり、もう問題の所在が明らかで具体的にやるべきものが見えていたり、早く効率的ないオペレーションをしたいといった場合にはそこから始めてもかまわないということである。

立案された戦略から、それを実現するための業務プロセスを特定し、そこにKPIを設定し、といったやり方は教科書的には正しいが、それは全社的なプロジェクトとなって、大がかりな進め方が始まるとそこで疲れてしまって挫折するなんてことにもなりかねない。だから、目の前の改善要求に対して企画するというのもありだと思っている。特に、部門内やグループでの起案では仕方ないでしょう。

しかしながら、注意しなくてはいけないのは、そういった始め方だと部分最適であって、全体最適にはならないのではないかという批判がついてまわる。ですから、お勧めしたいのは、ある程度進んだ段階、そうですね、プロセスの概要ができてきたぐらいで、そこからビジネスモデルに遡ることをしたほうがよいということです。

いま自分たちが作ろうとしているビジネスサービスは自分たちが営んでいる事業のビジネスモデルのどこに位置するものかという確認をすることが大事だと思う。先にサービスのイメージを作っておいて、それが事業戦略やビジネスモデルの目的に合致しているかどうかチェックするのである。いくら、問題があるからとか緊急性があるからとか言っても、事業の目的とかけ離れていたら作る必要はないかもしれないからである。

よく、企画では目的の明確化ということが言われます。しかしながら、注意しなくてはいけないのは、時として目的の目的化、手段の目的化がおきてしまうことです。どういうことかというと、お客さんの問い合わせに応えるのが煩雑だから自動応答サービスを作るという企画を立てたとします。すると、問い合わせ対応業務を分析してその業務を自動化するということが目的になります。そこは明確ですとなる。

ところが、事業の性格から、ただ早く答えればいいというのではなく遅くてもいいから丁寧に対応することで顧客満足度を高めているのがその事業の強みでそこで他社との競争に勝っているとしたら目的は明確化しているかもしれないが十分ではない、あるいは逆行してしまうことだってある。ですから、重要なことは目的の明確化の前に、"合目的性"をちゃんとチェックすることが重要なのである。

さて、身近なところから泥臭く始めても構わないが、いったん目を高みに転じて、それこそ"上から目線"で作ろうとしているサービスを眺めてみたらどうかという提言である。始めるための敷居は低いほうがよいという面は否めないので、気楽に初めて立ち止まり、またさっさとやるという循環サイクルをお勧めします。日本BPM協会の推進フレームワークにある3つの輪は循環サイクルとなっていて、どこから始めてもいいが必ず全体を見ることなのです。