完璧なデータを待たずに公開し、それでも根拠は妥協しない
完璧なデータを待たずに公開しながら、根拠のない数字や断定を避ける。GAOCRAFTがWebプロダクトで実践する公開と検証の考え方を紹介します。
WebサイトやWebプロダクトを作っていると、 「もう少しデータがそろってから公開した方がいいのでは」 と思うことがあります。
情報が足りない。 実測がまだ少ない。 検証も十分ではない。
そう考えているうちに、 いつまでたっても公開できなくなることがあります。
GAOCRAFTでは、 すべてが完璧になるまで待つことを 公開条件にはしていません。
ただし、
「早く公開するためなら、 分からない部分を適当に埋めてもよい」
とも考えていません。
完璧を待たないことと、 根拠を妥協することは別です。
完璧な
図：すべての条件が整うのを待ち続けず、今ある確かな情報で何を伝えられるかを考える。
GAOCRAFTが運営する「シーパラ攻略隊」では、 現地で移動時間や観覧時間を測ったり、 公式情報を確認したりしながら Webコンテンツを作っています。
理想を言えば、 必要な実測を何度も行い、 さまざまな条件を比較してから公開した方が 情報は充実します。
でも、現実にはそう簡単ではありません。
現地へ行ける日は限られます。
イベントが開催されていて 予定していた計測ができないこともあります。
天候や混雑によって 同じ条件を再現できないこともあります。
すべてがそろう日を待ち続けていると、 今すでに分かっている有用な情報まで 公開できなくなります。
だからGAOCRAFTでは、
「現時点で、何なら責任を持って公開できるか」
を考えます。
分かっている
図：確認できた情報の種類を区別し、分かっている範囲で読者に役立つ記事を作る。
独自実測がまだ十分でなくても、 記事そのものを公開できないとは限りません。
公式情報として確認できること。
信頼できる外部根拠があること。
実際に体験して確認できたこと。
すでに独自実測できていること。
それぞれを区別して書けば、 今ある情報だけでも 読者の判断に役立つ記事を作れる場合があります。
大事なのは、
「全部分かっているように見せない」
ことです。
まだ測っていないことを、 測ったようには書かない。
一度しか経験していないことを、 誰にでも当てはまる話にはしない。
公式情報と自分たちの体験を、 同じ種類の情報として扱わない。
足りないものがあるなら、 足りない状態を前提に設計します。
根拠の
図：分からない数字を仮に入力して、判断結果だけを完成させることはしない。
公開を早めるために やらないと決めていることもあります。
その一つが、 分からない数字を仮で入れることです。
たとえば、 おすすめの滞在時間や回り方を出すWebツールを作るとします。
必要な移動時間がまだ測れていないときに、
「たぶん10分くらいだろう」
と仮の数字を入れれば、 見た目だけなら完成させることができます。
でも、その数字が計算に使われるなら、 最終的なおすすめ結果まで変わります。
見た目は完成していても、 判断の根拠がありません。
その状態なら、 GAOCRAFTでは完成とは扱いません。
分からない数字を入れて 機能しているように見せるくらいなら、 その部分は未完成のままにします。
記事と
図：記事と計算型Webツールでは、未確認情報が結果に与える影響が異なるため、公開条件を分けている。
ここは特に分けて考えています。
記事は、 分かっている情報だけでも 読者の疑問を解決できる場合があります。
たとえば、
公式情報を整理する。
実際に体験したことを書く。
現時点で測れている範囲を示す。
まだ分からない点を明確にする。
こうした形で、 十分に価値を作れることがあります。
一方で、 診断や計算を行うWebツールは、 入力した数字が結果へ直接影響します。
根拠のない数字が一つ入るだけで、 それらしいけれど信頼できない答えを 返してしまう可能性があります。
そのため、
記事は先に公開できる。
でも、診断ロジックは 必要な根拠がそろうまで完成扱いにしない。
同じWebサイトの中でも、 公開条件を一律にはしていません。
小さく
図：最初に作る範囲を絞っても、未確認の断定や根拠のない数字は許容しない。
GAOCRAFTでは、 大きなものを一度に作るより、 小さく公開して改善することを大切にしています。
ただし、 「小さく作る」は 「雑に作る」という意味ではありません。
最初の記事数が少なくてもいい。
機能が最低限でもいい。
すべてのデータがそろっていなくてもいい。
でも、
根拠のない数字を入れない。
確認していないことを断定しない。
何が公式情報で、 何が自分たちの体験なのかを分ける。
公開する範囲については、 きちんと説明できる状態にする。
削るのは機能や範囲であって、 信頼性ではありません。
公開は
図：公開は完成ではなく、実際の利用状況を観測して改善を始める地点である。
公開前に考え続けるだけでは、 分からないことがあります。
実際に検索されるのか。
どの記事が読まれるのか。
どこから別の記事へ移動するのか。
作った機能が本当に使われるのか。
こうしたことは、 公開して初めて観測できます。
そのためGAOCRAFTでは、
作る。 公開する。 計測する。 改善する。
という流れを前提にしています。
最初から完成版を当てにいくのではなく、 公開後のデータから 次に直す場所を見つけます。
少ない
図：数値が記録された事実と、効果が証明されたことを分け、データが少ない間は観測を続ける。
公開後に数字が見えるようになると、 今度は別の注意が必要になります。
アクセスが1件あった。
クリックが数件発生した。
あるページだけ表示回数が多かった。
数字が出ると、 すぐに意味を付けたくなります。
でも、データが少ない段階では 偶然の影響も大きくなります。
公開直後には、 自分たちが表示確認したアクセスが 混ざっていることもあります。
だから、 数字が出たことと、 何かを証明できたことも分けます。
小さなデータは 「判断材料が増え始めた」と考え、 すぐに成功・失敗を決めません。
公開した
図：公開後に得た根拠を追加し、必要に応じて記事や機能を更新する。
最初からすべてを持っていなくても、 あとから追加できます。
現地実測が増えたら、 記事を更新する。
新しい体験ができたら、 実体験として追加する。
検索データが増えたら、 読者が迷っている場所を見直す。
機能に必要な根拠がそろったら、 未完成だった部分を進める。
公開時点をゴールにしなければ、 最初からすべてを詰め込む必要はありません。
重要なのは、 あとから改善できる状態で 正しくスタートすることです。
完璧を
図：分かる範囲を先に公開する一方、根拠のない数字や未確認の断定は避ける。
GAOCRAFTでは、 「まだ完璧ではない」という理由だけで 公開を止めないようにしています。
一方で、
早く公開したいから、 それらしい数字を入れる。
情報が足りないから、 断定してしまう。
完成しているように見せるために、 分からない部分を隠す。
そういう進め方もしません。
今分かっていることは、 今分かっている範囲で出す。
分からないものは、 分からないままにする。
公開して、 実際の反応を見て、 必要な情報を追加していく。
完璧を待たない。
でも、根拠は妥協しない。
GAOCRAFTでは、 その間を探しながら Webプロダクトを育てています。