最高のWebサイト開発リーダーになるための五ヶ条【第二回】
みなさまこんにちは。佐藤千草です。
「最高のWebサイト開発リーダーになるための五ヶ条」連載第二回目です。
今回のテーマはこちら。
あなたは、クライアントのためではなく、サイトを訪れるお客さまのために開発をすべきである
ケーススタディ
例えば、あなたの担当するCMS開発プロジェクトで、ワークフロー機能（コンテンツの作成から公開までの業務フローをCMSシステム上で実現する機能）を実装することになったとします。
クライアントと担当ディレクターで取り決めたワークフロー設計書には、以下のように定義されていました。
- CMSを利用するユーザは、コンテンツを編集できる「編集者」と、コンテンツを公開できる「承認者」の２種類の権限が必要。
- 「編集者」がコンテンツを作成・更新し、「承認者」に承認依頼を流す。
- 「承認者」がコンテンツのサイト表示をプレビューで確認し、承認操作を行うことで、コンテンツがサイト上に公開される。
担当ディレクターはあなたにこの設計書を渡し、こう伝えました。
「クライアントと仕様を詰めましたので、この設計書の通りに実装をお願いします。」
そこであなたは実装にとりかかろうとしましたが、ふとひとつの疑問が生じました。
「承認者」は、本当に「コンテンツを公開できる」権限だけを持っていればよいのか？
承認前に自らコンテンツを微修正してから公開したいケースもあるのではないか？
そもそも「承認者」が自身でコンテンツを作成・更新して、そのまま公開するケースはないのだろうか？
この疑問をディレクターに投げかけてみたところ、返事はこのようなものでした。
「クライアントからはそういう要望は特になかったですね」
「この設計書でクライアントに承認もらっちゃってるんで、この通りの仕様でお願いします！」
さて、あなたならどうしますか？
対応A
クライアントと直接やり取りをしているディレクターがそういうならと、「承認者」には「コンテンツを公開できる」権限しか付与せず、「コンテンツを編集できる」権限は付与しなかった。
対応B
ローンチ後にクライアントが運用に困ることがあるかもしれないと考え、クライアントにもう一度仕様をご確認いただくようディレクターに依頼をした。
対応Aを選択したあなたへ
ここであえて対応Aの是非を論じることはしませんが、起こりうる事態を推測して仮説を述べます。
あなたが対応Aを選択した理由は以下のようなものです。
「クライアントも特に要望しなかったって言うから、『承認者』にコンテンツ編集権限を持たせないのは、クライアントが本当に望んでいたことかもしれない」
「そもそも仕様を決める役割なのはディレクターだし、万が一あとでクライアントが困ったって自分のせいじゃない」
さて、サイトが公開され、実際にCMSをさわりはじめて、クライアントは初めてその運用のしづらさに気づきました。
そのクライアントは、あなたの会社に対して
「確かに取り決めた設計通りにはなってるけど、あまりにも気がきかなさすぎじゃない？」
「仕様の再確認や、改善提案をしてくれても良さそうなものなのに…」
と不満を抱くことになってしまいました…
ここであなたの会社に対して明確にクレームを入れてくれるクライアントなら、わざわざ時間を割いて「不満を持っている」ことを教えてくれているのですから、まだよいほうだと思わなければなりません。
制作者にとって一番怖いのは、クライアントの「声なき不満」に気づかないことです。
その不満は蓄積され、結果的に大きな仕事の受注機会を失うことだってあり得ます。
対応Bを選択したあなたへ
あなたは自分の役割だけにとらわれず、担当外のことでも「自分ごと」に考えることができているようです。
そんなあなたには、是非もう一歩先に進んでいただきたい。
実は、選択肢に挙げなかった「対応C」が存在します。
対応C
コンテンツの微修正に至るまで差し戻しが必要な運用であれば、それによってコンテンツの公開が遅れる可能性もある。
CMS運用が滞れば、サイトを訪れるお客さまに対して最適なタイミングで最適なコンテンツを提供することができない。
従って、是非とも改善しなければならない旨、ディレクターに説明のうえ、クライアントへの説明と仕様変更の承認を依頼した。
「クライアント最適化」を超えて「お客さま最適化」へ
ディレクターに対してアクションを起こすという意味では、対応BとCは同じです。
しかしながら、対応Bは「クライアントのため」の行動、対応Cは「サイトを訪れるお客さまのため」の行動です。
「改善しないと運用が不便になります」
ではなく
「改善しないとサイトを訪れるお客さまへのコンテンツ提供が滞ることになります」
と伝えることができれば、クライアントへのインパクトもより大きく、理解と承認を得やすくなります。
こういった対応の積み重ねによって、「クライアント最適化」を超えて「お客さま最適化」されたCMSが完成します。
この「お客さま最適化」実現のためには、第一回でのべた
- プロジェクトの目的・目標を意識する
- サイトがお客さまに提供しなければならないコンテンツ、サービス、ソリューションを意識する
が大前提となります。
Webサイトのすべてのコンテンツ、サービス、ソリューションは「サイトを訪れるお客さまのため」に存在しています。
お客さまのニーズを把握してはじめて、ひとつひとつの機能について、何をどのように実装すべきかの方向性が明確に決まってきます。
そのことを忘れずに日々の仕事に取り組むことで、クライアントは「あの会社は常に我々のお客さまのことを考えて対応してくれる」と認識し、あなたの会社の価値を高めてくれることでしょう。
それではまた次回お会いしましょう。
まとめ
なぜ、あなたのチームが開発するシステムはクライアントに喜ばれないのか？
サイトを訪れるお客さまにまで意識が向いていないから
- クライアントやディレクターの認識がぶれていても気づかずにそのまま実装してしまう
- 改善を提案したとしても、必要性へのインパクトが弱く、提案を通すことができない
お客さまに最適化されたシステムを実現するためにやるべきこと
- 「クライアント最適化」の一歩先「お客さま最適化」を意識する
- クライアントやディレクターの指示や設計がそこからぶれていれば指摘し、お客さまのためにどのような実装をすればよいか提案する
CMS組み込み前提HTML構築手法
テンプレート＆コンポーネント化
所属している会社では、全てCMS適用前提でのHTMLを作成します。 CMSのページはブロックパーツと呼ばれる部品と、テンプレートで成り立っています。 コーダーはこの2つを主に作成しています。
CMSに乗せるためには、パーツを汎用化させる必要があります。 そこで有効なのがアトミックデザインの概念になります。
アトミックデザインとは、最小の粒となるエレメント（原子）を組み合わせコンポーネント（分子）を構築し、コンポーネントを組み合わせテンプレートを作成する手法です。
エレメント
とは、見出し、画像、本文、リンク等の部品１つ１つを指します。
とは、エレメントを組み合わせ人が読み理解できる構造にしたものです。CMSのブロックパーツはこれを指します。
テンプレートはコンポーネントの集合体となり、１つのページ（コンテンツ）となります。 コンポーネントで気をつけなければならない点は、積み上げパターンを想定する事です。 ブロックパーツはお客様の要望次第で自由に形を変え積み上げられます。
そのため、エレメントの段階からあらゆる積み上げパターンを考慮し空きの担保や崩れが無いかを検証します。
デザインから読み解く力
昨今の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種類存在します。
ネット上などで公開されており、 誰でも自由に使用、複製、改変、再配布などが可能なシステム。 ネット上のコミュニティで運用・保守を行っている。
商用
特定の企業が開発し、販売を行っているシステム。複製、改変、再配布はできない。 企業で運用・保守を行っている。
それぞれの特徴や違い
機能・カスタマイズ・コストについて
オープンソースはライセンス費用が無償で、誰でも使おうと思えば直ぐに利用を開始するこ とができます。無償であり、素早く導入することができるのがメリットです。
カスタマイズ性が高い反面、商用のものに比べると標準機能が乏しく、 CMSの導入の際に、コミュニティ等で提供されるプラグインを導入したり、独自でカスタマイズを実施することで、目的に対して最適化することが多いです。
ライセンス自体に費用は掛かりませんが、カスタマイズにかかる費用が、商用のものより比較的高くなる傾向にあります。
オープンソースは無料だからという理由で導入したけど、カスタマイズしていったら、結局カスタマイズ分のコストが高くなり、想定よりも予算をオーバーするというのも十分にあり得る話です。
費用を低く抑えたいという場合にも、単純に費用が無償なオープンソースを選ぶのではなく、機能が豊富な商用も比較の上、選ぶべきだと思います。
商用
オープンソースが無償で、標準機能が乏しいのに対して、基本的に商用は有償で標準機能が豊富な場合が多いです。
オープンソースに比べるとカスタマイズを許容していないケースが多いです。 独自タグを利用したカスタマイズを一部許容している場合もありますが、JavaやPHPなどのプログラム言語を用いた開発はできず、限定的な範囲のみしか触ることができない場合が多いです。
標準機能が多いので、それで賄えるのであればコストパフォーマンスが高く構築できると思われます。
セキュリティについて
セキュリティに対しては、商用に比べるとオープンソースは自分たちで調査・対応していく能力が必要になってきます。
オープンソースは基本的には提供企業によるサポートを受けることができません。 （一部企業によっては、有料サポートを実施していることはあります。） セキュリティに関する対応などについても、基本的には自己責任となってきます。 自分たちで調査し対応をしていく、もしくは制作会社への依頼などが必要になってきます。
基本的には、コミュニティ内でパッチ提供などは実施されるので、提供されたパッチをCMSへ適用すれば良い事が多いのですが、それも自分で調査をして対応をする必要があります。
また有志の方々が開発して提供してくれるプラグイン等に関しては、途中で開発は止まってしまい脆弱性が放置されるような自体も少なくはありません。
保守されていないプラグラインなどを導入してしまった場合には、適切にセキュリティ対策を実施するのであれば、それらを自分達でどうにかしなければいけません。
プラグインの導入などに関しては、開発コミュニティが活発に動いているのか等の判断をした上で行ったほうが良いと思います。 闇雲に導入すると、後処理が大変になります。
セキュリティの観点からすると、適切に対応できるエンジニアがいないのであれば、オープンソースはあまりお勧めできません。
商用
オープンソースに比べると、商用の方がセキュリティにおいては安心できる面が多いです。
商用は提供元の企業がプログラムの運用保守を行っているため、オープンソースのような、急にプログラムが運用保守されない状態になるようなことがありません。 （提供元企業が倒産すると、また話は変わってきますが…）
セキュリティに問題がありパッチ適用が必要になった場合などでも、企業側でサポートしてくれます。自分たちで調べなくても問い合わせをすれば答えてくれる分、対応が楽と言えると思います。
商用は、企業が継続的にシステムを運用保守しており、不明点があれば適切にに教えてくれるので、セキュリティの観点から見れば、安心感は高いと言えるのではないかと思います。
どう選ぶべきか
オープンソースは良くも悪くも、開発者のスキルに大きく依存します。 優秀なエンジニアが運用・保守するのであれば、柔軟性にも富み、コストパフォーマンスも高く運用構築できるとは思いますが、そうでないのであれば、商用を利用するほうが苦労も無く安心できる面が多いと思います。
商用CMSはカスタマイズ性が低いものが多いので、カスタマイズをしないと、本来の目的を達成できないような場合、合致するものが商用でないという場合には、オープンソースを選ぶしかないと思います。
もし制作会社に任せるような場合には、オープンソースに関しては、かなりその会社のシステム開発スキルに依存するといって差し支えないでしょう。
「WordPressを導入します」という制作会社は少なくはないですが、正直WordPressの導入ぐらいなら個人でできるぐらいの範囲だと思います。 その先の深く突っ込んだところ（カスタマイズや適切なセキュリティ対応）などが難しいところであると個人的には思っています。
制作会社への依頼に関しては、その会社の力量を把握した上で行ったほうが良いと言えるでしょう。
2. 異なる二つの仕組み ～動的と静的～
CMSツールには、配信方法の仕組みが異なる、動的と静的という方式があります。 まずは、二つの違いについて説明します。
動的
コンテンツのデータをデータベースに蓄積し、 Webサイトへのアクセスに応じて、コンテンツの出力内容を生成する仕組み。
静的
CMSに登録したデータをもとに静的なHTMLをあらかじめ生成し配信する仕組み。
それぞれの特徴や違い
情報配信
情報配信の速さで言うと、動的なものの方が速く配信できます。静的は、情報が更新されたタイミングで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サイトについては今は、新規につくる場合のほうがレアケースかと思われるため、リニューアルにおける「要件定義」としています。
また、リニューアルの規模感によっても当然内容は変わってきますが、想定としては３ヶ月から１年程度の期間で行うリニューアルを想定した内容となります。
受託案件（発注側からは外注する）の想定となりますが、発注側、受注側双方の目線で記載しますが、基本受注側（制作者側）の内容として記載していきます。
対象サイトについて特に限定するものではありませんが、なんらかの『企業サイト』を想定しています。
Webサイトリニューアルについて
多くの企業サイトの場合、３年から５年くらいでサイトの全面または一部リニューアルが行われる場合が多いかと思います。場合によっては、１０年など長期利用となっていることも案外遭遇します。
Webサイトリニューアルの目的は様々ですが、企業としてはリニューアルの結果として以前より、より利益が上がる（売り上げが上がる、経費が下がるなど）ことが目的となるかと思います。
（目的と書きましたが、利益自体が企業の本来の目的ではない点に関しては、ドラッカーの「利益とは、企業が事業を継続・発展させていくための条件である。明日さらに優れた事業を行なうためのコスト、それが利益である。」であるかと）
Webサイトリニューアルの全体の流れについて
要件定義といってもどこまで何を「要件定義」の中で行うかは『定義』によってきますが、全体としては以下の流れ、ステップでWebサイトをリニューアルする前提としています。
構築の流れ
- RFP【提案依頼書】（クライアントが提示）
- 提案【提案書】
- 戦略策定【戦略策定書】
- 要件定義【要件定義書】
- 設計・計画【各種設計書】
- 構築・テスト・リリース【実装されたサイト、テスト結果報告書】
- 運用【マニュアル】
※かっこ【】内は主なアウトプット
※見積書作成、スケジュール作成などはもちろん別途行う
※別途基本契約、個別契約の中で機密保持や瑕疵担保責任、知的財産権の帰属は定める想定とする
要件定義書の中にもリニューアルの目的も記載は必要となりますが、経営戦略や企業としてどうしていくか、課題はなにがあり、あるべきはどうなるかについては、戦略策定の中で実施する想定となります。（KGI、KPIの策定含め）
そのため、この記事内には含んでいませんので、別の機会にRFPや戦略策定についてもまとめたいと思います。
受発注（契約）とそのタイミングについて
ウォーターフォールモデルを想定しています。
Web制作会社側としての受注の範囲については上記「構築の流れ」の全体の場合もあれば、2から5や、3から5などの場合もあるかと思います。（発注側の社内で実施している場合や、コンサルティング会社で実施済の場合など）
理想的には構築のステップ毎に発注をもらうことだと思います。なぜなら、上のステップが終わらないかぎり次のステップでの費用が本来確定しないからです。
また、RFP・戦略策定・要件定義までは準委任契約が望ましいです。
（とはいえ、請負契約となることも多いかとは思います。）
RFPと運用については基本契約は別れると思いますが、それ以外については一括契約となることもあります。
ただ、一定規模以上の案件であればせめて、要件定義までとその後の設計・構築については契約を分けて行うことは必須かと思います。
なお、企業の予算確保の関係で、事前にWebサイトリニューアルに関わる予算全体を発注元の企業内で承認をうける必要があるため、通常RFPを元に受けて提案（提案書・概算見積書）を元に予算確保が行われると思います。
※この時点では『概算』ですが、ここが実質予算上限になったりすることもあります。
要件定義とは
要件定義・要件開発とは何か
要件定義とはクライアント（発注元・顧客）の望んでいるサイト・機能をまとめることです。
システムでどうするかということもありますが、どういったことが出来る必要があるか、したいかをまとめるものです。
『定義』というとすでに望んでいる明確なものがあって、それをまとめるイメージですが、実際にはクライアント自身も明確に網羅的にすべての要件をもっているわけではなく、聞くだけで作成できるものではありません。
そのため『要件開発』と呼ぶことが適切とする場合もありますが、ここでは以降も一般的な『要件定義』と呼びます。
また、要件定義をまとめた書類を【要件定義書（RDD / Requirement Definition Document / business requirements document)】と呼びますが、本記事では要件定義書でまとめていく内容とそのまとめ方、クライアントとの確認・調整方法について記載していきます。
要件定義の目的
クライアントとWeb制作会社の『認識のズレを最小化する』ことです。
ひいては、クライアント内、Web制作会社内でも認識のズレを最小化することができます。
なお、極論として認識のズレが発生しない場合、発生した場合の影響が（費用、期間的にも）無視できるレベルであれば、要件定義は不要です。
例えば、クライアントから全幅の信頼があり、費用と期間以外はすべておかませで好きなようにやってよい場合や（クライアントの協力は結局必要ですが）、リニューアルの規模自体が極端に小さい場合ゆあ、実施する内容がすべて明確な場合であれば、見積書内に記載する前提条件レベルで要件定義としても大きな問題はないとは思います。
が、実際このような場合はあまりないので、やはり要件定義は必要となるでしょう。
また、書類だけがあればよいというものではなく、それがクライアントに伝わり認識されていなければ意味がありません。（契約としては、「ここ」に書いているのでで済ませられる可能性もありますが、クライアントは納得できない状態となり、プロジェクトとしてはうまくいかないことになります。）
書類単体としてもわかりやすく理解できるように作成する必要はありますが、クライアント担当者の知識レベルや知っている業務の範囲も様々だったりするため、ひとつづつすべての内容は説明する機会が必要です。担当者だけでは判断できない部分がある場合は関連するメンバーをあつめて説明をおこない認識のすりあわせと、内容調整を行う作業を必要に応じて繰り返す必要があります。
要件定義で何をどこまで定義するか
『認識のズレを最小化する』ためには、漏れなく、より細かく定義が必要ではありますが、費用や期間の制約は当然ありますので、何をどこまでどのように定義するかは事前に定めておかないと進められれない、期間に収まらないことになりがちです。
要件定義の結果としては設計フェーズ以降の正式な見積書を作成できる必要がありますので、ブレのない見積書ができるところまでを定義する必要があります。
要件定義はクライアントの要件ではありますが、制作会社側としては「やること・やらないこと」を明確にすることで費用、期間が確定できます。
要件定義の際に、「できる・できない」の確認が発生することもありますが、極論としてはなんでも要件の定義としては「できる」となります。
※現実世界でできること、法律上できることであれば。
もちろん定義の結果としては、費用や期間に影響がありますので、設計以降の予算やリニューアル予定日が決まっている場合であれば、予算上、期間上できない・現実的ではないということは多くあると思います。
そのため、優先順位や期間については複数ステップを検討するなど、全体としての計画も必要となります。
なお、認識のズレは設計を行っても、実際の構築してすべて完成したもので確認して調整したとしてもズレはどうしても出てきますので、ゼロにすることはまず当然不可能ですが、大きな問題、手戻りが発生しないように、制作会社側としては事前に推測できることについては定めていく必要があります。
いつまで要件定義書を更新するか
構築の流れの中で「3.要件定義」でおこない、いったんの完了（納品）となりますが、その後流れで要件定義に関わる部分が変更となる場合もあると思います。
変更が発生しないように定義出てきることが望ましくはありますが、サイトのリニューアル公開までについては、必要な場合は要件定義書に戻って更新することが望ましいでしょうか。
当然、紐づいて費用やスケジュールが変更になってきますが、双方（クライアント、制作会社）が合意していれば問題はないため、変更内容にあわせて要件定義についても更新していくべきです。
要件定義書を基準にできるため、追加・変更なのか、もとからの要件なのかも後から確認できるものになっているはずです。
※要件定義を更新していないと、実際の状況とことなり認識のズレの要因になるためです。
顧客が本当に必要だったもの
有名な風刺画があります。知っている方も多いと思います。
Webサイトのリニューアルやシステム開発の行ったことがある人（特に制作会社側の人である程度の経験がある人）であれば、笑えて・笑えない絵です。
そして程度の違いこそあれ、多少なりともこれに近いことを経験している人も多いと思います。
※いろんなパロディがあって面白いが、その筋に詳しくないと理解できない
繰り返しとなりますが、上記のような状況とならないために認識のズレを最小化するために重要となってくるのが、上流工程ともよばれる戦略策定と要件定義となります。
要件定義で決める内容
要件定義書の目次
要件定義書の中の目次は以下のように定義します。
※非機能要件の項目についてはIPAの非機能要求グレード*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箇所のデータを更新することで、そのデータを表示している複数のページが一括で更新される仕組みとなっているのです。わざわざ複数ページで同じ情報を更新しなくて良いため、業務効率化に繋がるだけでなく、掲載漏れや記述ミスなども防止できます。
この仕組みを応用することで、Webサイトとはまったく違うデザインのHTMLメールマガジンであっても、粒度さえ揃えてしまえば、CMSのコンテンツを流用することで、メールマガジンを簡単に作成することも可能です。 HTMLメールが正しく表示されない人のためのWebページも同様です。作成したメールマガジンの出力形式を、HTMLメール用のテンプレートから、Webページ用のテンプレートに変えて自動生成するようにすれば良いのです。これで、HTMLメールとWebページのそれぞれを作成する手間が省けます。
結果として、運用するWeb担当者に時間の余裕が生まれ、別の業務に時間をあてられることとなるでしょう。
事例
実際に、メールマガジンの配信システムと連携を行い、CMSで管理しているコンテンツを流用して、メールマガジンの作成を行うシステムの構築を行いました。 運用者の作業は、メールマガジンに掲載したいコンテンツをCMSで選択し、配信日時を設定するだけ。また、CMSの管理画面から配信予約、配信後の開封率の確認までを行えるよう構築しました。 これにより、運用者はCMSの管理画面にのみログインすれば、すべての作業ができます。別のシステムへログインする手間もなくスムーズに運用できるのです。
まとめ
重要となるのは、CMS構築時に適切な粒度の設計を行い、データを保持すること。 それさえできていれば、後からメールマガジンを配信する仕組みを構築することとなっても、CMSで管理しているサイトの情報を用いることができるのです。 そして、この考え方は、メールマガジンだけでなく、レコメンド機能や、MAツールでのコンテンツ配信などにも応用できます。 CMSを最大限に活用することで、様々な業務効率化が成し得られるのです。
