good-services-service-design

エンドツーエンドのサービス設計

プロバイダーの組織図や単一の画面ではなく、利用者が必要とする成果を基準にサービスを定義します。Good Servicesは、問題や改善点を見つけるための実践者向けフレームワークとして活用し、法的基準、自動認証、または未検証の設計が機能することを示す測定済みの証拠として扱わないでください。

有用な範囲を選ぶ

提供された概要、調査、分析、現場からの報告、ポリシー、運用上の制約を確認します。利用者が得たい成果、開始のきっかけ、完了条件、利用者グループ、チャネル、課題を特定します。受付用の質問票をいつも繰り返すのではなく、すでに得られている回答を活用します。不足している前提を明示し、証拠で裏付けられる部分を進めます。解決していない事実が適切な提案の妨げになる場合に限り、質問します。

簡易レビューでは、すべての資料ではなく、最も重要な調査結果と次に必要な証拠を示します。複数チームにまたがる再設計では、定義、ジャーニー、ブループリント、バックログ、サービス標準、検証計画が必要になる場合があります。ワークショップの依頼には、ファシリテーション計画と未記入のテンプレートが必要であり、ワークショップで合意された内容を捏造してはいけません。依頼に合わせて成果物を調整し、7つのパートからなる一式を必須として扱わないでください。

利用者のジャーニー全体をたどる

タスクの明確化に役立つ場合は、サービス定義、サービスマップ、ブループリントを使用します。該当する場合は、サービスの発見、利用資格の確認、準備、意思決定、取引、待機、サポート、完了、変更、キャンセル、アフターケアをマッピングします。順調に進む経路だけでなく、失敗した経路や代替経路も含めます。

利用者から見える行動や情報と、スタッフ、システム、ポリシー、引き継ぎを分けて示します。各ステップで証拠を記録し、誰の経験を表すのか、どこに情報の不足があるのかを明記します。利用者の感情、利用量、離脱の原因、スタッフの対応能力、チーム間の責任分担を捏造してはいけません。ステークホルダーの想定は、観察された利用者調査ではありません。離脱の指標だけでは、利用者がなぜ離れたのか、別の場所で成果を得られたのかは判断できません。

証拠に基づいて原則を確認する

原則を、見つけやすさ、目的、期待、完了、親しみやすさ、既有知識、組織内の引き継ぎ、労力、一貫性、行き止まり、インクルージョン、インセンティブ、変更、意思決定、人による支援を検討するための問いかけとして読みます。除外が平均化されて見えなくならないよう、利用者が求める成果と、実際に影響を受けるグループを常に明確にします。

ローカルスコアカードは、採点によって意思決定が改善される場合にのみ使用します。このカードでは、証拠に基づく不十分／部分的／十分なパフォーマンスと、未検証および対象外を区別します。テンプレートに空欄があるというだけで数値を付けてはいけません。限定された範囲での2点は、サービス全体がすべての人に機能する証拠ではありません。また、スコアは普遍的な品質割合に合計できる間隔尺度ではありません。

このパッケージの0～2の評価基準は、内部で使う簡略表記です。Lou Downeが公開しているGood Services Scaleは0～4を使用します。ローカルのワークシートを公式の尺度として提示したり、実際の定義を確認せずに両者の間で換算したりしないでください。公開されている尺度を正式に使用する場合は、著者の最新資料を参照してください。

スコアではなく、サービスを改善する

実際に確認されたユーザーへの被害、成果の未達、発生頻度、排除、運用上のリスク、必要な労力を優先します。確認済みの原因と仮説を区別します。提案する各修正について、根拠、判明している場合は担当者、依存関係、受け入れ基準、改善を確認できる観察結果を示します。必要に応じて バックログと サービス標準を使用してください。

クリック数を何よりも減らすのではなく、不必要な負担を最小限にします。一時停止、確認、異議申し立て、人との対話は、理解と主体性を守るうえで役立つことがあります。解約を見えにくくしたり、セルフサービスに人々を誘導したり、サポートを受けにくくしながら問い合わせの抑制を最適化したりしないでください。拒否やエラーの後に何が起こるか、実行可能な代替手段やエスカレーション先も含めて説明します。資格や異議申し立ての権利をでっち上げてはいけません。

アクセシビリティとインクルージョンを実現するには、関連するニーズやチャネルを実際に使ってテストする必要があります。見た目の監査だけでは、等しくアクセスできることを証明できません。現行の適用要件、プライバシー、セーフガードを確認し、実務上の原則を法的助言と言い換えないでください。書類、接続環境、言語の流暢さ、時間、自信が不足している職員、介護者、パートナー組織、ユーザーに転嫁される負担を評価します。

検証と報告

リスクの高い仮説を検証するため、観察可能なユーザー成果、運用指標、ガードレールを含む小規模なテストまたはパイロットを定義します。プロトタイプでの意図と、観察された結果を区別します。サンプリング方法、対象チャネル、期間、未解決の限界を説明します。提案段階にすぎないワークショップ、アンケート、ユーザビリティテスト、本番パイロットが実施されたと主張してはいけません。

意思決定に役立つマップ、調査結果、修正案または計画を、根拠と具体的な次の検証内容とともに提示します。ワークショップでは、既存のアジェンダを使用し、実際の依頼に合わせて役割、所要時間、参加に必要な配慮を調整してください。確認されるまでは、ステークホルダーの合意や担当者の割り当てが成立したものと見なしてはいけません。

2026-09-13に確認した情報源：著者の原則および 著者による尺度の説明。詳細なローカルテンプレートは、このパッケージによる応用であり、新たな公式標準ではありません。メタデータは Agent Skills仕様に準拠しています。