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

デザインの気づき ~フロントエンドエンジニア育成の取り組み を通して~

エンジニアのS.Uです。 現在フロントエンドエンジニア育成の取り組みを行っております。
取り組みがスタートして早1週間。その中で実践したことや学びについて書きたいと思います。

自己紹介

これまでは、主にバックエンドの開発を行ってきました。
先月よりフロントエンドの開発チーム(UXを検討するチーム)に配属になり、フロントエンジニアとして晴れてスタートを切りました。
UXチームはデザインの工程からマークアップの工程までを担う部隊で、日々UXのあるべき姿を追い求めて奮闘中しています。

目的 ~What is the goal?~

今回の取り組みでは、以下を達成することを目的としています。

  • デザイン~アプリ開発 までの工程を理解する
  • フロントエンジニアに必要なツールや言語の使用方法を理解する
  • エンジニア間のコミュニケーションを活性化する
  • つまづきやノウハウをアウトプットしてナレッジを蓄積する

取り組みの内容

現在フロントエンドエンジニア育成の取り組みの中で、フロントエンジニアの基礎の習得(1)の マークアップ実践に取り組んでいます。

このフェーズでは、レスポンシブデザイン*1に対応したマークアップコーディングを習得すべく、 カンプデザイン*2を基としたマークアップを実践しています。
UXチームに所属していることから、私はこの取り組みの前準備としてカンプデザインの作成を担当しました。

今回はこのカンプデザイン作成の中で得た学びを書いていきたいと思います。

カンプデザインの作成 ~初めての「カンプデザイン」と「イラレ」~

はじめに

レスポンシブデザインに対応した画面イメージを作成するために、複数画面サイズ用にレイアウトを作成することにしました。

そもそもデバイスの種類、サイズってどのくらいあるの?というところからスタート。 この辺のサイトをみると、主要なデバイスの画面サイズが載っています。 【CSS】適切なブレイクポイントを考えてみる(レスポンシブデザイン用)

ひとまず標準的な3種類のデバイスを選定。以下3つのカンプデザインを作成することにしました。

  • PCサイズ
  • タブレットサイズ
  • スマートフォンサイズ

カンプデザイン作成にあたり使ったツールは、Adobe Illustrator(通称イラレ)です。 カンプデザインもさながらイラレも初挑戦です。
メニューが豊富すぎて使いこなせるかやや不安を抱えつつ、レッツトライ。

実践

各サイズ5つのコンテンツを配置する簡単なレイアウトをイメージし、早速カンプデザインを作成。 この程度なら簡単、、とサクっと作成して余裕をかましていた私に落とし穴が。

作成後にUXの師匠にチェックをお願いすると、 出るわ出るわ指摘のオンパレードでした。

私のカンプデザインは何がだめだったのか。 今思えば甘さ満載の出来栄えですが、恥をしのんで公開。

作成したカンプデザイン

f:id:satomi_uetake:20170303141109p:plain ※左からPCサイズタブレットサイズスマートフォンサイズ

これに対する指摘事項

  1. 各サイズ間のコンテンツのサイズにルールがない
    コンテンツ1はヘッダー、コンテンツ2はメニューバーを想定したコンテンツだが、画面のサイズ間で幅が異なる。固定サイズであるべき。 可変サイズであれば、画面の縮尺に合わせる等、サイズに明確なルールが必要。
  2. 色に意味がない
    色が設計されていない。どんなイメージのデザインにしたいのかが明確でない。 また、使用している色の設定値にルールがない。 通常カラーパレットを作成する場合、明度、彩度を変えずに色見だけを変える手法をとる。
  3. コンテンツ間の線幅が考慮されていない
    コンテンツに枠線が1pxで設定されているが、その線が重なっているケース(コンテンツ間が1px開く)と重複していないもの(コンテンツ間が2px開く)が混在している。
  4. 拡大するとコンテンツ間に隙間が…👈論外

こんな簡単なイメージのカンプデザインを作成しただけでも、こんなにもダメポイントがあるなんて・・・
自分の知見のなさになかなかショッキングでしたが、同時にデザインの奥深さを思い知りました。

原因と考察

1、2の指摘については、コンテンツのサイズや色を「設計してしなかった」事が原因でした。 「なんとなく収まりがいいサイズ、パッと見でいい感じの配色」 私はこんな曖昧な基準でカンプデザインを作成していました。

3、4の指摘については、イラレの機能を使えば解消できる問題でした。

イラレには、オブジェクトの整列という機能があります。
↓このようなメニュー。

