最高のWebサイト開発リーダーになるための五ヶ条【第二回】

f:id:ChigusaSatoh:20200807162113j:plain

 

みなさまこんにちは。佐藤千草です。
「最高のWebサイト開発リーダーになるための五ヶ条」連載第二回目です。
今回のテーマはこちら。

あなたは、クライアントのためではなく、サイトを訪れるお客さまのために開発をすべきである

ケーススタディ

例えば、あなたの担当するCMS開発プロジェクトで、ワークフロー機能(コンテンツの作成から公開までの業務フローをCMSシステム上で実現する機能)を実装することになったとします。
クライアントと担当ディレクターで取り決めたワークフロー設計書には、以下のように定義されていました。

  • CMSを利用するユーザは、コンテンツを編集できる「編集者」と、コンテンツを公開できる「承認者」の2種類の権限が必要。
  • 「編集者」がコンテンツを作成・更新し、「承認者」に承認依頼を流す。
  • 「承認者」がコンテンツのサイト表示をプレビューで確認し、承認操作を行うことで、コンテンツがサイト上に公開される。

担当ディレクターはあなたにこの設計書を渡し、こう伝えました。

「クライアントと仕様を詰めましたので、この設計書の通りに実装をお願いします。」

そこであなたは実装にとりかかろうとしましたが、ふとひとつの疑問が生じました。

「承認者」は、本当に「コンテンツを公開できる」権限だけを持っていればよいのか?
承認前に自らコンテンツを微修正してから公開したいケースもあるのではないか?
そもそも「承認者」が自身でコンテンツを作成・更新して、そのまま公開するケースはないのだろうか?

この疑問をディレクターに投げかけてみたところ、返事はこのようなものでした。

「クライアントからはそういう要望は特になかったですね」
「この設計書でクライアントに承認もらっちゃってるんで、この通りの仕様でお願いします!」

さて、あなたならどうしますか?

対応A

クライアントと直接やり取りをしているディレクターがそういうならと、「承認者」には「コンテンツを公開できる」権限しか付与せず、「コンテンツを編集できる」権限は付与しなかった。

対応B

ローンチ後にクライアントが運用に困ることがあるかもしれないと考え、クライアントにもう一度仕様をご確認いただくようディレクターに依頼をした。

対応Aを選択したあなたへ

ここであえて対応Aの是非を論じることはしませんが、起こりうる事態を推測して仮説を述べます。

あなたが対応Aを選択した理由は以下のようなものです。

「クライアントも特に要望しなかったって言うから、『承認者』にコンテンツ編集権限を持たせないのは、クライアントが本当に望んでいたことかもしれない」
「そもそも仕様を決める役割なのはディレクターだし、万が一あとでクライアントが困ったって自分のせいじゃない」

さて、サイトが公開され、実際にCMSをさわりはじめて、クライアントは初めてその運用のしづらさに気づきました。
そのクライアントは、あなたの会社に対して

「確かに取り決めた設計通りにはなってるけど、あまりにも気がきかなさすぎじゃない?」
「仕様の再確認や、改善提案をしてくれても良さそうなものなのに…」

と不満を抱くことになってしまいました…

ここであなたの会社に対して明確にクレームを入れてくれるクライアントなら、わざわざ時間を割いて「不満を持っている」ことを教えてくれているのですから、まだよいほうだと思わなければなりません。
制作者にとって一番怖いのは、クライアントの「声なき不満」に気づかないことです。
その不満は蓄積され、結果的に大きな仕事の受注機会を失うことだってあり得ます。

対応Bを選択したあなたへ

あなたは自分の役割だけにとらわれず、担当外のことでも「自分ごと」に考えることができているようです。
そんなあなたには、是非もう一歩先に進んでいただきたい。

実は、選択肢に挙げなかった「対応C」が存在します。

対応C

コンテンツの微修正に至るまで差し戻しが必要な運用であれば、それによってコンテンツの公開が遅れる可能性もある。
CMS運用が滞れば、サイトを訪れるお客さまに対して最適なタイミングで最適なコンテンツを提供することができない。
従って、是非とも改善しなければならない旨、ディレクターに説明のうえ、クライアントへの説明と仕様変更の承認を依頼した。

「クライアント最適化」を超えて「お客さま最適化」へ

ディレクターに対してアクションを起こすという意味では、対応BとCは同じです。
しかしながら、対応Bは「クライアントのため」の行動、対応Cは「サイトを訪れるお客さまのため」の行動です。

「改善しないと運用が不便になります」

ではなく

「改善しないとサイトを訪れるお客さまへのコンテンツ提供が滞ることになります」

と伝えることができれば、クライアントへのインパクトもより大きく、理解と承認を得やすくなります。

こういった対応の積み重ねによって、「クライアント最適化」を超えて「お客さま最適化」されたCMSが完成します。

この「お客さま最適化」実現のためには、第一回でのべた

  • プロジェクトの目的・目標を意識する
  • サイトがお客さまに提供しなければならないコンテンツ、サービス、ソリューションを意識する

が大前提となります。

Webサイトのすべてのコンテンツ、サービス、ソリューションは「サイトを訪れるお客さまのため」に存在しています。
お客さまのニーズを把握してはじめて、ひとつひとつの機能について、何をどのように実装すべきかの方向性が明確に決まってきます。

そのことを忘れずに日々の仕事に取り組むことで、クライアントは「あの会社は常に我々のお客さまのことを考えて対応してくれる」と認識し、あなたの会社の価値を高めてくれることでしょう。

それではまた次回お会いしましょう。

まとめ

なぜ、あなたのチームが開発するCMSはクライアントに喜ばれないのか?

サイトを訪れるお客さまにまで意識が向いていないから

  • クライアントやディレクターの認識がぶれていても気づかずにそのまま実装してしまう
  • 改善を提案したとしても、必要性へのインパクトが弱く、提案を通すことができない

お客さま最適化CMSを実現するためにやるべきこと

  • 「クライアント最適化」の一歩先「お客さま最適化」を意識する
  • クライアントやディレクターの指示や設計がそこからぶれていれば指摘し、お客さまのためにどのような実装をすればよいか提案する

最適なUX(ユーザー体験)を実現するための情報設計

UXとは

UX(ユーザーエクスペリエンス)という言葉は一般的な用語になり、Webサイトに関わる方は皆さん聞いたことがあるでしょう。

UXとは、User eXperienceの略語で、ユーザーが製品やサービスを利用して得られる体験・経験の総称です。

 

本質は【UX向上 = デザインをカッコ良く】ではない

UXというとまずはデザインを変えようといった考え方を持つ方が多い気がします。

確かにデザインはUXを改善する上での1つの改善ポイントになりますが、

単にデザインをカッコ良くしただけでは、ユーザー体験の向上とはなりません。

 

Jesse James Garrett氏が提唱するUXの概念【UXの5階層モデル】でいう

ユーザーの目に触れる表面的な1要素にすぎません。

またUI(ユーザーインターフェイス)やユーザビリティもデザインと同様にUXを構成する1要素なのです。

 

わかりやすい表面的な部分を重要視されがちになりますが、

根幹のWebサイトの目的やユーザーのニーズ等の戦略といった見えづらい部分がUXを語る上で重要になります。

つまりベースとなる戦略を元に各要素が段階的に繋がることでUXの向上となります。

 

UX5階層モデル

 

f:id:hirokikajita:20200604123239p:plain

表面(Surface

視覚的なビジュアルデザインを適用し、操作性をプロトタイプで検証する。

骨格(Skelton)

ユーザーが理解しやすい様に共通のナビゲーション、各ページに表示される情報・表示順をプロトタイプで検証する。

構造(Structure)

シナリオに基づいたサイト構造・動線を整理する。

要件(Scope)

ユーザー毎の目的(ニーズ)を満たすためのシナリオを検討する。

戦略(Strategy)

サイトの目的、ユーザーのニーズを理解する。

 

最適なUX(ユーザー体験)を実現するために重要な情報設計、

戦略から骨格までの流れをご紹介します。

 

まずユーザーと向き合い自社Webサイトに訪れる

ユーザーの本質を知ることが、はじめの一歩となります。

 

ユーザーの本質を理解する

 

ユーザーの本質を理解するためには、ユーザーがどんな人で、どんな目的を持って自社Webサイトに訪れてくるか、自社Webを考える必要があります。

 

アクセス解析ヒアリング、インタビュー、アンケート等の様々な方法で

ユーザーの抱えている課題やニーズを発見し、ユーザー像を具現化していきます。

 

アクセス解析を例にユーザー像を具現化する方法について紹介します。

Webサイトは、ユーザーが能動的に検索エンジン

ユーザーが知りたい、疑問を解決したい内容を入力し、Webサイトに訪れます。

Googleアナリティクスやサーチコンソールの検索クエリから

自社Webサイトに訪れるユーザーのニーズを抽出することができます。

 

検索クエリ 例)

 〇〇〇ホテル 宿泊 予約

