Odoo 発表資料・解説動画

Odooの導入・カスタマイズ・日本語化、そしてオープンソースコミュニティ活動について、コタエルがイベントやウェビナーで使用した発表資料と解説動画を公開しています。

最終更新	2026/08/02
完了時間	2 時間 31 分
メンバー	1

コース
レビュー

Odoo概要/ノウハウ

全て表示

新規コンテンツ

OCA活動への参加方法（Odooオープントーク 2026年7月31日発表資料）

プレビュー表示

2026年7月31日に開催されたOdooオープントークで使用したスライドです。「OCA（Odoo Community Association）の活動に、どこからどう入るか」を、コードを書ける人にも書けない人にも向けて整理しました。

Odooを使う企業は日本でも増えましたが、エコシステムに返す企業はまだ多くありません。この資料は、その差が「意欲」ではなく「入口を知っているかどうか」だけであるという前提で、最初の一歩を具体的に示すことを目的としています。

取り上げている内容

OCA（Odoo Community Association）とは何か ―― Odoo S.A. との関係、AGPL/LGPLでの成果物
貢献は「コードを書く」だけではない ―― 翻訳・Issue・レビュー・ドキュメント
困っていることをIssueにする ―― 社内で解決して終わらせず、公開の場に置く
技術者ルート ―― CLAの提出から、小さなPRを出すまで
PRがマージされるまでの流れと、実際にかかる時間の目安
実例：2行のPRがどう進んだか（OCA/account-invoicing#2201）
新規貢献者がやりがちなミス ―― 翻訳PRを直接投げる、など
AIを使って貢献するときのルール ―― OCAの生成AI・LLMポリシー（2026年7月施行）
個人の貢献の先にあるもの ―― 企業として関わることの必要性
日本コミュニティとしての現実的な入口
用語集

取り上げている内容

世界で通用した勝ち筋が日本で停滞する理由 ―― 日本語UIとドキュメントが必須であること、言語的距離の大きさ、取引先に合わせて業務が変わること、独特の商習慣、実績を重んじる慎重な導入判断、そして強い国産の会計・人事ソフト
転換点 ―― Odoo社が2023年に翻訳を内製化して日本語UIが実用水準に達したこと、日本での認知向上、AIによる言語・実装障壁の低下
OCAへの貢献の実情 ―― 2024年にOCAへ貢献したパートナーは3,300社中448社にとどまり、パートナー総数が16,000社を超えるなかでその比率は縮小し続けている
Odoo S.A. への3つの提案 ―― 貢献する事業者を正当に評価すること、日本のローカライズを重複させず協働すること、新規パートナーにOSSの作法を伝えること
好循環を壊すもの ―― OCAへのフリーライド、「オープン」が実践ではなく宣伝文句になること、ローカライズの遅れによる満足度低下、差別化を失って価格競争に陥ること
健全なOSSエコシステムがOdoo S.A. のビジネスにも有利である理由 ―― 顧客獲得コストの低減、製品改善の高速化、パートナーの実力向上

取り上げている内容

Odooの歴史とライセンスの変遷 ―― TinyERPからOpenERP、Odooへ。GPL、AGPLを経て2015年10月にLGPL＋プロプライエタリのオープンコアモデルへ移行した経緯
なぜオープンコアに移ったのか ―― AGPL時代は開発元の収益確保が難しく、サービス販売に依存せざるを得なかった
ライセンスの違い ―― LGPLv3はプロプライエタリ機能を上に載せられる。AGPLv3は依存するコードにも同じライセンスが及び、ソースの入手可能性が求められる
Odooの発展サイクル ―― プロダクトの進化、ユーザベース獲得、マネタイズ、そして再投資という循環を、オープンソースがレバレッジしている
エコシステムの登場人物 ―― Odoo社、パートナー、その他事業者、OSSコントリビュータ、ユーザがそれぞれどう関わるか
Odoo社のフォーカスの変化 ―― オープンコア移行後、必然的に販売部門の声が大きくなった
いま懸念していること ―― 市場に接するスタッフやパートナーの多くがOSSエコシステムに無頓着に見え、新規参入パートナーがOSS活動に参加しない
ユーザにとって最悪のシナリオ ―― OCAモジュールでユーザ課題の6割は解決できるのに、そのエコシステムが死ねば個別開発のプロプライエタリ機能に戻ることになる
OSS活動に参加すべき理由と、参加しない理由を並べて検討する
まず誰にでもできること ―― コミュニティモジュールを使ってみる、使っていることをユーザに説明する、情報発信する

取り上げている内容

