製品開発の協力会社とユーザー評価を進める6つの手順｜要求のズレを早期発見

製品開発を協力会社と進める際、仕様書どおりに設計・製造できていても、実際にユーザーへ使ってもらうと「思っていた使い方と違う」「この操作では現場で使いにくい」「必要だと思っていた機能がほとんど使われない」といったズレが見つかることがあります。こうしたズレを量産直前や納品後に発見すると、設計変更、部品変更、追加試作、評価のやり直しなどが必要になり、開発期間や関係者の負担が大きくなりやすくなります。

そこで重要になるのが、製品開発の途中でユーザー評価を計画し、その結果を協力会社と共有しながら設計へ反映していく進め方です。ユーザー評価は完成品の満足度を確認するだけの作業ではありません。要求仕様が実際の利用環境と合っているか、設計者が想定した操作方法がユーザーに伝わるか、使用条件に見落としがないかを早い段階で確認するための工程でもあります。

ただし、ユーザーに試作品を渡して感想を聞くだけでは、有効な評価にならない場合があります。評価目的や対象ユーザーが曖昧なまま進めると、意見がばらばらになり、協力会社へ何を変更してほしいのか説明できなくなるためです。反対に、評価項目を細かく固定しすぎると、当初想定していなかった使い方や不満を見落とす可能性があります。

この記事では、「製品開発 協力会社」で情報を探している開発担当者に向けて、協力会社とユーザー評価を進める際の6つの手順を解説します。評価の準備から試作品の確認、フィードバックの整理、設計への反映、再評価までを一連の流れとして管理することで、要求のズレを早期に見つけやすい開発体制をつくることができます。

手順1：ユーザー評価の目的と確認したい要求を明確にする

協力会社とユーザー評価を始める前に、最初に決めておきたいのが「今回の評価で何を確認するのか」です。評価目的が曖昧なままユーザーへ試作品を渡すと、「使いやすい」「少し重い」「見た目がよい」といった感想は集まっても、設計変更の判断につながらないことがあります。

製品開発では、要求が一つだけ存在するわけではありません。性能、操作性、安全性、耐久性、携帯性、設置性、視認性、作業時間、保守性など、製品によって複数の要求が存在します。そのため、ユーザー評価では全項目を一度に確認しようとするのではなく、開発段階に応じて確認したい要求を絞ることが重要です。

例えば、初期段階では「ユーザーがこの製品を必要とする場面が本当に存在するか」「想定している作業手順と実際の業務が一致しているか」といった利用価値や要求そのものを確認します。形状や操作方法が決まり始めた段階では、「ボタンや操作部の位置が適切か」「作業中に迷わず操作できるか」「携帯や設置に支障がないか」といった具体的な使い勝手を確認します。量産設計へ近づけば、長時間使用、繰り返し操作、設置環境、保守作業など、より実際の利用条件に近い評価が必要になります。

ここで大切なのは、ユーザー評価を製品の合否判定だけに使わないことです。試作品に問題がなかったかを見るだけではなく、そもそも要求の設定が正しかったのかを確かめる機会として利用します。協力会社が仕様書どおりに試作品を製作していたとしても、その仕様自体がユーザーの実態と合っていなければ、製品としては改善が必要だからです。

発注側と協力会社の間では、評価前に今回の目的を共有しておく必要があります。例えば「操作方法が理解できるかを確認する段階なのか」「筐体形状の使いやすさを確認する段階なのか」「使用環境に耐えられるかを確認する段階なのか」によって、準備する試作品も異なります。

評価目的が共有されていないと、発注側は操作性を確認したいのに、協力会社は性能確認用の試作品として準備しているといった食い違いが起こります。試作品にはまだ実装されていない機能がある場合もあるため、どこまで完成しているのかをユーザーへ説明する必要もあります。

要求についても、「軽いこと」「使いやすいこと」のような抽象表現だけでは判断しにくいため、実際の利用場面へ置き換えて考えることが有効です。「作業者が持ったまま一定時間操作できること」「手袋を着用した状態でも主要操作を行えること」「屋外から屋内へ移動しても作業を継続しやすいこと」といった具体的な利用場面を設定すると、協力会社も設計条件を理解しやすくなります。

