White Paper
【解説】デザインエンジニアリングに必要な「評価」手段
2025年7月16日
デザインエンジニアリングに必要な「評価」手段

【目次】
Executive summary:「実現」した成果に、より確からしさを高めるには
「評価」の課題解決手段 ― デザインエンジニアリングが出来ること ―
デザインエンジニアリングの評価ツール① ― 主観的評価手法の応用 ―
デザインエンジニアリングの評価ツール② ― 適応型UIによる評価・検証 ―
デザインエンジニアリングの評価ツール③ ― メソッドを活用することでの評価 ―
企業が抱える課題解決のためのプロセスとして有効な「デザインエンジニアリング」。 第6回ではデザインプロセスであってもエンジニアリングプロセスであっても最後の大きな工程である「評価」に関する内容を解説致します。
「実現」した成果に、より確からしさを高めるには
「ユーザー評価」「ヒューリスティック評価」や「フィジビリティスタディ」「単体 / 結合・統合試験」等の一般的な評価やテストについてではなく、それらの評価方法では見落としがちな観点や工夫所を交えて「デザインエンジニアリング」の評価方法について紹介し、本記事を読まれた方々にとって、何か今後のヒントになることがあればという想いで書かせて頂きます。
様々な工程を経て作られた「モノ」としての機能品質、それを使う「人」の使用性品質、そ してそれを利用し、あるいは業務上運用する「コト」の利用時品質、それぞれの品質を高める為に考察して作り上げた成果を評価した上で本開発フェーズに移行し、市場に投入する必要がありますが、「モノ、コト、ヒト」それぞれに即した評価にもデザインエンジニアリングの観点が、従来の評価方法にも活用でき、必要であると考えます。

「形成的評価」と「総括的評価」それぞれの課題
ユーザー評価を代表例として、デザインプロセスにおける評価は、製品の開発過程において品質の暫時的な最適化を目指す途中評価であり、いわゆる形成的評価であることが多く、エンジニアリングプロセスでは、製品の完成後や納品・出荷の段階において要求品質の達成状況を確認するために実施する事後評価であり統括的評価といいます。
どちらに も課題はあるものの、開発品質、製品品質、これに加えこれまでの本記事でも触れてきた「利用時品質」を高めるためには欠かせない評価の手法です。