⇒ユーザーのニーズ:〇〇〇ホテルの予約をしたい

渋谷 宿泊 予約

⇒ユーザーのニーズ:渋谷のホテルの予約をしたい

〇〇〇ホテル 中華 ランチ

⇒ユーザーのニーズ:〇〇〇ホテルの中華レストランの予約をしたい

渋谷 中華 ランチ

⇒ユーザーのニーズ:渋谷の中華レストランの予約をしたい

〇〇〇ホテル 採用

⇒ユーザーのニーズ:〇〇〇ホテルの採用情報を知りたい

渋谷 ホテル 採用

⇒ユーザーのニーズ:渋谷のホテルの採用情報を知りたい

 

またニーズからユーザー像を導き出し自社がターゲットとする顧客をセグメントし

【ユーザーは何を求めているか】を明確にします。

  

ターゲットユーザー毎のユーザー体験を見える化

 

近年ではスマートフォンの普及、チャネルの多様化により

1デバイス・1チャネルでユーザーの目的を完結することがなくなりました。

多様化するデバイス・チェネルをシームレスに繋ぐためには、

ユーザーの目的(ニーズ)が満たされるまでのシナリオを可視化し検討する必要があります。

 

シナリオを検討する上で行う事は、

ユーザー視点に立ち各ユーザーのフェーズ・行動プロセス・ユーザーの思考・

すべき事柄の項目を整理し時系列に一覧化します。

 

フェーズ

 興味、興味・関心、比較・検討、購入等の様にユーザーの行動をステップ毎に分けた軸を記載する。

行動プロセス

製品やサービスに触れる入口(タッチポイント)から出口(ゴール)までの行動を記載する。

ユーザーの思考

フェーズ毎のユーザーの思考・感情を記載する。

すべき事柄

チャネル・デバイス毎(リアル、SNS、Web(PC・スマートフォン)等)にすべき事柄を記載する。

 

シナリオを作成することで

いつ、どこで、どんなコンテンツを提供する必要があるかが可視化できます。

 

シナリオに基づいてサイト構造・動線を情報設計に落とし込む

シナリオでは、ユーザーにいつ、どこで、どんなコンテンツを提供するかを可視化しましたが、Webサイトを構築する上ではより具体的な情報設計が必要となります。

 

洗い出したコンテンツをグルーピングし、Webサイト全体の大枠(サイト構造)を組み上げます。

コンテンツ同士の関係性、関連するページ同士の動線を考慮し、

入口(集客)から出口(ゴール)までの誘導がスムーズに行えるかサイト構造図で繰り返し検証します。

 

例えば、出口(ゴール)までの動線が適切に設けられているか、関連するページへの導線が設けられているかを重点的に確認します。

 

サイト単位・ページ単位で目的を成し得るための要素は配置

ユーザーの目的を成し得るためにサイト単位ではナビゲーション、ページ単位ではレイアウト、コンテンツ内容、コンテンツの表示順を検討します。

 

ナビゲーションはWebサイト内すべてに共通して配置されるリンクになります。

ユーザーを主要なコンテンツへ導く役割やサイト全体の構造を把握するための役割をもちます。

コンテンツをグルーピングした際のカテゴリから主要なコンテンツや

サイトの出口(ゴール)となるコンテンツを配置します。

 

次にページ単位のページ単位ではレイアウト、コンテンツ内容、コンテンツの表示順を検討します。

ページの目的毎にコンテンツの表示順、コンテンツ内容、関連するページへのリンク、コンバージョンリンクを配置します。

 

まとめ

ユーザーの本質を理解し、ユーザー視点にたった情報設計をするこでユーザーに最適なUX(ユーザー体験)を提供することができます。

 

CMS組み込み前提HTML構築手法

テンプレート&コンポーネント

所属している会社では、全てCMS適用前提でのHTMLを作成します。 CMSのページはブロックパーツと呼ばれる部品と、テンプレートで成り立っています。 コーダーはこの2つを主に作成しています。

CMSに乗せるためには、パーツを汎用化させる必要があります。 そこで有効なのがアトミックデザインの概念になります。

アトミックデザインとは、最小の粒となるエレメント(原子)を組み合わせコンポーネント(分子)を構築し、コンポーネントを組み合わせテンプレートを作成する手法です。

エレメント

とは、見出し、画像、本文、リンク等の部品1つ1つを指します。

コンポーネント

とは、エレメントを組み合わせ人が読み理解できる構造にしたものです。CMSのブロックパーツはこれを指します。

テンプレートはコンポーネントの集合体となり、1つのページ(コンテンツ)となります。 コンポーネントで気をつけなければならない点は、積み上げパターンを想定する事です。 ブロックパーツはお客様の要望次第で自由に形を変え積み上げられます。

そのため、エレメントの段階からあらゆる積み上げパターンを考慮し空きの担保や崩れが無いかを検証します。

デザインから読み解く力

昨今のwebサイトは、インタラクティブな要素が増え紙ベースでは伝えにくい環境になっています。

私達コーダー(フロントエンドエンジニア)は、この問題を解決するためプロトタイプを作成しクライアントの認識を一致させる事が重要と考えています。

そのため、デザインから動きがある要素を読み取る力が重要になります。 場合によっては、コーダーからデザイナーに動きを提案する必要もあります。

管理&追加しやすい命名規則

ファイル名やclass名等しっかりルール化する事が重要です。 これは作成者自身のマイルールで構築すると、別の人が更新する時そのルールを読み解くためにコストが掛かるからです。

ファイル名は「単語-単語-単語・・・」となるように単語と単語の間を「-(半角ハイフン)」で区切り命名します。 また、接頭にファイルの用途(img-、 icon-、 bnr- 等)を記載し単語から何に使用されているかなるべく分かりやすく命名し、同じ要素が複数ある場合は、末尾に「-01、-02、-03・・・」と 2桁の連番を付けていきます。

例)img-recommend-01.png、icon-blank.svg、bnr-links-01.jpg

エレメントのclass名は接頭辞として、’element’の頭文字である「el-」を付与します。 また、子要素の命名規則にはclass名の管理や重複を防ぐためBEM記法を使用し、「__」や「--」で単語間を繋ぎます。 下記は大見出し(h2)を上記のルールに沿って作ったHTML構造になります。

<div class="el-heading-lv2">
  <div class="el-heading-lv2__holder">
    <div class="el-heading-lv2__item">
      <h2 class="el-heading-lv2__title">大見出し(h2)</h2>
    </div>
  </div>
<!-- /el-heading-lv2 --></div>

複数人で作業するためのファイル管理

大規模なサイトになると複数人が携わり同時にファイルを編集する必要が出てきます。 この時問題になるのはデグレードが発生する事です。 これを解決するために私達はgitを導入しバージョン管理を行っています。 ただgitを入れれば全ての問題を解決する訳ではなく、明確なルールが必要になります。

機能の追加&改修時のgit活用法

お客様に確認頂く専用の環境を用意しています。 gitではdeveloperというブランチを用意し、このブランチを確認環境と常に同期するようにします。

またmasterブランチを本番環境と同期させ、機能の追加を行う時はこのmasterブランチのミラーを用意し機能を開発、完成したらお客様に確認して頂くためにdeveloperブランチにマージします。

ここで本番公開となったらmasterブランチにマージします。 これにより複数の機能を同時に開発し、必要な機能だけを本番に公開する事ができます。

種類から考える CMSを選ぶポイント

数多あるCMSツールの中からはどれを選べばよいのか、判断基準がよくわからないという人もいるかと思います。 「とりあえず、何でもいいから導入すればいい」と乱暴なことを言って導入を進める人もいるかもしれませんが、プロジェクトやサイトの目的・状況に合わないものを選定してしまうと、CMSはかなりコストパフォーマンスの悪いものになってしまいます。

  • 制作者にとっては無駄な労力と努力を強いられる。
  • 発注者にとっては高いコストを払う必要が出る。

合わないものを導入してしまうと、 そんな誰も幸せにならない結果になってしまう事態になりかねません。

