tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

"プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける"の感想

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

  • 作者:Melissa Perri
  • 発売日: 2020/10/26
  • メディア: 単行本(ソフトカバー)

社内で実施した読書会 & 議論で大分満足してしまい、記録を残し忘れていました。 今更ですが自分の感想メモです。

1章 : 価値交換システム

競合でその機能が成果を出していることを確認しているか?

競合がある機能をつけると「是非うちでも」という話が出てきがちで、2番手以降のプロダクトだと「星取表で負けてるから売れないんだ」という話に流れがちですが、「競合のその機能はユーザーに響いているんですか?」という返しはしたことなかったかも。でも「わからないけど星取表で全体的に負けているからダメなんだ」とか返されてぐぬぬとなりそう。こういうやりとり仕事でしていると、まずいいプロダクト作れていないので気をつけていきたい。

企業は従業員を顧客やユーザーと近づける必要がある。それによって学習できる。

これですね。

2章 : 価値交換システムの制約

リリースしたものがうまくいったかはどうわかりますか?

正常に動作した時の挙動や、受け入れ条件の話はよく出るけど、ユーザーの行動・振る舞いをプロダクトによって良い方向に変えたいことがゴールなので、どうやって知ることができるかはもっと気にしていきたい。

アウトカムってもうちょっといい用語ないかな?

この本を読んだ人同士だと「それってアウトプットじゃ無い? アウトカムは何だろう」と話せるけど、読んだことがない人に「アウトカムは何ですか?」と聞くとアウトプットが返ってきそう。もっといい日本語ある気がするんだけど思いつかない。読書会だと「Burning Needsどうだろう?」と思ったのですが、アウトカムよりさらに狭い界隈にしか刺さらなそう。

3章:プロジェクト / プロダクト / サービス

望ましいアウトカムを得られるまで組織を最適化する

アウトカムを目標に据えて、イテレーションでプロダクトを磨いていく。その過程で開発プロセスや開発組織も磨いていかないといけない。

プロジェクトではなくプロダクト

これは自分もことあるごとにいうようになったけど、プロジェクトやめていきたい。

4章:プロダクト主導組織

「ビジョナリー気取り問題」ってありません? エセジョブズ問題

自分の作りたいようにプロダクトを引っ張ることを目的としているPdM志望の人ってよくみませんかという話。 書籍では「ビジョナリー」と紹介されていたけど、TwitterSNSで見る感じ大抵の人はたまたまくじに当たった一発屋ジョブズでは無い感じ。 エセジョブズの人は夢を壮大に語るけど、何となくユーザーを向いてない気がするんですよね。

5章:私たちが知っていること、知らないこと

「未知の未知」が最近ようやくしっくりくるようになった

既知と未知の組み合わせの4象限の話。PdMは自身が手を動かすことによって未知を既知に変えていかなければならない。

6章:悪いプロダクトマネージャーの典型

PdMはミニCEOではない

会社(プロダクト)のビジョンを変えたり、人事をどうこうする権限がないので、CEOではないのだという話でした。 確かにその通り。

アジャイルではアイデアを検証するステップが抜け落ちている

これはここ1年ぐらいで痛感しています。 「小さく始めるんだ」といいながら、うまい検証のやり方を実験できてない感じ。

会社でPdM(プロダクトマネージャー)研修できそう。 ストーリーの書き方、ミーティングのやり方、要望の集め方、テストのやり方

PdMの育成プロセスがないよねという話から。 「いいPdMの排出企業」もこれといった会社が無い気がします。

自社でも育成に取り組んでいますが、「みてやって覚えろ」だけじゃなくて、定期的に勉強会・研修を整備しても良いのかもしれない。 複数社で協力してやると運営も楽になって良さそう。

7章:優れたプロダクトマネージャー

PdMはPO(プロダクトオーナー)を内包する

これもそうですねという話。 スクラムを使っていると、プロダクトオーナーが全てプロダクトの責任があるように思ってしまうが、責務を書き出してみるとPdMの方が多い。

