エンジニアリングとサービスデザイン
このnoteについて
わたしの知っているふたりの「すぎもとさん」がTwitterとQiitaで書いてらっしゃったことに共感したので書きます。
昔、業務システムを作る価値は、効率化や高速化にあると思っていた。今は、それらはむしろ副次的効果だと思っている。業務に係わる人々の間に新しい階梯の新しい調和を作り出すことが、システムエンジニアリングの主眼であるべきだ。そしてそれをするために、ドメインに働く諸力を理解する必要がある。
— 杉本啓 (@sugimoto_kei) June 12, 2020
📖 内容
・私が思うエンジニアリングとデザインの違い
・業務システムに必要なサービスデザインの視点
・私が実践していること
私が思うエンジニアリングとデザインの違い
エンジニアリング
科学技術を応用して物品を生産する技術。また、それを研究する学問。工学。工学技術。
（出典 三省堂大辞林 第三版）
デザイン
作ろうとするものの形態について，機能や生産工程などを考えて構想すること。意匠。設計。図案。
（出典 三省堂大辞林 第三版）
私見ですが、
「このシステムで便利になった」
「このシステムでできるようになった」
をエンジニアリング
「このシステムで気付かされた」
「このシステムが動機になった」
をデザイン
としてくくってます。
私は、どんなシステムであれ、
「システムが何をする」ではなくて、
「このシステムは、人をどうしたいのか？」
「どう使われることがこのシステムにとっての幸せか?」
を大事な観点としたいと考えます。
業務システムに必要なサービスデザインの視点
業務システムでDXを実現とか、アプリのUXといいつつ、
実施しているのは単一の業務課題に対する単一の解の提供だったり、
単なる1工程の効率化だったりしてませんか？
サービスをデザインするということは、
業務をシステムにデザインすることではなく、
システムによって業務を再発見できるようデザインで促すことです。
結果として、
業務が「楽しくてやめられない」とか「なぜかやってしまう」とか
「いつのまにか終わってた」といった存在にすることが、
サービスデザインによってもたらしたい、課題解決なのだと考えています。
大事なのは問題に対して、1対1の解決を目指さないこと。
例えば、「ボタンが押しにくい」という症状に対して、
ボタンをどうこうするのではなく、
ボタンは必要なのか？ボタンがなくても動くことは？などと考える。
ドナルド・A・ノーマンは「誰のためのデザイン？」で以下のように記しました。
人々は頭の中にある知識と外界にある知識とを組み合わせて、日々の生活をうまくやっている。
デザインのチャレンジとは、システムの状態についての情報を、取り入れやすく、解釈しやすく提示しながら、また同時に違った面からの説明や解釈を提供することにある。
解決を求められる問題は常に本当の”問題”ではなく”症状”である。
デザインの成功の秘訣は、なにが本当の問題なのかを理解すること。
我々デザイナーが焦点を当てるべきことは、作りだされたものが、人間の展望、ニーズ、能力にあっていることを確実にすること。
この視点は、いわゆるビジュアルデザイナーだけのものではなくて、サービスデザイナー、プロジェクトマネージャーにももとめられると考えます。
私が実践していること
過去５〜６年、私は流通小売業のお客様に対し、自社パッケージ商品である「顧客管理システム」を提供するプロセスをへて、業務を再設計するお手伝いをしてきました。
その文脈で当然、「スマホによる会員証」といった話もでます。
実際、様々なお客様に納入しており、まず2014年時点でファーストクライアントに納入しています。当時は、スマホでバーコードを表示して会員証とする考えは、まだ少なかったと記憶しています。（担当したプロジェクトの2014年のリリース）
私達が「スマホによる会員証」という手段をとったのは、「できるから」「あったら便利そうだから」ではなく、それらのお客様は「スマホ」にも「会員」にも、必然的な意味があったからです。
スマホ会員証の真髄は、接近検知とそれによる先回り接客と考えました。
私達が実現したかったのはクーポン値引きでの来客増加という話ではなく、顧客ロイヤリティの向上と従業員の業務スキル向上でした。
なぜなら、頻度が少なく、単価が高いお客様あいてのご商売だからです。
１回の購買単価が高く、専任のアドバイザーがつくような業態で、「スマホ会員証をレジで提示していただいてはじめて、名前がわかる。」というのはお客さまに対して失礼です。
このような業態では、もし可能ならば、お客さまが店に接近した時点で検知し、もしお車ならば、監視カメラと連動してナンバーを読み取りお車でのお越しを検知して店前でご来店をお待ちし、店員の側から「〇〇さま、お子さまのご入学おめでとうございました。お召しになったスーツはいかがでしたか？あれに合うシャツが入ったんですよ」などとニーズに対して先回り把握して声をかけたいわけです。
私達としては、その未来を実現させるべく、従業員がだれであっても一定レベルでそのように接客できる世界を目指しました。
そのためには、アプリ開発だけでなく、いろんなものが必要になりました。エンタメやSNSでバズるよりも先に、お金をかけなきゃいけないところはたくさんありました。
そしてこの仕事をする上で、従業員の業務に対する知識や動きを理解することは、不可欠だった。その理解なしに、ただアプリを提案することには意味がありませんでした。
近年になって、来客促進の施策として、スマホ会員証とクーポンがよく取り沙汰されます。しかし、本当はスマホ会員証と来客促進の関係はすごく遠いというのが、色々な業態で導入してきて感じることです。
スマホの会員証アプリは、事業者としてクーポン値引きをするためだけなら導入は控えたほうがよいです。スマホ決済が乱立してる中で、お客様の決済時に複数アプリを切り替えさせるのでしょうか。それであれば自社電子マネーでも導入してお客様を優遇すれば、キャッシュフローの良化とともにお客様を囲い込めますが、それよりもクーポン値引きしたいでしょうか？
いずれにしろ、表面的な「課題の顔をした要望」に対して、便利にしようとか単純化しようなどと、直接的な解を提供しようと思わない心構えが、大切だと思います。
アプリを作りたいと仰るクライアントさんに対しては、
「ここではスマホ出すことできないですよね？」とか
「この業務しながらPC開けるんでしょうか」とか
「決済アプリの操作に忙しく、ここで起動はしてくれないのでは？」
といった、ユーザーフロー、業務フローに対する確認を入れさせていただき、そこから提案をはじめさせていただいています。
そして、業務システムでも同様に考慮しないといけないのは、その局面に便利かどうか？ではなく、これまでの業務の積み重ね、慣れ、コンテキスト、メンタルモデル。
そういうものを理解して、情報設計をしなければならないということです。
旧システムを踏襲するでもなく完全刷新でもなく、
「違和感なく新しい」
このラインを作り出すのは、じつは難しいです。
まとめ
・「このシステムは、人をどうしたいのか？」
「どう使われることがこのシステムにとっての幸せか？」を
大事な観点としたい。
・直接的・短絡的な解決を目指さない。
・業務フロー・ユーザーフローの理解は避けて通れない。
よろしければサポートお願いします！