【トヨタ、車両情報を統一しAIで変換へ】なぜ社内システムは複雑になる？部門ごとに増えたシステムを整理・統合する方法

社内で長年使われているシステムを調べてみると、「営業部門と生産部門で同じ情報を別々に管理している」「同じ商品なのにシステムによってコードが違う」「システム間のデータ連携に変換処理が必要」といった問題が見つかることがあります。

一つひとつのシステムを見ると問題なく動いているにもかかわらず、会社全体で見ると複雑に絡み合い、簡単には変更できない状態になっているケースも珍しくありません。

こうした問題が発生する理由を考えるうえで参考になるのが、トヨタ自動車の取り組みです。

トヨタでは、企画、生産、営業、販売などで異なっていた車両情報の扱いを見直し、企画から販売までのシステムを連携させる取り組みを進めています。

特徴的なのは、現在の複雑な状態が短期間で生まれたものではなく、その背景が1950年の「工販分離」にまで遡ることです。

企業の歴史が長くなれば、組織も業務も変化します。そのたびに必要なシステムを追加していけば、当時は合理的だった判断が、数十年後にはシステム全体を複雑にする原因になることがあります。

本コラムでは、なぜ社内システムは複雑になっていくのか、部門ごとに増えたシステムにはどのような問題があるのか、そして整理・統合する際に何を考えるべきなのかを解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【記事要約】トヨタ、約70年前の「工販分離」に端を発する複雑なシステムを刷新

トヨタ自動車では、企画・生産・営業・販売の各部門で車両情報の扱い方やシステムが異なり、同じ部品でも工程ごとに異なる用語への読み替えが必要となっている。この背景には、1950年にトヨタ自動車工業とトヨタ自動車販売が分離した「工販分離」がある。当時、両社にまたがる各部門が、それぞれの業務に合わせて車両情報を変換し、個別に電算処理していた。1982年に両社が合併した後も部門ごとの専用システムが使われ続け、長年の積み重ねによってシステム間の連携が複雑になった。トヨタは現在、企画から販売までをつなぐ統括システムを構築し、AIによる用語変換や情報共有を進め、こうした長年の課題の解消を図っている。

出典：日本経済新聞「トヨタ、車部品用語9割減 企画～販売、AIで『翻訳』　工程減らし納車期間短く」2026年6月30日付朝刊

トヨタのシステムが複雑になった背景は約70年前まで遡る

トヨタの事例で注目したいのは、現在のシステム上の課題が、過去の組織や業務のあり方と深く関係している点です。

1950年、トヨタ自動車工業とトヨタ自動車販売が分離しました。その後、両社にまたがる部門では、それぞれの業務に合わせて車両情報を扱うようになり、同じ車両や部品に関する情報でも、部門によって異なる用語やコードが使われるようになりました。

1982年に両社が合併した後も、各部門ではそれぞれの業務に対応した専用システムが作られ、それらが長期間使われてきました。

重要なのは、最初から複雑なシステムを作ろうとしたわけではないという点です。

その時点では、それぞれの部門が自分たちの業務を効率化するために専用のシステムを利用することには合理性がありました。

しかし、それが10年、20年、30年と積み重なると、会社全体では異なるシステム、異なるデータ形式、異なる用語が併存するようになります。

システムの複雑化は、一度の大きな失敗によって起こるとは限りません。むしろ、その時々の業務に合わせて行われた個別の改善が長年積み重なった結果として発生することがあります。

なぜ部門ごとにシステムが増えてしまうのか

多くの企業では、最初から全社のシステムをまとめて設計するわけではありません。

営業部門には顧客管理や案件管理、生産部門には生産管理、物流部門には在庫管理や倉庫管理、経理部門には会計や請求管理と、それぞれ必要な機能があります。

業務上の課題が発生するたびに、各部門が必要なシステムを導入していくことは自然な流れです。

ところが、会社が成長して部門間の連携が増えると、それまで問題にならなかった違いが表面化します。

例えば、営業システムでは「商品A」、生産管理システムでは「製品001」、在庫管理システムでは「A-01」と登録されているケースです。

人が見れば同じ商品だと理解できます。しかし、システムは名称やコードが違えば、そのままでは同じものとして扱えません。

そこで、システム間を連携するために変換処理を追加します。

さらに別のシステムが加われば、そこにも新たな変換処理が必要になります。

