nDiki : 意思決定

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

今日から2日間ベルサール渋谷ファーストでプロダクトマネージャーカンファレンス 2019。

• https://2019.pmconf.jp/

去年に引き続きの参加である。

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

今日のキーワードは「feature team ではなく真の product team を」「プロダクトビジョン」「信頼(trust)」。

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

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

横道稔氏。

10:15 - 11:05 [MainRoom] ORDINARY PEOPLE, EXTRAORDINARY RESULTS

Silicon Valley Product Group Partner and Founder / Inspired 著者 Marty Cagan 氏

与えられた機能を作るだけの feature team ではなく、真の product team を作り信頼し、プロダクトマネージャーは本当のプロダクトマネージャーの仕事をしようという話。

feature team をそのまま product team に成長させて信頼していくことができるのか、それとも優れたメンバで優れた product team を作っているからこそ信頼できるのか。

• Product Discovery が重要。
• feature team (残念) と真の product team
  • なぜ empowered product team にしないか → チームを信頼していないから。そういうチームの PM は本当の PM の仕事をしていない。
• リーダーシップの役割
  • Product Vision (チームが同じ方向を向く。働く魅力になる。3〜5年/10年)
  • Product Strategy(Plan)
  • Product Principles
  • Product Priorities
  • Product Evangelism
• マネジメントの役割
  • 人のマネジメントはプロダクトマネージャー(PM)の役割ではない。
  • Staffing (強い人材を雇用する)
  • Coaching (能力を押し上げる)
  • Objectives
• 信頼
• 革新はエンジニアから生まれる。真の product team が重要。
• feature team から移行するには PM は自分の真の仕事をする。成果に責任をもつ。

11:15 - 12:00 [MainRoom] Special Session

TransferWise Head of Product Kaarel Kuddu 氏

• speed
• customer focus
• autonomous teams
  • 決定権をもつチーム。
• Autonomy = responsibility
  • 意思決定の自由は顧客インサイトやデータによって裏付けられる必要がある。
  • 成果に対する説明責任がある。

前のセッションに続きここでも、能力の高いメンバによる顧客のことを理解し考えて決定し実行できる優れたチームに決定権と成果に対する説明責任を与え信頼するという話が印象に残った。

ここでいっている責任をもつというものが何か指しているかが気になるところ。

13:00 - 13:30 [MainRoom] LINEにおけるお金とユーザーのジレンマ

LINE株式会社執行役員 二木 祥平 氏

「LINE公式アカウント」「LINE Ads Platform」が現在の担当プロダクトの二木氏のセッション。 「LINE(株式会社)では」 PM が何をしているかをふわっとまとめた話。ロジカルな構造や用語使いなどでしっくりこないところがあるけれど、生の声という意味で興味深く聞けた。

13:50 - 14:10 [MainRoom] PMにおけるストーリーテリング

freee株式会社 執行役員 プロダクトマネージャー 岡田 悠 氏

バックログの縮小均衡 → プロダクトビジョンが必要 → プロダクトビジョンが機能しなかった → ストーリーテリング。

「静的なビジョンを、動的なストーリーへ深堀ること」

セッション自体がストーリーがあるかのようで惹き込まれて響いててきてさすがだなと感じた。

「シャープに本質だけを抜き出した表現にしようとする」あるいは「そもそも事実を書き並べる以上の文章をなかなか書けない」のでつい端的な文章で済ませがちだけれど、やはり人を動かすにはストーリーも大切だなと思うことができた。

14:20 - 14:40 [MainRoom] “失敗事例で学ぶ” 失敗しないプロダクトマネジメント - PMの必須スキルと、自走する組織のつくりかた -

エン・ジャパン株式会社 デジタルプロダクト開発本部 部長 / プロダクトマネージャー 岡田 康豊 氏

スキルを明確化・指標化することで改善が動き出すというのは、プロダクトと同じで PM に馴染みやすいのかも。

今回のセッションの事例ではかなりガッツりやっているので、業務の中でどれだけのウェイトをかけてメンバが取り組んでいるのかが気になるところ。

14:50 - 15:20 [MainRoom] コミュニティマネジメント: プロダクトの開発と展開をコミュニティが加速させる

東京大学 FoundX ディレクター 馬田 隆明 氏

