Knowledge事例・記事

HCD-Net UXデザイン連続セミナー2026 受講レポート

2026.09.25

このレポートは、HCD-Net UXデザイン連続セミナー2026(全6日間、講師:井登友一氏)の受講内容と、最終課題として取り組んだ「2035年の人と人とのつながりの変化に対する新たな価値提案」(提案名「Kikkake Tag」)についてまとめたものです。

はじめに

このセミナーは、2026年7月から9月にかけて開催された、特定非営利活動法人 人間中心設計推進機構(HCD-Net)主催のUXデザイン集中講座(UX Design Bootcamp)です。フィールドリサーチから価値抽出、ペルソナ・インサイト開発、アイデア創出、プロトタイピングまで、人間中心設計の一連のプロセスを実践的に学ぶことを目的としています。
最終課題ではチームで「2035年の人と人とのつながりの変化に対する新たな価値提案」というテーマに取り組み、新たな価値提案「Kikkake Tag」を考案しました。

このレポートでは、各回で学んだ内容と、最終課題として提案した「Kikkake Tag」の検討プロセス、そしてセミナー全体を通じての学びと気づきを振り返ります。

セミナー概要と受講プロセス

開催日テーマ主な内容
2026/7/11Day1
価値探索のためのデザイン・リサーチ概論
全体カリキュラムの説明
発見と創造のためのリサーチ講義
デプスインタビューリサーチ演習
2026/7/19Day2
デプスインタビューを用いた
価値探索〜価値抽出
インタビューリサーチ補講
KA法による価値抽出
半構造化インタビュー実査
2026/8/8Day3
価値の構造化とペルソナデザイン
KA法による価値統合
デザインペルソナの講義
ペルソナ制作
2026/8/22Day4
ユーザー体験の俯瞰的な可視化による
アイデア発想手法
カスタマージャーニーマップ講義
サービスブループリント+サービスデザイン思考
価値提案ステートメントの検討
2026/8/29Day5
キーモーメントの策定→
具体化とアイデアの拡張発想
アイデア創出・強制発想法
プロトタイピング手法の講義
2026/9/19Day6
最終課題プレゼンテーション
提案コンセプト「Kikkake Tag」の具体化
体験ストーリー設計
スライド資料の作成・最終確認

各回の学習内容

Day1:価値探索のためのデザイン・リサーチ概論

Day1では、チームビルディングのあと、集中講座全体のテーマが示されました。デザインテーマは「① 2035年の人と人とのつながりの変化に対する新たな価値提案」と「② 2035年の消費意識・行動の変化に対する新たな価値提案」の2つが提示され、私たちのチームはテーマ①が割り振られました。

講義では「意味のデザインによるイノベーション」を概論として、人間中心設計のサイクルやデザイン思考のダブルダイヤモンドなど、デザイン思考の基本的な歴史とプロセスを学びました。
続いて「発見と創造のためのリサーチ方法論」として、「課題の質がソリューションの質を決める」という考え方のもと、フィールドリサーチの意義や、自分の目と耳で確かめて課題を自分ごと化することの重要性が説明されました。

午後の演習では「デプスインタビューリサーチ演習」を実施しました。設問の大項目設計→グループでの分担→中項目・小項目の詳細設計と進めた上で、実際にインタビューを実施し、最後に振り返りを行いました。この演習を通じて、設問設計がインタビューの質を左右することを実感しました。

Day2:デプスインタビューを用いた価値探索〜価値抽出

Day2は、講義パート1「インタビューリサーチについての補講」から始まりました。Day1で実施したデプスインタビュー以外のリサーチ手法として、心理描画図法(コラージュ)、文章完成法(SCTメソッド)、物語法(ストーリーテリング)、ライフヒストリー、タイムラインなどが紹介されました。

講義パート2では「KA法を用いた価値抽出〜構造化手法」を学びました。KA法は、インフォーマント(調査協力者)の思考の背後にある「価値」を抽出し、全体構造を俯瞰する手法です。まず収集したインタビューデータの中から、価値の理解や新たな洞察につながる可能性をもった情報片(ファクトイド)を抽出し、そこから心の声・価値へと解釈を重ねていきます。

午後の演習では、他チームのメンバーをインフォーマントとして半構造化インタビュー実査を行い、得られたデータをもとにKA法によるファクトイド抽出・価値変換に取り組みました。

Day3:価値の構造化とペルソナデザイン

Day3は、「価値統合(統合価値マップ作成)」の講義から始まりました。井登氏からは、価値カードに複数のコンテキストが混在している場合は一つ一つの価値に分割して記述するべきというブラッシュアップのアドバイスを得ました。