CMSツールが足かせとなり、運用上コストパフォーマンスの悪いWebサイトとならないように、選定については、慎重に吟味して行うべきだと考えます。導入後にどうにかしようと思っても、時すでに遅しとなってしまいます。

本稿では、CMSツールにおける仕組みの違いやライセンス形態などを説明し、 それぞれ「向き・不向き」、「できる・できない」があることを説明しつつ、CMSツールを選定する際のポイントについて解説していきます。

■目次:

1. ライセンス形態 ~オープンソースと商用~

ライセンスは誰でも自由に利用可能なオープンソースと商用の2種類存在します。

オープンソース

ネット上などで公開されており、 誰でも自由に使用、複製、改変、再配布などが可能なシステム。 ネット上のコミュニティで運用・保守を行っている。

商用

特定の企業が開発し、販売を行っているシステム。複製、改変、再配布はできない。 企業で運用・保守を行っている。

それぞれの特徴や違い

f:id:webcreatorsstruggle:20200518174007p:plain

機能・カスタマイズ・コストについて

オープンソース

オープンソースはライセンス費用が無償で、誰でも使おうと思えば直ぐに利用を開始するこ とができます。無償であり、素早く導入することができるのがメリットです。

カスタマイズ性が高い反面、商用のものに比べると標準機能が乏しく、 CMSの導入の際に、コミュニティ等で提供されるプラグインを導入したり、独自でカスタマイズを実施することで、目的に対して最適化することが多いです。

ライセンス自体に費用は掛かりませんが、カスタマイズにかかる費用が、商用のものより比較的高くなる傾向にあります。

オープンソースは無料だからという理由で導入したけど、カスタマイズしていったら、結局カスタマイズ分のコストが高くなり、想定よりも予算をオーバーするというのも十分にあり得る話です。

費用を低く抑えたいという場合にも、単純に費用が無償なオープンソースを選ぶのではなく、機能が豊富な商用も比較の上、選ぶべきだと思います。

商用

オープンソースが無償で、標準機能が乏しいのに対して、基本的に商用は有償で標準機能が豊富な場合が多いです。

オープンソースに比べるとカスタマイズを許容していないケースが多いです。 独自タグを利用したカスタマイズを一部許容している場合もありますが、JavaPHPなどのプログラム言語を用いた開発はできず、限定的な範囲のみしか触ることができない場合が多いです。

標準機能が多いので、それで賄えるのであればコストパフォーマンスが高く構築できると思われます。

セキュリティについて

オープンソース

セキュリティに対しては、商用に比べるとオープンソースは自分たちで調査・対応していく能力が必要になってきます。

オープンソースは基本的には提供企業によるサポートを受けることができません。 (一部企業によっては、有料サポートを実施していることはあります。) セキュリティに関する対応などについても、基本的には自己責任となってきます。 自分たちで調査し対応をしていく、もしくは制作会社への依頼などが必要になってきます。

基本的には、コミュニティ内でパッチ提供などは実施されるので、提供されたパッチをCMSへ適用すれば良い事が多いのですが、それも自分で調査をして対応をする必要があります。

また有志の方々が開発して提供してくれるプラグイン等に関しては、途中で開発は止まってしまい脆弱性が放置されるような自体も少なくはありません。

保守されていないプラグラインなどを導入してしまった場合には、適切にセキュリティ対策を実施するのであれば、それらを自分達でどうにかしなければいけません。

プラグインの導入などに関しては、開発コミュニティが活発に動いているのか等の判断をした上で行ったほうが良いと思います。 闇雲に導入すると、後処理が大変になります。

セキュリティの観点からすると、適切に対応できるエンジニアがいないのであれば、オープンソースはあまりお勧めできません。

商用

オープンソースに比べると、商用の方がセキュリティにおいては安心できる面が多いです。

商用は提供元の企業がプログラムの運用保守を行っているため、オープンソースのような、急にプログラムが運用保守されない状態になるようなことがありません。 (提供元企業が倒産すると、また話は変わってきますが…)

セキュリティに問題がありパッチ適用が必要になった場合などでも、企業側でサポートしてくれます。自分たちで調べなくても問い合わせをすれば答えてくれる分、対応が楽と言えると思います。

商用は、企業が継続的にシステムを運用保守しており、不明点があれば適切にに教えてくれるので、セキュリティの観点から見れば、安心感は高いと言えるのではないかと思います。

どう選ぶべきか

オープンソースは良くも悪くも、開発者のスキルに大きく依存します。 優秀なエンジニアが運用・保守するのであれば、柔軟性にも富み、コストパフォーマンスも高く運用構築できるとは思いますが、そうでないのであれば、商用を利用するほうが苦労も無く安心できる面が多いと思います。

商用CMSはカスタマイズ性が低いものが多いので、カスタマイズをしないと、本来の目的を達成できないような場合、合致するものが商用でないという場合には、オープンソースを選ぶしかないと思います。

もし制作会社に任せるような場合には、オープンソースに関しては、かなりその会社のシステム開発スキルに依存するといって差し支えないでしょう。

WordPressを導入します」という制作会社は少なくはないですが、正直WordPressの導入ぐらいなら個人でできるぐらいの範囲だと思います。 その先の深く突っ込んだところ(カスタマイズや適切なセキュリティ対応)などが難しいところであると個人的には思っています。

制作会社への依頼に関しては、その会社の力量を把握した上で行ったほうが良いと言えるでしょう。

2. 異なる二つの仕組み ~動的と静的~

CMSツールには、配信方法の仕組みが異なる、動的と静的という方式があります。 まずは、二つの違いについて説明します。

動的

コンテンツのデータをデータベースに蓄積し、 Webサイトへのアクセスに応じて、コンテンツの出力内容を生成する仕組み。

静的

CMSに登録したデータをもとに静的なHTMLをあらかじめ生成し配信する仕組み。

それぞれの特徴や違い

f:id:webcreatorsstruggle:20200518174105p:plain

情報配信

情報配信の速さで言うと、動的なものの方が速く配信できます。静的は、情報が更新されたタイミングでHTMLなどのファイルを生成し、その後配信という動作を取るため、情報更新から配信完了までにラグが発生します。 素早く世の中に情報を発信したいという観点だと、動的の方に軍配が上がります。

レスポンス

レスポンスは、仕組み上できあがったものを表示させているだけの静的に比べると、アクセスの都度表示内容を生成する動的の方が遅くなります。

EC/会員サイト&表示の出しわけ

動的の場合には、EC/会員サイトなどのユーザーがアクションを起こすようなサイトも実現可能です。 静的では、そのような仕組みを導入する場合には、別のシステムを導入したり開発したりする必要があります。

動的に関しては、ユーザーの情報をDBに蓄積して、表示の出しわけなどを行うことも可能です。

セキュリティ

セキュリティの観点から言うと、動的なCMSは静的なCMSに比べ仕組み上、セキュリティ的な攻撃を受ける可能性が高いです。 攻撃対象となるシステムがフロントの公開サーバーにあるので、仕組み上仕方がありません。 静的なCMSは、CMSサーバーと公開サーバーで分けて管理をすることができる(CMSサーバーから公開サーバーへHTML等のファイルを配信する)ので、攻撃対象となるシステムを公開サーバーに設置をしなくても済みます。 上記のような観点から、静的なCMSの方がセキュリティには堅牢と言えます。

どう選ぶべきか

動的と静的では、仕組み上大きく違うため、できることや優位性がかなり異なります。

静的なCMSでは、ECやSNS等の会員サイトやユーザーごとの情報の出しわけができないため、そのようなシステムの導入を検討しているのであれば、動的なCMSを導入した方が良いと思います。カスタマイズのしやすさや、CMS上で全ての情報を一元管理できるので、普段の運用更新の効率も変わってくると思います。

また、動的なCMSはセキュリティ上静的なCMSに比べて、弱くなる傾向にあるので、EC・SNS・情報の出しわけなどはせずに、尚且つセキュリティを担保したい場合は、静的なCMSから選定するのが無難だと思います。(レスポンスも早いですし)

「動的な仕組みはサイトに欲しい、でもセキュリティは堅牢に担保したい。」 という場合には、静的なCMS+別システム導入というのもアリだと思います。 動的なCMSを導入すると、サイト全体が攻撃対象となりえますが、静的なCMS+別システムだと、別システムの部分のみが攻撃対象となるため、脅威となる範囲が限定的になり、セキュリティリスクが下がります。

