方法論記事

低リスクの公共サービス適用および相談プロセスにおける複雑な問題のための、システム的サービスデザイン視覚化プロトコル

21 回視聴

⸱

2026年9月11日

 ,  , 
1Faculty of Innovation and Design, City University of Macau, 2College of Art and Design, Shenzhen University, 3College of Art and Design, Guangdong Baiyun University

この記事について

サマリー

本プロトコルでは、低リスクの公共サービス申請および相談プロセスにおける複雑な問題を診断するための、構造化されたサービスデザイン手法について解説します。このアプローチでは、ステークホルダーマッピング、ジャーニーマッピング、共創設計（コ・デザイン）、および低忠実度のプロトタイピングを統合し、実装前にユーザーの行動、意思決定、およびサービス資材のユーザビリティについて、タスクベースのシミュレーション評価を行います。

要約

複数のアクター、断片的な情報、不明確な責任境界、そして唯一の議論の余地のない解決策が存在しないことなど、「厄介な（wicked）」特徴を持つ複雑な公共サービス上の問題は、日常的な行政設定において構造化することが困難です。本論文では、低リスクの公共サービスアプリケーションおよびコンサルテーションプロセス（医療処置、法的地位、財政的適格性、児童保護、懲戒結果、またはその他の権利に影響を及ぼす重大な決定を下さない行政サービスと定義される）に向けた、系統的なサービスデザイン可視化プロトコルを提示します。このプロトコルは、ステークホルダーマッピング、公共サービスジャーニーマッピング、ダブルダイヤモンド共創デザイン、および低忠実度プロトタイプテストを統合することで、断片的な行政上の課題を実行可能な共創サービスコンセプトへと変換し、シミュレーションタスクを用いて評価します。代表的な低リスク行政アプリケーションパスウェイにおいて、28名の参加者を対象としたシミュレーションタスクテスト（112件のベースラインおよび112件のプロトタイプ後タスク記録）を実施した結果、プロトコルによって生成された資料に接した後、タスク完了時間の短縮（178.4 ± 49.6 sから121.7 ± 38.2 sへ）、エラー数の減少（1タスクあたり1.86 ± 0.91から0.79 ± 0.63へ）、およびタスク成功率の上昇（62.5%から82.1%へ）が示されました。固定された事前・事後シーケンスには学習効果が含まれている可能性があるため、これらの知見はタスクベースのユーザビリティのエビデンスとして提示されます。この再現可能なプロトコルは、低リスクの公共サービス環境において、複雑な公共サービス上の問題を診断し、解決策をプロトタイプ化するための、構造化された視覚主導のアプローチを提供します。

概要

公共サービス機関は、単純な行政上の調整では解決できない複雑な課題にますます直面しています。これらの課題は、複数のアクターの関与、断片化された責任、不均衡な情報アクセス、そして標準化された行政手続きと多様な利用者のニーズとの間の緊張関係を特徴としています。本プロトコルでは、こうした問題が完全に再現可能な数式で解決できると主張するのではなく、再現可能なファシリテーション手順を通じて構造化、可視化、および探索が可能な、「厄介な問題（wicked problems）」のような特性を持つ、範囲が限定された低リスクのサービス問題として扱います1,2。日常的な公共サービスの提供において、これらの問題は運用上の破綻として現れます。例えば、市民が必要な書類を特定するのに苦労したり、現場スタッフが反復的な問い合わせに直面したり、管理者がエンドユーザーにとって分かりにくいルールを強要したりするといった状況です。

これらの複雑さに対処するため、公共サービスのイノベーションは、内部的な効率化改革から、参加型のユーザー中心のアプローチへと移行しています。現在の研究では、共創（co-creation）と共産（co-production）により、市民、専門家、および組織がサービスイノベーションに協働的に貢献できることが示されています3,4,5。しかし、この参加型への移行は方法論的な課題をもたらします。多様なステークホルダーが、あるサービスが非効率であることには同意しても、構造的な破綻がどこで起きているのか、誰が最も影響を受けているのか、あるいはどのような具体的な介入が必要なのかについて合意に至ることは稀であるためです。

本プロトコルは、サービスデザイン研究者、行政学研究者、自治体や大学のサービス改善チーム、および実装前に複数の関係者による苦情を視覚的な診断資料に変換するための再現可能なアプローチを必要とする訓練を受けたファシリテーターを対象としています。本手法は、ユーザーが要件を解釈し、書類を準備し、複数のサービス段階を経て、複数の関係者と調整を行う必要がある、相談、登録、ステータス確認、フォローアップサービスなどの低リスクなアプリケーションに最適です。緊急時の意思決定、確立されたワンステップの手順を持つ高度に標準化された取引、法的裁定、医療行為、児童保護、移民ステータスの決定、財政援助の決定、懲戒手続き、または個人を特定できるケースファイルへのアクセスが必要なあらゆる環境において、主要な手法として使用してはいけません。

単独のステークホルダー分析、ジャーニーマッピング、または参加型ワークショップと比較して、提案されたワークフローは、アクターマッピング、ステージごとのサービス分解、共同設計による課題策定、およびシミュレーションによるプロトタイプテストを、監査可能な単一のシーケンス内で連携させています。この統合により、誰が影響を受けているか、どこで不具合が発生しているか、およびどの素材を安全にテストできるかを特定せずに、広範な不満から直接解決策のアイデアへ移行することを防ぐことができます。同様に、近年の公共部門および公衆衛生における共同設計のレビューにおいても、透明性のあるプロセス、明示的なファシリテーション、ならびに参加状況とパワーダイナミクスの慎重な評価の必要性が強調されています4,6,7,8,9。

サービスデザインは、視覚的かつ参加型で、プロトタイプを重視した手法を通じて、この課題に対処するための実践的なフレームワークを提供します6,8,10。サービスデザインでは、サービスの失敗を抽象的な政策上の不備として扱うのではなく、ユーザー、スタッフ、タッチポイント、およびバックステージのプロセスの間の相互作用を検証します。その結果、公共行政において、複雑な問題を定義するために市民を巻き込む手段として、共創デザイン（co-design）が提案される機会が増えています4,7,11。しかし、ステークホルダーの主観的な経験を検証可能な公共サービス資料へと変換するための構造的なメカニズムが欠如している場合や、参加者間の権力格差を明示的に管理できていない場合、共創デザインの取り組みは不十分な結果に終わることが少なくありません。

