プロジェクト事例紹介：介護業界向けコミュニケーションサービス
※本記事はコンセントのサービスデザインチームによるブログ『Service Design Park』に、2016年2月2日に掲載された記事の転載です（転載元：http://sd-park.tumblr.com/post/138544599886/daisy-circle）。
こんにちは、株式会社コンセントのサービスデザイナー、赤羽太郎です。
さて今回ぼくの記事では、サービスデザインの実際のプロジェクト事例について書いていきます。
※ちなみにこの事例についてはコンセントのコーポレートサイトの事例紹介ページにも紹介されていますが、ここでは、途中の紆余曲折や、どんな手法を用いたか、というプロセスをちょっとだけ掘り下げてお伝えします。
まず、このプロジェクトのクライアントはカシオ計算機株式会社様です。同社にとって未知の市場である「介護」に関わる課題を解決することをスコープとして、最終的に冒頭画像のスマートフォンアプリ「DaisyCircle」を開発・リリースしました。
クライアントからのオーダーには現在進行形で超高齢化社会へと突き進む日本において、今後あるべき家族の形を描き出したい、という思いがありました。今回のプロジェクトはそれを実現するためのソリューション、というわけです。とても有意義なプロジェクトだなー、というのが最初にお話を頂いた時の素直な感想でした。
しかし、そのために「介護」におけるどのような課題にアプローチするべきか、そのビジネスはBtoCなのかBtoBなのかBtoBtoCなのか、というような、サービスを開発するにあたっての具体的なことについては、ほとんど決まっていませんでした。
すべてのプロセスについて書くと大変長くなってしまうので（プロジェクト自体は１年半程度の期間かかっているので）、ここでは下記の３点に絞って紹介していきます。
1. 価値抽出からのサービス開発
2. 複数のステークホルダーへの価値提供
3. MVP（Minimum Viable Product)の重要性
なぜこの３点かというと、ほかのプロジェクトに比べて特徴的な点だからです（せっかくブログに書くわけですし）。ちなみにここでいう「価値」とは、サービスに対してユーザーが期待するであろう「価値」、つまり現状満たされていない未充足のニーズを指します。
さて、介護というものには、とても多くの人や要素が関係しています。下の画像はプロジェクト初期に情報の整理のためにまとめた介護に関わる関係者や要素の相関図です。
これだけ見ても複雑さがみてとれますね。たぶん、業界の方から見ればこれでもまだ足りない部分もきっとあるでしょう。
ご両親などが介護される事になった家族は、このような複雑な世界にある日突然飛び込むことになるわけです。それは混乱するし大変です。かくいう私も母親がケアマネージャーという介護に関わる仕事をしていたにも関わらず、あまり介護についてはなんとなくしか知りませんでした（しかし、他の人よりは知っていると思ってました。今考えると全然ですが）。
そのため、プロジェクトではまず、複雑な関係性の中のどの部分に対してのソリューションを検討するかを決めるところから始める必要がありました。その後、定義した範囲の関係者の、現状の介護への関わり方の文脈・課題と、その背景にある価値観を探っていきました。
１．価値抽出からのサービス開発
価値抽出のために、まずはコンテクスチュアルインクワイアリー（Contextual Inquiry：文脈的探求）という手法を用いて、介護が行われている現場や、介護に関わる人々のお宅に訪問し、インタビューを実施しました。そこで得たユーザーファクト（インタビューなので”発話”）をもとに、背景にどのような価値観が存在するのかを探っていきます。本プロジェクトではKA法という手法によってユーザーファクトを価値として抽象化し、最終的にその構造を「価値マップ」という概念図としてモデル化しています。
抽象化とはなんぞや…をざっくり説明すると、ある事象に関連した「具体的な事実」がたくさんあったとして、それらの事実の背景にある共通の要因に着目し、別個の概念として収斂・統合する…言い換えれば、ある視点から情報を解釈してまとめ直す、というプロセスです。例えば小学校のクラスに30名の生徒がいた場合、彼らを「男」と「女」という二種類に分けたり、「班」の所属でまとめたり…といったような手続きを指します。
抽象化の実務上の利点としては、複雑な要素で成り立つ構造をよりメタな視点で俯瞰して理解や整理、分析、そこからの仮説立案がしやすくなる、という事が挙げられます。ちなみに、先に述べたような「異なった視点」「別の解釈」も当然複数あるため、どのような抽象化の方針がプロジェクトに有益か、を探るために、抽象化のプロセス自体、多くのプロジェクトケースで何度もやり直す必要が出てきます。コンセントでも、ここはかなり時間をかけて複数回スクラップ＆ビルドを繰り返します。
なお、KA法はもともと紀文食品の浅田和実氏が開発した手法ですが、それをUXデザインの手法としてさらに千葉工業大学の安藤昌也教授がブラッシュアップしており、おおよそコンセントで用いている手法はおおよそこれと同様のものになります。
※さらに踏み込んだ話としては、この一連のプロセスはグラウンデッド・セオリー・アプローチ（Grounded Thory Approach- 以下GTA。）というメソッドをベースにしており、もともとこの手法自体も看護の現場の社会学調査のために米国の社会学者バーニー・グレイザーとアンセルム・ストラウスによって開発されたものです。ちなみにこの手法には複雑かつ恣意的な部分が多々あると言われており、研究者ごとの考え方やセンスにより分析結果にバラつきが出やすく、この課題点を改善した修正版グラウンデッド・セオリー・アプローチ（modified – Grouded Theory Approach）を日本人社会学者の木下康仁氏が提唱しており、大本のGTAよりはこちらの方がよりコンセントで用いている手法には近いものになります。
2.複数のステークホルダーへの価値提供
さて、今回のプロジェクトにおいてなぜ上記のようなアプローチを取ったか、という事については、3つ理由があります。まず1点目が、新しい仮説を調査から導き出すのには探究的な質的研究法、定性調査が適しているということ。2点目※として1人のステークホルダーがサービス提供者にもサービスの受け手にもなるような場合には、文脈が複雑化するため、分析対象としてわかりやすくするため、抽象化する必要がある、ということ。そして、最後の3点目の理由が、「2.複数のステークホルダーへの価値提供」を実現するためです。
※GTAが登場した文脈も看護の現場の複雑さを整理する必要から、というバックグラウンドがある。ちなみに、GTAにおいてはインタビューから得た膨大なファクトをルールに基いて一定の情報単位に「コード化（切片化）」し、それら文脈から切り離された抽象的な情報単位を再構成し、その過程で、情報集合を「概念」として構造化する、という手順を踏む。
私たちが調査を行う場合に、必ずしも上記のような調査〜コード化〜抽象化〜構造化、といったプロセスを踏むわけではありません。プロジェクトによっては、調査の結果からすぐにカスタマージャーニーマップを描いて、そこから得たインサイト（洞察／示唆）をもとにソリューションのコンセプトを開発するようなこともあります。つまり、そこには、観察から得られた情報のビジュアル化、モデル化はあっても抽象化するプロセスは明示的にはありません。この場合は、顕在化しているにせよ潜在的であるにせよ、行動文脈上に課題があり、それに対して解決策を提示していく、という、ある意味明快でわかりやすい手順を踏むことができます。
しかし、今回のプロジェクトのように複数の関係者の利害関係が絡み合っている場合、ある関係者に対してのソリューションが他の関係者の不利益につながることもあります。このようなケースでは、それぞれのユーザーインタビューの結果から、文脈やニーズを１つ１つ読み解き整合させていくことは非常に困難です。しかし、文脈の背景にある「価値」というものに抽象化することで、複数のステークホルダーにとって共通する「価値」とは何か、をマッチングすることが可能に（少なくともマッチングしやすく）なるのです。
本プロジェクトにおいても、抽象化された価値構造をつき合わせ、その中で複数の関係者に共通した価値をいくつか見つけることができました。その中で、なるべく多くの関係者にとって、意義のあるソリューションにつながる価値を選択しました。
結論から言えば、それは「適切な距離感を保つ」という価値です。
これを各ステークホルダーごとに落としこむと、介護サービスの利用者本人にとってはなるべく自立可能な期間を長く保つこと、家族にとっては両親や祖父母など、介護サービス利用者をちゃんと見守りつつ自分たちの生活スタイルをなるべく変えずに介護に関わっていくこと、サービス提供者にとってはプロとして必要な情報を過不足なく伝達・受容できるということ、と言えます（実際はもっと色々な価値や文脈を含みますが、ここでは簡単にまとめています）。
実際、介護の現場ではどの程度踏み込んだり意見しても良いのかがわかりにくく、遠慮しすぎてしまったり、逆に踏み込みすぎて過干渉になるようなケースが散見されています。この状態を解決するためのコミュニケーションツールを開発する、ということがプロジェクトの目標として定義されました。
3.MVPの重要性
サービスの方向性が定義されたのちには、具体的なソリューションを作っていきます。ここでクローズアップされてくるのが「3.MVPの重要性」です。MVPとは、 Minimum Viable Product、日本語で言うと「最小限実行可能な製品」という意味です。ここでは、ユーザーにサービス価値の体験提供が可能な最低限のプロトタイプ、という意味で用います。
さて繰り返しになりますが、このプロジェクトのターゲットである介護業界にはさまざまな立場のステークホルダーが存在しています。その人達に対して、本当にニーズがあるのか（Customer）？本当にコミュニケーションに問題があるのか（Problem）?このサービスで問題を解決できるのか（Solution）？、といういわゆるCPS軸のそれぞれを、各ステークホルダーに対して検証する必要があるわけです。
このような場合、「じゃあWebサービスをつくろう」「スマホアプリをつくろう」と開発を始めてしまうと、しかし開発後にあるステークホルダーにとっては致命的に不便だった、という事態も発生しかねません。そのため、MVPを複数段階でプロトタイプしながら、ステークホルダーに見せて検証していくという手順が必要になります。
もともとMVPはLean UXの文脈でよく使われる言葉であり、むしろシンプルなソリューションを特定のペルソナに適用する、というイメージが強いような気もしますが、個人的には本プロジェクトのような、複雑なステークホルダーの存在するような状況でも上記のような理由でむしろ有効だと感じています。結果的にステークホルダーが多いのでLean UXのようなスピード感のあるプロセスにはなりませんが、それはMVPの有効性とはまた別の話です。
本プロジェクトにおいては、大きく分けると
1. コンセプトシート（説明書やカタログのようなもの）でのユーザー検証
2. ラフプロトタイプ（工数低めに作れて動くもの）での検証
3. 実際のユーザーに長期間使ってもらう実証実験
という３段階で行いました。
それぞれの段階のMVPに対して各立場のユーザーからのフィードバックを受け、新機能を検討したり、逆に増えた機能アイデアをざっくり削ったり、方向修正を適宜行っていきました。
その甲斐あって、最終的に３ヶ月間実施した実証実験では想定した通りの成果や、部分的にはそれ以上の成果を得ることができ、実際に市場にリリースする運びとなりました。本サービスは、iOS、Android対応のスマートフォンアプリ「DaisyCircle」としてカシオ計算機からサービス提供されています。
DaisyCircle
http://daisycircle.casio.jp
とはいえ、現状の介護業界では多くのやり取りがFAXや電話で行われ、業務のIT化もそれほど進んでおらず、働く人の平均年齢も比較的高めで、スマートフォンアプリとの相性が決して良いとは言えません。そのためサービスの認知浸透にはまだまだ時間がかかりそうですので引き続き頑張ります。
このプロジェクトではほかにも、ビジネスモデルとしての収益性の検討やその裏付けのための定量調査、プロモーションのチャネルや手段の検討、そもそも別のソリューションの可能性はないかといった検討やプロトタイピングなど、さまざまな途中経過がありましたが、それらはまた別の機会があれば書いていきたいと思います。
さて、いかがでしたでしょうか。途中専門用語を使いすぎた感もなきにしもあらず、ですが、より「この部分の話が聞きたい」ということなどあれば、ぜひ下記アドレスよりご連絡下さい。次回以降の記事に反映するなり、お返事差し上げるなり、なにかしらリアクションいたしますので。
sd-park[at]concentinc.jp
※[at]は@に変えてください。
ではでは。
【執筆者プロフィール】
赤羽太郎｜サストコ
【関連リンク】
事例紹介｜カシオ計算機 介護業界向け新サービス開発
