nDiki : 承認

プロダクトマネージャーカンファレンス 2019 2日目 #pmconfjp

プロダクトマネージャーカンファレンス 2019 2日目。1日目の昨日に引き続き参加。

• プロダクトマネージャーカンファレンス 2019 1日目

以下タイトルは公式サイト掲載のものより。

10:00 - 10:10 [MainRoom] Welcome Talk

横道稔氏。

10:20 - 11:10 [MainRoom] 今からはじめるデザインスプリント

株式会社シークレットラボ代表取締役 / エクスペリエンスデザイナー 佐藤 伸哉 氏

デザインスプリントの概論。実体験に基づくポイントの話が興味深かった。

• ステップのポイント
  • Map: 全員が自分でメモを取る。
  • Sketch: 個人で考える。
  • Decide: 個人の主観でアイデアを即決する。投票で選ぶ。
  • Test: ユーザーインタビューは5人で十分。
• Google 流では6ステップ。DEFINE が入った。

個人の力を重視し、声の大きさを排除する。

その他ポイント。

• アイデア出しで使った付箋紙は捨てる。覚えていないアイデアは捨てる。
• スケジュール通りに進むとは思わない。

11:20 - 11:50 [MainRoom] 米国スタートアップ&グーグルを経て実践する、失敗し続けて学んだメルカリUSのプロダクトマネジメント

株式会社メルカリ Director of Product Management, Mercari US in Tokyo Brad Ellis 氏

フレンドリーで愉快なおじさん風なのだけれど、すごい経歴の Brad Ellis 氏。楽しくトークを聞くことができた。

グローバルな組織では「多様性」「共有」「期待の明確化」「Internal PR」などが大切とのこと。グローバルなプロダクトに対しては「各ローカル(国、都市と地方)に合わせていくこと」の重要性を話されていた。また優れたサービスを先行してる国(例えば日本)から他の国へ展開していく事例についても紹介されていた。

始めの方にあった「You are not the user」では昨日の増井氏の発表を思い出しておかしくなったよ。

12:00 - 12:30 [MainRoom] A day in the life of Silicon Valley PM

Smule, Inc Head of Product in AI (Principal Product Manager) 曽根原 春樹 氏

PM の考え方のシャープなセッション。「Think big」「上手に失敗する」。

13:30 - 14:00 [MainRoom] プロダクトアウトな新規事業立ち上げのリアル

株式会社プレイドプロダクトマネージャー 棚橋 寛文 氏

KARTE の事例。

14:10 - 14:40 [MainRoom] DXにおけるプロダクトマネジメント

• 株式会社三菱ケミカルホールディングス 先端技術・事業開発室 デジタルトランスフォーメーションGr Chief Digital Architect 伊東 武 氏
• 株式会社日本経済新聞社 デジタル編成ユニット CPO室 部長 重森 泰平 氏
• 株式会社デンソー 部長 成迫 剛志 氏

日経の方の話が一番しっくりくるし実践されている PM の話だった。他のお二方のは立場が違うのかちょっと雰囲気が違う感じ。

14:50 - 15:20 [MainRoom] プロダクトマネージャーが知っておくべき、「OKR」を通じたこれからのチームマネジメント

