SimLex ERP 誕生までの軌跡

第1章　「その倉庫をなくしたらどうなるか」・・・ペトリネットとの出会い

大学を卒業し、大手ベアリングメーカーに就職しました。

配属されたのは「生産技術研究所」と呼ばれる部署で、主に工程間物流や工程内搬送、工程設計などを担当することになりました。

あるプロジェクトで工程間物流の設計を担当した際、上司から「これを参考にしなさい」と、一冊の本を手渡されました。

そのときは、この本との出会いが自分の人生を大きく変えることになるとは、夢にも思っていませんでした。

そこに書かれていたのが、ペトリネット（Petri net）という理論だったのです。

ペトリネットの考え方自体は、非常にシンプルです。

「現実の世界を、いかに少ない本質的な要素だけでモデル化できるか」——これに尽きます。

その本の中に、私の目を釘付けにした一つの問いがありました。

「その倉庫をなくしたらどうなるか」

一読して、心の底から湧き上がる大きな衝撃でした。

確かに、倉庫そのものをなくすことができれば、入出庫の作業は一切不要になります。倉庫を管理する業務も、管理システムも、そして「倉庫」という建物そのものも必要なくなるわけです。

目の前に当たり前のように存在する「倉庫」を前提にして改善案を考えるのではなく、そもそも「倉庫は本当に必要なのか」と根本から疑ってみる。この発想の転換は、若かった私にとって強烈な体験でした。

そして同時に、もう一つの重要な真理に気づかされました。

「倉庫そのものは、何の付加価値も生み出していない」ということです。

製品を倉庫に入れても、製品の品質が上がるわけではありません。加工が進むわけでも、組み立てられるわけでもありません。それどころか、倉庫を維持するためには建物、設備、人員、搬送、そして膨大な在庫資金というコストと時間を消費し続けます。

もちろん、現実の生産活動において一時的な保管場所が必要になる場面はあります。しかしそれは、「倉庫という場所に価値がある」からではありません。本来必要なのは倉庫ではなく、「物を適切なタイミングで次の工程へ流すこと」そのものなのです。

そう捉え直した瞬間、今まで「あって当たり前」に見えていた工場内の景色が、まったく違って見え始めました。

「どうすれば倉庫を効率化できるか」という視点から、「そもそも倉庫をなくすことはできないのか」という構造的な問いへ。

この発想は、私にとって単なる物流改善の手法にとどまりませんでした。

「今存在しているものを前提としてマイナーチェンジを繰り返すのではなく、存在そのものを疑い、本質に削ぎ落とす」

これこそが、後に私が手掛けるシステム設計、そしてSimLex ERPの核となる思想が芽生えた最初の瞬間でした。

ペトリネットは、私に一つ上の視点を与えてくれました。

「存在しているから必要なのだ」という思い込みを捨てる。長年使われている慣習だから正しい、とも決めつけない。まずその要素を思考実験として取り除いてみること。そして、取り除いたときに何が起きるかを観察する。不要なものを削ぎ落とした果てに、真に不可欠な「本質」だけが残るのです。

「現実に存在する複雑な業務をそのままシステムに写し取るのではなく、ビジネスの本質だけを抽出して美しい構造に再定義する」

数十年後、この基本姿勢は「SimLex ERP」という現実のプロダクトとなって結実することになります。

振り返れば、SimLexの真の出発点は会社を設立した2012年ではありませんでした。大学を卒業して間もない頃、生産技術研究所のデスクで開いた一冊の本。あのペトリネットとの出会いから、すべてのストーリーは始まっていたのです。

【解説】ペトリネットとSimLexの共通項

ペトリネットの世界では、現実の複雑な状態をごくわずかな構成要素だけで見事に表現します。これをSimLexの設計思想に置き換えてみると、以下のように一対一で対応します。

• トークン（Token）： 物理的な在庫・モノの量

• プレース（Place）： 倉庫、工程、仕掛、出荷などの「状態・場所」

• トランジション（Transition）： 入庫、出庫、ライン投入、完成、出荷といった「状態の変化（事象）」

• 発火（Firing）： トランジションが実行され、トークンが次の状態へ移動すること

ここで決定的に重要なのは、「今、プレースに何個残っているか」という現在の結果そのものではありません。

真に価値があるのは、「何が、いつ、どのトランジション（事象）を通って、どこへ移動したのか」という変化の履歴です。

受払（Stock Transaction Log）を「トランジションの履歴」として一切の漏れなく保持できさえすれば、計算によって「現在どこにどれだけのトークンが存在しているか（＝最新の在庫状態）」は自ずと導き出せます。

単に結果としての「在庫テーブル」を保持するのではなく、状態を生み出した「変化（事実）そのもの」を単一のソースに記録する。

第1章で出会ったペトリネットの構造美こそが、後にSimLex ERPを貫く「Single Resource of Truth（唯一の真実）」のロジックそのものだったのです。

第2章　検討レベルによって変わる、ハードウエアとソフトウエアの境界の揺らぎ

会社員時代、社内で「次世代設備開発」という非常に大きなプロジェクトが発足しました。

各部署から、これまで優れた設備開発を担ってきたトップ技術者たちが集められ、私も設備間搬送の担当者としてプロジェクトに参画することになりました。

ミーティングが始まり、議論を重ねていく中で、私はある違和感を抱き始めました。

周囲の議論の中心が、終始「どんなスペックの設備を作るか」「どう設計するか」という要素技術の話に終始していたからです。

