この記事は クラウドワークス グループ Advent Calendar 2024 シリーズ1の5日目の記事です。
はじめに
こんにちは。クラウドワークスで不正利用対策チームのバックエンドエンジニアとして働いている得能 (@yoshi_10_11) です。
入社以来、主にRuby on Railsを使ったバックエンド開発業務をしていました。画面実装を行うこともありましたがerbでの実装でした。
そんな私は2024年にVue.jsでの実装に取り組む機会をいただきました。Vue.jsでの画面実装だけをフロントエンド開発と言うのは少し浅はかであるとは思いましたが、バックエンド開発が中心のエンジニアがフロントエンド開発に取り組んだ際の感想が誰かの参考になるのでは？と思い書いてみました。
作業内容
私がこの1年間でフロントエンド開発に携わった内容です。あくまでもバックエンド開発がメインであるため、1年間みっちりやりました！というものではありません。それを考えると、その機会の中でもとても濃い経験ができたのではないかなと思います。
施策で新規追加する画面をVue.jsで実装
私の所属している不正利用対策チームの施策で新規実装機能の画面をVue.jsで書きました。
今年新規実装した画面についてはすべてデザイナーさんにFigmaでデザインいただいたものを元に実装しました。
また、弊社ではNormanという名のデザインシステムを構築しており、先述のFigmaでのデザインにも組み込まれています。実装時にNormanのライブラリを使って開発する必要がありました。
私が初めてNormanを使った実装をした当時は、デザインチーム以外でのNormanを使った実装実績がまだそこまで多くない状況であったため、随時ベストプラクティスを確認しながらの実装となりました。また、実装をしていく中でフィードバックなども行いました。
既存のerb画面のVue.js化
既存のerbで書かれた画面をVue.jsで実装し直すことが社内で推奨されているため、施策の空き時間でできそう！と思ったときに数ページほどVue.js対応を行いました。
crowdworks.jpの既存のerb画面が抱える問題点として
- 画面のテストが容易ではない
- スクリプトがjQueryで書かれており、画面が複雑になるほど可読性が下がる
- CSSの適用範囲が広く思わぬ影響を受けることがある
などがあります。(個人主観)
Vue.js化すると、
- VRTなどのテストが行えるようになる
- 画面内のロジックをわかりやすくまとめられる
- CSSモジュールを使ってCSSの影響範囲を限定することができる
など既存のerb画面の問題を解消することができるのでVue.js化作業を行いました。
その他
Vue.jsでの実装の際にはあわせてStorybookの定義ファイル、(必要に応じて)Jestでテストを書くなどしました。
また、実装を通じて必要かな？と思い、StorybookのPlay functionを利用できるようにパッケージ導入も行いました。その際に、既存のStorybookの定義をいい感じにするファイル群たちに加筆するなど画面実装以外の部分についても手を加える経験をしました。
…という感じで、先述の通りみっちりやりました！というものではないですが、フロントエンド開発としてそれなりに幅広く業務を経験できたのではないかと思います。
気づき
ここからは気づきです。必ずしもすべての組織で当てはまる内容ではないということだけご理解ください。
業務知識を得る&残す難しさ
開発当初、crowdworks.jpのフロントエンド実装の手順を理解するのに苦労しました。Qiita Teamに先輩方が残してくれたノウハウ、記録などはたくさん存在するのですが、開発の前提となる基本的な開発の流れが理解できていない状況であったため読み解くのに苦労しました。
Ruby on RailsをAPIモードで実装し、Vue.js側で実装したフロント側からAPIリクエストを叩き取得した値を表示する…というフロントエンドとバックエンドとを完全に分離した形式で学ぶことが多いと思います。(私はそうでした)
しかし、crowdworks.jpでの実装ではerb上でVueコンポーネントをマウントする形式をとっています。また、その実装方法も状況に応じていくつかパターンがあります。
※既存のRailsアプリケーションにVue.js実装の画面を追加していっているなどの理由からこのような形式となっています。
それらの情報は学習ツールや外部の記事で事前に学べるものではなく、社内の情報ソースやコードから読み解くしかありません。弊社に限らず同じように長い歴史のあるWebサービスを運営している会社さんであれば、同じような場面に遭遇し同じような苦労をされるのではないかなと思いました。(これはフロントエンド開発に限らずバックエンドにも同じようなことは言えますが)
フロントエンドエンジニアとして入社した方であれば接する機会も多いためもう少し習得がラクだったのかもしれませんが、私のように手を広げるかたちで取り組むケースだとそういった情報を得るのは難しいです。
この経験を元に、フロントエンド開発の最初のハードルを下げる仕組みが必要だと思いチュートリアルを作成しました。作成から半年で多くの方にご利用いただき感謝の言葉もたくさんいただきました。
作成したら作成したで今度はこの情報の維持が難しいな、という思いも出てきました。
最近ちょっとだけフロントエンド開発から離れてしまっているのですが、早くもチュートリアルの内容の一部が現状に合わないという部分が見られています。
理想は常に最新・完璧なチュートリアル、ドキュメントが揃っている状態ですが、それらばかりを優先するわけにもいかないので難しいです。
Vue.jsなどの書き方を学ぶだけではいい仕事はできない
当然といえば当然なのですが、Vue.jsなどのフレームワークでの書き方だけを理解してもいい仕事はできないな、と感じました。
画面以外も実装できるようにしたい
フロントエンド開発は画面実装だけではありません。
例えば、StorybookやJestのテストの設定、テストをサポートするツールの設定(モック、CIなど)、ビルドツールの設定などがあります。
弊社では既に設定が書かれて運用しているものがあるので頻繁に書き換えるようなことはありませんが、まれに改良のために書き換えたいなと思う場面があります。
私も何度かそういう場面に遭遇しましたが、お恥ずかしい話、自分で解決できた場面がとても少なく悔しい思いをしました。
フロントエンド開発を支える周辺ツールの学習、および、JavaScript(TypeScript)を書く力を今以上に持たなければいけないな、と感じました。
良いWebサービスを作るための考え方を持ち合わせたい
「良いWebサービスを作るための考え方」と書くとものすごく抽象的なのですが、一例を出すならばWebアクセシビリティが挙げられます。
crowdworks.jpはとても多くの方にご利用いただいているサービスとなり、今後もより多くの人に不便なくご利用いただくためにもWebアクセシビリティを追求する姿勢は重要だと感じました。
また、デザイナーさんから新規実装の画面デザインをいただく際に、そのまま実装するのではなくこうしたらよいのではないか、という意見交換をすることもあります。
その際に、私のような実装者側もWebアクセシビリティなどの知見を持ち合わせておくと、よりよい意見交換ができると感じました。
実際に、ボタンのホバー時やフォーカス時のアウトラインの仕様について意見交換をする機会がありました。今思うとそのときにもう少しWebアクセシビリティ(だけの話ではないのですが)の知見を持ったうえで議論ができればよかったな、と感じています。
この経験から、専門家にならなくてもいいけど意見交換できるくらいの知見は持っておこう、という意識で良いWebサービスを作るための考え方に触れるようになりました。
※今回例で紹介したWebアクセシビリティの場合は、技術評論社の「Webアプリケーションアクセシビリティ」という本がとてもわかりやすくてよかったです。
終わりに
以上、私が今年のフロントエンド開発を振り返った内容、感想になります。
これからフロントエンド開発に携わる初学者さん、または私のように元々フロントエンドエンジニアではない方などに、今後業務を行う上での参考になればと思います。