【ITニュース解説】Building Extendable CRUD: How I Use Admiral to Create Flexible Admin Interfaces

近年、美容スタジオやクリニックといったB2Cサービスにおいて、顧客予約システムとその管理者向けの操作画面（アドミンパネル）の需要が急速に高まっている。これらのシステムでは、予約の作成、確認、変更、削除といったデータベースの基本的な操作（CRUD: Create, Read, Update, Delete）だけでなく、顧客情報、スタッフのシフト、サービスの割引など、多岐にわたる情報の管理が求められる。特に、予約システムは構築の速さ、費用対効果、そして既存の業務フローへのスムーズな統合が重要視される。スタッフが新しいシステムの使い方を習得するのに何週間もかけたり、日々の業務が中断されたりする事態は避けたいと考えるのが一般的だ。

しかし、多くの汎用的な予約プラットフォームや既存のCRUDジェネレーターは、往々にして「1人の専門家が1つのサービスを1つの時間枠で提供する」という直線的なモデルに特化している。これはシンプルな状況では有効だが、例えば複数人でのグループ予約、あるいは1人のスタッフが複数の工程に関わるような複雑なワークフロー、さらには予約のキャンセル、変更、サービス内容の入れ替えといったリアルタイムでの更新が頻繁に発生する状況には対応しきれないことが多い。このような課題に直面すると、多くの企業は汎用ツールではなく、自社独自のカスタムソリューションを求めるようになる。

開発者としては、このような状況で「どのフレームワークが予約システム管理画面に適しているのか」「標準的なCRUDジェネレーターでは対応できない複雑なビジネスロジックをどう扱うか」「システムとの互換性を損なわずにカスタムUIをどう構築するか」「柔軟性を維持しつつ開発時間をどう短縮するか」といった疑問に直面する。

私も以前は、ほとんどの開発者と同じように、市販のCRUDジェネレーターを使い始めていた。「10分で準備完了」という謳い文句は魅力的だが、常に同じ壁にぶつかった。それは、これらのツールがあまりにも融通が利かず、構造が固定されているということだ。特定の業務に合わせた独自のルール（ビジネスロジック）を実装しようとすると、フレームワークと協力して開発するのではなく、まるでフレームワークと格闘しているかのように感じられた。

このフラストレーションが、私が「Admiral」というフレームワークを開発するきっかけとなった。Admiralは現在、私たちのプロジェクトの70%以上で利用されており、オープンソースとして公開されている。Admiralが従来のツールと一線を画すのは、標準的なCRUDの枠を超えた複雑なワークフローを構築できる点だ。また、顧客にとって実際に役立つチャート、数値指標、ウィジェットなどを含むインタラクティブなダッシュボードを簡単に作成できる。Admiralは、ビジネス側がフレームワークに合わせるのではなく、フレームワークがビジネスのニーズに合わせて変化することを目指している。

Admiralの内部構造は、静的なファイルを固定されたテンプレートで生成するのではなく、拡張性のあるアーキテクチャ、柔軟なルーティングシステム、そしてモジュール化されたコンポーネントという形で提供される。これにより、開発者は必要に応じてカスタムのユーザーインターフェース（UI）や独自のロジックをシステムに組み込むことが可能となる。結果として、開発者を枠にはめ込むことのない強力なツールセットが得られるのだ。

私が最近手掛けたスパサロンの予約システムを例に、Admiralをどのように利用してCRUD機能をカスタマイズしたかを紹介する。このスパサロンの管理者が必要としていたのは、「予約の作成と管理」と「スタッフの稼働状況をカレンダーで確認する」という二つの機能だった。

まず、予約の作成と編集のためのカスタムページを構築することから着手した。私はAdmiralに組み込まれているコンポーネントと、独自に作成したコンポーネントを組み合わせて使用し、システム全体の一貫性を保った。例えば、RecordPageというコンポーネントは、新しい予約を作成する場合と既存の予約を編集する場合の両方に対応している。このコンポーネント内で、画面が表示されたときに既存の予約データを取得する処理や、フォームに入力されたデータをサーバーに送信する処理などを記述する。さらに、予約に関する情報、顧客情報、割引情報、支払い情報といった個々のセクションは、それぞれRecordSection、ClientSection、DiscountSection、PaymentSectionといった独立したコンポーネントとして定義し、それらをメインのフォームに組み込んだ。

このカスタムページが完成した後、Admiralのルーティングシステムに組み込んだ。具体的には、create.tsxというファイルで新しい予約作成ページへの経路を、[id].tsxというファイルで特定のIDを持つ予約の編集ページへの経路を、index.tsxで予約の一覧ページへの経路を設定した。これだけの作業で、予約の一覧表示テーブルに加え、カスタムデザインの予約作成・編集ページを備えたCRUDインターフェースが実現できた。

次に、管理者が必要としていた予約カレンダー機能の構築だ。単なるCRUDテーブルだけでは、スタッフの稼働状況や空き時間、予約変更などを視覚的に把握することは難しい。そこで、予約管理ページと同様に、Admiralを使って別のカスタムページとしてカレンダービューを作成した。CalendarPageというコンポーネントを作成し、その中でカレンダーのヘッダー、テーブル、予約メモといったUI要素を配置した。このページでは、API（アプリケーションプログラミングインターフェース）を通じてカレンダーデータを取得し、画面に表示する。これにより、管理者は視覚的に分かりやすい形で稼働状況を把握し、予約を管理できるようになった。

最後に、作成したこれらの新しいページをプロジェクトのメニューに追加し、管理者が容易にアクセスできるようにした。AdmiralのMenuコンポーネントとMenuItemLinkコンポーネントを使用することで、メニュー項目を定義し、それぞれの項目がどのURL（ページ）に遷移するかを設定する。例えば、「Main」という項目をクリックすると、作成したカレンダーページに移動し、「Records」という項目をクリックすると、カスタムの予約管理ページに移動するように設定した。

Admiralを複数のプロジェクトで利用した経験から、以下の点が明らかになった。第一に、複雑なロジックに対応できることだ。一般的なCRUDジェネレーターが限界に達するような場面でも、Admiralは柔軟に対応し、ビジネスの要求を実現できる。第二に、余計な負荷をかけずに高い柔軟性を提供することだ。カスタムUI、独自のビジネスロジック、カレンダー、ウィジェットなど、必要な要素を自由に組み込むことができる。第三に、迅速な立ち上げが可能で、かつ容易に拡張できることだ。まずはシンプルなCRUDテーブルから開発を始め、ビジネスの成長に合わせて段階的に複雑な機能を追加していくことができる。

私にとってAdmiralは、何十時間もの開発時間を節約し、フレームワークの制約に頭を悩ませるのではなく、本来のビジネス価値を提供することに集中させてくれる強力なツールとなっている。