nDiki : ビジョン

第17回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の17回目。今日は第17章 エンビジョニング (プロダクトプランニング)。

「エンビジョニング」という言葉に馴染みがなかったので「プロダクトプランニング」の方がわかりやすいよなーと最初は思ったのですが、慣れてくればエンビジョニングでも「ビジョン」に意識が向いていい気がしました。

エンビジョニングのタイミング

何度も繰り返すアクティビティであり、一度やってそれで終わりではない。

これ系のアクティビティはどうしても半期毎のサイクルになってしまいがちなのですが、アジャイル的にはもっと早いサイクルにやった方が良いということですね。

エンビジョニングをやりすぎないようにエンビジョニングの完了予定日を設定しておくのは確かに必要だなと感じました。やろうと思えばいくらでもやれてしまうものなので期日を明確にした方が経済的でしょう。

エンビジョニングの参加者

最初のエンビジョニングで必須なのはプロダクトオーナー。いったんプロダクトの開発が動き出して以降のエンビジョニングにはスクラムチーム全体が参加すべき。概要レベルのプロダクトバックログの作成でストーリー記述する際もスクラムチームメンバ全員が関わった方が良いと言っています。

このあたり結構孤独にやっちゃうことも多いんじゃないかと思うですが、やはりチームでやった方が良いようです。

価値のカテゴリ

図17.3 で「ステークホルダーが得る価値の分野」としてカテゴリ分けされているのは地味に便利ですね。

• 参入条件
  • ハードルをクリアする
  • リリース可能な最小限のフィーチャーをデリバリーする
  • SOX、FDA、HIPAAなどに準拠する
• 使用可能性
  • 新たなマーケットを対象とする
  • 他のプロダクトやサービスを販売できるようにする
• 差別化要因
  • 競合他社と差別化する
  • 顧客を喜ばせる
• 妨害
  • 競合他社の差別化要因を無力化する
  • ハードルを上げる
  • 市場での注目先を変えることで、ゲームのルールを変える
• コスト削減
  • 市場に投入する時期を早める
  • 開発工数や投入する要員を減らす
  • 利益を増やす
  • プログラミングの技術を高める

自分が取り組んできたものだと「顧客を喜ばせる」「要員を減らす」とかが多かったですが、製品・市場によっては確かに妨害とかもあるのでしょうね。

今日は参加者少なめで5人。23章までいれるとあと6回のところまできました。

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

仕事に対するスタンス共有 2017

去年9月ぶりの「仕事に対するスタンス共有ミーティング」です。下記の設問にあらかじめ答えを用意しておいて、ミーティングの場で発表するというものです。

チームビルディングの一環として、お互いを知り、うまく分担・補いあいながらコラボレーションしていけるようにしようという取り組みなんだけれど、他人を知るだけじゃなくて自分自身を再発見できたりもするのでお勧め。 -- 仕事に対するスタンス共有 2013

新しくメンバが増えたこともあり今日は CS 開発チームのリーダーがセッティングしてくれました。「そういえば自分がやっている仕事はいったい何なんだろう?」と考えつつ回答をアップデート。

「自ら実践して模範を示す。」というのを追加しておいたら「実際にどんなことをしていますか?」と突っ込まれて、とっさに「ハンドスピナー」と答えてしまいました。だいたいそんな感じの模範活動です。

Q1. 仕事上でどのようことが得意ですか? 苦手なことは何ですか?

• 得意なこと: 仕事を進めていく仕組み作りをしていくこと。
• 苦手なこと: 大勢の人がいる場所にいること。懇親会。

Q2. 仕事をする上で一番大切にしていることはどんなことですか?

• 「どのようにすればで言ってみる」こと。
• 「いますぐやる」こと。「早くフィードバックを得る」こと。
• 「遊び心をいれる」こと。
• 「笑顔でいる」こと。
• 「情報を共有する」こと。

Q3. 仕事をしていて陥りがちな傾向はありますか?

• 腑に落ちない時に顔に出る。(参照)

Q4. 仕事をする上でモチベーションが下がるとき、上がるときはどんなときですか?

上がるとき:

• 感謝されたとき。ほめられたとき。感動したとき。

下がるとき:

• 知らないうちに何かが進んでいたとき。

Q5. 所属チームで(あるいは会社で)でどのような役割を果たしたいですか?

• ミッション・ビジョン・バリューを常に意識しつつ、グループとして最大のパフォーマンスを発揮できるようにマネジメントする。自ら実践して模範を示す。

Q6. 仕事を通して目指す将来の目標はありますか?

• いけてるマネージャー。問題解決スペシャリスト。

Q7. 仕事をする上で周囲や会社に対して、あなたはどうありたいと考えていますか?

