※本記事は特定の企業・部署・個人を指すものではない。社内事情は身元が特定されないよう抽象化している。
私は一時期、社内DXの名のもとに、少人数で毎週時間を確保してプログラミング研修を回していた。
資料も作った。課題も用意した。質問にも答えた。伴走もした。
それでも、現場はほとんど変わらなかった。
「頑張ったのに報われない」という感覚だけが残った。
それ以来、私はこういうスタンスに切り替えた。
- 「研修を増やしてどうにかする」は断る
- 上司に抗議を頼まれても、基本は断る（議論しても勝ち筋が薄いと分かった）
- ただし、本当に教えてほしい人がいるなら、私が直接教える。必要な範囲で面倒を見る
冷たく見えるかもしれない。だが、これは諦めではなく最適化だ。
全員にプログラミングを身につけさせる設計は、構造的に破綻しやすい。
その理由を、経験ベースで言語化しておく。
研修が無駄になる原因は「努力不足」ではない
研修がうまくいかないと、だいたい最後は精神論になる。
- 受講者のやる気が足りない
- 忙しいから続かない
- 学ぶ文化がない
- 自走できない
もちろん一部は当たっている。だが、それを理由にすると何も改善しない。
本質は別にある。
研修が無駄なんじゃない。研修からDXに入る会社の設計が無理筋になりやすい。
現場が動かない原因を「人の問題」に押し付けると、永久に同じ失敗を繰り返す。
これは人の質ではなく、構造の問題だ。
プログラミングは「勉強」じゃなくて「工作」に近い
ここからが核心だ。
多くの会社は、プログラミングを「勉強」として扱う。
つまり学校の延長として設計してしまう。
- 講義
- 例題
- 小テスト
- 修了
- 出席率
- 受講満足度
だが、プログラミングはこの枠に入らない。
なぜなら、プログラミングは勉強というより工作に近いからだ。
コードは工具で、評価は成果物でしかできない
工作を想像すれば分かる。
ノコギリ、ドリル、ヤスリ。
工具にはそれぞれ用途があるが、工具の使い方をわざわざテストしない。
- 「ドリルの回転数を暗記せよ」
- 「ヤスリの番手を説明せよ」
- 「ノコギリの角度を答えよ」
そんな試験をやっても棚は完成しない。
評価方法はひとつしかない。
成果物を見るしかない。
プログラミングも同じだ。
if文を説明できても、コードを書けても、現場が変わらなければ意味がない。
DXで欲しいのは点数ではなく、**完成した“使えるもの”**だ。
「テストで測れるもの」と「現場で役立つもの」は別物
プログラミング研修が失敗する会社は、ここを取り違える。
テストで測れるのは、せいぜい「知識」だ。
- 文法を知っている
- 関数の名前を覚えた
- 例題をなぞれる
しかし現場で必要なのは「知識」ではない。
必要なのは「完成させる力」だ。
工作と同じで、プログラミングの本番はこうなる。
- 手順が曖昧
- 要件が途中で変わる
- データが汚い
- 例外だらけ
- それでも期限は来る
この状況で動けるかどうかは、テストでは測れない。
測れるのは成果物だけだ。
初心者脱出のゴールは「作品を1個作る」しかない
プログラミングにはゴールがない。覚えることは無限に増える。
だから「研修を終えた＝できるようになった」になりにくい。
しいて初心者脱出のラインを定義するなら、私はこれだと思っている。
「一人で業務改善ツールを1つ完成させる」
ここまで来て初めて、工具が“道具”になる。
逆に言えば、何も作れない限り、工具はただの知識のままだ。
そして、ここでほとんどの人が止まる。
最大の壁：「何を作っていいか分かりません」
研修を回していて何度も聞いた言葉がこれだ。
何を作ればいいか分かりません
自分の業務で使える題材が思いつきません
この瞬間、研修は終わる。
そして多くの会社が、ここでまた「やる気」や「意識」の話に逃げる。
だが私は、この停止はやる気の問題じゃないと思っている。
もっと残酷で、しかし健全な理由がある。
課題設定は、プログラミング以前のスキルだ
業務改善ツールの題材は、与えられるものではない。
自分の業務を観察して、ムダを見つけて、切り分けて、再設計する必要がある。
つまりこういうことだ。
- プログラミングを学ぶ前に
- 改善ポイントを見つける力が必要
ここがないと、研修は「じゃんけんアプリ」「ToDoアプリ」「電卓作成」で終わる。
それ自体が悪いわけではない。だが現場は変わらない。成果に変換されない。
そして現実として、課題設定ができる人は多数派ではない。
これは努力不足ではなく、役割分担の話だ。
「全員を作り手にする」設計が破綻する理由
ここまでをまとめると、研修が破綻する理由はシンプルになる。
全員を“作り手”にする前提が間違っている。
プログラミングは、スポーツや工作と同じで差が出る。
ただし大事なのは、「才能がない」で切り捨てることではない。
差が出るのは多くの場合、才能ではなく条件だ。
- 自分の業務に強い痛み（ムダ）がある
- 改善したいという執着がある
- 試せる環境がある（権限・データ・ツール）
- 少しでも評価される
- 相談できる相手がいる
この条件が揃った人だけが、研修を“現場の成果”に変換できる。
逆に言えば、条件が揃っていない人に「学べ」と言っても無理が出る。本人の問題ではない。
社内研修が空回りする会社の共通点
私が見た限り、研修が空回りする会社には共通点がある。
1. ゴールが「受講」になっている
成果が「受けたこと」「出席率」「修了証」になった瞬間、DXは死ぬ。
現場が欲しいのは修了証ではなく、時間と手戻りの削減だ。
2. 作るための権限・環境・データがない
社内は制約が多い。特に規制産業は顕著だ。
勝手にツールを入れられない、データを触れない、配布できない。結果こうなる。
学ぶ → 試せない → 忘れる → 研修だけが残る
3. 評価されない
作っても評価されないなら、学習コストが回収できない。
続かないのが普通だ。
4. 保守が設計されていない
作るところまで行けても、運用がない。
- 誰が管理するのか
- 異動したら誰が直すのか
- 事故ったら誰が責任を取るのか
これが曖昧な組織では、改善ツールは「怖くて使えないもの」になる。
じゃあ、どうするべきか：教育より先に「設計」をやれ
ここからが建設的な話だ。
結局、会社がやるべきは「教育の強化」ではなく「設計」だと思う。
1) 作り手を2〜3人決める
全員に学ばせない。まず作り手を固定する。
適任者は「興味がある人」ではなく、現場の痛みを知っていて改善に執着できる人だ。
2) 1本目の題材（設計図）を会社が用意する
「何作ればいいか分からない」を潰す。
工作で言えば、工具の使い方より先に“作るもの”を決める。
初心者の1本目は、だいたいこれでいい。
- 定型の転記をなくす（Excel→Excel、CSV→Excel）
- 入力漏れ・ルール違反を自動検出する
- 定型レポートを自動生成する
- ファイル整理、重複検出、バックアップを自動化する
- ログの整形、差分抽出、集計を自動化する
ポイントは「小さい」「壊れても影響が小さい」「一人で完結する」だ。
3) 相談窓口を作る（週1の30分でいい）
詰まったら聞ける場所を用意すると継続率が上がる。
研修よりこっちの方が効くことが多い。
4) 成果物をテンプレ化して横展開する
内製化は“個人芸”で終わらせたら負けだ。
テンプレ化して配る。誰でも使える形に落とす。
5) 保守と責任を決める
運用が決まって初めて「会社の資産」になる。
ここまでやらないと、現場は使わない。
私が「研修の増設」を断る理由は、責任だけが増えるから
研修を増やすほど、責任だけが増える。
- 受講者が伸びないと、教える側が反省させられる
- 研修は続くのに、成果が出ない
- 現場にも教える側にも恨みが溜まる
この構図に入った時点で、もうやめた方がいい。
だから私は割り切った。
「全員を引き上げる」ではなく「伸びる人を最短で伸ばす」
その方が組織の成果に直結するし、現実的だ。
そして、教えてほしい人がいるなら教える。
それが一番フェアで、一番効く。
まとめ｜工具のテストをしても棚は完成しない
社内DXでプログラミング研修が無駄になりやすいのは、受講者の努力不足ではない。
設計が間違っていることが多い。
- プログラミングは「勉強」ではなく「工作」に近い
- 工具の知識をテストしても成果物は生まれない
- 評価できるのは点数ではなく成果物だけ
- 初心者脱出のゴールは「業務改善ツールを1つ作る」
- そこで大半が「何を作ればいいか」で止まる
- だから必要なのは教育の増設ではなく、少数精鋭＋題材設計＋横展開＋運用設計だ
全員をエンジニアにするな。
作り手が勝てる環境を作れ。
そして成果物で評価しろ。
DXは「受講」ではなく「完成」でしか進まない。
余談
余談だが、AIが出てきたとき、私は「全員がコードを書けるようになる未来」を想像して少し怖かった。だが最近は逆だと思っている。仮に“全自動工作マシーン”ができても、作りたいものがない人は何も作れない。AIは工具をさらに便利にするだけで、目的まで勝手に生み出してはくれない。だから私は、プログラミング（というより“作れる側”）が簡単に飽和するとは思っていない。むしろ「何を作るか」を決められる人の価値は、AI以降さらに上がる。