厳格な手法的な移行には、特定の分析ツールの逐次的な統合が必要です。ステークホルダーマッピングは、アクターの関与、影響力、依存関係、および情報の非対称性を明確にすることで、診断上のベースラインとして機能します12。次に、ジャーニーマッピングを用いて、一連のサービスの各段階における具体的なペインポイントや責任の曖昧さを特定します13。その後、ダブルダイヤモンド フレームワークによって、これらのマッピングで特定された破綻箇所を、実行可能なデザイン上の課題へと変換するための構造化された経路が提供され、発散的な問題探索と収束的な解決策の開発を分離します7,8,14。最後に、低忠実度プロトタイプのテストにより、共同設計されたコンセプトを実装前に安全に評価することが可能になります。これは、時期尚早な変更が市民のアクセスを妨げたり、行政の業務負荷を増大させたりする可能性がある公共サービスにおいて不可欠なステップです15,16。

これらのツールに関する手法上のガイダンスが増えているにもかかわらず、公共サービスの共創（co-design）に関する文献において、再現性は依然として重大な制限となっている6,7,8,17。多くの研究では、デザインワークショップが概括的に記述されており、独立した再現に必要な詳細な分析ステップが不明確である。厳格な手法には、固定されたステージ、定義された時間配分、標準化されたスコアリングルール、一貫した視覚的アウトプット、および透明性のある決定基準を確立させるべきである。さらに、初期段階のタスクベースのユーザビリティ評価と、実際の運用におけるエージェンシーのパフォーマンスに関するより広範な主張とを、明確に区別する必要がある。

本論文では、低リスクの公共サービスイノベーションにおける複雑なマルチアクターの問題を構造化するために開発された、体系的なサービスデザイン視覚化プロトコルを提示します4,6,16,17。公共サービスの適用およびコンサルテーションプロセスに特化して設計されたこのプロトコルは、ステークホルダーマッピング、ジャーニーマッピング、ダブルダイヤモンドワークショップ、そしてプロトタイプテストを順次統合したものです。全体の目的は、断片的なサービスの不満点から、視覚的な診断、客観的な問題定義、そして共創（co-design）されたサービスコンセプトの実証的テストへと移行するための、再現性の高いステップバイステップのアプローチを研究者や実務家に提供することにあります。

プロトコル

本論文で報告されている代表的な適用例は、マカオ都市大学（中国マカオ）の人間研究保護倫理委員会によって承認されました（承認番号：260AL2401、有効期間：2026年1月10日から2028年1月10日まで）。すべての参加者から、参加前に書面または電子形式によるインフォームドコンセントを得ました。本プロトコルでは、医療的介入、脆弱な集団、欺瞞、生物学的試料、個人の財務データ、個人のパフォーマンス評価、または公的な行政記録へのアクセスは含まれていません。プロトコルに使用した研究ツールは、材料表に記載されています。

1. 被験者の募集とコンテキストの定義

  1. 評価対象として、低リスクの公共サービス申請および相談プロセスを選択する。例えば、情報の検索、資格の確認、書類の準備、申請書の提出、処理、通知、およびフォローアップサポートを必要とする、地方自治体、大学、または地域の行政手続きなどが挙げられる。
  2. 医療行為、法的事件の処理、移民ステータス、児童保護、財政援助の決定、懲戒手続き、緊急決定、または公式な行政記録に関わるコンテキストは除外する。
  3. 本プロトコルに適した公共サービスの課題として、「複数のステークホルダーグループの関与」、「責任境界の不明確さ」、「アクター間での調整失敗の繰り返し」、「不完全または矛盾したサービス情報」、「単一の合意された解決策の不在」という、複雑または厄介な問題（wicked problems）に似た特徴のうち、少なくとも3つを備えているものを検討する。
    注：本プロトコルを、完全に「厄介な問題」に対する解決策として提示してはならない。診断、共同設計（co-design）、およびシミュレーションテストのために、範囲を限定した低リスクの公共サービス課題を構造化するものとして提示すること。
  4. 公共サービスの利用、提供、調整、または管理に関する精通度に基づき、アンケート段階のために80～120名の参加者を募集する。
  5. このサンプルサイズを、非介入的なサービスデザイン研究として実現可能性を維持しつつ、複数の役割グループにわたって安定した記述的なステークホルダープロファイルを構築するための実務的な計画目標として使用する。
  6. 公共サービスプロセスに関与するすべての主要なステークホルダーの役割を代表する参加者を選出する。
  7. 共同設計ワークショップおよびプロトタイプテスト段階に参加させるため、20～30名の参加者からなるサブグループを編成する。
  8. 各グループが積極的な参加を維持できる十分に小さい規模になるように配慮し、4～6つの混合役割ワークショップグループを形成する。
  9. 各混合役割グループに、市民、窓口サービス職員、コミュニティワーカー、または管理者など、少なくとも3つのステークホルダーカテゴリーが含まれるようにする。
  10. 権力の不均衡が予想される場合は、初期のステークホルダーマッピングの議論において、市民とサービス提供者を分ける。
  11. 初期議論の後に、混合役割による統合（synthesis）を行う。混合役割統合では、管理者や専門職員が市民の意見を支配することを防ぐため、構造化された発言順の管理、サイレント・アイデアライティング、匿名でのカード提出、および匿名のドット投票を用いる。
  12. 参加者の募集、役割の準備、およびユーザーが単に専門家によって定義された問題に回答するのではなく、自らアイデアを出すことができる条件づくりに細心の注意を払う7,9,18。
  13. すべての参加者に対し、個人を特定できる名前、識別番号、自宅住所、電話番号、ケースID、医療記録、法的記録、所得記録、または機関のパフォーマンスファイルを開示しないよう指示する。
  14. 個人を特定できない参加者コード（例：P01およびP02）を割り当てる。
  15. データ収集前に、同一のファシリテーションスクリプト、ペインポイントカードのサンプル、デザインチャレンジのルーブリック、およびプロトタイプスコアリングの例を用いて、すべてのファシリテーターをトレーニングする。
  16. 重要なステップ：ファシリテーターに、少なくとも5つのペインポイントのサンプルと5つの「How might we（どうすれば～できるか）」ステートメントの草案を独立して分類させ、キャリブレーション（調整）を行う。
    注：ファシリテーターは、次へ進む前に、採用、クラスター化、および修正の決定について、少なくとも80%の一致に達していなければならない。
  17. ファシリテーターが採用、クラスター化、および修正の決定について少なくとも80%の一致に達するまで、不一致について議論する。
  18. 可能な限り、少なくとも2名のファシリテーターを配置する。1名は議論を導くリードファシリテーター、もう1名は時間、参加バランス、およびプロトコルからの逸脱を記録するオブザーバーとする。
  19. 複数のファシリテーターが並行してグループをリードする場合、各主要ステージの後に15～20分間のデブリーフィングを行い、プロンプトや解釈ルールの相違を監査シートに記録する。
    注意：参加者の募集、同意、ファシリテーターのトレーニング、および資料の準備が完了した後、調査者はステージ1を開始する前に一時停止してもよい。すべての参加者にコードが割り当てられ、すべてのワークシートに個人特定情報が含まれていないことを確認した後にのみ再開すること。

