ディレクター向けCMS案件の進め方 -WordPress中心-

by ErinaTakei

Slide 1

Slide 1 text

ディレクター向け CMS案件の進め方（WordPress中心） Presentations by SKYGUILD

Slide 2

Slide 2 text

CMSとは

Slide 3

Slide 3 text

CMSとは Contents Management System （コンテンツ・マネジメント・システム）の頭文字をとった略称。 Web制作に必要な専門的な知識が無い人が、HTMLやCSSを編集することなく、管理画面を通じてコンテンツの管理・更新が容易にできるシステムの総称。 CMSは世界中に800以上あり、Webサイトの目的や運用方法に合った特徴を持つ CMSを選定する必要がある。代表的なCMS： Movable Type、WordPress、Drupal、NOREN、WIX

Slide 4

Slide 4 text

◆ 更新頻度が高い・大量にページを制作する特にニュースやイベント、商品ページなどレイアウトをテンプレート化しやすいページがある場合CMS導入に適している ◆ 同じ情報をサイトの複数箇所で表示する一つのコンテンツを更新した際に、複数箇所を編集する必要がある場合、手間がかかる上に、更新漏れなどのミスが発生しやすいが、 CMSを用いれば自動で関連する箇所を同時に更新することができる CMS 導入に向いているサイト

Slide 5

Slide 5 text

◆ クライアントが運用作業を行う必要がある運用を制作会社が行わず、 Webの専門知識が全くないクライアントが担当する場合、CMSは必須と言える ◆ コンテンツ更新に承認や権限の制限の必要がある CMSではアカウントによる権限制限や承認フローを導入することもできるその他に予約公開やバックアップなどの機能もある CMS 導入に向いているサイト

Slide 6

Slide 6 text

◆ デザイン性の高いページを必要とするページごとに全く異なるデザインとなる場合には、テンプレート化しづらく、都度制作する必要がある ◆ ページ数が少なく、更新頻度が低い CMS導入にコストをかけるよりは、必要な際にWeb制作会社が更新を担当する方が効率的 CMS 導入に向いていないサイト

Slide 7

Slide 7 text

CMS案件の流れ 1.　ヒアリング 2.　要件定義～エンジニアの手配～ 3.　CMSの選定 4.　設計 5.　仕様書作成 6.　開発 7.　テスト 8.　マニュアル作成 9.　運用ワイヤーフレーム（サイト構成）作成の段階 ※多少前後したり、省略することもありますある程度デザインが出来てきた段階フロントエンド実装と同時並行か前後どちらのタイミングで進行しても可能

Slide 8

Slide 8 text

ヒアリング

Slide 9

Slide 9 text

ヒアリング ◆ インフラについて・既存サーバを使用するか？新規サーバか？・既存サーバの場合は、使用しているサーバーの種類を確認　→ 動作環境によっては、使用できないCMSも有りうるため要確認・使用可能なSSLを利用できるか？新規に導入可能か？ ◆ 既存サイトについて・既存サイトでCMS を使用しているか？・CMSを変更する、または、バージョンアップは可能か？・既存サイトから移行するコンテンツがあるか？ ※CMSに関連する内容を抜粋 ※その他、制作物の内容等、通常のWebサイト制作時にも必要な内容は省略

Slide 10

Slide 10 text

ヒアリング ◆ その他・多言語対応が必要か？・メルマガシステムやCRM を使用しているか？ CMSとの連携が必要か？　→ 該当する機能を持ったCMSの選定が必要となる ◆ クライアントについて・更新担当者にどの程度のリテラシーがあるか？　→ HTMLの知識がある場合、一部直接 HTMLを編集する更新方法を採用することも出来る　→ ある程度CMS使用経験がある場合は、マニュアルを簡素化することも出来る・コンテンツ毎に担当者の権限を制限する必要があるか？・更新担当者は上長などの承認を得てからコンテンツを公開する必要があるか？　→ 細かな権限分けや承認フローの機能を実装するかを検討する

