業者を替えたいが、うちのシステムのことは業者しか分かっていない

販売管理のシステムを入れて、何年も経つ。保守の業者とは長い付き合いで、困ったときは電話一本で来てくれる。ただ、ここ数年で保守料が上がり、担当者が替わってからは話の通りも悪くなった。一度、別の業者に話を聞いてみる。すると最初にこう言われる——「今のシステムの資料を見せていただけますか。それが無いと、見積もりが出せません」。社内を探して出てくるのは、最初の契約書と、何年か前の改修の見積書くらいである。結局、今の業者に頼むしかないのか——この辞典が扱うのは、その場面である。

• 設定の変更や小さな改修は、今の業者に頼めばやってくれる。何をどう変えたのかの記録は、社内には残っていない。
• 別の業者に相談したら、「今の仕組みが分からないと、移せるかどうかも言えない」と返された。
• 管理画面に入るIDとパスワードを、社内の誰も持っていない。使う人を一人増やすのにも、業者に連絡している。
• 取引先の指定に合わせた請求書の出し方など、自社のためだけの作り込みが何か所かある。それがどこにあるのかは、業者の担当者が知っている。
• 中のデータを別の形で取り出せるのか、取り出したとして次のシステムで読めるのか、確かめたことがない。
• 保守料は毎年払っているが、その中に何が含まれているのかを、社内では説明できない。

業者に不満があるかどうかとは別に、ここで問われているのは、替えるかどうかを自社で決められる状態にあるかである。

この場面で出てくる考え方は、二つに分かれやすい。

一つは「契約書を読めば、替えられるかどうかが分かる」。解約の条件や、作ったものの権利がどちらにあるかを探し、そこに答えがあると考える。

もう一つは「もう替えられない。今の業者で続けるしかない」。長く任せてきた以上、縛られているのだと受け止めて、話をそこで閉じる。

向きは逆だが、二つには共通点がある。どちらも、替えられるかどうかが、契約を結んだ日に決まったものとして扱っている。

公正取引委員会が2022年に公表した、国の機関や自治体を対象にした調査がある。同じ業者と再び契約することになった理由を尋ねたところ、最も多く挙がったのは、権利や契約の話ではなかった。「既存の業者しか、今のシステムの機能の詳細を把握できなかったため」で、答えた機関のおよそ半数にのぼる。

同じ調査のヒアリングでは、ある都道府県の担当者がこう述べている。システムは何度も改修されてきたが、改修のたびの変更の中身は既存の業者しか把握しておらず、自分たちも理解できていないため、他の業者に発注できない状態になっている——。替えられなくなった原因は、ある一日の契約ではなく、何年もかけた改修の積み重ねの側にある。

中小企業の場面に置き換えると、この積み重ねは四つのものに分かれる。

• データ：中に溜まった情報を、どんな形で取り出せるか
• 資料：設計書や設定の資料、機器のつなぎ方を示した図
• 権限：管理画面に入り、設定を変えられるID
• 作り込み：取引先の指定や社内の事情に合わせて、自社のためだけに足した部分

どれも、最初から業者の側にあったわけではない。取引先から「この項目を請求書に入れてほしい」と言われ、手作業では間違えるので業者に頼む。業者はそれに応える。設定の変更も、IDの管理も、任せたほうが早いから任せる。一つひとつは、その時点でもっともな判断である。ただ、応えてもらった中身をいちばんよく知っているのは、作った側になる。そして、改修のたびに資料が書き直されるとは限らない。IPA（情報処理推進機構）の資料も、長く運用してきたシステムを作り直す場面では業務の知識が失われていることが多いとし、その例として、設計書が更新されず古いままになっていることや、担当者の手作業や独自の仕組みが設計書に書かれていないことを挙げている。

つまり、替えられなさは契約書の一枚の中ではなく、保守と改修の請求書の枚数だけ積み上がっていく。この構造は、どちらかに落ち度が無くても成り立つ。デジタル庁の検討会の報告書も、同じ業者に長く任せることで生じる業務改善の停滞や価格の高止まりについて、原因を発注者と受注者の「双方」に置いて書いている。

同じ調査は、別のことも示している。同じ業者と再び契約した理由には、入札の結果としてそうなった例や、安定して動いていること、他社より明らかに安いことを理由に自ら選んだ例も含まれている。調査した側自身、同じ業者と再び契約していることが、ただちに抜け出せない状態を意味するわけではない、と書いている。分かれ目は、替えられるのに続けているのか、替えられないから続けているのかを、自社が区別できているかどうかにある。