2. プロトコル材料の準備

  1. 実施前にプロトコルの資材を準備する。
  2. 参加者説明シート、匿名役割ベースのアンケート、ステークホルダー・マッピング・ワークシート、5段階ステークホルダー評価シート、公共サービス・ジャーニーマップ・テンプレート、ペインポイント・カード、デザインチャレンジ・テンプレート、ソリューション・カード、プロトタイプ選定シート、ファシリテーター校正ルーブリック、シミュレーションタスクシート、タスクセット等価性チェックリスト、プロトタイプ・スコアリング・ルーブリック、コーディングシート、解析構文またはワークフローノート、および匿名化チェックリストを準備する。
  3. 研究固有の各資材に、不変の内部識別子とバージョン番号を割り当てる。
  4. ジャーニーマップ・テンプレートを、情報検索、適格性または要件の確認、資材準備、申請書の提出、部門間処理、結果通知、フォローアップサポートの7つのデフォルトステージに構成する。
  5. 選択したサービスがデフォルトの低リスク行政申請経路とどのように異なるかを文書化した後にのみ、ステージ名を変更する。
  6. タッチポイント、責任主体、情報入力、出力、ペインポイント、および下流への影響のシーケンスはそのまま維持する。
  7. 実際の個人データ、行政データ、または機関データを含めることなく、プロトタイプタスクシート用の公共サービス・シミュレーションシナリオを設計する。
  8. プロトコルに必要なステージ、時間配分、資材、および定義済みの出力については、表1を参照すること。
  9. データ収集項目、スコアリングルール、妥当性しきい値、およびデータ保護管理については、表2を参照すること。
  10. サービスデザインの手法を用いて、複雑な公共サービスの問題を可視化し、議論および検証可能にする19。

表1：プロトコルの段階、タイミング、必要材料、および定義済みの出力。プロトコルのワークフローには、各段階における主な活動、参加者、推定時間配分、必要材料、および期待される出力が含まれています。こちらをクリックしてこの表をダウンロードしてください。

表2：データ収集指標、方法、除外基準、およびデータ保護管理。各プロトコル段階で収集された指標、対応するデータ収集方法、事前定義された除外基準、ならびに参加者の機密保持およびデータの完全性を保護するために実施された対策。こちらのリンクをクリックして本表をダウンロードしてください。

3. ステージ 1：ステークホルダーのマッピング

  1. 参加者にステークホルダーマッピング用ワークシートを使用し、選択した公共サービスプロセスに関与するアクターを個人で5〜8名リストアップするよう指示します。
  2. ステークホルダーマッピングの段階に25〜35分を割り当てます。
  3. 可視化プロトコルの全体的なワークフローについては、図1を参照してください。
  4. リストアップした各アクターについて、5段階のアンカー付き尺度（1 = 非常に低い、5 = 非常に高い）を用いて、「サービス結果への影響力」、「他のアクターへの依存度」、「サービス情報へのアクセス」、「調整圧力」の4つの次元で評価するよう参加者に指示します。
  5. 参加者が評価を完了する前に、書面による例を提示します。
  6. 「高い影響力」とは、そのアクターの決定、遅延、または解釈がサービス結果に実質的な影響を与えることと定義します。
  7. 「高い依存度」とは、他のアクターからの情報、確認、またはアクションがなければサービスプロセスを完了できないアクターと定義します。
  8. 各ステークホルダーグループの次元ごとの平均スコアを算出します。
  9. 同一次元においてステークホルダーグループ間に2ポイント以上の乖離がある場合、それを「認識ギャップ」としてフラグを立てます。これは5段階尺度の少なくとも40%の変動に相当し、単なる評価のノイズではなく、ワークショップでの議論を裏付けるのに十分な大きさであるためです。
  10. フラグを立てた各認識ギャップを、ワークショップの議論へと引き継ぎます。
  11. 再設計作業を開始する前に、ステークホルダーマッピングの結果を用いて、アクターの役割、依存関係、影響力、および情報の非対称性を可視化します。
  12. ステークホルダーのカテゴリー、次元ごとの平均スコア、およびフラグを立てた認識ギャップを含む、アクター関係プロファイルを作成します。

プロトタイプテストおよびユーザビリティフィードバックのための共同設計（コデザイン）ステージを含む、ステークホルダーマッピングプロセスのダイアグラム。
図1公共サービス設計視覚化プロトコルの全体的なワークフロー。 ワークフローは、ステークホルダーマッピング、公共サービス・ジャーニーマッピング、ダブルダイヤモンド共同設計、プロトタイプテストの4つの連動したステージで構成されています。アウトプットには、アクター関係プロファイル、ステークホルダー・ジャーニーマトリクス、デザインチャレンジステートメント、プロトタイプコンセプト、および初期段階のユーザビリティフィードバックが含まれます。拡散的な探索から収束的な解決策の開発への移行を説明するため、ダブルダイヤモンドフレームワークの「Discover（発見）」、「Define（定義）」、「Develop（展開）」、「Deliver（提供）」の各フェーズを強調しています。 この図の拡大版を表示するには、ここをクリックしてください。

4. ステージ2：公共サービスのジャーニーマッピング

  1. ワークショップのサブグループを誘導し、7段階のサービスプロセスをマッピングさせる。
  2. この段階に45～60分を割り当てる。
  3. 参加者に対し、各段階における主たるアクター、入力情報、出力情報、コミュニケーションチャネル、典型的な遅延、ペインポイント、深刻度、および下流への影響を記録するよう指示する。
  4. 参加者に、各ペインポイントの深刻度を5段階評価（1 = 軽微な不便、5 = サービスアクセスに影響を及ぼし、正式な苦情を誘発し、または重大なエスカレーションを引き起こす可能性が高い深刻な破綻）で評価させる。
  5. 重要な手順：ペインポイントを統合するのは、それらが同一のジャーニー段階に言及しており、同一種類の情報ギャップまたは責任の曖昧さを含み、かつ同様の下流への影響をもたらす場合に限る。
  6. 1人の参加者のみから報告されたペインポイントは、生のコーディングファイルに保持する。深刻度のスコアが4または5でない限り、これらのペインポイントを優先させない。
  7. 統合的なステークホルダー・ジャーニーマトリクス（図2）を作成し、マトリクスのセル全体にわたるペインポイント (P)、情報ギャップ (I)、責任の曖昧さ (R)、および再設計の機会 (O) の存在を可視化する。
  8. 不満や遅延を単一の集計された結果として扱うのではなく、ジャーニーマッピングを用いて、連続するタッチポイントにおけるサービスの破綻箇所を特定する。

