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

Transcript

1. ディレクター向け CMS案件の進め方 （WordPress中心） Presentations by SKYGUILD
2. CMSとは
3. CMSとは Contents Management System （コンテンツ・マネジメント・システム） の頭文字をとった略称。 Web制作に必要な専門的な知識が無い人が、HTMLやCSSを編集すること なく、管理画面を通じてコンテンツの管理・更新が容易にできるシステム の総称。 CMSは世界中に800以上あり、Webサイトの目的や運用方法に合った特徴 を持つ CMSを選定する必要がある。 代表的なCMS： Movable Type、WordPress、Drupal、NOREN、WIX
4. ◆ 更新頻度が高い・大量にページを制作する 特にニュースやイベント、商品ページなどレイアウトをテンプレート化 しやすいページがある場合CMS導入に適している ◆ 同じ情報をサイトの複数箇所で表示する 一つのコンテンツを更新した際に、複数箇所を編集する必要がある場合、 手間がかかる上に、更新漏れなどのミスが発生しやすいが、 CMSを用いれば自動で関連する箇所を同時に更新することができる CMS 導入に向いているサイト
5. ◆ クライアントが運用作業を行う必要がある 運用を制作会社が行わず、 Webの専門知識が全くないクライアントが担当 する場合、CMSは必須と言える ◆ コンテンツ更新に承認や権限の制限の必要がある CMSではアカウントによる権限制限や承認フローを導入することもできる その他に予約公開やバックアップなどの機能もある CMS 導入に向いているサイト
6. ◆ デザイン性の高いページを必要とする ページごとに全く異なるデザインとなる場合には、テンプレート化しづらく、 都度制作する必要がある ◆ ページ数が少なく、 更新頻度が低い CMS導入にコストをかけるよりは、必要な際にWeb制作会社が更新を担当 する方が効率的 CMS 導入に向いていないサイト
7. CMS案件の流れ 1.　ヒアリング 2.　要件定義 ～エンジニアの手配～ 3.　CMSの選定 4.　設計 5.　仕様書作成 6.　開発 7.　テスト 8.　マニュアル作成 9.　運用 ワイヤーフレーム（サイト構成）作成の段階 ※多少前後したり、省略することもあります ある程度デザインが出来てきた段階 フロントエンド実装と同時並行か 前後どちらのタイミングで進行しても可能
8. ヒアリング
9. ヒアリング ◆ インフラについて ・既存サーバを使用するか？新規サーバか？ ・既存サーバの場合は、使用しているサーバーの種類を確認 　→ 動作環境によっては、 使用できないCMSも有りうるため要確認 ・使用可能なSSLを利用できるか？新規に導入可能か？ ◆ 既存サイトについて ・既存サイトでCMS を使用しているか？ ・CMSを変更する、 または、バージョンアップは可能か？ ・既存サイトから移行するコンテンツがあるか？ ※CMSに関連する内容を抜粋 ※その他、制作物の内容等、通常のWebサイト制作時にも必要な内容は省略
10. ヒアリング ◆ その他 ・多言語対応が必要か？ ・メルマガシステムやCRM を使用しているか？ CMSとの連携が必要か？ 　→ 該当する機能を持ったCMSの選定が必要となる ◆ クライアントについて ・更新担当者にどの程度のリテラシーがあるか？ 　→ HTMLの知識がある場合、 一部直接 HTMLを編集する更新方法を採用することも出来る 　→ ある程度CMS使用経験がある場合は、 マニュアルを簡素化することも出来る ・コンテンツ毎に担当者の権限を制限する必要があるか？ ・更新担当者は上長などの承認を得てからコンテンツを公開する必要があるか？ 　→ 細かな権限分けや承認フローの機能を実装するかを検討する
11. 要件定義
12. 要件定義 ◆ CMS案件における要件定義 CMSにより更新するコンテンツ、 大枠の必要な機能の洗い出しを行ったり、 SEO機能（タイトルやディスクリプション設定、sitemap.xml 等）や、 セキュリティ、権限・承認フロー、テスト内容、運用方法、マニュアルの 有無などサイトのコンテンツ以外に求められる達成すべき要件を定める。 ◆ 要件定義が不足していると・・・ ・開発終了後、データ入力を始めた段階で追加機能の要望が大量に ・公開後に、セキュリティの脆弱性が見つかった ・運用段階になって担当者が代わり、承認フローが必要と判明 などトラブルの元となる
13. 要件定義 ◆ サイトマップの作成 トップ 会社概要 404 お問い合わせ （フォーム） お知らせ一覧 商品カテゴリ一覧 動的ページ 静的ページ ※会員機能無し カテゴリ別 商品一覧 商品詳細 お知らせ詳細 動的（CMSで更新するコンテンツ）ページ、静的ページを明確にする。 フォームが必要なページを確認する。会員機能があるかを確認する。
14. 要件定義　　　　　　　　　　　　　　　　　　 ◆ 大まかな機能の洗い出し ワイヤーフレーム（サイト構成）を元に、CMSで更新する箇所やフォームの項目、 外部サービスとの連携箇所などを確認する。 フォームについては、送信された内容を管理画面で閲覧できるようにするか、 メールで送信するか、など管理方法も確認する。
15. 要件定義 ◆ ワイヤーフレーム （仕様策定） のサンプル ・管理画面から登録する項目、 最低数・最大数 or 上限なし、0件時に見た目 が変わるか、 PDFや動画登録箇所などをわかるようにする ・対象のページの登録画面以外でデータ登録し、 選択または自動表示するなど連携するデータ を明確にしておく
16. 要件定義 ◆ 移行コンテンツの確認 既存サイトの静的コンテンツ、または、CMSを使用していた場合のデータを どのように移行するかを確認する。 ・静的コンテンツから CMS 化するものがあるか ・独自のシステムが組み込まれている等、 CMS範囲外に設置する必要があるか ・インポート & エクスポートによるデータ移行が可能か 元のCMS とCMSの種類・データ形式が異なる場合、手動での移行が必要か
17. 要件定義 ◆ テスト内容の確認 事前にどのようなテスト形式を取るか （体制、 種類、 チェックリストなど）合意して おくと確認漏れを防げると共に、クライアントへ安心感を与えられる。 テストの種類： ・単体テスト　-　1 つ 1 つの機能の動作確認 ・結合テスト　-　機能同士の連携箇所の動作確認 ・総合テスト　-　CMS全体の動作確認 ・受入れテスト　-　クライアント環境での動作確認・使用感の確認 ※システム部署などのチェックが厳しい会社は、 クライアント側からテスト形式を指定されることもあるので、要望があるか確認する ※予算、クライアント要望、機能の複雑さ等によって、省略や簡易化も検討します。 ※テスト内容の詳しい解説は後述
18. 要件定義 ◆ 公開後の対応、 運用について 公開後にバグ・修正要望が上がった時の対応について合意を得ておく。 ・瑕疵対応：こちらに非がある場合の修正 ・改善要望 ：検証合意済の箇所で、 軽度の改善要望 ・追加要望：事前の要件に含まれない要望 ・免責事項：外部サービスに起因する等、 そもそも対応できない内容 → 期間、無償 or 有償、対応可否を定める。 運用に入った際に、 クライアントのみで更新するのか、 一部または全コンテンツを制作会社が担当するか、 制作会社が運用する場合、別会社へ引き継ぎを行うか。 マニュアルが必要か、 クライアントリテラシーに応じて内容の粒度を決める。
19. 要件定義 ◆ その他 その他にクライアントに合意を取ると良い項目。 SEO： タイトルやディスクリプションの設定方法、 sitemap.xml の生成について セキュリティ： CMS上でどのようなセキュリティ対策を取るか 権限・ワークフロー、公開手順： アカウントの権限種類、承認機能 （ワークフロー） が必要な場合の公開手順 ステージング・開発サーバから本番サーバへのデータ移行方法、 本番サーバでの公開作業の内容、 手順
20. スケジュール作成
21. スケジュール作成 ◆ ポイント ・テスト内容やコンテンツ内容、クライアントとの担当分けなどの要件によって、 必要なタスクは異なる。 ・フロントエンド担当・CMS開発担当のリソース状況、 または案件の納期によって、 実装の順序・進め方は様々なパターンが考えられる。 → エンジニア選定後、 相談しながら柔軟に効率的なスケジュールへ調整する ※CMSに関連する実装以降のフェーズを抜粋
22. スケジュール作成 ◆ 例 1：前提 ・クライアントが全てのコンテンツ入力、 運用を担当する ・マニュアルが必須 ・コーディング （フロントエンド） と開発が別会社の担当 ・機能が少ないため、 テストは簡易的に行う ・新規サーバを使用 ・公開後 1 週間は、 瑕疵・改善要望に対応する
23. スケジュール作成 ・コーディングと開発を同時に進め、 後から繋ぎこみを行う ・テストは自社による「総合テスト」とクライアントの「受け入れテスト」のみ ・受け入れテストは、 クライアントのコンテンツ入力により実施 ・コンテンツ入力開始前にマニュアルを納品 ・新サーバのため、 事前に本番サーバをセットアップ
24. スケジュール作成 ◆ 例 2：前提 ・公開時のコンテンツは制作会社が入力 ・半分以上のコンテンツは公開後も制作会社が運用 ・マニュアルは後日、簡易的でよい ・コーディング （フロントエンド） と開発は同じ会社が担当 ・受け入れテスト前に、綿密なテストを実施 ・既存サーバの既存CMSを使用 ・追加修正は運用契約の中で対応 ・瑕疵のみ、公開後 1 ヶ月間無償対応
25. スケジュール作成 ・コーディングと開発を同時に行い、繋ぎこみも同時に行う ・テストは随時完成した機能から「単体テスト」を実施、その後「結合・総合テスト」を実施 ・制作会社によるコンテンツ入力後にテストアップ、クライアント確認（受け入れテスト） ・公開後にマニュアルを納品 ・既存サーバ及び既存 CMS使用のため、 公開時にサイトをメンテナンス表示してから、 セットアップを行う
26. CMSの選定
27. CMSの選定 ◆ CMSの種類 導入形態によって大きく3 種類に分けられる。 それぞれのメリット・デメリットを考慮してCMSを選定する。 オープンソース型： プログラムのソースコードが無償で公開されており、商用・非商用問わず、 誰でも利用や修正（改変）さらには配布することができる。 パッケージ型： ベンダーが独自に開発した CMS ライセンスを購入し、自社サーバにインストールする。 クラウド型： ベンダーが管理するサーバにシステムやデータを保管し、インターネット経由で利用する。 出典：ビジネスと IT 活用に役立つ情報 https://www.asobou.co.jp/blog/web/cms-type
28. CMSの選定 ◆ オープンソース型のメリット ◆ オープンソース型のデメリット 代表的なCMS： WordPress、 Drupal、 Joomla ・ライセンス費用がかからないためコストを抑えることができる ・カスタマイズの自由度が高い（ただし、知識やスキルは必要） ・プラグイン（拡張機能）が豊富なため、無料で機能拡張や追加に対応できる ・バージョンアップのサイクルが早い ・日本のみならず世界中にも多くのユーザーがいるため、コミュニティが充実しており、 インターネット上にも多くの情報がある ・ベンダーからのサポートがないため、自己対応できない場合は外部に委託する必要がある ・サーバやドメインは自前で用意し、自らがCMSをサーバにインストールする必要がある ・アップデートや不具合対応などは自己責任で対応する必要があり、ある程度の知識を必要とする ・ソースコードが開示されているため 、脆弱性などを狙った攻撃によるセキュリティリスクがある
29. CMSの選定 ◆ パッケージ型のメリット ◆ パッケージ型のデメリット 代表的なCMS：MovableType （商用） 、 NOREN、 HeartCore ・ベンダーのサポートを受けられるため安心して運用できる ・ベンダーがアップデートや不具合対応などに対応してくれる ・承認機能や権限設定など企業や組織での運用に必要な管理機能が備わっている ・マニュアルやトレーニングといった運用支援が充実している ・初期費用やライセンス利用料が必要となる ・導入規模（ページ数やユーザー数）に応じてライセンス費用が大きくなる ・プラグイン（機能拡張）に追加費用が発生したり、機能のカスタマイズに工数とコストが発生したりする
30. CMSの選定 ◆ クラウド型のメリット ◆ クラウド型のデメリット 代表的なCMS：WIX、 Jimdo、 Weebly ・導入コスト（初期費用）がかからない ・CMS の利用料が月額もしくは従量課金制のため、ランニングコストが安い ・サーバの準備やソフトウェアの設定をする必要がないため、スピーディーに導入できる ・サーバやソフトウェアのメンテナンスコストや手間が発生しない ・ベンダー側で勝手にバージョンアップをしてくれる ・機能が固定化されているためカスタマイズができない ・デザインの自由度に制限がある場合がある ・海外で開発されたサービスが多いため、日本語でのサポートが十分に受けられない場合がある ・システムやサーバにトラブルが起きた際には、ベンダーの対応に依存してしまう
31. 小中規模サイトの受託制作において WordPressが多く採用される ・カスタマイズ性が高く、 導入コストがかからないため採用しやすい ・利用者が多いため、情報が多く、 プラグインも豊富なため構築しやすい ・規模の小さいコーポレート、ブランド、メディアサイトなどでは、 パッケージ型のような複雑な機能を求められることが少ない ・会員機能やコメント機能などユーザー投稿の機能をつけることもほとんどないため、 高度なセキュリティ対策を求められることもあまりない ・PHPベースのため、ほとんどのレンタルサーバで特別な環境構築を必要とせず、 簡単にインストールして使用できる
32. エンジニアの選定 CMSの選定が完了し、 要件定義が完了したら エンジニアを選定する ・ただし、要件が複雑またはディレクターの知識が不十分で、CMS 選定および要件定義が 困難な場合には上流工程からエンジニアに参加してもらうのがよい ・CMS選定前にエンジニアを選定する場合には、複数種類のCMSの導入実績があり、 システム・CMS全般に知識があり、仕様策定の経験も豊富なエンジニアを選択する ・CMS決定後に選定する場合には、採用した CMSが得意で、似たサイトへの導入実績が豊富 なエンジニアを選択する ※自社オリジナルのCMSを採用している開発会社もあるが、 他社への引き継ぎが困難で、 依存性が高く、 運用コストもかかるため、長期に運用するサイトにはあまりおすすめできない
33. WordPressの基礎知識
34. WordPressの基礎知識 ◆ WordPressの仕組み 管理画面 WordPressの管理画面から、 記事 （ページ） を作成して保存すると、 画像や PDF ファイルはサーバにアップロードされ、 記事タイトル・本文等のデータは、サーバ内のデータベースに保存される データベース サーバー 記事タイトル 本文 カテゴリー・タグ 作者、公開日時 など… 記事を作成・保存 画像やPDFファイルなど アップロード 保管
35. WordPressの基礎知識 ◆ WordPressの仕組み サーバー・データベースからファイルやデータを読み込み、 テーマ （テンプレート） によって表示する内容や見た目が決まり、 Webページとして表示される 同じ記事のデータでも、テーマを変えることで表示内容や見た目を変えられる →主にテーマをカスタマイズすることで、オリジナルのサイトを制作していく データベース テーマ A テーマB サーバー ファイルやデータを読み込み
36. WordPressの基礎知識 ◆ サイトをカスタマイズするための3つの”カスタム”機能 ◆ カスタムフィールド WordPress標準の機能を用いて、 ブログ機能程度のサイトを構築することはできるものの、 より 高度にコンテンツを管理する仕組みを構築するには、“カスタム” 機能が必要となる。 タイトルや本文とは別にオリジナルの入力欄を追加できる機能。 本文だけでは入力が面倒だったり、他のページに表示するキャッチコピーなどのテキストは、 入力欄を別に設けることで利便性が一段と向上する。必須チェックや、 日時や色、 地図の挿入など便利な入力欄を追加することができる。
37. WordPressの基礎知識 ◆ カスタム投稿タイプ 標準で備わっている 「投稿」 のメニュー以外に「お知らせ」 「イベント」 「よくある質問」など オリジナルのメニューを作成できる機能。 カスタムフィールドと組み合わせることで、メニュー毎に別々の入力欄を設定できる。
38. WordPressの基礎知識 ◆ カスタムタクソノミー 標準で備わっている「カテゴリー」 「タグ」以外にオリジナルの分類を作成できる機能。 複数のカテゴリーで分類するのに通常の 「カテゴリー」だけでは 使いづらい、カスタム投稿タイプ毎にカテゴリーを分けたい、 といった際に利用する。
39. 新エディタの大きな変更点 Wordpress5系のバージョンから採用された新エディタ「Gutenberg（グーテンベルグ） 」は、 従来のエディタ「クラシックエディター （ウィジウィグエディタ） 」と大きく使用感が異なる。 クライアントが従来のエディタを使い慣れている場合、最新バージョンを導入するか、従来の エディタを採用するかは、 要望を聞きながら要検討。 開発方法も多少異なるため、 エンジニアにも最新版で対応が可能か、 実績があるか確認する。 従来のエディタ 1つの入力欄の中にテキストを入力し、 「見出し」 「段落」などのスタイルを選択 「見出し」 「段落」 などを選択して1 つ 1 つの入力欄 を追加し文字を入力、必要な項目を積み上げていく 新エディタ（ブロックエディタとも呼ぶ）
40. 設計
41. 設計 要件定義の仕様策定で不足している細かい必要入力項目や条件を定義する 入力画面ごとに項目をまとめていく ・表示される箇所 ・必須／任意 ・未入力時の表示や代替メッセージ ・入力欄の種類 ・選択するデータの参照先 ・並び順の制御方法 ・入力制限（文字数、形式） ・連携先のデータが 0 件の時の表示 ※WordPress の場合は、 どのカスタム投稿タイプやカスタムタクソノミーを使用しているか、 カスタムフィールドの種類などを定義しておくと良い
42. 開発／テスト
43. 開発／テスト 設計内容を元に開発指示、 テスト仕様書を作成してテストを実施する 入力画面ごと、連携箇所ごとに テスト内容をまとめていく ・必須項目、入力制限チェックの エラーが表示されるか ・全データ入力後に正しく表示されるか ・任意データ未入力時に意図した 挙動となるか ・連携箇所にデータが表示されるか ・件数や文字数の増減により意図した 挙動となるか など
44. インフラ／セキュリティ
45. インフラ ◆ インフラとは ◆ インフラの重要性 ITの分野においては、情報システムを稼働・運用するための土台となるコンピュータなどの 機材や設備、それらを設置する施設、機器・施設間を結ぶ通信回線やネットワーク、サーバ、 ソフトウェア、データなどの総称。一般的な用語と区別して 「ITインフラ」とも言う。 Webサイトは紙媒体と違い、 デザインやコーディングのちょっとしたミスは速やかに修正 できる場合が多い。 その代わりに、 ネットワークやサーバのトラブルが発生すると一切サイトの情報にアクセス できなくなるため、 重大な損失に繋がる可能性もある。 さらに高度な専門知識を必要とするため、社内にインフラ専任担当がいない場合には、 基本的に外部の専門業者に委託することが望ましい。
46. インフラ ◆ 特に気をつけるケース ・大量のアクセスが見込まれるサイト 　そもそもアクセス数が多い、 キャンペーンや広告で瞬間的にアクセスが集中する、 といった 　案件はネットワークやサーバのスペックを十分に備える必要がある。 ・サーバやシステム停止が即座に金銭的損害に繋がるサイト 　広告、 キャンペーン、 販売、 サービスなどに関連するサイトは特に、数分間サイトにアクセス 　できなかっただけでも金銭的損害が発生し得る。障害が長時間に及ぶほど大損害となる。 　そのため、 サイトにアクセスできなくなった時に即座に知らせる 「死活監視」 や、 同じ機能を 　持つサーバーなどの機器を複数用意して、障害発生時に自動で切り替える 「冗長化 」などの 　対策が必要となる。 → いずれも具体的な内容はインフラ担当者と相談する
47. インフラ ◆ CMSに関連する確認点 ◆ 責任の所在の明確化 ・PHPが動作するか？バージョンは？ 　 （CMSの種類によっては PHP 以外が必要となるので適宜確認） ・データベース環境が用意されているか？ 　 （MySQLを使用することが多いが、CMS の種類によっては異なるため適宜確認） ・SSLが導入されているか？ クライアント側にシステム担当者がいる、または、インフラの専門業者が担当している場合、 自社に編集の権限があっても「極力インストールや設定変更などを行わない」ことで責任の 所在を明確にすることが重要。もし自社で対応する場合には、編集したファイルや作業内容 を細かく記録して報告しておくことで、 それ以外の場所には責任がないことを明確にする。
48. セキュリティ ◆ CMS導入時に確認するセキュリティのポイント ・SSLが導入されているか？ 　SSL とはブラウザとサーバ間でのデータの通信を暗号化し、 送受信させる仕組みのこと。 　会員情報やECで住所や請求情報などを扱う場合には特に重要。 ・アクセスログを取っているか？ 　管理画面へのログイン履歴、操作履歴のログを取っておくと、不正アクセスにすぐに気づく 　ことができ、不正にアクセスされた内容を把握しやすい。 ・パーミッションやアクセス制限が適切か？ 　パーミッションとはファイルのアクセス権のことであり、 編集の必要がなかったり、 外部から 　見られたくないファイルには制限を設けておくことが重要。 　管理画面にベーシック認証やIPアドレスでアクセス制限をする事も不正アクセス対策となる。 　ログイン画面に画像認証を設けたり、 WordPressにおいてはデフォルトのユーザや管理画面 　のURLを変更することも有効である。
49. まとめ
50. まとめ ・システム案件において、クライアントからのヒアリング、要件策定時の 　 合意をきちんと行うことが重要 ・予算やクライアントリテラシー、 機能やページ量を考慮して、 各フローで 　 どこまで厳密に対応するか、 最適な手順・内容を検討する ・エンジニアとの円滑なコミュニケーション、品質担保のためにも、 　各種仕様書の取りまとめが重要 ・各CMSの特性を把握し、 最適なCMSを選択する ・WordPressの基本的な仕組みを理解することで、 仕様策定・エンジニアと 　 コミュニケーションがスムーズになる ・インフラやセキュリティは、最低限のポイントを理解しつつ、専門家に 　依頼・責任の所在を明確化する
51. ディレクター向けCMS案件の進め方 （WordPress中心） ご静聴ありがとうございました。 Presentations by SKYGUILD