概要
相性の良い学生チーム編成で、より良い成果を実現
学生はしばしば不適切なチーム編成に悩まされ、 その結果、目標が不明確になったり、作業負荷が偏ったり、協働がうまくいかなくなることがあります。 本プロジェクトでは、学生を共有する目標・作業スタイル・スケジュールに基づいてマッチングし、 教員や大学全体の成果も支える、よりスマートなチーム編成プロセスを設計しました。
Lean UX の原則を用いて、 セカンダリリサーチを行い、 高速プロトタイピングを実施し、ユーザーと直接検証を繰り返しました。 このアプローチによって、 ユーザー成果とビジネス価値の両方を最大化するソリューションを形にしました。
担当領域
UXリサーチ
UXデザイン
UIデザイン
スキル
セカンダリリサーチ
高速プロトタイピング
ユーザー検証
反復テスト
プロジェクト概要
期間: 8週間
時期: 2025年春
個人プロジェクト
アカデミックプロジェクト
ビジネス上の課題
チームプロジェクトの開始は「運任せ」になりがち
学生はしばしばランダム、あるいは友人関係など表面的な基準でチーム分けされるため、 協働がうまくいかず、期待値が不明確になり、作業負荷が偏ることが多いです。 教員も時間やデータ不足のためバランスの取れたチーム編成が難しく、 既存ツールも作業スタイルやプロジェクト目標の「相性」を優先していません。
期待される成果
授業満足度と学習成果の向上
本プロジェクトのゴールは、学生がより良い協働体験を通じて成果を高め、 それによって授業全体の満足度を高めることです。 長期的には、大学の学術的な評価向上、学生定着率の改善、そして機関全体の成果向上につながります。 成功の指標としては、チーム満足度の向上、作業負荷の均衡化、成果物の改善、 そしてチーム変更のリクエスト減少などが挙げられます。
ソリューション
相性に基づく透明なチーム編成プロセス
本プロダクトは、学生の目標・スキル・協働スタイル・役割の希望をもとに マッチングを行うチーム編成プラットフォームです。 ユーザーニーズ・文脈・協働ダイナミクスを理解した設計で、 公平性・協働性・学習成果を向上させることを目指します。 これにより、ユーザー中心かつデータに基づいたアプローチで、 学習体験をより良いものにします。
文献レビュー
チーム編成の実践は「相性」と「バランス」を見落としている
課題領域を定義するために、教育分野におけるチーム編成に関する学術文献を調査しました。 主な発見は、特に協働スタイル・目標・スケジュールの「相性」が プロジェクト成果や学生の満足度に大きな影響を与えるという点です。 これにより、チーム編成の初期段階では単なるスキルマッチングだけでなく、 マインドセットの一致を重視すべきだと考えるようになりました。 この洞察から、オンボーディング時に協働スタイルやプロジェクト目標といった 軽量なデータ入力を用いる方針を導きました。
“
学生に早い段階で自由にチームを選ばせると、 不適切なマッチングにつながる可能性があります。 バランスの取れたスキル構成でグループを作ることで、 摩擦を減らし協働を改善できます。
Lopez et al., 2021
“
現在のグループ編成は非効率的で、 偶然に依存しすぎています。 目標・強み・スケジュールを活用すれば、 より適切なマッチングを自動化できるでしょう。
Lopez et al., 2021
“
グループ戦略は スキル・目標・性格を考慮する必要があります。 協働スタイルやスケジュールの要素は、 チームの結束に大きな影響を与えます。
Odo et al., 2019
プロト・ペルソナ
より良いグループワークを必要とする学生たち
ソリューションを実際の学生ニーズに基づかせるため、2人のプロト・ペルソナを作成しました。 Alex（3年生のコンピュータサイエンス専攻）と Rachel（2年生の認知科学の大学院生）です。 学年や目標は異なりますが、どちらも「不適切なチーム編成」「不明確な期待」「不均衡な作業負荷」に悩んでいます。 Alexは志の合う仲間と強力なポートフォリオプロジェクトを作りたいと考え、 Rachelは有意義な研究パートナーシップを求めています。 このペルソナを通じて、多様な学生をサポートする必要性と、 チーム編成における「相性」「透明性」「主体性」の重要性が浮き彫りになりました。
ビジネス機会ステートメント
機会・フォーカス・成功指標
現状
現在の学術分野におけるチーム編成は、主に教員による割り当てか学生の自己選択に依存しており、 目標・協働スタイル・スケジュール・作業の好みなどはほとんど考慮されていません。
ギャップ
CATMEのような既存プロダクトが対応できていないのは、 学生を「人間関係の相性」と「プロジェクト目標」に基づいて バランス良く透明性のあるプロセスでマッチングする必要性です。
ソリューション
私たちのプロダクトは、このギャップを埋め、 公平な協働・明確な役割・強力な学習成果を支える より適切なチーム編成を実現します。
フォーカス
最初の対象は、プロジェクトベースの授業に取り組む高等教育の学生です。
成功指標
成功の証拠は「より良いマッチングの実現」「スムーズな協働」「優れた成果物」として表れます。
ユーザー成果と利点
学生がこのプロダクトを使う理由
本プロダクトは、学生の目標・作業スタイル・スケジュールに沿った グループ編成を支援します。意図的なマッチングにより、 グループワークをより効果的でストレスの少ないものにします。
- 目標と関心を一致させることで、モチベーションを高め衝突を減らす
- 強みを組み合わせることで、学生が自信を持って貢献できる
- プロジェクトをマッチングし、個人・専門的な関心に合致させる
- 期待値を明確に設定し、混乱を防ぐ
- 協働を改善して成果と満足度を高める
- 時間を節約しストレスを軽減することで、チームの再編を防ぐ
適切なチームで始めることで、学生は学業的・社会的・実務的に大きな恩恵を得られます。
検証アプローチ
段階的な検証計画
プロセス初期では Pirate Metrics を用い、 MVPが本当に必要かを検証しました。 この段階では獲得（Acquisition）に注目し、 学生がどのようにプラットフォームを発見し、登録し、利用を始めるかを調べました。 その後、定着と継続利用を観察しつつ Outcome-to-Impact Mapping を取り入れ、 教育的・組織的な価値を探りました。 この段階的アプローチにより、初期段階でのユーザー行動のテストと、 長期的なインパクトの評価を両立できました。
| 段階 | 測定内容 | 学びたいこと | 測定方法 | 成功基準（目標） |
|---|---|---|---|---|
| 🧲 獲得（Acquisition） | 学生の関心と利用意欲 | 学生はより良いチーム編成に価値を感じ、試したいと思うか？ | ランディングページのCTAテスト（例：「より良いチームとマッチングする」） | 招待された学生のうち30%以上がCTAをクリック |
| ✅ 活性化（Activation） | 学生がプロダクトから価値を得られているか | オンボーディングで学生は「良いチームと組めた」と感じられるか？ | マッチング後のアンケート（リッカート尺度：「チームはどの程度希望に合っていますか？」） | 70%以上が1週間後に「満足」と回答 |
| 🔒 定着（Retention） | 学生がチームに留まり、システムを継続利用するか | 学生はチームに満足し、活動に積極的に参加しているか？ | 複数回のピアレビューでグループ体験を追跡 | コース終了までに80%以上のチームが変更されない |
| 💰 成果（Revenue） | チームの質改善による授業評価・プログラム成果の向上 | プラットフォーム利用は協働・満足度・成果の向上につながるか？ | 過去のコホートと比較してプロジェクトスコアやピアレビューを評価 | ピアレビュー平均4/5以上、プロジェクトスコア平均+10% |
| 🔁 推奨（Referral） | 他の授業でも使いたい／勧めたいと思うか | 学生は今後もこのプラットフォームを利用したいと思うか？ | 授業終了時のフィードバック調査やNPSアンケート | 60%以上が「また使いたい」と回答 |
How Might We
どうすれば学生が 共通の目標・関心・ 作業スタイルを持つ 相性の良いチームメイトを見つけられるだろうか？
デザインスタジオ演習
解決策の可能性を探る
HMW（How Might We）問いをもとに、6アップテンプレートを使ったデザインスタジオ演習を実施しました。 これにより、複数の解決策を素早く発想し、 学生ニーズに最も合致するものを比較・検討することができました。
仮説マッピング
機能をビジネス目標とユーザー目標に結びつける
この表では、それぞれの解決策を具体的なユーザー成果とビジネス目標に結びつけました。 すべてのアイデアは「より良いチーム形成を支援する」という課題に取り組んでいますが、 学生体験にどう影響するか、大学にどんな価値を生み出すかは異なります。 このマッピングによって各アイデアの期待効果を明確化し、 どのアイデアを優先的にテストすべきかを判断しました。
| ビジネス成果 | ペルソナ | ユーザー成果 | 機能 |
|---|---|---|---|
| 適切なチーム編成により授業評価やプログラム成果が向上する | Alex・Rachelのような学生 | 共通の目標や関心を持つメンバーとチームを組める | 過去プロジェクトやオンボーディング調査による相性判定 |
| 教育機関の成果や学術ランキングの改善 | Alex・Rachelのような学生 | グループ活動を楽しみ、学習効果を実感できる | プロンプト型グルーピング、過去プロジェクトによる相性判定 |
| 学生のインターンシップ・就職率の向上 | Alex・Rachelのような学生 | 自分の関心や強みに沿った活動ができる | 関心ベースのチャンネル |
| 学生の定着率・体験の向上 | Alex・Rachelのような学生 | チームメイトの期待が事前に明確で安心できる | 授業に組み込まれた分析 |
| チームプロジェクトの学習成果向上 | Alex・Rachelのような学生 | 自分が有意義に貢献できると自信を持てる | プロンプト型グルーピング |
仮説優先度キャンバス
テストと開発の優先順位を決める
ビジネス目標とユーザーニーズの両方にマッピングした後、 各仮説の潜在的価値とリスクを評価し、最初に検証すべきものを決定しました。 これにより、影響力と実現可能性のバランスが取れたアイデアに集中し、 早期に成果を出す可能性が高い仮説を選定できました。
仮説のリスクと検証基準
優先仮説
仮説を優先付けする際には、リスクの高い前提を洗い出し、 それをどう検証するかを定義しました。 これにより、小さく始め、重要なポイントを早期にテストし、 学生ニーズに真に合致するソリューションを構築するための次のステップを明確にしました。 評価の結果、オンボーディング調査が 「低リスク・高価値」であると判断し、MVP段階でのクイックウィンに最適と結論づけました。 また、学生のスキル・成績・過去プロジェクトといった 既存データを活用することで、 自己申告のみに依存せず相性を高められると考えました。
| # | 仮説 | 価値 | リスク | 根拠 | リスクのある前提 | 無効となる条件 |
|---|---|---|---|---|---|---|
| 1 | オンボーディング＋過去プロジェクトの相性判定でチーム満足度が向上する | 高 | 低 | スキル・成績・過去プロジェクトを用いて効果的にマッチング | データが満足度と体験を正しく予測する | 学生が調査を飛ばす／データと満足度が一致しない |
| 2 | プロンプト型グルーピングで学習成果が向上する | 高 | 高 | プロンプトがスキルやスタイルを捉えられるか要検証 | 回答がスキルや作業スタイルを反映する | 成果がランダム編成と差がない |
| 3 | 関心ベースのプロジェクトで就職率が向上する | 中 | 中 | 関心と就職成果を結びつけるのは難しい | 関心一致プロジェクトがポートフォリオに有益 | 成果物が就活に役立たない |
| 4 | グループ体験改善で大学ランキングが上がる | 高 | 高 | 長期的だがリンクの証拠はまだ不足 | 良い体験が高評価や成果につながる | 満足度改善とランキングに相関がない |
| 5 | 授業内データ分析で学生定着率が改善する | 中 | 低 | 既存の授業データを活用してマッチ精度を向上 | 行動データが相性や満足度を予測する | 定着率や満足度が改善しない |
仮説
もし学生が Alex や Rachel のように 共通の目標や 関心を持つ仲間と、 過去プロジェクトと オンボーディング調査による相性データで グループを組めれば、 授業評価の向上や プログラム成果の改善 が実現できると信じています。
実験
リスクのある前提
仮説に関連するリスクのある前提をリストアップし、次のステップを明確にしました。 これにより、小さく始め、重要な部分を早期にテストし、効果的に改善を進められました。
| # | リスクのある前提 |
|---|---|
| 1 | 学生は相性の良い仲間とのマッチングに関心を持っている |
| 2 | 学生はオンボーディング調査を進んで完了できる |
| 3 | 目標・過去プロジェクト・スキルに基づく相性判定が満足度を高める |
| 4 | 過去の成果が将来の相性を予測できる |
| 5 | 学生はチーム形成プロセスを信頼している |
実験
リスクのある前提を検証する
仮説の優先度づけに基づき、価値が高くリスクが低いアイデアから着手し、クイックウィンを狙いました。 まずは基盤となる前提「学生は相性の良いチームメイトとのマッチングを重視している」を検証しました。 この前提は主観的ですが、他のすべてのアイデアや仮説を支える重要な土台です。 もし学生がチームダイナミクスを重視していないなら、相性重視の機能に投資する意義は薄れます。 早期にこれを検証することで、リスクを下げ、次の解決策検討に向けた確信を得られます。
検証する前提
| 仮説 | リスクのある前提 | 実験 | 学びたいこと | 有効と判断する条件 | 無効と判断する条件 |
|---|---|---|---|---|---|
| 適切なチーム編成により、授業評価とプログラム成果が向上する。 | 学生は相性の良いチームメイトとのマッチングを重視している | ランディングページテスト | 学生がより良いチーム編成の方法に関心を持つかどうか | 一意訪問者のうち少なくとも30%がCTA（例：「より良いチームとマッチング」）をクリック、 またはフォーム入力を完了 | 10%未満しかCTAをクリックせず、またはフォームを完了しない |
方法
初期の関心とエンゲージメントを測るため、明確なCTA（「チームマッチ調査を始める」）を配置した シンプルなMVPランディングページを作成しました。ボタンは埋め込みのオンボーディング調査につながり、 体験を擬似的に再現します。単に関心を尋ねるのではなく、実際の行動を計測してバイアスの少ない洞察を得ました。 さらに短いアンケートで関心度、専攻や学年などの基本属性、類似ツールの利用経験も収集。 HCIプログラムの学生やプロダクト／デザインコミュニティに共有し、多様な入力を得ました。 これにより、機会領域の把握、期待値の明確化、既存ソリューションへの馴染み度の把握が進みました。
結果と次のステップ
ユニーク訪問者
ユニーククリック
クリック率
シンプルなMVPランディングページと明確なCTAにより、 ユニーク訪問者13名、ユニーククリック8件、 クリック率60%を得ました。参加者は全員が類似ツールの未使用者で、 8人中5人が過去にチーム形成で苦労した経験を持ち、本アイデアに一定の関心を示しました。 一方で、「このサイトが解決しようとしていることは？」への回答がばらつき、 追加文脈を求める声もあったため、価値提案の明確化が必要であると判明しました。
次のステップとして、実際のオンボーディング質問票を用いたクリック可能なプロトタイプを作成し、 学生がプロセスを最後まで完了するか、またプロジェクトのコンセプトと提供価値をより理解できるかを検証しました。
プロトタイピング
MVP開発
ランディングページテストでアイデアへの初期的な関心は確認できましたが、 静的なページだけでは製品が実際にどう機能するのかを十分に伝えられないことも分かりました。 そこで、オンボーディングとマッチングのフローを体験できる インタラクティブプロトタイプを作成しました。 これによりコンセプトをより具体化できただけでなく、 「学生がオンボーディングを最後まで完了できるか」という 2つ目の重要な前提を検証することも可能になりました。 プロトタイプを通じて、学生が実際にどのようにフローに関わるのか、 そしてチーム形成の体験が実際に有意義に感じられるかを観察しました。
プロトタイプの流れ
学生のオンボーディング → チームマッチング → チーム概要
学生はまずコース開始時に短いアンケートに回答します。 そこでは目標、好む協働スタイル、強み、関心のあるプロジェクト分野を入力します。 システムはこの情報をもとに、目標の一致と 協働スタイルの相性を重視したチーム構成を提案します。 チームが確定すると、学生はメンバー全員の目標やスタイルをまとめた チーム概要を閲覧でき、互いを理解しながらスムーズにプロジェクトを始められます。
デザインの根拠
1. インサイトに基づいたオンボーディング設計
Lopezら（2021）、Odoら（2019）の研究や調査回答から、 「ワークスタイルの不一致」「方向性の不明確さ」「タイミングのズレ」が課題として挙げられました。 これをもとに、プロジェクト目標、協働スタイル、チーム内での役割などを問う アンケート設計を行いました。 プロセスを軽量でシンプルにしつつ、 より相性の良いバランスの取れたチーム編成を支援する狙いがあります。
2. コンセプトの明確化の必要性
「このサイトは何を解決しようとしているのか？」と尋ねた際、 「仲間探しシステム」「学生がチームを作るための仕組み」などの回答がありました。 一部には混乱した答えもあり、より明確な伝え方の必要性が明らかになりました。 この気づきが、オンボーディングやマッチングを体験できる インタラクティブプロトタイプ開発へとつながりました。
3. 類似ツールに不慣れなユーザー
参加者の誰もチーム形成ツールを使った経験はありませんでした。 これは高い需要を示すわけではありませんが、 事前知識がなくても直感的に使える体験設計の重要性を再確認しました。
調査方法
非モデレート型オンラインテスト
参加者
コンピュータサイエンスやプロダクトデザインなど、 チーム型プロジェクトに参加経験があり、 チーム編成プロセスに慣れている大学院生7名を対象にテストを行いました。
目的
前段階では、8名全員がコンセプトに一定の関心を示しました。 サンプル数は少なかったものの、フィードバックは概ね前向きでした。 前回はランディングページとアンケートを用いたコンセプト検証が中心でしたが、 今回は初期的な関心を超えて、 ユーザーがプロダクトの価値、フロー、機能性を理解し、実際に活用できるか を確認しました。 特に、オンボーディングの完了可否、チームマッチングの理解度、 そしてグループ参加後に自信を持てるかを検証しました。
検証したいリスクのある前提
- 学生がオンボーディングを最後まで進められるかどうか。
リサーチクエスチョン
-
ユーザーはオンボーディングの目的と価値を理解できるか？
プロンプト（例：協働スタイル、プロジェクト目標）が 適切で答えやすいと感じるか、それとも文脈や例が必要かを確認。 -
チーム参加プロセスは分かりやすく、満足感があるか？
グループ選択に自信を持てるか、確認画面やチーム概要が 「区切り」として安心感を与えるかを観察。 -
チーム概要は不安や気まずさを軽減するか？
チームメンバーの役割やスケジュールが表示されることで 初期の関わりを促すか、それともまだ躊躇するかを確認。
ユーザーへのタスク
- プロジェクト目標、協働スタイル、希望役割、参加可能時間を入力してオンボーディングを完了する。
- 推奨されたグループを選んで参加する。
- チーム概要を確認し、このチームに会う準備がどの程度できているかを振り返る。
結果
主な学び
1. 全参加者がタスクを完了
観察
7名全員がオンボーディングを完了し、SUSスコアは平均82.5で、 高い使いやすさが示されました。
解釈
誰も途中離脱せず、支援なしでタスクを達成できたことから、 オンボーディングの設計は直感的かつ適切であると分かります。 これは「学生はオンボーディングを進められる」という前提を裏付け、 高いSUSスコアは満足度をさらに強化しました。
デザイン改善提案
高いスコアと100%完了率から、MVP段階のオンボーディングは十分有効です。 重大な課題は見られなかったため、 現在のナビゲーションやインタラクションは維持可能です。
2. 🧠 学生はチームメイトの働き方や性格を知りたい
観察
学生は単なる事実以上に「どう働くか」を知りたいと回答しました。 「締切に対してどうか」「仕事への姿勢」「性格タイプ」 「コミュニケーションスタイル」などを尋ねてほしいとの声がありました。
解釈
学生は、締切の守り方やチーム内での適応方法など、 行動や態度を知ることを求めています。
デザイン改善提案
ワークエシックや葛藤時の対応などを測れる シナリオベースの質問を追加しました。 これは状況判断テスト（SJT）の知見に基づき、 フォームを長くせず複数の特性を捉えることができます。
3. 👥 学生は参加前にもっとチームの情報が欲しい
観察
「どれくらい野心的か」「スキルや経験」「メンバーは誰か」など、 事前に知りたいという声がありました。
解釈
名前や役割だけでは不十分で、 学生はスキル・目標・人柄を理解した上で参加を決めたいと考えています。
デザイン改善提案
名前は伏せたまま、チームメンバーの目標・役割・スケジュールを 表示する「チームプレビュー画面」を追加しました。 これにより十分な文脈を提供し、安心して参加判断ができます。
反復改善
2つの大きな改善
シナリオベースの質問で、少ないステップでより深い洞察を獲得
質問の冗長さを減らすために、 直接的な質問2つを1つのシナリオベースのプロンプトに置き換えました。 この形式により、ワークエシック、コミュニケーションスタイル、性格 といった主要な適合要素を効率的に捉えられます。 SJT研究やグループワークの調査を参考にしたこの方法は、 実際の行動特性を軽量なステップで引き出します。
チーム参加前にメンバー情報を表示し、自信ある選択をサポート
ユーザーが参加前に主要なメンバー情報を確認できるようにすることで、 より情報に基づいた安心感のある意思決定が可能になります。
振り返り & もっと時間があれば
小さく作って、素早く検証、そして改善
このプロジェクトでは、新しいコンセプトや機能を段階的に開発しました。 デザインプロセスを通じて、まず小さく始め、 ユーザーと共にアイデアや機能を検証し、 その後次のイテレーションに進みました。 このアプローチにより、効率的に改善を重ね、 ユーザーが本当に必要とするソリューションを素早く形にできました。
ビジネスの視点
デザインを進める中で、ユーザーの成果だけでなく ビジネス成果の最大化も意識しました。 この視点を持つことで、ユーザーの課題解決だけでなく、 デザインを通じてビジネスの成長を支援することができました。
今後の改善
次のステップとして、行った改善が有効かどうかを確認するために もう一度ユーザビリティテストを実施します。 その後、「目標、過去のプロジェクト、スキルに基づく相性が より良いチーム形成と満足度向上につながる」という リスクの高い前提を検証したいと考えています。