最初のユーザー評価で全てを決めようとする必要はありません。むしろ、確認したい要求を限定し、評価結果を次の試作へ反映する方が、要求のズレを早い段階で発見しやすくなります。

手順2：評価するユーザーと利用場面を具体化する

ユーザー評価では、誰に使ってもらうかによって結果が大きく変わります。同じ製品でも、経験年数、担当業務、使用頻度、作業場所によって評価は異なるためです。そのため「実際のユーザーに評価してもらう」というだけではなく、想定している利用者を具体的に整理しておくことが重要です。

例えば、毎日使用する作業者と、月に数回しか使用しない担当者では、製品に求めるものが異なる可能性があります。毎日使う人は操作回数が多いため、わずかな手間や持ちにくさにも気づきやすくなります。一方、使用頻度が低い人にとっては、操作方法を覚えていなくても迷わず使えることが重要になる場合があります。

管理者と実作業者でも評価の視点は異なります。管理者は記録の確認やデータ管理を重視する一方、現場の作業者は入力作業の少なさや携帯性を重視することがあります。どちらか一方だけを評価対象にすると、導入後に別の立場から問題が出ることがあります。

製品開発の協力会社と評価計画を立てる際には、想定ユーザーの属性だけでなく、利用する状況も共有することが大切です。机の上で操作できる製品でも、屋外、暗所、狭い場所、騒音のある場所、手袋を着用する環境などでは操作性が変わります。設置スペース、移動距離、持ち運び方法、周囲の設備、利用時間なども製品設計に影響します。

特に現場で使用する機器では、開発室での評価だけでは見つからない課題があります。試作品単体では問題なくても、実際の作業では他の道具を持ちながら操作しなければならなかったり、途中で移動が発生したり、複数人が交代で使用したりすることがあります。こうした利用条件は仕様書だけでは把握しきれないため、ユーザー評価を通じて確認する価値があります。

評価場面を決める際には、通常作業だけを見るのではなく、開始から終了までの一連の流れを見ることも重要です。製品を保管場所から取り出し、準備し、設置し、操作し、結果を確認し、片付けるまでを観察すると、主要機能以外の問題を発見しやすくなります。

例えば、本体の操作は簡単でも、準備に時間がかかる、付属品を忘れやすい、記録を別の場所へ転記する必要があるといった問題が見つかることがあります。ユーザーにとっての使いやすさは、製品そのものだけではなく、作業全体の中で決まるためです。

協力会社へ利用場面を伝える場合も、「屋外で使用します」という説明だけでは十分ではありません。使用時間、持ち運び方法、設置方法、使用者の姿勢、周囲環境、作業の前後関係などをできる限り具体的に共有すると、評価結果を設計条件へ変換しやすくなります。

手順3：協力会社と試作品の完成度と評価範囲をそろえる

ユーザー評価で意外に起こりやすいのが、試作品の完成度に対する認識のズレです。発注側では「ほぼ完成形」と考えている一方、協力会社では「形状確認用の試作品」と認識している場合、評価結果の扱いを巡って混乱することがあります。

試作品にはさまざまな目的があります。外形寸法だけを確認するもの、操作方法を確認するもの、機構の動作を確認するもの、性能を評価するものなど、同じ「試作品」という言葉でも内容は異なります。そのため、ユーザーへ提示する前に、今回の試作品で評価できる項目と、まだ評価できない項目を明確にする必要があります。

例えば、外観確認用の試作品で重量が量産予定品と大きく異なる場合、ユーザーから「重い」という意見が出ても、そのまま設計課題として扱うべきとは限りません。一方で、量産品と同等の重量を想定していたにもかかわらず、長時間作業で負担が大きいという評価が出たのであれば、重要な設計情報になります。

この違いを整理せずに全ての意見を協力会社へ渡すと、本来変更する必要のない部分まで設計変更の候補になってしまいます。反対に、「これは試作品だから」という理由で意見を無視しすぎると、重要な要求のズレを見逃す可能性があります。

