この記事はモニクルAdventCalendar2023の21日目の記事です。
ご挨拶 + 概要
どうもこんにちは！モニクルのエンジニアの久慈です。
そろそろクリスマスも近くなってきましたね🎅
最近は朝がとっても寒く感じ、ベットからやっとの思いで飛び起きています。
毎朝の起床も試錬に感じますが、今回は業務で試錬に感じていることについてまとめていこうと思います。
↓「試練」とは
この記事では、モニクルに入社してから自分が携わっている業務の一つである、Railsで作られている社内向けプロダクトをReact+GraphQLに置き換えていく業務についてまとめていこうと思います！
開発しているアプリ「ADMIN」のざっくり紹介
現在、僕は社内でファイナンシャルアドバイザー（FA）さんが利用する、「ADMIN（アドミン）」と呼ばれるSFA（Sales Force Automation）とCRM（Customer Relationship Management）の機能をあわせもったシステム(「モニクルのプロダクトマネージャーの仕事とは？」から引用)を開発しています。
ADMINの遷移
このADMINというシステムは、コミットログを遡ると2019年11月6日に弊社CTOの塚田さん(通称gabuさん)がrails newされていて、およそ4年強の歴史を持つアプリケーションです。個人的な話になりますが、僕が学生時代にエンジニアのバイトを開始したのもちょうど4年ほど前なので、その頃から開発されていると考えると、とても長い歴史があるように感じます、、！
↓rails new当時のコミットログ
先ほど言及した通り、ADMINは4年強ほど前にrails newされました。
その後、ADMINはRails wayに沿ってさまざまな機能が追加されていきました。ちなみに、ViewはSlim形式で記述されています。
Rails wayを用いることで、初期のADMINアプリケーションの開発は非常に高い生産性とスピード感を持って行われ、たくさんのビジネス要件を満たす肥大化したアプリケーションへと変貌していきました。
その後、時は流れ、モダンなフロントエンドフレームワークを用いてリッチなUIを作る風潮がWeb業界に出来上がってきました。そのタイミングで、モニクルのエンジニア達はSlim形式で書かれたViewをReactに置き換える作業に直面することになりました。また、社内ではこの作業を、UIライブラリのMUIを利用してUIをリッチにしていることから「MUI化」と呼んでいます。
MUI化について
MUI化する理由
そもそも、「なぜやるのか？本当にやる必要があるのか？」、そんな疑問が出てきたかもしれません。もちろん、MUI化をせずともADMINは(ほぼ)毎日元気に動作しているし、ファイナンシャルアドバイザー（FA）さんはADMINを用いて業務を遂行することが可能です。
ですが、モダンなスタックへ移行しない問題点が大きいことや、MUIを採用することで享受できるメリットが大きいこともあり、MUI化をする流れとなりました。
モダンなスタックへ移行し、レガシーな技術を使い続ける上で発生する問題を解消したい
モダンなスタックに移行しない場合には、主に以下の問題点が発生すると思われます。
- 保守性が低下してバグの確認や修正に時間がかかる
- 開発効率が低下して機能実装に時間がかかる
- レガシーな技術を使い続けることで技術的負債が増える
- レガシーな技術を使いたいエンジニアが少なく、既存のメンバーがプロダクト開発に消極的になるだけでなく、採用にも支障が出る
これらの問題点を解決するためにも、モダンなスタックへの移行をする流れになりました。
MUIを採用する利点
MUI化を開始するタイミングでは、社内にはまだ統一されたデザインシステムが存在せず、各プロダクトごとにバラバラしている状態でした。その上で、統一されたデザインシステム自体を考え始めるとそれだけで大事になってしまうので、まずは「既存のデザインシステム」をベースとしたかったという経緯があります。
MUIは「Material Designをベースとしてよく使われているフレームワーク」であり、情報が多いことや、ドキュメントが充実しています。加えて、MUIにはフォーム要素や関連コンポーネントが数多く揃っていますので、ADMINのような業務アプリケーションに適している利点があり、デザイナーとエンジニアの双方で議論を進めた上で、MUIが採用されました。
補足
Railsそのものを移行することも検討しましたが、あまりにも巨大かつ他の社内サービスとも連携しており、移行が完了できるイメージが沸かなかったので、まずはフロントエンドだけを引き剥がす流れになりました。
使用技術
MUI化を行う上で利用する主な使用技術に関してです。
- フロントエンド： React, urql(GraphQLクライアント), MUI(UIライブラリ)
- バックエンド：Rails
- graphql-rubyというライブラリを利用しています。
フロントエンドとバックエンドの疎通はGraphQLで行っています。
※ 既存のRailsアプリケーションの構成は前述の通り素直なRails wayになります。
MUI化する単位
ADMINのMUI化は、Controllerのロジックを確認しながら必ず一画面ごとに進めていきます。
例えば、CustomersControllerに関するMUI化を行う場合は、CustomersControllerのindexアクション→new/createアクション→edit/updateアクション→destroyアクション、といった順番で進めていくイメージです。
MUI化の流れ
ここからは、実際にどのような流れでMUI化を行っているかを紹介していきます。
1. Controller、View(Slimファイル)のロジックを確認
モノリスで書かれたRailsアプリケーションでは、画面を表示するまでのロジックが至る所に存在しています。
データ取得やインスタンス生成、データ生成や更新などを担うControllerとデータ表示やちょっとしたロジックを含むSlimファイルに加えて、Modelファイル、そしてViewにロジックを書かないために採用されているDecoratorパターンに基づいたファイルと、、、さまざまな場所にロジックが分散して書かれていることが多いです。特に複雑な画面をMUI化しようとなると、このロジックの分散が顕著に現れてきます。
MUI化に際してまずやることとしては、MUI化する画面のロジックが大体どのファイルに書いてあって、どんなロジックがあるかを確認することから始まります。
この段階では、既存の実装内容やロジックの大まかな流れや、今後の実装内容や順序をイメージするために、figjamにて洗い出しをすることが多いです。社内ではこの洗い出し作業を「実行計画」と呼んでいます。
↓実際のfigjam(ブラーがかかっています。)
ロジックを確認する上での試練
ロジックを理解するためには、画面にMUI化する前の画面を表示してみて、実際に動作チェックしたいところだと思います。ですが、シードデータが足りていないことが原因で、すぐには画面の表示をローカルで行えないことがあります。その場合は、本番環境のデータの個人情報をマスキングしたからデータからSQLで引いてきた結果をCSVにてダウンロードし、それをGUIクライアントツール(TablePlusを使っています)にインポートする、あるいはseedファイルにサンプルデータを作成するコードを書いてシードを流してようやく画面を確認することができるようになります。(これが地味に面倒...)また、複数のモデルのインスタンスを参照している画面だとさらにシードデータを作成することが難しかったりもします。。。めげずにここは踏ん張りましょう。
2. Viewで扱う内容をGraphQLオブジェクトに追加 + (必要があれば)mutationの実装
1の作業が終わったら、次はUIに表示したい内容をGraphQLのfieldに追加していきます。
具体的には、MUI化する画面に対応するモデル及び関連モデルのGraphQLオブジェクトに不足しているfield(出力タイプ)を追加していきます。
その上で、前述したDecoratorに定義されている実装はModelもしくはqueryの実装ファイルに移動したり、SlimファイルでのロジックをGraphQLオブジェクトのfield(出力タイプ)に追加することが多々あります。
2の作業のゴールとしては、GraphiQLで必要なデータを取得できることを確認することになります。
GraphiQLに関して、詳しくはこちらの記事を参照ください。
また、新規作成画面などのmutationを伴うMUI化を実装する場合は、このタイミングでmutationの実装も済ませておきます。
3. フロントエンドの実装
さて、graphiqlにてquery、mutationのエンドポイントができたら、あとは実装するのみです。
デザイナーさんからいただいたイケてるデザインをMUIを用いてしっかり実装していきましょう！
また、フロントエンド領域でのより具体的なフォームの実装に関して、こちらの記事にまとめていますので、よろしければ参考にしてください！
番外編：デザイナーやPdM、ステークホルダーとの連携で意識していること
ADMINの開発チームではスクラムを利用して開発を行っています。
スクラムは一週間単位で行っていて、毎日エンジニア、PdM、デザイナー、ステークホルダーがオンライン(gather)上で顔を合わせてMTGを行っています。(スクラムの詳細の説明は省きます。)
そのスクラムのMTGでは、MUI化に関しての議題もよく上がります。
MUI化をする画面は数年前に作られたものも多く、現在では不要な機能が存在していたり、またその逆で現状ないと困るけれど既存画面には実装されていない機能があったりします。
従って、エンジニアである我々はPdMやステークホルダーと共に議論をして、必要な機能やMVPの洗い出しをした上で実装に取り掛かる必要があります。
また、必要な機能やMVPをもとにより良いUIにするにはどうしたら良いか、といった相談をデザイナーさんと行う必要があります。
一画面をMUI化するだけでも、ただ実装するのではなくて、本当に必要な機能は何なのかや、どんなUIがFAさんにとって使いやすいのかを日々考えながら実装を進めていくことが大切です。
まとめ
MUI化は試練です。
ADMINのアプリケーションでは着々とMUI化が進んできてはいるものの、まだまだMUI化し切れていない画面もたくさんあります。
ADMINチームのエンジニアメンバーやデザイナー、PdM、ステークホルダーと連携して一歩ずつ着々とMUI化を進めていければ良いなと思っています。
また、MUI化を通してFAさんの働きやすさが改善して生産性が上がるような、より良いアプリケーションにADMINをしていけたら良いなと思って、日々開発を楽しんでいこうと思います！
最後に
(ちょっと早いですけど)メリークリスマス！🎄
個人的には、今年は台湾に2回行きまして、もっともっと旅行したくなる一年でした〜！
来年もハッピーな一年にしていきましょう〜😁
Discussion