ServiceDesignGuidelineVERSION2.0

Transcript

1. サービスデザイン ガイドライン VERSION 2.0.0 2024年3月 東京都デジタルサービス局
2. 2 サービスで生活を 豊かにする、 それが私たちにできること 職員の皆さんが日々の業務で手がけるウェブサイトやデジタル施策 それらを通じて、便利さ、嬉しさ、快適さ……といった価値を 様々な人に届けることを、本ガイドラインでは「サービス」と呼びます。 本ガイドラインは、職員の皆さんがより良いサービスを作り、 様々な人の暮らしを豊かにすることを支援するものです。 「サービスデザイン」という考え方に基づき、 「東京都サービスキャンバス」というツールを使いながら、 より良いサービスを作るために必要なことを解説していきます。 なお、本ガイドラインは、ガイドラインの運用によって得られた知見や職員の方々の 意見を踏まえつつ、随時内容の見直しや改定を行っています。
3. 3 より良いサービスを作るには、ユーザーを理解し本質的な課題を突 き詰めて考えることが重要です。 必要なのは、ユーザーに目を向け、ユーザーの状況や考え方を知り、 解決策を形にし、実際に試してみることです。 その過程での試行錯誤の繰り返しが、分からなかったことを明らか にし、改善へのヒントを与えてくれるでしょう。 ゴールが見えにくい現代では、最初から完璧を目指すより、 こうしたやり方の方が目的地により早く辿り着けるのです。 ぜひ皆さんの業務で実践してみてください。 よい失敗から よいサービスへの 道が開ける
4. 4 1 章 サービスをデザインするとは このガイドラインの考え方と使い方 2 章 東京都におけるサービスデザイン サービス開発プロセスの概要とツール 3章 サービスを考える 東京都サービスキャンバスを作成する 4章 サービスを実現する サービスを開発するための大切な考え方 目次 企画 - 仮説検討 1 p.29 企画 - サービス立案 2 p.41 企画 - 要件定義・調達 3 p.53 はじめに p.2 p.6 このガイドラインが目指すこと 1 p.8 「サービスデザイン」の考え方 2 p.9 このガイドラインの使い方 3 p.11 p.13 サービス開発プロセスの全体像 1 p.15 ユーザーの声をサービスに取り入れる 2 p.16 「東京都サービスキャンバス」の使い方 3 p.20 p.25 設計 – 基本設計 / 詳細設計 1 p.60 開発 2 p.64 テスト・改善 3 p.66 リリース 4 p.67 問い合わせ先 p.68 参考文献一覧 p.69 p.57 担当者コメント p.70
5. 5 版数 発行日 改訂内容 VERSION 1.0.0 2023年3月31日 初版発行 VERSION 2.0.0 2024年3月29日 サービス開発プロセスの追加と記載、 ユーザーテストガイドラインの内容を統合 等 ユーザーテストガイドラインの内容を統合 サービス開発プロセスの追加 東京都サービスキャンバスを活用したサービス開発の 進め方を分かりやすく解説するため、全体のプロセス を示し、その中での東京都サービスキャンバスの使い 方や、実際のサービス開発プロセスに繋げるポイント などを記載しました ユーザーリサーチ、プロトタイピング及びユーザビリ ティテストの概要を説明した「ユーザーテストガイドラ イン」の内容を本ガイドラインのサービス開発プロセス に統合しました VERSION 2.0.0 更新の主なポイント 本ガイドラインは2024年3月にリニューアルしました
6. 6 このガイドラインの考え方と使い方 1 章 サービスをデザインするとは このガイドラインの考え方と使い方
7. 7 １章では、本ガイドラインの概要と、活用する ために知って欲しいことを紹介します。ぜひ サービス作りに取り掛かる前に読んでください。 初めに、本ガイドラインの目的や作られた背景、 基本となる「サービスデザイン」という考え方 を紹介します。 次に、東京都が発行する他のガイドラインとの 関係性や本ガイドラインの使い方を解説します。 7 サ ー ビ ス を デ ザ イ ン す る と は 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 1章 1章 の 内 容 このガイドラインが目指すこと 1 p.8 「サービスデザイン」の考え方 2 p.9 このガイドラインの使い方 3 p.11
8. 8 このガイドラインが目指すこと 1 出典：東京都デジタルサービス局 『デジタル10か条 』（2022年） 本質的な課題を解決するための サービス作りを後押しします サ ー ビ ス を デ ザ イ ン す る と は 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 1章 東京都は『デジタルサービスの開発・運用に係る行動指針 』で、より良いデジタルサービスの実現を通して、都民の QOL（クオリティ・オブ・ライフ、生活の質）を向上させ ていくことをビジョン（理想像）として掲げています。 都民のQOL向上に寄与するためには、東京都に暮らす誰も が、必要なサービスを必要な時に利用できるようにしなけ ればなりません。社会課題が複雑化し、価値観も多様化し ている現在、それは容易ではありません。さらに、人口減 少に伴い働き手は減っており、限られたリソースの中でよ り良いサービスを実現していく必要があります。だからこ そ、職員の皆さんの本質的な課題解決へ向けた試行錯誤が 不可欠です。「間違ってはならない」と強く思い過ぎると、 試行錯誤によってより良いものを生み出すことが難しくな ります。本ガイドラインを手がかりに、より良いサービス 作りの一歩を踏み出してください。
9. 9 2 「サービスデザイン」の考え方 利用者と一緒に価値を生み出す仕組みを作る、 それがサービスデザインです 本ガイドラインは「サービスデザイン」という事業開発の 考え方や手法に基づいています。 サービスデザインでは、モノやコトを通じて利用者と提供 者が一緒に価値を生み出すことを「サービス」と捉えます。 皆さんの業務も「サービス」を作ることに他なりません。 なぜなら、皆さんの仕事はウェブサイトやアプリといった モノを作るだけではなく、実際に利用してもらうことに よって便利さ、嬉しさ、快適さ…といった価値を生み出し、 利用者のQOL向上を実現することだからです。 大切なのは、一人ひとりの利用者の気持ちや体験を中心に して、どうすればそれをより良くできるかという視点で、 「サービス」を利用者と共に考えていくことです。 職員 都民の役に立つ 効率的なサービス を作りたい！ 高齢者 フレイル予防の 情報が知りたい！ 子を持つ親 保育園の 申し込みがしたい！ サービスを届ける側、使う側双方の立場や状況に思いを巡らせ ながら、それぞれの「困りごと」を「嬉しい！」に変えていく ことがサービスデザインです。 サ ー ビ ス を デ ザ イ ン す る と は 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 1章
10. 10 利用者に とっての価値 提供者に とっての価値 利用者にとって価値があることが前提とはいえ、あらゆる要求を実現 しようとするとサービスは持続できません。提供者視点も加味し、双 方のバランスがとれた状態を目指すことが重要です。 2 「サービスデザイン」の考え方 「利用者」も「提供者」もサービスのユーザーです サ ー ビ ス を デ ザ イ ン す る と は 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 1章 利用者にとっての価値を提供することは、すべてのサービ スにおける基本です。 しかし、サービスのユーザーには「利用者」だけでなく、 皆さんのようなサービスの「提供者」も含まれています。 利用者にとっては魅力的でも、提供者にとって運用が難し 過ぎたり予算がかかり過ぎたりするサービスは、持続が難 しく、全体的に見ると利用者のQOL向上に貢献できている と言えないかもしれません。 持続的な良いサービスは、全体最適の視点で以下のように 利用者と提供者双方の価値創出を継続的に目指していくこ とができるものと言えます。  利用者が普段の生活の中で無理なく使うことができ、困 りごとを解決できる  提供者が有限のリソースを有効活用でき、予算と社会的 成果のバランスが良い  提供者が利用者の声を聞くための接点が存在し、継続的 に改善していくことができる
11. 11 3 このガイドラインの使い方 より良いデジタルサービス作りに活用してください 本ガイドラインは、デジタルサービス局が作成した「東京都デジタルサービスの開発・運用に係る行動指針」の 構成要素の１つであり、行動規範の実践にあたって必要な技術的な基準を定めたものです。本ガイドラインを 使いこなし、より良いサービス作りを行うためにも、関連するドキュメントもぜひお読みください。 デジタルサービスの開発・運用に携わる すべての職員のミッションと使命を定義 東京都公式ホームページ作成に関する統一基準（改訂版） 東京都公式ウェブサイトについて、誰もが見やすく使いやすいサイト を作るための基準 東京都公式ホームページデザインに係るガイドライン（改訂版） 公式ウェブサイトとしての統一感を持たせ、発信力の一層の向上を図 るためのガイドライン プロジェクト監理基準 デジタルサービスの開発、サービス開始及び維持等に係る各工程にお いて予め定めた基準に適合しているかを、確認または協議する仕組み その他の関連ドキュメント 行動規範（デジタル10か条） サービスデザインガイドライン データ利活用ガイドライン セキュリティガイドライン ユーザーテスト実施手順書 ユーザーテスト（ユーザーリサーチ、プロトタイピング、ユーザビリ ティテスト）の具体的な内容が記載された手順書 機能別技術ガイドライン デジタルサービスの 開発・運用に係る行動指針 サ ー ビ ス を デ ザ イ ン す る と は 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 1章 東京都行政手続デジタル化QOS向上ガイドライン 都の行政手続デジタル化について、QOS向上に向けた品質基準と実現 に向けたアクションが記載されたガイドライン
12. 12 本ガイドラインは4章構成です。 1〜2章はサービスデザインの考え 方や検討の進め方の概要を記してお り、学習のためにもサービス作りに 取りかかる前に読んでください。 3〜4章では実際のサービス開発プ ロセスに沿って、必須事項や重要な 考え方を説明しており、実際にサー ビス開発を推進する方々にとって役 立つ内容となっています。 なお、本ガイドラインでは様々な成 果物やツールに言及していますが、 実際の検討状況に合わせて必要なも のを選ぶようにしてください。 本ガイドライン各章を利用するタイミングと主な内容 3 このガイドラインの使い方 本ガイドラインはサービス開発プロセスに 沿って構成されています 章 主な内容 想定読者 主な利用タイミング 1 章 サービスを デザイン するとは • 本ガイドラインの概要 • サービスデザインの考え方 全職員 • サービスデザインの考え方を学びた い時 2 章 東京都にお けるサービ スデザイン • サービス開発プロセス概要 • ユーザーの意見を取り入れる方法 • 「東京都サービスキャンバス」概要 • サービス開発プロセスの全体像や、 東京都サービスキャンバスの概要を 知りたい時 3 章 サービスを 考える • サービス検討における、 企画から要件定義・調達までの プロセスと重要事項 実際に サービス開 発に関与す る職員※1 • サービス企画に取り組むことになり、 各工程で気を付けるべきことを知り たい時 • ユーザーリサーチの実施手順や東京 都サービスキャンバスの書き方を知 りたい時 4 章 サービスを 実現する • サービス開発における、 設計からリリースまでの プロセスと重要事項 • 事業者とのコミュニケーションやプ ロトタイピング、ユーザビリティテ ストにおける注意事項を学びたい時 ※1：サービスデザインの重要項目から押さえたい方は各工程の [ 必ず守るポイント ] [ 重要な考え方 ] をお読みください。 サ ー ビ ス を デ ザ イ ン す る と は 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 1章
13. 13 このガイドラインの考え方と使い方 2 章 東京都におけるサービスデザイン サービス開発プロセスの概要とツール
14. 14 ２章では、東京都のサービスデザインのプロセ スを紹介します。 まず、東京都におけるサービスデザインではど のようにサービスを考え、実現するのか、その プロセスの全体像について説明します。次に ユーザーの声を取り入れるための取り組みと、 サービスの検討や全体像の整理を支援する「東 京都サービスキャンバス」の概要や使い方につ いても紹介します。 14 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 2章 の 内 容 サービス開発プロセスの全体像 1 p.15 ユーザーの声をサービスに取り入れる 2 p.16 「東京都サービスキャンバス」の使い方 3 p.20
15. 15 サービス開発プロセスの全体像 東京都では利用者の視点を取り入れたサービスを企画し、 事業者と連携のもとサービスを実現します 1 企画ではユーザーリサーチをもとに「東京都サービスキャンバス」を作成し、サービスの全体像を整理します。要件定義・ 調達では実現するサービス要件を整理します。次に、設計 / 開発 / テスト・改善ではプロトタイピングなどによりサービス を検証しながら開発を進め、テストや改善を行います。さらに、リリース後も継続的にサービスを改善していきます。 リリース テスト・ 改善 開発 要件定義・調達 定性調査・定量調査など リサーチ結果を分析 提供者エリア / 利用者エリ ア / 価値エリア 記入 リサーチ結果整理 ユーザーリサーチ 東京都サービス キャンバス記入 東京都サービス キャンバス ユーザーリサーチ 結果など ペルソナ、カスタマー ジャーニーマップなど 課題・解決策の整理 仮説の検証 目指す成果の整理 解決策エリア 記入 東京都サービス キャンバス記入 東京都サービス キャンバス 要件定義 仕様書作成 プロトタイピング 設計レビュー ユーザビリティ テスト 開発 リリース 成果物例 タスク 凡例 … チームメンバーとサービス 仮説をレビュー ワイヤーフレーム など 東京都サービスキャンバスを もとにサービス要件を整理 要件定義書 調達（業務委託契約等）に向 けた仕様書を作成 仕様書 ユーザーの声が反映されてい ることを検証 プロトタイプ 基本設計書 サービス仕様が企画に沿って いるかレビュー 詳細設計書 事業者の開発業務を理解し、 マネジメント ユーザーによるサービスの使 い勝手を検証 リリース後もデータやユー ザーの声をもとに継続的な改 善を実施 サービス・ プロダクト ユーザビリティ テスト実施計画 テスト実施結果 企画 サービス立案 仮説検討 設計 詳細設計 基本設計 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 プロセス
16. 16 サービスデザインは、ユーザーにとって「望ましい体験」 を考えることが重要です。そのサービスが本当にユーザー にとって望ましいものか検証し、ユーザーの声を取り入れ ながら開発する必要があります。例えばユーザーリサーチ を行い、課題を的確に把握する、サービス開発中の作成物 を見てもらい意見をもらう、などです。 本ガイドラインでは、サービスデザインにおける重要な観 点として「ユーザーが価値を感じられるか？」「正しく機 能するか？ 」「見やすく使いやすいか？ 」の３つを意識 することをおすすめします。例えば価値については企画段 階で検証することで、サービスの目指す姿が明らかになり、 品質向上に繋げることができます。 「価値」「機能」「見た目や使いやすさ」の3点を検証し、 それらを統合することでサービス体験を形作る必要があります。 サービス 体験 ユーザーが価値を 感じられるか？ 正しく機能 するか？ 見やすく 使いやすいか？ サービスデザインにおいては、 ユーザーの声をサービス開発の中で取り入れることが重要です サービスデザインの重要な観点*出典1 ユーザーの声をサービスに取り入れる 提供者と利用者に とって望ましい体験 サービスとは 「 」 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 2
17. 17 2 ユーザーの声をサービスに取り入れる ユーザーの声を取り入れるために ユーザーテストを実施しましょう 企画工程 プロトタイピングを行い、 ユーザー目線で画面の要素の 配置やデザインを確認する。 ユーザビリティテストを行い、 ユーザーにサービスの操作を 確認してもらう。 企画 開発工程 確認工程 テスト・改善 設計 検証観点 ユーザーリサーチの進め方 （ユーザーテスト実施手順書 01） 参 考 検証観点 機能 検証観点 プロトタイピングの進め方 （ユーザーテスト実施手順書 02） 参 考 ユーザビリティテストの進め方 （ユーザーテスト実施手順書 03 ） 参 考 ユーザーリサーチを行い、 ユーザーの要望を把握する。 また、サービス企画がユーザーの 要望と合致しているか確認する。 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 ユーザーの声をサービスに反映する取り組みの核となるの が「ユーザーテスト」です。ユーザーテストとは、ユー ザーとのコミュニケーションを能動的に行い、抱えている 要望や課題・サービスの問題点を発見し、確認する取り組 みを指します。東京都のユーザーテストは、ユーザーリ サーチ、プロトタイピング、ユーザビリティテストの3つ で構成されています。例えばユーザーリサーチは企画段階 で行うことで、品質の高いサービス企画に繋がります。ま た設計段階の作成物（プロトタイプなど）やリリース前の サービスをユーザーに試してもらう（ユーザビリティテス ト）ことで、ユーザーの要望に沿った使いやすいサービス を提供することができます。 見た目・ 使いやすさ 価値 機能 見た目・ 使いやすさ 価値
18. 18 ユーザーテストのポイント ユーザーとなる都民の方々の意見をサービスに生かしましょう 事項 概要 要件1 職員で代替できない 高齢者や子供を対象としているなど 職員では利用者目線を代替できない 要件2 案件の重要度が高い （影響度、政策的観点） 医療関係や子育て関係など 都民の生命や生活への影響度が高い 全庁を挙げて取り組むなど 政策的観点で重要である ユーザーテストの実践例 ※1：職員もサービスを利用する場合などは、職員がテスターを代替することが可能です。 2 ユーザーの声をサービスに取り入れる 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 満足度の高いサービスを作るには、「意見」を聞くのが一 番です。ユーザーとなる都民に、テスターとしてユーザー テストに参加してもらいましょう。 都民向けのサービスは、原則として都民にテスターとして 参画していただきます※1。特に下記のような場合は必ず都 民にテストしてもらいましょう。
19. 19 デザインプロトタイプ 画面の操作の流れを検証するた めにビジュアルと画面遷移や動 きを作成したもの モックアップ 画面の要素を確認するために 画面のビジュアルを作成した もの ユーザーテストのポイント ユーザーテストの型やプロセスに応じて作成物を使い分けましょう ユーザー検証のための作成物の例 サービスの仮説を形にしたモックアップなどを用いて、 仮説が妥当かユーザーに対して検証をすることは、良い サービス作りのための重要な工程です。 サービスを具体的に開発する前には、サービス要件をも とに画面の要素を簡易的に表現した「ワイヤーフレー ム」を作成し、チーム内でサービスの価値やイメージを 擦り合わせることが、サービス企画の精度を上げるため に有効です。 プロトタイピングでは、「モックアップ」「デザインプ ロトタイプ」などの、目的に応じた作成物を用いること で、具体的なサービスの流れや画面デザインが企画と相 違ないか、を確認します。ユーザビリティテストでは設 計の目的通りのサービスが実現できているか確認するた め、β版を準備します。 ワイヤー フレーム サービスの提供できる価値や利用の 流れを確認するために職員が手書き などの素早く作れる方法で画面の要 素を再現したもの 画面遷移 2 ユーザーの声をサービスに取り入れる β版 サービスリリース前に設計物を最終確認するために テスト環境で用意されたサンプルシステム 委託前 企画 工程 開発 工程 確認 工程 プロトタイピング ユーザビリティテスト 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 タスク 凡例 …
20. 20 必要な項目を網羅的に整理し サービスの全体像を描くためのツールです これまで説明したとおり、良いサービスを考える上では ユーザーの声を取り入れながら目的や価値を整理する必 要があります。この時、整理するツールとして有用なも のが「東京都サービスキャンバス」です。 より良いサービスを考えるためには、利用者・提供者そ れぞれから期待される価値を明確にし、解決策を導き出 すことが重要です。そして最終的に実現するための条件 や制約を考慮した上で、全体のバランスをとることが必 要です。 「東京都サービスキャンバス」はそのために把握すべき 項目を一枚の資料で網羅しており、サービスの全体像を 俯瞰的に捉えながら検討することができます。 拡大図は次ページ 3 「東京都サービスキャンバス」の使い方 サービスを作る場合には、新規開発、改良、いずれの場合でも予算 検討や仕様書作成の前段階から「東京都サービスキャンバス」を作 成してください。 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章
21. 21 利用者エリア 東京都サービスキャンバス VERSION 1.0.0 価値エリア 提供者エリア ・予算 ・期間 ・想定利用者数 ・想定される利用者 一人あたりのコスト 解決策エリア 中長期的に 目指すこと 担当部署： 事業名： 重要項目 困りごと 利用者がもっとも実現したいこと 嬉しいと感じること 提供者はどんな人？ 提供者がもっとも実現したいこと 提供者の価値 利用者の価値 利用者はどんな人 取り組むべき課題 解決策（実施内容） 施策を普及させるための手段 解決策を実現するための活動とリソース 目指す成果 活動評価指標 困りごと 嬉しいと感じること 3 「東京都サービスキャンバス」の使い方 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 Used as a reference 'Business Model Canvas' Strategyzer.com This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. A copy of this licence can be viewed at http://creativecommons.org/licenses/by-sa/4.0/. ・予算 ・期間 ・想定利用者数 ・想定される利用者 一人あたりのコスト
22. 22 3 「東京都サービスキャンバス」の使い方 提供者、利用者、価値、解決策の4つのエリアの項目を検討します A 提供者エリア サービスを提供する人の視点を書くエリアです。まず、前 提を整理し、あなたの思いをまとめましょう。 B 利用者エリア サービスを利用する人の視点を書くエリアです。利用する 人の立場に立って考えてみましょう。 C 価値エリア サービスに期待される価値を書くエリアです。利用者、提 供者双方の立場で捉え直しましょう。 D 解決策エリア 解決方法を考えて整理するエリアです。Ａ〜Ｃエリアに書い た内容を振り返り、全体のバランスを意識しながら、取り組 むべき課題と解決策、目指す成果を考えましょう。 A C A C B D 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章
23. 23 1 3 2 4 5 6 7 8 1 提供者エリア 提供者の置かれている状況や実現した いこと 2 利用者エリア リサーチに基づいた、利用者の置かれ ている状況や実現したいこと 3 価値エリア 利用者や提供者の実現したいことを踏ま えた「望ましい体験」や「あるべき姿」 4 取り組むべき課題 サービス提供によって解決すべき課題 5 解決策（実施内容） 価値を実現するための解決策 6 目指す成果 行政としてどのような社会を目指すか というビジョン 7 活動評価指標 目指す成果と因果関係のある計測が可 能な活動評価指標 8 施策を普及させるための手段 解決策を実現するための活動とリソース 本ガイドラインでは、サービスを新規企画する場合を想定し、 〜 を基本的な流れとして書き方を解説します。事業によっては予 算、期間等の制約条件が決められている場合もあるため、状況によっ て順番を変えて内容を検討してください。キャンバスの上半分は利用 者と提供者双方の視点からサービスの価値を考えましょう。下半分で はその価値を実現するための解決策を全体最適の視点で考えます。 3 「東京都サービスキャンバス」の使い方 各項目の記入内容を理解しましょう 1 8 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章
24. 24 キャンバスは繰り返し書き直しながら更新しましょう 3 「東京都サービスキャンバス」の使い方 「東京都サービスキャンバス」は、項目を埋めただけで完 成するものではありません。キャンバスを利用することで サービス全体像を描き出すだけでなく、記載内容の議論や 深掘りを通じてサービス企画の精度を高めることができる、 いわばサービスを「育てていく」ためのコミュニケーショ ンツールでもあるのです。サービスの企画からリリース以 降も継続して利用できますので、一度書き終えた後も都度 見直し、キャンバス内容を更新していきましょう。 3章-企画プロセスにてキャンバスを書き終えた後も、ユーザーテスト の結果や本ガイドラインを参考にキャンバスを見直しましょう。 2023 年 3 月 31 日　 東京都デジタ ルサービス局　 サービ スデザイ ン ガイド ラ イ ン VERSION 1.0.0 東京都サービスキャンバスを活用するタイミング キャンバス 活用イメージ 仮説検討 サービス立案 要件定義 調達 基本設計 詳細設計 開発 テスト・ 改善 リリース サービス 全体像 企画 要件定義 設計 初版 精緻化 継続・新規 取り組み に活用 仮説展開 情報共有ツールとして 都度更新しながら活用 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 2章 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章
25. 25 このガイドラインの考え方と使い方 3 章 サービスを考える 東京都サービスキャンバスを作成する
26. 26 ３章では、２章で紹介した全体プロセスの内、 サービスを企画し、要件をまとめるまでのプロ セスを追っていきましょう。 この工程では「東京都サービスキャンバス」を 作成しますが、各プロセスでどのように考えて キャンバスを書き進め、ユーザーの声を取り入 れるのか、これらの観点も踏まえて順を追って 紹介します。 要点を把握するためにも、各プロセスの「必ず 守るポイント」「重要な考え方」は必ず読んで ください。 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 26 3章 の 内 容 企画 - 仮説検討 1 p.29 企画 - サービス立案 2 p.41 企画 - 要件定義・調達 3 p.53
27. 27 サービス開発の全体像と各プロセスの重要なポイントを 理解しましょう 本ガイドラインはサービス開発の進め方に沿って、プロセスの概要やサービス開発を実施する上で皆さんに知ってもらいた い情報を記載しています。特に必ず守るポイントで記載されている内容には注意して読み進めるようにしてください。成果 物は例となりますので、プロジェクト毎に必要に応じて作成するようにしてください。 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 3章、4章の読み方 3・4章のガイドラインのページ構成はプロセスやタスクの内容により階層（深さ）が3つに分かれます 詳細説明 1.1 実践のポイント 1.1.1 概要説明 1
28. 28 サービスの全体像を描く企画 / 要件定義・調達 まずはサービス全体像の企画を検討した後、サービス実現に向けて要件を整理します。特に企画段階では、検討すべき項目 を集約した「東京都サービスキャンバス」や、ユーザーリサーチ、課題と解決策の整理、ワイヤーフレームでの価値検証な ど様々な考え方・手法を活用し、企画の精度を向上させましょう。 仮説検討 サービス立案 ユーザーリサーチなどの調 査を実施し、サービスを企 画するための提供価値を定 める。東京都サービスキャ ンバス上半分を記入する。 課題と解決策を策定し、優 先順位付けや検証を通して サービスを形作る。東京都 サービスキャンバスの下半 分を記入する。 企画 要件定義・調達 3章の全体像・使い方 東京都サービスキャンバス の記入内容をもとに、サー ビスの実現のために必要な 要件を具体化する。 要件定義 仕様書作成 企画したサービスの仕様書 を作成し、調達を実施して 事業者の選定を進める。 1 2 3 ユーザーリサーチ結果 ターゲットユーザー像 ペルソナ 共感マップ カスタマージャーニーマップ 東京都サービスキャンバス （提供者 / 利用者 / 価値エリア） 課題一覧 課題の解決策案 ワイヤーフレーム 仮説検証結果 東京都サービスキャンバス （解決策エリア） 仕様書 要件定義書 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン
29. 29 サービス企画の第一歩として、ユー ザーが求めている価値はどのような ものか、仮説を検討します。 精度の高い仮説を作るためには思い 込みやその場のアイデアではなく、 リサーチ結果などの事実をもとに ユーザーの人物像や背景にある状況 を深く理解する必要があります。 企画 - 仮説検討 仮説検討の全体像 ユーザー リサーチ 利用者 / 提供者 エリア記入 リサーチ 結果整理 • ユーザーリサーチ を実施 • ターゲットユー ザー像を特定 進め方 事業目標や仮説に 基づいてユーザー リサーチ計画を立 てる ユーザーリサーチ 計画に基づき、定 性調査や定量調査 を実施する 必ず守るポイント • ユーザーの潜在的な 課題や要望の探索 • ペルソナなどの成果 物作成・関係者共有 • 東京都サービス キャンバスの提供 者エリア・利用者 エリア記入 • 利用者・提供者に とっての価値を検討 • 東京都サービスキャ ンバスの価値エリア 記入 • キャンバス上半分の 見直し 定性調査や関係者 ヒアリングなどの リサーチ結果をも とに、潜在的な要 望や課題がないか、 分析・検討する ユーザーリサーチ、 関係者ヒアリング をもとに東京都 サービスキャンバ スを記入する 利用者と提供者双 方に価値がある状 態を想定する 提供者・利用者の 「価値エリア」と 「実現したいこ と」の整合をとる 1 仮説検討 ユーザーリサーチ結果 ターゲットユーザー像 ペルソナ 共感マップ カスタマージャーニーマップ 東京都サービスキャンバス （提供者 / 利用者 / 価値エリア） 1 価値エリアの 記入 1.1 1.2 1.3 1.4 タスク 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン
30. 30 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 ユーザーリサーチの概要 利用者が抱える要望や課題を明らかにするためにインタ ビューやアンケートなどによる調査をします。この工程が 利用者が求めるサービスの実現を導く基盤となります。 ユーザーリサーチは、利用者に満足してもらえるサービ スを企画するための基盤です。ターゲットとなる利用者 像を設定※1し、その行動、動機、課題を調査することで、 利用者に喜ばれるサービス立案に繋げます。 1 . 1 ユーザーリサーチ 必ず守るポイント  事業目標や仮説に基づき、ユーザーリサーチ計画を立てる  ユーザーリサーチ計画に基づき、定性調査や定量調査を実施する 重要な考え方  リサーチ目的に応じて定性調査や定量調査を実施する  あいまいな利用者像ではなく、ターゲットとなる利用者像 をしっかり定義し、その特徴・行動を明らかにする  ターゲットとなる利用者のサービスに対する動機付けを 検討・整理する ※1：リサーチを実施する対象はサービスのターゲットユーザーを想定しており、背景にある事業目的やサービスコンセプトから検討します。 ペルソナはターゲット像をもとに、より詳細に対象の属性を記述することで関係者間で共通認識を得るための成果物となります。 定性調査 インタビューなどから、課題を 具体的に把握 ◦◦システムの 使い勝手について 詳しく教えて ください 定量調査 アンケートなどから、仮説とし て持っている課題を検証 〇〇は課題だと 思いますか？ 1. 思う 2. 思わない • 目的、手法の検討 （インタビュー・アンケート） 計画 • 利用者像の検討、テスター確保 • 質問項目の作成、テスト環境確保 準備 • インタビューやアンケートの実施、結果分析 実施、 結果分析 ユーザーリサーチの結果をもとに以下の内容を明らかにします。 • ターゲットユーザー像 • ターゲットユーザーの特徴や行動 • ターゲットユーザーの抱える要望や課題 サ ー ビ ス を 考 え る 3章 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4 ポイント ポイント
31. 31 1 . 1 . 1 ユーザーリサーチの要点 利用者を理解し、本質的な課題や新しい価値を見つけましょう ユーザーリサーチでは、新しい発見を目的として定性調 査を重視し、利用者が行動する状況や動機、その背景に ある要因を理解することを目指します。選択肢式アン ケートを通じて傾向を把握し、統計的な証明を得るため の定量調査と異なり、定性調査では一人ひとりの利用者 のありのままを理解することが大切です。 リサーチ結果をサービス開発に活用するために、定性調 査で得られたデータを分析します。定性調査で主に扱う のは数字ではなく言語であり、利用者の発言や行動から 新しい意味を探します。例えばインタビュー対象者の発 言内容を整理・グループ化し、共通点を見出すことで、 課題や要望の傾向を分析することができます。 詳細は、「ユーザーリサーチの進め方（ユーザーテスト実施手順書 01）」へ。 また、データを活用したリサーチの考え方は「データ利活用ガイドライン」も参考にしてください。 サービスデザインにおけるリサーチでは発見型の定性調 査を重視して実施します。 定性調査 発見型 定性データから新し い価値を発見する 例）行動観察調査、 インタビューなど 定量データから新た な意味を見出す 例）データマイニン グなど 定量調査 検証型 サービスの仮説を検証 する 例）プロトタイピング、 ユーザビリティテスト など 定量データを統計的に 処理し仮説を検証する 例）選択肢式アンケー トなど ポイント サ ー ビ ス を 考 え る 3章 *出典2 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4
32. 32 リサーチ結果をもとにサービスデザインの代表的な分析 手法（ペルソナ・カスタマージャーニーマップなど）を 用いて、ユーザーの潜在的な要望や課題を明らかにしま す。 1 . 2 リサーチ結果整理 必ず守るポイント  定性調査や関係者ヒアリングなどのリサーチ結果をもと に、潜在的な要望や課題がないか、分析・検討する 重要な考え方  ターゲットとなる利用者像を具体的に定義し、 その考え方や要望を明確にする  関係者で共通認識を持つために、ペルソナ、カスタマー ジャーニーマップ、共感マップなどの成果物を作成する  成果物は想定する利用者の声をもとに作成し、 関係者で継続して共有・改善を行う 観点 捉えるもの 「東京都サービス キャンバス」の該当項目 代表的な分析方法 属性 利用者が 持っている 性質 • 利用者はどんな人 • ペルソナ 行動 利用者の特 徴的な行動 と場面ごと の感情 • 困りごと • 嬉しいこと • カスタマー ジャーニー マップ 考え方 利用者の 価値観 • 困りごと • 嬉しいこと • 利用者が最も実現 したいこと • 共感マップ 上記以外にも様々な分析手法がありますが、 実施しやすい代表的なものを挙げています。 利用者を捉えるための3つの観点 ユーザーリサーチから得られたデータをもとに、利用者を より深く理解するために、「属性」「行動」「考え方」と いう3つの観点から利用者を捉えることが役立ちます。 ポイント 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4
33. 33 ペルソナとは、利用者の立場に立ってサービスを企画・ 開発する際、関係者間で利用者の「属性」について共通 認識を得るための手法です。ここでの「属性」には大き く次の2種類があります。  デモグラフィック属性：年代、職業、家族構成など人口 統計学的な性質の総称  サイコグラフィック属性：性格や価値観、ライフスタイ ルなど心理的な性質の総称 ペルソナの作成時は、インターネットなどで情報を収集 し、利用者に関して自分なりの仮説を作ることから始め てみることをおすすめします。 最終的にはユーザーインタビューなどによって得られた 生の声（一次情報）に基づいて肉付けするようにしてく ださい。 ペルソナのイメージ図。顔 写真や名前、職業、年齢、 価値観、普段の行動などの 情報を集約した資料を作成 します。特徴的な価値観や 行動、情報リテラシーや障 害の有無、サービス利用状 況に関係する身体的・心理 的な特性など、サービス利 用上考慮すべき要素は「東 京都サービスキャンバス」 にも記入してください。 この作業は利用者エリアの 「利用者はどんな人？」の 項目を考える上で重要な作 業です。 ペルソ ナ 名前 現役のこ ろ は忙し かっ たから ね こ の⼈の⼝癖 基本プロフ ィ ール 東 京都（ あずま けいと ） 性別 年齢 居住地 趣味 家族構成 部署 / 業務内容 今年の⽬標 男性 67歳 妻、 ⼦ども 2⼈（ 独⽴し て別居） 東京都 練⾺区 2年前に定年退職（ 以前は営業部⻑） 新し い趣味を⾒つけたい 仕事帰り の飲み会だっ たが 最近は参加機会がない （ 地域の交流会などに参加し てみたいが、 気恥ずかし さ が強い） 1 . 2 . 1 「属性」を捉える ペルソナの活用 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4
34. 34 サービスデザインでは、一連の利用者の行動を「カスタ マージャーニーマップ」というツールで可視化します。 利用者の行動を理解するためには、「何をしているか」 だけではなく、「いつ・どこで・どのような状況で・誰 と・どのような手段で、しているか」まで掘り下げて理 解することが重要です。それにより、現状の体験が可視 化され、不満に感じる瞬間や、既存サービスの改善点を 発見することができます。 なお、利用者の行動は、サービスの利用中だけではなく、 利用する前、利用開始時、利用後も含めて考えてくださ い。時間の範囲を広くとることで、サービスが使われな い理由、サービス利用前や利用後に提供者側が支援すべ きことに気付くことができます。 体験前に 想像する 体験する 利用前 利用中 利用後 体験を 振り返る カスタマージャーニーマップのイメージ図。利用者の体験を時系列で書き出し、 それぞれの瞬間で、利用者が考えていることや気持ちなどを整理します。利用者 の立場で体験を捉えることで、サービスの改善ポイントをより深く検討すること ができます。この作業は「利用者の価値」や「提供者の価値」を考える上で、何 が課題となるのか、時系列の体験として捉えられる重要な作業となります。 利用者の行動 • いつ • どこで • どのような状況で • 誰と • どのような手段で 担当者・ 関連する書類 利用者の感情 不安 安心 疑問 税務署での確定申告の例*出典3 説明職員 受付窓口 申込書 税務署を訪問し、 職員のサポートを 受ける 受付窓口で完了の 通知を受ける 申込書を税務署に 行く前に準備する 初めての確定 申告。時間も かかるし難し そうだな… 職員のサポートを 受けながら作成し て安心。間違えな いように集中しな きゃ！ これで本当に完了 だよね…？ 次回 はデジタル手続き にできるのかな？ 1 . 2 . 2 「行動」を捉える カスタマージャーニーマップの活用 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4
35. 35 利用者が価値を実感できなければサービスが利用されるこ とはないため、「考え方」を捉えることはサービス開発に おいて非常に重要です。そのためには共感マップの活用が 有効です。 共感マップは、行動や感情などの整理項目に基づいて利用 者の置かれている状況を整理するツールです。リサーチか ら得られた利用者の考えや行動に関する情報を整理して意 味付けすることで、利用者の考え方や価値観を分析するこ とが特徴です。 共感マップを活用して得られた結果を「東京都サービス キャンバス」に転記しても良いでしょう。「ペイン」と 「ゲイン」は、「困りごと」と「嬉しいこと」に相当しま す。 共感マップは利用者の感情や行動を7つの観点で整理する手法です。 ユーザーリサーチの実施者が実際の利用者の反応なども踏まえて、 利用者の目から世界がどう見えるか？ を考えることが重要です。 1 2 3 4 5 6 1 共感の対象となる利用者は誰？ 3 何を見てる？ 5 何をしてる？ 2 利用者がやりたいことは？ 4 何と言ってる？ 6 何を聞いてる？ 7 7 何を考え、感じている？（ペイン / ゲイン） *出典4 1 . 2 . 3 「考え方」を捉える 共感マップの活用 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4
36. 36 ユーザーリサーチやヒアリングなどを通して、提供者と 利用者それぞれの立場を理解できた後は 「東京都サービ スキャンバス」の「提供者エリア」「利用者エリア」を 記入します。 必ず守るポイント  ユーザーリサーチ、関係者ヒアリングをもとに 東京都サービスキャンバスを記入する 重要な考え方  提供者エリアは事業の内容や目標に基づいて 記入する  利用者エリアはサービスのターゲットとなる 利用者像を明確にする 提供者エリア記入のポイント 利用者エリア記入のポイント サービス提供者の前提 を整理するエリアです。 提供者が考えるサービ スの目的や狙いを整理 しましょう。 サービス利用者像を明 確にするエリアです。 利用者の立場に立って サービスの価値を考え るために最も重要な箇 所です。 利用者エリア 利用者がもっとも実現したいこと 利用者はどんな人？ 困りごと 嬉しいと感じること 日中に一人で行けるような、楽しめる場所・コミュニ ティを増やし、仕事以外の新しい友人と出会うこと • 仕事以外の友人が少なく、日中 は家にこもりがちなこと • 日中、一人で気軽に行ける場所 がないこと 定年退職後の男性で、妻と二人暮らし。時間に余 裕はあり、地域活動にも関心はあるが、これまで 参加したことがない 提供者エリア 困りごと 嬉しいと感じること 提供者はどんな人？ 提供者がもっとも実現したいこと 住民参加型の地域づくりを目指す部署で、 地域の施設や活動に関する情報発信を担当 より多くの人、特に普段施設を利用しない人たちに、地域が運 営している施設を知ってもらい、気軽に利用してもらいたい 地域の公共施設の利用率と 認知度が低く、利用者も特 定の人に偏っていること 地域活動に対する住民の関心 が高まることで地域イベント の数と参加者が増えること 1 . 3 東京都サービスキャンバス 提供者 / 利用者 エリア サ ー ビ ス を 考 え る 3章 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 • 興味があることについて、誰 かと楽しく会話すること • 退職前は出来なかった新たな 楽しみを見つけられること
37. 37  提供者はどんな人：サービス提供者の部署や役職名だ けではなく、役割が具体的に分かるように書きます。  困りごと：リサーチ結果を引用し、提供者が業務にお いて課題と感じていることを書きます。  嬉しいこと：リサーチ結果を引用し、提供者にとって 起こると嬉しいことを書きます。  提供者がもっとも実現したいこと：「困りごと」「嬉 しいこと」の内容を要約し、今はできていないが解 決・改善・達成したいことを書きます。例えば「利用 者や住人が気軽に地域イベントに参加してくれる」 「定形的な申請業務の手間が無くなる」などです。手 段を通じて解決したい困りごとや、叶えたい嬉しさを 考えることが重要です。 チェックすべきこと  提供者の事業の目的や、業務を通して解決したい課題や 実現したいことをもとに記入している  サービス改修の場合は、解決したい課題を予め洗い出し、 それらをもとに記入している ポイント 提供者エリア 困りごと 嬉しいと感じること 提供者はどんな人？ 提供者がもっとも実現したいこと 住民参加型の地域づくりを目指す部署で、 地域の施設や活動に関する情報発信を担当 より多くの人、特に普段施設を利用しない人たちに、地域が運営し ている施設を知ってもらい、気軽に利用してもらいたい 地域の公共施設の利用率と認 知度が低く、利用者も特定の 人に偏っていること 地域活動に対する住民の関心 が高まることで地域イベント の数と参加者が増えること 1 . 3 . 1 提供者エリア サービス検討における提供者の前提や考えを書きましょう 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4
38. 38  利用者：解決すべき問題を抱えている人の情報を書きます。 あなたが実現したいと思っていることに対し、最も多くの困 難を抱えていると考えられる人を想定して書いてください。  困りごと：リサーチ結果を引用し、利用者が普段の生活の中 で感じている困りごとを書きます。  嬉しいこと：リサーチ結果を引用し、利用者にとって起こる と嬉しいことを書きます。  利用者がもっとも実現したいこと：「困りごと」「嬉しいこ と」の内容を要約し、今はできていないが解決・改善・達成 したいことを書きます。例えば「必要な情報に簡単にアクセ スでき、手間と不安から解放される」「仕事・家庭以外の交 流の場を持つ」などです。手段を通じて解決したい困りごと や叶えたい嬉しさを考えることが重要です。 チェックすべきこと  利用者の状況・感情に基づいて記入する （カスタマージャーニーマップの検討）  利用者の困りごと・嬉しいこと・実現したいことの整合 性を考慮して記入する  全ての人の要望に応えるのではなく「深刻な問題を抱え ている人」「本質的な要因」を持つ利用者を設定する （ペルソナの検討） ポイント 1 . 3 . 2 利用者エリア ターゲットとなるサービス利用者の立場で考えましょう 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4 利用者エリア 利用者がもっとも実現したいこと 利用者はどんな人？ 困りごと 嬉しいと感じること 日中に一人で行けるような、楽しめる場所・コミュニティを 増やし、仕事以外の新しい友人と出会うこと • 仕事以外の友人が少なく、日中 は家にこもりがちなこと • 日中、一人で気軽に行ける場所 がないこと 定年退職後の男性で、妻と二人暮らし。時間に余裕はあり、 地域活動にも関心はあるが、これまで参加したことがない • 興味があることについて、誰か と楽しく会話すること • 退職前は出来なかった新たな楽 しみを見つけられること
39. 39 提供者・利用者の情報や、ユーザーリサーチから得られた 分析結果をもとに、サービスを通して得られる提供者や利 用者の価値を考えます。提供者・利用者の双方のメリット を考えてサービスが提供すべき価値を記入しましょう。 価値エリア記入のポイント 必ず守るポイント  利用者と提供者双方に価値がある状態を想定する  提供者・利用者の「価値エリア」と「実現したいこと」 の整合をとる ※チェック方法は右記のポイントを確認 重要な考え方  利用者が望むことや困りごと・嬉しさについて その利用者ならではの視点をもとに価値を検討する  利用者の価値を書く際、提供者の都合で価値の範囲を 狭めないようにする 「利用者（提供者）の実現したいこと」に対し、So what?（だから 何？）と何度も問いかけてみると、その答えの延長線上に「利用者 （提供者）の価値」がでてきます。 ここは「取り組むべき課題」に深 く関わる部分ですので、じっくり考えて書きましょう。 本書における「価値」とは 利用者や提供者が実現した いことを踏まえて、「望ま しい体験」や「あるべき 姿」について記入してくだ さい。 提供者 エリア 利用者 エリア 価値 エリア 解決策エリア 記入の例 夫婦で子育てに関する情報を スムーズに共有したい 夫婦が対等に支え合って 子育てができる ポイント 利用者の実現したいこと 利用者の価値 理想のあるべき姿は何か？ ポイント 価値エリア 提供者の価値 利用者の価値 • 地域住民にとって施設が日常的に利用され る、生活の一部のような存在となること • 地域活動に対する住民の参加が増えること • 日常生活で、自分の「居場所」が自宅 以外にもあると実感できる • 地域活動への参加を通して、生活に張 り合いがでること 1 . 4 東京都サービスキャンバス 価値 エリア 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4
40. 40 利用者の価値・提供者の価値：利用者・提供者にとってそ れぞれ価値と感じることを書きます。価値とは、利用者や 提供者がそれぞれ「望ましい体験」や「あるべき姿」と いった実現したいことの延長線上にある姿を記入します。 チェックすべきこと  利用者が望むメリットや喜びが、利用者の視点で 捉えられている  誰にでも当てはまることを書くのではなく、 その利用者ならではの価値が捉えられている  利用者の価値を書く際、提供者の都合で価値の範 囲を狭めないようにする ポイント 価値エリア 提供者の価値 利用者の価値 • 地域住民にとって施設が日常的に利用され る、生活の一部のような存在となること • 地域活動に対する住民の参加が増えること • 日常生活で、自分の「居場所」が自宅以外 にもあると実感できる • 地域活動への参加を通して、生活に張り合 いがでること ポイント 1 . 4 . 1 価値エリア 利用者・提供者がサービスに対して期待している価値を 双方の立場で考えましょう 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 仮説検討 ユ ー ザ ー リ サ ー チ 1 . 1 リ サ ー チ 結 果 整 理 1 . 2 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 1 . 3 1 . 4
41. 41 サービス立案 2 ユーザーへの提供価値を定めた後は サービスを立案するために、解決すべ き課題と解決策を検討します。専門家 や第三者の協力を得ることで企画の精 度を高めることができます。 サービスが社会へ与える影響を考えな がら最終的に目指す成果を検討し、 東京都サービスキャンバスの下半分に その検討した内容をまとめます。 企画 - サービス立案 サービス立案の全体像 2  ロジカルシンキ ングなどの手法 をもとに理由や 原因を深掘る  ユーザーが抱え ている課題を洗 い出し、優先順 位を付ける • サービスの 図式化・ワイ ヤーフレーム の作成 • 第三者による レビュー実施  解決すべき課題 と解決方法を幅 広く洗い出す  解決策は専門家 などの多様な知 見をもとに検討 し、優先順位を 付けて選定する  検討したサービ ス仮説が、ユー ザーに対して価 値があるか関係 者を交えて検証 する  実現したいサー ビス内容・目指 す成果・評価指 標は、一貫性の あるロジックで 整理する  行政が取り組む べきか、という 観点で記入する  東京都サービス キャンバス全体 を見直す 課題の整理 解決策の整理 仮説の検証 目指す 成果の整理 東京都サービス キャンバス記入 • 課題に対する 解決策を展開 • 行政が実行す べき解決策の 絞り込み • 価値の阻害要 因となる課題 の洗い出し • 課題の真因の 深掘り • 課題の優先順 位付け • 「最も実現し たいこと」や 「価値」との 整合性を考え ながら、短期 と中長期の成 果を整理 • 東京都サービ スキャンバス の解決策エリ ア記入と、記 載内容全体の 見直し 課題一覧 課題の解決策案 ワイヤーフレーム 仮説検証結果 東京都サービスキャンバス （解決策エリア） 進め方 必ず守るポイント タスク 2.1 2.2 2.3 2.4 2.5 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン
42. 42 ユーザーの価値を実現するために行政が取り組むべき課 題が何かを特定します。なぜ現状では価値が実現できて いないのか？を深掘りすることでサービスの機能や要件 が明確になります。 必ず守るポイント  ロジカルシンキングなどの手法をもとに、理由や原因を 深掘る  ユーザーが抱えている課題を洗い出し、優先順位を付ける 重要な考え方  ユーザーの嬉しいこと・困りごと・実現したいこと・価値 などの背景に、どんな根本的要因があるのかを考えた上で、 課題を記入する  価値実現の阻害要因分析としてロジックツリーを用いるな ど、提供したい価値に紐付く課題を洗い出す。また、課題 同士の因果関係も注視し、真因を探るよう努める サ ー ビ ス を 考 え る 3章 課題を深掘りするための2つの観点 目の前の理解しやすい、表面的な課題だけでなく、 課題の真因を深掘りすることが重要です。 ユーザーの潜在的な課題の深掘り ユーザーを取り巻く状況に関する課題の深掘り ユーザーの発言や行動につ いて、「なぜ、こうしてい る（したい）のか？」「ど ういう意味を持つのか？」 など、心の声を掘り下げて 考えることが重要です。 本質的価値や潜在的な欲求は 氷山に例えられます 顕在的 潜在的 ユーザーの課題には様々な 関係者の存在や利害が背景 にある場合があります。 ユーザーの置かれた状況を 一歩引いた視点で観察する ことで課題を正しく捉える ことができます。 ミクロ マクロ 俯瞰視点が大事です ポイント サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3 2 . 1 課題の整理 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成
43. 43 SNS・サイトの存在が知られていない 広報のチャネルにアクセスしづらい 魅力的な情報提供が出来ていない 公共施設での イベントの 知名度が低い のはなぜ？ オフラインで の広報に問題 がある オンラインで の広報に問題 がある なぜか？を問い続ける MECE※1に整理 公共施設での イベント知名 度を上げたい 提供者の課題を分析した例 ※1：「MECE」とはMutually Exclusive and Collectively Exhaustive の略で、「漏れなく・重複せず」との意味を持ちます。 チラシ等広報文書が認識されていない 逃している広報機会が存在する 広報文書での情報提供が十分でない 通常、課題は一つではなく複雑に絡み合っています。課題 や解決策の整理においては、思いついたアイデアや上位者 の意見に流されず、構造的・論理的に思考（ロジカルシン キング）することが重要です。そのためにまずは課題を洗 い出してから優先的に対応すべき課題を決めましょう。解 決すべき課題を正しく特定することは、解決策の精度向上 や目指す成果の実現に繋がります。 ロジカルシンキングでは様々な手法が挙げられますが、中 でも原因究明型のロジックツリーでは課題をMECE※1（漏 れなく重複なく）に洗い出すことができます。これは最初 に設定した問いについて理由を問い続ける手法です。 この時、キャンバス上部で記載した（利用者・提供者の） 「嬉しいと感じること」、「困りごと」及び「最も実現し たいこと」がなぜ実現できないのか？という問いから始め ると良いでしょう。 2 . 1 . 1 課題整理のポイント 目の前のアイデアに飛びつかず、ロジカルシンキングで順を追って特定する 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3
44. 44 解決策の整理の流れ 取り組むべき課題を特定した後は、それらの課題に対し、 より良い解決策の仮説を導いていきます。ブレインス トーミングなどを活用して解決策のアイデアを多様な視 点で展開し、優先度を設けてアイデアを選定した後、行 政が取り組むべき解決策を決定します。  解決すべき課題と解決方法を幅広く洗い出す  解決策は専門家などの多様な知見をもとに検討し、 優先順位を付けて選定する 重要な考え方  利用者と提供者の価値と解決策が整合しているか確認する  民間ではなく、行政が取り組むべきか検討している  サービス展開により生じるリスクを把握している 発散 「発散」と「収束」のどちらのための議論か意識しましょう。 • 検討の幅を拡げるため、前例に囚われないような環境 で、解決のための問いやアイデアを発散する ブレイン ストーミ ング • アイデアを分類し、他の切り口がないか検討する • 専門家の知見なども有効活用する アイデア 展開 • 利用者観点、提供者観点、社会的観点といった 評価観点を設定し、アイデアを評価する アイデア 評価 多様な視点で アイデアを 考える アイデアに 更なる切り口 はないか 検討する アイデアを 評価し 意思決定する 収束 観点 評価観点の例 利用者 価値との整合性があるか / 使いやすいか / 多くの利用者に便益があるか 提供者 東京都が行うべきか / 運用性が良いか / 展開性があるか 社会 倫理的か / 不利益者はいないか / リスクは少ないか 必ず守るポイント 2 . 2 解決策の整理 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3
45. 45 解決策のサービス仮説ができたら簡易的な検証方法（ワ イヤーフレーム作成など）を用いて、立案したサービス が価値提供において妥当かどうか確認し、仮説を見直し ます。ユーザーを巻き込んだ検証ができると、満足度の 高いサービスに繋がりやすくなります。 必ず守るポイント  検討したサービス仮説が、ユーザーに対して価値がある か関係者を交えて検証する 重要な考え方  サービス企画内容が利用者、提供者双方にとってどのよう な価値を提供するか、具体的に把握する  定義した価値と解決策が、利用者にとって嬉しいものに なっているか、困りごとを解決しているか確認する  サービスの利用に際して想定される困難などが明らかに なった場合、対策を検討する 仮説の検証の流れ 仮説をもとにサービスを図式化したものやワイヤーフレーム などを作成して、関係者にレビューをしてもらいましょう。 • 東京都サービスキャンバスに記入した内容を もとにサービスの利用の流れや必要な機能を 書き出す サービス の 図式化 • サービスを形にした時にどのような機能やコ ンテンツが必要か画面のイメージを書き出す ワイヤー フレーム の作成 • サービスの関係者や、利用者に詳しい専門家、 ターゲットとなる想定ユーザーなどに、作成 したサービス図やワイヤーフレームを提示し てレビューをしてもらう 関係者 からの レビュー 自分たちでできる素早く手軽な方法（パワーポ イントや紙とペンなど）で作成しましょう。 デザインの作り込みは不要です 「利用者が価値を感じられるか？」は 可能な限り企画段階で検証してください ポイント ポイント 2 . 3 仮説の検証 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3
46. 46 利用前 利用中 利用後 利用者が解決 したいこと 「自分に合った 授業動画を 探したい」 インプット 利用者がやること 利用者の入力 データ アウトプット システムが返すもの 利用者に適切な コンテンツ 利用後の感情 「ぴったりな 授業動画が見つ かり嬉しい」 シ ス テ ム 内 処 理 メニュー 学習コンテンツの取 り組み状況をグラフ で可視化 おすすめ 写真と テキスト 写真と テキスト お知らせコンテンツ お知らせ 最後に学習した内容 教育コンテンツを提供するサービスの図式化の例 ・学年 ・成績 ・ユーザーの好み ・条件に合った 授業動画 ワイヤーフレームの例 手書き パワーポイント 機能やサービス要件に ついて集中して審議で きます サービスの仮説を具体化することで、サービスの要件と して考えるべき点やユーザーへサービスを提供する際に 注意が必要な点について気付くことができます。サービ スの要件を図やダイアグラムを用いて整理するサービス の図式化と、サービスのインターフェースのイメージを 書き出すワイヤーフレームといった手法が有効です。 サービスの図式化では、サービスの利用前から利用後ま で利用者とシステムが行うことを書き出してみましょう。 例えば、右図のようにサービスの一連の体験を可視化す ることも要件の具体化には有効です。 ワイヤーフレームは、サービスでどのような機能やコン テンツが必要かを検討するための設計図です。シンプル な線と図、文字で作成することができます。 2 . 3 . 1 仮説検証のためのワイヤーフレーム作成のポイント サービスを図や文字を使って形にしてみましょう 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3
47. 47 目指す成果を整理する2つの観点 検討しているサービス企画の目指す成果と、 成果を測るための具体的な指標の両方を考えましょう。 必ず守るポイント 重要な考え方  サービス実現から成果創出までのストーリーが、 第三者にとって違和感がないか確認してもらう  目指す成果に対して、実現したいサービスが本当に有効か、 成果創出までのストーリーを追いながら確認する 行政としてリソースを使い関係者を巻き込んで取り組む ためには、目指す成果をしっかり言語化することが大切 です。サービスが実現した先のビジョンを考えながら、 社会・公共にどのような効果をもたらすか、それはどの ような指標で測れるか、を具体化します。  実現したいサービス内容・目指す成果・評価指標は、 一貫性のあるロジックで整理する サービスの リリース 中長期的に 目指す成果 目指す成果 1-2年後 3-5年後 目指したいサービスが社会や公共にどのように 貢献できるか考えながら成果を具体化します 成果の達成状況が分かるように 計測できる指標を決めておきます 目指す成果 活動評価指標 活動評価指標の例 • 都民満足度評価結果の改善 • イベント参加人数の増加 • 宣伝ページ閲覧数の増加 2 . 4 目指す成果の整理 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3 ポイント
48. 48 これまでの検討を踏まえて東京都サービスキャンバスの 解決策エリアを記入します。キャンバスの上半分のエリ アも合わせて確認し、改めて各項目間の繋がりを意識し て見直しましょう。 必ず守るポイント  行政が取り組むべきか、といった観点のもとに記入する  東京都サービスキャンバス全体を見直す 重要な考え方  各項目について下記を確認する 課題と解決策の記入のポイント 価値を実現するための解決策を考えるエリアです。 解決策の良し悪しは、その前提となる課題設定によって大きく 左右されますので、的確な課題を設定した上で解決策を考えま しょう。 目指す成果の記入のポイント サービスによって目指したい成果を考えるエリアです。 行政として相応のリソースを使い、関係者（事業者など）を巻 き込んで取り組むためには、その先にどのような社会を目指し たいか？というビジョンを言語化することが大切です。 ・ 課題：行政が合理的に解決できそうか ・ 解決策：行政が取り組むべき妥当性があるか ・ 活動評価指標：実際に計測可能か ・ 施策を普及するための手段： ユーザーやステークホルダー※1に対し、効果的かつ合理的か ・ サービスの開発と運用に必要な活動とリソース： 期限や技術的制約などの留意点を考慮できているか ※1：「ステークホルダー」とは組織の活動により利益・損害を受ける関係者や団体を指します。 解決策エリア 取り組むべき課題 解決策（実施内容） 施設に対する住民の認知度が低い（利用者にとっ ては自宅以外の「居場所」、地域活動の拠点にな りうるということが知られていない） • 施設の使い方や地域活動の最新イベントを紹介するホー ムページを作り、希望者にはメルマガを配信する • ホームページでは、自分にあった施設やイベントをキー ワード検索できる機能を搭載する 中長期的に目指すこと 目指す成果 社会的な居場所づくり、市民同士の支え合い活動の推進 • 地域活動やイベントへの参加者が増える • シニア男性が地域活動に参加することで、独居老人や孤独 感に悩む高齢者が減少する 活動評価指標 • 施設利用者数と男性シニア層利用者の増加率 • ホームページで紹介される地域イベント数 2 . 5 東京都サービスキャンバス 解決策 エリア 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3
49. 49 解決策エリア 取り組むべき課題 解決策（実施内容） 施設に対する住民の認知度が低い （利用者にとっては自宅以外の「居場所」、地域活動の拠点になり うるということが知られていない） • 施設の使い方や地域活動の最新イベントを紹介するホームページを 作り、希望者にはメルマガを配信する • ホームページでは、自分にあった施設やイベントをキーワード検索 できる機能を搭載する 解決策エリアは、必ず左上の「取り組むべき課題」から記入し「解決策（実施内容）」の検討へと進むようにしてください。 解決策がすでに決定している場合でも、その解決策を記入した上で、課題と整合が取れているかを確認してください。 ポイント チェックすべきこと  利用者の困りごと・実現したいこと・価値などの背景にある 根本的要因を踏まえ課題が策定されている  解決することで、利用者に大きな価値が生まれる課題が策定 されている  合理的に解決できそうな課題が策定されている  解決策は運用しやすく、展開しやすいものである  取り組むべき課題：利用者の価値を実現するために、行 政が取り組むべき課題を書きます。  解決策（実施内容）：取り組むべき課題を解決するため の方法を書きます。「ウェブサイト」「アプリ」のよう な手段だけではなく、「それを使ってどのようなことが 可能になるのか」を考えてください。 2 . 5 . 1 解決策エリア 課題と解決策 行政が取り組むべき課題と解決策を考えましょう 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3 ポイント
50. 50 チェックすべきこと  中長期的に目指すこととして、サービス実現後のビジョン を書けているか確認する  活動評価指標は成果と因果関係が明確であり、 かつ実際に計測が可能な項目を設定する  目指す成果：サービスの実現によって価値が実現された、 望ましい社会や公共の状態を書きます。  中長期的に目指すこと：「目指す成果」を達成すること で、将来的に行政として社会にどのような良い効果を与 えられるか、長期的な目線で書きます。  活動評価指標：既存の事業目標やKPIをそのまま書くの ではなく、「目指す成果」やその過程の達成状況を適切 に評価するための定量的な指標を考えて書きます。 中長期的に目指すこと 目指す成果 活動評価指標 社会的な居場所づくり、市民同士の支え合い活動の推進 • 地域活動やイベントへの参加者が増える • シニア男性が地域活動に参加することで、独居老人や孤独感に 悩む高齢者が減少する • 施設利用者数と男性シニア層利用者の増加率 • ホームページで紹介される地域イベント数 ポイント ポイント 2 . 5 . 2 解決策エリア 目指す成果 解決策を実現することで社会がどう良くなるかを思い描きましょう 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3
51. 51 チェックすべきこと  施策を普及するための手段はユーザーや関連する ステークホルダーに対し、効果的かつ合理的か確認する  サービスの開発と運用に必要な活動とリソースは、期限や 技術的制約などの留意点を考慮できているか確認する  期待される成果に対し、実現に必要なリソース （予算や運用コスト）が大き過ぎないか確認する  施策を普及させるための手段：サービスを利用者に告知 するための手段や、必要な広報活動を書きます。  解決策を実現するための活動とリソース：サービスの開 発と運用に必要な活動とリソースを書きます。期限や技 術的制約など、事業計画上留意すべき条件があればそれ も書いてください。 ・予算 ・期間 ・想定利用者数 ・想定される利用者 一人あたりのコスト 解決策エリア 中長期的に 目指すこと 取り組むべき課題 解決策（実施内容） 施策を普及させるための手段 解決策を実現するための活動とリソース 目指す成果 活動評価指標 施設に対する住民の認知度が低い（利用者にとっては自 宅以外の「居場所」、地域活動の拠点になりうるという ことが知られていない） 社会的な居場所づくり、市民同士の支え合い 活動の推進 • 地域活動やイベントへの参加者が増える • シニア男性が地域活動に参加することで、独居老人 や孤独感に悩む高齢者が減少する • 施設利用者数と男性シニア層利用者の増加率 • ホームページで紹介される地域イベント数 ホームページの存在を伝えるチラシを市報に挟 んで配布する • 施設の使い方や地域活動の最新イベントを紹介するホームページを 作り、希望者にはメルマガを配信する • ホームページでは、自分にあった施設やイベントをキーワード検索 できる機能を搭載する • ホームページ開発でXXX万円。運用で月XX万円 • 令和X年X月公開 • 月間アクセス数 XX万人 • 利用者ひとりあたり XXX円 ホームページの開発会社へ依頼、開発後に運用を担当する職員1名が必要 ・予算 ・期間 ・想定利用者数 ・想定される利用者 一人あたりのコスト 2 . 5 . 3 解決策エリア 実現可能性を高める要素 解決策を実現するために必要なものを整理しましょう 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3
52. 52 企画プロセスの最後には、「提供者エリア」「利用者エ リア」「価値エリア」と「解決策エリア」の内容が論理 的に正しく接続されているかを見直し、解決策が価値を 創出できるものになっているか、確認します。 サービス企画のゴールは企画を考えることではなく、 ユーザーに価値を提供できる解決策を考えることです。 内容が正しく接続されていない場合は、利用者や提供者 の視点を踏まえ企画自体を見直す必要があります。  解決策は利用者が問題なく利用できる方法か確認する  サービス利用の際に困難が想定される場合、補助手段を検 討しているか確認する 「価値エリア」の内容との接続  解決策と目指す成果は、利用者や提供者に期待する価値を 提供できるものになっているか確認する 「利用者エリア」の内容との接続  提供者にとっても喜ばしいことが生じる解決策になってい るか確認する 「提供者エリア」の内容との接続 チェックすべきこと 2 . 5 . 4 サービス立案の仕上げのポイント サービス企画の全体像を見直しましょう 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 サービス 立案 課 題 の 整 理 2 . 1 東 京 都 サ ー ビ ス キ ャ ン バ ス 記 入 2 . 5 解 決 策 の 整 理 2 . 2 目 指 す 成 果 の 整 理 2 . 4 仮 説 の 検 証 2 . 3
53. 53 企画がまとまったら、サービスを実現する準備をし ます。要件定義を通して解決策となるサービス像や 必要な機能を整理した後、仕様書を作成し、共に サービスを作りあげる事業者を選定します。 仕様書は事業者に向けてサービスイメージが伝わる ことを意識し、後続の開発工程・リリース後の運用 像を見据えて作成します。 要件定義・調達 要件定義 • 仕様書の作成とレビュー • 事業者の選定実施 実現性も加味しながら、実現 したい要件を抽出して仕様書 に落とし込む 仕様書の内容がサービス企画 の目的から逸れていないか、 作成後に確認する • 解決策となるサービス像を具 体的に整理 • 実現すべき要件抽出 （必要な業務要件・ 機能要件・非機能要件） 東京都サービスキャンバスの 内容と整合するように、実現 したいサービス像の要件を具 体化する 仕様書作成 企画 – 要件定義・調達 3 要件定義・調達 3 要件定義書 仕様書 進め方 必ず守るポイント タスク 3.1 3.2 要件定義 仕様書作成 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 考 え る 3章 サ ー ビ ス を 実 現 す る 4章 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン
54. 54 サ ー ビ ス を 考 え る 3章 必ず守るポイント  東京都サービスキャンバスの内容と整合するように、 実現したいサービス像の要件を具体化する 重要な考え方  業務要件・機能要件・非効能要件の違いを理解した上で、 仕様書に盛り込むべき、主要な要件を明らかにする  既存システムやデータを有効活用できるか考慮する  利用者のアクションに対してどのような業務や処理が発生 するか、サービス全体像を可視化しながら検討する 実現したいサービス像に欠かせない業務要件を具体化し ます。機能ばかりに注目するのではなく、サービスの目 的やユーザーに提供したい価値に立ち返りながら、実現 したい要件を抽出しましょう。※1 要件定義の例 *出典5 業務要件 システム要件 機能 画面 帳票 データ 外部インター フェース 機能要件 非機能要件 業務実施手順 規模 時期・時間 場所等 管理すべき指標 情報システム化範囲 業務の継続の方針等 情報セキュリティ ユーザビリティ アクセシビリティ … 性能 教育 運用・保守 決めるべき要件の種類 要件定義で決めるべき範囲を確認した上で、実現する機能ば かりに目を向けるのではなく、利用者・提供者双方への価値 に繋がる要件は何かを検討しましょう。 ポイント 要件が対応可能な範囲を超えた場合、企画の目的や費用対効 果、機能の代替手段といった観点から、要件に優先順位を付 けます。 それぞれの項目は互いに関連しているため、 整合性を意識しながら検討しましょう ポイント ※1：要件定義から事業者が担当するケースもありますが、その場合もサービス目的や価値をふまえた要件となるよう協働しましょう。 要件定義 ・調達 要 件 定 義 3 . 1 仕 様 書 作 成 3. 2 3 . 1 要件定義 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成
55. 55 想定する利用者例 仕様書に盛り込むべきポイント例 仕様書の作成で気を付けるべきポイント 仕様書の確認では、東京都サービスキャンバスを用いて ユーザーがサービスを使用する場面をイメージしましょう。 必ず守るポイント 重要な考え方  事業者と調整する際は、プロトタイピングやユーザビリ ティテストなど、開発工程の重要成果物の作成やそれを見 据えたスケジュールについて予め協議しておく  事業者と職員が連携しやすい仕様内容を心がける 事業者の調達時に、正しくサービス像や要望を伝えられ るよう、要件定義結果をもとに仕様書に落とし込みます。  実現性も加味しながら、実現したい要件を抽出して仕様 書に落とし込む  仕様書内容がサービス企画の目的から逸れていないか、 作成後に確認する ポイント 事業者と連携するべきこと 業務委託の際には、より良いサービスを開発するための要件 を追加し、サービス開発期間を見積もりましょう。 • プロトタイピングによる基本設計確認 • ユーザビリティテストの実施 • リリース後の継続改善に向けたモニタリング機能実装 ポイント サービス開発が事業者任せとならないよう、チーム全体で開発 の全体像が理解できる作成物を準備しましょう。 • サービスブループリント • サービスの業務フロー など デジタル ネイティブ世代 サポートが 必要な人々 スマホをメインに様々なデバイスで 快適に利用しやすいサービス仕様 アクセシビリティ対応や多言語対応 など、利用者がサービスにアクセス しやすいサービス仕様 3 . 2 仕様書作成 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 要件定義 ・調達 要 件 定 義 3 . 1 仕 様 書 作 成 3. 2
56. 56 イメージしているサービスを適切に実現するため には、職員を含むサービス開発の関係者間で、 サービス全体像について共通認識を持つことが重 要です。この共通認識の形成は口頭で済ませるの ではなく、サービス全体像を可視化した作成物を 用いて理解を擦り合わせましょう。 例えばサービスブループリントでは、サービスの 全体的なフローと、利用者と提供者間のやり取り を視覚化することができます。これには、利用者 の接触点（タッチポイント）、利用者の行動、利 用者から見える提供者の活動、利用者から見えな い提供者の活動が含まれます。 時間の経過 利用者の 行動 利用者 の接触点 提供者の 内部で 発生する 活動 申請サイト を訪問 サポート のための プロセス・ システム 利 用 者 と の や り と り 利 用 者 か ら 見 え な い や り と り 内 部 と の や り と り 申請サイトで 必要な情報を 表示 ゴミ出し内容 に応じた情報 を表示 電子申請 システム 粗大ゴミを出す流れのサービスブループリントの例 必要な情報を フォームに 入力 申請フォーム 画面を表示 申請内容を 回収業者 と連携 回収業者と 連携するため のシステム 申請内容を 確認して 申請 審査結果及び 回収日連絡 メールを配信 回収日程の 確定メールを 受け取り、 処理券を購入 処理券を 貼り付け、 粗大ゴミを 出す コンビニで 処理券を 販売 粗大ゴミを 回収業者 が回収 コンビニと 処理券を管理 するための システム 粗大ゴミ 回収作業の 管理システム 処理券を回収 業者が受領 3 . 2 . 1 共通認識を持つためのポイント サービスブループリントで全体像を可視化し、共通イメージを持ちましょう 企画 仮説検討 サービス立案 要件定義・調達 要件定義 仕様書作成 サ ー ビ ス を 考 え る 3章 要件定義 ・調達 要 件 定 義 3 . 1 仕 様 書 作 成 3. 2
57. 57 このガイドラインの考え方と使い方 4 章 サービスを実現する サービスを開発するための大切な考え方
58. 58 ４章では、サービスを実現する時のプロセスや 注意事項を説明します。 ここから先のサービス開発工程は事業者が担当 するケースが多いですが、３章で検討していた サービス企画をイメージ通りに実現するために は、事業者との協働が重要です。 コミュニケーションする上でも、どのような作 業工程があり職員は何を意識すべきか把握する ことは重要な要素の一つですので、ぜひ事業者 との調整前にもお読みください。 4章 の 内 容 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 実 現 す る 4章 サ ー ビ ス を 考 え る 3章 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン 58 設計 – 基本設計 / 詳細設計 1 p.60 開発 2 p.64 テスト・改善 3 p.66 リリース 4 p.67
59. 59 4章の全体像・使い方 サービスを実現する、設計、開発、テスト・改善、リリース 要件定義・調達完了後は、事業者と協働しながらサービス仕様の設計に着手し、開発を進めます。 これらの工程ではユーザーの価値を達成できるサービスになっているか、確認しながらマネジメントしていく必要があり、 事業者とのコミュニケーションや連携は密に行うようにしましょう。 基本設計 詳細設計 設計 開発 テスト・改善 リリース 企画時のサービス目的 が達成できるか、事業 者が作成した基本設計 をレビューする。 事業者が作成した詳細 設計が、基本設計に 沿っていることを確認 する。 事業者が設計内容 に沿ってサービス を開発する。 サービス品質・仕様が 仕様書通りであり、 ユーザーにとって使い 勝手が良いか確認する。 ユーザーに公開する。 リリース後もユーザー の声をサービスに継続 して反映する。 プロトタイプ 基本設計書 詳細設計書 ユーザビリティテスト 実施計画 テスト実施結果 サービス・プロダクト※1 1 2 3 4 ※1：「サービス・プロダクト」とは現在作成・開発しているサービスの総称を指します。 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 実 現 す る 4章 サ ー ビ ス を 考 え る 3章 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン
60. 60 事業者が作成した設計内容をレビュー します。設計は画面の要素や操作の流 れを考える基本設計と、細かい仕組み を決める詳細設計に大別されます。 特に基本設計については企画していた サービス像から離れていないか、事業 者と協働しながらプロトタイピングを 実施し、目指すべきサービスを実現で きるか検証しましょう。 設計 - 基本設計 / 詳細設計 設計の全体像 プロトタイピング 設計レビュー • プロトタイプの作成 • テスト計画書作成 • 確認ポイントの整理 • テスト環境やテスターの確保 • テスターによる評価・検証 • 検証結果の分析と設計検討 事業者と協働してプロトタイ ピングを実施し、その検証結 果を基本設計に反映する • 事業者による 基本設計書作成 • 設計レビューの実施 • レビュー結果を 設計へ反映 • 事業者による 詳細設計書作成 • 設計レビューの実施 • レビュー結果を 設計へ反映 企画時にイメージして いたサービス像をもと に、利用者視点で基本 設計をレビューする 詳細設計内容が基本 設計・仕様書から逸 脱していないか、 サービスの背景・意 図を踏まえ確認する 1 設計 1 基本設計 詳細設計 プロトタイプ 基本設計書 詳細設計書 進め方 必ず守るポイント 1.1 タスク 1.2 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 実 現 す る 4章 サ ー ビ ス を 考 え る 3章 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン
61. 61 プ ロ ト タ イ ピ ン グ 1 . 1 プロトタイピングでは開発工程前の作成物をユーザーに 試してもらい、企画していたサービス像から離れていな いか、ユーザーの課題が解決できそうか、を検証します。 検証で生じた様々なユーザーの声を取り入れることで、 ユーザーの要望や課題に沿った、使いやすいサービス開 発につなげることができます。 必ず守るポイント  事業者と協働してプロトタイピングを実施し、その 検証結果を基本設計に反映する 重要な考え方  検証では「企画通りのサービスになりそうか？」という観 点だけでなく、「画面構成が分かり易いか？」「利用上の ストレスが無いか？」と言った設計観点も確認する サ ー ビ ス を 実 現 す る 4章 プロトタイピングの流れ 「どんな検証をすべきか？」「検証のためにどんなプロトタ イプが必要か？」「検証結果をどう解釈すべきか？」をしっ かり考えられるようなスケジュールを組むようにしましょう。 • 検証・判断したい事項を整理し、画面や機能 を絞り込んで、事業者にプロトタイプの作成 を依頼する • 評価したい事項に基づいてテスターの選 定やテストシナリオを整理する プロト タイプ 作成 プ ロ ト タ イ ピ ン グ 実 施 計画 作成 評価 結果 分析 • テスターがプロトタイプを操作する • アンケート・インタビューを通してテス ターの評価を収集する • サービスの主要要件など、利用者の 期待値を満たしているか確認する ※詳細手順や注意事項は「プロトタイピングの進め方（ユーザーテスト 実施手順書 02）」を確認してください。 ポイント 基本設計/ 詳細設計 設 計 レ ビ ュ ー 1. 2 1 . 1 プロトタイピング 設計 基本設計 詳細設計 開発 テスト・改善 リリース
62. 62 プロトタイピングの結果も踏まえて、事業者が作成した 基本設計の内容が企画していたサービス像と合っている か確認します。事業者から画面イメージの意図やデータ ベースの設計・管理方法などについて、説明を受けた上 で確認することが重要です。 必ず守るポイント  企画時にイメージしていたサービス像をもとに、利用者 視点で基本設計内容をレビューする  詳細設計内容が基本設計・仕様書から逸脱していないか、 サービスの背景・意図を踏まえ確認する 重要な考え方  レビューは利用者目線だけでなく、リリース後の運用や更 新を見据えた提供者視点でも実施する （無理なく運用できそうか？将来的に他のサービスに展開できそう か？など） 要件定義、基本設計、詳細設計など、工程の呼称や範囲は プロジェクトや事業者によって異なります。 事業者へのコミュニケーション サービスの要件は基本的に要件定義書に記載されます。ただ し、サービスの詳細化に必要な発注の背景や要件の意図は、 要件定義書だけでは読み取れないため、設計工程で事業者と コミュニケーションしながら補足する必要があります。 ポイント 設計の検討のポイント 設計工程には大きく基本設計と詳細設計があり、検討するポ イントや成果物が異なります。 ポイント 工程 概要 成果物例 基本設計 システム全体の構成や、 外側から見える部分につ いて定める工程 • 画面イメージ • 機能一覧 • ER図※1 • 基本設計書※2 詳細設計 どのような仕組み・ ロジックで実装するか、 開発に向けて定める工程 • 詳細設計書※2 ※1：「ER図」はEntity Relationship Diagramの略称で、情報システムで扱う対象を実体とし、属性や実体間の関係性を図示した文書を指します。 ※2：基本設計書ではサービスの外部に関わる設計を、詳細設計書ではより詳細な各機能のプログラム構造、エラー処理などを文書化することがあります。 1 . 2 設計レビュー 設計 基本設計 詳細設計 開発 テスト・改善 リリース プ ロ ト タ イ ピ ン グ 1 . 1 サ ー ビ ス を 実 現 す る 4章 基本設計/ 詳細設計 設 計 レ ビ ュ ー 1. 2
63. 63 申請者 部門 A 部門 B 対 応 事 業 部 申請 内容 登録 出力 出力/ 発送 決裁 二次 審査 一次 審査 受領 結果 出力 内容 確認 結果 登録 申請者 部門 A 部門 B 対 応 事 業 部 申請 内容 登録 一次 審査 出力/ 発送 二次 審査 結果 確認 受領 結果 出力 内容 確認 結果 登録 決裁 システムにて 自動処理 処理結果の確認業務が 新たに発生 As-Is 業務フロー（現在の業務フロー） *出典5 To-Be 業務フロー（新たな業務フロー） *出典5 OK NG OK NG ※1：「As-Is業務フロー」は現在の業務フロー、「To-Be業務フロー」はあるべき業務フロー、つまり変更後の新たな業務フローを指します。 設計工程では、開発内容が企画から外れていないことを確 認するほか、サービス実現により生じる業務への影響も把 握する必要があります。しかし、事業者の作業すべてを職 員が理解・確認することは困難ですし、レビュー内容や業 務への影響を様々な関係者へ口頭や文面のみで正確に伝え ることも、容易ではありません。 そのため要件定義や設計では As-Is/To-Be 業務フロー※1 やサービスブループリントなど、共通のアウトプットを用 いて認識合わせすることが望ましいです。業務の変更点や サービス効果を可視化することで、事業者の成果物や仕組 みのブラックボックス化を避け、コミュニケーションもと りやすくなります。 1 . 2 . 1 設計レビューのポイント 共通のアウトプットを使い、開発内容のブラックボックス化を避けましょう 設計 基本設計 詳細設計 開発 テスト・改善 リリース プ ロ ト タ イ ピ ン グ 1 . 1 サ ー ビ ス を 実 現 す る 4章 基本設計/ 詳細設計 設 計 レ ビ ュ ー 1. 2
64. 64 開発工程は主に事業者が担いますが、開発完 了後にすぐにサービスがリリースされる訳で はありません。職員も協働して様々なテスト を実施し、サービスの機能や使い勝手に問題 がないことを確認する必要があります。 ここでは、事業者が開発工程においてどのよ うな作業を行っているか補足しつつ、職員に とって関連性の高いユーザビリティテストに ついて説明します。 開発 / テスト・改善 / リリース 開発〜リリースまでの全体像 • テスト実施準備 テスター確保、テスト環境（会 場、β版のシステムなど）確保 • 検証 テスト実施、結果分析 • 改善 課題を優先順位付けし、システ ム等改善  リリース前にユーザビリティ テストを実施し、ユーザーの 使い勝手を確認する  テストによって発覚した課題 の内、重要な機能に影響する ものはリリースまでに対応す る 2 / 3 / 4 ユーザビリティテスト※1 テスト・改善 開発 リリース  事業者と密に連携 し、想定の品質・ スケジュールで進 行しているか確認 する  進行上の課題には、 事業者やチームメ ンバーを巻き込み、 打開策を検討する 事業者と連携して 開発し、 β版を作成 事業者と連携して リリース対応  サービス利用状況 の解析結果やユー ザーの声をもとに、 課題を検知・改善 するサイクルを継 続する  継続的な改善や新 規検討では、東京 都サービスキャン バスを再活用する 2 3 4 ユーザビリティテスト実施計画 テスト実施結果 サービス・プロダクト ※1：ユーザビリティテストは、事業者が単体テストや結合テストなどを実施し、受入テスト前に作成されるβ版を元に実施されます。 進め方 必ず守るポイント タスク 1章 サ ー ビ ス を デ ザ イ ン す る と は サ ー ビ ス を 実 現 す る 4章 サ ー ビ ス を 考 え る 3章 2章 東 京 都 に お け る サ ー ビ ス デ ザ イ ン
65. 65 事業者が実施する開発内容は、事業の位置付けやサービ ス内容により異なります。アプリケーションやWebペー ジの開発のみ実施するケースもあれば、サーバーやデー タ基盤導入など環境構築から取り組むケースもあります。 実現したいサービス像から外れないようマネジメントす るためにも、WBS※1などで各作業の工程や期限を可視化 しながら定例会議でコミュニケーションをとり、サービ ス実現に必要な機能・スケジュールを認識しましょう。 開発工程での注意事項 必ず守るポイント  事業者と密に連携し、想定の品質・スケジュールで進行 しているか確認する  進行上の課題には、事業者や庁内メンバーを巻き込み、 打開策を検討する サ ー ビ ス を 実 現 す る 4章 ポイント 環境構築 クラウドサーバーなど、システムを構 築する環境を整備 データ基盤準備 データ格納先となる基盤を構築し、投 入データを加工し準備 ユーザーインター フェース開発 ユーザーが操作する画面やアプリケー ションを作成 アプリケーション・ システム開発 システムパッケージ導入やスクラッチ 開発などで処理機能を実装 「開発」で示される作業例 事業者の開発に関する業務 「開発」と一口にいっても様々な作業が発生します。事業者 の作業内容は具体的にどのようなものか、コミュニケーショ ンをとりながら把握するようにしましょう。 運用・保守のための検討について ポイント 開発管理と並行して、運用・保守の内容を事業担当者と共に 検討したり、サービス展開を見据えてマニュアルを作成する 必要があります。 ※1：「WBS」とはWork Breakdown Structureの略称で、プロジェクトの成果物あるいは仕事を分解して構造化したドキュメント、または手法を指します。 開発 2 設計 基本設計 詳細設計 開発 テスト・改善 リリース
66. 66 事業者が実施する「テスト」の流れ リリース前にはβ版を作成し、ユーザビリティテストを 実施します。ユーザビリティテストでは、ユーザーの求 める・目的に適うサービスになっているか、使い勝手を 含めて検証し、課題があれば改善します。 必ず守るポイント  リリース前にユーザビリティテストを実施し、 ユーザーの使い勝手を確認する  テストによって発覚した課題のうち、重要な機能に影響 するものはリリースまでに対応する 重要な考え方  テスト実施者は、サービスの想定ターゲット層に近い人物 を選び、複数名で実施する  挙がった課題を全て直そうとするのではなく、優先順位を 付けて対応する サ ー ビ ス を 実 現 す る 4章 ユーザビリティテストの流れ ユーザーが実際に開発したものに触れてから気付くことも 多くあります。軽微な修正は対応できるよう、テストから リリースまでは余裕を持つようにしましょう。 • テスト環境（会場やテスト用システムなど）を整備 • 想定ユーザーに近いテスターを複数確保 • テストしたい観点を洗い出し、テスト計画を作成 準備 • β版をテスターが操作 • 確認観点例 : 「設計時の目的としたユーザー体験が実 現できるか？」「プロトタイピング指摘箇所は改善さ れているか？」など 検証 事業者は機能品質を確かめるべく、サービス開発後に単体、結 合テストなどを実施しβ版を作成します。β版でユーザビリ ティテストを実施後、都が行う受入テストの支援を行います。 • 確認結果を踏まえて、改善点を洗い出す • サービスの重要機能やすぐに対応可能な軽微な課題は、 リリースまでに改修 改善 ※詳細手順や注意事項は「ユーザビリティテストの進め方（ユーザーテスト実施手 順書 03）」を確認してください。 ポイント ポイント 設計 基本設計 詳細設計 開発 テスト・改善 リリース ユーザビリティテスト テスト・改善 3
67. 67 サービスデザインにはセオリーはあっても正解はありま せん。リリース後も、現在のサービスがユーザーが求め る価値を提供できているか検証を続け、改善し、サービ スの価値を高めていく必要があります。 サービス利用状況のデータは積極的に取得し、この改善 サイクルを繰り返し回していきましょう。 リリース後の改善 必ず守るポイント  サービス利用状況の解析結果※1やユーザーの声をもとに、 課題を検知・改善するサイクルを継続する  継続的な改善や新規検討では、東京都サービスキャンバ スを再活用する ご意見フォームの例 サ ー ビ ス を 実 現 す る 4章 モニタリングする指標の例 アクセス 分析結果 課題 Ver1.0 Ver1.1 • 離脱率が高い ページは？ • 滞在時間が短い ページは？ • あまり押されて いないボタンは？ リリース後にモニタリングすること（ウェブサイトの例） 必須事項を入力し、「確認」ボタンをクリックしてください。 サイト機能のわかりやすさ 分かりにくい 普通 分かりやすい サイト自体の見やすさ サイトに関するご意見 ご意見を入力ください 分かりにくい 普通 分かりやすい サービスのご意見フォームやアクセス状況を確認し、ユー ザーの意見・行動情報を収集します。特にアクセス分析にお いては、当初設定していた指標からモニタリングしましょう。 リリース後の東京都サービスキャンバスの活用 ポイント ポイント 東京都サービスキャンバスを使いながら、サービスが想定通 り利用されているか確認します。課題があればキャンバスを アップデートしながら、より良いサービス像を探りましょう。 ※1：リリースしたサービスの、各ページのアクセス数・時間やボタン押下数などを想定しています。 リリース 4 設計 基本設計 詳細設計 開発 テスト・改善 リリース
68. 68 関連ドキュメント サービスデザインガイドライン 付録 ガイドライン本文中で紹介した東京都サービスキャンバス、ペルソナシート及びカスタマージャーニーマップといった成果物の様式 を事例と合わせて掲載しています。 付録 東京都サービスキャンバスほか成果物ver.2.0.0 問い合わせ先 東京都デジタルサービス局デジタル戦略部デジタル戦略課技術管理担当 S1100201@section.metro.tokyo.jp 参考リンク • ペルソナ Aurora Harley.“Personas Make Users Memorable for Product Team Members”.2015-02-16. https://www.nngroup.com/articles/persona/,（参照2024-02-27） • ワイヤーフレーム Kelley Gordon.“How to Draw a Wireframe (Even if You Can’t Draw)”.2021-06-20. https://www.nngroup.com/articles/draw-wireframe-even-if-you-cant-draw/,（参照20 24-02-27） • カスタマージャーニーマップ Sarah Gibbons.“Journey Mapping 101”.2018-12-09. https://www.nngroup.com/articles/journey-mapping-101/,（参照2024-02-27） • 共感マップ Dave Gray.“Updated Empathy Map Canvas”.2017-07-16. https://medium.com/the-xplane-collection/updated-empathy-map-canvas-46df22df3c8a,（参照2024-02-27） • サービスブループリント Sarah Gibbons.“Service Blueprints: Definition”.2017-08-27. https://www.nngroup.com/articles/service-blueprints-definition/,（参照2024-02-27）
69. 69 • アレックス・オスターワルダー,イヴ・ピニュール著,小山龍介訳（2012）『ビジネスモデル・ジェネレーション ビジネスモデル設計書』翔泳社 • 馬田隆明（2022）『解像度を上げる』英治出版 • 小山田那由他（2021）『未来ビジネス図解 これからのデザイン思考』エムディエヌコーポレーション • キャット・ホームズ著,大野千鶴訳（2019）『ミスマッチ 見えないユーザーを排除しない「インクルーシブ」なデザインへ』ビー・エヌ・エヌ • ジェームス W.ヤング著,今井茂雄訳（1988）『アイデアのつくり方』 CCCメディアハウス • 白川克・濵本佳史（2021）『システムを作らせる技術』日本経済新聞出版 • 樽本徹也（2014）『ユーザビリティエンジニアリング（第2版）―ユーザエクスペリエンスのための調査、設計、評価手法―』オーム社 • 日本規格協会（2019）『人間工学ーインタラクティブシステムの人間中心設計（JISZ8530:2019）』 • 長谷川敦士（2009）『IA100 ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計 』ビー・エヌ・エヌ • 濱口秀司.“日本人の性質を活かした究極のブレストとは？”.WORKSIGHT.2012-09-18. https://www.worksight.jp/issues/59.html,（参照2023-03-09） • マーク・スティックドーン,アダム・ローレンス,マーカス・ホーメス,ヤコブ・シュナイダー編著,安藤貴子・白川部君江訳,長谷川敦士監修（2020） 『This is Service Design Doi ng サービスデザインの実践』ビー・エヌ・エヌ • 宮里隆司（2021）『改革・改善のための戦略デザイン 自治体DX』秀和システム • ルー・ダウン著,ヤナガワ智予訳（2020）『Good Service DX時代における“本当に使いやすい”サービス作りの原則15 』ビー・エヌ・エヌ • 『UX白書 ver.3』 hcdvalue. 2017-05-09. https://site.hcdvalue.org/docs,（参照2023-03-09） • デジタル庁『デジタル社会推進標準ガイドライン』,2023-03-31, https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c3 1-0f06fca67afc/8a3b6203/20230331_resources_standard_guidelines_guideline_01.pdf（参照2024-02-14） 参考文献 引用文献 1. マーク・スティックドーン,アダム・ローレンス,マーカス・ホーメス,ヤコブ・シュナイダー編著,安藤貴子・白川部君江訳,長谷川敦士監修（2020） 『This is Service Desi gn Doing サービスデザインの実践』ビー・エヌ・エヌ、p.245の図をもとに作図、一部追記 2. 長谷川敦士著（2009）『IA100 ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計』ビー・エヌ・エヌ、「21 さまざまなユーザー調査」の図をもとに 図および内容に追記 3. 『UX白書ver.3』.hcdvalue. 2017-05-09. https://site.hcdvalue.org/docs,（参照2023-03-09）をもとに作図、一部改変 4. Dave Gray.“Updated Empathy Map Canvas”.2017-07-16. https://medium.com/the-xplane-collection/updated-empathy-map-canvas-46df22df3c8a,（参照2023-03-2 8） 5. デジタル庁『デジタル・ガバメント推進「標準ガイドライン」研修資料』,2023-03-31, https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143 -ed29-4f1d-9c31-0f06fca67afc/67d846da/20220509_resources_standard_guidelines_guideline_07.pdf（参照2024-02-14）を元に作図、一部改変 出典 出典 出典 出典 出典
70. 70 倉谷 道夫 Michio Kuratani サービスデザインガイドラインをお読みいただきありがとうございました。 サービスデザインの考え方・手法が皆さまの業務で実践され、より良いサービス作りに繋がっていくことを願っています。なお、本ガイド ラインは都の職員向けに作成されましたが、他の自治体の皆さまにも幅広くご活用頂ければ幸いです。 本ガイドラインはデジタルサービス局デジタル戦略部デジタル戦略課技術管理担当を中心に、東京都デジタルサービス会議内にあるUI/UX ワーキングのメンバーの協力を得て、作成・更新されています。ワーキングメンバーからコメントを頂きましたので、ぜひご覧ください！ プロフィール デザイナー。2018-2023年ラクスル株式会社で物流、 コーポレートIT向けサービスなどのデザイン業務に 従事 コメント 利用者と提供者の両方にとって最適なサービスをデ ザインする方法を探し、過程から得られた洞察をも とにサービスを改善する、より実践的かつ簡潔で効 果的な方法について考えることができたのは、非常 に貴重な経験でした。 北田 荘平 Sohei Kitada 西村 洋 Hiroshi Nishimura プロフィール Goodpatch シニアUXデザイナー 大手電機メーカーでのUXリサーチやコンセプト策定、 コンサルファームでの事業創出支援経験を活かし、 経営戦略を基にした体験設計やサービスデザインへ の落とし込みを得意とする。 コメント 本ガイドラインは、あらゆる現場の実践を想定し、 デザイナー以外の方の意見や疑問を吸い上げ作成さ れており、組織全体のサービスデザイン力の底上げ に寄与できると考えます。 お薦めの書籍やウェブサイト デザインの中心であるヒトの理解が深まる書籍 存在と時間（マルティンハイデッガー） ヒトに深く影響を及ぼす社会の理解が深まるラジオ コテンラジオ プロフィール Co-Founder / UI Designer / Front-end Developer Webサイト、スマートフォンアプリの設計・デザ イン、フロントエンドの開発を軸にデジタルの分 野で活動中。2008年-2011年 thaに在籍。2011年 T-D inc.設立。2014年からニューヨークに居住。2 016年に帰国。多摩美術大学統合デザイン学科非常 勤講師。 コメント 誰かが作ったものを見る時、触る時に、どうして こうなったんだろう。どんなところが参考になる だろう。という視点で毎日過ごしてみましょう！ お薦めの書籍やウェブサイト 伝わる［図・グラフ・表］のデザインテクニック （ エムディエヌコーポレーション） UI/UXワーキンググループメンバーより サービスデザインガイドライン作成担当より