f:id:satomi_uetake:20170303142432p:plain
キーとなるオブジェクトを基にオブジェクトを整列させたり、 整列時にオブジェクトの間隔をピクセル単位で指定することができます。 この機能を正しく使っていれば、コンテンツ間の間隔の不揃いや、不要な隙間は発生しませんでした。

具体的には、こんな感じです。


整列前

f:id:satomi_uetake:20170303212432p:plain


整列後(オブジェクトの整列)

複数選択したオブジェクトを、指定した辺(または中央線)を基準に揃える。(以下は中央揃えにした例。)
f:id:satomi_uetake:20170303212437p:plain


整列後(オブジェクトの分布)

複数選択したオブジェクトを、指定した辺(または中央)を基準に均等に分布させる。(以下は左揃えにした例。)
f:id:satomi_uetake:20170303212441p:plain


整列後(等間隔に分布)

複数選択したオブジェクトの中で、キーとなるオブジェクトを1つ選択し、そのオブジェクトを基準に分布させる。
オブジェクト間の間隔が指定可。(以下は縦に均等分布した例。)

  • キーオブジェクトを選択。
    f:id:satomi_uetake:20170303212445p:plain

  • 間隔を10pxに指定。
    f:id:satomi_uetake:20170303212450p:plain

  • 整列。
    f:id:satomi_uetake:20170303212455p:plain


ここで学んだこと

デザインは設計されるものである

デザインのあらゆる要素にはルールと意味があり、アプリケーションと同様それらは完璧に設計されているもの。
なぜボタンはこのサイズにしたのか?なぜ文字をこの色にしたのか?
何となくきれいに見えるから。といった曖昧な基準で設定してはいけない。
なぜこのデザインになっているのかを、明確な基準を提示して他者にも説明できるように、設計することが大事。

カンプデザインはマークアップの基礎資料となる

カンプデザインはデザインを披露するだけの資料ではない。
マークアップをする際に、カンプデザインを基にオブジェクトのサイズや色を設定することもある。
今回利用したイラレのツールにも、デザインしたオブジェクトのCSSプロパティ(色やサイズ、フォント等)が 出力できる機能がある。
カンプデザインで作成したオブジェクトがそのままマークアップの工程にも影響することを理解する。

どう見せたいかを考える

デザインを通してどのようなコンテンツを作成したいか、コンテンツの利用者はだれか、 この点を意識してデザインは行われるべきである。
今回のカンプデザインは、マークアップの取り組みを行うメンバーにレスポンシブデザインの画面イメージを伝える事を目的として意識すべき点。

まとめ

取り組み前の自分

  • センスのいい人だけが芸術的な感性によって作り上げているもの。
  • デザインはかっこいいが正義。おしゃれなデザインやカラーのサイトこそがUXの極みだと信じて止まない。
  • フロントサイドって要はCSSとHTMLでしょ?

 ・
 ・
 ・
 ↓

取り組み後の自分

  • デザインは設計が大事。何より設計。見た目のセンスではなく、緻密な計算によって作り上げられているもの。
  • フロントエンジニアにとって、デザインとマークアップは切り離せないもの。マークアップを意識したデザインをする。
  • 線やオブジェクトの配置、色使いすべてに意味がある。
  • ユースケースを作成することが大切。見た目は付加価値を高めるもの。

引き続き取り組みたい事

今回の取り組みで、マテリアルデザインガイドラインなるものがあることを知りました。
ここには、デザインのあらゆる要素の標準を定義してあります。 何が標準とされているのか、その基準にはどういった意味があるのかを知り、UX設計に反映させていきたいです。

現在この取り組みはフェーズ1も終盤。次はいよいよフェーズ2が始まります。

続報は乞うご期待!

*1:ユーザーのデバイス(パソコン、タブレット、モバイル..)毎の画面サイズに対応して表示を変えることができるデザイン手法

*2:制作物の仕上がりを提示するための完成見本

フロントエンドエンジニア育成(序章)

はじめまして、弥生の田中です。

筆者の紹介

私はプロジェクトリーダーという肩書で、 弥生のお客さまが アプリケーション・サービスを満足に利用していただくために必要なUI/UXデザインを実践し、 各プロダクトチームとコラボレーションするチームを率いています。

このチームは、今期初めて弥生内に創設されました。

私の主な責務は アプリケーションのUI/UX周りのデザイン・評価を中心とし フロントエンドの技術トレンドの判断や導入といったエリアも担当します。

こんな私からは、UI/UXやフロントエンドエンジニア周りの情報を中心に発信していきます。

どうか、温かい目でご覧いただければ幸いです!


はじめに

最初の投稿は、先週から始まった弥生の取り組みをご紹介いたします。

次投稿以降は、実際のエンジニアからの発信を交えて投稿していきます。

どうぞ、お楽しみに・ω・

