時代に取り残されるのはDX戦略がない会社
大企業には「変えられないシステム」があります。
中小企業には「システムを変えられる人がいない」という問題があります。
これまで両者は、異なるIT課題として語られてきました。しかし生成AIの登場によって、状況は大きく変わろうとしています。
生成AIは、プログラミング経験の少ない人でも、業務用の画面やデータ処理を作れるところまで来ています。
つまり、経営者や情報システム部門が方針を決める前に、現場でシステム内製化が始まる時代です。
対策はできているでしょうか。
大企業を苦しめるのは「古いシステム」ではない
大企業では、長年使い続けてきた基幹システムが経営改革の足かせになることがあります。
しかし、本当の問題は単に技術が古いことではありません。
- 誰もシステム全体を説明できない
- 一部分を変更すると、どこに影響するのか分からない
- 当時の設計意図が残っていない
- 業務に合わせてシステムを変えるのではなく、システムに業務を合わせている
- 改修のたびに高額な費用と長い期間が必要になる
このような「安全に変更できない状態」こそが、レガシーシステムの本質です。
どれだけ新しい技術へ置き換えても、会社の業務構造やデータの関係を理解しないまま作り直せば、新しいレガシーシステムが完成するだけです。
中小企業ではIT人材不足が足かせになる
一方、中小企業には大規模な基幹システムがない代わりに、ITを担当できる人材が不足しています。
その結果、情報がExcel、メール、紙、チャット、会計ソフトなどに分散します。
業務を改善したくても、システム開発会社へ依頼するには費用がかかります。自社で作ろうとしても、プログラミングができる人がいません。
その隙間を埋め始めたのが生成AIです。
現場の担当者が生成AIに要望を伝え、表計算の自動処理、簡単なWeb画面、WordPressプラグイン、社内用アプリなどを作ることは、すでに珍しいことではありません。
これは中小企業にとって大きな機会です。
同時に、別の問題も生み出します。
プログラミング教育とシステム設計は別のもの
現在の小中学校におけるプログラミング教育では、主に論理的思考やアルゴリズムの基礎を学びます。
条件によって処理を分ける。繰り返す。入力した情報から結果を出す。
これらは重要な学習です。
しかし、企業で使う業務システムを設計するには、それだけでは足りません。
企業のシステムでは、次のような問題を考える必要があります。
- 誰が情報を登録できるのか
- 誰が承認するのか
- 承認後に修正できるのか
- 修正前の履歴を残すのか
- 例外が発生した場合に誰が判断するのか
- 複数の処理をどこまで一体として完了させるのか
- 在庫、請求、入金、会計へどう連携するのか
- 間違った操作をどのように取り消すのか
- 退職者や外部関係者に何を見せるのか
アルゴリズムが「どのように動かすか」を考えるものだとすれば、システム設計は「誰が、何を、どの責任で動かし、その結果をどこまで波及させるか」を考えるものです。
学校教育が悪いという話ではありません。小中学校で企業の権限設計や会計処理まで教えないのは当然です。
問題は、プログラミング教育を受けた人材が、企業システムの設計まで理解していると会社側が思い込んでしまうことです。
生成AIは「未設計のシステム」も大量生産できる
生成AIによって、コードを書くハードルは急速に下がりました。
しかし、コードを書けることと、企業のシステムを設計できることは同じではありません。
生成AIに「業務報告アプリを作ってください」と依頼すれば、動く画面は作れます。
ところが、誰が提出し、誰が確認し、差し戻した場合にどの状態へ戻り、承認後の変更をどう記録するのかは、会社側が決めなければなりません。
生成AIは、人材不足を自動的に解消する魔法ではありません。
設計原則を持たない会社にとっては、整合性の取れない小さなシステムを大量生産できる道具にもなります。
現場ごとに作られた便利なツールが増え、やがて請求、在庫、顧客情報、権限、会計にまで接続されていく。
その段階で止めようとしても、すでに業務が依存しているため簡単には廃止できません。
これが、生成AI時代の新しいレガシーシステムです。
最も危険なのは、試作品がそのまま基幹システムになること
受付フォーム、業務報告、情報共有などは、WordPressや表計算を使って素早く試作してもよいでしょう。
実際に動くものを見ながら改善することで、本当に必要な機能が見えてきます。
ただし、次の処理は試作品の延長で作るべきではありません。
- 会計情報を変化させる処理
- 請求金額を確定させる処理
- 在庫数量を変化させる処理
- 入出金を管理する処理
- 承認権限を制御する処理
- 会社の資産や負債を変化させる処理
これらは、要件、権限、例外、履歴、整合性を整理したうえで、本番用のデータモデルとコードを設計する必要があります。
「動いたから、そのまま使う」という判断が最も危険です。
今から準備すべき5つの対策
1．試作と本番の境界を決める
どこまでなら現場が自由に作ってよいのか。どの情報や処理に接続する場合は正式な設計が必要なのか。
この境界を、生成AIの利用が広がる前に決めておく必要があります。
2．権限と責任を先に設計する
画面から考え始めるのではなく、担当者、確認者、承認者、管理者、外部専門家が、それぞれ何を見て何を変更できるのかを整理します。
権限設計は後から付け足す機能ではありません。
3．会社のルールをコードで表現する
文章の設計書だけでは、実際のシステムとのズレが生まれます。
「検収済みの取引だけ請求できる」「一定金額以上は代表者承認を必要とする」といった業務ルールを、データモデルやコードとして明確に表現することが重要です。
コードそのものを、生成AIと人間の双方が確認できる設計情報にします。
4．生成AIで作られたツールを把握する
禁止するだけでは、現場での利用は止まりません。
何を作り、どのデータを扱い、どの業務に利用しているのかを登録し、重要度に応じて確認する仕組みが必要です。
5．経営者がシステム設計の原則を知る
経営者自身がすべてのコードを書く必要はありません。
しかし、会社のどの情報を正しいものとして扱うのか、誰にどこまで権限を与えるのか、どの処理が会計や会社資産に影響するのかは、経営者が判断すべき問題です。
システム設計とは、会社の脳と神経を設計することだからです。
必要なのは「AIを使える人」だけではない
これから必要とされるのは、生成AIへ上手に指示できる人だけではありません。
会社の業務を分解し、データの関係を整理し、権限と責任を定義し、変更してよい部分と慎重に扱う部分を判断できる人です。
大企業は、変更できないレガシーシステムに苦しんでいます。
中小企業は、IT人材不足によって変化できない状態にあります。
そこへ、アルゴリズムを学び、生成AIでコードを書ける世代が入ってきます。
システム内製化は、経営者が決断しなくても勝手に進みます。
だからこそ、今準備すべきなのはAIツールの導入ではありません。
自社のシステムを、どの原則で設計するのかを決めることです。
生成AI時代に差がつくのは、コードを速く作れる会社ではありません。
作ったシステムを安全に変更し続けられる会社です。
対策は、できていますか？
コメントを残す