そのため、評価開始前に協力会社と試作品の状態を確認し、「今回確認できること」「暫定仕様になっていること」「今回の評価対象外とすること」を関係者間でそろえておくことが重要です。

また、ユーザーに試作品を渡す際の説明方法も検討します。製品の操作方法を詳しく説明しすぎると、実際には分かりにくい操作でも問題なく使えてしまい、操作性の課題が見えなくなる場合があります。反対に、まったく説明しなければ、本来想定していない使い方をされ、適切な評価にならないこともあります。

何を説明し、何をユーザー自身に判断してもらうのかは、評価目的によって変わります。初見でも操作できることを確認したいのであれば説明を最小限にします。一方、熟練者が日常的に使用した場合の作業効率を確認するのであれば、一定の操作説明を行ったうえで評価した方が適切な場合があります。

協力会社にも評価条件を共有しておけば、ユーザーがなぜその行動を取ったのかを設計側から分析しやすくなります。単に「ここが使いにくいと言われた」という情報ではなく、「どの条件で、どの操作を行った結果、どのような問題が発生したのか」を伝えられる状態をつくることが大切です。

試作品の完成度と評価範囲を最初に明確にすることで、ユーザーの意見を必要以上に広く解釈したり、反対に重要な指摘を試作品特有の問題として片付けたりすることを防ぎやすくなります。

手順4：ユーザーの発言だけでなく行動と利用状況を記録する

ユーザー評価では「どうでしたか」と質問し、回答を記録するだけでは十分でない場合があります。ユーザー本人が感じている問題と、実際の行動から分かる問題が一致するとは限らないからです。

例えば、評価終了後に「特に使いにくいところはありませんでした」と回答していても、実際には操作中に何度も同じ場所を確認していたり、別の操作方法を試したりしていることがあります。ユーザー自身が小さな迷いを問題として認識していなくても、製品側から見れば改善のヒントになる可能性があります。

そのため、ユーザー評価では発言と同時に行動を観察することが重要です。どこで操作が止まったか、何を最初に触ったか、説明を求めた箇所はどこか、作業姿勢が不自然になっていないか、操作をやり直した場面はないかなどを記録します。

操作時間も有効な情報になります。ただし、単純に短ければよいとは限りません。初回利用では時間がかかっても、二回目以降に大幅に短縮される場合があります。一方、何度使用しても同じところで迷う場合は、操作方法や表示方法に改善余地があるかもしれません。

利用状況を記録する際には、結果だけではなく条件も残しておくことが大切です。同じ問題でも、特定の利用環境だけで発生するのか、誰が使用しても発生するのかによって対策が変わります。

例えば「表示が見づらい」という意見が出た場合、表示そのものに問題があるとは限りません。屋外の特定条件でのみ見えにくいのか、表示位置が原因なのか、文字や記号が理解しにくいのかなど、原因を分けて考える必要があります。

また、ユーザーから改善案を提案されることもありますが、その案をそのまま要求仕様に追加するのではなく、「なぜその改善が必要だと感じたのか」を確認することが重要です。ユーザーが「ここにボタンを追加してほしい」と言った場合、本当の課題は「現在の操作手順が分かりにくい」ということかもしれません。ボタン追加は解決策の一つであり、別の設計方法で解決できる可能性もあります。

協力会社へ伝えるべきなのは、ユーザーの提案だけではなく、その背景にある問題です。「ボタンを増やしてほしい」という要望だけを伝えるよりも、「目的の操作へ進むまでに複数回迷い、ユーザーが直接操作できる方法を求めた」と伝えた方が、協力会社は設計全体を見ながら改善案を検討できます。

現場利用を想定した製品であれば、評価時の写真や位置情報、作業内容、試作品の状態などを関連付けて残すことで、後から状況を確認しやすくなります。評価件数が増えるほど、文章だけの記録では「どの場所で、どの試作品を、どの条件で評価したのか」が分からなくなりやすいためです。

ユーザー評価の記録は、単なるアンケート結果ではなく、設計判断を支える開発記録として扱うことが重要です。

手順5：評価結果を要求・設計・優先度に分けて整理する