• オーディエンスマネジメントとコミュニティマネジメント
• コミュニティマネジメント → 新しいつながりを作ったり強めたり切ったり
• コミュニティ
  • エンゲージメントと継続率・アイデア・サポートコスト削減

ボリュームある発表で浅く広くエッセンスを列挙したセッション。30分じゃもったいない量だ。実経験ではなく、世の中で論じられているものをまとめた馬田氏らしい内容。ユーザーコミュニティのり活用について整理されていて、概論についての理解のリフレッシュの良い機会になった。

大きくなったコミュニティのサブグループ化は過去やってみたりしてきたけれど、やっぱりいいやり方らしい。

コミュニティのオンボーディングは、企業内でもそのまま使えるのでリストとして見えるところに書き出しておきたい。

コミュニティを育てることでエンゲージメントと継続率を高めるというのは自サービスでも意識している点。優先度がなかなか上げられないけれども継続はしていきたいところだ。

• スライド: PM と PMM のためのコミュニティマネジメント

15:30 - 16:00 [MainRoom] 企業が求めるプロダクトマネージャーとその人材戦略

• 株式会社ニューズピックス取締役CTO 杉浦 正明 氏
• 株式会社グッドパッチ代表取締役CEO 土屋 尚史 氏
• 株式会社クライス＆カンパニー代表取締役社長 丸山 貴宏 氏

パネルセッション。PM の需要・募集・市場・オンボーディングについて。

16:10 - 16:40 [MainRoom] 発明、ドッグフーディング、プロダクトマネジメント

Nota Inc.CTO 増井 俊之 氏

増井氏流の発想・発明ベースのプロダクト開発の紹介。自分が使いたいから作り、問題があればすぐ直す。

プロダクトマネジメントはほぼ関係なかったけれどウィットに富んだ参考になるセッションだった。

16:50 - 17:35 [MainRoom] Keynote Session

Zoom Video Communications, Inc Chief Information Officer Harry D. Moseley 氏

30分 Zoom の宣伝。ちょっとだけ PM の話があってまた Zoom の宣伝。

最大の価値は話し合う過程で気付きと学びを得ること

「エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド」の中でメチャクチャ好きなところの1つが見積もりついて書かれている以下のくだり。

いちばん大切なことだが、見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。 — 第7章 見積もりとベロシティ

「気づき」は原著「Essential Scrum: A Practical Guide to the Most Popular Agile Process」では「learning」と表現されている。

Finally, and most importantly, one of the primary values of estimation is the learning that happens during the estimation conversations. — Chapter 7 Estimation and Velocity

これは見積もりというアクティビティに限らない話だよね。

このくだりを読んでから「◯◯の最大の価値は話し合う過程で気付きと学びを得ることだ」と考えることが増えた。ミーティングが意思決定や共有などのゴールを達成する場であることはもちろんとして、チーム・個人が気付きと学びを得る場になるよう常に意識していきたい。

自己組織化されたチームになっていくためには話し合い超重要。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

[ opinion ]

ミーティング資料を事前に見すぎない

「ミーティングで深い話し合いと適切な意思決定ができるように、事前に議題を共有・検討しておく」派ではあるのだけれど、ここしばらく意図的に事前にミーティング資料を見すぎないようにしている。

事前に考えすぎてしまうなと。ロジックを組み立てて検討しているうちに、自分の主張を強化しすぎてしまう落とし穴がある。主張を確信しすぎてしまうとミーティングで話し合う価値が下がってしまう。

時間をかけて調べたり考えたりしたものの、ミーティングで議題の説明を聞いたら意図や温度感が違ったりすることもある。考え違い・考えすぎだった残念パターンだ。

心理的負担になる場合もある。重い相談を事前に目にしてしまうと、前日であれば一晩、金曜日の夕方なら週末ずっと心の片隅に居座り続けてしまうことがある。それって楽しくない。

他者の新規議題について見すぎない・準備しすぎないのがいいんじゃないかと。

[ opinion ]

Twitter で 縦長画像が縦長に表示されるようになった

Twitter で縦長画像が縦長に表示されるようになった。Android 版・iOS 版 Twitter 公式アプリの両方で確認。 Web 版はまだ。

縦写真好きなので嬉しい。「縦写真なのでタップお願いします/タップ推奨。」といった Tweet 文が流れてくるのが減るのも嬉しい。サムネイルに対して「縦かも? タップしてみる?」みたいなエネルギーを消費する細かい意思決定が減るのも嬉しい。

