(3ページ目)

ユーザー ✕ 設定

に関する学び

---

ファネル分析はどう？ 問題の原因を明確にするためには、取り組みを各プロセスに分解し、それぞれのプロセスを確認することが有効です。特にファネル分析は、ユーザーの利用段階を「注目」「興味」「欲求」「行動」などのプロセスに分け、どの段階でユーザーが離脱しているかを可視化する手法です。ファネル分析には、ファネルそのもの、横棒グラフ、プロセス×ウォーターフォールなどのチャートがあります。この分析を行う際のコツとしては、顧客の行動プロセスを適切に設定し、「実数」と「比率」のバランスを重視することが挙げられます。原因を一つに特定しすぎず、ある程度方向性が決まれば仮説に基づいてABテストなどで検証し、必要があれば仮説を修正していくことも重要です。 募集プロセスはどう？ 生徒募集活動においては、「学校の存在を知る」「学校に興味を持つ」「学校説明会・個別相談会を申し込む」「実際に参加する」「出願する」「入学する」というプロセスを通じてファネル分析を行います。それぞれのプロセスでの人数の実数と比率をチャートとしてまとめ、問題があり優先して取り組むべきプロセスを特定します。 事例調査はどう？ 具体的な取り組みとしては、まずファネル分析事例を検索して、できるだけ多くの事例、特に学校法人の事例を調査します。そして、入試広報部から昨年度の生徒募集活動の各プロセスのデータを入手し、ファネル分析を行います。その際は、実数と比率の両方でチャートを作成します。最終的に、分析結果を入試広報部と共有し、問題のあるプロセスについて共通認識を持ち、改善策の検討を進めます。

なぜ業務量に差が生じた？ 現在の業務は減少せず、同じ部署内で担当する業務量に大きな差があるという課題を感じています。この状況について、なぜそのような事態になっているのかを定性分析を用いて仮説を立て、解決に向かわせる方法を考えました。インタビューなどを通じ、単なる業務量だけでなく、その背後にある問題点を明らかにする必要があると考えています。 アンケートから何が分かる？ 今回の演習で気づいたのは、アンケートの結果から、経験や年代にかかわらず共通の課題が存在することが分かった点です。この結果は、データをコーディングすることで抽出されたものです。しかし、実際に対処するデータは今回のものよりも複雑で量も多くなるため、分析の難易度は大幅に上がると感じました。また、課題設定において、単に現状の課題を把握するだけでなく、その課題があることによってユーザーがどのような回避行動をとるのかという視点を加えるという新たな発想も得られました。回避行動も一つの課題として捉え、解決策を検討することが求められると学びました。 定性分析で何が見えた？ さらに、分析手法として定量分析と定性分析が存在し、特に仮説の構築が重要であることを再認識しました。定性分析は仮説構築に大いに役立つという新たな気づきも得られました。分析結果から浮かび上がった問題について、もし解決が進まなかった場合の条件を設定し、さらに課題を掘り下げる手法も有効であると感じました。なお、解決策を前提にして課題を定義しないという点についても、常に意識して取り組む必要があると理解しました。

チームの問いはどう？ 今週のライブ授業で印象に残ったのは、「同じチーム内でも立場が異なれば問いが変わる。しかしながら、互いにすり合わせることでチーム全体の利益になる問いに立て直すことができる」という点でした。前提や求めるものが異なる場合でも、共通のゴールを目指す問いを立てる考え方は、ビジネスはもちろん、プライベートにも応用できる大切な視点だと感じました。 本当の問題は？ サービスや施策の企画段階では、まず「本当に解くべき問題か」や「目的と問いに整合性があるか」を確認します。背景や目的、制約条件を整理し、関係者間で課題認識を一致させることが重要です。必要な場合は、課題の再定義を行ってから企画に入るといったプロセスが求められます。 なぜ問いから始める？ また、社内外の関係者とのディスカッションでは、解決策に飛びつくのではなく、まず「問い」から議論を始める姿勢が大切です。事実と解釈を明確に分け、ユーザー視点と事業視点の双方から多角的に問題を掘り下げることで、質の高い合意形成が図れると実感しました。 顧客の真意は？ さらに、顧客インサイトの見極めにおいては、相手の視点に立ってニーズや不明点の背景を探る必要があります。相手が本当に求めていることを引き出すため、質問の工夫を重ねることで、表面的ではなく本質的な課題意識にたどり着くことができるでしょう。これらのプロセスを継続することで、課題設定の精度が向上し、プロジェクトの迷走や手戻りを減らし、最終的なアウトプットの質も高められると感じました。

