もくもくプロダクトマネジメント( @Nunerm )

プロダクトマネジメント・エンジニアリングマネジメントなどについて黙々と

CSPO研修(認定スクラムプロダクトオーナー研修)で学んだ「ROIを考え抜く姿勢」

今回はCSPO研修での学びをまとめます。

 

CSPO研修とは?

CSPOとは"Certified Scrum Product Owner"の略で認定スクラムプロダクトオーナーという意味です。認定スクラムトレーナー(CST)によって開催される Scrum Alliance 認定のCSPO研修を受けることで認定されます。

training.odd-e.jp

 

つまりこの研修を受けて認定されたら「あなたをスクラム開発のプロダクトオーナーとして認めます」となるわけです。

 

プロダクトオーナーとプロダクトマネージャーの違いは?

このブログは「プロダクトマネージャー」について書いていますが、プロダクトマネージャとプロダクトオーナーは違います。

 

まずプロダクトオーナーはスクラム開発の役割の一つです。よってスクラム開発をしていない組織ではプロダクトオーナーは存在しません。

 

続きを読む

プロダクトマネージャー・カンファレンス(pmconf)2018 2日目まとめ

前日に引き続きもちろん参加!

 

2018.pmconf.jp

 

今回も全網羅的ではなく、個人的に刺さった言葉をピックアップして解説します。

 

 

1.愛をお金に変えよう

2018.pmconf.jp

 

マネーフォーワード今井さん。

所用で席を外してたので全部聞けてはいないんですが、最後のまとめて「愛をお金に変えよう」と仰っていたところが「確かに大事なことだ」と思いました。

 

今回のカンファレンスのテーマは「愛されるプロダクトを創ろう」。

ただいわゆる「無償の愛」ではダメで、企業はそのプロダクトを継続的に成長させる責任がある。そのためにはやはりお金を稼ぐこと、カスタマーやクライアントからお金を頂くことは必要なのです。

 

よって重要な観点は「プロダクトで得た愛をいかに効率よくお金に変えるか」で、マネーフォーワードで言えばより上位のプランにシフトしてもらうためにどのような価値を提供するか。

Appleはいい例で、ユーザーからの猛烈な愛をうまくお金に変えられる仕組み(例:高単価なiPhoneやその付属品、値引きしないスタンス)を作っている。要はユーザーがお金を出すことに対する納得感を醸成できるかが鍵。

これは完全にPMの腕の見せ所で、ブランディングやPR、CSなども合わせて戦略を立てないといけない。

 

愛とお金を稼ごう。

 

続きを読む

プロダクトマネージャー・カンファレンス(pmconf)2018 1日目まとめ

今年もプロダクトマネージャー・カンファレンスに行ってまいりました!

昨年に続き多くの学びと刺激をもらいに来ました。

 

1日目のまとめを書きます。

2018.pmconf.jp

 

全網羅的ではなく、個人的に刺さった言葉をピックアップして解説します。

 

1.Cut featureとWon't fixはPMだけが言えること

2018.pmconf.jp

楽天トラベルの熊谷さん。

楽天トラベルは国内でのシェアは強いものの、旅行市場においては国内旅行者の減少と海外サイト(Booking.comなど)の参入もあって、世界に出て行く決断をしたそうです。

 

世界で愛されるプロダクトになるために3つのポイントを挙げていただきました。

  1. Generalize
  2. Communication
  3. Decision Making

 

※ちなみにこの3つの定義はpmconf2017でも楽天トラベルの齊藤さんが提言されていました楽天に根付く考え方なんですね。

 

Generalizeは最初に機能のRequirementを定義するときにGeneralize、つまり何か特定のセグメントやドメインに特化せずに一般化することが大事ということ。

海外進出する際のハードルとなるのが、タイムゾーンや法律、個人情報の扱い(最近GDPRが話題です)など。これを考慮して一般化して設計することで、スピーディーに海外展開できる。

 

次の2つは海外に限った話ではなく、PMとして持っておくべき考え方です。

Communicationは"Positive"(問題は必ず解けるというスタンス)と"Open Communication"(しっかり議論して問題の本質を紐解く)という姿勢を持つべきとのこと。

 

そして最後のDecision Making

f:id:swnws322:20181106232550j:plain

バグトリアージのルールはこんな感じらしい。

ただ実際このHighとLowって定量的に仕分けるのってすごく難しく、各ステークホルダーの視点によっても変わってくる。例えばCSにとってはユーザーが最優先だけど、営業にとってはクライアントが最優先。

 

ここで重要な考え方がこちら。

 

Cut feature & Won't fix はPMだけが決められること

 

これはPMにとって本当に重要な役割。

「何がプロダクトの成長に繋がるのか」を一番知っているPMが「削る」と「やらない」をDecision Makingしないといけない。そしてその決定がプロダクトにとって最適でないといけない。

 