Slide 11

Slide 11 text

要件定義

Slide 12

Slide 12 text

要件定義 ◆ CMS案件における要件定義 CMSにより更新するコンテンツ、大枠の必要な機能の洗い出しを行ったり、 SEO機能（タイトルやディスクリプション設定、sitemap.xml 等）や、セキュリティ、権限・承認フロー、テスト内容、運用方法、マニュアルの有無などサイトのコンテンツ以外に求められる達成すべき要件を定める。 ◆ 要件定義が不足していると・・・・開発終了後、データ入力を始めた段階で追加機能の要望が大量に・公開後に、セキュリティの脆弱性が見つかった・運用段階になって担当者が代わり、承認フローが必要と判明などトラブルの元となる

Slide 13

Slide 13 text

要件定義 ◆ サイトマップの作成トップ会社概要 404 お問い合わせ（フォーム）お知らせ一覧商品カテゴリ一覧動的ページ静的ページ ※会員機能無しカテゴリ別商品一覧商品詳細お知らせ詳細動的（CMSで更新するコンテンツ）ページ、静的ページを明確にする。フォームが必要なページを確認する。会員機能があるかを確認する。

Slide 14

Slide 14 text

要件定義　　　　　　　　　　　　　　　　　　 ◆ 大まかな機能の洗い出しワイヤーフレーム（サイト構成）を元に、CMSで更新する箇所やフォームの項目、外部サービスとの連携箇所などを確認する。フォームについては、送信された内容を管理画面で閲覧できるようにするか、メールで送信するか、など管理方法も確認する。

Slide 15

Slide 15 text

要件定義 ◆ ワイヤーフレーム（仕様策定）のサンプル・管理画面から登録する項目、最低数・最大数 or 上限なし、0件時に見た目が変わるか、 PDFや動画登録箇所などをわかるようにする・対象のページの登録画面以外でデータ登録し、選択または自動表示するなど連携するデータを明確にしておく

Slide 16

Slide 16 text

要件定義 ◆ 移行コンテンツの確認既存サイトの静的コンテンツ、または、CMSを使用していた場合のデータをどのように移行するかを確認する。・静的コンテンツから CMS 化するものがあるか・独自のシステムが組み込まれている等、 CMS範囲外に設置する必要があるか・インポート & エクスポートによるデータ移行が可能か元のCMS とCMSの種類・データ形式が異なる場合、手動での移行が必要か

Slide 17

Slide 17 text

要件定義 ◆ テスト内容の確認事前にどのようなテスト形式を取るか（体制、種類、チェックリストなど）合意しておくと確認漏れを防げると共に、クライアントへ安心感を与えられる。テストの種類：・単体テスト　-　1 つ 1 つの機能の動作確認・結合テスト　-　機能同士の連携箇所の動作確認・総合テスト　-　CMS全体の動作確認・受入れテスト　-　クライアント環境での動作確認・使用感の確認 ※システム部署などのチェックが厳しい会社は、クライアント側からテスト形式を指定されることもあるので、要望があるか確認する ※予算、クライアント要望、機能の複雑さ等によって、省略や簡易化も検討します。 ※テスト内容の詳しい解説は後述

Slide 18

Slide 18 text

要件定義 ◆ 公開後の対応、運用について公開後にバグ・修正要望が上がった時の対応について合意を得ておく。・瑕疵対応：こちらに非がある場合の修正・改善要望：検証合意済の箇所で、軽度の改善要望・追加要望：事前の要件に含まれない要望・免責事項：外部サービスに起因する等、そもそも対応できない内容 → 期間、無償 or 有償、対応可否を定める。運用に入った際に、クライアントのみで更新するのか、一部または全コンテンツを制作会社が担当するか、制作会社が運用する場合、別会社へ引き継ぎを行うか。マニュアルが必要か、クライアントリテラシーに応じて内容の粒度を決める。

Slide 19

Slide 19 text