サービスプロセス課題マトリクス、ダイアグラム、ペインポイント、情報ギャップ、責任範囲、ワークフロー分析
図2公共サービスの課題可視化のための統合ステークホルダー・ジャーニー・マトリクス このマトリクスは、横軸に7つの公共サービス段階を、縦軸に主要なステークホルダーグループを配置したものである。各セルは、以下の略称で示される特定のサービス上の課題の有無を表している。P = ペインポイント、I = 情報ギャップ、R = 責任の曖昧さ、O = 再設計の機会。このマトリクスは、ステークホルダーの役割とサービス段階固有の課題を結びつけることで、ステークホルダーマッピングと共創設計（コデザイン）を視覚的に橋渡しする役割を果たす。 この図の拡大版を表示するには、ここをクリックしてください。

5. ステージ3：ダブルダイヤモンド・共創デザインワークショップ

  1. ダブルダイヤモンド共創ワークショップを2.5～3時間のセッションで実施する。
  2. ダブルダイヤモンドフレームワークを採用し、拡散的な探索と収束的な意思決定を分離する7,8,14。
  3. 専門家主導の内部改革だけに頼るのではなく、市民、現場の提供者、管理者、およびパートナー組織が共創または共設計に参加するようにする4,2。
  4. 「発見（Discover）」フェーズを実行する（30～40分）。
  5. 参加者にステークホルダー・ジャーニーマトリクスを確認させ、不足しているペインポイントカードを追加するよう指示する。
  6. 有効な各ペインポイントカードに、ジャーニーの段階、影響を受けるアクター、サービスの破綻、情報のギャップまたは責任の曖昧さ、および下流への影響が記録されていることを確認する。
  7. 「定義（Define）」フェーズを実行する（40～50分）。
  8. 各参加者に、深刻度が高く、複数のアクターにまたがるサービスの破綻を最もよく表しているペインポイントカードを3枚、静かに選択してもらう。
  9. ステータス効果や権力格差を軽減するため、オープンディスカッションの前に、匿名でのドット投票または書面によるランキングを行う。
  10. 選択されたカードを、ジャーニーの段階、影響を受けるアクター、情報のギャップまたは責任の曖昧さ、および下流への影響に基づいてクラスター化する。
  11. ファシリテーターに各クラスターを読み上げさせ、カードが同じサービスの破綻を記述していることに参加者が同意しているかを確認する。
  12. 各クラスターを、単一の「私たちはどのようにして（How might we）」という設計課題ステートメントに変換する。
  13. 各設計課題ステートメントに、影響を受けるアクター、問題のあるジャーニーの段階、サービスの破綻、および希望する改善方向が明記されていることを確認する。
  14. 具体性、アクターの明確さ、マッピングされたエビデンスとの関連性、およびローファイプロトタイプ試験の実現可能性を評価する4項目のルーブリックを用いて、各設計課題を審査する。
  15. アクターが欠落している、無関係な複数の破綻を組み合わせている、時期尚早に解決策を提案している、またはシミュレーション用サービス資材を用いてテストできないステートメントは、すべて修正する。
  16. 元の草案、修正理由、および最終的に検証されたステートメントを監査シートに記録する。
    注意： 調査者は、最終的な設計課題ステートメントを承認した後で中断し、解決策カードとプロトタイプ選択シートの準備が整った時点で再開してもよい。
  17. 「展開（Develop）」フェーズを実行する（50～60分）。
  18. 参加者に、各設計課題に対するサービス改善案を出し、解決策カードに記録するよう指示する。
  19. 実際のケースデータ、個人の資格記録、重大な法的または政策的変更、あるいは個人が特定可能な行政ファイルが必要なアイデアは除外する。
  20. 「提供（Deliver）」フェーズを実行する（30～40分）。
  21. 参加者に、期待されるサービスへの影響、実装の実現可能性、ステークホルダーの合意、およびシミュレーションタスク試験への適合性の観点から、各解決策アイデアを5段階で評価してもらう。
    注： 実現可能性とテスト可能性の両方で平均スコアが少なくとも4.0以上のプロトタイプコンセプトを選択する。この閾値は、実装上のボトルネックなく、プロトタイプがシミュレーションタスク試験において実行可能であることを保証するために必要である。

6. ステージ4：低忠実度プロトタイプのテスト

  1. 優先順位付けされたコンセプトに基づき、低忠実度プロトタイプを作成する。
  2. 1ページのサービス要件チェックリスト、サービスステータス追跡モックアップ、およびフォローアップまたはエスカレーションパスウェイの3つのプロトタイプ形式を準備する。
  3. 重要なステップ：テスト前に、対になる2つのタスクセットを作成する。タスクセットが、判断ステップ数、読解量、必須入力項目、シナリオの複雑さ、および予想完了時間によってバランスが取れていることを確認する。
  4. 判断ステップ数、読解量、必須入力項目、シナリオの複雑さ、および予想完了時間に基づいてタスクセットを適合させる。
  5. 非研究参加者のユーザー3〜5名を用いて、適合させたタスクセットのパイロットテストを行う。
  6. 平均完了時間に10%以上の差がある場合は、タスクセットを修正する。
  7. シミュレーションによる公共サービスタスクを実施し、プロトタイプを評価する。
  8. 可能な限り、タスクへの習熟度とプロトタイプへの接触を区別するため、カウンターバランス設計または対照群設計を用いる。
  9. すべての参加者がプロトタイプ接触後のタスクの前にベースラインタスクを完了させた場合は、これを学習効果のリスクとしてプロトコル、結果、および考察のセクションに記録する。
  10. プロトタイプへの接触前に、各参加者に4つのベースラインタスクシナリオを提示する。
  11. プロトタイプへの接触後、同様の内容だが同一ではない4つのタスクシナリオを提示する。
  12. 各タスクの制限時間を最大5 minに設定する。
  13. すべての参加者に対し、同一のタスク指示を読み上げる。
  14. タスク遂行中にヒントを与えない。確認事項は手順に関する質問のみに限定する。
  15. タスク提示から最終回答までのタスク完了時間を秒単位で測定する。
  16. 参加者が5 min以内にタスクを完了しなかった場合は、タスクを未完了として記録し、完了時間を30 sとし、タスク成功を0とコード化する。
  17. 参加者が制限時間内に正解を選択したか、またはすべての必須判断ステップを完了した場合のみ、タスクを成功としてコード化する。
  18. 見落とし、誤り、または不要な判断ステップを集計し、エラー数を算出する。
  19. 各タスクの直後に、5段階評価（1 = 非常に不明確、5 = 非常に明確）を用いて、参加者が評価した明確さを測定する。
  20. すべてのタスク完了後、参加者にプロトタイプのユーザビリティと導入意向を評価させる。
    注：プロトタイプテストは、公共サービスのパフォーマンス向上ではなく、プロトコルによって生成された資料のタスクベースの明確さとユーザビリティを評価するものである。

