見出し画像

忙しくても学習・成長を加速する「PdM/UXD版もくもく会」のススメ

こんにちは!
UXデザイナー(UXD)兼プロダクトマネージャー(PdM)の川崎です。
普段は「Airレジ ハンディ」などの業務支援領域で、
主に新規プロダクトの立ち上げやディカバリーフェーズに携わっています。

今回は、
プロダクトマネージャー(PdM)・UXデザイナー(UXD)の「PdM/UXD版もくもく会」をやってみたら、想像以上に「個人の学習」が加速してよかった話
をシェアします。

特に、具体的なビジュアルデザインフェーズの前、
要求定義や、新規立ち上げ等「顧客開発・ディスカバリー」フェーズでの個人の学習
を想定しています。

前半は、なぜ個人の学習が難しいのか、
後半は、その具体的な取り組みと展開方法についてです。

※HOWを手っ取り早く知りたい人は、目次の「PdM/UXD版もくもく会の全体像」からどうぞ!


この記事の10秒まとめ

内容をカンタンにまとめると、

① 顧客開発・ディスカバリーノウハウは、どうも身につきにくいよね
② ノウハウシェア・フィードバックをし合う「仲間」と「場」が持ちにくいから
③ そこで、「PdM/UXD版もくもく会」がおすすめ
④ 独りなら1ヶ月・半年とか時間すぎちゃう話が、1週間、1ヶ月で身になる経験・他の人の生々しい実践知を浴びるように獲得できる

という内容です。

【問題】PdM/UXDのディスカバリーはどうも身につきにくい

Q : PdMやUXDが、新規立ち上げ・ディスカバリーのスキルを学ぶためには何をすればいいの?

この問いについてのノウハウはたくさん出回っています。

・フェーズの全体像 : Idea Verification、PoC、Customer Problem Fit、Problem Solution Fit、Product Market Fit
・顧客開発、ディスカバリーの手法 : ユーザーストーリーマッピング、サービスブループリント、モックアップインタビュー、オズの魔法使い
・チーム作り : OKR、 アジャイル、 1on1など

この記事を読んでいる人なら、以下のような書籍や情報ソースは目にしたり触れたことがあると思います。

・ジョブ理論
・ユーザーストーリーマップ(オライリー)
・INSPIRED
・起業の科学
・UdemyのプロダクトマネージャーやUXD向け講座
・同じPdM/UXDをやっている人のnoteとかtwitter、slackグループ

ただ、実践となった時、
「自分は PdM/UXDとして学んだことが身についているのか?」
がわかりづらいと思います。

というのも、PdM・ UXDの仕事は、エンジニアと比較し、
ある種の曖昧さと個人依存性があると思っています。

スクリーンショット 2020-04-23 20.42.39

実際毎年行われている pmconf(PMカンファレンス)の基調講演やまとめのスピーチでも、
「 PM は体系化された決まったやり方というのはなくて、個別具体ケースの集積をどれだけするかだよね」
と言われてもいます。

こういう性質も相まって、成長実感が得られにくいことが多いと思います。

【原因】「仲間」と「場」がない

何があれば、成長・学習を実感しながら加速できるのでしょうか?

一般的に物事をなす際に重要な要素は以下の図で表せると思っています。

スクリーンショット 2020-04-30 11.17.51

しかしこの図には大事な要素が3つ欠けていると考えます。

スクリーンショット 2020-04-30 11.17.34

①フィードバック(仲間) : 自分が今抱えている課題を気軽に相談してフィードバックをもらえる仲間がいない
②プレッシャー(場) : 自分以外の人がどうやっているのか、自分が今やっていることはどうなのか、刺激を与え合う定期的な場がない
③実験の数(経験数):「わからない」を理由に忙しさに負けて行動を起こせない

こういった要素が欠けていることで、
PdM や UXDを孤独にし、
成長と学習スピードを鈍化させているのではないかと思います。

【解決策】仲間と場を作るPdM/UXD版もくもく会

では具体的にどうやってそれら(①②③)の要素を仕事の中で作っていくか?

PdM/UXDが「成長速度を早めたい」という課題に対して、
いくつか会社内で行われていることがあると思います。

・PdM/UXDグループ会:それぞれが担当しているプロダクトやサービスの状況や工夫・ナレッジポイントをシェアする
・デザイン相談会:具体的なデザインの相談やレビューを多角的に行う
・プロジェクト定例会議:進捗相談を行う
・1on1:個別の悩みやキャリアについて相談する

ただ多くの場合、それは「今抱えている」個人の課題や興味を満足させてくれるものではなかったりします。
個人の興味や問題意識に対して、時間投資先として優先度がどうしても低くなってしまいがちなんですね。

そこで見つけたのがエンジニアがよくやっている「もくもく会」です 。
もくもく会とはこのような位置づけのものです。

スクリーンショット 2020-04-23 20.54.52

引用) もくもく会のススメ

本来、内容は本当に様々ですが、
特定のツールや言語、 技術分野に興味がある人で集まってそれぞれの作業を黙々やり続けて終わる
というのが多かったりします。

このもくもく会を、社内の既存の会とは別の位置づけでやってみました。