「この議論の進め方は、どこかおかしいのではないか」

本来、設備のスペックというものは、設計する側が単体で自由に決められるものではありません。

「その設備は、何を作るためのものなのか」

さらに踏み込めば、「顧客からの需要に対し、工場全体としてどう応えていくのか」。そこから逆算して立ち戻らなければ、設備のあるべき姿など決まるはずがないのです。

例えば、複数の設備を繋いで一つの生産ラインを組むのであれば、まず「ライン全体としてどれだけの生産能力や段取りの柔軟性が必要なのか」を定義しなければなりません。そして、そのラインをどう編成して工場全体の需要を満たすのか。

つまり、【顧客需要 ➔ 生産計画 ➔ 工場 ➔ ライン ➔ 設備】というように、上位の要求からブレイクダウンして遡る視点が不可欠です。

私はプロジェクトの場で、この構造的な視点を強く主張しました。

しかし結果は、プロジェクトリーダーとの大喧嘩でした。

今思えば、お互いの見ている景色が違っていたので当然だったのかもしれません。

専門領域を極めた技術者たちは「自分が担当する設備をどう作るか」というミクロな視点から見ていました。一方で私は、「そもそも、その設備のスペックは何によって決定づけられるのか」という、一つ上のマクロな階層から全体を捉えようとしていたのです。

しかし、この激しい議論を通じて、私は非常に重要な真理に思い至りました。

「ハードウェアとソフトウェアの境界は、絶対的なものではない。どこから見るかによって揺らぐのだ」

後に私は、この概念を「制約条件」と「変更可能条件」という言葉で整理するようになります。

ある検討レベルにおいて、すでに決定していて動かせない前提が「制約条件」です。そして、その制約の中で組み替えたり最適化したりできる要素が「変更可能条件」です。

ところが面白いことに、検討する「階層（視点）」を変えると、この関係性が一変します。

• 機械設計のレベル： 購入品（部品）を「制約条件」とし、それらをどう組み合わせて機械を作るかが「変更可能条件」になります。

• ライン設計のレベル： 各設備を「制約条件」とし、それらをどう配置・連携させて必要なライン能力を出すかが「変更可能条件」になります。

• 工場設計のレベル： 各ライン編成を「制約条件」とし、それらをどう組み合わせて工場全体を構成するかが「変更可能条件」になります。

つまり、下の階層では選択不可能だった「ハードウェア（制約）」が、一つ上の階層から見ると、自由に組み替えられる「ソフトウェア（変更可能条件）」へと変化するのです。

ハードウェアかソフトウェアかという属性は、モノそのものに宿っているわけではありません。

「自分が今、どの抽象度（階層）からその課題を見ているか」によって決まるのです。

この「制約条件と変更可能条件の境界は、検討レベルによって変化する」という発見は、後に私がシステム設計において高度な「階層化モデル」を構築していく上で、揺るぎない背骨となりました。

そしてもう一つ、私のエンジニア人生にとって決定的な変化が起きました。

設備のスペックを決めるには、ラインを見なければならない。

ラインを見るには、工場全体を見なければならない。

工場全体を見るには、「いつ、何を、どれだけ作ればよいか」を知らなければならない。

そして、それを決定づけているのは、最終的な「顧客の需要」である——。

単なる設備のスペックを考えていたはずの私の視点は、こうして「生産管理」という広大な世界へと否応なく遡っていきました。これが、私が本格的に生産管理の深淵へと足を踏み入れる、大きなきっかけとなったのです。

第1章で私は、「その倉庫をなくしたらどうなるか」という本質への問いに出会いました。

そして第3章へと続くこの第2章で、「その制約条件は、本当に制約なのか。自分はどの階層から見ているのか」という視座の転換を得ました。

振り返れば、この二つの問いこそが、数十年後に誕生するSimLex ERPの設計思想を形づくる、かけがえのない原点だったのだと実感しています。

第3章　私のMRPの原点となった偉大な師との出会い

大手ベアリングメーカーに13年間勤務した後、私は独立して自分の会社を設立しました。

会社を立ち上げて間もない頃、ある大手モーターサイクルメーカー子会社の専務さんと出会い、部品メーカー向けのスケジューラを共同開発することになりました。

この方はもともと親会社に在籍されていた方で、1970年代——まだ日本で「MRP」という言葉すらほとんど知られていなかった時代に、いち早くMRPを実務に導入されたパイオニアでした。まさに、日本の生産管理における草分け的な存在です。

この師とのミーティングを重ねる中で、私は生産管理の神髄について多くを学びました。

それまでの私は、生産技術者の立場として「モノがどう流れるか」「設備をどうレイアウトするか」という物理的な視点からしか現場を見ていませんでした。

しかしここで初めて、「生産活動を情報の流れとして体系的に捉える」という全く新しい視点に触れたのです。

そこで学んだ概念は、驚くほどシンプルでした。

しかし、そのシンプルさの中にこそ生産管理の本質が詰まっていました。

一連の流れはこうです。

【受注管理 ➔ 基準日程生産計画 ➔ MRP（資材要件計画）】

顧客からの需要を受け取り、それを生産計画へ変換し、そこから必要な部品や材料を展開していく。一見すると当たり前の手順に見えます。しかし、これを一つの断絶のないプロセスとして捉え直すと、生産管理の全体構造が非常に鮮やかに見えてきました。