VUCA時代のAI活用は？ VUCA時代では、求められる方向や距離、形が常に変化していくため、仮説と検証のサイクルを何度も繰り返しながら、AIを効果的に活用する必要性が高まっています。具体的には、①AIを理解する（実際に使ってみる）、②生活に組み込むための試行、③クリティカルシンキングや各種フレームワークを通して思考力を高める、というステップが重要です。 プロトタイピングの流れは？ また、AI活用においてはプロトタイピングが欠かせません。まずは、目的や要件を明確にし、アイディアの収集や問題点、課題を洗い出します。次に、有望なアイディアを選定し、プロトタイプを作成します。その後、ユーザーテストやフィードバックを通じて改善点や要求事項を整理し、次のバージョンのプロトタイプ作成へと進めます。 仮説検証で成果は？ さらに、仮説を立て検証するサイクルは、仕事における検証マインドの向上に大いに寄与します。仮説は結論型と問題解決型があり、特に問題解決型は「what」「where」「why」「how」の観点から構築します。このプロセスを正しく実践することで、説得力だけでなく、業務のスピードや精度も向上します。 受講生の意見はどう？ 私自身は、week2のコンテンツにおいて、VUCA時代におけるAI活用方法、プロトタイピング、仮説設定と検証がどのようにつながっているのかを実感しました。他の受講生がどのようなAIの活用事例を生活に取り入れているのか、お互いの考えを共有しながら学びを深めていきたいと感じています。

リサーチの必要性は？ ある企業の開発事例から、まずリサーチ段階で潜在的なニーズを見つけることの重要性を学びました。真のニーズを引き出すためには、デプスインタビューやカスタマージャーニーの詳細な分析など、緻密な作業が必要であることが印象に残りました。 ニーズと強みはどう？ 商品開発の段階では、潜在ニーズと自社の強みを掛け合わせることで相乗効果が期待できると感じました。同時に、消費者がどのようなブランドイメージを期待しているのかという視点を取り入れる必要があると気づかされました。特にネーミングに関しては、開発側が届けたいイメージよりも、消費者が直感的にイメージできる言葉が求められると考えました。 調査手法はどう？ さらに、カスタマージャーニーのリサーチをより丁寧に行う必要性も感じました。過去のユーザーを数名ピックアップし、デプスインタビューを実施して真のニーズを明らかにすることや、業界サービスにおけるクライアントのペインポイントを探すことで他社との差別化を図ることが今後の課題です。 行動計画はどうする？ 具体的なアクションプランとしては、まず過去ユーザーの中から年齢層や職種ごとに3名のデプスインタビューを設定し（初めは5名から8名程度に声をかける）、次にデプスインタビューを通して転職活動に至るまでの行動背景やペインポイントについて再調査を行います。さらに、登録者が約2000名いるインスタアカウントを活用してインスタライブを実施し、ユーザーの生の声を収集していく予定です。

なぜグループにまとめ？ 仕事でお客様の会社において、事業部、部門、部署、チーム、そして個人といった多様な単位でヒアリングを実施しています。各単位で個別に課題を抽出し解決策を検討するというよりも、各々の課題をコーディングし、小グループとしてまとめる手法に取り組みました。その結果、企業全体のインサイトがより明確になったと感じています。同じ課題であっても、観る角度や背景が異なるため、捉え方に違いが生じることを実感しました。 どう問いを工夫する？ また、ヒアリングやアンケートで得られたキーワードや文章をコーディングする際には、自身の考えや先入観を持ち込まないよう注意しています。適切な問いの立て方が非常に重要で、オープンクエッションを用い「WHY」を投げかけることで、目先の要求だけでなく、根底にある不自由さや真の要求を引き出すことが可能となります。問いを設定する前に、事前調査や自身の体験を通じた共感を得ることで、相手の立場に立った一歩踏み込んだ質問ができると感じました。 なぜ共感が大切？ 事前調査や経験による共感、そしてその共感に基づく一歩踏み込んだ問い、さらにヒアリングやアンケート調査で得た定性的な結果のコーディングを通して、課題とインサイトを明確化するプロセスは、相互に連携して作用しています。深い共感があれば、より深い問いが実現し、結果としてユーザーや生活者の深層心理を引き出し、課題とインサイトの発見へと結び付くと実感しています。

