読者です 読者をやめる 読者になる 読者になる

naMemo

うぇっぶやアプリやデザインに興味深々なキモオタのメモ

2016年の振り返りと2017年の抱負

振り返り 目標


f:id:oooNAKi:20170105002925j:image

2016年、光の速さで終わってしまって、びっくり。
早く終わりすぎて、2016年なんかできたっけ?という不安感が残ってるので、2016年に挑戦できたこと、
また、明日から仕事なので、2017年の抱負を書きます。

 

 2016年振り返り

 仕事
  • 新卒研修のカリキュラム検討および講師をした。若手の自分達主体でプロジェクトを回すことが覚えられた。社外向けブログも書いた。人に教えることは、勉強になる。
  • 五輪関連の仕事をした。4年に1度の経験ができた。メインデザイナーとして、いままでで一番やりがいのある仕事ができた。UI設計も実装も全部関われた。自分がUIデザイナーを志したきっかけであった「自分が考えたUIが、動的に動いた瞬間、一番やりがいを感じる」という気持ちを思い出せて初心に戻ることができた。失敗も経験でき、良い経験になったし、せっかくデカイ会社にいるなら、こんな風に影響度の高い仕事をしたいと思った。東京五輪も何らかの仕事に関わりたい。
  • UXデザインスキルを磨くことが出来た。半年くらい、社内の定性調査スキルを学ぶセミナーを受講できたので体系的に学ぶこともできたし、実際に社外の被験者に対して定性調査を行ったので学びも身になった。今年は実際にユーザニーズ→プロダクトへの落とし込みをがんばりたい。
  • 常に自分のスキルに対して不安を感じる1年だった(ビジュアルデザイン、実装技術などいわゆる制作スキル)。この1年、去年と比べると、インプットもアウトプットの時間も少なかったと思う。
  • 色々案件はやったけど、サービスに貢献できたという実感が薄かった。結局先輩に頼っているからそう思うのか、やっている案件のインパクトが小さいからそう思うのか、数字を上げられていないからそう思うのか、色々要因はあるかも。

 

プライベート
  • 英会話はじめた。外国の方と話すことに抵抗はなくなった。が、ちゃんとしゃべれるようになったかはなぞ。英会話初心者がDMM英会話で学ぶ - naMemo
  • 下半期くらいから、月3〜4回くらいのペースでジムに通う始めることができた。仕事切り上げてQOLあげるの大事だな〜と思った。
  • 上半期、社外勉強会に行っていたが、行っても身にならないなと思うことが多く、行かなくなってしまった。ただ、改めて、暮れ位に社外の人達と久々に話してみて、社外の人たちはこんなふうに考えてるんだ、すげえ!わたしはなんて世の中をしらない小娘なんだ・・・とか思い知った。今年は、知らない世界を見る機会を増やして視野を広げて、もっと積極的に社内外で揉まれたい。
  • Hack Dayに出た。デザイナーとしては全然役に立たなかった。もっと実装スキルをあげたいと思った。
  • 下半期から、友達と週1でもくもく会を設けることができた。ただ、だべって終わったり、明確なアウトプットを生み出せず、聞いておしまいといったことが多かったので反省。
  • 海外にいけた(台湾) 今年は結構旅行に行けてアクティブだった。
  • ヲタ活が捗った。狂ったようにハマるジャンルを見つけられたし、舞台いけたし、好きな俳優の握手会に行って同じ次元を感じられた。趣味があると、毎日がハッピーになる。

 

2017年の抱負


2017年は、自走できる年にする。

まだまだ自分の貢献で担当サービスをグロースしていけてる自信がないから、自分がここに貢献したと胸を張って言えるくらい、自分中心となって仕事をしたいし、自分でどんどん提案していける年にする。

1人のデザイナーとして、社内外での自身の価値を高めて、サービス外でも自走できる自信をつける。

 

そのためにやること。

  • やりたいとおもってる某デカイ案件にデザイナーとして食い込む。自分から仕事をぶんどっていき、100%でなく120%を意識してやる。達成しても+α何かできないか?常に考えて達成する。
  • 勉強会で登壇する。
  • 週に一回もくもく会をする。やったらやったことが目に見える状態にする。
  • もっといろんなことに挑戦できるような自信をつけるために英語力をつける。TOEIC受講して700点取る。
  • 月に四回ジムにいって体力をつける。
  • 12時〜13時には寝る。ちゃんと寝て仕事のパフォーマンスをあげる。
  • やりたいと思ったことに対して、すぐに何らかアクションをおこす(やりたいとおもったことを放置しない)

 