MRPのロジック自体も実に見事なものでした。BOM（部品表）を分解し、必要数と必要時期を割り出していく。一見複雑を極める工場の管理業務が、どこまでもシンプルかつ明確な論理で表現できる——。この美しさに、私は強く惹きつけられました。

さらに決定的だったのが、データベース設計の根底となるER図（Entity Relationship Diagram）の考え方です。

品目、部品表（BOM）、工程手順、受注、生産計画といった生産管理に必要な要素を「関係性」として整理する。単に「何の情報を持っているか」ではなく、「それぞれの情報が、どのような構造で繋がり合っているのか」をデータモデルとして捉える手法です。この学びは、後に私がSimLex ERPのデータベースを構築していく上で、計り知れない財産となりました。

生産技術出身の私にとって、これらデータの世界はすべてが新鮮でした。

私はそれまで、「モノ」の世界を生きていました。工場があり、設備があり、加工された製品が次々と流れていく。

しかしMRPを学んだことで、その裏側には【受注 ➔ 生産計画 ➔ 部品展開 ➔ 必要量・時期の計算 ➔ 調達・製造】という、もう一つの整然とした「情報の世界」がリアルタイムに脈打っていることを知ったのです。

学びの中で、私は先人たちの偉業に対する深い敬意を禁じ得ませんでした。

1970年代という、現在のような高度なコンピュータもデータベース技術も存在しなかった時代に、先人たちは生産の本質を極限まで考え抜き、MRPという完成された理論を生み出していました。

私たちの世代がすべきことは、過去の理論を安易に否定することではありません。

まずは偉大な知恵を正しく受け継ぐこと。その上で、現代の技術と新しい思想を積み重ねていくことだと確信しました。

こうして私は、先人からMRPという本質的な知恵を受け取りました。

一方で、私自身にはこれまで生産技術の現場で泥臭く培ってきた、設備、工程、物流、そしてスケジューリングについてのリアルな知見と経験がありました。

そこで、私の頭の中に一つの問いが浮かび上がってきたのです。

「そもそも、MRPとスケジューラを別々のシステムとして分ける必要があるのだろうか？」

MRPは「何を、いつまでに、どれだけ作る必要があるか」を計算します。

スケジューラはそれを「実際の設備や工程の制約の中で、具体的にいつ作るか」に落とし込みます。

この二つを分離せず、完全に一つへ統合できれば、現実の工場を完璧に再現できる「極めて精度の高い生産管理」が実現できるのではないか——。

これが、後に私が長年追い求めることになる「MRPとスケジューラの融合」という新しい世界へ踏み出した、最初の一歩でした。

振り返れば、この偉大な師との出会いは、単に知識を得たという以上の意味を持っていました。

• 第1章（ペトリネット）： 現実の本質をシンプルな構造で捉える

• 第2章（制約条件）： 視座（階層）を変えることで、制約を変更可能にする

• 第3章（MRPとER図）： 生産活動を情報の構造体としてモデル化する

点と点だった私の経験と知恵が、この第3章で一つの線となり、未来のSimLex ERP誕生に向けて力強く動き始めたのです。

第4章　「単純化の最適化」と、その先に立ちはだかった「APSの限界」

MRPとスケジューラを真に融合させるためには、現実の生産現場に存在する無数の制約条件を、システム上に精密に表現しなければなりません。

しかし、従来のスケジューラを導入しようとすると、必要なマスタの数が爆発的に跳ね上がってしまいます。

• 設備の稼働時間帯、設備能力、代替設備と優先順位

• 前の生産品目に関係なく発生する固定段取時間

• 前の生産品目によって変化する変動段取時間

• 塗装色、材料、温度などの変更によって生じる生産優先度

• 作業者の人数、スキル、および勤務シフト

これらをすべて個別の組み合わせとしてマスタ登録しようとすれば、データ量は途方もない数になります。

例えば「塗装色」「材料」「温度」にそれぞれ複数の種類がある場合、それら全パターンに対してマスタを作成しなければなりません。これではマスタの登録作業だけで現場は疲弊し、運用の維持すら困難になってしまいます。

そこで威力を発揮したのが、私が温めていた「単純化の最適化」という設計思想でした。

ここで言う「単純化」とは、単に情報を削る（削ぎ落とす）ことではありません。

【単純化】 現実の本質だけを抽出し、それをさらに高次のレベルへと「抽象化」すること。

【最適化】 単一のマスタを個別最適化するのではなく、他のデータ群との整合性を保ちながら、全体として機能を全うさせること。

この思想を、具体的な例で解説してみます。

例えば、ある設備で「前に作った品目」の塗装色や材料によって、次に作る品目の生産優先度が変わるとします。

これを愚直にマスタ化しようとすれば、「白➔黒」「白➔灰色」「黒➔白」「黒➔灰色」……と、品目同士のあらゆる組み合わせを個別に登録する必要があります。品目数が数百〜数千に及べば、組み合わせは数百万件に達してしまいます。

そこで私は、品目そのものではなく、品目が持つ「品質特性」という本質へ抽象化しました。

• 品質特性1（塗装色）： 白、灰色、黒

• 品質特性2（材料）： 材料A、材料B、材料C

品目マスタには「この品目は【塗装色：白／材料：A】」という属性（特性）だけを持たせます。

そしてマスタとして定義するのは、品目同士の組み合わせではなく、「特性同士の変化（遷移）」に対する優先度です。

• 白 ➔ 黒： 優先度3