ただ、コストは動的なCMSを導入した場合に比べると、初期構築・運用保守的な観点からも高くなります。コスト感と何を重視するのかのバランスが重要だと思います。

3. CMS選定のポイントのまとめ

ライセンス形態と動的・静的の仕組みの違いの観点から選定のポイントを説明しました。

オープンソース or 商用」× 「動的 or 静的」という選択肢の中で、状況に合ったものを選択するだけでも、選定候補のCMSツールを絞り込む事ができると思います。

説明した種類の他にも、「スケーラビリティ(規模感)」も追加の条件に入れて絞り込めば、更に自分たちに合ったものの絞り込めると思いますので、自分たちに合ったCMSを導入できるように上記のような観点から選定してみてはいかがでしょうか。

Webサイトリニューアルにおける「要件定義」の勘所 vol.1

Webサイトリニューアルにおける「要件定義」の勘所いついてなるべく具体的に記載、紹介していきたいと思います。

 

 

大まかな前提条件 

はじめに

要件定義、要件開発に関する記事、書籍は多くありますが(当然ながら特にシステム開発関連が多いですが)、ここではWebサイトのリニューアルに限定した要件定義の内容や進め方について、これまでの経験を元に、私なりにまとめていきたいと思います。

Webサイトについては今は、新規につくる場合のほうがレアケースかと思われるため、リニューアルにおける「要件定義」としています。

また、リニューアルの規模感によっても当然内容は変わってきますが、想定としては3ヶ月から1年程度の期間で行うリニューアルを想定した内容となります。

受託案件(発注側からは外注する)の想定となりますが、発注側、受注側双方の目線で記載しますが、基本受注側(制作者側)の内容として記載していきます。

対象サイトについて特に限定するものではありませんが、なんらかの『企業サイト』を想定しています。

  

Webサイトリニューアルについて

多くの企業サイトの場合、3年から5年くらいでサイトの全面または一部リニューアルが行われる場合が多いかと思います。場合によっては、10年など長期利用となっていることも案外遭遇します。

Webサイトリニューアルの目的は様々ですが、企業としてはリニューアルの結果として以前より、より利益が上がる(売り上げが上がる、経費が下がるなど)ことが目的となるかと思います。

(目的と書きましたが、利益自体が企業の本来の目的ではない点に関しては、ドラッカーの「利益とは、企業が事業を継続・発展させていくための条件である。明日さらに優れた事業を行なうためのコスト、それが利益である。」であるかと)

 

Webサイトリニューアルの全体の流れについて

要件定義といってもどこまで何を「要件定義」の中で行うかは『定義』によってきますが、全体としては以下の流れ、ステップでWebサイトをリニューアルする前提としています。

構築の流れ
  1. RFP【提案依頼書】(クライアントが提示)
  2. 提案【提案書】
  3. 戦略策定【戦略策定書】
  4. 要件定義【要件定義書】
  5. 設計・計画【各種設計書】
  6. 構築・テスト・リリース【実装されたサイト、テスト結果報告書】
  7. 運用【マニュアル】

※かっこ【】内は主なアウトプット
※見積書作成、スケジュール作成などはもちろん別途行う
※別途基本契約、個別契約の中で機密保持や瑕疵担保責任知的財産権の帰属は定める想定とする

 

 要件定義書の中にもリニューアルの目的も記載は必要となりますが、経営戦略や企業としてどうしていくか、課題はなにがあり、あるべきはどうなるかについては、戦略策定の中で実施する想定となります。(KGI、KPIの策定含め)

そのため、この記事内には含んでいませんので、別の機会にRFPや戦略策定についてもまとめたいと思います。

 

受発注(契約)とそのタイミングについて

ウォーターフォールモデルを想定しています。

Web制作会社側としての受注の範囲については上記「構築の流れ」の全体の場合もあれば、2から5や、3から5などの場合もあるかと思います。(発注側の社内で実施している場合や、コンサルティング会社で実施済の場合など)

理想的には構築のステップ毎に発注をもらうことだと思います。なぜなら、上のステップが終わらないかぎり次のステップでの費用が本来確定しないからです。

また、RFP・戦略策定・要件定義までは準委任契約が望ましいです。

(とはいえ、請負契約となることも多いかとは思います。)

RFPと運用については基本契約は別れると思いますが、それ以外については一括契約となることもあります。

ただ、一定規模以上の案件であればせめて、要件定義までとその後の設計・構築については契約を分けて行うことは必須かと思います。

 

なお、企業の予算確保の関係で、事前にWebサイトリニューアルに関わる予算全体を発注元の企業内で承認をうける必要があるため、通常RFPを元に受けて提案(提案書・概算見積書)を元に予算確保が行われると思います。

※この時点では『概算』ですが、ここが実質予算上限になったりすることもあります。

 

要件定義とは

要件定義・要件開発とは何か

要件定義とはクライアント(発注元・顧客)の望んでいるサイト・機能をまとめることです。

システムでどうするかということもありますが、どういったことが出来る必要があるか、したいかをまとめるものです。

『定義』というとすでに望んでいる明確なものがあって、それをまとめるイメージですが、実際にはクライアント自身も明確に網羅的にすべての要件をもっているわけではなく、聞くだけで作成できるものではありません。

そのため『要件開発』と呼ぶことが適切とする場合もありますが、ここでは以降も一般的な『要件定義』と呼びます。

また、要件定義をまとめた書類を【要件定義書(RDD / Requirement Definition Document / business requirements document)】と呼びますが、本記事では要件定義書でまとめていく内容とそのまとめ方、クライアントとの確認・調整方法について記載していきます。

 

要件定義の目的

クライアントとWeb制作会社の『認識のズレを最小化する』ことです。

ひいては、クライアント内、Web制作会社内でも認識のズレを最小化することができます。

なお、極論として認識のズレが発生しない場合、発生した場合の影響が(費用、期間的にも)無視できるレベルであれば、要件定義は不要です。

例えば、クライアントから全幅の信頼があり、費用と期間以外はすべておかませで好きなようにやってよい場合や(クライアントの協力は結局必要ですが)、リニューアルの規模自体が極端に小さい場合ゆあ、実施する内容がすべて明確な場合であれば、見積書内に記載する前提条件レベルで要件定義としても大きな問題はないとは思います。

が、実際このような場合はあまりないので、やはり要件定義は必要となるでしょう。

また、書類だけがあればよいというものではなく、それがクライアントに伝わり認識されていなければ意味がありません。(契約としては、「ここ」に書いているのでで済ませられる可能性もありますが、クライアントは納得できない状態となり、プロジェクトとしてはうまくいかないことになります。)

書類単体としてもわかりやすく理解できるように作成する必要はありますが、クライアント担当者の知識レベルや知っている業務の範囲も様々だったりするため、ひとつづつすべての内容は説明する機会が必要です。担当者だけでは判断できない部分がある場合は関連するメンバーをあつめて説明をおこない認識のすりあわせと、内容調整を行う作業を必要に応じて繰り返す必要があります。

 

要件定義で何をどこまで定義するか

 『認識のズレを最小化する』ためには、漏れなく、より細かく定義が必要ではありますが、費用や期間の制約は当然ありますので、何をどこまでどのように定義するかは事前に定めておかないと進められれない、期間に収まらないことになりがちです。

要件定義の結果としては設計フェーズ以降の正式な見積書を作成できる必要がありますので、ブレのない見積書ができるところまでを定義する必要があります。

要件定義はクライアントの要件ではありますが、制作会社側としては「やること・やらないこと」を明確にすることで費用、期間が確定できます。

要件定義の際に、「できる・できない」の確認が発生することもありますが、極論としてはなんでも要件の定義としては「できる」となります。

※現実世界でできること、法律上できることであれば。

もちろん定義の結果としては、費用や期間に影響がありますので、設計以降の予算やリニューアル予定日が決まっている場合であれば、予算上、期間上できない・現実的ではないということは多くあると思います。

そのため、優先順位や期間については複数ステップを検討するなど、全体としての計画も必要となります。

 

なお、認識のズレは設計を行っても、実際の構築してすべて完成したもので確認して調整したとしてもズレはどうしても出てきますので、ゼロにすることはまず当然不可能ですが、大きな問題、手戻りが発生しないように、制作会社側としては事前に推測できることについては定めていく必要があります。

 いつまで要件定義書を更新するか

構築の流れの中で「3.要件定義」でおこない、いったんの完了(納品)となりますが、その後流れで要件定義に関わる部分が変更となる場合もあると思います。

