社内で何か仕組みを作ろうという話になると、まず出てくるのは「誰に頼むか」です。詳しい人。ITに強い人。あるいは、外の会社。

その順番が、いま逆になりつつあります。

作るのは詳しい人の仕事——この前提こそが、見直すべきいちばん大きなものかもしれません。今日は「誰が作るのか」という話をさせてください。

全6回の5本目です。前回は、AIで空いた手をどうするか——現場の不安に、経営者がどう答えたかをお話ししました。今回は、その先です。空いた手で、現場の人が何をするのか。私は、その一つが「自分の道具を、自分で作ること」だと思っています。

第1回で、AIを使うには三つの段階がある、とお伝えしました。AI入りのツールを使う。自分でAIに指示を出す。そして三つ目が、AIを使って自分の業務用のアプリを作ってしまうこと。あのとき「三つ目のインパクトが大きい」とだけ書いて、先へ進みました。今日は、その三つ目を、担い手の側から見ていきます。

これまでは、「作れる人」が作ってきた

考えてみると、これまで道具を作れたのは、技術を持っている人だけでした。

だから、困っている人は自分で作れません。かわりに「こういうものが欲しい」と説明する必要がありました。これを、要件定義と呼びます。

要件定義とは、要するに困っている人の頭の中を、作れる人の頭の中に移す作業です。そして、ここがいちばん失敗するところでした。

日々その作業をしている人にとっては当たり前すぎて、言葉にならない部分があります。「まあ、そこは適当にやってます」「例外のときは、こうしてます」。その「まあ」と「例外」にこそ、現場の勘所が詰まっている。でも、聞かれなければ出てこないんです。

できあがったものを見て「ちょっと違うんですよね」となる。あの現象の正体は、たいてい伝言の途中で落ちたものです。

AIが変えたのは、その順番のほうです

AI研究者のアンドレイ・カーパシー氏が、こんな言い方をしています。

「いま最も熱いプログラミング言語は、英語だ」

私たちで言えば、日本語がそのままプログラミング言語になった、ということです。

つまり、「作れる人」の条件が変わりました。プログラミング言語を知っていることではなく、何を作りたいかを言葉にできることが条件になった。

そうなると、順番が逆転します。困っている人が、作れる人に説明する必要がない。困っている人が、そのまま作り手になれるからです。

実は、この考え方自体は新しくありません。「シチズンデベロッパー」という言葉があります。プログラミングの知識はないけれど業務をよく知っている現場の担当者が、自分でシステムを作る、という考え方です。もう二十年近く言われ続けています。

ではなぜ、広がらなかったのか。ツールを覚える必要があったからだと思っています。専用のツールを導入して、その使い方を習得する。結局そこで「詳しい人」が必要になり、話が元に戻ってしまう。

日本語で頼めるようになって、初めてその壁が消えました。

現場の人が作ると、何が変わるのか

第1回で紹介した、設計図面の距離を測るアプリの話を覚えているでしょうか。「全自動にできないか」という相談が、話を聞くうちに「始点と終点を指定したら、距離が出る」だけに絞られ、半日で形になった、あの件です。

今度は、それを「誰が削ったのか」という側から見てみます。

このとき私が思ったのは、「それだけでいい」と分かるのは、現場の人だけだということです。外から見ると、どこまでが必要でどこからが要らないのか、判断がつきません。だから念のため全部盛り込もうとして、要件が膨らみ、いつまでも完成しない。

アプリと呼ぶほどのものでなくても構いません。ExcelのマクロでもGoogleのスプレッドシートを動かす仕組みでも同じです。毎回15分かけている転記作業が、ボタン一つになる。それで十分です。

そしてもう一つ。第1回で書いたとおり、一度アプリにしてしまえば、使う人はもうAIを意識しなくてよくなります。作り手の側が、リテラシーの差を引き受けてしまえるわけです。

決まりきったルーティンほど、この形が向いています。毎回AIに考えてもらうのは、贅沢な使い方ですから。

ただし、「誰でも作れる」わけではありません

ここは正直に書いておきます。

ペンシルベニア大学のイーサン・モリック教授が、実際にやってみた記録を残しています。AIに日本語ならぬ英語で頼んだだけで、四分で動くゲームができた。ところが途中でバグが出て動かなくなり、そこから復旧するのに二十分かかった。

面白いのは費用です。作るのにかかったのが約五ドル。バグを直すのに、その上さらに八ドル。作るより、直すほうが高くついたわけです。

モリック教授は、こう書いています。