7. データ解析および品質管理

  1. 回答時間が3分未満のアンケート回答、欠損値が20%を超える回答、すべてのリッカート尺度項目で同一の回答が選択されているもの、または役割に関する情報に矛盾がある回答を除外する。 
  2. アンケートデータをまとめ、連続変数については平均値と標準偏差を、カテゴリ変数については頻度とパーセンテージを算出する。 
  3. 構造化コーディングシートを用いて、ステークホルダーおよびジャーニーマッピングのデータをコーディングする。合意形成のための議論を行う前に、2名の研究者が少なくとも20%の資料を独立してコーディングし、一致率およびCohen's kappaまたは同等の信頼性統計量を報告する。 
  4. ワークショップの成果物を分析し、有効なペインポイントカード、問題クラスター、デザインチャレンジステートメント、解決策のアイデア、実現可能性の評価、および最終候補となったプロトタイプコンセプトの数を集計する。 
  5. 「要件の明確さ」「ステータスの可視性」「次のステップの明確さ」「タスク完了の容易さ」「資料使用への自信」の5つの5段階評価項目から、プロトコル固有のプロトタイプユーザビリティスコアを算出する。生スコア（5から25の範囲）を、以下の式を用いて0-10スケールに変換する。
    ユーザビリティスコア = (生スコア - 5) / 20 x 1017
  6. プロトタイプのテストデータを分析し、タスクベースの明確さとユーザビリティの指標を抽出する。IBM SPSS Statistics（分析 ＞ 平均の比較 ＞ 対応のあるT検定、分析 ＞ 非パラメトリック検定 ＞ 関連サンプル、分析 ＞ 記述統計 ＞ クロス集計 ＞ 統計量 ＞ McNemar）または同等のRコマンド（t.test(..., paired = TRUE)、wilcox.test(..., paired = TRUE)、mcnemar.test()）を使用して、検定統計量、正確なP値、可能な場合は95%信頼区間、および効果量を書き出す。 
  7. 定義済みのα = 0.05に基づきP値を記述的に解釈し、効果の方向性、大きさ、および指標間の整合性を強調して分析する24。
  8. 反復タスクの記録を参加者レベルで集計するか、1条件あたり4つのタスクを同時に分析する場合は、適切な反復測定モデルを使用する。
    注意：この仮定が明確に正当化されない限り、すべてのタスク記録を統計的に独立したものとして扱わないこと。
  9. 重要な手順：再現性を維持するため、データクリーニング、コーディング、タスクセットのマッチング、および統計解析に関するすべての決定事項を監査シートに記録する。匿名化されたすべてのデータは、研究チームのみがアクセス可能なパスワード保護されたファイルに保存すること。

結果

参加者の組み入れおよびプロトコルの実現可能性
本プロトコルは正常に実施され、10件の有効なアンケート回答（完了率89.3%）が得られたほか、ワークショップおよびプロトタイプテスト段階まで完了した28名の専用サブグループが構成された。維持された参加者は、公共サービスプロセスに関与する以下の7つのステークホルダーカテゴリーを代表していた：市民またはサービス利用者（n = 32）、最前線のサービススタッフ（n = 18）、コミュニティワーカー（n = 14）、公的機関の管理者（n = 12）、部門間コーディネーター（n = 8）、サードセクター代表者（n = 10）、およびデジタルプラットフォームサポートスタッフ（n = 6）。

28名のワークショップ参加者は、各グループに少なくとも3つのステークホルダーカテゴリーが含まれるように、役割を混ぜた5つのグループに分けられた。すべてのグループがステークホルダーマッピング、ジャーニーマッピング、ダブルダイヤモンド・コデザイン、およびプロトタイプテストを行い、アクター関係プロファイル、ステークホルダー・ジャーニー行列、検証済みデザインチャレンジステートメント、プロトタイプコンセプト、およびシミュレーションタスクテスト記録を作成した（表3）。構造化されたマッピング段階では、問題定義段階よりもファシリテーターによる介入が少なかった。

表3：参加者の組み入れ、ステークホルダーの構成、およびプロトコル実施段階。 参加者の募集と組み入れ、ステークホルダーグループの構成、ワークショップへの参加、プロトコルの完了、および4つのプロトコル段階における実施結果。 こちらの表をダウンロードするには、ここをクリックしてください。

可視化アウトプット：ステークホルダーおよびジャーニーマッピング
ステークホルダーマッピングの段階で9つのアクターカテゴリーが特定され、そのうち7つがすべてのグループで一貫して現れたため、ステークホルダー・ジャーニーマトリックスの縦軸として構成した。公的機関の管理者は平均影響力スコアが最も高く、一方で市民は依存度スコアが最も高く、情報アクセススコアが最も低かった。2ポイント以上の評価の乖離と定義される認識のギャップが9つ特定された。最大のギャップは、市民と管理者の間で認識されている情報アクセスにおいて生じた。

ジャーニーマッピングの段階で、126件の未加工のペインポイントに関する記述が得られた。ジャーニーの段階およびそれに伴う結果に基づいて構造的な統合を行った後、38件の固有のサービス不備が抽出され、そのうち12件が事前定義された優先順位付け基準（頻度 ≥10% または深刻度 ≥4.0）を満たした。優先度の高い不備の多くは、材料準備、適格性の確認、および部門間処理の過程で発生していた。これらの知見は、統合ステークホルダー・ジャーニーマトリクス（図2）にまとめられた。

共創デザインによる変革とプロトタイプの生成
ダブルダイヤモンド共創デザインワークショップにおいて、参加者は94枚の有効なペインポイントカードを作成し、それらを14の問題領域に分類しました。当初の17のデザインチャレンジステートメントのうち、改善の方向性が欠けている、影響を受けるアクターの定義が広すぎる、あるいは問題を明確に定義する前に解決策を提示しているといった理由で、6つのステートメントに修正が必要となりました。ルーブリックに基づく修正の結果、最終的に1のデザインチャレンジステートメントが採用されました。

開発フェーズにおいて、参加者は32個のサービス改善アイデアを創出した。あらかじめ定義した実現可能性およびテスト可能性のしきい値（スコア ≥4.0）を適用した結果、これらは6つの最終候補コンセプトに絞り込まれた。タスクベースのテストに向けて、3つの低忠実度プロトタイプコンセプト（1ページのサービス要件チェックリスト、サービスステータス追跡モックアップ、および定義されたエスカレーションパス）が選定された（図 3）。すべての可視化および共同設計ステージから得られた数値結果は、表 4にまとめられている。

サービスプロセスのフローチャート。ペインポイントからデザイン上の課題、そしてプロトタイプコンセプトに至るまでのステップ。
図3ペインポイントからプロトタイプへの変換経路。 この図は、優先順位付けされたペインポイントからデザインチャレンジステートメント、そして低忠実度（ローフィデリティ）のプロトタイプコンセプトへと至る3つの変換経路を示している。デザインチャレンジステートメントは、問題を解決策生成のためのオープンエンドな機会として定義する協同設計手法である「How might we（私たちはどのようにすれば〜できるか）」形式で提示されている。例として、(1) 不透明または不整合な材料要件から1ページのサービス要件チェックリストへの変換、(2) 不透明なサービス状況および責任者の特定からサービス状況追跡モックアップへの変換、(3) 遅延、却下、または修正依頼後の不透明なフォローアップルートからフォローアップまたはエスカレーションパスへの変換が示されている。 この図の拡大版を表示するには、ここをクリックしてください。

