Vol.01｜基幹システム刷新で失われる「業務知識」——AI時代の企業資産はどこにあるか

*AI駆動開発 **自社の知見·技術*

企業の競争力を支える業務知識は、文書・人・コードの中に分散し、見えないまま失われつつあります。そして、知識は「存在する」だけでは使えず、AI時代には人とAIの双方が読める形で構造化されていることが重要です。
そのために、埋もれた業務知識を取り戻し、オントロジーとして「育て続けられる資産」に変えていく必要があります。

序章｜この連載で考えたいこと

最初に、ひとつだけお伝えしておきたいことがあります。
私たちは、これから書くテーマそのものを事業にしています。
企業のシステム資産の中に埋もれている業務知識を取り出し、整理し、オントロジーとして育てていく、そんな仕事を日々しています。
なので、当然ながら今回のこのテーマについては「当事者」になります。

ただ、この連載では、”自社サービスの話”をしたいわけではありません。
いったん、私たちの立場は横に置きます。
この連載で考えたいのは、企業の業務知識が今どこにあり、どう残し、どう活かしていくべきなのかということです。書いてあることが妥当かどうかは、ぜひ論理と事実だけで判断してください。

いかがでしょう。
貴社のシステムにも、「動いてはいるけれど、なぜそうなっているのか説明できない処理」はないでしょうか。
この「なぜ」を説明する知識こそ、今回の連載で考えたい企業資産です。

第1回となる今回は、まず「業務知識はいま、どこにあるのか」という問いと、それを企業の資産としてどう捉えるかについて。
第2回では、失われつつある知識をどう取り戻し、どう育て続けるのか。
そして最終回では、その先に何が得られるのか。さらに、その知識という資産は、そもそも誰のものなのかを考えます。

第一幕｜資産の錯覚 ―― 本当に価値のあるものは、どの帳簿にも載っていない

「いまのシステムには、どんな業務ルールが入っていますか？」

基幹システムの刷新を検討している企業は、決して珍しくありません。
数億円規模の予算をかけ、数年かけて新しいシステムへ移行する。
経営会議で承認され、プロジェクトチームが立ち上がり、いよいよ具体的な検討が始まります。
そのとき、こんな質問をされたらどうでしょう。
「いまのシステムには、どんな業務ルールが入っていますか？」
みなさんは、すぐには答えられますか。
もちろん、設計書はある。
業務マニュアルもある。
長くシステムを担当してきた人に聞けば、ある程度は分かる。
けれど、実際に調べ始めると、
「この条件分岐は、なぜあるんだろう」
「この数字だけ計算方法が違うのはなぜだろう」
「この処理は今も必要なのだろうか」
といったものが、少しずつ出てきます。

最後にたどり着くのは、「あの人なら知っているかもしれない」

そこで、答えを探し始めます。
設計書を見る、当時の資料を探す、過去の議事録も確認する。
それでも分からない。
最後に出てくるのが、「あの人なら知っているかもしれない」という言葉です。そして、その人に聞いてようやく分かる。
「昔、ある取引先との契約で決まったルールです」
「以前の業務では必要だったので、そのまま残っています」
こうして初めて、その処理の背景が見えてきます。
つまり、長年の業務の中で積み重なってきた知識が、必ずしも「会社の資産」として見える形で管理されているわけではありません。

数億円のシステムは管理する。でも、その中身は？

ここで少し不思議なことが起きます。
企業は、システムそのものには大きな金額をつけています。
サーバーやソフトウェアは資産として管理される。システム刷新には、数億円の予算がつくこともある。
一方で、そのシステムを20年、30年と使うなかで蓄積されてきた、
「なぜ、この処理になっているのか」
「なぜ、この顧客だけ例外なのか」
「どの判断を、どんな条件で行っているのか」
といった知識には、値札がついていません。帳簿にも載っていません。けれど、実際の現場で「自社らしい判断」を支え、他社との違いを生み出しているのは、むしろこちらです。

競争力を実際に決めているのは、システムそのものではなく、その中に積み重なってきた業務知識なのかもしれません。

それにもかかわらず、私たちはシステムの金額や耐用年数は管理していても、その中にある知識がどれだけ残っているのか、誰が持っているのかまでは、ほとんど管理していません。

その知識は、なくなる直前まで見えない

