私（寺田 @u_1roh）が携わっているプロジェクトについて。
ここでは「金属加工品の多品種少量生産」という文脈の話をします。具体的には、例えば板金加工や旋盤やフライス盤による機械加工などの受注生産をイメージして下さい。
CAD/CAMの理想と現実
製造業では、CADやCAMといったソフトウェアが使われています。この2つは次の役割分担をしています。
- CADは、製品の形状や仕様を定義する。
- CAMは、製品仕様を満たす加工プログラムを生成する。
この役割分担の理想を突き詰めると、次のようになるでしょう。
- CADは、どんな複雑な形状でも表現できる高い自由度を持ち、実際に用いられる加工法を仮定することなく、製品の仕様を表現する。
- CAMは、どんな複雑な形状でも受け入れることができ、寸法公差や幾何公差を反映した加工プログラムを生成できる。
CAD界隈は、この理想に向かって進化を推し進めようとしているようです。しかしこの理想は、実現には相当なハードルがあるのではないかと私は予想しています。実際、3DCADに付与されたPMI（Product Manufacturing Information; 寸法公差や幾何公差などのこと）を下流工程に自動連携するというのは、語られてはいるもののまだ普及しているとはいい難いでしょう。
事実、弊社キャディでは、見積もりの段階で3DCADのデータを受け取ることはほとんどありません。多くのお客様は2D図面（PDF）で見積もり依頼や発注をされます。CAD業界が喧伝する高邁な理想をよそに、多品種少量生産の現実は「図面」で回っています。
Worse Is Better で現実に向き合う
しかし一方で、図面で設計情報を流通させている限り、この業界にブレークスルーをもたらすことは難しいことも事実です。PDFの図面は machine readable ではなく、「画像」という非構造化データです。これを読み取るには人の目が必要になる場面が多く、DXを阻む大きな壁として立ちはだかっています。
この状況を、Worse Is Better の哲学で打開したい、と私は考えています。
「正しいこと」は時として、描かれた理想像は美しくとも、それを実際に実装するコストが途方もなく高く付くことがあります。CAD業界が目指している理想は、まさにこの隘路にはまり込んでいるように私には思えます。少なくとも、彼らの描く理想が多品種少量生産の業界まで「降りて」くるまで長い年月がかかるでしょう。
こういった「正しいこと」の追求に対するアンチテーゼが Worse Is Better の考え方です。t_wada さんのツイートが非常に端的でわかりやすいので引用致します。
MO CAD 構想
現在、私のチームでは独自のCADフォーマットを作るプロジェクトに取り組んでいます。
- 私たちのCADは、数学的な美しさは犠牲にして、形状表現を加工ドメインの特性に合わせて実用上十分な範囲に制限し、代わりに寸法公差や幾何公差といった加工指示を重視したものにする。
- 下流工程のシステムは、上記のように制限された形状表現のみを受け取るものとすることで、形状認識のアルゴリズム開発の実装コストを低減させる。
このコンセプトを私たちは、Manufacturing Oriented CAD、略して MO CAD と呼んでいます。
MO CADの価値の中核を成すのは、3Dグラフィックスでもモデリング機能でもなく、データモデルです。純粋なCADでもなく、純粋なCAMでもなく、「製造に歩み寄ったCAD」という何とも中途半端な立ち位置のデータモデルを設計する必要があります。数学的な美しさや完全さは犠牲にして、代わりに下流システムの実装のしやすさに配慮し、妥協にまみれたデータモデルを設計しています。お世辞にも美しいとはいい難いものですが、「しかしこのほうが better なんだ」という信念のもとに実装を進めています。
これはつまり、Domain Specific なデータモデルです。フライス加工品のためには、フライス加工という加工ドメインに特化したデータモデルを作ります。加工ドメインごとにデータモデルが必要になるので一見ハイカロリーに思えますが、実際にはこの割り切りによって下流システムの実装コストが低減されるので、総じて見れば低コストで済むというのが私が持っている見立てです。
製造を指向すると、形状の自由度は制限できる
製造を指向すると、自然と形状は制限されます。これが MO CAD 構想の根拠になっています。
冒頭で述べたCADとCAMの分担は、顧客企業（発注側）と加工会社（受注側）の役割分担とも似ています。
- 顧客企業は、製品の形状や仕様を定義する
- 加工会社は、顧客が定義した製品仕様を満たすものを製造する
しかし、コトはそれほど単純ではありません。
加工が困難な形状を設計してしまうと、現実的なコストで製造できないことになります。ですから、顧客企業は製造のしやすさに配慮した設計をします。機能要件を満たしつつ、加工にも配慮してコストダウンを図るのが設計者の腕の見せ所です。
つまり、CADシステムの思想がどうであれ、実際には製品は設計の段階から加工方法がある程度想定されています。設計という行為は本質的に Manufacturing Oriented であるといえるかもしれません。
その結果、実際に設計される製品形状は、加工のしやすいシンプルな形状に収斂します。フライス加工品であれば、直方体のブロックから削り出しやすい形状になります。それらは、平面と円筒面のみから構成され、角の多くは直角です。
つまり、データモデルとして表現可能な形状が上記のように制限されたとしても、実用上は問題ありません。それよりも、下流工程を自動化するために必要になる演算を実装しやすくすることが重要です。
見積もりを自動化する
MO CAD データの活用先として、見積もりの自動化という課題を挙げます。
フライス加工の加工コストは、例えば切削によって除去される体積であったり、段替えの回数であったり、様々なパラメータによって決まります。見積もりを自動計算するためには、CADデータからこれらのパラメータを自動で推論しなくてはなりません。
一般的な3DCADデータは B-rep と呼ばれるデータ構造で表現されており、非常に柔軟で高い表現力を持っています。これはCAD側にとっては自由度が高い一方で、そのデータを受け取る側は負担を強いられます。B-rep データから段替え回数を推論するのは、おそらく相当に困難でしょう。対処しきれないほどの例外ケースを回避することに追われて、例外処理だらけの読むに耐えないプログラムになってしまうと予想されます。
こういった事態を回避するために、見積もりの自動化で必要になる形状演算が比較的容易になるようなデータモデルを考えていきます。
※ B-rep については例えば私のQiitaをご参照下さい。 3D CAD の内側をちょっと覗いてみませんか - Qiita
俺は B-rep をやめるぞーーッ！
具体的なデータモデルをここで詳細に述べることはできませんが、アイディアの一端を軽くご紹介します。
フライス加工というのは除去加工です。まず直方体の「母材」があり、そこから切削によって体積を除去していくことによって製品形状を得ます。この加工の実態をそのまま模したようなデータモデル、つまり引き算しかないCSG表現のようなモデルが、アイディアの核となっています。
これはつまり、3DCAD の「定石」である B-rep を捨てることを意味します。これは勇気の要る判断ですし、この判断が正しいかどうかはこれから検証されていくことになるでしょう。
しかし、3DCADが誕生して40年以上の年月が経過にしているにも関わらず、この業界は未だに図面で回っています。この事実がまさに、「3DCADの定石」が業界のニーズにマッチしていないことの証左ではないでしょうか。
常識に囚われない、大胆な判断が必要だ、と考えています。
まずはドッグフーディング
少なくとも最初の想定ユーザーは、キャディ自身です。
お客様から図面を頂いたらまず最初に、MO CAD データに変換するオペレーションを社内で回す想定です。これにより、後段のあらゆる処理に対して自動化への道が拓けるので、トータルで見るとオペレーションコストが大幅に下げられることが期待できます。
もちろん、将来はお客様に直接使って頂けたら嬉しいですね！ ですが、やはり最初はドッグフーディングから始めるべきでしょう。
見込める効果は、いわゆるフロントローディングです。
フロントローディングというのは、雑にいうと「前工程で頑張っておくと後工程がめっちゃ楽になるよ理論」ですね。前工程でリッチな情報入力を頑張っておくと、後工程が自動化されたり非常にスムーズになったりして嬉しいというやつです。
これの最大の嬉しさは、「問題がより早い段階で顕在化すること」です。
従来は後工程になってみないと発覚しなかった問題が、フロントローディングをするともっと早い段階で顕在化するようになります。早い段階で顕在化すれば、早い段階でお客様にフィードバックしたり擦り合わせたりできます。「納期直前で問題発覚、緊急電話と突貫工事のドタバタ劇」みたいなハレーションを事前に防ぐことが出来ます。
まずはキャディ社内でフロントローディングを実現させることで、QCD (Quality, Cost, Delivery) を更に向上し、受発注事業を通じてお客様に価値を届けることを目指します。
技術スタック
ブラウザで動く Web アプリケーションとして作っています。
- front-end
- TypeScript
- React, Vite, Nest.js(BFF)
- Three.js
- back-end
- データモデルのスキーマ定義
- F#
弊社はかなり Rust を推しており、本プロジェクトでもご多分に洩れず Rust を利用しています。私も大好きな言語です。
この中では F# が異彩を放っているでしょう。F# は Microsoft の .NET で動く関数型言語です。しかし Windows を使っているわけではなく、.NET Core を使って Linux の上で動かしています。
MO CAD データのスキーマは F# を用いて定義されています。F# は、Domain Modeling Made Functional というDDDの書籍でも使われているように、データモデルを簡潔に記述できる言語です。独自開発中のライブラリにより、F# で定義された型をリフレクションを使って動的に読み取り、Rust と TypeScript と Python の型をコード生成できるようにしています。これにより、F# で定義されたスキーマに沿って複数の言語で JSON のシリアライズ/デシリアライズが可能になっています。（これについても、頃合いを見計らってご紹介できたらいいなと考えています。）
エンジニアを募集しています
一緒にこの夢を追って頂ける仲間を募集しています。以上の技術スタックを見て、すべてについて自信を持って「自分はこの開発で活躍できる」といえる方は、かなり限られることでしょう。多くのWebエンジニアはCADというものには馴染みがないかと思いますし、逆にCADの業界にいらっしゃる方はWebの開発に馴染みが薄いと思います。ですのでもちろん、すべての分野に明るいスーパーマンを募集しているわけではありません。各々のエキスパートが、互いをリスペクトしあい、協力しあって開発を進めていければ良いと考えています。
MO CAD に関わるエンジニアは、大きく次の2つに分けられそうです。
- MO CAD そのものを作っていくエンジニア
- MO CAD データを利用するアプリケーションやアルゴリズムを開発するエンジニア
「MO CAD そのものを作っていくエンジニア」として、この場で特に募集したいのは、次のような方です。
- フロントエンド開発において、例えば Three.js や WebGL など、グラフィックスのご経験がある方。特に、まさにCADソフトのように、マウス操作を伴ったインタラクティブなUXを開発した経験がある方。逆にいうと、複雑なシェーダーを駆使した美しいグラフィックスとか、大容量データのレンダリングといった技術は、現時点では必要としておりません。CADアプリケーションのUX開発に情熱を燃やせる方だと素晴らしいです。
- バックエンド側で、RustやC++を使って2D/3Dの幾何アルゴリズムを書ける方。もちろん、ズバリこの通りの経験をお持ちである必要はなく、そういったポテンシャルがある方。空間幾何を扱う基礎的な数学力や、グラフ構造を扱う基礎的なアルゴリズムなどが必要になります。
- MO CAD や関連するデータモデルのスキーマを設計できる方。加工ドメインや下流工程のオペレーションといったドメイン知識を積極的に獲得し、製品の形状表現と下流工程の処理をバランスさせたドメインモデリングをする必要があります。
同時に、「MO CAD データを利用するアプリケーションやアルゴリズムを開発するエンジニア」も必要になっていきます。次のような関連アプリケーションが考えられます。
- MO CAD データを管理するシステム。BOM や PDM/PLM といったドメインに明るい方が加わって頂けると非常に心強いです。
- MO CAD データから加工プロセスを推論するアルゴリズム。プロセスが推論できれば、加工時間も予測しやすくなり、原価計算にもつながっていきます。幾何的な計算処理が書けると同時に、加工プロセスへの理解が必要になります。
- 難加工を自動検出するアルゴリズム。加工が非常に難しい箇所、あるいは不可能な箇所があれば、これを自動で検出するというものです。こういった難加工が受注後になって見つかると、大きなトラブルに繋がりかねません。受注前の早い段階で素早く自動的に検出できれば、お客様と擦り合わせをしてトラブルを事前に防ぐことが出来ます。この開発もやはり、幾何計算アルゴリズムのスキルと加工への理解が必要になるでしょう。
本プロジェクトは、当然ながら、決して成功が約束されたプロジェクトではありません。まだまだ多くの不確実性が横たわっており、それらを一つ一つ潰していく必要があります。
そういった不確実性を含めて、大きなチャレンジに立ち向かうことを楽しめる方のご応募をお待ちしております！
「まずはカジュアルに話を聞いてみたい」という方は、こちらより面談をお申し込み下さい。 - 応募フォーム | JP-TECH-000.エンジニア・デザイナー：カジュアル面談 - キャディ株式会社
選考へのエントリーは下記サイトよりお願いします。
