1票で「100%」とは表示しない。DOCHIが5票まで結果を隠す理由

1票中1票なら、計算上は100%です。しかし、その数字を見た次の人は「みんなAを選んでいる」と感じるかもしれません。まだ「みんな」と呼べる人数ではないのに、表示だけは決定的に見えます。

2票が同じ側へ入った場合も100%です。3票目で反対側へ1票入ると、今度は約67%対33%になります。母数が小さい間は、ひとつの投票で割合が大きく動きます。それでもパーセント表記は、十分に集まった結果と同じ見た目になります。

DOCHIは、迷っている人がほかの人の意見を参考にするアプリです。だからこそ、途中経過そのものが次の投票へ与える影響を小さくしたいと考えました。最初の数人の選択を、確定した空気のように見せないことを優先しています。

投票する前に結果を見せると、多い側へ寄せたい人も、あえて少ない側を選びたい人も出てきます。どちらの場合も、質問そのものへの答えだけでなく、途中経過への反応が票へ混ざります。

そのためDOCHIでは、まず自分でAかBを選び、投票後に結果を見る流れにしています。ただし、投票後であっても1票や2票の割合を強く見せれば、その結果を共有した人や後から見る人へ同じ影響が残ります。

完全に影響をなくすことはできません。DOCHIができるのは、数字がまだ不安定な時間を明確に「集計中」と扱い、意味の強い割合表示へ早すぎる確信を与えないことです。

投票直後に結果画面へ移りますが、5票未満では割合を表示しません。「現在4票」「まだ集計中です」のように、集まっている数だけを伝えます。自分の投票が受け付けられたことは分かりますが、多数派と少数派はまだ出しません。

5票以上になったら、初めてA/Bの割合を表示します。投稿した本人も同じルールです。結果を早く知りたい気持ちはありますが、最初の1〜2票を大きく見せないほうを優先しました。

「集計中」は結果を隠して焦らすための演出ではありません。割合を読むにはまだ早い状態を、そのまま伝える表示です。票数は見せるため、あとどれくらい集まれば結果が開くかも分かります。

5票あれば世論を代表できる、という意味ではありません。質問の対象や回答者の偏りを考えれば、5票は統計的な保証になりません。1票や2票の極端な表示を、そのまま確定結果のように見せないための最低ラインとして置いています。

100票集まるまで待てば数字は安定しますが、日常の小さな迷いにそこまで待つアプリではありません。友人や近い関心を持つ人から少し意見をもらい、決める材料にする軽さも必要です。安定性だけを求めて結果が見えない時間を長くすれば、投票する意味も薄れます。

そこで、極端さを少し和らげつつ、小規模な投稿でも結果まで届きやすい境界として5票から始めました。この数字は固定観念ではなく、利用状況を見ながら検証するプロダクト上の仮説です。

5票では、5対0なら100%対0%、3対2なら60%対40%です。1票の差が20ポイントになるため、まだ変化は大きくあります。5票に達した瞬間から、急に安定した調査結果へ変わるわけではありません。

そのため、結果画面では割合だけでなく総投票数も一緒に示します。60%という表示だけを見るのと、「5票のうち3票」と分かるのでは、受け取り方が変わります。割合と母数を切り離さないことが重要です。

将来、票数が大きく増える投稿が出ても、同じ割合が同じ意味になるとは限りません。DOCHIは正確な世論調査を提供するものではなく、投稿者が自分の判断を進めるための視点を集めるものです。その前提を、数字の見せ方でも崩さないようにします。

表示を設計するときは、割合の小数点を細かくするより、母数と状態を分かりやすくするほうを優先します。票が少ない段階で精密な数字を出しても、情報が正確になったのではなく、見た目だけが精密になります。数字の桁数ではなく、利用者が今の結果をどこまで信頼してよいかを伝えることが目的です。

5票未満なら割合を隠す判定をFlutter側だけに書くと、通信結果には割合が含まれたままになります。画面を改変したクライアントや、将来追加する別のクライアントで、意図せず早い段階の結果が見える可能性があります。

DOCHIでは、結果を返すサーバー側の処理が、票数に応じて何を返してよいかを決めます。Flutter側は受け取った状態を描画するだけで、取得した票数から割合を勝手に再計算しません。表示上の工夫ではなく、データを返す境界のルールとして扱います。

• 5票未満：総票数と「集計中」だけを返す
• 5票以上：A/Bの割合と総票数を返す
• 判定はサーバー側を正本にする
• 投稿者と投票者で抜け道になる別処理を作らない

同じルールを複数の画面へコピーせず、ひとつの境界で守れば、結果画面、通知、将来の共有表示でも食い違いにくくなります。プロダクト上の約束は、見た目だけでなく返すデータにも反映させます。

選択肢が多い投票では、票が分散し、少数票の割合がさらに細かく見えます。DOCHIがA/Bの二択を基本にしたのは、操作を軽くするためだけではありません。迷っている論点を分け、結果をひと目で読みやすくするためでもあります。

二択にした背景は「どっちにしよう」をひとりで抱えない。DOCHIを作っている理由で詳しく書いています。選択肢を絞る設計と、少数票の割合をすぐに見せない設計は、どちらも数字を必要以上に複雑で強いものにしないための判断です。

また、投票結果を使って迷いを解くときは、多数派の数字だけでなく、自分がなぜその選択肢を選んだかも大切です。MVPとは？最初のアプリで機能を絞る方法と、外れたときの扱いでも、判断の軸を先に決めてから数を減らす考え方を紹介しています。

5票を超えて60%対40%になっても、60%側が正解とは限りません。質問の背景、回答した人、投稿された時間によって結果は変わります。結果を見て「やっぱり自分は少数派のほうが好きだ」と気づくこともあります。

DOCHIが見せたいのは正解ではなく、決めるための外からの視点です。多数派へ従わせるのではなく、ひとりで考えているときには見えなかった材料を加える。そのためには、数字が必要以上に強く見えないことも体験の一部です。

5票まで隠すルールは小さな仕様ですが、プロダクトが結果をどう扱うかを表しています。早く答えを見せることより、受け取り方を誤らせないことを優先する。これが現在のDOCHIの判断です。

公開後は、5票へ到達するまでの時間、集計中で離脱する割合、結果を見たあとの行動を確認します。ただし、数字だけで境界を動かしません。集計中の意味が伝わっているか、待つ時間が不満になっていないかも合わせて見ます。5票という仮説を検証しつつ、最初の少数意見を過度に強く見せない原則は維持します。