【ITニュース解説】How I Solved the Flooded Icons Crisis in Our React Codebase

急速に成長を続けるSaaS（ソフトウェア・アズ・ア・サービス）プラットフォームにおいて、開発現場で大きな課題が持ち上がった。このシステムはReactという技術で作られた400以上の部品（コンポーネント）で構成され、5年以上かけて開発が続けられてきた。その結果、ユーザーインターフェースで使われるアイコンの管理が手に負えない状況になってしまったのだ。具体的には、600種類以上ものアイコンファイルがコードベースの様々な場所に散らばり、まるで「アイコンの洪水」のように混乱が生じていた。

このような状況は、日々の開発作業に深刻な問題を引き起こした。まず、開発者たちはどのアイコンを使えば良いのか分からず、常に迷っていた。「追加」を意味するアイコン一つをとっても、「IconAdd」「IconPlus」「IconAddCircle」など複数のファイルが存在し、さらに同じ「電話」のアイコンでも「IconCall」「IconCallAlt」のように多くのバリエーションがあった。これらのアイコンは異なるフォルダに分散しているため、一つを選ぶだけでも多くの時間を費やしていた。

次に、多くのアイコンが重複していたことも大きな問題だった。「追加」のアイコンが6種類、「LinkedIn」のアイコンが4種類、「電話」のアイコンが8種類も存在し、それぞれが似たような見た目や機能を持っていたのだ。これは、開発者が既存のアイコンを見つけられなかったために、新しいアイコンを次々と作成してしまった結果だった。

また、アイコンを使う際に指定する設定項目（プロパティ）に一貫性がなかった。あるアイコンでは「サイズ」が任意の文字列だったり、別のアイコンでは必須の文字列だったり、さらに特定のアイコンでしか使えない独自のプロパティが存在したりした。そのため、開発者はアイコンを使うたびにそのプロパティの型や使い方を確認する必要があり、作業効率が著しく低下していた。

最も深刻だったのは、利用可能なアイコンを視覚的に確認できる手段がなかったことだ。開発者は、新しいアイコンが必要なときに、既存のアイコンを探すために多くの時間を費やしたり、デザイナーに「こんなアイコンはありますか？」と問い合わせたりする必要があった。この不便さから、既存のアイコンを再利用するよりも、新しいアイコンを新しく作ってしまうという悪循環が生まれていたのだ。

このアイコンの洪水問題を解決するため、一人のエンジニアが「アイコンブラウザ」と呼ばれるツールを開発した。これは、コードベース内のすべてのアイコンを自動的に発見し、それらを視覚的に一覧表示し、簡単に利用できるようにする画期的な仕組みだった。

解決策は、いくつかのステップで構築された。まず、「自動アイコン発見」の仕組みだ。これは、特別なスクリプトを使ってコードベース全体をスキャンし、存在するすべてのアイコンファイルに関する情報を集める。集められた情報、例えばアイコンのファイルパス、名前、カテゴリ、ファイルの大きさ、最終更新日時などは、「iconList.json」という一つのJSONファイルに自動的にまとめられた。これにより、600以上のアイコンすべてが、どこにあり、どんな名前か、といった情報が整理された。

次に重要なのが「動的アイコン読み込みシステム」だ。ウェブアプリケーションの構築に使われるWebpackのようなツールは、通常、事前にどのファイルを読み込むか静的に解析する。しかし、アイコンブラウザでは、ユーザーが選択したアイコンをその場で読み込む必要があるため、動的に読み込む仕組みが必要だった。このシステムは、アイコンのパスや拡張子（例えばSVGファイルか、Reactのコンポーネントファイルか）に応じて、適切な方法でアイコンファイルをプログラムから読み込む。これにより、必要なアイコンだけを必要な時に取り込むことが可能になった。

さらに、「賢いコンポーネント抽出」という工夫も凝らされた。アイコンファイルの中には、コンポーネントをエクスポートする方法が複数ある。あるファイルでは「デフォルトエクスポート」として、また別のファイルでは特定の名前で「名前付きエクスポート」として、さらに「Icon」という接頭辞を付けずにエクスポートされている場合もあった。このシステムは、それらの様々なエクスポートパターンを自動的に識別し、アイコンの実体であるReactコンポーネントを正しく取り出すことができるように設計された。

