RSGT2019に行ってないけどレポートをする
久津（@Nunerm）です。
1/9から3日間Regional Scrum Gathering Tokyo 2019が行われました。
参加してません(｀・ω・´)
けどTwitterの"#RSGT2019"タグで流れてくるツイートが面白そうだったので、スライドやツイートを勝手に見てレポートします。もちろん全部は無理なので一部だけ。
Regional Scrum Gathering Tokyo 2019 - 運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた | ConfEngine - Conference Platform
EMFMファンにはおなじみのゆのんさん。
チーム人数が増えてきた時に「人数の割にはパフォーマンスが出ていない」という悩みはあるあるですね。"１＋１＜２"になりがちなのがチームというもの。そこで並行バージョン開発を導入してパフォーマンスを向上させたお話です。
うちの組織でも一回これと似たようなことを試してみたんですが、マネジメントが下手くそだったのでv.1.0.0チームとv.1.1.0チームのコミュニケーション量が減ってしまいました。例えばv.1.0.0が盛り上がってマネージャーがそっちにかかりっきりになってしまうと、v.1.0.0チームが放ったらかしにされてモチベーションが下がってしまったことがありました。
ゆのんさんのスライドのこのスプリントの組み立て方（つまりはLeSSっぽいスタイル）が有効なのかな。ここは詳しく聞いてみたい。
Regional Scrum Gathering Tokyo 2019 - ちゃんとやってるのになんかうまくいかないスクラムからの脱出 | ConfEngine - Conference Platform
とにかく絵が可愛い…
まだまだ自分はスクラム初心者で自分のチームも「なんちゃってスクラム」ですが、確実に最初はうまくいかないと思っています。うまくいくイメージが湧かないので。そんな時にこのスライドを参考にしたい。
この「コードレビューにかかる時間が読めない」のは自分のところも同じ。レビューイ・レビュアの組み合わせ、レビュー対象のコードの種類などでいつも時間がバラバラになるんですよね。そこへの打ち手として、全員の知識交換をして「チームとして納得するコードにする」というアプローチ。既にメンバー数人から「書き方がイケてないところがあるから書き直したい」と言われている現状では、この打ち手は有効かもしれない。
「スクラムを現実の上で回す」という表現は好きだな。決してチームのパフォーマンスを過大評価しているわけではないけど、スクラムに限らず開発のプロセスでは「想定」が入り込んでしまいがちです。現実を１つずつ可視化していって想定を排除していくことで、無駄やリスクの少ない開発ができますね。これは肝に命じておこう。ホワイトボードに貼っておこうかな。
Regional Scrum Gathering Tokyo 2019 - 行動分析学に基づくScrumの導入 | ConfEngine - Conference Platform
これは面白い！けどスライドだけでは十分に理解できない…！
スクラムがうまく機能しないので何かの「行動」を改善したい時に、その行動が引き起こす後続事象に着目するというアプローチということですかね。
後続事象がその行動に対して「好子」なのか「嫌子」なのか、つまりその行動を繰り返したくなるのかやめたくなるのかを把握し、そこをデザインし直すことで行動自体を改善するということ。
これは現場で聞きたかったなあ…
Regional Scrum Gathering Tokyo 2019 - プロダクトの「負債」を「機能」と呼び直すために ーA/Bテストを用いた"価値"の定量化ー / Fact based decision making | ConfEngine - Conference Platform
これは刺さる内容だ…！
表面上の数字だけで機能を「負債」と定義してしまって、特に深掘りもせずに切り捨ててしまい、気づいたら売上やユーザー数などの指標が悪化しているパターン。ありがちですね。
このスライドの例で言えば、キャリア決済の存在と売上・CVとの間の因果関係がテーマになってますが、この因果関係をアクションログなどから求めることは、相当データ分析に秀でた人材がいない限り難しいと思います。
では因果関係を明らかにできない時にどうするか？ありがちなのは「思考停止」すること、つまり表面上の数字だけで「たぶんこういう結果になるだろう」という思い込んで意思決定してしまうことでしょう。そっちの方が圧倒的に楽なので。
それをこの発表の例ではしっかり労力をかけてA/Bテストで因果関係を明らかにしました。いやー素晴らしい。この姿勢は見習います！
Regional Scrum Gathering Tokyo 2019 - そのときサーバントリーダーはどう振る舞うか | ConfEngine - Conference Platform
「サーバントリーダー」って何と無くイメージは湧くものの、具体的に何をクリアできればサーバントリーダーなのかモヤモヤしてたので、このスライドはいいヒントになりそう。
特にこのページが刺さりました。
メンバーが楽しく仕事をしてパフォーマンスが上がっていれば「ああ、俺良いサーバントリーダーだな」とか勘違いしてしまいがちなところで、改めてこの４つの観点で自問自答すると穴が見つかるはずです。特に「立場を超えた本音を聞けている気がしない」と「信頼されるだけのOutputを見せられているか不安」はまさに自分もそう思いました。
「傾聴」「共感」「癒し」「納得」の観点で本当に自分がサーバーントリーダーに慣れているのかは常々自分を客観視します。
以上、「RSGT2019に行ってないけどレポート」でした。
もちろん実際に参加する方が学びは多いはずだけど、こうやってスライドだけで学ぼうとする作業も大変だけどその分頭をフル回転させる必要があるので、色々気づきがありました。
とは言え来年のRSGT2020は絶対参加します！
PMは技術力やドメイン知識をどこまで持つべきなのか 〜NewsPicksアカデミア 及川ゼミより〜
久津（@Nunerm）です。
「日本のPMといえば？」という問いに高確率で名前が出てくるであろう人といえば。
及川卓也さんですね。
この度その及川さんから「プロダクトマネジメントの極意」を伝授いただける機会に恵まれました。NewsPickアカデミアのゼミです。
決して安くない受講料のゼミの30人の枠に対して60人の応募があったそうで、日本でもプロダクトマネジメントを学ぶ必要性に迫られている人が増えてきているんですね。
というわけで、この記事では初日の講義での学びである
「PMは技術力やドメイン知識をどこまで持つべきなのか」
の考察を書きます。
PMは技術力やドメインに詳しくあるべき？
PMの役割には色々な定義がありますが、メルペイの丹野さんの言葉を借りると以下のようになります。
このうち①を実現するためには、PMがその事業が属するドメイン（領域）を理解する必要があります。事業目標は通常そのドメインに存在するカスタマー、クライアントなどの全てのステークホルダーの課題や心理を理解し、かつ外部環境（景気、競合、規制など）をしっかり把握した上で立てられます。
事業目標自体はPMではなくCEOや別の人が決めることが多いと思いますが、その背景や狙い、本質をしっかりPMが理解しないと「事業目標を達成する打ち手」を導くことはできません。よってPMがドメイン知識を持つことが求められるのです。これがPMが"miniCEO"と呼ばれる所以でもあります。
pixivの清水さんのpmconf2018 の発表でも、特定ドメインのプロフェッショナルになることによるメリットが語られています。
続きを読む
プロダクトマネージャーは「組織の視力」を把握しよう
久津（@Nunerm）です。リクルートでPM/EMをやってます。
この記事は、Product Manager Advent Calendar 2018の23日目のエントリーです。
今回は「プロダクトマネージャーは『組織の視力』を把握するべきだ」という考えを書きます。
今いる環境でPMに何が求められるのか？
「プロダクトマネージャーの役割とは何か？」
これはPM界隈では常に問われる疑問です。
PMに求められるスキルや考え方は多岐に渡っていて、実際に活躍されているPMの方々が持っている武器も様々です。（エンジニア出身の人、マーケター出身の人、デザイナー出身の人…）
また組織やマーケットによっても求められる動きや成果は変わります。
プロダクトマネージャーカンファレンス2018で登壇されたのBaiduのPMのChenさんという方のプレゼンでも「アメリカと中国で求められるPMのスキルが違う」というお話がありました。アメリカはニーズがある程度一様化しているため、そのニーズを技術力で解決できるPMが求められる。中国ではニーズが極端に多様化しているため、解決されていない新たなニーズを探すことができるPMが求められるとのことでした。
つまり。
「プロダクトマネージャーの役割とは何か？」
に対する答えは、いくらでもあると思うのです。
大事なのは、自分の武器を認識し、かつ今いる組織でPMに何が求められるのかを理解した上で、目指すべきPMの姿をしっかり定義することです。
では「今いる組織でPMに何が求められるのか？」はどうやって知ることができるのでしょうか？
私は「組織の視力」を把握することでヒントを得られると思っています。
続きを読む
ボロボロのチームを立て直したエンジニアリングマネージャーのお話
久津（@Nunerm）です。リクルートでPM/EMをやってます。
この記事はEngineering Manager vol.2 Advent Calendar 2018の15日目の記事です。
普段このブログではプロダクトマネージャーに関する記事を書いていますが、エンジニアリングマネージャーも担っているので、この記事ではEM人格で語ります。
さて、エンジニアリングマネジメントにまつわるエピソードには様々なものがあります。ゼロからチームを作り上げた話、初めてEMになって試行錯誤した話、新しいやり方を装着しようとして失敗した話などなど…
今回は私は「ボロボロのチームを立て直した話」を書きます。このシチュエーションと似た経験をされた方がどれくらいいるのかわからないですが、何かしらヒントを得ていただけたら幸いです。
※なおこの話はリクルートの話ではありません。とある別の企業での話ですのあしからず。
- 序章：ボロボロのチームにジョイン
- 第一章：外部環境を整える
- 1-1.改革の宣言・ブランディング
- 1-2.意思決定プロセスの整備
- 1-3.技術的負債の可視化と解消によるメリットの説明
- 第二章：内部環境を整える
- 2-1.メンバーへの信頼を示す
- 2-2.チームビジョンの再定義
- 2-3.多様な内発的動機と向き合ってくすぐる
- 2-4.心理的安全性の担保
- 第三章：自ら成長できるチームへの変貌
- 3-1.チームのカオスエンジニアリング
- 3-2.階段を刻み、踊り場で遊ばせる
- 終章：１年後…
続きを読む
CSPO研修（認定スクラムプロダクトオーナー研修）で学んだ「ROIを考え抜く姿勢」
今回はCSPO研修での学びをまとめます。
CSPO研修とは？
CSPOとは"Certified Scrum Product Owner"の略で認定スクラムプロダクトオーナーという意味です。認定スクラムトレーナー（CST）によって開催される Scrum Alliance 認定のCSPO研修を受けることで認定されます。
つまりこの研修を受けて認定されたら「あなたをスクラム開発のプロダクトオーナーとして認めます」となるわけです。
プロダクトオーナーとプロダクトマネージャーの違いは？
このブログは「プロダクトマネージャー」について書いていますが、プロダクトマネージャとプロダクトオーナーは違います。
まずプロダクトオーナーはスクラム開発の役割の一つです。よってスクラム開発をしていない組織ではプロダクトオーナーは存在しません。
続きを読む
プロダクトマネージャー・カンファレンス（pmconf）2018 2日目まとめ
前日に引き続きもちろん参加！
今回も全網羅的ではなく、個人的に刺さった言葉をピックアップして解説します。
1.愛をお金に変えよう
マネーフォーワード今井さん。
所用で席を外してたので全部聞けてはいないんですが、最後のまとめて「愛をお金に変えよう」と仰っていたところが「確かに大事なことだ」と思いました。
今回のカンファレンスのテーマは「愛されるプロダクトを創ろう」。
ただいわゆる「無償の愛」ではダメで、企業はそのプロダクトを継続的に成長させる責任がある。そのためにはやはりお金を稼ぐこと、カスタマーやクライアントからお金を頂くことは必要なのです。
よって重要な観点は「プロダクトで得た愛をいかに効率よくお金に変えるか」で、マネーフォーワードで言えばより上位のプランにシフトしてもらうためにどのような価値を提供するか。
Appleはいい例で、ユーザーからの猛烈な愛をうまくお金に変えられる仕組み（例：高単価なiPhoneやその付属品、値引きしないスタンス）を作っている。要はユーザーがお金を出すことに対する納得感を醸成できるかが鍵。
これは完全にPMの腕の見せ所で、ブランディングやPR、CSなども合わせて戦略を立てないといけない。
愛とお金を稼ごう。
続きを読む
プロダクトマネージャー・カンファレンス（pmconf）2018 1日目まとめ
今年もプロダクトマネージャー・カンファレンスに行ってまいりました！
昨年に続き多くの学びと刺激をもらいに来ました。
１日目のまとめを書きます。
全網羅的ではなく、個人的に刺さった言葉をピックアップして解説します。
1.Cut featureとWon't fixはPMだけが言えること
楽天トラベルの熊谷さん。
楽天トラベルは国内でのシェアは強いものの、旅行市場においては国内旅行者の減少と海外サイト（Booking.comなど）の参入もあって、世界に出て行く決断をしたそうです。
世界で愛されるプロダクトになるために３つのポイントを挙げていただきました。
- Generalize
- Communication
- Decision Making
※ちなみにこの３つの定義はpmconf2017でも楽天トラベルの齊藤さんが提言されていました。楽天に根付く考え方なんですね。
Generalizeは最初に機能のRequirementを定義するときにGeneralize、つまり何か特定のセグメントやドメインに特化せずに一般化することが大事ということ。
海外進出する際のハードルとなるのが、タイムゾーンや法律、個人情報の扱い（最近GDPRが話題です）など。これを考慮して一般化して設計することで、スピーディーに海外展開できる。
次の２つは海外に限った話ではなく、PMとして持っておくべき考え方です。
Communicationは"Positive"（問題は必ず解けるというスタンス）と"Open Communication"（しっかり議論して問題の本質を紐解く）という姿勢を持つべきとのこと。
そして最後のDecision Making。
バグトリアージのルールはこんな感じらしい。
ただ実際このHighとLowって定量的に仕分けるのってすごく難しく、各ステークホルダーの視点によっても変わってくる。例えばCSにとってはユーザーが最優先だけど、営業にとってはクライアントが最優先。
ここで重要な考え方がこちら。
Cut feature & Won't fix はPMだけが決められること
これはPMにとって本当に重要な役割。
「何がプロダクトの成長に繋がるのか」を一番知っているPMが「削る」と「やらない」をDecision Makingしないといけない。そしてその決定がプロダクトにとって最適でないといけない。
さらにはその決定をステークホルダに納得してもらうためには、普段からしっかりとCommunicationをして信頼を勝ち得ないといけない。
これ簡単に言うけどめちゃくちゃ難しいことです。個人的にはPMとして１人前かどうかはこれができているかどうかで評価できると思ってます。
PMとしての「あるべき姿」を再認識することができました。
唯一「やらないことを決められる」という責任感を持って生きていきます。
続きを読む
