2018年11月24日にグランフロント タワーCにて行われたFRONTEND CONFERENCE 2018。フロントエンド技術のみならず、デザインやプロジェクトメイキングのことなど多彩なテーマのセッションやアンカンファレンスがぎっしりのイベントでした。私は午後から、管理画面デザインを担当させていただいた「EC-CUBE 4」のデザインのプロセスについてお話させていただきました。

当日のスライドはこちらです。おおまかにはお話した内容の通りのことが書かれているので、おおよその内容はこちらで掴んでいただけるかと思います。

このセッション、持ち時間が30分とかなり少ないものでしたので、立てたプロットからはかなり内容を削らないといけませんでした。都合上、若干話の流れが急になってしまったり、共有しておくべき前提が少し省かれていたりしています。なので、この記事では、発表前に削った内容をご紹介して補足代わりとさせていただきます。

なぜ私がリーンなデザインプロセスに興味をもっているのか

そもそも私がなぜ「リーン・スタートアップ」的な考えでデザインをしたいと思っているかという前提はお話していませんでした。

それはつまるところ、よくあるデザインプロセスの「ある面」に限界を感じることがあるからです。

「一発OK」はデザイナー視点で見ると、とても喜ばしいことです。これからかかるはずだった労力がかからないことになりますし、クライアントから見ても、いきなり期待通りのデザインを実現できたわけで、当然デザイナーへの評価も高くなります。

ですが、それはクライアントとデザイナーの見識が一致したということに過ぎません。そのデザインがクライアントの目的の役に立つものになるかというのはまた、別の問題です。

またデザイナーとクライアントが「一発OKを至上」と考えだすと、逆パターンに陥ったときがとてもつらい。修正や、そのためのコミュニケーションにポジティブなイメージを持てなくなることがなにより問題だと思うのです。

たとえばデザイナーさんがよくTwitterでボヤく内容にこんなものがあります、

・デザイン修正がいつまでたっても止まらず、予算的にも時間的にも大赤字
・素人の思いつきでいやに具体的なデザインの修正を依頼されたせいで全体のバランス調整に苦慮した
・「なにか分からないけどこれは違う気がする…」といった曖昧なフィードバックを返される
・デザインがFixしてからクライアント都合で修正を依頼された、それも追加予算なしで
・これ以上赤字を出すわけにはいかないので半ば喧嘩のような状態で納品せざるをえない

わかります。私も同じような想いを何度もしたことがあります。でもこういう状態ってクライアントさんから見れば

・どうも出されたデザインがよいものに見えてこないが、修正を繰り返しお願いするとデザイナーの機嫌が悪くなり、頼みにくい…
・イメージ通りにならないので、こちらで具体的に指示してみると怒られてしまった…
・だいたい私はデザインがわからないので、どう評価していいのかわからない
・ビジネスの状況が変化したのでコンテンツレベルで変更を加えざるをえないが、もう予算内ではできないと言われてしまった
・結果ビジネス上の都合にも合わず納得しきれないデザインで完成させるしかない

というようなことになるのかな、と。承認したデザインの結果に責任を持つのはクライアント側です。やむをえない部分があるでしょう。

なぜ協調できないデザインプロセスになるのか

長くなりすぎるので簡潔に書こうと思いますが「一発OKを最上とする」ということはプロダクトのデザインについて、実際にできたものを卓上に出してコミュニケーションをすることを忌避する意識につながっていると思うのです。

何度もデザインを書き直すのは力が足りないから、修正の連続はいらないプロセスであり損失…そのマインドのままでは、修正が繰り返されるたびにデザイナーとクライアントの距離は開き、最終的には合意とは言えない状態でプロジェクトの終了を迎えることになります。

もちろん事前のヒアリングでクライアントのニーズを意識し、それにピッタリのデザインを提供できることは素晴らしいことです。ですが、そうした認識にズレが生じる、ということはどんなに熟練したデザイナーであっても、避けることは難しいんじゃないかと思います。

であれば、デザイナーとクライアントに必要なのはファーストデザインはプロトタイプであり、これをたたき台に本当に必要なデザインについてコミュニケーションをおこなうことを是とする文化を確立することなのではないかと思うのです。

すぐに製品化できるくらいのデザイン案を見せて当たり前、クライアントにそれ以前のものを見せるのは失礼にあたる、という文化の中では、リーンなデザインプロセスを踏むことは不可能です。

もちろん最初から完成形に限りなく近いものを提示し、勝ち残りつづけるデザイナーは偉大です。ですが、私にはそれができない。ならば、初速が遅く感じられても面倒臭がらずにコミュニケーションを取る、もちろんそのための予算も取る、代わりにより確実にクライアントの利益にコミットできるデザインを、双方の協調と納得感のもとで提供できるプロセスにしていきたい、そういう理想があります。だから私は、一発OKよりプロトタイプを、機敏なデザインのバージョンアップを理想とするプロセスに憧れるのです。

私がこのプロジェクトで実践したかったこと

