1 pixel｜サイバーエージェント公式クリエイターズブログ -10ページ目

居心地の良いアプリを目指して

はじめまして。こんにちは。
株式会社タクスタデザイナーの中江（@mknakae）です。
7月にリリースしたライブ配信サービス「宅スタ」の　UIデザインを担当いたしました。

今回は簡単にですが、ユーザにとって居心地の良いデザインを心がけて如何にデザインの決定を行ったかを、ライブ画面に絞ってご紹介したいと思います。

宅スタとは

縦画面&業界初のフィルターで美肌加工することが可能なのが特徴の動画をライブ配信サービスです。

チームでのコンセプト

宅スタのコンセプトはおしゃれに動画配信ができること。
これを根本として、迷った時の裏のコンセプトとして「1日10回起動しても疲れないか？」を目標としていまし、ユーザーが何度見ても飽きないインターフェイスを目指しました。

居心地の良い縦配信を！

宅スタの最大の特徴である縦画面で配信するスタイルは私がチームにジョインしたときにはすでに決まっていました。
あとはライブストリーミングとしての最大限居心地が良いように機能をどのように見せるかでした。

まず、配信／視聴側の画面のすべての機能はこちらです
・全画面で動画が見える
・コメントが出来る、読める
・エールと呼ばれる★が飛ぶ
・誰が入室したかがわかる
・視聴数
・（配信者をフォローしてみよう！などの）チャットプツと呼ばれる自動的に入れる文章
・配信タイトル
・配信者情報
・配信時間

視聴側のみの機能
・★をとばして応援する機能

配信側のみの機能
・終了する
・配信情報を編集する

まず、配信タイトルや配信社情報はライブ視聴中にはあまり見ない情報として優先順位を下げ、左スワイプすると表示されるようにし、その他の情報はコメントと同じ場所に集中させました。
主に操作を要するコメントとエールの位置も、操作しやすい指が届くエリアに収めました。
コメントは配信社と視聴者とのコミュニケーションとしてもっとも重要なものなので、当初あった黒透過の上に白抜きの文字を表示させる案から、無透過の白背景を敷き、配信中の読みやすさを重視しました。ここまでで途中段階のUIです。

ここからさらに、とにかく配信してる人の映像を邪魔したくなかったので、画面の上部の要素を移動。

他にはこんなことをしています

・コメント表示エリアに、チャットオプツや入室情報も流れるようにし、配信、視聴中の情報はこのエリアを見れば良いように
・コメントエリアは全画面に対して60％もの表示領域をとっているので、画面をタップするという簡単な操作で表示／非表示を切り替えられるように
・閉じるボタンやコメント入力欄も、背景を敷くなどして見やすくしていましたが、動画の邪魔しないような表現に変更
・動きやインタラクションはなるべく自然に
・★（エール）は当初は1色でしたが、ここは盛り上げるポイントでもあるので入室したときに12色の中からランダムで色が振られる仕組みにし、視覚的に盛り上がる仕組みづくりを
・配信時間の情報優先度を下げ、画面に最下部に2pxのバーで簡略表現
・ユーザー情報は配信者も含め統一してモーダルで表現
・配信中でも配信情報を編集できる機能は配信画面を完全に隠さないように透過画面で
などなど

ユーザーにとって居心地のよいものにするために、こんな感じで1画面内の1機能ごとに、丁寧に細かく作り込んでいきました。

シンプルな画面を

文字で説明しなくても良い表現をさがしたり、インターフェースの構成要素に優先順位を付け、下げれるものをとことん下げたり。削れるところはとことん削って、ユーザーに考えさせず、気軽に使ってもらうために非常にシンプルに見えるUIになっていると思います。例えば配信開始フローの最初の画面。
ここは配信中のフィルター選択すると同時に、ホーム画面に表示される写真の撮影も行います。

タイトルが画面下部に入るため、なるべく画面上部に顔の目線を持って行って欲しかったので、下の方には薄くですが黒背景を敷き、ここより上に持ってくように自然と誘導しました。

最後に

このように、宅スタは「1日10回使っても疲れない」居心地のいいUIデザインに細部にこだわって作りました。
もちろん美肌が叶えられる動画のフィルターも必見です！
ぜひ1度アプリをダウンロードして使用していただけたらと思います。
最後まで読んでいただき、誠にありがとうございました。

UXなまトークvol.2 レポート

みなさま、こんにちは！
14年度新卒入社デザイナーの戸塚と申します。

今回は2度目の開催となります、
弊社で8/6に行われた『UXなまトークvol.2』についてレポートをさせていただきます！
どうぞよろしくお願いいたします。

『UXなまトーク』は、UXの現場のなまの声をトークするというイベントです。
各社どうのようにUXを考えているのか、現場ではどのように導入されているのかなどを対談、パネルディスカッションしていただきました。

登壇者は
DMM.comラボ井上誠さん × CyberAgent 大塚敏章さん
長谷川恭久さん × SIROK 石山貴広さん
Goodpatch 村越悟さん × CyberAgent 鬼石広海さん
AWA 室橋秀俊さん × AWA 冨樫晃己さん

インタラクションの現場でご活躍されている8名の方々です！
バラエティ豊かなお話を聞くことができました。
最後はパネルディスカッションもして頂きました。

Twitterを活用した質問など、登壇者と参加者の距離がとても近い！
ビールを片手にガチトークを繰り広げるすごい勉強会でした。

来れなかった人は残念すぎるんだぜ！(>_<)

なので是非下記にまとめた概要を読んで頂き、
次の機会に参加していただけたらと思います！

『インタラクションデザイン、その前に』

DMM.comラボ井上誠さん × CyberAgent 大塚敏章さん

インタラクションとは一体なんなのか？
アニメーション？カッコいいデジタルなフィードバック？

インタラクション＝世界観を作るというのは
わかっているつもりになっていても、わかっていなかったことなのかもと
改めて思うところでした！

インタラクションとは本来
「交流」「ふれあい」「やりとり」「相互作用」
という意味です。

人間は昔から「会話」というインタラクションを続けています。
プロダクトづくりも「ユーザーとの心地よい会話」という
言葉にとても惹かれました。
プロダクトも人格を持ち、ユーザーと会話をしていこうという考え方は
アプリのブランディングにも繋がるはずです。

そしてインタラクションはもちろん「人と人」だけでなく、
「人とコンピューター」の間にも起こることなのだと
井上さんが成長するロボットPalmiのお話しも交えて
説明してくださいました。

「インタラクション」はとても一言で表せるものではない…
広くて深い意味でのインタラクションについてのセッションでした。

『インタラクションデザインのこれから』

長谷川恭久さん × SIROK 石山貴広さん

このセッションではインタラクションの未来について語って頂きました。

・「ディープリンク」というFacebookなどで友達の記事を見に行った時
該当のアプリが開く機能があり、
今まではアプリは単独で存在していたが、これからは「アプリとアプリの関係」を
考えることになっていくだろうとのこと
SIROKではディープリンクの分析・運用ツールGrowth Linkなども開発されています。

・多くの種類のIoT(Internet of Things)がこれからも増えていき
スクリーンだけの話ではなく、スマホはリモコンのようなものになっていくだろうというお話しでした。
長谷川さんは記事やPodcastでもこういったインタラクションの今後の展望や様々な
課題について議論されています。
是非チェックしてみたいと思います！

・職と職の間をうまくつなぐ人(パイプラインエンジニア)が増えるかも？
コードとビジュアルの間をつなぐ人が必要となっていくのかも

ワクワクするようなテクノロジーの未来が垣間見えるセッションでした。
SF映画などで見る「未来っぽい」インタフェースやデバイス…
SF映画やアニメが好きな私はテンションがあがるお話でした。

遠い未来だと思っていた世界がもう目の前にきているのかもしれません。
そしてその未来を作るのは「インタラクションデザイン」なのです！

『インタラクションデザインの視点』

Goodpatch 村越悟さん × CyberAgent 鬼石広海さん

マネージャーとデザイナーという違った視点でみる
インタラクションについてトークして頂きました。

「偉大なプロダクトは偉大なチームからうまれる」
それは仕組みと組織をデザインするということ。
会社全体を俯瞰するマネージャー村越さんの視点

対して、現在AbemaTVでクリエィティブディレクターをされている鬼石さんは
マネージャーをなくそうという動きをしていて、
デザイナー、エンジニアが主体的にモノづくりを進めているとのこと。

真逆な考え方だな、と驚きましたが
「コミュニケーションが重要であり、
チームビルディングはプロダクト成功への鍵となる」
という意味では同じなのかもしれません。

AbemaTVでもGoodpatchさんのプロトタイピングツールProttを使っている
そうで、最近リリースされたSketchとの連携機能が
とても使いやすいとのことでした。(私も使っています)

『AWAインタラクションデザインの開発秘話』

AWA 室橋秀俊さん × AWA 冨樫晃己さん

話題の音楽アプリ『AWA』の開発秘話をそんなところまで！？
という細かい視点でお話しして頂きました。

AWAでは
【当たり前に使えるインタラクションにしよう】
に軸をおいてとにかくチームみんなでインタラクションに
こだわったということでした。
構造の矛盾は徹底的に考える！！

・位置関係
・トランジション
・ジェスチャー
・ディレイ
・スティッキー(AWAはスティッキーをあえて使っていないお話し、面白かったです)
・iOS7,iOS8への気遣い
・ストレスレスに作る

