こんにちは！AbemaTVでUIデザインを担当している内田達也です。この記事では、AbemaTVの立ち上げにおいて、デザイナーがどの程度エンジニアさんの領域に入り込むことができたかを書きたいと思います。

結論から言うと、現在4人いるデザイナー全員がAndroid、iOS、ブラウザいずれかの実装に直接参加することができました。作業量は皆様々でしたが、まずは一歩踏み出せた気がします。

弊社の一般的なデザイナーの役割

これまで弊社でデザイナーと呼ばれる人たちはSketchやPhotoshopでビジュアル部分を制作し、実装はすべてエンジニアさんにお任せしていました。これは、デザイナーが綺麗なUIを作るのに時間をかけることが出来たり、実装はいったん無視して理想の絵を作るという点でも意味があると思います。また最近は静止画を作ったあとにPixateで動きまで伝えることも多く、それで事足りているということも多いです。

しかし一方で、自分たちで見える部分の実装までで出来たらさらに良いのになという憧れみたいなものも一部でありました。

時を同じくして、社内でテクニカルクリエイターという肩書きがもち上がりました。現状はテクニカルクリエイター専任の人がいるわけではなく、本業デザイナーでインタラクションに踏み込めたり、本業エンジニアでUIについても考えられる人たちのことをテクニカルクリエイターと呼んでいたりするのですが、その目指すところは互いの垣根を超えていい物を作っていこうということだと思います。

ここからは、今回のプロジェクトの進行に合わせながらデザイナーが実際どのようにテクニカルクリエイター的な振る舞いをしていったかを書きたいと思います。

今回のプロジェクトでやったこと

1. モックによるUI検証

AbemaTV開発チームでは、初めから「動くモックをガンガン作ってUI考えようぜ」という空気がありました。これは先行事例としてAWAチームがモックを作って成功していたことが大きいと思います。これにならって自分も初期段階ではSwiftでiOSのモックを作ったりしていました。

しかしながら、毎日夕会をして進捗を見せていたのですが、さすがにネイティブで毎日新しいUIを見せるのはしんどく、デザイナーはPixateなどで素早く作って見せる方法にシフトしていきました。

同時に、iOSのエンジニアチームはプロダクト版とは別にモック版のアプリを作成し、そこにいろいろなアイディアを詰め込んだり削ったりしていきました。

こうしてある程度UIが固まってきたら（UIはかなり紆余曲折あったのでモックは効果的でした）本番の実装に移ります。ここでデザイナー達は今まであまりやったことのない作業をすることになりました。


2. Gitによるデザイン管理

エンジニアさんとSketchファイルを共有する方法として、Gitを導入してもらいました。とは言え、大してGitらしい機能は使っていません。デザインを更新したらMasterブランチにコミットしてGitHubにプッシュするだけです。あまり褒められた使い方ではないですが、エンジニア側ではいつも使ってるツールで管理できて楽なようです。

なお、GitHubで大容量ファイルを使う為に、GitLFSという拡張機能を使っています。またSketchからの書き出しをコマンドで行えるようなコマンドラインツールも導入しています。これらの設定はエンジニアさんに教えていただきました。

3. 各デバイスの実装にデザイナーが参加

GitHubを触れるようになるとデザイナーも実際のソースコードを見ることができます。テクニカルクリエイターになりたかったデザイナー達は、ここで実装に手を出してみることにしました。最初のハードルはやはり高かったですが、エンジニアチームの寛容さとサポートのおかげで一歩踏み出すことができました。ここで各デバイスの特徴と、各デバイスを担当するデザイナーがそれぞれ具体的にしたことを振り返ってみます。

Androidの場合
Androidのビュー面（ユーザーに見える部分）はXMLでできており、HTMLを書いたことのある人なら割と直感的に書けると思います。担当したデザイナーはまずは文言変更や、今ある実装の変更から始めました。本当はjavaも書きたかったのですが、手が及びませんでした。

<実際に手を加えた部分の例>
・視聴者数が見づらかったのでレイアウトを変更して背景を敷いた。

コードの例
Before

<LinearLayout 
      android:id="@+id/feed" 
      android:orientation="horizontal" 
      android:layout_width="wrap_content" 
      android:layout_height="wrap_content" 
      android:layout_alignParentRight="true" 
      android:layout_alignParentTop="true" 
      android:layout_marginRight="11dp" 
      android:layout_marginTop="7dp" 
      > 
 
<!— テキストビュー省略 —> 
 
</LinearLayout>

After

 <LinearLayout  
       android:id="@+id/feed"  
       android:orientation="vertical"  
       android:layout_width="72dp"  
       android:layout_height="46dp"  
       android:layout_alignParentRight="true"  
       android:layout_alignParentTop="true"  
       android:layout_marginRight="6dp"  
       android:layout_marginTop="6dp"  
       android:gravity="center"  
       android:background="@drawable/shape_hoge”  
       >  
 
 <!— テキストビュー省略 —>  
 
 </LinearLayout> 

