[AI新規事業創出]Qualitegが考える、仮説探索、顧客理解のための調査設計と準備方法

アイディア創出の事前準備として、ターゲットユーザーの課題を明らかにし、解決策を提案する方法を解説します。課題探索の目的と目標を定義し、競合の利用者からヒアリングします。また、調査手法と対象ユーザーの選定を明確にし、実際のインタビューでは深い洞察を得るために詳細な質問を繰り返します。

[AI新規事業創出]Qualitegが考える、仮説探索、顧客理解のための調査設計と準備方法

Qualiteg blogを訪問してくださった皆様、こんにちは。Micheleです。AIを活用した新規事業やマーケティングを手がけている私には、クライアントからよく寄せられる質問があります。AIを用いた事業展開を検討されている方々が共通して直面するであろう課題に対して、このブログを通じて私なりの解答をご提供したいと思います。


アイディア創出のための事前準備として、ターゲットユーザーの抱えている課題を明らかにして、その解決策を提案する方法についてご説明します。そのターゲットユーザーの課題は何かを明らかにするためにどのような調査をするべきかということについて今日は解説していきたいと思います。

ユーザーの課題探索調査のための目的と目標の明確化

まず初めに行うことは、ユーザーの課題探索調査の目的と目標の明確化です。どのような情報を収集したいのか、調査から何を得たいのかを明確に定義します。この段階で、具体的な研究質問を設定し、調査の範囲と焦点を決定します。

具体的には競合のサービス利用者の課題を聞いて、自社のサービス案とするのであれば、その競合サービスを現在利用していて、支払金額が高い人や、サービスを利用するのをやめた人をヒアリング対象にします。

woman in white long sleeve shirt sitting on red couch

このように、本調査によってどのような結果を得たいか、そのデータを使って何をしたいかというのをこの段階で明確化しましょう。

また、調査手法がインタビュー形式なのか、オンラインアンケート形式なのか、何人くらいにどのような項目を聞くのかもこのタイミングでクリアにしておく必要があります。

これらは、自身の調査目的を明らかにするだけではなくて、調査費用の社内決裁のための事前共有情報としても使えるので、面倒くさがらずにここで一度整理することをお勧めいたします。

対象ユーザーの選定とリクルー

調査の目的ゴールが決まれば次は、対象ユーザーの選定になります。よく調査を楽にするために、部署の人に声をかけてヒアリング対象にしたりするケースが多いですが、Qualitegでは身近な人をヒアリング対象にすることはおすすめせず、調査会社を使うことをお勧めいたします。

不確実性の高い環境下で企業が生き残るには、複数の未来への選択肢を持つことが重要です。株式会社Qualitegの Innovation-Crossは、企業の未来への選択肢を共創によって広げるプログラム。現状分析をもとに、オープンイノベーションやパートナー開拓を通じて「自社だけでは思いつかない」多様な可能性を発掘します。

アイデアワークショップ、ハッカソン企画、最先端AI技術の活用など、多彩なアプローチで社内外の知恵を融合させ、従来の延長線上にない革新的な選択肢を創出。経験豊富な専門コンサルタントが、御社の強みを活かしながら外部との協業による新たな道筋を描き、変化の激しい時代における戦略的柔軟性と競争優位性を高めます。未来への複数の扉を開く—それが私たちの役割です。

理由は明確で、ターゲットユーザーではない、似通った人に声をかけて、お世辞のいいねを言ってもらうことで、本来の目的である、顧客の課題をヒアリングすることができなくなってしまう恐れがあるからです。

このフェーズでは調査対象となるユーザー層を特定し、それらのユーザーがどのように製品やサービスを使用しているかを理解することが必要ですので、現在考えている、競合サービス課題仮説についてヒアリングするため、競合サービスの利用者を調査会社経由でスクリーニングしてもらい、ヒアリングすることをお勧めします。

person writing on white paper

調査対象人数の考え方とインタビュー時間

インタビューをする場合、多くの声を聴きたいのでグループインタビューをしたいというクライアント企業が多いのですが、Qualitegでのおすすめは「デプスインタビュー」となります。調査時間のおすすめは一人当たり60分~90分程度が適正でしょう。人数としては最低3名、できれば5名~7名くらいの方にヒアリングをすることをお勧めしています。

競合のサービスを利用し始めたきっかけ、利用している中で満足しているポイントや不満に思っている点を聞くのがインタビューの目的ですが、その中で機械的にこちらが質問したい内容をどんどん聞いて、Yes,Noで答えてもらうようでは、インタビュー調査をする意味がないのです。

A group of friends at a coffee shop

全ての項目において、なぜなぜ5回のように、Whyの質問を繰り返し、ユーザーがなぜその判断に至ったのか、その時の環境や心理的状況までしっかり掘り下げて聞く必要があります。そのため、最初の20分はアイスブレイクとして使い、信頼感を得て、いろいろ気軽に話してもらえる環境を整えてから、いろいろ聞いていくことで、自身が期待していたような、「真のユーザーの課題」をヒアリングすることができます。

そのため、しっかりした話をするのに30分では難しく、最低60分、できれば90分くらいの時間をかけて探索インタビューを実施することをお勧めしています。


コラムを最後までお読みいただき、誠にありがとうございます。私たちQualitegは、AI技術や新規事業の企画方法に関する研修およびコンサルティングを提供しております。もしご興味をお持ちいただけた場合、また具体的なご要望がございましたら、どうぞお気軽にこちらのお問い合わせフォームまでご連絡くださいませ。