さらにはその決定をステークホルダに納得してもらうためには、普段からしっかりとCommunicationをして信頼を勝ち得ないといけない。

 

これ簡単に言うけどめちゃくちゃ難しいことです。個人的にはPMとして1人前かどうかはこれができているかどうかで評価できると思ってます。

 

PMとしての「あるべき姿」を再認識することができました。

唯一「やらないことを決められる」という責任感を持って生きていきます。

 

続きを読む

心理的安全性を0から80ぐらいに上げた話

心理的安全性について話したLTのスライドがバズった…!

www.slideshare.net

 

Roppongi Product Manager Meetup #6のLT枠で発表したこのスライドがはてブTwitterでちょっとバズったので補足記事を書きます。

スライドだけでは伝えられない部分も多くあるので。

 

b.hatena.ne.jp

 

続きを読む

心理的安全性の高いチームの作り方と落とし穴

プロダクトマネジメントを進めるにあたって、チーム作りは非常に重要な要素です。

 

私は以前崩壊寸前のアプリ開発チームの立て直しを命じられ、プロダクトマネージャー兼開発ディレクターとしてジョインしました。

前任のマネージャーが「支配型」のタイプで、細かいところまで指示をしミスをしたら叱責をする。反発しようもんならさらに叱責をする。そういう状況で開発を続けてきた結果、エンジニアメンバーのモチベーションがどんどん下り、さらにどんどん辞めていき、プロダクトの品質も悪化の一途を辿っていました。

私は1年弱試行錯誤して何とかようやくチームらしいチームにすることができました。その立て直しの際に重要視したのが「心理的安全性」ですので、簡単に紹介したいと思います。

 

 

心理的安全性とは?

 心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。

(引用元:re:Work - ガイド: 「効果的なチームとは何か」を知る)

つまり、チーム内で安心して発言や行動できる心理状態をメンバーが持てていることを示します。「意見を言っても大丈夫」「質問しても大丈夫」とメンバー全員が思える状態です。

 

続きを読む

プロダクトマネージャーが新しい技術をざっくり理解する 〜イーサリアム編〜

「想像するため」に新しい技術をざっくり理解する

日々新しい技術が生まれ、世界中で活用事例がどんどん増えています。

プロダクトマネージャーたるもの、自分のプロダクトの新しい機能やサービスを常々考える必要がありますが、人間は持っている知識の範囲の中でしか想像できません。


「顧客・ユーザはは自分が何が欲しいのかわかっていない」という例でよく引用されるヘンリー・フォードの言葉で

「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう。」

というものがあります。

これはプロダクトマネージャーにも言えることだと思います。知らない技術のことは想像できません、例えば『ユーザに便利なレコメンド機能を提供したい』と思っても、機械学習のことを知らなければどう実現していいのかわからず、機能実現のための思考も止まってしまいます。たまたま周りに詳しい人がいればいいですが、それはもはや運任せです。

ただし、機械学習の基本的な仕組みを知っていれば、「あ、あの技術使えばできるかも…」と気づくことができます。具体的な実現方法検討フェーズに入ったら、詳しい人の助けを得ればいいのです。

 

とはいえ、全ての技術をしっかり習得するのは大変なので、私は「新しい技術をざっくり理解する」ことにしました。あくまでざっくりです。

 

イーサリアム

まずは最近話題のブロックチェーン、特にビジネス領域で活用が期待されているスマートコントラクトを実現できるイーサリアムをざっくり理解してみました。

 

まずはブロックチェーンの基礎的な内容はこの本で理解しました。

タイトル通りかなりわかりやすくまとまっているので、最低限暗号化の仕組みを知っていれば理解できる内容になってます。

またスマートコントラクトについてはこの本で理解しました。

 スマートコントラクトがどのようなサービスに活用されているのか、どういう仕組みなのかを理解できます。後半はSolidityでの開発まで言及されますが、ちょっと古いのと基礎的な内容なのでサービスやプロダクトにどう役立てればいいのかのイメージが湧きづらいので、もう一つCryptoZombiesというサービスを使ってみました。

cryptozombies.io

これはSolidityを実際に開発してゾンビ生成ゲームを作れるサービスです。

始めるにあたって必要なものはGoogle or Githubのアカウントだけ。全てブラウザ上でプログラミングできるので、開発環境の準備などは一切不要です。

また以下キャプチャのように説明とエディタが1画面にまとまっており、説明も非常にわかりやすいです。

f:id:swnws322:20180603154218p:plain

基本的にチャプターごとに一つずつ新しいことを説明し、それに対してテストを行い答え合わせする、という流れです。

間違っていても答え合わせで正しいコードを教えてくれるので、途中で止まってしまうこともありません。

f:id:swnws322:20180603154624p:plain

説明通りに実装していけば、可愛い(?)ゾンビが作れるゲームが完成します。

f:id:swnws322:20180603154757p:plain

現時点ではレッスン6までしか公開されていませんが、今後も楽しみです。

 

 

