プロダクトマネージャーの“悩みの種”を解消するためにやるべきこと

プロダクトマネージャーの悩みの種を解き明かす

長幸次郎氏：本日はこのテーマでお話ししようかなと思っています。オフィシャルのイベント案内と違うタイトルになってしまって恐縮ですが、『プロダクトマネージャーの悩みの種を解き明かす』というテーマで話したいなと思っています。

私自身プロダクトマネージャーの仕事をやるようになって、仕様作成のプロセスに関して強く課題を持っていましたし、今も持っています。

なので本日は、「そもそもプロダクトマネージャーって何やるんだっけ？」という話をもとに、私が感じた課題をベースに、今Eightのプロダクトマネージャーたちがどのように動いているのかを紹介差し上げようと思っています。何か今のみなさまの仕事で役に立てるお話ができればなと思っております。

簡単に自己紹介差し上げますと、私は入社して7年半経ちまして、ずっとEight事業に携わっています。

最初はどちらかというとサービス運営のバックエンドですね。サポートとか業務企画だとか、あとは内部のKPIの仕組みの構築などを担当していて。徐々に事業が拡大するのに伴ってサービス開発のほうに携わってきて、ちょうど3年前くらいからプロダクトマネジメントを主とした業務に携わっております。

Eightの概要

「そもそもEightとは何ぞや？」という話なんですが、ちなみにこの中でEightを使っていますという人はどのくらいいらっしゃいます？

（会場挙手）

だいたい4割くらいですね。どうもありがとうございます。

Eightは一言で言うと名刺管理サービスですが、名刺を撮影すると即時手動でデータ化されます。ただの名刺管理にとどまらず、その先の人脈の活用までを含めたサービスになっています。

例えば名刺交換をした相手の人が転職や昇進をすると、その最新の更新情報が届いたりですとか、接点のある企業様のニュースを受け取ることができるようになったりですとか。

あとは名刺プラスアルファでプロフィール情報の登録・閲覧もできるので、より深くその人のビジネスキャリアなどを知ることができるというようなサービスになっております。名刺管理をベースにすべてのビジネスパーソンの力になることを目指して現在サービス開発に取り組んでおります。

最初に「そもそもプロダクトマネージャーは何をしているのか？」という問いから整理をしたいと思っています。まずは「プロダクトマネジメントとは何ぞや？」という問いですが、主にはプロダクトとユーザーさんの間に立って、顧客満足度を高めていくために、プロダクトの価値を最大化すること。これがプロダクトマネジメントであり、プロダクトマネージャーの主な業務かなと考えております。

プロダクトマネージャーの2つのミッション

それにあたって大きく2つのミッションがあると考えております。1点目が新しい価値の創造。これはユーザー様に新しい体験を提供するための追加機能などを指しています。

もう1点目がプロダクト品質の担保・改善。こちらはKPIですとか、ユーザーさんからのフィードバックをベースにした改善プロセスを指しています。

この2つのアプローチを以ってユーザー様の満足度を高めていくのがプロダクトマネージャーのミッションかなと考えています。今日お話しする内容はどちらかと言うと、画面でいう右側の「新しい価値の創造」の文脈の話が主になるかなと思っています。

もう少し「プロダクトマネージャーが何をしているのか」という整理を進めたいのですが、次は社内における立ち位置、実業務においてどういった立ち位置で動いているのかという整理をしていきます。

まず大きいところでいくと、経営陣ですとかビジネス開発、あとは営業メンバーなんかのビジネスサイドのオーナーとの大きい事業計画の擦り合わせだとか、プロダクト開発計画の擦り合わせなんかの調整があるかなと思います。

次に実際にそのプロダクトを作り上げていくためのエンジニアQAとかデザイナーを巻き込んだプロダクト開発の推進役ですね。

もう1個はマーケティングチームやサポートチームとリリース後のプロモーションプランとかサポート体制の構築の擦り合わせの調整なんかもあるかなと思います。

場合によっては財務や法務との調整もあるかなと思います。こんな感じでプロダクトをよりよくして価値を高めていくための玉運び役みたいなことが、実際社内でのプロダクトマネージャーの役割かなと思っております。

プロダクト開発における立ち位置

もう少し具体的に、「プロダクト開発における立ち位置ってなんだ？」というお話です。

大きくこのプロセスでいくと、大枠の開発計画の策定だとか仕様の作成においては推進をしていって、実装フェーズに入ったら仕様調整だとかですね。あとはテストフェーズに入ると、テスト計画に対して実際それを対応するのかしないのかというジャッジなんかをして、リリースまで持っていくというのがプロダクトマネージャーの役割かなと思っております。ここまでがプロダクトマネージャーの役割の整理になります。

本題に入っていきますが、「こんな悩みないかな？」と思っています。「ようやくやることも決まったし、仕様も固まったので開発を進めていくぞ」と意気込むんですが、例えばQAメンバーから「UI仕様が決まってないのでテスト計画作れませんよ」というコメントがあったりとか。