年末年始で、目上の人や頑張ってる友人や、色んな人と話して、わたしはまだまだ人生あまちょろで精一杯生きられてねぇなと思いました。だから、今年は、自分自身で頑張った!やり尽くした!と思える年にしたいなと思います。

仕事もプライベートも、全部楽しい年にするぞ!

PJで協働してUIデザインを作るための3つのポイント

f:id:oooNAKi:20161222022634j:plain

この投稿は、UIデザインアドベントカレンダー21日目の記事です。

https://www.adventar.org/calendars/1834

私は某企業のデザイナーとしてWebサービスやアプリのUIをデザインしています。 デザイナーは、サービスを成長させていくためにプロジェクト内の様々な関係者と協働し、ユーザとの接点であるインターフェースを作るのが仕事です。

関係者とは、たとえば、以下の4つが挙げられます。

  • ディレクター
  • 自分以外のデザイナー
  • エンジニア
  • ユーザ(今回はあまりフォーカスしません)

様々な関係者と働く上での課題

私が働いているサービスは、デザイナーから、「こんな機能どうか」「ここのUIもっと改善したい!」と提案できる環境です。 ただ、これらの関係者に対し説得力のあるUIをつくっていくのは、難しいということをこの1年で痛感しました。 ディレクターからは「それ必要なの?それで数値伸びるの?」と言われたり、エンジニアからも「それ仕様的に無理」と言われたりと、上手く進行しないことがしばしばあります。 デザイナーの立場として、自分がやりたいだけだと受け入れてもらうことは難しいです。

様々な職種と協働して働くには、各々が大事にしていることを理解し、きちんとコミュニケーションをして、説得力のあるUIをつくる必要があります。 その為に、私がこの一年で学んだ点を整理していきたいと思います。

①ビジネス価値とユーザニーズの両面で目的を設定する

UI設計にのめり込んでいると、自分中心的なデザインになってしまい、結局コレって何のためにやるんだっけ?というのを忘れてしまいがちです。

機能仕様をまとめる際に、UIの目的を、以下の観点で明文化して、何のために作るか立ち返ることができるようにします。

  • ビジネス的な価値

    • この機能は、どんな指標に効果があるか

    • 例:PV向上、UU向上、継続率向上 などなど

  • ユーザニーズ

    • この機能で、ユーザのやりたいことは何か。解決したいことはなにか。

これをまとめておくことで、のちのち関係者にレビューしてもらうときの論拠にすることもできます。

ちなみに、機能を検討していく際に、サービス内でKPIツリーを設定しておくと、サービスのビジネスゴールに対し、どの指標を伸ばしていくべきかわかりやすくなります。

KPIツリーとは、

例えばアプリのKGIを売上とした場合、売上を構成する要素を分解して施策が実行可能になるレベルまで落とし込まれた指標(KPI)の一覧です。

KPI tree ※以下のサイトから画像転載しています。詳細はこちらにまとまっています。

https://growthhackjournal.com/kpi-tree-for-app/

KPIツリーをつくることで、施策が影響を及ぼす指標も明確になるので、リリース後の効果検証もしやすくなります。 デザイナーもKPIツリーを意識することで「これ意味があるの?」議論を減らすことができます。

ただ、KPIも重要ですが、あくまでデザイナーは、ユーザとの接点を守る砦であり、ユーザに寄り添って面をつくることを忘れないようにします。KPI厨になって、ユーザが使いづらいサイトをつくってしまっては、意味がありません。

②自分のつくるUIの理由を徹底的に追求する

UIデザインも一人でやるものではなく、チームの他のデザイナーと一緒に議論しながらUI設計をしていくことが多いと思います。私の場合は、デザインチームでUIのデザインレビューを行っています。

ただ、デザイナーによって、UIに対する考えは違います。ときには、UIに対して意見が食い違ったり議論になったりする場合もあります。そのような場合に、他のデザイナー達に、自分がなぜこのUIを設計したのか意図を説明できる力が必要になってきます。

意図を説明できるようになるために、自分の作ったUI一つ一つに対し、自問自答しながらデザインしていきます。 例えば、達成すべきユーザニーズや、サービスのブランディングと照らし合わせて、

  • なぜこの色にしたか?

  • なぜこの情報の優先度にしたか?

  • なぜこのレイアウトにしたか?

というように、常に自問自答しながらUIを作ることで、自分の中で設計の理由を明確にすることができます。

