分プロダクトの難しさプロダクトを作るのは本当に難しい。ユーザーが抱える問題を解決しようとしているのだから当然だ。したらあなたは人類史で初めてその問題に取り組んでいるかもしれない。プログラミングも難しいが,「難しさ」の種類が違うように思う。プログラミングの難しさはソースコードを介して他者と共有可能であり,ソースコードは機械語を解するコンピュータとエンジニア向けに書かれたものなのであいまいさが少ない。一方でプロダクトが解こうとする問題はあいまいで多岐にわたる。「タクシーを見つけるのが難しい」から「一緒にお昼ごはんを食べる仲間がいない」まで,1つとして同じものはない。同じ問題を解いている人に出会えることは少ないだろう。プログラミングにはデザインパターンというものがある。「この形はどこかで見たことあるぞ」「この種のコードはObserverパターンを使えばきれいに依存を分離できる」といったことを体験したことがあるだろう。デザインパターンをうまく使えばクオリティの高いコードが実現できる。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)代表的なターゲットユーザー。パワーユーザー問題これはエンジニアにありがちな問題だ。プロダクトミーティングで写真投稿機能の改善アイデアを出し合っているとしよう。するとあるエンジニアが「1日に何回も写真を投稿するんだけど,毎回写真を切り取って特定のフィルタで加工しているのが面倒。簡単なスクリプトを定義できるようにするのはどうだろう」と提案する。Lazy(怠惰)なのはエンジニアの美徳ですばらしいが,ここではやりすぎである。ターゲットユーザーは本当にそんなことをしているだろうか。そんなことができるだろうか。エンジニアはたいていの場合,どのアプリでもパワーユーザーだ。アプリのすべての機能を知りつくしているし,頻繁に使う。それは必ずしもターゲットユーザーの振る舞いとは一致しない。アイデアを出すときには「自分が欲しいか」ではなくて「ユーザーが欲しいか」を常に意識しよう。Development,オカン駆動型開発)である。自分の母親が使いたいと思うだろうか。その機能を使いこなせるだろうか。お友達にその機能をお勧めするだろうか。考えると,パワーユーザー問題から抜け出しやすい。サイレントマジョリティ問題これはわかりやすいと思う。いわゆる「声の大きなユーザー」の声に耳を傾け過ぎてしまうパターンのことだ。新しい機能を追加したら「やめてほしい」と抗議のメールがたくさん届き,慌ててしまう。機能を取り下げたり,設定で消せるようにしたりする。なるまえに少し落ち着こう。多くのユーザーは言葉に出して要望を出したり不満を表明したりはしない。好きになれば使い続ける。嫌いになれば使うのをやめる。「これ最高!」とか「この新機能が邪魔なので使いません」とは言わないのだ。ほとんどのユーザーは何も言わない。ユーザーがどう思っているかを知るにはどうしたらよいだろう。データを見るのはどうだろうか。新機能はどれくらい使われているのか。ほかの機能の使われる割合に影響はないのか。ユーザーが1日にそのアプリを使う時間は変わっただろうか。いったデータを見てみよう。大きな声を出す人に惑わされてはいけない。Indicator,重要業績評価指標)を各組織ごとに振り分けて,あなたのチームが何らかの数値目標を持っていることも多いと思う。業績の達成度を定量的に知ることはとても良いことだ。一方で行き過ぎるのもよくない。Users)の数値目標を持っているとしよう。するとプロダクトマネージャーはユーザーにアプリを開いてほしいので,プッシュ通知キャンペーンをしようと言い出す。「夏の海の写真を投稿しよう!」など。