拡張性　コンテンツとシステムの分離について

Webアプリケーションを開発する際には、画面をいくつかの「パーツ」に分けて、それぞれをCMS（コンテンツ管理システム）を通じて表示する方法があります。
この仕組みによって、 一部のパーツは非エンジニアでも自由に編集できる ようにしつつ、 システムに関わる重要なパーツはエンジニアのみが操作できるように制限 することが可能になります。
こうした権限の分け方をしておけば、誤って非エンジニアがシステムに影響する部分を変更してしまうリスクを防ぐことができます。
たとえば、最近主流のReactやNext.jsなどのフレームワークを使ったWeb開発（CMSなし）でも、画面の部品（パーツ）ごとに分けて開発することはできますが、 「誰がどこまで操作できるか」をシステム上で明確に区切ることは難しい のが実情です。特に、セキュリティが重要なシステムや大規模なシステムでは、編集してはいけない部分を誤って触ってしまうリスクが高まりやすく、 見た目だけの変更であっても、結局エンジニアの対応が必要になってしまう ケースが多くなります。
このような背景からも、 システムとコンテンツをきちんと分けて設計することは、運用や拡張性の面で非常に有効な方針 になります。

Webアプリケーションの拡張性実現するには

システムのパーツ化

システムの可読性を上げ、拡張性を上げる基本的な方針として、意味ある単位でまとまりを作りパーツ化することが重要です。パーツにすることで、再利用が可能であったり、ソースコードの内容を理解するうえでもパーツ単位で大まかな理解ができるため、メリットが大きいです。

パーツ化のメリット

項目	内容
可読性・理解のしやすさ	単機能に分離されていれば、パーツ単位での構造把握が容易になります。
再利用性の向上	汎用的な処理（UI部品・APIロジックなど）を複数の場所で再利用できます。
保守性・修正のしやすさ	修正対象が明確になるため、影響範囲を限定できます。
担当者ごとの分業が可能	パーツ単位で開発・テストができるため、チーム開発が効率化されます。
テストの効率化	単体テストをパーツ単位で行いやすくなります。
将来の拡張・入替が容易	特定パーツのみ差し替えることで機能の改善やリニューアルが可能になります。
権限設計・運用管理がしやすい（CMSなどと連動）	非エンジニア編集可能な部分と、技術者のみが触れるべき部分を分離できます。

パーツ化のデメリット

項目	内容
過度な分割で逆に複雑化する	「細かすぎるパーツ化」は依存関係が複雑になり、把握が困難になります。【解決策】適切なサイズのパーツ化
パーツ間のインターフェース管理が必要	データの受け渡しや依存関係の設計が雑だとバグや仕様漏れが起きやすいです。【解決策】インターフェースの標準化
境界が曖昧になると責任の所在が不明に	どのパーツが何を担うのかが不明確だと、改修時の混乱を招きます。【解決策】パーツ分離の明確なルールの設定
ドキュメントや命名ルールの整備が不可欠	パーツごとの役割や使い方が明示されていないと、再利用や引継ぎが困難です。【解決策】ルールの整備の徹底
初期設計のコストが高い	パーツ設計をきちんと行うには、時間と設計スキルが必要です。【解決策】経験を含めて、ノウハウを標準化して効率化
テストやバージョン管理が煩雑になる	多数のパーツが並行で更新されると、整合性を保つのが難しくなります。【解決策】テストの自動化やツールの活用

画面とロジックの分離

Webアプリケーションの拡張性を上げるのに、画面とロジックの分離が重要である。MVCやMVのようなフレームワークもあるように、画面とロジックの分離を採用しているフレームワークが多いです。これは様々なメリットにつながります。

画面とロジック分離のメリット

役割・責任の分離：画面とデータ処理などが分離され、修正する際にも読むコード量が減り、保守性が上がります。
再利用性の向上：同じような処理や画面がある場合、使いまわしができます。
チーム開発が可能：フロントエンドとバックエンドの役割分担が容易になります。

フロントエンドとバックエンドの観点の違い

フロントエンド開発とバックエンド開発が分離できることは効率性を生みます。これは、フロントエンド開発とバックエンド開発の考える観点や考慮すべきポイントが異なるためです。

フロントエンド vs バックエンド：考慮すべきポイントの違い

