要約: きれいで、見ていて楽しく、使って嬉しい気持ちになれることは基本的人権の範疇です。そうでないものを作るということは、これに反しているということです
この記事は ShanonAdventCalendar2017・1日目の記事です。
すべて国民は、健康で文化的な最低限度の生活を営む権利を有する
機能がそうであるように、デザインもメンテナンスしたい。
私の前職は小さな SIer で、企業の社内システムを作ることがよくありました。それは全てのケースでデザイナー不在、デザイン不在で、全てのアプシケーションは「動けば良い」という暗黙の了解がありました。結果、ボタンがずらっと列挙されたような「システム」が出来上がることがよくありました。
メニューと呼ばれたこの画面は、アナログな業務がコンピュータ上にそのままマイグレートされたように見え、インテグレーションとは一体何なのかと考えざるを得ないようなこともありました。
私は恐怖と欠乏から免かれ、平和のうちに生存したいと願っていましたから、こういったシステムを回避すべく提案することが度々ありましたが、大抵こうした場面では画面のデザインに関する工数は用意されていないのでした。SIer は納品により成果物がその手を離れてしまえば、あとはどうすることもできないのが通例でした。
システムがもたらされた現場は、人間相互の関係を支配する崇高な理想とは程遠い結果を招来しているように見え、システムのユーザに対して私は精一杯のことができただろうかと考えることもありました。
私がシャノンに来たのは、そうしたヒットアンドアウェイ的にボタン列挙システム乱造することなく、エンドユーザの健康で文化的な最低限度の生活を営む権利を脅かすことなく、一つのシステムを継続的に改善し、利用者の幸福と健康の増進、ひいては生産性の向上による経済的な繁栄をもたらしたいと願ったからです。これは私自身の生活の質にも関わることですから、継続的改善は死活的に重要なことでした。
シャノン、お前もか
入社して最初にシステムを目にした時、控えめにいって「あっ、玄人のシステムだな」と思いました。それが何なのかを理解するのにはさらに時間が必要でしたが、端的にいって複雑で難しそうで、古くからあるシステムであることは明らかでした。
システムが古くからあることは当然に理解していましたが、それが「古いまま」であるとは思っていませんでした。実際に古いままかというとそうでもなかったわけですが、パッとみて古いまま、今に引きずっているように見えたわけです。
MS UI Gothic を見続ける日々
研修期間中、一日の大半を自社のシステムの中で過ごしました。使い続けるうちにシステム内部に存在する論理とその必然性を理解し、これはこうなるべくしてなったということが分かってきました。しかしなぜデザインが10年も同じなのか、理解に苦しみました。時は2015年、控えめに言ってももっと見やすいフォントはいくらでもあるのに、このシステムにはどうして MS UI Gothic が指定されているのだろうか。
小さなボタンを注意深く押していく
もう一つ目についたのはボタンの小ささです。このボタンのサイズは直感的に Windows 2000 だと思いました。余白のないボタン。せめて Windows XP ならひとまわり大きかったのに。クラシックテーマなのだろうか。10年前と比べてだいぶ大きくなったディスプレイに対し、そのボタンはあまりに不釣り合いに見え、実際押すのに神経質にならざるを得ませんでした。
UI 改善に絡んでいく
入社も半年経ったところで、ふとUIの立ち話が自席から聞こえてきました。聞くとなしに聞いていると、どうやら自分たちのシステムが使いにくいといったものでした。やっぱりそうなのかと思いました。
じゃあ変えたらいいのでは
私はそういう改善をしたくて入社したわけですから、これは渡りに船とばかり早速割り込んで、じゃあ興味あるならこれから議論していこうとなりました。私は勇んでモックを作って提案しました。おー、CSSを変えるだけでも結構見た目変わるね。そんなイメージだね。全ては順調に見えました。
変える根拠、得られる効果
しかしながら「いいね」で即改善とはいきませんでした。変えるための企画が必要で、そこには変える理由とそれがもたらす効果が記されていなければなりませんでした。
うろたえました。工数を捻出するために理由が必要であることは理解しつつも、どうやらかなり真剣に説明をする必要がありそうなのでした。
どう見てもこのままじゃダメでしょ
入社して日が浅かった私からすれば、そのレキシテキケーイの沼にハマる前だったこともあり、そんなの変えるところいっぱいあるし、ちょっとずつ変えていけばいいし、少なくとも提案したやつは今と比べれば良くなるのは説明するまでもないのではないか？と思いました。
結局このあと、開発業務の合間を縫って進めたこともあって、このやり取りは一年近く続きました。このままではいけないことは理解している、でも「これ」に変える理由、他でもない「これ」こそが最善である理由が欲しい、そうした声に答えを見つけられないまま時間が過ぎていきました。
そんなやり方じゃ一生変えられない
そんなやりとりを細々とやっていることが周りにも知られはじめ、ある時「そんなのやってみなきゃわからないでしょ。それを説明しようとしたら一生変えられないよ」と言われました。そうですよね。一生変えられない。専制と隷従、圧迫と偏狭を地上から永遠に除去するためにはやるしかない。
丁度可知差異(ちょうどかちさい)
調べまくった結果、Google Scholor で良い概念を見つけました。丁度可知差異。マーケティング業界にあったじゃん。ということでこれを主軸に説明を組み立てていくことに。（ちなみに丁度可知差異とは、私のざっくりした理解によれば「じわじわ変えていけば既存顧客が変化を自覚することなく割と大きめな変更が可能になる」といったものです。一般消費財のパッケージデザインなどはこの手法が使われることが多く、マイナーチェンジを適宜行うことで時流に合わせ、商品の鮮度を維持するものです）
ゴーサイン、継続的改善の始まり
10年変わっていなかったものを変えようとすると、どんな小さなことでも壮大な変更のように見えてしまうという認知上の問題がありました。これを顧みずに説明をしようとすると、「これまで培ってきたものがバラバラに解体されてしまう」といった懸念を呼んでいた可能性はあります。「じわじわ変える」「既存顧客には影響ない」こういうことは暗黙的にではなく、ちゃんと言う必要があったという教訓を得ました。
ともあれ変更にゴーサインが下り、毎月のシステムアップデートでじわじわ（本当にじわじわ）変えていきました。じわじわすぎて一緒にやっていたQA担当者から「違いが分からない」と苦笑されることもしばしばありました。
半年やってみて
じわじわも半年積もれば結構変わっていて、前後で見比べると確かに変わったねという印象を得られる程度には変更ができました。そこで全社アンケートを取ったところ、メンテナンスしていくことの意義や有効性は理解してもらえたようです。
ちなみに2割弱の人がデザインが変わったことに気づかなかったと回答しており、10年築き上げてきたメンタルモデルは強固であることを改めて感じた一方、「じわじわ」が成功したとも言えるなと思いました。
これからも変え続けるために
自社のプロダクトを持ち、これを継続的に改善することにコミットできる、そうした環境を求めて入社して2年半、ようやくその端緒についたかなというところです。いったん変えてしまえば、実は「あれも、これも」といった声も聞こえてくるわけで、動き出した歯車を見て、今までどうして止まっていたのかと思うようにもなりました。
ここまで読んでくれたあなた、ありがとうございます。「よかったね」「その気持ち、わかる」と思っていただけたら幸いです。ひょっとしたらこの動き始めた船に乗ってみたいと思ったりしていませんか？そんなあなたに、デザインをエンジニアがやる上での FAQ をお届けしたいと思います。
FAQ:
デザインはデザイナーに任せたほうが良いのでは
餅は餅屋。絵が上手なのはデザイナー。そうかもしれませんが、デザイナーがいない会社がデザイナーを雇うというのは、車がないのにドライバーを雇うようなものです。卵が先かひよこが先かの問題はありつつも、デザイナーの価値が認識されていればデザイン部があったはずで、そうでないということは、そういうことなのでしょう。きっとフォントを買う稟議だけでも半年かかるでしょうし、そのデザイナーはそれだけで疲弊してしまうことでしょう。そうしてクリエイティビティの泉は枯れていく。
問題の半分は上記のようなことなのですが、残りの半分はデザインを適用しようとしているシステムにもあります。今回のデザイン変更もそうでしたが、相当に複雑なレキシテキケーイがあって、ビジュアル的には軽微な変更に見えて、実はシステム側ではかなり難易度が高いといったことも多々あるわけです。そうしたことを踏まえると、システムへの理解が欠かせないということになります。デザイナーが別途いる場合、説明コストにもなり変更のスピードにも影響します。
理想なのはおそらく、デザイナーを迎えて共にシステムのことを理解し、同じチームで改善をしていけるように成長するということなのでしょう。そのためにはそうした文化を理解し、受け入れる土壌が必要です。そのためにもまずはデザインの必要性を理解してもらう必要があって、その一歩はそこにいる自分たちが歯を食いしばらなければならないのだと思います。
とはいっても絵心が
こうして人々はデザインへの言及を控えていくのですが、写生をしろとかツボを作れとか言われているわけではなく、デザインというのはもっと身近にあるものであることを思い出すべきです。例えばAPIデザインとか。DB設計とか。
およそ設計と名のつくものはデザインであって、そうしたデザインは日々行っているはずです。では誰もがみな最初から「美しい」APIデザインができたかというと、それは学習の結果だろうと思います。デザインは学習できる。教材はたくさんある。読んで理解して実践すれば身につくという点で、プログラミングもデザインも変わらないんじゃないかと思います。
なお「絵心」というとき、人は「アート」を思い浮かべることが多いと思います。しかしアートとは作家がその信念を世に問うことであり、デザインとは課題を解決することであり、両者は異なるものです。私たちはデザインをするのであって、アートではない。そうであるなら、エンジニアにもデザインが可能であるはず。
最後に
デザインのメンテナンスは死活的に重要です。一日8時間システムを使うとすると、人生の三分の一をそこに費やしていることになります。限りある人生、その大切な時間は誰だって心穏やかに過ごしたいものです。自分たちのプロダクトがユーザの健康で文化的な生活に貢献できたらと思います。
最後までお読みくださりありがとうございました。共感してくださったそこのあなた、一緒にデザインをやっていきませんか？お気軽にお問い合わせを。上原と指名してくだされば、喜んでお話をうかがいます。
http://carrier.shanon.co.jp/
では！！