こうしてシステムを追加するたびに、それぞれをつなぐための処理も増えていきます。

一つひとつの追加開発は小さく見えても、それが長期間積み重なることで、全体を把握することが難しいシステムになってしまうのです。

「システムは動いているから問題ない」が複雑化を見えにくくする

社内システムの複雑化が厄介なのは、日常業務では問題として認識されにくいことです。

担当者がExcelでデータを加工して別システムへ登録する、CSVを出力して別の形式へ変換する、部門ごとのコードを対応表で読み替える、といった運用で業務を成立させている企業もあります。

長年続けていると、それが通常の業務として定着します。

そのため、

「なぜこのデータを変換しているのか」

「なぜ同じ情報を複数のシステムに入力しているのか」

「なぜこのExcelが必要なのか」

という疑問自体が生まれにくくなります。

本来はシステム同士が連携することで不要になる作業を、人が間に入ることで補っている状態ともいえます。

さらに、特定の担当者だけがデータの変換方法やシステム間の関係を理解している場合には、業務の属人化にもつながります。

システムが止まっていないからといって、必ずしも問題がないわけではありません。

転記、変換、確認、修正といった作業が日常的に発生しているのであれば、個々のシステムではなく、業務全体を横断して見直す余地があります。

システムの複雑化は業務効率だけの問題ではない

システムが部門ごとに分かれていると、問題になるのは入力や転記の手間だけではありません。

経営や事業の意思決定にも影響する可能性があります。

例えば、営業部門では受注状況を把握できても、生産部門の最新状況をすぐには確認できないとします。

営業担当者が顧客から納期を聞かれるたびに生産部門へ確認しなければならなければ、回答までに時間がかかります。

さらに在庫や調達の情報まで別のシステムに分かれていれば、「この注文をいつ出荷できるのか」を判断するために複数部門への確認が必要になります。

データそのものは社内に存在しているにもかかわらず、それを必要な人が必要なタイミングで利用できません。

これは単なるシステムの使い勝手の問題ではなく、会社全体の意思決定の速度にも関わります。

システム統合を考える際には、「システムを何個減らせるか」だけではなく、「必要な情報を誰が、いつ、どのように利用できるようにするか」という視点が重要です。

部門ごとのシステムを整理するなら、まず業務全体を把握する

複雑になったシステムを整理するとき、いきなり新しいシステムの開発を始めるのはおすすめできません。

最初に行うべきなのは、現在の業務とシステムの関係を把握することです。

例えば、次のような内容を整理します。

・どの部門がどのシステムを利用しているか
・どのシステムでデータが最初に登録されるか
・同じデータを別のシステムにも入力していないか
・ExcelやCSVを介した連携がどこにあるか
・システム間で名称やコードを変換していないか
・誰がどの情報を確認、承認しているか
・システム外で行われている手作業はないか

ここで大切なのは、システムだけを見るのではなく、実際の業務を見ることです。

長期間使われているシステムでは、仕様書だけを確認しても現在の業務を正確に把握できないことがあります。

導入後に業務が変わり、Excelや手作業による運用が追加されているケースがあるためです。

「システム上ではこうなっているはず」と「現場では実際にこう使っている」が一致しているとは限りません。

現場担当者へのヒアリングも行い、データがどこで生まれ、誰が加工し、どのシステムへ渡り、最終的に何に使われているのかまで確認する必要があります。

システム統合では「共通化するもの」と「残すもの」を分ける

システム統合というと、すべてを一つの巨大なシステムにまとめるイメージを持つかもしれません。

しかし、必ずしも一つにまとめることが正解ではありません。

重要なのは、全社で共通して利用すべき情報と、各部門の業務に合わせて管理すべき情報を分けることです。

例えば、顧客、商品、取引先などの基本情報については、部門ごとに異なる名称やコードを持たせるより、共通のマスターデータとして管理したほうが連携しやすくなります。

一方、生産、物流、営業などでは、それぞれ固有の業務があります。

すべての業務を無理に同じ操作方法やルールへ合わせると、かえって現場で使いにくいシステムになることもあります。

「全部統一する」のではなく、

「何を共通化するのか」

「何を各部門に残すのか」

「どこでデータをつなぐのか」

を整理することが重要です。

システム統合の目的は、すべてを一つにすることではありません。会社全体で必要な情報を適切につなぎながら、それぞれの業務を効率よく進められる状態を作ることです。