• 白 ➔ 灰色： 優先度2

• 同系色： 優先度1

こうすれば、将来的に品目が何千種類に増えようとも、マスタ化すべきデータ量は最小限で済みます。

「品目そのものをマスタ化するのではなく、品目に潜む『本質的な特性』を抽象化し、その特性間の関係性をマスタ化する」

これこそが「単純化の最適化」の具体例です。「品質特性マスタ」は単に登録の手間を減らすためのテクニックではありません。複雑極まりない現実世界から本質だけを抜き出し、最小限の構造でスマートに現実を再構築するためのアプローチなのです。

さらに、高速処理を実現するための工夫も施しました。

大量のデータを扱うスケジューラを実行する際、これらのシンプルなマスタ構造をそのままメモリ上のデータベースへ展開させたのです。

物理データベースとメモリ上のデータ構造をあらかじめ一致させておけば、プログラムによる複雑なデータ変換処理が不要になります。

結果として、「マスタがシンプルになる ➔ メモリ構造もシンプルになる ➔ プログラムもシンプルになる ➔ 処理速度が圧倒的に高速化する」という素晴らしい連鎖が生まれました。

こうして私は、MRPとスケジューラを完全融合させた先進的システム——いわゆるAPS（Advanced Planning and Scheduling）の構築に成功しました。

MRPで「何を、いつまでに、どれだけ必要なのか」を割り出し、スケジューラで「設備・人・工程の制約下で、実際にいつ作るのか」に落とし込む。これは間違いなく、従来の生産計画を大きく凌駕する革新的なシステムでした。

しかし、歓喜も束の間、私は巨大な壁に直面することになります。

「APSだけでは、工場は救えない——APSの限界」

APSの本質は、どこまでいってもスケジューラ（計画立案）を中心としたシステムです。

計画の精度を極限まで高めることはできても、それだけでは「生産管理」という巨大な営みの一部でしかありません。

生産管理とは、単に未来の精密なスケジュールを引くことではないのです。

計画を立て（Plan）、実行し（Do）、実績を把握し（Check）、その結果を次の計画へと反映する（Action）。このPDCAサイクルが円滑に回って初めて、工場は経営として機能します。

そのためには、一本の太い幹でつながった構造が不可欠でした。

【販売 ➔ 購買 ➔ 生産計画 ➔ 生産実績 ➔ 在庫管理 ➔ 原価管理 ➔（次の計画へ）】

APSには極めて優秀な計画エンジンがありました。しかし、販売も、購買も、現場の実績も、在庫も原価も、すべてが一つのエコシステムとして連動しているわけではありませんでした。

「APSは生産計画を高度化させる。しかし、それだけでは『生産管理そのもの』にはなれない」

その限界が明確に見えたとき、私は大きな決断を迫られました。

MRPとスケジューラの融合という一つの山を登り切った。しかし、その山頂から見えたのは、既存のAPSというフレームワークそのものでは決して解くことができない、さらに広大な課題の海だったのです。

「ここから先は、これまでの延長線上では答えが出ない」

私は、システム全体のあり方そのものをゼロベースで思考し直す、新たな試練の旅へと踏み出すことになりました。

第5章　なぜ開発Frameworkが必要だったか・・・属人性の排除とメタ駆動への到達

APSの限界に突き当たり、「これから自分はどの道を進むべきか」という大きな岐路に立たされていた私を置き去りにするように、テクノロジーの進歩は勢いを増していきました。

当時、ソフトウェア開発の世界では「.NET」への移行という巨大な潮流が押し寄せていました。

経営者であり技術者でもあった私は、これを単なる「プログラミング言語の切り替え」として片付けることはできませんでした。むしろ「これまでのソフトウェア開発のあり方そのものを見直す、絶好の契機にすべきだ」と考えたのです。

当時、私たちのスケジューラは処理速度を最優先し、C++で構築していました。

一方で、マスタデータやトランザクションデータの処理には「MS-Access」を使用していました。

しかし、MS-Accessを使った開発には、運用上見過ごせない二つの大きな課題がありました。

1. マイクロソフトによるバージョンアップ（仕様変更）の影響をダイレクトに受けてしまうこと

2. 開発者個人のスキルや癖に依存した「属人性の高いプログラム」になりやすいこと

特に後者は、組織の経営者として致命的なリスクでした。

「優秀なプログラマーが一人いればシステムは完成する。しかし、その担当者が退職したらどうなるか？ 他のプログラマーがその暗黒街のようなコードを読み解き、修正し、発展させることができるのか？」

私は、この開発の属人性に対して強い危機感を抱いていました。

そこで、新言語として.NETの「C#」を採用すると同時に、独自の「開発Framework（フレームワーク）」をゼロから自作するという構想を立ち上げたのです。

目指したのは一言で言えば、「誰が開発したプログラムであっても、他のプログラマーが容易にメンテナンスできる仕組み」です。

その実現に向け、最初から揺るぎないコンセプトを掲げました。

• マルチDB対応： Oracle、SQL Server、MySQL、DB2、MS-Accessなど主要DBに柔軟に対応する

• 自動管理機能： データベースの初期化や差分更新をFrameworkから直接実行可能にする

• グローバル対応： 多言語切替機能を標準実装する

• 設定のデータ化： 画面デザイン時のプロパティ情報、メニュー設定、権限設定をすべてDB化する

• Excel連携： データインポート／エクスポートおよび帳票出力（ノープログラム作成）を標準化する

