プロダクト思考が足りないことで起きる「エンジニア・PM・顧客の不幸」　熱狂的に開発するために必要な“ビジネスと開発間の越境”

田代氏の自己紹介

田代大輔氏：私からは「誰を顧客として考えるのか　〜プロダクト思考を持ったチームビルディング〜」というテーマで話します。よろしくお願いします。

まず簡単に自己紹介をします。田代大輔と申します。株式会社Relicという会社で働いていて、現在BtoBtoCプロダクトのプロダクトマネージャーをしています。

職歴としては、新卒で不動産営業をしていて、3年半働いたのちエンジニアに転職しました。初めは受託開発でエンジニアとしてキャリアスタートをしました。現在は新規事業開発の伴走支援を、事業ドメインとする株式会社Relicにて、プロダクトマネージャーをしています。

福岡拠点のエンジニア、デザイナー、PM、プロジェクトマネージャー、プロダクトマネージャーの採用も推進しているので、個人的に話を聞きたい方がいれば、声をかけていただければと思います。

私ごとですが最近三女が生まれて、三姉妹の父となりました。

熱狂的にプロダクト開発をするために重要なこと

（スライドを示して）本日の目次はこちらです。

さっそくですが、私が定義するプロダクトマネージャーとは、プロダクトの成長に責任を持つ人、チームを巻き込んで熱狂的にプロダクト開発をできる人と定義しています。周りを巻き込みながらプロダクト開発を行う。つまり、チームに熱を与えられる人となります。

それはどういう人なのか、どのようにチームで熱狂的にプロダクト開発をするのか。

そのためには、プロダクト思考を持ったチームを作るというところが重要になってくるのではないかと、私は考えています。

「プロダクト思考」と「プロジェクト思考」

プロダクト思考と似た考え方で、プロジェクト思考というものがあります。（スライドを示して）この図を見たことがある人はけっこう多いんじゃないかなと思いますが、一つひとつ説明します。

プロジェクト思考はHow・Whenですね。期待を理解し、計画を立て、リソースを集め、その期待に応えるために行動を調整することです。「いつまでに」「誰がするのか」「似たようなやり方はないのか」「どのようにして実現するのか」を考える思考です。

続いてプロダクト思考です。こちらはWhy・Whatで、動機を理解し、解決策を考え、その効果をシミュレーションし、望んだ効果に至る道筋を選ぶことです。「なぜこれが重要なのか」「達成すべきゴールとは？」「目指す状態は？」「差別化は図れるのか」というところに重きを置いた思考となります。

プロダクト思考が足りないと起きる2つのこと

プロダクト思考が足りないと何が起こるのかというデメリットです。

顧客からの要望をそのまま実装してしまうというところで、始まりは一緒です。ですが、パターン1は本当に実現したかったこととズレていて、手戻りが発生してしまい、エンジニアが疲弊します。PMに対しても「なんでこれを開発したんですか？」というような声が挙がって、お互いに不幸になるというところです。お客さんも不幸になります。

パターン2も顧客からの要望をそのまま実装してしまいます。納品は完了して、運用を開始します。ただ、ふたを開けてみると、実装した機能がまったく使われていないというようなパターンです。これもよくある話かなというところで、誰もハッピーになりません。

チームでプロダクト思考を根付かせていくメリット

その解決のために、チームでプロダクト思考を根付かせていくことのメリットです。（スライドを示して）左から、開発のモチベーションが上がる（かも）というところですね。これは誰がどのように使っているのかがわかるので、フィードバックも得やすいし、開発者として顧客の喜ぶ姿なども見られて、モチベーションが上がるかもしれません。

真ん中は部署間、BizDev問わずチーム内での会話が活性化するというメリットがあるはずです。弊社の場合、プロダクトマネージャーの私や、CSを担当しているビジネス職が、顧客、事業者さまから課題を吸い上げて開発に落とし込むので、BizDev問わずチーム内での会話が活性化するのではないかというところです。

最後に、チーム一丸となってプロダクト開発に向き合えるので、チームとして一致団結できるのではないかというところがメリットとして挙げられます。

熱狂的にプロダクト開発をするために、プロダクト思考を持ったチームを作っていきましょうということです。

チームの現状と理想とのギャップ

とはいえ、私たちのチームもまだまだ成長途中です。いろいろな課題があったので、その課題を解消するためチームビルディングをあらためてしました。そちらについて話せればと思います。

まず現状と理想とのギャップを考えてみました。理想はプロダクト主導組織を作っていきたい。ただ現状はどうなのかというと、セールス主導組織でした。

例えば、お客さまから「この〇〇という機能を実装してくれれば契約してくれるよ」というような声が挙がって、そのまま実装してしまうことがけっこうありました。恥ずかしい話ですが、けっこうほかの企業さまでもあるのではないかと思います。

じゃあ、そのためにどう変化させていくべきなのかを考えた時に、コミュニケーションの中心に、自分、プロダクトマネージャーを置く必要があると考えました。

具体としての課題です。どう改善していくかというところも含めて、まず誰が顧客なのかをはっきりさせようということに取り組みました。

次に質問です。ビジネスサイドから開発側への質問がかなり無法地帯となっていて、Slackやバックログ上に散見されていたので、質問を定型化しようということを進めていきました。

最後に、とにかく顔を出して、コミュニケーションの中心に自分がいる状態を作るように心がけました。

誰が顧客なのかをはっきりさせる

まず誰が顧客なのかというところで、私たちが手がけるプロダクトはBtoBtoCのプロダクトです。ただ、私たちが直接届けるのはtoB、法人さま、事業者さまになります。

そもそも僕がジョインする前は、開発目標がtoC向けになっていて、どちらかというとtoBに向けた開発目標がなかったので、いったい誰が顧客なのかがすごくふわっとした状態でした。

実際にユーザーヒアリングができる対象も事業者さまで、投資家さまはすごく大勢いるのですが、特定の人にヒアリングができていない状態だったので、誰が顧客なのかをはっきりさせていこうという動きを取りました。

顧客を明確にチームに浸透させるメリットは、誰に向けての機能開発なのかがわかり、なぜこの機能を開発するのかがクリアになることです。

無法地帯になっていた質問を整理する

次に、先ほどの図でいう質問です。質問が無法地帯となっていたという課題については、質問でナレッジを貯めていきましょうということで。（それまでは）質問がテンプレート化されていなかったので、回答者がすごく疲弊しました。（回答者とは）ここでいう開発者なのですが、開発サイドがすごく疲弊していました。

いつまでに回答すべきか迷っていた、優先度もわからないという状態をとりあえず脱却したいということで、いったん質問をテンプレート化しました。質問の回答がナレッジとなって仕様把握にも役立つので、新しく入った人も質問の貯まっている箇所を見てもらえれば、どういうシステム、サービスなのかが一目でわかる（ようになる）だろうというところを図っていきました。

同じ質問が頻繁に飛び交わなくなるメリットもあります。また、優先度や回答期限を明確にすることで、重要度・緊急度がひと目でわかるというような動きを取っていきました。