10章:戦略とは何か?

優れた戦略とは詳細な計画のことではありません。 戦略は意思決定を助けるフレームワークである。

何をやるかのリストより、何をやらないかを決める根拠にできるものがよい戦略・フレームワークだなと思うようになりました。 中期計画も機能のリストじゃなく、重要なアウトカムのリストで作っておけば軸がぶれなくて良さそう。

11章:戦略のギャップ

上位の意図をどう実現するかは任せるべき。 なぜ必要なのかは上から下に伝える。どう実現するかは下から上に報告してもらう。

普段から心がけていることではありますが、判断に使うであろう情報はできる限りオープンにしておき、判断を委ねるのがスピードが出て良いですね。

12章:良い戦略フレームワークを作る

チームに制約を設けた方が動きやすくなるが、ミッションで狭めるのが良いかというと悩ましい

今の開発チームは会社のほぼ全領域に携われるようにしているけど、チームや組織ごとにある程度の制約を設けた方が自分たちで目標立てやすくなって良いのかなともやもや。 制約を入れた方が良いことには同意しつつ、どう入れるかはプロダクトの範囲ではない気がしています。

失敗に成功したい

気持ちとは裏腹に成功した失敗の実例が思い出せず。小さな実験しかやってないのだろうなと。 失敗しないと許容文化も生まれない気がするのでもっと実験していかないと。

13章:企業レベルでのビジョンと戦略的意図

ミッションは企業の存在理由を説明する。 ビジョンは目的に基づいてどこに向かっていくかを説明する

ビジョンとミッション、以前はしっくりこなかったのですが、ビジョンがしっかりしてる現職で働いていてこれは良いものだなと思うようになりました。 ビジョンの存在が強すぎてミッションが弱くなっているのでこれを時間作ってブラッシュアップしていくといいんだろうな。

15章 プロダクトのカタ

価値提案の中心でないものに対して、凝ったものを作らない

これ。 SaaSが増えてきたからか、自身の考え方が変わったのか、お金で解決できるものはお金で解決した方が良いなと考えるように変わりました。

16章 方向性の理解と成功指標の設定

AARRRはユーザー満足度について語っていない

これ。 定量指標を意識することは大事だけど、何を見ていて、何を見れてないのかは常々意識しないといけない。

17章 問題の探索

問題を根本的に理解しなければ、適切なソリューションを意図して作ることはできない

同じアウトカムに対してイテレーションで取り組んでいると、問題の理解度がだんだん深まってきて適切なソリューションにたどり着ける気がする。 プロダクトの弱いところを全体的に手直ししようとして表層的な問題に取り組み続けるよりも、自社の未来につながる問題に継続的に取り組んでいかないといけない。

「ユニコーン企業のひみつ」を読んで考えたこと

ユニコーン企業のひみつ」を読みました。 きちんとした書評は会社のTech Blogで公開予定のため、ここでは個人的に感じたこと・考えたことを書き留めておきます。

どこから手をつけるのが良いのか

書籍だと変わった後の姿の紹介しかないため、自分の会社で同じように変えていこうとなるとどこから取り組むべきかに悩みそうです。 自分がやるなら「自律する開発チームを作る→自律する開発チームを増やす→目標を徐々に揃える」かと思いました。 自社の開発プロセス改善もそう言えばこの順でした。 Spotifyモデル(2013年)・Spotifyリズム(2016年)の公開時期を踏まえると、Spotifyもこの順のように思えます。

自律したチームはどこまでやるべきか

書籍では決められた手順通り開発するチームを「野菜切り」と比喩していますが、真に自律したチームはいったいどこまで出来るのでしょう?

https://res.infoq.com/articles/what-are-self-organising-teams/en/resources/AuthorityMatrix_figure1.png