変更が発生しないように定義出てきることが望ましくはありますが、サイトのリニューアル公開までについては、必要な場合は要件定義書に戻って更新することが望ましいでしょうか。

当然、紐づいて費用やスケジュールが変更になってきますが、双方(クライアント、制作会社)が合意していれば問題はないため、変更内容にあわせて要件定義についても更新していくべきです。

要件定義書を基準にできるため、追加・変更なのか、もとからの要件なのかも後から確認できるものになっているはずです。

※要件定義を更新していないと、実際の状況とことなり認識のズレの要因になるためです。

 

顧客が本当に必要だったもの

有名な風刺画があります。知っている方も多いと思います。

Webサイトのリニューアルやシステム開発の行ったことがある人(特に制作会社側の人である程度の経験がある人)であれば、笑えて・笑えない絵です。

そして程度の違いこそあれ、多少なりともこれに近いことを経験している人も多いと思います。

f:id:webcreatorsstruggle:20200522010934g:plain

顧客が本当に必要だったもの

※いろんなパロディがあって面白いが、その筋に詳しくないと理解できない

 

繰り返しとなりますが、上記のような状況とならないために認識のズレを最小化するために重要となってくるのが、上流工程ともよばれる戦略策定と要件定義となります。

 

 要件定義で決める内容

 要件定義書の目次

要件定義書の中の目次は以下のように定義します。

  • 全体概要
    • プロジェクトの目的
    • Webサイトリニューアルの背景と目的
    • 目標・評価達成指標
    • コンセプト
    • リリース予定日
    • 概要スケジュール
    • 納品物
  • プロジェクト対象範囲
    • 対象ドメイン
    • 対象コンテンツ
    • 対象システム
  • 機能要件
    • 利用システム・サービス
    • 機能一覧
    • 機能詳細
  • 非機能要件
    • 可用性
    • 性能・拡張性
    • 運用・保守性
    • 移行性
    • セキュリティ
    • 環境・エコロジー

 ※非機能要件の項目についてはIPAの非機能要求グレード*1の内容にあわせています。

要件定義書を何でつくるか

ワードでもパワーポイントでもエクセルでもなんでも良いと思います。

クライアントとより確実に認識のすりあわせができれば良いと思います。

細かなマトリクス情報なども一部必要なため、エクセルの資料も必要となる場合が多いとは思います。

また、資料は1つでなくとも状況に応じて複数になる形でもよいと思いますが、一式(ワンセット)として要件定義を管理する必要があります。 

要件定義の進め方

RFPと戦略策定が終わったあとの想定となりますが、まずは要件定義書を作成していく上で必要となる情報集めをする必要があります。

要件定義書としてどのような物となり最終的な納品物として何ができるか事前にクライアントに説明できるのが望ましいです。

全量をテンプレートにしたサンプルを定時するか、ざっとドラフト版の全量要件定義書を作って定時する方法もあります。

ヒアリングや受領した資料からわかる範囲を記載し、あとは規模や内容から制作会社側が経験上最適と推定できる内容で一度定義してしまう形がよいと思います。

その上で、クライアントに内容を確認してもらいその後、説明(レビューのMTG)を行う機会を設けてすべての内容について全量説明しつつ想定や実施したいことと合っていないか確認していく必要があります。

詳細についてはそれぞれのポイントないでも記載していく予定です。

 

要件定義作成にあたってリクエストする情報・資料

これから紹介していく内容でも定義をしていきますが、事前にクライアントにリクエストしておくべき資料について以下に記載します。(クライアントに用意があればですが)

  • アクセス解析結果の情報(Google Analyticsのアカウントなど)
  • Google Search Consoleなどのアカウント
  • 現状のページ一覧
  • 現状の各種設計書
  • 現状のインフラ構成
  • 現状のネットワーク転送量
  • 現状のサーバ内ファイル一式・データベース

 

 

ここまでで、vol.1は以上となります。

次回は、要件定義書の全体概要について紹介していきます。

CMSにおける業務効率化~HTMLメルマガ配信システムの構築~

企業のWeb担当者が抱える問題

企業のWeb担当者の業務の1つに、定期的なメールマガジンの配信があります。 しかし、多くの担当者は「週に1回、メールマガジンを配信する」という作業自体が目的となってしまい、メールマガジンの中身にまで頭が回らなくなってしまうことが多い。

その理由は、Web担当者の業務の範囲が非常に広いから。 例えば、「プレスリリースや新商品をサイトに掲載する」ことで、Webサイトを最新の状態に保つことに加え、「掲載コンテンツを制作する外注先とのやりとりや進行管理」「新たなコンテンツを作成するための企画立案」「サイトの効果測定を行い、コンバージョンを上げるための施策を検討」「SNSを活用して、より自社を知ってもらうための啓蒙活動を行う」など、多岐にわたる業務を行っています。 また、Web担当者は「営業企画部」「マーケティング部」などの肩書を持ち、Webサイトに関係する業務以外にも業務を抱えていることが多い。 そうなると、週に1回、新規でメールマガジン用のコンテンツを用意するのは、非常に難しくなります。 しかし、毎週目新しい情報を届けてくれる有益なメールマガジンだと認識されないと、ユーザはメールマガジンを読んではくれない。 だからこそ、定型化できる部分はすべて定型化し、毎週同じ作業を繰り返す手間を減らして作業を効率化することで、コンテンツを考える時間や配信結果を考察する時間を確保する必要があるのです。  

CMSでの業務効率化

所属の会社で構築するCMSは、コンテンツを複数の場所、複数の見た目で表示できるよう、適切な粒度(サイトでのデータの最小単位)を検討し、情報を一元管理するよう設計されています。 一元管理しているからこそ、管理画面で1箇所のデータを更新することで、そのデータを表示している複数のページが一括で更新される仕組みとなっているのです。わざわざ複数ページで同じ情報を更新しなくて良いため、業務効率化に繋がるだけでなく、掲載漏れや記述ミスなども防止できます。

f:id:webcreatorsstruggle:20200518181127p:plain

この仕組みを応用することで、Webサイトとはまったく違うデザインのHTMLメールマガジンであっても、粒度さえ揃えてしまえば、CMSのコンテンツを流用することで、メールマガジンを簡単に作成することも可能です。 HTMLメールが正しく表示されない人のためのWebページも同様です。作成したメールマガジンの出力形式を、HTMLメール用のテンプレートから、Webページ用のテンプレートに変えて自動生成するようにすれば良いのです。これで、HTMLメールとWebページのそれぞれを作成する手間が省けます。

f:id:webcreatorsstruggle:20200518181140p:plain

結果として、運用するWeb担当者に時間の余裕が生まれ、別の業務に時間をあてられることとなるでしょう。  

事例

実際に、メールマガジンの配信システムと連携を行い、CMSで管理しているコンテンツを流用して、メールマガジンの作成を行うシステムの構築を行いました。 運用者の作業は、メールマガジンに掲載したいコンテンツをCMSで選択し、配信日時を設定するだけ。また、CMSの管理画面から配信予約、配信後の開封率の確認までを行えるよう構築しました。 これにより、運用者はCMSの管理画面にのみログインすれば、すべての作業ができます。別のシステムへログインする手間もなくスムーズに運用できるのです。

f:id:webcreatorsstruggle:20200518181158p:plain

まとめ

重要となるのは、CMS構築時に適切な粒度の設計を行い、データを保持すること。 それさえできていれば、後からメールマガジンを配信する仕組みを構築することとなっても、CMSで管理しているサイトの情報を用いることができるのです。 そして、この考え方は、メールマガジンだけでなく、レコメンド機能や、MAツールでのコンテンツ配信などにも応用できます。 CMSを最大限に活用することで、様々な業務効率化が成し得られるのです。

UXで押さえておきたいポイント

1. スマートフォンファーストの概念

スマートフォンサイトから制作したからといって問題解決はできない

“とにかくスマートフォンサイトを作ってください” “スマホサイトがあれば大丈夫”。 こういった声をよく耳にします。 もちろんスマートフォンサイトに注力を注ぐのは当然ですが、問題はそれをどうやってなし得るかです。これは、ただスマートフォンサイトを作るだけでは解決できません。近年、実際にスマートフォンからのアクセスが激増しているサイトは多いでしょう。 しかし、将来どのようなデバイスが現れるかはわかりません。ただ、今後どのようなデバイスが現れようとも、「ユーザーにとって本当に必要な情報や機能は何なのか?」「それをどのデバイスで利用するのが最適なのか?」と常にユーザー視点で考えながら、Webサイトを構築する「お客さまのニーズへの最適化」ことこそが一番重要だということです。