専門性は、消えるのではなく再配分される。一行ずつコードを書く力から、全体を理解して、方向を示し、おかしいところを見つけて評価する力へ。

ですから「誰でも作れます」とは書けません。正確には、現場の知識と、最低限の技術の勘どころ、その両方が要るということです。

ただ、これは希望のある話でもあります。最低限の勘どころは、後から身につきます。でも現場の知識のほうは、その仕事をしていない人には手に入りません。どちらが希少かといえば、明らかに後者です。

私たちは、この二十年で二回失敗しています

ここで、経営者として押さえておきたい点があります。

「現場が自分で作る」は、今回が初めてではありません。そして二回とも、同じ壁にぶつかりました。

一回目は、Excelのマクロです。誰かが便利なものを作る。その人が異動する。誰も直せなくなる。「そのマクロ、作った人しか分かりません」という話は、どの会社にもあると思います。

二回目が、RPAでした。決まった手順のパソコン操作を、ソフトに代行させる仕組みです。「野良RPA」という言葉が生まれたくらいです。現場が勝手に作ったロボットが社内に散らばり、誰が何のために動かしているのか分からなくなった。

そして今回、同じことが「野良BOT」「野良アプリ」として起きようとしています。三度目です。

ただ、今回は一つだけ条件が違います。AIに読ませれば、中身が分かるようになりました。作った人がいなくても、何をしているコードなのか、AIが説明してくれる。属人化のコストが、下がったんです。

とはいえ、これで全部が解決するわけではありません。各自が作り始めた瞬間に、セキュリティのリスクは一段上がります。どのデータに触れているのか。外に出ていないか。誰も把握していない、という状態がいちばん危ない。

過去二回の失敗を振り返ると、原因は「作らせたこと」ではありませんでした。台帳がなかったことです。

そして幸い、その台帳づくりもAIに手伝わせることができます。

まず何から始めるか

• ステップ1：「これ、毎回めんどくさいんですよね」を一つ挙げてもらう（5分）——立派な課題でなくて構いません。むしろ、社内で誰も課題だと思っていないような、小さな手作業のほうが向いています。挙げてもらう相手は、その作業を実際にやっている人です。
• ステップ2：その本人に、AIに話しかけてもらう（30分）——ここが肝心です。上司が代わりに頼むのではなく、困っている本人にやってもらってください。「毎回こういう表を作っていて、ここが面倒なんです」と、普段の言葉のまま話しかけるだけで構いません。
• ステップ3：できたものを、一枚の台帳に書く（5分）——誰が、何のために、いつ作ったか。どのデータを使っているか。この三つだけで十分です。一つ目ができた時点で始めておくのが大事で、増えてからでは間に合いません。

結論｜困っている人を、作り手にする

• 要件定義とは、困っている人の頭の中を作れる人に移す作業だった。そこが最も失敗しやすい工程だったが、日本語で頼めるようになり、その工程自体が要らなくなりつつある
• 「それだけでいい」と削れるのは、困っている本人だけ。現場の知識は後から身につかない。技術の勘どころは後から身につく。希少なのは前者のほう
• 過去二回（マクロ、RPA）の失敗の原因は、作らせたことではなく台帳がなかったこと。作らせる、そのかわり登録させる——この二つをセットで決める

「うちには詳しい人がいないから」。この言葉を、私はよく聞きます。

でも、いま必要なのは詳しい人ではありません。いちばん困っている人です。そして、それはたいてい、社内にちゃんといます。

次回予告

最終回となる第6回は「社内開発か、外注か——第三の『フロント実装』」をお届けします。今回は「社内で誰が作るか」の話でしたが、次回は「社外と、どう組むか」です。自社で抱え込むのでも、丸投げするのでもない第三の道と、年齢に関わらずAIで成果を出す人に共通することを、お話しします。

参考・根拠資料

• Andrej Karpathy 氏の発言（「最も熱いプログラミング言語は英語」／2023年、および2025年の「vibecoding」に関する投稿より）
• Ethan Mollick「Speaking things into existence」（One Useful Thing、2025年3月11日）※制作費約5ドル・デバッグ費約8ドルの実例、および「専門性は消えるのではなく再配分される」の記述より
  https://www.oneusefulthing.org/p/speaking-things-into-existence
• 「シチズンデベロッパー」に関する各種解説（ZDNet Japan ほか）
• 「野良RPA」「野良BOT」に関する国内の議論、およびExcelマクロの属人化リスクに関する各種記事より
• 支援先での研修・対話（筆者の観測範囲より。設計会社での距離計測アプリの事例を含む）