自己組織化チームとは何か?で紹介されている「自己管理型チーム(タスクの実行、進捗管理)」かなと思っているのですが、書籍を読んでいると「自己設計型チーム(チームのデザイン、チームが運営される組織面の変更)」かそれ以上を求めているのかなと感じました。でも書籍の中ではプロダクトオーナー(PO)・テックリード(TL)・アジャイルコーチ(AC)から構成されるPOTLACなるチームが言及されているので、組織面の変更権限はこっちにあるような気がするんですよね。 だとするとチームの自律の範疇はフランチャイズオーナーの店舗運営ぐらいなのかなーとか思ったり。

「自律してね」チームに伝えると、多くのケースで何でもかんでもやろうとして動きが悪くなるので、書籍に出てくる下記の期待値表現は短くて今後使っていこうと思いました。

自律せよ、だが局所最適に陥るな。

イテレーションはプロダクトを試行錯誤して磨いていくこと

書籍の序盤に出てくる表現。iPhoneを思わせる挿絵があるけど、「Appleだって最初からiPhone12を発売できたわけではないでしょ」という説明は良さそう。 同じ対象を何度も何度も改善しながら作り直すことが大事なんですよというメッセージは伝えていきたい。 ただブラッシュアップとか違う用語がいいかなと思いました。 イテレーションは開発サイクルそのものを指して使われるケースが多い気がして、新たな意味を持たせるには広まりすぎたと思います。

課金コードは何番?

うけた

でもこれがうける人は過去にこの体験に触れた経験があるということで・・・

インハウスのアジャイルコーチがマネジメントチームの一翼を担う

プロダクトオーナー(PO)・テックリード(TL)・アジャイルコーチ(AC)から構成されるPOTLACというマネジメントチームが紹介されていますが、国内の企業でインハウスのアジャイルコーチがいて、その人にマネジメントチームに入ってもらう事例は聞いたことがありません。アジャイルコーチは外部からスポットで招聘していたり、アジャイルコーチが社内にいてもマネジメントチームの一員ではないと思うんですよね。うちはこれできているよという会社があったら話を聞いてみたいです。

日本のアジャイル実践者は外部コーチが多い気がするので「Spotifyではインハウスでアジャイルコーチを雇い、マネジメントチームに参加させている。日本もこうやっていくべき!」みたいな啓蒙活動するといいんじゃないかな。(適当)

Spotifyは合意形成の文化である。

ヤンテの掟に言及されているのが良かったです。Spotifyの開発文化はこれに根ざして形作られた「合意形成を重視する文化」だと考えるとしっくりきます。

  1. 自分がひとかどの人物であると思ってはいけない
  2. 自分が我々と同等であると思ってはいけない
  3. 自分が我々より賢明と思ってはいけない
  4. 自分が我々より優れているという想像を起こしてはいけない
  5. 自分が我々より多くを知っていると思ってはいけない
  6. 自分が我々を超える者であると思ってはいけない
  7. 自分が何事かをなすに値すると思ってはいけない
  8. 我々を笑ってはいけない
  9. 誰かが自分のことを顧みてくれると思ってはいけない
  10. 我々に何かを教えることができると思ってはいけない

ロードマネージャーの負担が大変そう

スクラムを発展させたLeSSだとスプリントのタイミングで全チームの方向性・リズムが強制的に揃うけど、Spotifyモデルだとカンパニーベットの遂行に責任を持つロードマネージャーの負担が凄そう。

というか彼/彼女らは本書で批判している"プロジェクト"マネージャーなのではないか?

Spotifyへの憧れ

そういえば2年前に転職活動をしていたときに、Spotifyを受けてみようかと考えていたくらいには憧れていたことを思い出しました。 当時は東京の募集がなく(今もオープンのポジション無いようです)、フルリモートもなかったことで調べただけで終わってしまいましたが。

www.spotifyjobs.com

Spotifyへの憧れはSpotifyモデルを公開した、Henrik Kniberg氏由来で、彼を自分のキャリアのロールモデルとしておいています。 今はMojang(マインクラフトの開発元)にいるそうですが、きっといろんな実験をしているんだろうな。

2021年3〜4月に社内で共有したアジャイル開発関連の記事

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第4弾です。

ノウハウ・知見

スクラムで回す開発の実際の話

