CMS導入でつまずくのは、要件定義のせい？──制作会社の視点で読み解く、“機能する要件定義”のつくり方

Webサイト制作には、何かしらの目的があるはずです。その手段としてCMSを導入する場合、ゴールを達成するための最適なCMSを選び、実装したうえで、継続的に運用していくことが不可欠です。

理想は、導入企業と制作会社が共有した見解のもとで進めていくことです。そのために、双方の認識にズレが生じないように方針を明確にする工程が「要件定義」です。サイト運営の目的や運用体制、更新頻度やセキュリティ要件など多岐にわたる判断軸を洗い出し、要件定義にまとめていくことが求められます。

今回、WordPressやMovable Typeからハイエンドクラスまで、多数のCMS案件を長年手がけている株式会社モノサスが運営するコーディングファクトリーのメンバーへのインタビューを行いました。現場のリアルを反映した、“機能する要件定義”のつくり方を探っていきます。

現場のリアルとは？　CMSの要件定義にまつわる誤解

──まずは、CMS導入を検討するクライアントと要件定義を巡って折衝する際、現場でよくあるケースについて教えてください。

龍田祥拡（以下、龍田）　CMSの認知はかなり広がっているので、Web制作にあまり慣れていない担当者の方でも、「CMSを使いたい」という前提で制作会社に問い合わせをいただくことは多いですね。

ここでは、大規模案件でハイエンドなCMSを扱うケースよりも、小中規模の実装案件でWordPressやMovable Typeなどを検討される場面のほうが、身近でイメージしやすいかもしれません。

ただ一方で、CMSを導入すれば「どんなことでも簡単にできる」と誤解されているケースも一定数あります。たとえば、「複雑なデザイン調整もボタン1つでできる」と考えられていたり、「実装さえしてくれれば、更新やデザイン修正はすべて自社で対応できる」といった認識を持たれていることもあります。

──更新以外の作業も容易にできる、という誤解ですね。

龍田　はい。CMSには向き・不向きがあります。たとえば、ニュースの更新や、多数の製品情報ページを条件分岐しながら表示すること、自社データを一元管理する用途には向いています。

一方で、CMSを導入するとテンプレート化が前提になるため、デザインの自由度には一定の制約が生じます。以前よりは減りましたが、今でもその点を十分に理解されていない担当者の方はいらっしゃいますね。

畑峯豪（以下、畑峯）　開発現場の視点を加えると、管理画面の仕様も重要なポイントです。編集画面をブロックエディタにするのか、リッチテキストエディタにするのか、あるいはカスタムフィールドを使うのか。ここを事前にすり合わせておかないと、認識のズレが起きやすくなります。

曖昧なまま進めると、納品後に「思っていたものと違う」「操作できない」といった不満につながりかねません。理想を言えば、エディタの種類ごとに実際に動かした状態を見せながら説明するのが望ましいですね。

──管理画面は運用時に必ず触れる部分です。互いに「当たり前」と思い込まず、きちんと確認する必要がありますね。

畑峯　もう1つ、RFP（提案依頼書）の段階では、CMSの定期的なバージョンアップやメンテナンスといった、いわゆる「非機能要件」が抜け落ちがちだと感じます。

設計前にどれほど細かく「要件」を「定義」できるものなのか？

──では、実際に要件定義を詰めていく過程について教えてください。企業からCMS導入を含むサイト制作の相談があった場合、どのように進めて要件定義へまとめていくのでしょうか。

龍田　問い合わせの段階でよくあるのは、クライアントが用意したRFPに「製品情報ページにCMSを導入したい」といった要望が書かれているケースです。基本的には、そのRFPをもとにヒアリングを行い、洗い出した内容を整理して要件定義にまとめていきます。

ただ、制作が本格化する前の段階で、CMS導入の具体的なイメージまで固まっており、それが要件定義に十分反映されているケースは、正直それほど多くありません。

──要件定義の時点では、定義しきれない部分が残るということですね。

龍田　そうですね。要件定義を踏まえて設計フェーズに入り、実際につくり始めてから、クライアント側のイメージが具体化し、新たな要望が出てくることが多いからです。「管理画面がこうなるなら、この機能も欲しい」といった具合ですね。

その場合は、「どうすれば予算内で実現できるか」という観点で調整を行います。

──実装側としては、「最初に言ってほしかった」と感じることもありますか。

龍田　正直に言えば、そう思うこともあります（笑）。ただ一方で、要件定義の段階ですべてを細部まで詰め切るのは酷だとも感じています。

たとえば、「CMSはWordPressで、ニュースページを更新できるようにしたい」といったところまでは決めておいてほしいですが、管理画面の細かな仕様については、次の設計フェーズで詰めていけば十分でしょう。

──要件定義では「何をするか（What）」を明確にし、「どう実現するか（How）」は設計フェーズで調整する、と。

龍田　はい。理想を言えば、設計段階で出てくる追加要望に備えて、想定予算の1.5倍程度を見込んでいただけると、より柔軟に対応できますね（笑）。

──予算に余白を持たせておくことで、当初想定していなかった要望にも対応できる余地が生まれますね。

畑峯　わかりやすい例が、ワークフローの承認機能です。この機能は、CMSによっては標準プランでは対応できず、データベース設計や権限管理を伴うため、実装コストが高くなります。

ただ、事前に検討しておけば概算見積もりは出せますし、「予算超過になるので今回は見送る」といった判断も早い段階で可能になります。

