これは何
「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア」カレンダー8日目の記事です！
エンジニアと一緒に仕事をすることが多いため、少しでも話が通じるようになろう……と思って勉強をしてきました。
私自身がコードをしっかり理解できるのは難しいにせよ、リテラシーとしては身につけておかねばといった気持ちです。
現状だと「デザイナー相手にこういう話が通じると助かるよ」とは言ってもらえる程度で、他の人の参考になればと思い記事を投稿します。
対象読者
- 「デザイナーのリテラシーがもう少し高かったら助かるなあ」と思っているエンジニア
- この記事をデザイナーに紹介してもらえれば何かのきっかけになるかもしれません
- エンジニアと話したいデザイナー
- この記事の内容を真似れば多少は理解が深まると思います
- ただし効率の良い順番かというと怪しいのでそこはご了承ください
要は、この記事に書いてある内容をデザイナーが実践すればある程度は話せるようになると思っています。
特別なことはしていないのでそれなりに再現性はあるはずです。
やったこと
時系列で記載していきます。
ちなみに、どのフェーズであっても周りの人へ色々と質問していました。
自分だけでやっていては何も分からなかったでしょうから、当時教えてくれた方達には感謝しています。
何か恩返しをしたいですが、彼ら彼女らへ返せるものも浮かばず……それなら次の世代へ少しでも役に立てればと思ったのもこの記事を書き始めた理由の1つです。
HTML, CSSを写経する
私は大学の授業で初めてWebデザインに触れました。
最初の方の授業はほぼ教材のコピペです笑
当時は何の罪悪感もなくコピペや目で見て真似るだけでコードを書いていましたが、それくらい割り切っていたおかげで挫折せずに済んだのかもしれません。
「divってめっちゃよく使うんだなあ」くらいの非常に低い意識でコードを書いていました。
HTMLやCSS自体がエンジニアリングのリテラシーを上げるかというと微妙ですが「たくさんの英語で書かれたコードを目の前にして逃げない」練習にはなると思います。 多分最初のうちは逃げ出したい気持ちが起きるでしょうが、コピペでもなんでも「コードを書いたら画面に何かが表示される」ことの体験を積むのが大事なのではないでしょうか。
HTML, CSSを調べて自分で書く
写経で教材通りのものが組めると、今度はオリジナリティーを出したくなり始めました。
背景色を変えたいとか2列じゃなくて3列が良いとか……そういうのをとりあえず調べて新しいコードの書き方を知って……そしてまたコピペです。
検索して出てきたものを片っ端からコピペして一番想像に近い結果になったコードを採用する、行き当たりばったりとしか言えません笑。
とは言え何度もコピペしているとさすがに覚えてきて「はいはい、またfloat: left;でしょ？」くらいにはなっていたような？1
ちなみに当時授業ではAdobe Dreamweaverを使っていましたが、サジェストの機能をよく分かっておらず「文字打ってる最中に何か横に出てくるなあ」くらいに認識していた気がします。
そのため「補完を上手くつかって仕上げていく」ような進め方は全く知らず、全部手で書いていました。馬鹿ですね。
ちなみにCSSの設計なんてもちろん知らないので全てを愚直に書いていて、5-6ページのサイトなのに2,000行くらいCSSを書いた記憶があります。
正解のコードをすぐに探し当てる嗅覚はいずれ身につけたいものですが、最初の時期は別にそんなに要らないと思います。 コピペであってもたくさん試行しているうちに少しずつ雰囲気を掴めるようになると思うので、そういう経験ができれば良いというスタンスです。
WordPressで出来合いのテーマをカスタムする
大学の授業がもう少し進んで、WordPressを使うことになりました。
しかしもちろん1からサイトを作るようなことはなく、無料で使えるテーマを少し改変する程度。
動的に変わる要素に面食らいましたが「ここは触ると壊れるからやめとこ笑」と割り切って、静的なパーツのスタイルだけ自分好みにカスタムして課題を終えたと思います。
WordPressともなるとググった結果の件数がとても多くて何から手をつけたら良いか分かりませんでしたが、またしても片っ端からコピペして上手くいったものを採用していました。
ときおり全く意味不明なエラーが出てしまって驚きましたが「最悪またデフォルトのテーマに戻せば動く」くらいでトライアンドエラーを続けていたと思います。
私は非常に面倒くさがりなので、手書きのHTMLからWordPressに移った段階で「今までコピペでコンテンツを増やしていたのが、1行書くだけで全部のコンテンツが表示される！」みたいに興奮していました。 1度静的なHTML, CSSだけでサイトを組んで、ひたすらコピペでコンテンツを増やしていく作業を経ると、エンジニアリングの良さを肌で感じてもらえるかもしれません。
設計の大切さを知る
今の会社に内定をもらって、研修期間中のことでした。
「自己紹介サイトを作る」という課題だったのですが、先ほどの章で書いていたように以下のような有様だったんですね。
- 全ての要素に1からスタイルを書いている
- クラス名が
item1,item2みたいなものばかり
メンターから、それはもうたくさんのレビューをいただきました笑
そこで初めてCSS設計という概念に触れたり、クラス名1つとっても大事と教わったり、新しい発見が多かったです。
とは言え学びはじめの時期からそんなこと言われてもパンクしていたと思うので、ある程度書けるようになってきたこの時期に教われたのは非常に良いタイミングだったのかもしれません。
ちなみに当時勧めてもらって、今でも良いなと思っている本がこちらです。
発行年は若干古いものの、押さえるべき場所がよくまとまっている良い本だと思います。
実務で「1つも分からん」状態になる
そして社会人になりました。
この時期に初めてGitを使い始めます。
そう、これまでの開発では自分ひとりで作っていたのもあって何もバージョン管理なんかしていません。
ターミナルを操作するってだけで大変なのに2、Gitの概念が1つも分からなくてかなり面くらいました。
「commitとcheckoutって何が違うんですか？」くらいのちんぷんかんぷん具合です。
最初のうちは割り切って機械的に決まった順番でコマンドを叩くこと以外しませんでした。
「addしてcommitしてpush、addしてcommitしてpush……。」と思考を停止してとにかくフローに慣れるというか。
ただそれでも決まったコマンドしか叩いていないつもりなのに何かしらを間違えてエラーを引き起こすことも多々ありました。
もう毎回エンジニアに泣きついていましたよね。
けど頑張って何回もやっているうちに「このエラーメッセージ、前も見たな……たしか……」と解消できることが増えていきました。
addし忘れてcommitしようとしてるからエラーになってるとか、本当その程度だったんですが、いくらか自分でできるようになったらとても嬉しかったです笑
遅かれ早かれターミナル操作はすると思うので、早いうちに少しでも慣れておくのは良いのかもしれません。 自分の場合Git操作はターミナルでしかできないものだと思い込んでいたので「やるしかない……！」と謎に追い込まれて頑張れました。 けど、これくらいの時期にvimとかを教えだすともう訳分からんことになる気がするので勧めません笑
それと、Railsもこの頃に初めて触りました。
これもまたちんぷんかんぷんでして……「WordPressはPHPだったけど、Railsとはどう違うんですか？」みたいな、要領を得ない質問をしていた気がします。
「.erbの中に<%=から始まるコードがあって、それが動的な要素な気配はあるけど、こいつの定義は一体どこでされている……？」と結局全てをエンジニアに聞いていました。
まあ1年目のデザイナーにcontroller見てとかmodel見てとか言っても分かるはずないですよね。
この時期は本当に1つも分からないまま、雰囲気だけでコードを書いてしまっていましたが非常に楽しくもありました。
HTMLとCSSだけって全然大したことないんだ！と「外の世界」を知れた感覚とでも言いますか。
もちろん今になって思えばHTMLとCSSは簡単とか口が裂けても言えないんですが、とにかく当時はそういう感覚でした。
このタイミングでRailsを触りだしたのは、学習ロードマップとしてはあまりよろしく無かったかもしれません笑 初めて触った上に全体的な知識が足りていなさすぎて、血肉にできたものが少なかったような気が……。 というのもありRailsチュートリアルを最近改めてやって理解を深めようと奮闘中です。
Progate、ドットインストールをやってみる
少し経つと「RailsってRubyとは別物なんだ！」とか「jQueryってJavaScriptとイコールじゃないんだ！」とか、今まで割と根本から間違えていたことに気づき始めました。
ある程度体系的にやりたいと思ったのですが、噂レベルで「環境構築は難しい」と聞いていたので最初からお膳立てしてもらっているProgateをやってみることに。
改めてHTML, CSSからやって、比較的とっつきやすそうなJavaScriptをやって、実務で使うからRubyやRailsをやって……としているうちに結構進んでいました。
若干調子に乗ってドットインストールもはじめて見て、全然業務に関係ないのにSwiftを触ってみたり……笑
やや行き当たりばったりでしたが以下のような学びがありました。
- 言語やフレームワークは色々あるものの、ifとかforとかだいたいどれでも似たような概念がある
- ものによって全然違うのかと思っていたけど似ている部分もあると知れて安心できた
- 理由のない不安とか恐怖心を拭えたという意味では価値のある経験だと思う
- 基礎の部分だけ学んでも仕事で役立つレベルまでは非常に遠い
- 今はサービス側が用意してくれてる環境やデータ類を全部自分で用意しないと仕事にならないってことでしょ？と道のりの長さを痛感
- 自分で使えるレベルでなくても、色々な単語を知れたので業務で出てきたときに多少は質問しやすくなった
- 以前は「すみません、今なんて言いました……？」から始まるばかり
非常に学びが多かった反面、もし自分が初めてコードを書くときに「コンソール上で1+2をしてみましょう。すごい！3が表示されました！」ばかりだと面白いと思えなかったかもしれません。
HTMLとCSSで「コードを書くと目に見える完成物が生まれる」体験が最初にあって良かった気もします。
どちらのサービスも割と早い段階で有料会員になっておきました。 お金払ってるんだしちゃんとやらないと！と自分を追い込むやり方です。
Reactをやってみる
この頃から若干変革が訪れたかもしれません。多分2018年に入ってしばらくしたくらいです。
当時会社の中で「React良いよね、使っていきたい」と盛り上がりを見せていました。
ただ、新技術導入にあたってのエンジニアが懸念していたことの1つに「デザイナーに急に『React覚えてください、業務で必要です』なんて言っても流石にそれは厳しいというか酷だ。果たして上手くやっていけるのか？」といったものがありました。
我が社はデザイナーもHTMLやCSS、またはそれに相当するコード（それこそ.erbの中のマークアップ部分など）は書くのが当たり前になっているのですが、React導入によってその当たり前が成立しなくなるのでは？といったニュアンスでした。
ごもっともな心配ですしむしろそこまで気遣ってもらってありがたいのですが、生意気にも私は「悔しい」と感じていました。
明らかに良い技術があるのに自分が足を引っ張っているせいで導入できないなんてことがあったら……嫌でたまりません。
エンジニアがReactのキャッチアップをしているのに混ぜてもらって、こちらのUdemyの講座なんかを見ながら勉強を始めました。
「仮想DOMってなんだよ、ていうかDOMってなんだよ」ぐらい何も分からないところからスタートしましたが、componentとかstateとか、そういった概念をうっすらと理解できるくらいにはなれました。
onClickに合わせてスタイルを変えるとかpropsを親から渡してコンポーネントの見た目を制御するとか、そういうのはできるようになったので最低限のラインは超えられたと思います。
私は大抵のものごとにおける原動力が「怒り」「悔しさ」「劣等感」などマイナスな感情なので、このときの技術選定の空気感はかなりプラスにはたらきました。 多分プラスの感情が原動力になる人の方が多い気がするのでちょっと参考にしづらい章かもしれませんが……ご了承ください。
ポートフォリオを作る
どういう理屈だったか忘れてしまいましたが、この頃から「自分で好き勝手にコードを書いて、最悪削除すれば良い、そんな場所を用意した方が良い気がする」と思うようになりました。
というわけでポートフォリオサイトを作るに至ります。リポジトリは以下。
- せっかくReactの流れがきてるしReactを使おう
- サイトをホスティングするとかデプロイのフローまで整えたことがないからやってみよう
- 詳しくは知らないけどこのGatsbyってやつが良さそうだから使ってみよう
などなど興味や好奇心のみで全てを進めていきました。
トークンを普通にコードの中に書いてしまったり、本番でもコンソールにしこたまエラーが出たまま放置していたり、初心者丸出しのミスも多かったですが割り切ってスタートしていたので非常に楽しくやれました。
大それたことはしていないとは言え、1からサイトを構築してみるのはやってみて良かったです。
間違いなくベストプラクティスではないコードだらけだと思うのですが、それでも自分の力で頑張ってみて良かったと思います。 整理された環境だけでやっていても身につかない「根性」みたいなのはあると思っていて、それが身についた時期なような。 分からないなりに公式ドキュメントを調べて試して直して……というフローはかなり価値があった、はず。
エンジニアの友達と一緒にiOSアプリを作る
これは完全に趣味です。
メンバーと役割は以下です
- エンジニア
- コード書く
- ↓の2人への厚いサポート
- 環境構築やアプリのパブリッシュなど、大半
- ビジネス
- 仕様考える
- コード書く
- デザイナー（私）
- モックアップ作る
- コード書く
普段Webばかりやっている自分にとっては全くの未知で、全てを手取り足取り教えてもらっていました。
全く分からない中でも彼がコードを書いている様子や何を考えているかを聞いているのは非常に面白かったです。
変な話、業務ではないので「スピード優先で！」となる場面もなく、結構長い時間をかけて色々教えてもらいました。
こういう活動もあると改めてエンジニアへのリスペクトが沸きます。
なお作っていたのは完全にクソアプリでした
チュートリアル太郎になる
ポートフォリオ作成でGatsbyのGetting startedやTutorial、その他諸々のDocsを読んで実装する経験を得られたので色々なフレームワークで実践していました。
ちょっと話題になっていたらとりあえず浅く試すようになって、例えば以下のようなものを触っていました
- チュートリアルなど
- React（公式チュートリアルを関数コンポーネントに置き換える）
- Vue
- Svelte
- Next.js
- Blitz.js
- frourio
- Remix
- ドキュメント読んだりコード覗いたり（スタイリング関連）
- Emotion
- styled-components
- MUI
- Vuetify
- Tailwind
- Ant Design
- Polaris
- Carbon
1つ1つを深く触っているわけではないので正直「だから何？」ってレベルですが、実装で分からなくなっても公式ドキュメントやIssue、過去のPull Requestを見てどうにかできる度合いが増えてきました。
経験に比例して「とりあえず動きはする」までが早くなってはいると思うので無駄ではないはずです。
チュートリアルだけやったからって業務で使えるわけないだろう……と感じていらっしゃるみなさん。全くもってその通りです。 チュートリアルをやって満足してはNGで、それをやる過程で公式ドキュメントとしっかり向き合う練習をするのが（私くらいのレベルの人間にとっては）大事でした。
デザインデータを上手いことコードに変換するためにデザインシステム的な概念に興味を持つ
実装のことがある程度分かってくると「静的なモックアップをどうにかこうにか人の手でコードで再現するの、効率悪いのでは？」と思うようになります。
そのためコンポーネントライブラリとかデザイントークンの管理とかドキュメンテーションとか……そういったものに興味を持つようになりました。
デザイナーとエンジニアの職域のちょうど間くらいにあるトピックだと思うので、両者を繋げるためにも頑張りたいなーという気持ちは日増しに強くなっています。
1年くらい前ですがこんな記事も書きました。
UIのモックアップを作る時点でいかにコード的な考えを持っていられるか？を大事にしています。
これくらいの時期になると、設計的な話でも「デザイン実装の観点だとこっちの方策が好ましいです」などある程度有用な（？）意見が出せる場面も増えた気がします。
TypeScriptに触れるようになる
今まで業務で触ったのがJavaScriptとRubyだったので、実質動的型付けしかやってきていませんでした。
（Swiftは……経験があると呼べるレベルではありません……）
けどなんやかんやあってTypeScriptを触るようになり勉強していくと「型への意識をモックアップ作成時から持ってれば色々やりやすいじゃん」と気づきました。
ほぼプリミティブな型かそれらのユニオンくらいしか使っていないですが……最近だとUXPinを導入してみるにあたってTypeScriptでコンポーネントを書いてみています。
そして現在へ、今まさに取り組んでいること
だいたい、頑張ってる順に記載しています。
- テストコード
- テストって大事なんだ！と最近気付いたので少しずつ勉強中
- Railsチュートリアル
- あの頃半端になってしまっていたのを今取り戻すべく頑張っている
- バンドラー
- 設定1つで配信のされ方って随分違うんだなあ……と思ってときどき調べている
- パフォーマンス
- 速さは正義
まとめ
結局時系列で自分がやったことを並べただけなんですが、無理矢理まとめるなら以下です
- 最初は静的なHTMLとCSSで良いから、まずはコードに向き合う姿勢を養うのが大事
- コードで楽をする、効率的に進める、そういう喜びを知るのもまた大事
- 体系的に学べばもちろん良いことは多いけど、はじめからそれだとあまり楽しくないかもしれない
- 自分のモチベーションにあわせて……楽しい感情の方が大事だと思う
- チュートリアル1つとっても、公式ドキュメントを読むとか実際のコードを読むとか、大事なエッセンスは詰まっている
- ある程度余裕が出てきたらコードとデザインを行ったり来たりできる人間になると「お互いにとってためになる」話ができる
- エンジニアに質問してばかりの時期から次のステップへ
- やれどもやれども終わりは無い
- 本職でやってるエンジニアの方が一生スキルアップに励んでいるのだから、当然！