先日、都内で飲食店を2店舗やっているオーナーさんに、業務システムのヒアリングをしていたときの話です。人件費の管理がどうにもうまくいかない、という相談でした。
「毎日いくら人件費がかかっているか、誰がどれだけ入っているかが一目で分かる画面、作れますよ」と提案したんです。技術的には難しくない。そうしたら、返ってきたのがこれでした。
そのシステムで金額が見れたとしても、うちの社員は「うーん」で終わるんですよ。「ああ、これぐらいかかってんだな、じゃあ帰らせます」で、結局帰らせない。
ぐうの音も出ませんでした。僕らが作れるのは「見える」までで、「動く」はその先にある。 しかも、その先のほうがだいたい難しい。
気になって、国内外の事例と研究をひと通り調べてみたんです。そうしたら、同じ壁に、規模を問わず全員がぶつかっていました。この記事は、その調べものの報告と、じゃあ現場でどうするかのまとめです。
01日本の中小企業で、何が起きているか
まず国内から。独立行政法人 中小企業基盤整備機構が2018年に出した「IT導入に関するアンケート調査」では、IT活用に取り組んでいて課題を抱えている企業のうち、「導入したITを使いこなせない」を挙げた企業が35.3%ありました。入れたけれど使えていない、が3社に1社です。
補助金の世界でも同じことが起きています。日本経済新聞は2026年2月に「IT補助金の『実績』独り歩き 中小企業、6割は業績改善せず」という記事を出しました。補助金で予約・決済システムを入れたのに、ほとんど使っていない事業者の例が取り上げられています。
これは行政も認識していて、ITmediaの取材に対して中小企業庁の担当者は、導入後に使い方が十分に理解されず活用されないケースがあることを認め、2025年度から導入後の活用支援を手厚くしたと説明しています。
人の問題も重なります。IPA（情報処理推進機構）の「DX動向2025」では、日本企業の85.1%でDXを推進する人材が不足していると報告されています。入れたあとに社内で面倒を見る人がいない、という状態が常態化しているわけです。
02海外の巨大企業も、同じところでこけている
金をかければ解決するのかというと、そうでもない。何百億円という規模で、同じ失敗が繰り返されています。有名なものを並べます。
| 事例 | 何が起きたか | 教訓 |
|---|---|---|
| ネスレUSA（1990年代後半〜2000年） | SAPの全社導入で、現場の混乱が収まらず。CIO誌の記事によれば、ヘルプデスクへの問い合わせは1日300件、需要計画の担当者は新システムを使わず従来のスプレッドシートに戻り、その職種の離職率は77%に達した | 使う人を設計に入れなかった。当時のCIOは後に、それが致命的なミスだったと振り返っている |
| ハーシー（1999年） | ERPの本番切り替えをハロウィン前の最繁忙期に強行。テストを省略し、従業員の研修も十分に行えないまま稼働させた | 繁忙期に切り替えると、教える時間も覚える余裕も消える |
| ナイキ（2000年） | 需要予測システムが遅く不具合も多く、運用する従業員の訓練にもっと資源を割く必要があったと指摘されている | 動くものを作ることと、運用できる人を用意することは別の仕事 |
| リドル（2011〜2018年） | SAP導入を7年続けた末に中止。在庫を仕入価格で評価する自社の古いやり方を変えられず、システム側の標準とぶつかり続けた | 教育以前に、業務をシステムに合わせるのか、システムを業務に合わせるのかを決めていなかった |
並べて気づくのは、技術そのもので失敗した例がほとんどないことです。詰まっているのは全部、人と業務の側でした。
03なぜ使われないのか、には研究がある
感覚の話だけで終わらせたくなかったので、理論も当たりました。情報システムがなぜ使われる／使われないかを説明する古典に、技術受容モデル（TAM）があります。1989年にデイビスが提唱したもので、総務省の調査研究などでも基本モデルとして使われています。
TAMが言っているのはシンプルで、人がシステムを使うかどうかは、だいたい次の2つで決まる、という話です。
- 知覚された有用性 — これを使うと、自分の仕事の成果が上がると本人が信じている度合い
- 知覚された使いやすさ — これを使うのに、大した努力はいらないと本人が思っている度合い
そして実証研究では、使いやすさより有用性のほうが、利用意図への結びつきが強いという結果が繰り返し出ています。
これ、さっきの飲食店の話とぴったり重なるんですよ。人件費の画面は、作れば「使いやすい」ものにはできる。でも現場の社員にとっては、それを見たところで自分の仕事は良くならない。むしろ、早く帰らせる面倒が増えるだけです。有用性がマイナスなんだから、使わないのは当たり前だった。
使われないのは、使いにくいからではない。使う理由が、その人の側に無いからだ。
04教えないことのコストは、きちんと数字に出る
教育を省くと何が起きるかを、いちばん厳しく記録しているのは医療の現場です。電子カルテ（EHR）の導入は、世界中で同じ問題を起こしてきました。
- フィンランドの看護師を対象にした横断調査では、電子カルテの導入そのものに加えて、研修が不十分だと情報システムによるストレスが高まることが示されている
- 米国の大学病院で、導入の旗振り役を担った医師45人に稼働の約5か月後に聞き取りをした研究では、研修の不足、現場に張り付く支援の不足、経営層やベンダーとの連絡の不安定さが課題として挙がった。彼らは結局、自前で研修を作り、支援を自分たちで調達していた
- 家庭医療のレジデントを対象にした研究では、約3分の1（32.3%）が勤務時間外に平均3時間以上を電子カルテ業務に費やし、それが長いほど燃え尽きのリスクが高く、仕事への満足度が低い傾向が報告されている
人が辞める、病む、時間外が増える。教えなかった分は消えてなくならず、現場の負担として現れるということです。
05では、何が効くとされているのか
ここからは、効果があるとされている側の話です。
変革管理（チェンジマネジメント）の専門会社プロサイは、自社の調査として、効果的なチェンジマネジメントを行ったプロジェクトは88%が目標を達成または上回ったのに対し、不十分だった場合は13%だったと公表しています。自社サービスの根拠として出している数字なので割り引いて読む必要はありますが、桁が違うことは確かです。
もうひとつ、日本の製造業にはTWI（監督者訓練）という、戦中・戦後に米国から入って定着した教え方の型があります。その中の「仕事の教え方（JI）」は、教える手順を4段階に固定しています。
| 段階 | やること |
|---|---|
| 1. 習う準備をさせる | 気楽にさせ、何の作業かを話し、知っている程度を確かめ、覚えたい気持ちにさせる |
| 2. 作業を説明する | 主なステップを1つずつ、言って、やって見せて、書いて見せる |
| 3. やらせてみる | やらせてみて、間違いを直す。できるようになるまで確かめる |
| 4. 教えたあとをみる | 仕事につかせ、分からないときに聞く人を決めておく。だんだん指導を減らす |
医療の世界で定着しているやり方も、構造は同じです。スーパーユーザー（現場の中に、詳しい人を何人か作っておく）と、at-the-elbow support（稼働直後、困った瞬間に横にいる人を配置する）。研修室で教えて終わりにせず、実際の仕事の場に支援を持ち込むという点で共通しています。
06まとめ：システムを「使われる」状態まで持っていくための10
ここまでの調べものを、うちが実際にやること・やろうとしていることとして並べ直します。発注する側で読んでいる方は、発注先にこれをやる気があるかを見る基準としても使えると思います。
1. 「使われている」の定義を、作る前に数字で決める
いちばん効くのにいちばん飛ばされるのがこれです。納品の検収条件は「仕様どおり動くこと」になりがちですが、それだと動いていれば合格になる。そうではなく、稼働3か月後に何がどうなっていたら成功かを、作る前に一文で書いておく。「店長が毎日1回は開いている」「紙の日報が廃止されている」「締め作業が平均20分短くなっている」。数字が動かなければ、きれいに動いていても失敗です。これを先に決めておくと、作っている最中の判断も速くなります。
2. 教える相手を間違えない
ネスレの教訓そのものです。説明会に呼ばれるのはたいてい決裁者と管理職ですが、毎日そのシステムを触るのは現場の人で、その人たちが使わなければ何も起きない。設計のヒアリングの時点で、実際に入力する人を1人でも同席させる。できないなら、せめてその人の1日の動きを聞き取ってから設計する。
3. 「有用性」を、その人の言葉で言えるようにする
TAMが示したとおり、人は「自分の成果が上がる」と思えないものは使いません。だから説明の仕方を変えます。「人件費が可視化されます」ではなく、「これを使うと、あなたが毎晩やっているあの集計がゼロになります」。経営にとっての価値と、現場にとっての価値は別物で、現場に刺さるのは後者だけです。ここが言えないシステムは、そもそも作らないほうがいい。ちなみにこれを探す作業は、設計のヒアリングと同じ作業です。現場の人が毎日いちばん嫌がっている作業を1つ見つけて、それを消す。それが言えれば、説明はほぼ要らなくなります。
4. 研修は「説明」で終わらせず、必ず「やらせてみる」まで行く
TWIの4段階でいうと、多くの導入研修は第2段階（説明する）で止まっています。説明を聞いて分かった気になることと、できることは別です。その場で本人に触らせて、間違えさせて、直すところまでを1セットにする。画面を見せながら喋る1時間より、実データで5件入力してもらう20分のほうが残ります。
5. 覚えていないのは、教え方のせいだと考える
「何回も説明したのに」「あの人はITが苦手だから」で止めると、そこから先が一歩も進みません。TWIの「相手ができていなければ、教えたことにならない」をそのまま採用して、できていない＝こちらの教え方か、システムの作りに原因があると考える。そう決めておくと、改善の宛先が自分たちになるので、実際に直ります。
6. 稼働直後の2週間に、人を貼る
医療のat-the-elbow supportの考え方です。マニュアルを配っても、人は詰まった瞬間に読みません。その場で聞ける人がいるかどうかで、最初の2週間の体験が決まり、そこでの体験がその後の定着をほぼ決めます。遠隔でもいいので、即答できるチャットの窓口を開けておく。質問が来なくなったら喜ぶのではなく、使われていないことを疑ったほうがいい。順調に定着しているときは、むしろ細かい要望が増えます。
7. 現場に1人、詳しい人を作ってから引き上げる
スーパーユーザーの考え方です。外部の開発会社は必ずいなくなります。 いなくなった後に社内で聞ける人がゼロだと、小さなつまずきが積み上がって、半年で誰も開かなくなる。だから納品前に、現場の中から1人か2人、他の人に教えられるところまで引き上げておく。その人の負担が増えるので、そこは経営側が評価で報いる必要があります。
8. 前のやり方を、意図的に閉じる
ネスレの計画担当者はスプレッドシートに戻りました。退路があると、人は必ず慣れたほうに戻ります。 紙の日報をなくす、旧システムを止める、二重入力をやめる。ただし、これは新しいやり方が本当に回ると確認できてからです。順番を間違えると、業務が止まります。
9. 教育コストを、最初の見積もりに入れておく
ここまでの8つは、全部ただではできません。研修の時間も、張り付く人も、スーパーユーザーを育てる工数もコストです。それを見積もりに入れず「サービス」でやろうとすると、忙しくなった瞬間に真っ先に削られる。削られた結果が、使われないシステムです。だから最初から、作る費用と使えるようにする費用を分けて書く。発注する側も、そこが0円になっている見積もりは一度疑ったほうがいいと思います。
10. 半年後に、必ず一度見に行く
納品して請求書を出したら関係が終わる、という契約の形そのものが、定着を邪魔している面があります。使われなくなるのは稼働直後ではなく、応援がいなくなった3か月後から半年後だからです。だから最初の契約に、半年後に一度様子を見に行く約束を入れておく。そのときに見るのは画面の動作ではなく、1番目で決めた数字です。動いていなければ、作りを直すのか、教え方を直すのか、そもそも業務のほうを変えるのかを、もう一度やる。ここまでやって、ようやく「導入した」と言えるんだと思います。
07作れる人より、使われるところまで持っていける人
ここまで書いてきて思うのは、システム開発という仕事の難しさの半分以上は、技術の外側にあるということです。
コードを書くところは、正直いまAIがかなりの部分を持っていきました。AIと会話しながら開発の現場に立っているメンバーもいますし、うちはそれを前提に体制を組んでいます。そのぶん、人間の側に残る仕事は、ここで書いたような現場を見て、誰に何を教えるかを設計するほうへ寄っていきます。
そして、この仕事に効くのは、プログラミングの経験よりも現場で働いた経験のほうだったりします。飲食店で働いたことがある人は、ピーク中に端末を触る余裕がないことを知っている。事務をやっていた人は、二重入力がどれだけ心を削るかを知っている。その感覚は、AIの中には入っていません。
前に別の記事で、試した回数が全員に配られた時代に差がつくのは「何をもって当たりとするかを決めるところ」だと書きました（天才って、たぶん「試した回数」のことなんですよ）。システム導入でいえば、それが1番目に書いた「使われているの定義」です。結局、同じ話にたどり着きました。
