ユーザ企業が絶対に知っておくべきOdooパートナーの選び方

「OCAのモジュールはオープンソースだからライセンスはありません。」

先日、とあるOdooパートナーが実際にユーザ企業にこのように説明していたのを耳にする機会がありました。これはまずい、と強い危機感を覚えましたので、記事にしたためます。

本記事は、主に日本のユーザ企業の皆さまに、「普段Odooの公式チャネルでは語られないがパートナー選定においてかなり重要な観点」を提供することを目的としています。かなり長文ですが、Odoo導入において失敗する可能性を減らすため、ユーザ企業の皆さまにはすべてお読みいただくことをお勧めします。

1. Odooの成長に付随して起こっていること

1-1. Odooの国内での伸長

Googleの検索トレンドを追っていても明らかなのですが、Odooは日本市場で伸びています。グローバルでのシェア拡大に伴い、日本でも全体的にプロダクトに接点を持つ機会が増えている状況に、Odoo社からの日本市場向けのマーケティング活動（YouTube広告が鬱陶しいという声もちらほら...）が重なり、国内企業にとっても基幹システムの選択肢としてOdooを検討する条件がそろってきたのだと見ています。

1-2. 失敗プロジェクトの増加

視点をミクロに移すと、ここ1年ほどでコタエルに寄せられるある種のご相談が増加しています。失敗プロジェクトの立て直しです。あるパートナーのもとでOdoo導入を進めたが、求めていた結果が得られず、どうにかできないかというものです。コタエルのリソースもタイトな状況が続いているため、なかなか全体を引き受けられないことが多いのですが、そういったプロジェクトにアドバイザとして関わるケースが増えています。

このマクロとミクロのトレンドは相関しています。「Odooの勢いとOCAの危機感、そしてこれから起こること」の記事で、Odooサービス事業者界隈のレモン市場化について触れましたが、それが身近なところで顕在化していることを感じます。

2. Odoo vs SAP — 根本差がどこにあるか

2-1. よく語られるOdooとSAPの違い―プロダクトについて

Odooと他の商用ERPの違いが語られる場面も増えています。プロダクトそのものについて、Odooと商用ERPの代表格であるSAPの違いを、いささか乱暴な対比で言うと、SAPは「引き算」のシステム、Odooは「足し算」のシステムです。

SAPはあらゆる企業の業務処理を運用するための仕組みが備わった（備えることを目指した）モノリシックで巨大なソフトウェアです。導入プロジェクトではパラメータ設定を中心に環境を構築していきます。使わない機能も大量にでてきますが、細かい粒度でのデータ管理や、特に会計実績に紐づくトランザクションの堅牢性を重視する場合に力を発揮します。その意味でやはり大企業向けのソフトウェアであるとの評価は妥当かと思います。

対してOdooは、最小構成（baseモジュール）に必要な機能（モジュール）を追加していくスタイルの、オープンソース（オープンコア）のソフトウェアです。「必要な機能」はOdooの標準機能のこともあれば、カスタム機能であることでもあります。技術的には標準機能もカスタム機能も同列です。使わないモジュールは有効化しないため、「標準機能」による制約を受けにくく、これがOdooの開発柔軟性を担保する一つの要素となっています。

この特長とセットで、Odoo本体はリーンに保たれています。つまり、Odoo標準機能でそれなりに使えるものは提供されますが、個別の要求に照らし合わせると足りないこともよくあります。「なければ作ってね」という思想です。そのため、一般的にはOdooの方がカスタム機能を導入すべき場面が多く発生します。

このことは、データの粒度やトランザクションの堅牢性において、やや「緩い」状況を生みます。モジュールの組み合わせ次第でOdooの実装パターンは無数に広がりうるためです。それができることがOdooの良さでもあるのですが、これはOdoo本体でデザイン上・統制上の縛りを強くすることとはトレードオフの関係にあります。

このような特性を踏まえると、よく言われる「SAPは大企業向け、Odooは中小企業むけ」という表層的な分類がどこから来るのか合点がいくかもしれません。基幹システム導入スタイルの観点では、SAPは「テンプレート導入型」、Odooは「フリースタイル型」と言えるでしょう。

2-2. あまり語られないOdooとSAPの違い—OCAの存在

プロダクトの違いはエコシステムの違いを生みます。

