Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ErinaTakei
March 31, 2020
2.3k

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

ErinaTakei

March 31, 2020
Tweet

Transcript

  1. CMS案件の流れ 1. ヒアリング 2. 要件定義 ~エンジニアの手配~ 3. CMSの選定 4. 設計 5. 仕様書作成 6. 開発 7. テスト 8. マニュアル作成

    9. 運用 ワイヤーフレーム(サイト構成)作成の段階 ※多少前後したり、省略することもあります ある程度デザインが出来てきた段階 フロントエンド実装と同時並行か 前後どちらのタイミングで進行しても可能
  2. ヒアリング ◆ インフラについて ・既存サーバを使用するか?新規サーバか? ・既存サーバの場合は、使用しているサーバーの種類を確認  → 動作環境によっては、 使用できないCMSも有りうるため要確認 ・使用可能なSSLを利用できるか?新規に導入可能か? ◆

    既存サイトについて ・既存サイトでCMS を使用しているか? ・CMSを変更する、 または、バージョンアップは可能か? ・既存サイトから移行するコンテンツがあるか? ※CMSに関連する内容を抜粋 ※その他、制作物の内容等、通常のWebサイト制作時にも必要な内容は省略
  3. ヒアリング ◆ その他 ・多言語対応が必要か? ・メルマガシステムやCRM を使用しているか? CMSとの連携が必要か?  → 該当する機能を持ったCMSの選定が必要となる ◆

    クライアントについて ・更新担当者にどの程度のリテラシーがあるか?  → HTMLの知識がある場合、 一部直接 HTMLを編集する更新方法を採用することも出来る  → ある程度CMS使用経験がある場合は、 マニュアルを簡素化することも出来る ・コンテンツ毎に担当者の権限を制限する必要があるか? ・更新担当者は上長などの承認を得てからコンテンツを公開する必要があるか?  → 細かな権限分けや承認フローの機能を実装するかを検討する
  4. 要件定義 ◆ CMS案件における要件定義 CMSにより更新するコンテンツ、 大枠の必要な機能の洗い出しを行ったり、 SEO機能(タイトルやディスクリプション設定、sitemap.xml 等)や、 セキュリティ、権限・承認フロー、テスト内容、運用方法、マニュアルの 有無などサイトのコンテンツ以外に求められる達成すべき要件を定める。 ◆

    要件定義が不足していると・・・ ・開発終了後、データ入力を始めた段階で追加機能の要望が大量に ・公開後に、セキュリティの脆弱性が見つかった ・運用段階になって担当者が代わり、承認フローが必要と判明 などトラブルの元となる
  5. 要件定義 ◆ サイトマップの作成 トップ 会社概要 404 お問い合わせ (フォーム) お知らせ一覧 商品カテゴリ一覧

    動的ページ 静的ページ ※会員機能無し カテゴリ別 商品一覧 商品詳細 お知らせ詳細 動的(CMSで更新するコンテンツ)ページ、静的ページを明確にする。 フォームが必要なページを確認する。会員機能があるかを確認する。
  6. 要件定義 ◆ ワイヤーフレーム (仕様策定) のサンプル ・管理画面から登録する項目、 最低数・最大数 or 上限なし、0件時に見た目 が変わるか、

    PDFや動画登録箇所などをわかるようにする ・対象のページの登録画面以外でデータ登録し、 選択または自動表示するなど連携するデータ を明確にしておく
  7. 要件定義 ◆ テスト内容の確認 事前にどのようなテスト形式を取るか (体制、 種類、 チェックリストなど)合意して おくと確認漏れを防げると共に、クライアントへ安心感を与えられる。 テストの種類: ・単体テスト - 1

    つ 1 つの機能の動作確認 ・結合テスト - 機能同士の連携箇所の動作確認 ・総合テスト - CMS全体の動作確認 ・受入れテスト - クライアント環境での動作確認・使用感の確認 ※システム部署などのチェックが厳しい会社は、 クライアント側からテスト形式を指定されることもあるので、要望があるか確認する ※予算、クライアント要望、機能の複雑さ等によって、省略や簡易化も検討します。 ※テスト内容の詳しい解説は後述
  8. 要件定義 ◆ 公開後の対応、 運用について 公開後にバグ・修正要望が上がった時の対応について合意を得ておく。 ・瑕疵対応:こちらに非がある場合の修正 ・改善要望 :検証合意済の箇所で、 軽度の改善要望 ・追加要望:事前の要件に含まれない要望

    ・免責事項:外部サービスに起因する等、 そもそも対応できない内容 → 期間、無償 or 有償、対応可否を定める。 運用に入った際に、 クライアントのみで更新するのか、 一部または全コンテンツを制作会社が担当するか、 制作会社が運用する場合、別会社へ引き継ぎを行うか。 マニュアルが必要か、 クライアントリテラシーに応じて内容の粒度を決める。
  9. 要件定義 ◆ その他 その他にクライアントに合意を取ると良い項目。 SEO: タイトルやディスクリプションの設定方法、 sitemap.xml の生成について セキュリティ: CMS上でどのようなセキュリティ対策を取るか

    権限・ワークフロー、公開手順: アカウントの権限種類、承認機能 (ワークフロー) が必要な場合の公開手順 ステージング・開発サーバから本番サーバへのデータ移行方法、 本番サーバでの公開作業の内容、 手順
  10. スケジュール作成 ◆ 例 1:前提 ・クライアントが全てのコンテンツ入力、 運用を担当する ・マニュアルが必須 ・コーディング (フロントエンド) と開発が別会社の担当

    ・機能が少ないため、 テストは簡易的に行う ・新規サーバを使用 ・公開後 1 週間は、 瑕疵・改善要望に対応する
  11. スケジュール作成 ◆ 例 2:前提 ・公開時のコンテンツは制作会社が入力 ・半分以上のコンテンツは公開後も制作会社が運用 ・マニュアルは後日、簡易的でよい ・コーディング (フロントエンド) と開発は同じ会社が担当

    ・受け入れテスト前に、綿密なテストを実施 ・既存サーバの既存CMSを使用 ・追加修正は運用契約の中で対応 ・瑕疵のみ、公開後 1 ヶ月間無償対応
  12. CMSの選定 ◆ CMSの種類 導入形態によって大きく3 種類に分けられる。 それぞれのメリット・デメリットを考慮してCMSを選定する。 オープンソース型: プログラムのソースコードが無償で公開されており、商用・非商用問わず、 誰でも利用や修正(改変)さらには配布することができる。 パッケージ型:

    ベンダーが独自に開発した CMS ライセンスを購入し、自社サーバにインストールする。 クラウド型: ベンダーが管理するサーバにシステムやデータを保管し、インターネット経由で利用する。 出典:ビジネスと IT 活用に役立つ情報 https://www.asobou.co.jp/blog/web/cms-type
  13. CMSの選定 ◆ オープンソース型のメリット ◆ オープンソース型のデメリット 代表的なCMS: WordPress、 Drupal、 Joomla ・ライセンス費用がかからないためコストを抑えることができる

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

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

    の利用料が月額もしくは従量課金制のため、ランニングコストが安い ・サーバの準備やソフトウェアの設定をする必要がないため、スピーディーに導入できる ・サーバやソフトウェアのメンテナンスコストや手間が発生しない ・ベンダー側で勝手にバージョンアップをしてくれる ・機能が固定化されているためカスタマイズができない ・デザインの自由度に制限がある場合がある ・海外で開発されたサービスが多いため、日本語でのサポートが十分に受けられない場合がある ・システムやサーバにトラブルが起きた際には、ベンダーの対応に依存してしまう
  16. WordPressの基礎知識 ◆ WordPressの仕組み 管理画面 WordPressの管理画面から、 記事 (ページ) を作成して保存すると、 画像や PDF

    ファイルはサーバにアップロードされ、 記事タイトル・本文等のデータは、サーバ内のデータベースに保存される データベース サーバー 記事タイトル 本文 カテゴリー・タグ 作者、公開日時 など… 記事を作成・保存 画像やPDFファイルなど アップロード 保管
  17. WordPressの基礎知識 ◆ サイトをカスタマイズするための3つの”カスタム”機能 ◆ カスタムフィールド WordPress標準の機能を用いて、 ブログ機能程度のサイトを構築することはできるものの、 より 高度にコンテンツを管理する仕組みを構築するには、“カスタム” 機能が必要となる。

    タイトルや本文とは別にオリジナルの入力欄を追加できる機能。 本文だけでは入力が面倒だったり、他のページに表示するキャッチコピーなどのテキストは、 入力欄を別に設けることで利便性が一段と向上する。必須チェックや、 日時や色、 地図の挿入など便利な入力欄を追加することができる。
  18. 新エディタの大きな変更点 Wordpress5系のバージョンから採用された新エディタ「Gutenberg(グーテンベルグ) 」は、 従来のエディタ「クラシックエディター (ウィジウィグエディタ) 」と大きく使用感が異なる。 クライアントが従来のエディタを使い慣れている場合、最新バージョンを導入するか、従来の エディタを採用するかは、 要望を聞きながら要検討。 開発方法も多少異なるため、

    エンジニアにも最新版で対応が可能か、 実績があるか確認する。 従来のエディタ 1つの入力欄の中にテキストを入力し、 「見出し」 「段落」などのスタイルを選択 「見出し」 「段落」 などを選択して1 つ 1 つの入力欄 を追加し文字を入力、必要な項目を積み上げていく 新エディタ(ブロックエディタとも呼ぶ)
  19. インフラ ◆ インフラとは ◆ インフラの重要性 ITの分野においては、情報システムを稼働・運用するための土台となるコンピュータなどの 機材や設備、それらを設置する施設、機器・施設間を結ぶ通信回線やネットワーク、サーバ、 ソフトウェア、データなどの総称。一般的な用語と区別して 「ITインフラ」とも言う。 Webサイトは紙媒体と違い、

    デザインやコーディングのちょっとしたミスは速やかに修正 できる場合が多い。 その代わりに、 ネットワークやサーバのトラブルが発生すると一切サイトの情報にアクセス できなくなるため、 重大な損失に繋がる可能性もある。 さらに高度な専門知識を必要とするため、社内にインフラ専任担当がいない場合には、 基本的に外部の専門業者に委託することが望ましい。
  20. インフラ ◆ 特に気をつけるケース ・大量のアクセスが見込まれるサイト  そもそもアクセス数が多い、 キャンペーンや広告で瞬間的にアクセスが集中する、 といった  案件はネットワークやサーバのスペックを十分に備える必要がある。 ・サーバやシステム停止が即座に金銭的損害に繋がるサイト  広告、

    キャンペーン、 販売、 サービスなどに関連するサイトは特に、数分間サイトにアクセス  できなかっただけでも金銭的損害が発生し得る。障害が長時間に及ぶほど大損害となる。  そのため、 サイトにアクセスできなくなった時に即座に知らせる 「死活監視」 や、 同じ機能を  持つサーバーなどの機器を複数用意して、障害発生時に自動で切り替える 「冗長化 」などの  対策が必要となる。 → いずれも具体的な内容はインフラ担当者と相談する
  21. インフラ ◆ CMSに関連する確認点 ◆ 責任の所在の明確化 ・PHPが動作するか?バージョンは?   (CMSの種類によっては PHP 以外が必要となるので適宜確認)

    ・データベース環境が用意されているか?   (MySQLを使用することが多いが、CMS の種類によっては異なるため適宜確認) ・SSLが導入されているか? クライアント側にシステム担当者がいる、または、インフラの専門業者が担当している場合、 自社に編集の権限があっても「極力インストールや設定変更などを行わない」ことで責任の 所在を明確にすることが重要。もし自社で対応する場合には、編集したファイルや作業内容 を細かく記録して報告しておくことで、 それ以外の場所には責任がないことを明確にする。
  22. セキュリティ ◆ CMS導入時に確認するセキュリティのポイント ・SSLが導入されているか?  SSL とはブラウザとサーバ間でのデータの通信を暗号化し、 送受信させる仕組みのこと。  会員情報やECで住所や請求情報などを扱う場合には特に重要。 ・アクセスログを取っているか?  管理画面へのログイン履歴、操作履歴のログを取っておくと、不正アクセスにすぐに気づく

     ことができ、不正にアクセスされた内容を把握しやすい。 ・パーミッションやアクセス制限が適切か?  パーミッションとはファイルのアクセス権のことであり、 編集の必要がなかったり、 外部から  見られたくないファイルには制限を設けておくことが重要。  管理画面にベーシック認証やIPアドレスでアクセス制限をする事も不正アクセス対策となる。  ログイン画面に画像認証を設けたり、 WordPressにおいてはデフォルトのユーザや管理画面  のURLを変更することも有効である。
  23. まとめ ・システム案件において、クライアントからのヒアリング、要件策定時の   合意をきちんと行うことが重要 ・予算やクライアントリテラシー、 機能やページ量を考慮して、 各フローで   どこまで厳密に対応するか、 最適な手順・内容を検討する

    ・エンジニアとの円滑なコミュニケーション、品質担保のためにも、  各種仕様書の取りまとめが重要 ・各CMSの特性を把握し、 最適なCMSを選択する ・WordPressの基本的な仕組みを理解することで、 仕様策定・エンジニアと   コミュニケーションがスムーズになる ・インフラやセキュリティは、最低限のポイントを理解しつつ、専門家に  依頼・責任の所在を明確化する