表4：プロトコルによって生成されたアウトプットおよび定量的タスクベース試験の結果。プロトコルの各段階で生成されたアウトプットは、シミュレーションによるタスクベースのプロトタイプ評価からの定量的な結果とともに、ユーザビリティおよびパフォーマンス指標を含んでいます。こちらのリンクをクリックして本表をダウンロードしてください。

タスクベースのプロトタイプテスト結果
このプロトコルにより、28人の参加者から合計24件のシミュレーションタスク記録（ベースライン12件およびプロトタイプ導入後12件）が得られた。プロトコルに基づき作成された教材は、シミュレーションタスク中のパフォーマンス向上に関連していた。繰り返し実施されたタスクにおける個人内相関を考慮するため、参加者レベル（n = 28）で対応のあるサンプル分析を行った。平均タスク完了時間は、ベースラインの178.4 ± 35.8秒から、プロトタイプ導入後は121.7 ± 28.4秒へと有意に短縮した（平均差 = −56.7秒、95% CI: −68.3 ～ −45.1秒、Cohen's dz = −1.92、対応のあるt検定、P < 0.01)。同様に、参加者1人あたりの平均エラー数は1.86 ± 0.61から0.79 ± 0.4に減少した（平均差 = −1.07エラー、95% CI: −1.27 ～ −0.87、Cohen's dz = −2.05、対応のあるt検定、P < 0.01)。タスク成功率は、参加者レベルの成功割合に対してウィルコクソン符号付順位検定を用いて分析し、有意な改善が示された（Z = −4.12, P < 0.01）。平均明瞭度の評価も参加者レベルで有意に向上し、3.1 ± 0.5から4.2 ± 0.4に増加した（平均差 = 1.10ポイント；95% CI, 0.94～1.26；Cohen’s dz = 2.71；対応のあるt検定、P < 0.001).

全体のタスク成功率は、ベースライン時の62.5%（タスク記録12件中70件）から、プロトタイプへの接触後は82.1%（タスク記録12件中92件）に上昇し、19.6パーセントポイントの増加を示した（95% CI, 8.2〜31.1パーセントポイント；2比率比較, P = 0.01）。集計数からプロトタイプ接触後に成功したタスク記録が2件増加していることが示されているため、作成可能なすべてのペア不一致表において、マクネマー検定による正確な感度結果はP < 0.01となり、入手不可能な個々の不一致ペアを再構成することなく、同一の方向性の結論が支持された。

参加者の報告によるアウトカムは、これらの運用上の知見と一致していた。5段階評価における明瞭性の平均評価は、3.1 ± 0.7から4.2 ± 0.5に上昇した（n = 条件あたり12タスクレコード；平均差 = 1.10ポイント；95% CI, 0.94～1.26；サマリーレベル標準化平均差 = 1.81；サマリーレベル P < 0.01）。最終的な材料は、プロトコル固有のユーザビリティスコア 78.4 ± 9.6 および導入意向評価 4.1 ± 0.6 を達成した（図4）。これらのユーザビリティスコアは、標準化されたシステムユーザビリティスケール（SUS）ではなく、プロトコル固有の5つの調査項目から算出されました。自由記述形式のフィードバックがこれらの結果を裏付けており、参加者28名のうち21名がステークホルダー・ジャーニー・マトリックスの視覚的な明快さが向上したと報告し、17名がアクターの役割がより明確になったと報告し、19名がサービスの段階がより明確になったと報告し、20名がプロトタイプ資料の実用的なユーザビリティを確認しました。

ユーザビリティ改善棒グラフ；完了時間、エラー数、タスク成功率、明快さを測定。
図4プロトタイプへの曝露後におけるタスクベースの明快性とユーザビリティのアウトカム。 (A平均タスク完了時間（秒）B) タスクあたりの平均エラー数 (Cタスク成功率 (%)D) 参加者が評価した明快さ（1～5段階評価）。パネル（における追加指標D）には、プロトコル固有のユーザビリティスコアおよび導入意向が含まれている。棒グラフは参加者レベルの平均値を表し、エラーバーは標準偏差（SD）を示す。ベースラインとプロトタイプ導入後の条件間の比較は参加者レベルで実施され、統計的に有意であった（P < 完了時間、エラー数、明瞭性、およびタスク成功率について（0.01）で評価した。 この図の拡大表示をご覧になるには、こちらをクリックしてください。

ディスカッション

   本プロトコルは、低リスクの公共サービス環境において複雑な問題を構造化するための、体系的かつ再現可能な手法を提供します。ステークホルダーマッピング、ジャーニーマッピング、ダブルダイヤモンドによる共創（co-design）、および低忠実度プロトタイプのテストを順次統合することで、断片的なマルチアクターによる苦情を、検証可能なサービス介入策へと変換します。その際、シミュレーションによるユーザビリティの根拠と、実際の行政パフォーマンスとの間には明確な区別を維持します。代表的な結果は、公共サービスの課題が単一の手続きステップに限定されることは稀であり、むしろユーザー、現場職員、およびバックオフィス管理者の間に分散していることを示しています。本プロトコルの重要な貢献は、ソリューションの開発を開始する前に、これらのマルチアクター間の依存関係と情報の非対称性を可視化できる点にあります。

本プロトコルの中心的な構成要素は、ステークホルダー・ジャーニー・マトリクスです。複数のアクターが関与する公共サービスにおいて、ステークホルダーはサービスの失敗がどこで発生しているかについて、しばしば異なる解釈を持ちます。このマトリクスは「境界オブジェクト（boundary object）」として機能します。これは、参加グループ間で共通のアイデンティティを維持しながら、異なる概念的な境界を越えて適応可能な有形のアティファクトであり、それによって役割を越えた合意形成と協調的なデザインを促進します25,26。拡散したユーザーの不満を、観察可能なステージ固有のイベントへと変換することで、このマトリクスは問題定義が曖昧になるリスクを軽減し、ワークショップの参加者が慣例的ではあるが効果のない行政上の調整に終始することを防ぎます。

ダブルダイヤモンド・フレームワークを構造的に適用することで、問題の探索から実行可能なサービスの再設計への制御された移行が可能になります。分析の結果、広範な不満点から具体的な「どうすれば〜できるか（How might we）」という設計課題へと移行させる段階が、プロセスの中で最も困難であることが示されました。この段階では、積極的なファシリテーション、明確な選別基準、および記録された修正作業が必要となります。これらの構造的な制約（影響を受けるアクター、ジャーニーの段階、サービスの破綻箇所、および意図する改善点の指定）がなければ、共創（co-design）セッションによって、特定されたサービスの破綻に対処できない汎用的な解決策が導き出される可能性があります。優先順位付けされたペインポイント（例：不明確な材料要件）と、それに対応するプロトタイプ（例：1ページのチェックリスト）との直接的な結びつきは、本プロトコルの生成的な妥当性を実証しています。

