![アイキャッチ](https://assets.st-note.com/production/uploads/images/18511358/rectangle_large_type_2_30b828c6b44f4cbbc1ea3aa174875578.png?width=1200)
プロダクトマネージャー視点から見る製造業プラットフォーム"CADDi"
こんにちは。
キャディでプロダクトマネージャーをしている白井と申します。
この記事では掲題の通り、プロダクトマネージャーの視野から見た"CADDi"というプラットフォームについて現状の解像度で記載してみたいと思います。(※ 全ての情報が記載できるわけではないので一定の抽象度は保っています)
プロダクトマネージャーという役職としての在り方や職務といった内容に拘っているわけではなく、飽くまでそのロールの視点で見てという意味合いです。キャディにおけるプロダクトマネジメント、といったテーマに特段フォーカスするわけではないです。
ちなみにやたら長いです。
もっと簡略にしようかとも考えましたが、あえて普通に言葉を尽くして書くことで出来るだけきちんと実態を説明ができる方を取りました。
特に重点をおいているのは「何を仕組みで解決していく必要があるのか」、です。"仕組み"についてはオペレーション(人/組織)とプロダクト、あるいはその両方がありえ、どういうHowをとるかはIssueや事業のフェーズによります。
そして、そのような課題解決のためにそれに長けた方々に解像度高くそれをお伝えし、是非是非お助けいただきたいのです。
また、よく開発観点でTechがどんなプロダクトや課題に取り組んでいるのかがよく分からない、というような話をいただく場合も多いので、そのあたりもフォローしつつ記載できればと思います。
(技術スタックの全体象などはこちらでご覧いただけます )
まず、様々なものの前提として、キャディがトライしているマーケットがどのようなものなのか、そこから話をスタートしたいと思います。そして、そのマーケットの中でキャディがどのようなことを課題と捉えており、それをどのように解決しようとしているかを整理していきます。
さらに、その解決のためには、分解された複数のIssueが存在しますが、それがそれぞれどのようなものであって、どのように開発が生かされていくのかを記載していきたいと思います。
1. キャディがトライしているマーケット
まずはキャディの向き合っているマーケットについての概要なのですが、原が懇切丁寧に解説してくれたので基本的には下記の記事を参照していただければと思います。
まだこの記事中で言及されておりませんが(おそらく後編でしっかりと解説があるかと)、特にキャディがフォーカスしているのは製造業の中でも「多品種少量」と「特注品」と呼ばれる特徴を持っている領域です。
例えば製造業と言って思い浮かびやすいものは自動車がありますが、一般向け自動車は通常1車種に対して数千・数万台生産され、それらを構成している部品もその単位で製造されます。
一方で、生産用機械と言われるようなカテゴリでは、例えば食品工場内で使われる機械など、一つの種類の装置で数台 ~ 数十台単位で生産されるものが多数あります。これらの機械は一つの種類の生産数こそ少ないものの、装置の種類が非常に多く存在しています。そのため、それらを構成する部品の製造も、たくさんの種類を少しずつ、という世界であり、まさに「多品種少量」と呼ばれる由縁であります。
そしてそこで使われるものの中には、例えばネジのような汎用的なものも含まれますが、先述のような多品種少量のような領域では大部分を閉めるのが、メーカーそれぞれが独自に設計し、図面と共に加工会社に発注する特注品と呼ばれるものです。
これはそれぞれのメーカーのナレッジが詰まった知財であり、オーダーメイドの仕様を持っているものです。
(キャディで取り扱っている製作事例)
この「多品種少量」と「特注品」の二つの特徴を持つ市場がキャディが目下取り組んでいるマーケットであります。
そして、これらの特性からくる特有の課題が存在しているのです。
このマーケットの2つ目の特徴は、市場が極めて細分化(フラグメンテーション)している点です。
この市場では中小企業が多数存在しており、大きな割合の付加価値を創出しています。
(中小企業白書(2011)より. 特に食料品製造業や生産用機器具製造業, 金属製品製造業では中小企業のプレゼンスが高い)
例えばサプライヤー側を見てみると、キャディで扱っている領域の一つである板金加工(金属の板を元に加工して部品を製造するもの)の領域だけでも日本国内に20000社以上存在しています。その多くが従業員数一桁の小企業であり、また板金加工と一口にいっても、それぞれの会社ができる加工・材質や得意なものはさらに細分化されます。
このフラグメンテーションの特徴を持つ多品種少量・特注品市場において、キャディの行っている事業は「調達」と呼ばれる領域と深く関わっています。
例えば、装置メーカーは自社の装置を作るために必要な部品を加工会社に発注し、納品された部品を元に組み立てて製造します。もちろん、加工自体も自社でやってしまうケースもありますが、このように外部に加工を発注し、必要な部品を集める業務は調達や購買と呼ばれます。
この調達領域は製造業の中で極めて大きな役割を持ち、実際に大きな取引額が存在するにも関わらず、長年イノベーションが起きていない領域なのです。
ロボットによる自動化など、製造の工程に注目されやすいのですが、この調達領域は120兆円もの市場規模を誇っています。
では、この中でキャディがトライしているイノベーションはどのようなものでしょうか?
2. キャディが解決しようとしていること
この世界ではどのような取引が発生するのでしょうか?
まず、原始的なパターンは以下のような形です。
このような多品種少量かつ特注品の受発注を成立させるためには必要な条件が2つあります。
①そもそもその部品を作れる(あるいは得意な)会社に発注する
②その取引の価格を算出し合意する
の2点です。
①については、馴染みがないとイメージが沸きづらいのですが、実はいわゆる加工会社と一口に言っても、持っている加工用の機材や抱えている職人は様々であり、ある図面の部品は作れるけどある図面の部品は作れない、ことはたくさんあります。
②については、当然の話なのですが都度の取引においていわばオーダーメイドでの受発注になるので、取引ごとに取引価格を見積もり、お互いに合意する必要があります。さらに、それゆえにこの価格は加工会社ごとに変わってきます。①とも関係してきますが、一口に「作れる」と言っても「いくらで」かはバラバラなんですね。一定の品質と納期をクリアできるという前提があるならば、より安く作れる加工会社の方がその図面の製造については「得意である」と見ることができます。
そのような背景があり、先ほどの図の取引に至る前に多くのケースでは、相見積もりの工程を必要とします。
装置メーカーは「こういうものを作って欲しい」という仕様情報を元に複数の加工会社に見積を依頼します。多くの場合は図面のファイルとテキストなどのメタ情報です。
加工会社は、
この仕様であれば、こういう材料を購入して、こういう機材を使った加工の工程が必要になってそれぞれの工程ごとにこれだけの原価がかかるのでそれらの金額や必要な時間を合計すると・・
と言ったことを考え、「これなら〇〇までに〇〇円で作れる」や「申し訳ないが、これはうちでは作れない」と言った回答をします。これらの回答を元にして、比較検討の上で装置メーカーはどこに発注するかを決め発注書を切ります。
ここで、一つの課題に直面します。
先述のように高度にフラグメンテーションしているこの市場では、候補になり得るサプライヤーが全国に数万社存在します。
調達担当者はこの中から、一つ一つの部品ごとに最適な加工会社に発注するのが理想的な状態です。すなわち、求める品質や納期を満たしつつ、最安値で納品してもらえるような加工会社を発見できている状態です。しかし、現実的には一つ一つの部品に対して相見積もりをとるのは数社程度です。なぜならば調達担当者は時に数百図面/日もの発注業務を行わなければならず、全ての図面に対してあまねく加工会社の可能性を追求するのは現実的に不可能だからです。
弊社の定義しているMISSIONは「モノづくり産業のポテンシャルを解放する」ですが、ここに一つの潜在的なポテンシャルが存在します。
また、もう一つ重要なのはそのような状況であってもすでに調達担当者は煩雑かつ膨大な調達のオペレーション業務に追われているというペインが存在していることです。
実はこの状況下では、加工会社にもオペレーション上のペインが存在します。それは見積業務です。多くの加工会社が中小企業と呼ばれる規模であり、限られたリソースであるにも関わらず、この見積業務には相当の労力が関わります。一方で、発注側が相見積もりをとるということは高い確率で失注します。平均的には5社程度の相見積もりを行うとすると、実に80%の見積もりは徒労に終わってしまうのです。
このように見ると、発注側の調達活動や受注側の販売活動ないし営業活動にある煩雑なオペレーションの工数をより簡単に、短時間でできるようにしていくことが、キャディがトライできる一つ目の課題解決です。
そして、このオペレーション工数がもし現状より圧倒的に低くなるとしたら?を考えていくともう一つのポテンシャルをそこに見出せます。
そういった世界では、オペレーション負荷が非常に小さいため、発注側は自分が調達しようとしている部品を最も安く、高い品質で製造できる加工会社を探し出すことができます。そのような作業をしても、オペレーション効率が見合うからです。数万社存在するサプライヤーから、自分たちのコスト競争力を最も高めてくれる取引先をパートナーに選択できます。
そして、逆に受注側は自分たちが最も得意な加工を必要とするメーカーを探し出すことができます。最も自分たちが強みを発揮し販売競争力を持ちながら、収益を確保できるような取引機会により集中していくことができます。
より双方にとってより最適な受発注のマッチングを実現することが、我々が解決したい二つ目の課題です。
3つ目はポートフォリオの問題です。
受発注には、売上をあげる/コストを下げる/収益性を改善するといったものの他にリスクという側面の課題があります。
分かりやすい例は、小さな町工場が特定の顧客からの受注に仕事の大半を依存しているようなケースです。
このような状況ではその顧客との取引を失ってしまうと経営が成り立たなくなってしまう、というリスクが大きくなってしまいます。またそのような力関係から、適切な価格交渉を行うのが難しくなってしまいます。言葉を選ばずいうと「買い叩き」と呼ばれる取引も起こりえます。
上記のような町工場のストーリーはかなり典型的なもので、イメージが湧きやすいと思うのですが、一方で、実は同様のリスクは発注側にも存在しています。
特に中小製造業においては、事業承継や経営難などの要因によってこの30年で事業者数が約半数にまで減少しています。年換算で約2%の取引先がなくなっていくことになります。今まで安定的に発注しており自社の発注する図面の癖や特徴を把握してくれていたサプライヤーがなくなってしまい、新たな調達先に苦労するケースが多くあります。
すなわち、受注側だけでなく、ポートフォリオをきちんと分散したり、リスクマネジメントをすることは発注側にとっても非常に重要な問題です。
このように特定の取引先への依存度を下げリスクの分散と適切な交渉力の確保をできるようにするのが、トライしている3つ目の課題です。
さて、ここまでキャディがトライしている課題について書いてきました。ここから、それらの課題をどのように解決しようとしているか?について書いて行ければと思います。
これらの3つの課題を解決して、どのような世界を実現したいのか?
それはつまりこういうことです。
発注側も受注側も受発注に関する煩雑なオペレーションから解放され、ベストな取引先と繋がることができ、取引上のリスクが分散され適切な価格交渉を行える世界です。
ここまで読んでいただいて、多くの方が察していらっしゃると思うのですがこれらのペインを解決するためにキャディがまずやろうとしているのはこの領域におけるマーケットプレイスを作ることです。
マーケットプレイスは様々なドメイン領域に既に、また古くから存在しており、特にインターネットやモバイルといった技術が大きくバリューを発揮して新たな形で成長させてきたビジネスモデルであると思います。
しかし、この製造業の領域でマーケットプレイスを実現していくためには大小様々な課題があり、それらをオペレーションとテクノロジーを柔軟に設計しながら解決していくことが重要です。このプラットフォームでは、「この図面の部品を作って欲しい」、という依頼がきた時に最適なサプライヤーを探し出せなければなりません。
3. マーケットプレイスを成すためのIssues
そして、その大小様々な課題を解決するために、いろいろなバックグラウンドの方々のナレッジやスキルをお借りして、この課題に辛抱強く取り組んでいきたいのです。
なのでここから、どんなIssueを解かなければいけないかを書いていければと思います。
繰り返しになってしまいますが、このプラットフォームでは、「この図面の部品を作って欲しい」、という依頼がきた時に最適なサプライヤーを探し出せなければなりません。(キャディではこのプラットフォームとして提携させていただいているサプライヤーの方々を「パートナー」と呼んでいますが)
そのため、まず我々はこのサプライヤーはこういう加工が、こういう材質のものに対して、いくらくらいでできる、という製造能力の情報をそれぞれに対して知らなければなりません。そして、もしある案件の依頼がきた時に最適なサプライヤーを数千数万の中から迅速に探し出そうとするなら、それらの情報を構造的に保持し、設計されたロジックに基づいて自動的に探索されるようにあるべきです。
求められているのは、材質・数量・サイズ・加工種類・対応可能納期、などの数多の変数の組み合わせからなるサプライヤーの強み弱みを構造的に整理してデータとして保持できるようにすることです。我々はこれをカバレッジデータベースと読んでいます。
僕もキャディにJOINして体感しましたが、製造業に存在する変数はとにかく膨大で、変数の組み合わせによって爆発的なメッシュになります。これを適切なサイズで分類し、構造化することができる情報設計が必要になります。
さらに事業成長と共にキャディで扱う加工種類は徐々に拡張しており、日々今まで想定していなかったエッジケースに遭遇するので、それらを取り込みつつ徐々にデータベース設計を成長させる仕組みが必要です。「これで全部想定される組み合わせは書き出せたね! はい完成!」というおめでたい進め方はなかなかできません。
このような背景から、IA(Information Architecture)やDevOpsに長けたエンジニア/PM/オペレーション設計などの方々を全力で募集しています。ちょっと話を聞いてみたい、といったところからでもいいので以下から是非ご連絡ください。
プロダクトマネージャー:
バックエンドエンジニア:
Rust版のサイトはこちら:
こちらもよろしくお願いします!
製造能力の情報と自動的に対照し、適切なマッチングを見つけ出そうと思うならば、それに対するInputも型化・構造化されていなければなりません。
ここでいうInputとは、依頼された製品の仕様です。
製造能力の情報とは、どのような加工を行うことができるかというHowの情報である一方、どのような材質でどのような形状で・・といったWhatの情報が仕様情報です。
こちらも同様に情報が適切に設計され、オートマティックに処理できるような形に落とし込まれている必要があります。この時に課題となってくるものの一つが仕様の一意性です。
例えば、装置の一部に使われる部品に対して「傷なし」という指定があったとします。しかし、この指定に対して、どの程度までの水準を要求されるか、については明確な指定がない場合も多いのです。農業用の装置を作っているメーカーと医療用の装置を作っているメーカーとでは暗黙のうちに前提としている水準が異なります。後者では言われなければ気づかないようなレベルの小さな傷も防がれていることが求められる場合もあります。
では、高い品質水準を一律に取ればいいかというとそうではありません。求められている水準に対して、過剰な品質を追求していくと、今度は求められているコスト水準を不必要に超えてしまう場合もあります。
このように、製造業界で完全に一意性が担保されていなかったり、意味や表記が揺らいでしまうものを型化/構造化/標準化して扱えるようにし、最適なマッチングやサプライヤーへの齟齬のない仕様共有を為せるようにしていく必要があります。
こうして、仕様情報の型化ができるとその情報の製造工程の情報への翻訳が必要になります。どのようなものを作る必要があるか、のWhatの情報から、そのためにどんな工程が必要か、のHowの情報への変換ですね。
(もちろん素材として何を使う必要があるかという情報もありますが)
この翻訳には2つの用途があります。
一つ目は製造原価の見積です。
ある製品を作るのにどのような工程が必要かを算出し、一つ一つの工程にかかる製造原価を計算し、それらを積み上げてその製品の製造原価を見積もります。ただし、例えば一つの製品を一つだけ作るより1000個作る方が一つあたりの単価が安くなるなど、積み上げだけではない様々なロジックを同時に勘案します。また、それぞれの工程にかかる時間を計算し、現実的な納期も同時に導き出します。
キャディではこの見積もりのためのアルゴリズムを開発しており、求められる製品の仕様に対して、製造原価や実現可能な納期を自動的に算出する開発を行っています。
このアルゴリズムモデルは仕様の工程への分解と工程ごとの原価算出、そしてそれらの組み合わせによって日々開発と改善が行われています。
このようなアルゴリズムモデルの開発を製造・加工の知見が詳しい事業部と共に構築していくエンジニアの方々をお待ちしています。
バックエンドエンジニア:
また、3D CADのファイルを元に形状解析自体を自動で行う技術開発を進めています。(通称7秒見積)
最近弊社の形状解析アルゴリズムを初期からけん引してきた弊社のいなむ氏がその歴史を綴ってくれました。
CADのバックグラウンドを持つ方、アルゴリズムに強い方をお待ちしています!
アルゴリズムエンジニア:
仕様情報の製造情報への翻訳、2つ目の用途はマッチングです。
仕様情報を製造情報の双方を型化し、それを繋ぐ翻訳機能を作ることによって両方を対照することができます。
これを元にして、その仕様を実現するために最適なサプライヤーを導き出すアルゴリズムを構築していっています。難しいところは単純にこの製品はここ、と言った形で一意に決められるわけではないと言う点です。(もちろんそれだけをきちんと決めることも難しいのですが)
例えば、一つの製品でも塗装とそれ以外であればサプライヤーを分けた方がいいケースは多いです。部品の形状の製造と塗装ができるサプライヤーに依頼するのではなく、塗装は塗装専門のサプライヤーに依頼する方が品質や価格面でよくなる可能性があるためです。
また、例えば一つの装置の100種類の部品を手配しなければいけない場合、それぞれ単体に最適な100のサプライヤーが分かったとしても、集約した方が安く製造できる規模の効果が働き、50部品ずつ2つのサプライヤーで製造する方がいいケースもあります。
いたずらに受発注の粒度を小さくしすぎてしまうと社内外のオペレーションコストをあげてしまい、目に見えない部分でコストを発生させ最適にならないことも起こりえます。
実はこういったマッチングはまだまだ製造業界全体でも実現できていません。キャディでは、提携しているサプライヤーをフラットに見て、一つの製品でもA工程はここ、B工程はここ、のように最適なサプライヤーを工程ごとに選定し、サプライチェーンを構築します。
この市場の多くのケースではある製品をサプライヤーに発注して、そのサプライヤーが一部の工程ができない場合、そのサプライヤーがその工程をさらに外注する、と言った形をとるケースが多いです。そのため、必要な工程の種類が多くなっていくほど、サプライヤーの探索/比較対象の範囲が狭くなっていき、市場全体を見たときの最適な調達から遠ざかってしまいます。
これがもし、同一部品の大量生産であるならば丹念にそれぞれの工程の発注先を精査しても割りに合うのですが、先述のような多品種少量領域でマニュアルにこれを進めるのはほぼ不可能です。一つ一つの発注の単価や粒度が小さすぎるためです。
そのため、これを自動化し低工数で実現することが非常に大きなValueを発揮します。
こういった状況を踏まえて、マッチングとサプライチェーンの構築のアルゴリズム構築とバックエンド開発に強い方々にまだまだ助けて欲しいです。
特に数理的なバックグラウンドが色濃い方だとより一層フィットが高いかもしれません。
バックエンドエンジニア:
さて、マッチングがとても重要なIssueであるのは間違いないのですが、私たちのビジネスで勘違いされてしまうことが多いことの一つに、"マッチングだけ"やっているという理解があります。
ビジネスモデル的に言えば、発注者と受注者をつなぐところまでやり、成立したら手数料が発生するモデルです。
実際には発注元の顧客と発注先のサプライヤーをつなげているだけではありません。キャディにおいては顧客は「キャディに対して」発注をし、サプライヤーは「キャディから」受注をします。
つまり、納品や品質の責任はキャディにあり、受注して以降も製造や輸送が正常に進んでいるかを管理し、納品までをオペレーションしきる責任が求められます。
この過程を円滑に管理しオペレーションのメンバーがよりミスなく低コストで進められるようにしていくことが必要です。またその間に生まれる様々なデータを分析・活用可能なものにすることも取引が現在進行形で大きく成長している中で重要なものになっています。
キャディではこのプロセス管理のプロダクトを内製しています。
これは一般的にはPDM(Product Data Management)やSCM(Supply Chain Management)と呼ばれる領域のシステムとかなり機能的には重複しているのですが、キャディ独自のビジネスモデルや生み出されるデータセットに対応しつつ、プラットフォームのスケーラビリティをあげるため内製という形をとっています。
極めて複雑なドメイン構造を持ちつつ、一方で様々なユースケースが想定されます。将来的に想定されうる様々な連携や事業構造の拡大/変更も含めてイメージしながら、的確にモデルを構築しなければなりません。
キャディのようなスタートアップでは、事業を進めていくごとに市場に対して新たな発見を繰り返していくことになります。全てを予測するのは難しいですし、完璧を求めすぎる姿勢では何も進められなくなってしまうものの、そういったDevOpsを進めていける拡張性を意識してモデルとアーキテクチャーを形作っていく必要があります。
そういったDDDやアーキテクチャ設計が好き/強いエンジニアの方々と一緒に進められればと思っています。
また、この領域は複雑なエンタープライズのERPなどの設計や開発を行っていたSIや総合コンサルのエンジニアの方々などもフィットすると思っています。
バックエンドエンジニア:
一方で、オペレーション効率や取引のエコノミクスを分析するためのデータ収集のインターフェースという側面も持っています。様々な面白いデータを集められるのですが、特にオペレーションのデータの側面では「分析のためのデータ」というのは中々入力が徹底されません。そういったものでもストレスなく使ってもらうためにはそれぞれのユースケースやオペレーションフローを理解しながら滑らかに使ってもらえるようなUI/UXが不可欠です。
業務システムではそういったデザイン領域が中々定量的なバリューを示しにくいので、リソース投下の意思決定がされづらいのですがキャディではここに意識的に投資をしています。
キャディでは"Whole Product"という考え方を大事にしています。
全てを一足飛びに自動化を目指す訳でなく、闇雲にシステム化をするわけでもなく、オペレーションとプロダクトの良さをそれぞれ両輪で生かしながら、課題を解決していくスタンスです。
この過程ではソフトウェアに入ったInputに対するOutputをよりわかりやすく直感的にユーザーに伝え、より簡単に再Inputを可能にするといった、ソフトウェアとユーザー(オペレーション)のインターフェイスが非常に重要になります。
toBプロダクトや業務システムに強いプロダクトデザイナーやフロントエンドエンジニアの方とは是非お話させていただきたいですし、また業務システムであってもtoCプロダクトのような軽さや使いやすさの世界観を取り込んでいくためにそういったバックグラウンドの方々も大歓迎です。
デザイナー:
フロントエンドエンジニア:
また、そういったシステムから作り出されるデータを元に、製造業に新たなインサイトを作り出していくデータ分析に強い方々も是非お話させてください。
データ分析:
ここまでで、与えられた仕様に対してそれをきちんと発注につなげ納品するまでに関わるIssueを整理してきました。
しかしながら、実は私たちが実現しようとしているプラットフォームの重要なIssueはそれ以前にもあります。
受発注のマッチングにつなげるために仕様情報の型化をするのですが、そもそも顧客からくる仕様情報にはフォーマットや表現、チャネルにバラつきがあります。
フォーマット情報はテキストや図面で伝達されますが、テキストの書き方や図面のフォーマットもかなり個社ごとに異なります。図面の場合は3D CADファイルの場合もありますし、2Dのpdfファイルの場合もあります。それぞれの書き方自体もそれぞれの顧客ごとの書き方や使っているソフトによって異なります。それらがチャネルとしてメールで送られてきたり、FAXで送られてきたりします。
また、少し先述しましたが同じ文言を使っていても想定しているものやそのレベルが顧客ごとに異なってきます。「傷なし」といった時にどのレベルをを想定しているのか、それは慎重に合意しなければ納品時に期待していたものと違うという事態になってしまいます。
そして、上記を補完するように機能しつつも非常に取り扱いが難しいのが「コンテキスト」です。製造業では、多くの取引で馴染みのサプライヤーは取引の積み重ねの記憶から上記の不確実性を補完していきます。
ここの溶接はこうだけど、こっちの溶接はこう、のような細かい指定は実際には図面にもきちんと書かれていないケースがあります。そういった時、前回こうしてくれたのに今回も同じにしてくれると思ってた、といった行き違いが発生することがあります。「言わなくてもわかってくれよー」というやつですね。
そういった、コンテキストを前提にし、「察し合う」ことによって不足した情報の補完や不確実性の低減を行う商慣習が存在しています。
そういったバラつき/揺らぎ/暗黙知といった不確実性を、標準化されたInputにどうやって低コストに落とし込んでいくか、それが極めて大きなIssueになっています。
ここでは、テキスト情報の型化や、図面のpdfファイルの分割・統合、編集プロセスのプロダクトなど、様々な打ち手が考えられます。
フロントエンド、バックエンド、アルゴリズム、画像認識、OCRなど、多様なバックグラウンドの専門知識をいかに生かすか様々な構想とコンセプト検証が進んでいます。
キャディではすでに数千社の顧客や担当者ベースでいうとより多くの方々とコミュニケーションをさせていただいております。なのでもちろん通常のCRMをきちんとできなければなりません。
加えて重要なのは上記のコンテキストをどうやって蓄積していくかです。
仕様に対して補完的な情報を効果的に蓄積していくことで、取引を重ねるごとに顧客/キャディ/サプライヤーにとってより不確実性が低く、スムーズで手軽な取引を実現していきます。
このようなドメイン特有の情報の蓄積を、個々の取引のベースとして如何に生かしていくかが重要な観点になります。
これらのために複雑なDDDに強い方や、複雑な構造をわかりやすい表現に落とし込めるフロントエンドの方々に手助けをいただきたい・・!
また、製造業においては仕様や図面の情報は重要な知財です。それらをしっかりとしたセキュリティで守るインフラに強い方々もお待ちしております。
インフラ・SREエンジニア:
4. 全体を通底する難しさ
特に重要なIssueについてピックアップしてここまで書いてきました。
ここでは個別のIssueに関わらず、全体を通底している難しさについて記載してみたいと思います。
とにかく変数が多い・・!
製造業の領域では仕様・用途・プレーヤーなど様々な側面で非常に変数が多いです。それらの掛け合わせによって様々なパターンが生み出されるので、それらをどう構造的に整理、処理していくかが重要です。
かなり先述してしまいましたが、同じ言葉でもイメージされているものが微妙に異なってきたり、コミュニケーションや取引のタイミングで何が必須の情報であり、何が任意の情報かなど、明確な定義が存在していません。
決済やECなどの領域におけるデジタルプロダクトでは、そういったプロトコルをきちんと設計するところから進んでいきますが、そのプロトコルが明確になっていない状況です。
こういった状況で求められるのは
・現状の様々な個別事例をを地道にみていく
・その中でパターンを見出していく
・As IsとTo Beの両方をイメージして、どのように標準化していくかを決めていく
・標準化を決めつつ、それを成長させていく運用フローを設計する
といったことです。出来るだけ属人化を廃し、プラットフォームとして成長していくにはそういった標準化を自分たちで設定していく能力が重要です。
キャディで扱っている領域は製造業ですが、もちろんこの領域の専門知識があります。これを理解せずしてビジネスを作っていくことはできません。
ただ、複雑なこの領域では一口に専門知識といってもさらに細分化されます。例えば、何を作るかの仕様の知識と、どうやって作るのかの製造の知識はまた違った特色があります。
それらについてより詳しくなり、より質や効率性を上げていくには、それぞれの専門部隊を作っていくことが有用な場面があります。そして練度が上がってくる中で新たなインサイトにたどり着いたりします。
ただし、これが進みすぎる、あるいは同時並行的にサイロ化が進んでしまう場合があります。サイロ化とはある部門において業務プロセスや知識共有が、他の部門などとの連携が弱くなってしまい自己完結して孤立してしまう状態のことです。
一方で、システム開発において有名な法則にコンウェイの法則があります。これは「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というものです。
必ずしもそういった設計がアンチパターンかというとそうではないはずなのですが、もしサイロ化が顕著に進んでしまい、それぞれの組織に各々のシステムコンポーネントが向き合いすぎると、組織とプロダクト共に全体最適から遠のいたものになってしまう恐れがあります。各組織それぞれに個別最適化しすぎてしまうということです。
プロダクトの側面で見れば、こういった視点でバランスをとることは難しい問題です。コンウェイの法則と呼ばれる現象がありますが、この重力に対して自覚的であり、バランスをとることが重要です。
開発組織ではそういったビジネスサイドやオペレーション設計に対し、As Isを解像度高く理解しつつ、得てして発展段階で未成熟なそういったAs Is に対し、To Beがどうあるべきかを思い描きながらバランスしなければなりません。
プロダクトマネージャーとしては言い訳に聞こえるかもしれないのですが、一握りの要件定義をするロールの人間がビジネスサイドと開発サイドをブリッジするのではなく、お互いに高いレベルで壁打ちしあうことで検討や設計を深められるように、エンジニアやデザイナーも手を動かす時間を一定犠牲にしても事業側の構造・戦略・課題の解像度を高めることにかなり時間を投資しています。
よりスムーズなコミュニケーションや取引を進めようとすると、個別の顧客や案件に最適化が進みすぎる場合があります。
ここで個別化が進みすぎると、プラットフォームとしてのスケーラビリティが失われたり、開発やオペレーション改善を進めていく過程で前提が変わると負債になってしまいます。
ただ、「スケールしないことをしろ」という言葉がありますが、強烈に個別の事例を深く掘っていく作業が新たな事業としての気づきに繋がる場合も多々あり、それぞれに対してどのように対応していくかを判断する必要があります。
そのために、直近の自分のタスクに必ずしも関係ない事業状況や外部環境についてキャッチアップし解像度高くコンテキストを把握していくことが求められます。
ここまでで、かなりの回数登場していますが、「型化」「標準化」「構造化」は非常に大きなテーマです。
しかし、型化に踏み込むタイミングは非常に重要であり、難しい判断が求められます。
特定の型に沿って情報を蓄積していく体制になっていくと、コミュニケーションがスムーズになったり、データが綺麗に揃い分析可能になりビジネスをドライブしたり、属人性を減少させスケーラブルになっていきます。
しかし、キャディのようなスタートアップは「トライしなければわからないこと」の積み重ねを経て事業をつくっていき、そのナレッジを先行者として競争力にしていきます。理解の深まりが要因となって、1週間1ヶ月の短い単位で前提や戦略が変わっていく環境にあります。
そういった中で、型化を進めても、その型の延長線上にある拡張では対応できないような変化に直面することがあります。型の設計自体を変更に柔軟にするのも大事ですが、そもそもどれくらいの「固さ」になった時点で型化を進めるに踏み切るかは重要な観点です。まだまだ模索中のうちは多少の工数がかかってもマニュアル処理にしておき、柔軟性を保ち負債を作らないという意図的な判断も必要です。
先に出てきた"コンテキスト"も重要かつ難しい要素です。
例えば、Amazonで本を買う時前回までの取引がこうだったから、今回は・・のような情報の引き継がれ方はそれほどありません。それぞれの購買は一つ一つShotのものとして独立しており比較的ローコンテキストと言えます。
一方でSaasのようなサービスでは取引はずっと連続的に続いており、情報は徐々に蓄積されたり、改善されたりし文脈が常時引き継がれています。比較的ハイコンテキストなモデルです。
キャディのプラットフォームの難しいところはその中間をついているところです。
常に連続的に取引をしているわけではないですが、多くの取引においてそれまでの取引で合意してきたことを察しあうことが暗黙的に期待されています。それによって明文化されていない情報を補完したり、表現の揺らぎを一意に解釈したりなどです。
もし、営業マンが2,3社少数の担当先と、それぞれに大きな比重を持って長期間付き合い続ける体制ならばあまり気にする必要はありません。
しかし、ここのオペレーションコストを仕組みかとテクノロジーによって下げ、より多くの方々にバリューを発揮できるような状況を作り出すために、このコンテキストの扱いの問題にきちんと取り組んでいく必要があります。
5. 少し、未来の話
さてここまで、今今キャディが取り組んでいるIssuesについてそれなりに詳細に書いてきたのですが、少し未来の展望についても触れておければと思います。
それは、今だけを見ればちょっと自分は違うかな、という感覚の方々でも少し将来の展開を見据えれば重なる部分を見つけられる可能性があるからです。そうはいっても、10年20年先の話ではなく数年スパンでトライしていくはずの未来なのでいつでもお話できればと思います。
今キャディは受発注の領域にフォーカスをしています。
顧客側にもサプライヤー側にも関わっています。それは顧客側で言えば調達、サプライヤーでは売上そのものという、経済活動において最も大きな部分を占める取引に関わることです。
さらに、単純に取引の決済だけではなく、その中身がなんなのかをしっかり把握・理解しながらでなければ成立しないプラットフォームです。
ここを基点に、周辺で価値を広げられるはずの領域はたくさんあります。
例えば、サプライヤーのファイナンスの領域。
取引を重ね、サプライヤーの持っているポテンシャルを単純な会計情報以上に、製造業の知見をベースにしてデータで評価することができます。
ポテンシャルが十分にあるにも関わらず、資金面でアグレッシブな投資が難しいサプライヤーはたくさんいます。
そうした面でファイナンス領域でキャディが貢献できることは増えてくるはずです。
もし、「製造業」という観点だけに囚われてしまうと遠く感じてしまうかもしれませんが、例えば金融領域で複雑なプロダクトに関わっているエンジニアの方々がいたら、ドメイン知識と開発力の両方でお力添えいただける可能性は高いです。
その時のために、今からこういう設計で開発しておいた方がいいよね、といったこともおそらくいろいろあるはずだと思うのです。
ファイナンス領域は一例で、こんな風にいろいろな接点を見出せる展望を持っているので、製造業という言葉が先歩きしすぎずお話ができるといいなと考えています。
6. 意味的側面
キャディがやろうとしていることの意味合いはなんなのでしょうか?
モノづくり産業に関わらず、「取引コスト」という観点でそれを見てみる話を以前キャディでは発信させていただきました。
製造業の領域の決めは、キャディにとって非常に大きな意味を持っていますが、特にデザイナーやエンジニアの方々で製造業やモノづくり産業に現時点で接点が多い方々となると非常に少なくなってしまいます。
しかし、少し引いた目で見ればキャディのやっていることの意味合いをもう少し馴染みやすくお伝えできると思っていますし、他の業界とも共通点が見出せると思っています。
キャディの一つのトライは、発注側にとっての調達や、受注側にとっての営業活動・見積といった領域を簡単にすることです。
そういう部分の工数や憂いを取り除ければ、「いいものを作る」「新しいものを作る」という本質的な価値に製造業がフォーカスできます。
ShopifyのようなカートASPのプラットフォームは、ものの売り手がECサイトのカートシステムや物流の管理をする部分を提供し、小さい売り手等でも自分たちの商品を作る部分にフォーカスしつつ店舗を持つことを可能にしています。そのアプリケーションプラットフォームでは、様々な他の機能の提供も進んでいっています。
WordpressのようなCMSは、魅力的な記事を作るネットユーザーが、サイト構築や管理、分析のようなコンテンツ以外を簡単にし、コンテンツの内容に集中することを可能にしてきました。
こういったものと同様の価値を製造業の"Makers"に対して提供していけるはずです。
D2Cという言葉が流行って定着してきましたが、より正確な(あるいは狭義の)言葉としてDNVB(Digitally Native Vertical Brand)という言葉が出てきています。
Direct to Consumerという言葉では、旧来よりある通販などもその言葉上のニュアンスに含まれるため、CasperやDoller Shave Club、Warby Parkerなど新世代に生まれてきたブランドに対してより明示的に表現した言葉です。
インターネットの成熟は、マスメディアと異なる情報の流れを生み出しました。特にSNSではディレクトリ型や検索型のサイトに比べ、より情緒的であったり、よりバイラル的な要素が重要です。
この情報流通の流れは今までよりニッチな層に対しても正確にリーチする手段を、小さなブランドに与えてきています。
もし、TVCMのようなマス的なリーチ手段しかないならば、10000人のうち5000人が潜在的な消費者になり得るマス商品なら良くても、10000人のうち10人しかいないようなニッチな嗜好性を持つブランド商品ではマーケティングの効率が合わず成り立ちません。
SNSのタイムラインアルゴリズムや、ハッシュタグ、シェアなどの情報流通はニッチな層にだけ受ける世界観を持つブランドでも、潜在ユーザーに効率よくリーチするマーケ手段の獲得を許してきました。
小さく散り散りに存在してる潜在顧客をより広くから効率的に集め、ブランドロイヤリティを高められるようになっています。
私たちの接しているサプライヤーの中にも、非常にまれな製造が得意なサプライヤーがいます。
ただ、その得意領域だけでは十分に売上が立てられないケースも多いのです。日本全国を見渡せば、あるいは世界に目を向ければ、一つ一つは小口でも積分でたくさんの潜在市場があり得るのに、そこまでリーチが及ばないのです。
そういったニッチな強みを持つ、小さいプレーヤーがきちんと情報流通の最適化で、自分たちの技術を求めている散り散りに存在する顧客に効率的に繋がることができ、経済的に健全に成り立つ状況を作っていくことは他の領域でも進んできていることだと思います。
これは、キャディのビジネスが持っている意味合いというよりは、個人的な興味の観点が強いのかもしれないのですが、製造業にきちんと情緒価値が伝播するといいなと思っています。
製造業では基本的に機能的価値が流通します。
どういう機能がある装置で、どういう強度がある部品で、どういう製造ができて、どんな品質で、といった具合です。
こういった市場でそういった価値をきちんと発揮し、正当な価格で売り、稼ぐことはいうまでもなくとても重要です。
そもそもそれがなければ食っていくことができませんし、貧すれば鈍するという言葉もあります。
それを前提とした上で、機能だけを生み出すために効率性のみを追求することはそこに従事する人を最終的に幸福にできるのか、というのは直近10年20年の間で問われてきていることではないでしょうか。
もちろんこれは製造業だけでなく、どんな世界でも同じだと思いますが、特に機能的価値が最優先事項になってくるこの業界において、誰の役にたったとか、これができるのは世界で自分たちだけ、というような誇らしさとか、どういう苦労があってそんな特殊な加工ができるようになったとか、そういった情緒価値がしっかりと意識され、伝播していくプラットフォームやプロダクトでありたいなと思っています。
DX(Digital Transformation)という言葉が流行っています。
特に、ECや広告のような大きくすでにインターネットやクラウドといった技術の恩恵を大きく受けてきた業界というよりも、製造業や建設業、保険などレガシー産業と言われる産業の文脈で使われることが多いような気がします。
キャディの場合はもともとデジタルな側面はもともと存在しています。キャディはそもそもCEO加藤とCTO小橋の2人で創業され、創業以来社内のテクノロジー本部とともに事業を進めてまいりました。
(創業者紹介:
キャディがトライしているそのスタンスは、製造業で行っているビジネスをデジタル化していく、というよりもデジタルが空気のように、当たり前に存在している前提で、製造業の取引・受発注を考えるとどういうものになるか、という視点が元になっているといった方がいいかもしれません。
その意味でDigital Orientedといった具合なのかなと思います。
ここまで書いてきて、難しい難しいと連呼しているのですが(笑)、まだまだいろいろなバックグラウンドの方々の助けを必要としています。
そして、この問題が解くべき問題であり、そのバリューの大きさには確信を持っています。
この記事では「課題」により重きをおいて書いてきましたが、より技術的なHowの部分についても発信を続けていければと思います。
開発チーム(プロダクトマネージャー/エンジニア/ デザイナー)はもちろん、ビジネスサイドの方も絶賛採用中ですので、ぜひお声掛けください。
エンジニア専用の採用サイトはこちら:
こちらのサイトからはカジュアル面談にもご応募いただけます。
Rust版のサイトはこちら:
ビジネスサイド含めた募集ページはこちら:
この記事が気に入ったらサポートをしてみませんか?