Nuxt.jsからNext.jsへのリプレイスにあたり、とりあえずコンポーネントカタログを作る3つの理由

あるプロジェクトで、Nuxt.jsで作られたプロダクトをNext.jsにリプレイスするというものが始まりました。そこで、とりあえずコンポーネントカタログの整備から開始することにしました。この記事ではそうすることにした3つの理由を書いていきます。

1. コンポーネントのI/Oを担保する作業を容易にするため

今回のプロジェクトでは、コンポーネントの粒度やI/Oはなるべく現状の設計を流用していきたいと考えています。I/OはInput/Outputを略したもので「どのようなデータを受け取り、どのような振る舞いをするか」ということです。

Nuxt.jsからNext.jsにリプレイスする上では、それぞれの特有の記法が存在するため多少コンポーネント内部のロジックが変わります。それであってもI/Oが正しければ、内部ロジックが変わろうが問題はありません。これはユニットテストの考え方にも通じます。

コンポーネントカタログを利用すると、このI/Oが容易に確認できます。Gaji-Laboでは、ReactのプロジェクトではStorybookを利用していることが多いです。

Storybookでは、状態の切り替えやデータの受け渡しなどを、実際にコードを書き換えることなくブラウザ上で実行でき、またその際のアウトプットもすぐに確認でき大変便利です。Storybook上で最低限I/Oが期待通りであることがわかることで、コードレビューにおいてもよりコードの品質そのものに目を向けやすくなるというメリットもあります。

2. メンバーの入れ替えをやりやすくするため

Storybookが「実際に動かせるコンポーネントカタログ」として機能することで、コンポーネント単位の挙動の理解がしやすくなります。これはプロジェクトにジョインする上で学習コストを大幅に削減できます。

学習コストの低いプロジェクトは、属人化の防止につながります。「○○さんが詳しい」ではなく「コンポーネントカタログを見ればわかる」状態になるためです。○○さんに依存している状態では、○○さんはプロジェクトから離脱しづらくなります。交代の際に発生する引き継ぎコストもそれなりにかかります。

理想は「すべてがドキュメンテーションされているので、引き継ぐことが特にない」「自分しかできないことがない」という状態です。これはGaji-Laboの社内でプロジェクト移籍をする際だけではなく、クライアント側のエンジニアが異動したり入社したりする際にもメリットがあります。

3. 作業完了単位を小さくするため

コンポーネント単位の振る舞いを確認しやすくすることで、作業ごとの完了状態が明確になります。期待するI/Oを達成していればいいのです。

もし、APIと繋いでみたりコードを触って確認しないとI/Oが適切かどうかわからない場合、例え作業が完了しても、すべてがつながるまでは「仮実装済み」に近い状態になります。これでは作業完了が不明確で、結局「ページが完全に動くことが確認できるまで」完了したとは言えない状態になります。

一方で、コンポーネントカタログ上でさまざまな入力パターン適切に振る舞うことがいつでも確認できる場合、そのコンポーネント自体はほぼ「実装完了」と言える状態になります(実際はコンポーネント同士を結合させたり、APIのレスポンスが予期せぬデータ形式であったりすることで多少の調整作業は必要にはなりますが)

よくフロントエンドの仕事では「デザインができているがAPIができていないので、とりあえずガワだけ作る」という単位の仕事が発生することがあります。ただ動かないガワだけをつくるのではなく、挙動確認がしやすいようにコンポーネントカタログ上で実装することは、この「ガワ作業」のアウトプットの価値が高まる効果もあります。

ガワ作業は「HTML/CSSは書けるが、データの受け渡しなどはまだよくわかっていない」というジュニアスタッフが受け持つことがよくありますが、そこに「コンポーネントカタログで扱えるように実装する」作業を加えることで、JavaScriptを扱うことに慣れていくことにもつながります。

終わりに

以上のような理由で、コンポーネントカタログの整備を開始しています。

Atomic Designで言えば、まずはatomsのような独立したコンポーネントから、徐々にmolecures、organisms、と組み上がっていき、常に安全な場所でそれぞれのコンポーネント単位の正しい振る舞いが確認できる状態をキープすることで学習コストの低いプロジェクトにしていくことを目指していきたいと考えていきます。

スピード感を持ってプロダクト開発にリソースを全力投下することももちろん大事ですが、中長期的な目線で「今後関わる人が快適に作業できる」開発プロセスを作ることも、パートナーであるGaji-Laboの仕事だと考えています。


投稿者 yuki nakamura

フロントエンドエンジニア。
受託制作会社を経てスタートアップへ参画、経営・組織づくり・事業開発・プロダクト実装と幅広く経験。のち、Gaji-Labo入社。
得意なことは何かといい具合にすることで、よしなにお願いされることが多く、度々よしなにしている。
元編集者でもあり、ドキュメントを書くことが好き。ダーツも好き。