はじめに
Next.js + Cloud Runで管理画面をリファクタリング・技術選定編で紹介したとおり、フロントエンドのリファクタリングを行いました。リプレイスも含めて実施したもので、技術選定の部分はその記事でざっくりと書きました。
今回はプロジェクトをチームで勧めた上で良かった点・難しかった点などの知見を共有できたらと思います。
チーム構成としてはフルスタックエンジニアが私を含め6人で、私は全体の進捗と方針をメンバーと話しながら決める担当をしていました。リファクタリングと言いながらデザインの刷新もあったのですが、そのためのデザイナーから事前にFigmaでデザインを頂いている状態でした。
リファクタリングのきっかけ
もともとテストの追加できないくらい、１ファイルに複数のコンポーネントが作成されていたり膨大なpropsをもつコンポーネントがあったりコードが煩雑化していました。少しずつファイルを崩しながらテストを書いていく方法を考えていたのですが、開発を一部止めてリプレイスをするという提案をもらえ大規模なリファクタリングを行えました。
さきほどデザインの刷新についても話していますが、これはリファクタリングに追加して新たにデザインを実装するという大変な作業でした。しかし、結果としてはしっかりユーザにも価値がある新たなデザインを提供できるので、開発をほぼとめるような大規模なリファクタリングでも個人的には社内の理解を得やすかったんじゃないかなと思います。社内のメンバーには感謝です。
これは余談ですが、このプロジェクトが終わったあとにあるmeet upで「営業にリファクタリングの理解はされないのでリファクタリングの許可をもとめるな」という話がありました。過激にも聞こえるかもしれないですが、具体的にはコードに関しては営業がエンジニアより把握していないのは当然であり、また、「開発をとめてもいいですか？」と許可をもとめられたら立場上 「開発をとめてはいけない」と言わないといけない場合もあるじゃないかということでした。それは「確かに」と思ったのでエンジニア発信でどんどんリファクタリングを開発の工数の合間をぬってやっていくのがいいんだなと思いました。
しくじりマネジメント
この前の章でも書きましたが、今回のリファクタリングはデザイン刷新もあるリプレイスをするプロジェクトだけでも大変でした。さらに、初めての規模でのマネジメントですし、使用したAtomic DesignやNext.jsに対して経験が明るいわけではなかったです。
ですが、進捗がおもわしくなければ自分が入って実装をもらっていこうと思い、コードの指針やメンバーのタスク整理に加え私もコードを書いていました。これは反省なのですが、結構難しかったです。
昼間はほとんどメンバーのPRなどタスクの困りごと、必要があればコード指針やロードマップの修正もします。それが終わったら私がコードを書き始めるので、どうしても時間が足らず重要な方針やタスクの受け渡しなどの判断がおくれたり結局コードを巻き取ってもらったりしました。これに関しては、やはりメンバーを信頼してコーディングはメンバーに任せるのが一番だったなと反省しました。決定が止まると複数のメンバーが困るので全然よくないですよね。
Atomic Designとタスク分担
リファクタリングの指針としてAtomic Designを採用していました。実際にリファクタリングのタスクをAtomic Designを踏まえて分担していくのはすごく悩みました。
というのもまずすでにロジックがあるコンポーネントからロジックをもってきつつコンポーネントの粒度をAtomic Designに沿って切り分けることをしないといけなかったです。Atomic Designに関しては、ただのデザインシステムでチームがつかいやすいように変えて利用するものらしくタスク分担の指針がだいぶつくりずらいです。幸いなのは、デザインの刷新でデザイナーがボタンなどのUIの要素や配置はほぼ固定のままデザインを作ってくれていたことでした。
「なんちゃってAtomic Design」
そこで編み出した技としては「なんちゃってAtomic Design」を作ってしまうでした。
私の方で一旦たたきのコンポーネントの分類をScreen ShotをとってざっくりとGoogle Slideにまとめて共有するというものです。
Atoms, Molecules, Organisms,Templates, Pagesの大きい順にコンポーネントを分けてざっくりと分類し、もしチームから異論がでれば適宜直していく方針でした。これ自体はデザイナーと協力してFigmaやStorybookを作っておくべきだったとも思いますが、とりあえずpropsを大量に持つコンポーネントや１ファイルが肥大化させないことが優先でしたので特に問題はなかったです。
しかし、問題点としては、Atomsからどんどん大きいコンポーネントをつくっていくというチームの分担はあまり好評ではなかったです。というのもコンポーネントがどこで使われているのか想定しずらいという意見をいただいたのですが、採用したChakra UIで用意されたコンポーネントの利用も相まってうまく共通化されコードの肥大化に効果がありそうなAtomsコンポーネントではないものも一部つくられてしまっていました。
Pagesなどの大きなコンポーネントからどんどん小さいコンポーネントをつくっていくリファクタリングの方針のほうがさきにロジックもざくっと移しやすいですし、メンバーもどんどんコンポーネントを細分化させていけばいいので実装しやすかったんじゃないかなと思います。
Atomic Designに慣れるのにAtomsから作っていくのが良いかと思ったんですがそこまでの効果は発揮されていなかったように思えます。
参考
プロジェクトを達成して個人的なマインドへの影響
結論うまくリプレイス、デザイン刷新を含めたリファクタリングをが成功したのですが、個人的なマインドの学びはいろいろありました。
視座が高まった
ユーザに提供できる価値をベースに置きながらタスクの優先度を考えてみるような癖ができて、これはやる・やらなくていい判断が自分の中で整理しやすくなりました。また、技術的な理解も増えもっと大きなレベルの勉強したい内容とかも出てきました。
是非自分の名前がでるプロジェクト・立場をやってみることは勧めたいです。単にお金とかじゃなくて、何をしたいかするべきなのか強烈に意識することができた気がします。
もっとメンバーと話したくなった
プロジェクトをすすめる上でやはり焦ってうまく話せなかったときに私の考えを支えてくれたり、一緒に提案してくれるメンバーがいました。これは非常に助かったので今後は自分も誰かの考えの助けになれるようになりたいなと思えました。
また、意外と焦っていても誰かに相談にのってもらうとほとんどの問題が解決されました。プロジェクトの進捗を進めないといけないという焦りとは関係なく何がタスクの邪魔をしているのかさぐって地道にチームでとりのぞいてくけば大きなプロジェクトも確実に終わらせられるんだなと自信になりました。これからもチームでうまく話しながら進めるように意識したいです。
まとめ
以上、しくじりを含めたリファクタリングプロジェクトをすすめた知見を書きました。誰かのためになると幸いです。
がんばるのも重要ですが、難しいことに取り組むには休みも必要だなと今回思いました。しっかり休みながら大きなプロジェクトにも果敢に取り組める人が増えると嬉しいです。
Discussion