つまり、プログラマーが画面ごとに毎回ゼロからコードを書くのではなく、「システムを動かす共通の仕組み（基盤）を作り、それを何度でも再利用する」という発想への転換でした。これこそが、後に誕生する「SimLex Framework」の土台です。

そして、このFrameworkの開発においても、第4章で確立した「単純化の最適化」の思想が絶大な効果を発揮しました。

その最たる例が「画面設定の抽象化」です。

私は「画面を設計するとは、一体何を定義することなのか？」と問いを深め、一つの究極的な抽象化に行き着きました。

「画面上に存在するすべての要素は、単なるフォームのリソースに過ぎない」

入力項目、コンボボックス、ボタン、ラベル、テキスト、メニュー、タイトル、タブ……。これらを一つひとつ個別のプログラムとして記述するのをやめ、すべて「フォームを構成する一連のリソース（定義情報）」としてデータ化したのです。

こうして、画面そのものを個別プログラミングする必要は一切なくなりました。

リソースとその属性情報さえDBに定義しておけば、Frameworkがそれを自動で読み込み、画面として動的にレンダリングする。

本質を抽象化することでコード量を激減させる——まさに「単純化の最適化」の真骨頂でした。

結果としてプログラムは極限までシンプルになり、バグの発生率も圧倒的に激減しました。

2005年、このFrameworkのプロトタイプが完成しました。

その絶大な成果は、現在のSimLex ERPに色濃く受け継がれています。

現在、SimLex ERPには約1,200もの画面が存在します。しかし、それらを個別にプログラミングしたわけではありません。わずか8種類の共通画面テンプレートをFramework上で組み合わせることによって、1,200画面すべてを完璧に制御・駆動させているのです。

大量の画面を一つずつ作るのではなく、「画面を自動生成するための仕組み（エンジン）」を作る。これこそが、私たちが到達したFrameworkの本質でした。

2005年に完成したこのFrameworkは、その後も進化を重ね、2026年現在に至るまでSimLexの強固なコアとして稼働し続けています。定義データベースを書き換えるだけで、特定の業界向けソフトにとどまらず、あらゆる業務アプリケーションへと柔軟に変化させることができるのです。

後から知ったことですが、現代ITの先端分野ではこうしたアーキテクチャを「Meta-Driven Application Platform（メタデータ駆動型アプリケーション基盤）」と呼びます。

しかし当時の私は、そんな最先端の用語など知る由もありませんでした。

ただひたすら「どうすれば特定プログラマーの頭の中に依存しない、美しく堅牢なソフトウェアを作れるのか」を現場で真摯に考え抜いた結果、自然とこの構造へとたどり着いたのです。

こうして振り返ると、第1章から続く私のシステム思想には、一本のブレない軸が貫かれていることがわかります。

• 第1章（ペトリネット）： 現実世界を最小限の本質要素で表現する

• 第2章（設備設計）： 階層の視座を変え、制約条件を変更可能にする

• 第3章（MRP・ER図）： 生産活動を情報の構造体としてモデル化する

• 第4章（スケジューラ）： 複雑な生産条件を品質特性へ抽象化する

• 第5章（Framework）： 画面や機能を抽象化し、定義データからシステムを自動生成する

すべては同じベクトルを向いていました。

「複雑な現実を、そのまま泥臭いコードとして持ち込まない。本質を抽出し、抽象化し、最小限の美しい構造で表現する」

これこそが、私にとっての「単純化の最適化」に他なりませんでした。

しかし——これほどの革新的なFrameworkが完成したにもかかわらず、根本的な課題は依然として解決していませんでした。

APS（高度計画スケジューラ）が抱える構造的な限界は、強固な基盤を作ったからといって消えてくれるわけではなかったのです。

MRPとスケジューラを完全融合させた。現場の複雑な条件も抽象化して美しく扱えるようにした。さらには、開発と保守を劇的に効率化するFrameworkまで完成させた。

それでもなお、私が理想とする「真の生産管理」には届いていない——。

「では、一体どうすればいいのか？」

ここで私は、これまで積み上げてきた実績や既存のフレームワークを一切捨て去り、「完全なるゼロベースから、もう一度設計し直す」という、人生最大とも言える決断を下すことになるのです。

第6章　タイへの移住で確信した「世界標準」の思い

APS（高度計画スケジューラ）の限界にぶつかり、それを克服するための共通基盤「開発Framework」まで自作した——。

それでもなお、私の胸の中には「これだ」という決定的な手応えがまだ届いていませんでした。

「一度、すべてをゼロベースにリセットして考え直す必要があるのではないか」

しかし、ここで一つ大きな懸念が頭をよぎりました。

「このまま日本に留まってシステムを作っても、これまでの延長線上にある『従来の日本のシステム』と同じものしか作れないのではないか？」

当時の私から見ると、日本の生産管理システムはどうしても「生産計画」と「工程管理」の2点に極端に偏重しているように思えました。

もちろん、それらが製造業において重要であることは言うまでもありません。しかし、生産管理という営みはそれだけで完結するものではありません。

【販売 ➔ 購買 ➔ 生産計画 ➔ 製造 ➔ 実績 ➔ 在庫 ➔ 原価】

これらすべてのプロセスが一つの太いデータ構造として繋がって初めて、真の「生産管理」と呼べるはずなのです。

幸いなことに、私は以前からタイに子会社を所有しており、タイにおける製造業の現場の実情をある程度把握していました。

