見出し画像

ところでキャディってなにを開発してるの?

「キャディ」という名前をを見かけるようになってきた

最近、キャディという会社の名前を聞かれたことがある人が少しずつ増えているのではないかと思います。たまたま観ていたテレビでイケているベンチャー企業の一つとして取り上げられていたり、Twitterのタイムラインで代表の加藤のつぶやきを見かけたり、あるいは面白そうなイベントだなと思ったら主催がキャディだったり。さらにエンジニアの方だとAtCoderでプログラミングコンテストの主催をしている会社として名前を見かけたことがあるかも知れません。

ちょっと気になってググって会社のサイト(https://caddi.jp/)に行ってみると、ちょっとレトロなテイストなトップページに作業服着た人たちの写真があり「産業機械・FA装置・設備機器の製缶・装置一式ならキャディ株式会社」って書いてある。あれ、違う会社かな?と思うけど、他にそれらしき会社は見当たらない。

はい、そこで合ってます(笑)。金属加工品の注文を受け、制作して納品するというのがキャディのビジネスの根幹です。じゃ、なぜ金属加工の会社にソフトウェアエンジニアが必要なの? キャディのソフトウエアエンジニアは何を開発しているの?という疑問に答えるのがこの記事の目的です

キャディが解こうとしている課題

キャディは「モノづくり産業のポテンシャルを解放する」というミッションを掲げています。モノづくり産業、すなわち製造業は日本の産業の中でとても強い領域でした。ところが最近少し元気がない。それには幾つか原因があると思っていますが、その一つが、製造を行う人たちが、製造以外の作業に時間を取られてしまっているということがあります。

例えば、「見積り」という作業。通常、工場が注文を受ける時には製作する金属加工品の形状や寸法が描かれた図面を貰います。その図面に描かれた情報を元にしてこれはどれくらいのコストで作れるかという試算を行い、そこに利益を載せて発注者に見積額として提示します。この見積りを行うためには、その加工品がどのような工程で加工されるのか、そしてそれぞれの工程にどれくらいの時間がかかるのか、などをはじき出す必要があります。それには熟練した技術が必要ですし、そもそも会社の損益に直結するので誰でもできる仕事ではありません。

しかも、せっかくそうやって見積りを行ったとしてもそれが必ず受注に繋がるわけではありません。通常は複数の加工会社に見積り依頼がされその中の一つだけが選ばれる事になります。選ばれなかった場合には見積り作業の見返りを得ることはできません。

我々は究極的にはこの「見積り」という作業を無くしたいと考えています。そしてその手前の段階として、できるだけ人手をかけずにできるようにしたい。そして加工工場の方々が見積り作業に費やしている時間をもっと創造的な作業に使って欲しいと考えています。

同じように、例えば以下のような作業にも多くの時間が費やされれています

・どの注文をいつまでにどこに納品すれば良いのかを確認する
・できた製品が図面通りに作れているのかを検査する
・できた製品を一つ一つ梱包してどの製品かがわかるようにタグを付ける

これら一つ一つはそれほど時間のかかる作業では無いかも知れません。ただキャディが扱う製品は多品種少量生産と言って、たくさんの種類の製品を少しずつ作るというものがほとんどです。したがって一つ一つの手間の積み重ねが大きな手間になってしまう。例えば一つの図面からそれを一個だけ作ろうが1万個作ろうが見積りの手間は一緒です。一つの注文で100枚の製品(図面)があれば手間は百倍かかることになるのです。

また、同じものをたくさん作る少品種大量生産であれば最適化が容易な生産管理や検査も、品種数が増えると複雑度が増します。同じ形状のものを繰り返し検査するのと、一つ一つ形状の違うものを検査するのでは手間が大きく異なりますよね。

キャディはこれらの課題をソフトウエアの力を使って解こうとしています。

課題解決に必要な技術

我々はある特定の技術をコアにして事業展開する企業ではありません。技術はあくまでも課題解決するための手段で、課題解決のためには新しい技術を貪欲に積極的に取り入れて、あらゆる手段を使って課題を解こうとします。Rustというプログラミング言語やKubternetesというコンテナプラットフォームを率先して取り入れているのもそれが理由です。

したがって「キャディはこういう技術の会社です」という説明は難しいのですが、幾つか特徴的な技術分野があるので、解こうとしている課題と関連付けて取り上げてみます。

図面に関連する技術

金属加工品の発注で製品の仕様書にあたるのが図面です。発注者は欲しい製品の仕様を図面上に表現し、受注した加工工場はそこに描かれた通りに加工を行います。図面上には寸法に関する情報だけでなく、加工誤差がどれくらいまで許されるのか(公差)という情報や、表面処理をどのように行うのかという情報が書かれています。

従来は図面を人が目で見て情報を理解し、見積りを行い、加工を行い、検査を行っていました。人が行う作業なのでどうしても見落としなどが発生してしまいますが、そうすると作り直しの手間が発生してしまうのでそれぞれが注意深く図面を見る必要があります。

キャディはこの負荷をコンピュータービジョンを応用することで軽減しようとしています。図面に描かれた情報をデジタルのデータとして抜き出し、見積りや加工指示や検査のサポートに用いようとしています。下記のような簡単な図面であれば情報抽出できるようになってきていますが、実際の発注ではもっと複雑な形状の図面もあるのでまだまだ改善が必要です。また、精度向上のためにコンピュータービジョンのアルゴリズムとともに、機械学習の応用も試し始めています。

画像1

図面一枚一枚の情報抽出とともに、大量の図面をどのようにに効率的に扱うかというのも課題の一つです。キャディは多品種少量生産の製品を中心に扱っているため、一つの発注で図面が100枚とか200枚とかいう単位になることもあります。そのような発注を同時並行的に大量に受けていますが、各企業の知的財産である図面を取り違えるということはあってはならず、図面の管理は非常に気を使う作業です。

さらに、図面の不備を修正するための修正版が発注者から送られてくることもあります。例えば200枚の中の数枚が差し替えなければならないという場合に、間違いなく差し替え対象の図面を特定し、さらにどこが変わったのかを把握しなければなりません。

これらの作業を人手だけで行うには限界があるため、キャディでは図面を管理するためのシステムを開発しています。発注と図面を結びつけて管理するだけではなく、差し替えに対するサポートや図面に描かれた情報を元に検索を行うということも求められます。

受発注に関連する技術

前に述べたように、受注の手前で必要になるのが見積りという作業ですが、キャディはここも既にシステム化しています。対象の加工品がどのような工程(金属の板を曲げる、穴を開ける、旋盤で削る、など)で作られるかを分析し、各工程がどれくらいの時間と工賃でできるかを積み上げることによってコストを算出しています。この製造原価を計算するシステムはすでに実用化されて生産現場の方々の負荷軽減に役立ち始めていますが、まだまだ満足できるレベルには達していません。精度の点でも改善が必要ですし、扱える品種ももっと拡充したい。精度の点ではデータ分析機械学習の応用も可能ではないかと考えています。

さらに受注後は、提携しているパートナー工場の方々に製造を依頼し、それが顧客に約束した納期通りに製造・検査されることをチェックし続ける必要があります。さらに、表面処理だけ別の工場で行うなど、一つの製品が複数のパートナー工場で処理される場合もあり、その依存関係の把握も重要です。これも人手だけで行うには限界があるので製造工程・サプライチェーン管理のシステムを開発していて稼働させています。このシステムは皆さんの想像以上に複雑なドメインモデルに基づいていて、ドメイン駆動設計(DDD)という手法をつかって設計されています。

製造を依頼するパートナー工場の選定も既にシステム化されているオペレーションですが、まだ改善の余地があります。できるだけそれぞれの強みを生かせる製品の製造をお願いしたいと考えていますが、さらに精度向上のために機械学習の応用を検討しています。

モノを確実に届ける技術

パートナー工場で作られた製品は、キャディの検査拠点で確認が行われた後に顧客に納品されますが、そのモノの流れを追うことも納期を守るためには大切です。QRコードを用いた製品のトラッキングを一部導入し始めているところですが、まだまだ改善の余地があるところです。

検査の現場では、例えばRFIDを用いて受け入れ確認やモノを探すという作業の時間短縮を検討しています。また、図面から抜き出したデータを用いて検査箇所を指示することで、誰でも測定ミスなく短時間で測定できるようにしたいと考えています。ただ、これらはまだ構想段階で実用化はこれからの段階です。

さらに運搬や梱包も同様で、人手が多く介在する非効率な運用がまだ多く残っていて、検査工程とともに今後集中的に取り組んでいく分野の一つです。

さらに未来の世界

今は見積りとか検査とかを独立したステップとしてシステム開発していますが、将来的にはこれらをシームレスに統合したシステムになっていくと想定しています。それは、調達だけでなく設計や製造にも染み出して、モノづくりのプロセス全体での効率化を図っていきます。

画像2

例えば、現在では見積りは設計が終わって図面が完成してから行うものになっています。したがって「もう少しここをこうしておけば安く作れたのに」ということがあったとしても基本的には図面に描かれた通りに作るしかありません。これが、例えば設計の段階で即座に見積りがわかったらどうでしょう? 設計者がCADで部品の設計をしている時にちょっとした違いで大きくコストが変わることに気がつけるようになります。コストを掛けて作りにくい形状をあえて作らなければならないものもあると思いますが、意図せずにそうなってしまっている場合もあるでしょう。そういったことを設計段階で気がつければ、コストも削減できますし、無駄に高難度の加工をせずに済んで製造上のミスも減ると考えられます。

我々が、見積もりのシステム化というチャレンジに挑んでいるのは、単純に人がやっている作業をシステムで置き換えるだけではありません。このように設計段階に見積もりを持ち込むなど、手動では到底実現できないような組み合わせをすることで新たな価値を生み出そうとしているからなのです。

もう一つ別の例として、500種類の部品を使った完成品を一日に1つずつ製造する顧客を考えます。組み立てを行う顧客視点で考えると部品の在庫は持ちたくないので毎日500種類の部品を1セットずつ納品して欲しい。ところが製造観点で考えると一日に一つずつ作るのは工作機械のセットアップの手間を考えると効率的ではないのでまとめて作りたい。コストもまとめて作った際のコストを顧客に期待される。結果的に、製造工場側では、将来的に注文が続くであろうと想定して、注文よりも多くの数を作っておいて自社でリスクを負って在庫を抱えておくことになります。

キャディはこの問題もシステムで解決しようと考えています。小ロットの製造であったとしてもオーバーヘッドを最小にするために、設計仕様(図面)から工作機械をすぐにセットアップできるようにしたり、それでもある程度の在庫を抱えなければならない場合にはそれを管理するための仕組みも提供します。このためには、製造の現場にも深く踏み込んでいく必要がありますし、より詳細にリアルタイムに製造や在庫の管理を行う必要がありますが、それによって人手では到底到達できないレベルの最適化が達成できると考えています。

そして、キャディは日本だけにとどまらずに世界中の製造業を変革していくつもりです。そのために組織のグローバル化にも取り組み始めているのですが、それに関してはまた別の機会に詳しく書きたいと思います。

画像3

キャディのエンジニアって特殊な人たちなの?

このような壮大なチャレンジをしているキャディですが、その技術を支えるエンジニアは特殊な人たちなのでしょうか?

そんな事は有りません(笑)。優秀なエンジニアが多く集まっていますが、特殊な能力を持った人たちというわけではなく、普通のソフトウエアエンジニアの人たちです。それぞれ、キャディに入る前にやってきたことや、技術のバックグラウンドも異なります。

ただ共通して持っている特徴が幾つかあって、その一つに「課題解決が好き」というのがあると思います。目の前に解くべき課題があるとそれを解かずにはいられない。特定の技術だけを極めていきたいというよりも、課題解決のために使える技術はどんどん使っていく。そんな志向をもったエンジニアの方は一緒に働きやすいんじゃないかと思います。

それでも特殊な人たちだと思われがちな点が2つほどあって、カジュアル面談などでもよく聞かれるので書いておきます。

一つは「Rust書けないとダメですか?」というもの。そんな事有りません。最近色々なところで取り上げられていて名前は良く知られるようになっていますが、実際にRustを製品開発に使われている企業ってまだ数える程しかないと思います。したがって業務経験がある方もとても限られています。

Rustでの業務経験は問いません。もちろん、趣味のコードでRustを使っているという経験は歓迎スキルになりますが、それが無いからダメということにはなりません。ただし、我々の開発の多くの部分(フロントエンド以外)でRustを用いているので、入社後にキャッチアップしていただく必要があります。その際に静的型付け言語やメモリ管理を開発者が行う言語(C/C++など)の経験は役に立つでしょう。

でも、一番大切なのはRustに対する興味で「本格的に使ったことないけど少し触ってみたらとっても面白そうなのでぜひこれを習得したい」という気持ちが重要です。そうすれば社内にエキスパートがたくさんいますし、コードベースもたくさんあるのであっという間にキャッチアップできると思います。

なお、フロントエンドはTypeScript / Reactでバックエンドシステムの一部でもTypeScript (Node.js)を用いています。

もう一つのよく聞かれる質問は「製造業に詳しくないとダメですか?」というもの。これも、そんなことありません。現在在籍しているエンジニアの多くは製造業とは関係ないキャリアを経てキャディに来ています。決済システムを作っていた人、受託開発をやっていた人、ゲームのバックエンドシステムやっていた人など。

製造業に関する経験や知識は問いません。ただここも同じく興味をもっていることは重要かなと思います。興味がなければ解くべき課題の面白みも薄れてしまうでしょう。でも、ソフトウエアとは言えエンジニアであればモノづくりの楽しさは、多かれ少なかれ皆さん知っているんじゃないかなと思います。むしろ、ソフトウエアの世界にいてなかなか馴染みが無かったけど、ハードウエアって面白そうって思ってた人はきっとハマります。

さいごに

キャディではどのような開発をしているのか、そしてそれをやっている人たちはどのような人たちなのかということを書いてみました。もっともっと書きたい事があるのですが、長くなり過ぎてしまうのでこの記事は一旦ここで止めておきます。また機会を見つけて素のままのキャディのをお伝えできればと思います。

今まで良くわからなかったのでどうしようかと思っていたけど、この記事で少しクリアになったのでより詳しい話を聞いてみたいなという方は以下から気軽にコンタクトしてみてください。



この記事が気に入ったらサポートをしてみませんか?