SlideShare una empresa de Scribd logo
1 de 11
本物のサービスを目指して
平本健二
内閣官房 政府CIO上席補佐官
経済産業省 CIO補佐官
0
サービス・デザインの現場
 推進側は、サイロにサービス・デザイン・フレーバーのような、疑似
サービスデザインや即席専門家が続出。
 対象サービスの現場は、ネガティブ・ワードのオンパレード。
1
そんなのできな
い
今までも問題な
かった
制度があるから
できない
みんなに迷惑が
かかる
忙しい
苦情が来る
予算がない
変えて問題が起
きたらどうするか
そんなニーズ聞
いたことがない
理解できない
サステイナブルな仕組みつくり
2
ガイド
サービスデザイ
ン導入ガイドブック
GovTech読本
研修
サービス・デザイ
ン 研修
DX研修
実践
制度DB
法人インフォメー
ション
評価
ワークショップ
プロジェクトの
評価
 サービスデザインが目的ではなく、価値あるサービスを提供し続けること
が重要であり、評価とフィードバックを含んだ仕組みで推進している。
体制整備
IT室 サービスデザインチーム
経済産業省 DXオフィス
技術基盤
IMI(インタオペラビリティ)
原理原則による評価(サービス設計12箇条)
 組織横断サービスの成功、失敗事例に対して、サービス設計12箇条で評
価を行うことで、実施にあたってのキーポイントが明確になる。
3
制度DB 法人インフォ システムA システムB
第1条 利用者のニーズから出発する ○ニーズ分析 ×法人番号 ×構築が目的 ×指示で改修
第2条 事実を詳細に把握する ○ ○ ×調査不足 ○
第3条 エンド・ツー・エンドで考える ○流れの検証 ○ケース検討 ×構築が目的 ×民間無視
第4条 全ての関係者に気を配る ○ヒアリング ○ヒアリング ×構築が目的 ×接続先無視
第5条 サービスはシンプルにする ○API重視 ○API重視 ○ ○
第6条 デジタル技術を徹底的に活用する ○ ○ × ×
第7条 利用者の日常体験に溶け込む ○ ○ ×構築が目的 ×接続先無視
第8条 自分で作りすぎない ○API重視 ○API重視 ○ ○
第9条 オープンにサービスを作る ○WS ○WS ×情報未提供 ×情報未提供
第10条 何度も繰り返す ○順次開発 ○アジャイル ×改修なし ×変更不可
第11条 一遍にやらず、一貫してやる ×引継ぎ ○ ×引継ぎ ○
第12条 システムではなくサービスを作る ○サービス ○サービス ×構築が目的 ×指示で改修
ニーズに基づき、エンド・ツー・エンドで考え、オープンに、見直しをかけながら、一貫したビジョンで推進する。
サービス提供(運用)
時間軸による評価(The Double Diamond)
 「初期の人材、訓練」、「安定した運用先」、「中だるみ防止」が重要 4