ソースコードが非公開で、「テンプレート導入型」であるSAPにおいては、ある意味サービス事業者の裁量が狭められる側面があります。また、プロダクトそのものもさることながら、過去30年近く日本市場でERPソリューションの雄として君臨してきたSAPには、サービス事業者界隈に「ベストプラクティス」が浸透しているという状況もあります。そのため大規模な追加開発を伴うケースをのぞき、傾向としては、SAP導入においては事業者間でのプロダクト実装内容に大きなブレが生じにくく、それがSAPの強みであるとも言えます。

翻って、Odooはソースコードの大部分（コミュニティ版）がGitHub上で公開されたオープンソースのプロダクトです。上述のとおり、「足し算」であるOdooの導入では、個別企業の要望に合わせてカスタム機能が必要になる場面も多くあります。

「オープンソース」と「足し算」いう特徴を組み合わせると、必然的にあるべき姿として見えてくるのがコミュニティでの協働です。そうしない場合は、各Odooサービス事業者が自力で個別要件に取り組むことになり、その結果、開発コストと品質担保の難易度が上がり、保守性が大きく毀損されてしまう可能性があります。

ここで重要な役割を果たすのが、Odooコミュニティ協会（OCA）です。OCAは2013年に設立された、Odooの補完機能の作成・メンテナンスにおいて、コミュニティ開発者の協働を推進する非営利団体です。OCAのもとには業務領域や国別に、実に200以上のGitHubレポジトリが存在し、各バージョンで2000ほどのオープンソースのモジュールが管理されています。OCAの作業プロセスには、厳格なコードスタイルチェック、レビューステップが組み込まれており、OCAのもとで管理されるモジュールは概して品質が安定しています。日本向けのローカライズ機能を管理するレポジトリもあり、2025年6月現在、ここにあるモジュールはすべてコタエルが出しています。

「フリースタイル型」のOdoo導入では、開発方面での制約が少なく自由が利く分、サービス事業者により実装内容に大きなブレが生じえます。OCAモジュールの活用は、このブレを抑え、安定した持続可能な環境構築を実現するための最も有効な手段です。古くからOdooに取り組んでいる事業者の間では、導入プロジェクトではOCA機能を活用するのが定石です。

OCAのようなオープンソースコミュニティの存在が、エコシステムの観点におけるOdooとSAPの決定的な違いであり、Odoo導入においてこのコミュニティの資産を活用しないことは、プロジェクトの失敗に直結しえます。

ちょうど今月25日に、SAPとOdooを比較するウェビナー「SAP vs Odoo ERP導入のプロが語る! それぞれの強みと選び方」がありますので、この記事の説明を踏まえて視聴すると、また違った見方ができて面白いかもしれません。

3. OSSプロダクトのプロによる情報発信のあり方

3-1. Odoo社の情報発信に欠けているもの

Odoo社の情報発信には、オープンソースソフトウェアのパブリッシャーとしてのGitHubを中心とした場での透明性の高い活動と、直接的に収益貢献するユーザ企業向けのマーケティング活動の2つの側面があるのですが、ここでは後者にフォーカスします。

Odoo社から日本市場向けに出されるメッセージは、その体制から、現状マーケティングや販売を担当しているチームからのものとなります。これらチームからオープンソースの側面を含めたエコシステムやコミュニティ活動を積極的に評価するものは基本的にでてきません（ご担当者の善意でコタエルの活動を取り上げていただいたことはありますが、現状、あくまで例外と言えます：「【Odooのパートナー企業の取り組み】「コタエル」の日本仕様へのカスタマイズ事例」）。そのあたりの事情は、ブログ記事「OdooのOSS活動への参加者を増やす試みを手探りで進める」でも説明している通りです。Odoo社としてはオープンソースの側面を前面に出さなくとも、今のところ順調に成長しているため特に問題ないと判断しているのだと思います。

ですが、Odooと他の商用ERPの決定的な違いが、OCAにて体現される活発なオープンソースコミュニティであり、それがOdoo導入において非常に重要なファクターとなることを理解していると、現在のOdoo社からの情報発信にはOSSの観点があまりに欠けており、ユーザに対して十分な情報提供ができているとはいえません。

「それはエコシステムに関わるサービス事業者の役割だ」と言われればそうなのでしょう。だからこそでもありますが、コタエルはOdooパートナーでありつつも、マーケットに対して全体のバランスをとるための情報発信をしなければならないと考えています。