スマートフォン対応するのではなく、お客様のニーズに最適化すること

スマートフォンは、既にPCに代わるデバイスになりつつあります。だから、スマートフォンファーストはあくまでも「お客様のニーズ最適化が最大の目的」になります。 スマートフォンの利用シーンは、もはやモバイルだけではありません。もしかしたら、近い未来では「PCでも閲覧可能です」と説明しているかもしれません。 スマートフォンの普及でPCサイト中心だった利用形態は劇的に変わったが、ユーザーの多くがスマートフォンの利用に慣れ親しんだことで、それ以外のさまざまなデバイスにおいてもスマートフォンと同様の「使い方」を生み出すことになりました。 つまり、閲覧方法や必要なコンテンツの大部分は、スマートフォンと同様であれば問題がないという状況になりつつあるのです。そこで、あえてここではスマートフォンでのみユーザーニーズの最適化を行い、そのコンテンツや構造を他のデバイスに展開することをスマートフォンファーストと呼んでいます。

どこでも、どんな時でも、誰にでも、簡単に

インターネットが出現してから幾度となくユーザーニーズは変化してきました。その変化は常にユーザーニーズの変化に依存することを肝に銘じてください。 スマートフォンがこれほど普及すると予測できた人は、ほとんどいないはずです。 言い換えると、これから新たなデバイスが登場して普及したとしてもなんら不思議ではないということです。テレビ、ゲーム機、時計が、インターネットとユーザーの新しい接点になるかもしれないということです。 こうした現状を鑑みれば、スマートフォンだけに対応するのではなく、お客さまのニーズに最適化することが、これからのWebサイト構築の肝となるということです。そして、デバイスごとのテンプレートを用意して、一元管理されたコンテンツを配信するというCMS的な概念が、もっとも合理的な対応手法であると理解できるはずです。 モバイルに限らず、お客さまのインターネットでの接点となるデバイスでは、以下の4つのキーワードを実現する必要がある。

  • どこでも
  • どんな時でも
  • 誰にでも
  • 簡単に

これまでは、PCサイトが利用できる限定的な場所だけを想定しておけば十分でした。しかし、これからは電車の中からでも、車内からでも、旅先からでもアクセスが可能になる。つまり、ユーザーのシチュエーションを理解することが必要になるし、そのうえでアクセスしているデバイスに最適化された情報を提供しなければなりません。 その際利用するお客さまのリテラシーやインターネットへの理解には期待してはいけません。インターネットの常識や、知識がなければ利用できないようなサービスは、意味がなくなる。普通の人が普通に利用できる、そんなサービスを提供しなければならないのです。 これまでのインターネットの常識である「ユーザーが探す」という行為でさえ、変えていかなければならない。探してもらうのではなく、こちらが必要なものを選んで提供する。つまり少ないクリックとシンプルな導線による自然な連動が必要不可欠になるのです。

2. 大規模サイトでのユーザー導線設計の手順

大規模なサイト程、はじめから完璧な導線設計をするのは難しい

Webサイトのユーザー導線設計を考える際に、ナビゲーションやサイト全体の導線設計を先にしてしまうことがあると思います。テキストや画像などを仮置きの状態で導線設計をしても、結局は手戻りが増えてしまったりして正しい導線設計ができていなかったりします。特に、大規模サイトになればなるほど、はじめから完璧な導線設計をするのは難しいはずです。しかし、正しい導線設計をすることでユーザーをゴールへ導くことが可能となります。そのためには、ゴールを明確にしWebサイトにとって必要な導線を洗い出す必要があるのです。

入口と出口を定義し、それらを結ぶ導線のパターンを発見すること

導線設計を整理するポイントは、ユーザーの入口と出口を定義し、それらを結ぶ導線のパターンを発見することです。そのニーズに基づいた導線設計は、まず「キーワードの洗い出し」から始めることが重要です。

例えば、ホテルのWebサイトの場合です。 ・駅周辺に泊まりたいけど、ホテルの情報は? ・ホテルのレストランで食事がしたいけど、どんな料理があるの?ランチもやってるのかな? ・結婚式を考えているけど、何人まで?料金は?婚礼サービスとかあるかな? 考えられるであろうシナリオに沿って必要なコンテンツを洗い出し、優先順位を決めます。 Webサイトの成功は、ユーザーが必要としている情報をいかに早く、いかにわかりやすく、いかに快適に提供できるかにかかっています。まずは、お客様の問題をしって、Webサイトで何をやるかを検討することが必要であるといえるでしょう。 所属している会社では、ユーザー体験シナリオにもとづき、ユーザーのニーズ別にシナリオを構造化することで、ユーザーが迷わずに目的の情報へ遷移できるWebサイト構造が実現できています。

シナリオに沿って必要なコンテンツを洗い出し、優先順位を決める

「ただ情報を掲載しておけばよい」という時代ではなく、ユーザーに対して「いかに価値あるサービスを提供できるか」が重要です。 つまり企業Webサイトにとって、ユーザー(=顧客)が抱えている問題を解決して満足させることが目標であり、その満足体験の積み重ねがユーザーの感じる企業価値の向上につながります。 ユーザーが得たい情報を得たい順で目に留まるよう、洗い出したキーワードを入り口として、お客さまに最適なコンテンツや表示する順番を明確にしていく。これで、必要なコンテンツの優先順位も明確になるはずです。

3. 大規模サイトでのUI改善の方法

UIは良質なUXを実現するための重要な要素のひとつにすぎない

UIは、一般的に、わかりやすいレイアウト、読みやすい文章、使いやすいボタン、 ・クリック(タップ)できるのか ・クリック(タップ)したら何が起こるのか ・どこに情報があるのか ・このページはどこにあるのか ・この言葉はどういう意味なのか と言われたりしています。 製品であれば製品そのものや外観など、 ユーザーの視覚に触れる全ての情報が「UI」と呼ばれます。 UXは、「アプリの使用により、これまで時間のかかっていた作業が簡単に終えられた」「Webサイトのおかげで欲しかった情報が手に入った」といった体験はもちろん、 「説明が読みやすいと感じた」「見た目が美しくて気持ちが安らいだ」「動作が遅くイライラした」など、使用によりユーザーに生じた感情もUXの一つと言われています。 ネット上にあるUI・UXを調べてみても文献や考察は人それぞれで、概念のようなものが多いのです。概念や考え方では具体性がなく誰にも分らないモノになってしまいます。この「使いやすさ」を定義するのはかなり難しいものです。また、UIだけが優れていても、それだけで良質なUXを実現することはできません。

例えば、旅行サイトのデザイン性や、操作性が優れていたとしても、そこに載せられているコンテンツの中身が魅力的でなければ、旅行サイトとしてのUXは良質なものとはならないということです。

大きなUI改善は、ユーザーにとって反感や違和感が生じる

デザインの一新はユーザーにとって、慣れるまでに一定の反感や違和感が生じることがあります。

“今のインターネットユーザーは、別段インターネットが好きではない”ということです。今までのユーザーは、インターネット自体が好きで、Webサイトを見たり情報を探すことが楽しかったはずですが、 今では、趣味でネットサーフィンをする人はほとんどいない。 ユーザーが求めているのは、美しいグラフィックやグリグリ動く動画ではなく、ほとんどの場合は、 “欲しい情報を素早く、クリックせずに入手したい。” これがユーザーのニーズであり、Webサイトはそれを解決しなければならない。ユーザーがサイト内でリンクを何回もクリックして情報を探してくれると期待してはいけません。 何が良くて何が悪いかは、ユーザーに使ってもらうまで正解が出せませんし、時代の変化によって新しい端末や操作方法が登場し、その正解さえも変わっていくためです。 一度サイトを公開したら、そこからがスタート。少しずつUIを改善して変化に対応していかなければいけないのです。

大規模サイトこそ、基本のデザイン4原則をしっかりと守る

デザインには基本中の基本となる「4大原則」があります。 Webデザインに限らず、デザインの基本となる法則です。

  • 近接 Proximity
  • 整列 Alignment
  • 強弱 Contrast
  • 反復 Repetition