長い調達
期間
運用先の
確約要求
英国 「Design Council, The Design Process: What is
the Double Diamond?」
https://www.designcouncil.org.uk/news-opinion/design-
process-what-double-diamond)
を基に作成
できる範囲を重視し組織の壁を容認
(ビジョンを示さず)
調達で失敗
合意形成に時
間がかかる
コアから順
次リリース
WSやアンケート
に基づき改修
少人数の精鋭
チームで作成
運用先
が拒否
PlanBに
よる回避
少人数の精鋭
チームで作成
ヒアリングに
よる精査
拡張性・柔軟性
を重視した設計
プロトタイプに
よる検証
要望に応じて順
次改修
最終運用先が
未定
サービスに知見のない
メンバーが作成
質ではなく量
による評価
不十分な合意での
運用先への移行
情報を開示せず
クローズに開発
提供時に問題が
発覚
制度
DB
法人
インフォ
システム
A
システム
B
調整 調達
サービス・デザイン成功へのクリティカルポイント
良いチーム、人材を配置する(リスクを恐れないチーム)
• サービス・デザインを理解し、オープンマインドな人が必要。交渉(説得)の得意な人も必要。
• 実施する権限も付与
ニーズに基づきエンド・ツー・エンドで考える
• 行政だけではなく民間も含め、利用者が「思い立った」ところから、「完全に完了」するまでを対象に
考える。
運用先に対する作戦を考える
• ビジョンを共有する(ビジョンを理解できない人に運用を渡してはならない)。
• 初期段階で最終運用先が決定しない場合もあるが、やむを得ない。(目途があれば、前に進める)
• 運用先が初期段階で確定していないときには、早めに運用先候補との調整を行うとともに、並行し
て、プランB、ダメな時の撤退戦略を考えておく。
オープンにアジャイルに推進する
• 徐々に明確になるニーズ、ステークフォルダー、用途に対応する。
一貫したビジョン
• 誰もが忘れないところに、コンセプトブックやビジョンを貼っておく。
5
中だるみの防止
 長い調整期間
1. 厳しいところに最初に行き、相場観を把握する。
2. 十分に時間をかけて話を聞く。
• 1時間も聞けば、3回くらい同じ文句(できない理由)を言う。
3. サービスの必要性を認めてもらう。
• 一個人の視点で考えてもらう。
4. できない、やらない理由を一つずつ消していく。
5. 上記で納得しない場合、周りから口説き、外堀を埋める。
6. 未来のシミュレーションを一緒にしてあげる。
• 「あなたのために考えている」という共感が重要。
 長い調達期間
 とにかく早く進める
• 調整と並行して準備する
 実力のある開発者を選定する
• 提案は、企業より個人の実績を評価する
6
みんなの熱が冷めないうちに推進していくことが必要
サービス・デザイン成功へのクリティカルポイント
良いチーム、人材を配置する(リスクを恐れないチーム)
• サービス・デザインを理解し、オープンマインドな人が必要。交渉(説得)の得意な人も必要。
• 実施する権限も付与
ニーズに基づきエンド・ツー・エンドで考える
• 行政だけではなく民間も含め、利用者が「思い立った」ところから、「完全に完了」するまでを対象に
考える。
運用先に対する作戦を考える
• ビジョンを共有する(ビジョンを理解できない人に運用を渡してはならない)。
• 初期段階で最終運用先が決定しない場合もあるが、やむを得ない。(目途があれば、前に進める)
• 運用先が初期段階で確定していないときには、早めに運用先候補との調整を行うとともに、並行し
て、プランB、ダメな時の撤退戦略を考えておく。
オープンにアジャイルに推進する
• 徐々に明確になるニーズ、ステークフォルダー、用途に対応する。
一貫したビジョン
• 誰もが忘れないところに、コンセプトブックやビジョンを貼っておく。
7
データのインタオペラビリティの確保
実践の中で切実に言われる
成功のためのクリティカルポイント
インタオペラビリティがなければ実現できない
 サービスデザインは制度の見直しと言われるが、ボトムラインであるテク
ノロジーが整備されていなければ実現できない。
8
サービス
日本独自のデジタル化の壁
60000文字の漢字
ハンコ
複雑な表現
+
サービス・デザイン・スコアカードの必要性
 サービス・デザインの評価に向けた可視化が必要
 サービス間比較
 経年的改善
