サービスデザインと呼ばれる方法論が国内でも実践され始めています。その考え方や進め方を解説する書籍やWebコンテンツも増えてきましたが、デザインされた事業を支えるシステムをどのように構築するかという課題に触れているものはまだ少ないかもしれません。しかし、スタートアップ企業や初めから小会社化して新規事業を立ち上げるケースを除き、企業内で新たなサービスビジネスを始めようとする場合は既に基幹システムが存在し、これに対する連携または増改築を検討せねばなりません。本稿ではその進め方についてご紹介します。

サービスデザインとは

「DX」に並び、「サービスデザイン」という言葉も経産省が旗振りをしていますのでご存知の方も多いと思います。「サービスデザイン」とは、単に「何らかのサービスをデザインすること」ではなくて、一単語として「お客様志向でサステイナブルなサービスビジネスを、組織やプロセス、それを繋ぐITシステム、さらには関係する他の事業者等も含めたエコシステム全体を包括的に設計し、実際に小さくやってみてビジネスの有効性を検証すること」といったニュアンスが含まれます。(この一単語からでは到底 連想できませんね) 「DX」との直接的な関係性は示されていませんが、私はDXレポートに書かれている「デジタル技術を活かした新たなビジネスモデル」を企画立案する方法論だと捉えても良いかと思っています。中身については下記サイトなどをご参照下さい。

(参考サイト: サービスデザイン思考: 経済産業省 https://www.meti.go.jp/press/2020/04/20200420002/20200420002-3.pdf)

それでは、サービスデザインがある程度固まったあたりから、話を始めてゆきます。

プロセスへの落とし込み

まずは、サービスと言われるものはどのように描かれ、どのようにプロセスに落とし込まれるかについて説明します。

図1. サービスデザインとプロセスとの接点

例えば、従来は店頭で消費者が買い求め所有していた商品を、シェアリング、つまりネットで好きな時に予約して利用できるようにするとします。そのような市場やニーズがあるか、どのようなペルソナを想定すべきか、お客様の共感を得られるか、ビジネスとして成り立つかなどを検討し、プロトタイプを作りテストしてみるというのが一般的なサービスデザインの工程です。アイデアを可視化し検証するための手法はさまざまありますが、サービスの内容が固まってきて企業として投資の判断をしようという頃には、「バリュープロポジションキャンバス」(図1の1段目)や「カスタマージャーニーマップ」 (図1の2段目)でサービスの特長と、想定されるお客様の行動様式が明確化されます。プロセス設計との接点は、図1の3段目にある「サービスブループリント」と呼ばれる部分です。これは文章や絵で表現された「カスタマージャーニーマップ」の各ステージに対応付けて、お客様や自社の各部署がどのように行動するのかをラフに描いたフロー図です。つまり、新しい業務フローの青写真とも言えます。このようにプロセス視点で考えることで、ネットでお客様は商品をどのように選ぶのか、予約という新たな業務を社内の各部署にどう連携するかなど、より実務に近い検討事項を洗い出し、明確化していくことになります。しかし、新たなビジネスモデルを生み出すと言っても、ほとんどの企業には既に従来型のビジネスモデルが存在し、そのためのプロセスと役割分担が存在します。現状のまま流用できる部分と、そうでない部分を見定め、新規または変更となるプロセスを定義してはじめて、新しいビジネスモデルが現場に実行可能な具体性を持って設計されたことになります。また、組織を変える、制度を変えるという要件もここから生まれてきます。「サービスデザイン」から「BPM」にバトンが渡るポイントです。

データモデルへの落とし込み

次に、描かれた「サービスブループリント」と同じ範囲で、そこに必要となるデータの構造や関係性を図示してみることにより、データ視点での変更点を洗い出します。(図2) 例えば、会員制Webサイトでお客様を囲い込み、商品の予約・申し込みができるようにするには、そのためのWebシステムが必要になることはもとより、Webシステムと従来の社内基幹システムとの連携が必要です。お客様の行動(Webサイトへのアクセスや予約・利用実績)をデータとして蓄積し、市場の変化と自社の売り上げ・利益を検証しながら、よりニーズの高い商品をそろえ、サービスカタログや価格設定を柔軟に変化させていく。データ分析に基づく意思決定はこのようなビジネスモデルにおけるキーとなります。どんなデータを蓄積し、どう分析して、どんなアクションをとるか、ビジネスモデルの設計段階で、データモデルに織り込んでおかなくてはなりません。

図2. サービスデザインとデータモデルとの接点

一方、現実問題としては現状のビジネスモデルにおいてでさえ、データが散在し一元化されていない、必要な時に必要なデータが手に入らないという悩みを抱えている企業が多いと思います。そこに新たなビジネスモデルを立ち上げようにも、既存システムとの連携や改修には時間とお金が多大にかかってしまう。DXレポートにある「レガシーシステムの足かせ」に直面します。「サービスデザイン」をスムースに実践するためにも、DX課題を克服する必要がある訳です。

アプリケーションへの落とし込み

さて、「サービスデザイン」に基づきプロセスとデータの青写真ができたら、このビジネスモデルを支えるシステム(本稿の例では、Webシステムと基幹システムの連携仕様)の仕様を検討する段階に入ります。

図3. アプリケーション開発に対するインプット

「サービスデザイン」におけるシステムの設計・開発ですが、この局面でウォーターフォール型の開発をやっていてはスピード感が出ませんので、基本はアジャイル開発を行うことになります。また、リリース後も状況変化に合わせて短いサイクルで仕様をどんどん変えていけることが必要です。従って、機能間の連携を疎結合とし、部分的に組み替えられるような作りが重要となります。プログラマの方はMVCモデルというデザインパターンをご存じのことと思います。ビジネスルールやロジックを記述するModel、ユーザーインターフェースを担当するView、ユーザーからのリクエストに基づきModelとViewを制御するControllerに機能を分割し、変更・修正があった時に互いに影響を受けにくくしましょうという考え方です。90年代から存在する考え方ですが、きちんとできているアプリケーションは少ないかもしれません。「サービスデザイン」を短いサイクルで実現し、検証して、どんどん改善サイクルを回していきたいというビジネス側からの要求が強まってきた近年、やっと実感を持ってその重要さが見直されているような気がします。ちなみに、サービスはViewに、データはModelに、プロセスはControllerに対応し、ビジネス要件がプログラムレベルに落とされていきます。

まとめ

少々大雑把でしたが、「サービスデザイン」が固まった後の「プロセス」「データ」「アプリ」の設計・実装へのつなぎ方についてご紹介させて頂きました。わたくし自身、RanabaseというITサービスを自部署で企画・開発し、ビジネスとして立ち上げている最中ですが、過去に経験した基幹システムの開発プロジェクトとは全く趣が異なります。これはプロジェクトではありません。恒常組織としての業務です。業務の中でITの企画・設計・開発・運用 (それに加えてマーケティングや営業)が日常的に回っているような感覚です。必要な人材像も変わってきます。システムをITベンダーに丸投げしていては前述のようなアプローチは取れません。そう思うと、プロセス、データ、アプリケーションのみならず、自分達の組織、スキルセット、文化などもデザインし直さなければいけないと実感しています。