仮説検証におけるフレームワークの役割 仮説を立てるための考え方について学びました。特に、3Cや4Pのフレームワークは、以前大学で学んだものの、実際の仕事では体系的に使用していませんでした。しかし、これらを意識することで仮説検証のための情報整理に役立つと感じました。 仮説A以外のデータも探すべき？ また、自分の仮説に都合の良いデータだけでなく、仮説A以外の可能性を否定するデータも収集することの重要性に気付きました。実務ではスピードが求められ、自分の仮説を証明するデータを集めがちだったので、この学びは大変有益でした。これからは、直接的なデータだけでなく、複数の切り口からデータを検証するよう心がけたいと思います。 具体的には以下の点に活用できると考えています： - **企画・施策立案** - **クライアントへの提案内容の精査**：クライアントの立場に立って仮説を複数持つことで、より効果的な提案が可能です。 - **ユーザーの動向分析**：例えば、使用率が下がっている場合の原因検証などに使えそうです。 - **目標の設定**：年間目標の設定や到達見込みの予測に活用できます。 行動前に何が大切？ 行動の前に、もっと仮説の検証やデータの収集に時間をかけることが重要だと感じました。今後は、「データを分析して仮説を立てる」という従来の手順から、「仮説を立ててデータを分析して検証する」という手順に意識を変えていきたいと思います。

営業実績の見える化の秘訣は？ 部内で営業実績を可視化するシステムを構築する際、ビジネス側がシステム設計を確認する中で、ベンダーさんがしっかりと手順を踏んで進めていたことを改めて知りました。システム構築は何となく進めていたものですが、今回の経験で、体系的に学ぶことの大切さを実感しました。 コンテンツ設計の極意は？ また、社内で公開するSharePointのページを作る際に、いきなり制作に取り掛かるのではなく、無意識のうちに行っていたコンテンツ設計の重要性に気づきました。当時は自分一人で資料上で並び替えなどを試行錯誤して使いやすい表示方法を模索していましたが、次回はチームメンバーやユーザーに評価を仰いだうえで、実際の作成に移ろうと考えています。 ユーザー受入の意義は？ システム構築の過程で、ユーザー受入テスト（UAT）も単なる操作性の確認に留めず、実際のユーザーが何を実現したいのかを意識し、情報の配置や表現方法をしっかりと検証することの大切さを改めて感じました。 試作品作りの秘訣は？ 普段は試作品を依頼する立場ですが、試作品を作る前の要件定義を十分に行うことで、より精度の高い試作品が生み出され、そこからさらにアイデアを加えてブラッシュアップできると実感しています。情報設計、UI設計、ユーザビリティ設計、アクセシビリティ設計を進めるにあたっては、ターゲットを明確に設定することが非常に重要だと感じました。

根本原因はどう探る？ 問題や課題に直面した際、それらの背景や根本のイシューを特定することが最初に、そして非常に重要であるということを学びました。イシューの特定や設定には、立場や部門の違いから様々なアプローチが考えられ、必ずしもイシューが一つではなく、複数存在することもあるという理解が深まりました。 品質不具合の真実は？ 多く発生するのは品質の問題であると考えられます。社内での問題であれば、「なぜこの不具合が発生するのか」という視点でのイシュー特定が一般的ですが、逆の視点、「なぜこの不具合が顧客から受け入れられないのか」という視点でのイシュー設定も可能であるという新しい学びを活かしたいと考えています。具体的には、この不具合が直接取引の顧客でどのような問題となるのか、さらには最終ユーザーではどのような問題となるのかという視点を取り入れれば、品質責任の負担を平準化したり、過剰スペックを是正したりすることに繋がる可能性があると感じました。 会議で何を疑問視？ 週次で開催される品質会議では、不具合に関する品質部門からの分析内容やその是正に向けた対策について、自分自身が何か疑問を持つように意識することが重要です。「何が問題か」「どこで発生するのか」「なぜ発生するのか」といった基本的な把握に加え、問題や品質がなぜ顧客に受け入れられないのか、顧客でどのような問題に繋がるのかという視点を持つことから始めていきたいと考えています。

