なぜLaravelによるスクラッチ開発を行うのか

企業サイトやサービスサイトの多くは、WordPressやMovable TypeなどのCMSで十分に運用できます。

実際、企業サイト、お知らせ、採用情報、実績紹介、オウンドメディアなどであれば、CMSを活用することで効率的な運用が可能です。

しかし、Webサイトの運用を続ける中で、

• 会員機能を追加したい
• 独自の検索システムを構築したい
• 外部システムと連携したい
• 独自の管理画面を作りたい
• 社内業務を効率化したい
• 複雑な権限管理を行いたい

といった要望が生まれることがあります。

このような場合、WordPressやMovable Typeを拡張し続けるよりも、最初からシステムとして設計した方が、結果的に運用しやすくなるケースがあります。

私たちは、そのような案件に対してLaravelを活用したスクラッチ開発を行っています。

Laravelは、会員管理や検索システム、API連携などを整理された構造で実装しやすく、将来的な機能追加にも対応しやすいフレームワークです。

また、長期運用を前提とした場合でも、構造が整理されているため保守や機能追加を行いやすいという特徴があります。

そのため私たちは、単純なWebサイトではなく、

• 会員サイト
• 検索システム
• 業務システム
• API連携
• 管理画面構築

などを伴う案件でLaravelを活用しています。

スクラッチ開発は本当に高いのか

スクラッチ開発という言葉を聞くと、「すべてを一から作る」というイメージを持たれることがあります。

そのため、

• 費用が高そう
• 開発期間が長そう
• 大企業向けの話ではないか

と感じる方も少なくありません。

しかし実際には、必ずしもそうとは限りません。

確かに、完全にゼロから開発を行えば、それなりの工数が必要になりますが、私たちが利用しているLaravelは、PHPの代表的なフレームワークのひとつです。

データベース接続や認証、メール送信など、多くの基礎機能があらかじめ用意されており、本当の意味でのスクラッチ開発とは異なります。

つまり、何もない状態から開発を始めるのではなく、整理された土台の上から開発を進めることができます。

さらに、私たちは長年Laravelを利用する中で、案件ごとに繰り返し利用する機能を整理・共通化してきました。

例えば、

• ログイン機能
• パスワード再発行
• 権限管理（Laravel Permission）
• 管理画面（AdminLTE）
• メール送信 / Mail Queue
• 一覧ソート機能（DataTables）
• ファイルアップロード機能（FilePond）
• リッチテキストエディタ（tiptap）
• 静的ファイル化機能（JsonSnapshot）
• 動的サイトマップ作成機能

などは、多くの案件で利用する機能です。

そのため現在では、これらを組み込んだLaravelのベーステンプレートを、Laravelのバージョンアップに合わせて継続的に整理・改善しています。

つまり、案件ごとに毎回ゼロから開発しているわけではなく、必要な部品を組み合わせながら、お客様の要件に合わせて構築しています。

実際には、「WordPressを大幅にカスタマイズする」よりも、「Laravelで素直に構築した方が結果的に安定する」ケースも少なくありません。

なぜテンプレート化しているのか

私たちがテンプレートを整備している理由は、開発を楽にするためではありません。

本当に時間を使うべき部分に集中するためです。

例えば、

• 業務理解
• システム設計
• データ設計
• 画面設計

といった部分は、案件ごとに大きく異なります。

一方で、

• ログイン
• 権限管理
• 管理画面
• メール送信
• ファイルアップロード

などは、案件が変わっても共通する部分が多くあります。

そのため、「毎回考えなくてもよい部分は仕組み化する」という考え方でテンプレート化を進めています。

私たちが時間を使うべきなのは技術そのものではなく、お客様の課題や運用を理解し、それをどのようにシステムへ落とし込むかという部分だと考えています。

テンプレート化は開発効率化のためだけではなく、品質の平準化や保守性向上にもつながっています。

管理画面構築の考え方

管理画面のUIは、AdminLTEで実装しています。これにより管理画面のUIについて、時間と費用をかけることなく、様々なBootstrapベースの機能を利用することができます。

また、多くの業務システムでは、

• 一覧
• 新規登録
• 編集
• 削除

という、いわゆるCRUD構成になりますので、この部分についても標準化しています。

一覧画面ではDataTablesを利用し、

• 検索
• ソート
• ページング

を標準機能として利用しています。

また、新規登録画面と編集画面は共通フォームを利用し、入力パーツも部品化しています。

• テキスト入力
• セレクトボックス
• ラジオボタン
• チェックボックス
• ファイルアップロード

などを組み合わせながら構築できるようにしています。

そのため、案件ごとにゼロから管理画面を作るのではなく、必要な項目を追加しながら効率的に構築することができるため、結果として、

• 開発スピード
• 保守性
• 操作性

を両立しやすくなります。

JsonSnapshotを作った理由

JsonSnapshotは、実際の案件での経験から生まれました。

Laravel6の時代、複雑な検索システムを構築していた際、

• whereHas
• リレーション
• ネストした検索

などを多用する場面がありました。

その時に直面したのが、N+1問題です。

データベースへのアクセス回数が増えることで、処理速度が大きく低下する現象です。

さらに運用を続ける中で、WebサーバーとDBサーバーが別の場所に存在する場合、その通信そのものが処理時間に影響することも実感しました。

当時は、「DBの処理速度」ばかりを考えていましたが、実際には、「DBへ何回アクセスするか」そして「その通信距離」も重要でした。

そこで考えたのが、毎回データベースへ問い合わせるのではなく、公開用のデータを事前に生成できないかという発想です。

そこから生まれたのがJsonSnapshotです。JsonSnapshotでは、公開サイトに必要なデータを事前に生成し、Webサーバー側で完結できる状態を作ります。

これにより、

• DB負荷の軽減
• API負荷の軽減
• 表示速度向上
• 障害耐性向上

などを実現できます。

スクラッチ開発は本当に属人化するのか

Laravelによる開発を検討する際、「他社へ引き継げなくなるのではないか」というご相談をいただくことがあります。

確かに、独自ルールで構築されたシステムは属人化するリスクがあります。

しかし、Laravelは世界中で利用されているフレームワークです。

フレームワークとは、開発者ごとの差を減らし、一定のルールに従って開発するための仕組みです。

例えば、

• Route
• Controller
• Model
• Middleware
• Migration

など、それぞれの役割が整理されています。

長年カスタマイズされ続けたWordPressでは、

• functions.php
• 独自プラグイン
• 独自ライブラリ

などが増え、全体像の把握が難しくなるケースもあります。

一方でLaravelでは、一定のお作法に従って開発することで、新しく参加した開発者でも構造を理解しやすくなります。

実際に私たちは、現在もSymfonyベースで構築されたEC-CUBEの運用を担当しています。

当然ながら最初から全てを理解していたわけではありません。

しかしフレームワークとして構造が整理されていたため、想像より短期間で全体像を把握することができました。

重要なのは、スクラッチかどうかではありません。

どれだけ整理された構造で作られているかです。

Flying High Worksの考え方

私たちはLaravelありきのご提案は行っていません。

まずは、「WordPressで実現できるのか」から始まり、その他のCMSの検討を行います。

他のCMSで、無理をして構築すると、複雑化する懸念があったり、未来拡張が前提である場合などに、

• 運用負荷
• 保守性
• 拡張性
• 将来性

を考慮し、Laravelによるスクラッチ開発が適していると判断した場合にご提案しています。

大切なのは、WordPressかLaravelかではありません。

お客様の運用体制や将来の展望に合わせて、無理なく成長できる基盤を選択することです。

私たちは、そのための選択肢のひとつとしてLaravelを活用しています。