開発メンバーからも「画面仕様がわからないので設計はちょっと着手できませんね」とか。あとは実際に今の実装から考えると「ちょっと現実厳しい仕様なんじゃないですか？」みたいなコメントがあって。アプリ開発メンバーからも同様のコメントがあってですね。

進めようと思ったんだけど思うように進まないということがけっこうあるんじゃないかなと思っていて、私自身かなりこれは強く課題としてありました。「なんか思うようにまとまらないなあ……」というのがざっくりの課題ですね。

結局ここが狂っているとその先のプロセス全体もどんどん狂っていって、本質的にその価値を提供するためのリリースのスケジュールに対するリスクも大きくなってしまう。

何が問題かと言うと、これはかなり複合的な理由がいろいろあるかなと思っています。

例えば、そもそも画面が固まってない状態で機能仕様をまとめあげていたりとか。あとは仕様作成の中でエンジニアの方を交えた実装観点が入っていないとか。あとはステークホルダーの人から後々要望が変わって差し戻しになったりとか。いろいろあるかなと思っています。

仕様作成の5つのステップ

この課題をどう解決しながら作り上げていくかっていうのを、ここから話していきます。簡単に言うと足りないのって各段階における合意形成と巻き込みかなというふうに思っています。

主にはこの右側のビジネスオーナーサイドとの大きいレイヤーの合意形成。あとはプロダクト開発メンバーとの具体的な仕様に関する擦り合わせなんかが足りていないと、さっき言ったようなことになるのかなと思っております。

実際にこのメンバーとどういった段階でどういったコミュニケーションをするのかというのをこれから話していこうと思うんですが、その前に仕様作成にあたって大きく5つのステップがあるかなと思っているので、その整理をしたいなと思っております。

まず始めるときにユーザーストーリーを作成するかなと思っています。実際実現したいことって、「誰に対してどんな価値を提供したいんだっけ？」とか「使う人はどういった状況において何を求めて操作するんだっけ？」みたいなことを改めて言語化するというプロセスがあって、その次に具体的に機能感を出していくために画面構成をワイヤーに落としていくと。その次にもう少しプロダクトの質感を意識してデザイニングをして、大きく作るものの方向性を定める。

次にデザインプロトタイピングをして、実際のプロダクトのデザインパーツに当て込んで、かつ画面遷移を含むものを作る。そもそも作るものは何かというのをここで固め切るというフェーズがあるかなと思っています。

なので、デザインプロトタイピングがそのまま機能仕様なり画面仕様になっていくというのがこのフェーズかなと思っています。

これが終わったら、ここからデザイン指示書とか機能仕様書に落とし込んでいくというので完結する。こういう5つのステップがあると思っています。

関わるステークホルダーを整理する

この5つのステップの中で巻き込むべきステークホルダーというのは異なってくると思っています。例えばモックアップであれば、デザイナーはもちろんですけれども、経営陣とか営業メンバーとかビジネスオーナーサイドと大枠のプロダクトの方向性なんかをここできちんと握る。

プロトタイピングに関してはもう少し具体的な機能仕様をデザイナー、QAエンジニア、開発メンバーを巻き込んで固めていく。最終段階でデザイナーとQAと一体となってドキュメンテーションをしていく。

この中で、プロダクトマネージャーが1人でやっていくという話ではないので各ステークホルダーとコミュニケーションを取りながらきちんとフィードバックを回していくというのが非常に重要かなと思っています。

きちんとこの段階で踏むべき合意形成ができていれば、自然と最終的に仕様ドキュメントができる状況にはなるかなと思っています。

あえて95パーセントとしてますけど、作りながら細かい仕様調整だとか細かい判断はあるかなと思うので、実際は100パーセントになるのは実装しながらだと思いますが、その前段階で95パーセントくらいの仕様を完成することはできるかなと思っています。

各ステップでのコミュニケーションのとり方

具体的にこの各ステップにおいてどういったコミュニケーションをどういった人たちと取っていくのかという話をここからしていきます。

まずこのユーザーストーリーの作成とワイヤーフレームに関しては、ペンを握って動けば大丈夫な世界かなと思っています。もちろん周りのメンバーに対して壁打ちをしたりというふうに推進する必要はありますが、基本的にここまではペンを握ってがんばると。

モックアップ作成段階からですが、これに関してはまずきちんとワイヤーフレームをデザイナーの人と擦り合わせて、そこからデザイナーにプロダクトをデザインに落とし込んだものをアウトプットでもらう。それに対してフィードバックを回して固めていく。主にはデザイナーとプロダクトマネージャーで固めていく。

そこでできあがったものをビジネスサイドのステークホルダーに対してレビューをかけて、ここでももちろんフィードバックもあると思うので、その場合は適宜修正を繰り返して固めていく。