この4つは「レイアウトのコツ」だけではなく、見た目以外のデザインの役割、「思考・概念を組み立てる」という部分に密接に関係しています。 そして、この基本をルール化した上で、コンポーネントという概念にしっかりと落とし込むことで、どんな大規模サイトでも徹底したルールに基づいたサイト構築が可能となります。 コンポーネントとは 文書構造を定義して、一定のフォーマットでWebサイト全体の見やすさ、文字の読みやすさを担保するものです。 さらに、CMSを利用してコンテンツ単位の管理を行うことで、コンテンツの一元管理、さらには One to Oneによる出し分けも有効に実現することができます。 つまり、コンテンツ有効利用の為の概念なのです。

所属している会社におけるUIは、コンポーネントという、考え方が基本になります。 このコンポーネントという考え方が徹底されているからこそ、サイトの統一やユーザビリティに効果が発揮されます。 このように、文書構造を定義して作成したコンポーネントを積み上げてサイト制作をすることで、 ユーザーにとって、わかりやすいレイアウト、読みやすい文章、使いやすいボタンを与えることができる。ということです。

まとめ

ページ単位でグラフィックに対する要望を細かくする指示することは、時にWebサイトの方向性や、ユーザーにとっての使いやすさ、運用更新性の考慮がなされていないこともあります。 グラフィックデザインが、Webデザインの要素の1つであることは間違いないですが、成果に影響するものではありません。 Webデザインにおいてももっとも重要なのは、「お客様のニーズへの最適化」であることを覚えておいてください。

2020年のマーケティングオートメーション(MA)有効活用術 vol.1

マーケティングオートメーション(MA)の有効活用するための方法についてのポイントを紹介していきます。

目次

マーケティングオートメーション(MA)について

マーケティングオートメーション(MA)の概要

マーケティングオートメーションツール(MAツール)とは、大枠としては『マーケティング業務の自動化や効率化行うツール』です。

2020年現在では日本でもマーケティングやWebサイトにかかわる大部分の人には名前としては認知されるようになってきた状況かと思われます。 また、各マーケティングオートメーションのツール提供会社のブログやマーケティング関連の会社で出している記事も多くあり、得られる情報や事例はとても増えている状況です。

そのため、本記事では主要な「マーケティングオートメーションとは」や必要性、出来る機能などの紹介は割愛し、有効活用のためのポイントや考え方を中心にご紹介してきます。

マーケティングオートメーション(MA)の現状

既にマーケティングオートメーションを導入している企業も増えており、特に大企業の場合なんらかツールはすでに導入済みとなっている場合が多いようです。 企業の内部事情や、すでに利用しているツールなどの兼ね合いからか場合によっては複数のマーケティングオートメーションが利用されている(Webサイトのタグとしては埋め込まれている)ような状況も比較的多く見受けられてきています。

ツール自体の市場規模としては年々増加している状況です。 2020年予想でMAのみで670億円ていどの市場規模予想となっているようです。

矢野経済研究所調べ

Yano ICT | DMP(データマネジメントプラットフォーム)/ MA(マーケティングオートメーション)市場に関する調査を実施(2019年)

 利用率や活用も増えてきていることに比例して、実際に効果が出ている、有効活用できている企業も徐々に増えてきているのではないかと思われます。 しかしながら、感覚としてはまだまだ有効活用できていない、実際にマーケティングオートメーションとして利用でできていないような場合が多いように思われます。 当然ながら、ツールがマーケティング活動自体をオートメーション化してくれるものではないた、人がツールへの対応および会社として顧客を呼び込むための対応自体については別途必要となります。

MAツールは導入しているが有効活用できていない例としては、

  • メール配信機能としてのみ利用している
  • 問い合わせフォームとしてのみ利用している
  • Webでの行動のログのみを取得している

などが上げられます。 (とりあえずでツールのみ導入して、利用できそうな最小限の機能だけ使っている場合など)

他のツールを利用した場合でも費用は発生するため、大手の企業様であれば単機能として利用してもそこまで費用対効果が悪くないという判断もできるものかとは思われますが、本来のマーケティングオートメーションツールとしての利用価値としては微妙なところです。

マーケティングオートメーション(MA)ツールの現状

日本でのシェアの参考としては以下となります。 実際の数値(感覚的な数値)とすこし慣れている部分はありますが、海外製大手ツールと日本ベンダーのツール利用それぞれシェアがある状態のようです。

日本でのシェア Datanyze

https://www.datanyze.com/market-share/marketing-automation--3/Japan

f:id:webcreatorsstruggle:20200518004623p:plain
Marketing Automation Share

主に利用されているMAツールとそこでのマーケティングオートメーションとはなどの紹介記事(MAツールでも重要となるコンテンツマーケティングの関連で各ツール開発元ではブログ記事が用意されているため、商品サイトではなく、マーケティングオートメーションの紹介記事)にリンクしています。

Hubspot blog.hubspot.jp

Marketo (Adobe) jp.marketo.com

Pardot (Salesfores 記事ページ不明) www.salesforce.com

Oralce Marketing Cloud (記事ページ未発見) www.oracle.com

ListFinder(記事ページ未発見 promote.list-finder.jp

BowNow (mtame) mtame.jp

SATORI satori.marketing

Karios3 blog.kairosmarketing.net

B-Dash bdash-marketing.com

Cloud CMO(Innova) innova-jp.com

マーケティングオートメーション(専用?)ツール以外に関しても、マーケティング関連を含むサービス、ツールに関してはそれぞれ機能強化などにより同じようなこととが実現できる場合もあります。 メール配信サービスやフォーム作成サービス、レコメンドサービスなどもMAツールと同様の機能を備えている場合もありますので、実際に利用する機能に適切なツールを検討することも必要となってきます。

なお、近似ツールとして営業支援のSFAや、顧客化後の顧客との関係性を管理するCRMなど近似ツールもあります。 他、DMP・CDPなどのツールについてもOne To Oneマーケティングという部分においては同じ用途で利用できる部分となります。

MAとDMPを連携すうる場合もありますが、MAにもDMPの一部機能を保持していたりするため、導入の際は混乱する(どのツールをどう利用するか、またはすでに導入していた場合のすみわけをどうするかなど)こともあるかと思います。

マーケティングオートメーション(MA)利用の課題

主な課題としては以下が上げられます。

  • 社内で使いこなせる人がいない
  • 初期導入の設定のままとなっている
  • KGI,KPII設定がなされていない
  • 社内での対応するチームが存在しない

デジタルマーケティングの必要性、重要度から導入までは行ったが、その後のサイクルを回せていない(有効的には回せていない)ことがあるかと思われます。

マーケティングオートメーション(MA)の有効活用の考え方

当然ながら、MAツールはOne To Oneマーケティングとして利用してこそ有効活用ができます。 一括でほぼ同じ対応でよければ、これまでのメルマガ配信なり、定期的な電話営業なりの近タンクをとった対応で十分と判断されてしまいがちです。 MAツールでは、見込み顧客を顧客化することをサポートしてくれると考え以下にサポートしてもらうところを増やすかをポイントに対応していくことが効率的です。

マーケティングオートメーション(MA)における見込顧客(リードジェネレーション)獲得方法

MAツール以前の話となりますが、見込顧客の獲得が必要となります。

  • セミナー、展示会
  • 名刺
  • ウェブサイトからの問い合わせ

何もせず、MAツールを導入しただけでは、見込顧客は一切増えないため、見込顧客を増やすための施策については別途対応が必要です。

Webサイトでの対応としてはベターなところではオウンドメディア構築やSEO対策となります。

とはいえ、コンテンツがなければ活用することもできません。 次回、第2回(vol.2)としては自社サイトまたはオウンドメディアに訪れる人を増やすためのコンテンツ作成のポイントを紹介していきます。

ECサイトにオウンドメディアは不要

モノの飽和

今日、日本国内のECサイト出店数は100万店舗を超えるといわれており、 店舗の売り上げを確保するためには、価格以外のバリューを提供することが必要不可欠である。 これに対し、SEO対策やコンテンツの量産などで流入を増やす施策をとる企業が多く、 Webに携わる人間であればコンテンツマーケティングはもはや馴染みの単語になった。 しかし、その量産されたコンテンツは本当にユーザーが求めるコンテンツだろうか。

コトの飽和

先日、暮らしの情報サイトnanapi の更新停止が発表された。 2009年にリリースされ、コンテンツマーケティングブームの火付け役となったサービスだ。 サービス停止の流れはnanapiに限った話ではなく、名の知れたメディアサイトも次々と閉鎖されている。ブームが起きたために、発信するコンテンツに似通ったものが既にインターネット上に存在している、ということが珍しくなくなってきたのだ。では、コンテンツマーケティングが通用しなくなったかというと、私はそうではないと考える。

メディアだけがコンテンツマーケティングの形では無い

コンテンツマーケティングで一番に優先すべき課題は徹底的なセグメンテーションである。 誰のために何を届けたいのかが明確でないメディアではユーザーの心に響くことはないだろう。当然流入を増やすことができれば、これまで来ていなかったユーザーにリーチできる可能性が高まるので、売り上げが上がる可能性がある。 しかし、それが最短ルートだろうか。ユーザーにバリューを提供することが目的であり、流入を増やすことが目的ではないのだ。 コンテンツマーケティングと聞くと条件反射的にオウンドメディアを想起してしまうのはブームの弊害だろう。 コンテンツマーケティングでは、ユーザーの行動変容が大きく4つのプロセスでわけられており、 「認知段階」「調査・理解段階」「比較・選択段階」「リピート・口コミ段階」 と進んでいく。 ブームに乗じてサービスを開始した多くのメディアが影響を及ぼす範囲は認知段階だ。そして、 ユーザーに認知してもらうためには、ユーザーニーズだけでなく、競合・SEOも考慮する必要があるため、最もコストがかかる段階でもある。  

投資をするなら出口に近いところから

オーディオ界隈では「投資をするなら音の出口に近いところから」という定石がある。コンテンツマーケティングにこれを当てはめると、高い運用コストを払い続けながら必死に間口を広げるより、出口に近い部分から作用していくのが売り上げ増加の一番の近道、ということになる。例えば、商品を文字から想像できる範囲には限界がある。動画コンテンツを用いて比較・選択段階のユーザーに商品を購入した疑似体験を提供することで、 文字だけでの説明ページよりもクロージング力を高めるといった施策の方が効果は出やすいだろう。 オウンドメディアの効果が出るまで試行錯誤を続けるよりも、まずはすぐに効果の期待できる部分からコンテンツマーケティングの第一歩を始めるべきではないだろうか。

最高のWebサイト開発リーダーになるための五ヶ条

f:id:ChigusaSatoh:20200807162113j:plain

自己紹介

みなさま、はじめまして。佐藤千草と申します。 CMSコンテンツマネジメントシステム)および関連するシステム開発の提案、見積、要件定義、設計、実装、テスト、公開、運用を行うエンジニアとして勤務しています。 入社当初より開発チームのリーダー格として、入社以来14年間で26件のプロジェクトを担当しました。 また予算に応じて開発メンバーをアサインしスケジュールを立案する開発進行管理業務もおこなっています。 2016年より現在まで、社内新人研修「CMS構築手法」講師も担当しています。

