はじめまして！
ランサーズ株式会社でlancers.jpのプロダクトマネージャーをしている板倉(@idemii)です。

この記事はランサーズ Advent Calendar 2020 15日目の投稿です。昨日は @boro1234 さんの [Apex]レポートの集計値を取得する方法 でした。

はじめてのnote投稿ということでカッコいいことを書きたい気持ちをグっと抑えて、このnoteでは新人プロダクトマネージャーが陥る「しくじり先生」的エピソードを書いていきます。ご笑覧ください。

こんな人に読んでもらいたい
・PO,エンジニア,デザイナーなど周囲の意見に右往左往している人
・何度も同じ議論をして、手戻りをしている人
・toBでターゲット顧客が複数あるプロダクトマネジメントをしている人

こんなことが書かれています
・手戻り理由は「ターゲットが違う」「細かい仕様の話」をしているから
・「ターゲットが違う」のはターゲットセグメントを可視化し、共通認識にした上でスコープを絞る
・「細かい仕様」ではなく「ゴール＝期待される完了状態」を擦り合わせる

■はじめに

私はランサーズ株式会社にグロースハッカーあがりのマーケターとして入社しました。
マーケター時代は、MAシナリオ設計/TOPページリニューアル/SEO施策と、主にActivation施策を行ってきました。SEO施策もしくじり度合いが半端なかったのですが、またいつかnoteに書きたいと思います・・・。

2019年1月からPdMとなり、約2年が経過しました。
初期はグロースハック、その後3ヶ月以上の大きなプロジェクトを企画、遂行しています。
グロースハックの単純明快KPIでA/Bテストが全ての世界と異なり、Go-To-Marketが求められるtoBプロダクト。かつ、ターゲット像もユースケースも複数ある lancers.jp に日々悪戦苦闘していました。

中規模の企画・開発に小慣れてきた頃に陥ってしまった、toB向けプロダクト企画の罠の紹介です。

■この話は4回目？議論が手戻りしたプロジェクトの話

2020年4月、toB向けのGo-To-Market兼カスタマーサクセスの部隊を立ち上げます。意気込んだ私は、聞いてきた課題をすぐに機能にしようと企業規模が異なる2社をペルソナとして企画をはじめました。

1回目：ユースケースが違うと指摘

類似機能が既に存在していたため、少し改変して機能開放で実装しようと提案。
PO（プロダクトオーナー）にユースケースが全く異なるものをつなぎ合わせてちぐはぐになっている状態と指摘され、新しく作り直すことを決めました。

2回目：コーポレート部と顧客に壁打ちして微妙なズレ

lancers.jpは仕事の受発注サービスで法的論点があったため、社内有識者に相談をしました。その仕様は一定基準では十分だが、弊社の業務プロセスとは異なるという意見でした。

顧客に対しても担当者を通じて、ヒアリング。顧客は課題を教えてくれるのみでこの機能にピンと来ていない様でした。

この企画をそのまま進めてもいいのか？再度POと議論しましたが、一定基準は満たせるということで、そのまま企画を進めます。

3回目：仕様が全く定まらず、POの言いなりに

PRD（製品要求仕様書）でPOに壁打ちすると、ほとんど全ての要件・仕様にわたり修正レビュー。

自分の企画なのに、POが要件と仕様を決めているのと変わらない状態。そんな体験は初めてでした。相当悔しかったので、驚異的なスピードで機能フローやワイヤーフレームを詰めた記憶です。悔しい時、パワーが出る人間もいるんですよね。不思議。

4回目：チームメンバーのまっとうな指摘

仕様が定まってきた段階で、複数のチームメンバーに仕様伝達をした時、議論が紛糾しました。

「この機能は自分だったら使わない、要らない」「このユースケースに対応していないけど良いのか」「これはまさにタイヤの絵だ」

タイヤの絵とは、「顧客が本当に必要だったもの」という有名な図で、システム開発において顧客の要望を捉えることが如何に困難であるかといったことを端的に表したものです。

引用：https://www.casleyconsulting.co.jp/blog/engineer/4334/

結末：POと大喧嘩もとい議論、からの発見

皆から奇譚なき意見をもらい、ランサーズというのは風通しが良い会社だなぁ。と思うのと同時に、再度疑問が生まれてきたのです。

「コーポレートも顧客もエンジニアも違うと言っている本当にこの仕様で良いのか？やっぱり１回目の議論の地点に戻るべきではないのか？なぜPOと話が折り合わないのかわからない・・何度目かの議論を持ちかけるも、同じことの繰り返しでどうすれば良いかわからない。」

悩みすぎてslackの分報(※)に突然投稿したところ、複数のメンバーが激励したり慰めてくれたりする中、エンジニアのKさんがある問いを投げかけてくれました。そこから解決策のきっかけが見つかったのです。
※分報：slackの悩みや進捗などなんでも書いて良い公開個人チャンネル。

（別件ですが、これを物怖じせず私に伝えてくれることに人事組織的観点でお褒めのお言葉がありました。）

■原因は「ターゲットの違い」「細かい仕様の議論」

紛糾したプロジェクトの経緯を長く説明しましたが、以下2点が原因でした。

1.ターゲットの違いを認識せず、全員違うターゲットを想定して会話
2.細かい仕様の議論をしているため、永遠にターゲットのズレに気付かない

誰一人間違っていたわけではなく、全員が違うターゲットのことを想定して正しいことを発言していたのです。

すぐに原因がわかったわけではなく、分報からヒントを得て解決策を実行。その後一切議論が起きずプロジェクト完了まで進めました。
原因をシャープにしたことで、以後別プロジェクトでも同じ解決策を踏むことで発生していません。

■解決策1：ターゲットの可視化、今回機能のスコープを定める

