(cache) webデザインの賞味期限(もしくは技術的負債の話)

「技術的負債」という話が、はてな村大字テクノロジー周辺を賑わせている。

あたりがにぎわっているエリアだろうか。

私はエンジニアではないから全ての話の理解はできないんだけど。『見えづらい技術的負債が発生し積み重なった結果、誰かが尻ぬぐいをしている』という状況はwebデザイン、特にUIデザインの現場でも同じだなーと思ってる。

糞コードならぬ糞UIデザイン。webディレクター、webデザイナー、コーダー、フロントエンジニア皆が想定しえない余計な工数をとられてしまうUIデザイン。そしてえてして「なんでそんなに工数かかるの？」と言われ、挙句ちゃんと状況説明を上司に怠ると「あいつらは仕事が遅い」とみなされる危険がある地雷案件。

糞UIデザインは拡張性が低い＝賞味期限が短い。運用しているうち、気づいたら腐ってて目も当てられない状態になる。そして当然美しくない＝マズい。

なんでそんな賞味期限が短くマズいデザインができてしまうのか？毎日の台所をつかさどる主婦視点＆UIデザイン運用の現場視点から書き起こしてみようと思う。

賞味期限切れ食材が発生する理由(もしくは賞味期限切れUIデザインが発生する理由)

賞味期限切れ食材が発生する理由も、賞味期限切れUIデザインが発生する理由も、まあ同じではないだろうか。

なんでもかんでも、無計画に気になったものを冷蔵庫(UI)に入れる
使いまわしがきかない食材(デザインパーツ)ばかり入手したり作ったりする
賞味期限がきれそう(メンテナンス性が悪い)なものを見ても「まあ大丈夫か」と放置

※なお、スキューモフィズムからフラットデザインへ転換した時のような、数年スパンでのデザインの流行の話は論点に含みません。あくまで公開直後～2、3年くらいの運用スパンで発生する技術的負債について述べています。

なんでもかんでも、無計画に気になったものを冷蔵庫(UI)に入れる

実家をでて妹と二人暮らししはじめた頃、家の近所に肉のハナマサがあった。大量の食材、そして安い！社会人なりたての頃なんて収入が少ないので「食費圧縮」を目標としていたのだ。鳥胸肉100gで46円とか安すぎる。

慣れてくると肉のみならず、じゃがいも1kgとかみかん段ボール1箱とか、キロ単位で食べ物を買うようになった。完全に感覚がマヒしてたのだ。結果、パン粉1kg、ドレッシング1リットルなど「毎日ではないけどなんとなく使う頻度高そうだし、今安いから買っとくか！」と買っていた。

その結果、冷蔵庫の奥で眠り続けたパン粉は緑色になり、ドレッシングは謎の発酵臭を放つようになった。
当時彼氏だった夫はマジギレして冷蔵庫の中身を捨て去った。よくふられなかったものだと思う。

よくこの問題が起こりがちなのが

ECの検索結果画面やニュース・ブログ記事画面における、右カラムもしくは左カラムのようなナビゲーション部分にバナーてんこもり
ECの検索結果画面における、各商品リストの中身

たとえばそんな経緯でつくられてきたんだろうなーと思うのが、JTBの海外ツアーのUIだ。

ぱっと見て、何をみていいのかがまったくわからないですごめんなさい…。
そしてもし何か追加の必要にせまられたら、お手上げだと思う。

「検索結果で1週間の空き状況わかりたい」「おすすめのポイントを読ませたい」「商品の特徴をはっきりした色のアイコンで目立たせたい」「アイコンクリックしたら検索条件絞り込みがきくようになる」「検索条件をユーザーに変えさえたい」etc…そんな要望がどんどんつみかさなった結果ではないだろうか。

きっと、一個ずつだと成果がでる局所最適的な施策なのだろうけど、積み重なると何を見せたいのかがまったくわからないものになってしまう。
また、その個別施策において個別の成果測定がされ、局所的な目標が達成されてしまったりすると「成果がでた施策だから」として組織内で正当化されてしまう。局所成果という裏付けをもった、ぎちぎちでもはや拡張できないＵＩだ。

「パン粉2回くらいつかって便利だったから、常にたくさん買い置きしておかないとだめなの！」といってパン粉を緑化させた、私の行動となんらかわりない…

使いまわしがきかない食材(デザインパーツ)ばかり入手したり作ったりする

おいしそーと思って買った冷凍いちご1kg、たいして甘くなく料理にも使えず放置した結果、冷凍庫の奥底で白く霜つきになって塊になる、ということもあった。
また、「○○のたれ」というものをお土産やさん等で入手するも、冷蔵庫のドア裏の棚にいつまでも鎮座しているとか。

食材は特定料理のみで利用するものを買ってしまい余らせると、たいていは冷蔵庫の邪魔になり、賞味期限をむかえることが多いと思う。

もちろん特定料理に特化したものは便利だ。たとえば、「チンジャオロースの素」。最近はこうした○○の素、というのが多く料理工数削減には役立つ。しかし、チンジャオロースを作らない時「チンジャオロースの素」は使う用途がとても限られる。

他の野菜炒めに転用する、という手法もあるけど。だとしたら醤油・オイスターソース・酒・砂糖をまぜてチンジャオロースのたれにするほうがいいんじゃないかなと思う。醤油、酒、砂糖はベーシックな調味料だし、オイスターソースは中華のみならず和食や洋食の隠し味に使うことができる。家にあるものさえ吟味しておけば、ある程度の料理は作れると思うのだ。