ここが好き

より良いものを作るために、プロダクトマネージャーと開発者が話をした方がいいなら、手を止めるのを気にしない。

ただ、全員が話をすると時間を持っていかれすぎちゃうから、代表で1人が話をするくらいがいいかな。その人が「他のメンバーの意見も聞いたほうがいいな」と思ったら、みんなに聞く。くらい。これは開発者を代表するくらいのスキルが必要なので、テックリードというロールの人がやる。

サービスの運用による突発対応は、あるものとして考える。突発対応が入ったらデイリースクラムでチームとしての動きを話し合う。「今日は突発対応を優先させるから、別のチケットの作業を止める」みたいなの。もし日中に緊急のものが入って次の日のデイリースクラムまで待てないって場合は、テックリードが開発者を集めてチームとしての動きを話し合う。

専門チームは他にも色んなチームとやり取りをしているから、そのようなチームとのやりとりはスプリントをまたいでやることになる。それも全然気にしない。 組織の活動も後輩の育成も楽しい。

大切にしてるのは、そういうのも全部ひっくるめたうえで開発できるものが、自分たちの健全なスピードなんだなって受け止めること。

bufferings.hatenablog.com

リソース効率とフロー効率

細く長く開発続けるのやめたいねーという社内の話から

www.slideshare.net

Whole teamという考え方

勇気をもって質問する。分かるけどまだまだできてない時あります

izumii19.hatenablog.com

角を立てない質問の仕方

Working Agreementでは下限も話し合うと良いのでは無いか?

夕方にやる短いミーティング→「帰りの会

弊社でも帰りの会いくつかできました。

blog.h13i32maru.jp

チームラーニング

どういう生活リズムか、強み・弱み、コミュニケーションは話すのが良いかテキストが良いか、MTGに対してのスタンスなど具体的な質問をチームで共有することで働きやすい環境づくりを目指すチームラーニングというプラクティス

blog.kyash.co

ホワイトボード(Miro)の使い方工夫

テンプレートを作ると「いきいき」しないよねという学び

note.com

スクラムマスターのキャリアを考える上で、ぜひ立ち止まってやってほしいエクササイズ

toshiotm.medium.com

他社事例

atama plusのLeSS事例

自分の感想

  • 議論を重視する文化があったからか、議論時間が無駄に増えてしまったのかも。
    • Rettyではリファインメントの人数を減らし、信頼してもらう方向に倒している
    • atama+のリファインメントは10〜20名で、そのうち8人ぐらいが議論する感じらしい
  • LeSSを導入する問題背景が全社で揃ってなさそう
    • Rettyの場合は「ミッション間の根回し」にパフォーマンスが左右されることが1番の課題だった
    • 「開発効率が上がる」ぐらいの意識なので、LeSS導入過程でパフォーマンスが落ちる(新しい領域をチームが学習している)ことに耐えられなかったように見える。

楽天 椎葉さんのチーム作り事例

うちと似ているなーと思うところもあるし、うちより洗練されてるなーと思うところもある。さすがな感じ

bufferings.hatenablog.com

GMOのレゴスクラム

developers.gmo.jp

勉強会・カンファレンス

モンハンスクラム

イクラとか繰り返し作業ゲーとスクラムの学習は相性が良いのかも

nrs-seminar.connpass.com

入社1年目の新人がふりかえりを習慣化して学んだこと

その他

スクラム用語を使わないスクラムの説明

スクラムアジャイルのおすすめ本

個人的には「アジャイルな見積もりと計画作り」と「エクストリームプログラミング」で良いんじゃないかと思っています

note.com

危ない兆候

SmartHR製のプランニングポーカー

リモートでバックログリファインメントをやる際に、物理プランニングポーカーを使うと顔出しする動機付けになるかもなーと思ったり。

cocoda.design

ボブおじさんのインタビュー翻訳

CleanAgileが書かれた背景を掴むのに短くまとまっていて良き。

izumii19.hatenablog.com

“The New New Product Development Game”とAgile with ScrumとLean

medium.com

ユニコーン企業のひみつ/訳者あとがき

scrapbox.io

ユニコーン企業はなぜスクラムをやってないのか」に対してと思われる原田騎郎さんのツイート

LeSS StudyでRettyでの大規模スクラム事例紹介をしてきました

2021年4月17日に行われたLeSS StudyでRettyでの大規模スクラム事例紹介をしてきました。

less-study.doorkeeper.jp

先月のatama plusさんの事例紹介に続いての事例紹介でしたが、多くの方に興味を持っていただいて参加いただき、自分たちの取り組みを整理する機会をいただくことができ感謝しております。

1時間半の長丁場でしたが、参加してくださった皆様、遅くまでお付き合いいただきありがとうございました。

反応など

Discordで頂いたQ&A

Q: チーム横断のリファインメントがどんな感じのことをするのか

A : 複数チームでのバックログリファインメント - tuneの日記

Q: 技術負債はどこからあげられてバックログに追加される感じですか?

A: エンジニアが積むことが多いです。ユーザー観点でも影響がある場合は企画担当にお願いすることもあります。

Q: レビュー→振り返り→プランニングの順番を変えている(こだわっていない?)ところはどういった経緯をたどったのか

A: スプリントレビューを朝一(11:00〜12:00)にしているのですが、メンバーのお昼休憩時間が揃いづらく、振り返りを優先するとプランニング開始時間が安定できないからです。食にこだわりがあるメンバーが多いからか、遠くのお店へ外食し休憩時間が長くなることがよくあります。振り返りを先にした方が良いと私も思うのですが、特に問題も起きていないためチームに委ねています。

Q: 1チームスクラムからLeSSになったときにアーキテクチャ的な変化はありましたか?

A: toCtoC、Webとアプリのように領域をまたがる大きな機能で実装箇所を一箇所に統一したり、ボトルネックになっている箇所を協力して解消したりという動きは増えました。

Q: 1チームスクラムに比べてPOと開発者の距離が遠くなったりはしませんでしたか?

A: 企画者と開発者の距離が遠くなったというのはメンバーからも上がっており把握はしています。LeSS導入前は一つの組織で以心伝心で動けるところがありましたが、企画者がWhy・開発者がHowに責任を持つにはそれなりの距離を保ち、議論する風土も必要ではないかなと思い、そちらを育くむように心がけています。

Q: POが歩き回ってコミュニケーションとのことですが、オンラインだと歩き回って会話できない気がしますが、オンラインならでは工夫ってあったりしますか?

A: Slackのチャンネルをよく見て、気軽に話しかけているのを見かけます。

Q: コロナ禍で延期しなければ、大物2つはLeSSのままやっていたんだろうか?

A: LeSSでやりたかったですね。スピードは出せたけど属人化はしちゃったよねという反省があり。

Q: PdM チームは、何チーム何人くらいですか?

A: 3〜4人ぐらいです。目的別に6チームぐらいあります。

Q: プロダクトロードマップとPOの関係性はどんな感じですか?(POが決めている?)

A: プロダクトロードマップはPOも入って議論していますが、作成は別のPdMが主導しています。初めての試みなのでどういう関係が良いのか自分たちも模索中です。

Q: 複数のスクラムチームを立ち上げるにあたり、見本となるスクラムチーム(1チーム?)があったからうまくスケールできた、のでしょうか?

A: スクラムチームとしてうまく回っている時の感じがわかるメンバーがいた方が良いと思います。そうでないとスクラムの問題なのか、LeSSの問題なのか切り分けができないので。

Q: 組織目標というのはビジネス目標ですか?

A: エンジニアリング部門はサービス開発・運用に責任を持つ部門ですので「インシデント数」「着手からリリースまでの期日」「サービスパフォーマンス」などの数値を目標として設定しています。

Q: インフラ的なメンバは各フィーチャーチームにそれぞれいる感じですか?それとも横断的ですか?

A: 横断です。フィーチャーチームのメンバーと混在で24時間サービス監視・アラート対応を行うオンコールチームを組織しており、協力してサービス改善に取り組んでいます。