• 周囲の人の良いところを引き出す人でありたい。

Q8. 仕事をする仲間に伝えたいことがあれば何でも。

• 一緒に笑いましょう。 (参照)

[ 仕事に対するスタンス共有 ]

GTD における見通し (Perspective) #nNote

• 5000m 目的 (Purpose)
• 5000m 価値観 (Prnciples)
• 4000m ビジョン (Vision)
• 3000m 目標 (Goals)
• 2000m 重点的に取り組む分野 (Areas of Focus)
• 1000m プロジェクト (Projects)
• 0m 次の行動 (Next Actions)

one-on-one ミーティングでキクトビジョン

one-on-one ミーティングで相手の方のキャリアビジョンを伺いたい時、私は「すごいやり方」に出てくる「キクトビジョン」の質問テンプレートをよく使わせていただいています。

• 「1年後にどうなっていたい?」
• 「じゃあ、3年後にはどうなっていたい?」
• 「その状態になるのに障害になっていることはなに?」
• 「どんなやり方をして、だれのどんな助けがあれば、その障害があっても望むような状態になれる?」

(すごいやり方 p.56)

多くの方はその場ではなく、次回の one-on-one までに考えをまとめてから答えてくれます。「そんな質問をされた事がなかった」「あまり考えた事がなかった」と言われることが多く、あらためて考えてみる良いきっかけになるようです。

書いたものは残しておくのがお勧めです。1年後・3年後に見返して「実現できている!」「考え方はその後もぶれていないな」あるいは「成長したな」「方向転換したな」などとふりかえることができて純粋に面白いです。

• すごいやり方 (単行本)

今日のさえずり: 「ポケットティシュー ケース メンズ」で検索したら本革のとか無駄に高級なのが出てきてコレジャナイ

• 07:00 MIKKE@自由が丘 #トイデジ #デジタルハリネズミ https://t.co/V5JscanBMS
• 09:37 2018年5月16日 朝の渋谷 https://t.co/vlHtK2YHim
• 17:38 久しぶりにキクトビジョンした。
• 22:15 「ポケットティシュー ケース メンズ」で検索したら本革のとか無駄に高級なのが出てきてコレジャナイだった。

今日のさえずり: 「実際のところ、ソフトウエア開発上の問題の多くは、技術的というより社会学的なものである。」を100回噛みしめている

• 07:00 ビックカメラレッド #トイデジ #デジタルハリネズミ https://t.co/r7KhOM1HKy
• 09:36 2018年5月21日 朝の渋谷 https://t.co/zFzxWuSsVv
• 12:15 one-on-one ミーティングで相手の方のキャリアビジョンを伺いたい時、私は「すごいやり方」に出てくる「キクトビジョン」の質問テンプレートをよく使わせていただいています。 http://bit.ly/2rROmfc
• 16:00 ぐるぐる回転している@渋谷 DSC-RX0 #RX0 https://t.co/c9aFcR4t0k
• 17:33 ピープルウエアの「実際のところ、ソフトウエア開発上の問題の多くは、技術的というより社会学的なものである。」を100回噛みしめている。
• 24:47 Adobe Photoshop Lightroom CC mobile のカメラは 3:2 が選べるんだと思ったら、これ非破壊の切り抜きなのね。いかにも Lr らしい。

プロジェクトでみんなをバスに乗せるために書いておく項目リスト

みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。

項目名を整理して決めておくと楽なのでちょっと書き出してみました。

コンセプトシート

比較的軽量にまとめる時。

• タイトル
• 概要 (What)
• 目標 (Goals)
• 背景と目的 (Why)

プロダクトプラン

プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。

• プロダクト名
• プロダクトビジョン
  • 概要
  • 目標
  • 背景と目的
  • 成果物
  • 完了条件
  • スコープ(含むの・含まないもの)
  • (opt) 依存するプロジェクト・制約条件
  • (opt) リスク
  • (opt) 予算
  • (opt) メンバ
• 概要レベルのプロダクトバックログ
• プロダクトロードマップ

ポートフォリオバックログアイテム

ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。

• プロダクト名
• プロダクトプラン
• 期間
• 遅延コスト(ビジネス価値・時間価値・リスク軽減/チャンスと利用)
• WSJF

プロダクトバックログアイテム

スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。

• プロダクトバックログアイテム名
• ユーザーストーリー(誰・概要と目標・背景と目的)
• 満足条件(あれば成果物を含む)
• サイズ
• レビュー方法

タスクチケット

ちょっとしたタスク。

• タスク名
• 概要
• (opt) 背景と目的 (概要で自明でない場合)
• (opt) 成果物/アクション (概要で自明でない場合)
• 完了条件
• 期日

