nDiki : スクラム

プロダクトマネージャー・カンファレンス 2018 2日目 #pmconfjp

プロダクトマネージャー・カンファレンス 2018 2日目。

• プロダクトマネージャー・カンファレンス 2018 1日目のメモ

以下メモ。

10:00 - 10:15 [07-01] Welcome Talk

プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏

今日もタイムテーブルから遅れて 10:10 スタート。

10:15 - 10:45 [07-02] 巨大なFinTech事業開発におけるプロダクトマネジメント

▲株式会社FOLIO 代表取締役 CEO 甲斐真一郎(@folio_kai)氏

経営者という立場でのセッション。金融サービスは一般のネットサービスとは異なる要求がある。また今まで枯れた業界であった。3カ月でできると思ったが2年かかったとのこと。 リリース後に単一プロダクトから異なるビジネス/KPIの複数のプロダクトに事業展開していく中で、個別のアプリケーション部分と共用されるバックエンドという構成になっていきマネジメントが複雑化し始めたとのことだった。

今は全プロダクトを単一の巨大なプロダクトバックログで管理しているのだそうで、今後どうしていくのかぜひ知りたいところ。単一の方が事業全体での優先度が明確になるもののリファインメント含めバックログの管理コストが大きいという問題があり、これはいつも悩ましい判断である。

その他の紹介されていた課題ははエッセンシャル スクラムでも取り上げられているテーマのものが多く、あるあるだなーと。

「愛されるプロダクト」

(まだ FOLIO 社にはいないが)プロダクトマネージャーには「プロダクトへの尊敬」を求めたいとのこと。プロダクトへの尊敬とは何だろう。愛じゃ駄目なのかな。

11:00 - 11:30 [07-03] C向けアプリのPM経験者から見た、B2B SaaSのプロダクトマネジメント

▲株式会社マネーフォワード MFクラウド経費本部 本部長 プロダクトオーナー 今井義人

短期的にはプロダクト改善が最適な改善ではない。人力で頑張るという局面も確かにあるよね。

B2C と B2B の違いはそうだよねで終わりがち。これから B2C から B2B に移ろうとしている人には参考になるかもという感じ。

「愛されるプロダクト」

「愛をお金に変えよう」で築いたエンゲージメントをベースに、より高いプランを作って移ってもらう施策などを紹介。

11:45 - 12:15 [07-04] 気がついたらプロダクトマネージャーになっていた

Nature株式会社 代表取締役 CEO 塩出晴海氏 新規事業での製造まわりのトラブルあるある談を含めた、プロダクトリリースまでのストーリー。プロダクトマネージャーというよりは起業家としての話。あきらめずにやり切る態度は凄いな。

「愛されるプロダクト」

特に話題なし。

12:25 - 12:40 [07-05] リクルートの横断組織で考えるプロダクトマネジメント

▲株式会社リクルートコミュニケーションズ ICTソリューション局 アドバンスドプロダクト開発部 部長 宮里裕樹氏、▲株式会社リクルートコミュニケーションズ ICTソリューション局 戦略企画グループ マネジャー／シニアプロデューサー／シニアプロダクトオーナー 金田將吾氏

細かいところはエンジニアがどんどん進められる組織なので、プロダクトマネージャーは HOW ではなく WHAT に注力しているとのことだった。開発チームのスキルや成熟度によって千差万別なところだ。

プランナーと呼ばれていた人がやっていた役割を

• ビジネスプロデュース
• プロダクトマネジメント
• ITディレクション
• プロダクトリード

に分けて定義しチーム体制を構築、得意な役割を任せたり不得意な役割を成長させたりしているらしい。しっかりピープルマネジメントに取り組んでいるなあと感じた。

「愛されるプロダクト」

特に話題なし。

12:40 - 12:55 [07-06] 顧客、会社、チームをHappyにするプロダクトマネジメント ～観点・プロセス・レバレッジ～

▲楽天株式会社 顧客戦略統括部 Vice Senior Manager 山下徹朗氏