という細かいインタラクションにフォーカスして
こだわりを教えて頂きました。

終始プロダクトを見ないとついていけないという
ハイレベルなお話でした…！

しかしびっくりするくらい細かい気遣いがあるからこそ
「カッコイイ、おしゃれ、新鮮」と思いながらも
息をするように自然に使えるのだと思います。
そういえばAWAは使い方に悩んだことがないかもしれません…
(文章ではよくわからないかもしれませんので、是非AWAを触ってみてくださいw)

おわりに

他では聞けない貴重なお話が2時間半にギッチリと詰まっていました。
私も未熟ながらデザイナー、襟を正すとともに楽しくなって参りました…！

UX、インタラクションーー
デザイナーだけではなく全ての職種、人々が考えていくべきテーマだと思います。

現場からは以上です！
最後まで読んで頂きありがとうございました～！m(_ _)m

サイバーエージェントでは最新のインタラクションやクリエイティブで
世界に挑戦していくクリエイターを募集しております。
エンジニア・クリエイターキャリア採用サイト

興味のある方は是非一緒に世界を目指していきましょう！

採用サイトができるまで

みなさんこんにちは！2013年度新卒入社の横尾麻衣と申します♪
現在アメーバ統括本部にてゲームのUIデザイナーをしています。

1pixelで記事を執筆させて頂くのは、実は2回目になります！
(以前は、新卒が初めてブログデザインにチャレンジしてみたという記事を書かせて頂きました)

今回は私がデザイン/ディレクションを担当した、株式会社サイバーエージェントのエンジニア・クリエイター向けキャリア採用サイト制作の裏話をお話させて頂きたいと思います。

はじめに：エンジニア・クリエイター向けキャリア採用サイトについて

株式会社サイバーエージェントでは、テクノロジーとクリエイティブで勝負する今、現在エンジニア・クリエイターの採用を強化しています。

今回サイトを作るにあたって、お題として出されたテーマは

「サイバーエージェントの世界に向けた新たな挑戦が始まる。
今こそクリエイティブで勝負する時。
世界に通用するサービスを一緒に作る仲間を募集します。」

キーワードとして、以下のイメージを誘発させるようなサイトにしたいというオーダーがありました。

・新しいチャレンジ、挑戦
・世界を震撼させるようなサービスをつくる
・クリエイティブ、技術で勝負する覚悟
・ともに市場をつくる
・勝負どころ

以上をふまえて、構成に沿ってデザインの作成を進めていきます。

事前調査として行った事は

・競合企業の採用サイトを片っ端から見る
(話題になった採用サイトや、純粋に求める人材が似ている競合企業等)

・市場のwebサイトのUIトレンドや気持ちのよいアニメーションを体験し、ひたすら見る
(世界に向けた新たな挑戦をすると唱うからには、サイト自体のクオリティを高める為にワンエッセンスは絶対に必要！と思い、サイトの見せ方はもちろん動きの部分もかなり時間を割いて調査をしました。)

・採用担当人事からのヒアリング
(ここでは面接や社内を見てサイバーエージェントのどんなところが魅力という声が多いのかなど、社外から見た弊社の良いところを重点的にヒアリングしました。)

・キャリア採用で入社した社員からのヒアリング
(実際にサイバーエージェントで働いてみて、他社とは違う特色やココが良かった！といった実際の声を聞きました。)

これらのインプットした情報をアウトプットの材料にしていきます。

コンセプトの決定

事前調査を経て、コンセプトを決めていきます。

私がこのサイトをデザインする上で押し出したいと思ったサイバーエージェントらしさをキーワードに落とし込みました。

・良い意味の派手さ、インパクト

・自由で活気のある社内や人材

・クリエイターが絶対的に活躍し挑戦できる

これらのキーワードを軸として、デザインに取りかかりました。

コンペ案

実際に提出したコンペ案です。（都合上割愛致しますが、実際にはPCとスマホ両方のデザ
インを提出しています）

▼動画モック

設定したキーワードから、インパクトを狙って有機的で自由な、曲線の多いデザインにしています。コーポレートカラーの緑をメインカラーに白基調の、比較的ラフでとっつきやすさを意識しています。

コンペ案の提出まではいろいろ全く違うパターンをつくってみたものの、グリッドデザインやかっちりした、いかにも企業サイトっぽいまったく違うデザインもつくってみましたが物足りず、もっと面白く作れるはずだという考えのもと、思い切ってつくってみました。

メインにうねりのある波の動きを入れた理由は、サイバーエージェントは最新のトレンドを追い常に進化していく、形状をもたない液体のような会社だなと個人的に思い、まるで生きているようなサイトにしたいと思いこのデザインにしました。

私は当初からおもしろ枠で自分のコンペ案を出すと決めていたので、一番主張したい波の動きをいかにもやりすぎなデザインで提出しました。一番わからせたいものはやり過ぎくらいやってみて、後々ブラッシュアップの段階に入ったら差し引いて調整すれば良いので、コンペの段階ではやりたいことが明確にわかる「やり過ぎ案」で提出するのが横尾流です。

他とは違った遊んだデザイン案を出せたおかげで、狙い通り私のデザインが採用され、晴れて本制作のステージに進みます。

本制作の流れ

上の図はサイト制作の全体的なざっくりとした流れになります。

リリースまで約2ヶ月で、デザインfixまでには大体1ヶ月といったスケジュール感でした。

ブラッシュアップ前段階で課題だったのは、さきほどお話した「やり過ぎ案」から、とっつきやすさとインパクトは残しつつ、大切なキャリア採用サイトであるという事と、きちんとしたオフィシャルサイトらしさをプラスしなければいけません。

"きちんとした感"と"抜け感"の調整が難しかったのですが、他の社員のコンペ案から良いところを頂きつつ、ブラッシュアップを繰り返し行いました。

▼コンペ参加者の提出案

▼ブラッシュアップ後のデザイン

▼ブラッシュアップ前と後の比較

ビフォーアフターで比較すると、明るさとインパクトはそのままに、見やすくすっきりとした清潔な印象を与えられたことがわかります。

PCのデザインがfixした段階で、スマホのデザインに移ります。その間コーダーさんと連携を取りつつ実装を進め、アニメーション部分の細かい調整やディテールなど詰めていき、妥協せずリリースまでもっていきます。

エンジニア・クリエイターにリーチするデザインの工夫

●意識した点

今回最も意識した点は、少しでもサイバーエージェントに興味を持ってこのサイトを見てくれた方々に、どのようにサイバーエージェントの雰囲気や良さを伝えられるかを考えました。

コンペ案段階ではサイトトップに社内の風景画像を入れる予定でしたが、画像で全てを伝えるのはむずかしく、動画のほうが社内の雰囲気・設備・仕事風景など伝わりやすいのではと判断し、急遽動画に変更しました。

サイト内で使用した写真に関しても、自由な社風であるという事を伝える為に、人物画像もなるべくラフなスタイルや自然体の笑顔のものを選定しています。

写真を選定するのもデザイナーがやるの？と思う方も居ると思いますが、サイト全体のトーンにあわせた写真をデザイナーが選ぶ事で全体のまとまりや雰囲気を守る事が出来ます。

●工夫した点

意識した点で書いた、写真や動画の撮影に関しても、全てにデザイナーが入るようにしました。

エンジニア・クリエイターらしさを伝えるにはどのような風景を納めるべきか、社内の自然な雰囲気を伝えるにはどのようなシーンが必要かなど、全てにおいて実際にロケハンにいって細かく絵コンテを描き、動きやアングルの指示等あたりをつけた上で、ロケ本番に望みました。ここでは主にディレクション業務になりますが、デザインと平行して撮影を行うことで伝えたい事などを明確にカメラマンさんへ指示ができるので、デザイナーが撮影に入ることはデザインする上でとてもメリットのある事だと思いました。

▼実際にロケに使用した絵コンテ(抜粋)

●使用したツール

今回の採用サイトは、最近話題のsketchを使ってデザインを作成しています。

社内でもsketchを使った開発をしているプロジェクトが増えてきました。

sketchはガツっとモックをつくったり、スピード重視の開発ができる非常に直感的に使えるツールなので、実装段階でフロント周りのやり取りをするときに、書き出しなど非常に簡単にできるので、今回のサイト作成との相性はかなり良かったのではないかと思います。

おわりに

最後までお読み頂きありがとうございます！

常に新しいチャレンジをし続けるサイバーエージェントのキャリア採用サイトの作成ということで、ものづくりをする技術者にフォーカスし、弊社の良さを最大限に引き出すデザインが出来たかと思います。

サイト内のコンテンツもとても読み応えがあり、サービスの開発秘話や役員インタビューなど、弊社のものづくりへの本気がお伝え出来ると思います！

今こそテクノロジーとクリエイティブで勝負する時。
世界に向けた新たな挑戦を共にしてくれるエンジニア・クリエイターの皆様、エントリーお待ちしています！

▼画像をクリックでキャリア採用サイトに移動します

https://www.cyberagent.co.jp/recruit/special/techcareer/

デザイナー新卒研修について

はじめまして。2015年度新卒入社のデザイナーの松本と申します。
私たち新卒のデザイナーは、4月から6月末までの約3ヶ月間、デザイナー研修を受けてきました。
今回はそのデザイナー研修の内容や成果物を紹介させていただきます！