そこで、「日本仕様のシステムをそのままタイへ持ち込んでローカライズする」という発想を完全に捨て去ることにしました。

「何の制約もない新しい地で、生産管理という仕組みそのものをゼロから作り直してみよう」

そう決意した私は、タイへの移住という大きな決断を下したのです。タイを選んだ理由はいくつもありました。

• システムを完全ゼロベースで構築・検証する開発環境として最適だったこと

• 多くの日系製造業が進出しており、巨大な現場ニーズが存在していたこと

• 日本と異なり、新興ベンチャーであっても単独で市場に挑戦できる開かれた環境があったこと

• 大手ITベンダーやコンサルティング会社の既存概念・利権の影響を受けにくかったこと

• タイ人の持つ「道徳観」や人柄が、自分の価値観に非常にしっくり馴染んでいたこと

こうして2012年8月、私はタイへ移住し、現地で新たな会社を設立しました。

スタートはごく少人数の小さなチームでした。

移住直後から朝から夕方まで開発に没頭し、わずか4ヶ月後の2012年12月には、早くも新しい生産管理システムのプロトタイプを完成させました。

開発で頭が強烈に疲労してくると、気分転換によく街のビリヤード場へ通いました。

タイではビリヤードが非常に盛んで、そこにはタイ人だけでなく、欧米人やインド人など世界各国から集まった多様な人々で溢れていました。

ビリヤードのゲームそのものも魅力的でしたが、そこで国籍を超えた様々な友人たちができたことは、私にとって予期せぬ大きな財産となりました。彼らと日常的に会話を交わすことで、教科書には載っていない「生の英語」や異文化の思考パターンを皮膚感覚で吸収することができたのです。

そこで、私は一つの重要な真理に思い至りました。

「国籍や人種、文化が違っても、人間の根本的な感情や思考回路はそれほど変わらない」

強気になるときもあれば、弱気になるときもある。窮地に陥ればビビりもする。ゲームに勝てば心から嬉しいし、負ければ心底悔しい。

人間そのものの本質は、日本人であっても欧米人であっても大差はないのだ——。この直感的な気づきは、後に私が「世界標準」という概念を定義する上で、極めて重要なマインドセットとなりました。

また、この時期には現地のある機械メーカーの保守サポートやシステム開発も手がけていました。

現場でタイ人のスタッフから直接話を聞き、彼らの実際の業務の進め方を観察していると、日本と海外の「現場の思想の違い」が明確に見えてきました。

「日本のやり方をそのままタイ向けにマイナーチェンジするだけでは、グローバル市場で勝ち残れるはずがない。今必要なのは『日本式』でも『タイ式』でもない。世界中のどの現場に持っていっても通用する、圧倒的な『世界標準』の生産管理システムを作ることだ」

私は自らの目指すべきゴールを「世界標準」へと定めました。

しかし、ここで即座に次の巨大な問いが立ちはだかりました。

「そもそも、『世界標準』とは一体何なのだろうか？」

世界中の企業の無茶な要求をすべてシステムに取り込むことなのか？

国ごとに異なる曖昧なローカルルールをすべてシステムの中に抱え込むことなのか？

機能をとにかく大量に実装し、巨大なシステムにすることなのか？

冷静に考えてみれば、「世界標準」という甘美な言葉だけでは何一つ具体像が見えてきません。

暗中模索の中で、私は再び第3章で出会った『師の教え』——すなわちMRPの原点へと立ち返りました。

師から学んだのは、極限まで削ぎ落とされた美しい生産管理の基本プロセスでした。

【受注 ➔ 基準日程生産計画 ➔ MRP ➔ 購入品発注 ➔ 生産指示 ➔ 実績管理 ➔ 在庫管理】

「この幹となるプロセスの整合性を、何ひとつ誤魔化すことなく、徹底的に美しく、正しく構築すること。これこそが、私の追い求める『世界標準』の正体なのではないか——」

私は確信しました。

世界標準とは、世界中の雑多な要求を何でもかんでも呑み込んでシステムを肥大化させることではありません。

「生産管理という営みの本質を、余計な装飾を一切削ぎ落とし、正しいデータ構造として完璧に構築すること」

それこそが、私が辿り着いた唯一無二の答えでした。

• 第1章（ペトリネット）： 現実の本質を最小限の要素でモデル化する

• 第2章（制約条件）： 視座を上げ、制約を変更可能にする

• 第3章（MRP）： データの流れる本質的な基本プロセスを遵守する

• 第4章（単純化の最適化）： 複雑な条件を抽象化し、最小限のマスタで制御する

• 第5章（Framework）： 定義情報からシステムを動動的に生成する

そして2012年、タイという新しい地で、これまでの思考と技術のすべてを一つの巨大な構造体として組み直す準備が整いました。

「真の世界標準 ERP をつくる」

この揺るぎない確信を胸に、SimLex ERPの本格的な開発の幕が切って落とされたのです。

第7章　販売管理・生産管理・会計をゼロベースから開発する

まったくのゼロベースからの開発でしたが、私の頭の中ではすでに構想が固まっていました。あとは、それをコードに落とし込んでいくだけでした。

そう言い切れたのも、すでに強固な自社Frameworkが存在していたからです。

画面設計においては、すべての画面をわずか8種類の画面テンプレートだけで構築することを決めていました。画面ごとに個別のプログラムを一から組むのではなく、Frameworkを共通基盤とし、その上に販売管理、生産管理、会計を積み上げていくアプローチです。