「目立つ Tweet にするにはこれからは縦画像だ」指南がちまたで一気に増えそうだな。

階層思考をセルフマネジメントチームで置き換える

『社員の力で最高のチームをつくる〈新版〉1分間エンパワーメント』の「第2の鍵」についてのポイントを書き出してみてから半年以上経ってしまった。残るは「第3の鍵」。

階層思考をセルフマネジメント・チームで置き換える。 (Replace hierarchical thinking with self-management teams.)

エンパワーメントのためには従来の階層組織において上司が下していた意思決定について、チームが意思決定し実行できるようにしていく必要がある。意思決定は最前線で行わななくてはならない。

セルフマネジメントチームとは

セルフマネジメントチームについて同書では

業務プロセス全体あるいは製品やサービス全体について責任をもつ社員によって構成され、仕事の最初から最後までを、このチームが計画し、実施し、管理します。

と説明されている。

セルフマネジメントチームの上司の仕事は?

チームが自律的に動くようになった際には、上司の仕事はより上位の計画や意思決定、組織のマネジメント・メンバの成長支援などになっていく。

セルフマネジメントチームに育てる

上司は仕事の仕方を教えるのではなく、チームメンバ同士が対立解消しながら意思決定し行動していく方法を教えていくようにする。上司に頼らないで仕事ができるようになる方法を教えるのだ。

チームがセルフマネジメントチームになるまでには、途中不満を抱える段階を通る。上司は支援をしていく必要がある。

「チームの一員の立場でセルフマネジメントチームにしていく」のか「チームの外からセルフマネジメントチームに育てる」のかによって必要なリーダーシップは全然違うだろうから、その時々の立場でしっかり考えて行動していきたい。

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

[ 読書ノート ]

ユニクロは実店舗にある比較表が重要

ショートパンツを新調したくてユニクロへ。

ユニクロオンラインストアでの事前チェックでは種類が多くて迷いまくり。店舗に行ったらショートパンツを丈の長さ別に分類した商品説明が掲示されていた。そうそう店舗だとオンラインストアでは見当たらない、意思決定用の追加情報があるよね、ユニクロ。

『amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法』

会議の資料は「箇条書きではなく文章で書く」のが Amazon のルールと紹介している書籍『amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法』が気になって全部読んでみた。

「会議資料の準備」と Amazon 流の「意思決定会議」「アイデア出し会議」「進捗管理会議」、そしてそのやり方の背景にある信条「Our Leadership Principles」との関係について読みやすくまとめられていた。

本書の内容は「Our Leadership Principles」という価値観・行動原則を体現したマネジメントや会議のスタイルだ。なので読んでやり方だけ真似てもうまくいかない。Amazon 流会議の紹介から同意できる大切にしたい価値観・行動原則を見つけ自分や組織に取り込みつつ、会議スタイルも参考にしていくのが良いのだろう。いや価値観・行動原則を取り込められたのなら、もう真似などせずとも自ずとイケてる会議スタイルになっていっているに違いない。

とはいえピンポイントで「なるほど」「やってみたい」というのもいろいろあったので、それはそれでピックアップして参考にしたい。

会議資料: 箇条書きではなく文章で書く

「箇条書きではなく文章で書く」については

いつ誰が読んでも確実に伝わる

と「伝えるための表現形式」として、また

きちんとした文章にするとなると、読んだときに辻褄が合わない部分が出て来ないように、最初から整合性をとらなくてはなりません。そのため、吟味に吟味を重ね、適切な情報を用いて推敲を重ねなければなりません。

と「書いて考えるための表現形式」として文章形式(ナレーティブ形式)の良さが説明されいた。

最近はできるだけ箇条書きではなく文章で書くようにしている。やってみると、なるほどそうだなと。お勧めのプラクティスだ。

会議資料: 定形フォーマットはつくらない

「定形フォーマットはつくらない」という話には唸った。

先人からの学びや自身の経験から「これは共通理解や意思決定に必要」という項目が自分なりにいくつかあって、ドキュメントの構成として意識していたりする。

しかしその構成に固執したり他人に強いたりすると、変化の阻害要因になりかねないと。定形にすると便利で楽だけれど思考の硬直につながりかねない。意識したい。

