CTOが「C++のトップ人材の過半数が所属する会社にする」と宣言したことで、ソフトウェア・エンジニア界隈で一躍話題になった「CADDi」。
C++のエヴァンジェリストとして有名な江添亮さんがテクニカルアドバイザーになったり、プログラミングコンテンストを主催したりと、スタートアップ企業の中でも圧倒的に強い技術へのこだわりが感じられます。
実は最近でも、まだ日本ではプロダクション採用している会社がほぼ無いであろう「Rust」を、主要な開発言語として採用したりと、かなり尖った技術選定が目立ちます。
今回アンドエンジニアでは、CADDiのCTO、小橋 昭文さんに、CADDiについてや、技術選定、エンジニア経営などについて、突撃インタビューを行いました！
「多品種少量」のペインをぶっ潰す
まず、CADDiがやっていることについて聞きたくて。 「CAD」から発注が出来るとは聞いてるんですが、いまいちピンとこなくて…。 具体的に何が出来るんですか？
CADDiが取り組んでいる課題は、ざっくり言うと「製造業の調達コストを下げる」です。 例えば、TOYOTAの車の生産だったら、それぞれの部品で数百万〜数千万のロットがある訳で、その部品毎に最適化・コスト削減を行うインセンティブが強いですよね。 数円でも安くするだけで、コストインパクトが大きいので、調達業務にリソースをかけられる。
でも、山手線の電車を作ろうと思ったら、必然的に超多品種少量になってしまう中で、それぞれの部品の発注に注力なんて出来ない。 こういった「多品種少量の製品における発注のペイン」を解決することに、CADDiは取り組んでいます。
その中の1つの取組みとして、ユーザが製品の「CAD」をアップロードすると、部品・加工方法・原価を自動的に算出し、見積もりができて、そこから発注も出来る「自動見積り」というプロダクトをリリースしています。
あぁ、なるほど。 「自動見積り」はCADDiさんのプロダクトの一つなんですね。
そうです。
3D版「SVG」をアップロードして「見積もり」を出す
ちなみに、自分は一介のWebエンジニアなので詳しくないのですが、「CAD」ってどのようなものなんですか？
そうですね…。 WebだとよくSVGファイル（Scalable Vector Graphics）を使用しますよね。 画像をベクタ方式で表現するので、どれだけ拡大してもボケない…。
アイコンやロゴなどでよく使用されていますね。
ざっくり言うと、その3D版で、STEPファイルというのがあって。 これがISO規格なので、どんなCADツールを使っていても出力できるようになっています。 これをブラウザでアップロードしてもらう、という感じですね。
なるほど！ そのSTEPファイルを元に、どんな工程が必要か計算して、最終的に見積もりを出す…と。 本当にそんなことできるんですか？
3DのCAD自体には、材質や塗装の情報は通常はない（一応入れることは出来る）ので、一緒に付随する情報も入力してもらいます。 例えば、「穴を開ける」という工程が必要だとして、CADから板厚や穴のサイズは分かります。 後は、そういった付随情報から「ドリルで開けるのか」「レーザーで開けるのか」「水流ジェットで開けるのか」などを判断する形ですね。
また、ジェットエンジンと、水道の蛇口だったら、同じ「5mmの穴を開ける」というタスクでも要求される精度が異なりますよね。 この誤差の許容範囲を「公差」というんですが、「公差」のパターンはJIS規格で定められています。 これも工程の選出に非常に影響するので、一緒に入力してもらっています。
「Rust」は採用にむしろポジティブ
現在はRustとTypeScriptを中心に開発を行っているんですよね。 Rust、僕も少しだけ触ったことがあるんですが、やっぱり「所有権」や「ライフタイム」の概念がとっつきにくいですよね（笑） 世の中に開発者も少ないだろうし、正直、採用も大変になると思うんですけど、どうでしょうか？
Rustを採用したのは、元々使っていたC++がWebサーバを書くのが苦手で、そこの部分でC++と共存させつつ使いやすかった、という感じです。 採用に関しては、実は、むしろポジティブだと考えていて。
ポジティブ！？
え〜っと…。 そもそも、CADDiで求めているエンジニアというのは、特定の技術・言語・フレームワークにこだわる人間じゃなくて。 常に様々な技術をキャッチアップしていて、その中から目的のために手段を選べる人。
例えば、弊社は元々フロントエンドはVueを使っていたんですが、Reactに乗り換えました。 これも、その当時はまだ、VueよりReactの方がTypeScriptでの開発がやりやすかった、というのがあって。 弊社はドメインが複雑なので、型の補助がないとヒューマン・エラーによるバグを招きやすい。 そういった弊社固有の事情もあって、TypeScript/Reactを採用しました。 「Vue大好き！」「React大好き！」ではこの判断は出来ないですよね。
「目的のためには、特定の技術に固執しない」のが大事ということですね。 でもそれが、Rustと何の関係が…？
今のRustって、エンジニアの中でも一部の人しか追いかけてないフェーズだと思うんですよ。 その状況で「Rustを推している弊社」に興味を持ってくれる人間は、技術に幅広く興味があり、キャッチアップしている人間が多い。 「技術の幅が広いエンジニアを抽出するフィルターになっている」というか。
基礎能力と経験に裏打ちされた「学習速度」
なるほど…！ ただ、それでも「そもそも世の中に開発者が少ない」という問題が残りそうだと思うのですが…？
世の中にRust開発者がいないというのはその通りなんですが…。 実は、「元々RustをやっていてCADDiに入社した」という人間は数名しかいないんですよ。
となると、ほぼ全員が入社してからRustを学んだということですか？
そうですね。 そういう意味では、「必要であれば新しい技術もすぐに吸収できるような、学習速度」も要求されるかもしれません。
う〜ん…。 「学習速度」が重要だっていうのは理解できるんですが、その能力って採用前に分かるものなんですか？
100%見ることは難しいですが、要素として大きく分けて2つあると思っていて。 1つ目は、情報工学的な基礎知識や理論を知っていること。 2つ目は、様々な開発経験を持っていて、規模の大小は違っても、実際の業務の…例えばトラフィックの負荷分散、などを経験として理解していること。 この2つをバランス良く備えていれば、高い学習速度が期待できると思っています。
「現場から」PDCAを回せる組織
代表のTwitter拝見したんですけど、エンジニアチームの熱量の高さがすごいみたいですね。
ありがたいことに（笑）。 やっぱりCADDiは現場が強いと思っていて、実は前述したような技術選定って僕はそこまで絡んでないんですよ。 「Rustを使おう」という話も現場から出た話だし。
トップダウンじゃないんですね！
現場からPDCAを回せる開発現場であることが重要だと思ってますね。
Rustもずっと使い続けるかは分からないですから。 弊社では既に1周回って、Rustの限界に意識が向いており、その問題にどう向き合っていくかのフェーズに入っているので。 その時にまた、現場から別の技術を提案できるような会社でありたい、というか。
「技術は手段に過ぎない」という訳ですね。
CADDiは今エンジニアが20名ほどいて、まだミドルマネジメントを置かずに経営出来ているんですが、今後は更に規模が大きくなっていきます。 その時でもまだ、現場からPDCA回せる組織を目指したいですね。
ライター
新着記事やエンジニアに役立つ情報をお届け！
日々のキャッチアップをお手伝いします！
編集部オススメコンテンツ
アンドエンジニアへの取材依頼、情報提供などはこちらから
