2025年、グッドパッチに新設されたデザイナートレーニングチーム「hatch」。このチームには、実務経験は浅くても、デザインへの強い思いと行動力を武器に入社したメンバーが集まっています。
今回の記事では、トレーナーとして育成に関わるデザイナー2名で進めてきた「レビューの仕組みづくり」についてご紹介します。トレーニングの現場で直面している課題や、実際にどんな取り組みを試してきたのかをまとめた記録です。
育成やトレーニングの仕組みづくりに課題を感じている方に、少しでも参考になる部分があればうれしいです。
目次
なぜ、レビューを仕組み化しようと考えたか
UXデザイナー育成のレビューを仕組み化しようと考えた背景には、現場で見えてきた課題があります。
hatchには現在3名のトレーナーと3名のトレーニーが所属しており、ペアでプロジェクトに入りながら、実務と研修を通してスキルを伸ばす体制をとっています。
このトレーニングを複数名並行して進める中で、
- 複数のトレーニーに同じフィードバックを何度も行う
- どのトレーニーも同じフェーズで似たようなつまずきがある
といったことが目立つようになってきました。
トレーニーが増えるほど、こうした繰り返しの対応による負荷は大きくなり、トレーナーの時間やエネルギーを圧迫してしまいます。また、フィードバックの傾向が共通してきたからこそ、「これは仕組み化できるのでは」とも考えるようになりました。
そこでレビュー観点を共通言語として整理し、トレーニーの一次レビューとトレーナーの二次レビューで質を担保できる流れをつくることにしました。フィードバックの負担を減らし、より深いサポートに時間を使えるようにするための仕組み化です。
1. 「レビュー観点の可視化」からスタート
最初に着手したのは、レビューの観点を棚卸しし、構造化することでした。
キックオフ、課題調査、ユーザーリサーチなど、フェーズごとにトレーニーがつまずきやすいポイントと、それに対して必要となるフィードバックを整理することが重要だと考えたためです。
この観点整理に大きく役立ったのが、hatchのオリジナル研修である「模擬クライアントワーク」です。この研修は、グッドパッチのトレーナーをクライアントに見立て、キックオフからコンセプト設計まで、実際のプロジェクトと同じプロセスを体験する内容になっています。
模擬クライアントワークをベースにした理由は以下の通りです。
- 全トレーニーが入社後に必ず実施しており、データがそろっている
- グッドパッチの標準的なプロジェクトプロセスをたどるため、基礎的なフィードバック観点が抽出しやすい
- 同じ手順で進むため、共通するつまずきや観点が見つけやすい
- 全パートが録画されており、AIでの議事録化やデータ抽出が容易
これらの条件がそろっていたため、まずはこの研修の情報をもとにレビュー観点の可視化に取り組みました。
実際に行ったこと
レビュー観点の可視化は、以下のような手順で進めていきました。
- 模擬クライアントワークのレビューセッションを毎回自動録画してtl;dv（議事録作成ツール）へ格納する
- レビューのデータから音声を抽出して、Google NotebookLM（AI搭載の要約・整理サービス）に格納
- 「キックオフ」「課題調査」など、フェーズごとで行った実際のフィードバック内容を抽出
- 抽出した内容を汎用的に使えるレビュー観点に整理し直す
- トレーナーが内容を確認し、抜け漏れを補完して観点の精度を高める
実際に抽出した観点例
「キックオフ」では
- クライアントから情報をもらう前提ではなく、自分たちで調べた上で仮説として提示する姿勢が信頼を生む
- グッドパッチは作業代行ではなく「意思決定の伴走者」として進めるため、その理由と期待役割をていねいに合意することが重要
- 専門用語は使わず、初心者でも理解できる言葉で「なぜそれが必要なのか」を自分の言葉で説明する
「インタビュー設計」では
- 対象者の定義は属性ではなく、調査目的に合致する「具体的行動（事実）」を行っているかを基準にして選定・定義する
- 単なる現状把握ではなく、仮説と目的の解像度を高め、課題に沿って「何を検証したいか」という仮説や問いを明確にする
- 人数・形式・対象などのすべての事項に対して目的と紐づいた「理由」を持つようにし、「なぜそうするのか」を論理的に整理してクライアントと意識合わせをする
- インタビュー項目は「何が欲しいか」を問うのではなく、「いつ・どこで・何をしたか」という「具体的な体験や行動の事実（エピソード）」を聞き出す設計にする
といった基本的な考えから、グッドパッチのプロジェクトで重要となる観点でレビューポイントを抽出できました。
このフェーズで重要だと感じたこと
大切なのは「実際に行ったフィードバックを後からデータとして扱える状態にしておく」ということです。口頭だけでフィードバックをしてしまうと記録が残らず、議事録として書き起こすにも手間がかかります。
その点、音声や録画が残っていれば、AIでの分析や観点抽出がぐっとやりやすくなります。ついつい口頭で話しながらフィードバックしがちですが、日々のレビューを「データ化できる形で残す」ことを意識するだけでも、後の仕組み化に大きく貢献すると感じました。
2. レビュー観点を活用し、仕組み化を検討
レビューの観点が整理できたら、次の課題は「それをどのように活用して、トレーニーが自分で一次レビューできる状態を作るか」でした。実際にトレーニーにヒアリングを行い、「どんな仕組みがあれば安心して進められるか」を一緒に検討しました。
ヒアリングで特に多かった声は、
- アウトプットが求められているクオリティに達しているのか、作りながら不安な状態
- そもそも、進め方がこれで合っているのか確信が持てない
- 何をどこまで決めればいいのかが分からない
といった、「迷いながら進めている状態」に関することでした。この声を受けて、まず必要だと考えたのは次の2つです。
- 作業につまずいたとき、気軽に相談できる仕組み
- 完成したアウトプットを自分で一次レビューできる仕組み
この両方がそろえば、トレーニーが自力で改善サイクルを回せるようになり、トレーナーの負荷軽減にもつながります。そこで、実際にプロトタイプとして、以下の2つを作ってみました。
実際に作ってみたもの：気軽に相談できるチャットボット
質問しながら必要な要件を詰めたり、粗い段階のものでもレビューすることができる先輩UXデザイナーのような役割を想定して、チャット形式のものを作ってみました。
Google GeminiのGem（AIアシスタント作成機能）であれば、長いプロンプトを入力しなくても、一定の形式での回答を繰り返し行えるので汎用性が高く、テキストだけでなく画像データに対してもレビューできます。
これによって、目的とのズレや不足している観点を補い、日常的なちょっとした迷いを解消できるものを目指しました。作成の手順は、以下の通りです。
- Gemにレビュー観点のデータをインプット
- Gemのカスタム指示として、ペルソナ、タスク、コンテキスト、具体的な回答形式などを設定
- 質問を繰り返し、回答の精度を確認
- 精度を上げるために、観点をさらに追加し改善を繰り返す
実際に作ってみたもの：アウトプットに自動で付せん型フィードバック
アウトプットに直接フィードバックを入れられる仕組みがあれば、トレーニーが一次レビューに取り組むハードルを下げられるのではないかと考えました。「これでいいのかな……」という不安を解消する、確認用ツールとしての役割を想定しています。以下のような手順で作りました。
- Cursor（AI搭載のコード編集ツール）にレビュー観点をインプット
- FigmaとCursorを連携
- Figmaで作成したアウトプットに対して、レビュー観点に基づいた付せんコメントを自動生成
- 実際の精度を確認しながら、改善を繰り返す
このフェーズで重要だと感じたこと
それぞれを実際に作ってみると、チャットボットで抽出したレビュー観点のみでは不足している観点が多くありました。今後精度を高めていくためにも、レビュー観点を追加して、ソースデータを更新していくことが重要です。
また、レビューする側のスタンスやフィードバックの粒度に関してもしっかり定義することで、受け手が理解しやすく戸惑わない作りにする必要があると感じました。
さらに、プロジェクトの概要や目的、背景などの前提条件を誤認してしまっている場合は、それに気付けないことも懸念です。これらはインプット情報として合わせて提供してもらうことで、フィードバックの精度を上げられるのではと考えています。
3. 有用性を確認する
プロトタイプが完成した後、実際にトレーニー3名に使ってもらい、有用性を確認しました。以下は、精度やフィードバックの内容についてのトレーニーの声です。
内容の読み取り精度について
- 入力した内容を正しく把握できており、誤読や誤認識はほぼ見られない
- インタビュー設計資料のキャプチャも画像も高い精度で読み取れている
- ファイルサイズが大きすぎるPDFは読み取りがうまくいかない場合があるが、情報量を調整すれば対応可能
レビュー観点の具体性について
- 「改善点／確認事項」が具体的で、すぐアクションに落とせるレベルになっている
- 不明点は追加プロンプトで深掘りでき、理解を補いやすい
- 次のステップに進むための示唆も含まれており、インタビュー設計の自走を助ける
- 「評価と詳細」「改善点／確認事項」「参照元フィードバック」などの構成が分かりやすく実践的
改善点・気になった点
- 一次アウトプットとしてのレビューには十分だが、指摘観点が今後さらに充実すると精度が上がりそう
- レビュー対象外の領域（目的の妥当性、調査方針のズレなど）は、背景情報が限られるため、正確な指摘が難しい可能性がある
- 背景・前提情報が設計書にない場合、前提を疑わずにレビューしてしまう点は課題になり得る。文脈に応じた柔軟な判断が必要
- レビュー観点の網羅性（どの観点が満たされているか／いないか）がチェックリスト的に可視化されると納得感が増す
- PDFの情報量が多いと読み取りが崩れるケースがあるため、入力時の工夫が必要
チャットボット形式と付せん形式それぞれの比較
チャットボット形式
メリット
- やり取りや質問を繰り返すことで、フィードバックの内容を詳細に把握できる（指摘内容について壁打ちしながら理解を深めたいというニーズがあり、対話形式の方が学習効果が高い）
- フィードバックで、気になる箇所についてより詳細を深掘りできるため理解を深められる
- Gemを共有すれば、誰でもすぐに使える
デメリット
- 膨大なデータ量だとエラーが起きてしまう
- 箇条書きでフィードバックされるので該当箇所を把握するのが手間
付せん形式
メリット
- 指摘箇所が視覚的に分かりやすい
- アウトプットの形が完成形に近いものに対しては、レビューしやすい
- レビュー者側が一次レビュー時に使うことで業務効率に活用できるデメリット
デメリット
- やり取りを通じてフィードバックの内容を詳細に把握するのが難しい
- クライアントワーク時に付せんの消し忘れが発生しそう
- レビューを受けたい側が環境を構築する必要がある
このフェーズでの結論
どちらの形式も状況に応じた使い方ができるので、まずはレビュー観点を充実させることと、回答の精度さえ上がれば、一次レビューの仕組みとして十分活用できることが分かりました。プロンプトをより詳細に定義して、回答のバラつきを減らすことも改善の余地があります。
レビューの仕組み化において重要なこと
今回、レビューの仕組みづくりを検討する中で、改めて重要だと感じたのは、レビュー観点そのものを継続的に蓄積することでした。一般的なUXチェックリストや観点はWeb上に多く公開されており、レビューされる側も、生成AIを使えば自分である程度チェックできます。誰でも手に入る観点だけでは、育成におけるレビューの価値にはつながりません。
実務の現場には、クライアントとの向き合い方、プロジェクトの目的の捉え方、意思決定の判断軸など、経験の積み重ねによって育まれる観点があります。フレームワーク通りに進めるだけでは見えてこない、こうした現場ならではの視点は、一般的な知識や生成AIだけでは補いきれません。
だからこそ、「日々後輩に伝えていること」や「実際のプロジェクトで行っているフィードバック」 を地道に記録し、蓄積していくことが大切だと感じています。蓄積を重ねることで共通する観点が可視化され、その観点を土台にした仕組みづくりは、AIを使えば柔軟かつスピーディに実装できます。
また、hatchには複数のトレーナーとトレーニーがいるため、通常よりも早いサイクルでフィードバックが集まり、つまずきの傾向も把握しやすい環境があります。これらを活かすことで、中途入社メンバーの立ち上がりだけでなく、新卒育成への展開にも役立てられるはずです。
最終的に目指しているのは、育成やレビューが特定の個人に依存しない状態をつくること。そのためにも、プロトタイプの改善と並行して、レビュー観点を継続的に蓄積していく仕組みを整えていきたいと考えています。
そしてゆくゆくは、今回の取り組みがデザイン業界全体のデザイナー育成にも貢献できるよう、今後も試行錯誤を重ねていきたいと思います。
以上、グッドパッチのトレーナーが取り組んだ育成の仕組み作りを、Goodpatch Design Advent Calendar 2025 13日目の記事としてご紹介しました。
グッドパッチのデザイントレーニングチームでは、現在UIデザイナーを積極採用中です。
私たちは現在のスキルよりも、これまでの挑戦・取り組み・これからの成長、そして期待と覚悟を大切にしたいと考えています。「hatch」はそのための入り口です。現在UI/UXデザイナーを積極採用中です。まずは一度カジュアルにお話ししませんか？ポートフォリオ不要・オンラインでの実施なので、ぜひお気軽にお申し込みください。皆さんとお会いできることを、一同楽しみにしています。
👉 カジュアル面談へのお申し込みはこちら
👉 UI/UXデザイナーの募集要項はこちら
👉 UXデザイナーの募集要項はこちら
執筆者
UI/UX Designer & trainer : Yuki Yamashita
UX Designer & trainer : Yoshiko Gotoh