プロノイア・グループ株式会社 CEO(Chief Executive Officer） ピョートル・フェリクス・グジバチ 氏

「OKR っていう言葉は使わなくたっていいじゃん」

• B2B に比べて B2C はボトムアップが自然。
• Un-Learn。
• Google だって四半期で計画。
• OKR が人事考課につなげるかは YES も NO もありえる(ただしスコアを直接の評価にしない)。

「承認 x 感謝」が大切で、マネージャーとして次のような態度を常にもっている必要がある。

• Sympathy = 同情
• Empathy = 共感
• Compassion = 思いやり

15:30 - 16:00 [Room2-2] プロダクトの強い軸を作るプロダクトマネジメントフレームワーク

Tably株式会社 小城 久美子 氏

プロダクトの Core・Why・What を決めていくプロセスのフレームワークの紹介を実践を通じて説明。とてもわかりやすく参考になった。

キーワード: 「リーンキャンバス」「PRD」「インセプションデッキ」「バリュープロポジションキャンバス」「ユーザーストーリーマッピング」

• スライド: プロダクトの強い軸を作るプロダクトマネジメントフレームワーク

16:00 - 16:20 [MainRoom] コネクティドカーにおけるプロダクトマネージメント

日産自動車株式会社 コネクティドカー＆サービス技術開発本部ソフトウェア＆ユーザーエクスペリエンス開発部アプリケーション＆サービス開発グループ主担（プロダクトマネージメント）海老澤 雅之 氏

ソフトウェア開発をウォーターフォール開発からアジャイル開発したよという話と、アプリの紹介。

今日はここで退散。

Alfred から指定したチャンネルを Mac 版 Slack デスクトップクライアントで開く

 slack://channel?team={TEAM_ID}&id={CHANNEL_ID}

という URL で Mac 版 Slack デスクトップクライアント上で指定したチャンネルを開けるということがわかったので Alfred でワークフローを作って開けるようにした。

deep linking を使うだけなら認証・承認まわり関係ないのでお手軽。

TEAM_ID と CHANNEL_ID はデスクトップ版のサイドバー上のチャンネルでリンクをコピーして確認。

• Deep linking into Slack clients | Slack

境界線を引いて自律性を生み出す

先週8月19日(水)に『社員の力で最高のチームをつくる〈新版〉1分間エンパワーメント』を買って読んでいる。一昨日の「第1の鍵」に続き、今日は「第2の鍵」を。

エンパワーメントの「第2の鍵」は以下。

境界線を引いて、自律的な働き方を促すこと。(Create autonomy through boundaries.)

境界線

「境界線って何?」とひっかかる。で読んでみると

1. 目的 (Purpose)
2. 価値観 (Values)
3. イメージ (Image)
4. 目標 (Goals)
5. 役割 (Roles)
6. 組織の構造とシステム (Organizational Structure and Systems)

と書かれていた。 組織の MVV 的なものを明確にし、チーム・個人に浸透させ、それぞれ役割と目標をもって主体的に動けるようにしよう。王道な話であった。

ビジョン

トップが「ビジョン(イメージ→目的→価値観)」を立て、全員でビジョンから個人の「役割と目標」に落とし込む。ビジョンを「全社員で磨きをかける」ってどうやるのだろうと思ったけれど、ビジョンの内容や表現をワイガヤ作っていくのではなく落とし込むことを言っているようだ。

価値観

トップが信念(belifes)から価値観を明確にし、全員で価値観からルール・業務に落とし込む。「ルールを作るのは社員」というのがここではポイントだな。

組織の構造とシステム

「組織の構造とシステム」は報酬体系だったり承認ルールだったりを指している。エンパワーメントを妨げるものがあれば解決していこうという話。

旅

王道な話なんて書いたけれど、やり切るには強い意志、それから時間が必要だと。

• 社員の力で最高のチームをつくる〈新版〉1分間エンパワーメント

[ 読書ノート ] [ 行動原則 ] [ Naney の行動原則 ]

動機づけと感謝する・褒める

動機づけ観点で褒めることの是非について、ちょっと再確認してみた。

動機づける・動機づけを下げないようにする

「行動・過程」に感謝する(あるいは褒める)。「結果・成果」を褒めない。金銭的な報酬を期待させない。

内発的動機づけがない

「外発的動機づけ」により「内発的動機づけ」が高まる「エンハンシング効果」を起こす。

• 言語的な報酬で「外発的動機づけ」する。
  • 「行動・過程」に感謝する。「行動・過程」を褒める(成長承認する)。
  • 「結果・成果」を褒めない(成果承認しない)。
  • 「能力」を褒めない。
  • 褒めるより感謝。(アドラー心理学)
  • 信頼されている人・好意を寄せられている人が承認するとより効果がある。
• 物質的な報酬で「外発的動機づけ」する(注意)。
  • 「内発的動機づけ」が高まるまでは物質的な報酬も有効(アンダーマイニング効果に注意)。

内発的動機づけがすでにある

「内発的動機づけによる行動」に対して「外発的動機づけ」することにより動機づけが下がる「アンダーマイニング効果」を起こさないようにする。

• 「内発的動機づけによる行動」に物質的な報酬を期待させない。
  • 「他者から統制されている」と知覚させない。

動機づけを奪うには

• 物質的な報酬を期待させて「外発的動機づけ」をしたあと、報酬を無くす(アンダーマイニング効果)。
• 「内発的動機づけによる行動」に対して、行動を強制したり干渉したりする。

表彰制度と競争と動機づけと

組織において表彰制度を実施する場合は「競争」と「動機づけ」について相当な注意を払う必要がある。

表彰制度と競争

表彰制度について用心する。

ピープルウエアでは「何かチーム内の競争心をあおるようなことをしたら、チーム殺し的と見なければならない。」(第2版 第28章 競争 p.235 より)

と競争についての問題を述べている。

表彰制度と動機づけ

表彰されるための行動は外発的動機づけによるもの。

報奨金有害論

Joel on Software の第21章「報奨金有害論」では、 Microsoft の「Ship It」アワードについて「従業員たちが子供のように扱われていると感じていることが明らかになった。」と述べている。

外発的動機づけされようとしていることについての反発だろう。

「今月の従業員」を表彰する代わりに「今月の成果」を表彰する

OKR についての書籍『Measure What Matters』では承認について

特別なプロジェクト、会社の目標の達成、会社の理念を体現する行為など、従業員の行動や成果を認める。「今月の従業員」を表彰する代わりに「今月の成果」を表彰する。

とし人ではなく「行動や成果」を表彰することを勧めている。外発的動機づけとしては「成果」よりも「行動」を褒める(成長承認する)ことに重点を置いた方が良いだろう。

報酬を小さくする

行動を起こさせる程度だがその行動すべてを正当化できない程度の報酬にする。そうすると人は認知的不協和を解消しようと他の動機(内発的動機)を見つけようとする。

• 「小さな報酬」が学習のモチベーションを高める | HBR.org翻訳マネジメント記事｜DIAMOND ハーバード・ビジネス・レビュー

[ opinion ]

MEEET 登録

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 スクリーンキャプチャより)