長年使ったシステムほどフルスクラッチが選択肢になる理由

既存システムを整理・統合する際には、パッケージやSaaSを活用する方法もあります。

自社の業務を標準機能に合わせられるのであれば、有力な選択肢です。

一方、長年にわたって自社独自の業務を積み重ねてきた企業では、既製のシステムだけでは対応しにくい場合があります。

部門ごとに異なる業務ルールがある、既存システムとの連携が多数必要、独自の承認フローがある、取引先とのデータ連携が必要といったケースです。

こうした場合には、自社の業務に合わせてフルスクラッチでシステムを開発する方法も選択肢になります。

ただし、既存システムをそのまま新しい技術で作り直すだけでは、これまでの複雑さまで引き継いでしまいます。

「現在ある機能をすべて再現する」という発想ではなく、

「なぜこの機能が存在するのか」

「この作業は現在も必要なのか」

「複数部門で共通化できないか」

「人が行っている変換や転記をなくせないか」

といったところまで掘り下げて考えることが重要です。

システム刷新は、古いシステムを新しくするだけのプロジェクトではありません。

長年積み重なった業務を整理し、これからの事業に必要なシステムのあり方を考え直す機会でもあります。

システム統合は一度にすべて変える必要はない

大規模な社内システムほど、一度にすべてを入れ替えることにはリスクがあります。

対象となる業務が広くなるほど現場への影響も大きくなり、移行するデータや確認すべき項目も増えるためです。

そのため、現在のシステムを整理したうえで、優先順位を決めて段階的に統合する方法も考えられます。

例えば、最初に共通マスターを整備し、その後に営業システムと生産管理システムを連携するなど、対象範囲を分けて進めます。

どこから着手するかを決める際には、「一番古いシステムから」という判断だけでは十分ではありません。

手作業が多い、複数部門への影響が大きい、データ活用を妨げている、保守できる担当者が少ないなど、事業や業務への影響を踏まえて優先順位を決める必要があります。

システム開発会社に相談する場合も、単に「このシステムを新しくしたい」と伝えるだけではなく、現在困っている業務や部門間の連携まで共有することで、より適切な刷新方法を検討しやすくなります。

まとめ

社内システムが複雑になる原因は、必ずしも過去のシステム開発の失敗にあるわけではありません。

会社の成長や組織変更、新しい事業への対応などに合わせて、その時々で必要なシステムを追加してきた結果、会社全体では複雑になっていることがあります。

特に注意したいのは、システム間の違いを人の作業で補っている状態です。

同じ情報を何度も入力する、Excelでデータを加工する、CSVを変換する、部門ごとのコードを読み替えるといった業務が日常化している場合、システムを横断して見直すタイミングかもしれません。

システム統合で重要なのは、単純にシステムの数を減らすことではありません。

現在の業務とデータの流れを整理し、全社で共通化する情報と各部門に残す業務を切り分け、必要な情報が必要な場所へ流れる状態を作ることです。

長年使われてきた社内システムを刷新する際には、既存システムをそのまま作り直すのではなく、これまで積み重なった業務そのものを見直すことが、将来の複雑化を防ぐための重要なポイントになります。

さいごに

長年使われてきた社内システムを整理・統合する際に重要なのは、単に古いシステムを新しいものへ置き換えることではありません。

部門ごとに異なる業務やルール、データの持ち方、システム間の連携、Excelや手作業で補っている部分まで整理し、「何を残し、何を共通化し、何を見直すべきか」を考える必要があります。

当社フレシット株式会社は、フルスクラッチ（オーダーメイド）のシステム開発を専門としています。既製のパッケージに業務を合わせるのではなく、お客さまの現在の業務や既存システムを丁寧に把握したうえで、本当に必要な機能やデータの流れを整理し、それぞれの企業に合ったシステムをご提案します。

「部門ごとにシステムが分かれている」「同じデータを複数のシステムへ入力している」「ExcelやCSVによる手作業が残っている」「既存システムが複雑で、どこから見直せばよいかわからない」といった状況でも、現状の整理からご相談いただけます。

長年積み重なった業務をそのまま新しいシステムへ移すのではなく、これからの事業や業務に合わせてシステムを作り直したいとお考えでしたら、ぜひ当社フレシット株式会社へご相談ください。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら