tuneの日記

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

"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ならその問題はありません。一番ツイートしていた人・いいねが多かったツイート・運営で選んだツイートを表彰する仕組み、ブログレポート枠の充実など、参加者の感想を吐き出させる仕組みがきちんと機能していることに感心しました。過去の開催経験や、地域ごとにあるコミュニティの下支えがあってこそのものだと思います。運営の皆様、聴講してくださった方々、ありがとうございました。

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

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事をよく放流しているのですが、社外向けでも需要があるかもなと思い試しに公開してみます。この記事は第3弾です。

ノウハウ・知見

具体的な事例質問(実例)を通して仕様を明確化する実例マッピングの紹介

speakerdeck.com

バーンアップチャートを使った可視化

quipper.hatenablog.com

他社事例

SmartHR プロダクトデザイングループの活動

社内横断でUI/UXを改善するコミュニティができるとこんな感じなのかなと思いました。

note.com

atama plusのLeanUX取り組み

note.com

Hunter Industriesでのモブプログラミング

kawaguti.hateblo.jp

github.com

delyとメルカリの開発体制

Spotifyモデル2013とは違うように話されているんだけど何が違うのかがよくわからず。中の人にぜひ聞いてみたい。

mercan.mercari.com

勉強会・カンファレンス

Regional Scrum Gathering Tokyo 2021

スクラムマスダーさんの恒例スライドまとめ

ハイブリッドカンファレンスだったので録画も順次公開されています。

ふりかえりカタログ speakerdeck.com

アジャイルコーチとVPoE/EMの違いについて。 speakerdeck.com

カネとAgile

www.slideshare.net

ヒット商品を生み出すプロダクトマネジメントブースター

Developers Summit 2021

リモートワークで取り組むべき事。

speakerdeck.com

EnPitでの学び

docs.google.com

その他

スクラムチームの成熟度モデル日本語訳

字が小さいのでもう少し大きい画像が欲しかったり → 公開していただけました! 【翻訳】あなたのスクラムチームの成熟度は? | Ryuzee.com

認定LeSS実践者研修

2021/6/2から3日間。

Certified LeSS Practitioner - June 2, 2021 @ Tokyo - Large Scale Scrum (LeSS)

スクラム実践者が知るべき97のこと が近日発売

miholovesq.hatenablog.com

目標・評価で使ってはダメなキーワード

Regional Scrum Gathering Tokyo 2021に参加しました #RSGT2021

f:id:tune:20210109174017p:plain

はじめに

2021.scrumgatheringtokyo.org

去年に引き続いて3回目の参加です。去年はスポンサーとして参加しましたが、今年は個人参加です。 Rettyから登壇者が出たので現地で参加する予定でしたが、結果的に3日間オンライン参加としました。 Discordの議論を横目に発表を聞いたり、早朝・深夜に他の参加者と無理なく交流が図れたりしてこれはこれで良かったかなと思っています。

聞いてきた話など

「全社で大規模スクラム(LeSS)移行して1年間」Retty執行役員が全て答えます

結果的に3件プロポーザルを出したのですが、これが一番採択されて欲しかったので決まったときはとても嬉しかったです。 自分も含めたパネルディスカッションにすることも考えましたが、「アジャイルのコミュニティにあまり出入りしていない」「導入推進者(自分)よりも上位の職位の人が語る」方がインパクトも大きく、より本質が伝わるかと思いこのような形にしました。

45分のセッションで40の質問が集まり、多くの人の興味を集められたのではないかと思います。

confengine.com

Rethink Scrum from a Japanese cultural perspective

23枚目のスライドが好き、「場の文化として生まれ、個の文化のために標準化」この後に続く「空気が場を支配する」の見解も面白かったです。 参考にされた日本と、体系化したアメリカと、そもそもベースが違うし、見つめる人も違うんだから、違った見解を持つことがあるというのはこの先気をつけておきたい。

終盤に出てくる「トヨタのチーフエンジニア(主査)に習いたい」のは自分も考えたことがあるけどまた答えは出ていません。 「大変だから分担して責務持とうぜ」って言うのは楽だけど、主査の凄さって分担しても出せるんだろうか・・・うーん。

confengine.com

アジャイルを忘れるチーム Unlearn Agile

わかるような・わからないようなスライド37枚目。 チーム・メンバーの直感を信じてそれを大事にすると言うのはわかる。直感はいつもだいたい正しい。 でも「ある程度型やルールに従って直感を養う期間が必要ではないか」とも思う。

LeSSのマップは原理・原則が中心にきて、最低限のフレームワーク、条件によって有効なガイド、導入する現場ごとに試行錯誤してもらいたい実験が囲む形をとっている。LeSS実践者研修受けた時はこれはこれでしっくりこなかったけど、決まりや試行錯誤の数で一番多いものが外側にきて土台になるという3角錐のような立体を思い浮かべるとそういう絵なのかなーと今は思える。

f:id:tune:20210109181651p:plain

キョンさんのマップも視点を変えるともっと自分にしっくりくるかもしれない。

confengine.com

患者さんや顧客に最大の価値を提供するために ~外資系製薬企業が組織全体の変革を目指しアジャイル導入~~

グローバルな製薬会社が、トライアルとして日本から組織・文化変革に挑み、成果が出てきましたと言う事例紹介、今回のRSGT2021講演で一番のお気に入りです。 小さく始める、社内からメンバー(スクラムマスターとか)を募る、広げるときに研修・周知など丁寧に行う、会社の協力を取り付けるなど、これまで多くの書籍・事例紹介・文献で示されている良いやり方が実例を伴って「ここまでやるんだぞ! お前らはやったのか!?」という迫力となって襲いかかってきます。

「弊社もDXを実現し・・・」とか言っている会社は見習うことがたくさんあると思います。資料公開して欲しいなー。

confengine.com

アジャイルコーチとVPoE、あるいはEMの間にあるもの

RSGTの参加者で「アジャイルコーチ」が増えてきているように感じるのですが、自分は「自社事業」で「当事者として」携わることが楽しいと思って過ごしています。それだけに発表者の悩みがすごくよくわかり、アジャイルコーチとEM/マネージャー/VPoEの違いがよく整理された資料がとても勉強になりました。

期せずしてゆのんさん小田中さんとシンクロ頷き。

f:id:tune:20210109183056p:plain

アジャイルコーチの価値に「客観性」があって、これはEM/マネージャー/VPoEと兼務してやることは難しいというのは納得。 社内ではアジャイルに詳しい人としてコーチのように思っているかもしれないけど、自分は主観で動いている「アジャイル助言者」ぐらいなんだと思う。 なので「おかしなことをやっていないか」事例発表を行うことで定期的に外部の目が入るようにしているところがある。

confengine.com

野中郁次郎スクラム再訪問(Nonaka's Scrum Revisited)

普段使っているスクラムがどういう理論に根差し、効果を発揮しているのかを歴史を追って解説していただき、3日目の基調講演の入りとして最高でした。 SECIモデルとか過去に目にしたことがあった気もするんですが、今回初めてつながりが理解できました。 社内でもスクラムをもっと深く理解できるよう上映会の予定を入れています。

confengine.com

Discordでの交流・情報交換

3回目の参加ともなると旧知の知り合いも随分増えましたが、今回初めましての方とも繋がることができました。 昨年、何度か登壇していたことで自社の事例を聞かれることもあり、今後も継続して事例紹介を続けていければと気持ちを新たにしました。

今年の感想

「泥臭く、全力で殴り合いながら、より良い何かを追求していく」しかないんだよねという再確認が最後の基調講演でもらったメッセージです。

今年も一層の精進を目指し、日々の実践・コミュニティへの貢献をやっていきます。

2020年11〜12月に社内で共有したアジャイル開発関連の記事

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事をよく放流しているのですが、社外向けでも需要があるかもなと思い試しに公開してみます。この記事は第2弾です。

ノウハウ・知見

スプリントレビューで共通認識を作る

ヤフーのスクラム開発実践者の経験年数ごとの学習方法の紹介

techblog.yahoo.co.jp

Miroを使ったふりかえりのテンプレート

daipresents.com

A-CSM研修の概要とふりかえり

qiita.com

他社事例

ビズリーチのとあるスクラムチームで心掛けていたこと

note.com

大規模組織でのLeSS再導入

nekonohitai.hateblo.jp

Uberアプリでのリアーキテクチャ失敗事例

gigazine.net

Classiのアジャイル開発シフト

たくぼんさん(木村卓央さん)にアジャイルコーチをお願いしているとのこと。

note.com

勉強会・カンファレンス

スクラムフェス札幌 江端さん基調講演書き下ろし

qiita.com

AgileJapan2020で気になったもの

東京海上日動でのLeSS開発の取り組み。カンバン(Miro)の写真が所々入っていますが、使い方がとても上手。

星のリゾートの事例

アジャイル開発ってなんだったんだっけという話、川口さん

その他

スクラムガイド 2020

平鍋さんにRettyが好きなサービスと言っていただけて嬉しかった

プロダクトの「骨」「肉」「皮」のどれになるかで重要度を表現する

SHIFT アジャイル白書2020年版レポート

topics.shiftinc.jp

Spotifyモデルに取り組んでいる国内事例一覧

f:id:tune:20210109084800j:plain
Photo by sgcdesignco on Unsplash

Spotifyが2013年に発表した組織形態 "Spotifyモデル"を採用している公言する事例が増えてきたなと感じているのでまとめました。公開されている資料をベースにまとめていますが、「うちもやってるよ!」というところがあればぜひお知らせください。

まとめてみるとTribeが必要な開発規模までには至らず、Squadが自律して動くことを指して「Spotifyモデルを採用」と言っているところが多い気がします。

アクサ生命

f:id:tune:20201230143633p:plain

dely

クラシルの開発

f:id:tune:20201230141835p:plain

for Startups,Inc

スタートアップ情報を発信するSTARTUP DBとタレントエージェンシー支援システム(SFA/CRM)の開発。

f:id:tune:20201230142517p:plain

READYFOR

クラウドファンディングサービス READYFORの開発

f:id:tune:20201230144936p:plain

SmartNews

スマートニュースの開発

f:id:tune:20201230142312p:plain

Wantedly

求人情報ウェブサイトWantedlyの開発

f:id:tune:20201230144125p:plain

GMOペパボ (2020/1/4)

f:id:tune:20210104151753p:plain

MSD製薬 (2020/1/6)

RSGT2021の講演資料でTribe / Chapter / Squad といった組織形態を紹介していました。

WealthPark (2021/3/13)

f:id:tune:20210313110014p:plain


lean-trenches.com

www.atlassian.com