見出し画像

【長文】わたしがプロダクト作りで大切にしていること

こんにちは、あたらしい旅行をデザインしたい令和トラベル篠塚です。先日元アナウンサーの大木さんがジョインしてくださり、大きな風を吹かせてくれました。とうとう私のTwitter役目も終わりました。これでSNSからは卒業することになりそうです・・・

https://twitter.com/Yuuki_Ohki/status/1486110544835022848


さて、本日のnoteは5年前くらい?に当時書いていたブログをふとひっくり返してみていたら、意外と価値観は変わっていないし、良いことがちょこちょこと書いてあったので転機しておくものです。一部表現の修正はしていますが、プロダクト開発に関わるPMやエンジニアの皆様などぜひご覧いただけたら嬉しい次第です。たまにこういうバックログも残してみようと思います。

では本題。

===
本日(※注意 2017年の記事です。笑)は、過去の日報とかで書き溜めてきたものをひっくり返しながら、「プロダクト作りで大切にしていること」をまとめておこう、と思い立ちました。なお、プロダクト企画の発想をどう持つかみたいな視点が多く、工程管理やマネジメント、エンジニアチームとのやり取りといった部分はあまり記載していません。
 
では早速、ここから7つのアイディアを紹介してみます。
結構長いのと、粒度バラバラですごめんなさい。


#1 ユーザー調査はほとんど意味がない

ちょっと大げさめに書いてますよ。笑

プロダクトオーナーのMissionを一行で表すとしたら、
「プロダクトを通じ、半歩先にあるユーザーの潜在課題を解決してあげること」だと思っています。マネジメントレイヤーの人ほど今日ではなく「半歩先」で、顕在課題ではなく「潜在課題」 という点が大きなポイントです。
 
スティーブ・ジョブズの例は大げさですが、機能についても言える話しです。「馬が移動の中心だった時代にユーザー調査をしても、「車」という案は出ずに速い馬を求めるだけである。」ということです。
 
現代でも同じで、ヤフオクユーザーに「便利な機能」を聞いたところで、
「メルカリをつくってほしい」という意見はまず100%出てこないのではないでしょうか。
 
これは「ユーザー調査を一切するな、意見は無視だ」なんて意味ではなく、
我々は常に、半歩先の潜在的課題を解決することが求められているという点が大切です。ユーザー調査ではあくまで現在ある顕在化している課題しか見えませんので、それの解像度を高めたかったり、ある仮説の補強をしたい場合にはとても便利です。仮説もなく闇雲に答え探しをするようなケースが多いのですが、それは全く意味がないですしお金が勿体ないです。なにより半歩先の潜在的な課題は、調査からはまずもって見えません。
 
ユーザー調査にはほとんど意味がなく、膨大なデータとにらめっこしながら、プロデューサーの知恵の絞り出しにこそ、時をかけ努力すべきでしょう。アイデアを出すことに困った時すぐに「ここはユーザー調査だ!」というのは、思考停止のサインかもしれません。 

#2 Whyから考える

このままなのですが、Whatから考えてしまうケースが意外とあります。
データ整理してみよ、ここA/Bテストしようよと言ってみる、この機能どう? 
とりあえずブレストしてみようか。 などなど。現場ではよく陥りがちな罠であるように思います。

また競合調査や似たサービスが提供している機能についても、そのまま自社に乗り換えるのは、極めて危険だったりします。たとえば「Airbnbではカスタマーに100%レビュー書かせているから、うちもそうしよう」といった安直なコピーペースト発想です。※2017年当時

彼らはCtoCプロダクトであり信頼こそすべて。その信頼を積み上げるためには100%レビューが絶対に必要(Why)だからそうしているわけで、単純にそれを通常のECなどでも実装するとただ単純に次回購入CVRが下がるだけだったりします。
 
時間を使うべきはWhyからであり、そうすれば自ずとWhatが大量に出てくるのでそこを誤解しないほうがよいものです。Whatという表層コピーだけでは、プロダクトは成長しません。あまりにも有名なSimon Sinek氏の動画は、インターネットサービスのプロダクト開発にも組み込めますので必見。

#3 直前の仕様変更は当たり前と、全員が許容すべき風土をもつ

