プロダクトマネージャーカンファレンス 2019 2日目。1日目の昨日に引き続き参加。
以下タイトルは公式サイト掲載のものより。
横道稔氏。
株式会社シークレットラボ代表取締役 / エクスペリエンスデザイナー 佐藤 伸哉 氏
デザインスプリントの概論。実体験に基づくポイントの話が興味深かった。
個人の力を重視し、声の大きさを排除する。
その他ポイント。
株式会社メルカリ Director of Product Management, Mercari US in Tokyo Brad Ellis 氏
フレンドリーで愉快なおじさん風なのだけれど、すごい経歴の Brad Ellis 氏。楽しくトークを聞くことができた。
グローバルな組織では「多様性」「共有」「期待の明確化」「Internal PR」などが大切とのこと。グローバルなプロダクトに対しては「各ローカル(国、都市と地方)に合わせていくこと」の重要性を話されていた。また優れたサービスを先行してる国(例えば日本)から他の国へ展開していく事例についても紹介されていた。
始めの方にあった「You are not the user」では昨日の増井氏の発表を思い出しておかしくなったよ。
Smule, Inc Head of Product in AI (Principal Product Manager) 曽根原 春樹 氏
PM の考え方のシャープなセッション。「Think big」「上手に失敗する」。
株式会社プレイドプロダクトマネージャー 棚橋 寛文 氏
KARTE の事例。
日経の方の話が一番しっくりくるし実践されている PM の話だった。他のお二方のは立場が違うのかちょっと雰囲気が違う感じ。
プロノイア・グループ株式会社 CEO(Chief Executive Officer) ピョートル・フェリクス・グジバチ 氏
「OKR っていう言葉は使わなくたっていいじゃん」
「承認 x 感謝」が大切で、マネージャーとして次のような態度を常にもっている必要がある。
Tably株式会社 小城 久美子 氏
プロダクトの Core・Why・What を決めていくプロセスのフレームワークの紹介を実践を通じて説明。とてもわかりやすく参考になった。
キーワード: 「リーンキャンバス」「PRD」「インセプションデッキ」「バリュープロポジションキャンバス」「ユーザーストーリーマッピング」
日産自動車株式会社 コネクティドカー&サービス技術開発本部ソフトウェア&ユーザーエクスペリエンス開発部アプリケーション&サービス開発グループ主担(プロダクトマネージメント)海老澤 雅之 氏
ソフトウェア開発をウォーターフォール開発からアジャイル開発したよという話と、アプリの紹介。
今日はここで退散。
先週8月19日(水)に『社員の力で最高のチームをつくる〈新版〉1分間エンパワーメント』を買って読んでいる。一昨日の「第1の鍵」に続き、今日は「第2の鍵」を。
エンパワーメントの「第2の鍵」は以下。
境界線を引いて、自律的な働き方を促すこと。(Create autonomy through boundaries.)
「境界線って何?」とひっかかる。で読んでみると
と書かれていた。 組織の MVV 的なものを明確にし、チーム・個人に浸透させ、それぞれ役割と目標をもって主体的に動けるようにしよう。王道な話であった。
トップが「ビジョン(イメージ→目的→価値観)」を立て、全員でビジョンから個人の「役割と目標」に落とし込む。ビジョンを「全社員で磨きをかける」ってどうやるのだろうと思ったけれど、ビジョンの内容や表現をワイガヤ作っていくのではなく落とし込むことを言っているようだ。
トップが信念(belifes)から価値観を明確にし、全員で価値観からルール・業務に落とし込む。「ルールを作るのは社員」というのがここではポイントだな。
「組織の構造とシステム」は報酬体系だったり承認ルールだったりを指している。エンパワーメントを妨げるものがあれば解決していこうという話。
王道な話なんて書いたけれど、やり切るには強い意志、それから時間が必要だと。
[ 読書ノート ] [ 行動原則 ] [ Naney の行動原則 ]
動機づけ観点で褒めることの是非について、ちょっと再確認してみた。
「行動・過程」に感謝する(あるいは褒める)。「結果・成果」を褒めない。金銭的な報酬を期待させない。
「外発的動機づけ」により「内発的動機づけ」が高まる「エンハンシング効果」を起こす。
「内発的動機づけによる行動」に対して「外発的動機づけ」することにより動機づけが下がる「アンダーマイニング効果」を起こさないようにする。
組織において表彰制度を実施する場合は「競争」と「動機づけ」について相当な注意を払う必要がある。
ピープルウエアでは「何かチーム内の競争心をあおるようなことをしたら、チーム殺し的と見なければならない。」(第2版 第28章 競争 p.235 より)
と競争についての問題を述べている。
表彰されるための行動は外発的動機づけによるもの。
Joel on Software の第21章「報奨金有害論」では、 Microsoft の「Ship It」アワードについて「従業員たちが子供のように扱われていると感じていることが明らかになった。」と述べている。
外発的動機づけされようとしていることについての反発だろう。
OKR についての書籍『Measure What Matters』では承認について
特別なプロジェクト、会社の目標の達成、会社の理念を体現する行為など、従業員の行動や成果を認める。「今月の従業員」を表彰する代わりに「今月の成果」を表彰する。
とし人ではなく「行動や成果」を表彰することを勧めている。外発的動機づけとしては「成果」よりも「行動」を褒める(成長承認する)ことに重点を置いた方が良いだろう。
行動を起こさせる程度だがその行動すべてを正当化できない程度の報酬にする。そうすると人は認知的不協和を解消しようと他の動機(内発的動機)を見つけようとする。
[ opinion ]
1月16日(土)にβ版が公開された「3人でつながる未来の友だちマッチングサービス」 MEEET に水曜日に招待していただいたの、今日登録してみた。
Facebook 連携での会員登録時に「友達リスト」の権限を要求されたが、 Facebook のソーシャルグラフを持ち込んでも面白くないので拒否。「氏名とプロフィール写真」(必須)のみで登録した。必須にしている権限だけ問題なくサービス利用開始できたのはいい作り。
「右にスワイプで Like」という操作、地味にどっちが「右にスワイプ」か不安な気持ちになった。右にスワイプと右からスワイプで一瞬混乱した(なお、スワイプではなくて下にあるアイコンでも振り分けできた)。
利用規約が「2020年5月24日 制定・施行」で「最終更新日 2019/07/29」となっていてそういうところまだゆるい感じ。プライバシーポリシーは「2020年5月24日 制定・施行」で「最終更新日 2020/05/24」とこちらはズレなし。
まだ最低限の実装での仮説検証プロセス段階なので、今後どう成長していくのか(あるいはコケるのか)楽しみ。
「共通の友だち」が承認する(MEEETする)とコミュニケーションが始まる仕組みになっているのが目新しい。仲人が同席しているので何か話そう(あるいは話さねば)という意識が働くのかもしれない(まだ1件しか MEEET されてないのでこれから)。
(画像は https://meeet.jp/hello スクリーンキャプチャより)
問題に取り組む前に「今本当に答えを出す価値のある問題(イシュー)」かどうかを見極める。そしてスタンスをとり、イシューに対して「問い」ではなくいきなり「答え(仮説)」を出す。
という考え方を紹介しているのが『イシューからはじめよ』だ。いかにして意味のある仕事を選択し成果を出していくかかが説明されている。
「問題を見極める」重要性をここまで明確にしているのを読んだのは本書が初めてだ。仮説思考の徹底ぶりもすごい。この2点を常に意識できるようになれれば本書を読んだ価値があるだろう。
第1章から「イシューからはじめる」アプローチ
について各章でポイントを解説している。ソリューションを考え出してプレゼンテーションをまとめる際に何度も読み返したい。
個人的に刺さったのは「イシューと仮説は紙や電子ファイルに言葉として表現することを徹底する。」というくだり。やはり「文章で書く」こと大切だよね。
本書を知ったのは Developers Summit 2019 の「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2019」プレゼン大会。同年のビジネス書部門大賞となっている。その後2020年5月に思い出して読んだ。読書ノートをまとめてなかったので、読み直してみたのが今日だ。
本書では問題設定から問題解決案/論文のアウトプットまでが主なスコープで、読んだ多くの人がコンサルティング的な仕事を思い浮かべるのではないだろうか。
ネットサービスのプロダクトマネジメントでは、承認を得るのがゴールではなくユーザーに価値を届けて成果を出すのがゴールである。仮説検証の段階でプロダクトをリリースしてできるだけ早くフィードバックを得て、検査と適応を繰り返していく。ライトウェイトなループの中にうまく本書の考え方を取り込んでいきたい。
仕事をしていると「確認お願いします」と言ったり言われたりしがち。
「はっきりさせてください」の意味にしか取れないなら問題ない。
(ドキュメントなどの)成果物ついての「確認お願いします」と言われると
のどれなのか不明確で気持ち悪く感じることがよくある。頼まれた側だった場合、つい面倒に感じてあいまいに「確認しました(=見ました)」と返事してしまって、良くなかったなあとなってしまったりする。
明確なリクエストになるよう言葉を選ぶよう気をつけよう。あいまいなリクエストを受け取った際にあいまいに返事をしないよう気をつけよう。
以上、ご確認お願いします。
[ opinion ]
11月30日にウェイティングリストに登録した Post から参加承認のメールが一昨日届いたので、本日登録してみた。ハンドル (現在のところ変更不可) は6文字以上ということで長い方で登録。
ニュースコンテンツを念頭においたソーシャルメディアのようだ。
ポストはリッチテキストでペイウォール設定できる。またポイントでチップを支払える機能もあり。 Following 以外に Explore というパブリックタイムラインぽいものがあるのが、サービス初期のソーシャルメディアらしい。
プロフィールの URL は下記に変更になっていた。
「確認お願いします」と言われた時に
と「事実か・正しいか」という元来の意味でのリクエストではなく
という「意見・意思決定」についてのリクエストではと感じることがある。聞くと実際そうだったりする。時には
とのリクエストの場合もある。
元来の意味でも「正しいと認めてください」と「正しいか確かめてください」では依頼された側が必要な労力が全く違ってくる。
「確認お願いします」と言いたくなったら、本当は何を求めたいのかきちんと自問したい。返答する時も「確認しました」で済ませがちなので、リクエストにあった言葉を選びたい。
以上ご確認お願いいたします。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。