だから普段は、それが「会社の資産である」と意識する機会もあまりありません。ところが、システム刷新や担当者の交代をきっかけに、その存在が急に見えてきます。
「あれ、この仕様は誰が分かるんだろう」
「この処理をなくして、本当に大丈夫だろうか」
そうなって初めて、これまでシステムの中や人の頭の中にあったものが、実は業務を動かすうえで欠かせない知識だったことに気づきます。見えていなかったのではありません。見える形で管理されていなかった。そう考えたほうが、実態に近いのかもしれません。

失ったあとでは、「何を失ったのか」すら分からない

さらに厄介なのは、こうした知識が失われたあとです。サーバーが一台なくなれば、資産台帳を見れば分かります。データが消えれば、バックアップやログから確認できるかもしれません。でも、「ある担当者しか知らなかった業務上の判断理由」が失われたとき、その消失を記録する帳簿はありません。何かを失ったことには気づけても、何を、どれだけ失ったのかまでは分からない。
業務知識という資産の扱いづらさは、まさにここにあります。普段は見えない。値段もついていない。けれど、なくなって初めて、その価値に気づく。

では、こうした知識を「見える資産」に変えることはできるのでしょうか。

第二幕｜「あること」と「使えること」のちがい ―― 知識の三つの不安定な姿

「あること」と「使えること」は違う

家のどこかにしまってある、大事な書類を思い浮かべてみてください。「確かにある。でも、必要なときに見つからない。」それでは、すぐには役に立ちません。業務知識も同じです。「設計書もある。コードも残っている」それは確かです。でも、「ある」ことと「使える」ことは同じでしょうか。
企業の業務知識を見ていくと、大きく三つの姿に分けられます。そして、それぞれに少しずつ、扱いづらさがあります。

1．人の頭の中にある知識

一つ目は、人が持っている知識です。これは、おそらく最も豊かな知識です。
「この顧客の場合だけは、この処理を変える」
「この数字が出たら、念のため別の項目も確認する」
「この時期だけは、この順番で処理したほうがいい」
文書には書ききれない細かな判断や、長年の経験から身についた勘まで含まれています。一方で、とても脆い。担当者が異動すれば、質問がしづらくなり、返答にも時間を要する。退職すれば、聞くこと自体が難しくなる。
もちろん引き継ぎは行われます。ただ、長年かけて身につけた判断の背景まで、すべて引き継ぐことは簡単ではありません。

2．文書の中にある知識

二つ目は、設計書やマニュアル、手順書などに書かれた知識です。これは人の記憶と違い、残すことができます。ただし、別の難しさがあります。業務は変わります。システムも変わります。顧客との契約条件も、組織も、運用も変わります。そのたびに文書も更新されればいいのですが、現実には変更のすべてが反映されるとは限りません。
少しずつ、実際の業務とのずれが生まれていきます。やがて設計書を読んだとき、「書いてあることと、実際の動きが違う」ということが起きる。文書が間違っているというより、現実のほうが先に進んでしまったと考えたほうが近いでしょう。文書には、ときに「いまの業務」ではなく、ある時点での業務の姿が残っています。

3．コードの中にある知識

三つ目は、システムのコードに埋め込まれた知識です。第一幕で触れた、
「この顧客だけ処理を変える」
「この条件を満たしたときだけ計算方法を変える」
といったルールです。
コードは、実際にシステムを動かしています。だから、ある意味では最も現実に近い。ただし、コードを読めばすべてが分かるわけではありません。「何をしているか」です。でも、「なぜ、そうしているのか」までは、必ずしも書かれていません。顧客との契約が理由なのか。当時のシステム性能が理由なのか。昔の業務フローの名残なのか。同じ処理でも、その背景まではコードだけでは判断できないことがあります。

では、「第四の姿」はつくれないだろうか

人の頭の中にある知識は、豊かだけれど失われやすい。文書は残るけれど、現実とのずれが生まれやすい。コードは実際の動きを持っているけれど、その理由までは分からない。だとすると、別の姿が必要なのではないか。私たちは、そう考えています。それが、人とAIの両方が読み取ることができ、業務の変化に合わせて育て続けられる、構造化された知識です。
この連載では、その一つの形を オントロジー（Ontology）と呼びます。

オントロジーは、業務知識の「設計図」