自分のデザインに芯を通すことができるので、他のデザイナーにレビューをもらう際に、「これはもっとXXに改善すべき」といった意見に対し、単純にナアナアと意見を受け入れるのではなく、自分の中でのUIの根拠をもとに議論することができます。

蛇足ですが、UIの議論をしていて、「こうしたらどう?」という意見をもらった際に、SketchMirrorを使ってリアルタイム制作をし、その場で実機確認してもらうと、良し悪しの判断が即座に出来てウケが良かったです。議論も長引きません。

③UI/UXをデザイナーだけで決定しない

エンジニアに実装をしてもらう時にある課題として、UI設計終わった段階で、技術的な工数の事情や仕様モレで指摘をもらい、作り直し・・・になることが挙げられます。

UXやUIに関する仕事は、ディレクターやデザイナーが担いがちですが、施策の企画を検討するフェーズからエンジニアに入ってもらうことで、早い段階で仕様のすり合わせを行うことができます。

この検討段階で気をつけているのが、UIをつくりこまないことです。

エンジニアにとっては、Sketchなどでつくった、デザイナーにとってのワイヤーフレームも「作り込まれていて議論が終わったUI」に見えてしまうこともあるそうです(人によるとは思いますが)。 そのため、ホワイトボードや紙の上に、あえてラフなプロトタイプ描いて議論をすることで、職種関わらず関係者が検討しやすいようにします。

ペーパープロト程度であれば、エンジニアの人も一緒に絵を描きながら議論できます。 エンジニアリング観点から、機能をもっとよくできる提案をいただける場合もあります。

まとめ

デザイナーが様々な関係者と協働し、説得力のあるUIを提案するために、私が気をつけている3つのポイントをご紹介しました。

ここ最近感じたことは、職種を超えて、密にコミュニケーションし、多くのフィードバックをもらって議論したものは、目的に沿ったUIがうまれていくということです。 デザイナーは、単純な制作スキルだけでなく、各関係者との仲立ちができるコミュニケーション能力、自分の成果物を論理的に伝える力が必要になってきているなと思います。

英会話初心者がDMM英会話で学ぶ

英語

巷で話題のオンライン英会話に挑戦しています。

サービスはDMM英会話。 6月から始めたので4ヶ月くらい経ちました。

今のところレッスン時間はこのくらい・・・ 4ヶ月の割に少ないので恥ずかしい限り・・・

f:id:oooNAKi:20160927010346p:plain

改めて自分が英語を勉強し直した目的を振り返ってみようかと思います

なぜ始めたか

英語ができたほうが仕事のチャンスが広がると思ったからです。

わたしはWebデザイナーとして働いているため、海外ドキュメントを読む機会が多いのですが、仕事をしながら、義務教育で英語を6年やっている割に、私は英語が読めなすぎる・・・という危機意識が常にありました。

また、私の会社はTOEICの点数次第で海外のカンファレンスに行ける機会が多く、WWDCやGoogleIOに行くこともできます。 せっかくチャンスがあるなら行ってみたい!ということで始めたのが一番の理由です。

あとは、単純に、周りに英語が出来る人が多くて、できないことが悔しかったというのあります。(笑)

オンライン英会話でなくても、英語の勉強法はいくらでもあると思うのですが、私は怠け者なので、ある程度お金を払って強制力のある環境を生むことで勉強することにしました。

なぜDMM英会話にしたか

  • 好きな時間に、毎日25分できる
    • 仕事柄帰宅が遅いため、夜23:00以降や早朝もレッスンができるのが◎(この点は、どのオンライン英会話もそうだとは思います)
  • 教材が多い
    • 習熟度に合わせて教材がある
    • 毎日更新されるニュースコンテンツもあるため飽きない
  • 講師の幅が広い
    • レアジョブはフィリピンの方が多いようですが、DMM英会話はセルビアなど東欧の方もいらっしゃるので様々な国の文化の話が聞けてなかなかおもしろいです。
  • 安い
    • 月4950円!

どうやって取り組んでいるか

  • 最低週に3回はレッスンをする
    • そもそも毎日英語を学習する習慣がなかったので、まずは慣れるところから
    • 無理しない
    • 今は初級教材とBeginer Daily Newsをローテして飽きない感じでやってます
  • レッスン前にevernoteで予習・復習
    • 教材でわからない単語を事前に調べてメモっておく(25分は結構短いため、変な所でつまずかずに時間を浪費しなくなる)
    • レッスン後に先生と話したことやフレーズをメモる
    • 先生の印象もメモっとくと次回レッスン予約時に役立つ