toBプロダクトの顧客は自分達でない可能性

「自分だったら」「弊社だったら」「今までの自分の体験では」という言葉と、lancers.jpの主要発注側顧客であるsmallB「小規模企業」を指していたPOと周囲のターゲットのズレがあったのです。
ランサーズ社自体は決して大きな会社ではないのですが、つい最近上場したことで、厳しい水準の業務プロセスを求められていたことも議論を発生させていた要因の一つです。

また、顧客へのヒアリングでピンときていなかったのも異なるセグメント層に質問していたということに気付きました。

ベンチマーク機能の理想と現状顧客の差分

また、最初の段階で目をつけた類似機能が、現在の主要顧客向けではなく大規模企業向け機能/体験でした。

最初の類似機能をベンチマークとしてしまったため、顧客の違いに気付かなかったのです。

求めるニーズを規模別に可視化、スコープを整理する

そこで、一枚の図を作りました。発注者が求める要求を企業規模別に定めた図です。
lancers.jpでの仕事の受発注サービスなのですが、今回は仕事受発注に付随する周辺の業務プロセスの要求です。周辺の業務プロセスは顧客と話していく上で「企業規模」などで違いが生まれていることがわかってきたため、今回はそのセグメントで分類しています。

（ぼかしばかりですいませんが、お許しを）

このセグメント定義で、限定したスコープの共通認識を持つことで以後議論は発生しなくなりました。

スコープの整理について、私はロフトワーク社長の林さんが大好きでロフトワーク社から出版されているPMBOOKの紫本を参考にしています。
ソフトウェア開発の古典PMBOOKをWebディレクションに合わせてカスタマイズしている良書です。しかも無償公開されているので、おススメ。

■解決策2：「細かい仕様」ではなく「ゴール＝期待される完了状態」を擦り合わせる

弊社のPRD（製品要求仕様書）フォーマット

各社いろいろなフォーマットがありますが、前提として弊社のフォーマットを簡単に紹介します。先代から改良を重ねて使い続けているもので、企画部分と実装部分に分かれています。

企画部分：顧客の真に迫った課題か、事業上投資効果が得られるか
実装部分：特定の課題に対して、期待通りの製品/体験を作れるのか

今回は実装部分が論点なのですが、業務フロー/ワイヤー/細かい仕様ばかりに注力していて、上段のゴール要件が最も大事だということに気づいたのです。

ゴールとは、顧客の機能使用後のあるべき状態

今思い返すと、以前の私のゴールの定義の仕方は、お粗末なものでした。
・「プロダクトのKPIがXXXに増加！」といった運営のKPIしか記載されていないので製品/体験の最終状態がわからないもの
・「上記のターゲットが機能を使えていること。」といった内容がないよう・・・というもの

今回の解決策としては、顧客が機能仕様後のあるべき状態になっているか、を定義しました。

このあるべき状態を一度定義し共通認識にすることで、仕様やデザインをその都度顧客やPOに相談せずとも、ゴールに向かってチームメンバーだけで効率よく検討できるようになったのです。

ゴールという言葉がビッグワードで紛らわしくさせているのではないか？と思っていたところ、グッドパッチ社などでは「期待されている完了状態」という言葉を使っているそう。
今回の解決策にぴったりなので、今後はこの言葉を使っていこうと思います。

文章ダルいから、概要と図だけで表現はダメ絶対

プロダクトマネージャーになる前は、私もワイヤーでのコミュニケーションや図での説明、チャット上でのざっくりの指示を多用していました。

しかし、PRDを雑に書くと今回のように絶対にズレます。
もっと拗れてプロジェクトが終わらない黒歴史を大昔に引き起こしたことも、目撃したこともあります。

ところで、最近子供のプログラミング講座を横から見ていたんですよね。小学一年生でも要件定義できるのに、私たち大人はいつになったら要件定義が上手になれるんでしょうか。永遠の課題ですね。

■その他の学び

それ以外にもいくつか確信に変わったことが多かったので、いろいろ学びがあるプロジェクトでした。

・顧客は答えは教えてくれないし、逆に答えを言ってきたものは万人には利用されないこともある
・全顧客への銀の弾丸はないことを受け入れる
・自分が何を大事にするか決める。人に言われているだけだから議論が紛糾して右往左往する

■おわりに

まとめ
・手戻りの原因は「ターゲットが違う」「細かい仕様の話」をしているから
・全員が正しい事を言っているのにターゲットが違うから、まとまらない

・「ターゲットが違う」に対する解決策は、ターゲットのセグメントを可視化し、共通認識にした上でスコープを絞る
・「細かい仕様」ではなく「ゴール＝期待される完了状態」を擦り合わせる

このプロジェクトは現在無事リリースし、リリースから1ヶ月強経ちますがプロモーション無しにも関わらず、対象顧客UUの80%程度利用しています。
共通認識化しスコープを絞ることで、プロジェクトが頓挫せず誰にも使われない製品/体験になることを避けることができました。

熟練プロダクトマネージャーであれば、遠い昔の通過点かもしれません。
一方でtoBプロダクトで、顧客像が複数あり各セグメントで顧客要求が異なるプロダクトでは身近な問題ではないでしょうか？

何か１つでも参考になれば、幸いです。

これ以外のテーマでもnoteを書いていくので懲りずにお付き合いいただければ幸いです。

最後に宣伝。
試行錯誤しながら仕事の受発注という、大きな課題解決を一緒にしていくPdMを募集中です！

www.wantedly.com 未曾有のこんな時代だからこそ、日本の働き方を変えにいきませんか。PdM募集 by ランサーズ株式会社

ランサーズ株式会社

募集要項をみる

#プロダクトマネージャー #PdM #プロダクトマネジメント #アドベントカレンダー #プロダクトオーナー