Webサイトの目的や対象範囲を整理した後は、その希望を実装・運用可能な条件へ変換します。この工程がシステム要件定義です。ニュースを更新できる、フォームを設置できるといった機能だけでなく、誰が使うのか、どのように承認するのか、障害や脆弱性へ誰が対応するのかまで整理します。

 

システム要件を細かくしすぎると、実際には使わない機能のために費用と期間が膨らみます。一方で、非機能要件を曖昧にすると、公開後にセキュリティ、性能、バックアップ、保守の責任範囲で問題が起こります。重要なのは、自社固有で定義する条件と、CMS・クラウドサービスの標準仕様を活用できる条件を分けることです。

結論｜機能要件と非機能要件の違い
機能要件は「利用者がWebサイトやCMSで何をできる必要があるか」、非機能要件は「その機能をどの品質・安全性・運用条件で提供するか」です。両方を、利用者・利用頻度・責任者・確認方法と合わせて整理します。

この記事のポイント

  • システム要件定義では、業務上の希望を実装・運用で判断できる表現へ変換する
  • 機能要件は機能名だけでなく、利用者、頻度、データ、権限、優先度を記載する
  • 非機能要件はセキュリティ、性能、可用性、バックアップ、保守、アクセシビリティなどを扱う
  • SaaS型CMSではサービス標準を確認し、自社固有の要件へ集中する

INDEX

システム要件定義とは

システム要件定義とは、業務要件やサイト要件を、システムとして実現できる条件へ落とし込む工程です。たとえば「各部門が迅速に情報を公開したい」という要望は、部門別権限、公開申請、承認通知、予約公開、操作履歴、緊急公開フローなどの要件に分解できます。

 

Webサイトでは、CMSだけでなく、サーバー、CDN、WAF、フォーム、検索、アクセス解析、外部サービス、ドメイン・DNSなど複数の仕組みが関係します。各要件について、どのサービスが担い、誰が運用し、障害時にどこへ連絡するかを明確にします。

機能要件と非機能要件の違い

区分

定義

Webサイトでの例

機能要件

利用者や管理者が実行できる必要がある処理・機能

ページ作成、ニュース、検索、フォーム、権限、承認、公開予約、多言語、外部連携

非機能要件

機能を提供する際に満たす品質、性能、安全性、運用条件

セキュリティ、表示速度、可用性、バックアップ、ログ、アクセシビリティ、保守、サポート

移行・運用要件

現行環境から切り替え、公開後に継続運用する条件

コンテンツ移行、URL・リダイレクト、テスト、アカウント管理、研修、問い合わせ窓口

Webサイトの主な機能要件

領域

確認する要件

具体化する質問

ページ管理

ページ作成、複製、下書き、プレビュー、予約公開、履歴

誰がどのページを作るか。自由ページと定型ページをどう分けるか。

ニュース・IR

カテゴリ、年度、絞り込み、PDF、TDnet等の外部連携

どの部門が、どの頻度で、どの形式の情報を公開するか。

権限・承認

部門別権限、編集範囲、申請、承認、差し戻し、複数承認者

通常更新と緊急更新の承認者は誰か。サイトを跨ぐ管理者が必要か。

ナビ・リンク

グローバルナビ、パンくず、サイトマップ、リンク切れ管理

ページ追加・移動時にどこまで自動反映させたいか。

検索

全文検索、カテゴリ絞り込み、サジェスト、PDF検索

検索対象、絞り込み軸、除外コンテンツ、検索ログをどう扱うか。

フォーム

問い合わせ、資料請求、応募、確認メール、スパム対策

個人情報をどこへ保存・連携し、誰が閲覧するか。

多言語

言語別ページ、翻訳管理、言語切替、公開タイミング

翻訳は誰が行い、日本語と同時公開するか。URL構造はどうするか。

外部連携

MA、CRM、採用管理、IR配信、認証、API

連携方向、データ項目、頻度、エラー時の対応をどうするか。

計測・SEO

タグ管理、アクセス解析、メタ情報、構造化データ、サイトマップ

誰が設定を管理し、公開前後に何を検証するか。

Webサイトの主な非機能要件

領域

確認項目

確認例

セキュリティ

通信暗号化、WAF、脆弱性対応、改ざん検知、アカウント保護

CMS・サーバー・周辺ソフトの脆弱性対応主体と期限は明確か。

可用性・障害対応

稼働監視、冗長化、障害通知、復旧目標、緊急連絡

障害検知後の連絡先、一次対応、復旧・報告の流れはどうなるか。

性能

表示速度、同時アクセス、キャッシュ、画像最適化

通常時・アクセス集中時の想定と、測定方法を定めているか。

バックアップ

対象、頻度、保存期間、復元方法、復元テスト

コンテンツ、設定、フォームデータをどの時点まで戻せるか。

ログ・監査

操作ログ、アクセスログ、保管期間、閲覧権限

誰がいつ何を変更したか確認できるか。監査時に提出できるか。

アクセシビリティ

目標水準、対象ページ、制作・検査方法

JIS・WCAG等の基準、検査範囲、公開後の維持方法をどうするか。

SEO移行

URL維持、301、タイトル・メタ、構造化データ、サイトマップ

流入ページを保全し、公開後にエラー・順位変動を確認するか。

保守・サポート

問い合わせ窓口、受付時間、アップデート、設定変更、改善支援

CMSとサーバーの窓口が分かれるか。追加費用が発生する範囲はどこか。

データ管理

保存場所、個人情報、エクスポート、契約終了時の取り扱い

データを取り出せるか。削除・返却の手順が契約に明記されるか。

要件を具体化する書き方

「承認機能が必要」「セキュリティを高くする」だけでは、提案を比較できません。要件は、主体、対象、条件、結果、確認方法を含む文章にします。

曖昧な要件

具体化した要件

承認フローが必要

IR部門の編集者が公開申請し、IR責任者と広報責任者の承認後、指定日時に公開できること。差し戻し理由と操作履歴を確認できること。

検索を使いやすくする

HTMLページとPDFを検索対象とし、カテゴリ・年度で絞り込めること。検索結果ゼロ件と主要検索語を解析できること。

セキュリティを強化する

CMS・サーバーの脆弱性情報を監視し、対応主体と対応方針を明示すること。管理画面は権限管理と安全な認証方式に対応すること。

表示を速くする

主要テンプレートを対象に、公開環境で性能を測定し、画像・スクリプトを最適化すること。目標値と測定条件は設計時に合意すること。

標準機能・設定・個別開発を切り分ける

対応区分

意味

選定時の確認

標準機能

契約範囲内でそのまま利用できる

追加費用、利用制限、アップデート時の互換性

設定・運用設計

管理画面の設定や運用ルールで実現する

設定担当、変更権限、マニュアル、引き継ぎ

外部サービス連携

フォーム、検索、MAなど別サービスを組み合わせる

契約主体、データ連携、障害時の責任分界、費用

個別開発

標準にない機能を独自に実装する

初期費用、保守、アップデート影響、開発会社への依存

代替・対象外

別の業務方法へ変える、または今回は実施しない

利用者への影響、次フェーズ、代替手順

CMS比較では、対応可否だけでなく、どの区分で対応するかを確認してください。同じ「対応可能」でも、標準機能と個別開発では、費用、導入期間、保守負荷、将来のアップデート対応が異なります。

SaaS型CMSで確認する責任分界

領域

CMS・サービス提供者へ確認

自社で決める

CMS・基盤

アップデート、監視、バックアップ、障害対応、標準セキュリティ

利用ルール、アカウント責任者、社内エスカレーション

コンテンツ運用

標準ワークフロー、権限範囲、公開・履歴機能

編集者、承認者、緊急公開、原稿責任

外部連携

API・連携可否、標準サービス、保守範囲

連携データ、業務責任、個人情報の扱い

移行

移行支援範囲、ツール、テスト方法

移行対象、削除判断、URL方針、原稿確定

サポート

窓口、受付、対応範囲、追加対応の条件

問い合わせ担当、社内一次窓口、改善体制

ShareWithの場合

ShareWithは、CMS、サーバー・セキュリティ、サポートを一体で提供するクラウドCMSです。

システム要件定義では、これらを個別に構築する前提ではなく、標準で提供される範囲と自社の運用を照合します。たとえば、編集者・承認者の役割、複数サイトを跨ぐ管理、公開予約、既存デザイン・コンテンツ移行、外部フォーム・検索の扱いを具体的なシナリオで確認します。

標準サービスに含まれない外部連携や特殊機能がある場合は、連携方法、責任分界、障害時の窓口、追加費用を個別に確認します。

システム要件定義チェックリスト

  • 各機能の利用者、利用頻度、対象サイト、必要な理由が明記されている
  • 権限、承認、公開、緊急更新の業務フローがある
  • 標準機能、設定、外部連携、個別開発を区分している
  • セキュリティと保守の責任分界が明確である
  • 性能、可用性、バックアップ、ログの確認方法がある
  • アクセシビリティとSEO移行の条件が含まれている
  • フォーム・個人情報・外部連携のデータフローが整理されている
  • 移行対象、URL、リダイレクト、テストの要件がある
  • 要件ごとに優先度と受入確認方法が設定されている
  • 契約終了時のデータ取り扱いとエクスポート条件を確認している

よくある質問

  • 機能要件と業務要件はどう違いますか？

    業務要件は、業務上実現したい状態です。機能要件は、その状態を実現するためにシステムが提供する機能です。「複数部門が安全に更新する」が業務要件、「部門別権限と承認フロー」が機能要件です。

  • 非機能要件は誰が決めますか？

    Web担当だけでなく、情報システム、セキュリティ、法務・個人情報、アクセシビリティ担当などと確認します。CMS・クラウドサービスの標準仕様も踏まえ、過不足のない水準を決めます。

  • すべて数値で要件を定義する必要がありますか？

    必ずしも必要ではありません。数値化できない段階では、適用する基準、対象範囲、確認方法、責任者を定めます。提案を受けて現実的な目標値を確定する方法もあります。

  • SaaS型CMSでは非機能要件を確認しなくてもよいですか？

    確認は必要です。サービス側が担う範囲が広いからこそ、標準仕様、SLA、セキュリティ対策、バックアップ、障害対応、サポート、データ取り扱いを確認し、自社側の責任と分けます。

まとめ

Webサイトのシステム要件定義では、機能の有無だけでなく、誰がどのように利用し、どの品質と責任分界で運用するかを整理します。機能要件、非機能要件、移行・運用要件を一体で考えることが重要です。

 

SaaS型CMSを利用する場合は、サービス標準で対応できる領域と、自社固有で定義する領域を分けます。標準機能を活かしながら、権限、承認、コンテンツ、外部連携、移行など、実際の運用に直結する要件へ時間を使うと、過剰な個別開発を抑えやすくなります。