開発をスタートするにあたり、徹底して遵守する基本方針を定めました。

• マスタデータの連携：Framework標準のExcelインターフェイスにより、自由自在にインポート・エクスポートができること

• トランザクションデータの連携：受注データ等もすべてExcel・CSVでインポート・エクスポートできること

• UI構造の標準化：受注処理、請求処理、発注（P/O）処理など、すべての業務画面を「ヘッダー・明細形式」で統一すること

• データ整合性の担保：一度登録されたトランザクションデータは物理削除を禁止し、取消が必要な場合はすべて「赤伝（キャンセル処理）」で履歴を残すこと

• 高速なハイブリッドMRP：製番管理とMRP型管理のハイブリッドに対応し、すべての所要量計算をインメモリ（メモリー上）で超高速に処理すること

• ノンプログラミング帳票：Frameworkの標準機能であるExcel帳票を採用し、プログラムレスで柔軟に帳票を作成・変更できること

この設計思想を軸に据え、「4か月後にプロトタイプを完成させる」という目標を掲げました。

在庫の「Single Source of Truth」

特に在庫管理の設計においてこだわったのが、すべての在庫の動きを「受払台帳」という単一のトランザクションに集約するコンセプトでした。

場所別在庫、品目別在庫、ロット別在庫、Stock Cardなど、業務上求められる多様な在庫ビューは、個別のテーブルで二重三重に持つのではなく、すべて発生源である受払台帳から動的に集計して生成します。

当時はまだ「Single Source of Truth（信頼できる唯一の情報源）」という言葉を明確に意識していたわけではありませんでした。しかし、振り返ってみれば、これこそがSimLexにおける「唯一の真実」の原点だったのです。

「在庫」という結果の数値をあちこちに分散して保持するのではなく、事実として発生した「受払ログ」を一箇所に集約し、そこからあらゆる情報へと展開する――この設計思想は、その後のSimLex ERP全体の根幹を形作ることになります。

最初の導入実績と、会計システムへの挑戦

プロトタイプが完成すると、すぐに営業活動へと打って出ました。 大手電機機器メーカーやコンサルティングファームなどを駆け回り、SimLexの生産管理システムを泥臭く提案して回りました。

その甲斐あって、大手電機機器メーカー経由で、東証一部（当時）上場企業タイ現地法人での採用を勝ち取ることができました。この案件の受注は、立ち上げ期における会社の資金繰りを大きく支えてくれる貴重な一歩となりました（同社には生産管理システムを導入いただき、現在に至るまで長くご使用いただいています）。

そして、あるコンサルティング会社への提案が、次なる大きな転機をもたらします。

「SimLexで、会計システムも作れませんか？」

そう声をかけられたとき、私は間髪入れずに答えました。

「分かりました。作れます」

二つ返事で引き受けたものの、正直なところ、経営者として貸借対照表（B/S）や損益計算書（P/L）を読むことはできても、会計システム内部の仕訳ロジックや元帳生成の仕組みまで深く精通していたわけではありませんでした。

それでも、「やると決めたら、何が何でもやり切る」。それが私の流儀でした。

国境の壁を越えるローカライズ開発

そこから会計システムの開発に没頭し、2013年5月には早くもプロトタイプを完成させました。しかし、本当の戦いはここからでした。

当時のタイ市場には、すでに現地ローカルの会計パッケージが深く浸透していました。後発であるSimLexは、現場の会計担当者から「あの機能がない」「この帳票が出ない」と次々に厳しいフィードバックを突きつけられたのです。

一つひとつの要件を検証し、不足している機能を猛スピードで実装していきました。最終的に会計システムとして納得のいく形に仕上がったのは、半年以上が経過した2013年12月のことでした。

開発において特に頭を悩ませたのが、「柔軟な採番管理」と「東南アジア各国の会計基準への適応」でした。

海外の商習慣では、伝票番号の採番ルールが日本と比べて極めて多様です。

• IVyyyyMMxxx（毎月連番をリセット）

• yyyyxxxxxx（年単位でリセット）

• [顧客コード]＋yyyyMMxxx（顧客ごとに採番体系を分ける）

これらに柔軟に対応するため、採番ルールそのものをマスタ設定化し、各種ドキュメントを発行する際に自由に選択・適用できる仕組みを構築しました。

また、インドネシアの会計基準では「税務申告（VAT）用の公定為替レート」と「商取引（売掛・買掛）用の実勢為替レート」を明確に使い分けなければならないなど、タイの税務とも異なる細かなローカルルールが存在しました。こうした各国の差異にも、愚直に一つずつ対応を重ねていきました。

ERPとしての完全統合、そして次なる壁

こうして完成した会計システムは、生産管理システムとER図のレベルで完全に結合しました。

販売管理、生産管理、会計がそれぞれ孤立したサイロ型システムではなく、単一のデータモデルとして緊密に整合する構造を手に入れたのです。

会計側の受払台帳も、独立して二重入力させるのではなく、データの発生源である生産管理のトランザクションからダイレクトに自動生成されます。ここでも、Single Source of Truthの思想が貫かれました。

「一つの事実を複数のシステムで二重持ちせず、発生源データを唯一の真実として必要な帳票や仕訳へ展開していく」

この思想によって、販売・生産・在庫・会計が一本の太い幹として貫通し、現在のSimLex ERPの骨格がここに完成しました。

