nDiki : ビジョン

チームでインパクトマッピングしてみた

次にどのようなサービス開発をしようか(ユーザーにどのような価値を提供しようか)というアイデア出しをするのに「インパクトマッピング(impact mapping)というのがあるよ」と教えてもらったのでチームで昨日やってみました。

ゴール (WHY) を中心に以下の階層でツリー(インパクトマップ)を描いて考えるというものです。

1. ゴール goal (WHY)
2. アクター actors (WHO)
3. インパクト impacts (HOW)
4. 成果物 deliverables (WHAT)

「ゴールは何か → 誰にインパクトを与えるか → どんなインパクトを与えるか(どのような振る舞いに変えさせるか) → 何によってインパクトを与えるか」と広げていきます。

個人では「ミッション → ビジョン → ゴール → (ここでいう)インパクト → (ここでいう)成果物」のように広げていくことはあるのですが、 WHO はツリーに入れたり入れなかったりするのでなるほどなと思いました。

昨日はすでにメンバの頭の中にあったアイデア(ここでいう成果物)を、このツリーに入れていくという整理の側面が強かった感じですが、それはそれで良かったかなと。みんなで同時にやると WHO・HOW の分類が違って見通しが悪いのでそこは別途誰かまとめる人が必要だなとも感じました。

ミッション・ビジョンをもってサービスを作り CS 活動をしていく【日記】

ネットサービスの CS グループマネージャーの方とディレクターの方と食事してきました。歩高里(ブルゴーニュ)は六本木交差点からすぐそばなのに、広くて空いていて安くて美味しかったので満足でした。

私の方は「最近はサービス開発と CS 開発の両方を担当するグループにいて、CS 開発チームがサービスと独立してリソースが確保でき、CS の価値観や KGI・KPI で動く良さを別の視点であらためて感じている」という話をしました。CS 開発という地位については相手の方に「サービス開発から CS への異動だと第一線から外れるような劣等感をもたれる事もある」と言われて、ああそうだよねとなりました。私のまわりだと誇りをもってやっている人が多かったので最近そういう風にとらえていませんでした。

相手の方のサービスの話などもいろいろ聞かせていただきました。相手のお2人とも、そしてその上の経営陣の方もきちんと大きなミッション・ビジョンをもって動いているのが強く感じられました。素晴らしいなと。あとちゃんと dogfooding しているなと。

それから本質的に意味のある仕事かどうかを見極めるのをとても大切にしているように感じました。

我々もあらためて自分たちのミッション・ビジョンに向けて邁進しなくてはと思って帰路についた1日でした。

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

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

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

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

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

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

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

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

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

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

価値のカテゴリ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上がるとき:

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

下がるとき:

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

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

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

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

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

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

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

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

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

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

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)
• リーンキャンバス

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

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