こんにちは、キャディでエンジニアやエンジニアリングマネージャをやっている高藤です。 久しぶりのTechブログへの投稿です。
今回はタイトルにあるようにCADDiで4年働く上で起きた事をエンジニア視点でまとめつつ、これから何をしようとしているのか私自身の思いを込めて書いてみようかなと思います。
4年前のあのころ
私は2019年2月に入社し、4年強の期間CADDiで働いてきました。私が当時CADDiに興味を持ったのは、単純に面白い経歴のCEOとCTOがなぜ日本で起業したのかという興味と私自身が成長できる環境で働きたいという2点でした。
正直な話、CADDiが対象とする、製造業ドメインへの興味は全くありませんでした。
当時のCADDiではWebから流入するたくさんの顧客に対して見積を自動で行い、見積頂いた顧客からくる製造依頼に対して製品を納品していました。これらの業務は当時フォーカスをしていた3D CADからの自動見積を行う技術や頂いた図面から見積に必要な入力を人力で抜き出し、社内の見積ロジックを使ってコストを算出するオペレーションを通じて実現していました。
まだまだ、複雑なオペレーションを人力で行っている状況も多く、流入する顧客数の増加に伴い、複雑なオペレーションを支えるための仕組みが社内で必要とされているタイミングでもありました。
当時私達が採用していた技術をまとめると以下のものがありました。
- 3D CADを解析して見積に必要な入力値を解析するC++で記述されたアルゴリズム
- 入力値から製造コストを算出するC++で記述されたロジック
- 製造コストを算出するためのExcelで記述された計算モデル
- 3D CADをアップロードし見積/製造依頼ができるWebアプリケーション
受発注管理の課題から生まれたKleinというプロダクト
当時の受発注の仕組は社内で用意されたSalesforceを軸にオペレーションを構築していました。しかし事業のスケールを見据え、より大量のトランザクションに耐えるオペレーションを実現するため、2つの大きなプロダクトを開発する決断をしました。
1つは顧客からの見積リードタイムを減らすため見積ロジックを担うQuipuと呼ばれるプロダクト。もう1つは受発注管理を行うKleinというプロダクトです。私は後者のKleinというプロダクトの開発に携わってきました。どんなプロダクトなのかは弊社白井の記事を見てもらったほうがわかりやすいかと思います。
また技術面としても開発言語をRustにするなどいくつかの大きな決定を行いました。当時Rustを選択した経緯などは別の記事でまとめてありますが、今ふりかえると自分でもよく決断したなと思ったりもします。Kleinの開発を通して私達が学んだことは大きく2点あると思います。
ドメイン駆動設計
Kleinの開発を通じて最も学んだことは「ドメイン駆動設計」を採用した事です。当時の開発チームはプロダクトマネージャーの白井も含め製造業出身のメンバーがおらず、ドメインナレッジが全くない状態からのスタートでした。
私達は「どのような業務プロセスにしたいのか」「どのような課題を解きたいのか」を明らかにしないと前にも進めない状態でした。またCADDiの成長に伴いプロダクトに求められることも変わると予測していたため、プロダクトの中核部分であるドメインはその時に見えている範囲で正しく設計したいという判断を行いました。
一言にドメイン駆動設計と聞くと、エンジニア視点ではどのように実装するのかという部分に目が行きがちですが、その本質は開発対象となるドメインについてどれだけ理解している状態で開発できるかが重要です。そこで、ドメインエキスパートとチームで徹底的に議論を行い、プロダクトの設計にあたりました。
具体的には毎日昼食時にはチームとドメインエキスパートである業務担当者を招き、徹底的にヒアリングとホワイトボード上でのモデリング繰り返しました。これらのプロセスを通じてユビキタス言語の構築したことで、エンジニア自身が現場で起きていることをクリアに理解でき、同じ言葉を使って議論できるようになったことが大きな学びでした。
新しい技術の採用
前述したRust以外にも通信プロトコルとしてのgRPC/GraphQLの採用を行いました。これらの新しい技術の採用過程には、解きたい課題に使う技術が合致しているかという問いだけでなく、新しい技術を使ってみたいという感情的な理由もあったかなとも思っています。それらの決断に対して「だめだったら考え直せばいいじゃん」「学べば良いでしょ」という開発組織の空気感があったことも支えになったと思っています。初めて利用する技術については我々の無知故にハマった数々の落とし穴など数え切れないような失敗も経験しましたが、ここで得た知見は現在でも資産になっています。
おや、CADDiのようすが
前述のKleinの開発と前後してCADDiが大きく方針を変えたのもこの頃でした。前述したとおり、当時のCADDiはWebからの受注を主としており、事業の成長としてもより多くの顧客からWebを通じて取引が発生する事を計画をしておりました。
しかしいくつかの理由からこの方針を変更することになりました。一言でまとめると以下のようなことだったかと思います。
「顧客の要求が顧客毎に異なりCADDiとして標準化した要求としてまとめることが難しかった」 これは品質などに対する要求が顧客毎に異なること、そのような品質を業界や用途向けに統一的に定義し、それを顧客に提示し受け入れてもらうことがが難しかったということになります。当たり前ではありますが、1スタートアップの小さい会社が標準化された仕様を作り上げたとしてもそれを受け入れてもらう交渉力はなかったと思います。
そこで、CADDiは顧客を徹底的に絞る決断をしました。今までは顧客が持つ装置の一部分の部品に対する調達依頼を受けていましたが、この方針転換により、装置一式などより大きい単位で依頼を受けることになりました。この変更によりプロダクト開発側としても様々な点で考慮が必要になりました。
プロダクトに求められる要件の変化
当初、顧客との取引においてCADDiが調達を行う製品数は20製品ほどが多く、プロダクトの設計においても20製品程度の納品を行う案件を大量に処理するオペレーションを想定していました。しかしこの方針転換の実施後、1回の取引で1,000製品を超える取引が発生するようになりました。
Kleinなどオペレーションを担うプロダクトは小さい案件を大量に処理することから、大きな案件を問題なく完遂するための大量の製品に対する操作が必要になるなど、当初想定していた機能ではオペレーションを支えきれないことがわかりました。
これらの問題を解決するためにプロダクトに対して一括で処理を行う機能の提供を行ったりなど、大きな案件を処理する上で必要な機能の追加や大量の処理を行った際のパフォーマンスを改善することを行ってきました。
より深いドメインナレッジの獲得
大きな意思決定ではありましたが、より顧客にフォーカスし特定の業界における産業装置に対する知見を獲得することができました。また大きな調達プロジェクトにおいて、どんな事が発生するのかなど数え切れないほど学びを得ることができました。
これらの新しいドメインナレッジは単純に既存プロダクトの改修だけには留まらず、新しいプロダクトの種にもなったと思っています。
CADDiにおける生産管理プロダクト
前述の大きな転換を行いながらも、CADDiは大きく成長してきました。私が入社した4年前を考えると比較にできないくらい大きい案件の調達を行っています。また、当初のCADDiでは基本的には受注生産を行ったオペレーションを行っていましたが、案件の規模が大きくなるにつれ、見込み生産を行い在庫を持つような取引も発生しています。
私が当初開発を行ったKleinでは受注生産モデルとして設計していたこともあり、こういった事業の成長に対してモデル自体を刷新する必要もでてきました。こちらは既存のKleinというプロダクトを改修する判断ではなく、根本からモデルを刷新するためプロダクトのリプレイスを実施しました。
顧客との取引を重ねることで製造業における図面管理の難しさに気づきました。現在CADDiが提供しているSaaSプロダクト「CADDi DRAWER」の原型となる図面管理プロダクトの開発も行い図面の世代管理や図面を介したコミュニケーションの改善を行ったりしています。
また、単純に受発注だけの管理だけでなく、製造を引き受けていただく加工会社様とのコミュニケーションを円滑にするためのプロダクトや倉庫での在庫管理や倉庫内オペレーションを支援するためのプロダクトを開発してきました。このように事業拡大と共に必要な課題を様々なプロダクトを開発・運用することで解決してきました。
これらの開発を通じて得たナレッジはエンジニアだけでなくCADDiの資産になっています。他方でCADDiの生産管理プロセスにおいてCADDi独自のナレッジや解決させるためのHowになっている部分と多くの企業と同様のアプローチで課題解決を行っている部分が出てきていることも事実です。
サプライチェーンのデータを資産化する
ここまで、今のCADDiのプロダクトの開発とその開発や課題を解決することで得たナレッジについての話をしてきました。私は現在「CADDi DRAWER」というCADDi初のSaaSプロダクトの開発を行っています。CADDi DRAWERについては以下の2つの記事をみてもらったほうが良いかなと思います。
この新しいプロダクトはCADDiで私達が経験した課題やその解決方法から生み出されたプロダクトです。現在は主に「図面」という製造業における重要なデータを取り扱っています。しかし製造業においては、図面以外にも様々なプロセスから情報が発生しています。それらはデータとしては存在しているのですが、資産として扱える状態ではないと考えています。
今後CADDi DRAWERには製造の各プロセスに関するより多くの情報をが蓄積され、それら情報から課題発見や意思決定を促すプラットフォーム基盤になると考えています。これらは私達が受発注プラットフォーム事業を行ってきたからこそ実現できることだと思っています。もちろん解くべき課題も多く、技術面だけでなく大きくなってきたCADDiの開発組織がより生産的に活動できるようにするにはどうしたら良いのかなど多くのことに取り組まないといけない状況です。
さて、なぜ私は働いているのだろうか？
製造業という未知の領域にCADDiのエンジニアとして飛び込んで、4年と少し働いてきました。製造業における課題を少しづつではありますが見てきたつもりです。最後になぜCADDiにいるのかをまとめて終わりにしようと思います。
記事の冒頭で記載したとおり、当初、製造業というドメイン自体への興味はありませんでした。4年間濃い経験を過ごすことができた結果、製造業という産業自体の課題をエンジニアとして解決してみたいと思うようになりました。
私が今後CADDiを通してやりたいのは「製造プロセスの中で標準的なプロトコルを定める」ことです。CADDiへ飛び込む前は製造において図面さえあれば顧客が望むものは製造できると考えていました。その意味で図面は1つの標準プロトコルだと捉えていました。ですが製造業の中で働く中で、図面だけでは顧客が望んでいるものを納品できないという現実が見えてきました。
顧客が望むものを納品するためには図面を元にした要求事項の確認が必要であったり、なかには図面で表現できていないことや過去の商習慣から生まれた暗黙知など、取引において図面以外のコンテキストが必要になります。このような標準でないプロトコルをCADDiが取引に参加することで標準化を促したり定義できると考えています。これは今まで行ってきた受発注プラットフォームや「CADDi DRAWER」どちらを通じても実現できるだろうと考えています。
こうした産業へのインパクトを起こせる仕事というのもなかなか無いと思っています。このようなチャレンジをできるCADDiだからこそ面白いと改めて実感しています。
（なお、この4年間は、本当にきついと感じることは何度もありました。ですが良い仲間に出会えお互いを支えられる関係でここまで仕事ができました。本当に感謝しています。）
本記事を読んで、CADDiのミッションやプロダクト組織に少しでも興味を持ってくださった方。お気軽にカジュアル面談でお話ししませんか。 https://open.talentio.com/r/1/c/caddi-jp-recruit/pages/78398
プロダクトマネージャ、ソフトウェアエンジニア、セキュリティエンジニア等、様々なポジションを募集しています。 https://open.talentio.com/r/1/c/caddi-jp-recruit/homes/4139?group_ids=8633
ご連絡お待ちしています。