3-2. バランスのとれた情報発信とは

例えば日本でOdooを売ろうとする人たちは「Odooは日本の〇〇の要件に対応しています！」という説明をしがちなのですが、私たちの観点からは「いやいや、そうですか？どういう前提で？」というものもよくあります。

冷静になると分かると思いますが、Odooがようやく知られるようになってきた日本市場においては、基本的にOdoo本体がそのままで完全にマーケットにフィットしているということはありえません。もしそう見えるとしたら、その大部分はコミュニティ活動に取り組んできた先達の努力によるものでもあります。

本来は、例えば「Odooの標準機能は日本でよくある月中締の支払条件に対応していません。ただしOCAのオープンソースモジュール account_payment_term_cutoff_day で対応できます。このモジュールのライセンスはAGPLで、〇〇社が作成しました。ただし、バージョン18.0への対応が未完了で、現在作業が進められているところです」くらいの説明もあってしかるべきだと思うのです。

このような本体でカバーされない部分を補完するオプションが豊富にあることが、オープンソースプロダクトの強みであるはずなのですが、それを活かした情報発信をする人たちはなかなか出てきません。

4. 品質問題とユーザ企業が抱えるリスク

4-1. 顕在化するOdooサービス事業者の品質問題

Odooは中小企業向けERP市場でのグローバルリーダーになりつつありますが、日本においては後発です。先行してオープンソースコミュニティを成熟させてきたヨーロッパ等の地域と異なり、コミュニティ活動への参加が進まない日本のサービス事業者のOdooに関する習熟度は総じて低いと言えます。ですがその事実がOdoo社やサービス事業者自身からユーザに伝えられることはありません。判断軸を持たないユーザは、Odooパートナーに言われるがままにOdooを魔改造してしまい、気がつくと誰も保守できないシステムができあがっていた。こうなってしまっては手遅れなのです。

「OdooパートナーはOdoo社に認定されていて、レベル分けもあり、この評価に従えば間違いないのではないか？」ユーザ企業の皆さまは自然とそう思うかもしれませんが、ここに大きな落とし穴があります。Odoo社からの情報発信にOSSの側面が欠けているのは、ここも同じです。Odooのパートナー制度では企業版ユーザの新規獲得数が最も重視されており、Odoo本体に優れた改善提案を出してそれが取り込まれたりしても、ここでは評価対象とはなりません。この状況は、残念ながら「コタエルはOdooの「ラーニングパートナー」になりました」の記事を出した2018年からも大差ありません。

これはコタエルにて受ける、失敗プロジェクトの立て直しのご相談件数にも如実に表れていると捉えています。ご相談いただくケースでは、いずれもOdooパートナーからユーザ企業に対してオープンソースエコシステムやOCA、オープンソースライセンスについての説明がなされていません。私から説明差し上げると、なぜOdoo社やサービス提供しているOdooパートナーからその説明がないのかと憤られることもあります。

この状況は私たちコタエルにとっても望ましくありません。失敗プロジェクトの立て直しに関わるとかなりのリソースが奪われ、その分私たちが日本市場向けに進めたいと考えている各種施策を推進する手を止める必要があるからです。

心配なのは、品質問題の露見がこれからさらに増えそうなことです。昨今のOdoo社からの日本市場向けの情報発信の一角を占めるのがパートナープログラムの紹介ですが、現状このような発信の中でオープンソースのカルチャーやその良さが語られることはありません。このような発信をもとに商材としてのOdooに飛びつく事業者が、オープンソースエコシステムを理解した上でユーザに適切なサービスが提供できるようになる可能性は極めて低いと考えられます。

4-2. ユーザ企業がオープンソースコミュニティを知らないことのリスク

推測するに、日本のユーザ企業が、Odoo社またはコタエル以外のOdooパートナー各社のチャネルを通じてOCAについて詳しく説明を受けることは、現状ほとんどないのだと思われます。ユーザ企業にとってはそこに大きなリスクが潜みます。

Odooのように開発柔軟性が高いソフトウェアでは、作れば大体のことができてしまいます。「動くように見せる」ことは簡単であるが、「保守できる状態」を保つのは難しい。この点に注意が必要です。さらに、できていなかったことが顕在化するのは、多くの場合導入後しばらく経ってからです。Odooの専門知識を持たないユーザは、機能が業務要求を満たすかは判断できるかもしれませんが、保守性については全くわからないのが実情かと思います。

