「便利にしたのに、使われない」の研究——非エンジニアが100回失敗して見つけた、7つの理由と1本の境界線
便利な仕組みを作ったのに、誰にも使われない。
情報をまとめた場所を用意したのに、結局みんな人に聞きに来る。
ツールを配ったのに、1ヶ月後に開いた形跡があるのは自分だけ。
私はエンジニアではありません。製造業の現場で、在庫や書類や引き継ぎに追われている、ただの実務者です。それでも「現場の面倒を道具で減らせるかも」と思い立っては作り、配ることを100回以上繰り返してきました。
そして、その大半で同じ壁にぶつかりました。
便利にしたのに、使われない。
最初は使わない側の問題だと思っていました。メールを読んでいないのかな。新しいものへの抵抗かな。リテラシーの差かな。
100回失敗して、ようやく分かりました。使われない理由には型があります。そしてその型のほとんどは、作る側・配る側の設計の問題でした。さらにその先に、もうひとつ大事な発見がありました。
使われないのは、設計の失敗とは限らない。そもそも「設計で解く問題ではない」ことがある。
この記事は、私が実際に作って、配って、使われなかった失敗の記録から、「使われない理由の7つの型」と、最後にたどり着いた「1本の境界線」をまとめたものです。
エピソードはすべて実体験です。各章の元になった実験記録（個別記事）のリンクは、文末にまとめてあります。
序章：いちばん読まれた記事は、いちばん痛い失敗の話だった
私はnoteで「AI活用100本ノック」と題して、業務改善の実験記録を100本以上、毎日公開してきました。
その中でいちばん読まれたのは、うまくいった自慢話ではありません。「便利にしたのに使われない」という、いちばん痛い失敗の話でした。
きっかけは、誰もやりたがらない突発案件でした。「これ、自分の仕事なの？」とみんなが思う。でも会社としては対応必須。なぜみんな同じ思いで動けないのか。掘っていくと、上の期待と下の不満の板挟み、伝言ゲームで薄れていく「なぜやるべきか」、解釈違いで別の意味にすらなる指示——そんなピラミッド構造の苦しさに行き当たりました。
だから最初はこう考えました。「思いが正しく伝われば、みんな動くはずだ」と。情報をまとめ、見える場所を作り、AIで配信まで自動化しました。
結果は、沈黙でした。
この記事が多くの人に読まれたという事実が、私には答えのように思えました。「便利にしたのに使われない」は、私だけの失敗ではなく、いたるところの職場で毎日起きている構造問題なのだと。
ここからの6章は、その構造を1つずつ解剖していきます。
第1章：「配れば使われる」という最初の思い込み
2日かけたExcelが、30秒も見てもらえなかった
チーム共通の集計作業に、毎回30分かかっていました。
関数とマクロを組んで、入力するだけで集計が終わるExcelを作りました。2日かけて仕上げて、共有フォルダに置いて、メールで「便利ツール置きました」と送りました。
正直、感謝されるつもりでいました。「これで楽になりますね」と言われる想像までしていました。
ところが1ヶ月経っても、開いた形跡があるのは自分だけ。チームメンバーに聞いてみると、返ってきたのはこんな声でした。
「どこにあるか分からない」 「開いたけど使い方が分からなかった」 「自分のやり方で間に合ってるので」
2日かけて作ったものが、30秒も見てもらえていなかった。「伝えたつもり」と「届いた」は全然違うと気づいた瞬間でした。
壁は3つ。すべて「届ける側」の設計の問題だった
冷静に振り返ると、壁は3つありました。
ひとつ、そもそも見つけられない。共有フォルダにはフォルダが何十もあり、「あの便利なExcel、どこだっけ」と思っても、探す手間で諦めます。メール通知は翌日には他のメールに埋もれて消えていました。
ふたつ、開いても何をすればいいか分からない。Excelを開くと最初に見えるのはマクロの設定シートでした。作った側には「裏側」でも、初めて開く人にとっては「最初の画面」です。「何これ？」で閉じられていました。
みっつ、今の作業を中断してまで試す理由がない。現場の人にとって、便利かもしれないツールより「今の締め切り」が優先です。「後で見よう」の「後で」は来ません。
共通しているのは、どれも「ツールが悪い」のではなく「ツールにたどり着くまでの道」がなかったことです。
通知ゼロで3人が使い始めた
直したのは、技術ではありません。置き場所と名前と最初の画面です。
チームが毎朝必ず開く共有フォルダに、ショートカットを置きました。ファイル名は「集計ツールv2_最新版.xlsx」から「▶今日の集計はここから.xlsx」に変えました。1シート目は設定画面をやめて、「今日の日付が自動入力された入力欄」にしました。
それだけで、追加の通知を一切せずに、3人が使い始めました。
定期レポートでも同じことが起きました。毎月送っているのに「確認しましたか？」の連絡が来る。送る（プッシュ型）のをやめて、共有フォルダに「いつでも最新」を置き、見るタイミングを受け取る側に決めてもらう（プル型）に変えたら、確認依頼が週2〜3件から0〜1件に減りました。
第1の理由：「配れば使われる」は思い込み。現場に届くのは「通知」ではなく「導線」。
第2章：同じツールが「神」と「邪魔」に分かれた日
3回のエラーで「やっぱり自分にはAI無理ですね」
「AIを使えばマクロが作れますよ」
そう伝えたとき、相手の目が少し明るくなりました。Excel作業に毎日30分かけている人でした。
ChatGPTの画面を開いて、「こういうマクロを作って」と入力してもらいました。出力されたコードを貼り付けて、実行。エラー。プロンプトを修正して、実行。またエラー。3回目。やっぱりエラー。
「やっぱり自分にはAI無理ですね」と言われました。
でも、これはAIの能力の問題ではありませんでした。「どのシートのどの列を集計するのか」「出力先はどこか」——人間同士なら「見ればわかる」前提条件が、AIには一切伝わっていなかった。それだけです。
そこで、AIが「いきなりコードを出さず、先に要件を質問してくる」仕組みを作りました。質問に答えるだけで要件が固まり、最初からエラーなく動くコードが出てくる。初心者には決定的に刺さりました。「AIが使える」と感じるかどうかは、AIの性能ではなく、最初の成功体験があるかどうかで決まるからです。
同じものが、別の人には「邪魔」だった
ところが、同じツールをAIに慣れている人に渡すと、反応はまったく違いました。
「質問が多すぎる」「自分で書いたほうが早い」「いちいち確認してこなくていい」
初心者のために丁寧に要件を聞く設計が、自分で前提条件を伝えられる人には「知っていることを何度も聞かれるストレス」でしかなかった。同じツールが、ある人には神ツールで、別の人には邪魔なツールになりました。
これはAIツールに限った話ではありません。Excel関数を教えたら「手で確認したほうが安心」と言われたことがあります。共有テンプレートを作ったら「前のやり方のほうが分かりやすい」と言われたこともあります。
手で確認するほうが安心な人にとって、関数は「見えない処理」であり不安の種です。慣れたやり方がある人にとって、新しいテンプレートは「覚え直し」のコストです。相手には相手の前提がある。
第2の理由：「便利」は届け先で意味が変わる。全員向けの便利は存在しない。「便利を渡す」のと「便利が届く」のは別の話。
第3章：ライセンスは降りた。でも誰も使わなかった
「どこで使えばいいですか？」
社内でAI活用の共有会を数ヶ月続け、役員から「定期で説明してほしい」と声がかかり、ついにM365 Copilotのトライアルライセンスが降りることになりました。
あのとき、正直「あとはみんな使ってくれる」と思っていました。環境が整えば自然に広がる、と。
1週間後に届いたのは、期待とは違う反応でした。
「どこで使えばいいですか？」 「自分の仕事に合うかわからなくて……」
関心がないわけではない。ただ「使ってみる入口」が見えていなかったのです。
Copilotは機能が多い。メール、会議、文書、Excel——「あれもできる、これもできる」とアナウンスすればするほど、「どれから始めればいいか分からない」状態になります。共有会で「すごい」と感じても、翌朝の業務に戻ったとき「あ、これCopilotでやろう」とはならない。
ライセンスと使用の間に、「最初の1回」の設計が抜けていました。
「1部門1シナリオ」で入口を作った
立て直しはこうしました。各部門に、試すシナリオを1つだけ渡す。
営業チームには「商談後のメール返信ドラフト」。バックオフィスには「週次報告の箇条書きまとめ」。経営企画には「会議議事録の要点整理」。どれもCopilotがなくても毎週やっている既存業務で、そこに「同じことをCopilotでやるとこうなります」という見本を1つ付けました。
シナリオは1ページ、手順は3ステップ以内。渡した翌週に「どうだったか」を10分だけ聞く場を先に予約して、軽い強制力も作りました。
作った本人ですら、最初の画面で止まった
「最初の1回」の壁は、自分が作る側に回ったときに、もっと痛い形で経験しました。
AIに指示して数時間で作った、家庭菜園の記録アプリ。直感的に、操作を少なく、画面は簡素に。「シンプルが正義だ」と思って公開した画面を自分で開いて、止まりました。
最初に出てきたのは、ただの「空っぽの白いマスの壁」。作った本人ですら「で、何をすればいいんだっけ」と止まったのです。
機能はありました。マスを押せば追加できる。でも「押せば追加できる」という手がかりが画面のどこにもない。簡素にしようとして、要素だけでなくヒントまで削っていました。機能は「在る」だけでは、無いのと同じ。見つけてもらえて初めて、機能は存在し始めます。
作っている最中の私は「簡素で良い」と本気で満足していました。作った本人は中身を知っているので、空っぽの画面でも迷わない。この「作り手の目」が、いちばんあてにならない。
第3の理由：使われるかどうかは、機能ではなく「入口」で決まる。最初の1回、最初の画面を設計しなければ、ライセンスも機能も存在しないのと同じ。
第4章：記録はある。でも誰も拾わない
AI議事録の1ヶ月後
会議の記録をAIで自動生成する仕組みを入れたことがあります。
最初の数回は「おお、すごいね」という反応がありました。でも1ヶ月もたつと、誰も議事録ファイルを開かなくなりました。理由はシンプルで、「今の業務に議事録を見返す場面がない」から。過去の記録を見なくても、今日の仕事は回る。だから開かない。
そして期末。「今期の成果は？」と聞かれて、全員が黙る。記録はあるのに、半年分の発言ログの山から「自分が何をやったか」を拾い出すのは、記憶で思い出すのと大差ない労力がかかる。
AI議事録は「記録する」を解決しました。でも「記録から成果を拾い出す」は解決していなかった。記録の量を増やしても、拾える形になっていなければ、振り返りには使えません。
FAQの翌週
FAQでも同じでした。整備を終えた翌週に、同じ内容の問い合わせが届きました。
「先週共有しましたよ」と返しかけて、止まりました。共有した、は正しい。でも「見てもらえた」とは別だ。そして「見てもらえた」と「必要なときに見つけられる」も、また別の話だ。
質問が浮かんだとき、人はFAQを探す前に「誰かに聞く」が先に動きます。人に聞くほうが速くて楽だからです。FAQへのアクセスが「人に聞く」より速くならない限り、FAQは使われません。
AIニュース配信の反応ゼロ
極めつけは、社内へのAIニュース自動配信でした。
AIで最新情報を自動収集して要約し、Teamsへ自動投稿する仕組みを作りました。「調査→要約→自動配信」の流れは完璧に回りました。
反応はゼロでした。👍もコメントも「見たよ」の一言もつかない。1週間経っても、2週間経っても。
壁はシステムの中ではなく、外にありました。現場の人は「情報を追いたい」のではなく、「目の前の仕事を終わらせたい」。どれだけ便利な仕組みを作っても、読むための時間を新しく作ることはできない。「いい情報を届ければ動いてくれる」という前提そのものが間違っていたのです。
ただ、この失敗には続きがあります。「すぐ行動させる」のは無理な目標でも、「記憶に残す」ことは狙える。人は困ったときに過去の記憶から解決策を探します。手作業がしんどくなったとき、「そういえばAIで何かできるって話があったな」と思い出す。そのフックを置く「遅効性リマインダー」と割り切ってからは、配信の設計も評価の仕方も変わりました。
第4の理由：「記録する」と「拾う」、「届けた」と「読まれた」は、それぞれ別の問題。前半だけ自動化しても、後半の設計がなければ成果につながらない。
第5章：情報は「場所」ではなく「仕事」に貼る
ここまでの失敗を貫く共通点に、あるとき気づきました。
私はずっと、情報やツールのための「立派な置き場所」を作っていました。知識をまとめた場所。FAQの置き場。議事録のフォルダ。ニュースのチャンネル。
そして、その置き場所は例外なく「わざわざ見に行く場所」になり、放置されました。
効いたのは、たったひとつの発想転換
発想を変えました。その仕事をやるときに必ず開くもの——案件のメモやタスク——に、背景や狙いを直接くっつけたんです。そうすれば、その仕事をやる人は、嫌でも目に入る。
情報を「別の場所」ではなく「作業に貼り付ける」だけで、見られる確率が明らかに上がりました。動線の上に置く、というだけの話なんですが、効きます。
場所を分けない。情報は「場所」ではなく「仕事」に貼る。
透明な組織とは、立派な情報置き場のある組織ではありません。「人に聞くコストより、自分で引くコストが安い」状態が作られている組織です。情報が人を経由するのは、たいていその人に聞くのが一番ラクだから。書くコストと探すコストを下げれば、人は勝手に「人を経由しなくなる」。ここ1年で実感しているのは、この「書く・探す」コスト下げこそ、AIが最も効くところだということです。
「念のため全員」が、いちばん埋もれる
一方で、はっきり失敗したこともあります。
最初に作った「別の場所の知識ベース」が放置されたこと。そして、その反省から「念のため全員」へ通知したら、今度は量が多すぎて誰も読まなくなったこと。
良かれと思った全員共有が、いちばん埋もれる。
通知は「全員」をやめて、関係する人だけ・必要なときだけに絞る。届ける範囲を広げることと、届くことは、むしろ逆方向でした。
第5の理由：情報は「場所」に置いた瞬間に死に始める。生かしたければ、仕事の動線上に貼る。
第6章：それでも使われないとき——設計で解けない問題
導線を作った。届け先を分けた。入口を設計した。拾う仕組みを作った。仕事に貼った。
それでも、使われないことがあります。
「これ、自分の仕事なの？」
冒頭の突発案件に戻ります。誰もやりたがらない、でも会社として対応必須の案件。
私は問題を2つに分けられていませんでした。ひとつは「伝わらない問題」。伝言ゲームで思いが薄れるやつです。もうひとつは「動かない問題」。伝わっても「自分の仕事なの？」と乗り気にならないやつです。
伝わらない問題は、ここまでの章の技術で解けます。導線、入口、貼り付け。AIも効きます。
でも、動かない問題は別物でした。
部署最適で考えると、自分の範囲だけこなすのが一番合理的に見える。これはサボりではありません。評価が「自分の範囲」で決まる以上、範囲外の大変な仕事を引き受けるのは、リスクだけ増えてリターンがない。だから合理的に避けている。
つまり、たとえ思いが100%伝わっても、評価のしくみがそのままなら、人は動きません。
AIや情報設計で直せるのは「伝わらない問題」だけ。しくみ・評価・モチベーションの問題は、どれだけ設計を磨いても動かない。
唯一できたこと
それでも、境界線の手前で唯一効いたことがあります。
情報を「事実」ではなく「あなたへの影響」の形に翻訳して渡すことです。
「案件が来た」ではなく、「これをやると、あなたが普段詰まっているところが楽になる」と。
これで半分は自分ごとに寄りました。でも残り半分は、やはりしくみの問題です。そこは一実務者の設計では届かない。届かないと認識できたこと自体が、収穫でした。
着手前に、1本の線を引く
100回の失敗の最後にたどり着いた結論は、こうです。
便利にしても使われないのは、設計の失敗とは限らない。そもそも設計で解く問題ではない、ということがある。
だからいまは、何かを作り始める前に一度だけ自問します。
「これは、情報設計で解ける問題か？」
解ける側なら、この記事の7つの型を順に潰せばいい。解けない側なら、ツールを作り込むだけ無駄です。しくみの議論に持ち込むか、「影響の翻訳」で半分だけ寄せるか、撤退するか。線の右側と左側では、打ち手がまったく違います。
この1本の線を最初に引けるようになったことが、100回の失敗でいちばん大きな収穫でした。
終章：「使われない」チェックリスト——明日から試せる7つの一歩
最後に、7つの型を「作る前・配る前のチェックリスト」に圧縮します。私はいま、何かを作るたびにこれを見ています。
導線：通知して終わりにしていないか。相手が毎日必ず通る場所に置いたか
届け先：「誰の・どの業務が」楽になるか特定したか。初心者と慣れた人を同じもので狙っていないか
入口：最初の1回・最初の画面を、初見のつもりで確かめたか。「次に何を押すか」の一言があるか
回収：記録した情報を「拾う」場面と形を決めたか。記録だけ自動化して満足していないか
場所：情報を「別の場所」ではなく、その作業で必ず開くものに貼ったか
翻訳：「事実」ではなく「あなたへの影響」の言い方で届けたか
境界線：そもそもこれは、情報設計で解ける問題か
7番が最初で最後の問いです。1〜6をどれだけ磨いても、7の線の向こう側にある問題は解けません。逆に、線のこちら側なら、たいてい1〜6のどれかで直ります。
ツールはどんどん賢くなります。AIを使えば、動くものは数時間でできる時代です。だからこそ、差がつくのは「作る力」ではなく「使われる設計」と「解ける問題の見極め」だと、私は100回の失敗から学びました。
あなたの職場の「便利にしたのに使われないもの」は、7つのうちどの型でしょうか。それとも、線の向こう側でしょうか。
実験記録一覧（本文の元になった個別記事）
この記事のエピソードは、すべて下記の実験記録として個別に公開しています。
この記事が参考になったら「スキ」で教えてください。あなたの現場の「使われなかったもの」の話も、コメントで聞かせてもらえたら嬉しいです。
このnoteでは、現場改善・AI活用・小さな自作ツールの試行錯誤を記録しています。
初めての方はこちらからどうぞ。
▶ はじめての方へ｜このnoteで書いていること