要件定義 ◆ その他その他にクライアントに合意を取ると良い項目。 SEO：タイトルやディスクリプションの設定方法、 sitemap.xml の生成についてセキュリティ： CMS上でどのようなセキュリティ対策を取るか権限・ワークフロー、公開手順：アカウントの権限種類、承認機能（ワークフロー）が必要な場合の公開手順ステージング・開発サーバから本番サーバへのデータ移行方法、本番サーバでの公開作業の内容、手順

Slide 20

Slide 20 text

スケジュール作成

Slide 21

Slide 21 text

スケジュール作成 ◆ ポイント・テスト内容やコンテンツ内容、クライアントとの担当分けなどの要件によって、必要なタスクは異なる。・フロントエンド担当・CMS開発担当のリソース状況、または案件の納期によって、実装の順序・進め方は様々なパターンが考えられる。 → エンジニア選定後、相談しながら柔軟に効率的なスケジュールへ調整する ※CMSに関連する実装以降のフェーズを抜粋

Slide 22

Slide 22 text

スケジュール作成 ◆ 例 1：前提・クライアントが全てのコンテンツ入力、運用を担当する・マニュアルが必須・コーディング（フロントエンド）と開発が別会社の担当・機能が少ないため、テストは簡易的に行う・新規サーバを使用・公開後 1 週間は、瑕疵・改善要望に対応する

Slide 23

Slide 23 text

スケジュール作成・コーディングと開発を同時に進め、後から繋ぎこみを行う・テストは自社による「総合テスト」とクライアントの「受け入れテスト」のみ・受け入れテストは、クライアントのコンテンツ入力により実施・コンテンツ入力開始前にマニュアルを納品・新サーバのため、事前に本番サーバをセットアップ

Slide 24

Slide 24 text

スケジュール作成 ◆ 例 2：前提・公開時のコンテンツは制作会社が入力・半分以上のコンテンツは公開後も制作会社が運用・マニュアルは後日、簡易的でよい・コーディング（フロントエンド）と開発は同じ会社が担当・受け入れテスト前に、綿密なテストを実施・既存サーバの既存CMSを使用・追加修正は運用契約の中で対応・瑕疵のみ、公開後 1 ヶ月間無償対応

Slide 25

Slide 25 text

スケジュール作成・コーディングと開発を同時に行い、繋ぎこみも同時に行う・テストは随時完成した機能から「単体テスト」を実施、その後「結合・総合テスト」を実施・制作会社によるコンテンツ入力後にテストアップ、クライアント確認（受け入れテスト）・公開後にマニュアルを納品・既存サーバ及び既存 CMS使用のため、公開時にサイトをメンテナンス表示してから、セットアップを行う

Slide 26

Slide 26 text

CMSの選定

Slide 27

Slide 27 text

CMSの選定 ◆ CMSの種類導入形態によって大きく3 種類に分けられる。それぞれのメリット・デメリットを考慮してCMSを選定する。オープンソース型：プログラムのソースコードが無償で公開されており、商用・非商用問わず、誰でも利用や修正（改変）さらには配布することができる。パッケージ型：ベンダーが独自に開発した CMS ライセンスを購入し、自社サーバにインストールする。クラウド型：ベンダーが管理するサーバにシステムやデータを保管し、インターネット経由で利用する。出典：ビジネスと IT 活用に役立つ情報 https://www.asobou.co.jp/blog/web/cms-type

Slide 28

Slide 28 text

CMSの選定 ◆ オープンソース型のメリット ◆ オープンソース型のデメリット代表的なCMS： WordPress、 Drupal、 Joomla ・ライセンス費用がかからないためコストを抑えることができる・カスタマイズの自由度が高い（ただし、知識やスキルは必要）・プラグイン（拡張機能）が豊富なため、無料で機能拡張や追加に対応できる・バージョンアップのサイクルが早い・日本のみならず世界中にも多くのユーザーがいるため、コミュニティが充実しており、インターネット上にも多くの情報がある・ベンダーからのサポートがないため、自己対応できない場合は外部に委託する必要がある・サーバやドメインは自前で用意し、自らがCMSをサーバにインストールする必要がある・アップデートや不具合対応などは自己責任で対応する必要があり、ある程度の知識を必要とする・ソースコードが開示されているため、脆弱性などを狙った攻撃によるセキュリティリスクがある

