【外注していたシステムが、自社で動かせる時代になった】〜「発注して待つ」から「要件を決めて任せる」に切り替わる経営判断〜
「エンジニアがいないから、外注するしかない」という前提を、多くの中小企業経営者は当たり前のように受け入れてきた。コードが書けなければ、システムは作れない。そういう時代が長く続いた。
だが、その前提が変わりつつある。自然言語で指示を出すだけでシステムの骨格が動く。コードを書かなくても、業務の流れを言語化できれば、AIがそれを形にして返してくる。この変化は、エンジニアの仕事を変えるだけでなく、経営者の役割そのものを変える。
経営者がやるべきことは、ツールを選ぶことでも、コードを覚えることでもない。「自社で何をしたいのか」を言語化し、構造化して決めることだ。本稿では、実際に紙の納品書処理や図面の積算業務をAIで動かした現場を題材に、「発注して待つ」から「要件を決めて任せる」へと経営判断の軸を切り替えるために何が必要かを整理する。
「エンジニアに任せる」の時代が、なぜ終わりに近づいているのか
「作れる人」と「使える人」の分業が崩れてきた
これまでシステム開発は、コードを書ける技術者の専有領域だった。経営者や現場担当者は「要望を伝える側」であり、「作る側」には立てなかった。そのギャップが外注という構造を必然にしてきた。
AIによるコード生成の精度が上がった今、この分業の前提が揺らいでいる。自然言語で業務の流れを記述すれば、AIがコードの骨格を生成し、動く画面を返してくる。技術的な実装の敷居が下がった結果、「何を作るか」を決める能力が、「どう作るか」を知っている能力よりも重要になってきた。
外注の構造的な問題は、技術よりも「言語化」にあった
外注が機能しない現場の典型的な失敗は、「思っていたものと違う」という結末だ。これは外注先の技術力の問題ではなく、要件を適切に言語化できていなかった問題である。業務の流れ、例外処理、担当者の判断基準、データの持ち方——これらを言葉にできなければ、どんな優秀なエンジニアも正しいものを作れない。
逆に言えば、要件を構造化して伝えられれば、今はAIがその指示通りに、想定を超える精度で返してくる。ボトルネックは技術ではなく、最初から「言語化」にあった。外注が生んでいた摩擦の正体は、そこにある。
「発注して待つ」姿勢が、自社の判断を外に預けていた
外注という構造には、もう一つの問題がある。経営者が「判断を外に出してしまう」ことだ。仕様の細部、優先順位の決め方、運用上の例外処理——これらは本来、自社が決めるべき業務判断である。それをエンジニアや外注先に「いい感じにやってほしい」と委ねることで、自社のシステムでありながら、自社が制御できない構造が出来上がっていた。
AI開発の普及は、この構造を逆転させる可能性を持っている。「判断を自社に取り戻す」きっかけとして捉えるべきだ。
「要件を決める」とは、何を決めることか
業務を言葉にする、というのは意外と難しい
「要件を定義する」と言うと、専門的な作業のように聞こえる。だが実態はシンプルだ。「誰が、何をするために、何を入力して、何が出てくれば業務が終わるのか」を言葉にすること。それが要件定義の核心である。
問題は、これが「簡単そうで難しい」という点だ。長年の業務慣行の中で、担当者の頭の中にだけある判断基準、口頭で処理されてきた例外、属人化した手順——こういったものを言語化するには、業務を外から眺める視点が要る。「なぜその手順でやっているのか」を問い直す作業が、要件定義の前に必要になる。
「動けばいい」から「何のために動くのか」へ
ここに、中小企業のシステム導入でよくある落とし穴がある。「とにかく今の手作業をシステムにしたい」という発注の仕方だ。現状の業務をそのままシステム化しても、非効率な手順を自動化しているだけになることがある。
AI開発の時代において、要件を決める前に問うべきことがある。「その業務の目的は何か」「システム化することで、何が変わるのか」「誰の負担が、どう減るのか」——この問いに答えられない状態で、AIにコードを書かせても、精巧に作られた使われないシステムができあがるだけだ。
実際の現場で何が起きたか——納品書・積算業務の例
紙の納品書をデータ化し、受発注の照合を自動処理したい。図面の数量を読み取って積算の下計算をAIに任せたい。こういった業務改善の相談が、実際に増えている。
共通しているのは、「何をしたいか」は明確だが、「どの条件で判断するか」が言語化されていない状態からスタートするという点だ。「だいたいこういうルールで処理している」という感覚を、AIが扱える言語に変換する作業——これが経営者や現場の担当者に求められる役割である。この作業を丁寧にやった現場では、AIが想定以上の精度で動いた。省いた現場では、AIへの指示が曖昧なまま出力も曖昧になった。
経営者の役割が「発注者」から「設計者」に変わる
「要件を渡せる人間」が、判断の起点に立つ
AI開発が普及した世界で、経営上の優位を決めるのは「何を作るかを決められる人間がいるかどうか」だ。コードが書けるかどうかではない。業務を構造化し、AIへの指示として渡せる状態に整理できるかどうか。この能力が、システムの品質を決める。
これは経営者にとって、むしろ好都合な変化である。技術的な実装は外に出せる。しかし業務判断の構造化は、自社の人間にしかできない。経営者が「判断の起点」として機能できれば、AIはその指示通りに動く。
「使いこなせる前提」を整えることが先決
ここで注意が必要なのは、AI開発ツールが使いやすくなったからといって、前提なしに飛びついても機能しないという現実だ。業務の流れが整理されていない。担当者の判断基準が言語化されていない。どのデータをどこに持つかが決まっていない。この状態でAIにシステムを作らせても、要件の曖昧さがそのまま出力に反映される。
カーネマンが指摘するように、人は「直感で決めた判断を、あとから合理的に説明している」ことが多い。業務の手順についても同じことが起きる。「なんとなくこうやっている」を言語化する前に、それが本当に正しい手順かを問い直す必要がある。
「任せる」の前に「決める」がある
AIに任せる、外注先に任せる——どちらの場合でも、「任せる」の前に「決める」がある。この順番を逆にした時に、システム開発は失敗する。要件が未決定のまま作業が始まり、途中で仕様変更が発生し、最終的に「思っていたものと違う」という結末になる。これは外注先の問題ではなく、決める側の問題だ。
AI開発の時代に経営者が身につけるべきは、コードを書く技術ではない。「何を決めれば、AIは動き出せるか」を把握する能力である。
「自社で動かせる」とは、どういう状態を指すのか
コントロールできる範囲を自社に取り戻す
「自社で動かせる」という言葉が意味するのは、すべてを内製することではない。「何が動いているかを自社が把握し、変更が必要な時に自社が判断できる状態」を指す。外注していたとしても、要件定義と検証を自社が担えれば、制御の主導権は自社にある。
逆に、エンジニアがいても、システムの中身を誰も説明できない状態では「自社で動かせている」とは言えない。どちらが問題かは、明らかだ。
「ブラックボックス外注」からの脱却
これまでの中小企業のシステム外注は、ブラックボックスになりやすかった。「動いているからいい」「触ると壊れそうだから触らない」——この状態が続くと、業務の変化にシステムが追いつかなくなる。改修のたびに外注先に頼み、見積もりを待ち、コストをかける。経営の機動力が、システムの硬直性に引きずられる。
AI開発が普及した今、この構造を変える選択肢が出てきた。要件を自社で言語化できれば、AIを使って小さな改修を自社で回せる場面が増える。全部ではなくとも、「ここだけは自社で動かせる」という領域を広げていくことが、経営の機動力につながる。
経営者が「IT音痴」であることは、もう言い訳にならない
「自分はITが苦手だから」という言葉を、経営者が免罪符にしてきた時代は終わりに近い。業務を言語化する能力は、ITの技術とは別の話だ。自社の業務を、「誰が、何をするために、何を入力して、何が出れば終わりか」と整理する力は、経営者が本来持っているはずの能力である。
AIはその言語化を受け取って動く。「コードが書けないこと」は障壁でなくなった。「業務を説明できないこと」が、唯一の障壁として残った。
結論 — 経営者が取るべき次の一歩
「エンジニアがいないから外注するしかない」という前提は、AI開発の普及によって崩れつつある。コードを書く技術よりも、業務を言語化し要件として構造化する能力が、システムの品質を決める時代になった。外注先やAIへの「任せ方」を変えることは、経営の制御権を自社に取り戻すことでもある。
経営者は、「ITが苦手」を理由に判断を外に出し続けることをやめるべきである。
第一歩は、自社の業務を一つ選び、「誰が、何のために、何を入力して、何が出れば終わりか」を書き出すことだ。その言語化が、AIへの指示の起点になる。