参考 xn--n9j173g3ni9qkzqbgw4b7xv5wn.com

  • レッスン中、分からなかった単語はQuizletに登録して通勤中に眺める

quizlet.com

現状の成果

以前は「英語を話すこと」自体に拒否反応があったのですが、それがなくなったことが一番の成果だと思います。 観光客の外国人に道を聞かれてもビビらなくなりました。

お気に入りの先生が取れると、いつもレッスンが楽しみです!

現在の課題

  • 成長実感がない・・・
    • 本当にリスニングできるようになっているか、喋れるようになっているか不明
    • 講師は褒めてくれるがマジなのか常に疑ってる
    • 今後は、DMM英会話内のリスニングテストやTOEICを受けてみようかと思います
  • 会話しててもキャッチボールが続かない。ボキャ貧、フレーズが思いつかない
    • ぱっと文章が思いつかないので瞬間英作文をやり始めてみています
  • どの教材を使ったらいいかわからない
    • 自分の習熟度や弱みに対し、どの教材で学習するのが良いか分からない
    • これは、他の方どうしてるのかとても気になります

まとめ

DMM英会話を初めてみて、

  • 英語を学習する習慣が身についたこと
  • 英語を話す面白さがわかってきた

以上が今のところの成果です。

ただ、DMM英会話のみだと、ゴールに対する自分の成長実感が湧きづらいため、TOEICなど別の指標で図ってみても良いと思いました。 引き続きDMM英会話で勉強していこうと思います。

CMU#40 ✕ HTML5minutes#11に参加しました

イベント フロントエンド

cmu.connpass.com

大学時代からお世話になってる先輩が登壇なさるとのことでいってみました。 ※わたしは登壇はしてない・・w

イベント概要

  • フロントエンド関連の5分LTと15分セッション
  • ただ、今回は技術寄りの話よりも、エモイ話、ライフハック的な話が多かった(FE界隈のイベントだと珍しい?)

スミマセン。思いっきり遅刻したので聞いたものだけφ(..)感想メモ。

道家 陽介さん

森本 新之助さん「AngularJS製アプリのチューニングと『Webサイト』をつくるはなし」

遅刻のため聞けず・・

新 日出海さん「ESLintプラグイン作成でAST入門」

speakerdeck.com

  • ASTを使えばESLintの独自ルールつくれる。
  • これを応用するとコード上にネムイとか死にたいとかふざけたコメント書く奴を阻止できるw

参考: JavaScript ASTを始める最初の一歩 | Web Scratch

AST(Abstract Syntax Tree)はコードをパースした抽象構文木のこと。 JavaScriptの場合はJavaScriptオブジェクト(JSON)として表現されます。

ちゃちゃまるさん「LIFEHACK FOR CREATIVES」

www.slideshare.net

  • 大学一年生が登壇してたことにまずびっくり!すばらしい・・・。
  • 個人的に、SlackをTODOリストとして使ってるのが面白いなーと思った。そういえば私も、会社のチャットで自分専用ルームを自分用メモ置き場として使ってるから似たようなものかも。

Session 01.武井 絵利菜さん「フロントエンドエンジニア 心の武器」

www.slideshare.net

  • エンジニアが豆腐メンタル脱却したい時に役立つ心理学Tips。
  • 心理学を学ぶことで、今までは「自分が悪い!」と思っていた原因を、「こういう心理状態だからか」と客観視することで冷静に対処できるようになる。

自他共認めるネガティブな私にとってはとても刺さる内容・・・個人的に特に役に立ちそうと思ったものは

  • ツァイガルニック効果
    • 人間は未知、未完成のことに興味を抱く。あえてきりよく作業を終わらせないことで次に仕事を始めるときのモチベーションをキープできる。翌日のタスクをちょっぴり手を付けておくと良い。
  • ゲシュタルト療法
    • 自分の気持をはっきり認識し、言葉として外に出す。例えば苛ついてる時はなぜいらついているのかという根源を言葉として話すことで気持ちに整理がつく。
  • どうしても気持ちが晴れない時は・・・

Session 02.高見 新さん「フロントエンドエンジニアにオススメ服装術」

  • エンジニアの服装ってイケてない人が多いよねという話から(だいたいパーカー、ジーパン、スニーカー)
  • 服をきること=自分をデザインすること
    • 自分がどういう人と話したいか?(服装が似ている人同士は話しかけやすい。)
    • 自分をどういうふうに見せたいか?