少し言葉を整理しておきます。
データは、「何があるか」を教えてくれます。
たとえばデータを見れば、「顧客Aの売上は1億円」という事実が分かります。
検索やRAGは、「どの文書が関係するか」を探してくれます。
たとえば、「顧客Aについて書かれた資料はどれか」を見つけることができます。
セマンティック層は、「この指標をどう計算するか」を共通化します。
たとえば、「売上」という指標を、どのデータからどう計算するかをそろえることができます。

では、オントロジーは何を扱うのでしょうか。
「顧客とは何か」
「顧客と契約はどう結びついているのか」
「どんな条件で、このルールが適用されるのか」
つまり、業務の概念やルール、そのつながりです。
オントロジーは、「この会社の業務が、どんな概念とルールで成り立っているのか」を表す設計図だと考えると、少し分かりやすいかもしれません。
そしてそれは、AIがその会社の業務を理解するための土台にもなります。

AIに足りないのは、モデルの賢さだけではない

最近、AI活用の文脈では「コンテキスト」という言葉をよく聞くようになりました。AIに正しい判断をさせるには、その会社や業務についての背景情報が必要だ、という考え方です。これは、とても重要な視点です。ただ、その前にもう一つ問題があります。AIに渡したい「会社の知識」そのものが、すでに整理されているとは限らないからです。
データベースにはデータがある。
共有フォルダには文書がある。
システムにはコードがある。
けれど、それぞれが別々に存在しているだけでは、会社の業務全体は見えてきません。
どのデータが、どの業務と結びついているのか。
どの文書が、どの処理の背景を説明しているのか。
それらをつなぎ合わせて、初めて見えてくる知識があります。
設計書やコードを読み解き、業務との関係を整理していく、その先に見えてくるものが、システム資産の奥に眠る業務知識です。

システムの知識を「氷山」として見てみる

ここまでの難しさを、もう少し具体的にしてみます。稼働しているシステムの中にある知識を、氷山のように考えてみてください。水面に出ていて、比較的見つけやすい知識もあれば、深いところに沈んでいて、簡単には見つけられない知識もあります。

L1｜目に見えるルール
税率、閾値、入力チェック、計算式。
比較的、コードや設計書から見つけやすい知識です。
L2｜境界条件と例外
月末だけ走る処理。特定顧客だけの例外。年度切り替えだけ使われるロジック。コードには残っていても、「なぜそうなっているのか」が失われ始める領域です。
L3｜書かれていない制約
「並列化すると別システムに負荷がかかる」など、コードにも設計書にも残っていない事情です。
L4｜技術的負債の中に残った知識
一見すると直すべきなのに、なぜか残されている処理。
そこに、過去の障害や契約、他システムとの依存関係が隠れていることがあります。

デモで見えやすいのはL1。怖いのは、その下にある

AIを使ったコード解析のデモで見えやすいのは、L1のような明確なルールです。ただ、システム刷新で本当に注意が必要なのは、その下にあるL2〜L4です。「何をしているか」ではなく、「なぜ残っているのか」が分からない。この差が、刷新時のリスクになります。

この問題は、昔から何度も挑まれてきた

実は、「業務知識を構造化し、それをシステムにつなげる」という発想そのものは、新しいものではありません。かつてはエキスパートシステムがありました。専門家の知識をルールとしてシステムに組み込もうとしたものです。CASEツールやモデル駆動開発も登場しました。設計情報を構造化し、そこからシステムをつくろうという試みです。
形は違っても、「知識をきちんと表現し、そこからシステムを動かしたい」
という挑戦は、何度も繰り返されてきました。それでも、広く定着するまでには至らなかった。理由は一つではありません。ただ、その難しさの一つに、「すでに動いているシステムから、業務知識を取り戻すことの難しさ」
がありました。新しく知識を定義することと、20年、30年動いてきたシステムから知識を掘り起こすことは、まったく別の問題だからです。

では、今回はなぜ違うと言えるのでしょうか。ポイントは二つあります。
一つは、これまで現実的ではなかった作業のコストが変わり始めたこと。
もう一つは、知識を一度つくって終わりにするのではなく、育て続けるものとして捉えること。

この二つについては、次回、もう少し詳しく考えてみます。

(Vol.02「基幹システムに埋もれた「業務知識」」に続く)

会社概要

会社名：株式会社イー・ビジネス
所在地：〒105-6405 東京都港区虎ノ門1丁目17番1号 虎ノ門ヒルズビジネスタワー5階
設立：2007年6月12日
社員数：333名（2026年2月現在）
コーポレートサイト：https://www.e-business.co.jp/