ぴかぴかサービスデザイナー育成記録
こんにちは、デザインマネジメントファームCOLOGUEでデザインリサーチをしております藤井さとみ（HCD専門家）です。今回は近日私が対応している「UX人材（サービスデザイナー/UXリサーチャーなど）の育成方法」をお話ししていこうと思います。
探り探りの内容になりますので、同じように育成・もしくは成長中の方のヒントになればと思い記録を残します。
サービスデザイナーになる人はいる、でも育て方ってあんまり確立されていない気がする
私も誰かに「育成してもらった」というよりは、課題を解決するために、自分で学べるところ見つけて実践してを繰り返してどうにか今にいたる…という感じです。
いろいろと様子をみていてもサービスデザイナーやリサーチャーの育成は（日本において）まだまだこれからの領域なのではと思っています。ということで、今回は、私のチームに今年度入った新卒1年生さんを対象にたいあたり育成をしてみた記録を書いていこうと思います！
育成対象者
新卒1年生（美術系大学卒）Aさん
サービスデザイナーとして採用
将来的に目指してほしい状態
・弊社以外でも通用するサービスデザイナーになる
・指導者のコピーではなく、独自のサービスデザイナーになってもらう
・サービスの当事者になるというマインドセットを持ってもらう
進め方
サービスデザインプロジェクトにAさんに参画してもらう。
指導者である私（藤井）は、プロジェクトプロセスを設計しファシリテートを担当します。
対象者であるAさんには、プロセスにおいてメイン作業者（ex.シナリオ作成、インタビュー実施など）として参画してもらいました。
指導者の働きかけ方は3種類
今回、ファシリテート（進行）以外の私の働きかけ方は以下3種類です。フェーズによって使い分けています。
Teaching
「教える」という働きかけ方。
対象者が持っていない知識を得ることを目指します。
本間浩輔、2017、「ヤフーの1on1」、ダイアモンド社。
Feedback
「伝える」という働きかけ方。
対象者がどう見えているか知ることを目指します。
本間浩輔、2017、「ヤフーの1on1」、ダイアモンド社。
Reflection
「振り返る」という働きかけ方。
対象者の物の見方、捉え方をアップデートすることを目指します。
プロジェクト進行と、指導者の働きかけ方
大まかなプロジェクトの流れ
1.ビジネスモデルキャンバス/ペルソナ・シナリオ作成
2.リサーチ計画・実施
3.インタラクションシナリオ・プロトタイプ作成
4.ユーザビリティテスト計画・実施・解決策のブレスト
1.ビジネスモデルキャンバス/ペルソナ・シナリオ作成
指導者の働きかけ方：Teaching・Feedback
ビジネスモデルキャンバスやペルソナ・シナリオはある程度書き方にコツがあるので「書き方」は教えるようにしました。ですが、内容について実業務では正解はないので「内容」にはフィードバック（私にはこういう風に見えますが、あなたはどう思いますか？）で返すようにしました。また、Teachする際は自論と他論をできるだけ区別して話します。他論を語るときは出典書籍を合わせて共有することで、自学を促しました。
2.リサーチ計画・実施
指導者の働きかけ方：Teaching・Reflection
「良い」仮説の立て方や聞き方は、ある程度失敗を繰り返さないと（経験を積まないと）取得しづらいスキルなので、リサーチについては働きかけ方をteachに振りました。（例えば、この課題を知りたいときはこんな問いを用意するといいと思います、質問するときは対象者が話しやすいように体験順に並べてみましょうなど）
インタビューの質問を考える際は「どうして〇〇という仮説を立てたのでしょうか？」など内省を促すようにします。インタビューはコツなどは置いておいてとりあえずやってみてもらい、失敗経験をできるだけ得られるようにしました。その際も指導者がリフレクションします。
3.インタラクションシナリオ・プロトタイプ作成
指導者の働きかけ方：Reflection
入社してすぐは先輩の正解を探してしまいがちになります。私はこのアクションや姿勢をバッドと捉えているので、できるだけ私が正解を伝えないように、プロトタイプの成果に対するteachはしないようにしました。プロトタイプの良し悪しはすべて次の「テスト」で発見します。
しかし、指導者的にこの態度はかなり辛かったです！「テストをしなくてもこうした方がユーザビリティはあがりそう」という指摘をついしてしまいそうになります。しかし、今後サービスの当事者として自分の出すプロトタイプに責任を持つ貴重な機会を奪うのではないか…と思い「あなたがこれで良いと思うなら、一旦テストしてみましょう」という態度を貫きました。
4.ユーザビリティテスト計画・実施・解決策のブレスト
指導者の働きかけ方：Feedback
このフェーズからはteachを極力やめました（やり方は私が決めていますが…）。Aさんの作ったプロトタイプは「私」が評価するのではなくテストを通して「ユーザーを憑依させた私とAさん」で評価するようにしました。
今回は評価内容をもとに、優先順位を決めて解決策は二人で出し、どの解決策を採用するか決めて全体のバランスを取るのは「Aさん」に担ってもらいました。これも将来的には先輩の顔色を伺わないようにして欲しいからです。
ここで採用した解決策は、さらに3.のユーザビリティテストを重ねて、バランス感覚や解決策を採用するとユーザー体験にどんな変化が出るのかの経験をしてもらいます。
対象者Aさんのようす
1.ビジネスモデルキャンバス/ペルソナ・シナリオ作成
2.リサーチ計画・実施
このフェーズはある程度Teachするので、そこまで対象者にとってストレッチな体験になりません。この段階では自分がつくったものを「チェックしてください」と私に聞いてくださる言動が多かったです。
参考文献の読む場所もある程度指定したので、そこを読んで自分なりに解釈してフレームワークを使いこなせるようになっていました。
3.インタラクションシナリオ・プロトタイプ作成
ここで一気にTeachがなくなるので、対象者は不安そうでした。「あなたがこれで良いと思うなら、一旦テストしてみましょう」という指導者の態度には、ヒンヤリしていた様子です。（私もなんだか心が痛んだ…）
また、対象者のアウトプットが「良いか悪いか」を指導者が伝えなくなるので、プロジェクトが進行すること自体にも不安を感じたまま進んでしまっている…というAさんの焦りも感じました。
4.ユーザビリティテスト計画・実施・解決策のブレスト
プロトタイプで自分の意図した体験を表現しきれなかったという思いも抱えながら、立場を振り払い自身のサービスを冷静に評価すること自体にAさんは難しさを感じていた様子でした。
「指導者」ではなく「ユーザー」に評価してもらうという体験はAさんにとって新鮮に映っていたように感じました。
働きかけをふりかえって
「指導者」として参加するのと「チームメンバー」として参加するのでは、目標が変わってきます。ほとんどの実務ケースでは「対象者の成長」よりも「提供サービスの品質」に重きを置くことになり、どうしても指導が「Teaching」に寄りすぎてしまうのではないでしょうか。そんなときに有効なのが「ターゲットを憑依させたユーザーテスト」なのではないか？と今回の取り組みを経て考えました。状況に応じて働きかけ方を変えるのが個人的には良いのでは？と現状は考えていますが、こういう風にするといいよ！などございましたら、ぜひ共有ください。
まだまだ成長の途中ではございますが、みなさまの育成・成長のヒントになりましたら幸いです。ここまでお読みいただきありがとうございました！