Session 03.菅原のびすけさん「なぜアウトプットし続けるのか」

speakerdeck.com

  • 仕事で、やりたい案件、やりたい技術えらべない。ただ、待っていたらやりたい案件がくる・・・とおもいきや、会社や上司が自分のことをわかってくれてる・・は幻想。部下の気持ちを完璧に読み取ることは不可能。評価されるには自分ががんばってるようにみせないとわかってはもらえない。
  • 「自己ブランディング」の重要さ。「この仕事やりたいな。いつか来るだろう」という待ちの姿勢でなく、「私これできるんだぜ」と行動で示し続けていることで、「こいつはこういう仕事得意だから任せよう」となって結果的にやりたい案件をできるんだろうな。

Session 04.佐藤 拓朗さん「Githubをエンジニア以外にも使ってもらうには」

  • githubを非エンジニアにつかってもらうために初心者向け勉強会を実施した話。
  • gitの練習はワークショップ形式が伝わりやすい。
  • 郵便局メソッドといった現実世界におきかえた説明が理解してもらいやすい。
  • →わたしも新卒研修でgit教えるときに使えばよかった・・・

Session 05.河村 奨さん「映像スタジオとフロントエンド」

speakerdeck.com

  • スタジオづくりのノウハウの話
  • FE技術の部分:Riot.jsで映像テロップを作ってる
  • DIYワクワク!

参加してみて

  • エモイ勉強会も面白い。
  • コジコジさんの最後のまとめ&感想がよかった。(その日のふりかえりができたのが◎でした)
  • ライトな雰囲気で、自分も登壇してみたくなった。

ありがとうございました!

「プロフェッショナル」と呼ばれる人について考える

振り返り 仕事

プロフェッショナルとは

プロフェッショナル - wikipedia

ある分野について、専門的知識・技術を有しているひと。 そのことに対して厳しい姿勢で臨み、かつ、第三者がそれを認める行為を実行している人。

Wikipediaだとこういうふうに書いてあるけど、以前見たNHKのプロフェッショナルで出演なさってたコンシェルジュの阿部佳さんの言葉がかなりしっくりきた。

ひとつのことに対して、もっと前へ、もっと先を目指そうと自然にできる人

www.nhk.or.jp

どうしてこんなことを考え始めたかというと

最近上司から、
「最近、考えを放棄して、相手に答えを求めていることが多いよね。言われた通りにデザインしてることが多いよね。」
というご指摘を受けた。

確かにその通りで、ハッとした。 最近の私は先輩と比べて仕事が遅いという意識が先行して、とにかく早く仕事をこなすことを考えていた。
自分の成果物に対して何か指摘を受けた時は、「確かにその通りかもな」とそのまま受け取り、その指摘に応えられるように直したり、
「え、それって何色がいいとおもいます?」と直接相手に応えを求めていたりすることもあった。
今考えてみると、無意識のうちに、仕事を「ここまでやればいいだろう」というところで終わらせていたかも。

身近にいるプロフェッショナルな人たち

私が見ていて、この人すごいな、尊敬するなと思う人 は、
期限内に、言われたことやマストの仕事を100%こなすだけでなく、120%こなしている気がする。
こういうことできたらいいよね、というマストではないけど、みんなが「これやれたらいい!」という仕事をしているきがする。
そして、そのために、技術を磨いているとおもう。
そういう人が、うちの会社では、総じてプロフェッショナルと呼ばれてると思った。

わたしは、学生時代、成果物にこだわりすぎて、担当教員に80%を意識しろ!といわれていたけれど、
今考えるとそれがわたしの良さでもあったとおもうのに、今はその良さを殺してしまっていて、「デザイナーのくせにこだわりがない奴」になってる。
新卒1年目のときのほうが、もっとこのクリエイティブよくできないか?とこだわって、しかも小さな仕事でもワクワクしながら楽しんでいたとおもう。
今のわたしは、とにかく早くこなすことに意識がいきすぎたかもしれない。変に仕事に手慣れてきたのもある。
モチベーションの上がらない案件は、さっさとおわらせて、モチベーションの上がる案件に移りたいと思ってる。

期限はもちろん大切だけど、
もっと良いアウトプットが生み出せるか?
成果物について相手と議論するときも、もっといいものを生み出すために、自分で考えて相手とハラオチするまで議論することに努めるか?
この辺意識しなきゃただのサラリーマンだ、と思った。

まとめ