本プロトコルによって得られたタスクベースのプロトタイプ検証結果と、実際の組織的な改善の主張とは明確に区別することが重要である。タスク完了時間の短縮およびエラー率の低下が観察されたことは、共同設計された資料がシミュレーション条件下で明確であり、利用可能であることを示している。しかし、公共部門における初期段階のプロトタイピングは、主に実装前の学習支援およびリスク軽減を目的としている16,27。また、代表的なアプリケーションで用いられた固定的な事前・事後テストのシーケンスは、参加者がプロトタイプ後のタスクの前にベースラインタスクを完了させたため、タスクへの習熟や学習効果を導入した可能性がある。今後の実装では、プロトタイプによる効果と学習効果を区別するために、カウンターバランスさせたタスク順序、マッチングさせた対照群、または反復測定モデルを使用すべきである。

再現性を確保するためには、プロトコルの一般的な失敗事例に対するトラブルシューティングが不可欠です。ステークホルダーマッピングにおいて、一般的すぎるアクターラベルしか作成されない場合は、ファシリテーターは参加者に対し、各アクターに関連する意思決定、情報、または調整上の依存関係を具体化するように促すべきです。カスタマージャーニーマップが単なる不満リストになってしまった場合は、各カードを特定のジャーニー段階、影響を受けるアクター、情報のギャップ、および下流への影響へと戻すべきです。

ワークフローを異なる公共サービス環境に移行する場合、プロトコルの修正が必要になると予想されます。大学の行政サービスでは、ステージラベルにおいて登録、異議申し立て、およびサポートプロセスを強調することがあります。外来診療経路の再設計においては、倫理的保護策および臨床ガバナンスの承認を拡充させる必要があります。社会福祉の調整においては、機関をまたぐデータ保護要件により、より強力な匿名化および紹介管理が必要になる場合があります。また、文化的な差異、行政上の違い、および政府間の相違によって、参加者が手続きに対してどの程度自由に批判を行えるか、混合グループ内で権限がどのように分配されるか、あるいは匿名投票やユーザーと提供者の個別のマッピングが必要かどうかが影響を受ける可能性があります。

この手法を適用する際には、いくつかの制限を考慮する必要があります。第一に、本プロトコルは低リスクのコンサルティングおよび管理サービス向けに特別に設計されています。医療介入や法的裁定などのハイステークスな環境に適用する場合、倫理的保護策、専門知識、およびデータ保護プロトコルの大幅な強化が必要となります。第二に、初期のマッピング段階でユーザーグループとプロバイダーグループを分けることで、ネガティブなフィードバックの抑制を軽減できる可能性がありますが、混合ロールによる統合の過程では、固有の権力不均衡が依然として共同作業のダイナミクスに影響を及ぼす可能性があります。第三に、「定義（Define）」フェーズの成功は、ファシリテーターの専門性に依存します。したがって、独立した研究グループが異なる設定間でアウトプットを比較する前に、標準化されたファシリテーター研修、キャリブレーション演習、観察チェックリスト、およびセッション後のデブリーフィングを実施する必要があります。

結論として、この体系的な視覚化プロトコルは、複雑な公共サービスの課題に対する診断および解決策のプロトタイピングのための、構造化され、倫理的境界が定められたアプローチを提供します。本手法は、専門家主導の改革とユーザー中心設計を橋渡しする再現可能なツールキットを提供することで、抽象的な政策議論を超えた公共サービスのイノベーションを推進します。今後の研究では、市町村のデジタルサービス、大学の事務サービス、教育支援、医療の外来パスウェイの再設計、社会福祉コーディネーションなど、さらなる公共サービス領域にこのプロトコルを適用すべきです。また、管理されたワークショップで開発されたプロトタイプが、日常的な行政ワークフローに導入された後にどのようなパフォーマンスを示すかを評価する研究も必要です。

開示事項

著者は、競合する利害関係がないことを宣言します。

謝辞

著者らは、アンケート、共同設計ワークショップ、およびプロトタイプ検証セッションに参加してくださった市民、最前線のサービススタッフ、公的機関の管理職を含むすべての参加者に感謝いたします。マルチアクターによる公共サービスの体験に関する彼らの寄与と洞察は、この体系的なサービスデザイン可視化プロトコルの開発を支えました。

著者らはまた、マカオ市立大学の革新・デザイン学部、深圳大学の芸術・デザイン学院、および広東白雲大学の芸術・デザイン学院による機関的および学術的な支援に感謝いたします。本研究は、公的、商業的、または非営利セクターのいかなる資金提供機関からも、特定の助成金を受けていません。

材料