デザイナー研修の目的とは？

新卒のデザイナー陣は、それぞれ得意分野やスキルに差があります。デザインの基礎はもちろん、それぞれの分野のデザインや考え方を学ぶことで、プロのデザイナーとして必要な力をつけていく、そんな目的があります。

インフォグラフィックスのポスター制作

デザイナー研修の入り口は一見Webデザインとは関係ない制作でした。
配色の基本、タイポグラフィの基本、レイアウトの基本...etc
これらの講義を受けデザインの基礎基本を学び、その「デザインの基本」の課題として、まずインフォグラフィックスのポスターを作ることに。

テーマは「就活生に向けた弊社のアピールポイントをインフォグラフィックスとして表現せよ。」

インフォグラフィックスはまさにその名の通り「情報」を整理することが求められます。
いかに情報をわかりやすくまとめ、かつ魅力的なビジュアルに仕上げるか。ここにデザインの基礎が詰まっていたように感じます。
講師の方のコメント「ただのグラフになってしまったり、装飾やイラストでキャッチーにしようとしてもそれはインフォグラフィックスの本質とは離れていますね。情報整理の考え方はあらゆるデザインで大事になってくるので普段から意識しましょう。」

デザインは問題解決の手段です。常に本質を見極めなければなりません。

ゲームキャラクターのイラスト制作

弊社ではスマホゲームの市場が大きな柱の一つとなっています。
ゲームにはイラストがつきもので、デザイナーは開発時に

①自分で描く
②イラストレーターに指示を下す

このような仕事を期待されます。特に後者の「ディレクション側の動き」をできるようになるため、この課題ではイラストの細かい設定やコンセプトまで考え抜きました。

イラストの細かい設定まで決めて実際の業務でイラストレーターに指示を出す状況を想定しながら制作しました。

Webサイトのデザインとコーディング

研修ではもちろんWebデザインについても学びます。
まずWebは紙媒体と何が違うのか、どのようなアプローチができるのか、という知識を蓄え、PhotoshopやIllustlatorなどを使って制作しました。
Webデザインはトレンドの移り変わりが早く、デザインツールの仕様変更&アップデートも多く起こります。その「スピード感」に対応できる足腰を鍛えました。

そしてhtmlとcssでのコーディングもしっかり学びました。
実際の業務ではコーディングすることは稀ですが、デザイナーがコーディング側の仕組みを知っておくと、チームでの連携がとりやすくなるでしょう。
まったくの初心者でも数週間かければ一つの立派なWebサイトを制作することができました。

テーマは「サイバーエージェントのサービスをまとめたポータルサイト」。

こちらのサイトは背景に動画が常に再生されている仕様です。綺麗にまとめているので情報が把握しやすいですね。

こちらはキーボードを叩くとそれに合わせたインタラクションが楽しめるサイトです。
なんとデザインはもちろんJavaScriptを書いて本当に実装しました。

iOSアプリのインタラクションデザイン

最終課題は、「TO DO アプリ班」と「ゲーム班」に分かれて制作を行いました。
それぞれのアプリのコンセプト・UIデザインはもちろんインタラクションまで考え、最終的に動画にしてプレゼンしました。

インタラクションの目的

最近のスマホアプリはツール系、SNS系、ゲーム系どれにしてもインタラクションで大きな差がつきます。
「ユーザーのアクションによってUIがアニメーションする」ということは、ただ派手にアニメーションすればいいというわけではなく、
ユーザーの次のアクションに繋げるためだったり、ローディングなどのストレスを視覚的に減らすためだったり、明確な目的を持つべきです。

スマホアプリのフルネイティブ化の流れや、Pixateなどのプロトタイピングツールの充実もあってデザイナーがインタラクションをデザインする需要が高まっています。

そのような感覚を育てるためにも、デザイナー研修ではインタラクション・アニメーションにかなり力を入れて勉強しました。

TO DO アプリ班
『notty』

簡単に言えば「ほしいものリスト」です。しかし、普通のアプリとは違い、場所と時間で通知をしてくれるアプリとなっています。ツール系アプリは堅いモノになりがちなので、アニメーションでユーザーの動きを促進させる狙いで作りました。また、最近話題になったAppleWatchのUIまで制作しました。

ゲーム班
『MARUPON』

MARUPONは「シカク」たちに捕まえられた「マル」たちを救出する話で、天井にぶらさがってジャンプをしながら前に進むワンタッチゲームです。スマホ自体を直接4回転させる独特なプレイ方法が特徴です。
シカクの世界の話なので、ゲームのボタンやUIはできる限り四角形を使って、世界観を守るようにしました。

最後に

弊社のデザイナーは、UIを作る人、イラストを描く人、CGを作る人など、さまざまな役割をもって活躍しています。
それぞれの分野でのノウハウやトレンドを理解して開発・運用していくことが求められます。

しかしすべてに共通して言えるのは、

最高のプロダクトを作るためにはもっと広い視野でモノづくりを見つめなければならない

ということです。

その広い視野を手に入れるために、私たちはデザインがどのような役割を持っているのか、どうすればその役目を果たせるのか、本質的なところをまず学び、
それから実際の業務に必要な技術・ツールをしっかりと身につけました。

ここまで手厚い研修でデザインのことを学べる機会はそうそうないと思います！
このデザイナー研修で得た経験をフル活用して、私たち新卒も良いプロダクトを生み出せるように頑張ります。

最後まで読んでいただきありがとうございました！

ボーイフレンド（仮）〜動くカードができるまで〜

ボーイフレンド（仮）でアートディレクションを担当しております池田と申します。
今日はカードイラストが出来るまでの課程をのお話をさせていただければと思います。

「ボーイフレンド(仮)」は、藤城学園を舞台に様々な個性をもつ男の子たちとの出会いを楽しみながら、運命の「カレ」をみつけることができる学園恋愛ゲームです。キャラクターデザイン原案は潤宮るか氏が担当されています。

今回はその中でも藤城学園2年生の周圭斗というキャラクターの動くカードについてご紹介しようと思います。

▲ゴシックな出で立ちとその美少年っぷりを際立たせるツンツンさが魅力です。

▲今回ご紹介するのはこのカードの制作過程。動きます！

①カード原案Ⅰ～キャラのここをみてみたい！～

カードを作る際に、アートディレクター、シナリオディレクター、プロデューサーとの話し合いからスタートします。
まずは軽くブレスト・・・このキャラクターの場合はこんな内容があがりました。

　・「甘えられたい」

　・「特別感が欲しい」

　・「かわいい一面を見たい」

初期段階から○○をさせようという事を考えるのではなく、「そのキャラクターの事が好きな自分が何をされたら嬉しいのか」という根本的な大枠の欲求をどんどん出していきます。

②カード原案Ⅱ～キャラらしさとは？～

①をふまえた上で今度は「キャラクターらしさ、魅力を引き出す」という観点で、実際に何をさせようか、どんな話にしていくかを詰めていきます。

たとえば「甘えられたい」を例に挙げると、甘えられたいと言っても男子の甘え方は色々あります。また甘える事が得意なキャラクターもいれば、そうでないキャラクターもいます。

今回例に挙げている周圭斗というキャラクターの場合、なかなか簡単には甘えてくれません。それなので、甘える必然性をストーリーに組みこむ必要がありました。

そこから話し合いのすえ、「周が熱を出してしまい、その看病をする」というストーリーと、カードイラストにする事にしました。

これでキャラクターが主人公に甘える必然性、かわいい一面を見る事が出来る、看病してあげる特別感という要素を全て兼ね備えることができました！

③カードイラスト制作開始！

シナリオディレクター、プロデューサーと話し合いながら、ラフを制作しました。
それをもとにカードイラストをおこしていきます。

【ラフ】
ここで一番重要なことは狙いが分かるかどうかです。

・どこにいるのか？
・どんな状態か？
・キャラクターの感情は？
・見た人にどう思ってもらう事を想定しているのか

絵的なクオリティアップは後でいくらでもできるので、まずは目的を明確にする事に重きをおきます。また、だいだいこの段階で実際にどのような動きをさせるのかを想定しています。

【線画】
細部までじっくりこだわり抜いて線画を抽出します。どんなに綺麗な顔をしていても彼らは男の子なので、’’男の子感’’はどのキャラでも大切にしています。（どんなに中性的なキャラでも、内股になりすぎない、腰をひねりすぎない、脇をしめすぎない・・・など）

【パーツ分け】
そして線画の段階からこのようにパーツ分けをし、次の行程に進みます。

【着色】
線画を活かした塗り、重くなりすぎずライトさがある塗りを心がけています。

【仕上げ】
仕上げで背景と合わせ、ぐっと雰囲気をプラスしました。

この後、カード枠に入れ完成です！

④絵コンテ

カード絵が出来上がったところで、今度は動かすための絵コンテをおこします。

【絵コンテ】
実際に収録された音声データを聞きながら、キャラクターの仕草を絵コンテに落とし込みます。声優さんの間のとり方や息づかい、セリフとその心情、キャラ性をふまえてコンテを描きます。鮮明に頭の中で仕草と表情の流れを思い浮かべるために何度も何度も音声を繰り返し聞きます。

各仕草に狙いがあり、どういう気持ちの現れでそれに至るのかが分かるよう、感情の解説をを付け加えています。あくまでも動きの豊かさを出すための’’感情の解説’’という判断材料を提供するにすぎず、実際にはシナリオの意図、声優さんの意図が複雑に絡み合ってできておりますのであしからず！