期限はあるにせよ、その期限内で、最高の、自分なりのアウトプットができるようになりたい。

2015年を振り返ってみる

振り返り 目標

2015年は、研究終わって卒業して、上京して、新卒でWebの会社でデザイナー兼コーダーとして入社して、色んな経験をした一年だった。 今年やったこと、来年にむけてやりたいことを整理がてら、長々と振り返ってみる。

2015年やったこと、できるようになったこと

1. 大学

研究を終え、無事に卒業する

思えば1月は、毎日研究のこと考えて、一日の研究スケジュールをきっちり立てて、毎日のように先生と議論して、ガンガン論文書いてた。結果として、自分で納得行く形で研究を終えることができた。 (2014年10月の中間発表でボコボコに叩きのめされた副査の先生にも納得していただけたのが嬉しかった)。

この時の熱量、必死さは何だったんだろうと考えてみたけど、卒業がかかってたのもあるし、半端な論文で終わらせたくない、やり遂げたいっていう意識が強かった気がする。 私は、追いつめられると力を発揮するタイプだなあと思う。この時の感覚を仕事でも活かしたい。

2. 仕事

新卒研修

企画研修

職種関係なく、グループで企画を考える研修をやった。この時の研修内容、今はあまり覚えてないけど、私のグループで考えた企画が最低評価で、悔しかったことは覚えている。なんでもかんでもつめこむのではなく、「一言で伝わる」「シンプルさのある」企画提案をする、という学びを得た。

デザイナー研修

デザイナーの最終課題では、LPのデザイン、コーディングを行い、成果物を制作同期内で発表した。 情報系の大学にいたので、自分のデザインやコーディングについて意見もらえる環境にいるのが嬉しくてたまらなかった頃。

「アーティスト」としてデザインするのではなく、ユーザのために、意図のあるクリエイティブを作る「デザイナー」としての心構え・ビジュアル設計の仕方が勉強になった。

具体的なビジュアル設計の仕方(自分のために覚書)

  • 1:LPのターゲットを設定
  • 2:デザインのコンセプト立て
  • 3:コンセプトから、カラースキーム、ビジュアルのムード決め
  • 4: 以上のことを念頭におきつつ、デザインに落としこむ
カスタマーサポート研修

地方拠点に実際に行き、カスタマーサポート業務を行った。 ユーザのナマの声を聞ける貴重な機会で、「自分のサービスが使われていること」を実感できたのが良かった。ただ、カスタマーサポートにくる少数意見をマスの意見と捉えてしまわないようにしないといけないなと思った。

チームでアプリ開発研修

エンジニアと共にチームで、1ヶ月でアプリ開発をした。少人数だったのでファシリテーターっぽいことも経験できた。デザイナーがチームに複数いる個人的にカオス環境だったが、お互い熱く議論できて、私だけで作っていたらできなかったであろう考えぬかれたアウトプットを生み出せたのが良かった。

ただ、デザイナーがこだわりすぎるとエンジニアにしわ寄せがいくことを痛感した。また、デザイナーもアプリのView部分の理解、開発ができたらエンジニアが嬉しいんじゃないか...?ということを意識しはじめる良い機会だった。

配属→サービス開発

UUの多い媒体に掲載するバナー制作

初仕事だったので、自分のつくったものが多くの人の目に触れることが、単純に嬉しくて、感動した。

この案件は、短期間でバナーの効果検証、改善、変更を繰り返し、ユーザに刺さるバナーを見つけるという施策だったので、デザイナーの私も数値を見ることを習慣づけることができた。この案件のおかげで、数値を元にデザイン案を提案できるようになったし、自分から「こうしたい、こうするべき」とがんがん言えるようになった。

自社サービスブラウザ媒体のコーディング

サービスのマークアップ命名規則が初見だと謎で、理解するのに時間がかかったので、CSS設計(BEM)、リーダブルコードなど、運用しやすいコーディングの勉強をした。

また、プルリクで誰かにレビューしてもらって、新しい知見を得ることの喜びを知る(学生時代は、コードデビューしてもらうことなんてなかったので)。この喜びから、どうしたらレビュー量が増えるか考えて、プルリクメッセージを書き始めるようになった。devブランチをmasterにpushするなど、今年はしょうもないミスが多かったので、来年は減らしたい...w

フロントエンドエンジニアさんとも話す機会が増え始めて、「エンジニアが開発しやすいデザイン、コーディング」について考えるようになった。 このあたりからVimmerに憧れを抱き始め、AtomをVimmodeで使いはじめる(半端w) GulpなどのタスクランナーやLinterも使い始めて、フロント界隈の知識も増えた。