「顧客・会社・チームを Happy にする」ことをプロダクトを作る目的として事業を進めている。全能なプロダクトマネージャーは(ほとんど)いないので、ビジネス・UX・マーケティングについてそれぞれ担当を割り当てそれぞれ問いを立て答え続けていくことで結果を出すプロダクトを生み出すという体制を全てのプロジェクトで採用しているとのことだ。

「愛されるプロダクト」

冒頭で「高すぎる目標の」「自己満足な」「誰のためのかわからない」プロダクトという偏った愛あるあるという話を取り上げていた。

12:55 - 13:10 [07-07] Build Narrative in Product

▲株式会社ドワンゴ サービス開発本部　副本部長 池田明啓氏、株式会社ドワンゴ セクションマネージャー 宮城良征氏

前半は、様々な手法を利用・開発してプロダクトマネジメントに取り組んでいるという紹介でとても研究されているなと感じた。知らない手法が紹介されていたので、それぞれちょっと調べてみたいな。

後半は実際のプロダクト開発事例の紹介。

「愛されるプロダクト」

特に話題なし。

13:40 - 14:10 [07-09] The mindset of building the product that user will love

▲株式会社メルカリ UX consultant Jasper WU 氏

Design Thinking についての非常に洗練された圧倒的なプレゼンテーションだった。ベストスピーカー賞があれば絶対 Jasper WU 氏だったと思う。

自己紹介や会社紹介などに時間は割かずセッションのメインテーマに絞ってきちんと語られた。直メルカリのプロダクトについて直接アピールしていないのだが Design Thinking についての取り組みのみの中で出てくる感じなのだが、結果的に組織・プロダクトについて好印象を受けてしまうというマジック。

デザインスプリントで駄目な案だったということがわかったことは失敗ではなく学びだということがきちんと根付いているのが素晴らしいなあ。

デザイン思考についてもきちんと学びたくなった。

「愛されるプロダクト」

一過性のキャンペーンを繰り返すのではなく、継続的な取り組みをしていくことが愛されるプロダクトにつながると言っていた。

14:25 - 14:55 [07-10] 北米・アジア・欧州のプロダクトマネジメントとスマートニュースのプロダクトマネジメント

▲スマートニュース株式会社 プロダクトマネージャ 宮田善孝氏

海外のカンファレンス紹介は、カンファレンスセッションとして知見を広める良いコンテンツだった。

スマートニュースではファンクショナルな組織のもと、プロジェクト毎に人が集まりチームを作るという体制とのことだった。プロジェクト毎にチームビルディングが必要そうだなというのと、機能開発プロジェクト終了後のその保守についてどうなっていくのかが気になった点。ファンクショナルな組織の方で保守していけるのかな。

「愛されるプロダクト」

特に話題なし。

15:10 - 15:40 [07-11] 中国のプロダクトマネジメントのリアル

Baidu, Inc. Product Manager 陈兆伟 (Chen Zhaowei)氏

日本語入力アプリ Simeji のプロダクトマネージャーの方のセッション。

コンピュータサイエンスやビジネススキルの高いスキルが求められる米国とは違い、中国のプロダクトマネージャーはニーズを掴みイノベーションを生み出す能力の方が求められているという話だった。またプロダクトマネージメントが階層化されていて、プロダクトマネージャーの下にプロダクトマネージャーがいる体制らしい。Baidu ではプロダクトマネージャーの役割/スキルについてのテーブルがあり、育成にも力を入れているようだった。

「愛されるプロダクト」

特に話題なし。

15:55 - 16:25 [07-12] Anycaにおけるプロダクトマネジメント

▲株式会社ディー・エヌ・エー オートモーティブ事業本部 Anyca事業責任者 馬場光氏

DeNA もプロダクトマネジメントの定義をしっかりともたれていた。 DeNA でも「全部できる人はいない」という前提で体制化しているようだ。

やはりある程度の規模になるとプロダクトマネジメントの定義・体制化・育成の仕組みが必要だなあ。

「愛されるプロダクト」

特に話題なし。

