2026-08-08
失敗の記憶にふさがれた提案を通す——DXを「別の課題」に乗せ直す方法
Argora編集部
一度のシステム導入が失敗に終わると、その記憶が次の提案の扉を閉じる。正しい提案が、過去の文脈で門前払いされる歯がゆさ。突破口は「別の課題に乗せる」設計にある。
一度のシステム導入が失敗に終わると、その記憶は長く組織に残る。担当者が変わり、予算が変わり、提案の中身が刷新されても、「あのときも同じことを言っていた」の一言で議論が止まる。
DXが「タブー」になった組織では、正面からシステムの話をすることが、最も通りにくい提案方法になっている。歯がゆいのは、提案の内容が正しくても関係ないという点だ。正しいことが、記憶によって跳ね返される。
「またあの話か」と言わせない入口をつくる
DX提案が過去の失敗と結びついてしまうとき、拒否は感情論として現れるのではなく、合理的な判断として機能する。「前回は一度も使われなかった」という事実は、反対する側にとって十分すぎる根拠だ。
だからこそ「今回は違います」と丁寧に説明しようとするほど、かえって「前回も同じことを言っていた」という記憶が掘り起こされる。論理で説得しようとするほど、過去の文脈に引き戻されていく。
この状況を突破しようとするなら、「システムの話」として出すことをいったんやめる必要がある。問題は提案の中身ではなく、提案が相手の耳に届く前に止まっていることだ。
課題を差し替えて、別口から入る
ここで有効なのが「課題の差し替え」という設計だ。
システムを導入したいのではない。残業を減らしたい。繰り返し起きているミスを防ぎたい。確認の往復に時間がかかりすぎている現状を変えたい。まずこの課題の言葉から入ることで、「またシステムの話か」という条件反射が起きにくくなる。
提案の入口を変えるだけで、同じ中身が通るケースがある。
- 「困っていること」を先に言語化する
- そこに必要な手段として、システムを後から置く
- 「システム」「DX」という言葉を、提案の後半に回す
手順よりも課題が主語になると、話を聞く人の構えが変わる。「問題を解決するための話」として受け取られるか、「またシステムを入れようとしている」と受け取られるか、出発点の言葉が分岐点になる。
正しい提案が通らないのは、提案が間違っているからではない。提案が届く前に止まっているだけだ。
再提案の前に整理すること
別口から入る前に、前回の失敗がどういう文脈で記憶されているかを確認することが先だ。
「わからない人間が先走っていた」という経緯が残っているなら、今回は意思決定のプロセスを先に示す必要がある。誰が何をどう決めるかを、事前に整理して見せること。そうすることで、「また同じ轍を踏むのでは」という不安の根拠を外しておける。こうした決定の透明化については、誰がどう決めるか——システム化が炙り出す、暗黙ルールの整理術で詳しく触れている。
また、「やらないこと」を最初に明示することが、再提案の信頼に直結する。前回の失敗が「大きすぎて使いこなせなかった」という記憶にあるなら、今回の提案がどこまでをスコープに入れないかを、提案の冒頭で言葉にしておく。何をやらないかを決めることは、提案の輪郭を明確にする作業だ。「却下」を設計に組み込む——やらないことを決める、健やかなDXの土台でも書いたように、やらない範囲を先に示すことで、相手の警戒を解くきっかけになる。
再提案を社内で一人で進めることが難しければ、外部の視点を持ち込む方法もある。しぼる:DX伴走支援では、社内の文脈や関係性を読み解きながら、再提案の設計を一緒に考える。
組織の記憶は変えられない。だが、その記憶が反応しない入口を探すことはできる。それが迂回ではなく、届けるための設計だ。
FAQ
よくある質問
DXが社内でタブーになったとき、どうやって再提案すればいいですか
システムの話として出さず、現場が困っている別の課題(残業削減・ミス防止など)に紐づけて提案するのが有効です。提案の入口を変えるだけで、同じ中身が通りやすくなります。
DX提案が前回の失敗を理由に却下されたとき、どう対応すればいいですか
「前回とは違う」と正面から説明するよりも、そもそもDXやシステムという言葉を使わず、解決したい課題の言葉で話す方が通りやすいです。
中小企業でシステム導入が一度失敗したあと、どう社内を動かせばいいですか
小さく始めることが近道です。失敗の記憶がない文脈で一つ小さな改善を通し、実績をつくってから次の提案につなぐ順序が重要です。
Related
Argo:デジタルの、ほかの読みもの
2026-08-11
自動化は業務フローを固定する——AIエージェントを乗せる前に確かめること
AIエージェントを業務に組み込む前に、問うべきことがある。自動化はフローを固定する技術であり、整っていないものを乗せれば、誰も読めない仕組みが生まれる。
2026-08-10
「非効率」と呼ぶ前に受け取るべきもの——現場の経験を失わないDXの進め方
アナログな業務を「非効率」と断じてデジタル化を進めると、現場が培った判断力と責任感ごと失いかねない。経験を受け取ってから設計することが、DXを根付かせる起点になる。
2026-08-10
ベンダーを動かすのは仕様書ではない——事業者が磨くべき「課題を語る力」
システム開発の失敗の多くは、技術ではなく「課題の伝わらなさ」から起きる。事業者がITを学ぶとはコードを書くことではなく、問いを立てる力を身につけることだ。