製品仕様の作成方法のベストとワースト

製品開発チームが直面する最大の問題の1つは、どの製品を作るかをどうやって決めるかということです。製品仕様に基づいて作業を行うチームの場合、特にハードウェア開発では、エンジニアは通常、製品仕様が完成し承認されるまで作業を開始することは許されません。 8057>

この課題を見る 1 つの方法を次に示します。円は、チームが製品を構築することができるすべての可能な方法であると想像できます。そして、その小さな青い点は、ある特定の製品の仕様です。

この投稿では、まず、製品仕様に合意するために使用される一般的な方法のいくつかを説明します。

私の視点は、アナログおよびミックスドシグナル半導体業界で、最初はアプリケーションエンジニアとして、後に製品定義担当者として 10 年間働いた経験から来ていると言っておく必要があります。

製品仕様を作成する最悪の方法:

顧客に作ってほしいものを聞く

1 つの方法は、顧客に何が必要かを聞くことから始めることです。これは、顧客から発行される見積依頼書（RFQ）を待つことでもよいし、あまり形式的でなく、ミーティングやディスカッションを通じて行うこともできます。一般的に、このアプローチでわかることは、現在使用しているソリューションや製品、そしてごく近い将来に変えてほしいことです。 8057>

このシナリオでは、既存の製品について反復することが求められているため、最終的に、間違いなく実装できる非常に具体的なアイデアが得られる可能性が高くなります。

顧客が製品戦略について話していることは、競合他社にも話している可能性が高く、プロジェクトの主な目標はおそらく、既存のソリューションよりも安いものを作ることでしょう。あなたは価格競争に巻き込まれることになるでしょう。
顧客はすでに、以前に購入したものに基づいて、あるタイプのソリューションに決めているため、彼らのニーズをよりよく満たすようなものを提案することが難しくなっています。
スケジュールが非常に厳しいため、新しいものを作ったり、真のイノベーションを可能にしたりする機会がほとんどない可能性があります。

この場合、より広い市場が必要とし購入する製品の要件をあなたが書くのではなく、顧客が彼らの内部要件を仕様に変換することに頼っていることになります。最良の選択がなされたことを確認する唯一の方法は、結果として得られる製品仕様の変更を顧客と一緒に確認することです。そうしなければ、顧客に受け入れられない製品を作ってしまう危険性があります。しかし、設計チームは厳しいスケジュールで仕事を進めなければならないため、十分な情報を得られないままトレードオフを行う可能性が高くなります。

このアプローチは、製品が納品されるという点で有効です。もし、あなたが汎用部品を提供するビジネスをしているのであれば、これは問題ないでしょう。粗利を守る独自のソリューションを探しているのであれば、これは最適なアプローチではありません。

RELATED POST: 上流と下流の関係についてのより良い影響度分析を行う方法

2. エンジニアに仕様全体を書かせる

もう1つのよくあるシナリオは、エンジニアや他の顧客対応チームのメンバーが、1人または数人の顧客との会話に基づいてソリューションを思い描くというものです。チームはこのアイデアに結集し、内部の勢いに乗って、要件はすぐに文書化され、チームの努力はすぐに製品仕様の作成とソリューションの開発に向けられます。

典型的には、このシナリオでは、製品要件は一人の個人の頭から直接生まれ、長い仕様書にまとめられ、チームの残りのメンバーは文書化された仕様書を使用して取引を行います。チーム内でトレードオフの問題に直面した場合、要件を作成した個人は、新しい情報がほとんどない状態で、独自に正しいトレードオフを決定しなければならない。さらに、その人が要件を調査も検証もしていなければ、チームは間違った製品を作ってしまうことになります。

Why These Approaches Don’t Lead to Success

これまでのアプローチに共通しているのは、できるだけ早く完成品の仕様に到達することに焦点が当てられていることです。チームは何かを作り始め、顧客の納期に間に合わせようと急ぐあまり、その何かが正しいものであることをまず確認しません。

さらに、要件に関する知識はチーム内のたった一人の個人にしか存在しません。その人物は、スポンサーである顧客とやりとりする人物か、製品のアイデアを思いついた人物である。

