OEM技術 ― callasの最大の秘密
「OEM技術 」 とは一体どういうものなのか、また、なぜこれほど多くの企業がすべてを自社で開発するのではなく、OEM技術に頼っているのか、考えたことはありますか ？
私が初めて「OEM」という用語を耳にしたのは――残念ながら――1990年代のことでしたが、当時はそれが何なのかとても戸惑ったことを覚えています。もし皆さんも同じように戸惑っているなら、実はとても単純なことです。「OEM」は「Original Equipment Manufacturer（オリジナル・イクイップメント・メーカー）」の略で、一般的に、購入先の企業とは別の会社が製造した技術を指す言葉として使われています。 このようなケースは多岐にわたりますが、例えばスキャナーやデジタルカメラを購入する場合を考えてみてください。製品に付属しているソフトウェアが、そのスキャナーやカメラのメーカーではなく、別の会社によって開発されたものであることがあります。つまり、あなたはOEM製品を購入したことになるのです。
なぜ企業がそんなことをするのでしょうか？すべてを自社で開発するほうが良いのではないでしょうか？そうすれば、ソフトウェア（あるいはハードウェア）の動作を完全にコントロールできるからです。場合によってはその通りであり、一部の企業にとっては、いわゆる「Not Invented Here（自社開発以外を認めない）」症候群と呼ばれる、真の経営理念となっていることもあります。 製品のあらゆる部分を管理できることには確かにメリットがあり、より洗練された製品や優れたユーザー体験を生み出すことにもつながる場合があります。Appleが自社のエコシステムで行っていることを考えてみてください。しかし、「Not Invented Here」症候群が症候群と呼ばれるのは偶然ではありません。これは非常に有害な側面も持つからです。
例として、Callas社の取り組みを見てみましょう。同社はPDF分野において、品質管理、標準化、自動化など、30年近くにわたる実績を築いてきました。それが同社の本業であり、唯一の事業です。それは同社のDNAに刻み込まれているのです。
さて、PDFベースの機能の実装が必要な製品を開発している会社があると想像してみてください。その場合、どのように取り組めばよいでしょうか？ もちろん、PDFをサポートするためのスキルをゼロから構築することも可能です。そのためには、PDF標準仕様書（良いニュースですが、最近はわずか1000ページ程度です）を理解するために多大な時間を費やし、必要な機能を実装できる優秀な開発者が必要となります。
「これは不可能だ」なんて誰も言っていません。実際、callasは明らかにそれを実現しました。ただ、彼らには30年もの時間があり、コードを完成させ、規格の細かい仕様をすべて実装し、規格から逸脱したPDFファイルの作成方法への対応を追加することができたのです（えっ？ すべてのPDFファイルが完璧ではないのですか？ 😱）。 ああ、それと、画像処理やフォントのサポート、カラーマネジメントの問題といった基盤となる技術のためのコードも追加しなければならなかったし……
このような機能の開発には、開発者年単位の工数がかかります。その数は 年 有能な開発者1人（いいえ、AIではありません）が、ある機能のサポートを実装する必要があるでしょうか？ そして、よく見落とされがちなもう1つの小さなポイントとして：いいえ、 10 開発者だけでは、必要な時間を 10. チームの人数が多いほうが確かに役立つのは確かですが、その関係は決して単純な直線的なものではありません。
つまり、本質的な問い――そしてOEM技術が存在する理由――は、結局のところ次のような点に集約されます。その機能が中核的なものかどうか、そして自社で実装する場合と他社からOEM供給を受ける場合とでは、それぞれどのような機会費用が生じるか、ということです。
もし毎週3時間を中国語の学習に費やすと決めた場合、その分は他のことに使える時間が失われてしまいます。例えば、中国へ旅行したいから中国語を話せるようになりたいと思う一方で、職場での昇進を目指してJavaScriptの書き方を学びたいとも考えているかもしれません。 時間が限られており、週に3時間が「余暇」として使える唯一の時間である場合、中国語を学ぶことによる機会費用は、「JavaScriptを学べないこと」、ひいては「昇進できないこと」となります。
確かに、これはちょっとおかしな例ですが、ビジネスの文脈でも完全に当てはまります。もし御社に、印刷担当者が使用するワークフローシステムがあり、ISO PDF/Xやゲント・ワークグループの規格といった国際基準に準拠したPDFの品質管理をサポートする必要がある場合、 どのように その実現方法も重要です。 機能を自社で開発するには機会費用が伴います。開発チーム（そしてプロダクトマネジメントやサポートチーム――見過ごされがちな投資です！）の一部が、その実装に数開発者年を費やすことになるでしょう。あるいは、（当然ながらcallas社の）OEM技術を利用すれば、その時間をより中核的な機能の開発に充てることができるでしょう。
特定のPDF機能をサポートするために実際に必要な時間は、しばしば過小評価されがちです。まもなく（新しく開設された）callas OEMのウェブサイトからダウンロード可能になる新しいOEM向けホワイトペーパーでは、 oem.callassoftware.com を詳しく調べて、いくつかの基本的な推測を立ててみました。このブログでは、最新の Ghent Workgroup 2022 仕様のサポートといった比較的基礎的なことさえ、開発年数で換算すると10～15年程度は軽くかかる総工数を要するという点に留めておきます。
OEM向けホワイトペーパーの先行公開：PDF処理技術をゼロから構築するのではなく、callasの技術を活用することによる投資対効果。
この新しいOEMホワイトペーパーをいち早くご覧になりたい場合は、ぜひ メールをお送りください その場合は、喜んで早期アクセスをご提供いたします。私の見通しは悲観的だ、あるいは自己都合的だと思われるかもしれませんが（私はcallasに勤務しており、当社ではOEM技術を提供しているわけですから）、喜んでその点について議論させていただきますし、私自身はそうは思っていません。 PDFプリフライト分野のトップ2社で勤務した経験があり、25年間を費やしてきたGhent Workgroupの執行役員を務めている私としては、優れたPDFサポートがいかに難しいかという点に対する私の認識は、十分に根拠のあるものだと考えています。
良い質問ですね。実は、すでにこの技術を使ったことがあるかもしれません。Adobe Acrobat Pro（プリフライトプラグイン）やFoxit Editorには、この技術が組み込まれています。 また、Kodak PrinergyやXerox FreeFlowといったワークフローシステムにもこの技術が組み込まれています。MultiPress社のDatalineなどのMISシステムでも採用されています。callasには現在75社以上のOEMパートナーがいますが、多くの場合、こうした統合は表立って注目されることなく行われています。
OEMパートナーの例
それは、OEMパートナーがその状態を維持したいと考えているからという場合もあるでしょう。何しろ、競合他社に勝っている秘訣をわざわざ明かす必要などないのですから。しかし、その理由の一部は、callasがPDFの専門家集団であり、自分たちが作り出したものに大きな誇りを持っているものの、それを自慢する必要性を感じていないからでもあると思います。
でも、もうそのことはご存知ですね。では、ぜひ 新しいCallasのOEMウェブサイト。ぜひご参加ください。 callas pdfフォーラム そして、ディスカッションに参加してください。あるいは、callasのOEMチームに直接連絡して、話し合ってみてください。
機会費用のことを忘れないでください。私たちはすでにその代償を支払っていますから、あなたが支払う必要はありません。