このような情報の非対称性は、意識とスキルの低いOdooサービス事業者に次のインセンティブを提供します。

• 保守性は蔑ろにして、とりあえず動くものを作成すること
• 独自仕様のカスタマイズでユーザが身動きとれない状態にし、ロックインすること

このような事業者のサービスを利用すると、言うまでもなくユーザ企業は多大な損失を被ります。経験上、誤ったアプローチのもとで進められたプロジェクトを正常化するには、「【Odooバージョンアップ事例】株式会社エムアイセブンジャパン様（V10→V15）」で触れているように、1からのやり直しに近い労力がかかります。

そして状況をさらに困難にするのが、切替コストの高さです。基幹システムの導入は、決して単にソフトウェアをインストールして終わるようなことはなく、体制を整え、諸々の規約を整備し、業務の見直しを図り、要求をまとめ、要件定義を進めていく、そのような骨の折れる作業を"信頼できる"パートナーと進めて、初めてスタート地点に立つようなところがあります。導入パートナーを切り替えるには、これらの準備にかかった労力の大部分もサンクコストとして受け入れる覚悟が必要になります。

繰り返しになりますが、「フリースタイル型」のOdoo導入においては、ユーザ企業が注意していないと低品質なOdooサービス事業者にやられてしまう状況は容易に発生します。そして販売実績を最大の評価軸としたOdoo社のパートナー制度は、現状これを牽制するに有効な仕組みは提供できていません。現にコタエルにて引き継いだお客様の大半は、Odoo公式パートナーからであり、そこには「ゴールド」や「シルバー」の実績をもつ事業者も含まれます。

一般的に基幹システムの導入プロジェクトには多額の費用がかかり、その成否はユーザ企業の事業全体の成否にも大きく影響します。ですがユーザ企業がオープンソースプロダクトとしてのOdooの特性と、それを踏まえた適切な導入アプローチについて十分な理解をしておらず、それが原因で誤った判断をしてしまっているケースが非常に多いと感じています。

5. サービス事業者のコミュニティ活動への参加から読み取れること

5-1. コミュニティ活動はサービス事業者のスタンスとスキルを可視化する

Odooは素晴らしいプロダクトですが完ぺきではありません。現状、次のようなポジティブとは言えない要素もあります。

1. バグおよび仕様考慮もれが比較的多い
2. 本体の日本向けローカライズが不十分
3. ヘルプデスクを介した改善のチャネルが細い

1については、スピーディな進化という利点と表裏一体であるため、致し方ない面もありますし、過去に比べるとだいぶ改善されているとも思います。ですが「これはERPシステムとしてどうなの？」という問題もたまに発生し、そのたびに頭を壁にぶつけたい気持ちになります。Odoo社CTOのAntonyさんと昨年会話したときに、Odooからバグはなくならないと高笑いしていましたので、これはスタイルとしてそういうものだと受け入れるべきなのでしょう。

2は現状まだ非常に弱いところです。Odoo本体の日本向けローカライズは、日本語化作業や日本用会計モジュールの追加を中心に、3-4年前までは大半がコタエルによるものでした。Odoo社が翻訳作業に内部リソースを振り分けるようになったのはここ数年のことですし、日本固有要件への対応は会計周りで部分的に進んでいるものの、全体からするとほんの一部であることは否めません。

3はOdooの仕組みに精通したパートナーにとっては改善の余地が大いにあると感じる点です。ユーザがOdooの運用上で直面する課題の原因が、仕様考慮もれであったり日本特有の要求であったりする場合は、ヘルプデスクのチャネルではほとんど対応してもらえません。

現状をもとにすると、日本でのOdoo導入では、たいていの場合、手直しが必要だけれどもOdoo社に頼ることができない状況もよく発生します。

このようなとき、ユーザへの提供価値を重視し、かつOdooに精通した事業者であれば、必然的にコミュニティ活動に参加します。私たちにとっては至極当たり前の感覚なのですが、Odooを使う上でマーケットに共通の課題がある場合、それはコミュニティ活動をもとに解決し、コミュニティ資産とすべきです。それが結果としてユーザの利益に叶います。

そうしない場合のオプションは、次のいずれかのみです。