9
サービス設計原則 2011 2013 2018
第1条 利用者のニーズから出発する 5 4 4
第2条 事実を詳細に把握する 5 5 5
第3条 エンド・ツー・エンドで考える 5 5 5
第4条 全ての関係者に気を配る 5 5 5
第5条 サービスはシンプルにする 5 5 5
第6条 デジタル技術を徹底的に活用する 5 5 5
第7条 利用者の日常体験に溶け込む 5 3 1
第8条 自分で作りすぎない 5 5 5
第9条 オープンにサービスを作る 5 5 4
第10条 何度も繰り返す 5 3 1
第11条 一遍にやらず、一貫してやる 4 5 1
第12条 システムではなくサービスを作る 5 5 1
フェーズ 2011 2013 2018
発見 5
定義 5
開発 5
提供 5
運用 5 3 1
基盤 2011 2013 2018
体制・人材 5 3 1
インタオペラビリティ 3 4 5
ユーザー評価 2011 2013 2018
価値 5 3 1
満足度(総合) 5 4 4
満足度(品質) 5 4 3
満足度(時間) 5 4 3
経年評価のイメージ
Evaluating services: An exploratory approach beyond Service Design
https://www.ifm.eng.cam.ac.uk/.../EvaluatingServices_Foglieni.pdf
関係者による評価のイメージ
原則
フェーズ
基盤
UX
10
Impossible is just a big word thrown around by small men who
find it easier to live in the world they‘ve been given than to
explore the power they have to change it.
Impossible is not a fact. It’s an opinion.
Impossible is not a declaration. It‘s a dare.
Impossible is potential. Impossible is temporary. Impossible is
nothing.
- Muhammad Ali –
不可能は、変らなければならないことを探求するのではなく、与え
られた世界で安穏と暮らしている小さな奴らが投げかける言葉だ。
不可能は事実ではない。それは意見である。
不可能は公式に定められたものではない。それは挑戦である。
不可能は可能性である。不可能は一時的なものである。不可能なも
のなんてない。
- モハメド・アリ -

Más contenido relacionado

Similar a 190228 service design in japan

U iscope 事業会社様向け_概要資料
U iscope 事業会社様向け_概要資料U iscope 事業会社様向け_概要資料
U iscope 事業会社様向け_概要資料
Daisuke Hiraishi
 
最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)
IMJ Corporation
 

Similar a 190228 service design in japan (20)

U iscope 事業会社様向け_概要資料
U iscope 事業会社様向け_概要資料U iscope 事業会社様向け_概要資料
U iscope 事業会社様向け_概要資料
 
To be sn agile enterprise
To be sn agile enterpriseTo be sn agile enterprise
To be sn agile enterprise
 
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory PatternCi&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory Pattern
 
IT革命からコミュニティ、コミュニケーション革命に!
IT革命からコミュニティ、コミュニケーション革命に!IT革命からコミュニティ、コミュニケーション革命に!
IT革命からコミュニティ、コミュニケーション革命に!
 
Developer Summit Summer 2013 C1セッション CA Technologies
Developer Summit Summer 2013 C1セッション CA TechnologiesDeveloper Summit Summer 2013 C1セッション CA Technologies
Developer Summit Summer 2013 C1セッション CA Technologies
 
2016 #meijisap - 明治大学理工学部情報科学科 情報システム論1講義「デジタルによるビジネスモデルの変革」
2016 #meijisap - 明治大学理工学部情報科学科 情報システム論1講義「デジタルによるビジネスモデルの変革」2016 #meijisap - 明治大学理工学部情報科学科 情報システム論1講義「デジタルによるビジネスモデルの変革」
2016 #meijisap - 明治大学理工学部情報科学科 情報システム論1講義「デジタルによるビジネスモデルの変革」
 