龍田　明らかに事前の予算感を超える要件や、根本的な作り直しが必要な場合は「できない」とお伝えします。一方で、工夫次第で実現可能な要件もあります。そのためにも、こうした話し合いを要件定義の過程で行えるのが理想ですね。事前に洗い出せていれば、設計フェーズ以降での支障も起こりにくくなります。

CMSの実装に最適な「要件定義」の練り上げ方とは？

──では、現場のリアルを踏まえた「要件定義」は、どうつくるといいでしょうか？

龍田　「要件定義」とは、「最低限、決めておかなければプロジェクトが前に進まないこと」を事前に洗い出し、方針を決めておく工程だと考えています。CMSを実装するうえでは、その「最低限」は、いわばシステムの骨子にあたる部分です。

──その「最低限」は、どのように整理していけばいいのでしょうか。制作会社への問い合わせが最初の接点だとすると。

龍田　クライアント側が用意しているRFP（提案依頼書）をもとに、制作会社がヒアリングを行います。RFPがない場合でも問題はありません。
そこでまず確認するのが、サイトの目的です。CMS導入がその目的に対して妥当だと判断できれば、次に目的に適したCMSの選定と、どのような運用体制で臨むのかを整理します。この2点は、最低限決めておいてほしいところですね。

たとえば、運用体制にソースコードを書ける人がいるのであれば、コード編集が可能なCMSも選択肢になります。一方、社内にエンジニアがおらず、ソースコードが何か分からないメンバーで運用する場合は、ノーコードで編集できるCMSに絞って検討するのが現実的です。

──運用体制の構成や、メンバーのスキルセットを整理するわけですね。予算に大きく影響する機能の有無についても、要件定義段階で決めておくべきでしょうか。

畑峯　設計フェーズに入る前に、ある程度は整理しておきたいですね。加えて、私の実感としては、セキュリティや保守に関する方針もあわせて共有しておくことは大事ですが、要件定義の時点ではあまり細かいところまでやりすぎなくても大丈夫だと感じています。

セキュリティや拡張性は、細部より「方向性」を明記する

──セキュリティ要件については、どのように扱うのがよいのでしょうか。

龍田　CMSのセキュリティを考えるうえでは、サーバインフラの管理権限が関わってきます。サーバを、クライアントの情報システム部が管理している場合もあれば、別会社が担っているケースもあります。その中で、実装側がどこまで責任を持つのか。いわゆる責任分界点を明記することは重要です。

──要件定義の段階では、細部ではなく大枠の方針を押さえる、ということでしょうか。

龍田　そうですね。細かな仕様については、設計フェーズを進めながら調整するのが現実的です。
要件定義では、トラブルが起きた場合の責任の所在や管理体制について、方針の合意を得ておくべきでしょう。

たとえば、WordPressを導入する場合であれば、「採用するプラグインはすべて報告し、承認を得る」といったルールを方針として明記しておく、といったイメージです。

畑峯　セキュリティ面で社内にリスクを抱えたくなかったり、運用負荷を下げたいという場合には、MovableType.netのようなSaaS型CMSを選択する判断も有力だと思います。

──将来を見据えたスケーラビリティや、API連携、データ移行といった要件についてはいかがでしょうか。

龍田　これらについても、要件定義段階で厳密に想定しておく必要はないでしょう。
設計前の段階で、CMSの拡張や乗り換えについて細かく決められるケースは、実際のところそれほど多くありません。

我々のようなベンダーフリーの立場で相談を受けた場合は、「一般的に流通しているCMS」を勧めることが多いですね。制作会社が独自に開発したCMSを否定するわけではありませんが、ベンダーロックインが起こりやすいのも事実です。

仮に、独自CMSを開発した制作会社が廃業した場合、その後のメンテナンスや保証が宙に浮いてしまう可能性があります。そうしたリスクは、できるだけ避けたいと考えています。

CMS導入側と実装側が一緒になって要件定義を仕上げていく

──要件を細かく定義できるのが理想とはいえ、設計フェーズに入る前の段階で定義できる範囲には限界がある、ということですね。

龍田　そのとおりです。課題に適したCMSを選ぶこと、そして運用体制を決めること。この2点が押さえられていれば、制作会社側は概算見積もりを出せますし、搭載可能な機能に対する予算感も見えてきます。
おおよその制作スケジュールも立てられますし、適切な制作メンバーのアサインも可能になります。

──最後に、クライアントと制作会社が揉めないためのコツを教えてください。

龍田　要件定義後の設計フェーズで決まる仕様を、「CMS設計書として必ずドキュメントに残す」こと自体を要件にしておくこと。そして、その要件を要件定義書に記載しておきましょう。

設計フェーズでは、Webサイトの表側だけでなく、管理画面といった裏側の設計にも必ず目を向ける必要があります。表側については、ワイヤーフレームを作成し、「この箇所にこの機能を搭載する」「タイトルはこのように表示される」といった点を明示します。

裏側についても、どのような管理画面になるのかを実際に見せながら説明し、クライアントの合意を得ることが重要です。その合意内容は、きちんとドキュメントとして残しておくべきでしょう。

畑峯　サイトマップに沿った確認も重要です。「どこにCMSを導入するのか」「どこはデザインを重視したページにするのか」といった切り分けを、確実にすり合わせておくことが大切です。

龍田　人事ローテーションなどで、たまたまWeb担当になった方も多いと思います。RFPをつくるだけでも大変ですし、まして要件定義となると、ハードルは高いですよね。

そうしたときこそ、Web制作会社というプロフェッショナルをうまく頼って、相談しながら一緒につくり上げていってほしいと思います。

取材・文：遠藤義浩