White Paper
【解説】デザインプロセスの欠点と、それを補うデザインエンジニアリングとは
2024年1月12日
発想を実現し確からしさを高める「デザインエンジニアリング」
【目次】
デザインプロセスの欠点と、それを補うデザインエンジニアリング
中流工程があることを認識し、開発に必要なアイテムを作り試し組み立てる
デザイナー・エンジニア双方で要件/ 目的をしっかりと捉える為に
企業が抱える課題解決のためのプロセスとして有効な「デザインエンジニアリング」。 第3回では発想を実現し確からしさを高める「デザインエンジニアリング」と題して、デザイナーとエンジニアの役割や共創により発揮される効果などを解説します。
デザインプロセスの欠点と、それを補うデザインエンジニアリング
デザインエンジニアリングの中でも重要な工程の１つとして、定めた要件や要求の中でも、実現可能性や課題に対して技術検証が必要な要件や描いたユーザー体験が狙い通りに体験できるか、これらを考察し、その効果が発揮できる工程があります。 ユーザーとシステムのインタラクションを実際の運用環境を想定して試すことが大切です。プロトタイプや実利用が想定される環境の上で、早期に試せることは試し、疑似的にでも相互のインタラクションを評価することで、要件や課題の抜け漏れを発見することが多々あります。
デザインプロセスの中でも、「ラピッドプロトタイプ」「紙芝居的モックアップでの基本的、正常系のフローの確認」「OZ 法によるフィードバックの再現、課題発見」「デザインツールやそこから出力されたプロトタイプによるユーザーインターフェースの評価」等の評価ツールを構築し、試すことで、確からしいシナリオの流れを把握し、ユーザ体験を評価 することは可能です。 しかし、システムや運用環境、そのシステムを取り巻く実際の運用状況を考えると、限られたテスト環境の中では発見できないシステムの課題が残されてしまう、というのがデザイナー主体で進むデザインプロセスの欠点です。
具体的には、「インストラクションメッセージの必要度合」「通信から取得する情報の表示までのタイムラグ」「操作の流れを考慮した上での適切な情報量」「実際の運用環境を想定した場合の課題」（例えば、会員登録やログイン周り、セットアップ手順など、ここは既に用意されたフローがあるので試す必要が無いとされて、ユーザーテスト段階ではスキップや省略されてしまうことがある。）など、それらを表層的なプロトタイプによる評価や観察だけではシステムも含めた想定するユーザー体験の確からしさは高められないという欠点です。
このあたりのシステム開発時や運用環境上の蓋然性は、想定し ていたことよりもギャップがを多いことが後工程で明らかになるケースは多く、実際に使う環境に近いシステム上で試作し評価を行うには、デザイナーだけでは準備、実施することができませんが、エンジニアが関わることで、近い環境を想定した作りの上で試すことができ、抜け漏れ、考慮漏れに気付かされることが多いことが実態です。
製品やサービスの本質的な要件 / 目的を捉えて具象化する
限られた時間やコストの中で用意できる「試してみる」環境を用意することは難しいのですが、少なくとも、本質的な要件や目的を捉えて具象化することにフォーカスし、要件の中でもっとも重要かつ、製品の本質的な特徴や機能だけでも、抜け漏れ無いように潰しておきたいものです。「試してみる」部分を精査してみると大掛かりなモックアップを仕立てるまでもない場合もあると思います。
例えば、対象となる製品やサービスの新たな「体験価値」が検討する重み付けが強いのであれば、
・その製品やサービスを知る機会は何か
・その製品やサービスを入手する方法は適切か
・その製品やサービスの「価値」を試すまでのステップは複雑ではないか
・その製品やサービスの「価値」を体験した上でユーザーは何を求めるか
このあたりの一連のフローを具現化し、評価する必要があります。
また、既にある製品やサービスの特徴的かつ新たな機能や性能を検討する必要があれば、
・その機能や性能を試すまでのステップは複雑ではないか
・その機能や性能が期待値まで達するか
・その機能や性能を感じたユーザーが次に期待するものは何か
など、本質的な部分にフォーカスして「確からしさ」を高めることに注力できることもあります。 製品やサービスの「戦略・要件」を開発者であるデザイナー・エンジニアとも共有し、「何を試すべきか」協議できることで、優先度や重み付けを考慮したモックアップが実現できると考えています。
上流工程の成果を「開発で使える」ものとするには
上流工程の中で定めた成果だけでは、開発工程では「作る上での情報」として足りない成果が多いことが現状で、その為の手戻り対策や想定外のドキュメントを新たに用意する必要が出てしまうケースがあります。
よくある上流プロセスの成果としては、デザインプロセスを経た上での「画面設計」「画面遷移仕様」「意匠仕様」等がありますが、画面の中にUI部品が実際にどのように動いてほしいのかによっても実装難易度や方法も変わってしまいます。UI部品が押下されたタイミングで、コンマ 0.3msec 以内に画面遷移しトランジション演出がどのくらいの尺で再生され、次に登場する画面の中でどのような順番で、その画面を構成するUI部品たちが出現するのかが分かりにくく、開発チーム自体で定義し実装することで、デザインチームの意図とは乖離することもあります。 エンジニアが実装設計に入る前に、要件に基づきどのような成果が情報として必要か認識を合わせておくことが必要です。
中流工程があることを認識し、開発に必要なアイテムを作り試し組み立てる
一般的に、長い開発期間の中では、デザインとエンジニアリングの役割やスキルの活用度合い、責務は変わるので、「上流」「下流」という表現で開発プロセスを語ることは多いと思いますが、我々は分けて考えてしまうと弊害が生じやすいことを経験しています。緩やかに役割は変わるものなので、分ける表現は適切ではないと思うものの、上流で定めた事柄を下流に引き継ぐタイミングはあるので、そのタイミングをあえて表現するならば「中流工程」とここでは表現します。
上記の中で、デザインチームと実装チームが分かれている（もしくは別会社）のケースでは、用意できていないものも多く、後工程で認識違いが出てくることが多いことで、開発工程に影響を与えます。 デザイナーが実現できないことが早期に試せたり、準備しておくことができるのが何よりもデザインエンジニアリングのメリットであり、エンジニアと共に、ユーザーが利用時に体験するワンシーンを上流工程から把握し共に協議することで、よりよくするための創造性や工夫所に向けて早い段階で心構えておくことが、利用時品質を向上させる為には必要なのです。
デザイナー・エンジニア双方で要件 / 目的をしっかりと捉える為に
デザイナーとエンジニアは当然バックボーンも違えば、身に着けたスキルや考え方のアプローチも違うこともあるので、開発プロセス上も交わる機会も少ないのが一般的だったと思いますが、近年は「体験価値」という顧客要求に応えていく業務も多く、上流型の思考方法が双方で活用する必要も増えていると思います。
デザイナーもエンジニアも「開発者」です。同じ製品やサービスを作り上げる為に共に協力しあうことが必須なのですが、当社でも長年共に開発をしていても、ある要件に対して「考え方や捉え方」が違うな、と思うことがあります。エンジニアから見てデザイナーは「ふわっと、もやもや」していると思われるし、デザイナーから見てエンジニアは「極論・結論」に急ぎ過ぎ、と思うこともあります。目的は共通認識しているのに、と。
デザインプロセスは帰納的なアプローチだと考えていて、事実の上で考察し、仮説を生み出す方法です。 一方、エンジニアリングプロセスは演繹的に、一般化された事柄を仮定し、その中の事実を元に結果を生む方法の場合があると感じています。また、実開発の中で、最後までタスクをもって業務を行うエンジニアは結果を重視しなければならず、よりよい製品やサービスを提供する責務を担うデザイナーとはプロセス上担う責務範囲も違います。
このような責務範囲の違いを、議論の中で観点を合わせるにはどうしたらよいか、分かりづらいかもしれませんが、少し掘り下げていきたいと思います。
デザイナーの観点とエンジニアの観点①：思考法の違い
帰納的：観察の結果と過去の経験から得た情報を組み合わせて結論を導く思考法
演繹的：理論、仮説、一般化から出発し、観察やデータ収集を通じてそれを検証する思考法
例えば、機能的なアプローチのデザインは、 「スマートフォンの操作、振る舞いは慣れ親しんだ人が多い」（観察や経験から得た事実） 「スマートフォンは幅広い世代に浸透しつつあると考えられる」（調査やアンケートから導く仮定） 「スマートフォンの操作、振る舞いはスマートフォン以外のデジタルデバイスでも受け入れられるのではないか」（事実と仮定を組み合わせ結論づけた仮説）
一方、演繹的なアプローチのエンジニアリングは、 「タブレットデバイスは幅広い世代でも使えている」（一般的な仮説） 「スマートフォンも幅広い世代で使っていて、操作や振る舞いもタブレットデバイスと同じだ」（仮説に当てはまる事実や事柄） 「タブレットデバイスをオーダー端末にしても、幅広い世代で扱うことができる」（仮説と事実から導いた結論）
1段目の論法は、双方違う"対象"の話をしている 2段目の論法は、受容性と操作性、違う"性質"の話をしている 3段目の論法は、"仮説"段階の話と"結論"段階の話をしている デザイナーは「必然性（そうなることの有無）」、エンジニアは「蓋然性（そうなることの高さ低さ）」の話をしているようにも見えます。 俯瞰してみると、同じ話をしているとも思えるのに、思考する順序や観点が違います。 実開発プロジェクトの議論の中でも、こんな一見食い違いのように見えることがあると思います。
デザイナーの観点とエンジニアの観点②：アブダクション
デザインエンジニアリングでは、前述（第2回）した "UX5階層" のようなフレームを想定し、双方、今どの段階の決め事を議論しているか認識を合わせて進めることができ、観点の違いを認識することで、新たな仮説や事実、結論に着地できる場合もあります。 仮説が結果に当てはまる規則を推論するアブダクション（仮説的推論）に近い推論ができるようになると考えています。
アブダクション 「あのオーダー端末は楽しみながら商品を注文でき、とても好評のようだ」
→誰もがそうだと思える事実 「操作方法や演出がスマートフォンのゲームアプリのようで、それが好評なのではない か」
→そうだと思える原因や理由 「直感的な操作と演出があれば、オーダーもストレス無くでき、楽しい時間を演出してくれるだろう」→適応できるアイデアの発見・創出
デザインエンジニアリングを実践していくと、このような探求・創造のプロセスが踏めるというメリットがあると感じています。 なかなかこのように論理的な議論ができる実際の開発現場は多くはないのですが、いいアイデアが生まれたときは、意識していなくとも、アブダクションのような推論が出来ているのかもしれません。
このような議論を経て、本質的な要件や新たなアイデアをデザイナーとエンジニアが共にプロトタイピングをして、より「確からしさ」を高めることがデザインエンジニアリングの役割であり、効能だと感じています。
次回（第4回目）のホワイトペーパーでは、その他の「発想法」にも着目し、sdtech流のデザインエンジニアリングの理解を高めて頂ければと思います。
本ページの内容をPDFでダウンロードすることができます
関連記事
Design Engineering vol.1:
企業、開発者、ユーザーの未来に喜びをもたらす「デザインエンジニアリング」
Design Engineering vol.2:
Design Engineering vol.4:
Design Engineering vol.5:
Design Engineering vol.6:
デザインエンジニアリングに必要な「評価」手段 （公開予定）
最新記事の公開時など、エスディーテックの最新ニュースをメールマガジンにてお知らせ致します。メールマガジンをご希望の方は、以下よりお申し込みください。
エスディーテックへのお問い合わせはこちら