カテゴリー: システム開発内製化

古いコードを蘇らせる前に、そこに埋まっている業務の意味を発掘せよ。

生成AIの発展によって、古いシステムを新しい言語や環境へ移行する「AIマイグレーション」という言葉を見かけるようになりました。

COBOLで書かれた古い業務システムを、JavaやPython、あるいは現代的なクラウド環境へ移行する。
一見すると、とても魅力的な話です。

古いコードをAIに読ませれば、新しいコードに変換してくれる。
属人化した古いシステムを、短期間で現代化できる。

そう聞くと、経営者にとっては非常に便利なサービスに見えるかもしれません。

しかし、当社は少し違う見方をしています。

AIマイグレーションは、単なるコード変換ではありません。
むしろ、業務システム考古学に近い作業です。

古い業務システムのコードには、その会社の歴史が埋まっています。

昔の業務ルール。
過去の制度変更への対応。
特定顧客への例外処理。
帳票出力の都合。
担当者がその場しのぎで入れた分岐。
すでに存在しない業務の名残。
誰も理由を説明できない区分コード。

これらは、単なる古いコードではありません。
会社の業務の地層です。

しかも、その地層の中には、今も会社のどこかを支えている処理が残っている可能性があります。

普段は動いていないように見える処理でも、月末、年度末、決算時、返品時、再請求時、税務調査時、特定顧客との取引時だけ必要になることがあります。

そのため、「使われていなさそうだから削除する」という判断は非常に危険です。

一方で、古いコードをそのまま現代のオブジェクト構造やデータベース設計の中に混ぜ込むのも危険です。

設計意図が分からない旧処理を、新しいシステムの中核モデルに入れてしまうと、今後の改修で何が起きるか分かりません。

請求モデルの中に在庫都合の処理が残る。
顧客モデルの中に帳票印刷のためだけの項目が残る。
売上処理の中に昔の特殊契約の分岐が残る。
会計処理の中に営業部門の便宜処理が混ざる。

そうなると、新しいシステムに移行したはずなのに、古いブラックボックスが現代の技術の中で再生産されてしまいます。

これは「近代化」ではありません。
古い呪いを新しい箱に移し替えているだけです。

本当に必要なのは、古いコードをそのまま蘇らせることではありません。

必要なのは、古いコードの中から業務上の意味を発掘することです。

この処理は今も必要なのか。
この例外処理は正式な業務ルールなのか。
それとも過去の応急処置なのか。
このデータは会計・監査・請求・在庫・顧客対応に関係するのか。
この帳票は今も使われているのか。
この区分コードは現在の業務でも意味を持つのか。

こうした問いを一つずつ確認しなければなりません。

つまり、AIマイグレーションで本当に重要なのは、AIがコードを変換できるかどうかではありません。

古いシステムから業務知識を取り出し、現在の会社に必要な形へ再設計できるかどうかです。

生成AIは、発掘作業を助ける道具にはなります。
古いコードを読み、処理の候補を整理し、データ項目を洗い出し、仕様書のたたき台を作ることはできます。

しかし、出土したものの意味を判断するのはAIではありません。

それは、経営者、業務担当者、会計担当者、そして設計者の仕事です。

「これは現在も必要な業務なのか」
「これは会社の正式なルールなのか」
「これは履歴として残すだけでよいのか」
「これは新しい設計に組み込むべきなのか」
「これは隔離しておくべき未解明仕様なのか」

この判断をしないまま、AIでコードを変換してしまうと、問題は解決しません。

むしろ、見た目だけ新しくなったブラックボックスが生まれます。

AIマイグレーションは、コード変換ではありません。
業務システム考古学です。

古い業務システムは、会社の過去の記録です。
しかし、そのすべてを未来に持ち込む必要はありません。

発掘するもの。
保存するもの。
隔離するもの。
現代の業務に組み直すもの。
そして、役目を終えたものとして供養するもの。

それらを分ける作業が必要です。

だからこそ、生成AI時代のシステム移行では、経営者が自社の業務構造を理解していることが重要になります。

外部業者に任せること自体が悪いわけではありません。
しかし、自社の業務ノウハウをどこまで外部に見せるのか。
どの処理を残すのか。
どの業務を今後も続けるのか。
どのデータを会計上の事実として保存するのか。

そこを判断できなければ、会社の頭脳そのものを外部に委ねることになります。

