CMSでは補えない領域を拡張するスクラッチ開発

スクラッチ開発は「CMSでできないから作る」ページではありません。

• 業務要件が絡む
• 将来的に機能が増える
• データ量や処理が増大する

こうした前提を踏まえ、CMSの外側を積極的に拡張するための開発領域として位置づけています。

管理画面の実装

管理画面は、案件ごとに作るものではなく、毎回ベースとして組み込む前提で設計しています。

• コンテンツ管理
• ユーザー管理
• 権限管理

を基本構成とし、

• 管理者ログイン
• ユーザーログイン

の双方に対応可能な状態を、使わない段階でも準備された構造として用意します。
また、デザインは、デザインテンプレートであるAdminLTEを利用するため、基本的にデザイン費用は無料です。

• AdminLTE3

会員管理・ログイン機能

会員機能は、「必ず使うかどうか」ではなく、入ってきても対応できる前提機能として含める考え方です。

• マイページ
• お気に入り
• 閲覧履歴
• 検索履歴
• 会員属性による出し分け

これらを個別機能としてではなく、拡張可能な会員基盤として設計します。

各種通知機能・タイマー処理

通知や定期処理については、必要になった時点で実装できる状態をあらかじめ用意します。

• メール通知
• 外部API連携（Slack等）
• 定期処理（daily / monthly）
• 指定時刻実行
• 繰り返しスケジュールの柔軟な設定

Laravelのスケジューリング機構を前提に、運用に耐えうる処理設計を行います。

Jsonスナップショットによる負荷対策

Jsonスナップショットは、一部の特殊な高速化手法ではありません。
FHWでは、出現率の高いテーブルを中心に、Jsonスナップショット化を基本設計に含めています。

• 読み取り頻度が高い
• 更新頻度は限定的
• 表示速度が求められる

こうした条件を満たすデータについて、負荷を抑えるための設計オプションとして積極的に採用します。

API連携と相性の良いスクラッチ開発

API連携を前提とした構成と非常に相性が良い設計になっています。
Laravelによる機能開発では、

• データ構造を明確に定義できる
• APIとして切り出すことを前提に処理を設計できる
• フロントエンドや外部サービスと役割分担しやすい

といった特性があり、フロントエンド分離・外部システム連携・将来的な拡張に柔軟に対応できます。
そのため、

• ヘッドレス構成への移行
• 外部APIとの連携
• 管理画面・業務システムとの接続

といった要件が後から加わる場合でも、大きな作り直しをせずに対応できる構成を取りやすくなります。

機能開発の具体例

これまでの開発では、以下のような機能を実装しています。

• 会員システム
• 検索システム
• マイページ機能
• Jsonスナップショットを用いた表示最適化
• 管理画面を起点とした業務機能

Laravel / WordPress のいずれを用いるかは、

• 機能の複雑さ
• 将来拡張の可能性
• パフォーマンス要件

を基準に切り分けます。

未来を見据えた拡張性を前提とした設計

スクラッチ開発では、「今は使わないが、後から追加される可能性」を前提にします。

• 権限が増える
• 管理者が増える
• 処理が定期化・自動化される
• 機能同士が連携する

こうした変化に対応できるよう、設計段階から拡張性を組み込んだ構成とします。

このページで伝えたいこと

FHWのスクラッチ開発・機能開発は、

• CMSの代替ではなく
• 一時的な対応でもなく
• 将来を見据えた拡張を前提とした実装

であることを大切にしています。
業務や運用に耐え、育てていけるWebシステムとして成立することを重視しています。