画像20

※ よもやま:リクルートで、「特にアジェンダやゴールを設定せずざっくばらんに相談したい会」としてよく用いられる会

このもくもく会が、
・業務に短期的・直接的に直結はしないけど、個人的に興味が強いものを
・定期的・継続的に
・フィードバックを得ながら進められる
会として機能しました。

ただ、 冒頭で書いたように 、PdM/UXDの仕事は成果の品質やフィードバックが得られにくいという性質がありました。
この性質を踏まえて、 PdM・ UXD版にアレンジしてみました。

PdM/UXD版もくもく会の全体像

具体的に、今何をどのようにやっているかを説明します。

画像20

プロセス全体におけるポイントは、以下です。
イメージは、それぞれの鍛えたい部位を、みんなで集まって鍛える筋トレです。

◆ポイント① 興味関心からはじめる

・今、自分個人が問題意識・関心を持っていることをテーマに据える
・テーマ・目標・動き方も個々人に任せる。じゃないと続かない
・集まったメンバーで無理に一つのテーマに集約しようとしない

◆ポイント② 実験・経験重視

・受動的に情報提供を受けるのではなく、自主参加型
・目標設定やプランニングに時間をかけない
・半強制的・定期的な振り返りとアクションの方向修正で、学びを血肉にする

◆ポイント③ 学びを得るためのコミュニケーション

・自分だったらどうするか、という視点
・純粋な疑問を遠慮なく投げかける
・詰問ではない。そこにいるメンバーで学びを最大化するために集まっている

それでは、一つ一つのプロセスをどう工夫したか書いていきます。


Stage.1 スタートアップ(立ち上げ)

まずはざっくりもくもく会を設計します。

Stage.1-1 設計

テーマ

まず、もくもく会を立てる人は、追求するテーマを設定します。

スクリーンショット 2020-04-30 10.32.54

期間・頻度・時間

次に、活動の期間・頻度・時間( = 参加メンバーにどのくらいのコミットを求めるのか)を明確にします。
ここではカジュアルさを重視します。

スクリーンショット 2020-04-30 10.33.00

募集要件・人数

次に、どんな人に参加してほしいかを決めます。
みんなが参加する人気のもくもく会にしようなんてことはやめましょう。
ニッチでいいんです。その方が深く濃く追求できますから。

スクリーンショット 2020-04-30 10.33.08

進め方

スクリーンショット 2020-04-23 21.27.11

ガチめ(WG)なものとゆるいもの(もくもく)がありますが、ガチめなやつは用意する方も時間を要します。
忙しい中で継続的に活動を続けるのは大変なので、今回はゆるいもくもく会形式について書きます。

Stage.1-2 仲間集め

次に、仲間集めです。
slackとかで、グループやチームのみんなが見えるところで募集しましょう。
個人的に一緒にやりたい人がいたら、個別に誘いましょう。

スクリーンショット 2020-04-30 10.33.17

Stage.2 オリエンテーション

仲間が集まったら、まず初回に、今後の進め方などオリエンテーションします。

目的・スタンスセット

最初は、メンバーはどう参加すればいいかわからないと思うので、発起人が「こういう風にしたい」と提案してあげるとスムーズかと思います。
強調したいことは、
・「もらう」時間ではない
・自分で発見し、自分で得にいく時間
ということです。

スクリーンショット 2020-04-30 11.38.12

各人テーマ・ゴール設定

進め方を共有したら、各自の課題やチャレンジしたいことを、
個人テーマ・ゴール・期間に落とし込んでもらいます。

スクリーンショット 2020-04-30 11.41.14

スクリーンショット 2020-04-30 11.44.28

特に、ゴールは、小さく、かける期間を短くすることで、
ゴール設定に時間をかけすぎないようにします。
3日以上悩みより、まず動いて振り返って、解像度を上げていけばOK。

画像20

Stage.3 もくもく会サイクル

初回オリエンテーションが終わったら、いよいよもくもく会のサイクルです。
もくもく会は、以下の一連のフローをサイクルで毎週回していきます。

スクリーンショット 2020-04-30 11.58.21

Stage.3-1 開始前

1週間の成果報告をメンバー同士で行います。
当日(1h)は効率的にしたいので、ただの共有はオンラインで済ませます。
他のメンバーの成果報告で、気になることを当日質問すればよいです。
もちろん事前にオンラインでもOKです。

スクリーンショット 2020-04-30 11.47.14

Stage.3-2 もくもくKPT会

環境・ツール

ツールはGoogle Docsがいいです。
全員が同時間に同ドキュメントを編集するので、リアルタイム・共同編集が大事。
みんなが黙々と考えて書いている様が見えて面白い。

もくもくKPT(前半30分)

前半30分、みんなで集まって、もくもくとKPT会をします。
先週1週間、ゴールに向けて、各自自分の行動を振り返ります。
他の人の振り返りも見ながら、他人の頑張りや悩みへのコメントやリアクションするとどんどん学びが広がります。

スクリーンショット 2020-04-30 11.54.34

最後に、特に学んだK・Pの部分をメンバー同士で発表し合います。

