デザインエンジニアリングに必要な「実現」手段
【目次】
Executive summary：「発想」を「実現」するためには ― 「発想」から、一歩二歩踏み込んで具象化し実現するには ―
システム／ソフトウェア製品品質「使用性」とは？ ― ISO/IEC25000「SQuaRE」―
企業が抱える課題解決のためのプロセスとして有効な「デザインエンジニアリング」。 第5回では「発想」を「実現」する手段に着目し、sdtech流のデザインエンジニアリングを解説します。
「発想」を「実現」するためには ― 「発想」から、一歩二歩踏み込んで具象化し実現するには ―
前回の第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シリーズ「利用者がある利用状況において、利用者のニーズに照らして、製品・システムを利用できる度合い。」
デザインエンジニアリング・コラボレーションツール①
前述した「使用性」を適切に設計し、実現するためには、第3回（発想を実現し確からしさを 高める「デザインエンジニアリング」）でも説明していますが、その後の工程の「実現手段」においてもデザインエンジニアリングを活用し、用途や工程に合わせた手段やツールが有効だと考えます。
実際に動作する基本部分を作りあげ、徐々に機能を追加し詳細化するトップダウン型と、部品を組み合わせて全体を構築するボトムアップ型があるプロトタイピングですが、ここではデザインプロセスの中の代表例を紹介します。
⚫︎ ペーパープロトタイピング
いわゆるラフスケッチ的にソフトウェアの情報構造やインタラクション要素を配置し、評価確認しながら改善点を見出す手法です。これはデザイナーならずとも、皆さんがホワイトボードを活用し協議しながら、初期段階のUIの方向性を定めるのに有効です。デザインエンジニアリング的に活用するならば、フロントエンド担当のエンジニアと共に、どれがユーザーが直接操作に関係しない部分なのかや、主要機能や共通化が有効となるコンポーネント、対象となるターゲットを見据えた 操作、振る舞い、などを意識しながら進めると、その後の画面設計工程でも効率的です。
⚫︎ WOZ法（Wizard of OZ）／アクティングアウト
音声インターフェース等対話型のシステム開発の初期段階にて行う方法で、利用者を想定した役割、利用者からのインプットからシステムとして判断した結果を利用者にどのようにフィードバックするべきか、それぞれ人間が代行し、あたかもシステムが動いているかのようにシミュレーションし、インターフェースの適否を判断する方法です。ある程度定まった要件があれば、特に何の道具もなく目指す対話型システムのイメージが掴める方法です。
デザインエンジニアリング・コラボレーションツール②
⚫︎ コラボレーション・インターフェース・デザインツール
Figma, XD, Sketch は近年機能進化を続けていて、設計から具象化するのに有用なツールでデザインリソースや配置に関する詳細情報なども出力することができ、アプリケーションエンジニアへの橋渡しツールとして充実してきました。
デザイナーが試行錯誤しながら基本設計をするツールとして、またはUIデザインが固まった段階で反映しデザインのマスターデータとして更新を続けることができるなど、用途は利用者次第ですが、利用する前にどこまでを開発にこのツールを担わせるか方針を決めておくことが重要です。PhotoShopで表層デザインを精緻化し、その精緻化した意匠をこれらツールに反映し、デザインデータとして出力するとなると、仕様改善や変更があった際に、またPhotoShopでの精緻化工程まで戻らないといけない等、デザイナーにとってはやや非効率に感じる流れにもなりうるので注意しましょう。
⚫︎ アプリケーションデザインツール
Figmaのようなツールと明確に名称表現が分かれているわけではないですが、Webブラウザやスマートフォンアプリケーション開発でも利用されつつあるローコード、ノーコードを特徴としたツールをここでは「アプリケーションデザインツール」と呼ぶことにします。
当社では「Storyboard」を使いアプリケーション開発で活用したこともありますが、Figma 等のコラボレーションツールとの親和性も考えると、基本機能実装段階までは効率的に進められるメリットはあると感じています。ローコード、ノーコードとはいえ、プログラム知識と経験がないと効率的に進められないアプリケーションデザインツールもまだありますが、SAP のように生成AIとの併用により進化は加速しそうに見えます。
デザインエンジニアリング・コラボレーションツール③
⚫︎ 統合開発オーサリングツール
XR やゲーム等のエンターテインメントに必要な表現力高い製品やサービス向け（Unity, Unreal-Engine 等）
多様なプログラム言語を対象にした高度な組み込みシステム開発向け（Qt Studio, KANZI Studio 等）
これらはシステム全体でもOS層から上位のアプリケーションまでの手段ではありますが、デザイナー、アプリケーションエンジニア、サーバーエンジニア、システムエンジニアで担当範囲を分けつつも、互いに具象化されたものを確認、評価し合えることが利用時品質の高い製品やサービスを実現するには有効です。当社もこれまで幾度とこの工程の効率化を図る為のソリューションとして「フレーム ワーク」という構造を持ち、上流工程と下流工程をつなぎ、デザイナーとエンジニア共通となるワークフローを実現してきました。
とても複雑で開発に数年を費やすような車載システム開発の場でも、このようなワークフローとツールの導入が進んでおり、コラボレーションツール、効率の良いシステム開発のワークフローツールはまだまだ進化をしていくことでしょう。
センサーデバイス（音声認識、温度湿度、位置情報）や特殊な操作デバイスとソフトウェア、ハードウェアとの組み合わせが必要な製品やサービスも、商用、量産開発のシステムを設計する前に、Arduino, Raspberry Pi などの開発ボード＆キットを活用する段階で、デザインエンジニアリングの現場では活用することも多いです。
エスディーテックの「デザインエンジニアリング」のゴール
これまで紹介した「実現」手段や開発環境やツールは、どれも世の中にあるものですが、デザインエンジニアリングを実践し、利用時品質の向上を目指すには、利用者の様々な用途や体験価値に応えると共に、どのようなターゲットで、システム環境で、どのようなチームでコラボレーションし、ワークフローを設計するか、臨機応変に手段を変える必要があります。これにより、多種多様な要求にこたえることができる「デザインエンジニアリング」が実践できると考えています。
エスディーテックのデザインエンジニアリングのゴールは「いかに利用時品質を高めるか」だけではなく、「利用時品質の高い製品やサービスをどうローンチさせるか」も達成することです。その為にはデザイナー、エンジニア、そしてプロジェクトマネージャーであってもこれまでの 役割の範囲を超えたタスクや互いに協力し合うことで達成できるタスクにチャレンジできるマインドセットも重要だと考えています。
次回最終回『第6回：デザインエンジニアリングに必要な「評価」手段』では、定性的・定量的な評価方法の例を交え、一連のデザインエンジニアリング・プロセスとサイクルが少しでもご理解いただけるようご紹介させて頂きます。
本ページの内容をPDFでダウンロードすることができます。
関連記事
Design Engineering vol.1:
企業、開発者、ユーザーの未来に喜びをもたらす「デザインエンジニアリング」
Design Engineering vol.2:
Design Engineering vol.3:
Design Engineering vol.4:
Design Engineering vol.6:
デザインエンジニアリングに必要な「評価」手段 （公開予定）
最新記事の公開時など、エスディーテックの最新ニュースをメールマガジンにてお知らせ致します。メールマガジンをご希望の方は、以下よりお申し込みください。
エスディーテックへのお問い合わせはこちら
White Paper
【解説】デザインエンジニアリングに必要な「実現」手段
2024年7月25 日