ログイン

会員登録

検索

ログイン

メニュー

検索

ログイン

メニュー

プロダクトオーナー祭り 2018 Summer ～プロダクトマネジメントが世界をツナぐ～

2018.07.07 - 2018.07.07

割と大きなプロダクト開発組織で「何を」「いつまでに」つくるかを整理した話（全1記事）

1記事目

2019.03.11

メインカテゴリ経営・マネジメント

Pairsの開発組織を「機能別」から「職能別」へ　組織の変革で学んだプロダクトオーナーのあるべき姿とは

リンクをコピー

記事をブックマークブックマーク解除

画像・スライド一覧

2018年7月7日、株式会社フリークアウトにて「プロダクトオーナー祭り 2018 Summer ～プロダクトマネジメントが世界をツナぐ～」が開催されました。IT関連企業に所属するソフトウェア開発のプロダクトマネージャーやプロダクトオーナーを中心に、それぞれが携わるプロダクトの価値や、マネージャーとしての体験談など、幅広い観点からライトニングトークが繰り広げられました。本記事では、株式会社エウレカ Head of Productの金田悠希氏によるLT「割と大きなプロダクト開発組織で「何を」「いつまでに」つくるかを整理した話」の模様をお送りします。

Pairsが好調なエウレカのプロダクト責任者が語る現状

金田悠希氏：みなさん、こんにちは。半ばに差しかかって、お疲れだと思うんですけれども、これから10分間、「割と大きなプロダクト開発組織で『何を』『いつまでに』つくるかを整理した話」という長いタイトルでお話をさせていただければと思っています。株式会社エウレカの金田と申します。Head of Productという肩書があるんですけど、Pairs Japanのプロダクト責任者をしております。

エウレカが（自身のキャリアで）2社目でして、前職ではモバイルゲームの立ち上げなんかをいろいろやっておりました。今はけっこう大きい組織のプロダクトマネージャーみたいなことやっているんですけど、前職では立ち上げをメインでやっていました。

ゼロイチから4人のチームでスタートし、そのチームがどんどん大きくなって、今では30人ぐらいになりました。その過程でいろんなことに悩んだり、試行錯誤したりしながらやってきた人間です。

僕、プロダクトが本当に大好きなんです。プロダクトを伸ばすにあたって、チームとか組織とかを、どうやって変えていかなきゃいけないかを、下手なりにもがんばってやっています。

（スライドを指しながら）こちらがPairsですね。先ほどの梶原（注：株式会社エウレカ CTO Office 責任者／Principle Engineerの梶原成親氏）の話で、みなさん（Pairsを）ご存知だってことはわかったので、ここでは簡単に説明しようかなと思っています。

累計会員数は700万人（2018年7月当時）を突破しました。利用・実績ともにナンバーワンのオンラインデーティングサービスとしてやらせていただいています。エウレカ自体は今、世界最大のデーティングサービスグループであるMatch Groupの傘下に入っています。

（Match Groupは）時価総額13億ドルでMAUは7000万人（2018年7月当時）。ちょっと想像しづらいような数なんですけど、世界110か国で展開しているようなグループに入って、いろいろとやっています。

ちょうどこの間、グループの各国の人たちが集まる交流会みたいなことをやっておりました。僕も実際に現地へ行って、「世界の人たちがどんなかたちでプロダクトマネジメントを行っているか」であったり、「どうやってプロダクトを作っていますか？」という話だったりと、いろいろ聞いてきています。

機能別組織から職能別組織への転換

前置きがちょっと長くなってしまいました。Pairs Japanに関わるメンバーはだいたい40～50人（2018年7月当時）なんですけど、今日はその「わりと大きい組織」をリニューアルした話をさせていただくため、どんなことをやってきたかを1つずつお話していこうと思っています。

（スライドを指しながら）左側がもともとの組織図です。3ヶ月前ぐらい前、2018年4月ですが、大きく右側の姿に変えました。左側の図はいわゆる「機能別」の組織ですね。「Pairsにおけるユーザー体験をあげていきましょう」とか、「マネタイズを強化しましょう」「ユーザー会員数を増やしていきましょう」と、機能別にチームを切っていました。

左側の組織で課題だと思うことに、MECE（Mutually Exclusive and Collectively Exhaustive)に分けづらいことがあります。例えば「iOSで技術的負債を解消したいよね」といった問題をどのチームが受けるのか、役割としてはっきりさせづらかった。そういう課題がありました。

あとは、例えばエース級人材のデザイナーがマネタイズチームにいたとして、そのエース級人材はマネタイズチームでは活躍できるけど、他のチームのメンバーをサポートするみたいな動きはちょっとやりづらかった。

そういった背景もあって、右側の「職能別組織」に変更しました。何を目的にしていたかというと、もっとも良かったのは「集合知を発揮する」ということですね。デザイナーの例でいうと、業務がいろんなチームやファンクションにまたがっちゃうと、横串での職能別で話しづらいということがあります。エース級人材が他の（同じ職能の）人材を引き上げていくみたいな動きが取りづらかったんです。

