デザイン思考について，考えたこと

　　ナラベルWebサービスとの連携エントリーです。　

＊本稿では，デザイン思考の詳細については触れていません

　デザイン思考については，5年ほど前に初めてそのコンセプト的なものを読み，これまでの経験と照らし合わせて，システム運用・開発の過程で参考にしてきましたが，正確に理解して役立てるのは，なかなかに難しいと思うことしばしば。これまでのキャリアがのシステム設計・開発のビジネスロジック部であることも，デザイン思考を上手く消化できない理由の一つかもしれません。そこで，かなり手垢がついたケースではありますが，「空港の荷物待ちクレーム解消」の事例を取り上げながら，デザイン思考について，少し考えてみたいと思います。

　ヒューストン空港は以前より「手荷物引渡所の待ち時間が長い」と、ユーザーからクレームが絶えなかった。ヒューストン空港もスタッフを増員させるなどの改善策を試して、待ち時間を10分以上から8分程度まで短縮させることは成功したのだが、クレームの数は減らなかった。
　そこで、ヒューストン空港がとった策が「到着ゲートから手荷物引渡所への移動距離を伸ばす」という方法だった。到着から手荷物を受け取るまでの総時間は変わらないのに、クレームの数はほぼ0にまで減少したというのだ。空港到着後、以前なら「引渡所で待っている」時間を、ユーザーは自らの足で移動することで時間を使い、引渡所での「待ちぼうけ」の時間をなくしたのだった。

デザイン思考のこと

　デザイン思考では，１）共感　２）問題・課題定義　３）概念化　４）プロトタイプ　５）テストの５つのステップを行き来しながら問題解決を目指していきますが，２）問題・課題定義が全体の成否を握っていると個人的には考えています。なぜなら，情報過多の現代においては，競合相手を圧倒的に凌駕するような画期的かつ合理的ソリューションを生み出すのは容易ではなく，故に競争に勝つためには，問題・課題定義によって他者と差別化し，合理的思考が導くソリューション以外の選択肢をより多く持つことが，自身の優位性を保つ効果的な手法だからです。この事例での合理的解決策は，荷物を可能な限り最短で渡すことですが，１０分を８分にしても，長年の問題を解決することはできませんでした。そこで，デザイン思考プロセスを取り入れ，荷物が出てくるのが遅いという問題を，荷物が出てくるまでの待ち時間が苦痛であると再定義し，一見合理的でないと思われる解決策によって問題を解決することができました。まさにデザイン思考の効果を示すにはうってつけの事例ですが，結果が明瞭であるからこそ，どこか腑に落ちない部分もあります。

　結果に焦点をあてれば，苦痛と感じる待ち時間を減らすために，不要であるにも関わらず長い距離を歩いてもらうことは合理的であり，正しい選択をしたと言えると思います。不条理な解決策が，ある範囲の人々の特定の状況を改善してしまうことがあることは，この事例が示すように事実ですし，現実的な解決策として，評価すべきでしょう。しかし望めるのであれば，結果評価だけに留まらずに，解決策を導き出すためのデザイン思考に基づく５つの過程における取り組みを，結果以上に評価したいと思います。なぜなら，デザイン思考の本質は，成果や解決策にではなく，思考の過程にこそ内包されているからです。この事例の場合でも，おそらくさまざまな解決策が検討され，試され，最終結果としてこの案が採用されたはずです。ですから，誰かがこの解決策に直感的な違和感を感じてクレームをつけたとしても，運営者にとって，それは当然折り込み済みでしょうし，これですべての問題が解決したとも思っていないと思います。高齢者や車椅子利用者への対応，荷物待ちスペースの改善など，さらなる解決策を探っているに違いなく，そうした継続的な改善への取り組みを続けられる組織になっていれば，それが真に評価されるべき成果だと思うのです（組織としてそういった持続的改善を行えるからこそ，これだけ多く事例として取り上げられるのだと理解しています）。そういった意味で，この事例の取り上げ方は，思考の過程を飛ばし，意図的に結果を強調するようになっており，惹きつける力はあるものの，デザイン思考の本質を見誤らせる要因になっているのではないかと思うのです。

バイアスとデザイン思考

　Ｗebサービスの開発・運用の中での様々な問題への解決策を探る上で，知らぬ間に身についたバイアスを上手に取り扱うことは非常に重要ですが，経験上，これほど難しいことはありません。すべてのバイアスが悪い訳ではなく，時にバイアスは信念や理想という形となって，私達の推進力ともなるのですが，と同時に，現実を見誤らせ，問題解決をより難しくもします。

　私達は，本を取り扱うナラベルWebサービスを開発・運用していますが，まだリリースしたばかりで，抱えている課題も数多くあります。このような状況の中で，本の専門家である図書館司書の方に私達のWebサービスに関してインタビューする機会を得ました。事前に基礎的知識は入れつつも，出来る限り思い込みを廃し，真っ白な状態でインタビューに臨んだつもりだったのですが，それでも，本や図書館に対する自分の認識がいかにバイアスによって歪められ，現実を正確に把握できていなかったかに気付かされる結果となりました。インタビュー直後には，どうしようもない無力感に襲われ，精神的に疲弊してしまったのですが，数日後に改めてインタビューを振り返ると，想像以上の成果を得られたことに気づいたのです。

　何かを自らが作り出した後，それを手にした人によって肯定されたいと思うのは，モノづくりに携わる人々が多かれ少なかれ持つ，原始的な欲求だと思います。故に，理性的でないと分かっていても，条件反射的に反論したり，双方に気分を害す対応をしまうこともあるのでしょう。しかし，モノづくりを続けていくのであれば，こういった内在するネガティブな感情を上手くコントロールし，プロダクトを次のステップへと成長させる原動力にすることが理想だと思っています。いかにして，バイアスを排して現実を正確に認識するか？今でも悩ましい問題ではありますが，デザイン思考を学んで，少しは改善したのではないかと思っています。

　インタビューで心がけているのは，デザイン思考の５つのプロセスのうち，１）共感と２）問題・課題定義です。共感できれば，その人自身でも言語化できない内なる欲求を見つけ出しやすくなり，それが正確な問題・課題定義へと繋がります。これはデザイン思考を学ぶ初期の段階で出てくる定説ではあるのですが，座学と実践では全く異なります。インタビューを繰り返す中で気づいたのは，自分を一旦脇におくことの大切さです。より具体的に記せば，”解決したい課題を具体的に定め，それに関する自らのバイアスをなるべく薄くしておくこと”，ではないかと思います。シンプルに言えば，”自分を疑うこと”かもしれません。この考えは，デザイン思考の根底にある”自由に発想する大切さ”と共通するものではないかというのが，最近の気づきでした。

まとめにかえて

　ビジネスロジックをシステムで実装する場合，そのシステムを使うユーザーは，常に合理的な選択を求めていることを前提とします。ですので，ユーザーからの合理的選択とは思えないシステム改修リクエストには，少なからず抵抗を覚え，ストレスを抱えたものです。そういった意味で，昔は自信家だったのだと思います。しかし今は，分からないことだらけです。それなのに，当時よりも開発環境が厳しくなった今の方が断然にシステム開発を楽しく思えるのは，なぜなのでしょうか？デザイン思考を学ぶ中で，自分自身でも気が付かない変化があったのか，もしくは，単純に力が衰えただけでしょうか。いずれにしろ，ここまでシステム開発を続けてこれたことに感謝し，これからも続けるために，学び続けたいと思っています。

　機能拡充するナラベルＷｅｂサービスに，ぜひご期待ください。

ナラベルＷｅｂサービスエントリー「デザイン思考を学ぶ」はこちら