iOSの場合
iOSではXcodeのStoryboardという機能を使ってコードなしでピクセル単位の修正ができます。アニメーションなどコードで制御している部分も細かい数字調整などをデザイナーが手を出したりしました。なおメインで担当したデザイナーは今回初めてのXcodeでしたが、Storyboardをいじる部分からコードに触れるまで割とすぐできていました。

<実際に手を加えた部分の例>
・コメントの吹き出しの出方のアニメーションを調整

Before

UIView.animateWithDuration(0.6, delay: 0, usingSpringWithDamping: 0.7, initialSpringVelocity: 0.8, animations: layoutIfNeeded)

After

UIView.animateWithDuration(0.4, delay: 0, usingSpringWithDamping: 0.8, initialSpringVelocity: 0.8, animations: layoutIfNeeded)

ブラウザの場合
ブラウザはnode.jsベースのウェブアプリになっています。またAtomic Designという概念でデザインを進めており、最初に定義された異なる粒度のコンポーネントを組み合わせてビュー面を構成しています。
担当したデザイナーは各コンポーネントを組み合わせる形でHTML/CSSを修正し、コマンドを叩いてローカル上で確認していました。nodeのインストールやビルドの方法は最初にエンジニアさんに教えてもらいましたが、一度やればすぐできていました。

<実際に手を加えた部分の例>
・FAQの文字サイズを少し大きく変更

Before

 .text {  
     font-size: var(--font-size-xs);  
 } 

After

 .text {  
     font-size: var(--font-size-s);  
 } 

メリット＆デメリット

デザイナーとして実装に参加してみてよかったですし、これからもどんどんやっていこうと思っているのですが、感じたメリットとデメリットを正直に上げてみたいと思います。


1. メリット

• 気の済むまでデザインの調整ができる
• 細かいデザイン修正を頼む心苦しさがない
• 各デバイスの仕組みに少し触れられる

やはり自分の納得がいくまで調整できるというのは大きいです。1px単位で調整したくても「今そこまで言いずらいな」とか「あの時はこう思ったけど・・・」と引き下がってしまうことはデザイナーなら誰しもあるはず。

しかしながらもっとコードを書くことができれば、アニメーションなどもつくり込むことができてプロダクトのクオリティに大きく貢献できたなと思っています。


2. デメリット

• 時間とエネルギーを予想より消費する
• 慣れると仕事がどんどん増える
• たまに迷惑をかける

普段Sketchでデザインしてる脳でいざ他のツールでコード読んだり書いたりするとなると切り替えるのに結構エネルギーが要ります。またエンジニアさんがやれば数分で終わる作業がデザイナーだと１時間とかかかる時もあります。しかしある程度出来るようになると実装作業にどんどん時間を取られ、普段の作業にかける時間をひっ迫することがあります。

こうした方が良さそうなこと

今回、何か明確なやり方が確立されたわけではありません。デザイナーによってもどんどんコミットしたい人もいれば、そうじゃない人もいると思います。
しかしながら、これからプロダクトに直接コミットをするテクニカルクリエイターとしての機運が増えるのであれば、こうした方が良いと思った点がいくつかあります。

・実装にかかる時間も作業見積もりに入れる

実装作業を手の空いた時にやるという感じなので作業時間を見積もりに入れていない場合が多いです。本当は余裕を持ってテクニカルクリエイター業だけをやりたいところですが、そうもいかないので、本気でやりたいならちゃんと見積もりに含めたほうが良さそうです。でないといつまでたっても始められなかったり、いざやってみると他の作業ができなくなったりします。

・技術について意識を高める

せっかくやるのであればその技術についてどんどん勉強＆実践しましょう。プログラミング経験の浅い人間がエンジニア領域に手を出せる範囲には限界があるし、実際分からないことだらけです。理解が深まれば作業も早くなり、デザイナーがソースをいじる意味が強まります。またエンジニアさんとの会話についていけたりすると嬉しいです。

おわりに

プロダクト開発において、デザイナーという職種は作る物を描く重要なポジションではありますが、数的に言えばエンジニアより圧倒的に少なく、作業方法もマイノリティです。そのため開発においてボトルネックになりやすい気がします。

デザイナーが自然にGitHubを使ったり、もっとコードを書いたりと、テクニカルクリエイターとしての仕事を増やすことができれば、プロダクトのクオリティをあげつつ、さらに一体感やスピード感の出るプロジェクトになるかもしれません。今回のプロジェクトではその一歩を踏み出すことができ、これからさらに踏み込んでみたいという気持ちが強まりました。