あるある問題かと思いますが、仕様変更は100%起こり得るので許容が大切というお話しです。プロダクトチームでQAテスト中にUXエラー(notバグ)を見つけたりしたときに、「エンジニアもここまで頑張ってきてくれたからな・・・」と、遠慮し、UXが落ちるかもしれないのにそれをそのままアウトプットしてしまうことがあります。人間だもの。

これは優しいチーム想いの思考であり、時にそれはとても大切ではありますが、リリースをしてしまうというのは、100%絶対にダメです。ダメぜったい。どんなに大規模修正となっても、やり直すべきなのです。なんならリリースしない。
 
理由はシンプルです。ユーザーは、我々サイドのプロセスには一切の興味がないからです。直前に仕様変更しようがしまいがプロセスを知らないので、影響が一切ありません。彼らは世に出たアウトプットしかみることがありませんので、そこですべてを評価されます。

どれほど優れた設計もすべてのUXを再現することはできませんので、チーム全体で「どんな精緻な仕様・計画であっても、仕様変更は起こり得る。」と思っておくことが重要でしょう。また、その思考を持つことによって最後の最後にどんでん返しが起こらないようにプロセスにおいても入念なケアをするものですし、全員がOwenershipをもって業務に取り組む風土が醸成されていきます。

誤ったUXをリリースすることのほうが、数十倍も損失が大きい。 ということを、プロダクトチームもエンジニアも互いに理解し合うことが大切とも言えます。

1つのネガティブなレビューは、その裏に100倍以上の人がそう感じているもので、静かに去ってしまいますので、配慮はしつつも遠慮は不要、サンクコストは許容、失敗はウェルカム。いつでも巻き戻しましょう。
 

#4 引き算の意思決定が難しい

ボタンを1つふやすなら、ボタンを1つ引き算しなければなりません。
新機能を1つふやすなら、旧機能を1つ引き算しなければなりません。
こんな動き方を、基本的には意識したほうがよいでしょう。
 
サービス開発に重要なことはコア機能であり、エッジ(とがり)ですが、運営を続けていくうちにどんどん膨れ上がり、使いづらくなっていきます。難しいのは足し算よりも引き算であり、引き算の最終意思決定はオーナーにしかできません。

「新しい機能を追加しよう」は、必要だからこそ意思決定は簡単ですが、「この機能を削除しよう」は、必要だと思ってリリースしたものですし、愛着もあり、また、誰かしらは必ず使っているので、ユーザーデメリットがどうしても発生します。しかし、たとえ利用者がいようとも数ヶ月後、半年後のプロダクトビジョンから考えて妥当ならば、鋼の意思をもって引き算しなくてはなりません。

当社では毎年末に「大掃除プロジェクト」と称して一斉引き算をするようにしていますが、16年も大きなものだけでもこれら機能を削減しています(全て12月にさりげなく削除済、プロダクト以外の制度も対象)

・多言語ページ(利用度が低い5ヶ国語以上を削除)
・決済通貨の変更機能
・法人向け福利厚生サービス
・アンバサダー機能
・トラベルカルテ機能
 
引き算の意思決定こそ、プロダクトオーナーのセンスや判断力が問われるポイントです。 

#5 「プロデューサー病」に要注意

プロデューサー病とは、自身が一般ユーザーの数百倍頻度でサービスを見ているがためにかかるバイアスです。皆さまは、自分のサービスにアクセスしない日はないですよね。しかし、ユーザーの方々は(Reluxだと)1年に数回しか基本的にはアクセスをしません。
 
何が起こるかというと、全く本質的ではないムダなところを気にかけてしまったり、一般的には誰も気にかけないような、使われないところを改善してしまっていたり、また、使い慣れたごく一部の人しか使わないような機能開発を一生懸命に優先度highで対応したり、プロデューサー病にかかると、誤った意思決定を日常的に執行してしまうものです。 
 
ありきたりですが重要なことは、素直なユーザー目線であり、プロデューサー目線はいらないのです。毎日触っている時点で素直なユーザー目線からは離れてしまっているので、プロダクトマネージャーには「バイアスがある」という前提で取り組み、そしてその前提を超えて解決策を提起しなくてはなりません。

#6 結果指標よりプロセス指標

結果指標(多くのKPI)だけではなく、プロセス指標という考え方をもったほうがよいと常々感じております。
 
「KPIは何?」といえば二言目には「ここのPV数をこうやって増やし、CVRを改善しよう」という、誰でもできる因数分解の話に陥ってしまうことがあるものです。これは単なる結果指標であり、その手前のプロセス指標もあわせてみるべきであると感じています。
(→プロセス指標の多くは、OKRに適切な数値であることが多い)
 
その理由は、結果指標だけでは影響する改善が多すぎて、単にそこを追いかけるには不適だからです。「あれ、この日はなんでこんなに上がったんだ・・・?」などと、なりがちです。

PVを減らして濃くすれば簡単にCVRはあげられるし、
PVを思い切りあげることも簡単だからなのですね。(⇔CVRは下がる)
これでは数値改善しても意味がなにもないけれど、意外と普通に行われていますし、実に分かりやすい利益相反でしょう。

KPIのモニタリングは大事であるのでそれはそれでするとして、それよりも日々の改善活動は「CVRを操作している隠れ指標(=プロセス指標)」をこだわるとよいです。

たとえば、ありそうな適切な数値は、
・1UUあたりの滞在時間
・サイト内平均滞在ページ数
・サーバーレスポンス速度の改善  といったものですね。
 
これらは直接的にCVRにHitしない(ようにみえる)けれども、明らかに予約相関があるような数値がいくつも転がっています。これらをKRとして定め、「上がることが確かなる正義」な数値を探すべきなのですね。
参考:OKRとは
 
その改善ループをWeeklyでぐるぐるまわし、気がつくとCVRが改善していく、というのが美しいプロジェクト体制のあり方ではないでしょうか。 

#7. リーンx失敗を認める文化

また文化の話しなのですが、当社では「Fail Harder」というバリューを掲げています。※2017年:Relux時代の話し
参考:新コーポレートバリューへの移行

「激しく失敗しよう」という意味なんですが、2つの良い点があります。
1つは、個人がみんな挑戦し合う文化になることです。
もう1つは、他者が失敗を許容しあう文化になることです。
 
今なお、流行りものはどこの旅行代理店や宿泊予約サイトよりも速く着手し、それだけ失敗量も多いですが、成長し、結果的に芽が出てくれたものが大量にあります。失敗量と成長カーブはおよそ比例するので、リーンに挑戦し失敗を称え合う文化を、プロダクトオーナーは持っておいたほうが良いのではないかと、私は強く感じます。

失敗を恐れた打ち手は、たいていインパクトが何もありません。

「What would you do if you weren’t afraid?」
Link http://ifuwerentafraid.tumblr.com/

まとめ

他にもたくさんありますが、なんとなく重要だなと思っていることをだらだらと書き綴ってみました。めちゃくちゃ長くなってきたので、これにておしまい。
 
令和トラベルでもいつも半歩先の潜在課題解決を意識し、新しい価値提供をして参る所存です。そして、共感いただけるエンジニア、PM、マーケメンバーなど中心に大募集中です!

こっそりとあたらしいカルチャーデックも公開されました。とてもいい感じの大作なので、ぜひご覧ください👏


最後にいろいろなURLまとめ

せっかくなので、令和トラベル社のことがわかりやすいURLを最後にペタペタと張っておきます。よろしくお願いします。

採用サイト:https://www.reiwatravel.co.jp/recruit
おすすめ度:☆☆☆☆☆
カルチャーデックや、募集職種などまとめていますので是非ご覧ください!

NEWT紹介ページ:https://newt.net/hello
おすすめ度:☆☆☆☆☆
先行リリースの案内や、特別なキャンペーンなどをスタートしています。

Twitterアカウント:https://twitter.com/newt_travel
Instaアカウント:
https://instagram.com/newt.travel
YouTubeアカウント:
NEWT公式チャンネル
おすすめ度:☆☆☆☆
海外旅行の情報や、見ててワクワクするコンテンツを発信中です。

Bridgeさん記事:スマホで買える海外旅行D2C
Diamond Signalさん記事:
この60年で一番の参入チャンス
おすすめ度:☆☆☆☆
当社が実現したい世界観をとてもきれいにまとめてくださいました。

シノ社長のYouTubeチャンネル:こちら
おすすめ度:☆ x 10
2022年こそ風が吹くはずなので、よろしくお願いします。

この記事が気に入ったらサポートをしてみませんか?