▲話をしている時の、何とも言えない揺らぎや間を表現したいと思いながら制作しています。

・・・絵コンテをもとに、アニメーターとやり取りをくり返し完成！

苦労したかいがあり満足のいく仕上がりになりました。しかし毎回反省点と改善点が見つかり、次回はこれをさらに越える素敵なものを作ろう！という気持ちになります。

最後に

絵コンテの部分でも何度か意図という言葉を使って紹介致しましたが、イラストを制作するうえでの根本的なところでも、意図は絶対に必要です。しかし意図は答えではないと思っています。

キャラクターを表現するために関わる全員が意図を持ち制作する。イラストはその行程の集大成でもあり、私の仕事はその意図をきれいにパッケージすることです。

そしていったいキャラクターがどんな気持ちで話しかけてくるのか、ボーイフレンド（仮）をプレイしてくれている皆さんひとりひとりがその答えを考えて見つけられるよう、最大限キャラの魅力を引き出すカードイラストになったら良いなと思い、日々制作しております！

これからもボーイフレンド（仮）をよろしくお願いいたします！
（まだプレイしたことのない方、ぜひプレイしてみてください！）

iOS 9 の Search API でできる事

本稿は Apple Developer Program にログインせずに得られる情報で構成されています。また執筆時点での iOS 9 のバージョンはβ2であり、リリース版とは状況が異なる点があることをご了承ください。

こんにちは。AmebaアプリのiOS版を開発しているなめき @Ridwy です。

運良くチケットが当たってWWDC 2015に参加してきました。 iOS 9, OS X El Capitan, watchOS 2の３つの新OSとともに今年も様々な内容が発表されましたね。

特に iOS 9 でユーザ体験を大きく変えそうな要素としては、検索の強化とアプリへのシームレスな連携 (Deep Link) があります。これまで検索といえば「ググってWebページを閲覧する」という感じでしたが、iOS 9 からは対応アプリがインストールされていれば結果を直接アプリで見られるようになります。また、サードパーティ製アプリ内のデータも検索可能になり、アプリへのアクセスがグッと楽になりそうです。

AndroidのApp Indexing機能と言い、検索とアプリの連携については近年熱くなってきているように思います。今回はiOS 9 のパブリックβ公開を目前に控え、強化された検索機能について調べてみました。

どうやって使うの？

検索は Spotlight か Safari の検索窓から行います。もちろん、Siriに話しかけても良いです。 Safari の結果には、コンテンツが Web上にもあるものが表示されるようです。

以下は Session 709 で紹介されていた Spotlight での検索結果の例です。表示内容はサムネイル、タイトル、説明、住所...となかなかリッチです。ここから電話をかけたり、（この例には表示されていませんが）動画や音楽を再生したり、経路案内を開始したりといったことも可能です。

結果をタップするとアプリに遷移し、アプリで内容を確認できます。他の結果が見たければステータスバーの「Back to Search」をタップして検索結果画面に戻れます。遷移アニメーションはナビゲーションの動きに似たさりげないものになっており、連携がスムーズに感じられます。また、このアニメーションのためかホーム画面の一番左にSpotlightのスペースが復活しています。

何を調べられるの？

少し分かりにくい表現になりますが、Cloud Index と Device Index に登録されているものが検索結果に現れます。Cloud Index はすべてのデバイスから参照されるクラウド上のインデックス、Device Index は端末固有のインデックスです。これらのインデックスには WWDC 2015 で発表された Search API によってサードパーティもアイテムを追加できます。

Cloud Indexには、レシピアプリならレシピ、ホテル検索アプリならホテルの情報などが登録されていると便利そうです。Device Indexには、ユーザが作成したデータやプライベートな情報を入れると良さそうです。

特筆すべきなのは、特定アプリをインストールしていなくてもインデックスにあるものは検索結果に現れる点です。タイミング的にアプリがユーザの目に触れる良いチャンスになりそうですね。

インデックスへの登録方法

Search API には CoreSpotlight API, NSUserActivity, Web Markup の3つがあり、それぞれ登録できる内容やインデックスが異なっています。

CoreSpotlight API と NSUserActivity はiPhone 4s, iPad 2, iPad (3rd generation), iPad mini, そして iPod touch (5th generation)ではサポートされません。 Web MarkupによるものはiOS 9がインストールできる全てのiOS端末に加えてOS Xでも検索できます。

Core Spotlight APIs

Core Spotlight APIs を使うと、Device Index への登録・更新・削除が可能です。 CSSearchableItem が検索可能なアイテム、CSSearchableIndex がインデックスを表すクラスで、こんな感じに登録できます。

let attributeSet = CSSearchableItemAttributeSet(itemContentType: kUTTypeImage as String)
attributeSet.title = "Title"
attributeSet.contentDescription = "Description"
attributeSet.thumbnailData = UIImagePNGRepresentation(UIImage(named: "photo")!)

let item = CSSearchableItem(uniqueIdentifier: "123",
               domainIdentifier: nil, attributeSet: attributeSet)
CSSearchableIndex.defaultSearchableIndex().indexSearchableItems([item]) { _ in }

iOS 9.0 API Diffs を見ると CSSearchableItemAttributeSet には曲、写真、動画のメタデータや電話番号や位置情報などの多くのプロパティがあります。これらを使ってリッチな結果を表示したり、詳細な条件での絞り込みが可能になるのだろうと思われます。

Core Spotlight APIsはバックグラウンドでもインデックスを操作できるので、Push通知と組み合わせると最新の情報を検索できるようにすることが可能です。

NSUserActivity

NSUserActivity はアプリの状態を保存しておくことができるクラスで、iOS 8で登場したデバイス間で作業を引き継げるHandoff機能のために導入されたものです。 iOS 9 では NSUserActivity を検索のインデックスに追加できるようになりました。

検索機能に関係するNSUserActivityの主なプロパティ

// Enable Capabilities 
var eligibleForSearch: Bool 
var eligibleForPublicIndexing: Bool 

// Provide Attributes and Keywords
var title: String?
var keywords: Set<String> 
var contentAttributeSet: CSSearchableItemAttributeSet? 
var expirationDate: NSDate 

// Restoring on the Web 
var webpageURL: NSURL? // Safariからの検索やアプリ未インストール時に表示したい場合必要

eligibleForSearch = true とすると Device Index に、eligibleForPublicIndexing = ture とすると Cloud Index に登録できます。（ただしプライベートな情報がCloud Indexで展開されてしまうのを防ぐため、一定数以上同じものが追加された時に検索可能になるという事です。）

有効期限を設定できるのが特徴的で、最近ユーザーが行った作業の履歴を表示するのに向いています。自前のWebコンテンツを持っていないアプリの場合、これが Cloud Index に登録するための唯一の方法になります。

Web Markup

Webページに特定のアプリへの Deep Link の情報を記載すると、ページのコンテンツをアプリで見る事が可能になります。Applebot という Apple のクローラーが、アプリへの Deep Link を Web から収集して Cloud Index に登録してくれます。アプリのサポートURLとマーケティングURLから探しだすということなので、この２つが重要になってきますね。

サポートされる Deep Link のフォーマットは Smart App Banners と Twitter Cards, Facebook の App Links です。

Smart App Banners

<meta name="myAppName" content="app-id=myAppID, app-argument=myURL">

Twitter Cards

<meta name="twitter:app:name:iphone" content="myAppName">
<meta name="twitter:app:id:iphone" content="myAppID">
<meta name="twitter:app:url:iphone" content="myURL">

Facebook's App Links

<meta property="al:ios:app_name" content="myAppName">
<meta property="al:ios:app_store_id" content="myAppID">
<meta property="al:ios:url" content="myURL">

myAppName はアプリ名、myAppID は App Store でのID、myURLは遷移時にアプリに渡されるURLで、アプリ側はこのURLからどんな情報を表示すれば良いのかを判断します。

これだけしか記載がない場合、検索結果にはページのtitleタグとdescriptionタグの内容しか現れません。結果をよりリッチにするには Open Graph または schema.org で定義されているフォーマットで情報を追加します。

WWDC15 Session 709 Introducing Search APIs より

Open Graph の audio, videog と Schema.org のスキームの AggregateRating, Offers , PriceRange, InteractionCount, Organization, Recipe, SearchAction, ImageObject がサポートされています。

まとめ

この機能がユーザーにとって便利なものになるかどうかはIndexの質に左右されるところが大きいですが、うまくいけば情報へのアクセスが格段にスムーズになるはずです。

参考

ピグブレイブ・デザインの開発秘話

ピグブレイブでアートディレクションを担当しているデザイナーの塚本(@lavitsea_art)です。
今日はピグブレイブの制作にまつわる裏話を色々と話せたらと思います。

RPGとしての「ピグ」を作ろう

まず、始めにアバターサービスとしての「ピグ」を一回頭から離してみました。今までのピグの「当たり前」をRPGゲームという枠で捉え直した時に、僕たちが挑戦すべき課題がいくつか明らかになりました。

箱庭式に囚われないRPGならではのフィールド表現

モンスターという未知の領域

「きせかえ」から「そうび」への進化

「PRG」向けのピグアバター化

クォータービューからの脱却

