はじめに
こんにちは、フリューのソフトウェアエンジニアkitajimaです。ピクトリンクの開発を担当しています。
弊社サービスピクトリンクにおけるお問い合わせ対応や調査で利用する、データベース情報を検索するための社内ツール(以下、検索ツール)を刷新しました。
刷新にあたり、技術選定で意識したポイントを紹介します。
検索ツールの概要
お客様からのお問い合わせ対応のため、頂いた情報をもとにデータベースを検索し、結果一覧および詳細情報を閲覧するツールです。社内ツールであり、お問い合わせに対応するカスタマーサポートメンバーからの利用に限られています。
ピクトリンク開発に携わる開発メンバーたちにとって、この検索ツールのメンテナンスも役割の一つです。 ピクトリンクの機能変更に伴う対応や利用メンバーからの要望などにより、継続的に機能改修を行っています。
旧検索ツールの課題
旧検索ツールの構成は以下のようになっています。
- S2Struts 1.2
- Velocity 1.4
バージョン履歴を確認すると、旧検索ツールは18年以上存在していました。筆者が9歳の頃ですね。 機能改修やライブラリのバージョンアップは続けられてきたものの、ベースは当時の最新フレームワークであるS2Strutsのままでした。
今の開発メンバーの技術スタックとは乖離しており、軽微な改修も困難です。時間がかかったり、古参のメンバーに頼ったりする場面が多くあります。
また、検索ツールに限らず社内ツール全般に対し言えることなのですが、機能開発が優先のため対応がどうしても後手後手やその場しのぎになりがちだったり、各々が自由に変更を重ねるため各種設計や技術選定等プロジェクト方針に統一性が無くカオスになってしまったりします。
結果、とっつきにくさ、苦手意識を感じるメンバーが多く、ますます改修できるメンバーが限られてしまうというループに陥っている状態でした。
新検索ツールの技術選定
新検索ツールでは、以下のように技術選定しました(一部抜粋)。
- バックエンド
- Kotlin + Spring Boot
- フロントエンド
- React + Vite(SPA)
- React Router
- Mantine
技術選定で意識したポイント
ただ単に新しいから、"イケてる"からではなく、開発メンバーに「これなら気軽に迷わずメンテできそう」と思ってもらえることを意識しました。大きく2つの観点があります。
1. ハードルを低くする
開発メンバーはメインのプロダクト開発でNext.jsやSpring Boot(Java/Kotlin)を主に利用しています。
普段利用している技術スタックに近づけることでとっつきにくさ、苦手意識を減らし、「これなら気軽にメンテできそう」と思ってもらえることを目指しました。
当たり前のように聞こえる一方で、社内ツールには「普段触れない尖った技術選定を気軽に試せる」という側面もあります。これはとても魅力的ですが、チーム開発における開発継続性とはトレードオフになると考えます。
今回は旧検索ツールの課題解消が主目的であること、旧検索ツールは18年間使われている息の長いツールであることから、「普段利用している技術スタックに近づける」方針に寄せました。
期間限定のサービス向けや使い捨てのプロトタイプ開発など、寿命の短いプロダクトではもう少し毛色の違った技術選定も試してみたいです。
余談ですが、旧検索ツールも思えば当時のプロダクトでも利用していた最新のフレームワークを採用していました。思想としては旧検索ツールの技術選定も同じだったのかな、だからこそ逆に18年間も改修されながら利用され続けられているのかな、と想像しました。(メンテしづらいとか言ってごめんの気持ち)
2. 自由度を低くする
各々が改修を重ねてもカオスになってしまわないように、また、機能改修で余計な迷いが生じないよう自由度を低くすることを狙いました。
フォーマッタを導入するなど基本的なことはありますが、ここではフロントエンドに関して2点やったことを紹介します。
UIライブラリを採用する
社内ツールはお客様に向けたサービスほどUIデザインを重視する必要が無いため、デザイナーはアサインされません。UIデザインは開発メンバーに委ねられています。
この状況でも統一性を保つ方法のひとつが、既存のUIデザインを持ったUIライブラリを利用し、カスタマイズは最小限にすることです。
Mantineは、React向けのUIライブラリです。他のUIライブラリも検討しましたが、以下の理由からMantineを採用しました。
- 活発にメンテナンスされている(2025年9月現在)
- コンポーネントにCSS Modulesが使用されており、カスタマイズする場合もCSS Modulesの利用が推奨されている
メインのプロダクト開発でもCSS Modulesを利用しており、親和性で一歩リード
- 生成AIに向けたテキストを公式が提供しており、エージェントによるコーディングで便利
ディレクトリ構成をlintする
フロントエンドのディレクトリ構成はこれ一択といった結論があるわけでもなく、巷でも度々議論があると認識しています。
ピクトリンクの主要プロダクト(Next.js)でも、最近ディレクトリ構成を見直したところです。
新検索ツールでは、Feature-Sliced Design (FSD)を採用しました。
FSDは、従来のような技術的レイヤ中心の構成に対し、アプリケーションの機能を中心とした構成にするという原則の設計です。
他の選択肢と深く比較検討をしたわけではありませんが、
- 特にReactエコシステムに向けた方法論と謳われていること
- 公式にディレクトリ構成のlinter steiger が提供されている(※ベータ版)
という点で導入することにしました。
Pull Requestを立てた時点でsteigerを実行するGitHub Actionsを設けたり、生成AIに対しては各種コンテキストや指示にsteigerを走らせる旨を盛り込んだりすることでFSDの構成を保つようにしています。
生成AI向けのmarkdownファイル(一部抜粋)
### Compliance Check **IMPORTANT**: After completing any frontend task, you MUST run the FSD compliance check: ```sh cd front npm run fsd:check ```
現時点で小規模なプロダクトなので却って冗長にも思えますが、ディレクトリ構成はプロジェクト全体に関わるもので、後からの見直しは大変です。発足時の今のタイミングで導入しておくことにしました。
さいごに
社内ツールにおいて、開発メンバーに「気軽に迷わずメンテできそう」と思ってもらえることを目指し、
- ハードルを低くする
- 自由度を低くする
という2観点で技術選定してみた旨を紹介しました。しかし内心は「これでいいのだろうか・・・」という気持ちです。正解も無ければ、ねらい通りの効果があるのかは色んなメンバーと共にメンテナンスし続けないと分からないからです。 そして、プロダクトの技術選定や初期リリースは楽しい一方、やり切ると満足しがちです。
旧検索ツールの寿命を超えて18年以上メンテナンスできるように、というのは冗談として、「触りたいときに誰もが触れる」状態をなるべく続けられるよう新検索ツールに向き合っていきたいです。
