社内でClaude Codeの講習を2回行いました。目的は「便利なツールがあります」と紹介することではなく、実際の開発風景をそのまま見せることでした。結果、開発経験のない事務員が自分の業務課題をひとつ見つけ、ブラウザで動く比較ツールを自分の手で作り上げました。しかもそのツールが実際に現場で使われ、3人でやっていた作業が2人で回るようになりました。「教える」ではなく「見せる」ことの効果を、身をもって実感した出来事です。
きっかけ:座学ではなく「実演」にした理由
社内でAIツールの勉強会をやると聞くと、多くの人は「スライドで使い方を説明する会」を想像すると思います。今回はあえてその形式を避け、Claude Codeの講習を2回とも「実際にその場で開発する様子を見せる」実演形式にしました。
理由はシンプルで、非エンジニアにとって一番イメージが湧かないのは「AIが実際にどう動いて、どう手が止まらずに完成に向かうのか」という工程そのものだからです。機能一覧を説明されても、「自分の業務でどう使えるか」までは結びつきません。だから、実際の開発風景・実装の流れ・使い方のサンプルを、手を動かしながらそのまま見せることにしました。
講習で見せたもの
2回の講習では、次のような流れをそのまま実演しました。
- 「こういうものを作りたい」という曖昧な要望を、Claude Codeに自然な日本語で伝えるところから始める
- AIが提案・実装する様子をリアルタイムで見せ、途中で「ここはこう変えたい」と口頭で修正指示を出す
- エラーが出た場面もあえて隠さず、AIがその場で原因を調べて直していく過程を見せる
- 数十分〜数時間という短い時間で、「動くもの」が画面上にできあがるまでを通しで体験してもらう
ポイントは、完成品ではなく「途中経過」を見せたことです。詰まった瞬間や修正のやり取りまでオープンにしたことで、参加者には「これなら自分にもできるかもしれない」という感覚が生まれたようでした。
教えたのは操作方法ではなく、「詰まっても進められる」という感覚でした。 完成物のデモだけでは、非エンジニアの手は動きません。試行錯誤の過程ごと見せることで、初めて「自分ごと」になります。
事務員が自ら作った「販売図面比較ツール」
講習後、開発経験のない事務員が自分の業務の中から課題をひとつ見つけ出しました。それが「販売図面」と呼ばれる資料の更新作業です。従来は、更新前後の図面を人の目で見比べて、変更箇所を洗い出す作業に複数人が時間を割いていました。
その事務員は、Claude Codeを使って自分でブラウザベースの比較ツールを開発しました。要件は次のようなものです。
設計書もエンジニアの手も借りず、講習で見た「AIに要望を伝え、動くものにしていく」という流れをそのまま自分の業務に当てはめた結果です。
何が起きたか:3人の作業が2人に圧縮された
このツールが実際に現場で使われるようになったことで、これまで販売図面の更新・比較確認に3人がかりで行っていた作業が、2人で回せるようになりました。人の目で1枚ずつ照合していた工程が、画像の重ね合わせとAIによる抽出に置き換わったことで、確認にかかる時間そのものが短縮されたためです。
これは単なる「作業スピードが上がった」という話ではありません。ボトルネックだった照合作業から1人分の工数が浮いたことで、その人員を他の業務に回せるようになった、という組織としての効率化です。しかも、それを実現したのは外部ベンダーでも情シス部門でもなく、日々その業務を行っていた事務員本人でした。
なぜ非エンジニアが「動くもの」を作れたのか
今回の件を振り返って、非エンジニアが自力で業務ツールを完成させられた理由を3つに整理しました。
「業務課題」を一番よく知っているのは現場の本人だった
販売図面の比較にどれだけ時間がかかり、どこが一番面倒なのかを一番よく知っているのは、日々その作業をしている事務員自身です。技術ではなく「何を解決すべきか」が明確だったことが、完成までの一番の推進力になりました。
詰まった時の実演を見ていたから、自分が詰まっても止まらなかった
講習でエラーや試行錯誤の過程を隠さずに見せていたため、実際に自分で作る際に問題が起きても「これは普通に起きること」と受け止められたようです。完璧な手本ではなく、詰まって直すプロセスを見せたことが効いています。
要望を「自然な言葉」で伝えるだけで実装まで届いた
コードを書く必要はなく、「画像を2枚並べて差分を出したい」「変わった場所をAIに文章で教えてほしい」という業務目線の言葉のまま、実装まで進められました。技術的な語彙を学ぶ手間がなかったことが、着手のハードルを大きく下げました。
社内でこれから同じことをやるなら
今回の経験から、社内でAI活用を広げたいときにおすすめできる順番があります。
- 座学ではなく、実際の開発風景をそのまま見せる場を作る(完成品だけでなく、詰まって直す過程まで見せる)
- 「自分の業務で一番面倒な作業」を参加者自身に一つ挙げてもらう
- その場で、あるいは持ち帰って、業務目線の言葉のままAIに要望を伝えてみる
- 小さく動くものができたら、実際の業務に一部だけ試験導入してみる
非エンジニアに火をつけるのは、機能の説明ではなく「詰まっても進める過程」を見せることです。 完成したツールを配るより、自分の業務課題をひとつ持ち帰ってもらう方が、結果として組織全体の効率化につながります。