1. なぜ今これを書くか
TokiQRは、音声・画像・テキストをQRコード一枚に埋め込む個人開発のツールとして生まれた。Codec2による音声圧縮、Brotliによるテキスト圧縮、完全オフライン動作。技術的には、ブラウザだけで完結する。サーバーにデータを送らない。ネットワークが断たれても動く。
そのツールに、公共施設や図書館から問い合わせが届くようになった。「音声ガイドに使えないか」「展示物の説明をQRに入れられないか」。機能に関する質問ではなかった。聞かれたのは、「これは信頼できるのか」だった。
個人ツールから公共ツールへの移行は、機能の拡張ではない。信頼の差を埋める作業である。その差が何であり、どう埋めたかを記録する。
2. お金のかかる話なら説明を聞きたい——透明な課金モデル
TokiQRのバルクモード——複数のQRコードを一括生成する機能——は、マルチQRクレジットを消費する。公共施設の担当者にとって、クレジットの消費は稟議の対象になる。「いくらかかるか事前にわかるか」という問いに、当初のUIは答えられなかった。
改善は単純だった。生成プロセスを二段階に分けた。まず見積もりを表示する。何枚のQRコードが生成され、何クレジット消費するかを明示する。ユーザーはその見積もりを確認してから、実行するかキャンセルするかを選ぶ。
「見積もりを見てからキャンセルできる」——これは、上長に説明する担当者にとっての最低条件だ。技術的には数行のコード変更だが、公共利用においてはこの一手順が導入の可否を分ける。
課金の透明化は技術の問題ではない。説明責任を構造に埋め込むことだ。
3. 無料でも始められるという備え
公共施設の担当者が最初に直面するのは、予算の壁ではない。「予算がないと試せない」という思い込みの壁だ。
TokiQRでは、短い音声をQRコード一枚に収める処理にクレジットは不要である。バルクモードであっても、単一チャンクで収まる処理にはクレジットが消費されない。つまり「予算ゼロで始められる」という事実が存在する。
この事実は、導入検討の初期段階で決定的に重要だ。公共施設の担当者が上長に「まず無料で試せます」と言えるかどうか。この一言が、検討の俎上に載るか載らないかを決める。
機能を増やすことより、入り口の敷居を下げること。それが公共利用の第一歩だ。
4. 実導入を想定した検証
開発者の手元で動くことと、現場で動くことは違う。公共施設への提供を見据えたとき、検証すべきは四つの条件だった。
- オフライン動作：Service Workerによるキャッシュで、初回アクセス後はネットワーク不要で動作するか。施設内のWi-Fiが不安定な環境を想定する。
- 低速回線での初回読み込み：初回アクセス時にService Workerが登録される前、低速なモバイル回線でもページが表示されるか。待ち時間が長すぎると、ユーザーは離脱する。
- 旧型スマートフォンのカメラ性能：生成したQRコードを、三年前、五年前の端末のカメラで読み取れるか。公共施設の利用者は最新端末を持っているとは限らない。
- 印刷時のQRコード品質：画面表示では読めても、プリンターで印刷したときに解像度が足りるか。展示パネルに貼り付けたとき、照明の反射で読み取れなくならないか。
これらは仕様書に書かれない要件だ。しかし現場で動かなければ、仕様がどれほど優れていても意味がない。公共提供とは、開発者の理想環境ではなく、利用者の現実環境で動くことを保証する行為である。
5. 四つの不安を構造的に起こさない
公共施設の担当者がツールを操作するとき、技術的な失敗よりも心理的な不安が障壁になる。観察から四つの不安を特定した。
「終わるのか？」——完了の見通し
音声のエンコード処理は時間がかかる。プログレスバーがなければ、ユーザーは処理が進んでいるのか、フリーズしているのか判断できない。Opus圧縮のプログレスバーを追加し、経過時間と残り時間を表示するようにした。「あと何秒で終わる」がわかるだけで、不安は消える。
「故障かな？」——無反応への不信
処理中にボタンが押せる状態のままだと、ユーザーは「反応しないのは故障か」と疑う。処理中はボタンを無効化し、ローディングインジケーターを表示する。見積もり表示中は設定UIをロックする。「押せない」という状態そのものが、「いま処理中です」というメッセージになる。
「やり直し？」——操作ミスへの恐怖
見積もりを表示した後に設定を変更すると、見積もりが無効になる。しかしユーザーは「設定を触ったら最初からやり直しか」と不安になる。見積もり表示中は設定UIをロックし、変更するにはキャンセルが必要な設計にした。誤操作の余地を構造的になくすことで、やり直しの不安を断つ。
構造的に起こさない、とは
個々のバグ修正ではなく、状態遷移の設計で不安を排除する。ボタンが有効ならば「押してよい」。ボタンが無効ならば「待つべき」。UIの状態がそのまま行動の指示になる。これが「構造的に起こさない」の意味だ。
不安はバグではない。状態設計で除去する対象だ。
6. 見て興味あるけど触るのが怖い——寄り添って一緒に超える
機能を説明し、UIを改善しても、なお残る壁がある。「自分が触って壊さないか」という恐怖だ。
公共施設の担当者は、ITの専門家ではない。ツールが「使いやすい」と評価されても、最初の一歩を踏み出せないことがある。マニュアルを渡しても、読むだけで手が動かない。
解決策は機能的なものではなく、体験的なものだった。最初のQRコード生成を一緒にやる。担当者の隣で、同じ画面を見ながら操作する。間違えても戻せることを実演する。成功体験を共有する。
「一緒にやる」というのは、技術的なサポートではなく、心理的な壁を超える伴走だ。一度成功すれば、二度目からは一人でできる。最初の一回だけ、隣にいること。それが導入支援の本質である。
7. 導入実績ゼロのときは自分が利用者の流れを一緒に体験すること
導入実績がゼロの状態で、担当者は孤独だ。「他にどこが使っているのか」と聞かれて、「まだどこも使っていない」と答えるしかない。実績という安全網がない。
開発者にできることは、導入担当者と一緒に利用者の動線を歩くことだ。受付から案内まで、QRコードのスキャンから音声再生まで、実際の施設で実際の端末を使い、一連の流れを体験する。
この体験が、実績のゼロをイチにする。他施設の事例ではなく、自分の施設での成功体験。開発者が隣にいるという安心感ではなく、「自分たちの施設で動いた」という事実。ゼロからイチへの跳躍は、機能ではなく共有された体験によって起こる。
8. まとめ——公共の信頼とは不安を名指しすること
公共提供への備えとは、機能を追加することではない。不安を減らすことだ。
- 課金プロセスを二段階にし、見積もりとキャンセルを保証する——財務の不安を除く。
- 無料で試せる入り口を維持する——予算の不安を除く。
- UIの状態遷移で操作の正しさを示す——操作の不安を除く。
- 最初の一回を一緒に体験する——孤立の不安を除く。
個人ツールが公共ツールになるとき、コードの変更量は多くない。変わるのは、不安に対する解像度だ。誰が、何を、なぜ怖がるのか。それを名指しし、構造的に取り除く。
公共の信頼は、機能の完成度ではなく、不安の不在によって生まれる。不安を名指しし、構造で断つ。それが、個人ツールが公共に開かれるための条件である。