多くの製造現場を見て回ると、高度な原価計算の仕組みが整っていることに気づく。機械稼働率は小数点以下まで追跡される。サイクルタイムは秒単位で測定される。材料ロスはオンス単位まで算出される。製造業は本質的に、「重要なものを測る」ことに規律正しい。
しかし、ほぼすべての工場の現場で、誰の目にも触れながら見過ごされているコストがある。損益計算書（P&L）に表れることはめったになく、オペレーションレビューで独立した項目として扱われることもない。それでも、あらゆるシフト、あらゆるプログラマー、あらゆる日々の中で静かに累積していく。ソフトウェア複雑性のコストだ。
そして多くの現場にとって、それは無視できない規模である。
誰も数えていない摩擦
典型的な1日を通じて、CNCプログラマーが実際に何をしているか考えてみてほしい。作業内容によって挙動が異なるインターフェースを行き来する。わずかなジオメトリの調整を行い、それがうまくいったかを確認するまで、ツールパスの再生成サイクルを丸ごと待つ。何度も参照してきたパラメータを見つけるためにドキュメントを探し回る。必要な編集が既存の構造では不可能だったため、ツールパスを最初から作り直す。
こうしたことは、標準的な運用報告の「生産性損失」としては表れない。ただ仕事がそうやって進むというだけであり、熟練プログラマーは回避の仕方を身につけ、新人はそれが当たり前だと受け入れる。
だが、その「背景ノイズ」は積み上がる。5分の再生成待ちが、1シフト中に12回繰り返されれば、プログラミング時間は1時間失われる。それをチーム全体で、さらに1年分に広げれば、意味のあるキャパシティが、ツールそのものによって静かに消費されていることになる。
製造業は数十年にわたり、この方程式の「機械側」を最適化してきた。一方で、ソフトウェアに起因する摩擦は、概ね検証されないまま放置されてきた。
「複雑性」が実際に生むコスト
製造業におけるソフトウェア複雑性にはいくつかの形があり、それぞれが独自の生産性税をもたらす。
• 整合しないインターフェース間のコンテキストスイッチは、プログラマーに、作業の進行に合わせて頭のギアを切り替えることを強いる。異なる作業で異なるロジック、異なる操作パターン、異なる慣習が用いられていると、移行のたびに認知的なオーバーヘッドが発生する。熟練プログラマーは適応できるが、適応にも時間はかかるし、システムを学ぶ人にとっての障壁となり、習熟のスピードを落とす。
• 調整→再生成→待機のサイクルは、CNC部品のプログラミング経験者にとって、おそらく最もなじみ深い摩擦の形である。パラメータを変える、再計算を実行し、待つ。深さを変える、再計算を実行し、待つ。複雑な部品では、その待ち時間が積み重なる。プログラマーのリズムは繰り返し断ち切られ、意図と結果の間に生じる累積遅延は、誰もわざわざ測ろうとしないほど長くなる。
• ドキュメント依存は、専門性に対する隠れた課税である。プログラマーが、以前にも必要とした情報を得るために、ワークフローを離れてマニュアルやヘルプシステムを探し回らねばならない状況が常態化しているなら、それはソフトウェアが「必要な場所に知識を提示していない」ことのサインだ。加えて、経験の浅いユーザーは不利が複利で増える。彼らほどドキュメントを必要とする一方で、それを探すためにワークフローを中断する影響は、より大きいからだ。
• ツールパスの作り直しは、最も回復しにくいがゆえに、最も高コストな摩擦である。設計変更により編集ではなく作り直しが必要になると、時間だけでなく、作業そのものを失う。プログラマーは、仕事の要件ゆえではなく、ツールの都合によって最初からやり直さねばならない。
摩擦から第一原理へ
ソフトウェア企業が、摩擦を「機能要望のバックログ項目」ではなく、あらゆる意思決定を形づくる設計上の制約として、第一級の問題として扱うとしたら、どのような姿になるだろうか。
当社では、この問いが、CAMソフトウェアのあるべき動き方に関する長年の前提を見直すきっかけになった。中核となる前提は明快だ。複雑性はコストを生む。そしてコストは、工学的に排除されるべきである。
その後に続いた設計原則は、複雑なものではなかった。ワークフロー全体で一貫した挙動を実現すれば、プログラマーは一度習熟した流れを、すべての作業にわたって活用できる。編集や更新をより賢く扱うことで、小さな変更が全面的な再計算サイクルへ連鎖することを防げる。
どれも目新しい発想ではない。どの領域であれ、優れたソフトウェア設計を駆動する原則と同じだ。注目すべきは、日々の使い勝手よりも深い機能性が歴史的に優先されてきたCAMという領域で、こうした原則が体系的に適用されることがいかに少ないかという点である。
従来の前提に異議を唱え、新たな設計原則を打ち立てることで、摩擦の低減を、点在する改善の寄せ集めではなく、一貫した設計哲学として扱えるようになった。
これまで無視してきたものを測るという提案
ここで述べたことは抽象論ではない。この摩擦は現実に存在し、CNC部品を生業としてプログラムしている人なら誰もが身に覚えがあり、測ろうと思えば測定可能である。
私が製造業のリーダーに投げかけたいのは、この点だ。機械の稼働率や歩留まりに適用してきたのと同じ規律は、ソフトウェアの生産性にも適用できる。プログラマーが、実は自動化でき、また自動化されるべきプログラミング作業にどれだけの時間を費やしているかを追跡してほしい。設計変更が、編集ではなくツールパスの作り直しをどれほどの頻度で要求するかを数えてほしい。新人プログラマーが自立して生産的に働けるようになるまでに、どれだけの時間がかかるかを問うてほしい。
これらは定量化できるコストである。製造の他のあらゆる側面を効率化してきたのと同じ種類の、焦点を絞ったエンジニアリングの注意によって改善し得る。ソフトウェア複雑性を「避けがたい生活の事実」ではなくコストとして扱い始めるメーカーは、おそらく、失っていることすら気づいていなかった回復可能なキャパシティを見いだすだろう。
この問題を解決するうえで、ツールはより良くなってきている。問われるのは、業界がそれに気づくほど十分に注意を払っているかどうかである。