RPGと聞いて僕が最初に思い浮かべたのは「広大なフィールドを巡る旅」だったんですが、ピグブレイブはMMOのようにフィールドを駆け巡ることが技術的に難しかった為、どうにか今の仕様の中でも広大なフィールド感が演出できたらなぁという想いがありまして。

箱庭のピグエリア。クォータービューで壁に擬似的な遠近感を出している。

ピグブレイブのモック用エリア。高低差を使って遠近感を強調している。

ピグでは「当たり前」のクォータービューの表現方法では、壁に擬似的に遠近感を出してごまかす手法が限界でした。上図の２つのエリアなんですが、上のピグエリアでは擬似的な奥行きを壁で表現しているのに対して、下のピグブレイブエリアはクォータービューでありながらも高低差を出すことで遠近感を表現しています。しかし、この手法だと限定的で高低差がない場合は結局いつものエリアと見栄えが変わらないというのが問題でした。
ピグブレイブならではの新しい見せ方はないのかってすごく悩んでいた時、義理姉の息子と遊ぶ機会がありまして、その子が大好きなアンパンマンの図鑑を見せてもらって「あ、コレ使えそう」って発見がありまして。アニメの背景って草原とかがレイヤー上に交互に重なりあって構成されていて、それでうまく遠近感を出してるじゃないですか。会社戻ってアンパンマンの図鑑買っていったら「えっ？」って感じになりましたが（笑）

ピグと大きく違う点はピグブレイブではバトルの最中、グリッド内しか移動できないという仕様があったんです。それを逆手に取って移動不可部分のパースペクティブをクォーターからさらに縦に潰して視点を下げることでフィールドの広がりを見せることが可能となりました。エリアの途中からパースが変化するのでよく見ると不思議絵に感じてしまうかもしれませんが、そこを馴染ませてごまかす工夫をエリアデザインでは徹底してます。

モンスターという未知の領域

ピグでは「可愛さ」と「デフォルメ感」の追求が主なテーマだったのに対して、ピグブレイブのモンスターの方向性をどうあるべきかは最初の課題となりました。

RPGゲームではプレイヤーの敵として存在するモンスターですが、大きく分けて２種類あるかなと思っていて殺られる前に殺れ的な「定番タイプ」とモンスター同士が戦うゲームに多い「敵も味方も関係ないタイプ」です。市場の人気ゲームには、敵モンスターが仲間として活躍するゲームは非常に多く、それらのモンスターに共通して言えるのは仲間にしたくなる「可愛さ、格好良さ」がキーポイントになっている点です。現在のピグブレイブは前者の定番タイプに当てはまりますが、倒さないとプレイヤーが殺されてしまうほどの「怖い存在」にするべきなのか「可愛い存在」にするべきかが非常に悩ましいポイントでした。

結果、あまり決め切らず良い意味で幅を持たせておくことにしました。コンシューマと違い、融通の効くブラウザゲームなのでユーザーの反応を見つつ、日々研究を重ね今後のモンスターの方向性を考えていきたいと思っています。

また、モンスターデザイン制作の仕組みにおいては低コストで量産できる方法を確立しています。１体１体個別にアニメーションを作るにはかなりのコストがかかってしまう為、モンスターの構造をボーン(骨格)とアバター(外身)で分けています。アニメーションをボーンごとに作ってしまえば、現状１０種程度のボーンに対して、外身のアバター約５０体もあるため、外身のデザインさえ増やすだけで新たなモンスターが量産できるわけです。

「きせかえ」から「そうび」への進化

ピグではモチーフやカラーなどの様々な項目別にポイント制でアイテムを点数化しランクの管理をしています。一方ピグブレイブにおける「そうび」は見た目以外に「パラメータ/スキル/ジョブ/レアリティ」という要素が含まれています。もちろんUIでジョブやレアリティは確認できるはずですが「パッと見でわかる強さ、レアリティ、ジョブらしさ」をデザイン設計してうまく表現できないか、というのが一番の課題でした。

まずレアリティの差別化に関しては「大きさ」を一番のポイントに持ってきました。ピグの経験上ユーザー心理的に面積が大きくより目立つアイテムを好む傾向にあったので「大きさ」をベースに色使いやモチーフの見せ方などでレアリティの管理を行う方向性で進めていきました。

一方、ジョブの差別化は「シルエット」がポイントです。防具の描き分けはシルエットがコントロールしにくく、いつか破綻するとすぐに予想できたので「武器」をきっちり分けることをポイントにしました。ナイト=剣と盾・モンク=爪・ウィザード=杖・クレリック=メイスと専用武器とそれを持つ専用ポーズを与える事でシルエットの差別化を図っています。街や部屋にいる時は武器をしまっている状態になりますが、そこでも各ジョブごとに納め方が違ったりして微妙に設定が違うのもこだわりですね。

「改造」が加えたピグアバター

６年目を迎えたピグのアイテム制作の中で生まれた「もっとこうできたらいいのに」を集約した「改造」が加えられています。ピグのアバターはたくさんのレイヤーが重なって表示されているんですが、今回ピグブレイブではさらに新規レイヤーをいくつか追加しており、今までできなかった表現ができるようになっているんです。すっごく細かい話ですが（笑）たとえば、エルフのとんがり耳、ドワーフのでか耳、ニャンクスの猫耳が帽子を装備した時に「耳がちゃんと出る」ような仕組みになってたりします。あとは、ツインテールとかポニーテールなどの髪型が頭装備からはみ出ないような仕組みがあったりと。きっと気づかないような変化ですが、かなり綿密に計算されているんです。

ピグブレイブのバトルではグリッドが見える事が重要なので、見えやすいよう実はピグが縮小して表示されています。その仕様でも、ピグが可愛く見えるように顔・手足・体の比率を少し変えているんです。また、髪の毛もより立体を意識した描き方に変更していて、それに合わせて肌にも影を落としています。少しでも重厚な感じを出す為とエルフの白い肌色表現には影が必要でした。

さいごにメイキングを

せっかくの機会ですので、デザイン制作で描き貯めたラフなどいくつか貼っておきます。開発中のラフでボツ案もかなりありますが、興味のある方はぜひご覧下さい。

NPCたちのラフ。ここから各キャラのイメージを固めていきました。

ロブロフ海賊団のラフ。ドロンボー一味やピラフ一味的なコメディタッチの３人組をどうしても入れたくて(笑)。

モンスターのラフ。動き方とシルエットをセットで考えています。

スィンガルドの各地域のラフ。地図だけじゃ伝えきれない地域性は家具で少しずつ出していこうかと。

マルマルは水辺に浮かぶデッキを張り巡らせた漁師町なんです！壊れてもすぐに修理できるよう木材がよく使われています。

長くなりましたが、日々より良いクリエイティブをお届けしようとチーム一同励んでおります。長文におつきあい頂き、ありがとうございました。ハウジングも実装され、好きな家具を飾って自分だけの部屋づくりも楽しめるようになりました。ピグブレイブ、是非遊んでみて下さい！

30万人突破！MORPG
https://brave.pigg.ameba.jp

デザイナーの塚本でした。
https://lavitsea.amebaownd.com
owndやっているのでよかったらぜひ。

「AWA」のデザインはどのようにして作られたのか。

こんにちは。
AWAでアートディレクション／デザイン／ブランディングを担当しているムロハシと申します。

今回はAWAのUIデザイン、インタラクションがどのようにしてつくられたのか、先日行った「メディアプロデューサー養成講座」の講義内容をベースに、簡単ではありますが書いていきたいと思います。

「AWA」とは？

AWAとは、ひとことで言うと
「登録なしですぐに音楽が聴ける定額制の音楽配信アプリ」です。

サービスの特徴として第一にあげられるのは、

・好きなアーティストを聴くだけでなく「プレイリスト」を軸に、自分の好みにあった音楽が「リコメンド」されること

リコメンドを通じて「昔好きだったあの曲」や「まだ知らなかったけど好きな曲」を一人ひとりにパーソナライズしてお届けしています。

そのほかの詳しい説明はプレスリリースをご覧いただければと思います。

インタラクションモックの重要性

AWAの初期の開発チームの体制は以下です。

チームの結成は2014年8月。実質プロデューサーは、6月から市場調査やサービスの企画など、結成前の母体となる軸を考えていたとのことです。デザイナーである私がジョインしたのは結成から2カ月後の10月でした。

ここからの2カ月間、仕様設計とデザインを同時並行で進めていき、デザイン自体は12月末の時点でほぼ完成しました。

この期間、自然に、デザインと同時にインタラクション専用のモックをつくる体制に変化していきました。

デザイナーは、インタラクションのイメージをもってデザインをしているのは当然なのですが、実際どう動くかは、またその動きにどんな体感を得るのかは「動かしてみないとわからない・・・」というのが常に悩みでした。

簡単な動きであれば、FlashやAfterEffects、最近では Pixateなどのツールをつかって共有ができるのですが、こだわりの強いインタラクションになればなるほど、数ミリ秒のズレで「得る体感」が全然違います。

ここを調整していくにはツールでは限度があり、やはり実際のコードで表現するのが一番だと思います。
AWAでは、この部分をデザイン制作の段階でエンジニアと常に話しながら同時並行で進められたことが、とても大きかったです。

また、毎日チーム全体で２時間近い夕会を行い、デザインやインタラクションの議論を行いました。ここでチームメンバーの意見を聞いたり、こだわりを話し合ってデザインが進んでいきました。