16:40 - 17:40 [07-13] [ワークショップ] 日本のプロダクトマネージャーは今何をすべきか

東京大学 本郷テックガレージ ディレクター 馬田隆明(@tumada)氏、プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏、プロダクトマネージャー・カンファレンス 実行委員 坂本登史文氏、プロダクトマネージャー・カンファレンス 実行委員 横道稔氏

馬田氏は「逆説のスタートアップ思考の人」の方。

「なぜ愛されるプロダクトにしていく必要があるのか」また「そのために自分の Next Action は何か?」をカンファレンスの最後にワークショップ形式で考えましょうという枠。聞きっぱなしにさせず、きちんとリフレクションまでカンファレンス内で完結させるという仕組みを入れるところに運営のセンスを感じた。

まわりの人と自分の考えを披露しあってその言語化を相手にさせるというフォーマット、1つめのワークで sli.do というサービスで anonymous で入力させて気持ち的な投稿障壁を下げたあとに2つ目のワークで自社製品名まで書かせるテンプレートで Tweet させるというマーケティング戦術にも恐れ入った。

ちなみに1つ目のワークで自分が考えた愛されるプロダクトについては

わたしは愛されるプロダクトがだいじだとおもっている。なぜなら「チームメンバの士気とパフォーマンスが向上し、さらに良いプロダクトへと導ける」から。

で Next Action については

わたしは「製品名」をもっと愛されるプロダクトにしたい。そのためにわたしは「プロダクトマネージャーを組織化する」。

としてみた。

17:40 - 17:50 [07-14] クロージング

プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏

2日間合計の来場者数速報値は563名との発表。1ホールでのカンファレンスでは結構な人数だ。

複雑な領域に合わせたプロジェクトマネジメントをする

あるプロジェクトのプレイングマネージャーが抜けることになってから、プロジェクトがうまく進まなくなってきた。プレイングマネージャーがメインでやってしまっている間は良かったけれど、そうでなくなった今も週1回30分のミーティングのスタイルのままでスローダウンしてしまったように思える。

なので

クネビンフレームワークで言うところの「複雑な領域」のプロジェクトだから、もっと密接にチームメンバが連携して「検査と適応」をしていかないと、進まないし成果も出ないよね。

という話をした。

開発プロジェクトではないけれどスクラムがいいんじゃないかなと思っているので取り入れてみるつもり。

スクラムブートストラップ #nNote

1. [ ] スプリント期間・開始日を決める。
2. [ ] スクラムインベントをスケジュールする。
   • [ ] スプリントプランニング
   • [ ] デイリースクラム
   • [ ] スプリントレビュー
   • [ ] スプリントレトロスペクティブ
3. [ ] プロダクトバックログリファインメントをスケジュールする。
4. [ ] プロダクトバックログを作れるようにする。
   • [ ] ツールを決める(付箋・Google スプレッドシート・Trello など)。
   • [ ] 見積もり方法を決める。
5. [ ] スプリントバックログを作れるようにする。
   • [ ] ツールを決める(付箋・Trello など)。
   • [ ] ふりかえりで決めた改善案も書いておけるようにする。
6. [ ] デイリースクラムのフォーマットを決める。
7. [ ] ワーキングアグリーメントを書く場所を用意する。
8. [ ] スプリントレトロスペクティブのフォーマットを決める。
9. [ ] スプリントレトロスペクティブのツール(付箋紙・マジック)を用意する。
10. [ ] 最初のプロダクトバックログを用意する。
    • [ ] プロダクトバックログアイテムそれぞれ完成の定義を書く。
11. [ ] キックオフをする。
12. [ ] 初回プロダクトバックログリファインメント(内容の確認と見積もり)をする。
13. [ ] 初回スプリントプランニングをしてスプリントを開始する。
14. [ ] デイリースクラムを開始する。
15. [ ] 初回スプリントレビューをする。
16. [ ] ベロシティを記録する。

複雑な領域なのでスクラムがいいと思ったけれど自己組織化するほどメンバがコミットできなさそう