Q: アウトカムかどうか検証するときに、どうやってされていますか?

A: 自分たちも模索中でプロダクトマネジメントを読んだメンバー同士で「それってビルドトラップでは?」「それはアウトプットでは?」「アウトカムはこういうやつでは?」と議論しながら良い表現・やり方を考えています。

Q: 導入期の自分に一つ助言できるとしたら、どんなことを伝えますか?

A: 2社目の導入なので特に焦りや苦労もなかったのですが、初めて取り組む人に伝えるなら成果が出るのに時間がかかるので「焦るな」でしょうか。

Q: スプリントゴールの話がありましたが、どうやって決めてますか?チームがたくさんあると同時に進むものも多くて難しく苦戦しています。。。

A: 雑多なバックログアイテムをカバーするような表現を昔はしていましたが、最近は主要なもの(上位にある、開発規模が大きい)物に絞り、目的やアウトカムを意識した表現で書くようにしています。

Q: ふりかえりはKPTが多いんですかね?

A: 私がコーチとして教えたのはKPTだったんですが、メンバーが自主的に勉強・いろんなやり方を取り入れています。 現在では「よこなーる」を取り入れているチームが多いです。

ihcomega.hatenadiary.com

Q: 発表内容以外でLeSS/スクラム/アジャイル関連で何か話があれば

A: 自分がマネージャーを担当するメンバーの人数が増え、1人でマネジメントできる上限を超えてしまったため、2021年1月にマネージャーを増やし2人でtoC Web開発を見る体制になりました。 マネージャーが増えた際、組織名を考える必要があったのですが、「人数が増えただけで対等の立ち位置」「マネージャー(評価者)が違うだけで、協力して開発にあたる」ことが表現できるいい名前がないかなーと悩んでいました。

「Web開発第1 / 第2」を提案したのですが、堅すぎてNGでした。 「Webメディア開発(フロントエンド寄り)」と「Web基盤開発(バックエンド寄り)」を次に考えたのですが、メンバーが期待される役割を意識してフィーチャーチームの良さが消えると思いやめました。 他社の例に良いものがないかと探した結果、エムスリーさんの「Unit」に落ち着いています。今の私の正式な役職名は「Retty株式会社 エンジニアリング部門 Web Unit1ミッション マネージャー」です。

Twitter

発表資料で参照した参考文献

"hey Talk" PdM #2「エンジニアと連携した優先順位決め」を聞いてきました #heytalk

f:id:tune:20210330205526p:plain

はじめに

hey.connpass.com

「企画側と開発側で深く議論して優先順位決めるの難しいなー」と課題を感じていたところ、heyさん主催の勉強会を見つけたので参加してきました。

tl; dr;

  • 「やらなければならないもの」はやった先に何が得られるかを明確にすることで、着手順を明確にできたり、取り組むモチベーションをあげることができる。
  • 工数大・リターン大のものはロードマップ積む、工数小・リターン中のものは手が空いた時にやっていく。
  • 職種間を超えて意思決定をするには腹落ちしてもらえるまできちんと伝え合う努力をする必要がある。heyでは随筆のような長文ドキュメントをしたためる文化があり、それを活用している。

LT① 「STORES 決済における【攻めの安定性】」

プロダクト開発で考えなければならないことは2つあり、バランスを保たなければならない。

  1. やりたいこと
  2. やらなければいけないこと

プロダクトの「最適なバランス」はフェーズによって異なる。STORES決済は「やらなければいけないこと」がたくさんあるフェーズ。

「やらなければいけないこと」を「やりたいこと」に変えられると良い。 変えるには「チーム全員が顧客の事業のために必要なことだと理解し、腹落ちする」必要がある。 より具体的には「客が体験するストーリーと紐づけて理解する」必要があると考えている。

決済は客からみて引っ掛かりがあってはならない重要な要素だと考えている。 安定稼働はあたりまえのことではなく、サービスの強みではないかという発想の転換に至ることで、安定稼働という「やらなければいけないこと」を「やりたいこと」に変えることができた。 安定稼働が他社との差別化になるまでやり切りたいと考えている。