このコラムの対象者

このコラムは、何かしらのシステム開発に従事している方、とくに現場でのリーダー役を務めておられる方を対象としています。 さらにその中でも、WebサイトやCMSにかかわっておられる方であれば、本コラムをより身近に感じていただけるかと思います。

このコラムを執筆する理由

このような文章を世に出すきっかけとなったのは、22年間のエンジニア生活を経て、いま「これだけは絶対に譲れない」「これをなしえないと情熱を持って仕事に取り組むことはできない」と考えていることを、私と同じくシステム開発に携わっている方に広くお伝えすることができればと思ったからです。 単なる技術Tipsやハウツーではなく、Webエンジニアが発信する、エンジニアのための、エンジニアとしての仕事への取り組み方についてお伝えしていきたいと思います。 ですからWebサイトやCMSの開発者に限らず、それ以外のシステム開発者の方にも、ぜひご一読いただければ幸いです。

連載について

このコラムは5回の連載を予定しています。

  1. あなたのお客さまは、上司でもクライアントでもなく、サイトを訪れるお客さまである
  2. あなたは、クライアントのためではなく、サイトを訪れるお客さまのために開発をすべきである
  3. あなたは、目の前のタスクだけでなく、ヒト・ジカン・カネを毎日意識すべきである
  4. あなたは、誰かが動く前に、いち早く自分で動くべきである
  5. あなたは、自分のチームメンバーの短所を嘆くのではなく、長所を活かして最大の成果を出すべきである

今回は連載第一回目ということで、早速お届けしたいと思います。

あなたのお客さまは、上司でもクライアントでもなく、サイトを訪れるお客さまである

突然ですが、あなたの開発するシステムは「成果」をあげていますか?

え?成果って何?と思われた方は、ぜひこの先をご一読ください。 上司やクライアントの言われた通りにやってるよ!問題ないよ!という方も、できれば最後まで読んでいただけると嬉しいです。

成果とは、プロジェクトでなし得なければならないゴールです。 何を成果とすべきかは、プロジェクトのスタート段階で、定量的および定性的に具体化されるべきものです。 Webサイト構築プロジェクトであれば、例えば以下のように定義されます。

  • Webサイトでの売上拡充   Web上での売り上げを3年後に1.5倍とする

  • 新規顧客層の獲得   40代女性顧客層を獲得する

さらに、その目的をなしえるために実施すべき施策、つまりプロジェクトの「目標」についても、実施時期を含めて明確に定義されます。 目標の一例を記します。

STEP1

  • コンテンツ・サービスの追加・改善
  • デザイン・UI・UXの改修

STEP2

さて、あなたのチームのプロジェクトはいかがでしょうか。 もしあなたが成果や目的・目標を認識していないのであれば、あなたの仕事は、もしかしたらプロジェクトの目指す目的から外れてしまっているかもしれません。 なぜならば、成果を意識していないということは、そのシステムを使うお客さまが何を求めているかということを一度も考えたことがない、あるいはそんなものが存在すること自体を認識していないのとイコールであるからです。

上司やクライアントが要求してくることをやり遂げることが成果なんじゃないの? 上のほうで決まったことなんて自分が考える必要ないんじゃない? と思われた方、もう少しだけお付き合いください。

あなたの上司やクライアントが、プロジェクトの正しいゴールに向かって進んでいれば、おそらく大きな問題はないでしょう。 ただ、悲しいことに、そうとは限らないのが現実です。 いくつかの例をあげてみましょう。

成果をあげられないクライアントのウィークポイント

とにかく運用を楽にすることしか考えていない トップダウン部署で自分たちがサイトをこうしたいという考えがない

成果をあげられないプロジェクトマネージャーのウィークポイント

顔がクライアントやさらに上の上司にしか向いていない クライアントのお客さま、つまりサイトを利用するユーザと向き合っていない

さて、それでは一体どうしたらいいのでしょうか。

まずは、毎日の仕事のひとつひとつをこなすたびに、以下のことを意識してみてください。

  • プロジェクトの目的・目標を意識する
  • サイトがお客さまに提供しなければならないコンテンツ、サービス、ソリューションを意識する

もしあなたがWebサイトやCMSの開発者なのであれば、あなたのお客さまは、上司でもクライアントでもなく、サイトを訪れるお客さまなのです。 プロジェクトの成果を意識するかどうかによって、あなたの開発するプロダクトの質は驚くほど違ってきます。 なぜならば、サイトがお客さまに提供すべきコンテンツ、サービス、ソリューションがなし得られていれば、サイトに対するお客さまの満足度は間違いなくアップするからです。 そして、それは「アクセス解析結果」という数値になって証明されます。 あなたのものづくりが、プロジェクトの成果を左右するのです。

プロジェクトの目的を「自分ごと」に考えて仕事をしてみてください。 「成果を出せるかどうか」が自分の中で明確な判断基準となってくるので、上司やクライアントにお伺いを立てなければならない機会が減り、仕事における決断が早くなります。 そうなれば、今までよりも多くの仕事を、クオリティ高くこなせるようになってきます。 仕事に対するモチベーションも必ず上向きになってくるでしょう。

それではまた次回お会いしましょう。

まとめ

なぜ、あなたのチームが開発するCMSは成果をあげられないのか?

「お客さまが何を求めているか」を理解していない、またはそんなもの自体を認識していないから

成果をあげられないクライアントのウィークポイント

とにかく運用を楽にすることしか考えていない トップダウン部署で自分たちがサイトをこうしたいという考えがない

成果をあげられないプロジェクトマネージャーのウィークポイント

顔がクライアントやさらに上の上司にしか向いていない クライアントのお客さま、つまりサイトを利用するユーザと向き合っていない

CMSの成果をあげるためにやるべきこと

  • プロジェクトの目的・目標を意識する
  • サイトがお客さまに提供しなければならないコンテンツ、サービス、ソリューションを意識する