また、新規事業創出のステップを体得したいという方にご好評のワークショップも実施しております。それぞれの担当者の方が役員目線で事業を考えるという点にフォーカスしたトレーニング内容となっており、企画担当者の方だけではなく、カウンターパートのエンジニア、デザイナー、マーケターの方にもご受講いただけるコンテンツとなっております。

皆様からのお問い合わせを心よりお待ちしております。次回のコラムも、ぜひご期待くださいね。


navigation

Read more

楽観的ロック vs 悲観的ロック:実際のトラブルから学ぶ排他制御

楽観的ロック vs 悲観的ロック:実際のトラブルから学ぶ排他制御

こんにちは! Qualitegプロダクト開発部です! 「楽観的ロックを実装したのに、まだ競合エラーが出るんですけど...」 これは私たちが実際に経験したことです。 本記事では、楽観的ロックと悲観的ロックの違いを、実際に発生したトラブルを通じて解説します。 抽象的な説明ではなく、 「なぜそれが必要なのか」「どんな問題を解決できるのか」 を実感できる内容を目指します。 目次 1. 問題の背景:並列処理で謎のエラー 2. ロックなしの世界:なぜ競合が起きるのか 3. 楽観的ロックの導入:期待と現実 4. 楽観的ロックの限界:解決できなかった問題 5. 悲観的ロックによる解決 6. 実装時のハマりポイント 7. どちらを選ぶべきか:判断基準 8. まとめ 1. 問題の背景:並列処理で謎のエラー 1.1 システムの概要 私たちが開発していたのは、 複数のワークスペースを切り替えて使用するAPIサーバー でした。 当社AI関係のプロダクトの一部だったのですが、結合テスト兼負荷テストを実行すると、まれに発生してしまっていました。 ユーザーは複数のワーキン

By Qualiteg プロダクト開発部
企業セキュリティはなぜ複雑になったのか? 〜AD+Proxyの時代から現代のクラウド対応まで〜

企業セキュリティはなぜ複雑になったのか? 〜AD+Proxyの時代から現代のクラウド対応まで〜

こんにちは! ChatGPTやClaudeといった生成AIサービスが業務に浸透し始めた今、 「AIに機密情報を送ってしまうリスク」 が新たなセキュリティ課題として浮上しています。 この課題に向き合う中で、私たちは改めて「企業のセキュリティアーキテクチャはどう変遷してきたのか」を振り返る機会がありました。 すると、ある疑問が浮かんできます。 「なんでこんなに複雑になってるんだっけ?」 企業のセキュリティ担当者なら、一度は思ったことがあるのではないでしょうか。 アルファベット3〜4文字の製品が乱立し、それぞれが微妙に重複した機能を持ち、設定は複雑化し、コストは膨らみ続けています。 当社ではAIセキュリティ関連プロダクトをご提供しておりますが、AI時代のセキュリティを考える上でも、この歴史を理解することは重要ではないかと考えました。 本記事では、企業ネットワークセキュリティの変遷を振り返りながら、「なぜこうなったのか」を整理してみたいと思います。 第1章:観測点を集約できた時代 ― オンプレAD + Proxy(〜2010年代前半) 統制しやすかったモデル かつ

By Qualiteg コンサルティング, Qualiteg AIセキュリティチーム
【IT温故知新】WS-* の栄光と黄昏:エンタープライズITはいかにして「実装」に敗北したか

【IT温故知新】WS-* の栄光と黄昏:エンタープライズITはいかにして「実装」に敗北したか

こんにちは。 —— 2003年のSOAから、2026年のAIへ —— この記事は、過去の技術動向を振り返り、そこから学べる教訓について考察してみたものです。 歴史は常に、後から見れば明らかなことが、当時は見えなかったという教訓を与えてくれます。 そして、今私たちが「正しい」と信じていることもまた、20年後には違う評価を受けているかもしれません。 だからこそ、振り返ることには意味があるとおもいます。同じ轍を踏まないために。 はじめに:20年前の熱狂を覚えていますか 2000年代初頭。 私はSOA(サービス指向アーキテクチャ)に本気で取り組んでいました。 当時、SOAは「次世代のエンタープライズアーキテクチャ」として、業界全体が熱狂していました。 カンファレンスに行けば満員御礼、ベンダーのブースには人だかり、書店にも関連の書籍がちらほらと。 SOAP、SOAP with attachments、JAX-RPC、WS-Security、WS-ReliableMessaging、WS-AtomicTransaction... 仕様書の山と格闘する日々でした。 あれから

By Qualiteg コンサルティング
DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

こんにちは!Qualitegプロダクト開発部です! 本日は Docker環境でPythonをソースからビルドした際に発生した、GCCの内部コンパイラエラー(Segmentation fault) について共有します。 一見すると「リソース不足」や「Docker特有の問題」に見えますが、実際には PGO(Profile Guided Optimization)とLTO(Link Time Optimization)を同時に有効にした場合に、GCC自身がクラッシュするケースでした。 ただ、今回はDockerによって問題が隠れやすいという点もきづいたので、あえてDockerを織り交ぜた構成でのPythonソースビルドとGCCクラッシュについて実際に発生した題材をもとに共有させていただこうとおもいます 同様の構成でビルドしている方の参考になれば幸いです TL;DR * Docker内でPythonを --enable-optimizations --with-lto 付きでソースビルドすると GCCが internal compiler error(Segmentati

By Qualiteg プロダクト開発部