全員プロダクトオーナーに参加して来ました！

こんにちは！おおはしりきたけです！3月15日に「全員プロダクトオーナー」に参加してきました！

全員プロダクトオーナーとは？

プロダクトオーナー、諸君らはプロダクトの結果に責任を担う。
時に雲を掴むような思いで、ユーザーのために実現すべき内容を練り上げる。
何もかも一度に提供することはできない。付けられるはずもない優先度をそれでも付けてきた。
そして、その日々は常に荒ぶる予算枠との戦いだ。振り向けばローンチの日が迫ってきている。
チームよ、スクラムマスターよ、我々はともに、プロダクトの夢を見れるのか。

今回のDevLOVEのテーマは、「プロダクトオーナー」です。
未だ暗黙知となっている領域が大きい、プロダクトオーナーの役割。
プロダクトとして何を作るかをどうやって考え、決めるのか。皆さんはプロダクトオーナー特有の課題に
迫られ、様々な工夫を実践されていると思います。その課題そのものと、工夫について、現場やプロダクトを
越えて共有し議論することはお互いにとって有益でしょう。
今回、プロダクトオーナーのロールを担い、プロダクト開発の前線で戦うお二人をお招きしました。
お二人には現場の話をして頂きます。お二人とも、実践のさなかにあり、お話頂くことは答えではなく問いです。
まずは、プロダクトオーナーの抱える課題とは何か、から始めましょう。

　イベントURL：http://devlove.doorkeeper.jp/events/2950

■プロダクトオーナー事例1

タイトル：「株式会社ネクスウェイ-アジャイル開発事例-」

発表者：小田切一成さん

NEXLINK Basic開発を進めるにあたり、アジャイル開発経験、PO経験がない小田切さんの経験を語って頂きました。

○なぜ？アジャイル開発を？

• UI/UXの不統一
• ランニングコストの増大
• 開発プロセスの透明性

結果的にアジャイル開発は効果的

• 内製化にこだわったUIとUX
• クラウドの積極利用
• 最新のデモ環境を常に提供

結果として

• 導入数：180社
• リリース前：100社以上の申し込み

完全版じゃないけど触ってもらえる環境を作れたのが良かった！！

リリース前

１．アジャイルコーチ

やるならやるでちゃんとやる！Scrumは、本を読むだけではできない

• 朝会の意義
• プランニングポーカー
• ワークショップ
• 振り返り

やることの意義を感じることができた。ワークショップは否定的だったけど、やった後は開発の人が積極的になった。自分たちではできなかった。

２．社内を仮想顧客に

社内で使えないものは社外でも使えない。まずは販促企画の方を仮想顧客にし、徹底研究した。メルマガに４０分かかる。目的は彼女たちの業務を半分にする。

３．開発環境の整備

Macを導入した。ディスプレイも購入。テストなど、Windowsが必要なので、VMWARE　FUSIONを導入し対応した。結果的に開発効率は上がっていたと思う。

４．コミュニケーションツール

• Skype：チャット、備忘録
• CO-MEETEING：議事録、wiki、外部とのやり取り
• youroom：関係者への共有

５．チーム増員と細分化

開発のスピードを上げるために、増員をした。
⇒正直なところは開発スピードが思ったほど上がっていない。また、既存のチームと分かれているため、コミュニケーションがとれない

６．勉強会/セミナー

週２回勉強会を実施。勉強会をすることでチームメンバーは成長！コードも綺麗になってきていた。

７．スプリント凍結

当初は１月にリリースだったが、バーンダウンチャートを見ると、無理。スプリントを凍結した。プロダクトオーナーとしては、反省

リリース後

８．短期リリース

リリース後の予定を作成したが、リリース後のほうが対応が増える。アジャイルにしたがって見積もりをし直す

９．誰かに依存させない

運用チームなどからの問い合わせも誰でも回答できるようになっている。

１０アジャイル開発浸透

• 営業
• 経営
• 運用
• インフラ

上記の方々から様々な意見が出てくる。とにかく社内にアジャイルを浸透させる。誰に満足してもらうため？経営向け/一般向けに社内勉強会をして普及活動をしている。

まとめ

良い点

• アジャイルコーチ（メンター）の積極活用
• 社内に仮想顧客の設置
• 開発環境の整備
• コミュニケーションツールの積極利用
• 勉強会/セミナーの参加を促す
• 機能開発を特定の人に依存させない

課題点

• チームメンバーの増加＆細分化
• アジャイル開発の社内浸透

ダメな点

• リリース直前のメンバーへの負担増
• リリース対応後を考慮しない開発計画

