この記事の要約
- プロダクトの価値を構成する「当たり前品質」と「魅力品質」の役割と関係性を、「狩野モデル」を基に整理
- 成功するプロダクトは「たった一つの魅力品質」とその魅力を最大化する「必要最小限の当たり前品質」で構成されている
- 「当たり前品質を完璧に作りきる」という発想の危険性を明らかにし、ユーザーの声を聞きながら品質を「育てていく」
「当たり前品質」と「魅力品質」
まず、言葉を揃えましょう。プロダクトがユーザーに提供する品質は、いくつかに分けられていて、これは1980年代に東京理科大学の狩野紀昭教授が提唱した「狩野モデル（Kano Model）」という品質管理の理論に基づいています。
当たり前品質（Must-be Quality）
これは、「あって当たり前、ないとユーザーが不満を感じる品質」のこと。ホテルの部屋に清潔なベッドとシャワーがあるようなものです。それらが完璧でも「このホテル最高！」とはなりませんが、もしベッドが汚れていたら「二度と泊まるか」と強い不満を抱きますよね。
プロダクトにおける「当たり前品質」とは、
- ログイン・ログアウトができる
- 入力したデータがきちんと保存される
- ページの表示速度が遅すぎない
- 基本的な操作が直感的に行える
といった、いわゆる「王道機能」や基本的なユーザビリティを指します。これらはプロダクトの信頼の土台であり、これがなければユーザーは安心してプロダクトを使い続けることすらできません。
魅力品質（Attractive Quality）
一方、こちらがプロダクトの成長を牽引するエンジンです。魅力品質は、「なくても不満はないが、あるとユーザーが熱狂し、満足度が飛躍的に高まる品質」を指します。
先ほどのホテルの例で言えば、期待していなかったのに部屋にウェルカムドリンクと手書きのメッセージが置いてあった、といった体験です。なくても文句は言いませんが、あれば「お、このホテルやるな！」と感動し、誰かに話したくなる。これが魅力品質です。
プロダクトにおける「魅力品質」とは、
- ユーザーが抱える、まだ誰も気づいていない本質的な課題を、驚くような方法で解決する機能
- 圧倒的に使い心地が良く、触っているだけで楽しくなるUI/UX
- これまで複雑だった作業を、ワンクリックで終わらせてしまうような体験
などを指します。これが、ユーザーが競合ではなくあなたのプロダクトを”指名買い”する決定的な理由になります。
重要なのは、この二つの関係性。「魅力品質という名のエンジンを輝かせるために、当たり前品質という名の基盤が存在する」。この関係を理解することが、全ての始まりです。
たった一つの魅力品質から始める
さて、ここからが本題です。リソースが限られる中で、どうすれば選ばれるプロダクトを創れるのか。その答えは、「最初に、突き抜けた魅力品質を“たった一つ”だけ定義し、そこに全てを賭ける」という原則にあります。
なぜ複数ではダメで、たった一つなのでしょうか。それには3つの明確な理由があります。
- リソースの超集中
新しいプロダクトや機能が成功するかは、誰にも分かりません。不確実性が高いからこそ、なけなしのエンジニアリングリソースやマーケティング予算を分散させるのは悪手。たった一点に集中投下することで、その魅力品質が本当にユーザーに刺さるのかを、最速かつ最高の解像度で検証できます。 - メッセージの単純化
「このプロダクトは、〇〇も△△も□□もできます！」とアピールされても、ユーザーの記憶には残りません。それよりも「このプロダクトは、あなたの面倒な〇〇を、ワンクリックで解決します」という一つの強力なメッセージの方が、遥かに鋭く心に突き刺さります。どのみち1つしか言えないんです。 - 最速の学習サイクル
検証すべき「独自の価値」が一つに定まっていれば、ユーザーインタビューやデータ分析で見るべきポイントも明確になります。成功・失敗の要因が特定しやすく、次のアクションに繋がる「学び」のサイクルを高速で回すことができるのです。
この好例が、初期のDropboxです。
今でこそ多機能なクラウドストレージサービスですが、彼らが最初に提供した価値はただ一つ、「特定のフォルダに入れたファイルを、複数デバイス間で自動的に同期する」というものでした。それだけです。当時はまだFTPソフトでファイルをアップロードするのが主流だった時代。この「魔法のような」同期体験こそが、彼らの「たった一つの魅力品質」でした。
初期のDropboxには、写真のプレビュー機能も、ドキュメントの共同編集機能も、気の利いた共有設定もありませんでした。しかし、たった一つの魅力品質が圧倒的だったからこそ、アーリーアダプターは熱狂し、口コミで広がっていったのです。
あなたのプロダクトにおける「Dropboxの自動同期フォルダ」は何でしょうか？それを考えることが、戦略の第一歩です。
「当たり前品質を“作りきる”」という誤解
「なるほど、まず魅力品質を一つ決めるのは分かった。じゃあ次に、それを活かすために当たり前の機能を全部しっかり作ればいいんだな！」
その考えは半分正解で、半分は危険な罠に足を踏み入れています。
ここで言う「当たり前品質を作りきる」という言葉の解釈が、プロジェクトの成否を分けるのです。もし、これを「考えうる限りの王道機能を完璧に実装する」という意味で捉えてしまうと、プロダクトはリリースされる前にその命運が尽きてしまいます。
なぜなら、完璧な当たり前品質を目指すことには、致命的なリスクが2つあるからです。
- リスク1：過剰品質とリソースの枯渇
- 「ユーザーなら、きっとこういう機能も必要だろう」
「競合にはあるから、うちにもないと不安だ」…。
こうした善意の推測が、過剰な機能開発に繋がります。しかし、その機能は本当に「たった一つの魅力品質」を体験する上で不可欠でしょうか？多くの場合、答えはNOです。結果として、時間と開発費という最も貴重なリソースを、実は不要だった機能のために浪費してしまいます。 - リスク2：市場投入の致命的な遅延
- 完璧な土台を築くのには時間がかかります。その間に、市場の状況は変わり、競合は先に行き、そして何より、あなたの「魅力品質」が本当にユーザーに求められているのかを確かめる機会を失います。数ヶ月、あるいは一年かけて完璧なプロダクトを作ってリリースしたら、誰にも見向きもされなかった…。これほど悲しいことはありません。
では、どうすればいいのか？
「独自品質の魅力を損なわない、必要最小限の当たり前品質」を実現することが必要です。「ミニマム・バイアブル・ファウンデーション（Minimum Viable Foundation）」とも呼ぶべきこのラインが、魅力品質という名の宝石を置くための、最小限で最低限の「台座」を作る。それが私たちのPdMの力の見せ所です。
「必要最小限の当たり前品質」を特定する3つのステップ
「理屈は分かったけど、じゃあ具体的にどうやってその“必要最小限”を見極めるんだ？」という話に入っていきましょう。具体的な3つのステップをご紹介します。
Step 1: 「魅力品質の体験シナリオ」を一行で描く
まず、あなたのプロダクトが提供する「たった一つの魅力品質」を、ユーザーが体験するまでの最もシンプルなシナリオとして書き出します。ポイントは、ユーザーの感情の動きも含めて具体的に描写すること。
例：AI冷蔵庫アプリの場合
- 仕事で疲れて帰宅したユーザーが、冷蔵庫を開けてスマホで写真を撮ると（アクション）、
- アプリが『豚肉とピーマンで、10分でできる中華炒めはいかがですか？』と提案してくれ（魅力品質の体験）、
- 『お、それなら作れそう！』と夕食作りの憂鬱から解放される（感情の変化）」
Step 2: シナリオ上の「絶対的な障害物」を特定する
次に、先ほど描いたシナリオをユーザーが辿る上で、「これがないと絶対に先に進めない」「これがないと不快すぎてアプリを閉じてしまう」という“ブロッカー”となる要素だけを洗い出します。これが「必要最小限の当たり前品質」の候補です。
例：AI冷蔵庫アプリの場合の当たり前品質
- 写真をアップロードする機能（ないと始まらない）
- AIが解析してレシピを1つ表示する機能（魅力品質のコア）
- レシピの材料と手順が見られる画面（ないと作れない）
- アプリがクラッシュしない、遅すぎない安定性（不快で離脱する）
Step 3: 「障害物」以外を“作らないリスト”に入れる勇気
最後が最も重要です。Step 2でリストアップされなかった要素、つまり「あったら便利だけど、なくてもシナリオは完結する」要素を、意図的に「作らないリスト」に入れます。これには勇気がいりますが、この意思決定こそがプロダクトの成功確率を高めます。
例：AI冷蔵庫アプリの「作らないリスト（v1）」
- レシピのお気に入り保存機能： まずは「作る」体験が重要。保存は後からでもいい。
- アレルギー食材の登録機能： あれば親切だが、最初の体験には必須ではない。
- 作った料理の記録機能： 同上。
- 買い物リスト作成機能： シナリオの範囲外。
どうでしょうか。こうして見ると、最初に作るべき機能は驚くほど少ないことに気づくはずです。これが、リソースを集中させ、最速で価値を検証するための具体的な方法論です。
リリース後に、当たり前品質を“育てていく”
さて、こうして「一つの魅力品質」と「最小限の当たり前品質」で構成されたプロダクトを無事にリリースできました。しかし、PdMの仕事はむしろここからが本番です。
「作りきる」という発想を捨てた私たちは、ここから「育てる」というフェーズに入ります。
リリース後、あなたの元には様々なフィードバックが届くでしょう。
- 「AIの提案は最高！でも、作ったレシピを保存できないのは不便すぎる！」
- 「このアプリ神！ところで、アレルギーがあるので使えない食材を除外したい…」
- 「ログインできないと、機種変更した時にデータが消えそうで怖い」
これらの声こそ、次に追加すべき「当たり前品質」のヒントが詰まった宝の山です。初期のユーザーは、あなたの「魅力品質」に惹かれて使い始めてくれた人たち。彼らが次に不満を感じる点こそが、プロダクトがより多くの人に受け入れられるために必要な、次の「当たり前品質」なのです。
このプロセスは、まるで「最初に超絶魅力的な一軒家を建てて人を呼び込み、住み始めた人の声を聞きながら、家の周りの道を舗装したり、庭に花を植えたりしていく」ようなものです。最初から完璧な街を作ろうとするのではなく、中心となる価値から育てていく。この動的なアプローチこそが、変化の速い市場で生き残るための鍵となります。
ユーザーの声に耳を傾け、どの「当たり前品質の欠如」が彼らの体験を最も損なっているかを見極める。そのためには、地道なユーザーインタビューやデータ分析が不可欠。
バランスは「静的な比率」ではなく「動的な優先順位」
ここまで、「当たり前品質」と「魅力品質」のバランスについてお話ししてきました。
結論として、この「バランス」とは、50:50のような静的なリソース配分のことではありません。それは、プロダクトのフェーズとユーザーの声に応じて、
「今、どちらに投資することが、プロダクト全体の価値を最も高めるか？」
を、常に問い続ける動的なプロセスそのものです。
- 最初に「たった一つの魅力品質」に賭けて針を振り切り、ユーザーを掴む
- → ex）魅力品質：当たり前品質：30：70
- 次に、彼らの不満を解消する「当たり前品質」で土台を固める
- → ex）魅力品質：当たり前品質：10：90
- そしてまた、新たな魅力品質を探求する旅に出る…。
- → ex） 魅力品質：当たり前品質：30：70
この問いを常に持ち続け、戦略的に優先順位を判断し続けること。それこそが、単なる機能開発の進行役で終わらない、真のプロダクトマネージャーの仕事なのだと僕は信じています。
今日から実践できるアクション
この記事を読んで「なるほど」で終わらせないために、ぜひ今日の業務で一つだけ試してみてください。
今日のワーク
あなたの担当プロダクトの「たった一つの魅力品質」を、30文字以内で言語化してみてください。そして、その魅力を体験する上で「絶対に不可欠な当たり前品質」は何かを3つだけ書き出してみましょう。
これをチームで議論するだけでも、プロダクトの現状と向かうべき方向性についての解像度が、きっと格段に上がるはずです。
Q&A
- Q1. ステークホルダー（経営層や営業）が、競合にある「当たり前品質」をすべて実装するように求めてきます。どう説得すれば良いですか？
- A1. 非常に難しい問題ですが、「リスク」と「機会」の言葉で語るのが有効です。全ての当たり前品質を実装するのは「機会損失のリスク（市場投入が遅れ、本当に価値ある機能の検証ができない）」を伴うことを説明します。その上で、「まず最小限の機能で“機会”を掴み（魅力品質を検証し）、その後で段階的に“リスク”を埋めていく（不足している当たり前品質を追加する）方が、事業として成功確率が高い」という戦略的ストーリーを提示しましょう。
- Q2. どの品質が「魅力品質」で、どれが「当たり前品質」なのか、チーム内で意見が分かれます。どう判断すれば良いですか？
- A2. チーム内で議論しても答えは出ません。答えは常にユーザーが持っています。こちらの記事が参考になるかもしれません。
- Q3. もし、最初に賭けた「魅力品質」がユーザーに全く刺さらなかった場合はどうすれば良いですか？
- A3. それこそが、このアプローチの最大のメリットです。「最小限の当たり前品質」しか作っていないため、投資の損失は最小限に抑えられています。もし刺さらなかった場合、それは「この魅力品質は市場に求められていない」という非常に価値のある学びを得られたということです。そこから、ピボット（方向転換）して次の「魅力品質」の仮説検証に素早く移ることができます。完璧なプロダクトを作ってから失敗するのに比べれば、遥かに健全な状態と言えます。
参考情報
- Kano, N., Seraku, N., Takahashi, F., & Tsuji, S. (1984). Attractive quality and must-be quality. The Journal of the Japanese Society for Quality Control, 14(2), 147-156.
- 『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』マーティ・ケーガン (著), 佐藤 伸哉 (監訳, 翻訳), 関 満徳 (監訳)
コメント