これでざっくりスマートコントラクト・イーサリアムの技術を理解することができました。さすがにいきなり新しいDAppが作れるほどのスキルは身についていないですが、ざっくり仕組みを理解することができたので、想像ぐらいはできるはずです。

 

次はディープラーニングについてざっくり理解しようと思います。

UX DAYS TOKYOイベント「セルフユーザビリティテスト検定講座」

 

UX DAYS TOKYO主催のイベント「セルフユーザビリティテスト検定講座」に参加してきました。

uxdt.connpass.com

 

UX DAYS TOKYOとは?

 国内最大級のUXカンファレンス&ワークショップを主催する団体です。

 

ユーザビリティテストとは?

Webサイトやアプリなどのサービス・プロダクトを実際に目の前で利用してもらい、その時の行動や発言、感情の変化などを記録してそのサービス・プロダクトの問題点を見つける手法です。

 

サービス・プロダクトを提供する側がユーザーの心理や求めているものを100%理解することはほぼ不可能です。「これはイケてるから使われるだろう」と思っていても、実際はユーザーから不評だったり、全く求められてなかったりするケースは数多くあります。

提供者はそのサービス・プロダクトのことばかり考えるためある種の「思い入れ」が強くなるので、初めてそのサービス・プロダクトに出会うユーザーの心理を想像できなくなっているのです。

ユーザビリティテストによってユーザーの心理を改めて理解し、それに合わせたサービス・プロダクト改善をしていくことが重要です。

 

またサービス・プロダクトの開発組織における「UI/UX改善の促進」にも役立ちます。

ありがちなのが「なんとなくデザインがイケてないのはわかるけど、具体的に何を直せばいいのかわからない」という状態で、UI/UX改善の優先度がずるずる下がること。これほんとありがち。

自分は開発チームなのですが、デザインはデザインチームにお願いしてます。デザインを受け取る際に「正直イケてないと思うんだけど、具体的に何が悪いか説明できないから、デザイナーさんに言いづらいな…」ということがよくあります。無下に「ダサい!」とか言ったら絶対ケンカになります。

デザイナーはあくまで「自分がいいと思うもの」を作っているので、そこに必ずしもユーザーの求めているものが含まれている訳ではありません。ユーザビリティテストによってユーザーの意見が明確になれば、「ユーザーからこういう意見が出てるから直しませんか?」と非常に言いやすくなります。

 

ユーザビリティテストについては以下サイトにわかりやすくまとまっているのでご参考までに。

popinsight.jp

 

 

ユーザビリティテストの問題点

何より「時間とコストがかかる」ことです。

実際のユーザーの方に会社まで来てもらって、個人情報がどうたらこうたら説明して、謝礼を払って…

また雑な対応をしてしまうと、そのユーザーの方に悪い印象を与えてしまうので、気軽にはなかなかできません。

 

 

セルフユーザビリティテスト

そこでセルフユーザビリティテストです。これは「まずは気軽にやってみよう」という手法です。会社の同僚や家族、友人にユーザーとなってもらってユーザビリティテストを行います。

 

このイベントではそのやり方の説明と検定試験、あと2度の実践を行いました。

↓こんな感じ (2枚目奥の白シャツが自分です)

 

座学パートでは色々な事例を交えながらユーザビリティテストの有効性などを説明していただきました。

 

例えば人間の脳にはシステム1/システム2があるという話。

 システム1:考えなくても直感で理解できる
 システム2:しっかり考えて理解できる

検索やフォームの入力などは極力システム1で完結できるユーザビリティが必要です。そこに「じっくり考えないと次に進めないデザイン」が紛れていてはいけません。

 

 

テストパートでは説明パートの内容をテストされました。

合格するとこんな証明書をもらえますよ(・∀・)v

f:id:swnws322:20180526152104p:plain

 

最後の実践パートはでは3人1組になって実際にセルフユーザビリティテストを行いました。モデレータ・ユーザ・記録者になって、とあるユーザビリティがダメダメなサイトを使って「〇〇の情報を調べてください」のいったタスクをユーザがトライします。

 

これから参加する方にネタバレになるので言いませんが、かなりひどいサイトでした笑

 

この実践パートでは色々と気づきがありました。実際ユーザになって不便だと思うところを声に出して表してみると、思った以上に色々なことに不便さを感じていることに気づきました。例えば、求めている情報がページ上ですぐ見つからない時に何度も上下スクロールするのは条件反射のようにやってしまってますが、「なかなか見つからない…」と声に出して改めてこれは小さいストレスであることを再認識しました。

 

 

ただやっぱりいきなり良いテストができた訳ではなく、もっと上手にユーザーの意見や心理を引き出せないといけません。これはもう場数を踏むしかない。

なのでセルフユーザビリティテストで身近な人で練習させてもらい、慣れて来たら実際のユーザを呼んでユーザビリティテストをやり、自分のプロダクトの改善につなげたいと思います。

【スポンサーリンク】