心理的安全性の高いチームの作り方と落とし穴
プロダクトマネジメントを進めるにあたって、チーム作りは非常に重要な要素です。
私は以前崩壊寸前のアプリ開発チームの立て直しを命じられ、プロダクトマネージャー兼開発ディレクターとしてジョインしました。
前任のマネージャーが「支配型」のタイプで、細かいところまで指示をしミスをしたら叱責をする。反発しようもんならさらに叱責をする。そういう状況で開発を続けてきた結果、エンジニアメンバーのモチベーションがどんどん下り、さらにどんどん辞めていき、プロダクトの品質も悪化の一途を辿っていました。
私は１年弱試行錯誤して何とかようやくチームらしいチームにすることができました。その立て直しの際に重要視したのが「心理的安全性」ですので、簡単に紹介したいと思います。
心理的安全性とは？
心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。
つまり、チーム内で安心して発言や行動できる心理状態をメンバーが持てていることを示します。「意見を言っても大丈夫」「質問しても大丈夫」とメンバー全員が思える状態です。
続きを読む
プロダクトマネージャーが新しい技術をざっくり理解する 〜イーサリアム編〜
「想像するため」に新しい技術をざっくり理解する
日々新しい技術が生まれ、世界中で活用事例がどんどん増えています。
プロダクトマネージャーたるもの、自分のプロダクトの新しい機能やサービスを常々考える必要がありますが、人間は持っている知識の範囲の中でしか想像できません。
「顧客・ユーザはは自分が何が欲しいのかわかっていない」という例でよく引用されるヘンリー・フォードの言葉で
「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう。」
というものがあります。
これはプロダクトマネージャーにも言えることだと思います。知らない技術のことは想像できません、例えば『ユーザに便利なレコメンド機能を提供したい』と思っても、機械学習のことを知らなければどう実現していいのかわからず、機能実現のための思考も止まってしまいます。たまたま周りに詳しい人がいればいいですが、それはもはや運任せです。
ただし、機械学習の基本的な仕組みを知っていれば、「あ、あの技術使えばできるかも…」と気づくことができます。具体的な実現方法検討フェーズに入ったら、詳しい人の助けを得ればいいのです。
とはいえ、全ての技術をしっかり習得するのは大変なので、私は「新しい技術をざっくり理解する」ことにしました。あくまでざっくりです。
イーサリアム編
まずは最近話題のブロックチェーン、特にビジネス領域で活用が期待されているスマートコントラクトを実現できるイーサリアムをざっくり理解してみました。
まずはブロックチェーンの基礎的な内容はこの本で理解しました。
タイトル通りかなりわかりやすくまとまっているので、最低限暗号化の仕組みを知っていれば理解できる内容になってます。
またスマートコントラクトについてはこの本で理解しました。
スマートコントラクトがどのようなサービスに活用されているのか、どういう仕組みなのかを理解できます。後半はSolidityでの開発まで言及されますが、ちょっと古いのと基礎的な内容なのでサービスやプロダクトにどう役立てればいいのかのイメージが湧きづらいので、もう一つCryptoZombiesというサービスを使ってみました。
これはSolidityを実際に開発してゾンビ生成ゲームを作れるサービスです。
始めるにあたって必要なものはGoogle or Githubのアカウントだけ。全てブラウザ上でプログラミングできるので、開発環境の準備などは一切不要です。
また以下キャプチャのように説明とエディタが１画面にまとまっており、説明も非常にわかりやすいです。
基本的にチャプターごとに一つずつ新しいことを説明し、それに対してテストを行い答え合わせする、という流れです。
間違っていても答え合わせで正しいコードを教えてくれるので、途中で止まってしまうこともありません。
説明通りに実装していけば、可愛い（？）ゾンビが作れるゲームが完成します。
現時点ではレッスン６までしか公開されていませんが、今後も楽しみです。
Web3.jsの仕組みがわかったので「どうやってコントラクトを呼び出すのか」が理解できた。一旦公開されているレッスンは完了！(・∀・)#CryptoZombies のレッスン６が完了！レベル3.0のクリプトゾンビ'The Phantom of Web3'をゲットしたよ!ゾンビ軍団が大きくなってきた！😉 https://t.co/SPdvJabsTq
— Hisatsu Yusuke (@Nunerm) June 3, 2018
これでざっくりスマートコントラクト・イーサリアムの技術を理解することができました。さすがにいきなり新しいDAppが作れるほどのスキルは身についていないですが、ざっくり仕組みを理解することができたので、想像ぐらいはできるはずです。
次はディープラーニングについてざっくり理解しようと思います。
UX DAYS TOKYOイベント「セルフユーザビリティテスト検定講座」
UX DAYS TOKYO主催のイベント「セルフユーザビリティテスト検定講座」に参加してきました。
UX DAYS TOKYOとは？
国内最大級のUXカンファレンス＆ワークショップを主催する団体です。
ユーザビリティテストとは？
Webサイトやアプリなどのサービス・プロダクトを実際に目の前で利用してもらい、その時の行動や発言、感情の変化などを記録してそのサービス・プロダクトの問題点を見つける手法です。
サービス・プロダクトを提供する側がユーザーの心理や求めているものを100%理解することはほぼ不可能です。「これはイケてるから使われるだろう」と思っていても、実際はユーザーから不評だったり、全く求められてなかったりするケースは数多くあります。
提供者はそのサービス・プロダクトのことばかり考えるためある種の「思い入れ」が強くなるので、初めてそのサービス・プロダクトに出会うユーザーの心理を想像できなくなっているのです。
ユーザビリティテストによってユーザーの心理を改めて理解し、それに合わせたサービス・プロダクト改善をしていくことが重要です。
またサービス・プロダクトの開発組織における「UI/UX改善の促進」にも役立ちます。
ありがちなのが「なんとなくデザインがイケてないのはわかるけど、具体的に何を直せばいいのかわからない」という状態で、UI/UX改善の優先度がずるずる下がること。これほんとありがち。
自分は開発チームなのですが、デザインはデザインチームにお願いしてます。デザインを受け取る際に「正直イケてないと思うんだけど、具体的に何が悪いか説明できないから、デザイナーさんに言いづらいな…」ということがよくあります。無下に「ダサい！」とか言ったら絶対ケンカになります。
デザイナーはあくまで「自分がいいと思うもの」を作っているので、そこに必ずしもユーザーの求めているものが含まれている訳ではありません。ユーザビリティテストによってユーザーの意見が明確になれば、「ユーザーからこういう意見が出てるから直しませんか？」と非常に言いやすくなります。
ユーザビリティテストについては以下サイトにわかりやすくまとまっているのでご参考までに。
ユーザビリティテストの問題点
何より「時間とコストがかかる」ことです。
実際のユーザーの方に会社まで来てもらって、個人情報がどうたらこうたら説明して、謝礼を払って…
また雑な対応をしてしまうと、そのユーザーの方に悪い印象を与えてしまうので、気軽にはなかなかできません。
セルフユーザビリティテスト
そこでセルフユーザビリティテストです。これは「まずは気軽にやってみよう」という手法です。会社の同僚や家族、友人にユーザーとなってもらってユーザビリティテストを行います。
このイベントではそのやり方の説明と検定試験、あと２度の実践を行いました。
↓こんな感じ （２枚目奥の白シャツが自分です）
座学パートでは色々な事例を交えながらユーザビリティテストの有効性などを説明していただきました。
例えば人間の脳にはシステム１/システム２があるという話。
システム１：考えなくても直感で理解できる
システム２：しっかり考えて理解できる
検索やフォームの入力などは極力システム１で完結できるユーザビリティが必要です。そこに「じっくり考えないと次に進めないデザイン」が紛れていてはいけません。
テストパートでは説明パートの内容をテストされました。
合格するとこんな証明書をもらえますよ(・∀・)v
最後の実践パートはでは３人１組になって実際にセルフユーザビリティテストを行いました。モデレータ・ユーザ・記録者になって、とあるユーザビリティがダメダメなサイトを使って「〇〇の情報を調べてください」のいったタスクをユーザがトライします。
これから参加する方にネタバレになるので言いませんが、かなりひどいサイトでした笑
この実践パートでは色々と気づきがありました。実際ユーザになって不便だと思うところを声に出して表してみると、思った以上に色々なことに不便さを感じていることに気づきました。例えば、求めている情報がページ上ですぐ見つからない時に何度も上下スクロールするのは条件反射のようにやってしまってますが、「なかなか見つからない…」と声に出して改めてこれは小さいストレスであることを再認識しました。
ただやっぱりいきなり良いテストができた訳ではなく、もっと上手にユーザーの意見や心理を引き出せないといけません。これはもう場数を踏むしかない。
なのでセルフユーザビリティテストで身近な人で練習させてもらい、慣れて来たら実際のユーザを呼んでユーザビリティテストをやり、自分のプロダクトの改善につなげたいと思います。
心に刺さるビジョン・ミッションの語り方の考察
プロダクトマネージャーとして「ビジョン・ミッションを語る」ことは非常に重要です。
素晴らしいプロダクトを創るために、ステークホルダーやチームメンバーと同じ方向を向く必要があります。その陣頭指揮を取るPMがビジョンやミッションを語らねばならんのです。これがPMが「ミニCEO」と呼ばれる一因かもしれませんね。
それはさておき…
自己紹介記事にも書いた通り、私はリクルートテクノロジーズで働いています。
で、４月は期初ということもあり、今期のビジョン・ミッションの説明があったのですが、同じ週にある事情でリクルートと関係のない企業（以下、A社）のビジョン・ミッション説明の場にも参加しました。
そこで思ったこと。
「話している内容は似ているのに、心への刺さり方が全然違う…( ；ﾟДﾟ)」
リクルートテクノロジーズの方が圧倒的に心に刺さって、「やったるぞ(#ﾟДﾟ)！」というモチベーションが湧き上がってくるのです。
どちらも話の構成は以下のような感じです。
・昨年の振り返り
・ミッション
・今期のビジョン
・優秀な社員の表彰
なのに全然違うんです。まあリクルートテクノロジーズ（以下、RTC）の社長がイケメンで話し上手なせいかもしれませんが、あまりにも違いすぎたのでちょっと考察してみることにしました。もちろん具体的な内容は明かせませんが。
キーワードは「距離感」「現実感」です。
続きを読む
"Product Management Exercises"というPM道場
面白いサイトを見つけました。
Product Management Exercises -
I have created this website as a free resource to help product managers sharpen their PM skills and prepare for PM job interviews.
I post job interview product management exercises on the blog and invite readers to submit their answers to the exercises and to post their thoughts on each other’s solutions.
About this site - Product Management Exercises より
「 PMの面接で聞かれるであろう質問をブログで投稿するので、そのコメント欄に答えを投稿したら添削するぜ！」というサイトですね。ほとんど文字だけのシンプルなサイトです。ところどころリンク切れもありますが…笑
また作者のBijanさんの情報がなく何者なのかわかりませんが、気にせず読んで見ました。
続きを読むUX DAYS TOKYO 2018 ワークショップ "顧客が望むプロダクトをつくりだせ 〜JTBD の実践的アプローチ〜" by Jim Kalbach
UX DAYS TOKYO 2018のワークショップに参加してきました！（最近イベントの記事ばっかり書いてるなあ…）
UX DAYS TOKYOとは？
国内最大級のUXカンファレンス＆ワークショップを主催する団体です。
ワークショップ
今回受けたワークショップはこちら。
"顧客が望むプロダクトをつくりだせ 〜JTBD の実践的アプローチ〜"
MURALという企業で顧客満足を管理する部門のリーダーであるJim Kalbachさんのワークショップです。O'Reillyの「マッピングエクスペリエンス」の筆者ですね。JTBD(Jobs To Be Done)を実践で役立てるための考え方と具体的なアプローチを教えていただきました。
続きを読む
【スポンサーリンク】
