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

企業が抱える課題解決のためのプロセスとして有効な「デザインエンジニアリング」。第5回では「発想」を「実現」する手段に着目し、sdtech流のデザインエンジニアリングを解説します。

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

PDFダウンロード

こんな方にお勧めです

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

「発想」を「実現」するためには　― 「発想」から、一歩二歩踏み込んで具象化し実現するには ―
「機能要件・非機能要件」の優先度を決める
システム／ソフトウェア製品品質「使用性」とは？　― ISO/IEC25000「SQuaRE」―
デザインエンジニアリング・コラボレーションツール①
デザインエンジニアリング・コラボレーションツール②
デザインエンジニアリング・コラボレーションツール③
エスディーテックの「デザインエンジニアリング」のゴール

「発想」を「実現」するためには　― 「発想」から、一歩二歩踏み込んで具象化し実現するには ―

前回の第4回『デザインエンジニアリングに必要な「発想」手段』では、主にデザイン、開発の本来の上流工程として「何をどのように発想し実現を目指すか」を見出す為のデザインエンジニアリングを説明してきましたが、今回は「では、それをどう実現するか」を紹介します。

第４回の記事はコチラから

昨今、製品やサービスで必要となるアプリケーション開発では、要件定義、デザイン設計で定めたものをプロトタイプ化し、盛り込まれた要件の妥当性を評価する工程まで、様々なツールやサービスを活用することで「容易」とは言わないまでも、開発チームの中でデジタライズに進めることで効率化が図られるようになってきました。前工程で生み出した「発想」を机上の話だけで淘汰せず、体感できるものにすることで、具体化するにあたり改善点やより良い要件が見出すことができ、「実現」に向けての優先度が付けられることも重要です。

例えば、モバイルアプリケーションの場合、OSも違えば、画面サイズも違い、綿密なリソース群を考慮して用意する必要と、それが対象となるデバイスで実際に実現できるのか、考慮することに多くの時間とコストを費やす必要がありましたが、今では様々なプロトタイピングツールが世の中に広まり、デザイナーは「コンセプトを定義し、表層を整える人」から「抽象から具象」化することもスキルとして必要となり、UX, つまり満足度の高いユーザー体験を定義し、どうそれをシステムとして実現するかが担当領域の主流へと幅が広がっています。

「機能要件・非機能要件」の優先度を決める

元々Webデザイナーはある程度ブラウザの仕様や性能、そして制約を考慮し、HTMLやscriptを駆使していたので、実現するための手段の飲み込み度合いはシステム開発においても早いと言えると思いますが、グラフィック専門、プロダクト専門、エディトリアル専門などのデザイナーはシステムで実現する上で考慮・配慮しておくデザインデータ設計に関しては、従来あまり知識を持ち合わせていませんでした。
現在「実現」するためのスキルセットは、デザイナーであってもプロトタイピングツール等により発揮され、コラボレーションできるツールへと進化し、エンジニアと対話しながら「実現」できる「手段」となったのです。

但し「実現」する上での「設計」は、画面設計、画面遷移、デザインデータの詳細設計等が詳細情報として必要で、プロトタイピングツールだけでは、「実現」する上で十分な情報が網羅できるというものでもありません。より綿密に、より多い仕様が網羅されていることに越したことはないのですが、実際の開発現場では、製品やサービスのリリーススケジュールや予算を踏まえて計画する必要があり、機能や適切なUI, 魅力となりうる演出の必要性に優先度を付けて仕様を落とす必要もあるのが現状です。

その中でも「非機能要件」は仕様書やプロトタイピングでは定義しにくく、言語化できない演出要素もあります。これらをエンジニアリングとどう組み込むのか、デザインエンジニアリングの例を紹介したいと思いますが、その前に、システム／ソフトウェア製品品質においても「非機能要件」に近い、8つの品質特性の1つ「使用性」について説明しておきます。

システム／ソフトウェア製品品質「使用性」とは？　― ISO/IEC25000「SQuaRE」※1―

開発の上流工程から関わっていなかったエンジニアからみると「機能要件」はシステムを品質良く作り出す責務が重要で、「非機能要件」という「利用時品質」に関連する副特性的な要件は、優先度を下げざるを得ないし、顧客側からも重要視されないことがあります。
昨今、アプリケーションの振る舞いに慣れたユーザーにとっては、一見優先度が低いと思われる演出的要素も、ユーザーからの高評価の一因を占めることがあります。システム／ソフトウェア製品品質の中でも「使用性」の中に、これらを「ユーザーインターフェース快美性」として定義している国際規格「SQuaRE」シリーズがあります。ユーザーに楽しさや満足度を与える為のユーザーインターフェースに、美的かつ魅力的であるかがシステム／ソフトウェア製品品質にとっても必要で、8つの品質特性の1つとされています。

※1　SQuaRE : Systems and software engineering Systems and Software Quality Requirements and Evaluation
ISO/IEC25000シリーズ「利用者がある利用状況において、利用者のニーズに照らして、製品・システムを利用できる度合い。」

続きをご覧になりたい方はこちら