CADDi DRAWERで何をしたいのか？/創業6年目からの新しい挑戦
¶ はじめに
こんにちは。
創立5周年記念note 13日目担当します。DRAWER事業部の白井です
(Twitter: @yskeee000)
なお、これまでの創立5周年記念noteは以下にまとめられています。
そんな5年目であった今年、キャディとして祖業であったCADDi MANUFACTURING(これまでは受発注プラットフォーム事業としていました。)に加えて、新規事業/新プロダクトとしてCADDi DRAWERをローンチいたしました。
このプロダクトは製造業における図面データを自動で解析し、単純に「図面を管理する」のではなく「活用」可能にすることによって新たなビジネス上の付加価値を生み出せるようにするためのSaaSです。
私は現在このDRAWER事業の事業責任者を務めています。
以前(二年前ほど)書いた記事ではMANUFACTURING事業についての話を詳しくご紹介しました。
少しプロダクトのローンチからは日がたってしまいましたが、5周年も迎えたこの機会に、今度はこのDRAWER事業の事業/プロダクトを通じて解きたい課題や世界観について書いてみたいと思っています。結構長いですが、興味があれば読んでみていただけると幸いです。
¶ なぜこのプロダクトをはじめたのか？
そもそもキャディとしてなんでこんなプロダクトをはじめたのか？ということから話を始めるのがわかりやすいかもしれません。
図面を扱うって結構大変なんです。
祖業である受発注プラットフォーム事業の役割は、顧客である装置その他のメーカー様から図面をお預かりし、図面の指示したように部品を製造して納品をすることです。その中で、大きな産業装置でいうと一装置で数千図面、電車一台となると数万図面という図面が扱われます。
厄介なことに製造業における多くの流通図面は2DのPDFなどのフォーマット = ほぼ画像のようなデータであり、構造的に扱うことがそのままでは難しいものになっています。
そのためこれらの図面を構造化しつつ、的確に扱うことは非常に煩雑な作業を伴います。
キャディの事業として、これらの図面がリーンに扱うことができなければ事業のスケーラビリティがおぼつかないということで、2019年ごろから社内のプロダクトとして図面を扱う仕組みを構築してきています。
そもそもこの文脈があった上で、「では社外でも同様あるいは近い課題があるのではないか」ということで、この視点から業界の中で探索を始め、プロダクト化したのがCADDi DRAWERということです。
余談ですが、キャディのMANUFACTURING事業は実際に製造から納品までを品質保証や納品責任を伴いながら行っています。非常にオペレーションヘビーな事業ですが、このプロセスにおける業界課題の体感から新たなプロダクトが生まれてくることが一つの魅力だと思います。
¶ CADDi DRAWERが解こうとしている課題
そのような経緯があり、顧客課題のよりシャープな特定というステップからプロダクト構築を進めてきた訳ですが、実際に解こうとしている課題はどういうものなのでしょうか？前提から始めて、イメージのしやすい目前の課題から順番に整理してみたいと思います。
図面というのは製造業や建設業界に関わりがある方を除けばあまり肌感がないかもしれませんが、数あるドキュメント/データの中でも非常に重要度が高い資産です。
なにせ、事業のコアである製品の仕様や製造方法が詳細に記載され、かつ社内外の多くのステークホルダーとその内容についてコミュニケーションする手段なので、その知財としての重要性たるや群を抜いています。
実際に我々の市場調査においても、製造業の事業活動において取り扱うデータのうち最重要のものは何か、という問いに対して6割超の人が図面と答えています。
先述のように、装置などのメーカーにとっての一つの製品だけでも数百~数万の図面があります。
一つの製品でもこれほど大量に図面があるのですが、製造業全体の中でもこと我々が相対している「多品種少量」という領域では製品の種類/ラインナップやカスタマイズも非常に多いので、一企業全体となると図面のバリエーションも膨大なものになります。
例えば10~20年分の図面数となると、数十万の単位であることはザラであり、もう一桁/二桁上ということもままあります。
また、古い図面であっても、装置や鉄道などの製品は納品されたら終わりというわけではなく保守保全などの観点でそれ以降も付き合っていくことになるので、10年前/20年前といった図面でも全然現役なわけです。
それだけ膨大な図面の中から、もし特定の図面を探し出さなければならないとしたらどうでしょうか？
数が多いから大変ということがもちろん第一にありますが、加えてこれらの図面の多くがPDFのような形式や、あるいは紙のまま書庫に保管されていることが大半の企業で起きています。
例えて言うならば、数十万/数百万の写真がフォルダに入っているイメージです。その中からふと思い出して頭に浮かんだ写真があってそれを探し出したいという場面を考えてみてください。まず、何を手がかりにして探したらいいかが難しい。直接脳内のイメージから検索することはできないので、保存した日付や、もし丁寧にフォルダ分けしていればそのフォルダの内容からあたりをつけつつ探していくことになり非常に時間がかかります。
このフォルダの構造がまた属人的だったりするので、探し方自体が属人知化してしまっている企業も多いのが実情です。
しかも、一つの会社が扱う製品はほとんどの場合、同じ装置や製品のカテゴリの中でのバリエーションなので「似てるんだけどちょっとずつ違う」写真が大量にあるのです。
結果として、製造業の中において設計や調達といった部署では平均して月に10時間程度、生産管理に至っては20時間程度を図面やそれにまつわる書類を探すことに時間を使っていると言うことが起きています。
まず、業務効率や生産性と言う身近な観点でもこれは大きな課題です。
そういったことを考えると、いざ探したいと言うときのためにどれだけ図面データを構造化して整理して置いておくか、と言う議論になります。
とはいえ、これもなかなか難しい問題です。
第一に、自動車業界のような量産系の製造業ではない多品種少量の世界では先述のように図面の絶対量が多く、一図面あたりにかけられる販管費が圧倒的に少ないです。一図面とはいえ、年間1万個生産しコストも数億になるものと、年間で5個しか作らず数万円単位のものではかけて良いコストが全く違います。
第二に、設計 -> 試作 -> 量産と段階をきちんと切り分けながら進む量産系に対して、受託生産も多い多品種少量系の領域では製造に入ってからの設計変更が頻繁に起きるなどバリューチェーンを往復しながらオペレーションがアジャイルに動きがちです。そのような流動性が高い状況で、図面の版管理などまで含めてデータを綺麗に整理された状態で保ち続けるのもまた難易度が高いです。
このような理由から「いざ探したい時のためにきちんと整理整頓し続けておこう」というのは実は中々難しいのが実情です。
また、「どのような探し方がしたいか」は探す時の目的や文脈によって一つではないので、全ての探し方に最適な整理方法で運用するのはより難易度を上げます。
さて、図面を探すのが大変ということが上がりましたが、普段の忙しい業務の中でそれだけ探すことが大変/煩雑だと、そもそも探すことに時間を使えない/見つけられないと言うことがしばしば起こります。
これが業務効率という観点以上に非常に大きな課題を生み出すのです。
ここで、いくつかの例を記載してみたいと思います。
ある製品を構成する部品が標準化されたり、部品を跨いで使い回すことができるとモノづくりの世界では色々な優位性を生み出します。
例えば、異なるものを少しずつ作るより同じものを数多く作る方が当然一つあたりの原価は安くなります。また、複数の製品で使われうるので在庫してストックしておくということもやりやすくなります。
そのため設計段階で部品などを標準化し、より多く品目を使い回したくなります。先述のように多品種少量の領域では、よく似ているが少しずつ異なる図面が大量にあります。これを統一していきたいわけですが、いざ設計するときに何が起きるかというと以下のようなことが起きがちです。
設計を進めていって、ある部分に行き着いた時、「同じような図面を前に書いたな」と思います。しかしながら先述のように図面を探すのは非常にめんどくさいので「探すくらいなら新しく書いたほうが早いな」という思考になりがちです。
結果として、何度も述べているような似ているけど少しずつ違う、という図面がまた新しく出来上がります。
設計する瞬間はこの方が早いのですが、その後の工程である調達では新たに見積もりを取らなければならず、ロット数が小さくなるので製造原価は上がり、製造では前の製造プロセスを使いまわせず、保守部品も品目が増えてしまいます。
結果、バリューチェーンを通して足し合わせるとその潜在的なコストの増加分は体感する以上に大きくなります。
多くの企業で「新しい図面を増やさない」ということをテーマに掲げていますが、そこには上記のような背景と一方で実行の難しさがあるわけです。
そのようなプロセスを経て、日々日々新しい図面が出てくるわけですが、それらを外注する際には調達部門の仕事になります。
調達部門では、新しい図面が発生するとそれをサプライヤーに見積もりを取り、時には相見積もりをしながら発注価格を決めていくわけですが、月に数百、数千という図面の手配をしながら個々の価格を一つずつ精査していくことが現実的にはなかなかできないという実情があります。
結果実態として何が起きがちかというと、非常によく似た図面でも手配価格がかなりブレているということが起きます。
もちろん材料価格や納期の長短により、このようなブレは一定リーズナブルに起きるものですが、ブレ幅の程度としてこのような事情では論理的には説明できない程度であることも多いのです。
もし、過去の類似図面とその価格に簡単にアクセスすることができればこのようなブレを抑え、価格の整合性をとっていくことができるはずですが、このようにコストの最適化という観点にも影響が及んでいます。
品質の面で言うと、似た図面で起こしてしまった不良を新しい図面で繰り返してしまうということも発生します。
設計や製造の段階で、前に類似の図面で起きた不良を把握し、それを改善し続ければこのような事象を減らすことができるはずですが、似ているといえどもあくまで異なる図面として扱い続けることによってそれらのナレッジを生かし続けることができないと言うことが起きると品質の安定という観点でも無駄が発生することになります。
これが多品種少量/一品一様の世界で起きやすい問題で、それは同じ図面を使いまわず頻度が低く、本来的には類似性が高いので使い回しうるナレッジでも図面が変わった瞬間に断絶してしまうということが起きています。
¶ CADDi DRAWERの現在地
このような中でCADDi DRAWERは現在主に多品種少量系の製造業メーカーのお客様を中心に2022年6月よりご提供をしております。
詳細については上記サービスサイトをご覧いただければと思いますが、現在は主要な機能として以下のようなものをご提供しています。
そして、その先に実現する価値として、
5年前に隣の部署で書かれた図面を即座に探し出すことができ、新図を描かなくてよくなる
3年目に買った類似品が即座にサジェストされることで、発注価格のブレを抑えることができる
ベテランの自分の調達先選定力を、新人社員でも再現することができる
と言ったシーンで活用いただき、事業上の付加価値を生み出しています。
先述したような課題を解決するため、図面を中心として顧客データを最適な形で「管理する」のではなく、「活用可能に」するということをプロダクトの価値の中心に据えています。
結果として数十人規模の会社様から数万人規模の大企業のお客様まで、様々な顧客に採用を進めていただいてきております。
ここからより広範なサプライチェーン上のデータや、3DのCADデータなどを扱い、それらも資産化して活用可能なように進化を進めていく予定です。
¶ 背景にある大きな潮流
ここまでではプロダクトとして向き合っている現状の具体的な課題について触れてきました。
ここからは少し、それらの背景にあると感じている大きな流れについて考えてみたいと思います。そして、目前の課題の先にそれらの大きな課題の潮流の解決に向かっていくことが中長期のこのプロダクトのミッションの軸になっていくと考えています。
製造業においても例に漏れず、データの活用による付加価値の創出が近年、また今後に向けて大きなテーマになっています。
データの蓄積から活用に向けてはいくつかステップ(バリューチェーン)を経る必要があり、求める活用に至れていない時、そのバリューチェーンのどこに課題があるのかをしっかりと見極めなければなりません。
製造業は歴史ある産業であり、大枠で言えば比較的長い間そのビジネスプロセスは変化していません。
昨今は盛んにDX(デジタルトランスフォーメーション)という言葉が叫ばれますが、デジタル化という文脈で言うとここ30年程度のタイムスパンで徐々に発展してきています。例えばSIerの売上上位の会社群などを見てみると、多くの会社で製造業というのは業界別の内訳のうち非常に大きな割合を占めるセクターです。レガシーと思われやすい製造業ですが、その実かなり様々なプロセスがシステム化自体は進んでいます。
すなわち、近年発展が著しかったGAFAに代表されるようなインターネットやITドメインに閉じた範囲におけるビジネス発展の文脈ではあまり触れられることがありませんが、同じビジネスプロセスに対して多額のソフトウェア投資が長期間行われ、じわじわとシステム化が進んできた領域の一つなのです。
もちろんそれらの過去のシステムのレガシー化といった諸問題はあるのですが、一方でビジネスプロセスで発生する多くのデータが記録され、「データの蓄積」という観点でいうと実は多くのデータが既に蓄積されています。
それらは例えば、会計に関わるデータであればERP、生産工程に関わるデータであれば生産管理システム、CADデータなどの設計に関わるデータ言えばPLM(Product Lifecycle Mangement system)といったような各々の領域を担当するカテゴリのシステムの中にあります。
近年ではこれに加えてIoTなどの新たな技術でさらに把握できていなかったデータのセンシングも進んできています。これは今後さらに多くの、特にホワイトカラー的なものよりも現場作業的な今までデータ化しづらかった部分のデータの獲得を促進していくでしょう。
このように、データの「蓄積」という課題が徐々に解決されてくると、今度はデータを「どのように活用するか」というところにバリューチェーン上のボトルネックが移ってきます。
散々述べてきたように現在主に流通している図面というデータは、PDFやTIFFなどの画像的なフォーマットが主流であり、非構造化データであることが多いことから、この課題がより顕著に現れやすいのですが、「蓄積はされているが活用しきれていない」データがそれ以外にも多く存在するというのは、このプロダクトを通じて市場と対話する中で、業界で今後顕在化していく課題のように感じることが多くあります。
つまり、蓄積されたデータを今度は実際にどう活用し具体的なビジネスインパクトにつなげていくかというイシューが大きな論点になってきています。
もう少し、細かな構造にも目を向けましょう。
実際にデータを活用するという観点に立った時には、当然それらの先に活用によって解決・改善したい具体的なビジネス上のイシューがあります。
あるイシューを解決したい時、それに必要なデータを集め、整形し、組み合わせたり分類したりすることによって、意味のあるインサイトや判断を導き出すはずです。
この観点に立ったときにふと気付いたこととして、部門横断的なデータの組み合わせが必要になるケースが多々あるということがあります。(考えてみれば当然のことですが)
一つ例を挙げてみましょう。
例えば部品の製造にかかるコストをどのように下げるか、という問題に取り組むとしましょう。
当然、部品の製造コストにはどのような形状であるか、材質は何か、塗装はどうするのか、といった要素が非常に重要なので図面やそこに記載されたデータは重要です。そういったデータは一般的には設計部門が管理しています。
一方で、実際にそれにかかったコストはどうだったのかというと、例えば製造を外注する場合には、その情報は調達部門の管理する発注管理システムや会計上のデータ管理をしているERPに記録されることが一般的です。
この問題で最低限必要となるデータを考えても上記のように異なるシステムに保存され、単一のシステムでは組み合わせて作業をすることができません。
このようなことが起こりやすい背景には以下のような構造があるのではないかと感じています。
・ソフトウェア産業と比較して、リアルの物を扱う産業では製品のサプライをスケールする際に人員が一定比例して増加しなければならない度合いが高い。
・そのため、スケールを目指す際に、各機能の練度を保ちながら増員するために機能別組織に分化していくケースが多い。
・予算管理の考え方もそれぞれの機能部門に紐づきやすい。
・結果としてソフトウェアベンダーは特定部門のペルソナ/課題、そしてターゲットとなる予算を想定してプロダクトを進化させる。
・そのため、各部門別に扱うプロダクトが分化していく。
特にSoR(System Of Record)は基本的に特定部分の業務プロセスに紐づくので、「業務プロセスをシステム化し、そこで発生するデータを統制する」という主目的を持つ以上部署最適的なものになりやすくなります。(もちろんプロダクトを拡大する過程で隣接領域に広がっていくこと自体は普通にありますが)
そのため、「存在するデータを活用して特定のイシューを解決することでビジネスインパクトを創出する」というSoRと明確に異なるValue Propositionを持つプロダクトが、横断的にデータを統合/整形しながらこの課題を解決していく必要性が高いという仮説を持っています。
一方で、上記のようなデータの分断という課題があっても、例えば多くの先進的なIT企業であればETL/Data Lake/Data warehouse/BIツール/各API連携などのツール群からツールチェーンを作ることで、それらのデータを活用可能にします。各システムに散らばったデータを横断的に集めうまく整形するのです。
そういったHorizontalなデータマネジメントのためのシステム群をうまく実装して活用することができますし、またそういったシステムの開発会社も最初はそのようにうまく活用が可能なリテラシーが高いイノベーターをターゲットにしがちです。
このような背景がある一方で、製造業などのVertical Industryではやや事情が異なっているように感じます。
まず、製造業や建設業などの元々IT領域が主戦場ではない会社では(特に日本では)それほどたくさんのソフトウェアエンジニアを抱えていないことが一般的です。そのようなモダンなツール群からデータ活用基盤を内製することがそれほど容易ではありません。
また、Horizontal = 一般的なデータ活用については多くの会社に対して汎用的なデータ活用の型やベストプラクティスが現れるため、それらの情報が比較的多く流通します。一方で、verticalな領域では「データをどのような形で活用するのがいいのか」ということが業界や領域特有になるために、システム構築の前にイシューになりやすく、それがわかりにくいためにシステム実装の手前の要件定義やROIの見積が難しくなりやすい。
そして、各業界では汎用的なデータ活用のためのソリューションでは解決しきれないことが現れます。ここまで読んでいただいた方ならお分かりになるかと思いますが、図面を解析して、記号や寸法といった情報を解析してデータ化する、みたいなことですね。業界/ドメイン特有に現れる課題を解決するモジュールが必要になります。
以上を踏まえると、一定の領域ではそのようなプロダクトが既に出てきてますが、verticalの領域では以下のような特徴を踏まえたソリューションが生まれる/伸びてくるのではないかという気がしています。
①データの蓄積から活用、ビジネスインパクトの創出に渡るバリューチェーンの中で、一定範囲の機能をパッケージングし、スクラッチから組み合わせて実装しなくても活用可能である
②一方で、多くの活用パターンを網羅的に可能にするというより、特定業界におけるデータ活用のパターンやベストプラクティスがプロダクトの型に反映されて重点的に利用可能になっている(これはDataOpsに留まらず、各領域のSaaSが多くのユーザーの知見を集約しながら共有のソリューションを提供している中で潜在的に発揮している付加価値と言えるでしょう。)
③データ活用のために必要なピースの中でも、特定業界向けに汎用的なプロダクトではカバーできないような解析や分析をするための特化型のモジュールが内包されている
例として挙げるとプラント/重工業領域にCogniteというプロダクトがありますが、これはさまざまなデータを格納し、関連づけ、またそれらをAPI経由でさまざまな形で活用できる一方、全体図と詳細図のデータの紐付けをAIから予測しレコメンドするなど、この領域特有の痒いところに手が届くような賢さを持っています。
このようなVertical Industry向けのDataOpsソリューションが各領域に現れていくという潮流が今後増えてくるのではないかと感じています。
データのバリューチェーンという側面に加えて、こちらはすでに非常に顕在化している流れとしてBusiness Spend Management(BSM)があります。
このBSMの詳細な解説は以下のLayerX福島さんなどの記事をご参照いただければと思いますが、ざっくりいうと企業の支出管理に関わるプロセスをソフトウェアしつつ、データから得るインサイトなどから最適化/効率化することです。
そして、そこから創出する主なビジネスインパクトとして業務効率の向上と支出の最適化(コストダウン)が挙げられます。
この大きな課題には参入の仕方が請求書処理や法人カードなどいろいろなアングルがありますが、言うまでもなく最終的に行き着く法人の支出の総額というのは莫大なため、最終的に目指されているその最適化というのは大きな課題であり、市場の規模も極めて大きなものになっています。
一方で、これらのBSMや購買管理に関わるプロダクトがこれまで主戦場にしているのは主に間接材の領域です。これにはさまざまな理由があると思いますが、ざっと思い当たるのは以下のようなポイントです。
・間接材購入は企業のさまざまな部署が分散して、かつ非定常業務として行っていることから無駄が多いこと
・分散しているがために購買方法や購買先の「統制をとる」ということに価値が出やすいこと
・基本的にはカタログ品がほとんどなため、カテゴリごとに集約し、ボリュームディスカウントを効かせたりサプライヤーを集約するなどコストダウンに向けた打ち手がパターン化しやすく、効果を出しやすいこと
他方で、我々が向き合っている領域だとどうでしょうか。
まず、例えば産業装置メーカーのような製造業では直接材のコストの対売上比率は約6割です。間接材と比較して単純にボリュームとして非常に大きいことがあります。この中で、特注品/図面品と言われるものはざっくり半分、売上の2-3割程度を占めます。
間接材と比べるとその購買業務というのは一般的には調達や資材部門と言われる部門に集約されており、一定の統制は取りやすいと言えます。
とはいえ、ではコストの最適化はどうかというと、ここは間接材と比べると非常に複雑です。
例えば、図面をもとに特注するものの場合、部品の名称 = 購買管理における名称は「軸」や「カバー」のようなものを使いがちですが、一口に言ってもアルミなのかステンレスなのか、小さいのか大きいのかなど非常に多くの変数があり、まずカテゴライズからして煩雑です。
部品番号のような一意の番号/IDを用いる場合も多いですが、今度は品目の特徴は特にそこに表出しないため、これも課題になります。
つまり、支出要素ごとにカテゴリを切ってそれぞれを分析する、といった手法もそう簡単に適応できません。
このように一品一様の直接材の領域では、管理/分析体系上の課題があり、その影響の一つとして前半で書いたような極めて類似の部品でも価格の整合性が取りにくいというような問題が起きるのです。
そのため、カタログ品や一般的な間接材領域とは異なるアプローチが求められます。。
つまり我々がアプローチしている課題は、BSMという大きな潮流の中で、モノづくり産業においては大きな割合を占めているが、その分独特な特徴がある品目領域を最適化しようとしている、という捉え方もできると考えています。
¶ "CADDi"という視点から見た時の景色、あるいは構造変化のための課題について
ここまで、業界の課題という軸に見てきましたが、我々キャディという視点から見たときの景色/文脈からCADDi DRAWERについて語るということもしておきたいと思います。
なぜか？
現状SaaSという形で提供されているCADDi DRAWERというプロダクトの観点でいうと、ここまで記述してきたような業界内の個別の会社の課題をどのように定義し、どのように解決するか、ということが重要です。
一方で、創業当初から5年という時間の中でキャディという会社は一貫して業界の構造をどのように時代に最適なものに変えるかということを考えながら取り組み、またその障壁となっていることを多々体感してきました。
そういった視座に立った時に、祖業の受発注プラットフォーム(MANUFACTURING)事業とこのDRAWER事業を両輪として、それらの障壁の解消に取り組んでいくということが極めて重要であると考えているからです。
そしてそれは、個別企業における課題解決(部分最適)と業界全体の課題解決(全体最適)に向かうインセンティブをいかにして揃えながら進んでいくか、ということとも言えるでしょう。
製造業では一企業の内と外にまたがって、長いバリューチェーンを通じて付加価値の創出が行われます。
すなわち、部門間や企業間をまたがって情報が様々な形式を通じて受け渡されていくわけですが、図面というのはその中で扱われる重要なコミュニケーション手段です。
そしてこの図面が意外と規格化されておらず、標準化されていないという問題があります。これについては以前のnoteに詳しく書いたのですが、一部を引用します。
また、少し先述しましたが同じ文言を使っていても想定しているものやそのレベルが顧客ごとに異なってきます。「傷なし」といった時にどのレベルを想定しているのか、それは慎重に合意しなければ納品時に期待していたものと違うという事態になってしまいます。
このように、言葉の定義やその度合い、記号の書き方などがかなり揺らぎがある一方で、多くの会社は繰り返しの業務や取引の中のコンテキストによってその一意性を補完しています。
このことは現状のキャディのMANUFACTURING事業においても大きなイシューの一つになっています。
業界の構造をより効率的なコラボレーションの姿に変えていくためにはこの図面に関わる表現の標準化を進めたり、その差異を適切に吸収できるようにすることで、異なるステークホルダー間の標準的なプロトコルを作っていくことが求められると考えています。
しかしながら、こういった「規格」や「標準」というものは単に「良い/よくできた」規格であれば浸透するものではありませんし、また推進や啓蒙にパワーを割いたからといって一般的なものにするのは至難の技です。
その浸透や伝播という課題に対して、CADDi DRAWERが普及した世界では一役買えるかもしれないと考えています。
DRAWERの中の機能において、一定の「標準」に寄せて貰えばよりユーザーにとってインセンティブがますという構造を作れる可能性があります。そして、多くのユーザーが自社にとってのそのインセンティブに乗る延長線上に企業横断で共通性のあるフォーマットに変化していくという構造を作れることに期待しています。つまり、個社の中での部分最適と業界的な全体最適をアラインさせる構造を意図的に作り出すということです。
これはSaaSとして多くの企業に共通のプロダクトを提供しながら、一方でMANUFACTURING事業では企業横断的なサプライチェーンにまたがった事業展開をしているキャディらしいミッションだと言えます。
ここまで、図面図面という話題が出てきいますが、製造業では多くの会社では以下のような段階を踏んでそれらの図面が作成されるようになってきています。
①設計部門において3D CADで設計し、組立時のシミュレーションなどを行う
②設計されたCADデータから2Dの図面に落とし込む。この際、3Dのデータでは持てない(持ちにくい)精度などのメタなデータを図面に落とし込む
③確定した2Dの図面をPDFなどの形式でエクスポートし、調達や製造部門、外注先に共有する
この2D化された図面のデータ、割ときっぱりとメリットデメリットが分かれてきます。
ーーーーーーーーーーーーーーー
■メリット
・(現段階では)3Dで持ちにくい精度などのメタなデータを記入しやすい。
・製造現場などでは紙に印刷されて扱われることが多く、その形にエクスポートしやすい。
・書き込んでメモなどを残しやすい。
--> 人間にとって扱いやすい(Human Readable)
■デメリット
・形状解析等をする際に、画像のようなデータになっており、解析が難しい。例えば外径線と寸法線が区別のない「線」になっているのでそれから区別する必要があり、難易度/コストが高い
・2D化されているので、3次元形状を推定する必要がある。元々3Dのデータで設計されているにも関わらず逆解析のようなことをしなければいけない。
--> 機械(コンピュータ)にとって扱いにくい("not" Machine Readable)
ーーーーーーーーーーーーーーー
このように元々CADというソフトウェアで設計されるためにMachine Readableに構成されているにも関わらず、後工程で人間が扱いやすいように出力してしまうことで多くの情報が削ぎ落とされてしまうのです。
結果として何が起きるかというと、
・画像のようなデータになっているので後工程でデータをシステムに入力する際に自動で読み取れないため、無駄な工数がかかる
・入力する割けない手間ため、フォルダにPDFが大量にあるといったような解析可能性が低いデータのまま運用され、結果として活用が難しい
・Inputが与えられないため、本来であれば可能な様々なソフトウェアによる自動化を行うことができない
といった勿体無いことが起きてしまっているのです。
製造業のように、現実の世界とバーチャルの世界を往復しながら成果物を作っていく世界では、その間の情報(データ)の往復が頻繁に起きます。その際にMachine/Human readaleなものに置換され往復します。その境界を越えることをよりシームレスにしながら、各工程の労力をどれだけ減らしていけるかが鍵です。
実はこのような人間とコンピュータの間をより直感性を持って繋いでいく流れはソフトウェアの世界でも歴史的に普通に起きてきていることではないでしょうか。元々バイナリのような極めてMachine friendlyな入力しかできなかったところから、より人間にとっても直感的でfriendlyな高級言語が現れ、コンパイラがその間をつなぐことでよりその協業のしやすさを高めてきています。
さらに直近では自然言語からイラストを作成するAI等の進化が目覚ましいですが、ある意味では機能的にはそのような進化のアナロジーの延長線上にあると言えそうです。
この課題に対して社内でも技術的なR&Dを続けています。これらを基点としてより人だけでなく、ソフトウェアがバリューチェーンの中でより有機的に協業する世界において、最適なデータのフォーマットを探索し、そしてDRAWERを通じてそれを流通されるようにしていけないかと考えています。
ここまで、どちらかというと情報やデータという部分を中心に語ってきました。しかし、製造業は当たり前ですが、モノづくりをやっている訳で、最終的にはモノに介在する付加価値自体が上がらなければなりません。
DRAWER事業を通じてわかってきたことの一つに、先述でも述べた似たような部品(図面)がたくさんあるということがあります。
一企業において、これを標準化することで製造原価を始めとするバリューチェーン全体のコストを下げるということを挙げました。
一方で、これは企業全体を超えても同じことが言えます。
極端な例を言えばネジなどがわかりやすいですが、最終的な製品の構成部品のうち、ノンコアなものを中心に共通化できる可能性があるものは実は色々あります。一品一様の部品群の中にも例えば留め具のような部品など、標準化可能と考えられるものは多々あり、もしそれらが企業を超えて業界的に標準化されカタログ化されていれば、一品目あたりの製造量が増え、在庫もしやすくなるので業界全体の生産性に寄与することができます。
(もちろん全く同じ部品で通用するケースはそれほど多くないと思われますが、一定の寸法などのパラメータだけを個別調整することでアジャストできる範囲となるとその幅はそれなりに広くなります。)
多くのサプライチェーン側のイノベーションは、横断的に必要とされる部品やソリューションを抽象化して共通に捉えられるようにすることで起きてきました。
例えば、クラウドの躍進は多種多様なサービスで必要とされるサーバーリソースを共通化し、個別性は設定などの領域で吸収することで同じサービスをスケールしてオンデマンドで提供できるようになりました。
3Dプリンタは、個別の生成物の具体の形が千差万別でも、設計のプログラムと積層数や材料の必要量が同じであれば同じように作ることができるようにしました。
このような横断的な標準化が部品製造の部分でより高度に達成されれば、業界全体の生産性に貢献できる可能性があると考えています。
しかしながら、このような発想自体は業界的にも素直なもので、特段新しいものではなく、それはすなわち発想は正しくとも実現には色々な障壁があるということを表します。
CADDiの目線で言うと、MANUFACTURING事業で案件を受ける時には既に図面が書かれてしまっています。その時、この標準部品に合わせてくれればいいのに、と言っても多くの工程や装置構成がその部品を前提に設計されており、変更コストが大きすぎて変えることが難しくなってしまいます。
その点、DRAWERは顧客の企業内で使われるため、より早い工程でサジェストすることができます。設計者は簡単な部品のCAD設計でいうと1分未満でやってしまうケースが多く、標準的な部品があるといってもそれにたどり着くのに数分かかるようではUXとして通用しないので、当然ながらその工程に食い込んだ先にもさまざまな課題はありますが、展望としてそのようなことを考えています。
最適なタイミングでユーザーにストレスなく提案することができれば、より図面を使いまわしたり、標準的なカタログに寄せてもらえる度合いを増やせるのではということです。
そしてこれもサジェストした標準部品を実際に製造して納品することも可能なサプライチェーンを持つという意味で、キャディらしい取り組みと言えます。
¶ 最後に: SaaSとしてのCADDi DRAWERなんてどうでもいい
目前のユーザーの課題から始まり、他業界も見渡した時の大きな潮流、そしてこの既存事業を通じての5年間があったからこそ解像度高く体感できた業界課題を持ってDRAWERに託している展望を書いてきました。
色々なトピックを織り交ぜて体系化乏しく書いてしまったので、すっとご理解いただける部分が少ないかもしれないのですが、全体を通して述べたいことは、単体のSaaSプロダクトとしてのCADDi DRAWERは、言葉を選ばず言うとどうでもいいと言うことです。
そうではなくてMANUFACTURING事業と、そして今後新たに出てくるであろう他の事業やプロダクトと合わせ、DRAWERは一つの手段として業界の構造に関わる大きな課題を解きたい、と言うことが僕らが目指しているミッションです。
そうは言いながら、大言壮語で目の前のユーザー課題を解けなければ何にもならないので、そういったミクロの解像度と課題解決に執着しつつ、大きなミッションを共に目指せる方々と一緒にわいわいやりたいと思っています。
そしてやりたいことに対して全く人が足りていません。
こういった世界観に共感をいただける方がいましたら是非お話しましょう！
ーーーーーーーーーーーーーーー
■会社概要Q＆A
https://recruiting.caddi.jp/recruit/event/meetup_friday
■創業5周年記念 キャディCEO/CTO対談ウェビナー
https://recruiting.caddi.jp/recruit/event/mhB-YpGb
■募集ポジション
JP-BIZ：https://herp.careers/v1/caddi
GLOBAL：https://caddi.freshteam.com/jobs
TECH：https://recruit.caddi.tech/
■カジュアル面談ご希望の方
https://herp.careers/ref/Zk1A9Yko3ohA8nAKXOQLsw1NAAlYZRhqAaxL2MADiLbgLgJLv6FewlvvZkYZsPDLxLLMpxFMRZvXqDAwSnM1LlR76GiAZ1we7eR
この記事が気に入ったらサポートをしてみませんか？