トラブルだらけの現場から仕事が「楽しい」現場に変わった、６か月間の話
•
3 likes•1,709 views
2019年4月19日のDevLove関西 「プロダクトオーナーの現場」で発表したプレゼンです。
Recommended
More Related Content
Similar to トラブルだらけの現場から仕事が「楽しい」現場に変わった、６か月間の話
Similar to トラブルだらけの現場から仕事が「楽しい」現場に変わった、６か月間の話 (20)
トラブルだらけの現場から仕事が「楽しい」現場に変わった、６か月間の話
- 1. トラブルだらけの現場から 仕事が「楽しい」現場に変わった、6か月間の話 April 19th, 2019 Kanako Muroyama EC Incubation Development. Dept. Rakuten, Inc.
- 3. 3 自己紹介 室山 加奈子 Kanako Muroyama 楽天株式会社 ECカンパニー ECインキュベーション開発部 ユーザーエンゲージメントプラットフォーム開発課 ランキングサービスグループ Certified Scrum Product Owner 販売やクリエイティブ、マーケティングなどの経験ののち、 2016年春に楽天へプロデューサーとして入社。 開発経験はありませんが、マーケティングの経験をベースに、 コンテンツ系サービスのプロダクトマネジャーをしています。 神戸大学大学院 経営学研究科MBA 在学中 趣味：ももいろクローバーZ プロダクトマネージャーやサービス運営する人にはおすすめ！
- 4. 4 どんなことをしてきた人か ＃ 仕事 何をしてたか 0 大学情報学部 自分で企画して人にプログラムを書かせていた。 1 地元の本屋でアルバイト 販売や流通について学ぶ。 ２ イベント会社でアルバイト Web・グラフィックデザイナー 同時に、派遣やフリーランスでも働く ３ 中小SIer（やっと就職） Webディレクター コーポレートサイトの仕事が多かった４ Web制作会社 ５ 食品製造の会社 マーケティング・広報 ６ CRM支援の会社 プロデューサー ７ 現職 ランキングサービスのプロデューサー
- 7. 7 組織のご紹介 ランキングサービス グループ エンジニアチームA エンジニアチームB エンジニアチームC プロダクトチーム PJM2人 PDM2人 エンジニアは合計18人くらい
- 8. 8 どんな状況だった？ トラブル連発動けないほど、重いプロジェクト 認識のギャップがでかい、多い さらに自信を失う プロデューサー vs エンジニア 見積もり vs 現実
- 9. 9 どんなんだった？ 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 2018年 2019年 リ リ ー ス が な か っ た 期 間 慢性的に トラブルは多め けっこうな事故を起こしている 確かに減っている 今日のトピック グラフ：トラブルの数
- 13. 13 こんな風に定義されました ※実際のドキュメント BEFORE AFTER Role Responsibility Role Responsibility Producers (PDM&PJM) Responsible for Product and Project •Prioritize •要件調整 •仕様調整 •Requirement Definition （内容・リリース日など） •Reporting(KPI、ROI) •Budget management •起案・管理（BvA） •Release Approval (Including Deployment plan) •調整事項 •Reporting （Project Progress） •Organizer（Kick-off , PRJ MTG, Agenda and minutes） PDM Responsible for Product (What and Why) •Prioritize •要件調整 •仕様調整 •Requirement Definition （内容、リリース日など） •Reporting(KPI、ROI) PJM Responsible for Project (How and When) •Budget management •WINES 起案・管理（BvA） •Release Approval •調整事項 •Reporting（Project Progress）Organizer（ Kick-off , PRJ MTG, Agenda） Engineers Tech lead •Deployment plan •Technical topic Engineers
- 16. 16 お願いごとは具体的な例で説明 ※実際のドキュメント 相談内容 相談相手 Notes 仕様や要求に関する相談 PDM 「なぜそれが必要か」 「なぜそれがあるといいのか」 「ENG視点でどのようにするのがおすすめか」 「おすすめした通りに実装する場合の影響は・・・」 といった”提案”の形で相談が望ましいです。 スケジュールに関する相談 PJM 必要に応じてPJMはPDMに相談 改善や、エンジニア側から発生したプ ロジェクトの相談 （開発・実装が必要な事項） PJM 例えば、今スプリントで実装して次のリリースに含めら れる 等 ただし、内容をPDMにシェアする。 •軽微でない場合は、PDMに相談する。 PDMがPriorityリストに入れて管理する。 ※PJMに相談する際は、Engineer側（Tech Lead)が内容 と工数や影響範囲などの情報をまとめておくこと。 エンジニアからの提案や相談について 混乱
- 17. 17 プロジェク ト承認 開発・ テスト リリース リリース後 やったこと4：プロジェクトのプロセスを再定義＆業務をAlign 各ステップで必要な ドキュメントは テンプレート化 承認者も明確化 遅延
- 21. 21 その他、やってみたこと • ロールモデルを見つける • 心理的安全性ゲームをやってみる。 • 文化にしたいことは繰り返し言う。
- 23. 23 具体的にどんな状態になった？ 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 2018年 2019年 • プロジェクトの進行がスムーズになった。 • トラブルが減った。 • メンバーが定時で帰る。
- 26. 26 チームとしての成果（業績以外の面） 歩みは一度遅くなっているかもしれないが 着実に歩んでいける ・・・という感覚をチームメンバー間で共有できている。 Photo by Kanako Muroyama
- 27. 27 これからの課題 個人戦からチームとしてのパフォーマンスアップをどうやっていくか • チーム外との関係性や連携をもっとよくしていきたい。 • もっと楽しんで／自信をもって仕事ができるようにしたい。 • 時間の余裕＆貯金をどうやって作っていくか。
- 28. 28 Let’s discuss !! 一緒にお話させてください。 複雑な案件の要求を スムーズにまとめる には？ 失敗したとき どう対応していますか？
- 29. スクラム道関西 x 楽天 スクラム Meet up 明日 4月20日 13:30開場 14:00開始 ワークショップ⇒2セッション⇒ディスカッション⇒ビアバッシュ なのに 無料！
- 30. Thank you!!
Editor's Notes
- 本日のアジェンダです。 タイトルは、トラブルだらけの現場から、仕事が「楽しい」現場に変わった、６か月間の話ということで、 どんな状況だったか その理由 何をやったか？ どうなったのか？ そして、そのまとめをお話ししていきます。
- そんな楽天でどんなサービスに携わっているかというと、 ランキングサービスです。 いわゆる、楽天ランキング第１位！とか言ってるそのランキングを作っています。 こんなページです。 どうやって作っているかというと、ざっくりなんですが データをとってくる、集計する、データ提供、そして提供先でデータが表示されるという感じです。 何がすごいって、対象になるアイテムが２億点を超えていて 国内のEC流通高が年間３．４兆円あるんですね。 ３．４兆の全部が対象というわけではないんですが、だいたい１日あたりどれくらいの量のデータをさばいているかを 想像していただけると、すごさがわかるんじゃないかと思います。 これを１日に１個、全体の１位を決めてるんじゃなくて、 だいたい１万くらいの商品のジャンルを集計するんですが、それが１日１回、だけじゃなくて、１時間に１回は更新されるようなものもあります。
- そんなランキング、作っているのは私が所属するランキングサービスグループなんですが、 こんな組織になっていまして、 エンジニアがだいたい１８人くらい。 プロダクトチーム、私が所属しているチームですが、 プロジェクトマネジャー PJMが２人 プロダクトマネージャー PDMが私を含めて２人 合計４人 今在籍しています。 ちなみに、私は今日お話しする６か月間では、プロダクトチームのリーダーをやっていて、今年に入ってからはグループ全体のヴァイスマネージャーも兼務でやっています。
- そんな私たち、どんな状況だったのか、ご紹介していきます。 （クリックしながら説明） こんな状況だったんですね。 本当にこんな顔しながら働いていたと思います。
- 具体的に、どんなんだったか？ということなんですが、
- （クリックしながら説明） かなり現場は疲弊していました。
- （クリックしながら説明） では、順を追ってご紹介していきます。
- （クリックしながら説明）
- 大きく１つの枠にまとめられていたのが 書く役割に分けられました。 特に、PDMは Responsible for Product （What and Why) PJMは Responsible for Project （How and When) と、 責任範囲も明確になったのがポイントです。 実は、エンジニアとの責任範囲もあいまいだったので、そこがはっきりしたのも大きかったです。
- 分割されたこと コミュニケーションのルートが設定されたこと
- やったこと６ 振り返りと、振り返りの振り返りを始めました。 しばらく振り返りってやってなかったのですが、やるようにしました。 KPTだと、Problemに目がいきがちなので、最近流行り？の、 Fun Done Learnを取り入れました。 これの特徴はできたことに目を向けられるので、 続けるうちに、メンバーから「仕事が楽しい」という言葉が出てきました。 このとき本当にうれしくて、仕事が終わってからこっそり泣きました。
- そんなこんなでですね。 不安、遅延、混乱が撃退されつつあるというわけです。
- 具体的に今、どんな状態かというと プロジェクトの進行がスムーズになりました トラブルが減りました メンバーが定時で帰り始めました。 うち、定時が５時半なんですけど、６時半まで残ってたら、最終提出になってしまうことが日常的になってきました。
- ロール分けと責任範囲の明確化 ドキュメントのテンプレート化とプロセスの標準化 グループ内メンバーへのアナウンスを丁寧にやる サポーターを得るこの４つです。 じつは、ここまでの話、全部が全部自力というわけじゃないんです。 うちの会社の特徴的なところだと思うんですが、カイゼングループというサポートチームがいまして、相談に乗ってくれたり、一度やってみせてくれたり、という形でサポートしてくれるんですね。 半年、お世話になって、やっとこれだけできるようになりました。 で、真似していただけそうなのは、この☆をつけた２つです。 ロール分けは、人数がある程度いないと難しいですし サポートのチームを作るのも会社の方針やリソース状況にもよるとよるので、できそうなところはこの２点かなと思います。
- 苦労したことは （クリックして説明） どうやって対応しているかというと。。。 （クリックして説明）
- クリックして説明 自信がついて、メンバーが明るく前向きになってきたのが何よりもうれしく思います。
- 最後に宣伝です！ 明日、すくらむ道関西と、楽天のコラボイベントがあります。 13時半開場、14時開始。場所は楽天大阪支社。すぐそこのフェスティバルタワーウエストの隣のビルです。 無料です。 ご希望の方は入っていただけるようにしておりますので こちらのQRコードから詳細が見られますので、そこから申し込みしてください。 セッションのテーマは「スクラムとパッション」、そして「サーバントリーダーシップ」です。