Slide 29

Slide 29 text

CMSの選定 ◆ パッケージ型のメリット ◆ パッケージ型のデメリット代表的なCMS：MovableType （商用）、 NOREN、 HeartCore ・ベンダーのサポートを受けられるため安心して運用できる・ベンダーがアップデートや不具合対応などに対応してくれる・承認機能や権限設定など企業や組織での運用に必要な管理機能が備わっている・マニュアルやトレーニングといった運用支援が充実している・初期費用やライセンス利用料が必要となる・導入規模（ページ数やユーザー数）に応じてライセンス費用が大きくなる・プラグイン（機能拡張）に追加費用が発生したり、機能のカスタマイズに工数とコストが発生したりする

Slide 30

Slide 30 text

CMSの選定 ◆ クラウド型のメリット ◆ クラウド型のデメリット代表的なCMS：WIX、 Jimdo、 Weebly ・導入コスト（初期費用）がかからない・CMS の利用料が月額もしくは従量課金制のため、ランニングコストが安い・サーバの準備やソフトウェアの設定をする必要がないため、スピーディーに導入できる・サーバやソフトウェアのメンテナンスコストや手間が発生しない・ベンダー側で勝手にバージョンアップをしてくれる・機能が固定化されているためカスタマイズができない・デザインの自由度に制限がある場合がある・海外で開発されたサービスが多いため、日本語でのサポートが十分に受けられない場合がある・システムやサーバにトラブルが起きた際には、ベンダーの対応に依存してしまう

Slide 31

Slide 31 text

小中規模サイトの受託制作において WordPressが多く採用される・カスタマイズ性が高く、導入コストがかからないため採用しやすい・利用者が多いため、情報が多く、プラグインも豊富なため構築しやすい・規模の小さいコーポレート、ブランド、メディアサイトなどでは、パッケージ型のような複雑な機能を求められることが少ない・会員機能やコメント機能などユーザー投稿の機能をつけることもほとんどないため、高度なセキュリティ対策を求められることもあまりない・PHPベースのため、ほとんどのレンタルサーバで特別な環境構築を必要とせず、簡単にインストールして使用できる

Slide 32

Slide 32 text

エンジニアの選定 CMSの選定が完了し、要件定義が完了したらエンジニアを選定する・ただし、要件が複雑またはディレクターの知識が不十分で、CMS 選定および要件定義が困難な場合には上流工程からエンジニアに参加してもらうのがよい・CMS選定前にエンジニアを選定する場合には、複数種類のCMSの導入実績があり、システム・CMS全般に知識があり、仕様策定の経験も豊富なエンジニアを選択する・CMS決定後に選定する場合には、採用した CMSが得意で、似たサイトへの導入実績が豊富なエンジニアを選択する ※自社オリジナルのCMSを採用している開発会社もあるが、他社への引き継ぎが困難で、依存性が高く、運用コストもかかるため、長期に運用するサイトにはあまりおすすめできない

Slide 33

Slide 33 text

WordPressの基礎知識

Slide 34

Slide 34 text

WordPressの基礎知識 ◆ WordPressの仕組み管理画面 WordPressの管理画面から、記事（ページ）を作成して保存すると、画像や PDF ファイルはサーバにアップロードされ、記事タイトル・本文等のデータは、サーバ内のデータベースに保存されるデータベースサーバー記事タイトル本文カテゴリー・タグ作者、公開日時など… 記事を作成・保存画像やPDFファイルなどアップロード保管

Slide 35

Slide 35 text

