「非エンジニアでもAIで自社システムを作れる」の落とし穴②──AIに任せるべきは「完成品」より「試作品」！
前回の記事「「非エンジニアでもAIで自社システムを作れる」の落とし穴──結局kintoneやExcelの方が良い？」では、「非エンジニアでもAIで自社システムは作れる。ただ、突き詰めると、kintoneやExcelといった既存のツールで組んだ方が良いことが多い」というお話をしました。今回は、その先にある、もう一段深い問いを掘り下げます。
そもそも、AIでの開発という道具は、いったい「誰のための、何のための」ものなのでしょうか。世間では「非エンジニアでも完成品が作れる」と語られがちですが、私は、それはこの道具の使い方を、半分しか捉えていないと考えています。
AIが本当に輝くのは、「完成品」を作る場面ではありません。「試作品」を、驚くほど速く生み出す場面です。そして、それを使いこなすべきなのは——実は「設計を分かっている人」なのです。この記事では、その理由と、では非エンジニアの経営者は何をすべきかを、率直にお話しします。
「AIで動くものができた」と「システムが完成した」は、別の話
前回もお伝えしたとおり、いまやAIに頼めば、見た目のきれいな「動くもの」は、専門知識がなくても作れてしまいます。ボタンが並び、データが入力でき、一覧で表示される。ここまでは、本当にあっという間です。
ただ、ここで区別しておきたいことがあります。「AIで動くものができた」ことと、「業務で使えるシステムが完成した」ことは、まったくの別物だということです。
「AIを使って、爆速で動くものを作るスキル」と、「本番の業務に耐えるシステムを作るスキル」は、まるで別の能力です。前者で出来上がるのは、あくまで「試作品」。後者で求められるのは、毎日使われ、人が入れ替わっても回り、何年も保守し続けられる「本番品」です。見た目は似ていても、中身の難しさがまるで違います。
これは、私が現場で実際に見てきたことです。そして同じことは、私とは別の立場、別の状況で「AIでのシステム開発」に携わる人たちからも、よく聞こえてきます。置かれた状況の違う人間が、それぞれの現場を経て同じ結論にたどり着く。そうなると、これはもう個人の感想ではないのだと思います。
AIでの開発が、魔法のように見える瞬間
誤解のないように言っておくと、私はAIでの開発を否定したいわけではありません。むしろ逆で、その威力は本物だと思っています。
最近では、こうしたAIを駆使した高速開発のスタイルは「バイブコーディング」（雰囲気で指示するだけで、AIがどんどんコードを書いてくれる開発手法）などと呼ばれ、注目を集めています。実際、頭の中にあったアイデアが、数日で「動く形」になる。その勢いは、初めて体験すると魔法のように感じられます。
この爆速さが、いちばん活きる場面があります。それが「とりあえず形にして、試してみる」という場面です。アイデアが本当に使えそうか、画面はこれで分かりやすいか——頭の中だけで悩んでいたことを、すぐ「触れるもの」にして確かめられる。この「試作品をすばやく作る」用途において、AIは間違いなく、最強のパートナーです。
問題は、ここから先。その「試作品」を、そのまま「完成品」として本番に乗せようとした瞬間に、話が変わってくるのです。
そして始まる、「モグラ叩き」
試作品を本番のシステムに育てようとすると、当然、より複雑な要件が次々と出てきます。そして、ここで多くの人がつまずきます。私が見聞きする限り、典型的なのは、こんな展開です。
一つ直すと、なぜか別の場所が壊れる。ある画面を修正したら、まったく関係ないはずの画面のレイアウトが崩れる。想定外の操作をされた途端、エラーで止まる。——いわば、出てきたモグラを叩いたら、別の穴から新しいモグラが顔を出す。終わりのない「モグラ叩き」が始まるイメージです。実は、この「直したはずが、別の場所を壊してしまう」現象、開発の世界では「デグレード」と呼ばれ、昔ありふれた現象なのですが、AIでのシステム開発の世界においても普通に起こり得ます。
なぜ、こうなるのか。システムは、見えないところで部品どうしが複雑に繋がり合っています。この繋がりが強すぎる状態——専門的には「密結合」と言います——だと、一か所いじっただけで、その影響が思いがけない場所まで連鎖してしまう。「ある画面を直したら、まったく別の画面が崩れる」のは、まさにこれです。本来は、部品どうしの繋がりをできるだけ緩く保ち（「疎結合」）、一か所の変更が他に波及しないように「設計」しておく必要があるのです。
ここで、こう思う方もいるでしょう。「でも、AIはどんどん賢くなっている。そのうち、そのあたりも全部やってくれるのでは?」と。ごもっともな疑問です。そして実は、ここがいちばん肝心なところです。
少し、人に置きかえて考えてみましょう。どれだけ優秀な部下や外注先でも、「とにかく急いで」「細かいことはいいから、まず形にして」とだけ言い続けたら、どうなるでしょうか。きっと、言われたとおり、目の前の作業をどんどん仕上げてくれます。一つ一つの仕事は、見事かもしれません。
でも、全体の段取りを誰も描かないまま、「あれも」「これも」と頼み続ければ、出来上がるのは、つぎはぎだらけの成果物です。これは、その人が無能だからではありません。むしろ優秀で、素直だからこそ、こちらの「とにかく急いで」に忠実に応えた結果です。足りなかったのは能力ではなく、「全体をどう組み立てるかを考える、指示する側の段取り」なのです。
AIも、まったく同じです。賢くなればなるほど、こちらの指示に忠実に、すごい速さで形にしてくれる。だからこそ、「何を、どんな順番で、どう組み立てるか」を考える人がいなければ、賢いAIほど、見事なつぎはぎを高速で築き上げてしまう。ここは、AIがどれだけ進化しても、変わらないところだと思います。
「とりあえず動くもの」は、今や誰でも作れます。本当に難しいのは、全体の見通しを保ち、後からの変更にも耐えられるように「設計する」ことの方です。「最近のAIなら、いい感じに設計まで全部やってくれるだろう」——この期待に寄りかかりすぎることが、つまずきの入口になります。
だからAIは、「分かっている人」が試作を速くする道具
ここまで来ると、冒頭の問い——「AIでの開発は、誰のための道具なのか」——の答えが、見えてきます。
AIでの構築は本来、非エンジニアが「完成品」を作るための道具ではなく、設計を分かっている人が「試作」を速くするための道具。私は、そう捉えるのが健全だと思っています。そして、その「試作」の使い道は、大きく二つに分かれます。
使い道①：エンジニアが、本開発の前のたたき台として使う
一つ目は、エンジニアやプロが、本格的な開発に入る前の試作として使う使い方です。全体の設計を頭に描ける人が、その確認のためにAIで素早くたたき台を作る。完成品との違いを分かったうえで使うので、「モグラ叩き」に陥りません。AIの爆速さを、いちばん安全に引き出せる形です。
使い道②：非エンジニアが、発注時の「認識合わせ」に使う
そして、こちらが、非エンジニアの経営者にとってむしろ重要だと思う使い方です。エンジニアや開発会社に「こういうものが欲しい」と伝えるための、試作として使うのです。
システム開発で最もよくあるトラブルが、「言葉で伝えた要望」と「実際に出来上がったもの」のズレです。頭の中のイメージを言葉だけで正確に伝えるのは、想像以上に難しい。ところが、AIで「こんな感じ」という動く試作をサッと作って見せれば、「これのここを、こうしたい」と、具体的なモノを前に会話ができます。AIで作った試作品が、発注の「共通言語」になります。非エンジニアにとってのAIの正しい出番は、「作って終わらせること」ではなく、「作りたいものを、正確に伝えること」。ここにこそ、大きな価値があります。
使い道①と②に共通しているのは、どちらも「試作品として使う」という点です。エンジニアの試作も、発注のための試作も、本番に乗せる前の段階で活きる。逆に言えば、「試作品」をそのまま「完成品」として本番に乗せることだけが、危ういのです。
では、非エンジニアの中小企業は、どう向き合えば良いか
ここまでをまとめると、非エンジニアの経営者がやめるべきなのは、「自分で完成品まで作り切ろうとすること」だけです。向かうべきは、「自分で作る」でも「分からないまま丸投げする」でもない、第三の道。AIの試作で「欲しいものの輪郭」を掴み、その先の設計と構築は、それを分かっている人と組んで進める。これが、いちばん現実的で、いちばん損のない進め方だと思います。
そしてもう一つ。前回の記事で詳しくお話ししたことですが、そもそも、その業務はkintoneやGoogle Workspace、Excelで組んだ方が、むしろ良い場合がとても多いのです。これは「AIで作れないから、仕方なくそちらで」という話ではありません。シンプルさ、作りやすさ、後からの引き継ぎやすさまで含めて考えると、既存のツールの方が優れているケースが、現実にはたくさんある——そういう意味です。AIでゼロから作ることを、最初の選択肢にしない。これは、今回の「試作と完成品は別物」という話とも、まっすぐ繋がっています。
こうして見てくると、本当に大事なことが浮かび上がってきます。AIで作るのか、既存ツールで組むのか、プロに頼むのか——「何で、どう作るのがいちばん良いか」を見極められる相手を、手元に持っておくことです。ツールが増え、選択肢が広がった今だからこそ、その都度こうした判断を一緒にしてくれる「IT化のパートナー」がいるかどうかが、結果を大きく左右します。流行りに乗って作っては行き詰まる会社と、着実に成果を出していく会社の違いは、たいていここにあります。
当事業所では、「AIで作りましょう」と表面的にお勧めすることはしません。その業務が本当に自作に向くのか、既存ツールで足りるのか、プロの手が要るのか——そこを一緒に見極めるところから始めます。「動くもの」を作って渡して終わり、ではなく、後々まで会社できちんと回り続ける状態にして、はじめて支援が完結すると考えているからです。
最後に、もう少し大きな話を一つ。「AIは、エンジニアの仕事を奪う」とよく言われます。ですが、ここまでお話ししてきたことを踏まえると、私はむしろ「逆」ではないかと感じています。
エンジニアにとってAIは、試作を一気に速め、仕事の質を底上げしてくれる相棒になります。そして発注する側も、「こういうものが欲しい」を「動く形」で見せられる。言葉だけでは伝わらなかった要望が、正確に伝わります。これは、エンジニアにとっても歓迎すべきことでしょう。曖昧な注文に振り回されず、「作りたいもの」がはっきり見えた状態で、本来の力を出せるのですから。
AIは、非エンジニアとエンジニアの間にあった「分厚い壁」を、取り払ってくれる道具なのかもしれません。どちらかの仕事を奪うのではなく、両者をつなぎ、どちらの価値も高める。そういう使われ方こそ、本来あるべき姿だと、私は思っています。
前回の記事もあわせてどうぞ
「そもそも、AIで自作すべきか？既存ツールの方が良いのでは？」という話は、前回の記事で詳しくお話ししています。
→ 「非エンジニアでもAIで自社システムを作れる」の落とし穴──結局kintoneやExcelの方が良い？
さらに深く知りたい方へ
当事業所が、AIとどう向き合い、どんな形でAI環境構築を支援しているかは、こちらのページで詳しくご紹介しています。
「土台づくり」から考えたい方へ
AIや独自システムの前に、まず会社のデータ基盤（フォルダ整理）から整えたいという方は、こちらをご覧ください。