プロダクトディスカバリーにかけるリソースは何に影響するのか
はじめに
「顧客やニーズを調査して何を作るかを考える」プロダクトディスカバリー作業はとても大事だと思うのですが、ここに時間や人手をかけるとどのような良い効果が期待できるのか、個人的にしっくりきていません。
1. プロダクトデリバリーで成功する確率が上がる 説
「時間をかけて調べたんだから、きっと成功するはずだ」というやつです。 でも時間をかけても100%成功する打ち手なんてわかるはずがないですし、冷静に考えればすぐに違うとわかるはずです。
時間をとって考えた方が成功確率がほんのわずかに上がることはあるのでしょうが、そこに時間をかけるよりも打ち手の数を増やした方が成功する確率は高められる気がします。
2. プロダクトデリバリーで得られる成果が大きくなる(数値がより伸びる) 説
成功率でないとすると「成功したときのリターンが大きくなるはず」と考えたいですが、これもしっくりきません。 そうあって欲しいと願うプロダクトマネージャーの祈りのように感じます。
思いつきでも大きな成果が出る打ち手はありますし、開発工数が大きくなれば成果もつれて大きくなるかというと必ずしもそうではないでしょう。私にはこうあって欲しいという願望以上の理屈が見出せません。
3. 1変更を加えた影響がプロダクトに長く関与する 説
成功率も成功したときのリターンも変わらないのであれば、「グロースハック」のような短期の打ち手をたくさん打てばよいとなりそうです。 しかし、これもプロダクトが場当たり対応ばかりになって中長期で伸びるイメージが湧きません。
中長期を睨み、大小様々な打ち手を組み合わせてプロダクトを改善し、成長する方向に導いていくのだとすると、ディスカバリーへの投資による効果は「打ち手の方向が揃うため、ある打ち手が他の打ち手やプロダクト全体に影響を及ぼしやすくなる」ではないかと考えています。グロースハックのような点の打ち手ではなく、複数の打ち手が相互に関係・影響しあい相乗的な効果が出しやすくなる。
ただし個別の打ち手の成功率や成功した時のリターンは工数とは対してリンクしないので、たくさんの打ち手を考えて筋が良さそうなものをどんどん実行していった方が良い・・・こうではないかと。
おわりに
プロダクトマネージャーの人はどう考えているのか気になります。ぜひ考えをお聞かせください。
リリース間隔が開いてようが、開発はアジャイルにやった方が良いのでは?
はじめに
Xで「toB SaaSはリリース期間を長く取る必要があるので、アジャイルでない開発プロセスでも良いのではないか? (意訳)」という内容の投稿を読み、自分の中では答えが出ている問いだったのでメモがわりの投稿です。
「リリース間隔は短ければ良い」とは限らないプロダクトは確かにある
プロダクトにもよるのでしょうが、「toB向けのプロダクトでは必ずしもリリース間隔が短いことが良いとは限らない」のは事実だと思います。
- プロダクトの展開前に変更内容の周知や、サポート・セールスの教育・学習が必要
- プロダクトの更新作業にコストがかかる。オンプレで運用されているとか
- そもそもユーザーが頻繁なアップデートを望んでいない など
リリース日の決定を開発以外の部門に委ねるメリット
「開発の終了 = リリース」だとすると、リリース日に合わせて成果が最大化できるように開発スケジュールを組もうと考えますが、「開発の終了 != リリース」だとどうでしょう?
「この機能は開発が完了しました。いつリリースしてもらっても大丈夫です。セールス・マーケティング・サポートの都合に合わせて、一番良いリリース日を好きに選んでください」と言えると、いろんな選択肢が考えられます。マーケティングは大きなプロモーションを打とうとするでしょうし、サポートは問い合わせが多い事項の改善を早く出したいと考えるでしょう。リリースタイミングを短くできなくても、いつリリースするかがコントールできると、事業として取れる打ち手は広がります。
過去に聞いて良いと思ったtoBプロダクトのリリース管理のやり方
「オンプレ環境にインストールして利用するタイプのソフトウェア」でしたが、年に3回のリリースが予定されており、「いつリリースされるか」「リリースに何が含まれるか」は公開されていませんでした。問い合わせをするとおおまかなロードマップは共有してもらえ、「いつのリリースに含まれるかは確約できないが、開発チームはこの機能に取り組んでいる。これが搭載されればこんな課題が解決できる」という話は聞くことができました。確約ではないけどおおよその実現時期も知ることはできました。展示会に合わせた大きなプロモーションとともにリリースされることもあれば、しれっと新バージョンが出ているということもありました。内部では希望の期日に開発が間に合うことも間に合わないこともあったと思うのですが、リリース日を調整するなどして対応していたのではないかと思います。
まとめ
リリース間隔が開いていて短くすることが叶わなくても、開発はアジャイルに短いサイクルで確認しながら進めた方が良いし、開発の終了とリリースを同じにしなければならない理由はないはずです。リリースのコントロールをステークホルダーに委ねることができると、事業上の選択肢を広く持つことができます。
FaST agileとは
はじめに
ログラスさんで取り組もうとしているFaST agileを下記の資料で知り、調べてみました。
FAST概要
"Fluid Scaling Technology (for Agile)"を標榜した、自己組織化を重視した軽量なフレームワークです。 日本語ガイドも公開されています。
※ 以下「スクラムでいうXX」といった表現を避け、FASTガイドの文言をできるだけそのまま受け取ってみます
用語
コレクティブ
活動に必要な人全員を合わせてコレクティブにします。 コレクティブは自律的で、十分な権限を持ち、自己組織化していて、自己管理できる人達によるグループで、共通の目的のもとに集まり、プロダクトのディスカバリーとビジネスゴールの達成ができる能力を持ち合わせています。
ある目的のために集まった開発活動に必要な人全体を指して「コレクティブ」と呼びます。ある目的の粒度はフィーチャーやプロジェクトといった単位ではなく、プロダクトビジョンなど大きな粒度のような気がします。 コレクティブにはエンジニアだけでなくプロダクトマネージャーやデザイナーも含めるのでしょう。ステークホルダーも含めてコレクティブと呼ぶのかは分かりません。 コレクティブの参加者には「自己管理」が求められ、コレクティブは「自己組織化」してプロダクトのディスカバリーとビジネスゴールの達成のために「十分な権限」も持ちます。
ガイドには詳細の記載がありませんが、コレクティブに集まった面々は「セットアップ」と呼ばれる活動を行い、「目的・ミッション(ビッグピクチャー)」および「活動に対する理解と進捗」を可視化するワークショップを行うそうです。
バリューサイクル
以下の3ステップがバリューサイクルを構成します。3ステップを継続的に繰り返します。
1) 自己組織化する: ミーティングをファシリテートし、人々が自己組織化して活動を行うためのチームを形成できるようにします。
2) 活動する:各チームは、自身が集った活動アイテムのために計画し、協働します。
3) 同期する:短い周期でコレクティブはミーティングを開催し、学びを共有し進捗して、プロダクトの状態と現在の状況について共通の理解を得ます。
開発の区切りを「バリューサイクル」と呼びます。固定期間ではなく、ガイドでは「コレクティブが2日間のバリューサイクルを実施した後に3日間のバリューサイクルを実施することもあり得ます」と書かれています。 メンバーは自己組織化して何の活動をするか、どんな担当割(ガイドではチームと表記)で行うかを計画し、協働します。 バリューサイクルの終わりにはミーティング(FaSTミーティング)を開催し、活動の進捗や学びを共有し、プロダクトの状態・状況についての理解を揃えます。
ロール
メンバー：コレクティブに所属する全員がメンバーです。
プロダクトマネージャー：戦略、プロダクトディスカバリー、そして顧客とビジネスに価値を届けること、のそれぞれの仕組みがどうなっているかを理解しているメンバーです。
チームスチュワード：バリューサイクル内で、チームに奉仕すると有志で申し出たメンバーです。
フィーチャースチュワード(オプション)：あるフィーチャーのコンセプトから完成に至るまでの全てを理解することを有志で申し出たメンバーです。フィーチャースチュワードは開発の進捗について議論をする能力を持ちます。
コレクティブには4つのロールがあります。1コレクティブ=1プロダクト という制限はなく、コレクティブには複数のプロダクトマネージャーが所属できます。 チームのお世話係となる「チームスチュワード」と機能開発のお目付け役となる「フィーチャースチュワード」は自己組織化により立候補したメンバーが持ち回りで担当します。
ツール
コレクティブアグリーメント:常に更新されるドキュメントで、コレクティブがどのように協調するかを記述したものです。少なくとも、どのように意思決定がなされ、どのように対立が解消されるかについて記述してあるべきです。
マーケットプレイスボード:現在のバリューサイクルでどの活動アイテムが選ばれ、そのアイテムのために集まったチームに誰がいるかを可視化するためのものです。
コレクティブ内の意思決定・コミュニケーション方針など行動指針を「コレクティブアグリーメント」としてまとめます。 またバリューサイクル内の活動計画・進捗状況は「マーケットプレイスボード」で可視化を行います。
バリューサイクル内の開発の流れ
タスクをメンバーに分配するのではなく、タスクの周りにメンバーが集まる仕組みをベースとしている。
1. プロダクトマネージャーの指針表明
プロダクトマネージャーが、みんなを鼓舞するメッセージと共にバリューサイクルを開始します。 そのメッセージは、理想的にはビッグピクチャーを改めて共有する形をとります。 場合によって、プロダクトマネージャーは前のFaSTミーティング以降にプロダクトにどのような変化があったか、例えば新たな観点の登場や緊急度の変化など、を強調することもあります。
プロダクトマネージャーの話から始まる。 ビッグピクチャー(=目的・ミッション)をその時点の情報に基づいて見直し、再重要だと考えている課題や解決したいことをコレクティブのメンバーに対して説明します。
2. 自己組織化し、活動の周りにチームを形成
オープンスペーステクノロジーにインスパイアされた進め方で、コレクティブは新たなバリューサイクルのために、活動のマーケットプレイスを作成します。 チームスチュワードは立候補して自ら立ち上がり、1人ずつ短い「ピッチ」を行い、活動に奉仕する意思表明をします。 そして、チームスチュワードがその活動に対応するプレースホルダをマーケットプレイスボードに置きます。 すべてのチームスチュワードがピッチを終えると活動のマーケットプレイスができあがります。 メンバーはそれぞれ、どうすれば最大の貢献ができるかを考え、マーケットプレイスボードにある活動アイテムの隣に自分の名前を置きます。 こうして、各自の選択によってチームが構成されます。
プロダクトマネージャーの話を踏まえ、「こういう活動が必要ではないか」と考えたチームスチュワードが立候補し、どのような貢献をするか説明した上で、マーケットプレイスボードに活動を記載する。 その後メンバー各自がどう貢献するかを考え、マーケットプレイスボードの活動の側に自分の名前を記載する。 これにより誰が何の活動に貢献するのかが見えるかされ、バリューサイクル内の担当割(チーム)が形成される
このあとチームごとに活動をタスク分解し計画を行う。計画を詳細化することで複数チーム間の依存関係やリソースの過不足などが見つかるが、FaSTでは自己組織化によって解決する。チーム間で依存性をどう解消するかを話したり、メンバーはどの時点でもチームを移動して貢献することが推奨されている。
価値・原則・柱
ガイドからの抜粋です。 ざっと眺めてみるだけでもどんな考え方をベースにしているフレームワークなのか伝わるかと。
考えたこと
フレームワークの狙いは何か
読んでいてどうしてもスクラムやカンバンといった既存手法との差異が気になってきます。 自分はスクラムで起きるであろう下記の課題の解決を狙っているのかなと感じました。
- 固定化された開発リズム→バリューサイクルの期間は変えても良い
- 固定化されるスクラムマスター→チームスチュワードは立候補
- スプリントが進んでも深まらないプロダクトへの理解→バリューサイクルの最初にプロダクトオーナーが最新状況を都度説明
- 複数チームのスケーリング調整→チームスチュワードのピッチにメンバーが自発的に集まる仕組み
- チームで成果を出すため、個人の強みや専門性を抑えてしまう→ピッチにメンバーが集まる仕組み & いつでも移動可というルール
とはいえ、良い取り組みはスクラムを使っていようが導入可能なものにも見えます。
できそう?
どっちにもなりえそう、スケールさせるための前提が挑戦的なので「これは(やる側が)試されるな…」というのが少し前にみたときの印象でした。これでスケールしたらおもしろそうですよね
— Kakutani Shintaro (@kakutani) 2024年7月16日
↑角谷さんのツイートが"まさにコレ！"でした。
「プロダクトのために集まるメンバー全員が高い自律性を持ち発揮し続けることを前提としたフレームワーク」なので、前提条件を成立させることがまず非現実的なのではと思いました。FaSTのやり方がまずいのか、自律ができてないのか、他に何か問題があるのか切り分けることにずっと苦労しそうです。
下記のどちらかに早晩収束しそう
- 自己組織化を最大限に引き出せ、はちゃめちゃな所まで辿り着ける
- そんなことは人類には早すぎるので、はちゃめちゃな状態に早晩なる
ログラスさんが取り組むようですが、「FaSTが良いと公言し実際に推進する人がいるなら、人間の光の部分を強く信じている人」なのではと思いました。 私はやっていいよと言われても色々悩んで実行に移せないと思います。
参考文献
「プロフェッショナルプロダクトオーナー」を読んで
翻訳者の皆様から献本いただきました。
こんな書籍です
「アジャイルなプロダクトマネジメント を実施していくための心技体(考え方・知識・打ち手)が網羅された本」です。タイトルから「スクラムのプロダクトオーナーを担当している人が、認定資格を取ってさらにスキルアップをしていくための書籍」かと思っていましたが、そんな誤解からこの書籍を読もうとしないのはもったいないと思います。タイトルを見ただけで判断するのではなく、スクラムだから自分には関係ないとか思わず、中堅以上を狙っていくプロダクトマネージャーに是非読んでほしいです。
世の中のプロダクト開発のスピードが上がってきていて、開発は「アジャイル」に取り組むことが普通になってきている中で、「プロダクトマネジメントをアジャイルにやる」ってどういうことだか気になりませんか? 書籍で扱う内容に新しいものはなくとも、重要なものから順を追って、スクラムの考え方をベースとしながら、スクラムでない開発であっても役立つマネジメントの話が盛りだくさんです。
ここが好き
書籍は3部構成で「第1部 戦略」「第2部 スクラム」「第3部 戦術」と大きな柱があります。第1章が戦略からはじまるところが最高だと思っていて、わかっているようで今一つわかっていない「ビジョン(Vision)」「価値(Value)」「検証(Validation)」がたっぷりページを割かれて説明されています。
プロダクトマネジメントのすきまとそれを埋める３つのV（Vision, Value, Validation ）。スクラムガイド2020年版のアップデートもこのすきまを埋める意図があったかな。#プロフェッショナルプロダクトオーナー pic.twitter.com/9uyHnxaeAt
— Arata Fujimura (@aratafuji) 2024年7月5日
会社のビジョンや戦略はあり、ボトムアップのスクラムやスプリント計画はあれど、その間に「プロダクトマネジメントのすきま」を感じたことはありませんか?
- 良いプロダクトビジョンはどんなものか、そしてそれはビジネス戦略とはどう違うのか
- 価値は何で測られるのか (書籍では"お金(収益と費用)"とはっきり言ってくれる)
- 検証とはいってもMVPの作り方ってパターン(プロモーションになるもの、概念実証をしたいもの、将来性をみせたいもの、完成したかのように顧客に見せて反応を見るものなど)があるよねという話
こんな話が100ページもあります。
第2部はプロダクトマネジメントの観点から、スクラムの知識を体系づけて説明してくれます。第3部はアジャイルコーチが教えてくれるようなスクラムを実践する現場でよく直面するであろう悩みや困りごとに対する答えをズバッと提示してくれています。
こんな方におすすめ
ボトムアップでスクラムを始め、アジャイルな開発はうまくできるようになった。だけどプロダクトの大きな方向性や会社の戦略とうまく合わず、経営層やプロダクトの責任者とのすきまをどう埋めていくべきなのか途方にくれている・・・ そんなプロダクトマネージャーやプロダクトオーナー、そして社内でアジャイルに詳しいコーチ役として活躍している人にぴったりだと思います。
「アジャイルチームによる目標づくりガイドブック」を読んで #目標づくりガイドブック
事前レビューに参加させていただいた書籍を頂戴しました。この記事を公開した2024年7月15日時点では発売されておらず、2024年7月22日発売予定です。
昨年出版された私の書籍「アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知」のシリーズ本で、アジャイルな開発で役立つであろう目標づくりの知識や考え方について網羅的に触れられています。書籍の内容が興味深すぎて、事前レビューを真っ先に完走したのは良い思い出です。著者の小田中さん、編集の方の次にこの書籍を読み終わった読者は私のはずだと自信を持って言えます！
こんな書籍です
目標設定のやり方から始まり、目標を達成するまでのチェック頻度やふりかえり方、チームメンバーが助け合う関係性をどう構築するか、チームの開発生産性など、 目標を達成して大きな何かを成し遂げるのに必要なこと が網羅的に紹介されています。業務で何かしらの目標設定をしている人がほとんどだと思いますが、「目標設定のやり方によって成果を出しやすくできる！」と言われると、言われるとどう感じますか? 考えてみれば自明なことなのに、そこに向き合うことは簡単ではありません。知識が不足しているだけでなく、目標の継続な見直しをどうやるか、うまくいってない時の気持ちの持ち方など、詳しい誰かから教えてもらえる機会はなかなかありません。この本はそれらの悩みに答えてくれます。
ここが好き
RSGTやスクラムフェスなどのカンファレンスで目標を扱った発表はこれまでもありましたが、紹介される参考文献はどれも「難易度もページ数も重ため(主観)」で、「複数冊を読んで全体感が掴める」状態で、目標設定に困っている人のレベルと、課題が解決できるまでに必要な勉強コストに大きな隔たりがありました。この書籍は1冊で幅広い内容が触れられており、元の参考文献もきちんと紹介され、チームの成長に合わせた説明が漫画と共に行われており、軽い読み口で多くの知識が吸収しやすいように書かれています。
事前のレビューでは「文章の節々に小田中さんの熱いパッションがほとばしっていて、コッテリな読み口の本になりそうだ」と思っていました。が、いただいた書籍では著者の思いはそのままに、より多くの人に読んでもらいやすく進化しています。
またコラム執筆者が豪華で、書籍をいただいて真っ先に読んだのも全員分のコラムでした。 いろんな立場で活躍されている各者の知見も合わさり、いろいろな角度から目標設定について考えを深めることができます。
- 目標達成マシンにならないために（芹澤 雅人）
- 目標は記憶に残すのではなく、記録に残そう（市谷 聡啓）
- 自分の成長と組織からの評価は、重なるが別のもの（小笠原 晋也）
- 戦略とは今やるべき3つの優先度リスト（松本 勇気）
- あなたは自分のゴールを持っていますか？（新井 剛）
- スクラムチームにおける評価のあり方（川口 恭伸）
- 目標設定と確認はいつやるの？（森 一樹）
- ワクワク目標を立てる意義とは？（湯前 慶大）
こんな方におすすめ
少し長い期間(3ヶ月〜1年)を見据えて、チームをまとめて大きなゴールに辿り着くことを期待されるリーダーの方、および苦しんでいるリーダーを助けたいと思うチームメンバーに刺さるのではないかと思います。
出版に絡んで、イベントや登壇もあるようなので、こちらも合わせておすすめです。
大吉祥寺.pmで「組織のスケーリングと持続性」を話してきました #kichijojipm
はじめに
吉祥寺.pmの10周年イベント 大吉祥寺.pmで登壇機会をいただき話してきました。 吉祥寺.pmは「おっ、面白そうな話をしている人が多いな」と以前から存在を知っていたものの機会が合わず、いつか行ってみたいなとずっと思っていた勉強会でしたので大変嬉しかったです。大吉祥寺.pmで扱われたトピックも非常に幅広く、いつもの吉祥寺.pmの良さを失わず、大人数で盛り上がれた良いイベントだったと思います。自分の発表もその一翼を担えていたなら光栄です。
名札とランチ企画が素敵で他のカンファレンスにも広がってほしい
カンファレンスは参加者の名前やアイコンを記載する名札を配るのが一般的ですが、名札の裏側がランチ情報やヘルプページ動線になっていました。QRコードを読むだけでたどり着け、とても賢い仕組みだと思います。
また名札には「ランチに食べたいものは」の記入欄があります。参加者同士の会話のアイスブレイクかと思いきや、ランチ時間にグルーピングをして初めて会った人同士でもランチが楽しめる仕組みでした。私もラーメンが食べたかったお二方と、青葉のラーメンをご一緒する機会をいただき、ラーメンも道中の会話も楽しい時間が過ごせました。Xのタイムラインには名札と一緒に撮った料理写真がたくさん流れてきて楽しい思い出がたくさん生まれたことが確認できました。これも他のカンファレンスで広がってほしい。
素晴らしいカンファレンスができたのもMagnolia.kさんがいたから
吉祥寺.pmの主催者 Magnolia.kさんのブログ(Magnolia Tech)を以前から購読していたものの、「どんな人が書いているんだろうな?」というのはずっと疑問に思っていたことでした。会期を通じてMagnolia.kさんとお話しして感じたのは「この方はどんなことも受け止める広い度量があり、良いところや楽しいところを見つけることがとても上手な方なのだな」ということです。前夜祭から終始楽しそうにしておられ、参加者の方と積極的に交流を図り、カンファレンス全体を包む温かい・後押しする空気感はMagnolia.kさんが10年間吉祥寺.pmで広げた結果なのだと思います。
大吉祥寺.pmでとても楽しい時間が過ごせました。運営の皆様、参加された皆様、お話しする機会がつくれた皆様ありがとうございました。
期待からはじめる
今年は「今の仕事にワクワクしていません」という声をメンバーから聞く機会が増え、考えこむ機会が増えました。ワクワクとは何だろう・・・
新しい技術を取り入れること、新しい領域に取り組むこと、プロダクトや事業を大きく成長させること。さまざまなことが考えられます。 一方でその時の市場環境や事業環境を踏まえると、いつでも誰にでもワクワクする仕事は用意できないのではないか、そう考えている自分がいました。 でも「ワクワクしない」気持ちは、本当にそれらの要因から来ているのでしょうか?
数ヶ月に渡って悩んでいたある時、私が一緒に働くメンバーは「誰かの役に立つプロダクトを開発すること」がやりたくて集まってきていることをふと思い出しました。 採用面接で、中長期のキャリアを考える面談で、飲み会やふとした雑談で、何度も話し何度も聞いた話です。 そこに気がついてからは「誰かの役に立つと感じられるプロダクトが開発できていない」と問題を捉え直しました。 ユーザーにとっての利用価値や、事業戦略における重要性を噛み砕いて細かく説明することも考えました。しかし求められていることはこれでは無さそうだと考え、実行に移してはいません。 ワクワクを引き出すには、もっとメンバーの根源的な要求に応える必要があるはずです。
最終的に取った打ち手はすごくシンプルで「抽象度が高いまま課題をチーム/メンバーに与える」ことを意識して増やしました。 仕事の難易度は上がり、課題の理解や分解のためユーザーに接する機会が増え、企画・デザイン・開発といった職責の枠を超えて協力する必要が出てきます。 「難しい仕事をお願いしていることは認識しているつもりです。でもこれが会社のため・事業のため・皆さんのためになると考えてお願いしています。」メンバーが壁に当たっている時、意識して何度も口にして伝えました。
マネジメントキャリアを長く積むほど、「このぐらいの難易度が良いだろう」と無意識のうちに手加減ができてしまいます。段取りを整えてあげたり、大きな仕事の一部を切り出して与えたり、できるレベルの仕事に調整することはマネージャーが自然と身につけるスキルの1つです。でも、もっと期待をしてあげるべきなのではないでしょうか? コントロールできる範疇での挑戦から得られる学びに、ワクワクややりがいを感じてもらえるとは思えません。
今のメンバーといつまでも一緒に働けることはないでしょう。別れの時に「もっと色々挑戦したかった」と言われることはとても悲しいことです。誰の何のために仕事の難易度をセーブしていたのかと。 「相手に期待する」という当たり前のことから始める必要がある、これが私にとっての今年いちばんの学びでした。
この記事はEngineering Manager Advent Calendar 2日目の記事でした。
