更新日：
相談内容と専門家からのアドバイス
３）サービス設計におけるUXDの進め方 ＜相談件数３件＞
＜お悩み３－１：専門家からのアドバイス①＞
確かに、“表現”の問題のようです。もう少し言えば、“表現上の粒度の違い”もしくは“表現上の主体（起こっている事象／ユーザ側の認知・行動／画面のことなのか”ということのようです。
相談者様が挙げておられる例ですと、
「アプリを使えないこと」＝事象
「ボタンアイコンを押して次の画面を表示できないこと」（想像するに、「次の画面を表示したくてもボタンアイコンをうまく押せないこと」、だと理解しました。でないと、（ボタンは押せたけど、次の画面が出てこない、ということだとすると、）他の問題になってしまいます。）＝ユーザ側の認知・行動
「ボタンアイコンが押せないこと」＝ユーザ側の認知・行動（上記解釈により、上記と同じ）
「ボタンアイコンに気付けないこと」＝ユーザ側の認知・行動
「ボタンアイコンが小さいこと」画面＝画面
（上記の並べ方は、粒度大→小、としました。）
見方を変えると、粒度大は、あくまでも表面的な事象であって、そのような事象を引き起こしてしまう原因を突き詰めていくと、下に降りてくる、という、一種の問題解決プロセスでもあるようです。
回答にはなっていないかもしれませんが、表現する状況（相手）によって、どのレベル（粒度）で表現するかは、変わってくるような気もしますし、上述したように、一連のプロセスだとすれば、どれか一つだけを取り上げて言うのも端折り過ぎなのかもしれません。
＜お悩み３－１：専門家からのアドバイス②＞
ISO 9241-11の「usability」の定義は “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”とされています。そのユーザビリティ上の問題が、ボタンやアイコンのサイズからくる視認性の問題なのか押しづらさなのか、ナビゲーションの問題なのか、アプリ全体の使用感なのか、原因や症状は様々ですが、ユーザーが使用上その製品の「効果」・「効率」・「満足度」の面で問題を抱えたとすれば、それらはすべてユーザビリティ上の問題と言って差し支えないと思います。
＜お悩み３－１：専門家からのアドバイス③＞
“ユーザビリティ問題”ということにこだわらずに考えてみましょう。プロジェクトのゴールはユーザが使えるようにするとか、サービスに課金してもらうとかゴールから逆算して問題とらえましょう。上がってきた問題を整理するのに私が使っている方法が「リスク・ハザード」という考え方です。https://ecompliance.co.jp/CSV/MHLW_Guideline/Risk_Assessment.htmlもともとは安全衛生などの分野で使われていたと思いますが、問題が起こってビジネスに貢献できないということを考えると起こった問題に優先度をつけて取り組む必要があるためです。ISO規格になっているので汎用的な概念なので、相談者様の事業にフィットするように解釈しオリジナリティを加えて活用してみるのをおすすめします。
＜お悩み３－１：専門家からのアドバイス④＞
難しい問題かとは思いますが、観察された事実から判断していくしかないと思います。
挙げていただいた事例で言うと、ボタンを押しづらそうにしていたり、近くの別のボタンを押してしまったりしていたのであれば、ボタンの大きさ、正確に言うとタッチエリアの大きさが適切でないことが考えられますが、ボタンに気付けないのは大きさ以外にレイアウトや表現の問題が、ボタンが押せない、ボタンを押して次の画面を表示できない、といったことは、レイアウトや表現以外にも画面遷移設計にも問題があるかもしれません。
いずれにせよ、観察された問題の原因になりうることはどれもユーザビリティの問題と捉えてしまって差し支えないように思います。さすがに「アプリを使えないこと」は大括りすぎるとは思いますが。
＜お悩み３－１：専門家からのアドバイス⑤＞
改めてISO9241-11のユーザビリティの定義に戻ってユーザー視点での「結果」で考えるとよいです。
「特定の利用状況において、特定のユーザによって、ある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、ユーザの満足度の度合い。」とあります。
「ボタンアイコンが小さいこと」が要因で何度も押すのに失敗した結果、目標を達成するのに時間がかかったのであれば「効率」の問題、押せずに目標を達成できなかったら「有効さ」の問題になります。
「ボタンアイコンに気付けない」結果、「ボタンアイコンが押せない」、「ボタンアイコンを押して次の画面を表示できない」ことによりユーザーの目標が達成できなかったのであれば、「有効さ」を阻害したときに起こった現象ということになります。
アプリを使ってなにかしらの目標を達成したかったのにさまざまな問題で「アプリを使えない」という結果であれば、やはり「有効さ」の問題が起こったことになります。
上記内容を構造化して記述してみると整理して説明しやすくなるかもしれません。
＜お悩み３－１：専門家からのアドバイス⑥＞
問題をアプリ側とユーザー側で切り分けて考えてはいかがでしょうか。例であげいる内容だと、ボタンアイコンが小さいことはアプリ側の問題であり、それが要因でユーザーが気づけない、押せない、次に進めない等の問題が発生していると考えられます。アプリ側の問題をユーザビリティ問題と定義し、それが要因となって引き起こされるユーザー側の問題は、事象と考えるとスッキリするのではないでしょうか。ユーザビリティ問題が解決できれば、これらの事象も発生しなくなるはずなので，説明がしやすいかと思います。
ただ，これが正しい定義ということではなく，私だったらこのように説明するかな，という一案ですので，ご参考までに。
＜お悩み３－１：専門家からのアドバイス⑦＞
ヒューリスティック評価を行うと良いのでは無いでしょうか？
有名な指標としては、ヤコブ・ニールセンのユーザービリティーの10原則
システム状態の認知度（Visibility of system status）
システムと実世界の調和（Match between system and the real world）
ユーザーの主導権と自由度（User control and freedom）
一貫性と標準化（Consistency and standards）
エラーの予防（Error prevention）
再生より再認（Recognition rather than recall）
柔軟性と効率性（Flexibility and efficiency of use）
美的で最小限のデザイン（Aesthetic and minimalist design）
ユーザーによるエラーの認識・診断・回復のサポート（Help users recognize, diagnose, and recover from errors）
ヘルプとドキュメンテーション（Help and documentation）
この指標に則り、指摘内等を分類するとよろしいかと思います。
＜お悩み３－１：専門家からのアドバイス⑧＞
■ ユーザービリティ問題における表現方法の選択は、報告先(読者)に合わせて変えてはいかがでしょうか
ユーザービリティの問題自体は基本的にユーザービリティの原則で考えて、設計物とメンタルモデル、ビジネス等の観点で指摘事項を整理します。但し、纏める時には、資料目的や読者にあわせ、どれかの観点に重きをおいて整理しています。(設計物：ファクト、メンタルモデル：ファクト + 解釈 or 影響、ビジネス：影響)
例えで挙げらているユーザビリティの問題について、設計者に伝え改善を促すのであれば、「ボタンアイコンが小さいこと」になります。一方で、ユーザビリティ関係者に伝えるのであれば、「ボタンアイコンに気付けないこと」「ボタンアイコンが押せないこと」です。事業企画等に説明する場合には、「ボタンアイコンを押して次の画面を表示できないこと」「アプリを使えないこと」です。
＜お悩み３－１：専門家からのアドバイス⑨＞
ユーザビリティテストはその機器やアプリが「使えるか」をテストします。問題の発見には次の三段階があります。「気付くか」「わかるか（理解できるか）」「使えるか」です。機器やアプリを使う際の問題点をこれらの三段階の視点で抽出します。例に挙げていただいているモバイルアプリのテストであれば、まず最初に「ボタンアイコンに気付く/気付かない」を判断します。「ボタンアイコンに気付かない」結果として、「ボタンアイコンが押せない」ということが発生した可能性はあります。しかし、「ボタンアイコンに気付いた」けれども、「そのボタンアイコンの意味がわからない（理解できない）から押せなかった」可能性もあります。さらに、「ボタンアイコンに気付いて、意味を理解した」にもかかわらず、「ボタンアイコンが小さすぎて物理的に押せない」こともあります。このように「気付いたか」「わかるか（理解できるか）」「使えるか（この場合は押せるか）」を段階的に分けて観察するのがよいと思います。場合によっては、ユーザーがこれらの判断と操作を一瞬で行ってしまうこともあるので、その場合は後からヒアリングして問題を分解することが必要と考えます。
「ボタンアイコンを押して次の画面を表示できないこと」は「三段階のうちの何らかの問題により、ボタンアイコンを押すことができなかった結果、次の画面を表示できない」という位置付けになります。「アプリを使えないこと」は、個々のユーザビリティ問題の抽出を行うには、課題設定として漠然としてしまいます。
また、三段階の三つ目の「使えるか」という言葉は様々な意味に捉えることができてしまうので、混乱の基とも言えます。例えば、「ボタンを押せるか」「ふたを開けられるか」「〇〇を取り出せるか」という具体的な言葉にした方がスムーズにテスト設計できると考えます。
＜お悩み３－２：専門家からのアドバイス①＞
社内でユーザーに近い方を探し，インタビュー等に協力していただくのはどうでしょうか。飲み物やお菓子など，ちょっとしたモノを謝礼として用意し，30分から1時間程度なら，協力してくれる方はいらっしゃると思います。
＜お悩み３－２：専門家からのアドバイス②＞
■ 社内や社外の協力者で、ユーザー調査(ゲリラ調査)を実施してみてはいかがでしょうか
調査にかける費用がない場合には、ターゲットユーザー層の社内関係者や自分の社外の関係者(家族、友達)に協力を仰ぐゲリラ調査を行うことがあります。ご質問者のケースもゲリラ調査が使えると思います。
＜お悩み３－２：専門家からのアドバイス③＞
複数のペルソナの情報が不十分であるために、この先の開発で発生するリスクがどの程度かにより、予算がない中でも調査をすべきと説得するのか、ある情報で進めるのか判断します。
自分は調査をしたから必ず課題に対する解が見つかる可能性は高くないと考え、まずは今ある情報の中で解決案を作成し、プロトタイプを作るか実装をして、ユーザビリティ評価をしてしまいます。
その評価の後にインタビューをするなどして、調査とは言わずに必要な情報を可能な範囲で集めて判断材料にする、といったアプローチを取ります。
ユーザビリティ評価さえできないのであれば、リリース後に調査をし、改善をする、という方法を撮ることもあります。
＜お悩み３－２：専門家からのアドバイス④＞
Google Analyticsを入れましょう。そして参照元別ページビューなどでペルソナを作り上げましょう。ボトルネックになっている個所を判定するには仮説を立ててシーケンス分析も効果的だと思います。UXのユーザー理解のツールとしてもGoogle Analyticsは活用でで、実際に弊社ではメディアサイトでの実績があります。
＜お悩み３－２：専門家からのアドバイス⑤＞
ペルソナをどこまで細かく作ったところで、ECでの購入意思決定のプロセスまでは描けないと思います。
・ユーサーがどの様に商品を選び
・ユーザーがどの様に商品を比較見当し
・ユーザーがどの様に購入を確定する
な上記の様な詳細な購入プロセスの洗い出しは、スカベンジャーハントではなく、オープンタスクのUTを行ったり、デプスインタビューを行う必要があると考えます。
UXDはあくまでも仮説立案のプロセスの一つです、ROIをしっかりと定め、許されるコストの中で効果的な仮説立案を行うべきと考えます。
コストが無いのであれば、サイトの定量分析からファネル分析を行い、改修プランのMVPを決めるのも一つの手だと思います。
売上目処が立たないサービスに、数百万もかけて仮説を立てるよりは、Lean UXの視点でグロースさせることを優先させるが重要かと思います。
＜お悩み３－２：専門家からのアドバイス⑥＞
もし、調査を外注する費用はないが、質問者様自身が動くだけの費用（時間）は確保できる、ということであれば、社内や知人、友人などから残りのペルソナに近いような属性のひとを探してヒアリングをする、といった方法は取れないでしょうか。
ヒアリングの人数が少ないとペルソナ可視化の精度は落ちるでしょうが、それでも実際のユーザーになり得る人の声を聞くのと聞かないのとでは大きな違いがあると思います。プロジェクトを進めていくと、そのときヒアリングした人の顔なりコメントなりが浮かんできて、プロジェクトメンバー内でペルソナをよりリアルに感じられるようになる、といった効果は小さくないと考えます。
＜お悩み３－２：専門家からのアドバイス⑦＞
最初に上司の方は自分の発言に論理矛盾があることに気づかれていない。その時点で私も退職すると思います。でも、仕事の場合はそういった理不尽は切りがないので頑張ってください。
さて、ペルソナが４人もいることが気になります。その４人に優先度はありませんか？購入プロセスが分からないことが致命的になる程の差があるペルソナを４人も対象にしている時点で、かなり無理があるかと思いました。（具体的内容がわからないので何とも言えませんが）
他の専門家には非難されるかもしれませんが、無いところは想像で補い。所謂「ゴム人間」的なペルソナを仮説として定義し、もし仮説が真ならば、ということでサービス立案と試作品を作成することはあります。この方法に価値があるか？ 分からないところは分からないとして”仮説”として置き、とにかくプロセスとして先に進む。そして、早期に良い失敗を沢山洗い出す。失敗の原因を分析する・・・といった方法もあると思います。このようにまず先に進むことを優先することで、絶対失敗はしますが何が失敗して何は取り越し苦労だったかの判定はできます。つまり、失敗という事実が現象化した対象のみに対処をすることで、効率的に開発を進めます、この方法のコツは、絶対失敗するので、極力リソース（時間、予算、工数）はかけないこと。目的意識を持つこと。発想の転換をする点は２点です。１．失敗しないように進める方法から、失敗を直す方法に変える。早期にリスクの少ない方法で後に役立つ失敗を多くして直すことでクオリティを上げる方法も世の中にはある。 ２．手段ではなく、目的に意識を向ける。今回の場合、購入プロセスが分かることは目的ではなく、スムーズに購入に至る道筋を得ることが目的。だとすると手段は他にもあるとは思いませんか？
＜お悩み３－３：専門家からのアドバイス①＞
CJMをどこまでの粒度で制作するのかによりますが、ユーザーストーリーマッピングは、ユーザーにとっては１つのタスク（例えばメールを送る）だとしても、分解すると「新規の宛先に送る」「アドレス帳の宛先に送る」「返信で送る」。。。。のように細分化され、その細分化したタスクは更に深さも異なる場合があります。この様な多岐に及ぶユーザーのシナリオを、抜け漏れ無く洗い出すために利用すると効果的とされています。
CJMは大きな体験動線を語る際に利用して、詳細な機能への落とし込みの際に、細分化する必要があると感じた際に、部分的なユーザーストーリーにマッピングするなど、使い分けをしてみては如何でしょうか？
＜お悩み３－３：専門家からのアドバイス②＞
ユーザーストーリーマッピングは，ビジネス側と開発側の認識合わせを行うのに有効であり，その手段として活用するものと考えています。現状のやり方で既に同等のことができているのであれば，あえて作る必要はないと思います。
＜お悩み３－３：専門家からのアドバイス③＞
「カスタマージャーニーマップ」は、簡単に言ってしまえば、シナリオ（具体的に場面設定・登場人物設定をして、時系列に操作内容などを追っていく）＋そのときの感情を表現するもので、一方、「ユーザーストーリーマッピング」は、ストーリー(ユーザーにとっての価値)を、ユーザーの体験順に時系列で左右に整理、似た機能は上下に整理してマッピングしていく手法です。二次元の表に整理することでストーリーの抜け漏れに気づくことができるだけでなく、会話を通してプロダクトオーナーがストーリーに込めた思いを理解することができたり、複数のストーリーを分割する線を左右に引くことでリリース計画を表現することもできます。
いずれも、ユーザーの時間軸で記述するという点では同じですが、ユーザーストーリーマップは、優先度も考慮して並べます。すなわち、カスタマージャーニーマップはユーザーの要求獲得場面を抽出し、ユーザーストーリーマッピングでは、要求の優先順位付けを行う、ということかと。
開発対象のサービスの仕様としてどこまでを具備するかの優先順位を付けるのであれば、時間的余裕があれば、ユーザーストーリーマッピングまで作成してみてもよろしいかと思います。
＜お悩み３－３：専門家からのアドバイス④＞
■ 基本的には変わらないものであり、ユーザーストーリーマッピング作成は不要と思います
ご質問者のご理解の通り、カスタマージャーニーマップもユーザーストーリーマップも基本的には目的は同じです。違いは、読者ぐらいと考えています。(手法の背景もありますが)
カスタマージャーニーマップは主にビジネス設計のフェーズで、複合的なサービスを束ね、ユーザーの観点での見える化することが主な目的のため、読者は事業開発の関係者です。一方、ユーザーストーリーマップはアプリ開発フェーズで、主に一つのサービスに関するユーザーの観点での見える化であり、読者はアプリの設計・開発者です。そのため、ビジネスの規模により、カスタマージャーニーマップとユーザーストーリーマップは同じこともあります。(小規模、もしくはスタートアップの場合)
上記を踏まえると、ご質問者のカスタマージャーニーマップは、おそらくユーザーストーリーマップまで細かくしたマップを作成していると思います。そのため、ユーザーストーリーマッピングは不要と考えます。
＜お悩み３－３：専門家からのアドバイス⑤＞
エンドユーザの体験を時間軸で整理するという点では共通性があるが、視点・観点が異なると理解しています。
CJMは、ユーザの体験の流れ（特に情緒的変化・メンタル面）を表現するツール。つまり視点はユーザにある。対してUSMは、提供価値の流れ（特にファンクション・フューチャー的変化・UIなど客観的確認ができる変化）を表現するツール。つまり視点は価値提供者・開発者にある。ので、同じことを対に表現するのだと認識しています。価値提供の流れをUSMで、それを受容したユーザの情緒的変化をCJMで表現する。
次に、USMが必要でしょうか？という問いに対しては、現状困っていないならば必要ない。というのが（身も蓋もない答えですが）私の回答です。想像でしかないですが、開発規模が小さい、または開発対象が複雑ではない、またはとても良き理解者のソフトエンジニアと仕事をされていると察しました。複雑な大規模開発で1000人単位のチームが幾つもあり、関係する人とバックグラウンドが全然違って会話の共通基盤がない、といった場合には、CJMのような実現手段で書かれていない表現を使っても「つまりは何を作ればいいの」と言われてしまいます。USMを含め開発者視点で開発対象を整理し、開発段取りと進捗を見える化の必要を感じたとき、USMを書いてみてはいかがでしょうか？
これは参考ですが、私は千葉工大の山崎先生が開発された「エクスペリエンスビジョン（エビシート）」の手法が好きです。これだと、CJMもUSMも兼ねて表現することができます。
４）その他 ＜相談件数３件＞
＜お悩み４－１：専門家からのアドバイス①＞
質問者が受けているオーダーは品質管理に属すると思います。
WEBサイトであれば「リリース判定」などになると思います。
これは、おっしゃる通りUTでは決められません。
予め、サービスとして最低限担保しなければ行けない項目と基準を設け、それを満たしているかの各人を行う必要があります。
項目と基準は、そのサービス毎に異なるので、一概には言えませんが、UXデザイナーが一人で決めるものでは無いと考えます。
最終的にはビジネスオーナーの承認が必要となる事項かと思います。
＜お悩み４－１：専門家からのアドバイス②＞
■ 出荷可能時の品質の定義・方針を確認してみてはいかがでしょうか
この手の場合には顧客が求めているユーザーテストとUXデザインコンサルティングでのユーザーテストには、ギャップがあることがあります。
また、出荷しても問題ないことを担保したいのであれば、要件定義時点で、出荷しても問題ないという品質の定義が必要です。
この定義の基づいて、品質への方針を定めます。(バグへの許容、設計時の優先順位)
仮にこの定義が曖昧なままで、エキスパートレビューを行っても、目的が不明瞭なため、あまり意味がないケースが散見されます。
この手の話を受ける場合には、要件定義時点で、出荷しても問題ないという品質の定義を確認することから初めてはいかがでしょうか。
＜お悩み４－１：専門家からのアドバイス③＞
ユーザビリティの問題がないことを担保したい、というご要望だとすると、それに応えるのは難しいのかなと思います。致命的な問題が出なくなるまでユーザーテストを実施するとか、ユーザーテストの結果で満足度が何％以上となったら合格とするなど、基準を設けて試行し、最適な方法を見つけるのが良いかと思います。
＜お悩み４－１：専門家からのアドバイス④＞
相談者様も承知しているとは思いますが、結論から申し上げて、“問題がないことを確認”できるテストは存在しないと言わざるを得ません。厳密に言えば、どんなテストをしても、その結果として確実にいえることは、“テストした項目については問題なかった”ということであって、“100%すべての問題をクリアして、もうどんな問題も残っていない”というとまでは言い切れません。
ですので、（あくまでもコスト（時間、費用）的に可能であれば）複数のテストを実施して、網羅性を高める、ということしかないと思われます。
＜お悩み４－１：専門家からのアドバイス⑤＞
ユーザビリティテストが問題がないことの確認には向かない、という認識はそのとおりだと思いますが、どうしてもやりたい、ということであれば実施するしかないかと思います。
その際、すべての操作においてユーザビリティテストで確認するのは現実的ではないと思いますので、品質を担保したい主なルートのいくつかにテスト対象を絞り、仮に何か問題が発生した場合の対応（修正要否の判断や、いつ修正するかなど）の手順を事前にクライアント様と握った上で実施する、など、品質担保の条件を事前に決めておく必要があるかと思います。
大丈夫とわかっているルートでも、何が起こるかわからないのがユーザビリティテストですので。
＜お悩み４－１：専門家からのアドバイス⑥＞
ユーザビリティの有効さ・効率性・満足度を計測して報告書化してはどうでしょうか。有効さは課題の達成度、効率性はかかったコスト（時間や手順、資源など）、満足度は主観的な評価（5段階やSUSと呼ばれるスケール）です。国際標準規格ISO/IEC 25062は、ユーザビリティテストの実施結果を記述するための標準書式であるCIF（Common Industry Format）という報告書があり、HCDのセミナーでも取り上げられた実績があります。https://www.hcdnet.org/hcd/event/post_64.html.CIFは計測して統計的検定を求めてきます。なのでユーザビリティ評価に参加してもらう人の人数も多くなると思います（ウェブサービスならオンラインテストなどで多く集められるかも）。ユーザビリティは人を物差しとして計測するにもかかわらず統計的検定を求めてくるのがこの報告書の大変なところであり、価値のあるところです。「問題がないことを担保する」には膨大なコストがかかることをクライアント様が理解してもらい、それだけの時間とコストをもらえるといいですね。調査方法は一般的な課題提示型のユーザビリティテストで十分です。その際にギブアップも加えていくことで有効さを計測できます。CIFに関してはNECの福住さまの論文でも取り上げられています。「https://www.jstage.jst.go.jp/article/jje/52/Supplement/52_S112/_pdf」
＜お悩み４－１：専門家からのアドバイス⑦＞
ユーザビリティテストはおっしゃる通り問題発見のためには有効ですが、既に問題点を全て解決してしまった機器やアプリについてテストを行う場合には有効ではありません。「品質の確保」「出荷判定の根拠」ということであれば、その機器やサービスは設定した仕様通りに出来上がっている状態だと思います。仕様通りに出来上がっているということは、想定しているユーザー操作もすべて書き出すことができるはずです。想定しているユーザー操作をすべて書き出し、その機器、アプリをその表の通りに操作し、すべてに〇を付けることができれば、「品質の確保」がされていることを証明できる書類として、「出荷判定の根拠」になると思います。
＜お悩み４－１：専門家からのアドバイス⑧＞
そのユーザビリティの問題をそのままにして出荷した場合に、どんな影響があるのかの程度をどう見積もるのかによります。
一般的な基準を期待されているのであらばCIF(ISO/IEC25062:2006)を参考に、〇〇人でテストをした結果、何％以上の人で問題が出なかった、という評価結果をレポートするのが１つのアプローチです。
出荷をして問題がないか、という基準は製品を出す側が決めるべきことですが、その基準を決めるプロセスをお手伝いできるとコンサルティングとしては、一段上の業務になると思います。
例えばハードウェアの商品を想定すると、初期設定が完了できずその製品を使い始めることができない、という有効さの問題が発生するとクレームや返品になるという影響が想定でき、そこにはコスト発生します。その発生確率がテストにより概算できれば、許容範囲が見積もれます。
また、使うの時間がかかる問題があり、出荷までに改善できないとしても、そのことにより、使うのをやめてしまうほどではない、とすれば出荷した後にソフトのアップデートで改善する、という判断もありえます。
健診機関が受診者と健康診断についてコミュニケーションをとれるサービスを作っています。健診機関はWEBツールをつかって受診者アプリにコンタクトをとったり、健診結果をアップしたりします。このWEBツールとサービス全体の体験について、健診機関の満足度を計測し改善につなげていきたいと思っています。NPSを考えたのですが、このサービスは業界がマニアックなので比較対象があまりできないことと、NPSはその理由がわからないため改善につなげていくなら他のアンケートと一緒に行わなくてはならず、結局NPSの良さ（1つの設問で楽）が失われるとおもい他の手段を探したいと思っています。とくにtoB向けサービスで顧客満足度など測れるおススメの手段はありますでしょうか。よろしくお願いいたします。
＜お悩み４－２：専門家からのアドバイス①＞
"NPSのメリット
・採用しているサービスが多いので比較しやすい。
・設問が少ないので、回答率が比較的高い。
・満足度が数値化されるので、成長度合いを図りやすい。
などが現状サービスで享受でき無いのであれば、
通常のアンケートを調査したい機能毎に用意して、
実施する形が妥当な選択肢と思われます。"
＜お悩み４－２：専門家からのアドバイス②＞
B to Bに特化した満足度調査というのは，特にコレというのは無いかと思います。単純に5段階評価でつけてもらい，その理由もあわせて問うのが，最もシンプルで測りやすいのではないでしょうか。
SUS(System Usability Scale)を使う手段もありますが，業務システムを対象にすると，経験上高くでも60前後となり，それ程高い満足度は得られませんでした。ただ，その際は点数はあくまでも参考であり，その点数となった要因を詳しく調べることを重視しました。NPSを使う場合も同様で，その点数と判断した理由を問うことが大事だと思います。
＜お悩み４－２：専門家からのアドバイス③＞
■ 定期的な満足度検証で、自社サービス用の指標を作られてはいかがでしょうか
※ 質問者の置かれている状況が不明なため、理想的な方法ではどうするかという観点で回答致します。
WEBアプリ・サービスの定期的な検証としてアンケートによる満足度調査が目的であれば、質問者の理解の通り何かしらの指標が必要になります。自社で作ってみてはいかがでしょうか。特殊な業界とのことですが、基本的な指標の作り方は変わらないと考えています。
一度WEBアプリ・WEBサービスのアンケートとUXやユーザビリティの調査を行い、そこでの満足度に関する気づきを一旦の指標として設定してみてください。設定したかといって終わりにせず、定期的に調査を実施し、指標をブラッシュアップしてみると、自社のサービスに応じた注目すべき指標やナレッジがたまり効果的と思われます。また、特殊な業界であることを逆手にとり、どこかの検診機関の作業風景の観察やインタビューができると、さらに踏み込んだものになるかと思います。
＜お悩み４－２：専門家からのアドバイス④＞
そもそもの話で申し訳ありませんが、顧客満足度を測る理由は何でしょうか？文中に「改善」とあるので、改善点を知るためかと察しました。顧客満足度調査が、具体的な改善点と改善方針を知る手段として適切だと思われているのでしょうか？限られた文面で十分な理解ではないかもしれませんが、得たい事と求めている手段の不一致を感じます。
検診機関のご担当者様が実務を遂行する際、ご担当者様の満足度が高ければ相談者様の製品の評価が上がり、事業貢献する、と考えられたと察します。この場合の満足度というのは具体的には何だとお考えでしょうか？または、満足度に対する支配的影響要因は何だとお考えでしょうか？
私は、「使いやすさ」「効率性」「リスク回避」かと思いました。つまり（今流行の事ではなく、地味で古臭いかもしれませんが）実直なユーザビリティの向上が必要だと考えます。顧客満足度調査ではなく、所謂ユーザビリティテスト。ISOに定義されているHCDプロセスの実行が最も適切な手段の選択だと考えます。
「健診機関の満足度を計測し改善につなげていきたいと思っています。」のこの一文が誤解で、満足度を測っても改善点は見つかりません。100歩譲ってご担当者様の声（不満点）を拾えたとしても、その声を信じ言われたとおりに直しても製品は良くなることは少ないです。なぜならば、エンドユーザは「なりたい状態、それと現状との差分」は話してくれますが、なりたい状態への達成手段は話せません。例えば。病人は「お腹が痛い」と症状は話せますが、腹痛を解決する手段は正確にわかるはずがないです。素人考えが通用して病気が適切に判断できるならば、医者は必要ないですから。この構造と同じです。改善とは、製品にとっての病名が分かり適切な治療方法を選択し、実行し、処置結果の確認が必要な行為です。これがHCDプロセスです。
真の原因と真にご担当者様にとって良い状態を専門家として正しく定義し、その姿を達成するために改善を繰り返さないと”改善”にはならないと考えます。
＜お悩み４－３：専門家からのアドバイス①＞
（HCDというお題ではない勉強会での例ですが、）
・書籍（例えば『HCDライブラリー（0巻～3巻、7巻）』）の輪読
・論文（例えば、HCD研究発表会のもの）の輪読
・ワークショップ形式での実践
＜お悩み４－３：専門家からのアドバイス②＞
座学だけではなく，体験してもらうことで，より習得しやすくなると考えています。私が実施する講習では，ペルソナやカスタマージャニーマップを作成する演習を含めていますが，受講者から「理解が進んだ」や「実践につなげられそう」と，好意的なフィードバックをいただいてます。
＜お悩み４－３：専門家からのアドバイス③＞
■ 受講者の目的に応じて、研修計画、メニュー、研修資料等を準備していました
受講者の目的に応じた研修計画、メニュー(※)、研修資料を準備していました。
最初のころは、全てを用意できないため、数々のプロジェクトでネタを貯めました。
擬似プロジェクト実施時には、受講生と講師の成果物を比較し、どの程度のレベルであるかなどのフィードバックもやっていました。
※ 座学(基本知識)と疑似プロジェクト(ケーススタディ)と実プロジェクト
また、社内に研修設計のエキスパートもいなかったため、本を参考に研修を立案・実施・改善していました。
＜お悩み４－３：専門家からのアドバイス④＞
ざっくりしていて、お答えしづらいです。
どの様なHCDプロセスの勉強会を開きたいのでしょうか？
HCDの必要性を教えたいのか？一部のプロセスに特化して説明したいのか？
内容によって、講義の内容も変える必要があります。
