【解説】デザインエンジニアリングに必要な「評価」手段
Design Engineering vol.6

企業が抱える課題解決のためのプロセスとして有効な「デザインエンジニアリング」。第6回ではデザインプロセスであってもエンジニアリングプロセスであっても最後の大きな工程である「評価」に関する内容を解説致します。

記事のPDFダウンロードをご希望の方はこちら

PDFダウンロード

こんな方にお勧めです

IoT改革やDX推進担当者
製品、サービス企画、開発担当者
デザイン思考・UXデザインに興味がある方
提供している製品やサービスのユーザビリティに課題をお持ちの方
企画/デザインと実装/開発の連携に課題をお持ちの方

「実現」した成果に、より確からしさを高めるには
「形成的評価」と「総括的評価」それぞれの課題
「評価」の課題解決手段　― デザインエンジニアリングができること ―
エンジニアリングの「フィジビリティ」観点の活用
デザインエンジニアリングの評価ツール①　― 主観的評価方法の応用 ―
デザインエンジニアリングの評価ツール②　― 適応型 UI による評価・検証 ―
デザインエンジニアリングの評価ツール③　― メソッドを活用することでの評価 ―
進化する機能や開発方法に対する新たな「評価」手段の必要性

「実現」した成果に、より確からしさを高めるには

「ユーザー評価」「ヒューリスティック評価」や「フィジビリティスタディ」「単体 / 結合・統合試験」等の一般的な評価やテストについてではなく、それらの評価方法では見落としがちな観点や工夫所を交えて「デザインエンジニアリング」の評価方法について紹介し、本記事を読まれた方々にとって、何か今後のヒントになることがあればという想いで書かせて頂きます。

様々な工程を経て作られた「モノ」としての機能品質、それを使う「人」の使用性品質、そしてそれを利用し、あるいは業務上運用する「コト」の利用時品質、それぞれの品質を高める為に考察して作り上げた成果を評価した上で本開発フェーズに移行し、市場に投入する必要がありますが、「モノ、コト、ヒト」それぞれに即した評価にもデザインエンジニアリングの観点が、従来の評価方法にも活用でき、必要であると考えます。

「形成的評価」と「総括的評価」それぞれの課題

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

いずれもエキスパート人材による評価基準や計画、方法、実施で改善に向かうことはあるのですが、現実的には、または、実際の現場では人材不足の為、いまある体制の中で実施しがちではないでしょうか。

「評価」の課題解決手段　― デザインエンジニアリングが出来ること ―

デザインエンジニアリングでの評価方法であっても、「形成的評価」をより効率化、評価観点や分析レベルにバラつきが無いようにするに留まり、「統括的評価」に関してはレガシーな方法と進め方のままなのが現状で、「形成的評価」の結果がうまく活用されていないケースがあります。デザイナ、エンジニアの評価エキスパートによって何か新たな評価方法を見出すことが出来ないか、模索する日々が続いているのが現状です。
「形成的評価」と「統括的評価」を分断せずに、それぞれの評価の負荷や考慮漏れが無いようにするにはどうすればよいのでしょうか。
過去の当社事例ではありますが、以下のような工夫によって課題を削減できないかトライしたケースを紹介します。

◆ HMI 開発フレームワーク・ツールへの利用時品質評価項目「HMI メトリクス」ロジックの導入

あらかじめ定義されたユーザビリティに関する「HMI メトリクス」を用いて開発工程にあるHMI 品質を開発ツール上で機械的に判定
モノやサービスの「品質」を数値的・定量的に評価する「メトリクス」の中でも HMI にフォーカスした「利用時品質」の特性に限定
対象となるデバイスの利用シーンを想定し、画面サイズ、視距離を基準値として設定することで判定基準へも適用　等

開発当時は反響も多く、設計・開発をしながら、仕様変更によって更新されるUI設計や意匠、機能も、毎回メトリクスを実行することで自動的にチェックが入り、「HMI メトリクス」の基準に反している箇所にアラートとその評価項目がわかり、効率性には非常に将来性を感じた取り組みでした。
しかしながら、ソフトウェア開発環境自体の進化が早く、様々なソフトウェアベンダーから新たな開発環境が登場し、OSS やシミュレータ等の活用も進む流れとなり、自社開発の開発ツール自体の拡張を続けることを断念することになったのです。
「HMI メトリクス」のロジックは変わらないものの、それを搭載する開発環境の進化、多様化までは予見できなかったことが反省点です。

ただ、この観点を取り入れた開発環境は、Web ベースのビジュアルテイスティングツールのような表層上のバグ検証は存在するようですが、おそらく現在も皆無ですし、当時より数年が経った今だからこそ、AI やクラウドを活用した自動化ツール上で再度トライ出来そうに思います。
上記のような構想に興味がある開発環境構築される方々、是非当社までお声がけください！色々ノウハウあると思います。

エンジニアリングの「フィジビリティ」観点の活用

「形成的評価」「総括的評価」の課題解決の手段はまだまだ検討が必要ではありますが、現在実践している「デザインエンジニアリング」での評価事例をいくつか紹介します。

◆ エンジニアの知識や観点を取り入れた「ヒューリスティック評価、分析」

ヒューリスティック評価は一般的にはユーザビリティのエキスパートが UI の原則やガイドラインに沿って課題を抽出しますが、この工程では、その課題をどう解決するのか、課題解決の為の技術的難易度や、代替手段までを想定することなく進めることも多いはずです。
まだ「発想」段階においては視野の解像度を粗く広い視点で進める必要もあるのですが、プロジェクトの状況次第では、解像度を上げて、優先度が高い課題にフォーカスすることも必要と考えます。この工程段階でも、ユーザビリティを「実現する」エンジニアのフィジビリティの観点を入れることで、ユーザビリティのエキスパートであっても、気付かない課題や解決手段に気付くことができるようになります。

例えば、ヤコブ・ニールセン博士がまとめた「10 ヒューリスティックス」の一つ、
「Flexibility and Efficiency of Use」（柔軟性と効率性）を例にすると、