キャディのプロダクトマネジメント～製造業のグローバルプラットフォームを創るということ～
キャディでプロダクトマネージャーを務めている笹口です。
この度キャディでは、プレスリリースでの発表の通り、シリーズBラウンドで80.3億円の資金調達を実施しました。2030年までに売上高1兆円のグローバルプラットフォームを目指し、受発注にとどまらず、設計から製造・物流・販売までのバリューチェーン全体のDXを加速し、製造業のデジタル化におけるデファクト・スタンダードを構築していきます。
このnoteでは、上記に実現についてキャディのプロダクトマネジメントが担う役割、これまでの歩みとこれからの未来についてお話しできればと思います。9/1開催のウェビナーでもお話しさせて頂きますので、ご都合つく方は是非こちらにも参加ください！
また、シリーズB前後のキャディの概況については社長室芳賀の書いたこちらのnoteを是非ご覧頂ければと思います。
キャディのPM4類型とその役割について
まずは、キャディのプロダクトマネージャーの役割についてお伝えできればと思います。
現在キャディにおいてプロダクトと呼ばれるモノは8つあり、これを計6名のプロダクトマネージャーがみています。以下はその一部です。
各プロダクトのもう少し細かな内容や、これまでのエンジニア組織の変遷などについては是非こちらのCTO小橋のブログをご覧ください。
－－－
さて、プロダクトマネージャーの動き方や責任範囲はその会社によって異なるのが常ですが、特にキャディの場合はtoCやSaaSのようにITプロダクトそのものが収益源となるビジネスモデルではないため、プロダクトマネージャーの担う役割が特に見えづらい性質があるかと思います。
プロダクトマネージャーの役割についてはこれまでも変化してきているため、今後も変わっていく前提ではありますが、現時点での役割は以下の4つに分けられます。
プロダクトマネージャーの役割
前提として、キャディのプロダクトマネージャーは全員が1つ以上のプロダクトのオーナーを担っています。
ここでいうプロダクトオーナーの役割は、ロードマップの策定やProduct Backlog上のエピック及びチケットの優先度判断、関係部署との調整に基づく意思決定などです。
また、キャディにはプロダクトマネージャーのジュニアとしてAPM（アソシエイトPM）というロールがあり、純粋に1つのプロダクトまたはコンポーネントのオーナーとして振る舞います。それに対して、プロダクトマネージャーは複数のプロダクトのオーナーを兼任したり、プロダクトに閉じないより広範な責任を併せ持つなど、より大きなスコープでの価値創出が求められるのが特徴です。
そのため、キャディのプロダクトマネージャーは部下の有無に限らず基本的にリーダーロールとして扱われ、Biz/Tech双方において経営に非常に近いポジションでの経営戦略理解及びプロダクト戦略の構築、実行が求められます。
これらを前提として、続いて以下4つのタイプについて見ていきたいと思います。
1. ドメインオーナータイプ
プロダクトとそのプロダクトがカバーするドメインについてセットでオーナーシップを持つタイプです。
プロダクトごとにカバーするドメインの広さには差がありますが、例えばKLEIN（サプライチェーン管理プロダクト）の場合、物流・検査まで含めたサプライチェーン全体という広い範囲をカバーしています。各工程にはそれぞれの専門家がいますので、KLEINのプロダクトマネージャーは彼らと密に連携しつつ全体を俯瞰し、ドメイン解像度を高く保ちながらプロダクトオーナーを担うことになります。ドメイン全体のイシューを高解像度で把握できかつ解決策となるプロダクトのオーナーシップも同時に持つため、ドメイン単位で戦略と実行を一致させることができる点が大きなメリットです。
2. 事業兼任タイプ
プロダクトのオーナーシップとそのプロダクトの関与度が高い事業部のロールをセットで持つタイプです。
私自身がこちらに該当するのですが、QUIPU（原価計算プロダクト）のプロダクトオーナーに加えてオペレーション効率化に寄与する2つのプロダクトのオーナーを兼務しつつ（APM絶賛募集中です）、弊社でリテンションフェーズと定義しているアカウント群のユニットエコノミクスに責任を持ちながら、標準的かつリーンなオペレーションの型化/浸透にオーナーシップを持っています。
1のタイプのようにドメイン単位できれいにカバーしきれてはいないのですが、BtoBビジネスではプロダクトの優先順位が事業の優先順位にアラインすることが多く、事業/プロダクトともにオーナーシップを持つあり方は戦略と実行の一致という点でもメリットがあるため、toBプロダクトマネージャーのあり方として一つのモデルになっていくべきと考えトライしてみているところです。
3. テクニカルPMタイプ
コンピュータービジョン/機械学習/データサイエンスなどのテクノロジーに関する専門性を主軸とし、それらがキーテクノロジーであるプロダクトのオーナーを担うタイプです。
それぞれの技術領域についてエンジニアと肩を並べるほどの専門性を持ったプロダクトマネージャーというと、市場的にもまだまだ希少な存在として扱われることが多い人材ですが、キャディではニーズの高まりと共に徐々に仲間が増えてきています。
こういったプロダクト開発はR&D的な側面を持ち、プロダクトアウト的な発想で機能活用を考えていく必要もあるため、プロダクトマネージャーにも高い技術理解が求められます。その分ドメインやビジネス面でのオーナーシップは求められませんが、プロダクトの価値創出を考える段階ではそれらを解像度高く理解することは不可欠であり、そのベースとなる高い戦略理解・事業理解が求められる点は他の類型と同様です。
4. 新規事業タイプ
既存のドメインやプロダクトについてはオーナーシップを持たず、新しい事業開発にコミットするタイプです。
現在キャディでは新規にSaaSプロダクトの開発を進めており、以前は1のドメインオーナータイプのプロダクトマネージャーを務めていたPMが役割を変えてフルコミットしています。
なお、現在こちらの新規プロダクトを一緒に開発してくれる方を積極募集中です。とても刺激的な開発だと思いますので、ご興味のある方は是非ご一読下さい。
－－－
今回は4つの類型にまとめてみましたが、今後プロダクトの数も種類も増え、プロダクトマネージャーとしてもより多様なスキル・経験が求められてくることになると思われます。少しでもご興味あれば、（上記の4つに当てはまらない）と思われる場合であっても、まずは下記リンクからのご連絡をお待ちしております！新しいプロダクトを共に生み出していきましょう。
シリーズAの調達からシリーズBまでのプロダクト開発の軌跡
ここからは、キャディがこれまで進めてきたプロダクト開発についてお伝えしていきたいと思います。
－－－
最初の意思決定
私がキャディに入社したのは創業から1年半ほどが経った頃で、同期の白井と共に初めてのプロダクトマネージャーとして入社しました。最初に手掛けたのはあるべきオペレーション像の定義とボトムアップの課題抽出、そしてそれらを解決するプロダクト構想の整理でした。
とはいっても、当時のオペレーションはなかなかのカオス。標準的な型はなく、ヒアリングする人によって全く違うオペレーションをしているのは当たり前。それもすぐに変わっていき、中央集権的に管理されていないsalesforceにはすぐに使われなくなる項目たちが日に日に足されているような状態でした。（今だから笑える話ですが、当時は真剣に頭を抱えました）
当時はエンジニアもアルバイトを含め10名足らずで、デザイナーもおらず、自分たちでワイヤーフレームを描いていました。リソース的に、本格的に開発着手できるプロダクトは2つが限度。それも、事業が著しく成長し変化していく環境で、本当に将来に渡って価値ある開発なのかを見定めて意思決定する必要がありました。
検討の末、サプライチェーン管理プロダクトであるKLEIN、原価計算エンジンであるQUIPUの2つを開発することに決めました。重視したのは、今後指数関数的に増加することが見込まれたオペレーション負荷を可能な限り低減するための効率化と、それまで構造的に蓄積されないまま流れていたトランザクションデータのアセット化の2点です。プロダクト開発にはどうしても一定の期間が必要になります。だからこそ、先を見据えた上で最もROIの高くなる開発を仕込む必要がありました。KLEINもQUIPUも非常に開発では苦労することになるのですが、今でもこの時の選択は間違っていなかったと思います。
事業成長＝要件追加というジレンマに打ち勝つ
プロダクトローンチまでの期間も、Bizメンバーは間違いなく事業を成長させてくれるだろうという信頼がありました。それは裏を返せば、開発中も確実に要件が増えるということを意味しました。
そこで、初めからとにかく変更に強い作りを意識した開発を行いました。特にドメインモデリングには力を入れ、テックリードと毎日、長い時で半日以上ホワイトボードに向き合いながら、思いつく限りのイレギュラーケースを想定してモデリングを進めました。そこまでやっても、開発中にドメインモデルに影響のある追加要件が発生してしまい、その都度リファクタリングを行いながら開発を進めました。また、要件追加のペースが開発のベロシティを大きく上回る時期が続くなど、非常にタフな開発でした。一緒に乗り越えてくれたチームのみんなには心から感謝し、信頼しています。
なお、QUIPU（原価計算エンジン）の開発についての学びはこちらのスライドにまとめてあります。
両プロダクトのローンチと図面へのアプローチ
2つのプロダクトがローンチを迎える少し前、CTOの小橋が「図面を管理するプロダクト」の構想を打ち出しました。これが今のHERODOTUSに当たります。
キャディが向き合う多品種少量生産の世界において、最も多く流通している情報媒体がこの図面です。
近年では3D CADを用いた設計が一般的になってきています。しかし、非常に残念なことに、設計段階では3Dとして表現されている設計指示情報が、調達工程に渡る際に2D/画像情報へと変換されてしまうケースがとても多いのです。要因は様々ありますが、結果的に情報が大きく劣化することになり、これは製造業が抱える大きな課題のうちの一つだと捉えています。
将来的には、この課題もキャディのサービスによって解決していきたいと考えています。しかし、そこへ到達するまでの道のりは長く、このタイミングで図面と向き合うという意思決定は、今のキャディにとって重要なものでした。このHERODOTUSを軸に、図面処理を効率化するための開発が積極的に行われ、それが先にご紹介した新規プロダクト開発へと繋がっていきます。
製造業のグローバルプラットフォームを創るということ
最後に、今後のプロダクト開発の展望について触れたいと思います。
－－－
見えてきた次のフェーズへの足掛かり
2021年に入り、元々オペレーションの効率化とトランザクションのアセット化を企図したプロダクト開発と事業への浸透が進捗したことで、明確に次のステップが見えてきた感覚を持つようになりました。
特に大きかったのはアセット化です。愚直なプロダクト開発とオペレーションの改善を繰り返した結果、現在のキャディには非常に細かく、かつ広範なデータが構造的に蓄積されるようになりました。既に、これを元にしたMLの活用の動きも始まっています。
これまでのとにかくデータを蓄積することに腐心していたフェーズから、活用のフェーズへ。プロダクトマネージャーにとって最高に腕が鳴る環境が生まれつつあります。
製造業のグローバルプラットフォームを創るための3つの方向性
図らずも、プロダクト開発において明確にフェーズが変わろうとしているタイミングで、会社としてもシリーズB調達という節目を迎えました。今後はより一層明確に、製造業のグローバルプラットフォーム構築という目標を目指して突き進んでいくことになります。
以下で、その上で重要になってくる3つの方向性についてお伝えしたいと思います。
－－－
1. 受発注領域のさらなる進化
今回キャディのフェーズを進めた要因がトランザクションのアセット化にあるとお伝えしましたが、これはつまり、キャディがサプライチェーン/オペレーションをデジタルに処理できるようになったということを意味します。
キャディ創業直後には何もない状態でビジネスを回せていたことからもわかるように、キャディのビジネスは極論電話とメール、紙とFAXさえあれば回せてしまいます。しかし、ここでやりとりされる情報の大半がアナログな情報であり、構造的にデータとして蓄積することができません。これを、処理するだけでデータが溜まる状態に持ってこれたことに価値があるのです。
とはいえ、まだまだサプライチェーン/オペレーションの全工程をデジタル化できたわけではありません。未活用の技術も取り入れながら、キャディのコアである受発注領域をさらに進化させ、その全てをデジタル化していきます。そうすることでキャディが生み出す付加価値の増加にも繋がりますし、キャディが内製で培った技術そのものが価値となり、それらをお客様/パートナー様に使って頂くという形での価値提供にも繋がっていきます。
付加価値を増大することでさらなる取引を獲得し、取引量の増加をさらなる効率化で実現しながら、そのトランザクションを全てデジタル化・アセット化していくことでさらなる付加価値を生み、それを製造業全体へ敷衍していく。キャディという会社自体が、製造業全体の取引をデジタル化/効率化していく機構になっていくのです。
2. 新領域への展開による価値創出
既に動き始めている新規プロダクト開発のように、受発注領域に閉じない価値創出にも本格的に取り組んでいきます。
その元になるのは社内に蓄積されたデータかもしれませんし、内製で生み出した要素技術かもしれません。いずれにせよ、製造業という極めて裾野の広い産業のポテンシャルを解放していくためには、相応のサービスラインナップを揃える必要があります。
受発注をコアとしながら、データ/テクノロジーを活用した様々なソリューションを併せて提供していくことで、キャディの製造業プラットフォームとしての価値は高まっていきます。さらに、各サービスで新たに得られるデータもまた受発注の効率化に寄与したり、次のサービスの元になっていったりしますので、複利が効いてきます。
3. グローバル対応
3点目はグローバル対応です。これは、ただ単に多言語対応する、ということではありません。
サプライチェーン/オペレーションの観点でいえば、OCEAN/AIRという新しい輸送形態に対応していく必要がありますし、国による商慣習の違いにも対応できるようになる必要があります。これらはおそらくドメインモデルに少なからず影響を与えるでしょうし、開発自体も日本で行う以外の選択肢が生まれてくるかもしれません。そうなれば、プロダクト開発の手法にも必然何かしらの変化が求められるでしょう。
国を跨げば品質や納期に関する考え方も変わってきます。作っているものが変われば、必要とされるモノにも相応の特徴が表れてきます。これらを全て取込み、デジタルなサプライチェーン/オペレーションとして拡張していくことで、キャディは製造業のグローバルプラットフォームにまた一つ近付いていくことになるのです。
おわりに
最後に、改めてキャディでプロダクトマネージャーとして働くことの面白さをお伝えしたいと思います。
こちらは、先にご紹介した弊社CTO小橋のブログからの引用です。
これだけ社内で貴重なデータが溜まっている一方、製造業は当然物理的なものを扱っているため決してデジタルの世界で全てが完結しません。パートナー加工会社はデジタル設計情報を実物に変換していますし、我々の検査拠点では制作物を開梱してノギスやハイトゲージで確認していますし、受発注の全ては最終的に実世界の実態とデジタル予定情報の突き合わせに収束します。今後はより物理とデジタルの世界の往復に挑戦し、データを片方の世界に滞留させない事が operational excellence とも言えるかと思います。
2000年代、webは大変な進化を遂げました。Marc Andreessenの"Why Software Is Eating the World"はあまりにも有名ですが、こと日本においてはまだまだソフトウェアが浸透していない領域が多く残されていると感じています。
ソフトバンクの孫正義社長は、ビジョンファンドの設立に際し「インターネット業界が革新したのは、たった2つ。広告と小売。広告は米国のGDPでたかだか1%、消費者向け小売は6%に過ぎない。これだけの世界のトップ10のうち7社をIT企業が占めている。今後、AIは残り全部を革新する」と述べました。AIが全ての解決策になるとは思いませんが、インターネットによる革新が届いていない業界が多いという点はまさにその通りだと思います。
キャディで、世界の製造業を変えましょう。モノづくり産業のポテンシャルを解放しましょう。
キャディのプロダクトマネージャーは、この挑戦を最前線で担えるロールです。インターネットだけ、AIだけでは不十分です。製造業をはじめ、残された領域には必ず物理/アナログのレイヤーが存在します。これをデジタルな情報に変換するコストは、誰かが善意で払ってくれるものではありません。それが自然に払われる仕組みが必要です。そこには必ず人の手が介在します。つまり、オペレーションが必要不可欠です。これら全てをスコープに詰め込んで、どうすれば目の前の課題が解決できるのか、サプライチェーンをデジタル化できるのか、一緒にとことん悩みましょう。
時に苦しい場面もあるかもしれません。私にはあります。でも同時に、本当に面白い仕事をしているという自信があります。難しいから面白いんです。
ご連絡をお待ちしています。
この記事が気に入ったらサポートをしてみませんか？