原因はどの段階で？ 今回、問題解決のアプローチとして、最初から原因を追求するのではなく、結果に至るプロセスを段階ごとに分解し、どの段階で課題が生じているのかを特定する重要性を改めて認識しました。たとえば、表示からクリック、そして申込という流れに分けることで、どの部分で数値が低下しているのかを明確にし、原因の仮説を立てやすくなることが分かりました。 複数案はどう選ぶ？ また、解決策を検討する際には一案に絞らず、複数の案を洗い出し、判断基準を設定したうえでその重要度に基づいて評価・選択することが重要だと感じました。特に、判断基準を明確にし、重み付けを行いながら意思決定する視点は、新たな気づきとなりました。 ユーザーの動きはどう見る？ この学びは、社内サイトのアクセス解析にも活かせると考えています。具体的には、サイト流入からコンバージョンまでのユーザーの動きを、「流入数」「遷移数」「コンバージョン数」といった各段階で確認し、どの段階にボトルネックがあるのかを特定します。その上で、数値の流れを踏まえて問題箇所を絞り込み、原因の仮説を立てる手法は非常に有用だと実感しました。 改善案はどう評価？ さらに、改善案については複数の選択肢を検討し、判断基準を設定して優先順位を決めるとともに、必要に応じてA/Bテストを実施し効果を検証しながら、継続的な改善を進めていきたいと考えています。

今週の学び「問いの立て方」とは？ 今週は「問いの立て方」について学びました。その内容としては、以下の3点が重要です。 1. **問いから始める事**：最初に問いを意識すること。 2. **問いを残す事**：問いを意識し続けること。 3. **問いを共有する事**：組織全体で方向性を共有すること。 解決策とは何を指すのか？ 「問いから始めること」について特に考えさせられました。総合演習の設問で解決策と課題のまとめを行う中で、「そもそも何を解決したかったのか」が不明確なことに気が付き、自分自身で今ここで答えを出すべき問い（イシュー）を意識して取り組む必要があると改めて感じました。 業務への応用を考えてみる ここから得た気づきを基に、社内外の業務にどのように応用できるかを考えてみました。 **製品仕様、要求仕様の検討**： 製品の細かい仕様やユーザーからの要求仕様を製品仕様に落とし込む際、「何のために必要な機能か」「本当に必要な機能は何か」を最初に考え、イシューを設定してから仕様の検討に着手することが重要です。 **社内の打合せ**： 社内外の打合せでは、目的をイシューとして設定し、会議の時間内に何を決めるべきかを明確にすることで、会議の時間を効率的に使えるようにする必要があります。 以上のように、問いを意識することが、業務の効率化や質の向上に寄与すると感じています。

テスト比較の狙いは？ A/Bテストでは、施策の比較効果を検証するため、比較対象のグループ間での差異を可能な限り限定することが重視されています。例えば、目的や仮説を明確にし、検証項目をしっかり設定することが大切です。また、テスト対象は1要素ずつに限定するべきであり、複数の要素を同時に検証したい場合は、別の手法を検討する必要があります。さらに、比較実験は同時期に実施することで、外部要因の影響を排除する狙いがあります。 利用段階の課題は？ ファネル分析については、ユーザーの利用段階ごとに各プロセスを分解し、どの段階で離脱が発生しているかを明らかにする手法です。デジタルマーケティングでの活用は非常に効果的ですが、営業活動における利用も十分に期待できると感じました。ただし、営業活動の場合は、各担当者が利用プロセスや各段階（Stage）の定義を正確に理解し、適時更新することが不可欠です。例えば、Stageの更新が一度に行われる場合や、同一状況でも担当者によって判定が異なる場合、分析の精度が低下する恐れがあるため、その点に留意する必要があります。 全体の改善点は？ さらに、Top、Middle、Lowパフォーマー各グループでの離脱状況の違いや、全体で共通して離脱が目立つ段階を把握することで、どの段階に改善の余地があるのか具体的に見極めることができると考えました。