本番実装までイメージのズレがなく進められたのも、この議論のおかげだったと感じています。

モック開発からデザインの軸が見えてきた

すこし話を戻して、デザイナーが加入前の2カ月間は、エンジニアが主体となって各々が思うアプリをイメージしてモックづくりをしていました。

サービスの仕様も決まっていたのは
「パーソナライズされた音楽がリコメンドされる」
ということだけ。

デザインももちろん存在していないので、すべてバラバラです。

実際のモックは以下のようなものです。

手探り状態でのモック開発でしたが、モックは動かないデザインと違って実際に触って動かせるので、その体感から「いいところ」「悪いところ」が見えてきました。

とくにインタラクションではデザインを決めていく部分ですごく参考になりました。

たとえば、
・視差効果（パララックス）は、使う箇所で良くなったり悪くなったりする
・動きのインパクトを重要視するのではなく、統一性と洗練性で全体的な心地よさになる
・インタラクションは言葉で説明せずに動きで理解させることができる
といったことです。

こういった発見をもとにデザインを進めていきました。

その過程で見えてきたのが

「デザインやインタラクションにおいて矛盾をつくらない」
ということ。

たとえば、AWAでプレイリストを見るときに、「プレイリストのサムネイルは、進むときも戻るときもおなじ動き」をします。

バックボタンは当然ですが、iOS標準のエッジングバック（画面の端から右にスワイプすること）を行っても同じサムネイルの動きをさせているのがその特徴です。

（背景部分は右に移動し、サムネイルは残った状態にする）

なぜそういった実装がされているのかというと、ページが進んだときは サムネイルが浮いて表示 された のに、戻るときに 一緒に右に戻ってしまった ら、ちょっとした違和感を残してしまうからです。

ほんの小さな矛盾ですが、こういった矛盾が積み重なるとアプリ全体で大きな矛盾になってしまいます。
この「矛盾をつくらない」という軸が、どんなインタラクションにするのかを考える、ひとつの基準になりました。

デザインで実現したいこと

もともとプロデューサーからデザインの要望として、
・今までにない、とにかくクールでかっこいい
・海外のアプリのようなインパクト
・考えないで感覚的に使える
といったものがありました。

ここで非常に難しかったのが、「今までにない」というUIと「考えないで使える」というUI。

UXの分野になりますが、「考えないで使える」ということを実現させるには「よく見かけるUI」を採用することが一般的な考え方です。たとえば、Facebookでよく見かけるUIだったら、Facebookユーザーは考えなくてもわかるUIだ、ということです。

でも、AWAでは「今までにない」という要望もあります。

なので、AWAのデザインで実現したいことを言語化すると、
「誰もが見たことないインターフェイス」でありながら 「操作が直感的で、感覚的に使えること」
となります。

私はこれを
「人に薦めたくなるデザイン」
というように置き換えました。

・今までにないインパクトだけのデザインだと、操作が難しくて人に薦めにくい。
・よくあるインターフェイスだと、すごく良い機能でない限り積極的には人に薦めない。

しかし、「インパクト」かつ「使いやすい」が共存さえすれば、
積極的に人に薦めたくなる、人に見せたくなるのではないか、と考えたのです。

そのための「見た目の斬新さ」だったり、「iOS, Androidで差をつくらないつくり」が必要だったり、デザインで表現、工夫、解決すべきところが徐々に見えてきました。

デザインにおいて、ユーザーにどんなことをしてほしいか、どんな風に感じてもらいたいか、このあたりを念頭に考えると、自ずと実現したい方向性が見えてくるのかもしれません。

デザインには右脳と左脳が必要

実はもともとジョインした10月の時点で、ある程度のデザインが仕上がっていました。
それがこちら。

デザインは違えど、これが現在の遷移構造やメニュー表示のベースになっています。

こちらをもとに、まず私がデザインしたのがこちら。

前述のモックもまだ見ていなくて、デザインの軸もなにも決めていない状態で考えたものなので、かなり粗が目立ちますね。。

これは自分の感覚だけでデザインすることで、インターフェイスの発想を広げたかったのが狙いです。

フォント、マージン、ブラー処理など、実装上の都合は全く考えず、余計な固定概念を取っ払って、まずはデザインをしておきたかったのです。

このとき、なんとなくですが、ジャケットを主役にしていこうと考えていました。

なぜジャケットを主役にしようと思ったのか。

それは「ジャケット自身がすでにアーティストのこだわりによってデザインされたもの」だからです。
なので、アプリのデザイン都合で、ジャケットが目立たなくなってしまったらいけないな、と考えました。（この段階ではメイン画面でもジャケットを全面背景にしていますね）

こういった右脳だけで作ったデザインをもとにしてチームと議論をするなかで、ベースのデザインが決まっていきました。

そして実際の画面はこちらになります。

ベースのデザインができた段階で、ここから今後はアプリ全体の構造を考えました。

この構造は、アプリ内の画面が、どのレイヤーにいるかを図式化したものです。
このあたりから矛盾がないようなつくりを意識し始めました。左脳の出番です。

デザインルールも、全体のデザインがある程度出来上がってから作っていきました。

普通は、デザインルールを決めてからデザインするのかもしれませんが、それだと左脳をつかったデザインしかできません。
最初にルールを固めてしまうと、そのルールを超えたデザインにはならない、と思ったのです。

このルールも絶対的なものではなく、制作過程で「もっとクオリティがあがる」と判断したものはどんどん変更していきました。
たとえば、アイコンやフォントサイズなどもこのルールからすこし変更している箇所があります。

右脳をつかって出来上がったデザインに対して、左脳をつかって構造やルール付けをしていき、全デバイスへ統一をしていく。

この作業は効率は悪いのかもしれませんが、エモーショナルなデザインをつくる場合においては重要なのではないかと思います。

ロゴについて

前述のラフデザインを見て「あれ？」と思ったひとも多いかと思いますが、 AWAは開発当初はRobinと呼ばれていました。

AWAというネーミングは、弊社社長の藤田がつけた名前ですが、「線対称」という文字の見た目の良さで決めていて、その言葉にとくに深い意味はありません。

（参照：755「藤田晋のトークライブ」）

なので、AWAのロゴマークもその文字自体のつくりを生かして、ほとんどいじっていません。

実はけっこうなバリエーションで作成したのですが、意味をつければつけるほどAWA自体の強さが弱まっていく感じがあり、形を変えれば変えるほど別の印象を与えてしまうことにもなり、「クセのない強くて太いフォント」を綺麗にするのが一番だと判断しました。

フォントについて

「AWAのアプリ内で使っているフォントって何？」とよく聞かれるのですが、デバイスフォントのほか「Mplus」というフォントと「Tex Gyre Adventor」というフォントを使っています。

ベースで、デバイスフォントを使いながら、 AWAを印象づけるメイン画面は、Mplusの細いフォントを使い、タイトル名を大きく見せる表現をしています。ただし、細いのでセクションヘッダーなどではちょっと弱い。そこでアクセントとして「Tex Gyre Adventor の Bold」を利用しています。

これらのフォントとデバイスのフォント、合わせて３つのフォントをうまく使い分けることで、いろんな表現を可能にしています。

アイコンやパーツ部分の画像について

iOSとAndroidで、差がないようにデザインしながらも、「まったく同じにするのも実はよくないのでは？」と考えました。
その一つがアイコンやパーツ部分の画像です。

AWAのAndroidアプリ内のすべてのアイコンは、マテリアルデザインの標準としてGoogleが配布しているアイコンを使用しています。

標準のアイコンにすることで、Android自体の世界観を崩さず、かつ見慣れたアイコンで、ユーザーに迷いなく使ってもらうのが狙いです。
シャッフルボタンやリピートボタン、ラジオのボタンなど、よく見るとiOSとは違うデザインになっています。

iOSでも標準のアイコンを基本としていますが、iOSの場合は各アプリのオリジナリティも必要になります。
なので、一般的な機能のアイコンはメタファーを合わせながらも、 AWAの世界観に合わせて、ひとつひとつ作成しています。

作成方法は、最近は当たり前になっている「Sketch」をつかっています。
全体のデザインはPhotoshopをベースとしていますが、アイコンやパーツ部分はデバイスごとでサイズが変わってくるので、 Sketchが非常に効率的です。

また、アイコンやパーツの画像のほか、背景画像やジャンルなどの画像、スプラッシュの画像など、すべてをひとつのデータで管理できるので、そういった使い方としても有効でした。

（SketchデータのiOSアイコン群）

最後に

AWAは、デザインやインタラクションで注目されることが多いですが、これが実現できたのも優秀なエンジニア、デベロッパーがいたからこそです。
デザインについては、本当に毎日毎日議論をして変化していきました。
まさに「チーム全員でつくったデザイン」だと思っています。

また、リリース前にもたくさんの方々にテストユーズしていただき、本当にいろいろな意見をいただきました。
ローンチの最後の最後までデザインに粘ることができたのも皆様のおかげです。

AWAのサービスは、まだ始まったばかりです。
ローンチしてみてわかった部分、至らない部分などが浮き彫りになっています。
さらに世界のアプリデザインに目を向ければ、もっと良いデザインはいくらでもあります。

ですので、これからも気を引き締めてデザインをしていきたいと思います。

非常に長いブログになってしまいましたが、最後まで読んでいただきありがとうございました！

Ameba Ownd のフロントエンド開発