• 仕様考慮もれや日本固有要件への対応については対処をあきらめる
• 自社に閉じた場所でソリューションを構築する

前者は無論ユーザにとってはフラストレーションの溜まる状況であるはずです。後者は効率面とソリューションの透明性の観点で問題があり、個別に開発した独自ソリューションにユーザをロックインすることにつながります。

コミュニティ活動への参加有無は、オープンソースの本質的な利活用に関するサービス事業者の資質を如実に示します。オープンソースプロダクトの本質的な優位点は、情報が自由に流通する仕組みを備えていることにありますが、この仕組みの活用なくしてオープンソースの本質的な利活用はありえません。

OCAでのモジュール作成等、コミュニティでの活動実績はオープンな場所での具体的なソリューション構築例です。ここにOdooサービス事業者のプロダクトへの理解と課題の解決力が表れます。飾られたスライド資料を読むよりも、実際に動くモジュールを試しコードをレビューする方が何倍も解像度高く力量を見ることができます。

コミュニティ活動実績からは、Odooサービス事業者の力量を大まかに次のように評価することが可能です。

• Odoo本体またはOCAのレポジトリにて継続的に有意な改善/修正提案を出す
  →力量が高く信頼に値する事業者
• Odoo本体またはOCAのレポジトリにて有意な不具合報告を出す
  →力量はないかもしれないがコミュニティ貢献のスタンスは良い事業者
• コミュニティ活動に参加しない
  →オープンソースの本質的な利活用はできない事業者

この評価の観点は、Odoo企業版の販売実績に重きを置くOdoo社のパートナー評価には全く含まれていません。コミュニティ活動に取り組むことがすべてではありませんが、情報の取得元がOdoo社およびコミュニティ活動に参加しない事業者に偏っていると、かなり重要であるにもかかわらず容易に見落としてしまう観点であるかと思います。

5-2. グローバル企業がコミュニティ活動に参加する事業者を選ぶべき理由

コタエルは2013年からOdooに取り組んでいることから、新しくOdooパートナーになった事業者やこれからOdooパートナーになることを検討している事業者に、協業を打診されることがたまにあります。そのようなケースは得てして私たちがノウハウを提供するばかりで、本質的にユーザにメリットがある座組が提案されることがないため、基本的にお断りしています。

ですが、これがOCAを中心とするコミュニティでの活動実績をもつ事業者とであれば話は別です。特にOCAでのコミュニティ活動に取り組む事業者の間では、あらかじめ次のような共通前提が確保されているため、協業におけるコミュニケーションコストや利害対立のリスクが大幅に抑えられます。

• ノウハウをシェアし成果物をコミュニティ資産とする価値観
• 既存のコミュニティソリューション（OCAモジュール）の知識
• オープンソースライセンスを遵守したコード管理
• OCAのガイドラインに則った開発手続きや品質管理

コタエルでは、それぞれアジアにおけるOCAの有力なコントリビュータであるタイのEcosoft社やベトナムのKomit社とともに、Odoo導入プロジェクトを遂行したことがあります。各社当然ながら固有のプラクティスも存在するものの、上記のような共通前提があることで、プロジェクトの進行もスムースで、各社のスキル・ノウハウを持ち寄ってシナジーを発揮することができました。普段からOCAでの活動を通じてゆるく協業しているようなものなので、ある意味当然のことでもあります。

コミュニティ活動に参加しない事業者間での協業で、このような成果を発揮するのは大変困難なように思われます。コタエルは実際、現在そのような協業が失敗に終わったプロジェクトの立て直しに携わっています。

特にグローバル企業で複数拠点にOdoo導入を進めていくユーザ企業は、パートナー選定においてこの観点を持っておくとよいかと思います。

5-3. 多くのOdooサービス事業者がコミュニティ活動に参加しない理由

Odooサービス事業者にとって、コミュニティ活動への参加は、顧客への提供価値を最大化させるにとどまらず、自社の実力をマーケットに見てもらう絶好の機会でもあります。自社で作成したモジュールが評価され、使われるようになると、そこからマーケットでの自社の認知が少し進みます。会社の看板を背負ってオープンな場で活動をすることは、スキルが不十分な事業者にとっては抵抗がありますが、実力ある事業者にとっては良いアピールになります。