スライドでは「リーンなデザインプロセスをふんでデザインしたい！」という主題のお話のみに絞っていますが、他にもいくつかやりたかったことがあったので、ここでご紹介します。

誰でもアクセスできるデザイン

EC-CUBEはオープンソース・プロジェクトであり、管理画面のデザインはプラグイン開発者や管理画面のカスタマイズをする人などの仕事に関わってきます。もちろんデザインそのものはオープンソースライセンスとは関係がありませんけど、そのルールやシステムについては、誰もがアクセスできるべきですし、できる限り再利用しやすいものであるべきでしょう。

管理画面デザインガイドは今後、クライアントである株式会社ロックオンさんがご自身で管理画面をデザインするときはもちろんのこと、多くのユーザーさんがオリジナルの管理画面ページをデザインするときにそのまま利用してもらえるようにと思って作りました。

スタイルガイドを提供するにあたっての課題

ただ、そのアウトプットが今公開されているようなPDFのガイドであるべきかどうかは悩ましいところです。本来ならHTMLとCSSもセットで示されたほうがコーディングをする人には扱いやすいはずであり、いわゆるスタイルガイドという形で提示できたほうがいいのかな、とは思っています。

ただ少しお話はしましたが、フロントエンドチームとのコミュニケーション不足もあり、私は今回CSSのclass設計などにはまったく関われていません。本来（私が命名した）デザインガイド上のコンポーネント名と（フロントエンドチームが策定した）clsss名は一致しているべきでありますが、現状はそうなっていないものと思われます。

その状態でスタイルガイドを提示しても、名前のブレがあってはかえって混乱を生むではないかと危惧しており、そうした提案はできておりません。

どこかでclass名とコンポーネント名の命名を合わせるなどの対策が必要になるかとは思いますが、それも大仕事だと思います。将来なんとかできるチャンスがあるかどうか…というところです。

EC-CUBE 2.11にさわった経験からの目標

私は一度だけ、クライアントワークでEC-CUBEをさわったことがあります。クライアントのオリジナルECサイトを構築するために利用しました。バージョンは2.4系からアップデートされたばかりの2.11系を選択しました。

当時の私はWordPressのカスタマイズの面白さを知りはじめていた頃で、おなじPHP製のCMSならなんとか扱えるかなという気持ちだったと記憶しています。

しかし、やはりといいますか、そんなに甘くはない。2.4系のノウハウはまだ数が多かったのですが、当時発表されたばかりの2.11系のノウハウはほとんどインターネット上に公開されていませんでした。

またEC-CUBEのテーマは構造上WordPressほど見た目と機能の分化が進んでいおらず、デザインの変更にも戸惑う場面が多かったことを覚えています。テンプレートエンジンであるSmartyの扱いにも悪戦苦闘し、結局自分の手に負えず、近所にいらっしゃったEC-CUBEのパートナー開発会社さんの力を借りて、なんとか納品までもっていったことがありました。

そのときにもちろん管理画面もさわっていたのですが、正直にいって「あんまり素人に理解しやすい管理画面じゃないな」と思いながら触っていました。EC-CUBEの管理画面をさわるのは、第一にショップマスターだと思います。ショップマスターのITリテラシは様々ですので、もうちょっと低いレベルに合わせたものになればいいのになという想いは当時もっていました。

ですので、このお話をいただいたときにまずやりたいと思ったのは「ITの苦手なショップマスターさんでもわかりやすいEC-CUBEの管理画面を実現したい」ということでしたし、新バージョンが掲げる「”あなたのための”（すべての人のための）EC-CUBE」というコンセプトにはとても感銘を受けました。その一助になる仕事ができたとしたら、本当に嬉しいことです。

誰のためのデザイン？ 多くのユーザーをすでに抱えているプロダクトの難しさ

さきほど言ったように、私は「ITリテラシの高くないショップマスターや、技術に明るくないデザイナー」といった人々をおもなデザインの受け手として想定してデザインをしましたが、話はそう単純ではありません。

EC-CUBEのコンテキストになれたベテランのショップマスターさんやECシステム管理者・プラグイン開発者には当然私とは異なる文脈でリニューアルを捉えます。新しいUIや機能には途中、いくつかの疑問が呈されました。

あたり前のことながら、既存ユーザーの声はまた貴重です。私では持つことが難しい視点からのアドバイスをたくさんいただけ、私自身、納得できたものもたくさんありました。なんでも変えればいいというものではないのです。

こうしたオープンソースプロジェクトをはじめ、多くのユーザーを抱えるプロダクトのデザインは「誰のため」というところで玉虫色になりがちです。結局のところ、こればかりは意見を数多く出し合いながら、形をつくりつづけて、着地点を見出すしかないのかなと思います。

以上、「補足」でした

めちゃくちゃ長い補足になってしまいました…。下手したらこれで別にひとつセッションが作れそうですね。完全版の再演、ニーズがあればよろこんでやりますので、ご興味ありましたらぜひお声がけください（笑）