プロダクトマネージャーは、なんでもないことにも面白みを見つけられるような素養があると良いのではないか。

LT② 「エンジニアから見た hey の PM とプロダクト開発」

f:id:tune:20210330210755p:plain

開発チームは職能横断チームで構成されている。目的はコミュニケーションの円滑化と、チーム内の意思決定を促すことである。

f:id:tune:20210330210819p:plain

開発チームではプロジェクトを理解したり、自律的なチームを育む取り組みをしている。例えばプロジェクトのREADME(入隊キット)を用意したり、ドラッカー風エクササイズを実施したりしている。

PdMは「何のためにやるか」を考える責務がある、先の開発チームは「どうつくるか」を考える責務がある。 PdMは開発チームから「顧客の理解」について強い信頼(期待)が置かれている。

エンジニアリングマネージャーはプロダクトロードマップの計画をPdMと一緒に作ったり、プロジェクト開始前の事前調査(プリプロジェクト)のサポートでPdMと協力している。

PdMはいろいろ大変なこと・求められる責任の大きさがあるが、「コアの課題を見つけてフォーカスできる」「たくさんのステークホルダーからコアの課題を引っ張り上げる」ことがすごいと思っている。

トークセッション

やりたいことがたくさんある中で、やらなきゃいけないMUST案件をどう扱って優先順位決めるか

「やらなきゃいけないこと」は締め切りが決まっているのでやらないといけない。なので「やった先に何が得られるのか」をイメージして動くようにしている。 それが見えるとやらなきゃいけないことの中でもどれを先に取り組むかが見えてくる。 法律で決まったことは「やらなければいけない」だが、人が「やらなきゃいけない」と言っていることはそうでないことがある。 きちんと見極める必要があり、思考停止しないように気をつけている。。

ユーザーから寄せられる多種多様で膨大な要望に対して、やる/やらない、いつやるの優先順位をどう判断するか

f:id:tune:20210330210904p:plain

[1例目] 要望は社員がGoogleフォームで気軽に投稿できるようにしている。Zapier経由でGitHub Issue化している。 エンジニアが週次リファインメントで工数感を相談している。その後「小案件リスト」化して着手しやすい状態にしている。 「小案件リスト」から汎用的な課題、かつ1〜2スプリントで完了するものを優先してスプリントに割り込ませている。 全体ロードマップは別途あるので、それを邪魔しないように一石三鳥が狙えるものを優先している。

[2例目] 組織規模が小さい時は毎週集まって顧客の声を議論していたが、現在は月一で報告会を開いている。 問い合わせのサマリ・推移などの定量情報や、顧客の生の声のような定性情報も共有している。 「解決したい課題」「発生原因」「解決案」まで整理した状態で共有している。

[3例目] Googleフォーム→slack投稿でカジュアルに要望を集める仕組みを設けている。 週次定例でCS Manager/PdM/EM/Designerが集まってロードマップに組み込むか検討する。 ロードマップは「将来あるべき姿」で作る。登り方は後から考える。

Q: ロードマップとユーザー要望との優先度ってどう決めているか

  • ロードマップは最優先
  • イテレーションの進捗がいいときにユーザー要望を進めている
  • ユーザー要望(温度感と対応工数)を普段から会話やディスカッションをしておき、できるときに進めている

技術的負債とどう向き合うか

影響度・返済コストがある。 エンジニアから見てまずいものはエスカレーション・提言して、PdMから信じてもらい、エンジニア主導でやらせてもらうことがある。

ロードマップ作成。中長期のやることと短期のやることの紐付け

f:id:tune:20210330210733p:plain

長い文章を書く文化があり、ドキュメントを活用して「まきこみ・議論・共有」を重要視している。 「決めたことを伝達して終わり」ではなく「理解して腹落ち」してもらうことを気をつけている。

感想

