Webサイトリニューアルの要件定義を、発注側が損しない順番で決める
2026.09.28
Webサイトのリニューアルを考えはじめたとき、「まだ何も決まっていなくて」と前置きしてから相談に来られる方が多くいます。要件定義やRFPという言葉が先に耳に入っていて、準備不足だと感じておられるのだと思います。
一方で、公開後に「こんなはずではなかった」となる原因は、デザインや実装の出来ではないことがほとんどです。多くは、要件定義の段階で誰も決めなかった項目が、そのまま残り続けたことから生まれます。
一般には、発注側が要件を固めてから制作会社に相談するのが筋とされます。かいなはそう考えていません。発注側でしか決められないものと、決めずに持ち込んだほうがいいものは、はっきり分かれます。その線引きを先にすることが、要件定義の実質だと考えています。
CONTENS
要件が決まっていない相談は、かいなでは普通のことです
かいなに届く相談で最も多いのは、カートやシステムを替えたいという内容です。ただ、話を進めるうちに別のところへ着地することがよくあります。
「リニューアルしたい」の下に、別の課題が隠れている
現行サイトへの不満は、たいてい症状の形で語られます。更新が面倒、スマホで見づらい、問い合わせが増えない、という具合です。
掘っていくと、原因が別の場所にあることが少なくありません。データの持ち方であったり、ブランドサイトとECが分かれていて読みものから購買までの導線が切れている構造であったりします。
このとき最初の要望どおりに作ると、症状は消えても原因は残ります。半年後に同じ不満が別の形で戻ってきます。
決まっていない状態のほうが、課題を見つけ直せる
かいなは決まった型に当てはめる進め方をとっていません。毎回の対話からその会社だけの課題を見つけ、そこから設計します。
要件が固まっていない段階の相談ほど、この探し直しができます。余白があるほど、当初の要望より良い解き方が見つかる確率が上がります。
ですから、準備が足りないことを気にする必要はありません。気にすべきなのは、次に挙げる3つだけです。
それでも、発注側でしか決められないものがある
制作会社が代わりに決められないのは、目的、社内の優先順位、公開後の体制の3つです。
この3つを外部が埋めてしまうと、見た目は整っているのに誰も更新できないサイトが残ります。公開日が実質的な運用の終わりになってしまいます。
逆に言えば、機能の仕様やページ構成は、決めずに持ち込んで構いません。そこは提案で比べたほうが選択肢が増えます。
発注側が先に決めておくと損をしない順番
決める項目を並べるより、順番を守るほうが効きます。目的、現状の棚卸し、優先順位、体制の順です。順番が入れ替わると、後の工程で必ず戻ります。
最初に決めるのは、何が起きたら成功と言えるか
「売上を伸ばしたい」は目的として粗すぎます。伸ばす経路が決まらないため、作るページも決まりません。
新規の問い合わせを増やすのか、既存のお客様の再訪を増やすのか、採用の応募を増やすのか。経路が変われば、力を入れる場所がまったく変わります。
社内で言葉が割れているなら、そこを揃えるのが先です。見積もりを取るのはその後にしたほうが、比較が成立します。
次に、いまのサイトで何が起きているかを棚卸しする
棚卸しは、ページ一覧、更新履歴、流入の入口、データの置き場所の4つで足ります。細かい解析指標を集める前に、この4つを紙に出します。
見落とされやすいのが更新履歴です。1年以上触っていないページが大半なら、作り直すべきは構造ではなく運用のほうだという判断になります。
この棚卸しは、制作会社に渡す資料としても効きます。現状が見えている会社からの相談は、提案の精度が上がります。
そのあとで、今回はやらないことを決める
リニューアルの要望は、社内で意見を集めるほど膨らみます。全部を盛り込むと、公開後に何が効いたのか分からなくなります。
「今回はやらない」と明記された要件は、提案の質を上げます。制作側が、空けた余白をどう使うかを考えられるからです。
迷ったときは、公開日に必要かどうかで切ります。後から足せるものは後に回して構いません。
最後に、公開後に誰がどのページを触るかを決める
かいなは自社ECを4サイト運営していますが、リニューアルのたびに一番決まらないのが、公開後に誰がどのページを触るかです。
受注処理や出荷までを自分たちで回しているので、サイト上のひとつの仕様が現場の手数に跳ね返ることを身をもって知っています。入力項目を一つ増やすかどうかが、繁忙期の問い合わせ件数に直結します。
担当が決まらないまま公開した領域は、例外なく更新が止まります。体制は要件の付属ではなく、要件そのものとして扱います。
RFPを作ったほうがいい会社と、作らないほうがいい会社
RFP(提案依頼書)は、複数社に同じ条件で提案してもらうための文書です。作れば良い提案が集まるわけではなく、効く場面と効かない場面があります。
RFPが効くのは、比較の軸を揃えたいとき
社内に決裁者が複数いて、なぜその会社を選んだのかを説明する必要がある場合、RFPは役に立ちます。条件が揃っていないと、比較が感想になってしまうためです。
書くのは、目的、現状、制約、体制、進め方の希望まで。機能の仕様は書かなくて構いません。
反対に、1社に相談して進めると決めているなら、文書化の手間は口頭の整理に回したほうが早く進みます。
要件を固めきってから相談するのは、すすめません
かいながお止めすることがあるのは、社内だけで画面仕様まで決めきってから相談に来られるケースです。
決めきった要件には、そのとおり作る以外の提案が入りません。対話で見つかるはずだった課題が、最初から選択肢の外に置かれてしまいます。
とくに危ないのが、現行サイトの不満から逆算して機能を並べた要件です。症状への対処が並ぶだけで、原因に届きません。
固めるのは目的と制約まで。解き方は複数出してもらい、そのうえで選んだほうが、結果として手戻りが減ります。
相見積もりが機能しなくなる条件
社数を増やせば良い提案が集まるとは限りません。条件が曖昧なまま5社に投げると、前提の違う5つの金額が返ってくるだけです。
比較が成立するのは、目的と現状と制約が同じ文面で共有されているときだけだと考えています。
社内で要件がまだ割れているなら、先に2社ほどと話して整理し、そのうえで声をかける範囲を決めるほうが早く着地します。
提案と見積もりが割れたとき、どこを見て判断するか
各社から返ってきた提案の内容も金額も揃わない、という状態は普通に起きます。そこから先の読み方を整理します。
金額の差は、作る量ではなく前提の違いから生まれる
同じ依頼でも金額が割れるのは、含んでいる前提が違うからです。移行するページ数の想定、原稿と写真の担当、既存データの移し替え、公開後の保守の範囲。この4つで各社がずれます。
見るべきは総額よりも、何が含まれていないかの記述です。安い見積もりほど、発注側の作業として残っている量が多い場合があります。
かいなが料金表を出していないのも同じ理由です。何で金額が変わるかを説明しないまま数字だけ置くと、金額の印象だけで判断が終わってしまいます。
決めきるか預けるかの分かれ目は、更新頻度と社内の人数
公開後に週単位で更新する予定があり、社内に担当者を置けるなら、管理画面の操作性と権限設計まで要件に入れます。デザインの自由度を多少削ってでも、更新のしやすさを優先する判断になります。
更新が年に数回で、担当も兼任になるなら、要件に更新性を詰め込まないほうが得です。使われない編集機能にお金を払うことになります。
この場合は、更新を外部に預ける前提を要件に書きます。同じ予算でも、行き先がまったく変わります。
公開日を先に決めるかどうかで、要件の性格が変わる
展示会や新商品の発売に合わせるなら、公開日が動かせない制約になります。要件は「公開日までに何を諦めるか」を決める文書になります。
公開日を動かせるなら、要件は「どこまで作り込むか」を決める文書になります。同じ項目でも、議論の中身が変わります。
どちらが良いという話ではなく、先にどちらかを選びます。両方を動かしたまま進めると、判断のたびにふりだしへ戻ります。
要件が固まる前の状態で、お気軽にご相談ください
ここまで書いてきたとおり、発注側に決めておいていただきたいのは、目的と社内の優先順位と公開後の体制です。機能や構成は、話しながら決めたほうが良いものになります。
かいなは30分の無料相談をGoogle Meetで用意しています。売り込みはしませんので、現状の整理だけを持ち帰っていただいても構いません。
「何から決めればいいか分からない」という段階が、いちばん相談しやすいタイミングです。お気軽にご相談ください。