DevOps時代の開発環境と現場体験 [#cmdevio2015]
DevOps時代の開発環境と現場体験 [#cmdevio2015]DevOps時代の開発環境と現場体験 [#cmdevio2015]
DevOps時代の開発環境と現場体験 [#cmdevio2015]
 
超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0
 
ITプレナーズ社オンラインセミナー講演資料_Why ITSM?_20210421
ITプレナーズ社オンラインセミナー講演資料_Why ITSM?_20210421ITプレナーズ社オンラインセミナー講演資料_Why ITSM?_20210421
ITプレナーズ社オンラインセミナー講演資料_Why ITSM?_20210421
 
最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)
 
大規模システムリプレイスへの道
大規模システムリプレイスへの道大規模システムリプレイスへの道
大規模システムリプレイスへの道
 
システムコンサルタント
システムコンサルタントシステムコンサルタント
システムコンサルタント
 
connpass特徴と開発の流れ
connpass特徴と開発の流れconnpass特徴と開発の流れ
connpass特徴と開発の流れ
 
DeNAでのサービスの作り方
DeNAでのサービスの作り方DeNAでのサービスの作り方
DeNAでのサービスの作り方
 
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織
 
Base 20141011 1_for_slideshre
Base 20141011 1_for_slideshreBase 20141011 1_for_slideshre
Base 20141011 1_for_slideshre
 
サービスデザインの全体像
サービスデザインの全体像サービスデザインの全体像
サービスデザインの全体像
 
[G-Tech2015]攻めのITに必要なITサービスマネジメント人材と組織 - 株式会社ITプレナーズジャパン・アジアパシフィック[講演資料]
[G-Tech2015]攻めのITに必要なITサービスマネジメント人材と組織 - 株式会社ITプレナーズジャパン・アジアパシフィック[講演資料][G-Tech2015]攻めのITに必要なITサービスマネジメント人材と組織 - 株式会社ITプレナーズジャパン・アジアパシフィック[講演資料]
[G-Tech2015]攻めのITに必要なITサービスマネジメント人材と組織 - 株式会社ITプレナーズジャパン・アジアパシフィック[講演資料]
 
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
 
ヒーロー島 Visual Studio 2012
ヒーロー島 Visual Studio 2012ヒーロー島 Visual Studio 2012
ヒーロー島 Visual Studio 2012
 

Más de Kenji Hiramoto

Más de Kenji Hiramoto (20)

Notice
NoticeNotice
Notice
 
220331GIF説明資料詳細.pptx
220331GIF説明資料詳細.pptx220331GIF説明資料詳細.pptx
220331GIF説明資料詳細.pptx
 
220401IMI2.pptx
220401IMI2.pptx220401IMI2.pptx
220401IMI2.pptx
 
220209 nds
220209 nds220209 nds
220209 nds
 
220111 global e participation workshop
220111 global e participation workshop220111 global e participation workshop
220111 global e participation workshop
 
210629data strategy servicecatalogue
210629data strategy servicecatalogue210629data strategy servicecatalogue
210629data strategy servicecatalogue
 
210618 c4jdatastrategy
210618 c4jdatastrategy210618 c4jdatastrategy
210618 c4jdatastrategy
 
210519smartcity101
210519smartcity101210519smartcity101
210519smartcity101
 
210512opengovernment101
210512opengovernment101210512opengovernment101
210512opengovernment101
 
210508 legaltech
210508 legaltech210508 legaltech
210508 legaltech
 
210413 data101day23
210413 data101day23210413 data101day23
210413 data101day23
 
210413 data101day1
210413 data101day1210413 data101day1
210413 data101day1
 
2020-12-21 data strategy in Japan
2020-12-21 data strategy in Japan2020-12-21 data strategy in Japan
2020-12-21 data strategy in Japan
 
(old version)2020-12-21 data strategy in Japan
 (old version)2020-12-21 data strategy in Japan (old version)2020-12-21 data strategy in Japan
(old version)2020-12-21 data strategy in Japan
 
191018 data interoperability
191018 data interoperability191018 data interoperability
191018 data interoperability
 
Measures for covid19
Measures for covid19 Measures for covid19
Measures for covid19
 
Law modeling report
Law modeling reportLaw modeling report
Law modeling report
 
191226 baseregistries summary
191226 baseregistries summary191226 baseregistries summary
191226 baseregistries summary
 
191228Base registries
191228Base registries191228Base registries
191228Base registries
 
191228smartcity
191228smartcity191228smartcity
191228smartcity
 

190228 service design in japan