あとは

• プロジェクトリーダーが意思決定会議のオーナーになる。
• 本題から外れた意見をメモしておく「パーキングロット」を使って脱線から戻す。
• ソーシャル・コヒージョン (Social Cohesion) に気をつける。
• 「メトリックス・レビュー」と呼ばれる会議には、異常値の分析・対策検討など然るべき準備をした上で望むのが暗黙のルール。

は意識したりやってみたりしたいなと思った。

それから

• 意思決定会議で「What(何を) Who (誰が) When (いつ)」を明確に決める

というのは、『すごい会議』で学んだ

• 「誰が」「いつまでに」「なにをして」「どんな成果をだすか」を明確にする

というのと同じ普遍的な考え方だな。ガッツがいるのでついユルくなりがちだが、スピードと成果が圧倒的に変わってくるのでしっかり踏ん張ってコミット・リクエストしたい。

• amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法 (Kindle版)
• amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法 (単行本)

[ 読書ノート ]

東京2020オリンピック 17日目: 閉会式

東京2020オリンピック最終日。朝食後にテレビをつけ、 7:00 にスタートした男子マラソンで服部選手が73位でフィニッシュするのを見届けた。

昼食の時にテレビをつけたら今度はバスケットボール女子で日本がアメリカと決勝戦中。銀メダルを獲得。チャンネルを変えたらNHK2020ソング 「カイト」にのせた日別のダイジェストが流されていたので、それで会期後半を振り返った。

閉会式は 20:00 から。交響曲第9番が流れて年末ぽかったり、東京音頭が流れてお盆ぽかったりといろいろミックスな感じ。2024年パリオリンピックの引き継ぎでの映像は、歴史を感じさせるパリ市街・エッフェル塔そばの広場での賑やかなイベントの様子など魅力的な開催を予感させ素晴らしかった。

直前まで開催中止の声が多かったように感じられた今回のオリンピック。目にする情報から考えるに組織運営・意思決定・発表の仕方など多々問題はたしかにあったのだろう。

一方で完璧を求める声ばかりが大きくフォーカスされがちであったとも思う。ちょっとした声がソーシャルメディアやマスメディアで増幅される時代になったことや、新型コロナウイルス感染が続くなかで不安・不満が積もってきている世の中という背景がそうさせているのだろうか。

完璧を求める社会になると何もかもが停滞していき、巡り巡って全員が生きづらい社会になってしまう。完璧ではない人間が、他者にどれだけの完璧を求めるべきなのか。

批判のあり方について考える機会にもなった大会であった。

ナチュラルプランニングモデルでプロジェクトプランを書くためのテンプレートを作ってみた

(GTD で言うところの)プロジェクトの中でエネルギーがいる意思決定が必要なプロジェクトはつい先送りししてしまいがちだ。 Remember The Milk 上で滞留してしまっている。そういうのはナチュラルプランニングモデルできちんとプロジェクトプランニングした方がいいんじゃないか。

プロジェクトプランのノートを Obsidian で書けばいいかなと思ってテンプレートを作り、既存のプロジェクトノートをそのテンプレートで書き換えてみた。ちょっといいかも。

• ナチュラルプランニングプロジェクトプランテンプレート

テキストファイルベースのタスク管理(シンプルなチェックリスト・todo.txt・TaskPaper など)は過去うまくいっていないので、引き続き Remember The Milk をメインにしつつ、プロジェクト支援資料としてうまく参照しあって使えればいいな。

nNote クローズ

ちょっとしたノートを置いておくスペース nNote をクローズした。

この Web 日記 (nDiki) より気軽にに更新したり削除したりできるノートを書いておく場所が欲しくて2017年1月に作成して気がつけば4年。

• 去年の12月に nNote ではなく nDiki にちょっとしたノートを書くことにした。
• 今年の2月に Obsidian Publish サイトを作り、テキストファイル同期でノートを公開できる環境が別途できた。
• Obsidian Mobile + Obsidian Sync により、テキストファイルに書いた持ち物リストをスマートフォンでも不便なく見られるようになった

などで今年に入ってほぼ新規にノートを追加することが無くなっていた。書くスペースが多いとどこに書くかの意思決定にコストがかかるデメリットもあるので今回クローズすることにした。

[ ノート・日記はテキストファイルに ]