アルゴリズムで事業の非連続を創りたい - CADDi アルゴリズムチームへの招待

CADDi でアルゴリズム系の開発を担当している寺田です。ぜひ一緒にアルゴリズム開発に携わってくれる仲間を募集したいと思い、筆を執りました。通常の Tech Blog よりPR色の強い内容となりますことをご容赦ください。


そこに課題があるから

アルゴリズムが好きな方であれば、「解くに値する面白い課題」を欲しているのではないでしょうか。

教科書を読めば、様々なアルゴリズムの技法を学ぶことが出来ます。その技法を使えばどんな問題が解けるかも分かるし、身近なライブラリの背後で使われている理論的背景を知ることが出来ます。

しかし、教科書の例にドンピシャに当てはまる仕事に巡り会う機会はそうあるものではありません。多くのアルゴリズムは既にライブラリとして実装済みであり、自分で実装する機会は多くありません。また、現実の問題は教科書のように整理や定式化がされていませんし、場合によっては問題と認識すらされていません。したがってアルゴリズムを活かすには、まず現実を「観察」し、そこから問題を「発見」し、それをアルゴリズムの問題として「定式化」していく必要があります。

こういった機会を得るためには、問題が顕在もしくは潜在する「現実」の近くに身を置く必要があります。加えて、アルゴリズムという選択肢に戦略的価値を見出す「組織文化」が必要です。

この両方が、CADDi にはあります。

調達業務の現実

まず「現実」について。

CADDi は多品種少量生産の製造業における受発注プラットフォームです。ただし、受発注を結びつけるだけのマッチングサービスとは違います。CADDi は仲介業者ではなく、CADDi 自身が受注し、製造を請け負っています。実際の製造はパートナー企業にご協力を仰いでいますが、品質や納期は CADDi 自身が責任を負って受注するモデルとなっています。

これが意味するところは、問題がゴロゴロしている「現実」と常に隣り合わせであるということです。他品種少量生産の調達業務には、多くの非効率と苦しみが横たわっています。この問題を解くのが CADDi に課せられた使命です。この調達業務に CADDi が自ら身を置くことで、突き刺すような現実のペインに晒されることになり、これが問題解決への強烈なモチベーションにつながっています。

困難の一端を紹介します。

まず、ほとんどの案件において、発注部品の仕様は2次元の図面で届きます。図面は、DXF のようなCADデータですらありません。画像なのです。それも、紙に印刷されたものをスキャナで取り込んだ画像です。こういった図面が、ひとつのPDFファイルにまとめて送られてきます。大型案件では、PDFは1000ページを超えることもあります。

これを聞くと驚かれるかもしれません。製造業は今や 3D CAD が当たり前であり、3D データを末端まで流通させて効率化していると思われている方も多いしょう。そして実際、自動車・航空・電機、その他多くの業界で 3D CAD は使われています。しかし、「多品種少量生産」の「調達」という業務においては、3D CAD のデータが流通することは多くありません。様々な理由が考えられますが、3D CAD には寸法交差や表面粗さといった加工に必要な情報が乗せられない(乗せにくい)ことが理由のひとつかもしれません。

ともかく、これが現実です。私たちは図面(画像)と向き合わなくてはなりません。ここに多くの「解くべき課題」が横たわっています。

図面には大抵、「図番」という(一意に見えて実は一意ではない)番号が振られており、図面に右下にある表に記載されています。しかし、繰り返しますが、これは画像であってテキスト情報ではありません。従って、1000ページに及ぶPDFから図面を探したくとも、図番で検索することが出来ません。何らかの工夫がなければ、取引先からの問い合わせのたびに目で探すことになってしまいます。(弊社ではかねてより管理シートから該当図面のページ番号を辿れる体制を作っており、最近では図面管理用の社内システムもローンチされました。)

加えて、図面はたびたび「差し替え」が発生します。なんらかのミスの修正や、設計変更が生じうるからです。こういった差し替えが生じると、修正は軽微だとしても、図面の管理コストは跳ね上がります。「xyz.pdf に格納された1000枚の図面のうち、図番 AB-123-345 と図番 CD-987-654 だけは xyz2.pdf の図面を使用する」といったオペレーションは煩雑で、ミスを誘発します。また、差し替え前後の図面はよく似ていますから、その違いを漏れなく読み取るにも注意が必要になります。ミスは不良の発生に直結しますから、影響は甚大です。

問題は複雑であり、複合的であり、単一の施策で全てが解決するわけではありません。ある種の問題は管理システムの構築がソリューションになります。既にテックチームでは図面を管理するためのシステムを社内リリースしており、社内の図面管理体制に変革を起こしつつあります。しかし別種の問題は、Webとデータベースだけでは解決できません。

アルゴリズムが必要だ、と私たちは考えています。

Orama プロジェクト