問いを「替えるか、替えないか」から、「次の業者に、何を渡せるか」に置き換える。

先の四つ——データ、資料、権限、作り込み——について、それぞれが今どこにあるかを三つに分ける。自社の手元にあるもの。今の業者に頼めば出てくるもの。どこにも無いもの。この三つに分かれた時点で、「替えられない」というひとかたまりの感覚が、具体的な欠けの一覧に変わる。

この分け方は、業者と対立する話にはならない。二つ目の「頼めば出てくるもの」は、まさに今の業者に頼んで出してもらうものだからである。人口5万人に満たない自治体の中には、設定の資料や機器の構成図を、作業の成果物として提出してもらうことを契約に書いている例がある。先のデジタル庁の報告書も、業者の側に権利がある部分であっても、改修や運用に必要な内容は形を変えて提供を受けられるようにする、という方向を示している。業者の権利を取り上げるのではなく、運用に要るものを手元にも置く、という線の引き方である。

続けるにしても替えるにしても、この一覧がある会社と無い会社とでは、次の判断の重さが違ってくる。

自社に何が無いかを知り、それを手元に寄せていく道は、三つに分けられる。

A案：AIに、手元の書類から「次に渡せないもの」の一覧を作らせる

冒頭の場面のように、手元にあるのが契約書と見積書くらいでも、そこに業者とのメールや請求書、作業の報告書を合わせれば、読む量はそれなりになる。それを読み比べて「何が書いてあって、何が書いていないか」を拾う作業は、手間がかかるわりに後回しになりやすい。この読み比べをAIに任せる、という道がある。

やることは、こうだ。手元の書類の文面をAIに渡し、次のように頼む。

• 「この契約書と保守契約書の中で、契約が終わるときのデータの返し方、作ったものの権利、次の業者への引き継ぎ、資料の提出について、書いてあることと書いていないことを分けて一覧にして」
• 「今のシステムから書き出したデータの、項目名の一覧を渡す。それぞれの項目が何を表していそうかを推定し、名前から意味が分からない項目を挙げて」
• 「業者を替えると仮定したとき、次の業者に渡す必要があるものの確認表を作って。手元の書類から、あるものと無いものに仕分けて」
• 「今の業者に、設定の資料とデータの書き出し方を問い合わせるメールの下書きを作って」

返ってくるのは、たとえばこういう形になる。

• 「保守契約書には、契約終了時のデータの返却について記載が見当たりません」
• 「改修の見積書が4件ありますが、改修後の資料を受け取ったことが分かる記載はありません」
• 「データの項目のうち、"区分2"と"予備1"は名前から意味を推定できません。業者への確認が要ります」

これで分かるのは、自社の手元に何が無いかである。無いものを取りに行くのは人と業者の話し合いになるが、何を頼むかが一覧になっていれば、その話し合いは短く済む。データについては、中身ではなく項目名だけを渡す形にすれば、顧客の情報そのものをAIに渡さずに済む。

• 向く場面：書類は社内に散らばって残っているが、読み比べる人と時間が無い会社。業者に何を頼めばよいのかが、まだ言葉になっていない会社。
• 割に合わないこと：AIに見えるのは、渡した書類の中だけである。業者の側のシステムの中で何がどう作り込まれているかは、AIには分からない。この題材では、そこがいちばん大きな部分でもある。渡した資料が古く、実物とずれていれば、AIの整理も同じだけずれる。出てきた一覧は「書類に書かれていないもの」の一覧であって、「システムに無いもの」の一覧ではない。契約の文言がどういう効力を持つかも、この一覧からは決まらない。さらに、契約書や取引の記録を外のAIサービスに渡すことになるため、入力した内容が機械学習に使われないかを、使うサービスの規約で先に確かめておく必要がある。
• 始める前に要ること：社内に散らばっている契約書・見積書・報告書を、一か所に集めること。紙しか無いものは写真やPDFでよい。データの項目名は、今の業者に書き出し方を聞くか、画面に出ている項目を書き写す。

※使う道具は問わない。ここで指しているのは、手元の文書を読み比べて抜けを拾う作業をAIに任せる、という使い方である。

B案：今の業者に、資料と取り出し方を出してもらう