とある複雑な領域のプロジェクトについてスクラムがいいのではと思って準備したんだけれど、メンバがコミットできるエネルギーを考えると失敗する可能性が高いと思えてきた。

事業全体での WIP を下げた方がいいなと。

今日のさえずり: ポケベルといえばキャッツ♥アイのトシ

2018年12月03日

• 06:45 裏道のクリスマスツリー。 PowerShot G9 X Mark II https://t.co/N1NFDywBGP
• 07:00 比丘橋 PowerShot G9 X Mark II https://t.co/RZWRQMyq8s
• 09:20 ポケベルといえばキャッツ♥アイのトシ。
• 09:47 2018年12月3日 #朝の渋谷 見慣れてきた新しい渋谷。 DSC-RX0 #RX0 https://t.co/TV0x5IH6C6
• 12:30 良かったものをふりかえるのは至福のひととき。 / “買って良かったもの 2018” http://bit.ly/2SjzqBr
• 24:12 スクラムがいいんじゃないかなと思って準備したんだけれど、メンバがコミットできるエネルギーを考えるとイケてないと思えてきた。事業全体での WIP を下げた方がいい。

品質と時間のトレードオフを判断できたの自画自賛

ワークショップで「品質より時間を優先」の判断をとっさにしてゴール達成できたの、品質・時間・スコープ・予算のトレードオフを意識して意思決定するアジャイルソフトウェア開発経験の賜物だなーと思ったり。

(なお、スクラムだと期日固定で、品質可変よりもスコープ可変の方が多くの場合望ましい。今回はスコープ変更ができない課題だったので品質を下げるという選択をした。)

Developers Summit 2019 1日目 #devsumi

2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00～10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ

• スケール
  • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
• Scrum @ Scale フレームワーク
  • スクラムだけでもスケールする。
  • スクラムマスター(SM)
    • デイリースクラム階層。チームで解決できない課題を上位のデイリースクラムに伝えて解決していく(チームのデイリースクラムの方を1日の先にやる)。トップレベルは役員によるエグゼクティブアクションチーム(EAT)。 EAT もスクラムチームなのでスクラムの全てのアクティビティをやる。
    • SM で寄ってたかって協力。
    • マネージャーの仕事。
  • プロダクトオーナー (PO)
    • チームに1 PO。PO チーフ PO。チーフチーフ PO。
    • PO は上位のオーナーが絶対。
  • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
• PO
  • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

11:05～11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10～12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05～13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10～14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた ～spanner、GKE導入の実体験から得たこと～

株式会社コロプラ 廣本洋一氏

• コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
• コピーベースで新しいアプリケーションを作ることによる課題があった。
• ノーメンテナンス時間というポリシーを前提とした技術選択。
• オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15～16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末で退職済みということで、嗚呼となった。

16:20～17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25～18:45 【14-A-8】 「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。

個人 OKR をやってみる (4)

月曜日に立てた1週間 OKR 終了。

採点

KR のスコア(自己採点)

• A: 0.3
• B: 0.3
• C: 1.0

でトータルスコア(平均)は 0.5。でも最後の C: 1.0 のおかげで目標(O)は達成できている状態なので、KR の設定が何かイケてなかった気がする。

ふりかえり

• OKR 設定は適切だったか?
  • 目標(O) の野心度合いが低かった。
  • 主要な結果(KR) は C だけで十分だったかもしれない。(A・B はそのための行動)
• フォーカスできたか?
  • OKR を意識しなかったら、これだけ集中して取り組まなかったので良い効果だった。
  • 他の業務もあるため1週間だとサイクルが短く感じる。ただスクラムでは1週間スプリントが良いというケースが多いし、検査と適応的には1週間も悪くないか。
• トラッキングできていたか?
  • 途中、進捗を数値化できていなかった。

やること

• 次回2週間サイクルでやってみる。
• OKR スプレッドシートにデイリーの進捗度がわかるような列を追加する。

今日のさえずり: 『スクラムガイド 2020』を追従した『エッセンシャル スクラム』改訂版出ないかなー