弊社では今、図面の画像処理アルゴリズムを開発するプロジェクトが始動しています。そのプロジェクトは "Orama" と命名されました。Orama とは古代ギリシア語で「視覚」を意味する語で、panorama の語源となった言葉です。図面管理システムに図面を読み取る「視覚」を授けることが、このプロジェクトの目的です。

課題のひとつは、図番の自動検出です。基本的には、OCR でテキストを検出します。しかし検証の結果、図面をそのまま OCR に渡しても実用に耐えるテキスト検出は望めないことが分かりました。図番は右下の表に書かれていますが、表の罫線が OCR の読み取りを邪魔するようです。従って、まず外枠や罫線を自動認識し、これを消去した上で OCR に入力する必要があります。図番が書かれたセルを特定する必要もありますので、その意味でも表の認識は必要です。

下図が、現在得られている成果です。左の入力画像から表の罫線をベクターデータとして検出し、表のセルを認識することに成功しました。(右の画像はSVG形式でエクスポートされたものです)

他にも差し替え図面との差分検出など、さまざまな課題に取り組んでいます。

プログラミング言語は、主に Python と Rust を使用しています。PythonOpenCV との親和性がよく知られていますが、Rust は目新しさがあるかもしれません。Rust は安全性とスピードを兼ね備えているので、パフォーマンスが求められるアルゴリズムの開発には本当に適していると実感しています。Python + OpenCV だけで賄えない理由は、ベクターデータの処理が必要になるからです。上で紹介した表の罫線認識では、まず画像をベクターデータに変換してから様々なアルゴリズムを組み込んでいます。ベクターアルゴリズムを含めた各種のアルゴリズムの実装に、Rust が活躍しています。罫線の認識処理は、画像ファイルの読込からセル情報(JSON)のエクスポートまで 200〜400ms ほどで処理が完了します。

アルゴリズムの喜び

上で紹介したテーブル認識処理がうまく動いたときはとても嬉しくて、出力結果を眺めてはニンマリしていました。ちょっと気持ち悪い人ですね。

自分が試行錯誤したアルゴリズムがうまく動いたときの喜びは、格別なものがあります。時には、まるでアルゴリズムが知性を得たかのように思えて、作った本人なのに「どうしてこんなにうまく動くのだろう」と不思議になることがあります。特に、ごくシンプルなアルゴリズムの組み合わせて驚くほど複雑な問題に対処できたとき、それを感じるようです。再帰的なアルゴリズムに感じることが多いかもしれません。

こういった喜びは、一部の天才だけに許されたものではありません。私は凡才に過ぎませんが、それでもごく稀にですが、この手の喜びの機会に恵まれています(その瞬間だけ、自分のことが天才だと勘違いできます)。こういった機会に巡り会うためには、自分が天才になる必要はなく、何より「解かれるのを待っている問題」がある環境に身を置くことだと思っています。

CADDi が向き合っている問題は、もちろんハードルは高いのですが、しかし天才でないと解けない超難問というわけではないはずです(そういう問題もあるかもしれませんが、それは天才に任せましょう)。何故それが解かれないまま残っているかというと、今まで必要に迫られたプレーヤーがいなかったからではないか、と思います。「多品種少量生産」の「調達」という業界で、仲介業ではなく自らが製造責任を負うビジネスモデルで、図面の管理をITの力で解決するという強いモチベーションを持ったプレーヤーが、今まであまりいなかったのではないでしょうか。

あまり前例のないポジションに身を置いていますから、解法が定まっていない問題が多く発生していますし、これからも生じ続けるでしょう。そして解決策はひとつではありません。画像処理も解決策のひとつですが、お客様からCADデータで頂ける機会を増やしていくというビジネス的な解決方法も考えられます。これが可能になれば、そのときはCADデータを扱うアルゴリズムの重要度が増すことになるでしょう。切れば血が出る活きた問題が、次から次へと供給され続ける環境であることは間違いありません。

一翼を担うために

CADDi はバリューのひとつとして「一丸」を掲げていますが、半年ほど前までは胸を張って言える状況ではありませんでした。

半年前にあったこと、それは社内業務システムのリリースです。リリースに漕ぎ付ける前は、私たち Tech 組織にとってはやや苦しい期間でした。要件は膨らみがち、リリースは遅れがち、目の前の開発に忙殺される毎日ですが、しかしビジネスに何のバリューも提供できていません。ビジネスサイドから見れば、Tech は「何をしているのかよく分からない人たち」だったことでしょう。

しかし、システムをローンチしてからは状況が一変しました。「効率的になった!」という喜びの声が多くビジネスサイドから届きました。それに伴って、多くの改良要望も届きました。Tech の各チームは今までの鬱憤を晴らすように、それらの要望に迅速に応えています。こうして今、Biz と Tech が両輪となって業務が回るようになり、私たちはようやく「一丸」になったと感じています。Biz と Tech は、どちらが上でも下でもなく、対等に互いを尊重し合う良い関係の元で仕事が出来ています。