項目	フロントエンド開発者の観点	バックエンド開発者の観点
主な関心領域	画面の表示、操作性、ユーザー体験	データの処理、保存、整合性
対象技術	HTML / CSS / JavaScript / React / Vue	DB設計 / REST・GraphQL・SOAP/バッチ処理 /認証・セッション
重視すること	UIのわかりやすさ、レスポンスの速さ、レスポンシブ対応	正確なデータ処理、セキュリティ、パフォーマンス、スケーラビリティ
主な課題	デザインとの調整、ブラウザ間対応、UXテスト	複雑なビジネスロジック、データ整合性、負荷耐性
セキュリティ意識	入力バリデーション（XSSなど）、表示の安全性	認証・認可、SQLインジェクション、API認可
パフォーマンス	表示の高速化、通信の最適化、画像圧縮	データベースの最適化、キャッシュ、処理分散
テスト観点	UIテスト、E2Eテスト、アクセシビリティ	単体テスト、統合テスト、APIレスポンス検証

画面とロジックを分離して、パーツ化すること

Webアプリケーションの拡張性を上げるのに、画面とロジックの分離をして、それぞれパーツ化していくことが重要です。
ただし、これを高いレベルで実現することは難しく技術的な負荷が高いです。

そこでCMSを用いたWebアプリケーション開発をすることで、これらを実現することにつながります。CMS開発とは、「画面の中で、利用頻度が高い単位を見抜き、パーツ化すること」にあります。これを突き詰めることで、画面のパーツ化ができるとともに、CMSに乗らないロジック部分もCMSから分離されることになります。結果、CMSを利用したWebアプリケーション開発は、結果、拡張性が高いシステムを実現することにつながります。

注意点として、すべてにおいて拡張性を維持することは初期コストを大きくしていくことになるため、改修頻度が小さいならば、必ずしもパーツ化しなくてもよいです。この判断には正しい予測、経験則が必要になります。

中長期で利用するWebアプリケーションはパーツ化が必須

改修頻度も高くなく、重要度も高くないシステムあれば、拡張性を担保する必要がありません。しかし、そのアプリケーションのUIUXが顧客満足度に直結したり、会社の重要な競争要因になりえるウェブアプリケーションであるならば、それらの拡張性を担保することは企業戦略上においても重要な取り組みになります。

システムとコンテンツ分離のメリット

CMSを用いたWebアプリケーション開発は、システムとコンテンツの分離をより少ない工数で実現することができ、運用性や拡張性を向上することにつながります。

一般的に、本内容はヘッドレスCMSでよく謳われている内容ですが、本来ヘッドレスCMSかどうかは関係ありません。CMSにおいてAPIベースで作られているCMSは、ヘッドレスCMSであれ、ヘッドフルCMSであれ、同様のメリットを受けることが可能ですが、本内容が実現できないヘッドフルCMSが存在するので注意が必要です。
LYZONで取り扱いの多いSitecoreは、ヘッドレスとヘッドフルの共存ができるCMSのため、状況に合わせて使い分けます。LYZONでは、Sitecoreだけでなく、ContentfulなどののヘッドレスCMSの開発案件も多数進めているため、ケースに応じた使い分けが可能です。

CMSを基盤とした Webアプリケーション開発	CMS無しの Webアプリケーション開発
非エンジニアとエンジニアのシステム的な分離が可能なため、運用効率・改修効率が大幅に向上	フロントエンジニアとバックエンジニアの分離が一部可能なため、改修効率が向上
非エンジニアがCMSを用いた効率的な運用が可能（運用コストの削減が可能）	HTMLやJSの知識がある人材が運用する必要がある
非エンジニアとエンジニアの変更領域をシステム的に制御（システムの改修トラブルが減少）	非エンジニアとエンジニアの変更領域を人的にしか制御できない
コンテンツ改修時にプログラムファイルのデプロイが不要（リリースの工数が大幅に減り、運用スピードも大幅に向上）	コンテンツ改修時にプログラムファイルのデプロイが必要

まとめ

拡張性を実現するために、パーツ化、表示と見た目の分離は非常に重要なテーマであり、それらを費用対効果高く実現する方法の1つとして、CMSを用いたWebアプリケーション開発があります。特に非エンジニアが編集できる領域を増やしたいのであれば、これらはとても有効な方法であり、自分たちが作るシステムの今とこれからを正しく予測してシステム開発を進めることが重要です。