なぜ1週間で全ページ分のデモが出せるのか
要件定義と発注の実務｜デモで決めるということ 2本目 全4本
目 次
ヒアリングを45分いただいて、1週間後に全ページ分のデモをお出ししています。
速いのは、作業が速いからではありません。決めるべきことを、短い時間で決められるからです。
45分で聞ききれなかった部分は、これまでの案件から補って一度形にし、1週間後のデモの場で答え合わせをします。外れていれば、その場で直します。
1週間で出るのはデモです。公開は1.5〜2か月です
先に、いちばん誤解されやすいところを書いておきます。
| 工程 | 期間 |
|---|---|
| ヒアリング | 45分 |
| デモの作成 | 1週間 |
| デモを見ながら修正 | — |
| 公開まで（合計） | 1.5〜2か月 |
| お願いする打ち合わせ | 初回45分＋その後数回 |
1週間で公開できるわけではありません。
一般的なWeb制作が3〜6か月であることを考えると、2か月でも十分に速いほうだと思っています。ただ、「1週間でホームページができる」という話ではありません。
なお、この45分は、私たちが直接ご相談を受ける場合の時間です。間に別の会社が入っていて先にお話を伺っている場合は、私たちの側は30分ほどで済むこともあります。
全体の日程は要件定義から公開まで、実際のスケジュールを出しますに詳しく書いています。
ヒアリングが45分で足りる理由
聞く項目を減らしているわけではありません。
いちばんよく聞かれるところなので、先に否定しておきます。
普通の制作会社が聞くことは、ざっくばらんに一通り伺います。事業の内容、困っていること、見てほしい相手、予算、時期、今のサイトのこと。特別に短いリストを使っているわけではありません。
それでも45分で終わります。理由は、聞ききれなかった部分を、これまでの案件から補っているからです。
正直に書きますが、褒められた方法ではないかもしれません。全部を聞き出してから作るのが本来の姿だと思います。
ただ、22年・年間40本のペースで作り続けていると、「この業種で、この規模で、この困りごとなら、だいたいこうなる」という蓄積ができます。
特に、私たちが多く手がけてきた建設・工務店、福祉・介護のような領域では、精度が高くなります。
45分の中身については、要件定義のヒアリングは45分です。足りない分をどう埋めているかに書きました。
「うちの業界の実績は?」と思われた方へ
「自分の業界は挙がっていないな」と思われたかもしれません。
正直に書くと、業界の実績があるかどうかで、デモが外れる度合いはあまり変わりません。 数字で検証したわけではなく実感としての話ですが、初めての業界だから大きく外した、という覚えがあまりないのです。
理由は、業界のことは伺えばいいからです。何十年もその業界にいらっしゃる方より、私たちが詳しくなることはありません。
蓄積で補っているのは業界知識ではなく、サイトとしての型です。ページの順番、問い合わせ直前に見られる場所、写真が少ない場合の埋め方。業種が変わっても共通する部分です。
そして初めての業界の場合は、その業界向けの質問を用意してから打ち合わせに臨みます。分かっているつもりがない分、かえって丁寧に聞きます。
この話は「その業界の実績はありますか」と聞かれたときの、正直な答えに詳しく書いています。
補って進めて、大丈夫なのか
外れることはほとんどありません。そして、外れても事故になりません。
理由は、補って終わりにしていないからです。
45分で聞く ↓ 足りない分を、これまでの案件から補う ↓ 1週間後、全ページ分のデモを出す ↓ ここが答え合わせの場 ↓ 外れていたら、その場で直す
回収の仕組みが先にあるから、補っても安全なだけです。補うこと自体が上手いわけではありません。
もしデモを出さずに、補ったまま3か月作り続けたら、それは事故になります。同じことをしても、答え合わせの場がなければ危ないということです。
デモは「たたき台」ではありません
お出しするのは全ページ分です。しかも、文章や写真が入った状態です。
トップページのイメージ画像だけ、というものではありません。
だから、こういう感想をいただきます。
「これで、ほぼ、公開できるよね」
「ほぼ全部できてますよね！」
「このままでもアップできるクオリティですよね」
別々のお客さまの言葉です。 言い方は違いますが、おっしゃっていることは同じでした。
そしてもうひとつ、私たちが嬉しかった言葉があります。
「あのヒアリングで、ここまでできるの?」
驚いていらっしゃる対象が、デモの出来ではなくご自身が話した量だというところです。「あんなに少ししか話していないのに」という含みがあります。
私たちが「お客さまに負担をかけません」と自分で書くより、この一言のほうが正確だと思います。
1週間で形にできる、3つの仕組み
時間の使い方の問題だけではありません。仕組みの側でも支えています。
① 言葉でデザインを決めない
デザインの方向性は、言葉ではなく参考サイトで伺います。他社のサイトでも、他業種のサイトでも構いません。1本あれば十分です。
「シンプルで」「高級感のある」といった言葉は、書くほうも読むほうも真面目に扱います。ただ、思い浮かべているものが一致している保証がありません。
参考サイトなら、そこがずれません。言葉で決めようとしないので、解釈違いの事故がそもそも起きない。 これが1週間で形にできる理由のひとつです。
詳しくはデザイン要件定義書は必要か。参考サイト1本のほうが正確ですに書いています。
② あとから直すのが軽い作りにしてある
私たちは、固定ページもブロックエディタで編集できる仕組みを自社で開発して使っています。
公開後に自分で直せる範囲は、作り方で決まります。 お知らせだけは自分で更新できて、他のページは制作会社に頼む——そういう形になっていることは、よくあります。
私たちの場合は、会社案内もサービス紹介も採用ページも、同じ仕組みの上に乗っています。
このためコーディングの認識ズレが起きにくく、あとから直すのが軽い。 デモを早く出しても、直すコストが低いので怖くありません。
このあたりはコーディング仕様書に、書くことがほとんどない理由に書きました。
③ AIで浮いた時間は、中身に使っている
制作の一部にはAIを使っています。ただ、それで納期を縮めることを目的にはしていません。
浮いた時間は、文章や構成のような中身のほうに回しています。デモに文章まで入っているのは、そのためです。
AIで浮いた時間を、中身に使う。制作の内側を書きますに、もう少し詳しく書いています。
確認を待たない前提で、進行を組んでいます
Web制作が止まるとき、原因は書類の不足ではなく、確認が返ってこないことです。
そして確認が返ってくるかどうかは、窓口の方の役職では決まりません。 決まるのは、その方が現場を持っているかどうかです。
現場を持っている方は本業が優先されます。こちらからの確認は後ろに回ります。それは仕方のないことですし、責める話でもありません。
なので、待っている間もこちらは先に進めておきます。デモをスタート地点に置いているのは、そのためです。
止まらないから、結果として速くなります。
窓口をどなたにするかは、ホームページの要件定義、社内の誰が書くべきかに書いています。
同じことを、どの会社でもできるわけではありません
必要なものが2つあるからです。
| 蓄積 | 聞ききれなかった部分を補える経験。これがないと、45分では終わりません |
| 直せる作り | 早く出したものを、軽く直せる仕組み。これがないと、早く出すこと自体が怖くなります |
どちらか片方だと成立しません。蓄積がなければ補えないし、直せない作りなら、早く出したぶんだけ手戻りが重くなります。
逆に言うと、この2つが揃っていない状態で「1週間でデモを出します」と言われたら、少し確認されたほうがいいかもしれません。
何ページ分なのか。文章は入っているのか。直すのにどれくらいかかるのか。
この進め方に変えた結果はデモ先行に切り替えて、受注率が10%前後から20%前後になりましたに書きました。
向くケース・向かないケース
向いているケース
- イメージが湧いていない。見ないと判断できない
- 社内に専任の担当者がいない。窓口の方が現場を持っている
- 過去に、確認待ちでプロジェクトが止まった経験がある
- 完成に近い状態を見てから、社内で共有・相談したい
4つ目は、実際によくある使われ方です。デモが全ページ分あると、社内を説得する材料としてそのまま使えます。
コンペのように複数社を並べて比べる場でも、同じ形でお出ししています。進め方はホームページのコンペにまとめました。
向いていないケース
- 着手前に、書面で仕様を確定させる必要がある
- 稟議や入札で、承認を得てからでないと作業に入れない
- デモを見ずに、文書だけで判断したい
この場合は、順番が逆になります。それでもお受けできますが、私たちのいちばん得意な進め方ではありません。
1週間でデモが出るのは、作業が速いからではありません。決めるべきことを短い時間で決められるからです。
そして、決めきれなかった部分を抱えたまま進めても事故にならないのは、あとで直せる状態を先に作ってあるからです。
完璧に決めてから作る、という順番を取っていません。
もし今、何から決めればいいか分からない状態でしたら、それで大丈夫です。決まっていない状態から始めるための進め方です。書類がない場合の進み方は要件定義書がなくても、Web制作は進みますに書いています。
そのままの状態でご相談ください。
要件定義書は、書かなくて大丈夫です。