おかわりトーク(後半30分)

お互いのKPT発表を読んで・聞いて、気になるところを質問します。
質問は、「自分だったらこうする」ってイメージとの差分を「なぜ?」と聞いていくと掘り下げられたりします。
質問する側は、質問することで視点や観点が手に入ります。
質問される側は、説明することでより学びが深まり強固になります。
ここでは、素朴な疑問や純粋な興味を何よりも大事にします。

Stage.3-3 開催後

見えてきた課題に対して、自分で設定したTRYを実行します。
タスクリストに入れ、優先度をセットし、とにかくやってみる。実験!!

このStage3-1〜3-3を、毎週繰り返します。
テーマやゴールが一定達成されたら、次のテーマを設定しても構いません。

Stage.4 最終発表

もくもくサイクルを繰り返してQや半期が終了したら、最終発表です。
最終発表があったほうがメリハリはつきます。
G会やチームに発表すると、学びがチームに還元されると同時に、
自分が個人的興味で追求してきたことがチームのためになると、
よりモチベーションが上がります。

そして、また次期のテーマを宣言し、新たに目標設定をしていきます。

【番外編1】リモート環境での工夫

最近はコロナ影響でリモートでの業務が前提となることも多いと思います。
リモート環境下でも、このPdM/UXD版もくもく会は有効です。
ただし「一緒にやる・(オンラインでも)集まる」のは続けるべきです。
特に「もくもくKPT」、「おかわりトーク」は時間を合わせてやりましょう。

理由は、2つです。

理由① 「一緒にやる」ことの半強制力

これはこのもくもく会の意義自体でもあります。
「各自で任意のタイミングでやっておく」だと、どうしても続きません。
実際、僕たちも忙しさなどで参加度が落ちました。
忙しい合間に半強制的に時間を確保し、そこでみんなでプレッシャーを与えながらやることが、この会を意義あるものにします。

理由②「(リモート)対面会話」のコミュニケーションコストの低さ

リモートは、目的のない会話が状況として作りにくいです。
できたとしても、テキストベースの非同期コミュニケーションです。
「自分が今学びたいことを」「瞬時に学ぶ」スピードが遅くなります。
対面はコミュニケーションコストが低いから、素朴な疑問やちょっとした興味で会話が活発にできる。それがこの時間の意義です。
ZoomやMeetなどでリモート会議ツールを使って同時間にもくもくしましょう。

【番外編2】(マネージャー観点)チーム内への広げ方

マネージャーの方々は、
「どうしたら、各人が自律的・スピーディに成長できるか?」
は大きなテーマだと思います。

特にPdMのマネージャーや、
上流工程に関わるUXDのマネージャーは、
このもくもく会が役に立つ可能性があります。

まず意欲が強い人で事例を作る

いきなり全員に勧めてもメンバーはどうしていいかわからないでしょう。
まずは、個人的に興味が強く、自分で色々動いてくれそうな人に、
PdM/UXD版でのもくもく会を紹介・提案してみると良いかもしれません。

まず一つ、事例を作ることができれば、
そこから全体に広げることもできると思います。

WGマップで、参加したくなるようにする

スクリーンショット 2020-04-30 11.35.03

事例を作った後は、特に継続性は問わず、もくもく会でもWGでも軽率に立てていくと良いです。
その際、今どんなワーキンググループがどんなテーマで走っているのか一目でわかる場所を作ると良いです。
もくもく会やWGを宣言して立てた人はこのマップとslackなどを通じて募集するようにして、クォーターや半期でマップを更新します。

あくまで興味ベースの自主参加で。参加必須にしない

参加必須にすると、上手くいかないと思います。
外部講師やメンバー持ち回りコンテンツをやろうとしても、
準備にパワーが取られ、長続きしません。
結果、メンバーはパワーを最低限にして、参加者にとってあまり意味のないコンテンツばかりが共有され時間の無駄になっていく懸念が出てきます。

別に特にテーマがない人は、参加しなくていいんです。
別にインプットでOKな人も、無理に参加する必要はありません。

ただ、完全にボランティアにしておくのももったいないです。
日々の業務と本人が関心のあるテーマを上手に関連付けられればパフォーマンスに良い影響を与えることができるかもしれません。
マネージャーは、可能な範囲で、本人の業務と関心テーマをすり合わせる必要があります。
※  関心テーマを業務へ、ではなく、業務を関心テーマと関連づける、です

まとめ

まとめます。

成果や成長実感が得られにくいPdM/UXDにとって、
業務以外での好奇心や興味を、
似た仲間と定期的に集まって、
自テーマの実験と振り返りを半強制的に共有し、フィードバックを受ける。
このPdM/UXD版もくもくサイクルで、成長・学習が加速する。

という話でした。

「あれやりたいなぁ」からやるまで、1ヶ月〜数ヶ月かかってないですか?
その時間、無駄です。
軽率にもくもく会を立てて、推進すれば、
忙殺されているうちに経過する時間で、はるかに血肉として学ぶことができます。

ぜひ試してみてください!



みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!

プロダクトデザイン室では、一緒に働く仲間を募集しています。