【入門編】Odooコミュニティ(OCA)活動の始め方

Odooを使っていると、

• 「この機能、もう少しこうなればいいのに」
• 「日本向けにこういう対応が必要だよね」
• 「この便利機能、他の人にも共有できないかな」

と思うことはありませんか？

そうした改善やアイデアを、世界中の開発者と一緒に形にしていく場が Odooコミュニティ（OCA）活動 です。

この記事では、

 「OCAって何？」

 「どうやって始めるの？」

 という方に向けて、最初の一歩を分かりやすく解説します。

OCAとは

OCA（Odoo Community Association）は、Odooのコミュニティ版をより良くするための国際的な非営利団体です。

世界中の開発者や企業が協力し、

• 機能追加モジュールの開発
• 不具合修正
• 翻訳
• コードレビュー

などを行っています。

詳しくはこちらの記事もご覧ください。

 👉OCA（Odoo Community Association）とは？Odoo導入前に知っておきたい役割とメリット 

 👉2025年版 日本でのOdoo導入で欠かせないコタエル作のOCAモジュール5選

OCA情報サイト

OCA活動を始めるうえで、知っておきたいサイトをご紹介します。

🌐 OCA公式サイト（活動の全体像をつかむ場所）

https://odoo-community.org/

OCAの理念・活動内容・ガイドラインがまとまっている“公式の玄関口”です。 OCAがどんな組織で、どんな目的で活動しているのかを理解するのに最適です。

• ハウツーガイド： https://odoo-community.org/how-to-guides

 OCAのルールや貢献の流れが体系的にまとまっています。

• OCAアプリストア： https://apps.odoo-community.org/shop

OCAが公開しているモジュールを検索できます。ただし、すべてのOCAモジュールが掲載されているわけではないため、アプリを探すときはGitHubも併用するのが確実です。

💻 GitHub（実際の開発・議論が行われる中心地）

https://github.com/OCA

OCA活動の“本丸”です。モジュール開発、Issueの議論、PRのレビューなど、すべての実務がここで行われます。

• OCA Guidlines：https://github.com/OCA/odoo-community.org/blob/master/website/Contribution/CONTRIBUTING.rst

OCAのモジュール開発に関する統一ルールをまとめた文書です。

よく使われるリポジトリ：

• 日本ローカリゼーション（l10n-japan）： https://github.com/OCA/l10n-japan/

日本向けの会計・税制・商習慣に関するモジュールが集まっています。日本企業がOdooを使う上で重要な改善が多く議論されています。

• OCB（Odoo Community Backports）： https://github.com/OCA/OCB

Odoo社のサポートが終了したバージョンに対して、OCAが独自にバグ修正やセキュリティ対応を行うリポジトリです。 長期運用している企業にとっては非常に重要な存在です。

🌏 Weblate（翻訳プラットフォーム）

https://translation.odoo-community.org/

OCAモジュールの翻訳を管理するサイトです。

英語が苦手でも、翻訳作業は比較的参加しやすい入口です。ブラウザ上で翻訳できるため、環境構築は不要で、技術的な知識がなくても参加できます。

OCA活動を始めるには？

「参加してみたいけれど、なんだか難しそう…」と感じる方も多いと思います。

理由は主に次の2つです。

• 国際コミュニティのため、基本的にやり取りは英語
• 仕組みやルールが多く、全体像がつかみにくい

ただし、いまは翻訳ツールが非常に優秀になっており、言語の壁は以前よりずっと低くなっています。 ウェブブラウザの翻訳機能や DeepL などのツールを使えば、英語のやり取りも十分こなせます。

また、OCAに関する詳細な情報は英語で豊富にありますが、全体像を日本語でまとめた資料はほとんどありません。

 そこでこの記事では、OCA活動の概要をつかみ、最初の一歩を踏み出せるように整理しました。

何から始めるのがおすすめ？（難易度順）

OCA活動には、いろいろな形で参加することができます。

 ここでは、難易度の低いものから順番にご紹介します。

1．翻訳（★☆☆）

もっとも始めやすいのが翻訳活動です。

• 日本語の修正
• 未翻訳部分の追加
• 用語の統一

技術的な開発スキルがなくても参加できます。

翻訳を始めるには、まず transbot@odoo-community.org 宛に「翻訳したい言語」と「登録したいメールアドレス」を送り、アカウントを登録します。その後、Weblateという翻訳プラットフォームで翻訳を行います。

OCAの翻訳に関する詳細情報はこちら

2．レビュー（★☆☆）

次のステップはプルリクエスト（PR：改善提案）のレビューです。

OCAでは、誰かが出したPRは、必ず第三者の確認（レビュー）を経てマージされます。

• コードの確認
• 機能テスト
• コメントでの指摘

レビューは開発と同じくらい重要な活動です。

GitHubアカウントをお持ちの方ならどなたでもレビューを投稿できます。

OCAのレビューに関するページはこちら

レビューにはコードレビューと機能レビューがありますが、機能レビューは自分で環境を構築しなくてもGitHub上からOCAのOdooインスタンスにアクセスして行うことができます。

【Runboatを使った機能レビュー】

①．OCA配下リポジトリのPRを選択し、チェック結果欄の全てを表示します。

②．runboat/build をクリックします。

緑色でない場合は、"Start"ボタンを押して起動を待ちます。