メンバー間のゆるい会話をたくさん聞くことができ、「良い会社なんだろうな」ということが終始感じられました。 思いを文章化する文化、職種間で互いの立場を理解してもらおうと努力する姿勢が根底にあることで、うまく優先順位づけが議論できる文化につながっているのだろうと感心しました。見習えるところは自社でも取り入れていきます。

LeSS Study atama plus 事例講演 「5チームでLeSSをしたatama plusがLeSSから学んだこと」

f:id:tune:20210328144223p:plain

LeSS Study atama plus 事例講演

less-study.doorkeeper.jp

LeSS Studyが2021年にオンライン移行してからの第2回。atama plusさんの事例共有会がありました。

講演中に気になったこと、質問して回答をもらったことのメモ

LeSS導入前に社内で話し合いを結構した。

Q: どのくらい話し合った? → A: 3時間/日を5日ぐらい Q: どんなことを話し合ったのか? → A: 「LeSSを導入したらどう変わる?」「LeSS体制でのメンバーのスプリント内での振る舞い方とか」

LeSS移行時に開発を止めてみんなでLeSSを勉強した。

Q: どのくらい勉強したのか → A: 2週間

LeSS移行後の変化 - 移行前はPO3人体制→移行後は1名 - チームに求められるレベルが上がった。

問題点 - LeSS導入でPOが忙しくなった結果、Discoveryフェーズに関われなくなってしまった。 - → BX(Business Experience)という職種を導入 - POの代わりにDiscoveryに協力 - 複数チームでのバックログリファインメントに時間がかかり不評に - 得られるアウトカムが少ないものはチームを決めて1チームリファインメント & 開発に倒した

感想

  • 議論を重視する文化があったからか、議論時間が無駄に増えてしまったのかも。

    • Rettyではリファインメントの人数を減らし、信頼してもらう方向に倒している
    • atama plusのリファインメントは10〜20名で、そのうち8人ぐらいが議論する感じらしい
  • LeSSを導入する問題背景が全社で揃ってなさそう


BacklogWorld 2021でGo To Eatキャンペーンでのプロジェクトマネジメントを話してきました #BacklogWorld #JBUG

はじめに

f:id:tune:20210320182358p:plain

jbug.info

2021年3月13日に行われたBacklogWorld 2021で、RettyでのGo To Eatキャンペーンのプロジェクトマネジメントについて話してきました。公募セッションとして応募し採択されたものです。

YouTubeで配信アーカイブを見ることもできます。

youtu.be

反応など

ブログ

Twitter

基調講演直後の登壇だったのに、まとめツイートの始まりが16ページ目からというのはびっくりです。いかにたくさんの反応がツイートされていたのかがわかります。

感想

YUMEMI.pm #1でも同じテーマの話をしてきましたが、きちんと整理した内容をお伝えできる機会が作れたことがよかったです。登壇後の懇談会で「公募セッションが来るか不安だったのですが、何がモチベーションだったのですか?」と質問をいただいたのですが、会社としても多くを学んだプロジェクトだったので、工夫した点が他者に伝わるよう整理し、広く記録に残しておきたいと思っていました。実際にこの後のプロジェクトでも似たような推進形態をとっており、成功に一定の貢献をしている手応えを感じています。今回の登壇でこのやり方・エッセンスを取り入れた事例が増え、さらなる改善のきっかけが見つかると良いなと思っています。

BacklogWorld自体の感想ですが、オンラインカンファレンスでありながら、熱量を逃がさない工夫が各所でされており、よく考えられたカンファレンスだなという印象を持ちました。Discord運営のカンファレンスだと外に盛り上がりが伝わりづらい課題がありますが、Twitterならその問題はありません。一番ツイートしていた人・いいねが多かったツイート・運営で選んだツイートを表彰する仕組み、ブログレポート枠の充実など、参加者の感想を吐き出させる仕組みがきちんと機能していることに感心しました。過去の開催経験や、地域ごとにあるコミュニティの下支えがあってこそのものだと思います。運営の皆様、聴講してくださった方々、ありがとうございました。