生成AIは便利です。
しかし、生成AIは成功の増幅器であると同時に、失敗の増幅器でもあります。

信号もなく、道路標識もなく、交通ルールも共有されていない道を、自動車で走ればいつか大事故が起きます。

業務ルールが整理されていない。
データの意味が定義されていない。
責任範囲が決まっていない。
承認手順が曖昧なままになっている。

その状態でAIを使ってシステムを移行すれば、混乱も高速化します。

AIを使うな、という話ではありません。

AIが安全に走れる道路を作ること。
つまり、業務構造、データ構造、会計構造、責任範囲、権限、承認手順を整理すること。

それが、生成AI時代のシステム移行において本当に必要な準備です。

当社が内製化準備を重視するのは、そのためです。

システムをすべて自社で作れ、という意味ではありません。
外部専門家を使うべきところは、使うべきです。

しかし、何を任せているのか分からないまま任せるのは危険です。

古いシステムを新しい技術へ移す前に、まず自社の業務を発掘し、整理し、未来に残すべき構造を見極める。

AIマイグレーションとは、単なる技術作業ではありません。
会社の過去を読み解き、未来の業務構造を設計し直す経営判断なのです。

資本力だけではなく、業務構造と情報システムが経営者だけでなく社員の未来も左右する

公開予定日：2027年6月8日

会社の成長を決めるものは何でしょうか。

資本力。
営業力。
商品力。
人材。
ブランド。
立地。
経営者の判断力。

もちろん、これらは今でも重要です。

しかし、これからの時代において、もう一つ避けて通れない要素があります。

それが、システム設計です。

会社が小さいうちは、多少システムが未整理でも業務は回ります。
Excelで管理する。
担当者同士で確認する。
口頭で調整する。
必要な時だけ外部業者に依頼する。

それでも、規模が小さいうちは何とかなることがあります。

しかし、会社が成長し、社員が増え、顧客が増え、取引が増え、部署が分かれ、外部専門家との連携が始まり、上場や経営統合が視野に入ってくると、状況は一変します。

その時に問われるのは、単に「システムが動いているか」ではありません。

誰が、どの情報にアクセスできるのか。
誰が、どの操作を行えるのか。
承認の責任はどこにあるのか。
操作履歴は残っているのか。
監査に耐えられるのか。
外部から攻撃された時に、被害範囲を限定できるのか。
他社と経営統合する時に、どちらのシステムを基盤にすべきなのか。

こうした問いに答えられるかどうかが、会社の成長限界を決める時代になっています。

上場は、必ずしもハッピーエンドではない

上場は、多くの企業にとって大きな節目です。
社会的信用が高まり、資金調達の選択肢が広がり、会社の知名度も上がります。

しかし、上場はゴールではありません。

上場すれば、会社はより多くの人から見られる存在になります。
株主、監査法人、取引先、金融機関、従業員、顧客、そして悪意ある攻撃者。

会社の情報資産の価値が高まれば、それを狙う人も増えます。

その段階で、システムの権限管理が甘い。
業務フローが整理されていない。
誰が何を操作できるのか説明できない。
外部ベンダーに聞かなければ自社システムの構造が分からない。

このような状態では、上場後の運営は決して楽ではありません。

毎月、気分が悪くなるような金額の保守費、改修費、監査対応費、セキュリティ対応費を受け入れざるを得なくなる可能性があります。

しかも、その請求を断れない。
なぜなら、システムを止められないからです。
社内に構造を説明できる人がいないからです。
他社へ乗り換えるには、リスクと費用が大きすぎるからです。

上場はハッピーエンドではありません。
システムの主導権を持たないまま上場すると、会社の神経系を外部に握られたまま成長することになります。

ベンダーロックインは、突然始まるものではない

ベンダーロックインは、ある日突然始まるものではありません。

最初は、便利だから依頼する。
自社では分からないから任せる。
安く早く作りたいから、なるべく一つの仕組みにまとめる。
設計の意味が分からないまま、見積もりだけを見て判断する。

その積み重ねの先に、気がつくと自社では動かせないシステムができあがっています。

もちろん、外部のシステム開発企業やシステムインテグレーターが不要だという話ではありません。

大規模なインフラ構築、セキュリティ対策、クラウド設計、データ移行、監査対応、専門的な開発には、外部専門家の力が必要です。

問題は、外部専門家を使うことではありません。

