プロダクトの難しさ
プロダクトを作るのは本当に難しい。ユーザーが抱える問題を解決しようとしているのだから当然だ。ひょっとしたらあなたは人類史で初めてその問題に取り組んでいるかもしれない。プログラミングも難しいが、「難しさ」の種類が違うように思う。プログラミングの難しさはソースコードを介して他者と共有可能であり、ソースコードは機械語を解するコンピュータとエンジニア向けに書かれたものなのであいまいさが少ない。一方でプロダクトが解こうとする問題はあいまいで多岐にわたる。「タクシーを見つけるのが難しい」から「一緒にお昼ごはんを食べる仲間がいない」まで、1つとして同じものはない。同じ問題を解いている人に出会えることは少ないだろう。
プログラミングにはデザインパターンというものがある。「この形はどこかで見たことあるぞ」「この種のコードはObserverパターンを使えばきれいに依存を分離できる」といったことを体験したことがあるだろう。デザインパターンをうまく使えばクオリティの高いコードが実現できる。プロダクトに関するパターンであればDDD（Domain-Driven Design、ドメイン駆動設計）で紹介されているものが有名だが、これらのパターンは抽象的すぎて適用するのが難しいことも多い。
そこで今回は、筆者が経験から学んだ5つの「プロダクトアンチパターン」を紹介しようと思う。アンチパターンとはやってはいけないパターンのことだ。いくつかは読者のみなさんも経験済みかもしれない。
A/B/C/D/E/F/G/Hテスト問題
ある日のこと、あなたはプロダクトマネージャー、デザイナーと新機能へのナビゲーションについて議論をしている。プロダクトマネージャーはこう切り出す。「新機能に行くためのナビゲーションだけどさ。検索結果、写真ビュー、プッシュ通知、アプリ内通知、タブ、お知らせウィンドウ、ハンバーガーメニューのどれからも行けるようにしよう。すべてA/Bテストでやってみてメトリクスの良かったものを採用しよう」。
さて何が問題だろうか。これは、エンジニアリングとプロダクトのそれぞれに問題がある。
エンジニアリングの問題は理解しやすい。実装コストの問題だ。A/Bテストフレームワークはいくつかのパターンを気軽に試すことを目的に作られているが、そのコストはゼロではない。試すパターンの数に比例してコストは高くなる。次のようなエンジニアリングコストが発生することにプロダクトマネジャーが気付いていない可能性がある。リストの後半に行くほど見えづらいコストだ。
- 各ナビゲーションを実装するコスト
- 各ナビゲーションをテストするコスト
- 各ナビゲーションの成績を分析してユーザーの振る舞いを理解するコスト
- テスト後のクリーンアップのコスト
- テストのためにアプリのコードが複雑になり、ほかの開発に影響が出るコスト
- 別の機能で走っているA/Bテストと競合するコスト
最後のものはわかりづらいかもしれないので例を挙げよう。あなたが「クイック写真投稿機能」へのナビゲーションとしてタブの追加を考えているとしよう。一方で広告エンジニアリングチームが「広告パフォーマンスタブ」ナビゲーションを追加してテストしている。ここで競合が発生する。次のことを考えなければいけない。
- ユーザーには2つのタブを表示してよいのだろうか。表示するならタブの順序が成績に影響しないだろうか
- どちらかのタブしか表示してはいけないのであれば、どちらが優先されるべきだろうか
- 前者のA/Bテストが成功に終わり、本番反映された場合どうしたらよいだろうか。もう一方のA/Bテストをやりなおすべきだろうか
- 「クイック写真投稿タブ」を英語設定のユーザーのみに表示したい場合はどうすればよいだろうか
上記をすべて考慮したテストをしなければいけない。
では、プロダクトの問題はわかるだろうか。なぜ8パターン（A/B/C/D/E/F/G/Hテスト）もテストする必要があるのだろう。テストしている本人たちがどれが正しいかさっぱりわかっていないからだ。ユーザーの問題を解決する方法がいくつかあるのだが、テスト前に仮説として優劣を付けていないのが問題である。そしてパターンが多すぎる。本来あるべき姿は「私はこのナビゲーション（A）がユーザーの問題を解決すると信じている。だが実際にどうかはわからないから世に問うてみよう。議論の中でナビゲーション（B）も次点として評判が良かったので試そう。でも私は（A）に賭ける」である。このように筆者はプロダクトマネージャーの信念が大事であると考える。「自信がないから全部試そう」はだめなのだ。
「それ設定で」問題
プロダクトマネージャーがやってきて、「写真一覧ビューでパズルゲームを遊べるようにしたいんだ。何人かのユーザーから要望が上がっている。それにエンゲージメントも上がるはずだ」と言う。あなたは「えっと、良いアイデアかもしれませんね。ただユーザー全員が欲しい機能ではないと思うんです。そもそもそこはユーザーが写真を見にくる場所です。なぜゲームを置くのですか」と反論するかもしれない。するとプロダクトマネージャーは「うーん、たしかになあ。じゃあ、邪魔だと思う人は設定でパズルゲームを消せるようにしよう。そうすればみんなハッピーだ」と言ったとしよう。
何が問題だろうか。これも、信念がないのが問題である。そもそもプロダクトはすべての人に受け入れられるようには作れない。もちろんそうなるように努力すべきだが、不可能だ。人それぞれ好みがあるし、使う頻度や使い方もさまざまだ。そういうことを踏まえたうえでいわゆる「ペルソナ」（注1）を定義してプロダクトを作っていく。どんなにがんばっても誰かには文句を言われたり、いらない機能だと言われるものだ。そのような中で何かを作っていくときには、「自分が何を大事と思っているか」すなわち信念を持つことが肝要である。「ユーザーが必要と思うかわからない」から設定にするというのは、問題解決をユーザーに投げてしまっている。ユーザーは本来の問題に集中できなくなってしまう。誰も触ることのない設定だらけのアプリをあなたも一度は見たことがあるだろう。
パワーユーザー問題
これはエンジニアにありがちな問題だ。プロダクトミーティングで写真投稿機能の改善アイデアを出し合っているとしよう。するとあるエンジニアが「1日に何回も写真を投稿するんだけど、毎回写真を切り取って特定のフィルタで加工しているのが面倒。簡単なスクリプトを定義できるようにするのはどうだろう」と提案する。
Lazy（怠惰）なのはエンジニアの美徳ですばらしいが、ここではやりすぎである。よく考えてみよう。ターゲットユーザーは本当にそんなことをしているだろうか。そんなことができるだろうか。エンジニアはたいていの場合、どのアプリでもパワーユーザーだ。アプリのすべての機能を知りつくしているし、頻繁に使う。それは必ずしもターゲットユーザーの振る舞いとは一致しない。アイデアを
出すときには「自分が欲しいか」ではなくて「ユーザーが欲しいか」を常に意識しよう。筆者がよく利用する指標はODD（OKAN Driven Development、オカン駆動型開発）である。自分の母親が使いたいと思うだろうか。その機能を使いこなせるだろうか。お友達にその機能をお勧めするだろうか。こう考えると、パワーユーザー問題から抜け出しやすい。
サイレントマジョリティ問題
これはわかりやすいと思う。いわゆる「声の大きなユーザー」の声に耳を傾け過ぎてしまうパターンのことだ。新しい機能を追加したら「やめてほしい」と抗議のメールがたくさん届き、慌ててしまう。そしてすぐに機能を取り下げたり、設定で消せるようにしたりする。
そうなるまえに少し落ち着こう。多くのユーザーは言葉に出して要望を出したり不満を表明したりはしない。好きになれば使い続ける。嫌いになれば使うのをやめる。わざわざ「これ最高！」とか「この新機能が邪魔なので使いません」とは言わないのだ。ほとんどのユーザーは何も言わない。
では、ユーザーがどう思っているかを知るにはどうしたらよいだろう。データを見るのはどうだろうか。新機能はどれくらい使われているのか。ほかの機能の使われる割合に影響はないのか。ユーザーが1日にそのアプリを使う時間は変わっただろうか。こういったデータを見てみよう。大きな声を出す人に惑わされてはいけない。
KPI問題
最近ではKPI（Key Performance Indicator、重要業績評価指標）を各組織ごとに振り分けて、あなたのチームが何らかの数値目標を持っていることも多いと思う。業績の達成度を定量的に知ることはとても良いことだ。一方で行き過ぎるのもよくない。プロダクトマネージャーとあなたのチームがMAU（Monthly Active Users）の数値目標を持っているとしよう。するとプロダクトマネージャーはユーザーにアプリを開いてほしいので、プッシュ通知キャンペーンをしようと言い出す。たとえば「夏の海の写真を投稿しよう！」など。
何が問題だろうか。それは出発点である。ユーザーに価値を提供したいというところからではなく、MAUを増やしたいというところから始まっている。そのプッシュ通知を受け取ったユーザーが、そもそもそれを必要としていたか。アプリが提供する価値の中でどういうユーザーストーリーなのか。こういったことがすっぽり抜け落ちてしまうのだ。そこに本当の人間、ユーザーがいるのだ。プッシュ通知を受け取ったユーザーは、限りある時間を使ってアプリを開いているのだ。開いてみてがっかりしたら二度と使ってくれないかもしれない。短期的な数値目標も大事だが、「なぜこのアプリを作っているのだろう」と常に原点を意識するようにしよう。
まとめ
紹介したアンチパターンは筆者が実際に経験してきたものばかりだ。アンチパターンを知れば、より本質に集中できるようになる。ほかにもアンチパターンをお持ちの方がいれば、ぜひ筆者のTwitterアカウント@higeponに共有してほしい。
- 特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現！
- 特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう
- 特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、NFT