いずれもエキスパート人材による評価基準や計画、方法、実施で改善に向かうことはあるのですが、現実的には、または、実際の現場では人材不足の為、いまある体制の中で実施しがちではないでしょうか。
「評価」の課題解決手段 ― デザインエンジニアリングが出来ること ―
デザインエンジニアリングでの評価方法であっても、「形成的評価」をより効率化、評価観点や分析レベルにバラつきが無いようにするに留まり、「統括的評価」に関してはレガシーな方法と進め方のままなのが現状で、「形成的評価」の結果がうまく活用されていないケースがあります。デザイナ、エンジニアの評価エキスパートによって何か新たな評価方法を見出すことが出来ないか、模索する日々が続いているのが現状です。「形成的評価」と「統括的評価」を分断せずに、それぞれの評価の負荷や考慮漏れが無いようにするにはどうすればよいのでしょうか。
過去の当社事例ではありますが、以下のような工夫によって課題を削減できないかトライしたケースを紹介します。
◆ HMI 開発フレームワーク・ツールへの利用時品質評価項目「HMI メトリクス」ロジックの導入
あらかじめ定義されたユーザビリティに関する「HMI メトリクス」を用いて開発工程にあるHMI 品質を開発ツール上で機械的に判定
モノやサービスの「品質」を数値的・定量的に評価する「メトリクス」の中でも HMI にフォーカスした「利用時品質」の特性に限定
対象となるデバイスの利用シーンを想定し、画面サイズ、視距離を基準値として設定することで判定基準へも適用 等
開発当時は反響も多く、設計・開発をしながら、仕様変更によって更新されるUI設計や意匠、機能も、毎回メトリクスを実行することで自動的にチェックが入り、「HMI メトリクス」の基準に反している箇所にアラートとその評価項目がわかり、効率性には非常に将来性を感じた取り組みでした。
しかしながら、ソフトウェア開発環境自体の進化が早く、様々なソフトウェアベンダーから新たな開発環境が登場し、OSS やシミュレータ等の活用も進む流れとなり、自社開発の開発ツール自体の 拡張を続けることを断念することになったのです。
「HMI メトリクス」のロジックは変わらないものの、それを搭載する開発環境の進化、多様化までは予見できなかったことが反省点です。
ただ、この観点を取り入れた開発環境は、Web ベースのビジュアルテイスティングツールのような表層上のバグ検証は存在するようですが、おそらく現在も皆無ですし、当時より数年が経った今だからこそ、AI やクラウドを活用した自動化ツール上で再度トライ出来そうに思います。
上記のような構想に興味がある開発環境構築される方々、是非当社までお声がけください!色々ノウハウあると思います。
エンジニアリングの「フィジビリティ」観点の活用
「形成的評価」「総括的評価」の課題解決の手段はまだまだ検討が必要ではありますが、現在実践している「デザインエンジニアリング」での評価事例をいくつか紹介します。
◆ エンジニアの知識や観点を取り入れた「ヒューリスティック評価、分析」
ヒューリスティック評価は一般的にはユーザビリティのエキスパートが UI の原則やガイドラインに沿って課題を抽出しますが、この工程では、その課題をどう解決するのか、課題解決の為の技術的難易度や、代替手段までを想定することなく進めることも多いはずです。
まだ「発想」段階においては視野の解像度を粗く広い視点で進める必要もあるのですが、プロジェクトの状況次第では、解像度を上げて、優先度が高い課題にフォーカスすることも必要と考えます。この工程段階でも、ユーザビリティを「実現する」エンジニアのフィジビリティの観点を入れることで、ユーザビリティのエキスパートであっても、気付かない課題や解決手段に気付くことができるようになります。
例えば、ヤコブ・ニールセン博士がまとめた「10 ヒューリスティックス」の一つ、
「Flexibility and Efficiency of Use」(柔軟性と効率性)を例にすると、

というように、よりユーザーの本来期待する結果を考察することができることと、デザイナはUI設計に反映しつつ、エンジニアはその手段が実現できるのか検証に進むことができ、纏まった分析結果を待たずに 、双方で次の課題に取り組むことが出来ます。
デザインエンジニアリングの評価ツール① ― 主観的評価手法の応用 ―
他の形成的評価手法である「認知的ウォークスルー」や「ユーザビリティテスト」でも、「発想し定義する側」「実現する側」の双方の観点が上流工程の中でも必要であると考えます。
◆ 心理的負荷を定量的に計る NASA-TLX(Task Load Index)
(参照 https://humansystems.arc.nasa.gov/groups/TLX/index.php )
主観的なメンタルワークロード(精神的な負担)を評価するための手法です。米国 NASA で開発され、とっくに航空パイロットの作業負担を評価するために用いられていましたが、現在では医療従事者や自動車運転者など、様々な分野で広く使われていて、手順や評価テンプレートも公開されており、定性・定量の両側面で評価できるツールです。

主観的な評価方法ではあるので、気分や体調の影響によりバイアスが掛かる可能性があり、生体センサーモジュール + ラズパイ等のマイコンによる評価時間中のストレス度合いを並行して計ることで評価の確からしさを高めることができます。
現在では、AppleWatch のように精度高く生体データを取れる様々なデバイスもあるので、ログを見ながら刺激因子と行動因子を比較し因果関係を見つける手段も取れるかもしれません。
デザインエンジニアリングの評価ツール② ― 適応型 UI による評価・検証 ―
◆「人を正しく理解する」質的、量的評価
当社の試験的なプロジェクトでは、ユーザーの置かれた状況に合わせて UI や振る舞いをアダプティブに変えるシステム