2022年のことですが、株式会社エムアイセブンジャパン（現 株式会社ジェネレックジャパン）様（以下、「エムアイセブン様」）でご利用いただいているOdooのバージョンをV10からV15に上げました。コタエルでは過去数社のお客様向けにバージョンアップ作業を行っていますが、日本で外向けに紹介されている事例はまだほとんどありません。その中で苦労したことなど。どちらかというと注意点ばかりで読んで楽しいものではないかもしれませんが、Odooサービス事業者・ユーザ企業ともに参考になる内容を盛り込んだつもりですので、ぜひご一読ください。
エムアイセブン様について
エムアイセブン様は、海外のハイテク電子楽器や業務用音響機器のハードウェアメーカーおよび楽譜作成や楽曲編集のソフトウェアメーカーの日本市場参入と市場育成を担うディストリビュータです。製品の輸入販売にとどまらず、マーケティング戦略策定や合弁現地法人設立等、案件に応じて多面的に活動しています。
この事業ドメインにおけるパイオニアとしてメディア産業界に貢献すべく、ITを活用しリアルタイムで在庫照合、受注発注、課金照合等を行う仕組みを構築し、高付加価値なサービスを提供体制を整えています。その仕組みを担うプラットフォームとしてOdooを採用しています。
- Odoo利用アプリ：販売、Eコマース、購買、在庫、製造、請求
- ユーザ数：約20名
プロジェクト背景
エムアイセブン様はもともと他のOdooサービス事業者のもとでOdoo導入を進め2018年秋にOdooの運用を開始しました。その事業者からの一方的なサービス条件の変更等の事情があったことからパートナーを切り替え、2020年夏からコタエルのサービスをご利用いただいています。
2020年の秋頃からエムアイセブン様では自社のサービス改革のためにOdooの利用スコープを拡大したいという要望が具体化していました。一方でV10は2019年秋にはOdoo社のサポート対象から外れたものとなっており保守性やセキュリティ担保のため新バージョンへの切り替えが待たれる状態になっていました。いわば攻守両面からバージョンアップの必要性が高まっていたということです。
既存のOdoo環境に目を向けると、「膨大なカスタマイズがされている」という事実がバージョンアップの阻害要因となっていました。コタエルでエムアイセブン様のサポートを引き受けたときには、実に有意な部分（コメント、空白行、翻訳等を除く）のみで54,000行以上（テーマを除くと27,000行以上）のカスタマイズが施された状態でした。コタエルにて個別の保守要求事項に対応する中で少しずつカスタマイズ内容理解を進めてはいたものの、バージョンアッププロジェクト開始の段階ではその全貌を理解するには程遠い状態でした。
作業の流れ
ものすごくざっくり言うと、データベース構造とカスタムモジュールを新バージョンに対応させるとOdooを新バージョンで利用することが可能です。
狭い意味での「バージョンアップ」作業はこの通りなのですが、今回の特殊事情としては、私たちが全貌を把握していない膨大なカスタマイズがあるということでした。引き継いだカスタムコードの品質が良くないことは認識していましたので、まずこれをきれいに整理すべきと考えました。すなわち、データベースとカスタムモジュールの新バージョン対応作業にかかる前に、「要件棚卸および既存のカスタマイズモジュールの改善」を実施すべきとなりました。
ということで、大まかな流れとしては次のとおりでした。
１．要件棚卸および既存のカスタムモジュールの改善
２．カスタムモジュールの新バージョン対応
３．データベースの新バージョン対応
１．要件棚卸および既存のカスタマイズモジュールの改善
こちらの作業、開始時には若干楽観視していたところもあった（反省）のですが、蓋を開けてみると結構果てしない作業でした。
- 当初の想定：既存のカスタムコードの半分程度手直しが必要
- 実際：既存のカスタムコードの9割方手直し
既存のカスタムコードは次のいずれかに振り分けていきました。
a) 不要な実装
b) 意図がわからない実装
c) 必要だけれども保守性に難がある実装
d) 必要で品質がOKの実装
当初、a)～c)が半分くらないのかなという感覚でいたのですが、実際に内容を紐解いていくと、ほとんどがここに該当していました。
「a) 不要な実装」というのは、多くがOdooの標準機能で対処できるはずのものを、わざわざ機能を作成して対処しているというものでした。これらについては個別のポイントにつきお客様と認識合わせのうえ機能を切り捨てていく（標準機能を使用した運用に切り替えていただく）というステップをふんでいきました。
「b) 意図がわからない実装」も多数あり、すべて個別にお客様の認識合わせをしていては時間がいくらあっても足りないほどでした。ある程度は私たちの判断で不要と判断して切り捨て（この部分は「a) 不要な実装」ということになる）、そうすることにリスクがありそうな部分についてはお客様から過去の経緯をヒアリングするなどして、ゼロベースであるべき実装を見直した上で改修作業を行いました。
残りの大部分は「c) 必要だけれども保守性に難がある実装」でした。いくつか例を挙げると、
モジュール作成単位が機能目的ごとでなく「xxx_sale」のように業務領域単位となっており、その中に様々な目的の機能がごった煮のように放り込まれている
- 上記のため、モジュール間の依存関係が破綻したところ（相互依存関係になっているもの）が何箇所もある
- 標準メソッドの拡張でなく上書きが多用されている
- 同じメソッドがいろんな場所にコピペされている
等で、これらの解消には相当の時間（500時間以上）を要しました。もうやりたくない。
結果、ウェブサイトのテーマを除いて27,000行以上あったカスタムコードは18,000行程度に圧縮されました。これはOdoo社でカスタムコードの保守を引き受けた場合のレート（100行ごとにUSD18/月）をもとに考えると、月額22万円以上（USD1=JPY140で計算した場合）の保守費用低減効果があったことになります。
２．カスタムモジュールの新バージョン対応
カスタムモジュールの新バージョン対応はコタエルでの作業となります。これも有償でOdoo社に対応してもらうという選択肢がなくもないのですが、今回はそれは現実的なオプションではありませんでした。いかんせんボリュームが大きく、その内容の大幅な見直しが必要であることを当初より認識していたからです。Odoo社のサービススコープには要件定義作業は含まれません。
３．データベースの新バージョン対応
データベースの新バージョン対応は、Odoo企業版を利用している場合はOdoo社の専用スクリプトでサポートされます。コミュニティ版を利用している場合は、OCAで更新しているOpenUpgradeのスクリプト群を使用しての作業となります。エムアイセブン様には企業版をご利用いただいているため前者での対応となりました。
成果
ざっくりと次のような成果があがりました。
- 全体的にパフォーマンスが上がった（さくさく動くようになった）
- 操作性/生産性が上がった
- カスタムコードのクリーンアップにより保守コストが低減できた
- お客様がOdoo機能につきより深く理解できた
- 新領域への対応がとれる下地ができた
全体的にパフォーマンスが上がった（さくさく動くようになった）
フロントエンド（ショップ）、バックエンドともにパフォーマンスが上がりました。とくに顧客のUXに直結するショップの画面ロードスピードが格段に上がったのは大きな成果でした。
操作性/生産性が上がった
Odooもバージョンを重ねる中で様々なUIの改善を施してきました。バックエンドに目を向けると、インポート/エクスポート機能、メニュー検索、複数レコードの項目値一括更新機能等。フロントエンドでは各種スニペットが充実して表現力が豊かになり、第三者テーマに依存しなくとも手間をかけずにウェブサイトの見た目をきれいに整えることができるようになりました。
カスタムコードのクリーンアップにより保守コストが低減できた
先述の通りカスタムコードのボリュームを大幅に削減し、また継続インテグレーションツールでの環境ビルドが通せる状態になったため、問題が発生したときのトラブル対応が、以前と比べると格段にやりやすくなり、また変更適用時のトラブル発生可能性を大幅にへらすことができました。
お客様がOdoo機能につきより深く理解できた
引き継いだカスタムモジュールの根拠/背景が定かでない場面が多数ありましたため、半ばOdooの新規導入さながらに要件定義のやり直しをする状況となりました。その際にOdooの標準機能のコンセプトや制約、OCAモジュールの機能、カスタマイズ方針等をつぶさに説明さしあげる中で、お客様のOdooについての理解が以前に比べ格段に進んだという評価をいただきました。何か問題があったときに、以前はどうすればよいか分からなかったけれども、今は大体どこを見ればよいか勘所がついたとのこと。
コタエルでは機能や問題状況への対処内容を説明する際に、具体的なデータやその確認方法、仕様策定の背景等についても説明することを意識しているため、Odooに興味を持って取り組まれるお客様はノウハウが身につき、問題状況にある程度自力で対処いただけるようになります。この点は今回明確に期待していた成果ではありませんでしたが、ご認識いただけたのは大変喜ばしいことでした。
新領域への対応がとれる下地ができた
今回の移行作業前は、引き継いだカスタムモジュールによりOdoo標準の挙動が変更されていたり、制約が加えられていたりで、継続インテグレーションでの環境ビルドやテストも通らない状態でした。ここから導入対象領域を追加したり新たにカスタマイズを施すのはリスクが大きく、身動きができなくなっていました。
今回コードベースを整理したことで身軽になり、新たな領域でのOdooの活用の可能性が拡がりました。実際、ヘルプデスクやサブスクリプション、マーケティング関連機能の運用に向け、具体的な検討が進んでいます。
反省点
包み隠さずに言うと、最大の反省点は、当初の見積が甘く、作業工数が想定以上にかかり大きな遅延が発生したことです。
見積が困難であった点は次の2点に集約されます。
- 引き継いだカスタムモジュールの仕様や品質が正確に把握できていなかった
- 10.0→15.0という、比較的多くのバージョンをまたがるアップグレードであった
後者は作業を進めながら課題に対処するアプローチでもよいのですが、前者については段取りを工夫すべきでした。
普段私たちはOdoo本体やOCAモジュール、そして自分たちで実装したカスタムモジュールを扱っており、これらについては基本的に品質がそれなりに担保されているか、私たちで内容を把握しています。ですが、品質基準をともにしない第三者で開発した機能については勝手が全然異なります。結果としてかかった工数には影響しなかったのかもしれませんが、当初の工数見積が過小で複数回にわたるスケジュール調整が発生し、お客様にご迷惑をおかけしました。
将来に向けて
「既存のOdoo環境をいかにスムースに新バージョンに移行するか」の問いは、日本でのOdoo普及が進むにつれ、今後もっと認識されてくるはずです。そこへの先鞭をつける意味で改めて何ができるのかを考えると、以下のようなものに落ち着きます。コタエルでは既に実行していることではありますが、ユーザ・事業者ともに、ライフサイクルコストを抑えるために認識していきたいポイントです。
１．カスタマイズは極力避ける
Odooはカスタマイズでの拡張がしやすいプロダクトであるがゆえに、注意しなければ過度なカスタマイズが発生してしまいます。お客様の要求が出てきたときに、「カスタマイズで対応できるから」と安易にその方向に進むのではなく、業務を標準機能に合わせることができないのか、なんとなくではなく明確にそうせざるを得ない理由があることをもってカスタマイズを施す判断をする姿勢が肝要です。
カスタマイズをするときにはその先の保守コストやアップグレード時の対応コストにまで、お客様の考えが及ばないことも多くありますが、だからこそ私たち事業者はここをしっかり押さえるべきです。
２．第三者モジュールはOCAのもののみ利用する
Odooの特長として多数の第三者モジュール（2023年5月現在Odooのアプリストアで4万件以上）が利用できることがよく挙げられますが、ほとんどのモジュールは適正な品質基準に則っていません。過去の経験上、OCA以外の第三者モジュールはインストールすればとりあえずは動くけれども、コードを見るとぐちゃぐちゃであることが多いです。OCAのモジュールであれば基本的に設計がしっかりしており、所定の品質管理基準を満たしたものとなっています。
３．自社開発のカスタムモジュールは品質基準をOCAに合わせる
コタエルでは汎用的な要件については原則OCAでモジュール開発することにしています（要件が汎用的なものになるように要件定義をするようにもしています）。汎用的な要件にできない場合は、お客様向けの開発を行います。この際コーディングスタイルチェックや継続インテグレーションの仕組みはOCAと同じものを使用することでモジュールの品質を担保しています。
これをやることには1つ大きなメリットがあり、OCAとの連携がスムースになります。お客様向けにスピーディに機能を追加する際には一度OCAから切り離して作業を進めることもあるのですが、その後そのモジュールをOCAに加えたくなった場合に、OCAレポジトリへのプルリクエストが出しやすくなります。
まとめ
どのようなERPシステムでもカスタマイズを施した環境のバージョンアップには難しいものがありますが、Odooの場合も多分にもれず根気強い試行錯誤と検証作業の繰り返しが求められます。導入時には保守性やバージョンアップ時のコストに考えが至らず、そのため誤った判断をしてしまうこともありがちです。
対策は至って地味で、まずは極力Odooの標準機能を使用する方向に寄せ安易なカスタマイズはしない方針を貫くことです。Odooは拡張性が高いからこそ、この点には注意が必要です。中途半端なコンサルタントほどカスタマイズになびきます。
そしてカスタムモジュールを入れる際には品質を担保する仕組み/プロセスのもとで行うということです。これを徹底せずに結果オーライとなることはないと考えた方がよいです。必ず高くつきます。ここについてはユーザ側も勉強しておきましょう。可能であれば複数の事業者にコンタクトしてどのようなプラクティスを取り入れているのか聞いてみてください。
お客様のことば
バージョンアップにより全体的にパフォーマンスが良くなり、操作性・生産性が高まりました。カスタムコードのクリーンアップにより保守性が向上したことと、Odooの仕組みをより深く理解したことで、自己解決できる課題の幅が広がりました。カスタマイズは極力避けるべきという考えを身をもって学びました。
Odooセカンドオピニオン
Odooの専門家として、Odoo導入・運用体制やカスタムコード品質等につき第三者の見地からアドバイスいたします。
Photo by Karsten Würth on Unsplash
【Odooバージョンアップ事例】株式会社エムアイセブンジャパン様（V10→V15）