しかし、ERPとして真の完成を迎えるには、どうしても越えなければならない最後の巨大な壁が残されていました。

それが、「原価管理」です。

当時の原価計算機能は、まだ簡易的なレベルにとどまっていました。しかし、受払から会計までが完全に一元化された以上、原価計算だけを簡易的な仕組みのまま放置するわけにはいきません。生産と会計が直結したからこそ、原価管理もまた同じ思想のもとで抜本的に再設計しなければならない――。

私は、原価管理エンジンの大規模なフルモデルチェンジという、次なる挑戦へと突き動かされていくことになります。

第8章　原価管理の開発で生まれた「工程チャージ」への疑問

SimLex ERPの初期バージョンに搭載していた原価管理は、いわゆる「簡易的な原価管理」でした。

工程マスタにあらかじめ「工程チャージ（時間当たりの加工費レート）」を登録しておき、工程別・品目別の標準単価を計算して積み上げていく仕組みです。一般的なシステム要件としては、これで十分だと考えられていました。

しかし開発を進める中で、私の頭の中に一つの巨大な疑問が浮かび上がってきたのです。

ユーザー企業に「この工程チャージは、いつ、どのように算出したものですか？」と尋ねてみると、返ってくるのは耳を疑うような回答ばかりでした。

「工場の設立時に決めた数値をずっと使っています」

「日本の本社から指示された金額をそのまま入れています」

すべての企業がそうだとは言いませんが、多くの現場で現実の製造コストから大きくかけ離れた数値がそのまま使われていたのです。

そもそも工程チャージというものは、会計と生産の両方に精通した特定の担当者が、Excelを駆使して複雑に集計・計算しているのが実態です。

「なぜ、これほど曖昧で属人化しやすい『工程チャージ』という概念が存在するのだろうか？」

深く考察した結果、一つの構造的な原因に行き着きました。

日本の企業において「生産管理」と「経理・会計」が縦割り組織になっており、その断絶した二つの組織をつなぐための“便宜上のバッファー”として作り出されたのが工程チャージだったのです。そして、その計算プロセスは特定個人の頭の中にブラックボックス化されていました。

工程チャージが一度もメンテナンスされなければ、過去の古い基準で原価を計算し続けることになります。それでは経営者が正しい判断を下せるはずがありません。

何より、工程チャージという固定化された数値を使っている限り、「生産数量が減ったら固定費が分散されず、製品1個当たりの原価が上がる」という当たり前のコスト動態すら見えなくなってしまうのです。

ここで私は、第1章で出会った「現実の世界を、いかに少ない本質的な要素だけでモデル化できるか」という原点の問いに立ち戻りました。

原価を構成する「本質的な要素」とは一体何でしょうか？

削ぎ落として残るのは、以下の2つしかありません。

1. 会計から出力される「実際の経費データ」

2. 受払台帳に記録された「数量・生産時間・購入単価データ」

そう——本質的な原価の構成要素の中に、「工程チャージ」などというものは最初から存在しないのです。

「であれば、会計の経費データと、受払台帳のデータをダイレクトにつないで原価計算すればいいのではないか」

極めて合理的で、自然なロジックが導き出されました。

世界的な大手ERPパッケージでさえ、原価計算には工程チャージを採用しています。しかし「本質」から考えれば、私のアプローチこそが絶対に正しいという揺るぎない確信がありました。こうして、常識を覆す新しい原価管理エンジンの開発が始まりました。

実際の開発で最も苦労したのは、「会計の部門」と「工場の工程」が1対1で一致しないという問題でした。

この課題に対しては、勘定科目データを各工程へと適正に配賦する「配賦マスタ」を新設することで解決しました。共通費、直接費、間接費、減価償却費といった勘定科目データを工程と紐付け、自動で正確な工程経費を算出するロジックを組み込んだのです。

これまで特定担当者の頭の中に隠されていた配賦ルールを「マスタ化」したことで、誰でも原価管理の仕組みを透明に理解できるようになりました。

こうして、SimLex ERPの真の原価管理システムが完成しました。

標準原価、実際原価、さらには予算原価の管理までを完璧に実現したのです。SimLex ERPの世界において、従来の「工程チャージ」とは最初から入力するものではなく、計算の過程で自動的に導き出される単なる「結果」に過ぎなくなりました。

このロジックの正しさは、すぐに現実の成果として証明されました。

iPhoneの精密部品を製造する大手メーカーにSimLex ERPの原価管理を導入していただいた際、計算された原価データが見事に日本の大手会計監査法人の厳格な監査に合格したのです。大手ERPの常識を疑い、本質から作り上げたロジックが世界基準で通じた瞬間でした。

ただし、システムとしては完成したものの、現地ではまったく別の角度から新たな壁にぶつかることになります。

タイのローカル会計監査人（Auditor）には、「標準原価・実際原価・差異分析」という高度な管理会計の概念自体が浸透しておらず、「実際原価のみで管理すべきだ」という実務習慣が根強く残っていたのです。

歴史的背景から、日本とタイでは原価に対する考え方や発展のプロセスが大きく異なります。

システムとしてのロジックは完成したものの、「国ごとの会計思想の違いにどう向き合っていくか」という新たな運用上の課題を残すことになりました。

しかし、販売・生産・会計、そして原価管理までが「Single Resource of Truth（唯一の真実）」の思想のもとで一本の太い幹として完璧につながった瞬間でした。