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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 機械設計のレベル： 購入品（部品）を「制約条件」とし、それらをどう組み合わせて機械を作るかが「変更可能条件」になります。
  • ライン設計のレベル： 各設備を「制約条件」とし、それらをどう配置・連携させて必要なライン能力を出すかが「変更可能条件」になります。
  • 工場設計のレベル： 各ライン編成を「制約条件」とし、それらをどう組み合わせて工場全体を構成するかが「変更可能条件」になります。

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

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

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

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

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

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

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

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

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

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

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

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

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