ユーザー評価を実施すると、想定以上に多くの意見が集まることがあります。全ての意見をそのまま協力会社へ送り、「対応してください」と依頼すると、設計側では優先順位を判断できません。そこで、評価結果を整理してから設計へ反映する必要があります。

まず確認したいのは、その意見が要求そのものに関するものなのか、現在の設計方法に関するものなのかという違いです。

例えば「片手で操作できる必要がある」という評価結果が得られた場合、これは製品に求められる要求として整理できます。一方、「現在の操作部の位置では片手操作しにくい」という問題は、具体的な設計に関する課題です。この二つを分けて整理することで、要求を維持しながら別の設計方法を検討できます。

ユーザー評価では、複数の要求が競合することもあります。小型化すると携帯しやすくなる一方、操作部が小さくなり使いにくくなる場合があります。機能を増やすことで対応できる業務は広がりますが、操作が複雑になることもあります。このような場合、個別の意見だけを見て設計変更を繰り返すと、製品全体のバランスが崩れてしまいます。

そこで、評価結果には優先度を付けて整理します。優先度は単純に意見が多かった順に決めるものではありません。発生頻度、影響の大きさ、安全性への影響、主要業務への影響、設計変更の範囲、他の要求との関係などを確認します。

一人のユーザーからしか出ていない意見でも、重大な使用上の問題につながるのであれば優先度は高くなります。反対に、多くのユーザーが軽微な不満を挙げていても、製品の主要目的に与える影響が小さければ、他の課題を優先する判断も考えられます。

また、評価結果は「対応する」「対応しない」だけで管理しない方がよいでしょう。追加確認が必要なものや、次回試作で確認するもの、量産設計段階で検討するものなど、判断時期を分けて管理することで、すぐに結論を出せない意見も残しておけます。

協力会社と検討する際には、変更要求だけを提示するのではなく、評価結果と変更理由をセットで共有します。「操作部を移動してください」という指示だけでは、協力会社はその変更がどの要求に基づくものか理解できません。「片手保持時に操作部へ届かないユーザーが複数いたため、片手操作という要求を満たす配置を再検討したい」と共有すれば、位置変更以外の設計案も含めて検討できます。

協力会社が機構、回路、筐体、生産方法などに関する知見を持っている場合、ユーザーの課題に対する解決方法を発注側だけで決めないことも重要です。発注側はユーザー要求と優先順位を示し、協力会社には技術的な実現方法を提案してもらうことで、双方の役割を生かした開発につながります。

また、変更内容が別の要求へ影響しないかも確認します。操作性向上のために形状を変更した結果、収納性や耐久性に影響する場合もあります。ユーザー評価で見つかった一つの課題を解決するだけでなく、変更による新たなズレが生まれないかを確認することが必要です。

手順6：設計変更後の再評価まで協力会社と管理する

ユーザー評価で課題が見つかり、設計変更を行っただけでは評価工程は完了しません。変更した結果、本当に問題が改善したのかを確認する再評価が必要です。

製品開発では、課題を発見した時点よりも、その後の管理で混乱が起こることがあります。評価結果をもとに複数箇所を変更したものの、どの変更がどの課題に対応しているのか分からなくなったり、以前解決した問題が別の変更によって再発したりするためです。

そのため、ユーザー評価で確認された課題と、協力会社が行った設計変更を関連付けて管理することが重要です。どの評価結果に対して、何を変更し、どの試作品から反映され、再評価でどう判定されたのかを追える状態にします。

再評価では、変更部分だけを見るのではなく、関連する使用場面も確認します。例えば、操作部の位置を変更して片手操作がしやすくなったとしても、その変更によって誤操作が増える可能性があります。持ちやすさを改善するために形状を変更した結果、設置時の安定性が変わることもあります。

ユーザー評価を繰り返す場合、毎回まったく同じユーザーだけで確認するのが適切とは限りません。同じユーザーは製品に慣れるため、初回利用者が感じる問題を確認しにくくなるからです。学習後の使いやすさを確認したい場合は継続して同じユーザーに評価してもらい、初見での分かりやすさを確認したい場合は新しいユーザーにも試してもらうなど、評価目的に応じて対象を変える必要があります。

