【ITニュース解説】Behind the Scenes: Refactoring Glyph Catalog 🛠️

Glyph Catalogというウェブサイトが、最近の大規模なシステム改修を経て、以前よりも高速で整理され、使いやすくなった。この改修作業は「リファクタリング」と呼ばれ、システムの外部から見た動作を変えずに、内部のコード構造を整理し、保守性や拡張性を高めるための重要なプロセスである。今回のGlyph Catalogのリファクタリングでは、何が、なぜ、どのように変わったのか、そしてそこから何を学んだのかが詳細に語られている。

新しいシステムに移行する前、Glyph Catalogはいくつかの課題を抱えていた。まず、当初はシンプルな目的で開発されたが、収録する記号の数が増えるにつれて、ウェブサイトの表示方法が複雑化していった。カテゴリーごとに分類された記号を、すべて一つの大きな表形式で表示していたため、情報が混在し、全体像を把握しにくい状態だったのだ。また、ウェブサイトの「ルーティング」、つまりURLに応じてどのページを表示するかを制御する仕組みにも問題があった。Next.jsという技術の「キャッチオールセグメント」という機能を使って、様々な種類のページを一つのファイルでまとめて処理していたため、コードベースが肥大化し、システムの管理と理解が非常に難しくなっていた。

さらに、各記号には詳細な情報を提供する「専用ページ」が存在しなかった。すべての記号は大きな表の一部としてのみ表示され、個々の記号の具体的な使い方や関連情報が不足していたため、ユーザーの深いニーズに応えられなかった。データの管理方法も非効率的で、記号のデータが複数のTypeScriptオブジェクトとして別々のフォルダーに分散して保存されていた。これにより、新しい情報の追加や既存データの更新が煩雑になり、データ全体の一貫性を保つのが困難だった。

検索機能も不十分だった。以前の検索は、ポップアップ形式のダイアログ内に結果がすべて表示されるもので、検索の状態を保存する機能がなく、検索結果から目的の場所へ移動する際にバグが発生しやすかった。記号の数が増えるにつれて、この検索機能では対応しきれないという拡張性の問題も抱えていた。また、データベースにデータを登録する際の「データ検証」が不足していたことも大きな課題だった。データの品質をチェックする仕組みがほとんどなく、メタデータ（データに関する情報）も不十分なまま登録されていたため、新しいコードの追加やエラー修正が非常に手間のかかる作業となっていた。

これらの課題を解決するため、開発者は段階的にリファクタリングを進めた。まず、すべての記号データに対して「データ検証」の仕組みを導入した。これは、空欄のチェック、不適切な重複の確認、不正な文字の検出などを行い、データベースに格納されるデータが常にクリーンで一貫性があり、信頼できる状態を保つことを目的としている。

次に、「ルート構造」を全面的に見直した。以前のまとまりのないキャッチオールルートを廃止し、「[カテゴリー] → [メジャー] → [マイナー] → [記号]」という階層的なURL構造を持つ動的なページ構成に変更した。これにより、各記号が独立した「専用ページ」を持つようになり、その記号の詳細な情報を提供できるようになった。また、従来の表形式の表示を廃止し、カテゴリーやメジャーのページでは「カード」形式のレイアウトを採用することで、視覚的な情報の整理とナビゲーションの改善を図った。

データベースも再構築され、データの保存方法が根本から変更された。データをデータベースに登録するスクリプトを書き直し、すべてのデータを「単一のJSONファイル」という集中化された情報源から読み込むようにした。この新しいスクリプトは、データを自動的に検証し、適切なカテゴリーに分類し、必要なメタデータを割り当てる機能を備えている。さらに、メタデータや参照リンクを主要なデータとは別に管理することで、将来的に新しいコード形式を追加する際にも、データベースの構造を柔軟に変更できるようになった。

検索機能も大幅に改善された。以前のポップアップ形式ではなく「検索専用ページ」が導入され、検索条件がURLに保存されることで、検索結果の共有や再利用が容易になった。結果を絞り込むための「フィルター機能」も追加され、より多くの項目が明確な文脈とともに表示されるようになった。記号の「説明文」だけでなく「コード」でも検索できるようになったため、ユーザーはより柔軟に目的の記号を見つけられる。

「SEO（検索エンジン最適化）」と「アクセシビリティ」も向上した。各記号に専用ページができたことで、それぞれのページが検索エンジンによって個別にインデックスされるようになり、ウェブサイト全体の検索エンジンの評価が高まった。これにより、より多くのユーザーが検索を通じてGlyph Catalogを見つけられるようになった。収録されている記号の数は200未満から1,800以上へと大幅に増加し、メタデータやアクセシビリティ（誰もがウェブサイトを利用できるような設計）も改善されたことで、より広い範囲のユーザーに利用してもらえるようになった。

デザインとユーザー体験（UX）の面でも大きな変更が加えられた。レイアウトはよりシンプルになり、余白が増え、視覚的な情報の階層が明確になった。Unicode、Alt Code、HTML Hex、HTML Dec、Binaryなど、以前よりも多くの「コード形式」がサポートされ、それぞれのコードの使用例も示されるようになった。将来的に新しいコード形式を追加しても、レイアウトが崩れない「スケーラブルなデザイン」も採用されている。その他にも、ダークモードの切り替え方法の変更や、カラー調整、文言の洗練など、ユーザー体験をスムーズにするための細かな調整が多数行われた。これらの変更の最終目標は、開発者、デザイナー、そして一般のユーザーといった幅広い層にとって、Glyph Catalogが等しく便利で使いやすいツールとなることである。

今回のリファクタリングを通じて、開発者は多くの貴重な教訓を得た。システムの安定性と信頼性を確保するためには「データ検証」が不可欠であること、すべてのデータを「単一の情報源（Single Source of Truth）」で管理することが更新作業の効率化とデータの一貫性保持につながること、システムが将来的に拡大することを考慮し「スケーラビリティ」を見越した設計を早い段階で行うことの重要性、そしてシンプルで分かりやすい「ミニマルデザイン」がユーザーの探索体験を向上させることを学んだ。また、ウェブサイトの露出を高めるための「SEO」対策、利用者の実際の「ニーズ」に基づいた機能開発、そして情報発信としての「コンテンツ」（ブログなど）の重要性も再認識した。

今後のGlyph Catalogは、さらに進化を続ける予定だ。より多くのコード形式や記号に関する詳細な「メタデータ」のサポート、ユーザーの意図を理解する「高度な検索機能」、アクセシビリティガイドラインの継続的な改善が計画されている。また、コミュニティ主導型への移行や、ブログやSEOを通じたトラフィック増加にも注力していく。特に、現在すべての記号データが単一のファイルに保存されていることで生じる、ローカル環境での読み込み遅延などのパフォーマンス問題を解消するため、データ処理の仕組みを最適化し、再構築する必要があると考えている。

今回のリファクタリング作業は、地味で多くの再考と書き換えを伴うものだったが、その結果としてGlyph Catalogは、より堅牢で、将来の発展に耐えうる強固な基盤を手に入れた。システムエンジニアを目指す初心者にとっても、このような「システムの内部構造を改善する」という作業がいかに重要であるか、そしてその過程でどのような課題に直面し、どのように解決していくのかを理解する良い事例となるだろう。