スピード重視の立ち上げ期あるある負のループ
江面陽一氏：では、私から「”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なの？」とパッとわからなかったりという状況があって、全体像がわからないことが大きな課題でした。
スピード重視で開発することは、立ち上げ期のアプリケーションのあるあるだと思っていて、しょうがない部分もあるのかなと思っているのですが、直近の開発ではつらいということで、なんとかよい方向に舵を切りたいなとみんなが思っていました。
CIリブランディングの一部としてUIリニューアルプロジェクトが始動
そんな中、2019年5月のある日、弊社のCTOの町野から「UIリニューアルをやろう」という意思決定が降りてきまして、一同「やったぜ」とリニューアルプロジェクトが発足しました。次はそのリニューアルプロジェクトがどんな感じだったかをお話ししたいと思います。
このプロジェクトは「プロダクトの負債がとにかくやばいからリニューアルしようぜ」という話ではなくて。全社的にブランディングをリニューアルするプロジェクトが発足して、サービスのリニューアルはその一部であるというのがすごく大事なポイントだったと思います。
弊社の代表・米良がどのような思いでブランディングの刷新に踏み切ったのかが左側のnoteに記事でまとまっていますので、興味がある方はぜひ見てみてください。
一方、技術的な面としてやっぱり開発がつらかったのがあるので、なんとかいい方向に舵を切れるような施策を打ちたいなと考えました。ただ、ブランディングのプロジェクトは社内外が一丸となって進めるもので、どうしても期限は守らなきゃいけないものでした。
期限を守りつつもフロントエンドの開発がよくなっていくような攻めの側面も組み込みたいよねという話があり、このバランスをうまく取るためにどういう技術構成にするか、というのは、立ち上げときにすごく考えました。
UIリニューアルでやると決めたこと・やらないと決めたこと
最終的に無事決まった中身をちょっとシェアします。まずそのときにやると決めたことで、デザインシステムを入れました。今回対象じゃないほかのページや、プロダクトが今後分割していくにあたって、ブランドに紐づいた統一されたデザインの運用がどのみち必要になるだろうなという話があり、このタイミングで始めようということになりました。
他には、「UIライブラリの新規作成」というところで、デザインシステムから派生するライブラリを用意しました。機能の部分はどうしても仕様の戦いとなってしまうので、それならばデザインシステム文脈は最初から別のリポジトリで用意したほうがいろいろ開発もしやすいし、混ざらなくてよいだろうなと考えました。
こちらは「READYFOR Elements」と命名をて、社内限定ではあるんですけれども、npm installをすることによって利用が可能です。
一方で、先ほど「やると決めたこと」を紹介したんですけど、「やらないと決めたこと」もあって、それがReact on Railsからの脱却です。
こちらはつらかったのでやめたかったんですけど、当時、いくらブランディングが目的であったとしても、やっぱり対象ページの事業数字を落としてはいけないよねという話がありました。主にSEO観点なんですけれども、そうするとSSRを削る選択ってしにくいよね、という話になりました。
Node.jsのサーバーを新しく立てて、SSRするのでもいいのかなと思ったんですけど、ここに貼ったコードのとおり、コンポーネントを描画するときのパラメータでprerenderをtrueにするとSSRできるという仕組みがあったので、これはReact on Railsを使ったほうがいいよねという判断をしました。
他にもブランディングの刷新が目的なので、SPA化することによるUX向上などは、今回は必須ではないかなとなりました。API化するのであれば、バックエンドの工数も必要になってくるので、今回は現実的じゃないねという話をしました。
こんな感じで技術構成がいろいろ決まりて、2019年の10月に無事リリースできてよかったなと思っています。
UIリニューアルで使用した技術
では、そのときに使用した技術で、使ってみてどうだったのかという話も併せて紹介したいと思います。
最初に書いたのが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フロントエンドがいい方向に転がり始めたということで、「黎明」というタイトルで発表しました。
それでは終わります。ご清聴ありがとうございました。