何が翻訳対象になるのか ―― 項目ラベル、メニュー、ボタン、ヘルプテキスト、レポート、メールテンプレート、ウェブサイト、エラーや警告のメッセージ、そして翻訳対象として定義されたデータ項目
ソースコード上での見分け方 ―― Pythonのフィールド定義における translate=True、アンダースコア関数で囲まれたメッセージ、XMLのビューやテンプレート内の文字列
管理領域による違い ―― Odoo本体、OCAモジュール、そして自社のカスタムモジュールでは、翻訳ファイルの更新経路がそれぞれ異なる
処理エンジンによる違い ―― サーバー側で処理されるものとフロントエンド側で処理されるものがあり、ウェブサイト側のテンプレートは制約が出やすい
翻訳データの格納場所 ―― 15.0まではテーブルに持っていたが、16.0からは対象項目にjsonb形式で保持される。性能は改善した一方、画面からの調整はしにくくなった
プロジェクト固有の訳語を当てる方法 ―― カスタムモジュールは通常どおり翻訳ファイルを更新し、Odoo標準機能は i18n_extra フォルダに上書き用の翻訳を置く
ありがちな問題 ―― 同一モジュール内での訳語の衝突。SendやStateのように文脈で訳し分けたい語が同じ文字列として扱われる
役に立つOCAモジュール ―― template_content_swapper と report_qweb_field_converter

取り上げている内容

Odooとは何か ―― 世界でもっとも使われているオープンソースの業務アプリケーションスイートであること、技術構成、対応領域の広さ、多通貨・多言語対応、そしてコミュニティの規模
Odooの特長 ―― 低コスト、幅広い業務領域のカバー、グローバル対応
Odooとオープンソース ―― 発展サイクル、コミュニティ版と企業版の違い、そしてOCAの位置づけ
日本マーケットの特徴 ―― 日本語情報とプロダクト日本語化が必須であること、特殊な商習慣、失敗を恐れる文化、英語での情報発信の少なさ
デモを通じた課題への対処 ―― 日本固有の要件に対し、OCAのコミュニティモジュールでどこまで解決できるか
Odooを試してみる方法
Odoo導入プロジェクトを進めるうえでのコツ

取り上げている内容

Odooのカスタマイズとは ―― パラメータ設定とアドオン機能開発の違い、そしてPython、PostgreSQL、JavaScript、QWebというテクノロジースタック
カスタマイズは極力避けるべきという前提 ―― 費用がかかり、保守が難しくなり、バージョンアップがしにくくなる
課題への対応例1 ―― 登録番号を請求書に表示する（インボイス制度対応）。まずドキュメントレイアウト設定で8割方は足りるが、足りない場合はアドオンモジュールで対応する
課題への対応例2 ―― 会計証憑の添付削除を防ぐ（電子帳簿保存法対応）。attachment_delete_restrict でモデルごとに削除可能なグループやユーザを指定する
Odooのモジュール構造 ―― 機能はすべてモジュールであり、base、web、mail、product、account、saleと依存関係で積み上がる。カスタムモジュールも技術的には標準機能と同列
モジュールの構成要素 ―― ビジネスオブジェクト、データファイル、ウェブコントローラ、静的ウェブデータ
実際のコード ―― __manifest__.py、モデル定義、そしてビューを継承するXMLの書き方
モジュール作成時の注意点 ―― 上書きせず拡張する、ORMを通してレコードを操作する、いらないものは作らない、業務目的ごとに分ける、ライセンス違反をしない
オープンソースを理解する ―― OCAの役割と、LGPLv3とAGPLv3の違い。Odooは「ライセンスフリー」ではない

あらすじ

音響機器メーカーを率いる堀場さん。従業員45名で1日4,500件のオーダーを処理していた、1人当たり100件の会社だった
財務部長の斉藤さんは、物流システムからの請求書作成、タイムシート取り込み、返金処理、レポート作成、オンラインショップとの同期、支払処理に追われている
数年のあいだに個別のITツールが次々と増え、業務はつながらないまま複雑になっていった
2015年、従業員は90名に増えたのにオーダーは1日5,000件どまり。1人当たりの処理件数は55件と、5年前から45%も落ち込み、利益率も低下した
人事部長の北田さんから採用管理ソフトの導入を求められた堀場さんは、また新しいシステムが増えることに悩む
乱立したITインフラを一つにまとめたいと考えていたところでOdooに出会い、まず採用アプリから小さく始める
CRM、製造、販売、BI、プロジェクト、会計と適用範囲を広げるにつれ、1人当たりの処理件数は55件から段階的に回復し、ITコストは年750万円から下がっていく

