(5ページ目)

ユーザー ✕ 検証

に関する学び

---

課題を明確にできた？ IRコンサルティング業務では、これまでお客様の課題を明確な言葉で定義していなかったため、今回学んだ手法を通じて、お客様の状況や課題を整理できたと感じています。また、カスタマージャーニーはBtoB事業においても十分に活用できると実感しており、早速試してみたいと思います。 実践はどう進む？ 実践については、４週目以降に取り組む予定です。お客様の課題を言語化することで、認識のずれが減少し、提案の精度が向上すると考えています。同時に、BtoBにカスタマージャーニーを適用することで、意思決定プロセスが可視化され、より効果的なコンサルティングが期待できると感じました。 分析法は何が鍵？ また、以下の点にも留意しながら進めます。まず、定性分析は仮説の立案を目的とし、定量分析はその仮説の検証を目的とします。定性分析では、コーディングによってデータを1次コードから3次コードへと分類し、体系的に整理します。さらに、ユーザーの暗黙知を把握するためには観察を、形式知を引き出すためにはインタビューを実施し、それぞれを適切に使い分けることが重要です。最後に、ペルソナを具体的に設定し、カスタマージャーニーを描くことで、実践的な分析を目指していきます。

フィードバックの意義は？ ユーザーやメンバーからのフィードバックが、製品やサービスのブラッシュアップに大いに寄与し、ひいては新たなアイデアの創出に繋がるという点が非常に印象的でした。現状では、製品開発において構造や機能の検証は行われるものの、人間中心の視点でユーザーの共感や意見を十分に取り入れる場面が少なく、チームで意見交換を行うことが新たな開発のヒントとなると感じました。 SCAMPER法の効果は？ また、SCAMPER法の7つの視点を実際に活用することで、その効果が実感できるという点も参考になりました。さらに、初めて知ったストーリーボードは、ユーザーの価値ある体験を物語形式で視覚化する手法として理解が深まり、大変有益でした。 ペルソナ設定はどう？ この学びを通じて、エンドユーザーを具体的にイメージするためにペルソナを明確に設定すること、そしてエンドユーザーにとっての価値（バリュープロポジション）を中心に考えることの重要性を再認識しました。加えて、開発チーム内でSCAMPER法やダブルダイヤモンドの手法を取り入れ、ユーザーからのフィードバックを効果的に得られる仕組みを構築することが、今後の製品開発に大いに役立つと感じました。

どうしてデザイン思考？ ライブ授業の録画を視聴して感じたのは、従来のロジカルシンキングだけでは達成し得なかったイノベーションを、デザイン思考で実現できるのではないかという期待です。特に、ユーザーが抱える潜在的な課題を見える化することで、本質的な課題が明確になるという点に大きな意義を感じました。 どうして顧客不在？ また、結果を出せない組織には「顧客（ユーザー）不在」という共通点があると感じています。私の職場では、新しい企画を提案すると「予算は？」「担当は誰が？」、「上層部が賛同しない」といった否定的な意見が次々と出され、そのために改革が進んでいない現状です。厳しい状況下で経営層を巻き込むのは難しいですが、自らの業務の中で「ユーザーは誰か」「どのような喜びを提供できるか」「どんな困りごとがあるのか」を常に意識することが、デザイン思考を活かす第一歩だと考えています。 プロトタイプの効果は？ 当面は、自分の担当業務の範囲内でデザイン思考のプロセスを実践していこうと思います。特に、プロトタイプを用いた検証プロセスは、試行錯誤を通じて小さな失敗から学ぶ大きな醍醐味だと感じており、これを繰り返すことで改善を図っていく所存です。

原因分析はどう進める？ 原因の分析にあたっては、まずプロセスごとに分解し、確認することが大切だと感じました。特に「what／where／why／how」を意識し、まず「where」から入念に分析することで、その後の「why」や「how」の解像度が高まると理解しています。 A/Bテストってどうやる？ また、A/Bテストが有効な手法であることを学びました。その際、検証する「要素」は極力少なくし、その他の条件は共通とすることで、スコープを狭めることが重要だと感じました。実際にアプリ上でプッシュ通知とバナーを用いたA/Bテストを実施した経験から、振り返ると「キーメッセージ」に差が生じてしまった点が課題として残りました。 ログイン改善は何が？ さらに、アプリのログイン率向上を図るため、ログインに至るフローを細かく分解し、原因の追究を行いたいと考えています。特に、パスワード設定の箇所で離脱するユーザーが多いという仮説に基づき、検証からスタートする予定です。その後の改善策として、ユーザーインタビューやUIテストの実施を検討しています。