その結果、多くの時間とコストが浪費された後、製品が必要以上に遅く潰れたり、売れない製品や価格で勝負するミートゥー製品を作ったりすることがよくあります。これらはいずれもビジネスにとって良いことではありません。

Related POST: 8 Do’s and Don’t for Writing Requirements

The Best Ways to Create a Product Specification:

顧客に買ってもらえる製品を作る最善の方法は、仕様書を書き始めるずっと前に、ターゲット市場に出向いて話をすることです。

製品の問題ステートメントは、市場のニーズを説明するいくつかの文章または段落です。これは重要なことですが、実際に問題を解決する方法については何も言いません。

問題ステートメントは一般的に3つの部分から構成されます：

第1はペルソナ、または誰が問題を持っているかの説明です。ペルソナを個別に詳細に説明し、問題ステートメントで特定のペルソナを参照すると、同じペルソナの説明を繰り返さずに済みます。
次は、問題の説明です。ここでは、より詳細であればあるほどよいでしょう。ニーズが明確であることを確認したい。また、問題に名前を付けます。これにより、プロジェクト中にチームがそれを参照することが容易になります。
最後に、問題がどの程度の頻度で発生するかの説明を書きます。問題がめったに起こらず、影響が小さい場合、それを解決することは価値が低い。

あなたは、あなたが解決できると思う彼らが持っている問題は何かを顧客に尋ねることから始めることができますが、本当に価値のある問題文またはゴールデンナゲットに到達するために深く掘り下げる必要があります。

これをうまくやれば、最終的に解決でき、顧客がお金を払ってくれるような問題を特定することができるだろう。社内の人間の話を聞きすぎたり、少数の顧客だけの話を聞いたりすると、問題を誤って検証したり放棄したりすることになりかねません。 8057>

今回、制約を表す交差する線を追加しました。問題ステートメントを円を横切る線と考えるなら、市場の理解に基づく優れた問題ステートメントは、円内のすべての許容可能な解決策を表す領域を囲みます。 8057>

この領域の大きさは、以前のRFQや製品アイデアの円よりもはるかに大きいことにお気づきでしょう。これは、これらの問題ステートメントとコンテキストが、新しいアイデアが前に出ることを可能にするために、意図的にソリューションをできるだけ緩く縛っているからです。

このアイデアは、制約の中で最も革新的なソリューションを作成するために設計チームに最大の柔軟性を与えることです。

問題提起から仕様へ

さて、問題提起ができ、チームがそれに慣れてきたら、製品仕様を共同で開発し始める。チームの全員が解決しようとしている問題を理解しているので、全員が仕様に貢献できます。

特定した制約の中で、解決しようとしている問題を特定するという先行作業を行い、チームはソリューションを提供する複数の方法を検討したので、製品仕様を書くのに十分な情報を持っていると言えます。

Release the Product Specification in Small Batches

ここでの最善の方法は、できるだけ早くチームに仕様の小片をリリースして、迅速なフィードバックを得ることです。これにより、間違った方向に進む無駄な時間を避けることができ、チームが高品質のフィードバックを提供することがはるかに容易になります。これを考えてみてください。 200 ページにわたる仕様書をレビューするために受け取ったとしたら、どうなるでしょうか。 8057>

では、1 ページのドキュメントを受け取った場合はどうでしょうか。おそらく全体を見直すでしょう。 8057>

Refer to the Problem Statement to Ensuure You’re on Track

また、仕様を作成しながら、製品がまだ問題に対する有効な解決策であることを確認します。製品開発特有のトレードオフにとらわれ、自分がまだ目標に近づいているかどうかを確認することを忘れがちです。プロセスが管理されているため、誰かが決定を覆すことができないような枠組みと透明性があります。プロジェクトのどの時点でも、製品がどのような価値を提供し、なぜチームが指定した機能を持つ必要があるのかを正確に説明することができるようになります。しかし、市場の競争が激化し、製品がますます複雑になるにつれ、以前に作ったものの別の反復を提供するだけでは、長くビジネスを続けることはできません。

すべての関係者が開発ニーズを明確に理解できるように要件を書く方法の詳細については、eBook「要件を書くためのベストプラクティス」をダウンロードしてください。