デザイナー週次勉強会でRailsとSQLを取り上げてみて分かったこと

[CrowdWorks Advent Calendar 2017](https://qiita.com/advent-calendar/2017/crowdworks) の5日目の記事です。

![udg_study-club.JPG](https://qiita-image-store.s3.amazonaws.com/0/168321/5ee30f93-1207-e3a3-7f2f-38ba11408a7e.jpeg)


こんにちは、デザイナーの田村です。
突然ですが、あなたは勉強が好きなタイプでしょうか？

自分の好きな分野なら全く苦にならなくても、苦手意識を持った分野は本を開くだけ苦痛という方もいらっしゃるかもしれませんね。

しかし、そんな専門外の分野でも、チームメンバーで集まってワイワイ勉強すれば案外楽しくなるものです！

実はわたしの所属するUXデザイングループでも、4ヶ月ほど前から「デザイナー週次勉強会」というものを開き、RailsとSQLを勉強し始めました。

どうしてデザイナー勉強会を始めたのか。また、どうやって運営すればいいのか。

今回は、そんなデザイナーの週次勉強会でRailsとSQLを取り上げてみて分かったことを書いてみたいと思います。

## デザイナー勉強会の目的

デザイナー勉強会の目的は、当然ながら「スキルアップ」につなげることです。

元々は、UXデザイングループの中長期的な展望を考えるミーティングで、「自分の専門領域（デザイン）以外のスキルアップに投資する時間も必要ではないか」という意見が出たことがきっかけでした。

クラウドワークスにおいて、デザイナーはエンジニア・マーケター・プロダクトオーナー等、様々な職種のメンバーと協働しながらデザインを進めていくことになります。

そのため、デザイナーもエンジニアリングやマーケティング、プロジェクトマネジメントといった他領域について積極的に学ぶことで、より良いデザインの提案につなげられるのではないかと考えました。

## 勉強するテーマを選ぶ

勉強会をやることが決まり、続けてデザイナー週次勉強会で取り上げるテーマを選びました。
RailsとSQLを学ぶというのは最初から決まっていたわけではなく、当初はざっくりと、以下の３つの領域の中からテーマを選ぼうとしていました。

- エンジニアリング
- データ分析
- UXデザイン

このうち「UXデザイン」については、既にチーム内でユーザーインタビュー等のUXデザイン的手法を試し始めていたこともあったため、いったん見送ることにしました。

残ったのは「エンジニアリング」と「データ分析」ですが、一口にそう言っても範囲は膨大ですよね。

そこでエンジニアリングについては、社内で開発言語として用いられている「Ruby on Rails」に触れることで、Webアプリケーションの仕組みや概要を。

データ分析については、社内でredashを用いてKPI等の計測が行われていることから、「SQL」に触れることでデータベースの基礎的な操作方法を勉強することに決めました。

## 目標を決める

テーマを選び終えたので、今度は目標を決めることにしました。

例えば「Ruby on Rails」を題材にエンジニアリングを学ぶといっても、本格的に実装できるようになることを目指すのか、とりあえず触ってみて概要の理解を目指すのかによって、勉強会の内容も大きく変わってきますよね。

今回の場合で言えば、わたしたちが目標として定めたのは後者です。

というのも、当初の目的は、デザイナーが他領域を学ぶことでより良いデザインの提案に活かせるようになることでした。

言うなれば、外国語がぺらぺらに話せるようになることではなく、その国の文化に触れることでリスペクトを深めるというイメージです。

## 必要なリソースを揃える

続けて、デザイナー週次勉強会を進めていくにあたってのリソースを揃えていきます。
ここでは、次の２つのことを準備しました。


### 教材を選ぼう

選んだテーマと目標を踏まえて、フィットしそうな教材を選びます。

今回は、おなじみの[Ruby on Rails Turtorial](https://railstutorial.jp/)と、[スッキリ分かるSQL入門](http://amzn.asia/gCiqHhG)という本を教材にすることに決めました。

当初 Ruby on Rails Turtorial を選んだ際には「いきなりそれは難しすぎるのでは？」といった声もあがりました。（正直、僕もそう思いました…）
しかし、主軸に置いていたのは、あくまでも「Webアプリケーションの仕組みを知ること」や「開発のフローを体験する」ことです。

ある程度実装できるようになることを目指すのであれば、もっと簡単な教材から徐々に始めても良いのかもしれません。

しかし「Herokuにデプロイする」「テストを書く」「Gitでバージョン管理を行う」という、実際の開発フローの体験を重視するのであれば、Ruby on Rails Turtorial は教材として合っているのではないかと考えました。

スッキリ分かるSQL入門については、SQLを学ぶにあたり環境構築が必要ない（あらかじめ用意されたWebサービス上でSQLを実行して体験できる）ことや、事例や練習問題が豊富ということから選んでみました。
 
### 先生役を見つけよう

デザイナー週次勉強会を進めていくにあたり、先生役をしてくれるメンバーがいると非常に捗ります。

上記で選んだ教材は、いちおう個人で進めることができるものです。

しかし、つまづいた時に教えてくれるような先生役がいることで、効率よく勉強を進めることができますし、参加しているメンバー同士の目線も合わせやすくなるのです。

クラウドワークスには教えるのが上手な方がたくさんいらっしゃるので、今回の場合も同僚のエンジニアに先生役をお願いしました。

ちなみに、12月から新しく先生役をしてくれることになった@kinakoboさんも、ちょうど昨日Advent Calender に記事を投稿されていますのでぜひ :tada:

[はじめてドメイン駆動設計をしてみて感じたこと](https://qiita.com/kinakobo/items/616c9b9e4537f9cc9aa8)

## デザイナー週次勉強会を開いてみる

以上を踏まえて、実際にデザイナー週次勉強会を開いてみました。
実際にやってみると、良かったこともありましたが、反省点も分かり得るものが大きかったです。

### 良かったこと

当初の目論見通り、基本的な仕組みの理解や概念モデルの構築という目標には、かなり近づくことができたように思えます。

例えば、Ruby on Railsの方では、「Hello World!」としか表示されないWebアプリケーションであっても、実際にHerokuにデプロイするところまで進めてみると、以前よりはかなり理解が進んだように思います。

SQLでも、データベースの仕組みや構造のイメージを掴むことができ、少しずつですが実務にも活かせるようになるための筋道が見え始めました。

### 反省点

週に一度のペースで開いているのですが、当初は「Ruby on Rails」と「SQL」の回を交互に開催していました。
しかし、この進め方は見事に失敗しました。

前回どこまで勉強したのかを忘れてしまうことと、どちらも計画通りにカリキュラムが進むわけではないので、結果的には両方とも中途半端になってしまうのです。

この失敗を受けて、途中からはまずSQLの教材を消化することに集中した結果、記憶を持続させつつ良いペースで進められるようになりました。

## おわりに

今回はデザイナー週次勉強会の、主に運営方法についてご紹介しました。

実際にデザイナーで集まって勉強してみると、「これはデザインでいうと、こういうことなのかな？」と身近な例で置き換えることで全員の理解が促進されたり、メリットの多さを実感できたように思います。

今回の記事が、もし「うちのデザインチームでも勉強会をやってみたいんだけど、どうすればいいのか分からない」という方にとって少しでもお役に立てれば幸いです。

それでは、引き続き[CrowdWorks Advent Calendar 2017](https://qiita.com/advent-calendar/2017/crowdworks) をよろしくお願いします！