■今後の課題

• 息を抜く隙がない
• ドキュメントを整備
• 開発と運用の一体化
• リリース後の会議増加

■POやってみて

• 何でも屋だと思われている
• 謝るの”も”仕事だと思わないと
• 製品に愛がもてた 

開発メンバーに気持ちよく働いてもらう＝いいサービス！

顧客満足の最優先を目指して一緒に頑張って行きましょう！というお言葉でまとめて頂きました。

■プロダクトオーナー事例２

タイトル：「楽天市場のプロダクトマネジメント」

発表者：伊勢路真吾

１．自己紹介

楽天市場のプロヂューサー約２年 　楽天の前もWebサービスをやっており、Shufoo！Mapionなどを担当していた。地図サービスは情報設計が難しいが、位置情報を使ったサービスは刺激的だった。2009年に楽天に入社

２．楽天市場とは？

商品ページは情報が多い・

楽天ユーザー数：8156万人。楽天市場は、1兆円の売上があり、購入者1000万人以上。店舗は4万店舗以上あるため、全店舗さんに満足してもらうのを考えるのは難しい

多種多様なジャンルがあり、売上の規模もぜんぜん違う。ビジネスモデルは、B2B2Cモデル

ビジネスサイド

• 営業・ECコンサルタント
• 企画サポート

開発サイド

• 技術サポート
• 開発・運用

その他

• 外部ステークホルダー

楽天大学で、店舗をサポート
⇒店舗の声を聞いてサービスに入れていく

楽天市場の開発

• 自社サービス
• サービス規模が大きい
• 社内開発体制が強い

３．取り組み（PDM、Producer）

PDM＝Product　Manager

特定のプロダクトについて、戦略にのっとった機能開発、要望やバグなどを含め、対応順序をプライオリティづけ。各種仕様を把握し、次に来る要件や仕様検討を実施。開発プロジェクト化までのフェーズを担当。

プロダクトの単位は？

店舗を支えている機能

• 出店
• 商品管理
• 注文管理
• 分析

ユーザーから見える機能

• 検索
• 商品ページ
• イベント

それぞれの機能ごとにプロダクトオーナーをつけている。

プロダクトをマネジメントする

• 仕様把握
  • 縦だけじゃなくよこも
• アイデア収集
  • 社内から（ビジネス部門、開発）
  • 顧客（コンシューマー、マーチャント）
• 優先度づけ
  • プランニング

実際にどんなツールを使っているか？

• JIRA
• CONFLUENCE

１９９７年から稼働しているサービス 昔からあるシステムにありがちな複雑さに付き合わなくてはならない

現場の混乱が起こる

• 新しいポジション
• 分業すぎない？
• 国際色豊か

組織も国をまたいでの連携が求められる。縦横の連携が必要

PDM以前のProducerとは？

開発部門に身を置き、主に上流工程を担当

• エンジニアと一緒にサービスを作る
• プロジェクトマネジメント
• QA
• 運用
• サービス改善

個人差がでる。PDMと比較して棲み分けがないのが良い点ではあるが、全部できるおはスーパーマン。PDMが浸透中

４．改善試作

リーンなサービス開発

• 受託開発ではない
• 顧客の声をどう聞くのか

店舗様からの声

• イベントの活用
• サポート窓口への問い合わせ
• 場合によっては個別訪問もある

ユーザー様の声

• レビュー
• ソーシャルメディア
• サポート窓口への問い合わせ

これらの声を、PDMやProducerがJIRAに登録

５．なにを目指すか

プロダクトオーナー

• プロジェクトマネージャー？
• プロデューサー？

パフォーマンスの最大化

• 体制づくり
• 組織である意味

高いパフォーマンスを継続する

• スピードを重んじる文化
  • ナレッジやノウハウ
  • 次世代育成、人員の入れ替わり
• モチベート

この先グローバル展開。視点を広く持つ必要がある

■まとめ

全員プロダクトオーナーというタイトルながら、プロダクトオーナーではない私が参加しても良いのか？という疑問もありましたが、前回の全員スクラムマスターに続き、迷わず参加させてもらいました。上記セッションが終わった後、プロダクトオーナーについのてダイヤログを行いましたが、どのテーブルも盛り上がっていました。私自身はプロダクトオーナーではないのですが、様々なプロダクトオーナーの方々からお話を聞けとても有意義な時間が過ごせました。私は本などの座学でしかプロダクトオーナーを理解していませんが、経験している方々に貴重な話を聞くことができました。コミュニティって本当に素晴らしいですね！！