こんにちは。スマートキャンプデザイナーの髙松です。
私は今年の1月からスマートキャンプにデザイナーとして入社したのですが、プロダクト部門のエンジニアチームに所属しています。
弊社にはデザイン部署がないというのも理由の1つですが、私の業務の半分は開発が必要となることが主な理由です。
しかし、入社した当時、実務での私の開発経験は0に等しい状態でした。
この記事では、開発経験0から出発したデザイナーが、エンジニアチームにいた半年で身についたことや、やりきれなかったことなどを書いていこうと思います。
似たような境遇にある方の参考になれば幸いです。
いろいろと0地点からの出発
いきなりの告白ですが、私は「未経験枠」のデザイナーとしてスマートキャンプに入社しました。
前職では最後の3ヶ月ほどデザイン業務に携わっていたのですが自分がメインの仕事としたかったWebデザインに携われるチャンスが少なく、転職活動を始めたことがスマートキャンプと出会えたきっかけになっています。つまり、開発どころかデザイン経験もかなり浅いところからの出発でした。
入社前にいくつかのサービスを使って学んでみたあとの自分のスキルは以下のような状態でした。
デザイン経験
- 実務
- 資料デザイン
- 紙面デザイン / リーフレット / パンフレットなどの社の販促物のデザイン
- バナー制作 数本
- LPデザイン 1本
- 他
- 簡単なサイトのデザインとコーディング作業
- Daily UIなどで個人演習したもの
- 使用可能なツール
- Photoshop / Illustrator / XD の基本的な操作
- 実務
開発まわりの経験
エンジニアの方はお気づきと思いますが「開発」と言っておきながら、プログラミングは一切できない状態です。（現状もできるわけではありません...。）
昨今、Webデザイナーとエンジニアの境目に立つ人材が多いと言われていますが、そんなハイパー人材などではなくコーディングをかじり出した初心者デザイナーというかんじでした。
自分の理想とギャップ
このような状態だったので、身に付けなければならないことは山のようにあります。入社後、数週間が経過したタイミングで自分の理想とギャップを整理してみました。
自分の理想
入社当時から、私の理想は数値に貢献できるデザイナーになることです。
デザインの成果というものは全てを数値に置き換えられるわけではありませんが、それでも数値は1つの結果だと思っています。デザイナー本人だけでなく、関係部署を含めた全員がシンプルに喜ぶことのできるフィードバックです。
私にとってWebデザインが魅力的と思える最も大きな理由の1つはトラッキングができることにあります。
つまり、デザインの数値的なフィードバックが得られる点です。
自社プロダクトを持つ会社にいれば、数値を足がかりに早いサイクルでデザイン改善する経験ができるはずと考えたことも、スマートキャンプに入社を決めた理由の1つになっています。ちなみに入社後に携わったデザイン改善施策は以下のようなものがありました。
例
- レイアウト変更による会員登録フォームのCVR改善
- ポップアップ実装やレイアウト変更によるリスティングLPの流入改善
- メディア記事内に設置されているボタンのCTR改善
理想と現実のギャップ
理想を掲げたのは良いのですが、数値を足がかりにデザインを運用するためには足りないスキルが多くあったため、必要なプロセスをざっくりと書き出してみました。
プロセスだけを見ればシンプルですが、これらを実際に自分の手で行えるようになるには学習時間と反復機会が必要になります。
できるようになったことは後ほどまとめますが、苦しめられたポイントについて先に書き出してみます。
初めて見るRuby on Rails
スマートキャンプが運営しているボクシルSaaSはRuby on Railsで実装されています。初めてプロダクトを裏側から見た日にしたことは、自分がさわりたいHTMLとCSSに該当するファイルを探し当てることでした。
Railsではファイル名を利用して呼び出すファイルと読み込むファイルの関係が成り立つなどアプリケーション上のルールがあります。慣れ親しんだエンジニアには便利なものが初見の者には理解できないブラックボックスになってしまい、自分がデザインしたものを自力で実装する日は本当にくるのか、不安になったことを覚えています。
現在は見るべきファイルを絞ってエンジニアに教えてもらうことで、自分の業務に必要な部分を徐々に勉強することができるようになりました。
デザイン / 開発環境が変化している
例えば、制作から分析までのプロセスを自分が慣れ親しんだツールのみで完結することができれば、追加で学習しなければいけないことは最小限に抑えられます。
一方で、制作ツールなども転職をきっかけに変更する必要があった場合、1つのプロセスを完了させるにはツールに慣れるところから始める必要がありました。
私の場合の、過去と現在の作業環境の変化を比較するとこのようになります。
| 過去 | 現在 | |
|---|---|---|
| デザイン | Adobe | Figma+Adobe |
| コーディング | HTML / CSS | Slim / Sass |
| テスト実装 | Google Optimize | Split※ |
| 分析 | ローデータからExcelで成形 | クエリを書いてredashから取り出す |
※Split ... Ruby on Rails上で動かせるABテストツール
学習計画を立てるときは内容に目が行きがちですが、こういった環境の変化なども加味して計画を立てるべきだったと今にして思います。
なにがわからないのか、わからない状態
「開発をする」という全く土地勘のない領域では、今自分がなににつまづいているのかを把握することが難しいです。自分が辿るべき道を見つけて、プロセスを組み立てられるようになるために、初めは人の頭を借りる必要がありました。
このときに、下手にプロセスを組み立てていくよりも「自分がなにをやろうとしているのか」を明確にして早い段階で人にヒントをもらうことも大事だと学びました。
もちろん自分で立てた仮説も無駄にはならないので、自分の頭で簡単にプランAを組み立て、本業のエンジニアにプランBを立ててもらうと、足りなかった考えや自分がもてるスキルで代替可能なプロセスなどを照らし合わせることができます。
やったこと
こういった予定外の事態や気づきを得ながら、半年間エンジニアチームのデザイナーとして制作/実施したものを列挙してみます。
- コーディングを含めたLPの制作
- Railsアプリケーションで動くプロダクトに、動的に内容が変わるページを新設する
- 検証するデザインの制作〜実装
- Rails上で動くABテストツール（Split）を使った、テストの設定
- Figma やSTUDIO など、新しいツールを使ったデザイン/ 開発
これらの制作は、ただ作ればですごいわけではなくクオリティを上げていく必要もあるので、まだまだ良い品質のものが作れるようになったとは言えません。
また、各場面で必要となるプログラムやクエリなどはエンジニアに書いてもらうなど、自分にできないと明確にわかるものは切り出して、協力を仰いで制作しています。
半年で得た学び
未だに大きい仕事を1人で完遂することは難しいですが、前章の「できるようになったこと」は半年前の自分には確実にできなかったことです。
しかし、一方で「これの体得は無理だ...。もう少し成長してからの目標にしよう...。」となったものもあります。
このような判断も含めて半年間で「やってよかったこと」と「改善点」を4つほど挙げてみます。自分と似た境遇の人の一助になれば嬉しいなと思います。
やってよかったこと
エンジニアに学習内容の相談にのってもらう
なりたい理想像が決まった後、身につけるべきスキルをリストアップして何人かのエンジニアに見てもらいました。今では恥ずかしい限りですが「Railsを理解して書けるようになる」といった大きすぎる目標もそこには含まれていました。
見上げている山が大きすぎて頂上が見えず、高すぎる目標を書いていたと思います。
1人のエンジニアにはっきりと「短期目標に掲げるのは無理だと思う。それはなぜか。」を説明してもらい、自分がやりたいことの難易度と工数を一緒に見積もってもらいました。
さらに、業務での活用頻度も合わせて優先順位の整理をしてもらい、自分がはじめに何をできるようになるべきか、整理することができました。
ペアプロをしてもらう
サイトTOPのような繰り返しの要素が多いページを実装するとき、その処理を行うコードをエンジニアに書いてもらったことがあります。そのときに初めてペアプロをしてもらったのですが、どのような仕組みで処理を行うか説明を聞きながら書いてもらうと、格段に理解が深まります。
説明をしてもらう過程で「よくわかってなかったけど、あそこのコードはこういう意味だったのか...！」など副産物を多く得ることもできます。個人でも、本やカリキュラムを通じて体系的な勉強をすることはできるかもしれませんが、実務で出てくるコードの理解には人の説明を受けることが、開発場面においても重要なんだな...（小並）と感じました。
デザイナーがそこまでコードを理解をしておく必要があるのか賛否はあると思いますが、開発をしないデザイナーにとってもコードを理解しておくことにはメリットがあると思います。
デザイナーは最後まで修正をしたい生き物です。開発が完了したあとに「修正したいけどコードがもはや暗号」という状態を回避したい箇所は、ペアプロで一緒に作ってもらうことで事前に理解を深めておくと、いざという時にササッと直せたりします。
改善点
きっかけを得てから勉強する
できないことが複数把握できている場合、同時平行で学習を進めようとしたり、新しい技術の使用場面がくる前に勉強をしておきたいという気が働いていたのですが、これは結果的に効率が悪い方法になってしまいました。
個人的に、技術を身に着けるにはインプットする学習時間と反復練習が重要だと考えているのですが、実務での反復練習ができないインプットは次のインプットに押しやられて抜け落ちてしまいます。
必要以上に先回りをしようとしたり、網羅的な理解を優先しようとせず、学習の必要が生まれた場面で必要なことだけをインプットし、反復の機会を業務中に持つことが一番効率の良いやり方だったように思います。
業務時間外の学習時間を当てにしすぎない
学習計画を立てていた頃は、業務時間外や休日に勉強をしよう！と考えていたのですが、期限のないまま努力を続けることは自分には不向きでした。
「できないこと」という大きい山を切り崩すには「長期的に少しずつ学習を継続する」か「短期間で一気に1つを学習しきる」などのペース配分を意識すべきだったなと思います。
日々の業務中でも「できないこと / わからないこと」に対峙している中で、業務後や休日も同じことを繰り返しているとやる気と効率が低下してしまいます。
次の半年は、プライベートな時間を当てにするのではなく、業務時間を通じていかに効率良くインプットして反復する時間を持てるか、を考えるようにシフトしようと思います。
周囲に助けられた半年間
長々と書いてしまいましたが、半年間デザインと開発業務に関わっていく中で多くのことを経験させてもらいました。その中での発見や反省が、記事を読んでくれた方のお役に少しでも立っていれば幸いです。
開発未経験かつデザイナーである自分が、開発チームの1人として多くの業務に携われているのは、エンジニアをはじめとする周りの協力的な社員のおかげでもあります。社員同士の連携や、どんな質問も受け入れてくれると思える環境があってこそ、実務を通しての学習というのは成り立つものだとわかった半年でした。
この記事を読んでくださった方が少しでもスマートキャンプに興味を持ってくだされば嬉しいです！
スマートキャンプ株式会社にはデザインブログもありますので、ぜひそちらもチェックしてください！↓↓↓↓↓ note.mu