アイコンは、それぞれ独自のコードを持つため、レンダリング（画面に表示する処理）中に予期せぬエラーが発生する可能性があった。この問題を解決するため、「エラー境界」と「安全なレンダリング」の仕組みが導入された。これは、各アイコンのレンダリングを監視し、もしエラーが発生しても、そのアイコンだけが壊れて表示されず、アプリケーション全体が停止しないようにする保護機能だ。さらに、アイコンに渡されるプロパティ（サイズ、色など）も、どんな値が来ても安全に処理できるよう、自動的に適切な形式に整形される（サニタイズ）。これにより、アイコンの表示が非常に安定したものになった。

そして、これらの技術的な基盤の上に「アイコンブラウザのユーザーインターフェース」が構築された。このブラウザは、検索バーとカテゴリフィルターを備え、開発者はキーワードでアイコンを検索したり、特定のカテゴリに絞り込んだりできる。画面には、発見されたすべてのアイコンがグリッド状に美しく表示され、それぞれのアイコンをクリックすると、そのアイコンを自分のコードにコピー＆ペーストで簡単に組み込めるインポート文が自動的に提供される。

これらの解決策が導入された結果、開発現場は劇的に改善された。まず、すべてのアイコンが完全に可視化され、開発者は一箇所で383種類以上のアイコンをすべて確認できるようになった。スマートな検索機能のおかげで、アイコンを探す時間は以前の10分以上かかっていたものが、わずか30秒程度に短縮された。重複するアイコンが視覚的に分かりやすくなったことで、同じ機能を持つアイコンを統合する作業も容易になった。しかも、新しいアイコンが追加されても自動的にブラウザに反映されるため、特別なメンテナンスは不要だった。

この変化は、開発者の体験を大きく向上させた。以前は、どのアイコンを使うべきか分からずにフォルダを探し回ったり、間違ったアイコンを使ってやり直したりする手間があったが、今ではアイコンブラウザを開いて検索し、クリックするだけで目的のアイコンをコードに組み込めるようになったのだ。結果として、重複アイコンの作成は約80%も減少し、新しくチームに加わる開発者もすぐに必要なアイコンを見つけて使えるようになった。デザイナーとの連携もスムーズになり、デザインシステム全体の一貫性が大幅に向上した。

このプロジェクトを通じて、いくつかの重要な教訓が得られた。一つ目は、適切なツールを導入することが、技術的な負債（将来的に問題を引き起こす可能性のある、修正が困難なコードや設計）を未然に防ぐことにつながるということだ。アイコンの混乱は、可視化されて初めて具体的な対策を講じることができた。二つ目は、開発者の体験（DX）が向上すれば、それが直接的に製品の品質（UX）に結びつくという点だ。開発者が適切なアイコンを簡単に見つけて使えるようになれば、製品全体のデザインの一貫性が保たれ、ユーザー体験も向上する。三つ目は、自動化されたシステムは、手作業で更新されるドキュメントよりも優れているということだ。「どのアイコンを使うべきか」という情報を文書で管理するのではなく、ツールがそれを自動的に表示・提供することで、常に最新で正確な情報が得られる。そして最後に、大きなアーキテクチャの変更でなくても、日々の開発作業を改善する小さなツールが、開発者の生産性に大きな影響を与えることが示された。

このアイコンブラウザの成功を受け、今後は重複アイコンの統合、デザインシステムとのさらなる連携強化、重複作成を防ぐための自動コードチェック（Linting）の導入、そしてどのアイコンが実際に使われているかを分析する機能の開発などが計画されている。このように、開発者向けのツールに投資することは、時間の経過とともに大きな利益をもたらすことが証明された。開発者が既存の資産を容易に発見し再利用できるようになれば、コードベースはより一貫性を保ち、チーム全体の生産性も向上する。