ソフトウェアエンジニアが CIID の IDP コース（27~29週目）に参加して学んだことをゆるりと共有します。今回（9/28~10/16）はサービスデザインの授業でした。今までのインタラクションデザインとは違い、長い時間軸のサービスのデザインでした。アウトプットにも満足でしたが、プロセスにもとても満足がいく授業でした。
24~26週目の記事もあるので良かったら読んでみてください。
Day 121: Service vs Product
この日はサービスとプロダクトの違いを説明されました。この違いを常に意識する必要はないと思いますが、自分が今どこのレイヤーのデザインをしているのか俯瞰で考えられるようになるのが大事なんだと思います。
Systems thinking
この違いを説明する上で、システム思考（Systems thinking）について説明されました。その際に下記の動画を紹介されました。
簡単に説明すると、複雑な相関関係のある人やものをデザインする時に使う思考のことです。例えば、社会問題などは複数のステークホルダーとパラメーターが絡み合って、一連の問題を解決するのが複雑で難しくなっています。今回のクラスでは実際にシステム思考を使ってはいませんが、エコシステムマップ、カスタマージャーニーマップ、サービスブループリントで代替して、サービスをデザインしています。下記の記事でシステム思考についてもうちょっと詳しく説明されています。興味ある人は読んでみてください。
社会問題の例のように、サービスとは複数のステークホルダーがいて、一連の体験を提供するものです。一方で、プロダクトとは一つのタッチポイントに対して価値を提供するものです。ざっくり言うと、プロダクトの集合体がサービスで、プロダクトを違和感なくシームレスに繋いだものが良いサービスです。このように、プロダクトとサービスではデザインしてるレイヤーが違い、デザインするものも異なります。今までの授業では、インタラクションデザインを軸として、プロダクトをデザインしていました。しかし、今回の授業では、その一つ上の層の「体験」と「行動」をデザインする授業でした。
Day 122~125: Find co-creator
この日は、3週間に渡る課題が説明されました。その課題は「コスタリカの観光業を拡大させ、かつレジリエンスにする」でした。更に、今回の授業では「共創（Co-create）」をすることが求められました。正直、短期間でパートナーを見つけて、スケジュールを確定させるのに苦労しました。しかし、とても貴重な体験とコスタリカならではのデザインに辿り着くことができました。
Conserve sea turtles
最初の2日間は、デスクリサーチをして、可能な限り多種多様な人にインタビューを行いました。その結果、多くの人がコスタリカの自然や生物の魅力について言及していました。なので、大まかな方向性を「バイオダイバシティー」にして、更に深ぼることにしました。そこで、「バイオダイバシティー」に関して、コスタリカの生物学者にインタビューをしました。
生物学者のインタビューの中で、更に面白い話を聞くことができました。それは、コスタリカが生物学者に地政学的にも気候的に独特な環境を有していることでした。太平洋と大西洋に接していおり、海岸の気候から高地の気候があることによって、バイオダイバシティーを促進しているとのことでした。そして、その独特の地形からウミガメの保護がコスタリカで隆盛していることを教えてもらいました。このインタビュー結果から、「バイオダイバシティー」から「ウミガメの保護」に更に絞ってデザインをすることにしました。
そして、下記のウミガメ保護の NPO に辿り着くことができました。紹介してくれた方に感謝しかありません。この NPO の代表の方に、僕たちのパートナーになっていただきました。
まずは、共創を始める前に、簡単なオンライのインタビューを済ませて、僕たちのデザインのスコープを更に絞って起きました。この段階では、「ウミガメの保護」を軸として、メインのユーザーを「アメリカやヨーロッパからくるボランティア」にして、「サイエンストゥーリズム」を促進するようなサービスを考えていました。最後にこの段階の HMW を共有しておきます。
How might we make volunteering experience of turtle conservation in Costa Rica accessible and exciting for University Students?
Day 126: Ecosystem map
この日から1週間かけてサービスの全容を整理するための手法を学びました。最近、メジャーになっている手法なので聞いたことがある人もいると思いますが、改めて各章に分けて共有しようと思います。ちなみに、Day 126 ~ Day 130 はサンホセを離れて、上記のウミガメの保護団体のもとを訪れて実施しています。
Put everything at first
この日は「エコシステムマップ」という整理手法を教わりました。簡単に説明すると、自分たちがデザインしようとしているサービスのステークホルダーを羅列して、それぞれの関係を可視化するツールです。詳しい説明は下記の記事に譲ります。
僕たちの場合は、前日にメインのユーザーを「アメリカやヨーロッパからくるボランティア」としていたので、メインのユーザーを中心として、関係ありそうなステークホルダーをとにかく羅列して、思いつく限りの関係性を可視化していました。僕たちは、エコシステムマップを実際のインタビューの前に作成していたので、「これ、あってるのか？」みたいに思いながら作っていました。ただ、結果的にこのエコシステムマップをもとに、実際に正しいのかどうか確かめるようなインタビューを設計して、一番最初のインタビューを行いました。
エコシステムマップは、一番最初にサービスの全容を理解するのに役立つなと感じました。そもそもサービスがどういう環境で使われて、誰を巻き込む必要があるのかと言うのを、一目瞭然にしてくれます。最初の章で説明した通り、サービスは複雑になりやすいのでところどころで整理して置くのは、僕にとっては嬉しいなと感じました。また、僕たちもそうだったのですが、初期に作ったエコシステムマップと最終的にできたエコシステムマップは全然違うものになっています。とりあえず、最初は思いつく限りのことを羅列して、インタビューや共創を通して、徐々にスリムにしていくイメージで作ると良いと思います。
最後に僕たちの最終的なエコシステムマップを共有しておきます。文字が小さくて見にくいと思いますが、最終的には僕たちが見たり聞いたりしたステークホルダーを残して、どういう関係があるのかを矢印の種類で示しています。色々載せるより、事実に沿ったものだけを載せているとかなりスリムになっていくと思います。
Day 127~128: Customer Journey Map
この日は、カスタマージャーニーマップの作り方を説明されました。今ではかなりの人がカスタマージャーニーマップを知っていて、作ったことがある人も多いと思います。この章では、「共創」をもとに少し違ったカスタマージャーニーマップの作り方をしたのでそれを共有しようと思います。
From the user in
カスタマージャーニーマップは後述するサービスブループリントの対として説明されました。その対応関係は、カスタマージャーニーマップは「ユーザーと作る（From the user in）」で、サービスブループリントは「自分たちが作る（From the organization out）」です。主に、カスタマージャーニーマップを作るときはユーザーを理解することが目的になります。僕たちは、カスタマージャーニーマップを二段階に分けて作りました。
まずは、パートナーの団体でボランティアしているイギリスから来ている学生に対して、40分のインタビューを2回行いました。その後、実際にチーム全員でボランティアの1日を朝から晩まで体験して、それをカスタマージャーニーマップに落としていきました。正直、生物学や環境学の専攻の修士と学士のボランティアだったので、仕事内容を甘く見ていました。ウミガメの保護のボランティアはめちゃくちゃ体力仕事です。一番きつかったのは、夜10時から朝4時までのウミガメ産卵と羽化のデータ採集の仕事でした。この後に、チーム内で大まかなカスタマージャーニーマップを作り上げました。下記に、この時用意したインタビューガイドを載せておきます。このくらい簡単に作ったものでも十分役に立ちました。
次に、この授業の最も重要な「共創」を使ってカスタマージャーニーマップを作りました。何をしたかと言うと、実際にパートナーのボランティアたちとカスタマージャーニーマップを作りました。インタビューと僕たちの体験をもとにして作ったカスタマージャーニーマップを見せて、「それぞれどう思うか？」や「この時の気持はどんな感じ？」などの質問をしてカスタマージャーニーマップの完成度を高めていました。この時に、意識したことは、「カスタマージャーニーマップにある行動に過不足がないか確認すること」と「ペインポイントはどこにあるか」です。前職で、何度かカスタマージャーニーマップを作る機会はありましたが、実際にユーザーと作ったのは初めてで僕にとってはとても良い経験でした。今まで、感情曲線やペインポイントは推測で作っていたので、共創の手法は僕にとってとても納得感の大きなやり方でした。
最後に、最終的な僕たちのカスタマージャーニーマップを共有しておきます。もっと見た目をかっこよく作れたと思いますが、内々の資料なので労力的にはこのぐらいで十分だと思います。
僕たちは、この段階で、「期待値のミスマッチ」をサービスの解決する問題として選びました。ウェブサイトを見て来るイメージと、実際に行うボランティア内容がかなり乖離があるように気がしました。ウェブサイトでは楽しいところがやはり載せらていますが、実際の作業はかなり体力仕事で居住環境もお世辞にも良いとは言えないです。そこの「期待値のミスマッチ」を緩和するようなサービスを作ろうとチームで決めました。
Day 129~130: Service Blueprint
この日は、サービスブループリントの作り方を教わりました。サービスブループリントも最近有名になってきていると思います。色々名前がありますが、ストーリーマッピングやアクティビティ図とやりたいことは同じだと思います。この章では、その作り方を共有しようと思います。
From the organization out
サービスブループリントは、前述したカスタマージャーニーマップと対になる手法です。調査したカスタマージャーニーマップをもとに自分たちがデザインしているサービスの機能やタッチポイントを整理して、必要なリソースを羅列していきます。平たく言うと要件定義です。エンジニア出身の僕には、割と馴染みやすかったです。詳しい説明は下記の記事に譲ります。
基本的にやることとしては、アイディエーションです。カスタマージャーニーマップとは違い、今度は問題に対して解決策を提案する段階です。カスタマージャーニーマップで可視化したペインポイントやフェーズ、アクションに対して、どういうことが出来るのかというのをみんなでアイディエーションしていきます。僕たちのチームは「Crazy 8s」という方法でアイディエーションを行いました。詳しい説明は下記の記事に譲ります。簡単に説明すると、8分で8つのアイディアをだすだけです。
そして、出てきたアイディアに対して、みんながどれが良いか投票してそれを組み合わせてサービスにしていきます。僕たちのチームは、投票する前に、どのアイディアがカスタマージャーニーマップのどのフェーズに当てはまるかを分類してから、投票していました。最終的には、その投票結果をもとに、一つのサービスに入れて違和感ないアイディアをそれぞれのフェーズに当てはめてサービスブループリントを作成しました。この段階の僕たちのサービスブループリントを共有します。
基本的には、「期待値のミスマッチ」という問題を軸に、ボランティア開始前に出来ることと、ボランティア開始後に出来ることを組み合わせています。
Day 131: Storytelling
この日は、ストーリーテリングのやり方を教わりました。サービスという大きく複雑な物をどのように説明したら良いかを教わりました。とても基本的なことでしたが、大切だと思ったことに絞って共有しようと思います。
Explain your context
正直、おおまかな内容自体は今までのストーリーボードと変わりません。ただ、念押し刺されたことは、ユーザーの「問題」と「ニーズ」をちゃんと伝えることです。確かに今までのストーリーボードは機能面の描写が殆どで、「問題」と「ニーズ」を描写していなかったなと思いました。あとは、下記のフレームワークに沿って、サービスブループリントの内容を当てはめて、完成させていきます。
また、ストーリーテリングで調べた時に下記の記事を見つけました。内容はピッチ資料の説明ですが、ストーリーテリングの観点からとても参考になるなと思ったので共有しておきます。記事を読むと、確かに Space X のような大きな志を持った会社にはストーリーテリングの要素はとても重要だと感じます。
Day 131~132: Combine CJM with Service Blueprint
この日は、講師のフィードバックをもとにカスタマージャーニーマップとサービスブループリントの修正を行っていました。対に2つのツールが繋がった瞬間で、個人的にはとても気持ちよかったです。その修正点を共有しようと思います。
Make touchpoints more clear
講師に、僕たちのカスタマージャーニーマップとサービスブループリントを見せて言われたことは、「もっとタッチポイントを明確にしなさい」ということでした。なので、カスタマージャーニーマップのタッチポイントを整理して、さらに具体化させました。その結果、講師にそういう意図があったかは分かりませんが、結果的に面白いことが分かりました。
カスタマージャーニーマップの「タッチポイント」が、サービスブループリントの「ユーザーのアクション」にリンクしているのが可視化出来るようになりました。また、ユーザー調査の結果が、僕たちのサービスの中に組み込まれていることが確信できました。何事も根拠をもって、機械的にやるのが好きな僕にとってはとても嬉しかったです。この段階の、カスタマージャーニーマップとサービスブループリントを下記に載せます。
文字が小さくてわかりにくいですが、カスタマージャーニーマップ に Proposed changes という行を追加してます。この Proposed changes がサービスブループリントの Customer journey（ユーザーのアクション）という行にそのまま転記されています。カスタマージャーニーマップで、その Proposed changes に対して、タッチポイントを具体化して洗い出しています。
このようにエコシステムマップから始まって、カスタマージャーニーマップ、サービスブループリントのように徐々に複雑なサービスを整理して、可視化していくのはチームで合意を取るという点でも、とても有意義だったなと感じました。
Day 133~134: Prototype
この日からは、発表に向けてプロトタイプの製作に取り掛かりました。僕たちのチームはサービスブループリントを、ビデオと Figma のプロトタイプで作りました。僕は、ビデオを担当していました。少しサービスデザインの観点からはズレますが、ビデオの制作手順を共有しようと思います。
Step by step
今回は、いつものビデオの制作とは違って2日間あったので撮影と編集を複数回に分けて行うことができました。それが、結果的に徐々に完成に近づけていくことに出来てとても学びが大きかったです。基本的には、下記のビデオプロトタイプの授業で習った内容をそのままやりました。
それに加えて、Day 131 で教わったストーリーテリングの要素を入れて、下記の画像のようなストーリーボードを作りました。僕はこのストーリーボードをショットリストとしても使ってしまいました。本当はもっと詳細にやったほうが良いと思いますが、編集する日が2日間もあったので、「足りなかったら撮り直せば良いや」と思ってビデオ制作を行っていました。
あとは、これに沿って、撮影を行って、編集するというのをただ繰り返しました。結局、3回撮影を行って、6個のビデオを作りました。徐々に、改善できて、個人的には自分に合ってるなと思いました。そして、改めて1日で撮影して編集しているのに、ハイクオリティなビデオを作るクラスメートはすごいなと思いました。僕が作った動画は次の章で共有します。
Day 135: Presentation
この日は今回のプロジェクトの発表の日でした。僕たちは「Sergio」というサービスを考えました。その発表資料と動画を下記に共有します。
個人的にはサービスの理解から、ビデオ製作まで学びの多い授業だったなと思います。今まで小さいインタラクションのデザインをやっていたので、授業の最初は思考の変換に戸惑いました。ただ、自分がどこのレイヤーのデザインをしているのかを理解すると、どこを気をつけなきゃいけないのかを理解できたと思います。授業の最後で、講師の一人が、「インタラクションデザインのような小さいデザインだけではなくて、大きな絵を描きながらデザインをしてほしい」と言われたのが印象的でした。これからも、自分のデザインがどこのレイヤーなのかを意識してデザインしていこうと思います。
また、コスタリカらしいデザインが出来たこともとても誇らしく思っています。実際にウミガメの保護団体のもとへ伺わせてもらって、1週間一緒にデザインできたのはとても良い経験になったと思います。
末筆になりますが、実はこの授業が最後の授業でした。来週からは企業と一緒にデザインをすることとなっています。その企業とは NDA を結ぶのでブログに出来ません。僕の学びの書留として始めましたが、最後まで読んでくださった方がいたなら感謝しかありません。お粗末な文章でしたが、最後までお付き合いくださりありがとうございました。今後はなにかネタを見つけて記事にしていくつもりなので、また読んでくれたら嬉しいです。