# 3.6 評価をして改善のサイクルを回す **中心主張**: プロトタイプの評価は、開発に関わる多様な立場のメンバー（技術者だけでなく営業・販売・サポート窓口の担当者など）とユーザー自身の両方で行い、そこで出てきた「ことば」を改善に反映しながらサイクルを回すことが重要。 **論の展開**: - プロトタイプを作成しカタチにすることで、システムやアプリの流れを把握できる。評価するときは、ペルソナシートやジャーニーマップとともに、分析したユーザーのニーズや課題に合致しているかどうかを検討する - UXデザインの手法でまとめた各種シートやアウトプットを活用することで、個人的な経験や感想だけで評価してしまうのを避けられ、多様な視点で吟味してきた結果からずれていないか検討できる - 評価は、システムやサービスの開発にかかわるメンバー全員で実施する。どんなに優れたシステムでも、ビジネスとして成り立ち、社会システムとして継続利用されなくては成功とはいえない - UXデザインの関係者や技術者の視点だけでなく、営業や販売の担当者、ユーザーをサポートする窓口の担当者といった多様な目で評価することが大切。接しているユーザーによって状況や経験していることは異なる - UXデザインのガイドラインなども参考にするとよい。意見が割れたらペルソナに戻り、「このユーザーならばどう考えるか」を基準に検討する - そして何より重要なユーザーの評価も必ず取り入れる。評価のプロセスで出てきた「ことば」を、システムやサービスの改善に反映する - 関係者から評価を受けたら、必要に応じてジャーニーマップを修正する。特にTO-BEを修正しておくと、あるべきサービスをチーム全体で共有できる - アジャイル型開発ではUXデザインのプロセスに応じて調査・分析、コンセプト作成、プロトタイピング、評価を行い、それぞれのプロセスを見直しながらプロトタイピングして評価するといったサイクルを何度か回しながら最終形のシステムやサービスへと進めていく **実践指針**: - プロトタイプ評価は開発チーム全員に加え、営業・販売・サポート窓口など多様な立場の担当者を巻き込んで行え - 評価者の間で意見が割れたら、個人の主観ではなくペルソナに立ち返り「このユーザーならどう考えるか」を判断基準にせよ - 必ずユーザー自身の評価を取り入れ、評価で出てきた実際の「ことば」を改善に反映せよ - 評価後はジャーニーマップ（特にTO-BE）を必要に応じて修正し、チーム全体であるべき姿を共有し直せ - アジャイル型開発では調査・分析→コンセプト→プロトタイピング→評価のサイクルを1回で終わらせず、何度も回しながら最終形に近づけよ **根拠となる研究・事例**: - 例 → ストーリーボードを使って関係者を集めて説明し、出てきたコメントや疑問に答えてシステム開発に活かす手順（図3.6.1） **キーワード**: - 多様な視点での評価: 技術者だけでなく営業・販売・サポート窓口を含めた評価体制 - ジャーニーマップの修正/TO-BE: 評価結果を反映し、あるべき姿をチームで再共有する仕組み