デザインプロセスについて 4/4

ISOモデルとデザイン思考のモデルは設計に関するプロセスモデルだった。そのため、UXとの関係をもっと明確に示すことが必要であると考え、筆者は図のような開発プロセスモデルを提案した。

  • 黒須教授
  • 2020年2月12日

(「デザインプロセスについて 3/4」からのつづき)

デカゴンモデル

ISOモデルとデザイン思考のモデルは設計に関するプロセスモデルだった。そのため、(ISO規格のなかでは不明瞭な形でUXに関する言及が行われていたが)UXとの関係をもっと明確に示すことが必要であると考え、筆者は図1のような開発プロセスモデルを提案した(2020)。PDS、PDCA、PDSA、ISOのモデル、そしてデザイン思考のモデルとたどってきて、ISOやデザイン思考のようにデザイン(設計)だけのモデルではなく、開発全体のモデルが必要だと考え、また特にPDSの精神は現代も生きていると考え、独自の開発プロセスモデルを提案するに至ったものである。このモデルは開発プロセス全体をモデル化したもので、ちょうど10段階の10角形になるのでデカゴン(decagon)と呼ぶことにした。

図
図1 人間中心的な開発プロセスに関するデカゴンモデル

開発プロセスと設計プロセス

このモデルに示した開発という円のなかに含まれている白抜き文字の矩形10個からなるデカゴンが開発プロセスに含まれる活動である。このうち①企画(仮説生成)から⑥評価・検査までの6つの活動がデザイン(設計)に相当する。

10個の活動

簡単に10個の活動を説明しておくと、開発プロセスの最初は企画①(Plan)である。ここでは、その時点で利用可能な技術に関する知識が必要なので、技術から破線が出ている。また、仮説生成(Hypothesize)というのは、研究の場合同様、まだ成果(売れ行き)が実証されていない仮説を立てる段階だからである。

次に企画の方向に沿って②ユーザ調査(Survey)が行われる。焦点課題が企画によって与えられているので、それを具体的に展開したリサーチクエスチョンの設定から調査活動が開始され、インタビューや観察などの調査データが得られる。なお、調査においては、共感性(Empathy)や洞察力(Insight)が特に重要な役割を果たす。

次が③分析(Analyze)であり、調査から得られた情報を、KJ法やSCATで分析したり、コンテクスチュアルデザインのワークモデルにまとめたり、ペルソナ・シナリオを作ったり、ジャーニーマップを描いたりする段階である。

これによって調査結果の分析ができたところで、次に④着想(Ideate)に進む。ここはISOモデルで無視されていた部分だが、実は重要な活動段階である。また、そのためには直観(Intuition)が必要になる。この段階でも、技術と連動して、実現可能性を考えながら想を練ることが必要である。

次に⑤具体化(Give Shape)となる。デザイン案を作る段階である。これは着想と往復することもあるが、ともかくアイデアに「具体的な形を与える」ことが必要である。この段階は、(狭義に)デザインと呼ばれることもあるが、概念の混同を避けるため、あえてデザインとは呼ばず、具体化とすることにした。この段階では、当然、利用可能な技術を適用する。また、プロトタイピングを行って、徐々に具体化を進めてゆくやり方もある。

設計で忘れてはならないのが⑥評価・検査(Evaluate & Test)である。プロトタイピングを行う場合でも、評価によって確認する作業を抜きにしてはならない。当然、評価・検査で問題が見つかった場合には、具体化に戻り、そこに往復が発生する。ここまでの範囲が設計プロセスであり、そこにはPDSが含まれているし、評価・検査から具体化への戻りをActと考えるならPDCAが含まれていると考えることもできる。

次に⑦製造(Manufacture)となる。ここにも技術が適用される。ただし、ウェブサイトの構築のような場合には、具体化の段階が製造と同じことになるので、この段階をスルーすることになる。そして⑧宣伝・広告(Advertise)が行われる。

