製品要件分析の作業は、製品の一連の作業の始まりであり、良いスタートは成功の半分と言われています。この作業を良いスタートで進めるために、筆者は本文で製品要件分析プロセスでよくある 5 つの典型的な落とし穴をまとめ、自身の経験と教訓に基づいていくつかの具体的なアドバイスを提供しています。
要件分析は、製品マネージャーの日常業務の一部です。プロトタイプ設計の準備作業として、要件分析は後続の製品関連作業の方向と範囲を大きく左右するため、その重要性は言うまでもありません。したがって、優れた製品マネージャーは、要件分析に対して一定の方法と戦略を持つべきです。
今日、私は自身の過去の要件分析の経験と観察した状況に基づいて、要件分析作業でよくある 5 つの落とし穴を共有します。私自身やこの記事を読んでいるあなたにとっても、それは一種の警告と鞭撻となるでしょう。
1. 自分自身をユーザーとして扱う#
これは、製品マネージャーが最も陥りやすい落とし穴です。
要件の観点から見ると、製品マネージャーはユーザーの要求の代弁者です。この時、製品マネージャーには実際に 2 つの身分が統合されています。
- 要求を出すユーザー
- 要求を整理する自分自身
一般的に、要件分析作業の開始段階では、製品マネージャーは一定の冷静さを保ち、要求の出所を比較的合理的に区別することができます。製品の要件分析作業が進むにつれて、ユーザー調査や競合分析、および関連する要件分析など、製品マネージャーはユーザーの要求にますます精通していくことになります。製品マネージャーは要件分析の面で自信を持つようになります。
しかし、製品調査に長い時間を費やしたことによる達成感に浸っている間に、製品マネージャーは自然と、これらの 2 つの身分を混同し、自分自身を典型的なユーザーとして扱い始め、自分自身のニーズに合わせたがユーザーのニーズではない要件を提案し始め、後期にはユーザー調査を無視し、自分の好みで要件の妥当性を判断し始めることがあります。
このような状況では、製品マネージャーは一般的に頑固で自己中心的になり、自分が代わりにやっているとは思わない傾向があり、結果として製品の後続作業に不要な偏差が生じます。
これに対して、私は 2 つの戦略を提案します：
戦略 1：ユーザーの一員として組み込まれ、定期的かつリズムを持って製品要件の整理結果をユーザーとコミュニケーションする#
私の経験では、少なくとも 2 回のコミュニケーションが必要です。1 回目は製品要件のフレームワーク整理が完了した時で、このコミュニケーションでは方向の偏差や誤りをフィルタリングすることができます。2 回目は製品要件の詳細な整理が完了した時で、このフィードバックでは詳細な偏差やミスをフィルタリングすることができます。
このような 2 回のコミュニケーションとフィードバックを経て、基本的には低レベルまたは致命的な偏差は発生しないため、この落とし穴を効果的に回避することができます。同時に、これらの 2 回のフィードバックで発見されたエラーの状況を記録し、なぜその時に間違いを犯したのかを反省する時間を見つけることができます。
戦略 2：自分自身とユーザーの役割関係を平等にし、自分を神として扱わない#
製品は最終的にユーザーが使用するものであり、機能が必要かどうか、要求の強度が低いか高いかは、製品マネージャーが決めるのではなく、目標ユーザーが決めるのです。
製品マネージャーは自分の心構えを正しく持ち、自分の責任は要件を定めることではなく、ユーザーの要求を発見し、自身の専門能力と知識を使って発見したユーザーの要求を規範的で完璧な要件記述文書に変えることだと覚えておくべきです。
ユーザーの声を尊重することが重要です。なぜなら、あなたが望むのは製品の成功であり、あなたの要求の成功ではないからです。
あなたが自分が正しいと思う要求に固執するとき、龍兄のこの言葉を思い出してください。
2. ユーザーに惑わされる#
製品マネージャーの要件分析の道は、一つの落とし穴から次の落とし穴へと続きます。落とし穴が尽きることはありません。
最初の落とし穴をうまく乗り越えた製品マネージャーたちは、次にユーザーに惑わされるという 2 番目の落とし穴に直面します。
製品の要件は最終的にはユーザーからのものですが、優れた製品マネージャーは、ユーザーが専門家ではないことを理解しているはずです。彼らはしばしば短期的な視野に立ち、表面的な要求（見かけ上の要求であり、真の要求ではない）を提供する傾向があります。
もしもあなたが十分に注意深く敏感でなければ、ユーザーに惑わされることは非常に簡単です。たとえそれが要求を出したユーザーの意図ではなかったとしても。
この落とし穴に対して、龍兄はあなたに一つの秘策を提供します：なぜか尋ねてみてください。
ユーザーが短期的な視野を持つ理由は理由があるのです。彼らは問題を解決したいだけであり、自分の知識範囲内で合理的な解決策を見つけようとしています。もしもあなたがこの解決策を要件として受け入れるならば、それはあなたを惑わすことになり、時にはかなりの程度で。
上記の分析に基づいて、あなたは「なぜ」（なぜこの機能が必要なのか？なぜそれをするのか？）と尋ねることで、ユーザーの表面的な要求の背後にある真の要求を見つけることができます。真の要求が見つかれば、惑わされることは自然に避けられるでしょう。
例を挙げましょう（製品マネージャーならば耳にタコができる例ですので、龍兄は要点だけを提供し、詳細は度娘や人肉検索でお願いします）：
製品マネージャー（フォード）：あなたはまだ何か欲しいですか？
ユーザー：もっと速い馬が欲しいです。
製品マネージャー（フォード）：なぜもっと速い馬が欲しいのですか？
ユーザー：時間を節約するためにもう少し速く移動したいです。
製品マネージャー（フォード）：私は自動車というものを作りました、馬よりもずっと速いですよ。
この落とし穴は、製品マネージャーの専門レベルを試す場所であり、怠けることはできません。心を込めて、ユーザーの表面的な要求から真の要求を引き出す必要があります。
3. 一つのことを一度にやろうとする#
製品マネージャーはユーザーと打ち解け、表面的な要求から真の要求を見抜くことができるようになりました。この時、3 番目の落とし穴がやってきます。一つのことを一度にやろうとするという落とし穴です。
この時、製品マネージャーは多くの要求を集め、それぞれが本物の要求であり、重要であり、欠かせないと見えるが、これらの要求が実際には多すぎるように感じ、少し頭が痛くなるかもしれません。
この現象の原因は、ほとんどの場合、要求を分類し、優先順位を付けていないことです。この落とし穴について、龍兄は次のアドバイスを提供します：
KANO モデルを使用する（詳細は度娘や人肉検索でお願いします）。
KANO モデルは要求を以下の 3 つのカテゴリに分類します：
- ** 基本要求：** 龍兄はこれを基礎要件と呼んでいます。このタイプの要求がなければ、製品を作る必要はありません。たとえば、音楽プレーヤーが mp3 を再生できないというのは信じられません。
- ** 期待要求：** 基本要求の最適化です。このタイプの要求があると、製品を使うユーザーは快適に使えるようになります。たとえば、音楽プレーヤーが自動的に現在再生中の曲に完全にマッチする歌詞をダウンロードして表示することができるようになります。
- ** 興奮要求：** 基本要求の背後にあるユーザーの心理的動機を満たすものです。このタイプの要求は、製品マネージャーが私を飛ばしてくれる感じをユーザーに与えることが多いです。たとえば、音楽プレーヤーの曲のランキングや音響効果の強化などです。
この順序は、龍兄がランダムに書いたものではありません。一般的に、新しい製品を開発する場合、基本要求の優先順位が最も高く、期待要求が次に、興奮要求がその次になります。
4. 上司によって曲げられる#
第 3 の落とし穴をうまく乗り越えたら、おめでとうございます。あなたは今、第 4 の落とし穴に到着しました - 上司によって曲げられる。
あなたは自分が発見し、整理し、優先順位を付けたユーザーの要求を持って、上司に報告するために意気込んでいます。上司の賞賛と承認を期待していますが、時には自分が正しいと思っていても、否定されることがあります。
なぜかわからないが、あなたは上司に曲げられ、あなたが表面的には同意しているかもしれないが、内心では同意していない要求を出すことがあります。
この落とし穴に対して、龍兄の戦略は次のとおりです：状況に応じて対処する。
上司が専門家である場合、一般的には上司はあなたよりも多くの経験と知識を持っているため、あなたが見落としているものを見つけることができるかもしれません。彼はあなたの範囲、経験、教訓を超えたものを見ることができるため、当時は理解するのが難しいかもしれませんが、彼の言うことを聞くべきです。
もう一つの場合は、上司が素人であり、しかも強気な場合です。この場合、次のような状況が発生する可能性があります：彼の意見には同意していないが、上司であるために言えないか、言えないかもしれません。
この場合、龍兄のアドバイスは：試して言ってみてください。理由を整理し、自信を持って自分自身を信じてください。自分が何の根拠もなく無駄な要求を出すわけではないと上司に説明し、もしもあなたの理由が十分で正しい場合、上司は間違ったものを固執する必要はありません。製品が良いからです。
もちろん、3 回以上試しても結果が変わらない場合は、よく考えてください。
5. どのように開発するか#
上司を乗り越えたら、最後の落とし穴に到着します - どのように開発するか？
あなたはおそらく「それは簡単です、基本的な要求だけを開発すればいい」と言うかもしれません。
実際、製品要件分析を行ったことがあれば、基本的な要求もたくさんあることに気付くでしょう。
この問題について、龍兄は次の 2 つのポイントを持っています：
戦略 1：今回のリリースの製品目的を明確にする#
すべての基本機能をリリースする必要はありません。異なる製品の時期やバージョン計画では、基本機能の重点は異なります。この時期やバージョンで解決するべき目標ユーザーの主要な問題、つまり今期の製品の主な目的を明確にする必要があります。
例えば、音楽プレーヤーの最初のバージョンでは、市場で主流のオーディオ形式をスムーズかつ正確に再生できることを解決する必要があります。
戦略 2：この目的に基づいて機能を MVP 化する#
この MVP は NBA の MVP ではありませんが、最小限の実現可能な製品の意味です。この MVP の範囲は、戦略 1 の目的に基づいて決まり、基本機能のサブセットです。したがって、これらの戦略は併用されます。
本期の製品目的に基づいて MVP を分割し、MVP に基づいて製品化作業を行い、最小の作業量、最短の時間、最低のリスクで製品の実現可能性を検証します。検証結果が正しい場合は、勝ち進むことができます。もしも正しくない場合は、小さな船でも早く方向転換し、すぐに戦略を調整して再開する必要があります。
MVP が適格かどうかを判断するためには 2 つの基準があります。1 つ目の基準は「完全性」です。つまり、これらの機能があれば、製品の目的を達成することができます。2 つ目の基準は「必要性」です。必要な機能は削減できないものであり、1 つでも欠けると製品の目的を達成することができません。
製品要件分析の道は、一つの落とし穴を踏み抜くことなく、次の落とし穴に進むことであり、一つも小さな落とし穴に落ちることはありません。
優れた製品マネージャーとして、まずこれらの落とし穴の位置、大きさ、形状に慣れる必要があります。次に、素早く行動し、穴を埋めるか回避する必要があります。これにより、製品作業の次のステップに成功することができます。