替えるかどうかとは別に、今の業者に「設定の資料」「機器の構成図」「データを書き出す方法と形式」「管理者のID」「自社専用に作り込んだ部分の一覧」を出してもらう道。業者の手元にあるものを、自社の手元にも置く。

替える話を持ち出す必要はない。「社内でも分かる状態にしておきたい」という頼み方で足りる。出てきたものは、そのままA案でAIに渡す書類にもなり、C案で契約に書き込む項目の見本にもなる。

• 向く場面：業者との関係は悪くなく、不満は主に費用や対応の遅さにある会社。すぐに替える予定は無いが、替えられる状態だけは作っておきたい会社。
• 割に合わないこと：依頼の内容によっては、資料づくりが別の作業として扱われ、見積もりが出てくることがある。業者の側に権利がある部分は、そのままの形では渡されないこともある。また、出てきた資料が今の実物と合っているかは、受け取った側では確かめにくい。
• 始める前に要ること：何を出してほしいかを、項目として書いておくこと。「資料をください」だけでは、何が出てくるかは相手次第になる。

C案：次の更新や改修の契約に、受け取るものを書き込む

保守契約の更新や、まとまった改修を発注するときに、「作業後の設定の資料を受け取る」「契約が終わるときは、読める形でデータを返してもらう」「業者が替わる場合は引き継ぎに協力してもらう」といった項目を、契約の中に入れてもらう道。これまでの積み上がりを崩すのではなく、これから積み上がる先を自社の側に寄せる。

先の調査でも、国の機関や自治体が、特定の業者に限らずどの業者も参入できるようにするための工夫として挙げたものの中で、最も多かったのは、構築が終わったときに機能の説明や設計書を受け取ることだった。データの権利を発注者の側に置くこと、引き継ぎを契約に書いておくことも、工夫として挙がっている。また、IPAと経済産業省は、ITの専門知識を持たない発注者と業者の取引を想定した契約書のひな形を公開しており、その全体図では、データの移行の支援は保守とは別の契約として並んでいる。移行は、頼まなくても付いてくる作業として扱われていない、ということでもある。

• 向く場面：保守の更新時期や、まとまった改修の予定が近い会社。
• 割に合わないこと：すでに積み上がった分には効かない。どこまで書き込めるかは相手との話し合いで決まり、受け取るものが増えれば費用に跳ね返ることもある。
• 始める前に要ること：自社に何が無いかの一覧。A案かB案で先に分かっていると、何を書き込むかが決まる。

並べてみると、AかBで「何が無いか」を確かめ、Cで次から積み上がる先を変える、という順でつながる。替えるかどうかは、そのあとで決められる。

業者に連絡する前に、社内だけでできることがある。

紙に四行、データ・資料・権限・作り込みと書く。それぞれの横に、「手元にある」「業者に頼めば出てくるはず」「分からない」のどれかを書き込む。「分からない」が並ぶ行が、今の自社でいちばん業者の側に寄っている所である。

そのうち権限の行は、今日のうちに確かめられる。管理画面に入るIDとパスワードを、社内の誰かが持っているか。持っていなければ、それが最初に手元へ戻すものになる。

もう一つ、次に業者と話す機会があれば、一つだけ聞いてみる。「今のデータを、他のシステムでも読める形で書き出すことはできますか」。その答えが、紙に書いたデータの行を埋める材料になる。

ここまでで分かるのは、自社の手元に何が無いかの輪郭までだ。それを誰に、どの順で頼むか、そして替えるのか続けるのかという判断は、その先に残る。

「書類を集めても、どれが大事なのか読み分けられない」「業者に資料を頼みたいが、どう切り出せば角が立たないか分からない」「作り込みが多く、替えるとどこまで作り直しになるのか見当がつかない」——一覧ができても、ここから先は会社ごとの事情で答えが変わる。何が業者の側にだけあるのかは、何年もかけて少しずつ積み上がったものなので、社内からは見えにくい。

そういうときは、OSAKA AI-Center の窓口に相談するという選択肢がある。何かを買う必要はなく、こちらから売り込むこともない。「うちのシステムで、業者の側にしか無いものはどれか」——その切り分けを一緒に考えるところまでが、この辞典の役割である。

ITは、本来は専門家の領分でもある。弁護士や税理士のように、ITと経営の両方を知る第三者を"ブレイン"として側に置く——という考え方もある。何もかも自社だけで抱え込まなくていい。この辞典も、そうした相手と一緒に読めば、自社に合った次の一手につながりやすい。