新しい組織に変えてandroidはandroidの人、デザイナーはデザイナーの人で集まることによって、モブプログラミングのように「自分の持っている強みを共有し合って、1つのプロダクトに還元する」みたいな動きが、ちょっとずつ増えてきました。

さっき言ったような、iOSで何か取り組みたいとか、デザイナーとして新しいトレンドに着手したいとか、そういった職能毎に「こういうことを事業としてやっていこうよ」っていう提案もちょっとずつ増えています。

また、去年からPairsのデザインを新しく変えていっています。こうした動きを加速していこうというのも、今の事業体制だとかなりやりやすくなったと感じています。

散らばっていたバックログを1つに集約した効果は

もうひとつ、バックログについてです。もともとは機能別にバックログを持っていました。Pairs Japanとして1つにしていなかったんですよ。これはみなさん、普通に聞くと「危ないな」って思うかもしれないですね。

そういうこともあって、Pairs Japanとしてどういうバックログを、どういった優先順位でやるか1つに整理するように変えました。こうすることによって、例えばマネタイズでものすごく重要な施策があって、UXチームの人もグロースチームの人も手伝わないとダメな状況に対し、全員で1つのプライオリティを持って、優先度変更とかリソース変更とかを柔軟に行いやすくなりました。

心掛けているのが、技術課題やデザインの課題といった「ビジネス課題と直結しづらいもの」を、バックログとして別に置きがちなんですけど、我々は「それを絶対に1つにするぞ」と決めて、全部1つのバックログに並べるようにしています。

これをやっている背景がありまして、例えばこのスライドに「Tech Issue 1」と書いてあるのが、iOSのものだったとします。そういう図があったときに、iOSチームが結局「何を軸に、今自分たちはどういう優先度を持ってやらなきゃいけないか？」ってことを、全体のバックログを参照しながら、自分たちのチームのバックログの並べ替えもちゃんとできるようにすると。

先ほど「1つ」って言ったんですけど、実態としてはPairs Japanで大きなもの（バックログ）を1つ持って、それぞれがそれに合わせるかたちで各チームのバックログを持つということをやっています。これを職能毎に置くようにしています。

これはSpotifyの（マネジメントの）用語なんですけど、AlignmentとAutonomy、つまりは「規律」と「自分たちで判断する領域を増やす」ことができるように、「僕らとして何が大事か」というのを1つにして持っておくということをやっています。

あと、優先度を判断する軸を作成しました。PMが事業バックログを並べ替える責任者であるべきだと思うんですけど、組織が大きくなってくるとその人が最終的に並べ替えるよりも、「どういう優先順位に並べ替えるべきか」というポリシーを作って、みんながその判断に乗っかれるようにしていくことがより重要になるかなと思っています。

なので、僕がやったことは「事業バックログを並べ替えるという作業」をし続けることではなくて、（文章にすると）6行ほどなんですけど、「それ（事業バックログ）を並べ替える『ポリシー』をまとめる」という作業でした。

組織の変革で学んだ、プロダクトオーナーのあるべき姿とは

ポリシーの作り方を、詳細まではなかなかお伝えするのが難しいです。まず「何を目指すのか」ということから逆算します。僕らは「文化を作る」ということを大事にしてやっているんですけど、「文化になる」とはどういう状態なのかをキーリザルトに設定し、逆算してキープライオリティを作るようにしています。

この大きなプライオリティのもとで、例えば誰かがアイテムを提案したとしても、比較的、誰でも優先度を判断しやすい状況を作れるように心掛けています。

最後です。「かんばん（注：トヨタ自動車株式会社の生産管理方法「かんばん方式」において使用される帳票のこと）の導入」と「週次の改善」をやっています。先ほどの機能別のチームでスクラムをやっていたんですけど、「かんばん」を1つ大きく設け、Pairs Japanのタスクっていうのを、さっきのバックログ1つに対して「かんばん」で管理するようにしています。

僕がここでやったことに関しては、「なぜ『かんばん』をやるか」ということを、ただ言語化しただけです。そして「どうやって『かんばん』を回していくべきか」はみんなで考える。これを「改善委員会」というかたちで組織しています。週次でリードタイムをみながら、「どうすれば早くユーザーに価値を届けられるか」「WHYを達成できるか」ということを、常に考えてもらうようにしています。

最後にまとめなんですけど、けっこうプロダクトマネージャーって、わりとプロダクトバックログ作りだとか、事業にフォーカスしがちなんですけど、組織が大きくなってくるとプロセスに対してもすごく責任を持つことが重要かなと思っています。

さっきの話のとおり、事業バックログを1つにし、何が1番重要かを明確にし、それに対してみんなが「かんばん」で優先度を判断して、「そこからやっつけていこうよ」とフォーカスポイントを明確化できることが重要かなと考えています。

私が学んだ大切な振る舞いは「ポリシーを作ること」だと思っています。AとBのどっちが大事かということについて、みんながわかる判断基準を作ることと、そのためにWHYを言語化していくこと。これがすごく重要だということを学びました。これで私の発表を終わりにしたいと思います。どうもありがとうございました。

（会場拍手）

続きを読むには会員登録
（無料）が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら