はじめに
ご無沙汰しております。キャディでCTO務めております小橋です。
先ほど製造業のモノづくりに直接関わっていたキャディならではの製造業向けSaaSプロダクト「CADDi DRAWER」のプレスリリースを出しました。この数年間、物理的な製造・検査・納品をしながら培ったドメイン知見とソフトウェア技術をレバレッジして、ソフトウェアを通じて産業に直接的な価値を提供出来たことは非常に嬉しく思っています。
今回は長い歴史のある製造業に寄り添ったプロダクト作りの体験を皆さんに共有させて下さい。
背景
製造業は物理的な物を作る産業です。バーチャルな構想を物に変換する工程を「製造」と呼び、その想定アウトプットを描いた「設計図面」が設計者から製造担当者に渡ります。図面には、製造する物（部品）の材質や形状や寸法が記載されています。下記の図は社内で書いたサンプル図面です。ここから、SUS304(ステンレス)で幅500ミリの金具で、といった加工の現場で必要な情報を多く読み取る事ができます。
私達の生活を支えている家電は、この図面で製造されるような個別部品の集合体から組み立てられ、我々の手元に届いています。極端な例かもしれませんが自動車には30,000点以上の部品が搭載され、部品ごとにこのような図面が存在しているのです。
さて、この図面のデータや管理には製造業独特の難しさがあります。先述の通り、現場で読み取るためのツールであるため、フォーマットも多く、人間が読むために注記等が記載されていたりします。また、SVGに似たベクトル画像フォーマットを利用する場面が多く、バージョン管理がしにくいためsuffixに v1, v2, v3 と連番を追加したり、図面内に記載の図番(XCVF-118)を変更する事もあります。(製造業ではよく図番という図面固有の番号をふります)ソフトウェアの世界だと簡単にコードをGitHub上で検索したり、過去書いたコードと比較出来ますが、設計図面を扱っていると実現しにくいのが現状です。もちろん、数多くの設計CADソフトとセットで専用バージョン管理システムが販売されていますが、オープンな業界スタンダードはありません。
また、製造業の特徴として、産業バリューチェーンが長いということが挙げられます。複数の会社が物や情報を受け渡しながら数多くの部材・部品を製造し、組み立てることで製品をつくる産業です。大手メーカーでは、部品の多くを自社工場ではなく外の加工会社に製造をお願いしています。この、社外に部品の製造を依頼したり購買・調達する業務や役割を「調達」といいます。調達担当者は、設計図面をもとに加工会社に部品の製造を依頼しますが、この図面が殆どの場合、紙や2D画像(pdfやtiffのようなデータ)でやりとりされているため、過去の担当者の知見や発注履歴などの情報を活用することができません。調達部門は会社の財務状況に直接影響する製造原価を握る重要な役割を持っているからこそ、調達に関わるデータの課題を解くことは製造業においても非常に重要であるといえます。
実際、キャディが受発注事業を拡大する上で取引社数も、社内で取り扱う図面数も急増し、まさに自社でこの図面管理の難しさを実感し苦しめられていました。社内のオペレーションを清流化するためのシステムを作り改善を続ける中で、図面の問題にはもっと大きなポテンシャルがあると考えるようになりました。図面を管理するだけではなく、情報を自動的に抽出するといったデータ活用法へのニーズがあり、図面特有の画像解析技術の研究も進めてきました。解析アルゴリズムが成長したタイミングでこの技術の業界への汎用性にも気づき、ソフトウェアの技術を通じて産業全体に価値提供が出来るのではないかと思ったのが本製品の始まりです。
始まり
この気付きをもとに業界調査を始めたかったものの、アンケート資料も無い状態でした。専属の開発チームもマーケティング担当もいない、アイデアと夢だけの創業期に戻った感覚でした。
既に受発注の事業を提供していたため、キャディには沢山の製造業のお取引先様があります。1日でも早くヒアリングを始めようと、コンセプトを伝えて反応をつかむためのデモを突貫工事で作る事になりました。システムの設計としても状態を持たず、図面データの検索性や活用シーンといった使い勝手を想像しやすいUXを起点に、裏側はフルマネージドのデータベース(Firestore, Algolia)を利用しました。検証段階でデータ構造が揺らぐことも想定し、schema-lessに寄せてバリデーション緩く。リリース時にドタバタしたく無かったので最低限の開発と本番環境までCI/CDを設けましたが、一方で結合テストなどは省略し、人力テスト駆動開発でデモの品質を担保することにしました。
突貫工事を数週間続けてお客様の意見を回収した結果、我々が社内で当たり前のように使っている図面管理の仕組みが驚くほど数多くの企業様・製造業で働く方々に求められていると実感できました。早速、本格的にプロダクト開発の投資を始める判断に至りました。あまりにも商談が順調で正直焦りましたが、これは喜びの悲鳴とも言えるでしょう。お客様に「いいね」「欲しいです」と言われる事で価値検証の確度が上がり、プロダクトの価値が固まっていきました。
事業としては素敵な事ですが、開発者としては冷や汗をかき始めます。今までは運用や安定性などを考慮せずでデモを作ってきたところで、突然複数のお客様が触れるシステムが求められている訳です。「技術負債が…」と言いたい気持ちもありますが、検証したい仮説を絞った上で全力で走ろうと決めました。社内でサンプル図面を作成する事でセキュリティ要件も抑え、ブラウザも指定、テストも最低限とする戦略を取りました。
走りながらも未来に投資
スタートアップはよく“崖から飛び降りながら飛行機を作る”事に例えられますが、我々もまさに目の前の仕事で必死なのにも関わらず、同時に将来に投資し続ける事が求められました。翌週のリリースに向けて開発しながらも、並行して新規プロダクトのために顧客理解を深めるリサーチも続け、さらに半年後の技術的不確実性を潰す挑戦も必要でした。新たな検証結果や情報が手に入る度に軌道修正する事も求められました。仮説の上にまた仮説を重ねていたので、初期仮説が崩れれば全部ひっくり返る。そんな状況でしたが、これこそが新規事業に求められるアジリティだと今では思います。
組織や体制づくりについても同様で、まだプロダクト価値の検証中でも、成功する前提で将来を見据えて投資する必要もありました。設計図面は製造業にとって最重要データといわれており、大切な知財に当たります。そうした機密性の高い情報を扱うプロダクトになる事が想像出来ていたため、セキュリティ対策の優先度は当然高めました。技術的なプロダクト自体のセキュリティだけでなく、組織として情報取扱を含む幅広い情報管理体制を整える必要があると考え、社内の関係者10人前後の段階から ISMS (Information security management system) の構築を決断しました。詳細に営業や開発部門の取り扱うデータを整理し、強弱を付けて施策に落とすだけではなく、制度と実態が合っているのか継続的に確認、改善できる体制を作りました。もちろん、クラウド世代のエンジニアらしくIaC (Infrastructure as Code) 管理で運用負荷を下げるために特定情報取り扱うSlackチャネルの参加者もIaC管理しました。
この段階で情報セキュリティに投資した事が、正式ローンチを迎えた今、組織力に変換され根付いています。開発のスピードが重要なフェーズにも関わらずセキュリティ対策に時間をとられ目の前の進捗を犠牲にすることもありましたが、お客様の大切な情報を取り扱うプロダクトだからこそ過剰といえるぐらいの対策を行う必要がありますし、非常に重要な施策だったなと今振り返ってみて思います。事業が拡大してから、組織の価値観を変える事はとても難しいからです。
突貫工事を卒業しベータ版へ
お客様からの強いニーズを確認できたため、ベータ版として提供し使っていただくことにしました。突貫工事のデモを卒業するにあたっては、事業的にも技術的にも多くの仕事がありました。特にエンジニアとして「ソフトウェアを作る人」ではなくて「ソフトウェアの専門性を活かして事業を作る人」として振る舞う必要がありました。お客様が直接ソフトウェアを触る事で初めてプロダクト価値が分かるので、それに向けて少しでも早く商談が始められるように開発の順番等を調整し続けていました。営業の場に同席して、自分達でヒアリングもする事で情報を仕入れ続けていました。IT分野を超える多能工化が求められるわけですが、これこそが新規事業の楽しみだなとも振り返って思います。
数ヶ月かかりましたが徐々にデモの状態からしっかりと組まれたソフトウェアに成長し、ドキュメントやタスクも整理出来ていきました。弊社の設計図面の解析技術も進化して、当初の想定以上のパフォーマンスを出せるようになっていました。ソフトウェアのスタックも社内標準に合わせ、インフラもKubernetesクラスターに移し、監視も出来るようになり、定期的にブラックボックステストも追加されていきました。今では、メトリクスを通じて提供したい価値がユーザにお届けできているかの測定も可能になっています。
エンジニア個人の腕力と気合に依存していた部分もありますが、この四年間で蓄積してきたB2Bのシステム運用の知見が社外に発揮出来たとも思っています。社内用に大量の図面を処理する仕組みを構築した経験もありましたし、複雑なデータ構造を扱う非同期処理が多い基幹システムの落とし穴も事前に分かっていました。ドメイン駆動設計（DDD）にレバレッジをかけた開発の難しさも経験していたお陰で、なるべく事業の目指す方向に適した開発手法が選定出来たのかなと思います。
新規目玉機能の開発
ベータ版を通じてお客様の調達の課題をひとつ解決出来ることは検証出来ましたが、これはいわゆるProblem Solution Fitでしか無く、まだ1つの大きなプロダクトと言える状態ではありませんでした。我々は痒いところに手が届く仕組みだけを作りたいわけではなく、大きく業界を次の世代に進化させる事を目的としています。もちろん業務簡略化機能を届ける事も大切にしていましたが、他の誰にも実現出来ないキャディならではの圧倒的なWOW要素を込めた1つの”プロダクト”にするために試行錯誤を繰り返しました。
プロダクトマネージャのヒアリングやリサーチから出てきた案が、設計図面の類似検索でした。Googleで検索キーワードの代わりに写真をキーにした画像検索が出来るかと思いますが、それを調達というコンテキストで設計図に適用し、類似品の比較を通じて調達の最適化を行うというアイデアです。製造業に関わっていないと分からない「類似」に関する強いドメイン知識もあり、まさに受発注に日々関わっているキャディにしか出来ない事です。
素早く弊社のAI Labを巻き込み、社内のドメインエキスパートや図面に纏わるデータを参考にした探索を始めました。また、「類似」というほぼ定義の無い要件を言語化して評価指標を用意出来るまで、数多くの方々にお世話になりました。受発注に日々関わっているからこそ仮説を立てフィードバック頂ける時間が短縮出来たのかなと思います。見積・調達・製造・検査と幅広いオペレーションを社内で持っているため、アルゴリズムの評価指標を設計する上で重要な要素を現場にヒアリングする事も出来、まさにキャディの総力で挑んだプロダクトになっています。
アルゴリズムだけではなく、アプリケーション全体の設計も一気に難易度が上がりました。類似判定をする特殊なアルゴリズムの開発を始め、その解析技術を活用する分散処理の仕組みや類似データを格納する特殊なデータベースも必要になりました。データ保管をするともちろんバックアップやマイグレーションも求められ、開発の関係者数も増えるため情報の交通整備の難易度も上がっていきました。
色々組織的にも技術的にも苦労して負債も積んでいますが、お客様に調達業務を進化させるプロダクトがついに出来たと思っています。デモを作り始めてから一年間で業界特化のバーティカルSaaSを立ち上げ、プレスリリース出せた事は嬉しい限りです。ですが、これから事業成長を続けるには正直足りていない要素ばかりです。この勢いで急速立ち上げしているので、改善の余地しか無いです。
現状パフォーマンス改善を省略しマシンスペックで殴っていたり、CI/CDの関係で新規機能がお客様の手元に届くまでの時間が長かったり、開発者体験や運用コストを犠牲にして走ってきた部分もあります。また、設計変更を繰り返した結果チーム構造とシステム構造にねじれがあって連携コストが高くなっている事実もあり、チームとシステム両方の最適化が必要です。
プロダクトとしてもこれがまだスタート地点にやっと立てた状況です。公開は出来ないワクワクするロードマップが沢山待ち構えておりますので、また皆さんに紹介出来るのを楽しみにしております。
これからの挑戦
ユーザ数及び図面数が急増する中での継続安定運用
今後事業伸ばしていく上で桁違いの負荷に耐えて安定運用を継続出来る組織体制や技術挑戦が必要とされてます。組織的にはカスタマーサクセスに向けたUX改善やユーザより先に問題を検知出来る品質の作り込み、そして障害が起きても速やかにリカバリー出来る体制の強化が重要かなと思います。これを実現出来る組織作りに挑戦したいエンジニアリングマネージャー を探しております。
技術的には既にクラウドのスケーラビリティ力に頼っておりますが、甘えすぎずにパフォーマンスを常に意識し続ける事で、新たな機能開発の弊害を避けられると信じています。非同期処理も多い複雑なプロダクトに関わりたいアプリケーションよりの方々、そして縁の下の力持ちとして組織とプロダクトを支えたいプラットフォームエンジニア の仲間も絶賛募集しております。
開発者体験改善を通じて組織のアジリティ向上
最初の一年は不確実性が多く、そもそもプロダクトとして価値を出せるのかも分からずに走って来たため、人数絞ってハイコンテキストで仕事を進められる体制をとっていました。しかし、これからさらなる拡大をしていく上では内部のAPIやインタフェースを安定化してドキュメント化し、毎週 breaking change が起きない状態を目指したいです。複数チーム横断したパッケージの共有やリリースの清流化、細かいけど重要なログフォーマットの共通化等も今後は開発者体験及び生産性に効いてくると思います。
キャディのプラットフォームエンジニアリングチーム は開発者組織のアジリティ向上とイノベーション推進をミッションに掲げており、直近ではサービスメッシュの検討等も進めており、深い知見をお持ちの方に協力して頂きたいです。
種からプロダクトまでのイノベーションパイプライン短縮化
今後、R&Dから生まれた新規画像解析アルゴリズムや新たなUXの検証実験等、数々の施策を打っていくことを想定しています。最速で新規アイデアをユーザの手元に届けられ、プロダクション提供しているものを継続改善出来る世界に持っていきたいんですが、まだ苦労しているのが現状です。
データ領域に関しては半年前にAI Lab設立したばかりで、更地どころか無の状況で始まり、やっと更地になったくらいです。今回のプロダクトリリースで初めてend-to-endのデリバリーが実現出来た良い事例かなと思いますが、今後はこの価値提供を加速化する領域にも投資したくてMLOpsやData Engineeringの領域を強化して行こうとおもっています。上流のデータ取得やディスカバリーは現状人海戦術な部分も多いのは多少仕方がないとしても、運用中のモデルのパフォーマンス評価を元にPDCA回したり、更新に伴うバージョン管理やロギング周りも劣後して来たので、今後は力入れていきたい。データが好きだったり、データとソフトウェア開発の境界線を歩みたい方と一緒にイノベーションパイプライン作っていきたいです。
プロダクト成長を支える新規施策
最初の課題を解くプロダクトが出来上がったと感じていますが、これからデータ基盤になるのか、新しいWOWの提供に特化したサービスになるのか、ヒアリングと試行錯誤を続ける難しいフェーズになるなと考えています。プロダクトとして立ち上がった今、1から100に成長させられる力強いプロダクトマネージャーとプロダクトデザイナーも募集しています。
製造業の品質管理とソフトウェアの比較記事を以前書きましたが、キャディでは現状テスターのみの組織はもっていません。四六時中単体テスト書く職人もいません。現状は各開発者にお任せしている状況ですが、これではキャディ全体がスケールしないと考えており、DevOps系の施策が好きな方や自動化に興味があるQuality Assuranceエンジニアとも一緒に働きたいと考えています。