ところで、消費者やユーザのことを考えると、彼らは図1の左側のように、機器やサービスについて何らかの過去経験をもっていることが多く、それが次の購入の期待値に影響を与える。また、⑧宣伝・広告は彼らの期待に影響を及ぼす。このようにして、消費者の購入決定への道が開かれる。購入(ときには無料で入手ということもあるだろう)は、こうした期待と宣伝・広告の結果として行われ、さらに⑨営業・販売(Sell)によって促進される。購入・入手の段階でユーザとなった消費者は、実利用を開始する。サービスの場合には短時間のことが多いが、製品の場合には年の単位の長期間に及ぶこともある。そしてそれらの経験の印象がUXとなる。

このUXをERMのような評価法によって評価する(Get Feedback)ことが、開発の10番目の活動である⑩UX調査となる。そうやって得られたフィードバック情報は、当然、次の①企画に反映される。ウェブを使ったサービスデザインのような場合には、ここから③の分析に戻ってデザインの修正案を考えることもある。そうすることで迅速な最適化が可能になる。

このようにして10段階の活動によって構成されるのが、人間中心的ないしユーザ中心的な開発プロセスである。なお、⑩UX調査と②ユーザ調査は似たところもあるが、前者は、現行バージョンに対するフィードバック情報を得ることであり、何らかの仮説を検証しようとする活動ではない。後者は、次期バージョンに向けた情報の取得であり、仮説検証の目的を持っている。したがって、同等他社製品を調査することもあるし、まだ製品やサービスとして実現されていないものを調査することもある。手法的には類似した点があるが、姿勢や動機付けに違いがある。

デカゴンモデルとISO 9241-210:2019のプロセス

ISO 9241-210:2019のプロセスモデルとの対応を図2に示した。まず、①企画(仮説生成)が第6章の「人間中心設計プロセスの計画」に対応する。計画は英語ではPlanであり、それは企画をも意味する言葉である。

規格の第7章の「人間中心設計の設計」が②から⑥までの範囲に該当する。②ユーザ調査(共感、洞察)は7.2節の「利用状況の理解及び明示」に対応する。③分析は7.3節の「ユーザ要求事項の明示」に対応する位置にあるが、内容的には必ずしも対応していない。④着想(直観)は、ISOモデルで欠落している部分である。次の7.4節の「ユーザ要求事項に対応した設計解の作成」は⑤の具体化に対応しており、着想(直観)はその一部に含めて考えることもできる。しかし、やはり独立した活動段階として明示すべきだっただろう。⑥評価・検査が7.5節の「ユーザ要求事項に対する設計の評価」に対応する。

⑥評価・検査から⑤具体化への戻りは、ISOモデルにおける7.5節から7.4節への戻りに相当する。ただし、ISOモデルにおける7.5節から7.2節への戻り矢印は、設計活動のなかにあるのではなく、設計から一旦外にでて、⑦製造から⑩UX調査までの活動を経て、①企画(仮説生成)にもどってくる流れを意味している、と解釈するのが適当だろう。

図
図2 デカゴンモデルにおけるISO 9241-210:2019のプロセス

デカゴンモデルとデザイン思考のプロセス

デカゴンモデルとデザイン思考のモデルとの対応をとると、デザイン思考のモデルでは企画の位置づけが不明瞭になっている。①企画は、どのような利用状況にいるどのようなユーザにどのような人工物を提供するかを考える段階だから、当然プロセスモデルに含まれるべきであり、この点がデザイン思考モデルの弱点といえる。それ以降は原則的にこのデザイン(設計)の範囲に対応する。つまり、②ユーザ調査(共感、直観)は「共感する」に、③分析は「定義する」に、④着想(直観)は「考える」に、⑤具体化は「プロトタイプを作る」に、⑥評価・検査は「評価する」に対応している。

しかし、ISOのモデルもデザイン思考のモデルもデザイン(設計)に関するモデルであり、開発全体には及んでいない。図1から明らかなように、ユーザがUXを経験するのも、開発者がそれを調査するのも、デザイン(設計)の外側の活動である。もっと視野を広げ、開発全体に目を向けないとUXとの関係を明瞭に示すことはできない。その意味では、ISOモデルもデザイン思考モデルも、そこからUXについて言及するのは言い過ぎである、ということができる。

図
図3 デカゴンモデルにおけるデザイン思考のプロセス