2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
READYFORフロントエンドの黎明 DesignSystem導入/READYFOR Elements誕生(全1記事)
リンクをコピー
記事をブックマーク
江面陽一氏:では、私から「”READYFORフロントエンド” の黎明」というところで、分離に向かっていいサイクルに傾き始めたときのきっかけをお話ししたいと思います。よろしくお願いします。
まず簡単に自己紹介させてください。江面陽一と申します。SIerからWebをやりたいなと思って転向しまして、READYFORに2018年の11月に入社をしています。私生活では、バンド活動をしていたり、猫を飼っていたりしています。技術的なところでは、React、Netlify、CSS設計、component設計などが好きです。
(スライドの)最後に「要素セレクタ警察」と書いているんですけど、これは「CSSの要素セレクタをプロダクションコードで書くのは悪だ」というふうに考えていまして、日々のプルリクエストを見ているときに、要素セレクタを気軽に書いてくる者を見つけた場合には、すぐに笛を吹いて、CSSの治安を良くするための取り締まり活動をしています。
では本題に入りますが、「”READYFORフロントエンド” の黎明」というところで、アジャンダを4つ用意しています。それまでどうだったかという話と、2019年のUIのリニューアルプロジェクトで使った技術を紹介します。最後にまとめてシェアしていきたいと思います。
それまでのREADYFORのフロントエンドですね。Railsアプリケーションで稼働を開始した「READYFOR」は、現場の要望を実現するためにとにかくスピード重視の開発が繰り返されていて、将来を見据えた設計というより動作することをとにかく優先して、スピード重視で開発されていました。
そうすると、やっぱり本番に出したときに初めてわかる考慮漏れがあって、それを突貫で塞ぐと、さらにバグを生みやすくなるという、負のループを踏んでいたと思っています。
フロントエンドの話で言うと、フロントエンドのコードの一部だけにRubyの変数が埋め込まれていたり、ReactとCoffeeScriptなどのいろいろな技術がちょっとずつ入っていたりしました。他にも、Gulpとwebpackが両方入っていたりとか、「npmなの? yarnなの?」とパッとわからなかったりという状況があって、全体像がわからないことが大きな課題でした。
スピード重視で開発することは、立ち上げ期のアプリケーションのあるあるだと思っていて、しょうがない部分もあるのかなと思っているのですが、直近の開発ではつらいということで、なんとかよい方向に舵を切りたいなとみんなが思っていました。
そんな中、2019年5月のある日、弊社のCTOの町野から「UIリニューアルをやろう」という意思決定が降りてきまして、一同「やったぜ」とリニューアルプロジェクトが発足しました。次はそのリニューアルプロジェクトがどんな感じだったかをお話ししたいと思います。
このプロジェクトは「プロダクトの負債がとにかくやばいからリニューアルしようぜ」という話ではなくて。全社的にブランディングをリニューアルするプロジェクトが発足して、サービスのリニューアルはその一部であるというのがすごく大事なポイントだったと思います。
弊社の代表・米良がどのような思いでブランディングの刷新に踏み切ったのかが左側のnoteに記事でまとまっていますので、興味がある方はぜひ見てみてください。
一方、技術的な面としてやっぱり開発がつらかったのがあるので、なんとかいい方向に舵を切れるような施策を打ちたいなと考えました。ただ、ブランディングのプロジェクトは社内外が一丸となって進めるもので、どうしても期限は守らなきゃいけないものでした。
期限を守りつつもフロントエンドの開発がよくなっていくような攻めの側面も組み込みたいよねという話があり、このバランスをうまく取るためにどういう技術構成にするか、というのは、立ち上げときにすごく考えました。
最終的に無事決まった中身をちょっとシェアします。まずそのときにやると決めたことで、デザインシステムを入れました。今回対象じゃないほかのページや、プロダクトが今後分割していくにあたって、ブランドに紐づいた統一されたデザインの運用がどのみち必要になるだろうなという話があり、このタイミングで始めようということになりました。
他には、「UIライブラリの新規作成」というところで、デザインシステムから派生するライブラリを用意しました。機能の部分はどうしても仕様の戦いとなってしまうので、それならばデザインシステム文脈は最初から別のリポジトリで用意したほうがいろいろ開発もしやすいし、混ざらなくてよいだろうなと考えました。
こちらは「READYFOR Elements」と命名をて、社内限定ではあるんですけれども、npm installをすることによって利用が可能です。
一方で、先ほど「やると決めたこと」を紹介したんですけど、「やらないと決めたこと」もあって、それがReact on Railsからの脱却です。
こちらはつらかったのでやめたかったんですけど、当時、いくらブランディングが目的であったとしても、やっぱり対象ページの事業数字を落としてはいけないよねという話がありました。主にSEO観点なんですけれども、そうするとSSRを削る選択ってしにくいよね、という話になりました。
Node.jsのサーバーを新しく立てて、SSRするのでもいいのかなと思ったんですけど、ここに貼ったコードのとおり、コンポーネントを描画するときのパラメータでprerenderをtrueにするとSSRできるという仕組みがあったので、これはReact on Railsを使ったほうがいいよねという判断をしました。
他にもブランディングの刷新が目的なので、SPA化することによるUX向上などは、今回は必須ではないかなとなりました。API化するのであれば、バックエンドの工数も必要になってくるので、今回は現実的じゃないねという話をしました。
こんな感じで技術構成がいろいろ決まりて、2019年の10月に無事リリースできてよかったなと思っています。
では、そのときに使用した技術で、使ってみてどうだったのかという話も併せて紹介したいと思います。
最初に書いたのがReactですね。当時は、デザインシステムを新しく作るんだったら、スタイルが書きやすいVue.jsという選択肢もなくはないかなと思っていました。ただ先ほど言ったとおり、React on Railsを使い続けるのであれば、React以外にする理由もないよねというところもあり、当時技術顧問をしてくれていた方がReactが得意だったので、主にこの2つが大きな理由になってReactを使う決定をしました。
TypeScriptはこのときに初めて入れました。「Reactを使うんだったらTypeScriptを使ったほうがいいよね」という、もはや使わない選択肢はなかった雰囲気がありましたね。
使ってみてわかったんですけれども、やっぱりどんなデータをコンポーネントがもらっているのかが実行しなくてもわかる、propsの型を見ればわかる状態というのがすごく快適で、これが「コンポーネントとどういうふうに分けていこうかね」という設計の時点で、ものすごく役に立ったなと思っています。
RailsからReactの連携部分だけはどうしても型の補完が利かないところなので、そこは手動でがんばって気をつけて開発していました。
AtomicDesignも今回新しく入れていたものです。「デザイナーの方との意思疎通のために一定のフレームがあったほうがよさそうだろう」と考えました。コンポーネント指向で、ゴリゴリ開発するのが慣れていないエンジニアも多かったので、最初の分割の指標になったのもよかったのかなと思っています。とはいえ、「Moleculeなのか、Organismなのか?」というAtomicDesignのあるある問題はもれなくウチも踏んでまして、コンポーネント分割の「どっちが正しいんや?」という議論も生まれているので、随時改善していきたいなと思っています。
あとはStorybookですね。こちらも触ったことはなかったんですけど、コンポーネントライブラリを作るのであれば入れたほうがいいんじゃないかという技術顧問の勧めで使い始めました。Railsのビューを作るときと違って、いきなりそのビューの開発に取りかかれるというのはすごく快適だなと思いました。
他にも、使ったことある方も多いと思うんですけど、addon-knobsというブラウザで状態の変化をポチポチ確認できるプラグインもあって、これもすごく役に立っています。
スクリーンショットで紹介しますと、このリブランディングのときに生まれたデザインがこういったかたちで、状態に応じて4つありました。Storybookで、ラジオボタンやチェックボックスをポチポチすると、状態に応じて確認できます。
ボタンだと「このラベルのところが長くなったらどうなるの?」というところがデザイン段階ではけっこうわからないと思うんですけど……こんな感じで「2行には決してならないボタンなんだな」ということがその場でわかるというのが、すごくコンポーネント開発の役に立ちました。
駆け足で説明したんですけれども、まとめです。コンポーネントを設計・実装する基礎力が身について、その感覚をエンジニア間でレビューなどを通して共有できたのはすごくよかったなと思いました。
責務を考えることはどんなReactコンポーネントを作るにあたってもけっこう大事なことだと思っていて、これをUIライブラリを作ったことによって、みんなが同じレベルで話ができるようになったというのは、ものすごくよかったと思いました。
あとは、デザインシステムとUIライブラリの運用が開始できたというのも素直によかったことだなと思っています。始まっていないと改善もできないと考えているので、今後改善をしてブラッシュアップしていきたいなと話しているところです。
反省点として1点挙げます。「これをいま言うなよ」って感じかもしれないんですけど、いきなりUIライブラリを作ると、機能を開発しているときにライブラリ側とアプリケーション側のどっちも直さなきゃいけなかったりして、その往復の工数がけっこうかかっちゃったなと思っています。今振り返ると、これは別のスコープでもよかったのかなと思います。とはいえ、さっき言ったとおり強制的に設計力が鍛えられた面もあったと思うので、大変だったんですけど、結果的にはよかったかなと思いました。
最後に、当時の弊社と同じような状況で、モノリシックなアプリケーションのフロントエンドを変えていきたいという方がいましたら、お伝えしたいのが次の4つです。
まず、新しいことをするタイミングは改善のチャンスでもあると思いました。きっかけがあれば、それに全力で乗っかるというのはいいタイミングになるかなと思っています。
2つ目はTypeScriptですね。これはメリットだらけだから少しでも入れたほうが本当にいいと思っています。僕も今まではTypeScriptを書いたことがなかったので、最初は「型を書くのが面倒だな」と感じていたんですけど、わりとすぐに「開発を楽にしてくれるものなんだな」という感覚に変わっていきました。コンポーネント開発に慣れていないエンジニアがいれば、なおさら型を明示的に書くことによって、コードを見ただけでどんな使い方なのか共有できる状況になるので、少しでも入れるとすごくよいと思います。
3つ目に「外部のスペシャリストに協力を仰ぐ」って書きました。今回デザインシステムを始めたときにデザイナーが社内にいなくて、外部のすばらしいデザイナーや、技術顧問に協力してもらって前に進めたので、社内にスペシャリストがいなければ、社外に頼むことで進めるかもしれません。
最後は「スコープを切る勇気をもつ」です。やりたいことがすごくたくさんある状況なら、なおさら「ここまではやる」「ここまではやらない」ということを決めることがいい方向に転じるきっかけになるのかなと思っています。
以上で僕の発表を終わりたいと思います。READYFORフロントエンドがいい方向に転がり始めたということで、「黎明」というタイトルで発表しました。
それでは終わります。ご清聴ありがとうございました。
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略