試作が動いても、製品化には部品ばらつき、製造・検査、使用環境、調達の確認が残ります。試作の成功条件を量産時にも再現できるかを評価し、設計資料と検査手順を揃えます。
この記事の内容
試作機では狙った動作ができたのに、製品化へ進もうとすると課題が増える。電源を変えると動かない、通信が切れると復帰しない、別の担当者が組み立てると結果が違う。こうした問題は、中核機能の確認と、製品として継続して使う条件の確認が異なることから生じます。
試作の成功は大切な前進ですが、それだけで製造、設置、運用、保守まで成立したとは言えません。本記事では、試作で確認した範囲を明確にし、使用環境、異常時の動作、製造検査、納品後の対応を仕様へ戻す手順を整理します。
試作から製品化へ引き継ぐ項目
| 項目 | 確認すること | 判断に使うもの |
|---|---|---|
| 設計 | 部品公差・温度・電源変動 | 成立する条件の範囲 |
| 製造 | 組立・書込み・校正 | 作業手順と必要治具 |
| 検査 | 測定点・基準・記録 | 不良を出荷前に見つける方法 |
「動いた」の条件を、まず書き出す
試作では、特定の電源、センサー、通信環境、ダミーデータを使って動作を確かめることがあります。開発者が操作し、必要に応じて手動で設定を直している場合もあります。何が確認済みで、何が担当者の作業によって成立していたかを、試験記録から分けます。
例えば、センサー値を画面へ表示できた試作なら、値の取得、通信、表示という一連の流れを確認したと言えます。一方、通信が途切れた場合の扱い、センサー故障の検出、複数台での管理、更新後の復帰まで、同時に確認できたとは限りません。確認していない項目を製品の機能へ読み替えないようにします。
試作の成果を小さく評価する必要はありません。試験した条件、結果、次に確認する条件を対応させることで、その成果を製品化の判断材料として使えます。専用基板や筐体へ移る前に、最も大きな不明点を見つけることが目的です。
使用環境を、製品の要求へ置き換える
製品になると、開発者以外の人が、想定した場所と手順で使います。電源の投入と切断、周囲温度、設置方法、接続ケーブル、外部機器との組み合わせなどを整理します。机上の試作と実際の設置条件が違うなら、その差を試験項目へ加えます。
| 段階 | 主に確かめること | 次へ進む判断材料 |
|---|---|---|
| 簡易試作 | 一機能・一データフローの成立 | 構成、動作結果、残った課題 |
| 実用途での試行 | 実データ、設置条件、操作 | 正常・異常時の評価結果 |
| 製品設計 | 専用基板、筐体、検査、更新 | 仕様、製造資料、試験方法 |
| 導入・運用 | 設置、保守、復旧、引き継ぎ | 担当、手順、履歴の残し方 |
環境への対応は、対象製品と用途によって変わります。必要な規格や認証、顧客の受入条件がある場合は、その適用範囲を個別に確認します。試作の動作結果だけで適合済みと扱わず、設計で対応する項目と、別途評価する項目を分けて計画します。
正常系だけでなく、復帰まで設計する
現場では、停電、通信断、センサーの抜け、入力の誤りが起こり得ます。異常時に止まることだけでなく、利用者が異常を判断できるか、記録が失われないか、再開後に整合が取れるかを確認します。担当者が装置の前へ行かないと直せない条件も把握します。
通信が戻った後のデータを確認する
通信断の間に取得した値を後から送る場合には、取得時刻と送信時刻の扱いを決めます。再送で同じ記録が重複したり、受信順が変わったりする可能性を試験します。機器の状態と設備の状態を混同しないよう、欠測や接続断を表示する方法も必要です。
電源を切って再投入する試験では、設定、時刻、接続先、保存していたデータがどうなるかを確認します。利用者が特別な操作をしなくても復帰すべき範囲と、点検をしてから再開する範囲を定めます。安全に関わる判断を、便利さだけで自動化しないことも設計条件です。
作りやすさと、検査できる設計
一台の試作を手作業で調整できても、同じ方法で多数の製品を作れるとは限りません。部品表、組立図、書き込み手順、設定の初期値を揃え、製造する人が判断に迷う箇所を減らします。部品の代替や設計変更が生じた場合の評価範囲も決めておきます。
製造検査では、どこを測り、どの機能を動かし、どの結果なら合格にするかを具体化します。検査のために筐体を何度も開ける、開発者の専用環境が必要といった構成なら、検査端子や治具、操作手順の見直しが必要になることがあります。検査を製作後に付け足すより、設計段階で含める方が整理しやすくなります。
製品の個体識別と、回路・ソフト・設定の版を対応させます。出荷時の試験結果を個体にひも付けると、現場で不具合が起きた際に、対象の構成と検査履歴を確認できます。同じ外観の装置でも、中身の版が違う可能性を運用で扱えるようにします。
少数台を作る段階では、組立と検査を担当する人に、資料に沿って実施してもらう方法が有効です。開発者だけが知っている調整や、口頭で補っていた操作が見つかります。複数台の結果を比べ、部品や作業の違いで結果が変わる箇所を、製造手順と設計へ戻します。
販売後の更新・保守を、先に決める
ソフトを更新できることと、安全に更新を運用できることは別です。更新対象を識別し、誰が承認し、いつ適用し、途中で失敗したときにどう復旧するかを決めます。設定を維持するのか初期化するのか、以前の版に戻せる範囲も評価の対象です。
IoT製品では、販売後のセキュリティ対応も設計と運用をつなぐ課題になります。IPAの「IoT開発におけるセキュリティ設計の手引き」は、設計段階の脅威分析に加え、運用段階の脆弱性対策などを扱っています。製品寿命、更新方法、問い合わせ窓口、廃棄時の初期化まで検討します。参考:IPA IoT開発におけるセキュリティ設計の手引き。
保守担当者が確認できるログや状態表示も必要です。何でも保存するのではなく、原因を切り分けるために必要な情報と、保存してはいけない情報を分けます。現地対応と遠隔対応の範囲、交換後の設定復旧、問い合わせ時に必要な情報を、引き継ぐ手順として残します。
試作で使っていた接続設定を、そのまま全製品へ複製してよいかも点検します。個体ごとに持つ情報、共通の初期値、設置先で変更する値を分けます。交換時に以前の個体へ残るデータの扱いや、返却・廃棄時の初期化まで決めておくと、保守の途中で管理が曖昧になるのを防げます。
量産へ進む前の評価を組み立てる
製品化の評価では、要求ごとに、設計で対応した箇所、確認する試験、合否条件をつなげます。中核機能、環境条件、異常時、製造検査、更新・保守を一つの評価計画で見られると、未確認のまま残っている要求が見つかります。
試験で問題が出たら、回路、ソフト、構造、運用のどこで解くかを検討します。一時的な手動操作で回避できても、製品仕様として成立したとは扱いません。対応後には対象の版を固定し、変更によって影響を受ける機能を確認してから、製造資料へ反映します。
納品時には、動作する本体だけでなく、合意した設計資料、試験結果、設定・更新手順を揃えます。評価条件と対象外を明記しておけば、使用範囲が広がるときにも、追加で確かめる条件を判断できます。
評価の一覧には、確認済み、未確認、条件付きで確認した項目を分けて示します。例えば通信の動作は確認済みでも、長時間の運転や更新失敗時の復旧が未確認なら、それぞれの状態を残します。全体を「動作確認済み」とまとめるより、製品化を止めている具体的な条件が分かります。
相談前に揃えておく情報
- 試作で使った部品、データ、回路・ソフトの版と試験結果
- 利用者、設置場所、台数、運用期間、外部機器との接続条件
- 正常動作と、停電・通信断・誤操作などの復帰条件
- 製造、設置、保守を担当する人と、必要な資料・検査方法
まとめ:動作から、繰り返し使える条件へ
試作から製品へ進むには、動作した機能を出発点に、使用環境、異常時、製造、更新、保守の条件を加えます。確認済みと未確認を分け、要求と試験を対応させることで、製品化で足りない工程と、次に行う検証を具体化できます。
技術支援のご案内
LinkT&Bでは、回路・組込み設計、試作・評価、製造検査や運用を見据えた開発をご相談いただけます。詳しくはR&D・パワエレ事業、個別相談はお問い合わせをご覧ください。
関連記事
仕様書がなくても、開発相談できる?
古い設備を交換せずIoT化するには?
研究開発・回路設計・実験評価の相談
回路設計や試作、実機での評価を支援します。現在の課題と使用条件を伺い、必要な測定や開発の進め方を提案します。