なぜ今更フロントエンジニアを育成することになったのか??

近年、弥生では、クラウドサービスの新規展開、需要も増えており フロントエンドエンジニアの不足と、社内でのスキルナレッジの不足が目下の課題です。

事実、弥生への採用においても、WindowsC++C# といった、Windowsクライアントのエンジニア像が強く、フロントエンドな方々と接点が薄い状況 orz

提供するアプリケーションやサービスが増えてくると、 それぞれのシステムで独自拡張が始まり、システム間でデザインや使い勝手のズレが生まれます。

こういった状況を打開するために、UX検討チームは何ができるか。

ただでさえ破綻しやすい、フロントエンドをどのように立て直すことができるか。

そんなミッションを背負っています。

まさに!

この問題こそが、本記事を投稿するきっかけとなった、 フロントエンドエンジニア育成というミッションです。

何から始めようか?

この大きなミッションを前に超えなければならないのが、 前項でも記載した、 フロントエンドエンジニアの不足と、スキルナレッジの不足です。

デスクトップアプリケーションでは、長い歴史を経て積み重ねたスキルがあるものの、 Webのフロントエンドは、まだまだ乏しいのが実情です。

このため、UX検討チームがまず着手したのは、各プロダクトで働くエンジニアのスキルの底上げです。

こういった施策は、社内外の勉強会という形で立ち上がるものの、なかなか継続できないジレンマを抱えていました。

この悪い流れを今年こそ払拭せねばと意気込み、 フロントエンジニアの育成プランについて実行の承認を得ました。

筆者の目指したいエンジニア像

ユーザー体験を満足させられるようなプロダクトを考え実装できるエンジニア

想像に容易く、文章では一言、中はとーってもディープ(苦笑)