問題は、会社の業務構造、権限設計、データ設計、成長戦略まで外部に握られてしまうことです。

外部専門家は使う。
しかし、会社の頭脳にあたる設計判断は、自社側が理解して主導する。

この違いが、将来の成長限界を大きく変えます。

経営統合では、システムの強い会社が主導権を握る可能性がある

経営統合というと、一般的には資本力の大きい会社、売上規模の大きい会社、社員数の多い会社が主導権を握ると思われがちです。

もちろん、資本力は重要です。
しかし、経営統合後に実際に動かすのは業務システムです。

顧客管理。
受発注。
在庫。
会計。
請求。
入金。
人事。
権限管理。
承認フロー。
監査ログ。

これらをどちらのシステムに統合するのか。

規模の大きい会社のシステムであっても、権限管理が甘く、責任範囲が混ざり、監査対応が弱いのであれば、統合後の基盤としては危険です。

一方で、規模が小さい会社でも、セキュリティ上のアンチパターンを避け、権限や責任範囲が整理され、将来の統合や分社化に耐える設計になっていれば、そのシステムが統合後の基盤として選ばれる可能性があります。

つまり、システム設計は経営統合時の主導権にも関わります。

資本力は会社を買う力です。
しかし、統合後の業務を安全に動かす力は、システム設計に宿ります。

システムは、社員の生活水準にも影響する

システム設計は、経営者だけの問題ではありません。
社員の働き方、待遇、将来のポジションにも影響します。

会社が成長した時、あるいは経営統合が起きた時、管理部門は再編対象になりやすい部門です。

経理、人事、総務、情報システム、営業管理、在庫管理、請求管理。

その時、自社のシステムが統合後も残るのであれば、そのシステムを理解している社員は重要な存在になります。

この処理はなぜこうなっているのか。
この権限は誰に与えるべきなのか。
この業務フローはどの部署が担当するのか。
統合先の業務をどこに組み込むのか。
監査法人や外部専門家にどう説明するのか。

こうしたことを説明できる社員は、単なる事務担当ではなく、統合後の業務運用を支える中核人材になります。

上場企業だから高い給与を払えるのではありません。
高い生産性を支える業務構造とシステムを持つ企業が、結果として高い給与を支払えるのです。

システムを外部に握られ、高額な請求を受け入れ続ける会社と、システムを自社の経営基盤として改善できる会社では、社員に還元できる利益も変わります。

システムは、社員の生活水準にも影響します。

内製化とは、すべてを自社で作ることではない

私たちが考える内製化は、すべてのシステムを自社だけで作ることではありません。

税理士、社会保険労務士、データベース専門家、インフラ担当、セキュリティ専門家、外部エンジニア、デザイナー。

専門家を活用すべき場面は数多くあります。

重要なのは、外部専門家を使わないことではありません。
外部専門家を乗りこなせる状態になることです。

自社の業務構造を説明できる。
権限と責任範囲を説明できる。
どこを自社で理解し、どこを外部に任せるべきか判断できる。
生成AIが作ったコードを、動いたからという理由だけで本体に組み込まない。
なぜその設計にするのかを、経営者と担当者が理解している。

これが、これからの内製化です。

会社の成長を止めないために

会社が成長するかどうかは、最初から分かるものではありません。

上場するかどうか。
経営統合するかどうか。
多店舗展開するかどうか。
フランチャイズ展開するかどうか。
事業承継やM&Aが起きるかどうか。

それらは、成長した後に見えてくる選択肢です。

しかし、将来どの道を通るか分からないからといって、最初から壁を作ってしまう必要はありません。

小さく始める。
しかし、将来分けられる構造にしておく。
今は単純でも、権限と責任範囲を混ぜない。
今は小規模でも、監査や統合に耐える説明可能性を残しておく。

これは過剰投資ではありません。
将来の選択肢を潰さないための設計です。

私たちは、システムを単なる業務効率化の道具とは考えていません。

システムは、会社の成長余地を広げるものです。
経営統合時の主導権を守るものです。
社員の働き方と生活水準にも影響するものです。
そして、外部専門家を正しく活用するための経営基盤です。

法人化にあたり、私たちは中小企業が自社の業務構造とシステム設計を理解し、生成AIと外部専門家を正しく活用できる社会を目指します。

会社の成長限界は、資本力だけで決まる時代ではありません。

これからは、システム設計を理解している会社が、より自由に成長できる時代です。