また、再評価のたびに要求を追加し続けると開発が終わらなくなるため、どの段階で要求を確定するかも決めておくことが大切です。開発初期では幅広く意見を収集し、設計が進むにつれて変更対象を重要な要求へ絞っていくことで、開発スケジュールを管理しやすくなります。

協力会社との定例確認では、試作品の製作進捗だけではなく、ユーザー評価で残っている課題も確認します。設計変更待ち、追加確認待ち、再評価待ちなどの状態が分かるようにしておけば、課題が放置されにくくなります。

量産移行前には、それまでのユーザー評価結果を振り返り、主要な要求について確認が完了しているかをチェックします。評価で問題がなかったという事実だけでなく、「どの条件で確認したか」が残っていることも重要です。使用環境や評価条件が限定されていた場合は、その範囲を理解したうえで量産判断を行う必要があります。

ユーザー評価は一回実施して終了するイベントではなく、要求確認、試作、評価、改善、再評価をつなぐ開発工程として運用することで効果を発揮します。

製品開発でユーザー評価を早期に行うメリット

製品開発でユーザー評価を早期に行う最大のメリットは、要求のズレを設計変更しやすい段階で見つけられることです。

開発後半になるほど、製品を構成する要素同士の関係は複雑になります。一つの形状変更でも、内部部品、取付方法、製造工程、検査方法などへ影響する可能性があります。そのため、ユーザーが求めていたものと仕様が違うことを後半で発見すると、変更範囲が大きくなることがあります。

開発初期であれば、まだ設計が確定していないため、要求そのものを見直しやすくなります。「この機能を追加するべきか」という議論だけではなく、「そもそもこの作業を製品で行う必要があるのか」といった上位の検討もできます。

協力会社にとっても、早期にユーザー情報を得られるメリットがあります。仕様書だけでは理解しにくい利用背景を知ることで、設計上の提案を行いやすくなるためです。

例えば発注側が指定した形状について、協力会社が「この利用方法であれば別の構造にした方が扱いやすい」と提案できる場合があります。ユーザー評価を発注側だけで管理し、結果として決定済みの変更指示だけを協力会社へ伝えると、このような提案機会を失うことがあります。

また、ユーザー評価を早い段階から繰り返すことで、関係者間で製品の目的を共有しやすくなります。開発期間が長くなると、仕様書に記載された個別要件を満たすことが目的になり、本来どのようなユーザー課題を解決する製品だったのかが見えにくくなることがあります。

実際の利用状況やユーザーの反応を定期的に確認することで、「誰が、どこで、何のために使う製品なのか」という開発の基準へ戻ることができます。

一方、早期評価だからといって、未完成の試作品を無計画にユーザーへ見せればよいわけではありません。完成度が低い状態では評価できない項目もあるため、その段階で確認できる内容を選ぶことが重要です。

初期段階では使用場面や操作の流れ、中盤では形状や操作性、後半では性能や実使用に近い条件というように、開発段階に応じて評価内容を変えることで、試作を効率的に活用できます。

協力会社とユーザー評価を進める際に起こりやすい失敗

協力会社との製品開発では、ユーザー評価を行っていても、その結果を十分に活用できないケースがあります。原因の一つは、ユーザーから出た意見を全て要求として扱ってしまうことです。

ユーザーの意見は重要ですが、一人の意見が市場全体の要求を表しているとは限りません。また、ユーザーが提示する改善方法が技術的に最適とは限りません。そのため、発言内容だけを見るのではなく、その背景にある課題を確認する必要があります。

もう一つの失敗は、評価結果を発注側だけで整理し、最終的な変更内容だけを協力会社へ伝えることです。この進め方では、協力会社がユーザー課題を理解できず、指定された修正だけを行う関係になりやすくなります。

製品開発の協力会社には、設計や製造に関する専門知識があります。ユーザーの課題を共有し、技術的な解決方法を一緒に検討できれば、発注側が想定していなかった改善方法が見つかる可能性があります。

反対に、評価結果を整理せず、そのまま大量に共有するのも避けたい進め方です。「使いにくい」「大きい」「分かりにくい」といったコメントだけが並んでいても、協力会社はどこから対応すべきか判断できません。