続いて「デザインペルソナ」の講義では、良い製品・サービス体験のデザインに必要な「誰に?どんな価値を?どのように提案するのか?」や、ゴール指向デザインの考え方、ペルソナ開発の7工程(定量調査によるクラスタリング→質的調査→ファクトイド抽出→グループ化→骨組み作成→肉付け→完成)を学びました。「なぜそうしたいのか」が描かれていないペルソナは浅い、という指摘が印象的でした。

演習では、それまでに得たインタビューデータをもとに統合価値マップを作成し、簡易ペルソナ「野崎護」を作成しました。その中で、彼の「人の役に立ちたい」という思いと、「知らない人への声かけをためらう」という行動に着目しました。

Day4:ユーザー体験の俯瞰的な可視化によるアイデア発想手法

Day4は、「カスタマージャーニーマップ(CJM)」の講義から始まりました。CJMは「ペルソナと製品・サービスとの体験の旅」の全体像を、BEFORE(予期的UX)・DURING(一時的UX)・AFTER(エピソード的UX)と累積的UXの軸で描き出す手法です。描く際の重要な視点として、【視野】現状を描くか理想を描くか、【視点】インサイドアウト(企業から見た顧客の世界)かアウトサイドイン(顧客が見ている世界)かが示され、「現状×顧客視点」と「理想×ビジネス視点」の2つのCJMを作成して「提案価値と起こすべき変化」を考えることが推奨されました。

続いて「サービスブループリントとサービスデザイン思考」を学びました。CJMが「顧客が経験する世界(カスタマー・フロントエンド)」だけを描くのに対し、サービスブループリントはその背後の「従業員やシステムが動く世界(ビジネス・バックエンド)」も含めて可視化する違いが整理されました。さらに「サービスコンセプト」について、ペルソナへの一般化にはコンテクストが伴うこと、価値提案の3つのステートメントは矛盾していてよい(むしろ矛盾がないとサービスは生まれない)という考え方が示されました。

演習ではペルソナのカスタマージャーニーマップとサービスブループリントを作成し、ソリューションアイデア発想に取り組みました。質疑応答では「ペルソナが自分自身に似てしまうのは問題か」という質問に対し、井登氏からは「リサーチとデータ解釈の結果としてオーバーラップしたのであれば問題ないが、根拠となるデータがないのに自分に引き寄せていないか、KA法のラダーダウンでファクトに立ち戻って確かめるとよい」という実践的なアドバイスがありました。

サービスコンセプトの策定時に、「ペルソナで表現されなかった目的(ゴール)があるのでは?」という意見がチーム内であがりました。それに対し、チューターの方からは、ライフゴールの設定を見直す必要があるという指摘をいただきました。

ここで立ち戻るべきなのは、ペルソナの記述だけでなく、その根拠となったインタビューデータです。調査で捉えた目的をペルソナに十分に表現できていなかったのか、それとも提案に都合のよい目的を後から足そうとしていたのか。この二つを区別しなければ、ペルソナと提案の整合性を取るだけで、調査から離れてしまう可能性があります。

Day5:キーモーメントの策定→具体化とアイデアの拡張発想

Day5は、「アイデア創出・強制発想法」の講義から始まりました。カスタマージャーニーマップ上でペルソナにとって重要な局面を「キーモーメント」と定義し、その解決アイデアをアイデアシートに書き出していくアプローチを学びました。

後半は「プロトタイピング」の講義でした。プロトタイピングは、詳細が決まってから形にするのではなく、アイデアを批評し発展させるためのコミュニケーション手段であるという位置づけが示されました。

演習では、カスタマージャーニーマップ上のキーモーメントに対するアイデアを拡張し、ストーリーボード化することで、最終課題である「Kikkake Tag」の体験ストーリー(困りごとを可視化する場面と、共通の興味から声をかけ合う場面)の基となるアイデアが形になっていきました。

最終課題:2035年の新たな価値提案「Kikkake Tag」

ペルソナとインサイト

Day2・Day3で実施したインタビューとKA法による価値抽出をもとに、最終課題の起点となるペルソナ「野崎護」(45歳・会社員マネージャー・既婚・高校生の子供1人・東京在住)を作成しました。キャッチフレーズは「僕にまかせて!」で、自分のこれまでの経験を人に渡すことが、結果的に自分の成長にもつながると考えています。ライフゴールは「親しい人に、役立てる自分で居続けること」であり、そのために親しい人とのコミュニケーションを絶やさず、相手が求めていることを察知できるよう気にかけています。

このペルソナを検討する中で着目したのは、「人の役に立ちたい」という思いと、「知らない人への声かけをためらう」という行動です。親しい人との関係を大切にすることと、知らない人への関わりをためらうことは、必ずしも矛盾しません。そこで今回は、役に立ちたいという思いを行動につなげるには、何が必要なのかを考えました。