共感ってどう大切？ 共感の大切さが一番印象に残りました。ユーザーの動作や発言に注目し、彼らの立場から本質的な課題を捉える観察力が必要だと感じました。また、誰がどのような状況でどんな課題に直面しているのかを明確にし、仮説に基づいた解決策を提供することの重要性も実感しました。 営業はどう変わる？ BtoB向けの営業プロセスでは、自社商品やサービスの提供に留まらず、まずユーザーの課題を把握することが基本です。ユーザーの課題を観察し、仮説を立てながら顧客との検証を繰り返すことで、まだ気づかれていない本質的な問題にも気付くことができ、その結果、より効果的な営業活動（インサイト営業）につなげることができると感じました。 課題共有は必要？ また、商談前に課題を共有する活動の重要性も印象に残りました。普段の業務においては、顧客サーベイやチームでのブレインストーミングを通じ、ユーザー視点の仮説を多々収集しています。その後、実際の検証結果をもとに、各メンバーが顧客との面談時の特性や仮説の内容を共有し、より質の高い対応策の検討へとつなげています。

データの見せ方は？ 分析の基本は比較であり、どのデータをどのように加工するとわかりやすいかを考えながら進めることが重要です。データにはさまざまな種類があり、それぞれに応じた加工やグラフの見せ方があります。データ分析を始めるにあたっては、「目的」の確認や「仮説」の設定とその検証が欠かせません。 オンライン離脱はなぜ？ 私たちのチームでは、お客様に対して紙の手続きではなく、ウェブサイトでのオンライン手続きを推奨しています。しかし、オンライン手続きを行っているお客様がどの段階で離脱しているのか、また、紙を取り寄せるお客様の属性や動機がどのようなものかを理解し、分析する必要があります。 改善点の見極めは？ 具体的には、オンラインで離脱しているページやそのユーザーの属性、さらに紙手続きを行っている方々の属性や動機に関するデータを収集し、オンライン手続き率を向上させるためのボトルネックを特定することが目指すべきゴールです。仮説を立てながら慎重にデータを分析し、検証するプロセスを通じて、この課題に取り組んでいきたいと思っています。

どうやって原因究明？ 原因を特定するためには、分析対象を複数のプロセスに分解し、各段階で明確な問題箇所を探ることが重要です。人の行動に即したプロセス設定を行うと、問題の箇所が特定された後の改善策の検討もスムーズに進むことが分かりました。 なぜ事前に決定すべき？ また、What、Where、Why、Howといった基本的なステップと同様に、プロセスの設定も仮説検証に入る前に決め、その内容を関係者間でしっかりとすり合わせる必要があります。たとえば観光客の減少の原因を探る場合、ユーザーがどのように情報を収集し観光地を選んでいるかというプロセスと、現状で手に入っているデータがどの段階で取得されたものかを突き合わせることが求められます。 データ整理の要点は？ さらに現状分析においては、最初に幅広いデータを集めることが大切です。各データが持つ性質や項目、定義について周知するとともに、ファネルに沿ってデータの分類や分析を進め、必要なデータの補完を行うといった段階的な準備が成功の鍵となります。

A/Bテストの条件は？ A/Bテストを行う際には、条件を揃えることや分析対象を明確にすること、そして仮説に基づいた比較検証のポイントを絞ることの重要性を確認できました。また、課題解決に向けた顧客心理に着目したテキストや、ユーザーが行動しやすい要素が重要であると実感しました。 ファネル分析の重要性は？ 日々のウェブマーケティング業務において、今回の課題事例から多方面で役立つ考え方を学ぶことができました。特にファネル分析は不可欠であり、全体のマーケティング戦略を踏まえた上で確実に設定し、日々の分析に活用していきたいと感じています。 新たな仮説はどう導く？ 今後は、売り上げ向上を目指すサイト改善や広告のA/Bテストにこれらの知見を活かしていくとともに、単一のデータに頼るのではなく、関連する複数のデータを俯瞰的に捉え、そこから新たな仮説を導き出す取り組みを深めていきたいと思います。

多様な視点が見えた？ 同じテーマについて多様な視点が存在することを学びました。ユーザー目線で現状の仕組みが本当に適切かどうか検証する過程で、各メンバーが異なる観点から意見を述べるのが非常に印象的でした。また、デザイン思考に関しても、参加者それぞれの想いが交わり、ディスカッションが盛り上がった点がとても興味深かったです。 現状をどう問い直す？ 現状に疑問を持つことの重要性を実感しました。従来の方法や制度がただ続いている理由だけで運用されている場合、それをユーザー目線で見直し、より使いやすい形に改善する必要があります。まずは現行制度の確認と再検討を行い、実際に受けた問い合わせや相談内容を反映させながら問題定義を進めることが大切です。さらに、可能な範囲で改善策を検討し、ロジックツリーなどの手法を用いて試行錯誤を重ねるプロセスが印象に残りました。