デザインで考えると、たとえばこんなUIを過去に担当したことがあった。

商品が3つ以上になったときどーすんだ、と思ったら。上が2ブロック、下が1ブロックというレイアウトになった。衝撃。（まあ、上が2ブロック、下が2ブロックのうち1ブロックになって空白になるよりはいいのかもしれないが…）

また、2ブロックのとき、商品の説明が長いものと短いものが発生する。左が長いもの、右が短いもの、となるとむだな空白がうまれたりもしていた。ユーザーも読みづらいし、コンバージョンにつながる入力画面がどんどん下のほうにおおいやられてしまっておりもったいなかった。

・・・使いまわせないよ！！

賞味期限がきれそう(メンテナンス性が悪い)なものを見ても「まあ大丈夫か」と放置

日々の買い物や食材管理に気をつけていたって、賞味期限切れはどうしたって発生してしまうと思う。急に体調悪くてごはんをつくれなくなったとか。大事なのは、気づいたときどう対処するか、だと思う。

たとえば冷蔵のお肉の消費期限が明日の場合。基本は今日か明日に料理するけど、確実に料理できない場合は冷凍庫へつっこむ。冷凍して、数日後に使いきるのだ。冷凍庫につっこんだ場合、ずっと冷凍してると冷凍庫のにおいがついてどんどんまずくなってしまうからだ。

賞味期限が間近のものは冷凍庫に入れるほか、糠漬けにしてしまう等の回避方法もある。また、賞味期限を気にしないような食材手配オペレーションを組むことも大事。（詳細は「共働き夫婦が、パルシステムの宅配サービスを4年続けた結果の考察」参照）

賞味期限きれそうだと思ったら（もしくはその危険が予測できるなら）、ひと手間かけて食材の延命をはかるべしだと思う。「まあどうにかなるんじゃね」と思って放置しても、絶対どうにもならない。断言する。野菜はとけて茶色い水がでてきたり、肉は茶色く変色したりする。
まさに台所の負債である。

台所の負債はもったいないけど、捨てることは容易だ。しかし、UIデザインはそう簡単には捨てられない。デザイナー、コーダー、フロントエンジニア等々改修の工数を確保しないと捨てられないのだ。
この捨てる障壁が高いあまり、「まあしょうがないか」で放置されることがままあると思う。

たとえば、同じような機能の画面なのに、導線によってデザインやコーディングが違う場合。
えてして違う制作会社さんが独自作成した、という場合に発生することが多い。
同じような機能の画面に、同じような機能を追加するだけ、と思うと想定する工程は以下。

一個デザインとHTML・CSSを作成する
フロントエンジニアが1を見て、1と他の画面にも流用

ところが、導線によってデザインやコーディングが違うと以下のような工程となる。

一個デザインとHTML・CSSを作成する
1をもとに、他の画面でも同じようなUIとなるよう、HTML・CSSを作成する
※1つ１つコーディングのルールが違うので、解読していくことから必要
フロントエンジニアがそれぞれ違う2を全種全部組み込む
※HTMLの作り方によっては、画面Aでは数行だったif文が画面Bでは使えない、というのも発生する。

メンテナンスめんどくせええええ！！

※地獄のミサワより引用

こういうとき、メンテナンスまで手をだす工数とそれを判断するディレクターがいればいいけど。見た目だけ気にするディレクターだとそのあたりきづかず、気づいたら運用工数が想定の数倍かかっている状態を繰り返す、という事象も頻発する。

自分がサイトを改修する際、技術的負債を見つけてしまったら。多少の工数を追加してでも、技術的負債であるメンテナンス性の悪い部分をなおす、という意思決定をしていかなきゃいけないと思う。
その場はやりすごしても、またその後だれかが技術的負債に直面し、工数を余計に使う・・・となると負のスパイラル一直線になってしまう。そんな技術的負債を放置して都度都度工数かけるより、よりユーザーのためになる施策に工数を使ったほうがいい。

賞味期限の短いUIデザインを生み出さないように

きっと、UIデザインは表面上にみえる部分がおおい分、エンジニアよりは技術的負債が見えやすいパートだとは思う。

技術的負債が（エンジニアより）見えやすく、かつその影響がディレクター、デザイナー、コーダー、フロントエンジニア等々多くの人の工数へ影響を与えてしまう部分なのだとしたら。
一人がデザインをしつづける体制は不可能なので、ガイドライン化に工数をさくというのが現実的なんだろうなと思う。最初すごく大変なんだけど。

個人的には、クックパッドのようなルール作りを目指しているとこ。
・UIコンポーネントの抽象化
・キーカラー変数化（ソースコードから参照可能）
・ルールの周知徹底
とか。自社は自分が関わったサイト部分はルールづくりしているんだけど、それでも途中でサイトのデザインリニューアルをした部分もあり、ガイドライン化をちゃんとしてない部分が多い。ぐぬぬぬぬ。いかん。

—–
デザインの流行はさすがにどうにもならないけど。
自分がコントロールできる範囲のUIデザインは、ちゃんと長く使えるものを作りたいと思う。
私が尊敬していたUIデザイナーの先輩は、こういっていた。

「3年先まで使えるUIデザインを考えてる」と。

残念ながらその先輩は退職されてしまったけど。その先輩の生んだUIを、今は私が改修している。
他の人が作ったものと比べると、なんでそう設計したのかがとてもわかりやすいので拡張しやすく、触るたびに驚いてしまう。
そんな先輩のようなUIデザインを私は目指している。先輩の背中をずっと追い続けている。