提案の起点としたのは、「つながりが欲しいのではなく、関わる理由が欲しい」というインサイトです。相手が何を求め、自分に何ができるかが分かれば、声をかける後押しになるのではないか。この考えを、今回の提案で検証すべき仮説として置きました。

提案コンセプト

「つながりが欲しいのではなく、関わる理由が欲しい」というインサイトをもとに、Day5のアイデア発想を経て具体化した提案が「Kikkake Tag」です。コンセプトステートメントは「見えない思いを、人と関わるきっかけに」。

Kikkake Tagは、本人のつぶやきや状況からAIが困りごとや興味を読み取り、本人が表示を許可した情報だけを「タグ」として可視化するウェアラブルガジェットです。ガジェット越しに周囲を見ると、「声かけOK」「困りごと」といったタグが、その人に重なって表示されます。これによって、相手が何を求めているか、声をかけてもよいか、自分に何ができるかを判断する手がかりを提供します。

現在Kikkake Tagのある未来
声をかけてよいか分からない相手の意思が分かる
自分に助けられるか分からない困りごとの内容が分かる
関わる理由がない役割や共通点が見つかる
行動に移せない自分から行動を始められる
自分の役割を感じにくい人の役に立てたと実感できる

想定されるガジェットの形は1つに限定せず、腕時計型・AIサングラス型・ペンダント型・バッジ型など、身につけ方によって複数の形が考えられることとしました。これは、日常のさまざまな場面や人の好みに自然に取り入れられることを目指したものです。

プロダクトのしくみと利用体験ストーリー

Kikkake Tagは、次の4つのステップで機能します。
①本人のつぶやきや状況をAIが読み取り→②困りごとや興味をタグとして表示し→③周囲の人がガジェット越しにそのタグを見て関わる理由を知り→④実際に対面で声をかけ、手助けや会話をします。
AIは困りごとや興味を読み取りますが、タグとして公開する情報は本人が許可したものに限ります。また、タグを見た人が実際に声をかけるかどうかも、その人自身の判断に委ねます。情報の可視化によって関わるきっかけをつくり、その先の行動は本人が選べる設計を目指しました。

利用体験は、大きく2つのストーリーで構成しました。体験ストーリー①「困っていたら助けてもらえる」では、移動中のペルソナがガジェット越しに困りごとのタグを見つけて自分から声をかけ手助けする場面と、逆に自分が困っているときにつぶやいた内容がタグ化され、声をかけられて助けてもらう場面を、双方の視点から描きました。体験ストーリー②「共通点も、人と関わるきっかけになる」では、困りごとだけでなく趣味・関心といった共通点も声をかけ合う理由になることを、同様に双方の視点から示しました。いずれのストーリーも、手助け後にガジェット同士をタッチすることで体験がログとして残る仕様としています。

この利用体験で私たちが最も重視したのは、タグを見る瞬間ではなく、実際に相手を助け、人の役に立てたと実感する瞬間です。不安(声をかけてよいか分からない)から、判断(自分にも助けられそうだ)、行動(自分の意思で声をかける)、実感(人の役に立てた)へとつながる体験を想定しました。Kikkake Tagは、その最初の一歩を支えるものとして位置づけています。

プレゼンテーション資料

まとめ・今後の展望

HCD-Net UXデザイン連続セミナー2026を通じて、フィールドリサーチから価値抽出、ペルソナ・インサイト開発、体験の可視化、アイデア発想、プロトタイピングまで、人間中心設計の一連のプロセスを実践しました。各手法を個別に学ぶだけでなく、調査で得た事実をもとに価値を抽出し、ペルソナや体験の設計を経て「Kikkake Tag」という一つの提案へとつなげる過程を経験できたことは、今回の受講で得た大きな学びです。

一方、限られた人数と期間での検討だったため、ペルソナやインサイトの妥当性は十分に検証できていません。特に確かめたいのは、「声をかけてよいと分かること」が、実際に声をかける後押しになるのかという点です。ためらいの理由が、断られる不安や関わった後の負担にあるなら、タグで情報を示すだけでは十分ではありません。今後はプロトタイプを用いて、今回の提案が置いた前提から検証したいと考えています。

私は日頃、業務システムの画面設計に関わっています。今回の学びを実務に戻すうえで意識したいのは、要望を画面に反映する前に、その背景にある利用者の目的を確かめることです。打ち合わせで聞いた要望と、利用者について確認できた事実、自分たちの解釈を区別し、何を根拠に設計しているのかを説明できるようにしたいと考えています。

手法の解説に加え、演習を通じて私たちの解釈や前提を問い直す指摘をくださった講師の井登さん、そして実践と振り返りの機会をつくってくださった運営の皆さま、ありがとうございました。