• 19:31 『スクラムガイド 2020』を追従した『エッセンシャル スクラム』改訂版出ないかなー。
• 21:48 月見をしながら帰宅したら、リビングにススキが飾られていた。ご飯の後には月見だんご。パーフェクト。

第2回 『Hacking Growth グロースハック完全読本』を読む会 第1章 グロースチームを結成する

『Hacking Growth グロースハック完全読本』を読む会の第2回目。今日からいよいよ第1章に入る。第1章は「グロースチームを結成する」だ。

グロースチームに必要なメンバ構成、チームの規模と業務範囲

グロースチームに必要な役割として以下が挙げられている。スクラムチームと同様に機能横断型チームであることがグロースチームには求められる。

• グロースリード (マネージャー + プロダクトオーナー + データサイエンティストの役割)
• プロダクトマネージャー
• ソフトウェアエンジニア
• マーケティングスペシャリスト
• データアナリスト (常任で配属したほうがいい)
• プロダクトデザイナー

チームの規模によって1人が複数の役割を兼任したり、複数の人が1つの役割を担当したりする。

チームのマネジメントはグロースリードが行う。

グロースリードはマネジャー、プロダクトオーナー(プロダクトの最終決定権と責任を持つ役割)、データサイエンティストをあわせたような役割を担う。

本書ではプロダクトマネージャーを

一般的には、プロダクトマネジャーはプロダクトのさまざまな要素を形にする過程を監督する。

と説明している。グロースサイクルでプロダクトの新機能を実験として選定した場合に、グロースリードはメンバの中のプロダクトマネージャーを実験のオーナとして任命すると後の章である。

ここで言うプロダクトマネージャーはグロースチーム内での機能開発をマネジメントするのか、それとも別チームを率いているプロダクトマネージャーで、そちらで実験のための機能開発をマネジメントするのか。組織体系の節にあるチームだと前者なのかな。

このあたりは企業によって組織構造や役割名の定義が違うので、そういった典型的な型があるよねぐらいで読んだ方が良いだろう。

業務プロセス

詳しくは4章。

チーム内での役割分担

「専門分野に応じた業務を担う」とありメンバの専門性に頼っているイメージ。スクラムのように銃士の姿勢まではここでは求めていないようだ。銃士の姿勢であることに越したことはない。

まとめ

分析とプロダクト開発とマーケティングができる機能横断型のグロースチームを結成せよ。

• Hacking Growth グロースハック完全読本 (Kindle 版)
• Hacking Growth グロースハック完全読本 (単行本)

第6回 『Hacking Growth グロースハック完全読本』を読む会 第4章 高速で実験を繰り返す

『Hacking Growth グロースハック完全読本』を読む会の第6回目。今日は「第4章 高速で実験を繰り返す」。

いよいよ今回はグロースハックプロセスのまわし方の章である。

1〜2週間をタイムボックスとしてイテレーションするプロセスは、スクラムなどのアジャイルソフトウェア開発プロセスに通じるものがある。グロースハックでもタイムボックスは1週間が良いようである。

初期のスタートアップ企業では、週に1〜2の実験から始めて徐々に数を増やしていくのがよい。

とあり早い段階から高速な実験サイクルが期待されている。

多くの実験を行うためには多くのアイデアが必要だが、週1回のグロースミーティングはアイデア出しの場としては使ってはいけないそう。たしかに「創造的なアイデア出し」と「高速な実験サイクル」とは切り離した方がうまくいくのかもしれない。

チームメンバは「みずからの専門知識に基づいてアイデアを出すよう求められる」。ここでもメンバの専門性を重視しているように感じた。このあたりスクラムより分業感が漂っている。優先順位付けのためのアイデアのスコア付けも提案者自身だ。

実験の結果に迷った場合は従来のバージョンを維持するのが最善の道だという。時間と労力をかけた実験は、実験を続けることで良い結果が出てくるのではと思いたくなる。きちんと元に戻す判断ができるようにしておきたい。

• Hacking Growth グロースハック完全読本 (Kindle 版)
• Hacking Growth グロースハック完全読本 (単行本)