緑色になったら、"live"ボタンをクリックします。

③．Odooにログインします。

２つのデータベースが表示されます。

• 末尾が "baseonly"：モジュールが何もインストールされていない環境
• もう1つ：PRリポジトリのモジュール＋依存モジュールがインストールされた環境

どらかのデータベースを選択し、ユーザID：admin、パスワード：admin でログインします。

ログインした環境で、自由に機能テストを行うことができます。

④．レビューを登録する

「File Changed」タブを選択し、「Submit Review」をクリックします。

コメントを入力し、テスト結果が期待通りであった場合は"Approve"、それ以外の場合は"Comment（コメント）"または、"Request Changes（変更依頼）"を選択し、"Submit Review"をクリックします。

【コードレビュー】

コードをレビューした結果は、上記の「④．レビューを登録する」と同様にレビュー内容と結果を登録します。

※ レビューのコメント内容は、テストで確認した内容（動作、エッジケース、テスト、可読性など）を簡潔に英語で入力します。

3．バグの報告（★★☆）

OCAモジュールのバグを見つけた場合は、GitHub上でIssue（イシュー）を出します。

バグの報告に関する詳細情報はこちら

①．バグのあるリポジトリを特定し、Issueタブを開いて、「New Issue」ボタンをクリックします。

※ Issue を作成する前に、同じ問題を扱った Issue がすでに存在しないか確認してください。

②．「Bug Report」を選択します。

③．バグの詳細について報告します。

Title：バグの内容について簡潔に記載してください。

Module：バグが発生しているモジュール名を記載してください。

Describe the bug：発生しているバグの内容を、簡潔かつ明確に説明してください。

To Reproduce：バグを再現するための手順を記載してください。１．２．３．

Affected versions：バージョン

Expected behavior： 期待される動作。本来どのように動作することを期待していたかを記載してください。

Additional context：追加情報。問題に関連するその他の情報を記載してください（例：OS、Python のバージョンなど）。

※ 他のコントリビューターから、バグの特定に役立つ追加情報を求められる場合があります。必ず回答してください。スキルをお持ちの場合は、修正コードを書いて共有します。

※バグを報告してすぐに対応してもらえるケースは少ないかもしれません。Issueを簡潔に分かりやすく書くことが重要です。

４．改善提案（★★☆）

既存のOCAモジュールのバグを修正したり、機能を追加したい場合は、実際にコードを修正し、GitHub上でPR（プルリクエスト）を出します。

PR作成に関する詳細情報はこちら

 OCAのガイドラインに沿って修正し、PRを提出します。ここでは概要の手順のみを説明します。

①．CLAを登録します。

CLA（Contributor License Agreement：コントリビューターライセンス契約）

https://odoo-community.org/about/cla

※ OCAにコードを提供する場合、最初にCLAが必要です。

②．PRを作成するリポジトリをフォークし、開発環境にクローンします。

③．開発環境で、ローカルブランチに修正をコミットし、フォークした GitHub リポジトリにプッシュします。

コミットメッセージは、コミットメッセージ規則に従います。

④．PRを作成します。

PRには、レビュー担当者が状況を把握できるように、説明を入力します。関連するIsuueがある場合は、Isuueへのリンクを追加します。

※ PRのすべてのチェックが通り（緑色）になり、5日以内に3件の肯定的なレビュー（5日を超える場合は2件）を獲得するとマージされます。上記のレビューのうち少なくとも1件は、PSC(Project Steering Committee：プロジェクト運営委員会）のメンバー またはOCAコアメンテナーによるものでなければなりません。

５．バージョンアップ対応（★★☆）

Odooは毎年バージョンアップします。既存モジュールを新バージョンへ移行する作業も重要な貢献です。

モジュールにより旧バージョンから修正がほとんど必要ないケースもありますが、Odoo本体の関連する箇所がバージョンアップにより大幅に変更になっている場合は、依存するOCAモジュールも大幅な変更が必要になるケースもあります。

バージョンアップは地道ですが、コミュニティにとって非常に価値の高い活動です。

OCAモジュールのバージョンアップ開発についての詳細情報はこちら

手順としては、「４．改善提案」と同様にGitHub上で行います。

６．モジュール追加提案（★★★）

最も難易度が高いのが、新規モジュールの提案です。Odoo標準機能、開発ルール、OCAへの深い理解と設計力が求められます。

• 要件整理
• 設計
• 実装
• テスト
• ドキュメント作成

手順としては、「４．改善提案」と同様にGitHub上で行います。

大切なのは「段階的に挑戦すること」

最初から高度な開発を目指す必要はありません。

翻訳 ・レビュー →  バグ報告 → 小さな修正 → バージョンアップ → 新規モジュール提案

という流れで、少しずつ関わりを深めていくのが理想的です。

コミュニティ活動は人との関わりの中で行われるため、実績があるほど Issue や PR がレビューされやすくなる 傾向があります。

OCA活動は、

• Odooをより深く理解できる
• 世界中の開発者とつながれる
• 実績がオープンに残る
• 技術力の証明になる

という大きなメリットがあります。

まずは、「見るだけ」からでも大丈夫です。

GitHub上でどのようなOCAモジュールがあるのか探したり、他の人が作成したIsuueやPRを読んだりすることから始めてみてください。

そこから、あなたのコミュニティ活動が始まります。