「普通はこうなんです」が一番伝わらない
自分の店で長年使ってきた業務改善ツールを、他店にも展開できる形にしたい。そう考えて開発会社に相談に行くと、多くの店舗経営者が同じ壁にぶつかります。それは、自分にとって「当たり前」すぎることほど、相手に伝わらないという壁です。
たとえば「予約は前日の20時で締める」「常連客とそうでない客で対応を変える」「繁忙期は在庫の回転が倍になる」——これらはあなたの店では説明するまでもない共通認識かもしれません。しかし開発会社のエンジニアやディレクターは、あなたの業界の外にいる人です。「普通そうですよね」で済ませた部分は、システムの仕様から静かに抜け落ちます。
そして厄介なのは、抜け落ちたことに双方とも気づかないまま打ち合わせが進み、実際に動くツールを見てはじめて「あ、そこが違います」となる点です。手戻りは、伝え方の工夫でかなりの部分を防げます。
具体例を用意してから打ち合わせに臨む
業界の事情を言葉だけで説明しようとすると、抽象的な話になりがちです。「うちの業界は特殊で」「昔からの慣習があって」という説明は、聞いている側にとっては輪郭のない話にしか聞こえません。
効果的なのは、実際の業務で起きた具体的な場面を1つか2つ、ストーリーとして用意しておくことです。
- 「先週の火曜、常連のAさんから電話で予約変更の連絡が来て、うちのスタッフは常連台帳を見て即答した。この『即答できる』が売りなんです」
- 「月末の棚卸しでは、紙の在庫表と実際の数がずれることが月に3回はある。だから在庫は『目安』として扱っていて、厳密な数字管理を前面に出すと逆に現場が混乱する」
具体的な場面には、業種特有の判断基準や優先順位が自然と埋め込まれています。抽象的な説明よりも、開発会社側が「なるほど、だからこの機能が必要なのか」と逆算しやすくなります。
現場の写真・資料を「見せる」
言葉での説明には限界があります。特に、日々の業務が紙の帳票やアナログな掲示物、独自のレイアウトに支えられている場合、それを見せるだけで説明が一気に短くなります。
打ち合わせに持っていくと効果的なものの例です。
| 資料の種類 | 伝わること |
|---|---|
| 手書きの予約台帳・シフト表 | 実際の記入項目、更新の頻度、誰が書き込むか |
| レジ横やバックヤードの掲示物 | 現場で本当に守られているルール |
| 既存の紙の伝票・注文書 | 必須項目と、実は使われていない項目の区別 |
| 業務の様子を撮った写真・動画 | 作業の順番、複数人が同時に触る場面の有無 |
特に「実は使われていない項目」が分かる資料は貴重です。フォーマット上は存在していても、現場が形骸化させている項目は、システム化する際に思い切って削れる候補になります。逆に、口頭では出てこなかったのに現物を見ると必ず埋まっている欄があれば、それは業務上欠かせない情報だという合図です。
写真や資料は、開発会社にとっても「想像で補う部分」を減らす効果があります。想像で補われた部分は、大抵あとで修正対象になります。
一度で終わらせようとしない
業界特有の事情は、1回の打ち合わせで全部出し切れるものではありません。話しているうちに「そういえばこれも」と後から気づくことは自然に起こります。
無理に完璧な説明を準備しようとするより、
- 最初の打ち合わせでは代表的な場面を2〜3個に絞って伝える
- 開発会社からの質問に答える中で、抜けていた事情を都度補足する
- 見積もりや要件が固まってきた段階で、もう一度「これは反映されているか」を確認する
という段階を踏むほうが、双方にとって負担が少なく、精度も上がります。最初から100点を狙わず、対話の中で解像度を上げていく前提で臨むとよいでしょう。
用語集があると、以降の会話が速くなる
業界特有の言い回しや略語が多い場合は、簡単な用語集を1枚用意しておくことも有効です。特に士業や専門職に近い業務知識を扱う場合、専門用語の誤解はそのまま仕様の誤解に直結します。用語集を渡すことの意義については、専門用語が多い業界の発注で、事前に用語集を渡すべき理由 で詳しく整理しています。
また、そもそも自分の業務知識をどう言語化して伝えるかという工夫の幅を広げたい場合は、専門分野の業務知識を、開発会社に正確に伝える工夫 も参考になります。
自分の店のために作ったツールを他店に展開できるかどうかの判断軸そのものについては、自分の店のために作ったツール、他店にも展開できるか判断する視点 で扱っています。打ち合わせの伝え方を工夫する前に、そもそも展開する価値があるかを一度整理しておくと、開発会社への説明もぶれにくくなります。
業界の事情は、あなたにしか持っていない情報です。それを正確に渡せるかどうかが、出来上がるツールの精度を大きく左右します。