DXプロジェクトにおいて、なぜデザインリサーチが重要なのか？
アンカーデザイン代表の木浦です。
世の中におけるDX（デジタルトランスフォーメーション）の盛り上がりとともに、弊社でもDX関連と言えるようなご相談が増えつつあります。デザイン会社なのにDXって関係あるの？という声も聞こえてきそうですが、実はDXとデザイン、特にデザインリサーチには切っても切れない関係があります。
先日、総務省の外郭団体である行政情報システム研究所から「GDX：行政府における理念と実践」と題する報告書が発表されました。この報告書の中でDXとは「ユーザー中心」なるキーワードを用いて説明されています。
「ユーザー中心」が意味するところは受け手によって若干解釈に幅があるものの「ものづくりのプロセスの中心にユーザーを据え、ユーザーにとって必要なプロダクトを、ユーザーと一緒に作ること」であると説明できるでしょうし、これはすなわりデザインリサーチのことであるとも捉えることができます。
これは近年、DXプロジェクトと合わせて語られることの多いデザイン思考やリーンスタートアップ、そしてスクラム開発手法に共通する思想です。ユーザー中心や人間中心的なリサーチ手法はまさに私達のようなデザイン会社が得意とする領域であり、私達のようなデザイン会社にDXに関する相談を多数頂く状況を鑑みても、このことは一定程度、社会の中で認知されつつあるように思います。
そこで本記事では、DXプロジェクトにおけるデザインリサーチ、つまり、ものづくりの中心にユーザーを据え、ユーザーを巻き込みながらプロジェクトを進めることにどのような意味があるのかを、大きく3つ分けて説明させて頂きたいと思います。
価値のあるソリューションを見つけだすために
DXプロジェクトを推進する上で重要であり、かつそれなりに難しいことは、そもそも「何をすればいいのか？」を考えるフェーズではないかと思っています。
企業の上層部においてもDXの重要性が認知され、予算がつき、DX推進部などの専門部署が社内で設立され「DXをやれ！」と言われたはいいものの、何をすれば良いのかわからない。このようなケースは珍しくないはずです。
DXではユーザーのことを知る事が重要
このフェーズにおいてユーザーを巻き込むとは、自分たちの妄想でコンセプトを作るのではなく、自分たちが価値を届けようとする人々を知ることを意味します。その手法としてはインタビューのこともあれば、オブザベーションなどのこともありますし、ワークショップを実施することもあります。いずれにしても社会の中で実際に働いたり、遊んだりと毎日の生活を送っている人々を理解することが大切です。様々な調査を通して得られた知見（インサイト）をもとに、人々が持っている課題やニーズを探し出し、コンセプトを探します。
DXプロジェクトにおけるユーザーは会社の中にもいる
なお、私たちは「ユーザー」なる言葉を使ったときに、会社の外に居るお客さんのことを想定してしまいがちですが前述した「GDX：行政府における理念と実践」では、企業や行政の中に居る人のことを「内なるユーザー」と称しています。
DXプロジェクトにおいて私たちは、つい自分たちの顧客に対して何らかのソリューションを提供することをイメージしてしまいがちですが実際のDXプロジェクトは社内向けであることも珍しくありません。
例えば従業員の働き方を変革することであったり、チームの組織のあり方や仕事の流れに対して新しいソフトウェアや仕組みを導入することで従業員がより気持ちよく働けるようにしたり、業務効率を向上させたりするようなものが挙げられるでしょう。
ユーザーが中に居ても、外に居ても、考え方は同じ
このようなケースにおいてもユーザー中心の考え方はもちろん適用することができます。社外の顧客むけに提供するコンセプトを検討するときには社外の顧客に対してインタビューを実施することが一般的だったと思いますが、このインタビューの対象を社内の従業員に設定すれば良いのです。
従業員にインタビューを実施したり、あるいは仕事の様子を観察したりすることによって業務を進める上での課題やイノベーションのための機会領域を見つけ出し解くべき問題を設定します。これらのプロセスはリサーチ対象が社内か社外かの違いだけであり、いわゆるデザインリサーチのプロセスがほぼそのまま利用できることがイメージつくかと思います。
過去のプロジェクトで私たちはコールセンターや小売店舗、営業部門などで働く従業員の方を対象にリサーチを実施し、DXの施策を提案、実施させて頂いたことがあります。内なるユーザー向けの体験向上のためにデザインプロジェクトを実施することは全く珍しいことではないのです。
必要なスペック・機能を見出すために
ユーザーを理解して彼らに対して必要と思われるコンセプトを作ったそのあとには、それを実現するために細部の検討を進めなければなりません。
ユーザーとして想定する人々がA地点からB地点までもっと楽に、早く移動できる手段があったら喜ぶだろうとの考えに至ったとして、実際に新しい移動手段を具体化する際には、適切な「スペック」はなにか？を考える必要があります。。
ユーザーと一緒にスペックを決める
新幹線や飛行機のような移動手段は素晴らしいものですが「近所のコンビニにちょっとコーヒーを買いに行きたい」というニーズにはマッチしないでしょう。最近話題の電動スクーターは非常に楽しい乗り物ですが、大阪東京を往復したいというケースではおそらく他にもっと良い移動手段があるはずです。
どれぐらいの速度で移動できればユーザーは価値を感じるだろうか？どれぐらいの移動距離を移動できればユーザーは価値を感じるだろうか？荷物の積載量はどれぐらいが必要だろうか？ユーザーはいくらぐらいまでならこのプロダクトに払ってもいいと思うだろうか？コンセプトを具体化する上で、検討しなければならないことは無数にあります。
近年ではDXプロジェクトを進める上で、あるいは理想的な体験を実現するためにAIなどが必要になるケースもあります。AIが必要となるケースも多く見受けられます。AIの開発はいわゆるシステム開発とは異なる勘所が必要になるケースもあります。
例えば、ソリューションを構築するために画像認識（コンピュータービジョン）に関するアルゴリズムが必要だとして、その認識精度はどの程度あればユーザーは価値を感じるのだろうか。認識のスピードはどの程度あればユーザーの体験が損なわれないだろうか？画像認識アルゴリズムに対する入力（例えば画像の解像度や撮像条件など）と、その出力はどのようなものが望ましいだろうかなど、AIを開発したり、あるいは選定する際の条件を定めるためにユーザーを巻き込むようなシーンも珍しくありません。
これらは当たり前ですが、パワーポイントの上で資料を作っていても見えてきません。ユーザーを巻き込みながら検討することに勝ることはないのです。
ときにはプロトタイピングを通してスペックを決めることも
場合によってはユーザーに対するインタビューだけで必要なスペックや機能を見出すことは難しいかもしれません。その際にはプロトタイピングが必要なケースもあるはずです。プロトタイピングとはクイックにものを作る行為として捉えられがちですが、プロトタイピングの狙いとしては作ろうとしているプロダクトが人々に受け入れられるか、プロダクトに求められる機能やスペックはどのようなものなのかを見出す仮説検証のことと言っても良いでしょう。
手戻りを最小限にするために
どれほど綿密にユーザーのことを知り、彼らに必要だと思われるものをと作ったとしても、最終的にソリューションを評価するのはユーザーです。どれだけ「ユーザーために」と思っていたとしても、それがユーザーに受け入れられなければ、それはソリューション提供側の自己満足であるとも言えるでしょう。
もちろん、実際に作ってみないとわからないことは少なくありませんし、新しい試みには失敗がつきものです。そのため、どれほど自信のあるコンセプトであってもいきなり大きく投資するのではなく、小さくはじめて大きく育てて行くのが望ましいでしょう。
まずは最低限の製品を作り育てていくことが重要
この際にポイントとなるのもやはりユーザー中心であることです。下記はHenrik KnibergさんによるMVPの考え方を示す有名な図です。
上も下も車を作るプロセスですが、プロセスに大きな違いがあります。上のプロセス（Not Like this）は車を作る際にタイヤを作って、シャシーを作って。ボディを作って…のような順序で車を作っていますが、ユーザーがその製品の価値を享受できる最終ステップになってからです。これでは最終的な製品がユーザーにとって満足できるものなのかどうかわかるのは、最後の最後です。一般論として、プロダクトを作り込めば作り込むだけプロダクトの修正に必要なコストも大きくなりますから、このようなプロセスでプロジェクトを進めると修正が必要となった場合は大きな手戻りが発生するかもしれません。
フィードバックを得ることでユーザーに喜ばれるものを作る
下のプロセス（Like this！）では、最初の段階から製品としては十分ではないかもしれませんがユーザーが何らかの形で試用できるようになっています。そしてユーザーのフィードバックを受けつつプロダクトの完成度を高めることができます。
なかなか気づかれませんが、最終的に出来上がるプロダクトは上と下で違います。上は屋根付きのオーソドックスな自動車ですが、下はオープンカーです。これはものづくりのプロセスの中で「風を切って走るのは気持ちいい」とユーザーが気がついたからかもしれませんが、その結果としてユーザーの表情も明らかに異なります。プロダクト提供側の思い込みだけで車を作ってしまうと、ユーザーがほしいのはオープンカーであるというアイデアにはなかなか思い至らないかもしれません。
まずはクイックにプロトタイプを作って、人々からフィードバックを得ること。そしてそれをもとにプロトタイプをブラッシュアップしていくこと。これによって本当にユーザーが欲しいものに辿り着ける可能性が高まるということを、この図は表現しているようにも取ることができます。
おわりに
プロセスの中で何度もユーザーとの対話を繰り返すことは一見面倒で遠回りであることのように感じるかもしれませんが、ユーザーに受け入れられるソリューションを作るためにはものづくりのプロセスの各ステップにユーザーを巻き込み、ユーザーと一緒に良いものを作ろうというマインドセットが不可欠です。
もちろん、ユーザーを巻き込むと言っても、なかなか最初はハードルが高いものです。企業の場合はさまざまな制約（予算やルールなど）もあるでしょうし、巻き込み方についても実際どうしらたいいか見当もつかないかもしれません。
私がご相談を受けたときにまず申し上げているのは、まず実施してみることの重要性です。インタビューひとつ取っても、慣れ不慣れやスキルの問題はあるかもしれませんが、目の前にいる人を1人の人間として尊重し、彼/彼女がどのような生活を毎日送っており、何を考えているのか。どのようなニーズや要望を持っているのかについて興味を持つことさえできれば、これだけで大きな失敗が起こることを防げるはずです。
プロトタイピングの重要性については本記事の中でも言及したところですが、ものづくりのプロセスやユーザーの巻き込み方そのものについてもプロトタイピングの考え方が適用できます。まずはやってみる。そしてそれを徐々に改善して行くことができれば、最終的にはユーザーに受け入れられるプロダクトを提供できるようになるのではないかと考えています。
なお、最後に宣伝となってしまい恐縮ですが、デザインリサーチについては下記の本で詳細に説明させて頂いておりますので、興味を持っていただいた方はぜひ書店などで手にとって頂けると大変うれしく思います。
この記事が気に入ったらサポートをしてみませんか？