また、情報感度の高いユーザ企業が積極的にコミュニティ活動に取り組むサービス事業者をパートナーとして選ぶケースも着実に増えていると思われます。Odoo社からの情報発信にオープンソースの文脈が欠けている一方で、ユーザ企業からの能動的な情報収集をもとにOCAのことを知り、それがきっかけでコタエルに問い合わせをいただくケースが出てきています。Odoo社公式チャネルからは伝えられないコミュニティ活動実績を、生成AIが吸い上げて説明することもあるようです。

このようにコミュニティ活動には大きな意義とメリットがある一方、実際のところ、コミュニティ活動に参加する事業者は非常に少ないです。Odooの公式パートナーは2025年6月時点で世界に3300社以上ありますが、この中でOCAの活動に参加している事業者は一部にとどまります。2024年に活動実績があった事業者は448社で、継続的に活動しているところはもっと少ないです（日本においてはコタエルのみです）。

その理由は何でしょうか？それは活動に参加して成果を出す（プルリクエストがマージされる）難易度がそれなりに高いことがあるのだと思います。

まず、「OSSコミュニティ活動のすすめ」にて挙げているように、コミュニティ活動（ここでは特にOdooやOCAのレポジトリでプルリクエストを出すことを指しています）への参加には一定のハードルがあり、次のすべてが揃っていないと活動に支障をきたします。

• Odooエコシステムがどのように成立しているか理解していること
• プロダクトに習熟していること
• コミュニティの共通言語（英語）でコミュニケーションがとれること
• コミュニティの品質基準や手続きを理解していること

これら条件を満たして提出したOdoo本体やOCAにプルリクエストは、熟練のメンバー（通常複数）の承認を受けて初めてマージされるに至ります。

条件が満たせていない事業者からすると、これらハードルを乗り越えて1つのコミュニティ活動実績を残すのは大変な手間を要します。コミュニティ活動自体は収益に直結しませんし、短期的に割りに合わないと感じられることも理解できます。

ですが、コミュニティ活動への参加は、プロダクトがTinyERPやOpenERPと呼ばれていた頃、つまりOdoo本体がオープンコア（LGPL）でなく完全にオープンソース（AGPL）であった頃のサービス事業者にとっては当たり前のことでもありました。

オープンコアへの移行で、オープンソースの世界と切り離されたエコシステムが出現するのは必然でもあったのですが、それが現状のように、コミュニティ活動に参加する新規のOdooパートナーが全く現れなくなってしまったのは、前述のとおりOdoo社公式チャネルからのマーケットへの情報発信に大きな偏りがあることにも影響されているはずです。

5-4. オープンソースを活用するための契約条件

Odooサービス事業者がコミュニティ活動に参加しない理由には、ユーザ志向やスキルの不足とは別の要因もあります。ユーザ企業との契約条件です。

オープンソースを本質的に活用することを是とした場合、Odooサービス事業者とユーザ企業間の契約で基本的に避けるべきなのは、プログラム等成果物の著作権をユーザ（発注者）側に帰属させることです。著作権法上、成果物の著作権は原始的に開発者/発明者に帰属することになっています。ですが、これをユーザ側に帰属させる条件にしてしまうと、開発機能のオープンソース化を含め、成果物の二次利用に支障をきたします。

また、機能の新規開発ではなく、既存のOdoo本体機能やOCAモジュールの改修に制約が設けられることになります。OdooやOCAのレポジトリでの活動にはコントリビュータライセンス契約（CLA）への署名が必要ですが、ユーザ企業にその手続きをとってもらうのは、多くの場合現実的ではありません。

汎用的なところはベンダー帰属、そうでないところはユーザ帰属という契約もできなくはありませんが、そのような線引きをすること自体に手続きコストがかかってしまいます。実際のところ、デザインをしっかり煮詰めると、「汎用的でない要件」というのはそれほどありません。

ですので、著作権をユーザ企業に帰属させるのは、ユーザ企業側主導でコミュニティ活動に取り組む体制がない限り、オープンソースの本質的な利活用を妨げることにほかなりません。

オープンソースに正しく向き合うには、コミュニティ活動にコミットできる主体が著作権を保持することが肝要です。実際コタエルでは、成果物の著作権はコタエルにて保持し、ユーザ企業に永続的に成果物の自由な利用・改修・配布を許諾する条件を、すべての案件で例外なく適用しています。