『イシューからはじめよ』

問題に取り組む前に「今本当に答えを出す価値のある問題(イシュー)」かどうかを見極める。そしてスタンスをとり、イシューに対して「問い」ではなくいきなり「答え(仮説)」を出す。

という考え方を紹介しているのが『イシューからはじめよ』だ。いかにして意味のある仕事を選択し成果を出していくかかが説明されている。

• イシューからはじめよ (Kindle版)
• イシューからはじめよ (単行本)

「問題を見極める」重要性をここまで明確にしているのを読んだのは本書が初めてだ。仮説思考の徹底ぶりもすごい。この2点を常に意識できるようになれれば本書を読んだ価値があるだろう。

第1章から「イシューからはじめる」アプローチ

1. イシュードリブン 今本当に答えを出すべき問題=「イシュー」を見極める。
2. 仮説ドリブン イシューを解けるところまで小さく砕き、それに基づいてストーリーの流れを整理する
3. 仮説ドリブン ストーリーを検証するためのに必要なアウトプットのイメージを描き、分析を設計する
4. アウトプットドリブン ストーリーの骨格を踏まえつつ、段取りよく検証する
5. メッセージドリブン 論拠と構造を磨きつつ、報告書や論文をまとめる

について各章でポイントを解説している。ソリューションを考え出してプレゼンテーションをまとめる際に何度も読み返したい。

個人的に刺さったのは「イシューと仮説は紙や電子ファイルに言葉として表現することを徹底する。」というくだり。やはり「文章で書く」こと大切だよね。

本書を知ったのは Developers Summit 2019 の「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会。同年のビジネス書部門大賞となっている。その後2020年5月に思い出して読んだ。読書ノートをまとめてなかったので、読み直してみたのが今日だ。

本書では問題設定から問題解決案/論文のアウトプットまでが主なスコープで、読んだ多くの人がコンサルティング的な仕事を思い浮かべるのではないだろうか。

ネットサービスのプロダクトマネジメントでは、承認を得るのがゴールではなくユーザーに価値を届けて成果を出すのがゴールである。仮説検証の段階でプロダクトをリリースしてできるだけ早くフィードバックを得て、検査と適応を繰り返していく。ライトウェイトなループの中にうまく本書の考え方を取り込んでいきたい。

• イシューからはじめよ (Kindle版)
• イシューからはじめよ (単行本)

[ 読書ノート ] [ お薦めの本 ]

あいまいなリクエスト「確認お願いします」を避ける

仕事をしていると「確認お願いします」と言ったり言われたりしがち。

「はっきりさせてください」の意味にしか取れないなら問題ない。

(ドキュメントなどの)成果物ついての「確認お願いします」と言われると

• 「承認は不要ですが見ておいてください」
• 「問題ないと思うので調べた上で承認してください」
• 「問題がまだあると思うので調べて指摘してください」

のどれなのか不明確で気持ち悪く感じることがよくある。頼まれた側だった場合、つい面倒に感じてあいまいに「確認しました(=見ました)」と返事してしまって、良くなかったなあとなってしまったりする。

明確なリクエストになるよう言葉を選ぶよう気をつけよう。あいまいなリクエストを受け取った際にあいまいに返事をしないよう気をつけよう。

以上、ご確認お願いします。

[ opinion ]

Post 登録

11月30日にウェイティングリストに登録した Post から参加承認のメールが一昨日届いたので、本日登録してみた。ハンドル (現在のところ変更不可) は6文字以上ということで長い方で登録。

• https://post.news/pleasuright

ニュースコンテンツを念頭においたソーシャルメディアのようだ。

ポストはリッチテキストでペイウォール設定できる。またポイントでチップを支払える機能もあり。 Following 以外に Explore というパブリックタイムラインぽいものがあるのが、サービス初期のソーシャルメディアらしい。

2023年3月12日 追記

プロフィールの URL は下記に変更になっていた。

• https://post.news/@/pleasuright

「確認お願いします」の「確認」の確認

「確認お願いします」と言われた時に

• 「正しいと認めてください」
• 「正しいか確かめてください」

と「事実か・正しいか」という元来の意味でのリクエストではなく

• 「意見をください」
• 「選んでください」
• 「承認してください」

という「意見・意思決定」についてのリクエストではと感じることがある。聞くと実際そうだったりする。時には

• 「見ておいてください」

とのリクエストの場合もある。

元来の意味でも「正しいと認めてください」と「正しいか確かめてください」では依頼された側が必要な労力が全く違ってくる。

「確認お願いします」と言いたくなったら、本当は何を求めたいのかきちんと自問したい。返答する時も「確認しました」で済ませがちなので、リクエストにあった言葉を選びたい。

以上ご確認お願いいたします。