この流れに、アルゴリズムも乗せたい…!

と私たち Orama チームは考えています。アルゴリズムが持つ可能性やインパクトの大きさは、社内では十分に理解されています。それと同時に、開発のハードルが高いことも知られています。私たちはアルゴリズムを可能性のまま終わらせず、きちんとビジネスにインパクトを与えるところまで作りきる必要があります。そして Biz 組織と「一丸」になって継続的にアルゴリズムの開発に取り組んでゆく組織文化を醸成したい、と思っています。

そのためには、今いるメンバーだけでは力不足です。もっと多くの方の知識や経験、そしてアイディアが必要です。

スキルとマインド

では、どんなスキルが求められるのでしょうか? 画像処理? 機械学習? 数学?

現時点では、私たちは Orama プロジェクトで画像処理に取り組んでいます。しかし、事業の状況は目まぐるしく変化し、それに応じて求められる開発も変わってゆきます。半年後には全く違うプロジェクトに注力しているかもしれません。従って、画像処理を専門家をお誘いしても、その方が入社される頃にはプロジェクトの内容が変わっているかもしれないのです。入社後に「こんなはずではなかった」というミスマッチが生じるのは本意ではありません。

「画像処理」や「機械学習」といった特定の How に軸足を置いて、その技術の専門家として活躍したいという方は、弊社は合わない可能性があります。私たちは「多品種少量生産の調達」という What に軸足を置いていて、使う技術は要求に応じて柔軟に切り替えるスタイルだからです。ですから、私たちの事業ミッションに共感し、その問題解決をエキサイティングに感じるマインドをお持ちの方が、より親和性が高いと考えています。

その上で、数学やアルゴリズムについてある程度の素養がある方、が必要です。

ここの言語化が難しいのですが、決して「〇〇の定理について自力で証明できるほど深く理解していること」とか「□□のアルゴリズムについて実装および正確な計算量の解析ができること」といったことは必要ありません。もちろんこういった知識は持っていれば何らかの形で活かせるとは思うものの、この知識がなければ仕事が出来ないと断定できるようなものはありません。

ただ、「数式」という論理の表現形式を、(プログラム言語と同様に)言語のひとつとして読み書きする素養は必要だと考えます。例えば、解析学の諸定理を即答できる必要はないのですが、$\forall \epsilon>0\ \exists N\ \forall n[n> N \Rightarrow |a_n-a|<\epsilon]$ のような式を見て「ウッ…」と思考停止せずに、「どれどれ…」と読み解いていく地力は欲しいように思います。あとは、初歩的な線形代数についてはそれなりに理解していることが望ましいでしょう。

アルゴリズムについても同様で、もちろん初歩的なソートアルゴリズムや二分探索木などは教養として理解している必要がありますが、それ以上は「どのアルゴリズムを知っていれば良い」「これを知らないのはダメ」と断定できるものはありません。ただ、ある程度の複雑なアルゴリズムでも書籍や論文を見ながら自分で実装しきる能力だとか、それを現実の問題に適用して試行錯誤した経験だとかは、あると望ましいものです。

結局のところ、先ほど書いたことと矛盾するようですが、何らかの専門分野(とまでは行かなくとも、得意分野)をお持ちだと良いのかもしれません。その専門がドンピシャに活かせるとは限らないのですが、なんらかの得意分野をお持ちの方であれば上で述べたような素養というのは、既に培われているものと思うからです。

その一例として、手前味噌ながら自己紹介をさせてください。

私は20年近く 3D CAD やその周辺の 3D 技術で仕事をしてきた経歴で、約一年前に CADDi に入社しました。そして見積りシステムのバックエンドの開発を経て、Orama プロジェクトに配属されました。3D 関連のアルゴリズムは経験があるものの画像処理はほとんど経験がなく、胸のうちには一抹の不安を抱えていました。しかし始めてみれば、図面の黒いピクセルを点群として取り出すことで、3D 計測点群を扱ってきた経験を応用できました。図面のベクターデータ変換や、そのベクターデータを操作する処理においても、三角形メッシュ等を扱ってきた経験が活きました。基礎があればなんとかなるものだと実感しています。

ご連絡をお待ちしています

ですので、今お持ちのスキルと分野が違うからという理由で応募を躊躇う必要はありませんし、「まずは軽く話を聞いてみたい」というご要望でも問題ありません。

アルゴリズム開発の魅力は何と言っても、今までの常識をひっくり返すほどのインパクトを事業や業界に与えるかもしれない、という可能性の大きさにあります。これが達成できたとき、アルゴリズムは事業の非連続的な成長の支えとなるでしょう。この夢を一緒に叶える仲間を募集しています。皆様からのご連絡をお待ちしております。

弊社のエンジニア採用ページへ (https://corp.caddi.jp/recruit/eng)