プロジェクト憲章

• プロジェクト名
• 概要
• 目標
• 背景と目的
• 成果物
• 完了条件
• スコープ(含むもの・含まないもの)
• (opt) 依存するプロジェクト制約条件
• (opt) リスク
• (opt) スケジュール・期限
• (opt) 予算
• (opt) メンバ

備考

他には以下のような形式もあります。

• One Pager
• インセプションデッキ
• 製品要求仕様書 (PRD: Product Requirements Document)
• リーンキャンバス

[ プロジェクトマネジメント ]

OKR #nNote

四半期 OKR サイクル

• 期初4〜6週間前: [幹部] 組織 OKR 検討開始 (第1四半期 OKR 設定時は年間計画も)。(↓組織 OKR 設定)
• 期初2週間前: [幹部] 組織 OKR 完成・共有。
• 期初: [チーム] チーム OKR 完成・共有。
• 期初1週間後: [コントリビューター] コントリビューター OKR 完成・共有。
• 期中: [コントリビューター] コントリビューターが進捗を測定・共有・定期的にマネージャーに報告・評価。
• 期末前: [コントリビューター] OKR 採点・評価。

組織 OKR 設定

ミッションと最上位の OKR を結びつける。

1. ミッション・ビジョン・戦略をもとに目標をピックアップする。
2. 圧倒的に事業に価値をもたらす3〜5個の目標を選ぶ。
3. OKR にふさわしい目標の形にする。 (↓チェックリスト)
4. それぞれ主要な結果を設定する。 (↓チェックリスト)
5. スプレッドシートに入力する。

決めるにあたり「紙に書いて発表する」などの方法を活用する。

四半期 OKR 設定チェックリスト

• [ ] 3〜5項目程度である。
• [ ] トップダウン目標とボトムアップ目標が半々ぐらいである(組織の階層を飛び越えてよい)。
• [ ] コミットする目標(100%達成する)と野心的目標が区別できている。
• [ ] 通常業務を含んでいない。
• [ ] やることリスト・To Do リストになっていない。
• [ ] 斬新的 OKR ではなく飛躍的 OKR である。

目標(O)設定チェックリスト

• [ ] 「何を」達成すべきかが書かれている。到達点や状態を示す表現になっている。
• [ ] 重要である。達成によって事業に価値をもたらす。
• [ ] 野心的である(困難で達成できない可能性もある)。「続ける」「維持する」「継続する」は NG。 (野心的 OKR の場合)
• [ ] 現実的である。成功の可能性がある。
• [ ] 達成されたか曖昧さなく客観的に評価できる。
• [ ] 簡潔である。1行に収まっている。

数値目標を含んでも良い。

主要な結果(KR)設定チェックリスト

• [ ] 目標を「どのように」達成すべきかが書かれている。行動ではなく成果が書かれている。「相談」「支援」「分析」「参加」「評価」は行動なので NG。
• [ ] 1つの目標(O)に対し3つ程度である(5つ以下である)。
• [ ] 曖昧さがなく、測定可能である。
• [ ] すべての主要な結果(KR)を完了すれば目標が達成される。
• [ ] 質的な「主要な結果」が含まれている。
• [ ] 量的な「主要な結果」が含まれている。

OKR 用語

• 野心的 OKR (Aspirational OKRs)
• コミットする OKR (Committed OKRs)
• 組織の OKR (organizational OKRs)
• チームの OKR (team OKRs)
• 個人の OKR (individual OKRs)
• ウィン・セッション (wins session)

参考

• Measure What Matters
• OKR(オーケーアール) 及川卓也氏監修。
  • 原題: Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results

Web ページ

• Google re:Work - ガイド: OKRを設定する

[ OKR ノート ]

プロダクトマネージャーカンファレンス 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 の宣伝。

今日のさえずり: Lightroom Classic で Pixel 4 がサポートされているカメラに入った

• 08:17 おっ、 Lightroom Classic 9.0 Camera Raw 12.0 で Pixel 4 がサポートされているカメラに入った。 #Pixel4
• 08:29 サポートされているレンズ(レンズプロファイル)はまだだった。 (RAW ファイル内蔵のレンズプロファイルは前から効いてる。)
• 09:09 ウッシッシッ。 RICOH GR III #GR #GRIII #GR3 https://t.co/R37vyTPoDJ
• 09:40 巨大ビジョンみたい。 2019年11月15日 #朝の渋谷 #Pixel4 https://t.co/BJV30b0RJZ
• 11:04 インフルエンザ予防接種サクッと完了。

自律的な働き方を促す

先週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分間エンパワーメント
  • 原題: Empowerment Takes More Than a Minute

[ 行動原則 ] [ Naney の行動原則 ]