Ameba Ownd（アメーバオウンド）のフロントエンドエンジニア、五藤（@ygoto3_）です。前々々々回、前々々回に引き続き Ameba Ownd について、今回はフロントエンド開発のお話です。

本エントリーのアジェンダ：

はじめに
Ameba Ownd は３つのアプリケーションで構成
再利用可能な機能単位でのパッケージング
機能別のパッケージをまとめてモジュール化
複数のアプリケーションで再利用可能な UI コンポーネント作成
機能の独立性が高い大きなモジュールは非同期読み込みでファイル分割
３つのアプリケーションで異なるルーティングの特徴
階層が深いルーティング処理
動的なルーティング生成
アプリケーション間の連携
おわりに

はじめに

Ameba Owndのフロントエンド開発は以下の技術を使用して開発しました。

Ameba Ownd は開発開始からリリースまで約８ヶ月の期間を経てリリースしましたが、初期開発メンバー全員が話し合い、当時みんなが（若干の偏見や趣向も交えながら）サービスにとってベストだと判断した技術を選択しました。

Ameba Ownd は３つのアプリケーションで構成

Ameba Ownd は「誰でもかんたんにオシャレなサイトが作ることができ、共有しあえるサービス」ですので、サイトを作成する機能、閲覧する機能、共有する機能、と大きく３つの機能のアプリケーションで構成されています。

作成する機能：サイト管理アプリケーション - https://m.amebaownd.com/
閲覧する機能：ユーザーが作成・公開した Web サイト - （例）スターバックス様の Ameba Ownd 公式ページ：https://starbucks.amebaownd.com/
共有する機能：Ameba Ownd 自体のポータル - https://www.amebaownd.com/

上記３つは Web ブラウザで使うアプリケーションですが、ここに iOS アプリと Android アプリも加わり、Ameba Ownd という１つのサービスを構成しています。従って開発も大規模なものになりました。

本エントリーでは、Web ブラウザ版 Ameba Ownd を構成する３つのアプリケーションを開発する上でのフロントエンドの工夫について書いていきたいと思います。

再利用可能な機能単位でのパッケージング

３つのアプリケーションを同時に開発するのですが、３つ各々の役割は全く異なり、必要な機能も違います。

しかし、サービス全体で使いたい機能や共通のビジネスロジックもあり、共有できるところはできる限り共有したいです。開発当初は特定のアプリケーションでしか使わないはずだった機能が別のアプリケーションでも欲しくなったりすることもあります。

再利用可能なコードを増やすために機能単位で分けられたパッケージングをする必要がありました。

機能別のパッケージをまとめてモジュール化

Ameba Ownd をパッケージごとに図にすると上記のようになっています。こういった構成を表現することが、AngularJS のモジュールシステムを利用したことで比較的簡単にできました。機能別に小さな単位でパッケージングしておいたものを、依存モジュールとして大きなモジュールに登録しておくことで１つの大きな単位の機能としてパッケージングすることが簡単にできます。

機能別のモジュールを、依存モジュールとして以下のように登録するだけで、別のモジュールにその機能を取り込むことができます。

angular.module('featureModule', []);


// featureModule を取り込む
angular.module('sharedModule', ['featureModule']);


// sharedModule を取り込むことにより featureModule も取り込んでいる
angular.module('mainModule', ['sharedModule']);

３アプリケーションをそれぞれ AngularJS のメインモジュールとして作成し、全アプリケーション共通で持たせたい機能は別モジュールとして作成します。これを３つのメインモジュールの依存モジュールとして読み込ませることで全てのアプリケーションから機能を呼び出せるようにしています。

複数のアプリケーションで再利用可能な UI コンポーネント作成

Ameba Ownd のディレクトリ構成は、コードを機能別にパッケージングして管理するために、モジュールごとにディレクトリが別れています。これら別れたファイルたちを依存関係を解決してバンドルする必要があります。バンドラとして利用しているのが WebPack です。

WebPack は Browserify とよく比較されるモジュールバンドラの１つですが、静的アセットを全て管理する目的で作られているため、比較的機能が盛り沢山という点で特徴的です。（WebPackについての詳細は、過去の 1 pixel の記事である RequireJS等はもう古い。WebPackとは？が参考になります。）

Ameba Ownd の UI の多くは、その UI に必要な JavaScript、HTML、CSS（に変換するための CoffeeScript、Jade、Stylus ）を１つのディレクトリにパッケージングして管理しています。WebPack は JavaScript や CoffeeScript だけではなく、HTML、Jade、CSS、Stylus などもロードすることができるので、UI をコンポーネント化してまとめる役割をしてくれています。

NotificationSummary
├── index.coffee
├── indexSpec.coffee
├── template.jade
└── style.styl

１つのコンポーネントのディレクトリは上記のようなファイルが入っており、

module.exports = angular.module('components.notificationSummary', ['services.applyStyle'])

.directive 'notificationSummary', [

  'applyStyle'
  (applyStyle) ->
    return {
      restrict: 'E'
      replace: true

      # テンプレートファイルの読み込み
      template: require('jade!./template.jade')

      link: ->

        # スタイルファイルの読み込み
        style = require('!raw!stylus!./style.styl')
        applyStyle(style)

    }
]

上記のように CoffeeScript で書いた AngularJS の Directive 内で、Jade で書いたテンプレートや Stylus で書いたスタイルを読み込み、コンポーネントにバンドルさせます。このコンポーネントは必要なリソースを全て含んでいるので、別のアプリケーションからも再利用が可能になります。

また、WebPack は対象リソース用のローダーを別途追加することであらゆるリソースを JavaScript ファイルにバンドルできます。

サービスが大きくなってくると使用するサードパーティーライブラリも増えます。ある UI ライブラリが Sass などの Ameba Ownd では使用していない CSS プリプロセッサ用に実装されている場合もありましたが、そういった場合も言語の違いを気にせずに気軽にライブラリを試すことが可能です。

WebPack のおかげで、コンポーネント内で完結してる分には多少言語がバラついても影響範囲を最小限に抑えることができます。

また、将来的に現在 Ameba Ownd で採用している技術からほかの技術に移るような場合、例えば CoffeeScript から ES6 に変える必要があった場合にもコンポーネント単位でゆるやかに乗り換えていくことが可能なことも WebPack を利用するメリットです。

独立性が高い大きなモジュールは非同期読み込みでファイル分割

開発が進むにつれて、サービスに必要な JavaScript のコードは膨大になり、それを１ファイルにまとめてしまうと複数ファイルに分かれている場合と違い並行ダウンロードができないため、結果的に読み込みに時間がかかってしまう場合があります。

Ameba Ownd の機能の中には、ユーザーがある画面に辿り着くまでは読み込む必要が全くない機能も存在します。こういった機能のモジュールは別ファイルとして非同期に読み込むことで、Ameba Ownd にランディングしたときの初期読み込みの負担を軽くすることができます。

WebPack では Browserify と同様に同期的なモジュールバンドルの機能も提供していますが、非同期的に別ファイルとして読み込むことが可能です。

例えば、自分のサイトのアクセス数を確認できる「アクセス統計」機能などです。この機能を提供するための JavaScript ファイルは、ユーザーが「アクセス統計」画面にアクセスするまで全く必要のないものなので、この機能を提供するモジュールだけ別ファイルとして遅延ロードさせる方が得策です。

AngularJS は通常、アプリケーションに必要な依存モジュールが先に登録された状態でメインモジュールが起動されます。しかし、非同期で依存モジュールを読み込んで追加する場合は、既にメインモジュールが起動した後なので、単純に追加しようとしても上手くいきません。

そこで、Ameba Ownd では、ocLazyLoad という Angular モジュールやコンポーネントを簡単に依存モジュールとして追加できるライブラリを使用しています。

$stateProvider.state 'sites.stats',
  url: '/stats'
  resolve:
    stats: [
      '$ocLazyLoad'
      '$q'
      (
        $ocLazyLoad
        $q
      ) ->
        return $ocLazyLoad(path_to_module).then(
          ->
            return null
          ->
            return $q.reject(key: 'Module load failure')
        )
    ]

例えば UI Router の resolve 機能と ocLazyLoad を組み合わせて、以上のようなコードで簡単に Angular モジュールを後読みすることができるので便利です。このコードではアクセス統計画面にルーティング処理されるときに、アクセス統計のモジュールを読み込み、それが完了した後にアクセス統計画面へ遷移されるようになっています。

３つのアプリケーションで異なるルーティングの特徴

３つのアプリケーションは、その役割の違いのため必要となる画面数やルーティングの特徴がそれぞれ異なります。

作成する機能：サイト管理アプリケーション - 階層が深く、複雑なルーティング
閲覧する機能：ユーザーが作成・公開した Web サイト - 階層は浅いが、動的なルーティング
共有する機能：Ameba Ownd 自体のポータル - 階層も浅く、ルーティングもシンプル

Ameba Ownd は Single-page application（以下SPA）なのでフロントエンドでルーティング処理を行います。ルーティング処理はフレームワークである AngularJS を利用して行いますが、SPA でのルーティングを実現するオプションとして以下の３つがあります。

Angular New Router は開発初期当時の選択肢としては存在しなかったので省きますが、Ameba Ownd では画面遷移がそれほど複雑ではないアプリケーションについては ngRoute を使い、複雑なアプリケーションでは UI Router を使用しています。UI Router は ngRoute と比較して以下のようなメリットがあります。