こんな人物像をブレイクダウンすると

  • ユーザー目線での品質確保の手法を知っていること
  • UI/UXデザインの実践
  • コーディングやサーバーサイドなどのスキルは必須
  • モノ作りやプロダクトへの情熱を育む(←ここが一番大切

・・・・

道のりは果てしなくぼんやりとしていたので、 スモールスタートとし、チームの若手を中心とした有志で始めました。

集まった有志は、私を除いて5名。

本プロジェクトのメンバー紹介

今後記事を投稿してくれるメンバーになるので、かんたんにご紹介します。

  • Y.Kさん
デスクトップアプリケーションのベテランエンジニア。私と同じく中途の同期入社!

前期よりフロントエンド開発に従事するものの、
不慣れな開発に不安があり、「スキルアップしたい」との思いから
プロジェクトへの参加を志願!

エンジニアのお手本として、メンバーに刺激を与えてくれることを期待しています。
  • K.Kさん
本プロジェクトで唯一、弥生内でフロントエンド開発の経歴を積んだ中堅エンジニア。
私と一緒に本プロジェクトを牽引するために、日々施策を検討してくれています。

フロントエンド周りの問題発生時に頼りにしたい!と、

プロジェクトメンバーからの熱い期待が寄せられています。
  • S.Fさん
新入社員として入社。
デスクトップアプリケーションの自動テストエンジン作成などの経歴を経て、
上記二人と同じく、フロントエンド開発に初めて携わることに。
自宅でのスキルアップの進捗が芳しくなく、どうせなら一緒に!と、めでたく合流することに。
  • S.Uさん
  • M.Fさん
弥生に今期入社したばかりの中途で、今期初めてフロントエンドに携わる若手エンジニア。
休日もスキルアップに励んでいるのを知っていたので、
どうせなら!と、本プロジェクトにお声がけ。迷うことなく合流してくれました。

見ておわかりいただけたように、 フロントエンド開発の経験が浅いメンバーで構成されています。

このため、まずはフロントエンドの構築に必要なスキルから始めてみよう!

ということで、下記の感じで3週間頑張っていきます。(がんばろー!)


ステップ

フロントエンジニアの基礎の習得(1)←いまここ

<目的>
マークアップスキルの習得(HTML5,CSS3)/グリッドシステム(FlexBox,Bootstrap等)
<内容>
与えられたデザインカンプに沿ってマークアップを実践

フロントエンジニアの基礎の習得(2)

<目的>
習得したマークアップスキルの活用
<内容>
(1)で習得したスキルを活かし、WEBサイトで定番のパンくずやサイドメニューをマークアップする

実際にどんなことやっているのか?

この活動は、以下の制約の元に活動しています

ダラダラやらない

  • 業務の定時後に1時間30分程度
  • 課題の提出期限を設ける

ペアプロ推奨

  • 2人1組で課題をこなすことで生産性をあげる

社外へ発信する

  • GitHubで公開しています

先週から今週にかけては、①を実施しています。

今週は、下記のように画面解像度によって異なるサイズのコンテンツを グリッドシステムを利用して構築するといったマークアップを実践しています。 f:id:miketanaka0430:20170228165425p:plain

投稿準備が追いついてませんが、 このパイロットプロジェクトで得たナレッジをどこかで共有できればと思います。

それでは次回更新をお楽しみにお待ちください!

筆者プロフィール

f:id:miketanaka0430:20170228182550j:plain 弥生株式会社 田中良文 弥生がクラウドに本腰を入れた2009年の変革期に入社。 近年は弥生のアプリケーションのUI/UXデザイン実務・評価を担当。 今期のスローガンは弥生のお客さまが利用するフロントをモダンに、エンジニアの環境もモダンに! 写真歴6年生。都内や近場の散策、最近は工場夜景に夢中♪写真活動中に得たAdobe製品を使ったDTPスキルを実際の業務でもフル活用。 デザイン戦略を確証するために、デザイン関連の本を読み漁るのが最近の日課。 Twitterなどで紹介していきます。(まだ始めたばかりです)

IT系勉強会を開催する前に知っておきたいこと(2)~Rで分析してみよう~

こんにちは、iotasです。

前回に引き続き、RでIT系勉強会の分析をしていきたいと思います。

前回は「IT系勉強会がどの辺で多く開催されているのか」という観点から見てみましたが、今回は視点を変えて「IT系企業がどの辺に分布しているか」という観点で見てみたいと思います。

データ集め

前回のコードを流用すれば、地図上に密度を描画できることがわかっていますので、データ集めさえすれば大丈夫です。

私はiタウンページから、ひたすらネット企業を抽出して手で補正するという単純作業を繰り返しましたが、クローラーの知識があれば、プログラムを書いて機械的にやった方がよいと思います。

私自身、なぜこの部分を手でやろうと思ってしまったのか、今となってはわかりません。

とにかく、単純作業をひたすら繰り返した結果、2,000件程度のデータが集まりました。エンジニアとしての魂は失った代わりに、なにがしかの徳は積めたような気がします。

データの補正

住所から経度・緯度を取り出すには、前回のようにGoogle Maps Geocoding APIを使います。
今回は件数が多かったので、区ごとにデータをマージして、区役所の所在地にまとめてプロットすることにしました。

プロットする

前回とほぼ同じコードを使います。
一応掲載します。

library(ggplot2)
library(ggmap)
library(scales)


# プロット用のCSVのパスを記載します
internet_company_landscape  <- read.csv("it_com_location.csv",
                                        fileEncoding="shift-jis")


# get map area
loc=c(min(internet_company_landscape$lng), min(internet_company_landscape$lat), max(internet_company_landscape$lng),
      max(internet_company_landscape$lat))

# get map data from google
Map = ggmap(get_map(location=loc, zoom=12,
                    source="google"))+xlab("")+ylab("")

internet_company_p <- Map +
  stat_density2d(data=internet_company_landscape, aes(fill=..level..,x=lng, y=lat, alpha=0.1), geom="polygon") +
  scale_fill_continuous(low = "green", high = "red")  +
  geom_point(data=internet_company_landscape, aes(x=lng, y=lat), color = "black")+
  scale_alpha_continuous(guide="none",range=c(0,.2))


internet_company_p

結果はこうなりました。

f:id:iotas:20160830085405p:plain

比較する

前回作成したIT系勉強会の分布と比較してみます。
f:id:iotas:20160901084000p:plain

こうしてみると、「渋谷は、IT系勉強会の数ほどにはIT企業の数がなく」、「港区は、IT系勉強会は少ない一方でIT系企業は多い」ということが見えてきます。
渋谷と比べて、IT系企業の数で遜色のない港区・千代田区といった地域でも、集客は見込めそうです。
特に、六本木・品川(駅)・新橋といった港区の企業に勤めている方が、会社帰りに立ち寄ってくれるような勉強会を開催すれば集客が期待できそう。
(分散メッセージングシステムみたいな大規模ユーザー向けシステムの話題とか?)

終わりに

今回は「集客」という観点からIT系勉強会をみてみましたが、実際に「集客」「集客」と血眼になって分析するようなケースは多くないかもしれません。
(個人的な趣味でやるような勉強会では特に)

ただ、IT系勉強会を開催する前に、「どのような人が来そうなのか」「どんな話題を出せば楽しんでもらえるのか」といった観点で考えてみるのは、自分たちの不安を解消する意味でも有益です。

もし、「勉強会を主催しようかな」と考えているのであれば、遊びがてらにでも分析してみてはいかがでしょうか。