ユーザ企業としては、自らが著作権を保持することの意味を理解した上で、契約条件を判断すべきですし、サービス事業者側から提示される条件がユーザ企業側に著作権を帰属させるものになっていた場合は、その事業者には本質的なオープンソース活用能力は期待できないことを認識すべきです。

5-5. 事業者のコミュニティ活動実績を見るには

Odooはオープンソース（オープンコア）のプロダクトです。オープンソースのプロダクトは「情報がオープンに流通する仕組み」を備えています。多くの方は商用のプロプライエタリプロダクトに慣れすぎて観点がごっそり抜け落ちてしまっているのですが、オープンソースのプロダクトを扱う事業者の実力を見る最も有効な方法は、オープンな場所でのアウトプットを確認することです。

Odooにおいては、コミュニティ活動のアウトプットは概ね次の場所で見られます。

• OdooのGitHubレポジトリ（プルリクエストやイシュー）
• OCAのGitHubレポジトリ（各レポジトリのプルリクエストやイシュー）
• OCAのアプリストア/ Odooのアプリストア（オープンソースのもののみ）
• Transifex（Odoo本体の翻訳） / Weblate（OCAモジュールの翻訳）
• OCAメーリングリスト
• Odooフォーラム

翻訳活動に関してはプラットフォームにログインが必要などの事情で活動実績が追いにくい面がありますが、その他は大体誰でも見られるようになっています。

とはいえ、ユーザ企業の担当者にはGitHub等のプラットフォームになじみがない方もいますし、普通は各事業者のメンバーのアカウントが分からないと思いますので、その場合は気になる事業者に直接問い合わせるとよいでしょう。有意な活動実績があればすぐにリンクを出してくれるはずです。

ちなみに、先述の通りOdoo本体およびOCAレポジトリでの修正・改善活動に関してはCLAが必要です。Odoo本体に関してはOdooのGitHubレポジトリのCLAディレクトリで、その所在が確認できます。ここに登場しない事業者はCLAがなく、改善/修正提案が受け付けられませんので、Odoo本体に対する改善活動の実績がないと捉えて差し支えありません（コタエルのCLAはこちらです）。

6. サービス事業者が自社で抱え込むことの意味

6-1. 自社開発チームは強みとなるのか

自社で開発チームをかかえており、それをアピールポイントとするOdooサービス事業者もいます。ありがちなのは、日本では販売活動や要件定義のみ行い、開発は海外拠点で担当する体制です。

コタエルでも海外に開発をメインで担当するメンバーがいますが、開発チームというほどの体制はとっていません。

顧客への提供価値を最大化する上で大切なのは、しかるべきソリューションを、なるべく手間をかけずに早く提供することです。「開発チーム」がそれにうまくはまることもあるかもしれませんが、それは大規模開発が必要であるという前提でのことである気がします。

コタエルでは必要な機能はOCAで調達またはOCA内で作成した上で、個別プロジェクトではコンシェルジェ的にOCA機能を提案するスタイルをとっています。OCAでの機能開発活動にはそれなりに時間を要するものの、個別事案への対処と中長期での保守工数を減らすことができるため、少ない開発リソースでそれなりの規模のプロジェクトを遂行することが可能になります。このスタイルでは、どちらかというと要件定義をするコンサルタントが開発の知見を持ちOCAのソリューションに明るいことが重要になります。コミュニケーションにかかるコストや認識齟齬のリスクを下げるため、コンサルタントであってもコードレビューをしますし、必要に応じて機能開発もします。

無論、自社で開発チームをもっていても、このスタイルを採用することは可能です。ですが、開発チームを抱えていること自体が前面に出てくるようであると、むしろコンサルタントの要件定義能力やコンサルタントと開発チーム間の連携精度が確かなものであるのかが気になります。

開発リソースの有効活用のためのコミュニティとの協働という観点のほか、昨今は生成AIを活用した開発もできるようになっており、自前で開発チームを持つ必然性は、以前と比べてだいぶ減っているのではないでしょうか。これと同じ理由で、オフショア開発によるOdoo導入推進もその意義が薄れているように感じます。

6-2. 内製モジュール群の落とし穴