評価時の条件、発生した行動、要求への影響、対応の優先度まで整理すると、設計検討に利用しやすくなります。

また、ユーザー評価の実施が遅すぎることも大きな問題です。完成に近い試作品になってから初めてユーザーへ見せると、重大な要求のズレが見つかっても変更しにくくなります。「せっかくここまで開発したから」という理由で不十分な設計を残してしまうことも考えられます。

そのため、完成度の高い試作品を一回評価するより、開発段階に応じた評価を複数回行う方が、要求のズレを早期に見つけやすくなります。

ユーザー評価の結果を協力会社へ伝えるときの考え方

協力会社へユーザー評価結果を共有するときは、「ユーザーからこのように言われたので変更してください」という伝え方だけではなく、事実と解釈を分けることが重要です。

例えば、「本体が大きすぎる」という意見が出たとします。この発言だけでは、どの寸法が問題なのか分かりません。持ち運び時に収納できなかったのか、操作時に片手で保持できなかったのか、設置スペースに収まらなかったのかによって、必要な対策は異なります。

そこで、「収納場所へ入らなかった」「持ち替えが複数回発生した」「設置時に周囲の設備と干渉した」といった観察事実を共有し、そのうえで「携帯性に関する要求を満たせていない可能性がある」と整理します。

こうすると、協力会社は単純な小型化以外の方法も検討できます。持ち方を変える、収納方法を変える、構造を分割するなど、要求を満たす方法は一つとは限りません。

評価結果には、写真や作業記録などの情報を関連付けておくと、言葉だけでは伝えにくい状況を共有しやすくなります。ただし、記録量を増やすこと自体を目的にすると管理が複雑になるため、設計判断に必要な情報を残すという考え方が必要です。

また、協力会社から「なぜこの変更が必要なのか」と質問されたときに、ユーザー評価へ戻って説明できる状態にしておくことも重要です。開発期間が長くなると、変更理由が分からなくなり、以前の設計へ戻してしまうことがあります。

要求、評価結果、設計変更、再評価の関係を追えるようにしておけば、変更理由を共有しやすくなり、担当者が変わった場合でも判断の経緯を確認できます。

まとめ

製品開発の協力会社とユーザー評価を進める際は、完成品への感想を集めるだけではなく、要求と実際の利用状況のズレを早い段階で確認する工程として位置付けることが重要です。

最初に評価目的と確認したい要求を明確にし、対象ユーザーと利用場面を具体化します。次に、協力会社と試作品の完成度や評価可能な範囲を共有したうえで、実際のユーザー評価を行います。評価中は発言だけでなく、操作の迷い、作業姿勢、利用条件なども記録し、背景にある課題を把握します。

集まった結果はそのまま設計変更へ結び付けるのではなく、要求に関する問題なのか、設計方法に関する問題なのかを整理し、重要度や影響範囲を確認します。そのうえで協力会社と解決方法を検討し、設計変更後は再評価によって改善できたかを確認します。

この流れを繰り返すことで、「仕様書どおりには完成したが、ユーザーには使いにくかった」という事態を減らしやすくなります。また、協力会社にとっても利用実態を理解したうえで技術提案ができるため、単なる図面や仕様の受け渡しではなく、要求を実現するための開発協力体制を築きやすくなります。

特に現場で使用する製品では、評価場所、作業状況、試作品の状態、写真、位置情報などを後から確認できるようにしておくと、発注側と協力会社の認識をそろえやすくなります。評価件数や試作回数が増えるほど、「どの場所で何を確認し、どの課題が見つかったのか」を一元的に追える記録体制が重要になります。

現場写真・位置情報・施工記録を管理できるLRTK Phoneを活用すれば、現場で確認した状況を位置情報とともに残し、関係者間で確認するための記録として整理できます。現場利用を前提とした製品のユーザー評価でも、評価した場所や状況を記録として残しておくことで、協力会社へ問題の発生条件を伝えやすくなります。製品開発では、ユーザーの声を集めるだけで終わらせず、実際の利用状況と設計変更を結び付けて管理し、要求のズレを早期に発見できる開発プロセスを整えることが重要です。