この記事で使用された材料の一覧
名前会社カタログ番号コメント
分析構文またはワークフローノート研究チームPSD-VP-S17 v1.1対応のある比較、ウィルコクソン検定、マクネマー感度チェック、効果量、信頼区間、およびレポート出力のためのSPSSまたは同等のRワークフローを文書化するため。
匿名役割ベース質問票研究チームPSD-VP-S02 v1.1ステークホルダーの役割情報および選択された公共サービスプロセスに関するベースラインの認識を収集するため。
匿名化チェックリスト研究チームPSD-VP-S14 v1.1参加者名、ID番号、住所、ケースID、および行政記録が収集または開示されないことを確認するため。
デザインチャレンジテンプレート研究チームPSD-VP-S07 v1.1クラスター化されたペインポイントを、構造化された検証可能な「How might we（どうすれば〜できるか）」ステートメントに変換するため。
ファシリテーター較正ルーブリック研究チームPSD-VP-S15 v1.1ファシリテーターの準備、コーディング例、チャレンジステートメントの修正、およびファシリテーター間の整合性を標準化するため。
5段階ステークホルダー評価シート研究チームPSD-VP-S04 v1.1各ステークホルダーの影響力、依存関係、情報アクセス、および調整上の圧力を評価するため。
IBM SPSS StatisticsIBM CorporationVersion 26.0以降プロトタイプ検証結果の記述統計分析、対応のあるt検定、ウィルコクソン符号付順位検定、およびマクネマー検定を実施するため。
低忠実度プロトタイプ資材研究チームPSD-VP-S10 v1.1必要事項チェックリスト、サービスステータスのモックアップ、フォローアップパスウェイを含む、初期段階のサービス資材を開発および検証するため。
Microsoft ExcelMicrosoft CorporationMicrosoft 365または同等品質問票データを整理し、記述統計を計算し、コーディングシートを管理し、サマリーテーブルを作成するため。
ペインポイントカード研究チームPSD-VP-S06 v1.1サービスの破綻、情報の乖離、責任の曖昧さ、影響を受けるアクター、および下流への影響を記録するため。
参加者説明書研究チームPSD-VP-S01 v1.1参加前に、研究目的、手順、参加者の権利、および同意要件を説明するため。
パスワード保護付きデータストレージ機関または研究チームのコンピュータシステム研究チームにアクセスを制限匿名化された質問票データ、ワークショップ成果物、コーディングファイル、およびタスク検証記録を安全に保存するため。
プロトタイプ採点ルーブリック研究チームPSD-VP-S12 v1.1プロトタイプの明快さ、ユーザビリティ、タスク成功率、エラー数、および導入意向を評価するため。
プロトタイプ選定シート研究チームPSD-VP-S09 v1.1事前定義された実現可能性および検証可能性の閾値を満たすプロトタイプコンセプトを選定するため。
公共サービスジャーニーマップテンプレート研究チームPSD-VP-S05 v1.1情報検索、必要事項の明確化、資料準備、申請、処理、通知、およびフォローアップサポートにわたる公共サービスプロセスをマッピングするため。
模擬タスクシート研究チームPSD-VP-S11 v1.1プロトタイプへの接触前後におけるタスク完了率、意思決定の正確性、および明快さを評価するため。
ソリューションカード研究チームPSD-VP-S08 v1.1ダブルダイヤモンド共創ワークショップ中に生成されたサービス改善アイデアを文書化するため。
ステークホルダーマッピングワークシート研究チームPSD-VP-S03 v1.1公共サービスプロセスに関与する5〜8名のアクターを特定し、アクターの役割と依存関係を可視化するため。
構造化コーディングシート研究チームPSD-VP-S13 v1.1ステークホルダーマッピングデータ、ジャーニーマップ成果物、ペインポイントクラスター、およびワークショップ結果をコーディングするため。
タスクセット等価性チェックリスト研究チームPSD-VP-S16 v1.1意思決定ステップ、読解量、必須項目、複雑性、およびパイロット完了時間に基づいた、ベースラインタスクとプロトタイプ後タスクのマッチングを文書化するため。

参考文献

  1. Rittel HWJ, Webber MM. Dilemmas in a general theory of planning. Policy Sci. 1973;4(2):155-69.
  2. Suoheimo M, Vasques R, Rytilahti P. Deep diving into service design problems: Visualizing the iceberg model of design problems through a literature review on the relation and role of service design with wicked problems. Des J. 2021;24(2):231-51.
  3. Voorberg WH, Bekkers V, Tummers LG. A systematic review of co-creation and co-production: Embarking on the social innovation journey. Public Manag Rev. 2015;17(9):1333-57.
  4. Schwoerer K, Keppeler F, Mussagulova A, Puello S. CO-DESIGN-ing a more context-based, pluralistic, and participatory future for public administration. Public Adm. 2022;100(1):72-97.
  5. Edelmann N, Mergel I. Co-production of digital public services in Austrian public administrations. Adm Sci. 2021;11(1):https://doi.org/10.3390/admsci11010022
  6. Blomkamp E. Systemic design practice for participatory policymaking. Policy Des Pract. 2022;5(1):12-31.
  7. Vargas C, et al. Exploring co-design: A systematic review of concepts, processes, models, and frameworks used in public health research. J Public Health. 2025;47(4):https://doi.org/10.1093/pubmed/fdaf084
  8. Wacnik P, Daly SR, Verma A. Participatory design: A systematic review and insights for future practice. Des Sci. 2025;11:https://doi.org/10.1017/dsj.2025.10009
  9. Udoewa V. An introduction to radical participatory design: Decolonising participatory design processes. Des Sci. 2022;8:https://doi.org/10.1017/dsj.2022.24
  10. Stickdorn M, Schneider J. This is service design thinking: Basics, tools, cases. BIS Publishers; Amsterdam; 2011. https://www.wiley.com/en-us/This+is+Service+Design+Thinking%3A+Basics%2C+Tools%2C+Cases-p-9781118156308
  11. Blomkamp E. The promise of co-design for public policy. Aust J Public Adm. 2018;77(4):729-43.
  12. Bryson JM. What to do when stakeholders matter: Stakeholder identification and analysis techniques. Public Manag Rev. 2004;6(1):21-53.
  13. Folstad A, Kvale K. Customer journeys: A systematic literature review. J Serv Theory Pract. 2018;28(2):196-227.
  14. Design C. Eleven lessons: Managing design in eleven global brands. Design Council; London; 2007. https://www.idi-design.ie/content/files/ElevenLessons_Design_Council_2.pdf
  15. Steen M, Manschot M, De Koning N. Benefits of co-design in service design projects. Int J Des. 2011;5(2):53-60.
  16. Not E, et al. Designing a digital environment to support the co-production of public services: Balancing multiple requirements and governance concepts. Digit Gov: Res Pract. 2024;5(3):https://doi.org/10.1145/3603632
  17. Excellence UGCfPS. Design thinking for public service excellence. UNDP Global Centre for Public Service Excellence; Singapore; 2014. https://www.undp.org/publications/designthinking-public-service-excellence
  18. Osborne SP. The new public governance? Public Manag Rev. 2006;8(3):377-87.
  19. Hartley J. Innovation in governance and public services: Past and present. Public Money Manage. 2005;25(1):27-34.
  20. Freeman RE. Strategic management: A stakeholder approach. Pitman; Boston; 1984.
  21. Stickdorn M, Hormess ME, Lawrence A, Schneider J. This is service design doing: Applying service design thinking in the real world. O'Reilly Media; Sebastopol; 2018. https://www.thisisservicedesigndoing.com/
  22. Bovaird T. Beyond engagement and participation: User and community coproduction of public services. Public Adm Rev. 2007;67(5):846-60.
  23. Donetto S, Pierri P, Tsianakas V, Robert G. Experience-based co-design and healthcare improvement: Realizing participatory design in the public sector. Des J. 2015;18(2):227-48.
  24. Tomczak M, Tomczak E. The need to report effect size estimates revisited: An overview of some recommended measures of effect size. Trends Sport Sci. 2014;21(1):19-25.
  25. Sanders EBN, Stappers PJ. Co-creation and the new landscapes of design. CoDesign. 2008;4(1):5-18.
  26. Star SL, Griesemer JR. Institutional ecology, 'translations' and boundary objects: Amateurs and professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39. Soc Stud Sci. 1989;19(3):387-420.
  27. Liedtka J. Why design thinking works. Harv Bus Rev. 2018;96(5):72-9.

再版と許可

タグ

お問い合わせ
図書館に推薦する

プライバシー

利用規約

ポリシー

著作権 © 2026 MyJoVE Corporation. 無断転載を禁じます。