特に自前の開発チームを持っているサービス事業者でとりがちなアプローチとして、開発した機能を自社資産とした上で、ユーザ企業に課金を前提に提供するというものです。ビジネス上の手法としては分かりやすく、それ自体を否定はしません。ですがオープンソースであることをアピールしてOdooを販売する一方で、開発機能は自社のみで利用しコミュニティに還元することがない場合は、OSSコミュニティを含めたOdoo界隈全体のエコシステムの健全な発展の観点からは、あまり誠実でない手法であるように思います。もしそれら内製モジュールの作成・改善にて、オープンソースのOCAモジュールを参考にしていたりする場合はなおのことです。

界隈のエコシステムはさておき、ユーザ企業視点で理解すべきなのは、このアプローチは実質的にユーザを事業者のサービスにロックインするものであることです。もしユーザ企業がこれら機能を切替先の別サービス事業者のもとでは使えない条件となっていればロックインそのものですし、仮に使えるようになっていたとしても切替先で実装内容やその経緯を把握するのには、結構な学習コストがかかります。

この意味でも、Odooのカスタマイズには極力OCAのもとでコミュニティ資産となっているオープンソース機能を活用するのが賢明です。

7. Odoo導入パートナー選定用チェックリスト（全18項目）

ここまで、古くからコミュニティ活動に取り組むOdooエキスパートの目線で、Odooパートナーを選定する上での重要な観点を網羅的に出してきました。

これらのポイントを踏まえて、信頼できるOdooサービス事業者を選定するためのチェックリストを作成すると、次のようになります。おそらく多くのユーザ企業にてこれまで認識していなかった項目が多数あるのではないかと想像します。ぜひ自らの身を守るため、これらの項目についてサービス事業者の実態を確認するようにしてください。

8. Odooエコシステムの健全な発展に向けて

繰り返しになりますが、現状Odoo社や大多数のOdooパートナー各社から日本のマーケットに届けられる情報には、ユーザ企業にオープンソースの良さを最大限に利活用してもらうという観点が欠けています。長年コミュニティ活動に携わってきた立場からすると、この状況は中長期的なOdooエコシステムの健全な発展にはマイナスです。事実、コタエルのもとでは失敗プロジェクト立て直しのご相談が増え、Odooサービス事業者界隈のレモン市場化が進んでいることがうかがえます。

今回このような長文の記事を書いたのは、私自身の強い危機感によります。本来Odooの競争力の源泉であるはずのオープンソースコミュニティ活動が評価されず、フリーライドはおろかライセンス違反が横行する現状を変えなければ、コミュニティ活動に取り組むプレイヤーが消滅してしまう可能性すらあると考えています。コミュニティ活動のなくなってしまったOdooの優位性はどこにあるのでしょう？プロダクトはそれでも進化するのでしょうが、日本のユーザ企業は確実に割を食います。

この状況を変えるのに最も有効なのは、ユーザ企業の皆さまに積極的に声を上げていただくことなのだと思います。皆さまはコミュニティ活動が盛んで豊富なオープンソース機能の選択肢があるOdooと、標準機能とプロプライエタリの第三者機能しかなくなってしまったOdooでは、どちらに魅力を感じますか？答えは明白ではないでしょうか。

おまけ: Odoo専門家としてのキャリア安全性

本記事の趣旨とは少しズレますが、コミュニティ活動に取り組まないOdooサービス事業者のメンバーは、キャリア形成に大きく好影響を及ぼし得る機会をみすみす逃していると考えた方がよいと思われます。

個人レベルにおいて、OSSコミュニティでの活動には次のメリットが存在します。

• 百戦錬磨のコミュニティメンバーからアドバイスが得られる
• マーケットの中での自分の実力が分かる
• 英語での対人コミュニケーション力が高められる
• Odoo本体の仕組みや不足点についての理解が進む
• 活動実績がそのまま自身のポートフォリオになる

オープンで情報が自由に流通する環境に身を置くのと、自社に閉じた環境にいるのとでは、数年スパンで身につけられるスキルセットに雲泥の差が生じます。

コタエルで成果が出せるメンバーはどこに行っても通用すると自信を持って言えますが、コミュニティ活動に取り組まない事業者でOdooの経験を積んだ人がコタエルに参画しても、すぐに成果を出せるとは限りません。

コタエルでOdoo経験者の採用を検討する際には、確実に、コミュニティ活動の実績や、それがなければ活動に取り組む意志を重視します。

Photo by Andy Beales on Unsplash