ブラウザ版機能追加のUIデザイン、コーディング

わたしのいる部署は、UIデザインをするデザイナーと、コーディングする人が分かれていて、私はそれがフラストレーションに感じている(UIデザインした人がコーディングまでできればデザイン仕様書作る時間も削減されるし、自分の思い通りのデザインが実装できるから)。

制作業務を一貫してやりたい!と主張し続けた結果、この案件では、私一人でUIデザイン〜コーディングを任せてもらえた。 多くの人を巻き込んだ案件だったので、プロトタイプを作って、議論して、それをブラッシュアップするプロセスをいかに早く回すかめちゃくちゃ考えてた。

社外とのコラボ企画のコーディング

CSS AnimationやjQueryを駆使して、動きのあるアニメーション実装をした。自分から手を挙げて仕事をやらせていただいたが、自分の技術不足で、本来やりたかった動きが実装できなかったのが、悔しかった。技術を日頃から試したり、先輩にガンガン聞きに行ったりすべきだったかも。

また、仕様がコロコロ変わるので、社外とのやりとりが入る案件の辛さを感じた。上司が何度も修正を依頼してくることに対して、当時は苦しんだ。が、私達はプロだから、常に「もっとよく出来ないか?」と考えてアウトプットするべきで、今思うと、上司もそれを伝えたかったのかもしれない。

その他

  • 週一の定例で、最近私が良いと思ったサービスやアプリを紹介する時間を設けていただけた。自分が良いと思ったものをアウトプットして、周りの人に知ってもらう良い機会になった。
  • 学生向けハッカソンへのチューター参加した。学生は、下手に技術力のことを考えず、やりたいことベースで物事を考えるので、刺激になった。IoT流行ってるなーとしみじみと感じた。

3. プライベート

  • Photoshop,Illustratorチュートリアルをこなした。リッチなビジュアルデザインが苦手なので、勉強になった。
  • プライベートで大学の友人とアプリ開発を始めた。ただ、開発スピードが遅いのが反省点。 Sketchを使いたくて、Sketchでアプリデザインをした。Sketchは、UIデザインをするだけならとても使いやすいし、何よりエンジニアとのコミュニケーションコストが下がりそうなので、来年は業務でもつかっていきたい。
  • Swiftの勉強(Storyboardなど)もできた。来年はViewControllerあたりの勉強もガッツリしたい。
  • 初LTした。就活時にお世話になった逆求人関連のイベントにて、就活に関するLTをさせていただいた。起承転結を意識してスライドを作成したら、割とウケた。
  • Advent Calendarかいた。 来年はもうちょっと技術寄りのことを書けたらいいな。
  • 美術展にいきまくった。上京して、行きたい美術館に気軽に行けるのがとても嬉しい。今年はモネがたくさん見られたのが良かった。春画展も面白かったなー。
  • 2.5次元舞台にハマった。DEATH NOTENARUTO、ハイキュー、テニミュに行った。来年は黒バス、テニミュに行く予定...とれたら...
  • 数年ぶりに冬コミにいった。
  • キャンプ行った。
  • 美味いものめっちゃ食った。

2015年でもっとやりたかったこと

アプリ開発

  • プライベートでアプリ開発したけどリリースできなかった。プライベートの開発になかなか時間を当てなかったのが原因。
  • 業務でアプリ開発案件ができなかったので、機会があれば声をあげて、質の良い仕事がして、任せてもらえるようになりたい。

フロントエンドの知識を増やす

  • サービス開発上javascriptを書く機会があったが、プログラムを書く上で当たり前の知識が足りず、エンジニアさんにもご注意をうけることが多かった...
  • 個人的に足りないと思う知識は、
    • オブジェクト指向を理解したうえでの開発
    • javascript、ブラウザの仕様の理解(そもそもなんとなくでjsを動かしていることが多い)

インプットとアウトプット

今年は、積極的に情報収集が出来たし、学生時代と比べて環境に恵まれてるのでインプット量も多かったと思うけど、このあたりをもっとやりたかった。

  • 読書時間。積み本が多い。
  • 自分の考えを言語化して、アウトプットする。(ブログ、社内への情報シェア)
  • 特に平日はプライベートで勉強に当てる時間が少なかった。

自分の考えを適切に伝える

  • 言い訳を枕詞につけがち。ダラダラと長い話になりがち。
  • 手段を目的かのように話しがち。what,why,howを常に考えて伝える。