複数の view を表示できる
テンプレートを入れ子にできる
親子関係の概念を持つステートにより、子は親のステートの設定を継承する

階層が深いルーティング処理

前述の通り、Ameba Ownd の３つのアプリケーションのうち、サイト管理の機能については、ルーティングが複雑です。まずアプリケーションの画面はペインが３つに分かれた構成になっているため、複数の view を別々に読み込む機能は必須です。

ページを細かく作成するためのアプリケーションなので、より細かい編集を行う画面は必然的に階層が深くなります。そのとき親子関係を持ったルーティングの状態管理は必須になります。

例えば、個別のページを編集する機能を提供する画面では、該当のページを特定するためのページ ID が必要となりますが、下の階層でも同じページを編集する機能を提供するので、そのページ ID は引き続き必要です。

このとき UI Router のように、ページ編集機能を提供する画面のうち一番上の階層で設定した処理を下の階層も受け継ぐ機能を提供してくれると、格段にルーティングの管理が容易になります。

また画面に親子関係を設定できると、階層を意識させるためのトランジションアニメーションの設定も容易にできるようになります。

前述の通り、サイト管理アプリケーションは深いページ階層を持っています。そのため、ユーザーが現在いる階層を相対的に意識できるように、階層を下ったとき、上がったときをユーザーにフィードバックする必要があります。Ameba Ownd ではページ遷移時のサイドメニューのトランジションアニメーションでユーザーにフィードバックしています。

上のように、階層を下ったときは右から新しいメニューが現在のメニューの上に被るように現れ、

逆に階層を上がったときは現在のメニューが左に捌け、その捌けた下に新しいメニューがあるというアニメーションで表現しています。

このアニメーションのサイドメニューが動く方向は、UI Router で設定するステートの親子関係に管理することができます。しっかり URL 設計をしておけば URL 遷移時に、現在のステートと次のステートの親子関係をチェックするだけでアニメーションの方向を判定させることが可能です。

動的なルーティング生成

サイト管理アプリケーションは複雑な画面構造と深い階層構造を持ってるため、UI Router を使用してルーティングを設定しました。しかし、ユーザーが作成・公開した Web サイトと Ameba Ownd のポータルでは、深い階層構造などはないため、ngRoute を使用しています。これらは階層構造はシンプルなのですが、ユーザーが作成・公開した Web サイトに関しては、動的にルーティングを構築する必要があります。

Ameba Ownd では、ユーザーは自分のサイトに対して自由にページを追加・編集・削除することができます。ユーザーの Web サイトを表示するとき、それらのページデータをサーバーサイドから受け取り、ページの種類や選択されているテーマ情報から ngRoute に渡すルーティングデータを動的に生成します。

アプリケーション間の連携

それぞれ別のサイト管理アプリケーションとユーザーが作成したサイトを表示するアプリケーションは、連携します。

サイト管理アプリケーションとサイトを表示するアプリケーションは、お互いに iframe 間で通信するためのインターフェースを持っています。

例えば、ユーザーがサイト管理アプリケーション側からサイトの背景色を変更するアクションを行った場合、背景色が変更することで影響される色を全て計算し、フォーマットに従った形で CSS 化したデータを postMessage で送ります。サイトを表示するアプリケーション側はその CSS データを受け取り、自身の head 要素にセットすることでサイトの色変更を行った際のリアルタイムプレビューが実現します。

おわりに

Ameba Ownd を構成する３つのアプリケーションを開発する上でのフロントエンドの工夫について書かせていただきました。

３つのアプリケーションを効率的に開発するために再利用性を高めるための機能のパッケージングや、異なる特徴を持ったルーティング処理、アプリケーション間の連携など、それぞれトライアンドエラーで開発をしてきた中でこういった工夫が生まれてきました。

フロントエンド開発をされている皆様にとって何かしら参考になれば幸いだと思っております。最後までお付き合いいただき、ありがとうございました。

フロントエンドエンジニア
五藤佑典
@ygoto3_

2017年度卒向けインターンシップ「DRAFT 2015」

こんにちは。サイバーエージェント新卒採用担当　白田です。
今回はデザイナー志望の学生の皆様へお知らせです。

いよいよ今年もサイバーエージェントインターンシップのエントリーが開始しました！
今年は今までのインターンシップとは少し違います。

ただイベントに参加して終わりではなく、「選抜（DRAFT）型」で展開し、
4種類のインターンシップ・プログラム（「短期集中型」「長期就業型」「コンテスト型」「講義型」）を実施していきます。

そして全職種1000人以上の参加者の中から、優秀な成績を納めたメンバーには

サイバーエージェントより正式に選抜メンバー認定証を授与し、

選ばれたメンバーは選抜型合宿に参加いただきます。（冬頃開催予定）

▼詳細・エントリーはこちらから▼

https://www.cyberagent.co.jp/recruit/special/draft/

その中でデザイナー向けのインターンシップは現在、以下３つのコースからお選びいただけます。

・DesignCAMP～デザインスプリント
・TechDesignCAMP
・弟子入り

ご自分の興味・得意分野に合わせてエントリーしてください！

※併願可能です。詳しい参加日程･コースは面談にて相談の上決定いたします。

DesignCAMP～デザインスプリント

DesignCAMPは短期間で課題に対するデザインアイデア、プロトタイプの制作、ユーザー検証、ブラッシュアップまで、実際にサービスを生み出すまでの一連のデザインプロセスを学べるインターンシップです。

本合宿では、Google Venturesが提案するスタートアップ向けの「デザインスプリント」というデザイン解決手法を用います。アイデアからプロトタイプの検証までを5日間という短い期間で行い、アイデアを形にしていきます。

■日程

8月5日（水）～8月11日（火）

■締切り

7月21日（火）12:00

■募集人数

15名程度

■参加者全員特典

・報酬5万円、交通費全額支給、宿泊所提供（※遠方の方のみ）

・社員との懇親会、その他各種イベント、参加優先権（社内勉強会等）

・優勝者にはご希望の最新デバイス、ソフトウェアを贈呈予定。

■場所

【東京】サイバーエージェント渋谷オフィス

▼エントリーはこちらから▼

https://www.cyberagent.co.jp/recruit/fresh/program_detail/id=10498

TechDesignCAMP

「TechDesignCAMP」はスマートフォンやタブレットで楽しめる音楽や動画サービスや、スマートフォン向けのゲーム制作を体験するインターンシップです。

実際にプロダクトが直面している課題や開発環境、デザイン設計の手法について当社社員による講演を聞いていただき、それを踏まえ、課題解決し、技術面、デザイン面での創意工夫に挑戦していただきます。

エンジニアとデザイナーがチームを組んで開発することで完成度の高いプロダクトを目指していただきます。

■日程

【エンタメ編】東京　:　8月27日(木)～9月3日(木)

【ゲーム編】　東京　:　9月9日(水)～9月16日(水)

【エンタメ編】京都　:　9月10日(木)～9月17日(木)

■締切り

【エンタメ編】東京　:　7月27日(月) 12:00

【ゲーム編】　東京　:　8月7日(金) 12:00

【エンタメ編】京都　:　8月10日(月) 12:00

■参加者全員特典

・報酬5万円、交通費全額支給、宿泊所提供（※遠方の方のみ）

・社員との懇親会、その他各種イベント、参加優先権（社内勉強会等）

・優勝者にはご希望の最新デバイス、ソフトウェアを贈呈予定。

■場所

【東京】サイバーエージェント東京オフィス

【京都】京都市内

▼エントリーはこちらから▼

https://www.cyberagent.co.jp/recruit/fresh/program_detail/id=10494

弟子入り

「弟子入り」とは、サービス現場の第一線で活躍するデザイナーのもと、約1ヶ月間実務に携わっていただく、長期就業型インターンシップ・プログラムです。

本プログラムは、世界観・コンセプトの設計、UI/UXデザインなど幅広い業務に携わっていただきます。また、その際、ご自身のデザインが実際のプロダクトに採用される可能性もあります

■日程

8月3日（月）～9月30日（水）の期間中、1ヶ月程度

10:00-19:00 平日のみ

※出勤日数と期間については応相談

■締切り

7月31日（金）12:00

■給与

時給1,000円

■参加者全員特典

・交通費全額支給、宿泊所提供（※遠方の方のみ）

・社員との懇親会、その他各種イベント、参加優先権（社内勉強会等）

■場所

【東京】サイバーエージェント渋谷オフィス

▼エントリーはこちらから▼

https://www.cyberagent.co.jp/recruit/fresh/program_detail/id=10497

この夏、ハードルを越えた先にあるもの

圧倒的にこの夏、成長したい

新しいことにチャレンジしたい、

ただのインターンシップではもうつまらない

優秀な仲間と出会いたい

自分たちのクリエイティブでIT業界を変えたい

サイバーエージェントのインターンシップはこんな皆さんの想いに

全身全霊で答えます。

ハードルを乗り越え、その先に出会う仲間、そこでの経験。

それらは間違いなく皆さんの財産となることでしょう。

今、サイバーエージェントでは
今年4月にロゴ、Amebaキャラクターを刷新し、

藤田社長自ら「クリエイティブ」の重要性を主張しています。

クリエイターにとってたくさんのチャンスにあふれている今、
学生の皆様からの挑戦、是非お待ちしております！

https://www.cyberagent.co.jp/recruit/fresh/internship/