CMS要件定義。後になって「しまった！」とならないために。【webディレクター向け】
たぐと申します。
東京のweb制作会社でプロデューサーをしています。
今回は、CMSの要件定義について考えます。
CMSと一言で言っても
スクラッチ開発
パッケージ利用
と様々。
CMSを使ったwebサイトにおいて、
CMSの要件定義をどのように進めるのが良さげか、何を押さえるべきか、ということをまとめてみようと思います。
ちなみに、先日次のようなツイートをしました。
CMSの非機能要件、もっと目をむける必要があると実案件で感じた。
— たぐ@webプロデューサー (@tagtaz74) December 27, 2020
・表示スピード
・セキュリティ
・再構築スピード
・バックアップ
・データ移行
要件定義時、機能設計の方に目が行きがちだが、クライアントの現場の人が気にするのは、意外と非機能の方だったり。
機能要件もそうですが、
- 表示スピード
- セキュリティ
- 再構築スピード
- バックアップ
- データ移行
こういった非機能要件にも目を向ける必要がありますからね。
webディレクターの方、企業側のwebサイト運用担当者の方の参考になれば幸いです。
求める要件を精査し、最初に擦り合わせることが大事。
今回の結論は、
webサイトの運用担当者がCMSに何を求めているのかを洗い出す。
その上で、機能面、非機能面両面で最適なものを定義すべき。
という話です
webサイトのリニューアル提案では、トップページのデザインや、検索キーワードを踏まえた集客の話など、フロントサイドの設計には、きちんと触れられているが、CMSでどういう管理ができるか、安全快適な運用ができるか、といった裏側の仕組みには、触れられていないことが、多いと感じます。
もちろん、提案段階で、そこまでのことは詰められないということはわかります。しかし、クライアントの担当者が最も向き合うことが多いであろう、コンテンツの管理部分には、何かしら安心感を与える情報の断片は必要なのではないかと思います。
そしてweb制作会社からのCMS部分の提案というと、
このCMSを使いましょう。セキュリティ的に安心なのでご安心ください。
みたいな、CMSの選定とその機能一覧を提示するだけになっていないでしょうか。
CMSは、企業の情報発信の根幹をなすものになっており、そのCMSを操作して、管理するのは、webサイトオーナーである企業担当者です。
実際にサイトを公開し、webサイトの運用フェーズになってはじめて「あれがない」「これが不便」にならないように、CMSを新規導入したり、リプレイスすることで何が変わるのか、明確にしておくことを強くお勧めします。
CMSの要件定義で押さえておくべきことの具体例
私がこれまでCMSのテンプレート開発に携わってきて、特に確認が必要と思うのは次のようなものです。
※網羅出来ているわけではありませんが、チェックリストとしてお使いいただくことはできるかと思います。
私がCMSの要件定義に関わってきた中で押さえておいた方が良さそうなもの、また、Wordpressや、PowerCMS、WebRelease2などの有名CMSのオンラインマニュアルなども参考にしています。
内容としては、機能要件、非機能要件に当たるものです。
ちなみに、webサイトの機能要件、非機能要件とは何か、については以前記事にしているのでよろしければそちらも参照ください。
もちろん全部について、定義をする必要はないですが、後になって、確認しておけば良かった、ということにならないよう、活用ください。
1. 機能要件
それでは、まず、機能要件について見てみましょう。
それなりに数がありますね。
環境管理、公開管理、ページ管理の3つに分けて紹介してみます。
1. 環境管理
- 本番・ステージング環境のデータ同期機能
- プラグインによる機能拡張
- 管理者権限管理
- 複数サイト管理機能
- 履歴管理、ロールバック機能
2. 公開管理
- 多段承認フロー
- 承認メール通知
- 予約公開有無
- 公開連動ページ管理
- ページデータのエクスポート・インポート機能
- 一時保存機能
- ページプレビュー機能
- ページプレビュー共有機能
3. ページ管理
- コンポーネント管理機能
- コンポーネント順序入れ替え機能
- WYSIWYGエディタ機能・HTML編集機能
- エラーページ定義
- SEO機能
- SNS連携機能
- ウィジェット機能
- お問い合わせフォーム作成管理
- 最新記事表示
- 柔軟なフロントエンドテンプレート開発
- タグ付け機能
- レコメンド機能
- ページの一括編集機能
- データの一括読み込み機能
- ページの複製機能
- リダイレクト機能
- SEO機能
- URLの個別設定
- サイト内検索機能
- 多言語対応
- ページング自動生成
- ぱんくず自動生成
- アクセスログ分析機能
- 表現の揺らぎチェック機能
- リンクチェック機能
- 他のCMSからのデータインポート機能
2. 非機能要件
次に非機能要件です。
こちらは、挙げている項目数は少ないですが、それぞれについてどのような定義をするかは、プロジェクト個別で大きく差が出るところです。
- 同時アクセス数（フロント）
- 同時アクセス数（管理画面）
- ページ作成時間（更新スピード、再構築時間有無）
- 冗長性
- セキュリティ
- マニュアル
- 運用サポート
- セキュリティアップデート
- バージョンアップ対応
１つ例を挙げます。
静的CMSであれば、ページの再構築というステップが入るわけですが、再構築を開始してから完了までにはある程度時間が掛かります。
数千ページとかの大規模サイトであれば、5分、10分と掛かることだってあるでしょう。
そういう時、どの程度の時間なら許容できるか、許容出来ない時間がかかりそうな場合にどうするのか定義が必要です。
この辺の話は、CMSのテンプレートの開発が終わり、いざデータ投入するという段階になって初めて顕在化したりする問題です。
セキュリティやバックアップ、災害発生時のリカバリ的なこともそうですね。機能とは言えないが、何をどこまで担保するのか、という点で、非機能要件の定義は、機能要件の定義よりも難しいと思った方が良いです。
CMSの要件を大きいレベルで押さえておくことが重要。
今回は、webサイトの制作者は
webサイトの運用担当者がCMSに何を求めているのかを洗い出す。
その上で、機能面、非機能面両面で最適なものを定義すべき。
という内容についてお話ししました。
CMSの機能要件、非機能要件について、web制作会社側は、システム会社と連携して対応することが多く、クライアントとの窓口に立つ、web制作会社は、裏側の仕組みについて、明確に説明出来ていないことが多いように感じています。
もちろん、機能要件、非機能要件について、プロジェクトの初期段階で完璧に定義することは難しいでしょう。
ただ、
ここはこういう想定ですよ。
こういう可能性はありますよ。
CMSで出来ることのポイントはここですよ。
逆にこういうことは出来ないと思ってくださいね。
そういう、大きいレベルでの押さえは必要だと思うのです。
後になって、「イメージと違う」「運用しにくい」とならないように。。
大枠部分から定義して押さえておく、ということをお勧めしたいです。
以上でーす。