ポジティブな言葉を使って話す

自分に自信なくて、ネガティブになりがちなので、せめて話すことはポジティブにするべきだったなーと思う。

体力をつける

去年はジム通ってたのに、今年は運動時間が減ってしまった。 めちゃくちゃ平日頑張ると、糸がきれたかのように土日寝まくっちゃうので、体力つけないといけない... あと、単純にふとってきたので、痩せたい。

2016年の目標

以上を踏まえて、2016年やりたいこと。

  • プライベートで作ってるアプリをリリースする。
  • エンジニアさんが開発しやすいコーディングをするために、フロント、アプリViewの知識を増やす。具体的には、
    • ブラウザの勉強をする。ハイパフォーマンスブラウザネットワーキングを読む。
    • そろそろJQueryからES5,ES6の記述へ慣れる。業務で使えそうなところはjQueryを使わずに描いてみる。気になったOSSがあれば、コードリーディングをする。
  • 毎日30分自分のWeb制作の勉強にあてる。
  • 週に1回は読書時間を設ける。
  • 勉強会に参加したら、感想をブログにかく。
  • PREPで話すことを意識する。

    P=要点、結論(Point)

    R=理由、背景、根拠、効果(Reason & Reality)

    E=具体的な事例、仮説(Example)

    P=結論の再確認(Point)

  • 毎日これつかって5分運動する。

あと、定性的な目標というか、野望に近いけど、

  • ビジネス分野×デザインとか、デザイン×エンジニアリングとか、別領域に理解があるデザイナー、デザイナーという役割に縛られないデザイナーになりたいという目標がずっとあるので、そのためにアクションを起こしていきたい。具体的には、
    • 上記に上げたようなエンジニアリングへの知識をつけ、エンジニアさんがコイツとは働きやすいなと思えるようなデザイナーになる
    • サービスの現状を定量的に見て、デザインを提案できるようになる
  • ただ、上記の目標も自分の中では持ちつつ、自分が今のチームの中で、どんな仕事で貢献できるのか明確でないので、模索して明確化にする年にしたい。
  • 会社の目標達成のための案件が多かったので、ユーザに喜んでもらえるような案件をやりたい。わがままをいうと、仕事でもプライベートでもいいから、0ベースのデザインもやっていきたい!

自分で書いててなんか意識高いこといってんなーwとか、寒いなーwと思うけど、色々変わった年なので、やったことをちゃんと記録に残しときたかったのです。 2016年は今年以上に色んな挑戦できるといいなー。

2016年もよろしくお願いいたします。

Paper - 画面遷移がシームレスなスケッチ&メモアプリ

UI アプリレビュー

この記事はiPhoneアプリレビュー Advent Calendar 2015 16日目の記事です。

Paperとは?

f:id:oooNAKi:20151216231625p:plain:w300

  • 画面遷移がシームレスなメモ、スケッチアプリ
  • 以前はiPadアプリだったようですが、最近iPhoneアプリがリリースされたようです。

こういうひとにおすすめ

  • iOSアプリでお絵かきがしたいひと
  • iPhoneで撮った写真にかきこみをしたいひと
  • おしゃれなUIのメモアプリがつかいたいひと

Paperのここがすごい

基本操作が片手でだいたい済むUI

f:id:oooNAKi:20151216231938p:plain:w300

  • たくさんの紙を、グルーピングして、1枚のホワイトボードに貼っているイメージのUI
  • →シームレスに画面遷移ができるのが気持ちいい
  • スワイプで画面遷移できる
  • スワイプでTODOリストにできる

お絵かき機能がすごい

f:id:oooNAKi:20151216232022p:plain:w300

  • 筆の種類が多い(特に水彩筆がイケてる。たのしい)
  • 色を選ぶとき、混色っぽいことができる

UIがおしゃれ

  • アプリアイコンがオシャレ
  • アプリのなかも、ビジュアルが「紙」っぽくて、オシャレ
  • インタラクションまでもオシャレ
    • 削除するときのインタラクションは、「紙を捨てている感覚」

Paperのここは不便

まとめ

  • 既存メモアプリとは一味違うUIの、Paperを紹介いたしました
  • iPhoneで絵をかいたり、写真に書き込みをしたりするときに楽しそうかな、と思います

余談

Advent Calendar はじめて書いてみました!(勝手に参加させていただきましたが...w)

maxiさん(@rel0005)参加させていただき、ありがとうございましたmm