ゴールとしては大枠のプロダクトの質感を以ってした合意形成かなと思っています。実際のプロダクトに近い画面をベースに具体的なイメージがビジネスサイドのオーナーと握れている状態というのをモックアップで作ることを目指す。ここで合意が握れればもう少し具体化することができていきます。

プロトタイピングにおけるポイント

次はプロタイピングですね。ここからが楽しくなってくるポイントかなと思うんですけれども。基本的には必要となる機能や画面の整理というのはプロダクトマネージャーが整理します。

各機能だとか画面における仕様の決めごとだとか論点の整理というのもプロダクトマネージャーが中心となってやりますが、とはいえ1人で動くというよりは、例えばQAメンバーからは仕様検討の観点不足をフィードバックしてもらったりですとか、エンジニアのメンバーからは技術的な観点での課題なり懸念なりをフィードバックしてもらったり、はたまた実現方法の提案というのをもらって。例えば「もう少しこういう仕様にしたほうが工数を抑えられますよ」みたいな類のものですね。

デザイナーに対してはデザインをオーダーして、デザイナーは必要になるデザインを作ってプロトタイプをマージしていく。このワークが下準備になって、プロトタイプをベースに挙がっている論点を潰していくという会議体を設定する。

スクラム開発でいくとリファインメントっていうスクラムイベントがそれに該当するかなと思います。頻度はその体制だとか実際のプロジェクトの状況によって変わると思いますが、デイリーで詰める場合もあるでしょうし、週次で詰める場合もあると思います。

基本的にここの会議体のアジェンダがよれたり、ここの決定スピードが遅れると、全体へのインパクトもでかいので、ここは非常に重要なポイントになってきます。

あとはこのミーティングにおいて画面をベースに話をしていけば、自然と機能仕様なんかも論点として上がってきて、議論が深まるというのも良いポイントかなと思っております。

基本的にはこの2つがゴールになっていて、これができあがると、画面遷移含めて実挙動に近いもので、認識が開発チーム内で共有されている状態を作り上げることができると。

かつユーザーヒアリングも使えるかなと思っています。

EightではtoBのサービスであれば見込み顧客の方にデモンストレーションをしてフィードバックをもらったり、あとはEightのユーザー会なんかのイベントでもデザインプロトタイプを見せてフィードバックをもらってチューニングするといったようなことをしています。ユーザーヒアリングにも使えるというのは良い点かなと思っております。

仕様ドキュメントの作成

ここまで来たら最後はまとめあげのステップで、プロトタイプをベースにデザイナーはデザイン指示を作って、プロダクトマネージャーは機能仕様書を作っていく。

この2つが揃った段階で、QAから仕様の抜け漏れの最後のチェックをしてもらい、これを完了すれば基本的にはエンジニアは受け入れて実装スタートできる状態になるし、QAはテスト設計が開始できるという感じでスムーズに次のステップに回すことができるかなと思っております。

仕様書のベースの軸でいくと、プロトタイプがあって、それをベースにデザイン指示書と機能仕様のドキュメントができあがって、これらを以っていわゆる仕様書が完成するというようなイメージですね。

ここまでできていれば、こうだった状況も自然とハッピーな状況になっていくかなと思っています。ここがきちんとまとめられていればきちんとリリースまでスムーズに進めることができるかなと思っています。

使用しているツールとポイントの振り返り

使っているツールも簡単に紹介したいなと思っていたんですが、時間も迫って来ているのでかいつまんでいきます。Eightでは基本的にこの4つのツールを使っています。

会議体で詰めるべきものの議事録だったりステータス管理だったりはすべてGoogleスプレッドシートで行っています。プロトタイピングツールはInVisionだとかMarvelを使っています。

この2つがいいのは、当然オンラインで管理できるというのもそうなんですが、スマホでアプリを触るような質感で操作できるので、気になったときにすぐ確認できるというのはかなりデザインレビューが捗るかなと思っています。あとはメンバーへの配布も簡単にできますね。

デザイン指示書はZeplinを使っていて、機能仕様に関してはすべてQuipにまとめて管理しています。Quipはとにかく軽いのとコメント機能も充実しているので仕様調整なんかも捗りますね。

最後にポイントの整理に入りますが、重要なのはやはり画面をベースにステークホルダーときちんと握っていくこと。ワイヤーフレームの状況とかだと結局具体化する中で動線が変わったりだとか、イメージが変わったりすると思うので。きちんとプロダクトの質感に近いモックアップでビジネスサイドとは握り、プロトタイピングを使って開発チームとは詰めていく。

プロダクトマネージャーってなにかと抱え込みやすいかなと思うんですけれども、きちんと各メンバーにボールを配ってアウトプットする場であるミーティングを設計するというのは非常に重要かなと思っております。

あとは、プロトタイピングは開発チームを交えて議論しながら詰めていって、1番重要なのは各フェーズにおいてきちんと好循環のフィードバックプロセスを回すコミュニケーションの設計を意識するというのが重要かなと思っています。

以上をもちまして発表を終わらせていただきます。本日はどうもありがとうございました。

（会場拍手）