WordPressの基礎知識 ◆ WordPressの仕組みサーバー・データベースからファイルやデータを読み込み、テーマ（テンプレート）によって表示する内容や見た目が決まり、 Webページとして表示される同じ記事のデータでも、テーマを変えることで表示内容や見た目を変えられる →主にテーマをカスタマイズすることで、オリジナルのサイトを制作していくデータベーステーマ A テーマB サーバーファイルやデータを読み込み

Slide 36

Slide 36 text

WordPressの基礎知識 ◆ サイトをカスタマイズするための3つの”カスタム”機能 ◆ カスタムフィールド WordPress標準の機能を用いて、ブログ機能程度のサイトを構築することはできるものの、より高度にコンテンツを管理する仕組みを構築するには、“カスタム” 機能が必要となる。タイトルや本文とは別にオリジナルの入力欄を追加できる機能。本文だけでは入力が面倒だったり、他のページに表示するキャッチコピーなどのテキストは、入力欄を別に設けることで利便性が一段と向上する。必須チェックや、日時や色、地図の挿入など便利な入力欄を追加することができる。

Slide 37

Slide 37 text

WordPressの基礎知識 ◆ カスタム投稿タイプ標準で備わっている「投稿」のメニュー以外に「お知らせ」「イベント」「よくある質問」などオリジナルのメニューを作成できる機能。カスタムフィールドと組み合わせることで、メニュー毎に別々の入力欄を設定できる。

Slide 38

Slide 38 text

WordPressの基礎知識 ◆ カスタムタクソノミー標準で備わっている「カテゴリー」「タグ」以外にオリジナルの分類を作成できる機能。複数のカテゴリーで分類するのに通常の「カテゴリー」だけでは使いづらい、カスタム投稿タイプ毎にカテゴリーを分けたい、といった際に利用する。

Slide 39

Slide 39 text

新エディタの大きな変更点 Wordpress5系のバージョンから採用された新エディタ「Gutenberg（グーテンベルグ）」は、従来のエディタ「クラシックエディター（ウィジウィグエディタ）」と大きく使用感が異なる。クライアントが従来のエディタを使い慣れている場合、最新バージョンを導入するか、従来のエディタを採用するかは、要望を聞きながら要検討。開発方法も多少異なるため、エンジニアにも最新版で対応が可能か、実績があるか確認する。従来のエディタ 1つの入力欄の中にテキストを入力し、「見出し」「段落」などのスタイルを選択「見出し」「段落」などを選択して1 つ 1 つの入力欄を追加し文字を入力、必要な項目を積み上げていく新エディタ（ブロックエディタとも呼ぶ）

Slide 40

Slide 40 text

設計

Slide 41

Slide 41 text

設計要件定義の仕様策定で不足している細かい必要入力項目や条件を定義する入力画面ごとに項目をまとめていく・表示される箇所・必須／任意・未入力時の表示や代替メッセージ・入力欄の種類・選択するデータの参照先・並び順の制御方法・入力制限（文字数、形式）・連携先のデータが 0 件の時の表示 ※WordPress の場合は、どのカスタム投稿タイプやカスタムタクソノミーを使用しているか、カスタムフィールドの種類などを定義しておくと良い

Slide 42

Slide 42 text

開発／テスト

Slide 43

Slide 43 text

開発／テスト設計内容を元に開発指示、テスト仕様書を作成してテストを実施する入力画面ごと、連携箇所ごとにテスト内容をまとめていく・必須項目、入力制限チェックのエラーが表示されるか・全データ入力後に正しく表示されるか・任意データ未入力時に意図した挙動となるか・連携箇所にデータが表示されるか・件数や文字数の増減により意図した挙動となるかなど

Slide 44

Slide 44 text

インフラ／セキュリティ

Slide 45

Slide 45 text

インフラ ◆ インフラとは ◆ インフラの重要性 ITの分野においては、情報システムを稼働・運用するための土台となるコンピュータなどの機材や設備、それらを設置する施設、機器・施設間を結ぶ通信回線やネットワーク、サーバ、ソフトウェア、データなどの総称。一般的な用語と区別して「ITインフラ」とも言う。 Webサイトは紙媒体と違い、デザインやコーディングのちょっとしたミスは速やかに修正できる場合が多い。その代わりに、ネットワークやサーバのトラブルが発生すると一切サイトの情報にアクセスできなくなるため、重大な損失に繋がる可能性もある。さらに高度な専門知識を必要とするため、社内にインフラ専任担当がいない場合には、基本的に外部の専門業者に委託することが望ましい。

Slide 46

Slide 46 text

インフラ ◆ 特に気をつけるケース・大量のアクセスが見込まれるサイト　そもそもアクセス数が多い、キャンペーンや広告で瞬間的にアクセスが集中する、といった　案件はネットワークやサーバのスペックを十分に備える必要がある。・サーバやシステム停止が即座に金銭的損害に繋がるサイト　広告、キャンペーン、販売、サービスなどに関連するサイトは特に、数分間サイトにアクセス　できなかっただけでも金銭的損害が発生し得る。障害が長時間に及ぶほど大損害となる。　そのため、サイトにアクセスできなくなった時に即座に知らせる「死活監視」や、同じ機能を　持つサーバーなどの機器を複数用意して、障害発生時に自動で切り替える「冗長化」などの　対策が必要となる。 → いずれも具体的な内容はインフラ担当者と相談する

Slide 47

Slide 47 text

インフラ ◆ CMSに関連する確認点 ◆ 責任の所在の明確化・PHPが動作するか？バージョンは？　（CMSの種類によっては PHP 以外が必要となるので適宜確認）・データベース環境が用意されているか？　（MySQLを使用することが多いが、CMS の種類によっては異なるため適宜確認）・SSLが導入されているか？クライアント側にシステム担当者がいる、または、インフラの専門業者が担当している場合、自社に編集の権限があっても「極力インストールや設定変更などを行わない」ことで責任の所在を明確にすることが重要。もし自社で対応する場合には、編集したファイルや作業内容を細かく記録して報告しておくことで、それ以外の場所には責任がないことを明確にする。

Slide 48

Slide 48 text

セキュリティ ◆ CMS導入時に確認するセキュリティのポイント・SSLが導入されているか？　SSL とはブラウザとサーバ間でのデータの通信を暗号化し、送受信させる仕組みのこと。　会員情報やECで住所や請求情報などを扱う場合には特に重要。・アクセスログを取っているか？　管理画面へのログイン履歴、操作履歴のログを取っておくと、不正アクセスにすぐに気づく　ことができ、不正にアクセスされた内容を把握しやすい。・パーミッションやアクセス制限が適切か？　パーミッションとはファイルのアクセス権のことであり、編集の必要がなかったり、外部から　見られたくないファイルには制限を設けておくことが重要。　管理画面にベーシック認証やIPアドレスでアクセス制限をする事も不正アクセス対策となる。　ログイン画面に画像認証を設けたり、 WordPressにおいてはデフォルトのユーザや管理画面　のURLを変更することも有効である。

Slide 49

Slide 49 text

まとめ

Slide 50

Slide 50 text

まとめ・システム案件において、クライアントからのヒアリング、要件策定時の　合意をきちんと行うことが重要・予算やクライアントリテラシー、機能やページ量を考慮して、各フローで　どこまで厳密に対応するか、最適な手順・内容を検討する・エンジニアとの円滑なコミュニケーション、品質担保のためにも、　各種仕様書の取りまとめが重要・各CMSの特性を把握し、最適なCMSを選択する・WordPressの基本的な仕組みを理解することで、仕様策定・エンジニアと　コミュニケーションがスムーズになる・インフラやセキュリティは、最低限のポイントを理解しつつ、専門家に　依頼・責任の所在を明確化する

Slide 51

Slide 51 text

ディレクター向けCMS案件の進め方（WordPress中心）ご静聴ありがとうございました。 Presentations by SKYGUILD