提案が弱く見える人ほど、言い方より順番を見直したい
15時の打ち合わせで、機能説明だけが残った
個人経営の飲食店から、予約管理を楽にしたいと相談を受けた。電話、予約サイト、店頭のメモが別々にあり、週末になると席の空き状況を合わせるのに時間がかかるらしい。
打ち合わせ当日、エンジニアは管理画面の案を見せた。
予約を一つの画面へ集めて、自動集計と通知も入れられます。権限を分ければ、店長とスタッフで見える範囲も変えられます。
説明は間違っていない。作れる機能も、使う技術も、事前に調べていた。それでも店主の返事は短かった。
便利そうですね。いったん持ち帰って考えます。
そこで会話が止まった。
相手の反応が薄いと、「説明が弱かった」「もっと自信を持って言い切るべきだった」と感じやすい。経験が足りないと思われたくなくて、通知の種類や画面構成をさらに説明したくなる。価格を下げれば進むかもしれない、とその場で余計な約束をしそうにもなる。
でも、店主が判断できなかった理由は、声の強さではなかった。機能は分かったのに、自分たちの何がどう変わるのかが見えなかったのだ。
打ち合わせが終わり、エンジニアがパソコンを閉じた時、スタッフがカウンターにたまった予約票を指した。
金曜の夜だけ、電話の予約をサイトへ写すのが追いつかないんです。先週も同じ席を二組に案内しそうになって。
その一言で、話すべきことが変わった。欲しいのは多機能な管理画面ではない。金曜の混雑前に、電話とサイトの予約が同じ席へ重なっていないと確認できる状態だ。
提案が伝わらなかった後は、恥ずかしさで口数が増えるか、反対に黙って帰りたくなる。どちらも自然な反応だ。ただ、その気持ちのまま機能を足すと、相手との距離はさらに開く。
ここで戻りたいのは、うまい言い回しではない。「相手は何を決められずにいるのか」を一つ聞くことだ。質問を一つに絞ると、提案を否定された気持ちから離れ、目の前の判断へ戻りやすくなる🙂
提案の前に、事実と解釈を分ける
提案を組み直す時は、いきなり新しい資料を作らない。まず、聞いた事実と、自分の解釈を分ける。
この店で確認できた事実は、次のようなものだった。
- 電話、予約サイト、店頭メモの三つに予約が分かれている
- 金曜の17時以降は、電話予約を転記する人が決まっていない
- 先週、同じ席を二組へ案内しかけた
- 営業後に30分ほど使い、三つの記録を照合している
一方、「予約管理システムを刷新すべき」「通知機能が必要」は、まだ解決策についての解釈だ。相手が本当に困っていることを確認する前に解釈を事実のように置くと、提案は押しつけに見えやすい。
デジタル庁のユーザビリティ導入ガイドブックは、利用者の実態を把握し、利用品質の目標を置いたうえで設計と評価を進める考え方を紹介している。対象は政府情報システムだが、使う人の状況と、達成したい状態を先に確かめるという順番は、小さな業務改善の提案でも使える。
GOV.UKのService Standardも、特定の解決策から始めるのではなく、利用者と解くべき問題を理解し、仮説を早い段階で試すよう勧めている。提案を強く見せるために機能を増やすより、問題と仮説のつながりを見えるようにする方が、相手は判断しやすい。
相手の沈黙を、反対だと決めつけない
「持ち帰ります」は、提案への反対とは限らない。予算の決裁者が別にいる、現場へ確認したい、今の作業時間が分からない、他のシステムとの関係が見えない、といった理由もある。
反応が薄い時に怖いのは、何が足りないか分からないことだ。その空白を「自分への評価」で埋めると、急いで説得したり、値下げを申し出たりしやすい😓
そこで、説明を足す代わりにこう聞く。
今日の話を判断するために、まだ分からないことはどこでしょうか。費用、現場の使い方、始める時期のどれが近いですか。
選択肢を添えると、相手も答えやすい。返ってきた内容が費用なら費用を扱う。現場の使い方なら利用場面へ戻る。沈黙の理由を確かめてから、足りない材料だけを出す。
強みではなく、相手に起きる変化へつなぐ
「自動集計を実装できます」だけでは、提案者の能力説明で止まる。相手に必要なのは、その機能によって仕事がどう変わるかだ。
たとえば、次のようにつなぐ。
電話予約を受けた時点で同じ台帳へ登録できれば、金曜の営業前に予約を転記し直す作業をなくせます。まずは二週間、電話予約だけ同じ画面へ入れて、二重登録と営業後の照合時間が減るかを確かめませんか。
機能、変化、確かめ方が一つにつながった。ここまで見えれば、相手は「便利そうか」ではなく、「二週間試すか」を判断できる。
IPAのDX推進スキル標準では、関係者の意見や対立を引き出して論点を深めること、目的と到達点を設定すること、短い周期でフィードバックを反映することを、DXを進める人に必要な力として整理している。提案は一方的に正解を示す場ではなく、目的と論点をそろえ、次の検証へ進む共同作業として考えた方がよい。
分からないことは、確認項目として残す
提案者が苦しくなるのは、質問されたことへその場で全部答えようとする時だ。
今の予約サイトと連携できますか。
スタッフ全員が使えるようになるまで、どれくらいかかりますか。
まだ調べていないのに、沈黙すると頼りなく見える気がする。「たぶんできます」「一週間くらいです」と即答すれば、会話は止まらない。ただし、その返事が次の見積りや納期の前提になると、あとで自分が抱えることになる。
分からないことは、無理に埋めなくてよい。次の三行へ分ける。
- 確認できた事実: 現在は三つの記録を営業後に照合している
- まだ分からないこと: 予約サイトからどの情報を取得できるか
- 今日決めること: まず電話予約の入力だけを試すか
このメモがあれば、聞かれた時もこう返せる。
既存サイトとの連携方法は、契約と提供機能を確認してから回答します。今日の時点では、連携を前提にせず、電話予約の入力だけで試せる範囲を決めたいです。
これは回答を避けているのではない。確認が済んだこと、済んでいないこと、今決められることを分けている。
提案後に不安になると、相手の疑問をすべて自分の宿題として持ち帰りやすい。けれど、予算を決める人、現場で使う人、今のサービスの契約を管理する人は別かもしれない。誰へ何を確認するかを相手と分ければ、一人で正解を作る必要はなくなる。
分からないことを隠さず、次の確認先まで示す方が、提案は現実的になる。
相手が判断できる「4つの順番」に組み直す
提案の基本形は、「問題、打ち手、効果」だけでも使える。ただし、実務ではもう少し具体的に、次の四つへ分けると扱いやすい📝
- 今起きている事実
- 放置すると困ること
- 提案する一手と、期待する変化
- 小さく試す条件と、今日決めてほしいこと
1. 今起きている事実を、一場面で示す
「予約管理が非効率です」では、何が起きているか人によって想像が違う。日時、行動、回数など、確かめられる事実へ戻す。
金曜の17時以降、電話予約の転記担当が決まらず、営業後に三つの記録を30分かけて照合しています。
数字がまだ分からなければ、無理に作らない。「毎週30分かかっているか、次の二週間だけ測る」でもよい。事実がない場所は、調査項目として残す。
2. 放置すると誰が困るかを置く
課題を大きく見せる必要はない。現状のままだと、誰のどの仕事に影響するかを一つ置く。
転記が遅れると、ホール担当が空席だと思って案内し、店頭でお客さまへ謝ることになります。
ここには業務時間だけでなく、現場の気持ちもある。案内を間違えるかもしれない緊張、忙しい時間に確認相手が見つからない焦り、来店した人へ謝る気まずさだ。感情をあおるのではなく、現場の行動を止める要因として扱う。
3. 一手だけ提案し、変化と結ぶ
最初から完成版を提案すると、予算も影響範囲も大きくなり、相手の判断が重くなる。今回の例なら、最初の一手は「予約管理全体の刷新」ではない。
電話予約だけ、受けた時点で既存の一覧へ登録できる入力画面を作ります。これで、営業前の転記と二重登録の確認を減らせるか見ます。
提案する機能は一つ。期待する変化も一つにする。対象外も伝える。
予約サイトとの自動連携や売上分析は、今回の試行には含めません。
対象外を言うと弱く見える気がするかもしれない。しかし、何をまだ約束しないかが分かる提案ほど、相手は安心して試せる。
要件が広がって整理できない時は、要望を三つの種類へ分ける方法も使える。作るもの、確認が必要なもの、今回は見送るものを分けると、提案の境界が見えやすい。
4. 試す条件と、今日の判断を小さくする
最後に、相手へ何を決めてほしいかを書く。
- 二週間、金曜を含む営業日で試す
- 使う人は店主とホール担当の三人
- 営業後の照合時間と、二重登録の件数を記録する
- 二週間後に、継続、修正、終了のどれかを決める
これなら、相手はシステム全体の導入を今決めなくてよい。「二週間の試行へ進むか」を決めればよい。
試した結果を何で確認するかは、着手前に合わせる。作り始める前に合格条件を決める方法までつないでおくと、「作ったのに良くなったか分からない」を避けやすい。
打ち合わせの最後、エンジニアは説明をやり直した。
先ほどは機能から話してしまいました。まず解きたいのは、金曜の転記遅れで同じ席へ予約が重なることだと理解しました。電話予約の入力だけ二週間試し、営業後の照合時間が減るか確認する案なら、現場の三人で試せそうでしょうか。
店主は予約票を見てから、「それなら、金曜担当にも聞けます」と答えた。
一度の説明で契約が決まったわけではない。それでも、「便利そうですね」で止まった会話は、誰へ確認し、何を試すかまで進んだ。提案後の気まずさが消えたのは、自信のある話し方ができたからではない。相手と同じ問題を見られたからだ🙂
提案の強さは、強く言い切ることではなく、相手が次の判断をできることに表れる。
次に反応が薄かったら、機能を足す前に一行だけ書き直してみてほしい。
今、誰のどんな作業が止まり、今回の一手で何を変え、どこまで試すのか。
この一行が言えれば、言葉を飾らなくても提案は前へ進む。
伝わらなかった提案を、相手が判断できる順番へ整える
ページへ移動参考にした情報
- デジタル庁「DS-671.1 ユーザビリティ導入ガイドブック」（2026年6月1日最終改定、2026年8月10日確認）
- IPA「DX推進スキル標準 分冊版 ver.1.2」（2024年、2026年8月10日確認）
- GOV.UK Service Manual「Understand users and their needs」（2019年5月8日公開、2022年5月30日最終更新、2026年8月10日確認）
- GOV.UK Service Manual「Understanding and meeting policy intent」（2022年4月8日公開、2024年10月22日最終更新、2026年8月10日確認）
