Odooの1つの修正で1日12分を節約する方法

Odoo Community はリードからメール送信を行う際、リードに登録されている連絡先を受信者に自動で入れません。検索して入力して選択する作業がメール1通あたり約15秒かかります。少しの時間に思えますが、CRMから営業チームが1日に送るメール数で掛け合わせると違いが出ます。計算は下の方にあり、概算で示しています。ご自身の試算には1つの数値だけ必要です。

この記事では、なぜ Odoo の標準動作が営業チームに不利に働くのか、修正がどういうものか、そしていつシステムを変えるよりも局所的な対処が適切かを示します。

問題点：空の受信者欄

Odoo Community Edition を CRM として使っている方は経験があるかもしれません：リードを開き、「メール送信」をクリックすると、メール作成画面が開きますが、受信者欄が空になっているのです。

リードには連絡先が登録されており、メールアドレスも入っています。しかし Composer はそれを引き継ぎません。

その後に起きるのは毎回同じ手順です：

1. 受信者欄に連絡先名を入力する
2. ドロップダウンリストから正しい連絡先を選ぶ
3. その後で実際のメールを書く

1通あたり多分15秒ほどかかります。取るに足らないように聞こえます。

誰も計算しない損失

しかし計算してみましょう：CRM から1日約50通のメールを送るとすると、これは毎日12分の時間損失になります—本来すでにある受信者を手作業で入れるだけのために。

月単位では4時間超になります。年換算では従業員1人あたりおよそ50時間です。

年に50時間です。本来システムが自動でやるべき作業のために。

そしてこれは測定できる部分に過ぎません。本当の損失はもっと微妙です：余分なクリックごとに注意が逸れ、流れが途切れ、あるいはメールを書かないという結果につながることがあります。営業では速度が重要で、不要な障害は受注を失う原因になります。

思いつきの解決策—しかしそれは間違い

一見した解決策は：Odoo Enterprise を買うことです。Enterprise では Mail-Composer の動きが改善され、機能やサポートも充実しています。

しかし Odoo Enterprise はユーザーあたり月額ライセンスです。10人のチームだと月に数百ユーロになりかねません—しかも問題の核心は欠けている1行のコードでしかない機能のためにです。

これは Odoo Enterprise を否定するものではありません。アップグレードの合理的な理由はあります。しかし唯一の問題が空の受信者欄だけなら、ライセンス変更は大砲で雀を撃つようなものです。

我々の解決策：1つの Python ファイル

我々は問題を解析し、判明したのは：Odoo Community の Mail-Composer は CRM リードから開かれた際に単純にリードに登録された連絡先を考慮していない、ということでした。これは古典的なバグというよりも、単にそのためのロジックが欠けているだけです。

解決策は最小限の Odoo モジュールで、やることは1つだけ：Mail-Composer が CRM リードから開かれた場合、リードの連絡先を自動で受信者に入れる、というものです。

それだけです。 新しいメニューも、データベースの新しいフィールドも、設定も不要です。Mail-Composer の挙動を CRM リード向けに拡張する単一の Python ファイルだけです。他はそのままです。

以前の動作

「メール送信」をクリックすると Composer が開きますが、受信者欄は空です。連絡先名を入力し、ドロップダウンを待って正しい項目をクリックします。その後でようやくメールを書けます。

修正後の動作

「メール送信」をクリックすると Composer が開き、受信者は既に入っています。すぐに書き始められます。

なぜこれを伝えるのか

技術的に見せ場があるからではありません—むしろその逆です。伝えたいのは繰り返し見られるパターンです：

小さく具体的な問題が大きく高額な決断の口実になる。

• 「Mail-Composer が不便だ」→「Odoo Enterprise が必要だ」
• 「テーブルが見づらい」→「新しい ERP が必要だ」
• 「レポーティングが足りない」→「BI プラットフォームが必要だ」

場合によってはそれが正しい判断です。大きな解決が必要なこともあります。しかしまず問うべきは：問題は正確に何か、そしてそれを直す最小の解決は何か？

いつ修正で足りるか—いつ新しいソフトが必要か

局所的な修正で足りる場合：

• 問題が明確に限定されている—ある機能が欠けている、ある手順が阻害されている
• 既存ソフトが基本的に合っており、チームに受け入れられている
• 修正が保守可能で、壊れやすい特注に依存しない
• 修正コストがシステム移行のコストを大きく下回る

新しいソフトが適切な場合：

• 複数の根本的要件が満たされていない
• 既存システムがもはや開発・保守されていない
• アーキテクチャが構造的に合わない—たとえば API がない、マルチテナントに対応していない、など
• ワークアラウンドの労力がライセンス費用を上回る

結論

この例は意図的に小さなものです。目的は革命ではなく姿勢です：新しいソフトを探し始める前に、まず今あるものを注意深く見る価値があります。

我々はこの修正を毎日自分たちでも使っています。時間とストレスを節約しており、数時間の解析と開発以外に費用はかかっていません。

このモジュールは Odoo App Store で無償のオープンソースとして公開しています—このような基本的なワークフロー修正は全ての Odoo Community ユーザーが利用できるべきだと考えるからです。

同じような問題を御社のシステムで抱えていますか？ 多くの場合、費用のかかる代替案を検討する前に、一度お話しするだけで局所的な修正が可能かどうかがわかります。