取り上げている内容

リストビューからの出力手順 ―― 対象モデルの一覧を開き、左端のチェックボックスでレコードを選び、アクションメニューからエクスポートを選ぶ。アクションボタンはレコードを選択しないと現れない
出力項目の選択 ―― 左側の一覧から必要な項目を選び、ExcelとCSVのいずれかを指定して書き出す
項目リストの保存 ―― よく使う組み合わせを保存しておくと、次回以降の項目選択の手間が省ける
エクスポートの2種類の使い分け ―― 「すべてのデータをエクスポート」は、参照しているモデルだけでなくリレーション先のモデルの項目も出力できるため、レポーティングなど参照目的に向く
もう一方の「インポート可能なフォーマットでのエクスポート」は、そのモデルに直接含まれる項目のみを出力する。インポート用のテンプレートを作る場合や、出力したデータを直して取り込み直す場合はこちら

Odooの翻訳について

概要 ―― 翻訳はOdoo社の専任チームが管理し、数日おきにGitHubのOdooレポジトリへ反映される。チーム外の人は「提案」を出し、承認されると反映される
準備 ―― アカウント登録後、translations@odoo.com へ申請する。近年は審査が厳しくなっているため、所属会社・ERP経験・翻訳経験を書き添える
翻訳用のOdoo環境がない場合は、runbotの環境を利用できる
Weblateの構成 ―― プロジェクトがOdooのバージョンに、コンポーネントが各モジュールに対応する
対象モジュールの特定 ―― 開発者モードのデバッグメニューからフィールドを確認し、「関連モジュール」がWeblateのコンポーネントに対応する
検索クエリの書き方 ―― source: 原文、target: 訳文、component: コンポーネント名、project: プロジェクトのslug名。完全一致は = を付ける
注意点 ―― 原文にタグが含まれる場合はタグを変更しない。消すと実行時エラーになる
対応バージョン ―― メジャーバージョンすべてと最新のSaaSバージョンに提案を出す。新バージョンの翻訳は最新SaaSから取り込まれるため、ここを直さないと古い訳が残る
訳語の品質ルール ―― コロンと括弧は半角、エラーやヘルプは敬体、項目説明は体言止めか常体、用語は過去訳をWeblateで検索して統一し、大幅な意訳は避ける
コンポーネント単位での翻訳ファイルのアップロード（「提案として追加」のみ）と、Odoo側で翻訳を最新化する手順

OCAの翻訳について

Odooとの違い ―― プロジェクトの単位はレポジトリとバージョンの組み合わせ、GitHubへの反映は毎日、そして承認を待たずに反映される
準備 ―― GitHubアカウントで登録し、transbot@odoo-community.org へ希望言語を添えて連絡する（処理まで1週間程度）
日本語の翻訳言語がまだ無いコンポーネントでは、自分で追加してから翻訳を始める
モジュール単位で作業することが多いため、翻訳ファイルのダウンロードとアップロードが便利

取り上げている内容

Odooのマーケットポジション ―― 主要ERPの検索トレンド比較、そして他のオープンソースERPとの比較
Odooがなぜ世界で人気なのか ―― 低コスト、幅広い領域のカバー、グローバル対応という3点
OSSプロダクトの発展サイクル ―― OdooはオープンソースERPのなかで、この循環を回すのにもっとも成功している
日本マーケットの特徴 ―― 日本語情報とプロダクト日本語化が必須であること、特殊な商習慣、失敗を恐れる文化
オープンソースとは何か、そしてユーザ・サービス事業者・開発元それぞれにとってのメリット
導入形態の違い ―― パートナーに依頼する場合と自力で導入する場合
Odooコミュニティ協会（OCA）の存在意義と、バージョン別のモジュール数の内訳
コタエル（Quartile）の紹介と、コミュニティでの活動内容
カスタマイズ事例 ―― 購買登録時の項目追加、仕入先テーブルからのデータ呼び出し、品切れ商品の自動アーカイブ、落札データの一括インポートなど
導入ユーザの声と、パートナー選びが重要である理由

Odoo 発表資料・解説動画

Odoo概要/ノウハウ

取り上げている内容

関連リンク

取り上げている内容

関連リンク

取り上げている内容

関連リンク

取り上げている内容

関連リンク

取り上げている内容

関連リンク

取り上げている内容

関連リンク

あらすじ

関連リンク

取り上げている内容

関連リンク

Odooの翻訳について

OCAの翻訳について

関連リンク

取り上げている内容

関連リンク