デカゴンモデルの改定

以前、デザインプロセスについて小連載したときにデカゴンモデルを紹介したが、その後、このモデルの修正すべき点について幾つか気がついたので、その修正点について紹介しておきたいと思う。

  • 黒須教授
  • 2020年10月20日

以前、デザインプロセスについて小連載したときの4回目で、デカゴンモデルを紹介したが、その後、HCD-Netの関西支部で「デザイナーは何をすべきか-UX原論の視点から」というオンライン講演を行った。聴講した皆さんからはわかりやすいと好意的に受け止めいただいたのだが、録画講演の形で実施しながらデカゴンモデルの修正すべき点について幾つか気がついたので、スライドを訂正した。併せて、ここでもその修正点について紹介しておきたいと思う。

1. UX調査から企画に至るパス

まず、元のモデルだが、図1のように⑩のUX調査からは①の企画と③の分析に矢印がでていた。これは、通常(製品の場合など)なら①の企画に戻って企画をやり直し、次のバージョンについて検討を行い、以後、②③④と開発を進めてゆくという意味と、急ぐ場合(サービスの場合など)には、いちいち企画をやり直さず、UX調査の結果を③の分析に送り、迅速に具体化をやり直して市場に提供するという意味を込めたものであった。

図
図1 デカゴンモデルの最初のバージョン

しかし、これだと⑩のUX調査から③の分析に至る場合は、調査結果をちゃんと分析することになるが、①の企画に至る場合は、分析を行わず、UX調査から直接企画に進んでしまうことになる。調査結果の分析を行わずに企画の作業が行えるように見えてしまうわけだ。やはり、これではおかしい。ということで、⑩のUX調査を行ったら、必ず③の分析に至るべきだと考えて、⑩のUX調査から①の企画に至る矢印を削除した。

ただし、そうなると、③の分析から①の企画に至る矢印が必要になるわけで、それを追加することにした。この矢印については、①の企画から②、③と進んで、ワンパスで④の着想に至るようになってしまう点も改善する意味が込められている。もともとユーザ調査というものは一回だけ実施するものではなく、ざっくりした調査を行って、焦点をより明確にした段階で改めての調査を行うという繰り返しが存在するべきなので、①の企画の段階は、②と③の一群をまとめたものと考えることができる。したがって、モデルを図2のようにすれば、①の企画と②のユーザ調査と③の分析とがサイクリックになり、一群としてまとまることになる。もちろん、⑩のUX調査から③の分析を経て、①の企画に戻らずに、そのまま④の着想に至る流れは残されている。

図
図2 デカゴンモデルの改訂版

2. 評価・検査の位置づけ

図1のモデルでは、⑤の具体化と⑥の評価・検査との間には往復する双方向矢印があった。これは反復的設計に欠かせないものだ。そして⑥の評価・検査を経た後は、⑦の(製造)を経て、⑧の宣伝・広告に至るようになっていた。⑦の製造は( )付きになっているが、これはハードウェア特有のもので、ソフトウェアやサービスなどには特に存在しないと考えたからだった。しかし、ソフトウェアでも製品として出荷するためにはいろいろと調整することもあるし、サービスでも実地に運用を開始しようとするとやはり調整を要する場面がでてくる。その意味ではカッコは外したほうが良いのかもしれなかった。

また、そうした調整はハードウェアでももちろん発生するが、その結果、設計時に考慮したユーザビリティが損なわれるようであってはいけない。したがって、⑦の製造を行う段階で、やはり⑥の評価や検査が必要になることも多いと考え、⑦から⑥への矢印を追加することにした。さらに⑥の評価や検査と⑤の具体化の間の双方向矢印も、行ったり来たりするという意味を明示するためには、2つの矢印に変えた方がいいかと思われた。そのように考えた結果、⑤の具体化と、⑥の評価や検査、⑦の製造の間には戻り矢印を明示することにした。

3. その他

もちろん、細かいことをいえば、⑥の具体化と④の着想の間には戻り矢印が存在した方がいいとか、⑧の宣伝・広告において、設計段階でのコンセプトが明確に示されているかどうかを確認するとか、⑨の販売店での実査によってフィードバック情報を得るとか、細かい矢印を加えることも考えられたのだが、あまり図が複雑になるのもモデルのわかりやすさを損ねることになると考え、それらは明示しないことにした。

ただ、一つ追記しておくべきなのは、このモデルの各段階、または複数段階のブロックは、担当者が異なることが多く、そこでの意思疎通が不十分になってしまうことが多いという点だ。これは企業活動においては不可避でやむを得ないものだともいえるが、すべての段階を全員でぞろぞろと実行するのは非効率だし無駄といえるものの、その仕事を特に開発全体を俯瞰するデザインマネージャの分掌として強調しておく必要はあるだろう。デザインのつかないマネージャでもいいが、ともかく設計内容を一気通貫で把握し、その行く末をユーザに手渡すまで、いや、ユーザが利用した⑩のUX調査の段階まで、きちんとフォローしておく人が存在することはユーザ中心的な開発においては必須のことといえるだろう。今は、そうした人材がそのような権限をもって開発全体に入り込んでいることは少ないかもしれないが、これは是非とも改善してゆくポイントといえるだろう。